Repository: helm/helm-www Branch: main Commit: 7679207217e9 Files: 2098 Total size: 10.3 MB Directory structure: gitextract_c40cox6w/ ├── .containerignore ├── .editorconfig ├── .github/ │ └── workflows/ │ ├── build.yml │ ├── stale.yml │ ├── typos.yml │ └── update-community-docs.yml ├── .gitignore ├── .markdownlint.json ├── .netlify/ │ └── state.json ├── .nvmrc ├── .typos.toml ├── .vscode/ │ └── launch.json ├── AGENTS.md ├── ARCHITECTURAL_DECISIONS.md ├── CONTRIBUTING-ko.md ├── CONTRIBUTING.md ├── Containerfile ├── HELM2-TO-DOCUSAURUS.md ├── HELM3-TO-DOCUSAURUS.md ├── LICENSE ├── Makefile ├── OWNERS ├── README-ko.md ├── README.md ├── blog/ │ ├── 2018-06-01-cncf.md │ ├── 2018-07-23-bring-helm-home.md │ ├── 2018-07-24-helm-emeritus-rimus.md │ ├── 2018-08-27-helm-switch-dco.md │ ├── 2018-09-07-new-gov-and-elections.md │ ├── 2018-09-25-chart-testing-intro.md │ ├── 2018-10-04-helm-org-maintainers.md │ ├── 2018-12-11-helm-hub.md │ ├── 2019-01-14-chartmuseum-security-notice.md │ ├── 2019-01-14-helm-security-notice.md │ ├── 2019-04-18-helm-summit-eu-2019.md │ ├── 2019-04-22-helm-3-preview-pt1.md │ ├── 2019-04-25-helm-3-preview-pt2.md │ ├── 2019-04-29-helm-3-preview-pt3.md │ ├── 2019-05-02-helm-3-preview-pt4.md │ ├── 2019-05-06-helm-3-preview-pt5.md │ ├── 2019-05-09-helm-3-preview-pt6.md │ ├── 2019-05-13-helm-3-preview-pt7.md │ ├── 2019-06-10-get-helm-sh.md │ ├── 2019-08-27-helm-v3-beta.md │ ├── 2019-09-11-migrate-from-helm-v2-to-helm-v3.md │ ├── 2019-10-22-helm-2150-released.md │ ├── 2019-10-30-helm-symlink-security-notice.md │ ├── 2019-11-04-helm-security-audit-results.md │ ├── 2019-11-11-community-management.md │ ├── 2019-11-13-helm-3-released.md │ ├── 2019-11-15-helm-at-cloudnativecon.md │ ├── 2020-04-02-covid-19-extending-helm-v2-bug-fixes.md │ ├── 2020-04-30-celebrating-helms-cncf-graduation.md │ ├── 2020-08-13-helm-v2-deprecation-timeline.md │ ├── 2020-10-07-helm-hub-moving-artifact-hub.md │ ├── 2020-10-19-helm-turns-five.md │ ├── 2020-10-26-new-location-stable-incubator-charts.md │ ├── 2020-10-30-charts-repo-deprecation.md │ ├── 2020-11-11-helm-release-process.md │ ├── 2020-11-13-helm-2-becomes-unsupported.md │ ├── 2021-03-05-second-security-audit/ │ │ └── index.md │ ├── 2021-06-24-welcome-martin-hickey.md │ ├── 2022-01-11-welcome-karen-chu.md │ ├── 2022-02-28-storing-charts-in-oci.md │ ├── 2022-04-19-tools-to-manage-helm-declaratively.md │ ├── 2022-10-14-helm-at-kubecon-na-22.md │ ├── 2022-11-14-welcome-yxxhero.md │ ├── 2023-03-31-helm-completes-fuzzing-security-audit.md │ ├── 2023-05-15-helm-oci-mediatypes.md │ ├── 2023-09-29-helm-3.13.md │ ├── 2024-03-14-cve-2019-25210.md │ ├── 2024-06-26-the-road-to-helm-4.md │ ├── 2024-07-16-helm2to3-becomes-unsupported.md │ ├── 2024-10-07-kubecon-na-24/ │ │ └── index.md │ ├── 2024-11-08-experience-helm-release-kubecon-na-24.md │ ├── 2025-08-19-debian-helm-repository-move.md │ ├── 2025-09-09-path-to-helm-v4.md │ ├── 2025-10-19-helm-turns-10/ │ │ └── index.md │ ├── 2025-11-04-helm-at-kubecon-na-25.md │ ├── 2025-11-17-helm-4-released/ │ │ └── index.md │ ├── authors.yml │ └── helm-at-kubecon-eu-25.md ├── code-of-conduct.md ├── community/ │ ├── MAINTAINERS.md │ ├── README.md │ ├── SECURITY.md │ ├── art/ │ │ └── readme.md │ ├── blog-topics.md │ ├── code-of-conduct.md │ ├── communication.md │ ├── developers.md │ ├── governance/ │ │ ├── README.md │ │ ├── _category_.json │ │ └── governance.md │ ├── hips/ │ │ ├── README.md │ │ ├── archives/ │ │ │ ├── README.md │ │ │ ├── helm/ │ │ │ │ ├── distributed-search.md │ │ │ │ └── helm-v3/ │ │ │ │ ├── 000-helm-v3.md │ │ │ │ ├── 001-charts.md │ │ │ │ ├── 002-events.md │ │ │ │ ├── 003-state.md │ │ │ │ ├── 004-hooks.md │ │ │ │ ├── 005-plugins.md │ │ │ │ ├── 006-repositories.md │ │ │ │ ├── 007-security.md │ │ │ │ ├── 008-controller.md │ │ │ │ ├── 009-package_manager.md │ │ │ │ ├── 010-removed.md │ │ │ │ ├── 011-user_stories.md │ │ │ │ ├── 012-chart-dev-stories.md │ │ │ │ └── research/ │ │ │ │ └── package-manager-ux.md │ │ │ └── monocular/ │ │ │ └── 1.0-improvements.md │ │ ├── hip-0001.md │ │ ├── hip-0002.md │ │ ├── hip-0003.md │ │ ├── hip-0004.md │ │ ├── hip-0005.md │ │ ├── hip-0006.md │ │ ├── hip-0007.md │ │ ├── hip-0008.md │ │ ├── hip-0009.md │ │ ├── hip-0010.md │ │ ├── hip-0011.md │ │ ├── hip-0012.md │ │ ├── hip-0014.md │ │ ├── hip-0015.md │ │ ├── hip-0016.md │ │ ├── hip-0017.md │ │ ├── hip-0018.md │ │ ├── hip-0019.md │ │ ├── hip-0020.md │ │ ├── hip-0021.md │ │ ├── hip-0022.md │ │ ├── hip-0023.md │ │ ├── hip-0024.md │ │ ├── hip-0025.md │ │ └── hip-0026.md │ ├── history.mdx │ ├── incubator.md │ ├── localization.md │ ├── meeting-notes/ │ │ ├── 2017.md │ │ ├── 2018.md │ │ ├── 2019.md │ │ ├── 2020.md │ │ ├── 2021.md │ │ └── index.mdx │ ├── related.md │ ├── release_checklist.md │ ├── release_policy.md │ ├── stable-repo-charts-new-locations.md │ └── user-profiles.md ├── docs/ │ ├── _v4-in-progress.mdx │ ├── changelog.md │ ├── chart_best_practices/ │ │ ├── conventions.md │ │ ├── custom_resource_definitions.md │ │ ├── dependencies.mdx │ │ ├── index.mdx │ │ ├── labels.md │ │ ├── pods.md │ │ ├── rbac.md │ │ ├── templates.md │ │ └── values.md │ ├── chart_template_guide/ │ │ ├── accessing_files.md │ │ ├── builtin_objects.md │ │ ├── control_structures.md │ │ ├── data_types.md │ │ ├── debugging.md │ │ ├── function_list.mdx │ │ ├── functions_and_pipelines.mdx │ │ ├── getting_started.md │ │ ├── helm_ignore_file.md │ │ ├── index.mdx │ │ ├── named_templates.md │ │ ├── notes_files.md │ │ ├── subcharts_and_globals.md │ │ ├── values_files.mdx │ │ ├── variables.md │ │ ├── wrapping_up.md │ │ └── yaml_techniques.md │ ├── glossary/ │ │ └── index.mdx │ ├── helm/ │ │ ├── _category_.json │ │ ├── helm.md │ │ ├── helm_completion.md │ │ ├── helm_completion_bash.md │ │ ├── helm_completion_fish.md │ │ ├── helm_completion_powershell.md │ │ ├── helm_completion_zsh.md │ │ ├── helm_create.md │ │ ├── helm_dependency.md │ │ ├── helm_dependency_build.md │ │ ├── helm_dependency_list.md │ │ ├── helm_dependency_update.md │ │ ├── helm_env.md │ │ ├── helm_get.md │ │ ├── helm_get_all.md │ │ ├── helm_get_hooks.md │ │ ├── helm_get_manifest.md │ │ ├── helm_get_metadata.md │ │ ├── helm_get_notes.md │ │ ├── helm_get_values.md │ │ ├── helm_history.md │ │ ├── helm_install.md │ │ ├── helm_lint.md │ │ ├── helm_list.md │ │ ├── helm_package.md │ │ ├── helm_plugin.md │ │ ├── helm_plugin_install.md │ │ ├── helm_plugin_list.md │ │ ├── helm_plugin_package.md │ │ ├── helm_plugin_uninstall.md │ │ ├── helm_plugin_update.md │ │ ├── helm_plugin_verify.md │ │ ├── helm_pull.md │ │ ├── helm_push.md │ │ ├── helm_registry.md │ │ ├── helm_registry_login.md │ │ ├── helm_registry_logout.md │ │ ├── helm_repo.md │ │ ├── helm_repo_add.md │ │ ├── helm_repo_index.md │ │ ├── helm_repo_list.md │ │ ├── helm_repo_remove.md │ │ ├── helm_repo_update.md │ │ ├── helm_rollback.md │ │ ├── helm_search.md │ │ ├── helm_search_hub.md │ │ ├── helm_search_repo.md │ │ ├── helm_show.md │ │ ├── helm_show_all.md │ │ ├── helm_show_chart.md │ │ ├── helm_show_crds.md │ │ ├── helm_show_readme.md │ │ ├── helm_show_values.md │ │ ├── helm_status.md │ │ ├── helm_template.md │ │ ├── helm_test.md │ │ ├── helm_uninstall.md │ │ ├── helm_upgrade.md │ │ ├── helm_verify.md │ │ ├── helm_version.md │ │ └── index.mdx │ ├── howto/ │ │ ├── chart_releaser_action.md │ │ ├── chart_repository_sync_example.md │ │ ├── charts_tips_and_tricks.md │ │ └── index.mdx │ ├── index.mdx │ ├── intro/ │ │ ├── CheatSheet.mdx │ │ ├── index.mdx │ │ ├── install.mdx │ │ ├── quickstart.md │ │ └── using_helm.mdx │ ├── overview.md │ ├── plugins/ │ │ ├── developer/ │ │ │ ├── index.mdx │ │ │ ├── tutorial-cli-plugin.mdx │ │ │ ├── tutorial-getter-plugin.mdx │ │ │ └── tutorial-postrenderer-plugin.mdx │ │ ├── index.mdx │ │ ├── overview.md │ │ └── user/ │ │ └── index.md │ ├── sdk/ │ │ ├── examples.mdx │ │ ├── gosdk.mdx │ │ └── index.mdx │ └── topics/ │ ├── advanced.mdx │ ├── architecture.md │ ├── chart_repository.md │ ├── chart_tests.md │ ├── charts.mdx │ ├── charts_hooks.md │ ├── index.mdx │ ├── kubernetes_apis.md │ ├── kubernetes_distros.md │ ├── library_charts.md │ ├── permissions_sql_storage_backend.md │ ├── plugins.mdx │ ├── provenance.mdx │ ├── rbac.md │ ├── registries.mdx │ └── version_skew.mdx ├── docusaurus.config.js ├── i18n/ │ ├── de/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ └── helm_version.md │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── el/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── helm/ │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ └── helm_version.md │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ └── charts_tips_and_tricks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ ├── examples.mdx │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── es/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── helm/ │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ └── helm_version.md │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── fr/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── it/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── index.mdx │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── release_policy.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── ja/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ ├── developers.md │ │ │ ├── history.mdx │ │ │ ├── localization.md │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── ko/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ ├── 2019-11-13-helm-3-released.md │ │ │ ├── 2019-11-15-helm-at-cloudnativecon.md │ │ │ ├── 2020-04-02-covid-19-extending-helm-v2-bug-fixes.md │ │ │ ├── 2020-04-30-celebrating-helms-cncf-graduation.md │ │ │ ├── 2020-08-13-helm-v2-deprecation-timeline.md │ │ │ ├── 2020-10-07-helm-hub-moving-artifact-hub.md │ │ │ ├── 2020-10-19-helm-turns-five.md │ │ │ ├── 2020-10-26-new-location-stable-incubator-charts.md │ │ │ ├── 2020-10-30-charts-repo-deprecation.md │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current/ │ │ │ │ ├── _v4-in-progress.mdx │ │ │ │ ├── changelog.md │ │ │ │ ├── index.mdx │ │ │ │ ├── overview.md │ │ │ │ └── plugins/ │ │ │ │ ├── developer/ │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── tutorial-cli-plugin.mdx │ │ │ │ │ ├── tutorial-getter-plugin.mdx │ │ │ │ │ └── tutorial-postrenderer-plugin.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── overview.md │ │ │ │ └── user/ │ │ │ │ └── index.md │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ ├── _install.mdx │ │ │ │ │ ├── _list.mdx │ │ │ │ │ ├── _main.mdx │ │ │ │ │ ├── _pull.mdx │ │ │ │ │ ├── _uninstall.mdx │ │ │ │ │ ├── _upgrade.mdx │ │ │ │ │ ├── examples.mdx │ │ │ │ │ ├── gosdk.md │ │ │ │ │ └── index.mdx │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ ├── developers.md │ │ │ ├── history.mdx │ │ │ ├── localization.md │ │ │ ├── related.md │ │ │ ├── release_checklist.md │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── pt/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ └── gosdk.md │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── ru/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ ├── _install.mdx │ │ │ │ │ ├── _list.mdx │ │ │ │ │ ├── _main.mdx │ │ │ │ │ ├── _pull.mdx │ │ │ │ │ ├── _uninstall.mdx │ │ │ │ │ ├── _upgrade.mdx │ │ │ │ │ ├── examples.mdx │ │ │ │ │ ├── gosdk.md │ │ │ │ │ └── index.mdx │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ ├── uk/ │ │ ├── code.json │ │ ├── docusaurus-plugin-content-blog/ │ │ │ ├── 2024-10-07-kubecon-na-24/ │ │ │ │ └── index.md │ │ │ ├── 2025-09-09-path-to-helm-v4.md │ │ │ └── options.json │ │ ├── docusaurus-plugin-content-docs/ │ │ │ ├── current/ │ │ │ │ ├── _v4-in-progress.mdx │ │ │ │ ├── changelog.md │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.mdx │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.mdx │ │ │ │ │ ├── functions_and_pipelines.mdx │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.mdx │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.mdx │ │ │ │ │ └── uninstalling.mdx │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_package.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_plugin_verify.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.mdx │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.mdx │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.mdx │ │ │ │ ├── overview.md │ │ │ │ ├── plugins/ │ │ │ │ │ ├── developer/ │ │ │ │ │ │ ├── index.mdx │ │ │ │ │ │ ├── tutorial-cli-plugin.mdx │ │ │ │ │ │ ├── tutorial-getter-plugin.mdx │ │ │ │ │ │ └── tutorial-postrenderer-plugin.mdx │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── overview.md │ │ │ │ │ └── user/ │ │ │ │ │ └── index.md │ │ │ │ ├── sdk/ │ │ │ │ │ ├── examples.mdx │ │ │ │ │ ├── gosdk.mdx │ │ │ │ │ └── index.mdx │ │ │ │ └── topics/ │ │ │ │ ├── advanced.mdx │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.mdx │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.mdx │ │ │ │ ├── provenance.mdx │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.mdx │ │ │ │ └── version_skew.mdx │ │ │ ├── current.json │ │ │ ├── version-2.json │ │ │ ├── version-3/ │ │ │ │ ├── chart_best_practices/ │ │ │ │ │ ├── conventions.md │ │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ │ ├── dependencies.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── labels.md │ │ │ │ │ ├── pods.md │ │ │ │ │ ├── rbac.md │ │ │ │ │ ├── templates.md │ │ │ │ │ └── values.md │ │ │ │ ├── chart_template_guide/ │ │ │ │ │ ├── accessing_files.md │ │ │ │ │ ├── builtin_objects.md │ │ │ │ │ ├── control_structures.md │ │ │ │ │ ├── data_types.md │ │ │ │ │ ├── debugging.md │ │ │ │ │ ├── function_list.md │ │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ │ ├── getting_started.md │ │ │ │ │ ├── helm_ignore_file.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── named_templates.md │ │ │ │ │ ├── notes_files.md │ │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ │ ├── values_files.md │ │ │ │ │ ├── variables.md │ │ │ │ │ ├── wrapping_up.md │ │ │ │ │ └── yaml_techniques.md │ │ │ │ ├── faq/ │ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── installing.md │ │ │ │ │ ├── troubleshooting.md │ │ │ │ │ └── uninstalling.md │ │ │ │ ├── glossary/ │ │ │ │ │ └── index.mdx │ │ │ │ ├── helm/ │ │ │ │ │ ├── _category_.json │ │ │ │ │ ├── helm.md │ │ │ │ │ ├── helm_completion.md │ │ │ │ │ ├── helm_completion_bash.md │ │ │ │ │ ├── helm_completion_fish.md │ │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ │ ├── helm_create.md │ │ │ │ │ ├── helm_dependency.md │ │ │ │ │ ├── helm_dependency_build.md │ │ │ │ │ ├── helm_dependency_list.md │ │ │ │ │ ├── helm_dependency_update.md │ │ │ │ │ ├── helm_env.md │ │ │ │ │ ├── helm_get.md │ │ │ │ │ ├── helm_get_all.md │ │ │ │ │ ├── helm_get_hooks.md │ │ │ │ │ ├── helm_get_manifest.md │ │ │ │ │ ├── helm_get_metadata.md │ │ │ │ │ ├── helm_get_notes.md │ │ │ │ │ ├── helm_get_values.md │ │ │ │ │ ├── helm_history.md │ │ │ │ │ ├── helm_install.md │ │ │ │ │ ├── helm_lint.md │ │ │ │ │ ├── helm_list.md │ │ │ │ │ ├── helm_package.md │ │ │ │ │ ├── helm_plugin.md │ │ │ │ │ ├── helm_plugin_install.md │ │ │ │ │ ├── helm_plugin_list.md │ │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ │ ├── helm_plugin_update.md │ │ │ │ │ ├── helm_pull.md │ │ │ │ │ ├── helm_push.md │ │ │ │ │ ├── helm_registry.md │ │ │ │ │ ├── helm_registry_login.md │ │ │ │ │ ├── helm_registry_logout.md │ │ │ │ │ ├── helm_repo.md │ │ │ │ │ ├── helm_repo_add.md │ │ │ │ │ ├── helm_repo_index.md │ │ │ │ │ ├── helm_repo_list.md │ │ │ │ │ ├── helm_repo_remove.md │ │ │ │ │ ├── helm_repo_update.md │ │ │ │ │ ├── helm_rollback.md │ │ │ │ │ ├── helm_search.md │ │ │ │ │ ├── helm_search_hub.md │ │ │ │ │ ├── helm_search_repo.md │ │ │ │ │ ├── helm_show.md │ │ │ │ │ ├── helm_show_all.md │ │ │ │ │ ├── helm_show_chart.md │ │ │ │ │ ├── helm_show_crds.md │ │ │ │ │ ├── helm_show_readme.md │ │ │ │ │ ├── helm_show_values.md │ │ │ │ │ ├── helm_status.md │ │ │ │ │ ├── helm_template.md │ │ │ │ │ ├── helm_test.md │ │ │ │ │ ├── helm_uninstall.md │ │ │ │ │ ├── helm_upgrade.md │ │ │ │ │ ├── helm_verify.md │ │ │ │ │ ├── helm_version.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── howto/ │ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ │ └── index.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── intro/ │ │ │ │ │ ├── CheatSheet.md │ │ │ │ │ ├── index.mdx │ │ │ │ │ ├── install.md │ │ │ │ │ ├── quickstart.md │ │ │ │ │ └── using_helm.md │ │ │ │ ├── sdk/ │ │ │ │ │ ├── _install.mdx │ │ │ │ │ ├── _list.mdx │ │ │ │ │ ├── _main.mdx │ │ │ │ │ ├── _pull.mdx │ │ │ │ │ ├── _uninstall.mdx │ │ │ │ │ ├── _upgrade.mdx │ │ │ │ │ ├── examples.mdx │ │ │ │ │ ├── gosdk.md │ │ │ │ │ └── index.mdx │ │ │ │ └── topics/ │ │ │ │ ├── advanced.md │ │ │ │ ├── architecture.md │ │ │ │ ├── chart_repository.md │ │ │ │ ├── chart_tests.md │ │ │ │ ├── charts.md │ │ │ │ ├── charts_hooks.md │ │ │ │ ├── index.mdx │ │ │ │ ├── kubernetes_apis.md │ │ │ │ ├── kubernetes_distros.md │ │ │ │ ├── library_charts.md │ │ │ │ ├── permissions_sql_storage_backend.md │ │ │ │ ├── plugins.md │ │ │ │ ├── provenance.md │ │ │ │ ├── rbac.md │ │ │ │ ├── registries.md │ │ │ │ ├── v2_v3_migration.md │ │ │ │ └── version_skew.md │ │ │ └── version-3.json │ │ ├── docusaurus-plugin-content-docs-community/ │ │ │ └── current/ │ │ │ ├── MAINTAINERS.md │ │ │ ├── README.md │ │ │ ├── code-of-conduct.md │ │ │ ├── communication.md │ │ │ ├── developers.md │ │ │ ├── history.mdx │ │ │ ├── localization.md │ │ │ ├── related.md │ │ │ ├── release_checklist.md │ │ │ └── release_policy.md │ │ └── docusaurus-theme-classic/ │ │ ├── footer.json │ │ └── navbar.json │ └── zh/ │ ├── code.json │ ├── docusaurus-plugin-content-blog/ │ │ └── options.json │ ├── docusaurus-plugin-content-docs/ │ │ ├── current.json │ │ ├── version-2.json │ │ ├── version-3/ │ │ │ ├── chart_best_practices/ │ │ │ │ ├── conventions.md │ │ │ │ ├── custom_resource_definitions.md │ │ │ │ ├── dependencies.md │ │ │ │ ├── index.mdx │ │ │ │ ├── labels.md │ │ │ │ ├── pods.md │ │ │ │ ├── rbac.md │ │ │ │ ├── templates.md │ │ │ │ └── values.md │ │ │ ├── chart_template_guide/ │ │ │ │ ├── accessing_files.md │ │ │ │ ├── builtin_objects.md │ │ │ │ ├── control_structures.md │ │ │ │ ├── data_types.md │ │ │ │ ├── debugging.md │ │ │ │ ├── function_list.md │ │ │ │ ├── functions_and_pipelines.md │ │ │ │ ├── getting_started.md │ │ │ │ ├── helm_ignore_file.md │ │ │ │ ├── index.mdx │ │ │ │ ├── named_templates.md │ │ │ │ ├── notes_files.md │ │ │ │ ├── subcharts_and_globals.md │ │ │ │ ├── values_files.md │ │ │ │ ├── variables.md │ │ │ │ ├── wrapping_up.md │ │ │ │ └── yaml_techniques.md │ │ │ ├── example/ │ │ │ │ ├── golang.md │ │ │ │ └── index.mdx │ │ │ ├── faq/ │ │ │ │ ├── changes_since_helm2.md │ │ │ │ ├── index.mdx │ │ │ │ ├── installing.md │ │ │ │ ├── troubleshooting.md │ │ │ │ └── uninstalling.md │ │ │ ├── glossary/ │ │ │ │ └── index.mdx │ │ │ ├── helm/ │ │ │ │ ├── _category_.json │ │ │ │ ├── helm.md │ │ │ │ ├── helm_completion.md │ │ │ │ ├── helm_completion_bash.md │ │ │ │ ├── helm_completion_fish.md │ │ │ │ ├── helm_completion_powershell.md │ │ │ │ ├── helm_completion_zsh.md │ │ │ │ ├── helm_create.md │ │ │ │ ├── helm_delete.md │ │ │ │ ├── helm_dependency.md │ │ │ │ ├── helm_dependency_build.md │ │ │ │ ├── helm_dependency_list.md │ │ │ │ ├── helm_dependency_update.md │ │ │ │ ├── helm_env.md │ │ │ │ ├── helm_get.md │ │ │ │ ├── helm_get_all.md │ │ │ │ ├── helm_get_hooks.md │ │ │ │ ├── helm_get_manifest.md │ │ │ │ ├── helm_get_metadata.md │ │ │ │ ├── helm_get_notes.md │ │ │ │ ├── helm_get_values.md │ │ │ │ ├── helm_history.md │ │ │ │ ├── helm_init.md │ │ │ │ ├── helm_inspect.md │ │ │ │ ├── helm_install.md │ │ │ │ ├── helm_lint.md │ │ │ │ ├── helm_list.md │ │ │ │ ├── helm_package.md │ │ │ │ ├── helm_plugin.md │ │ │ │ ├── helm_plugin_install.md │ │ │ │ ├── helm_plugin_list.md │ │ │ │ ├── helm_plugin_uninstall.md │ │ │ │ ├── helm_plugin_update.md │ │ │ │ ├── helm_pull.md │ │ │ │ ├── helm_push.md │ │ │ │ ├── helm_registry.md │ │ │ │ ├── helm_registry_login.md │ │ │ │ ├── helm_registry_logout.md │ │ │ │ ├── helm_repo.md │ │ │ │ ├── helm_repo_add.md │ │ │ │ ├── helm_repo_index.md │ │ │ │ ├── helm_repo_list.md │ │ │ │ ├── helm_repo_remove.md │ │ │ │ ├── helm_repo_update.md │ │ │ │ ├── helm_rollback.md │ │ │ │ ├── helm_search.md │ │ │ │ ├── helm_search_hub.md │ │ │ │ ├── helm_search_repo.md │ │ │ │ ├── helm_show.md │ │ │ │ ├── helm_show_all.md │ │ │ │ ├── helm_show_chart.md │ │ │ │ ├── helm_show_crds.md │ │ │ │ ├── helm_show_readme.md │ │ │ │ ├── helm_show_values.md │ │ │ │ ├── helm_status.md │ │ │ │ ├── helm_template.md │ │ │ │ ├── helm_test.md │ │ │ │ ├── helm_uninstall.md │ │ │ │ ├── helm_upgrade.md │ │ │ │ ├── helm_verify.md │ │ │ │ ├── helm_version.md │ │ │ │ └── index.mdx │ │ │ ├── howto/ │ │ │ │ ├── chart_releaser_action.md │ │ │ │ ├── chart_repository_sync_example.md │ │ │ │ ├── charts_tips_and_tricks.md │ │ │ │ └── index.mdx │ │ │ ├── index.mdx │ │ │ ├── intro/ │ │ │ │ ├── CheatSheet.md │ │ │ │ ├── index.mdx │ │ │ │ ├── install.md │ │ │ │ ├── quickstart.md │ │ │ │ └── using_helm.md │ │ │ ├── sdk/ │ │ │ │ ├── _install.mdx │ │ │ │ ├── _list.mdx │ │ │ │ ├── _main.mdx │ │ │ │ ├── _pull.mdx │ │ │ │ ├── _uninstall.mdx │ │ │ │ ├── _upgrade.mdx │ │ │ │ ├── examples.mdx │ │ │ │ ├── gosdk.md │ │ │ │ └── index.mdx │ │ │ └── topics/ │ │ │ ├── advanced.md │ │ │ ├── architecture.md │ │ │ ├── chart_repository.md │ │ │ ├── chart_tests.md │ │ │ ├── charts.md │ │ │ ├── charts_hooks.md │ │ │ ├── index.mdx │ │ │ ├── kubernetes_apis.md │ │ │ ├── kubernetes_distros.md │ │ │ ├── library_charts.md │ │ │ ├── permissions_sql_storage_backend.md │ │ │ ├── plugins.md │ │ │ ├── provenance.md │ │ │ ├── rbac.md │ │ │ ├── registries.md │ │ │ ├── v2_v3_migration.md │ │ │ └── version_skew.md │ │ └── version-3.json │ ├── docusaurus-plugin-content-docs-community/ │ │ └── current/ │ │ ├── developers.md │ │ ├── history.mdx │ │ ├── localization.md │ │ ├── related.md │ │ ├── release_checklist.md │ │ └── release_policy.md │ └── docusaurus-theme-classic/ │ ├── footer.json │ └── navbar.json ├── netlify-plugins/ │ ├── README.md │ ├── cache-docusaurus-dirs-api/ │ │ ├── index.js │ │ └── manifest.yml │ └── cache-docusaurus-dirs-file/ │ ├── index.js │ └── manifest.yml ├── netlify.toml ├── package.json ├── postcss.config.js ├── remote-content_community.js ├── scripts/ │ ├── migrate-v2-docs.js │ ├── migrate-v3-docs.js │ ├── regenerate-cli-docs.mjs │ ├── util/ │ │ ├── href-diffs-process.js │ │ ├── util-docusaurus-links.js │ │ ├── util-file-operations.js │ │ ├── util-frontmatter.js │ │ ├── util-migration.js │ │ └── util-text-replacements.js │ ├── v2/ │ │ ├── copy-files.js │ │ ├── href-diffs.json │ │ ├── menu-generate.js │ │ └── menu.json │ ├── v3/ │ │ ├── add-netlify-redirects.js │ │ ├── href-diffs.json │ │ ├── migrate-sdk-section.js │ │ ├── migrate-sdk-section.json │ │ ├── process-helm-files.js │ │ ├── remove-aliases.js │ │ ├── removed-aliases.json │ │ └── sdk-href-diffs.json │ └── v4/ │ └── changelog.mjs ├── sdkexamples/ │ ├── .gitignore │ ├── Makefile │ ├── README.md │ ├── go.mod │ ├── go.sum │ ├── install.go │ ├── list.go │ ├── main.go │ ├── pull.go │ ├── tlsutil.go │ ├── uninstall.go │ └── upgrade.go ├── sidebars.js ├── sidebars_community.js ├── src/ │ ├── client-modules/ │ │ └── heroHeightCalculator.js │ ├── components/ │ │ ├── Boat/ │ │ │ ├── boat.css │ │ │ └── index.js │ │ ├── GetVersion.js │ │ ├── HomeAbout/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── HomeCommunity/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── HomeFeatures/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── HomeGettingStarted/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── HomeHeader/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ └── HomeSupport/ │ │ ├── index.js │ │ └── styles.module.css │ ├── css/ │ │ ├── announcement-bar.css │ │ ├── content.css │ │ ├── custom.css │ │ ├── fonts.css │ │ ├── footer.css │ │ ├── home-cards.module.css │ │ ├── home-sections.module.css │ │ ├── main.css │ │ └── navbar.css │ ├── pages/ │ │ ├── helm-4-release-party.js │ │ ├── index.js │ │ ├── index.module.css │ │ ├── markdown-page.md │ │ └── party.module.css │ ├── theme/ │ │ ├── Blog/ │ │ │ └── Pages/ │ │ │ ├── BlogAuthorsListPage/ │ │ │ │ ├── index.js │ │ │ │ └── styles.module.css │ │ │ └── BlogAuthorsPostsPage/ │ │ │ └── index.js │ │ ├── BlogAuthorsListBreadcrumbs/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── BlogAuthorsPostsBreadcrumbs/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── BlogBreadcrumbs/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── BlogLayout/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── BlogListBreadcrumbs/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── BlogListPage/ │ │ │ ├── StructuredData/ │ │ │ │ └── index.js │ │ │ └── index.js │ │ ├── BlogPostItem/ │ │ │ └── index.tsx │ │ ├── BlogPostPage/ │ │ │ ├── Metadata/ │ │ │ │ └── index.js │ │ │ ├── StructuredData/ │ │ │ │ └── index.js │ │ │ └── index.js │ │ ├── BlogSidebar/ │ │ │ └── Desktop/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── DocBreadcrumbs/ │ │ │ ├── Items/ │ │ │ │ └── Home/ │ │ │ │ ├── index.js │ │ │ │ └── styles.module.css │ │ │ ├── StructuredData/ │ │ │ │ └── index.js │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ └── TOCCollapsible/ │ │ ├── CollapseButton/ │ │ │ ├── index.js │ │ │ └── styles.module.css │ │ ├── index.js │ │ └── styles.module.css │ └── utils/ │ ├── communityDocsHelpers.js │ └── communityDocsTransforms.js ├── static/ │ ├── .nojekyll │ ├── chartmuseum/ │ │ └── index.html │ └── helm/ │ ├── index.html │ ├── v2/ │ │ └── index.html │ ├── v3/ │ │ └── index.html │ └── v4/ │ └── index.html ├── style-guide.md ├── versioned_docs/ │ ├── version-2/ │ │ ├── architecture.md │ │ ├── chart_best_practices/ │ │ │ ├── chart_best_practices.md │ │ │ ├── conventions.md │ │ │ ├── custom_resource_definitions.md │ │ │ ├── labels.md │ │ │ ├── pods.md │ │ │ ├── rbac.md │ │ │ ├── requirements.md │ │ │ ├── templates.md │ │ │ └── values.md │ │ ├── chart_template_guide/ │ │ │ ├── accessing_files.md │ │ │ ├── builtin_objects.md │ │ │ ├── chart_template_guide.md │ │ │ ├── control_structures.md │ │ │ ├── data_types.md │ │ │ ├── debugging.md │ │ │ ├── functions_and_pipelines.md │ │ │ ├── getting_started.md │ │ │ ├── helm_ignore_file.md │ │ │ ├── named_templates.md │ │ │ ├── notes_files.md │ │ │ ├── subcharts_and_globals.md │ │ │ ├── values_files.md │ │ │ ├── variables.md │ │ │ ├── wrapping_up.md │ │ │ └── yaml_techniques.md │ │ ├── developers.md │ │ ├── developing_charts/ │ │ │ ├── chart_repository.md │ │ │ ├── chart_repository_faq.md │ │ │ ├── chart_repository_sync_example.md │ │ │ ├── chart_tests.md │ │ │ ├── charts_hooks.md │ │ │ ├── charts_tips_and_tricks.md │ │ │ ├── developing_charts.md │ │ │ └── provenance.md │ │ ├── glossary.md │ │ ├── helm/ │ │ │ ├── helm.md │ │ │ ├── helm_completion.md │ │ │ ├── helm_create.md │ │ │ ├── helm_delete.md │ │ │ ├── helm_dependency.md │ │ │ ├── helm_dependency_build.md │ │ │ ├── helm_dependency_list.md │ │ │ ├── helm_dependency_update.md │ │ │ ├── helm_fetch.md │ │ │ ├── helm_get.md │ │ │ ├── helm_get_hooks.md │ │ │ ├── helm_get_manifest.md │ │ │ ├── helm_get_notes.md │ │ │ ├── helm_get_values.md │ │ │ ├── helm_history.md │ │ │ ├── helm_home.md │ │ │ ├── helm_init.md │ │ │ ├── helm_inspect.md │ │ │ ├── helm_inspect_chart.md │ │ │ ├── helm_inspect_readme.md │ │ │ ├── helm_inspect_values.md │ │ │ ├── helm_install.md │ │ │ ├── helm_lint.md │ │ │ ├── helm_list.md │ │ │ ├── helm_package.md │ │ │ ├── helm_plugin.md │ │ │ ├── helm_plugin_install.md │ │ │ ├── helm_plugin_list.md │ │ │ ├── helm_plugin_remove.md │ │ │ ├── helm_plugin_update.md │ │ │ ├── helm_repo.md │ │ │ ├── helm_repo_add.md │ │ │ ├── helm_repo_index.md │ │ │ ├── helm_repo_list.md │ │ │ ├── helm_repo_remove.md │ │ │ ├── helm_repo_update.md │ │ │ ├── helm_reset.md │ │ │ ├── helm_rollback.md │ │ │ ├── helm_search.md │ │ │ ├── helm_serve.md │ │ │ ├── helm_status.md │ │ │ ├── helm_template.md │ │ │ ├── helm_test.md │ │ │ ├── helm_upgrade.md │ │ │ ├── helm_verify.md │ │ │ └── helm_version.md │ │ ├── history.md │ │ ├── index.mdx │ │ ├── related.md │ │ └── using_helm/ │ │ ├── install.md │ │ ├── install_faq.md │ │ ├── kubernetes_apis.md │ │ ├── kubernetes_distros.md │ │ ├── plugins.md │ │ ├── rbac.md │ │ ├── securing_installation.md │ │ ├── tiller_ssl.md │ │ └── using_helm.md │ └── version-3/ │ ├── chart_best_practices/ │ │ ├── conventions.md │ │ ├── custom_resource_definitions.md │ │ ├── dependencies.md │ │ ├── index.mdx │ │ ├── labels.md │ │ ├── pods.md │ │ ├── rbac.md │ │ ├── templates.md │ │ └── values.md │ ├── chart_template_guide/ │ │ ├── accessing_files.md │ │ ├── builtin_objects.md │ │ ├── control_structures.md │ │ ├── data_types.md │ │ ├── debugging.md │ │ ├── function_list.md │ │ ├── functions_and_pipelines.md │ │ ├── getting_started.md │ │ ├── helm_ignore_file.md │ │ ├── index.mdx │ │ ├── named_templates.md │ │ ├── notes_files.md │ │ ├── subcharts_and_globals.md │ │ ├── values_files.md │ │ ├── variables.md │ │ ├── wrapping_up.md │ │ └── yaml_techniques.md │ ├── faq/ │ │ ├── changes_since_helm2.md │ │ ├── index.mdx │ │ ├── installing.md │ │ ├── troubleshooting.md │ │ └── uninstalling.md │ ├── glossary/ │ │ └── index.mdx │ ├── helm/ │ │ ├── _category_.json │ │ ├── helm.md │ │ ├── helm_completion.md │ │ ├── helm_completion_bash.md │ │ ├── helm_completion_fish.md │ │ ├── helm_completion_powershell.md │ │ ├── helm_completion_zsh.md │ │ ├── helm_create.md │ │ ├── helm_dependency.md │ │ ├── helm_dependency_build.md │ │ ├── helm_dependency_list.md │ │ ├── helm_dependency_update.md │ │ ├── helm_env.md │ │ ├── helm_get.md │ │ ├── helm_get_all.md │ │ ├── helm_get_hooks.md │ │ ├── helm_get_manifest.md │ │ ├── helm_get_metadata.md │ │ ├── helm_get_notes.md │ │ ├── helm_get_values.md │ │ ├── helm_history.md │ │ ├── helm_install.md │ │ ├── helm_lint.md │ │ ├── helm_list.md │ │ ├── helm_package.md │ │ ├── helm_plugin.md │ │ ├── helm_plugin_install.md │ │ ├── helm_plugin_list.md │ │ ├── helm_plugin_uninstall.md │ │ ├── helm_plugin_update.md │ │ ├── helm_pull.md │ │ ├── helm_push.md │ │ ├── helm_registry.md │ │ ├── helm_registry_login.md │ │ ├── helm_registry_logout.md │ │ ├── helm_repo.md │ │ ├── helm_repo_add.md │ │ ├── helm_repo_index.md │ │ ├── helm_repo_list.md │ │ ├── helm_repo_remove.md │ │ ├── helm_repo_update.md │ │ ├── helm_rollback.md │ │ ├── helm_search.md │ │ ├── helm_search_hub.md │ │ ├── helm_search_repo.md │ │ ├── helm_show.md │ │ ├── helm_show_all.md │ │ ├── helm_show_chart.md │ │ ├── helm_show_crds.md │ │ ├── helm_show_readme.md │ │ ├── helm_show_values.md │ │ ├── helm_status.md │ │ ├── helm_template.md │ │ ├── helm_test.md │ │ ├── helm_uninstall.md │ │ ├── helm_upgrade.md │ │ ├── helm_verify.md │ │ ├── helm_version.md │ │ └── index.mdx │ ├── howto/ │ │ ├── chart_releaser_action.md │ │ ├── chart_repository_sync_example.md │ │ ├── charts_tips_and_tricks.md │ │ └── index.mdx │ ├── index.mdx │ ├── intro/ │ │ ├── CheatSheet.md │ │ ├── index.mdx │ │ ├── install.md │ │ ├── quickstart.md │ │ └── using_helm.md │ ├── sdk/ │ │ ├── _install.mdx │ │ ├── _list.mdx │ │ ├── _main.mdx │ │ ├── _pull.mdx │ │ ├── _uninstall.mdx │ │ ├── _upgrade.mdx │ │ ├── examples.mdx │ │ ├── gosdk.md │ │ └── index.mdx │ └── topics/ │ ├── advanced.md │ ├── architecture.md │ ├── chart_repository.md │ ├── chart_tests.md │ ├── charts.md │ ├── charts_hooks.md │ ├── index.mdx │ ├── kubernetes_apis.md │ ├── kubernetes_distros.md │ ├── library_charts.md │ ├── permissions_sql_storage_backend.md │ ├── plugins.md │ ├── provenance.md │ ├── rbac.md │ ├── registries.md │ ├── v2_v3_migration.md │ └── version_skew.md ├── versioned_sidebars/ │ ├── version-2-sidebars.json │ └── version-3-sidebars.json └── versions.json ================================================ FILE CONTENTS ================================================ ================================================ FILE: .containerignore ================================================ # Ignore node_modules directory node_modules # Ignore any log files *.log # Ignore Containerfile and .containerignore itself Containerfile .containerignore # Ignore git repository files .git .gitignore # Ignore temporary files tmp *.tmp # Ignore build output dist build resources app ================================================ FILE: .editorconfig ================================================ root = true [*] end_of_line = lf insert_final_newline = true [Makefile] indent_style = tab [*.{html,js,json,md,sass,scss,yaml}] indent_style = space indent_size = 2 ================================================ FILE: .github/workflows/build.yml ================================================ name: build on: push: paths: - sdkexamples/** branches: - main pull_request: paths: - sdkexamples/** branches: - main permissions: contents: read jobs: build: runs-on: ubuntu-latest strategy: fail-fast: true steps: - name: Checkout uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pin@v4.2.2 - name: Setup Go sdkexamples/go.mod file uses: actions/setup-go@41dfa10bad2bb2ae585af6ee5bb4d7d973ad74ed # pin@5.1.0 with: go-version-file: 'sdkexamples/go.mod' check-latest: true - name: Build sdkexamples run: make sdkexamples ================================================ FILE: .github/workflows/stale.yml ================================================ name: "Close stale issues and prs" on: schedule: - cron: "0 0 * * *" jobs: stale: runs-on: ubuntu-latest steps: - uses: actions/stale@5f858e3efba33a5ca4407a664cc011ad407f2008 # v10.1.0 with: repo-token: ${{ secrets.GITHUB_TOKEN }} stale-issue-message: 'This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.' stale-pr-message: 'This pull request has been marked as stale because it has been open for 90 days with no activity. This pull request will be automatically closed in 30 days if no further activity occurs.' exempt-issue-labels: 'keep open,v4.x,in progress' days-before-stale: 90 days-before-close: 30 operations-per-run: 200 ================================================ FILE: .github/workflows/typos.yml ================================================ name: typos on: push: branches: - main pull_request: branches: - main permissions: contents: read jobs: typos: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # pin@v4.2.2 - name: Check for typos uses: crate-ci/typos@v1.38.1 ================================================ FILE: .github/workflows/update-community-docs.yml ================================================ name: Update Community Documentation on: schedule: # Run weekly on Mondays at 3 AM UTC # Adjust frequency as needed - could be nightly: '0 3 * * *' - cron: '0 3 * * 1' workflow_dispatch: # Allows manual triggering permissions: contents: write pull-requests: write jobs: update-community-docs: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version-file: '.nvmrc' cache: 'yarn' - name: Install dependencies run: yarn install --frozen-lockfile - name: Update community docs run: yarn download-remote-community - name: Create or Update Pull Request uses: peter-evans/create-pull-request@v7 with: token: ${{ secrets.GITHUB_TOKEN }} commit-message: 'chore(community): update docs from upstream' signoff: true title: 'chore(community): update docs from helm/community' body: | ## 🔄 Automated Community Documentation Update Updates community documentation from [helm/community](https://github.com/helm/community) repository. ### What this does: - Downloads latest docs from helm/community - Applies transformations (frontmatter, links, etc.) - Creates PR if there are changes ### Review checklist: - [ ] Verify docs render correctly with `yarn start` - [ ] Check that no local files were overwritten --- *This is an automated PR. See `.github/workflows/update-community-docs.yml` for details.* branch: upstream-community-changes delete-branch: true labels: | docs community ================================================ FILE: .gitignore ================================================ # Dependencies /node_modules # Production /build # Generated files .docusaurus .cache-loader # Misc .DS_Store .env.local .env.development.local .env.test.local .env.production.local npm-debug.log* yarn-debug.log* yarn-error.log* # SDKExamples build output sdkexamples/sdkexamples # JetBrains IDEs (GoLand, IntelliJ, ...) config folder .idea # Obsidian IDE config folder .obsidian # Link checker artifacts bin/ tmp/ # Migration source files orig/ .claude CLAUDE.md ================================================ FILE: .markdownlint.json ================================================ { "default": true, "MD013": { "code_block_line_length": 999, "tables": false }, "MD014": false, "MD025": false, "MD026": false, "MD033": false } ================================================ FILE: .netlify/state.json ================================================ { "siteId": "bbe72dce-fa74-4199-abb2-6bdfe2b4d08c" } ================================================ FILE: .nvmrc ================================================ 22 ================================================ FILE: .typos.toml ================================================ [default] extend-ignore-re = [ # Hex color codes in SCSS/CSS "F[0-9A-F]{2,4}", ] [default.extend-words] # Company/Publisher names Packt = "Packt" SkippBox = "SkippBox" Skipp = "Skipp" KOMMA = "KOMMA" Hashi = "Hashi" # HashiCorp # Icon/variable names stange = "stange" mutliple = "mutliple" # May be intentional in legacy code multiplebgs = "multiplebgs" psuedo = "psuedo" # Legacy typo in vendor code # Technical terms AKS = "AKS" # Azure Kubernetes Service ba = "ba" ede = "ede" # Git commit hash # German words in translations Paket = "Paket" # German for "package" [files] extend-exclude = [ # Internationalization files (Docusaurus i18n directory) "i18n/", # Go dependencies "sdkexamples/go.mod", "sdkexamples/go.sum", # v4 changelog (don't want to change commit messages) "docs/changelog.md", # v2 docs "versioned_docs/version-2/*", # Ignore typos on files imported from remote repos (fix upstream instead) # See docusaurus.config.js customFields.communityDocs.remoteDocs[] for full list "community/art/", "community/hips/", "community/meeting-notes/", ] ================================================ FILE: .vscode/launch.json ================================================ { // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "type": "chrome", "request": "launch", "name": "Launch Chrome against localhost", "url": "http://localhost:8080", "webRoot": "${workspaceFolder}" } ] } ================================================ FILE: AGENTS.md ================================================ # AGENTS.md This file provides guidance to AI coding agents working with the helm.sh website repository. ## Overview This is the official Helm project website (helm.sh) - a Docusaurus static site serving Helm documentation, blog, and community resources. The site supports multiple languages and versions, and is automatically deployed to Netlify. ### Technology Stack - Docusaurus (static site generator) - React (component framework) - Node.js/Yarn (package management) - Netlify (hosting and deployment) ## Quick Start ```bash # Install dependencies yarn install # Start development server yarn start # Build for production yarn build # Serve production build locally yarn serve ``` ## Repository Structure ### Content Organization - `docs/` - Current version documentation (unversioned) - `versioned_docs/version-N/` - Versioned documentation snapshots - `blog/` - Blog posts and announcements - `i18n/{lang}/` - Internationalized content for supported languages - `src/` - React components and custom pages - `static/` - Static assets (images, files) ### Configuration - `docusaurus.config.js` - Main Docusaurus configuration - `sidebars.js` - Documentation sidebar structure - `versions.json` - Available documentation versions - `netlify.toml` - Netlify deployment configuration ### Languages Supported: English (en), German (de), Spanish (es), French (fr), Japanese (ja), Korean (ko), Portuguese (pt), Russian (ru), Ukrainian (uk), Chinese (zh) ## Build and Test Commands ### Development ```bash # Start dev server (usually port 3000) yarn start # Start with specific locale yarn start --locale ko # Clear cache if needed yarn clear ``` ### Production Build ```bash # Build all locales yarn build # Build specific locale yarn build --locale en # Build without minification (faster for testing) yarn build --no-minify ``` ### Quality Checks ```bash # Type checking (if TypeScript is added) yarn typecheck # Link checking make check-links-ci # Spell checking typos ``` ## Architectural Documentation This codebase includes an `ARCHITECTURAL_DECISIONS.md` document that explains key architectural decisions made during the Docusaurus implementation. When implementing new features or making significant changes: 1. **Document architectural decisions** in `ARCHITECTURAL_DECISIONS.md` with clear reasoning 2. **Include requirements** that drove the decision 3. **Link to relevant Docusaurus documentation** when applicable 4. **Keep explanations concise** but comprehensive enough for future contributors This helps maintain consistency and guides future development decisions. ### Writing Guidelines for ARCHITECTURAL_DECISIONS.md When updating architectural decisions: - **Describe current state** - Document what exists now, not proposals or ideas - **Keep it concise** - One paragraph per topic, link to external docs instead of repeating them - **Focus on the "why"** - Explain decisions that aren't obvious from the code - **Help contributors** - Write for developers who need to understand the codebase quickly - **Avoid duplication** - Link to Docusaurus docs rather than explaining Docusaurus features Example: Don't explain what CSS modules are, but DO explain why we chose them over other styling approaches for this specific project. ## Content Management ### Documentation #### Adding/Editing Docs 1. Edit files in `docs/` for current version 2. For versioned docs, edit in `versioned_docs/version-N/` 3. Frontmatter format: ```yaml --- title: "Page Title" sidebar_label: "Short Label" sidebar_position: 1 --- ``` #### Creating New Versions ```bash # Create new version snapshot yarn docusaurus docs:version 3.18.0 ``` This creates: - `versioned_docs/version-3.18.0/` - Snapshot of current docs - `versioned_sidebars/version-3.18.0-sidebars.json` - Sidebar config - Updates `versions.json` #### CLI Reference Documentation Located in `docs/helm/` (and versioned equivalents). To update: 1. Uninstall all helm plugins: `helm plugin uninstall` 2. Navigate to appropriate docs directory 3. Run: `HOME='~' helm docs --type markdown --generate-headers` 4. Commit changes ### Blog Posts Create in `blog/` directory with naming: `YYYY-MM-DD-slug/index.md` Frontmatter format: ```yaml --- title: "Post Title" authors: - name: Author Name url: https://author.link tags: [tag1, tag2] --- Post summary appears here. Full post content here. ``` Images go in the same directory as the blog post or in `blog/assets/`. ### Internationalization #### Adding Translations 1. Extract strings: `yarn write-translations --locale ko` 2. Translate files in `i18n/{locale}/` 3. Content structure: - `i18n/{locale}/docusaurus-plugin-content-docs/` - Docs translations - `i18n/{locale}/docusaurus-plugin-content-blog/` - Blog translations - `i18n/{locale}/code.json` - UI strings #### Translation Guidelines - Maintain consistent terminology across versions - Test with `yarn start --locale {locale}` - Ensure all navigation and UI elements are translated ## Code Style and Conventions ### Markdown - Use semantic line breaks (one sentence per line preferred for diffs) - Code blocks should specify language: ```yaml, ```bash, ```go - Use relative links for internal pages: `[text](../path/to/page.md)` - Images: `![alt text](./image.png)` or from static: `![alt text](/img/image.png)` ### Frontmatter Standards - Required: `title` - Recommended: `sidebar_label`, `sidebar_position`, `description` - Blog posts: Use `authors` array, not `author` string ### Component Usage - Use Docusaurus components when available: ``, ``, `` - Custom components in `src/components/` - Import at top of MDX files: `import ComponentName from '@site/src/components/ComponentName'` ### File Naming - Docs: Use descriptive names, lowercase with hyphens: `getting-started.md` - Blog: Date prefix required: `YYYY-MM-DD-title/index.md` - Assets: Descriptive names, avoid spaces ## Deployment ### Netlify Configuration - **Build command**: `yarn install && make build` - **Publish directory**: `build` - **Node version**: Specified in `netlify.toml` - **Auto-deploys**: From `main` branch - **Preview deploys**: Automatic for PRs ### Build Process 1. Netlify clones repository 2. Installs dependencies with yarn 3. Runs `make build` which executes `yarn build` 4. Deploys `build/` directory contents 5. Runs post-build plugins (link checking, etc.) ### Environment Considerations - Build timeout: 15 minutes - Memory: Standard Netlify build environment - Cache: `node_modules/` and `.docusaurus/` cached between builds ## Contributing Guidelines ### Requirements - **Signed commits**: All commits must include DCO sign-off (`git commit -s`) - **PR approval**: Requires maintainer review - **Testing**: Build locally before submitting PR ### Workflow 1. Fork repository and create feature branch from `main` 2. Make changes following existing patterns 3. Test locally: `yarn build && yarn serve` 4. Commit with sign-off: `git commit -s -m "description"` 5. Submit PR with clear description 6. Address review feedback ### Commit Messages - Use conventional commits format when possible - Be descriptive but concise - Reference issues: `fixes #123` or `relates to #456` - Sign all commits with `-s` flag ### Content Approval Process - **Documentation**: Any maintainer can approve - **Blog posts**: Require core maintainer approval - **Configuration changes**: Require thorough review and testing ## Common Tasks ### Updating Helm Version References 1. Update `docusaurus.config.js` - Search for version strings 2. Update relevant documentation pages 3. Consider creating new version snapshot if major release 4. Update `versions.json` if needed ### Adding New Documentation Section 1. Create directory in `docs/` 2. Add index page: `docs/new-section/index.md` 3. Update `sidebars.js` to include new section 4. Add translations to `i18n/{locale}/` directories ### Fixing Broken Links 1. Run link checker: `make check-links-ci` 2. Review output for broken links 3. Fix links in source files 4. Verify in both current and versioned docs if applicable ### Migration from Hugo If encountering Hugo-specific syntax or structure: - Hugo shortcodes -> Docusaurus components or MDX - Hugo frontmatter -> Docusaurus frontmatter (mostly compatible) - Hugo content organization -> Docusaurus docs structure - See `HELM2-TO-DOCUSAURUS.md` and `HELM3-TO-DOCUSAURUS.md` for migration details ## Security Considerations ### Content Security - Never commit secrets or credentials - Be cautious with external links and embeds - Validate all user-contributed content - Use HTTPS for all external resources ### Build Security - Dependencies audited via Dependabot - Use exact versions in `package.json` where security-critical - Review dependency updates before merging ### Deployment Security - Netlify handles HTTPS/SSL certificates - No server-side code execution (static site) - Environment variables kept in Netlify dashboard, not in repo ## Troubleshooting ### Common Issues **Build fails with "Cannot find module"** - Solution: `rm -rf node_modules .docusaurus && yarn install` **Changes not reflecting in dev server** - Solution: `yarn clear && yarn start` **Version mismatch errors** - Solution: Ensure Node.js version matches `.nvmrc` or `netlify.toml` **Broken links after content move** - Solution: Search for old path, update all references, run link checker **Translation missing strings** - Solution: `yarn write-translations --locale {locale}` to regenerate ### Getting Help - GitHub Issues: https://github.com/helm/helm-www - Kubernetes Slack: #helm-users and #helm-dev channels - Documentation: https://docusaurus.io/docs ## Special Notes for AI Agents ### When Making Changes 1. Always build and test locally before considering work complete 2. Check both English and at least one translated version if touching i18n 3. Verify changes in both current docs and latest versioned docs if applicable 4. Run link checker before finalizing PR 5. Ensure all commits are properly formatted and signed ### File Generation - CLI reference docs are auto-generated - note this in commits - Don't manually edit generated files without noting the generation source - If regenerating docs, ensure clean helm environment (no plugins) ### Be Aware Of - This is a versioned documentation site - changes may need to apply to multiple versions - Blog posts are part of permanent site history - be extra careful with edits - Some content may be in multiple languages - coordinate changes across translations when needed - External links should be checked periodically as they can break over time ================================================ FILE: ARCHITECTURAL_DECISIONS.md ================================================ # Architectural Decisions - Helm Website This document explains Helm-specific architectural decisions that help maintain the site and guide contributors. For general Docusaurus concepts, see the [official documentation](https://docusaurus.io/docs). ## Homepage Hero Height Management ### Helm-Specific Requirement The Helm homepage hero needs to fill the full viewport height minus the navbar for a clean presentation. ### Solution Uses a [Docusaurus client module](https://docusaurus.io/docs/advanced/client#client-modules): `src/client-modules/heroHeightCalculator.js` **Handles:** Window resize, orientation change, client-side navigation (SPA routing), and development hot reloading **Why client modules instead of static scripts:** Integrates with Docusaurus build process and avoids file serving issues in different deployment environments. ## Homepage Component Organization ### Helm-Specific Requirement Split the homepage into focused components so contributors can easily find and edit specific sections. ### Component Structure ``` src/components/ ├── HomeHeader/ # Hero section ├── HomeAbout/ # "What is Helm?" section ├── HomeFeatures/ # Feature cards ├── HomeGettingStarted/ # Installation tabs └── HomeCommunity/ # Community links ``` **Shared CSS modules:** `src/css/home-*.module.css` for common patterns across components. **Date internationalization:** Uses [Intl.DateTimeFormat](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) for locale-aware date formatting instead of hardcoded strings, automatically adapting to user's language settings. ## Hero Responsive Design ### Helm-Specific Requirement Hero content must never be hidden behind navbar or waves, especially on mobile landscape or small windows. ### Key Solutions **Extreme height constraint (< 380px):** Switches to side-by-side layout instead of stacked **Text scaling:** Uses CSS `clamp()` for smooth scaling while maintaining readability **Container bounds:** Absolute positioning keeps content above wave animations ## CLI Documentation Generation Script ### Helm-Specific Requirement Regenerate Helm CLI documentation for each release with consistent formatting and Docusaurus-compatible structure. ### Solution Uses an ESM Node.js script: `scripts/regenerate-cli-docs.mjs` **Why ESM over CommonJS:** Modern package compatibility (ora, p-limit) and consistency with future Node.js direction while maintaining parallel processing capabilities for performance. **Post-processing steps:** Automatically handles Docusaurus requirements like converting links to absolute paths, cleaning frontmatter, and creating proper index files - tasks that would be error-prone if done manually for each release. See `src/components/HomeHeader/styles.module.css` for implementation details. ## React Hydration Warning Suppression ### Helm-Specific Requirement The HomeCommunity component displays event dates using locale-specific formatting, which causes unavoidable hydration mismatches between server and client rendering. ### Solution Following [React's official guidance for suppressing unavoidable hydration mismatches](https://react.dev/reference/react-dom/client/hydrateRoot#suppressing-unavoidable-hydration-mismatch-errors), we use `suppressHydrationWarning` on date-displaying `` elements in `src/components/HomeCommunity/index.js`. **Why this happens:** The server renders dates using one locale during static generation, but the client may have a different locale, causing React error #418 (text content mismatch). Since dates are intentionally locale-aware for internationalization, this mismatch is expected and acceptable. **Implementation:** Added `suppressHydrationWarning` prop to both date range and single date `` elements in the CustomDate component. ## Boat and Wave Animation ### Helm-Specific Requirement Boat must appear to float on waves across all screen sizes while using minimal space in the hero section. ### Key Solutions **Scaling:** Uses `max(rem, vw)` for viewport-proportional scaling with minimum readable sizes **Space efficiency:** Boat can overflow above a compact wave container to maximize hero content space **Animation sync:** Boat bob animation coordinates with wave heights for consistent floating appearance See `src/components/Boat/styles.module.css` for implementation. ## CSS Organization ### Helm-Specific Requirement Homepage styles should only load on homepage, not other pages. ### Solution Uses [CSS Modules](https://docusaurus.io/docs/styling-layout#css-modules) with strategic sharing: - `src/css/home-*.module.css` - Shared patterns (sections, cards) - Component `styles.module.css` - Component-specific styles **Why this approach:** Only homepage components import homepage CSS, so other pages don't load unnecessary styles. ## Blog and Docs Layout Consistency ### Why This Change Was Made Blog and docs pages now use identical layout and navigation. This was done by [swizzling Docusaurus theme components](https://docusaurus.io/docs/swizzling) rather than custom CSS. ### Key Files for Maintainers **Core Components (don't delete):** ``` src/theme/BlogLayout/ # Makes blog look like docs src/theme/BlogBreadcrumbs/ # "Home → Blog → Post" navigation src/theme/BlogListBreadcrumbs/ # "Home → Blog" navigation src/theme/DocBreadcrumbs/ # "Home → Docs → Page" navigation src/theme/TOCCollapsible/ # Mobile "On this page" menu ``` ### Expected Navigation Patterns - **Blog listing:** Home → Blog - **Blog post:** Home → Blog → Post Title - **Docs page:** Home → Docs → Category → Page ### Common Issues **Blog breadcrumbs broken?** Check `src/theme/BlogBreadcrumbs/index.js` **Mobile TOC not working?** Verify `src/theme/TOCCollapsible/` and that blog posts use proper headers (##, ###) **Missing "Docs" in breadcrumbs?** Check `src/theme/DocBreadcrumbs/index.js` has the "Docs" link **Layout looks wrong?** Don't add custom CSS - edit the React components instead See [Docusaurus swizzling docs](https://docusaurus.io/docs/swizzling) for how these theme components work. ## Markdown Links This section provides guidance for working with markdown links in the Helm docs site. ### Absolute paths required Absolute paths are required for all links. Absolute paths are more verbose but necessary to avoid broken links in our multi-locale site due to the following Docusaurus i18n bug: [facebook/docusaurus#10907](https://github.com/facebook/docusaurus/issues/10907). The sections below include more information about how and when to use absolute file paths or URL paths. #### Linking within docs or blogs When linking from one doc page to another or from one blog post to another, use the _absolute file path_: * Exclude `/blog/` or `/docs/` from the path * Start the path from the directory within `/blogs` (eg `/2024-10-07-kubecon-na-24/`), or from the version-specific docs folder (eg, `/topics/`, `/chart_template_guide/`, `/helm/`) * Include the `.md` or `.mdx` file extension Examples: ```markdown ✅ GOOD (doc to doc link): [Advanced Topics](/topics/advanced.md) ✅ GOOD (blog to blog link): [Helm at KubeCon/CloudNativeCon SLC](/2024-10-07-kubecon-na-24/index.md) ❌ AVOID (relative file path): [Advanced Topics](../topics/advanced.md) ❌ AVOID (relative file path): [Advanced Topics](advanced.md) ❌ AVOID (adding /docs): [Advanced Topics](/docs/topics/advanced.md) ❌ AVOID (absolute URL path, no .md/.mdx): [Advanced Topics](/docs/topics/advanced) ``` #### Linking across docs and blogs When linking to a doc from a blog, or from a blog to a doc, use the _absolute URL path_: * Include `/blog/` or `/docs/` * Exclude the `.md` or `.mdx` file extension * If the doc or blog has a `slug` defined in its front matter, use the slug in the URL path instead of the filename Examples: ```markdown ✅ GOOD (file name without .md extension when no slug is in front matter): [See this blog post](/blog/2024-01-01-title) ✅ GOOD (when slug is in front matter): [See this blog post](/blog/my-slug) ❌ AVOID (don't use the file extension): [Advanced Topics](/docs/topics/advanced.md) ``` ### Anchor links to headings Anchor links are challenging in multi-locale sites because anchor IDs are automatically generated from the heading text. This means that any links that point to English language anchor IDs will break in other locales if the given heading is translated to a different language. For example: ```markdown English: ## Storage backends → #storage-backends Chinese: ## 后端存储 → #后端存储 (different anchor ID) ``` To avoid broken anchor links, add explicit IDs to headings in all translations. For example: ```markdown ## Storage backends {#storage-backends} ## 后端存储 {#storage-backends} ``` In this case, anchor links to the given ID will work across all locales since the anchor ID itself remains the same in all translations. ### Troubleshoot broken links You can run a local build to check for broken links (`yarn build`). If there are broken links, you'll see an error like this in the build output: ```bash Broken link on source page path = /docs/faq/changes_since_helm2 -> linking to /topics/charts.md ``` To troubleshoot, go to the _source page_ listed in the error message. Note that the source page with the broken link might be in the English docs, even if the broken link was triggered for a different locale. ## Netlify Redirects Strategy ### Hugo to Docusaurus Migration Requirements During the migration from Hugo to Docusaurus, several legacy URL patterns needed to be preserved to avoid breaking existing links and integrations. ### Redirect Processing Order [Netlify processes redirects from top to bottom](https://docs.netlify.com/routing/redirects/redirect-options/), with the **first matching rule taking precedence**. This means **more specific patterns must come before general ones**. ### Go Module Import Support Hugo served Go module import pages at `/helm/`, `/helm/v2/`, `/helm/v3/`, `/helm/v4/`, `/chartmuseum/` using a `content/en/code/` directory with metadata files processed by `themes/helm/layouts/code/single.html`. ### Docusaurus Implementation Docusaurus replicates this functionality using static HTML files in `/static/`: - `/static/helm/index.html` - `/static/helm/v2/index.html` - `/static/helm/v3/index.html` - `/static/helm/v4/index.html` - `/static/chartmuseum/index.html` Each file provides: 1. **Go import meta tags**: `` for Go module proxy 2. **Go source meta tags**: `` for source code navigation 3. **Client-side redirect**: `` for browser users 4. **Fallback link**: HTML body with link to GitHub repository ### Go Package Import Compatibility Internal redirects handle Go module proxy requests: ```toml [[redirects]] from = "/helm/v3/*" to = "/helm/v3" status = 200 [[redirects]] from = "/helm/v2/*" to = "/helm/v2" status = 200 ``` ### Helm v2 Documentation Redirects Legacy Helm v2 documentation from `https://v2.helm.sh/docs/*` redirects to the new combined site at `/docs/2/*`. These redirects: 1. **URL format changes**: Map old underscore URLs to new dash URLs (e.g., `using_helm/` → `using-helm/`) 2. **Category-level only**: Target section landing pages (fragments not supported by Netlify) 3. **Temporary status**: Use 302 status during migration phase for easy rollback if issues discovered 4. **Script-managed**: Generated by `scripts/helm2-to-docusaurus.js` for consistency ```toml # TODO: Change status codes from 302 to 301 after cutover verification [[redirects]] from = "https://v2.helm.sh/docs/using_helm/" to = "/docs/2/using-helm/" status = 302 ``` ### Status Code Strategy - **302 (temporary)** during testing/migration phase - allows easy rollback if issues are discovered - **301 (permanent)** after Docusaurus site cutover is verified - provides SEO benefits and signals permanent move This follows [Netlify's best practices](https://docs.netlify.com/routing/redirects/redirect-options/#http-status-codes) for safe migrations. ## Documentation Migration Automation ### Helm-Specific Requirement Migrating legacy Helm documentation (v2 from Hugo, v3 from existing content) to Docusaurus while preserving URLs and fixing broken links. ### Solution **Migration Orchestrators:** `scripts/migrate-v2-docs.js` and `scripts/migrate-v3-docs.js` with corresponding `yarn migrate:v2` and `yarn migrate:v3` commands. **Modular Architecture:** Scripts organized in `scripts/util/`, `scripts/v2/`, `scripts/v3/` directories following UNIX philosophy - each script has a single purpose and can be composed together. **Key Features:** - **Fresh start capability:** Each migration clears and rebuilds from source - **Menu generation:** Extracts navigation structure from live Helm v2 site - **Link path correction:** Shared `scripts/util/href-diffs-process.js` applies version-specific link fixes from JSON configuration files - **Missing file handling:** Adds helm commands not present in original navigation but available in source **Why this approach:** Enables repeatable, testable migrations while maintaining URL compatibility and fixing legacy Hugo-to-Docusaurus link issues. **For contributors:** Run `yarn migrate:v2` or `yarn migrate:v3` to regenerate versioned documentation. Link fixes are managed via JSON files in each version directory. **Detailed operational guides:** - [HELM2-TO-DOCUSAURUS.md](./HELM2-TO-DOCUSAURUS.md) - v2 migration procedures - [HELM3-TO-DOCUSAURUS.md](./HELM3-TO-DOCUSAURUS.md) - v3 migration procedures ## Hugo Legacy Files Cleanup ### Files to Remove Post-Migration Once the Docusaurus migration is complete and verified, these Hugo-specific files should be removed: - **`config.toml`** - Hugo configuration file, replaced by `docusaurus.config.js` - **`themes/` directory** - Hugo theme files, replaced by Docusaurus theme components - **`content/en/code/` directory** - Hugo code metadata files, functionality replaced by Netlify redirects ### Migration Strategy Keep these files during the migration phase to: 1. Reference Hugo configuration when setting up Docusaurus equivalents 2. Understand legacy URL patterns for redirect configuration 3. Maintain ability to rollback if needed during testing Remove them only after: 1. Docusaurus site cutover is verified 2. All redirects are tested and working 3. No rollback scenarios require Hugo functionality ## Community Documentation Import ### Helm-Specific Requirement The Helm project maintains community governance documents in a [separate repository](https://github.com/helm/community) that need to be included in the website as an unversioned documentation section with proper Docusaurus integration. ### Solution Uses [docusaurus-plugin-remote-content](https://github.com/rdilweb/docusaurus-plugin-remote-content) to import and transform content at build time. **Architecture:** - **Multi-instance docs:** Community docs are a separate Docusaurus docs plugin instance with `id: "community"`, creating `/community/*` URLs - **Content transformation:** Custom functions in `src/utils/communityDocsTransforms.js` handle all content processing - **Configuration:** Centralized in `docusaurus.config.js` under `customFields.communityDocs` - **Files committed to Git:** Imported files are tracked in version control to maintain clean git status and avoid complex .gitignore management - **Build settings:** Uses `performCleanup: false` to prevent file deletion during i18n builds (workaround for [plugin issue #98](https://github.com/rdilweb/docusaurus-plugin-remote-content/issues/98)) ### Content Transformation Features **Import notice headers:** Every imported file gets a warning header indicating it shouldn't be edited directly, with a link to the source file in the helm/community repository. **HIP (Helm Improvement Proposal) formatting:** HIP documents get special treatment: - Metadata fields (hip, authors, created, status, etc.) displayed as a markdown table - Sidebar labels include HIP number for easy navigation (e.g., "0023: Utilize Server Side Apply") - Frontmatter cleaned to remove duplicate metadata **Plain text file handling:** `.txt` files (like meeting notes) are automatically: - Converted to `.md` files during import - Title extracted from content headers - Content wrapped in code blocks to preserve formatting **Link transformations:** Only applied for configured exceptions - most links work as-is since the file structure mirrors the source repository. ### Why imported files are committed to Git The `/community` directory mixes imported files from helm/community with locally-maintained community docs. Committing imported files to Git: 1. **Avoids complex .gitignore patterns** - No need to maintain a parallel list of which specific files to ignore 2. **Provides clean git status** - Contributors don't see dozens of untracked files during development 3. **Enables offline development** - With `noRuntimeDownloads: true`, `yarn start` works without network access 4. **Simplifies mental model** - All files in `/community` are tracked, regardless of source The tradeoff of content duplication is acceptable since these files rarely change structure and the import notices clearly indicate they shouldn't be edited locally. ### Commands - `yarn download-remote-community` - Fetch and transform latest content from helm/community repository - `yarn clear-remote-community` - Remove imported files (useful for testing) ### Automated Updates A GitHub Action (`.github/workflows/update-community-docs.yml`) runs weekly to: 1. Check for updates in helm/community repository 2. Apply transformations and import changes 3. Create or update a PR if there are changes 4. Skip if an identical PR already exists The workflow can also be triggered manually through GitHub Actions UI. ### For Contributors To add new community documents: 1. Add entry to `customFields.communityDocs.remoteDocs` in `docusaurus.config.js` 2. Include optional `meta` field for frontmatter overrides 3. Add link exceptions only if specific links need custom mapping 4. Run `yarn download-remote-community` to test import locally To modify transformation logic: 1. Edit `src/utils/communityDocsTransforms.js` for content processing 2. Test changes with `yarn download-remote-community` ## Netlify Build Caching ### Problem Docusaurus builds take ~11 minutes. Need faster builds for development workflow. ### Solution Custom Netlify plugins cache `.docusaurus/`, `node_modules/`, and `build/` directories. **Current:** `cache-docusaurus-dirs-file` (stable, 2-4 minute builds) **Future:** `cache-docusaurus-dirs-api` (beta, potentially 10x faster) ### Build Pipeline Changes Changed from `make build` (runs destructive `clean`) to `make netlify-build` (preserves cache). ### Cache Strategy - **Production/branches:** Isolated per branch - **PR previews:** Shared across PRs via `CACHE_PER_BRANCH=false` - **Auto-invalidation:** `yarn.lock` changes, `CACHE_VERSION` environment variable See `netlify-plugins/README.md` for configuration details. ================================================ FILE: CONTRIBUTING-ko.md ================================================ # 기여 가이드라인 helm.sh 웹사이트 및 문서에 대한 기여 가이드입니다. 헬름의 기본 프로젝트는 [helm/helm](https://github.com/helm/helm/blob/main/CONTRIBUTING.md)으로 이동하세요. --- 헬름은 GitHub 풀 리퀘스트를 통해 기여를 받습니다. 이 문서는 기여하는 데 도움이 되는 프로세스를 간략히 설명합니다. ## 보안 이슈 신고 대부분의 경우 헬름에서 버그를 발견하면 [GitHub 이슈](https://github.com/helm/helm/issues)를 사용하여 신고해야 합니다. 그러나 _보안 취약성_ 을 신고하는 경우 [cncf-kubernetes-helm-security@lists.cncf.io](mailto:cncf-kubernetes-helm-security@lists.cncf.io) 이메일로 신고해주세요. 이것은 이슈가 악용되기 전에 해결할 수 있는 기회를 줄 것입니다. ## 당신의 작업에 서명해주세요 서명(sign-off)은 커밋 메시지 끝에 있는 간단한 줄입니다. 모든 커밋은 서명이 있어야 합니다. 귀하의 서명은 패치를 작성했거나 자료를 기여할 권한이 있음을 증명합니다. 아래 개발자 증명서([developercertificate.org](https://developercertificate.org/)에서 발췌)에 동의하는 경우, 규칙은 매우 간단합니다. ``` 원본 개발자 증명서 버전 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 모든 사용자는 이 라이센스 문서의 사본을 복사하여 배포할 수 있지만 변경할 수는 없습니다. 원본 개발자 증명서 1.1 본 프로젝트에 기여함으로써 저는 다음 사항을 보증합니다: (a) 해당 기여의 전부 또는 일부를 제가 작성했으며, 파일에 명시된 오픈 소스 라이센스에 따라 제출할 권리가 있습니다. 또는 (b) 해당 기여는 제가 아는 한 적합한 오픈 소스 라이센스에 따라 적용되었으며, 해당 라이센스에 따라 (다른 라이센스로 제출할 수 있는 권한이 없는 경우) 파일에 표시된 것과 동일한 오픈 소스 라이센스로 제가 작성한 전부 또는 일부의 수정 작업을 제출할 권리가 있습니다. 또는 (c) 해당 기여는 (a), (b) 또는 (c)를 인증한 다른 사람이 직접 제공했으며, 제가 수정하지 않았습니다. (d) 저는 해당 프로젝트와 기여를 공개하고 기여 기록(본인의 서명과 함께 제출한 모든 개인 정보 포함)이 무기한 유지되며 해당 프로젝트 또는 관련 오픈 소스 라이센스와 일치하도록 재배포될 수 있음을 이해하고 동의합니다. ``` 모든 git 커밋 메시지에 한 줄을 추가하기만 하면 됩니다. Signed-off-by: Joe Smith 실명을 사용해주세요. (죄송하지만, 가명 또는 익명의 기여는 허용되지 않습니다.) `user.name` 과 `user.email` git config를 설정하면 `git commit -s` 로 자동으로 커밋에 서명할 수 있습니다. 참고: git 설정 정보가 올바르게 지정된 경우 `git log` 를 보면 커밋 정보가 다음과 같습니다. ``` Author: Joe Smith Date: Thu Feb 2 11:41:15 2018 -0800 Update README Signed-off-by: Joe Smith ``` `Author` 와 `Signed-off-by` 줄이 일치하는 것에 주목해주세요. 만약 일치하지 않는다면 자동 DCO 검사에서 PR을 거부할 것입니다. ## 지원 채널 당신이 사용자 혹은 기여자라면 공식 지원 채널은 다음과 같습니다. - [이슈](https://github.com/helm/helm/issues) - 슬랙: - 사용자: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/) - 기여자: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/) 새로운 이슈를 열거나 새로운 풀 리퀘스트를 보내기 전에 해당 프로젝트를 검색하는 것이 도움이 됩니다. 사용자가 겪은 이슈를 다른 사용자가 이미 보고했거나 저희가 이미 알고 있는 이슈일 수 있습니다. 슬랙 채널에서 물어보는 것도 도움이 될 수 있습니다. ## 이슈 이슈는 헬름 프로젝트와 관련된 모든 항목을 추적하는 기본 방법으로 사용됩니다. ### 이슈 유형 5가지 유형의 이슈가 있습니다(각 이슈마다 해당 [레이블](#labels)이 있음). - `question/support`: 향후 참조를 위해 기록하기를 원하는 지원 또는 기능 관련 문의가 있습니다. 일반적으로 슬랙 채널에 저장하기에 너무 복잡한 또는 큰 질문이거나 커뮤니티 전체에서 특별한 관심을 갖는 질문입니다. 논의에 따라 `feature` 또는 `bug` 이슈로 바뀔 수 있습니다. - `proposal`: 대규모 커뮤니티 논의가 필요한 새로운 아이디어 또는 기능을 제안하는 (이 글과 같은) 이슈에 사용됩니다. 이렇게 하면 기능이 실제로 개발되기 전에 커뮤니티의 다른 사용자로부터 피드백을 받을 수 있습니다. 해당 레이블은 작은 이슈에 필요하진 않습니다. 기능의 제안 필요 여부 결정은 핵심 관리자에게 달려 있습니다. 모든 제안 이슈는 해당 레이블과 "Proposal: [제목의 나머지 부분]" 이라는 제목이 있어야 합니다. 제안은 `feature` 가 될 수 있으며 마일스톤은 필요하지 않습니다. - `feature`: 이 이슈는 완료될 때까지 특정 기능 요청 및 아이디어를 추적합니다. `proposal` 에서 바뀔 수도 있고 이슈 사이즈에 따라 개별적으로 제출될 수 있습니다. - `bug`: 코드와 함께 버그를 추적하는 이슈입니다. - `docs`: 문서 관련 문제(예: 누락 또는 미완)를 추적합니다. ### 이슈 생명 주기 이슈 생명 주기는 주로 핵심 관리자에 의해 관리되지만, 헬름에 기여하는 사람들에게도 좋은 정보입니다. 모든 유형의 이슈는 동일한 생명 주기를 따릅니다. 차이점은 아래에 설명되어 있습니다. 1. 이슈 생성 2. 분류 - 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다. 여기에는 우선 순위, 유형, 메타데이터(예: `good first issue`) 레이블이 포함됩니다. 저희가 추적할 유일한 이슈 우선 순위는 이 이슈가 "중요한지" 여부입니다. 향후 추가 레이블이 필요하면 추가하겠습니다. - (필요한 경우) 간결하고 명확하게 이슈를 설명하기 위해 제목을 정리하세요. 또한 제안의 제목은 "Proposal: [제목의 나머지 부분]"으로 서두를 떼야 합니다. - 이슈를 올바른 마일스톤에 추가합니다. 질문 이슈일 경우, 질문에 답변할 때까지 이슈를 마일스톤 추가하는 것에 대해 염려하지 마세요. - 저희는 작업일에 적어도 한 번 이상 이 과정을 시도합니다. 3. 논의 - `feature` 또는 `bug` 로 레이블이 지정된 이슈는 이를 해결하는 PR에 연결해야 합니다. - `feature` 또는 `bug` 이슈를 작업하는 사람(관리자 또는 커뮤니티의 누군가)은 해당 이슈를 직접 자신에게 배정하거나 해당 이슈를 처리하고 있다는 내용의 코멘트를 작성해야 합니다. - `proposal` 및 `support/question` 이슈는 해결될 때까지 또는 30일 이상 활발하지 않은 경우에도 계속 열려 있어야 합니다. 이렇게 하면 이슈 대기열을 관리 가능한 크기로 유지하고 잡음을 줄일 수 있습니다. 이슈가 계속 열려 있어야 하는 경우 `keep open` 레이블을 추가할 수 있습니다. 4. 이슈 종결 ## 패치에 기여하는 방법 1. 아직 서명하지 않은 경우 기여자 라이센스 계약에 서명하세요(위 세부 정보 참조). 2. 원하는 저장소를 포크하여 코드 변경 사항을 개발하고 테스트하세요. 3. 풀 리퀘스트를 보내주세요. 코딩 규약 및 표준은 [공식 개발자 문서](/community/developers)에 설명되어 있습니다. ## 풀 리퀘스트 모든 좋은 오픈 소스 프로젝트와 마찬가지로, 저희는 PR(풀 리퀘스트)을 사용하여 코드 수정을 추적합니다. ### PR 생명 주기 1. PR 생성 - PR은 일반적으로 이슈를 해결하기 위해 생성되거나 특정 이슈를 해결하는 다른 PR의 하위 집합이 됩니다. - 저희는 현재 진행 중인 PR을 환영합니다. 아직 진행 중이지만 다른 사람들이 보기에 유용한 중요 작업을 추적할 수 있는 좋은 방법입니다. PR이 진행 중인 작업의 경우 **반드시** "WIP: [제목]"으로 제목을 시작해야 합니다. PR을 리뷰할 준비가 되면 제목에서 "WIP"를 제거합니다. - 특정 이슈와 관련된 PR을 보내는 것이 바람직하지만 필수 사항은 아닙니다. 해당 PR이 급한 해결책이라면 이슈가 적절하지 않게 종결될 수 있는 상황이 있을 수 있습니다. 이 경우 PR 설명란에 세부 정보를 넣어주세요. 2. 분류 - 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다. 모든 레이블이 적용된 후에는 최소한 사이즈 레이블, `bug` 또는 `feature`, `awaiting review` 가 포함되어야 합니다. 레이블 정의에 대한 자세한 내용은 [레이블 섹션](#레이블)을 참조합니다. - PR을 올바른 마일스톤에 추가합니다. 이는 PR이 닫는 이슈와 동일해야 합니다. 3. 리뷰 배정 - 리뷰에 `awaiting review` 라는 레이블이 표시되면 관리자는 스케줄이 허용하는 대로 리뷰합니다. 이슈를 제기한 관리자는 리뷰에 대해 자체 요청(self-request)해야 합니다. - `size/large` 레이블이 있는 PR은 병합하기 전에 관리자로부터 2개의 리뷰 승인이 필요합니다. `size/medium` 또는 `size/small` 인 경우 관리자의 판단에 따릅니다. 4. 리뷰/논의 - 모든 리뷰는 GitHub 리뷰 도구를 사용하여 완료됩니다. - "Comment(주석)" 리뷰는 답변해야 하는 코드 관련 질문이 있을 때 사용해야 하지만 코드 변경은 포함되지 않습니다. 이러한 유형의 리뷰는 승인에 포함되지 않습니다. - "Changes Requested(변경 요청)" 리뷰는 코드를 병합하기 전에 수정해야 함을 나타냅니다. - 리뷰어는 필요에 따라 레이블을 갱신해야 합니다(예: `needs rebase`). 5. 질문에 답변하거나 코드를 수정하여 의견을 반영합니다. 6. LGTM (Looks good to me) - 리뷰어가 리뷰를 완료하고 코드가 병합될 준비가 된 것으로 보이면 "Approve(승인)" 리뷰는 기여자와 다른 관리자에게 코드를 리뷰한 후 병합 준비가 완료되었음을 알리는 데 사용됩니다. 7. 병합(merge) 또는 종결(close) - PR은 병합될 때까지 또는 30일 이상 활발하지 않은 경우 열려 있어야 합니다. 이렇게 하면 PR 대기열을 관리 가능한 크기로 유지하고 잡음을 줄일 수 있습니다. PR이 계속 열려 있어야 하는 경우 (WIP의 경우처럼), `keep open` 레이블을 추가할 수 있습니다. - PR을 병합하기 전에 PR에 한 개 이상의 LGTM이 필요한지 여부를 결정하기 위해 아래 [사이즈 레이블](#사이즈-레이블) 항목을 참조하세요. - PR 소유자가 `OWNERS` 파일에 포함되어 있는 경우 해당 사용자는 반드시 자신의 PR을 병합하거나 다른 OWNER에게 명시적으로 요청해야 합니다. - PR의 소유자가 `OWNERS`에 포함되어 있지 않은 경우, 모든 핵심 관리자가 PR을 병합할 수 있습니다. #### 문서 PR 문서 PR은 다른 PR과 동일한 수명 주기를 따릅니다. 또한 `docs` 레이블로 레이블이 지정됩니다. 문서의 경우 철자, 문법, 명료성에 특히 주의를 기울여야 합니다(코드의 주석*만큼* 중요하지 않음). ## 분류자 (Triager) 매주 목요일 공개 스탠드업 회의를 시작으로 핵심 관리자 중 한 명이 "분류자" 역할을 하게 됩니다. 이 담당자는 일주일 내내 새로운 PR 및 이슈에 대한 분류를 담당하게 됩니다. ## 레이블 다음 표에서는 헬름에 사용되는 모든 레이블 유형을 정의합니다. 카테고리별로 나뉩니다. ### 공통 레이블 | 레이블 | 설명 | | ----- | ----------- | | `bug` | 이슈를 버그 또는 PR을 버그 수정으로 표시합니다. | | `critical` | 이슈 또는 PR을 중요한 것으로 표시합니다. 이것은 PR이나 이슈를 다루는 것이 최우선이며 가능한 한 빨리 해결되어야 한다는 것을 의미합니다. | | `docs` | 이슈 또는 PR이 문서 변경임을 나타냅니다. | | `feature` | 이슈를 기능 요청으로 표시하거나 PR을 기능 구현으로 표시합니다. | | `keep open` | 이슈 또는 PR을 30일간 사용되지 않는 상태로 열어 둬야 함을 나타냅니다. | | `refactor` | 이슈가 코드 개선이며 버그를 고치거나 추가 기능을 추가하지 않음을 나타냅니다. | ### 이슈용 레이블 | 레이블 | 설명 | | ----- | ----------- | | `help wanted` | 이슈를 해결하기 위해 커뮤니티의 도움이 필요하다고 표시합니다. | | `proposal` | 이슈를 제안으로 표시합니다. | | `question/support` | 이슈를 요청이나 질문으로 표시합니다. | | `good first issue` | 이슈를 헬름을 처음 접하는 사용자에게 좋은 첫 이슈로 표시합니다. | | `wont fix` | 이슈가 논의되었으며 구현되지 않을 것임(또는 제안의 경우 받았음)을 나타냅니다. | ### PR용 레이블 | 레이블 | 설명 | | ----- | ----------- | | `awaiting review` | PR이 분류되었으며 다른 사용자가 리뷰할 준비가 되었음을 나타냅니다 | | `breaking` | PR이 코드를 변경한다는 것을 나타냅니다 (예: API 변경) | | `in progress` | 아직 리뷰되지 않았어도 관리자가 PR을 보고 있음을 나타냅니다 | | `needs rebase` | PR이 병합되기 전 리베이스(rebase)할 필요가 있음을 나타냅니다 | | `needs pick` | PR이 기능 브랜치(일반적으로 버그 수정 브랜치)로 체리픽(cherry-pick)할 필요가 있음을 나타냅니다. 체리픽했다면 `picked` 레이블을 적용하고 해당 레이블을 제거해야 합니다 | | `picked` | 해당 PR은 기능 브랜치로 체리픽했다는 것을 나타냅니다 | #### 사이즈 레이블 사이즈 레이블은 PR이 얼마나 "위험"한지를 나타내는 데 사용됩니다. 아래 가이드라인은 레이블을 배정하는 데 사용되지만, 궁극적으로 관리자에 의해 변경 될 수 있습니다. 예를 들어 PR이 한 파일에서 30 줄만 변경하더라도 주요 기능이 바뀐다면 여러 명의 서명이 필요하므로 `size/L` 로 레이블이 지정될 가능성이 높습니다. 반대로 작은 기능을 추가하지만 모든 경우를 다루기 위해 150 줄의 테스트가 필요한 PR은 줄 수가 아래에 정의된 것보다 많더라도 `size/S` 로 레이블을 지정할 수 있습니다. 핵심 관리자에 의해 제출되는 PR은 사이즈에 상관없이 한 명의 추가 관리자 승인만 필요로 합니다. 이렇게 하면 코드베이스(codebase)에 도입된 중요한 PR을 알고 있는 관리자가 두 명 이상 있게 됩니다. | 레이블 | 설명 | | ----- | ----------- | | `size/XS` | 생성된 파일은 무시하고 0~9줄을 변경하는 PR을 나타냅니다. 변경 사항에 따라 테스트가 거의 필요하지 않을 수 있습니다. | | `size/S` | 생성된 파일은 무시하고 10-29줄을 변경하는 PR을 나타냅니다. 소량의 수동 테스트만 필요할 수 있습니다. | | `size/M` | 생성된 파일은 무시하고 30-99줄을 변경하는 PR을 나타냅니다. 수동 유효성 검사가 필요합니다. | | `size/L` | 생성된 파일은 무시하고 100-499줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. | | `size/XL` | 생성된 파일은 무시하고 500-999 줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. | | `size/XXL` | 생성된 파일은 무시하고 1000개 이상의 행을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다. | ================================================ FILE: CONTRIBUTING.md ================================================ # Contributing Guidelines This is the contribution guide for the helm.sh website and documentation. Go to [helm/helm](https://github.com/helm/helm/blob/main/CONTRIBUTING.md) for the core project. --- Helm accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted. ## Reporting a Security Issue Most of the time, when you find a bug in Helm, it should be reported using [GitHub issues](https://github.com/helm/helm/issues). However, if you are reporting a _security vulnerability_, please email a report to [cncf-kubernetes-helm-security@lists.cncf.io](mailto:cncf-kubernetes-helm-security@lists.cncf.io). This will give us a chance to try to fix the issue before it is exploited in the wild. ## Sign Your Work The sign-off is a simple line at the end of the explanation for a commit. All commits needs to be signed. Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. The rules are pretty simple, if you can certify the below (from [developercertificate.org](https://developercertificate.org/)): ``` Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ``` Then you just add a line to every git commit message: Signed-off-by: Joe Smith Use your real name (sorry, no pseudonyms or anonymous contributions.) If you set your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. Note: If your git config information is set properly then viewing the `git log` information for your commit will look something like this: ``` Author: Joe Smith Date: Thu Feb 2 11:41:15 2018 -0800 Update README Signed-off-by: Joe Smith ``` Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will be rejected by the automated DCO check. ## Support Channels Whether you are a user or contributor, official support channels include: - [Issues](https://github.com/helm/helm/issues) - Slack: - User: [#helm-users](https://kubernetes.slack.com/messages/C0NH30761/details/) - Contributor: [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG/) Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. It is also worth asking on the Slack channels. ## Issues Issues are used as the primary method for tracking anything to do with the Helm project. ### Issue Types There are 5 types of issues (each with their own corresponding [label](#labels)): - `question/support`: These are support or functionality inquiries that we want to have a record of for future reference. Generally these are questions that are too complex or large to store in the Slack channel or have particular interest to the community as a whole. Depending on the discussion, these can turn into `feature` or `bug` issues. - `proposal`: Used for items (like this one) that propose new ideas or functionality that require a larger community discussion. This allows for feedback from others in the community before a feature is actually developed. This is not needed for small additions. Final word on whether or not a feature needs a proposal is up to the core maintainers. All issues that are proposals should both have a label and an issue title of "Proposal: [the rest of the title]." A proposal can become a `feature` and does not require a milestone. - `feature`: These track specific feature requests and ideas until they are complete. They can evolve from a `proposal` or can be submitted individually depending on the size. - `bug`: These track bugs with the code - `docs`: These track problems with the documentation (i.e. missing or incomplete) ### Issue Lifecycle The issue lifecycle is mainly driven by the core maintainers, but is good information for those contributing to Helm. All issue types follow the same general lifecycle. Differences are noted below. 1. Issue creation 2. Triage - The maintainer in charge of triaging will apply the proper labels for the issue. This includes labels for priority, type, and metadata (such as `good first issue`). The only issue priority we will be tracking is whether or not the issue is "critical." If additional levels are needed in the future, we will add them. - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure that proposals are prefaced with "Proposal: [the rest of the title]". - Add the issue to the correct milestone. If any questions come up, don't worry about adding the issue to a milestone until the questions are answered. - We attempt to do this process at least once per work day. 3. Discussion - issues that are labeled as `feature` or `bug` should be connected to the PR that resolves it. - Whoever is working on a `feature` or `bug` issue (whether a maintainer or someone from the community), should either assign the issue to themself or make a comment in the issue saying that they are taking it. - `proposal` and `support/question` issues should stay open until resolved or if they have not been active for more than 30 days. This will help keep the issue queue to a manageable size and reduce noise. Should the issue need to stay open, the `keep open` label can be added. 4. Issue closure ## How to Contribute a Patch 1. If you haven't already done so, sign a Contributor License Agreement (see details above). 2. Fork the desired repo, develop and test your code changes. 3. Submit a pull request. Coding conventions and standards are explained in the [official developer docs](https://helm.sh/docs/developers/). ## Pull Requests Like any good open source project, we use Pull Requests (PRs) to track code changes. ### PR Lifecycle 1. PR creation - PRs are usually created to fix or else be a subset of other PRs that fix a particular issue. - We more than welcome PRs that are currently in progress. They are a great way to keep track of important work that is in-flight, but useful for others to see. If a PR is a work in progress, it **must** be prefaced with "WIP: [title]". Once the PR is ready for review, remove "WIP" from the title. - It is preferred, but not required, to have a PR tied to a specific issue. There can be circumstances where if it is a quick fix then an issue might be overkill. The details provided in the PR description would suffice in this case. 2. Triage - The maintainer in charge of triaging will apply the proper labels for the issue. This should include at least a size label, `bug` or `feature`, and `awaiting review` once all labels are applied. See the [Labels section](#labels) for full details on the definitions of labels. - Add the PR to the correct milestone. This should be the same as the issue the PR closes. 3. Assigning reviews - Once a review has the `awaiting review` label, maintainers will review them as schedule permits. The maintainer who takes the issue should self-request a review. - Any PR with the `size/large` label requires 2 review approvals from maintainers before it can be merged. Those with `size/medium` or `size/small` are per the judgement of the maintainers. 4. Reviewing/Discussion - All reviews will be completed using GitHub review tool. - A "Comment" review should be used when there are questions about the code that should be answered, but that don't involve code changes. This type of review does not count as approval. - A "Changes Requested" review indicates that changes to the code need to be made before they will be merged. - Reviewers should update labels as needed (such as `needs rebase`) 5. Address comments by answering questions or changing code 6. LGTM (Looks good to me) - Once a Reviewer has completed a review and the code looks ready to merge, an "Approve" review is used to signal to the contributor and to other maintainers that you have reviewed the code and feel that it is ready to be merged. 7. Merge or close - PRs should stay open until merged or if they have not been active for more than 30 days. This will help keep the PR queue to a manageable size and reduce noise. Should the PR need to stay open (like in the case of a WIP), the `keep open` label can be added. - Before merging a PR, refer to the topic on [Size Labels](#size-labels) below to determine if the PR requires more than one LGTM to merge. - If the owner of the PR is listed in the `OWNERS` file, that user **must** merge their own PRs or explicitly request another OWNER do that for them. - If the owner of a PR is _not_ listed in `OWNERS`, any core maintainer may merge the PR. #### Documentation PRs Documentation PRs will follow the same lifecycle as other PRs. They will also be labeled with the `docs` label. For documentation, special attention will be paid to spelling, grammar, and clarity (whereas those things don't matter *as* much for comments in code). For additional style guidelines, see [Documentation Style Guide](style-guide.md). ## The Triager Each week, one of the core maintainers will serve as the designated "triager" starting after the public stand-up meetings on Thursday. This person will be in charge triaging new PRs and issues throughout the work week. ## Labels The following tables define all label types used for Helm. It is split up by category. ### Common | Label | Description | | ----- | ----------- | | `bug` | Marks an issue as a bug or a PR as a bugfix | | `critical` | Marks an issue or PR as critical. This means that addressing the PR or issue is top priority and must be addressed as soon as possible | | `docs` | Indicates the issue or PR is a documentation change | | `feature` | Marks the issue as a feature request or a PR as a feature implementation | | `keep open` | Denotes that the issue or PR should be kept open past 30 days of inactivity | | `refactor` | Indicates that the issue is a code refactor and is not fixing a bug or adding additional functionality | ### Issue Specific | Label | Description | | ----- | ----------- | | `help wanted` | Marks an issue needs help from the community to solve | | `proposal` | Marks an issue as a proposal | | `question/support` | Marks an issue as a support request or question | | `good first issue` | Marks an issue as a good starter issue for someone new to Helm | | `wont fix` | Marks an issue as discussed and will not be implemented (or accepted in the case of a proposal) | ### PR Specific | Label | Description | | ----- | ----------- | | `awaiting review` | Indicates a PR has been triaged and is ready for someone to review | | `breaking` | Indicates a PR has breaking changes (such as API changes) | | `in progress` | Indicates that a maintainer is looking at the PR, even if no review has been posted yet | | `needs rebase` | Indicates a PR needs to be rebased before it can be merged | | `needs pick` | Indicates a PR needs to be cherry-picked into a feature branch (generally bugfix branches). Once it has been, the `picked` label should be applied and this one removed | | `picked` | This PR has been cherry-picked into a feature branch | #### Size labels Size labels are used to indicate how "dangerous" a PR is. The guidelines below are used to assign the labels, but ultimately this can be changed by the maintainers. For example, even if a PR only makes 30 lines of changes in 1 file, but it changes key functionality, it will likely be labeled as `size/L` because it requires sign off from multiple people. Conversely, a PR that adds a small feature, but requires another 150 lines of tests to cover all cases, could be labeled as `size/S` even though the number of lines is greater than defined below. PRs submitted by a core maintainer, regardless of size, only requires approval from one additional maintainer. This ensures there are at least two maintainers who are aware of any significant PRs introduced to the codebase. | Label | Description | | ----- | ----------- | | `size/XS` | Denotes a PR that changes 0-9 lines, ignoring generated files. Very little testing may be required depending on the change. | | `size/S` | Denotes a PR that changes 10-29 lines, ignoring generated files. Only small amounts of manual testing may be required. | | `size/M` | Denotes a PR that changes 30-99 lines, ignoring generated files. Manual validation should be required. | | `size/L` | Denotes a PR that changes 100-499 lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. | | `size/XL` | Denotes a PR that changes 500-999 lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. | | `size/XXL` | Denotes a PR that changes 1000+ lines, ignoring generated files. This should be thoroughly tested before merging and always requires 2 approvals. | ================================================ FILE: Containerfile ================================================ FROM node:20-alpine WORKDIR /src # Tools needed by Make targets RUN apk update && apk add --no-cache make # Use existing Yarn; install deps with lockfile for reproducibility COPY package.json yarn.lock ./ RUN yarn install --frozen-lockfile # Copy project files COPY . . # Docusaurus dev server port EXPOSE 3000 # Make targets run inside the container (serve, build, etc.) ENTRYPOINT ["make"] ================================================ FILE: HELM2-TO-DOCUSAURUS.md ================================================ # Helm v2 to Docusaurus Migration Guide Automated migration of Helm v2 documentation from the original source repository to Docusaurus versioned documentation format, preserving the familiar v2.helm.sh navigation structure and fixing broken links. ## Key Features - **Complete Structure Analysis** - Analyzes live v2.helm.sh to capture exact sidebar structure - **Missing File Integration** - Adds helm commands not present in navigation but available in source - **Link Path Correction** - Fixes broken internal links using shared href processing utility - **Image Path Replacement** - Updates all image references to `/img/helm2/` format - **H2 Heading Removal** - Removes redundant first H2 headings from helm command files - **Index File Creation** - Generates proper Docusaurus landing page with DocCardList - **Proper Positioning** - Maintains v2.helm.sh hierarchical organization - **Fully idempotent** - Safe to re-run multiple times ## Usage **Simple command:** ```bash yarn migrate:v2 ``` **Manual steps (if needed):** 1. **Run complete migration:** ```bash node scripts/migrate-v2-docs.js ``` 2. **Copy images (if not already present):** ```bash cp -r helm2/docs/images static/img/helm2 ``` The migration command handles all steps automatically including: - Cloning helm2 source repository - Generating navigation structure - Processing and copying files - Applying link path corrections ## What It Does The migration process includes: 1. **Fresh Start**: Clears existing v2 documentation and helm2 source 2. **Source Setup**: Clones Helm v2 repository (release-2.17 branch) 3. **Structure Analysis**: `scripts/v2/menu-generate.js` fetches and analyzes complete v2.helm.sh sidebar structure 4. **Content Processing**: `scripts/v2/copy-files.js` processes all files: - Removes UTF-8 BOM characters - Replaces image paths from `(images/` to `(/img/helm2/` - Removes first H2 headings from helm command files - Creates proper Docusaurus frontmatter with hierarchical positioning - Adds missing helm commands (helm get notes, helm inspect readme) 5. **Link Correction**: `scripts/util/href-diffs-process.js` fixes broken internal links using `scripts/v2/href-diffs.json` 6. **Structure Creation**: Generates `versioned_docs/version-2/` with proper category organization 7. **Index Generation**: Creates `index.mdx` landing page with DocCardList component ## Output Structure ``` versioned_docs/version-2/ # Complete Docusaurus v2 docs ├── index.mdx # Landing page (position 1) ├── using_helm/ # Basic usage (position 2) ├── helm/ # CLI reference (position 3, 45 commands) ├── developing_charts/ # Chart development (position 4) ├── chart_template_guide/ # Template guides (position 5) ├── chart_best_practices/ # Best practices (position 6) └── [5 top-level files] # architecture, developers, etc. (positions 7-11) static/img/helm2/ # All migrated images ``` ## Validation & Maintenance **Verify after running:** - Navigation matches v2.helm.sh structure with correct positioning (1,2,3,4,5,6,7-11) - All images display correctly (`/img/helm2/` paths) - Index files use parent category labels in sidebar - First H2 headings removed from all helm command files - Netlify redirects handle v2 → v3 category mapping **Key paths:** - Migration orchestrator: `scripts/migrate-v2-docs.js` - Component scripts: `scripts/v2/menu-generate.js`, `scripts/v2/copy-files.js` - Link correction: `scripts/util/href-diffs-process.js` with `scripts/v2/href-diffs.json` - Generated data: `scripts/v2/menu.json` - Source: `helm2/docs/` (auto-cloned) - Output: `versioned_docs/version-2/` and `static/img/helm2/` The migration is fully automated and idempotent - safe to re-run multiple times. **Link path corrections:** Managed via `scripts/v2/href-diffs.json` - add entries here to fix additional broken links discovered in migrated content. ================================================ FILE: HELM3-TO-DOCUSAURUS.md ================================================ # Helm v3 to Docusaurus Migration Guide Automated migration of Helm v3 documentation from existing Hugo content to Docusaurus versioned documentation format, applying comprehensive text transformations and link corrections. ## Key Features - **Hugo to Docusaurus Conversion** - Transforms Hugo content structure to Docusaurus versioning - **Hugo Shortcode Processing** - Converts `{{< ref "path" >}}` and `{{< highlightexamplego file="path" >}}` to standard links - **Link Path Correction** - Fixes broken internal links using shared href processing utility - **Alias Removal** - Removes Hugo aliases that conflict with Docusaurus routing - **SDK Section Migration** - Imports and processes Go SDK examples with transformations - **DocCardList Integration** - Adds navigation cards to index pages - **Netlify Redirect Generation** - Creates redirects for removed aliases - **Fully idempotent** - Safe to re-run multiple times ## Usage **Simple command:** ```bash yarn migrate:v3 ``` **Manual steps (if needed):** 1. **Run complete migration:** ```bash node scripts/migrate-v3-docs.js ``` The migration command handles all steps automatically including: - Fresh start with clean slate - Moving docs from Hugo structure to Docusaurus versioning - Processing Hugo shortcodes and text replacements - Applying link path corrections - Removing conflicting aliases - Adding navigation components ## What It Does The migration process includes: 1. **Fresh Start**: Clears existing v3 documentation and restores from git main 2. **Docusaurus Setup**: Creates `versioned_docs/version-3/` structure 3. **Content Migration**: Moves docs from `content/en/docs/` to versioned structure 4. **Content Cleanup**: Deletes files marked with deprecated frontmatter section 5. **File Renaming**: Converts `index.md` files to `index.mdx` for React component support 6. **Frontmatter Conversion**: Replaces Hugo `weight` with Docusaurus `sidebar_position` 7. **Index Metadata**: Adds proper metadata to main index file 8. **SDK Migration**: `scripts/v3/migrate-sdk-section.js` imports Go SDK examples with transformations 9. **Text Processing**: `scripts/util/util-text-replacements.js` handles: - Hugo shortcode conversion (`{{< ref "path" >}}` → `path`) - Link path correction using `scripts/v3/href-diffs.json` 10. **Helm File Processing**: `scripts/v3/process-helm-files.js` removes redundant H2 headings and adds metadata 11. **Alias Removal**: `scripts/v3/remove-aliases.js` removes conflicting Hugo aliases 12. **Navigation Enhancement**: `scripts/util/util-migration.js` adds DocCardList components to index pages 13. **Redirect Generation**: `scripts/v3/add-netlify-redirects.js` creates redirects for removed aliases ## Output Structure ``` versioned_docs/version-3/ # Complete Docusaurus v3 docs ├── index.mdx # Landing page with DocCardList ├── intro/ # Introduction section ├── topics/ # Advanced topics ├── chart_template_guide/ # Template development ├── chart_best_practices/ # Best practices ├── community/ # Community resources ├── helm/ # CLI reference └── [other sections] # Additional documentation areas netlify.toml # Updated with v3 redirects ``` ## Validation & Maintenance **Verify after running:** - Navigation structure matches expected Docusaurus layout - Hugo shortcodes converted to standard markdown links - All `index.mdx` files have proper DocCardList components - CLI reference files have clean headings (no redundant H2s) - Netlify redirects handle removed aliases - No Hugo aliases remain in frontmatter **Key paths:** - Migration orchestrator: `scripts/migrate-v3-docs.js` - Component scripts: `scripts/v3/migrate-sdk-section.js`, `scripts/v3/process-helm-files.js`, `scripts/v3/remove-aliases.js`, `scripts/v3/add-netlify-redirects.js` - Text processing: `scripts/util/util-text-replacements.js`, `scripts/util/util-migration.js` - Link correction: `scripts/util/href-diffs-process.js` with `scripts/v3/href-diffs.json` - Source: `content/en/docs/` (Hugo structure) - Output: `versioned_docs/version-3/` (Docusaurus structure) The migration is fully automated and idempotent - safe to re-run multiple times. **Link path corrections:** Managed via `scripts/v3/href-diffs.json` - add entries here to fix additional broken links discovered in migrated content. **SDK examples:** The migration includes Go SDK examples from `sdkexamples/` with automatic transformations for Docusaurus compatibility. ================================================ FILE: LICENSE ================================================ The MIT License (MIT) Copyright (c) 2017 Microsoft Corporation Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ================================================ FILE: Makefile ================================================ SITE_URL ?= http://localhost:3000 BASE_URL ?= / clean: rm -rf node_modules/ build/ .docusaurus .cache-loader install: yarn install --frozen-lockfile build: clean install SITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run build # Cache-friendly install - only runs if dependencies missing or yarn.lock is newer install-if-needed: @if [ ! -f "node_modules/.bin/docusaurus" ] || [ "yarn.lock" -nt "node_modules" ]; then \ echo "Installing dependencies..."; \ yarn install --frozen-lockfile; \ else \ echo "Dependencies up to date, skipping install"; \ fi # Cache-friendly build for Netlify - preserves cached directories netlify-build: install-if-needed SITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run build .PHONY: sdkexamples sdkexamples: make -C sdkexamples serve: SITE_URL=$(SITE_URL) BASE_URL=$(BASE_URL) yarn run start --host 0.0.0.0 IMAGE_NAME ?= helm-www image: podman build -t $(IMAGE_NAME) -f Containerfile . # Default target executed inside the container if none specified CONTAINER_TARGET = $(if $(filter-out image-run,$(MAKECMDGOALS)),$(filter-out image-run,$(MAKECMDGOALS)),serve) # Podman run: pass env for both build and serve targets image-run: image podman run --rm --init -it \ -p 3000:3000 \ -v $(PWD):/src:Z \ -e BASE_URL="$(BASE_URL)" \ -e SITE_URL="$(SITE_URL)" \ --name $(IMAGE_NAME)-run \ $(IMAGE_NAME) $(CONTAINER_TARGET) ================================================ FILE: OWNERS ================================================ maintainers: - gjenkins8 - karenhchu - mattfarina - paigecalvert - scottrigby - technosophos - TerryHowe - yxxhero emeritus: - angellk - bacongobbler - bridgetkromhout - flynnduism - hickeyma - jdolitsky - thomastaylor312 ================================================ FILE: README-ko.md ================================================ ![github-banner-helm-helmwww](https://user-images.githubusercontent.com/686194/68531441-f4ad4e00-02c6-11ea-982b-74d7c3ff0071.png) 여기서 [헬름](https://github.com/helm/helm) 프로젝트의 웹 사이트 [helm.sh](https://helm.sh/)를 구성하는 모든 것을 확인할 수 있습니다. 문서를 편집하거나 웹 사이트 버그를 보고하거나 새 블로그 게시물을 작성하려는 경우 잘 찾아오셨습니다! ## 개발 Helm.sh는 간단한 [Docusaurus](https://docusaurus.io/) 정적 사이트입니다. 웹 사이트를 로컬에서 실행하려면 먼저 의존성을 설치해야 합니다. ``` yarn ``` 그런 다음 사이트를 로컬에서 컴파일하고 실행할 수 있습니다. ``` yarn start ``` ## 배포 [![Netlify Status](https://api.netlify.com/api/v1/badges/8ffabb30-f2f4-45cc-b0fa-1b4adda00b5e/deploy-status)](https://app.netlify.com/sites/helm-merge/deploys) 변경 사항을 `main` 브랜치에 병합하면 [넷틀리파이(Netlify)](https://app.netlify.com/sites/helm-merge/deploys)에 자동으로 배포됩니다. 빌드 로그는 [여기](https://app.netlify.com/sites/helm-merge/deploys)에서 확인할 수 있습니다. --- ## 기여 누구나 풀 리퀘스트(PR)를 제출하여 Helm.sh을 편집할 수 있습니다. 커밋을 위해서는 서명이 필요합니다. [기여 가이드](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#sign-your-work)를 참조하세요. 풀 리퀘스트는 병합되기 전에 [관리자](https://github.com/helm/helm-www/blob/main/OWNERS)의 승인이 필요합니다. ### 헬름 문서를 편집하는 방법 헬름 v4 문서는 이 저장소의 `/docs/` 에 있습니다. 헬름 v4 문서의 사이드바는 `sidebars.js`에 있습니다. 헬름 v3 문서는 `versioned-docs/version-3` 에 있습니다. 헬름 v3 문서의 사이드바는 `versioned-sidebars/sidebars-version-2.js`에 있습니다. 이전 버전의 경우, [기본 헬름 저장소](https://github.com/helm/helm/tree/dev-v2/docs)의 dev-v2 브랜치를 참조합니다. ### 헬름 CLI 레퍼런스 문서 업데이트 헬름 CLI 명령어 목록에 대한 문서는 기본 헬름 프로젝트 저장소에서 [내보내지고](https://github.com/helm/helm/blob/a6b2c9e2126753f6f94df231e89b2153c2862764/cmd/helm/root.go#L169), [여기](https://helm.sh/docs/helm)에서 레퍼런스로 제공됩니다. 문서를 업데이트하려면 다음을 수행해야 합니다. 1. `helm plugin uninstall` 을 실행하여 현재 설치된 모든 플러그인을 제거합니다. 2. `content/en/docs/helm/` 으로 이동합니다. 3. 기존 마크다운 파일을 대체하여 새로운 마크다운 문서 파일을 생성하기 위해 `HOME='~' helm docs --type markdown --generate-headers`를 실행합니다. **참고:** 문서를 빌드하려는 helm 버전을 실행해야 합니다 (예: 올바른 태그를 체크아웃하고 빌드) 4. 변경 내용을 커밋하고 PR을 만들어 웹 사이트를 업데이트합니다. ### 블로그 게시물을 작성하는 방법 블로그 게시물은 풀 리퀘스트를 통해 만들어집니다. 다음 단계를 사용하여 추가합니다. 1. `/blog/` 디렉터리에 게시 날짜와 제목이 파일명인 새 파일을 추가합니다. 파일은 마크다운 형식이어야 합니다. 형식 예시는 기존 제목을 참조합니다. 2. 이 형식을 사용하여 파일에 헤더 메타데이터를 추가합니다. ```yaml --- title: "Blog Title" slug: "blog-slug" # from /blog/authors.yml authors: ["firstlast"] date: "YYYY-MM-DD" --- ``` 3. 이 저자의 첫 번째 블로그 게시물인 경우, `/blog/authors.yml`을 업데이트하여 새 저자 레코드를 추가합니다. ```yaml # authors.yml johndoe: name: John Doe image_url: https://github.com/johndoe.png page: true socials: github: johndoe linkedin: johndoe website: http://johndoe.com/ ``` 4. `---` 아래에 마크다운으로 내용을 추가합니다. 이 섹션에는 제목을 포함할 필요가 없습니다. 5. 모든 이미지는 `/blog/images/` 디렉토리에 두어야 합니다. 이미지 크기를 줄이려면 무손실 압축되어야 합니다. [ImageOptim](https://imageoptim.com/)와 같은 도구를 사용할 수 있습니다. 6. 블로그 인덱스 페이지의 내용을 요약하려면 마크다운 파일에 `` 구분자를 넣습니다. 이렇게 하면 _더 읽기_ 링크로 내용 끝을 자릅니다. 블로그 PR은 병합되기 전에 주요 헬름 [관리자](https://github.com/helm/helm/blob/main/OWNERS)들의 승인이 필요합니다. ### 버전 관리 이 저장소의 다음 파일들이 버전 관리를 제어하는 데 사용됩니다: - 버전 관리된 문서는 `versioned_docs`에 있습니다. - 각 버전에 해당하는 사이드바는 `versioned_sidebars`에 있습니다. - 버전 관리 동작은 `docusaurus.config.js` 파일에서 관리됩니다: ```js export default { presets: [ '@docusaurus/preset-classic', docs: { // lastVersion = 최신 릴리스 버전 (/versioned_docs의 특정 버전 또는 'current') // 최신으로 나열되지 않은 버전의 경우, 사용자가 오래되었거나 사전 릴리스 문서를 보고 있다는 경고 배너가 자동으로 표시됩니다 lastVersion: '3', versions: { // current = 최상위 /docs 디렉토리의 문서. 이것들은 사전 릴리스이거나 최신 릴리스 버전일 수 있습니다 // label = 네비게이션 바 드롭다운에 표시되는 버전 레이블 current: { label: '4.0.0-alpha.1 🚧' }, // 번호가 매겨진 버전은 /versioned_docs의 디렉토리에 해당합니다 '3': { label: '3.19.0' }, '2': { label: '2.17.0' }, }, }, ], }; ``` - 사용 가능한 버전 목록은 `versions.json`에서 유지됩니다. 아래 표는 이 저장소의 버전 관리된 문서에 매핑되는 버전 레이블과 URL 경로를 설명합니다: | 저장소 경로 | 버전 | URL 경로 | | -------------------------------------- | -------------------- | ------------------- | | `versioned_docs/version-2/filename.md` | 2.17.0 | /docs/2/filename | | `versioned_docs/version-3/filename.md` | 3.19.0 (최신) | /docs/filename | | `docs/filename.md` | 4.0.0-alpha.1 (현재) | /docs/next/filename | #### 사전 릴리스 문서를 GA로 이동하는 방법 Docusaurus는 _사전 릴리스_ (알파, 베타) 문서 게시를 지원합니다. 기본적으로 사전 릴리스 문서는 helm.sh/docs/next에서 게시되며 이 저장소의 최상위 `/docs` 디렉토리에서 제공됩니다. 또한 Docusaurus는 사용자가 릴리스되지 않은 문서를 보고 있다는 것을 알리기 위해 모든 사전 릴리스 문서에 자동으로 배너를 적용합니다. Helm의 사전 릴리스 버전이 GA로 승격될 때, 사전 릴리스 문서를 helm.sh/docs/next에서 helm.sh/docs로 이동하려면 다음을 수행합니다: 1. `docusaurus.config.js`를 업데이트하여 `lastVersion`을 `'current'`로 설정합니다. 이렇게 하면 메인 `/docs` 폴더의 내용이 helm.sh`/docs`에 게시됩니다. ```js // docusaurus.config.js lastVersion: 'current', ``` 1. `current` 버전의 네비게이션 바 `label`을 업데이트합니다. 예를 들어: ```js // docusaurus.config.js current: { label: '4.0.0' }, ``` 1. 변경사항을 테스트하기 위해 로컬 미리보기를 시작합니다. "릴리스되지 않음" 배너가 현재 버전에서 제거되고 현재 버전이 helm.sh/docs/next가 아닌 helm.sh/docs에서 사용할 수 있게 되는 것을 확인해야 합니다. #### 새로운 사전 릴리스 버전을 만드는 방법 새 버전 만들기는 `/docs` 디렉토리 내용을 `versioned_docs`의 버전 관리된 폴더로 복사하는 것을 의미합니다. 새로운 _주요_ 사전 릴리스 버전의 문서를 게시할 준비가 되었을 때 버전을 만듭니다. 이는 일반적으로 Helm의 새로운 알파 버전이 개발되고 문서화할 준비가 되었을 때입니다. **참고:** Helm의 사전 릴리스 버전이 개발되고 문서화할 준비가 될 때까지는 새 버전 만들기를 권장하지 않습니다. 그렇지 않으면 문서를 두 곳에서 유지해야 하므로(둘 다 `/docs`와 최신 `/versioned_docs` 폴더), 관리자가 동기화 상태를 유지하기 위해 추가 작업을 해야 합니다. 대신 아래의 *사전 릴리스 문서를 GA로 이동하는 방법*을 참조하세요. 새 버전을 만들려면: 1. ``이 주요 Helm 버전에 해당하는 정수인 `yarn docusaurus docs:version `을 실행합니다. 예를 들어, Helm v5에 대한 새로운 사전 릴리스 문서를 게시하려면 v4 문서 내용을 새로운 `version-4` 폴더로 복사하기 위해 `yarn docusaurus docs:version 4`를 실행할 수 있습니다. 이 명령은 다음을 수행합니다: - 전체 `docs/` 폴더 내용을 새로운 `versioned_docs/version-/` 폴더로 복사합니다. - `versioned_sidebars/version--sidebars.json`에 버전 관리된 사이드바 파일을 생성합니다. - `versions.json`에 새 버전 번호를 추가합니다. 1. `docusaurus.config.js` 파일을 업데이트합니다: 1. `lastVersion`을 최신 GA 버전으로 설정합니다. 이렇게 하면 helm.sh/docs의 문서가 최신 versioned_docs 폴더에서 제공됩니다. 그리고 helm.sh/docs/next의 문서가 메인 `/docs` 폴더에서 제공됩니다. 예를 들어, Helm v4 문서를 `versioned_docs/version-4/` 디렉토리로 만들고 Helm v5.0.0-alpha.1에 대한 사전 릴리스 문서를 게시하려면 `lastVersion`을 `'4'`로 설정합니다. 1. `current` 버전의 네비게이션 바 `label`을 업데이트합니다. 예를 들어, 현재(사전 릴리스) 버전을 `5.0.0-alpha.1`로 레이블링하려면 다음과 같이 레이블을 업데이트합니다: ```js current: { label: '5.0.0-alpha.1 🚧' }, ``` 1. 변경사항을 테스트하기 위해 로컬 미리보기를 시작합니다. 드롭다운에서 새 버전을 보고, helm.sh/docs/next에서 사전 릴리스 문서에 액세스할 수 있으며, 모든 사전 릴리스 문서 상단에 "릴리스되지 않음" 배너가 표시되는 것을 확인해야 합니다. 새 문서 버전 만들기에 대한 자세한 정보는 Docusaurus 문서의 [버전 관리](https://docusaurus.io/docs/versioning)를 참조하세요. ### 국제화 & 번역 **우리 사이트와 문서의 컨텐츠 번역을 환영합니다** 전 세계에서 Helm에 대한 접근을 확장하는 데 도움이 되도록 합니다. Helm.sh는 여러 언어를 지원합니다. 해외 사용자를 위한 컨텐츠 번역과 구성 가이드는 [헬름 문서 현지화](/community/localization)를 참조하세요. --- ### 행동 강령 헬름 커뮤니티 참여는 헬름 [행동 강령](https://github.com/helm/helm/blob/main/code-of-conduct.md)을 따릅니다. ### 감사합니다! 웹 사이트 및 문서 기여에 감사드립니다! :clap: ================================================ FILE: README.md ================================================ ![github-banner-helm-helmwww](https://user-images.githubusercontent.com/686194/68531441-f4ad4e00-02c6-11ea-982b-74d7c3ff0071.png) This is where you'll find all of the assets that make up [helm.sh](https://helm.sh/), the website for the [Helm](https://github.com/helm/helm) project. If you're looking to edit docs, report a website bug, or write a new blog post, you've come to the right place! ## Development Helm.sh is a simple [Docusaurus](https://docusaurus.io/) static site. To run the website locally, you'll need to first install the dependencies: ``` yarn ``` You can then compile and run the site locally: ``` yarn start ``` ## Deployment [![Netlify Status](https://api.netlify.com/api/v1/badges/8ffabb30-f2f4-45cc-b0fa-1b4adda00b5e/deploy-status)](https://app.netlify.com/sites/helm-merge/deploys) Changes are automatically deployed to [Netlify](https://app.netlify.com/sites/helm-merge/deploys) when merged to `main`. Build logs can be found [here](https://app.netlify.com/sites/helm-merge/deploys). --- ## Contributing Anyone can submit a PR to edit Helm.sh. We require commits be signed - please refer to the [contributing guide](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#sign-your-work). Pull requests require [maintainer](https://github.com/helm/helm-www/blob/main/OWNERS) approval before merge. ### Style Guide For Helm documentation style guidelines, see [Documentation Style Guide](style-guide.md). ### How to Edit The Helm Docs Helm v4 documentation is located in this repo under `/docs/`. The sidebar for the Helm v4 docs is located at `sidebars.js`. Helm v3 documentation is located under `versioned-docs/version-3`. The sidebar for the Helm v3 docs is located at `versioned-sidebars/sidebars-version-2.js` For earlier versions, see the dev-v2 branch of the main Helm repo [here](https://github.com/helm/helm/tree/dev-v2/docs). ### Community Documentation The Community section imports content from the [helm/community](https://github.com/helm/community) repository. To manage these imported docs: #### Download/Update Community Docs ```bash yarn download-remote-community ``` This command fetches the latest community documentation from the helm/community repository and applies transformations for proper integration. #### Clear Community Docs ```bash yarn clear-remote-community ``` This removes the imported community documentation files (useful before re-importing or for troubleshooting). The imported docs configuration is defined in `docusaurus.config.js` under `customFields.communityDocs`. See `ARCHITECTURAL_DECISIONS.md` for details on the implementation. ### Updating the Helm CLI Reference Docs The documentation for the list of Helm CLI Commands are [exported](https://github.com/helm/helm/blob/a6b2c9e2126753f6f94df231e89b2153c2862764/cmd/helm/root.go#L169) from the main helm project repo and rendered [here on the website](https://helm.sh/docs/helm) as a reference. #### Using the automated script The automated script regenerates and properly formats the CLI documentation: ```bash node scripts/regenerate-cli-docs.mjs # Examples: node scripts/regenerate-cli-docs.mjs v3.19.0 versioned_docs/version-3 # → versioned_docs/version-3/helm/ node scripts/regenerate-cli-docs.mjs v4.0.0-rc.1 docs # → docs/helm/ node scripts/regenerate-cli-docs.mjs v4.0.0 versioned_docs/version-4 # → versioned_docs/version-4/helm/ ``` The script will: - Download the specified Helm version - Generate documentation in `/helm/` - Apply all necessary post-processing (frontmatter cleanup, link conversion, etc.) ### How to Write a Blog Post Blog posts are created via pull requests. The following steps are used to add them: 1. Add a new file to the `/blog/` directory whose name is the published date and the title. The files must be markdown formatted. See the existing titles for examples of the format 2. Add the header meta-data to the file using this format. ```yaml --- title: "Blog Title" slug: "blog-slug" # from /blog/authors.yml authors: ["firstlast"] date: "YYYY-MM-DD" --- ``` 3. If this is the first blog post by this author, update `/blog/authors.yml` to add a new author record. ```yaml # authors.yml johndoe: name: John Doe image_url: https://github.com/johndoe.png page: true socials: github: johndoe linkedin: johndoe website: http://johndoe.com/ ``` 4. Add the content below the `---` as Markdown. The title does not need to be included in this section 5. Any images should be placed in the `/blog/images/` directory. Images should be losslessly compressed to reduce their size. Tools, such as [ImageOptim](https://imageoptim.com/), can be used. 6. To summarize the content on the blog index page, insert a `` break in your markdown. This will truncate the content with a _Read More_ link. Blog PRs require approval from the core Helm [maintainers](https://github.com/helm/helm/blob/main/OWNERS) before merge. ### Versioning The following files in this repo are used to control versioning: - Versioned documentation is located in `versioned_docs`. - The corresponding sidebar for each version is located in `versioned_sidebars`. - Versioning behavior is managed in the `docusaurus.config.js` file: ```js export default { presets: [ '@docusaurus/preset-classic', docs: { // lastVersion = the latest released version (either a specific version from /versioned_docs or 'current') // For any versions not listed as the latest, a banner is automatically displayed to warn users that they are viewing either old or pre-release docs lastVersion: '3', versions: { // current = docs from the top-level /docs directory. These can be pre-release or the latest released version // label = the version label displayed in the navbar dropdown current: { label: '4.0.0-alpha.1 🚧' }, // numbered versions correspond to directories in /versioned_docs '3': { label: '3.19.0' }, '2': { label: '2.17.0' }, }, }, ], }; ``` - The list of available versions is maintained in `versions.json`. The table below explains the version labels and URL paths that map to versioned docs in this repo: | Repo Path | Version | URL Path | | -------------------------------------- | ----------------------- | ------------------- | | `versioned_docs/version-2/filename.md` | 2.17.0 | /docs/2/filename | | `versioned_docs/version-3/filename.md` | 3.19.0 (latest) | /docs/filename | | `docs/filename.md` | 4.0.0-alpha.1 (current) | /docs/next/filename | #### How to move pre-release docs to GA Docusaurus has support for publishing _pre-release_ (alpha, beta) documentation. By default, pre-release documentation is published at helm.sh/docs/next and is served from the top-level `/docs` directory in this repo. Additionally, Docusaurus automatically applies a banner to all pre-release documentation to notify users that they are viewing unreleased docs. When a pre-release version of Helm is promoted to GA, do the following to move pre-release docs from helm.sh/docs/next to helm.sh/docs: 1. Update `docusaurus.config.js` to set `lastVersion` to `'current'`. This publishes the content of the main `/docs` folder to helm.sh`/docs`. ```js // docusaurus.config.js lastVersion: 'current', ``` 1. Update the navbar `label` for the `current` version. For example: ```js // docusaurus.config.js current: { label: '4.0.0' }, ``` 1. Start a local preview to test your changes. You should see that the "unreleased" banner is removed from the current version, and that the current version is now available at helm.sh/docs, rather than at helm.sh/docs/next. #### How to cut a new pre-release version Cutting a new version refers to copying the full `/docs` directory contents to a versioned folder in `versioned_docs`. You cut a version when you are ready to publish a new _major_ pre-release version of the docs. This is usually when a new alpha version of Helm is being developed and is ready to be documented. **Note:** Cutting a new version is _not_ recommend until a pre-release version of Helm is being developed and is ready to be documented. Otherwise, the docs will need to be maintained in two places (both `/docs` and the latest `/versioned_docs` folder), creating extra work for maintainers to make sure they stay in-sync. Instead, see _How to move pre-release docs to GA_ below. To cut a new version: 1. Run `yarn docusaurus docs:version `, where `` is an integer that corresponds to a major Helm version. For example, when we publish Helm 4.0.0 we will run `yarn docusaurus docs:version 4`. This command does the following: - Copies the full `docs/` folder contents into a new `versioned_docs/version-/` folder. - Creates a versioned sidebars file in `versioned_sidebars/version--sidebars.json`. - Appends the new version number to `versions.json`. 1. Update the `docusaurus.config.js` file: 1. Set `lastVersion` to to the latest GA version. This ensures that the docs at helm.sh/docs are served from the latest versioned_docs folders. And, the docs at helm.sh/docs/next are served from the main `/docs` folder. For example, if you just cut the Helm v4 docs to a `versioned_docs/version-4/` directory, and want to publish pre-release docs for version Helm v5.0.0-alpha.1, then set `lastVersion` to `'4'`. 1. Update the navbar `label` for the `current` version. For example, to label the current (pre-release) version `5.0.0-alpha.1`, update the label as follows: ```js current: { label: '5.0.0-alpha.1 🚧' }, ``` 1. Start a local preview to test your changes. You should see the new version in the dropdown, be able to access the pre-release docs at helm.sh/docs/next, and see an "unreleased" banner at the top of all the pre-released docs. For more information about cutting new docs versions, see [Versioning](https://docusaurus.io/docs/versioning) in the Docusaurus documentation. ### Internationalization & Translation **We welcome content translations** to our site and our docs, to help expand access to Helm around the world. Helm.sh supports multiple languages. Please refer to the [Localizing Helm Documentation](https://helm.sh/docs/community/localization/) for a guide on translating and configuring content for international users. --- ### Code of Conduct Participation in the Helm community is governed by the Helm [Code of Conduct](https://github.com/helm/helm/blob/main/code-of-conduct.md). ### Thank You! We appreciate your contributions to our website and our documentation! :clap: ================================================ FILE: blog/2018-06-01-cncf.md ================================================ --- title: "Helm Enters the CNCF" slug: "helm-enters-the-cncf" authors: ["mattbutcher"] date: "2018-06-01" --- Today we are happy to announce that Helm has become an official top-level [CNCF](https://www.cncf.io/) project, joining the ranks of Prometheus, Linkerd, OpenTracing, and others. Helm will enter the CNCF as an incubating project as we continue to work on the next-generation Helm 3 cloud-native package manager. We are grateful to the Helm community, which has diligently contributed to the core Helm project, to the official charts repository, Monocular, to Chart Museum, and to other Helm-related projects. As a CNCF project, we look forward to expanding the Helm ecosystem. Over the coming months, we will be re-organizing as we ease our way out of the Kubernetes org and into CNCF. Helm began as an internal hackathon project at Deis, and we made our first public release at the original KubeCon. Now, only a few short years later, the Helm ecosystem has seen 3,500 contributors spanning 566 companies. We have made more than 50 releases, and see over 50,000 downloads per month. And last February, we had the [inaugural Helm Summit](https://www.youtube.com/playlist?list=PLVt9l4b66d5EjjJ_VBe_5tEiJrAGLsDb-), where 179 developers, operators, and SREs gathered in Portland, Oregon to talk about the future of the project. Thank you for making the Helm community a welcoming place where people from all skill levels can participate in this emerging cloud-native landscape! We are excited to improve Helm as the package manager for the cloud-native landscape. We would like to conclude with special thanks to Brian Grant for sponsoring the CNCF proposal, and Matt Farina for writing the proposal and guiding it through the process. ================================================ FILE: blog/2018-07-23-bring-helm-home.md ================================================ --- title: "Bringing Helm Home" slug: "bringing-helm-home" authors: ["mattbutcher"] date: "2018-07-23" --- Earlier this summer, we announced that [Helm joined the CNCF](https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/) as an official incubating project. Part of that transition involves moving the Helm project out of the Kubernetes GitHub org and into its org. We’re excited to announce that we’ve completed that process. As of last week, we have moved the Helm code repository to [https://github.com/helm/helm](https://github.com/helm/helm). Fun fact: This is the same GitHub repository where the Helm project first started. When we started Helm in 2015, we created the Helm organization in GitHub. But thanks to the enthusiastic support of the Kubernetes community, we migrated the entire codebase into the Kubernetes org in 2016. As a separate CNCF project with its own vibrant and growing ecosystem, it makes sense to once again have Helm back home in its own GitHub org. Since the first beta release of Helm 2.0, we have pledged to keep Helm stable for users and developers alike. Before moving Helm into its new GitHub home, we tested to make sure that this would not break existing builds or existing tooling. Thanks to GitHub’s excellent support for repository moving, we believe we have maintained our stability promise. Along with the main Helm source code repo, we have moved a few other Helm related repositories including [Charts](https://github.com/helm/charts), [Monocular](https://github.com/helm/monocular), [Community](https://github.com/helm/community), [ChartMuseum](https://github.com/helm/chartmuseum), and other Helm projects all under the official CNCF Helm GitHub org. This means the community can find all Helm related items under one GitHub org. This isn’t our only big news since joining CNCF. Helm 3 is now underway, as developers begin adding new features. And soon we will announce a minor process change that will simplify the process of becoming a Helm contributor as we switch from requiring a CLA to a DCO. ================================================ FILE: blog/2018-07-24-helm-emeritus-rimus.md ================================================ --- title: "Helm Emeritus Maintainer Rimas Mocevicius" slug: "helm-emeritus-maintainer-rimas-mocevicius" authors: ["mattbutcher"] date: "2018-07-24" --- Rimas Mocevicius ([rimusz](https://github.com/rimusz)) has become the fourth Helm Emeritus Maintainer. Rimas is one of the three original founders of Helm. Author of [CoreOS Essentials](https://rimusz.net/coreos-essential-book/) (Packt, 2016) and creator of [Kube Solo](https://github.com/TheNewNormal/kube-solo-osx), Rimas is a long-time member of the Kubernetes ecosystem. Rimas was an active contributor on Helm Classic, and has been a leading voice in the community ever since. Check out Rimas' latest blog post on [Tillerless Helm](https://rimusz.net/tillerless-helm). ================================================ FILE: blog/2018-08-27-helm-switch-dco.md ================================================ --- title: "Helm Moves To DCO" slug: "helm-dco" date: "2018-08-27" --- When Helm was part of the Kubernetes project it, like the rest of Kubernetes, used the [CNCF Contributor License Agreement (CLA)](https://github.com/cncf/cla). This served Helm well for years. But, most of the CNCF projects use a [Developers Certificate of Origin (DCO)](https://developercertificate.org/) instead of a CLA. The exceptions are Kubernetes and gRPC. Upon Helm becoming a CNCF project itself we were asked if we wanted to move Helm to a DCO. After some careful consideration and a little research, the Helm maintainers voted to move to a DCO. ## What Does This Solve? Why Switch? Making a change like this should have a good reason and we have one. It is often easier to get started contributing under a DCO than a CLA. When one is developing software for a company they need to have the company sign the Corporate CLA prior to submitting contributions. That means there is a step after the business decides to contribute where legal documents need to be signed and exchanged. Once this is done there are steps to associate people with those legal documents. All of this takes time. In some companies this process can take weeks or longer. We wanted to make it simpler to contribute. ## What Is A DCO? A DCO is lightweight way for a developer to certify that they wrote or otherwise have the right to submit code or documentation to a project. The way a developer does this is by adding a `Signed-off-by` line to a commit. When they do this they are agreeing to the DCO. The full text of the DCO can be found at https://developercertificate.org. It reads: > Developer Certificate of Origin > Version 1.1 > > Copyright (C) 2004, 2006 The Linux Foundation and its contributors. > 1 Letterman Drive > Suite D4700 > San Francisco, CA, 94129 > > Everyone is permitted to copy and distribute verbatim copies of this > license document, but changing it is not allowed. > > > Developer's Certificate of Origin 1.1 > > By making a contribution to this project, I certify that: > > (a) The contribution was created in whole or in part by me and I > have the right to submit it under the open source license > indicated in the file; or > > (b) The contribution is based upon previous work that, to the best > of my knowledge, is covered under an appropriate open source > license and I have the right under that license to submit that > work with modifications, whether created in whole or in part > by me, under the same open source license (unless I am > permitted to submit under a different license), as indicated > in the file; or > > (c) The contribution was provided directly to me by some other > person who certified (a), (b) or (c) and I have not modified > it. > > (d) I understand and agree that this project and the contribution > are public and that a record of the contribution (including all > personal information I submit with it, including my sign-off) is > maintained indefinitely and may be redistributed consistent with > this project or the open source license(s) involved. An example signed commit message might look like: > An example commit message > > Signed-off-by: Some Developer Git has a flag that can sign a commit for you. An example using it is: ``` $ git commit -s -m 'An example commit message' ``` In the past, once someone wanted to contribute they needed to go through the CLA process first. Now they just need to signoff on the commit. ## FAQs ### What About Existing Pull Requests Under The CLA If a pull request was previously submitted under the CLA we will still honor those. All new contributions will need to be under the DCO and any pull requests that are updated will need to conform to the DCO prior to merging. ### What About The Other Elements Of A CLA The CNCF CLA has provisions for some areas other than right to contribute the code. For example, there is an explicit patent grant and that the contribution is "on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND". The CNCF views elements like these as already being covered elsewhere. For example, through the code contributions being under the Apache 2 license which has patent grant and warranty clauses. ### What About Commits With Multiple Contributors If more than one person works on something it's possible for more than one person to sign off on it. For example, > An example commit message > > Signed-off-by: Some Developer > Signed-off-by: Another Developer ### If I Contribute As An Employee Does My Employer Need To Sign Anything Nope. The DCO assumes you are authorized to submit the code. This is what makes the contributor experience simpler for many people. ### What If I Forget To Sign-off On A Commit There is a DCO check, similar to the previous CLA check, that will cause the status of the pull requests to be listed as failed. This will remind everyone that the commit was not signed off. To update the last commit message with a sign off you can use the command: ``` $ git commit --amend -s ``` The `-s` flag is short for `--signoff`. If you need to amend older commit message the process is a little more detailed. [GitHub has a writeup detailing on changing commit messages](https://help.github.com/articles/changing-a-commit-message/) that deals with numerous different cases. ================================================ FILE: blog/2018-09-07-new-gov-and-elections.md ================================================ --- title: "New Governance And Elections" slug: "new-gov-and-elections" date: "2018-09-07" --- Being a top level incubating CNCF project requires having a governance structure to ensure that there is a publicly documented process for making decisions regarding the project and the community. While Helm was under Kubernetes, we relied on Kubernetes governance. As part of the transition to CNCF, the Helm project is required to have its own governance structure. To handle this we set up a [provisional governance](https://github.com/helm/community/blob/aa0586011786dfbc3993e7edd959a841241c96e3/governance/provisional-governance.md) with a goal of creating a long term one. After a few months we are happy to announce that the new governance structure has been written and approved. The gist of the new governance is that it organizes those responsible into a couple groups (org and project maintainers), spells out their responsibilities, and provides for decision making processes. You can read all the details in the [governance doc (here)](https://github.com/helm/community/blob/main/governance/governance.md). ## Two Types of Maintainers The new governance has two types of maintainers. **Project Maintainers** are those who maintain the code, documentation, websites, and so forth. There are currently several groups of maintainers for Helm core, Charts, ChartMuseum, Monocular, and Web/Docs. These are the same people who have been maintaining this work. The second type of maintainer is the **Helm Org Maintainer**. These individuals are responsible for elements such as the scope, vision, brand, code of conduct, owning security issues, finances, and other aspects of this nature. ## Next Step: Selecting Helm Org Maintainers The next step in the process is to select the initial Helm Org Maintainers. To handle this selection we are using the documented process in the governance. _Anyone who has contributed to the Helm GitHub organization can nominate one of the Project Maintainers to be a Helm Org Maintainer._ This includes the Project Maintainers of Helm core, Charts, ChartMuseum, etc. The nomination period will be open for three weeks (closing on 9/28 at 12pm PT). We wanted Helm Org Maintainers to be project maintainers so that they have shown they are vested in Helm by their actions. After that the project maintainers will vote. How that vote works will depend on the number of nominated individuals, who they work for as no one company can have a majority of members, and some other rules. To provide for a diverse representation from the projects in the initial selection of Helm Org Maintainers the selected folks will include 3 Representatives from the Helm core project, 2 Representative from the Charts project, and 2 Representatives representing another Helm project. The initial election will create a total of 7 Helm Org Maintainers. The length of their terms is open ended and how changes happen is documented in the governance. If you have questions about the process, or how to nominate someone, please use the [Helm mailing list](https://lists.cncf.io/g/cncf-helm). ================================================ FILE: blog/2018-09-25-chart-testing-intro.md ================================================ --- title: "Using the Community Chart Testing Tools Yourself" slug: "chart-testing-intro" date: "2018-09-25" --- The Helm community charts, [available as the stable and incubator repositories](https://github.com/helm/charts), have long had testing. That testing has grown and improved a significant amount in the past year; from Helm linting and testing if an application runs in a cluster to now include YAML linting, some validation on maintainers, `Chart.yaml` schema validation, tests on chart version increments, and more. These testing tools are useful for more than the community charts. They could be used in development workflows, in other testing systems, and for private charts. To make the testing more accessible we (mostly [Reinhard Nägele](https://github.com/unguiculus/)) refactored the tools into a container image that can be run outside of the community charts testing infrastructure. This new image is now available as the [Chart Testing project](https://github.com/helm/chart-testing). This project is built and maintained by the Helm Charts Maintainers, powers the community chart testing process, and is being used elsewhere. ## Example: Locally on Mac One of the easiest ways to take a look at it is to try it out locally. To aid with that, one of the [examples provided by the project shows you how to use it with Docker for Mac](https://github.com/helm/chart-testing/tree/main/examples/docker-for-mac) with the [charts repository](https://github.com/helm/charts). An easy way to try it out is to make a change to a chart and run the following command from the root of the charts directory: $ /path/to/chart-testing/examples/docker-for-mac/my_test.sh To illustrate this I added a tag in the `Chart.yaml` file of the mariadb chart without incrementing the chart version. Running the test produced the following output: Cluster "docker-for-desktop-cluster" set. Cluster "docker-for-desktop-cluster" set. Switched to context "docker-for-desktop". -------------------------------------------------------------------------------- Environment: REMOTE=k8s TARGET_BRANCH=master CHART_DIRS=stable incubator EXCLUDED_CHARTS=common CHART_REPOS=incubator=https://kubernetes-charts-incubator.storage.googleapis.com/ TIMEOUT=600 LINT_CONF=/testing/etc/lintconf.yaml CHART_YAML_SCHEMA=/testing/etc/chart_schema.yaml VALIDATE_MAINTAINERS=true GITHUB_INSTANCE=https://github.com CHECK_VERSION_INCREMENT=true -------------------------------------------------------------------------------- Charts to be installed and tested: stable/mariadb Initializing Helm client... Creating /root/.helm Creating /root/.helm/repository Creating /root/.helm/repository/cache Creating /root/.helm/repository/local Creating /root/.helm/plugins Creating /root/.helm/starters Creating /root/.helm/cache/archive Creating /root/.helm/repository/repositories.yaml Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com Adding local repo with URL: http://127.0.0.1:8879/charts $HELM_HOME has been configured at /root/.helm. Not installing Tiller due to 'client-only' flag having been set Happy Helming! "incubator" has been added to your repositories -------------------------------------------------------------------------------- Processing chart 'stable/mariadb'... -------------------------------------------------------------------------------- Validating chart 'stable/mariadb'... Checking chart 'stable/mariadb' for a version bump... Chart version on k8s/master : 5.0.3 New chart version: 5.0.3 ERROR: Chart version not ok. Needs a version bump. Linting 'stable/mariadb/Chart.yaml'... Linting 'stable/mariadb/values.yaml'... Validating Chart.yaml Validating /workdir/stable/mariadb/Chart.yaml... Validation success! 👍 Validating maintainers Verifying maintainer 'bitnami-bot'... ERROR: Chart validation failed. Building dependencies for chart 'stable/mariadb'... No requirements found in stable/mariadb/charts. Chart does not provide test values. Using defaults... Linting chart 'stable/mariadb'... ==> Linting stable/mariadb Lint OK 1 chart(s) linted, no failures -------------------------------------------------------------------------------- ✖︎ stable/mariadb -------------------------------------------------------------------------------- You'll notice the chart failed to pass testing because the version was not incremented. ## Configurable While the testing image contains defaults, it is configurable so it can be used without any association to the community charts setup. The [configuration is handled via environment variables which are documented in the README.md file](https://github.com/helm/chart-testing/blob/main/README.md#configuration). For example, if you wanted to skip checking for a version increment on the chart for every change you can set `CHECK_VERSION_INCREMENT` to `false`. This will skip that check and is useful for cases where every change to a chart is not released. ## Example: Using It with CircleCI Linting, without trying to operate the chart, is easy to incorporate into a workflow. The following is a simple example CircleCI configuration to do so: version: 2 jobs: lint-charts: docker: - image: quay.io/helmpack/chart-testing:v1.1.0 steps: - checkout - run: name: lint command: | chart_test.sh --config .testenv --no-install workflows: version: 2 lint: jobs: - lint-charts In this case the environment variables for the configuration are stored in a file name `.testenv`. This file holds the environment variables and is sourced into the environment. The following is an example from the community charts: # The name of the Git remote REMOTE=k8s # The name of the Git target branch TARGET_BRANCH=master # Chart directories separated by a space CHART_DIRS=( stable incubator ) # Charts that should be skipped EXCLUDED_CHARTS=( common ) # Additional chart repos to add (=), separated by a space CHART_REPOS=( incubator=https://kubernetes-charts-incubator.storage.googleapis.com/ ) TIMEOUT=600 ## Try It in Your Workflow This toolchain, wrapped in a container image, is meant to be used in a wide variety of workflows. Please take it for a spin, give it a try, use it in your workflows, and provide feedback. ================================================ FILE: blog/2018-10-04-helm-org-maintainers.md ================================================ --- title: "Introducing the Helm Org Maintainers" slug: "intro-helm-org-maintainers" date: "2018-10-04" --- The first major action under the [new Helm governance](https://www.helm.sh/blog/new-gov-and-elections/index.html) was to elect a set of [Helm Org Maintainers](https://github.com/helm/community/blob/52161625acabf4187ae052f4e5fdd36daea91684/governance/governance.md#helm-org-maintainers). In the initial election we were looking to select 7 people to represent Helm core, charts, and other projects under the Helm umbrella. The election is now complete and I would like to introduce the first set of Org Maintainers. In alphabetical order, by first name, they are: * Adam Reese (adamreese) * Adnan Abdulhussein (prydonius) * Josh Dolitsky (jdolitsky) * Matt Butcher (technosophos) * Matt Farina (mattfarina) * Matt Fisher (bacongobbler) * Reinhard Nägele (unguiculus) * Scott Rigby (scottrigby) * Vic Iglesias (viglesiasce) Thanks to everyone who ran. Helm is off to a great start under the CNCF and this is another step in our journey. ## What Do Org Maintainers Do? Org Maintainers are responsible for maintaining the vision, mission, values, and scope of the broader Helm project. This includes the Helm client, the charts repository, ChartMuseum, and Monocular. While the org maintainers are not responsible for the technical direction of each individual project, they take on the higher level task of keeping the organization unified. ================================================ FILE: blog/2018-12-11-helm-hub.md ================================================ --- title: "Introducing the Helm Hub" slug: "intro-helm-hub" date: "2018-12-11" --- Helm was designed with many distributed repositories in mind. Like Homebrew Taps and Debian APT repositories, Helm has the ability to add and work with many repositories. While the Helm [stable and incubator repositories](https://github.com/helm/charts) have been front and center from the beginning it was never our intent for these to be the only public repositories. With this in mind, we are delighted to announce the launch of the [Helm Hub](https://hub.helm.sh). This hub provides a means for you to find charts hosted in many distributed repositories hosted by numerous people and organizations. ![Helm Hub](https://helm.sh/img/blog/helm-hub.png) Helm repositories can be hosted in many ways including as GitHub or GitLab pages, in object storage, using [Chartmuseum](https://github.com/helm/chartmuseum), and via a service provider. If you have a chart repository you would like listed please head over to the [hub repository on GitHub](https://github.com/helm/hub) and follow the directions. The process is as simple as a pull request. The Helm Hub is powered by [Monocular](https://github.com/helm/monocular), one of the projects that has long been a part of Helm. This was originally crafted by Bitnami and Deis, now part of Microsoft. As the Helm Hub grows in complexity, Monocular will need to grow in its ability to handle many repositories and charts. This is an area where UI and UX designers looking to be part of the Helm and [CNCF](https://cncf.io) community can contribute and make a difference. We look forward to the Helm Hub ushering in a new phase of chart development and sharing. ================================================ FILE: blog/2019-01-14-chartmuseum-security-notice.md ================================================ --- title: "ChartMuseum Vulnerability: Authorization Bypass [CVE-2019-1000009]" slug: "chartmuseum-security-notice-2019" date: "2019-01-14" --- Security researcher Bernard Wagner of [Entersekt](https://www.entersekt.com/) discovered a vulnerability in ChartMuseum, impacting **all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1**. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location. When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant. Additionally, if ChartMuseum is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to. We are unaware of any public exploits caused by this issue. ## Details When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within. When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters. ## Fix Update to ChartMuseum >= 0.8.1 To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a _400 Bad Request_ response and message to signify the name issue. ================================================ FILE: blog/2019-01-14-helm-security-notice.md ================================================ --- title: "Helm Vulnerability: Client Unpacking Chart that Contains Malicious Content [CVE-2019-1000008]" slug: "helm-security-notice-2019" authors: ["mattbutcher"] date: "2019-01-14" --- Security researcher Bernard Wagner of [Entersekt](https://www.entersekt.com/) discovered a vulnerability in the Helm client, impacting **all versions of Helm between Helm >=2.0.0 and < 2.12.2**. Two Helm client commands may be coerced into unpacking unsafe content from a maliciously designed chart. A specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart’s path, potentially overwriting existing files. No version of Tiller is known to be impacted. This is a client-only issue. The following Helm commands may unsafely unpack malformed charts onto a local folder: `helm fetch --untar` and `helm lint some.tgz`. We are unaware of any public exploits caused by this issue. ## Details During unpacking operations, file names were not checked to see if they contained references to parent directories. Normally, this does not impact Helm’s operation because file names are only used as in-memory names. However, two operations were found to export files directly to disk without sanitizing the file names. The `helm lint` command may unpack a tar archive into a temporary directory, and `helm fetch --untar` will unpack an archive into a user-supplied directory. In both cases, not all file names were correctly sanitized. No Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not store unpacked charts. All charts are loaded in-memory, and paths are resolved as string names, not as locations on a file system. ## Workarounds Unpack charts with the appropriate `tar` command, and do not use the `--untar` flag on `helm fetch`. Do not run `helm lint` on tars. Unpack them manually and run `helm lint` on the unpacked directory. ## Fix Update to Helm >= 2.12.2. As of Helm 2.12.2, the unpacking operation disallows paths that could be used to store files outside of the present working directory. This is considered a bug fix, rather than a breaking change, because there is no way to produce such malformed packages from within Helm or from standard chart-building tools. From Helm 2.12.2 onward, charts that contain files that are not relative to the current working directory will fail to load, even when loaded into memory. ================================================ FILE: blog/2019-04-18-helm-summit-eu-2019.md ================================================ --- title: "Helm Summit EU 2019" slug: "helm-summit-eu-2019" authors: ["karenchu"] date: "2019-04-18" --- We're beyond excited to share that [Helm Summit EU 2019](https://events.linuxfoundation.org/events/helm-summit-2019/) is now official (h/t to [CNCF](https://cncf.io/))! Join the Helm community on September 11 - 12 in Amsterdam, The Netherlands at Pakhuis de Zwijger for our first European Helm Summit. Over the course of two days, we'll discuss all things Helm and hold tutorials, working sessions, and small group discussions with new and existing users. Interested in... * Registering? Sign up [here](https://events.linuxfoundation.org/events/helm-summit-2019/register/) before Aug 27 for Early Bird pricing of $250. Prices will go up to the Standard pricing of $300 thereafter. * CFPs? Submit a proposal for a lighting talk, presentation, or tutorial before the Friday May 31 deadline. Click [here](https://events.linuxfoundation.org/events/helm-summit-2019/program/call-for-proposals/) for details. * Sponsoring? Sponsorships are now open and in limited quantity. Please reach out to sponsor@cncf.io for the sponsorship prospectus. In the mean time, make sure to follow us on [Twitter](https://twitter.com/HelmPack) for the most up-to-date news on #HelmSummit! ================================================ FILE: blog/2019-04-22-helm-3-preview-pt1.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 1: A History of Helm" slug: "helm-3-preview-pt1" authors: ["mattfisher"] date: "2019-04-22" --- On October 15th, 2015, the project now known as Helm was born. Only one year later, the Helm community joined the Kubernetes organization as Helm 2 was fast approaching. In June 2018, the Helm community [joined the CNCF](https://www.cncf.io/blog/2018/06/01/cncf-to-host-helm/) as an incubating project. Fast forward to today, and Helm 3 is nearing its first alpha release. In this series of seven blog posts over the next four weeks, I'll provide some history on Helm's beginnings, illustrate how we got where we are today, showcase some of the new features available for the first alpha release of Helm 3, and explain how we move forward from here. In order, I'll discuss: 1. The history of the creation of Helm 2. A Gentle Farewell to Tiller 3. Chart Repositories 4. Release Management 5. Changes to Chart Dependencies 6. Library Charts 7. What’s Next? ### A History of Helm Let's get started. Part 1 of 7 of our *Helm 3 Preview: Charting Our Future* blog series is about the history of how Helm was created and evolved. #### Helm was Born Helm 1 began as an open source project created by Deis. We were a small startup company [acquired by Microsoft in the spring of 2017](https://blogs.microsoft.com/blog/2017/04/10/microsoft-acquire-deis-help-companies-innovate-containers/). Our other open source project - also called Deis - had a tool called [`deisctl`](https://github.com/deis/deis/tree/master/deisctl) that was used for (among other things) installing and operating the Deis platform on a [Fleet cluster](https://github.com/coreos/fleet). Fleet was one of the first "container orchestrator" platforms to exist at the time. In mid-2015, we decided to shift gears, and the foundation of Deis (now re-named "Deis Workflow") moved from Fleet to Kubernetes. One of the first things we had to rewrite was the installation tool, `deisctl`. We used this tool to install and manage Deis Workflow on a Fleet cluster. Modeled after package managers like Homebrew, apt, and yum, the focus of Helm 1 was to make it easy for users to package and install their applications on Kubernetes. We officially announced Helm in 2015 at the inaugural KubeCon in San Francisco. Our first attempt at Helm worked, but had its fair share of limitations. It took a set of Kubernetes manifests - sprinkled with generators as YAML front-matter - and loaded the generated results into Kubernetes. For example, to substitute a field in a YAML file, one would add the following to a manifest: ``` #helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml ``` Makes you really happy that template languages exist today, eh? For many reasons, this early Kubernetes installer required a hard-coded list of manifest files and performed only a small fixed sequence of events. It was painful enough to use that the Deis Workflow R&D team was having a tough time replatforming their product around it, but the seed of an idea was there. Our first attempt was a very successful learning opportunity: we learned that we were passionate about building pragmatic solutions that solved real day-to-day problems for our users. Learning from our past mistakes, we started designing Helm 2. #### Designing Helm 2 As 2015 wound to a close, a team from Google reached out to the Helm team. They, too, had been working on a similar tool for Kubernetes. Deployment Manager for Kubernetes was a port of an existing tool they used for Google Cloud Platform. Would we be interested, they asked, in spending a few days talking about similarities and differences? In January 2016, the Helm and Deployment Manager teams sat down in Seattle to share some ideas. We walked out with a bold plan: merge the projects to create Helm 2. Along with Deis and Google, [SkippBox](https://github.com/skippbox) joined the development team, and we started work on Helm 2. Our goal was to maintain Helm's ease of use, but add the following: - Chart templates for customization - In-cluster management for teams - A first-class chart repository - A stable and signable package format - A strong commitment to semantic versioning and retaining backward compatibility version-to-version To accomplish these goals, we added a second component to the Helm ecosystem. This in-cluster component was called Tiller, and it handled installing and managing Helm charts. Since the release of Helm 2 in 2016, Kubernetes added several major features. Role-Based Access Control (RBAC) was added and eventually replaced Attribute-Based Access Control (ABAC). Many new resource types were introduced (Deployments were still in beta at the time). Custom Resource Definitions (then called Third Party Resources, or TPRs) were invented. And most importantly, a set of best practices emerged. Throughout all of these changes, Helm continued to serve the needs of Kubernetes users. After 3 years and many new feature additions, it became a good idea to introduce some major changes to the code base so that Helm would continue to meet the needs of this evolving ecosystem. This brings us to Helm 3 -- check out our next blog post [here](https://helm.sh/blog/helm-3-preview-pt2/) where we discuss the fate of Tiller in our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-04-25-helm-3-preview-pt2.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 2: A Gentle Farewell to Tiller" slug: "helm-3-preview-pt2" authors: ["mattfisher"] date: "2019-04-25" --- This is part 2 of 7 of our *Helm 3 Preview: Charting Our Future* blog series. (Check out our previous blog post on the history of Helm [here](https://helm.sh/blog/helm-3-preview-pt1/).) During the Helm 2 development cycle, we introduced Tiller as part of our integration with Google's Deployment Manager. Tiller played an important role for teams working on a shared cluster - it made it possible for multiple different operators to interact with the same set of releases. With role-based access controls (RBAC) enabled by default in Kubernetes 1.6, locking down Tiller for use in a production scenario became more difficult to manage. Due to the vast number of possible security policies, our stance was to provide a permissive default configuration. This allowed first-time users to start experimenting with Helm and Kubernetes without having to dive headfirst into the security controls. Unfortunately, this permissive configuration could grant a user a broad range of permissions they weren't intended to have. DevOps and SREs had to learn additional operational steps when installing Tiller into a multi-tenant cluster. After hearing how community members were using Helm in certain scenarios, we found that Tiller's release management system did not need to rely upon an in-cluster operator to maintain state or act as a central hub for Helm release information. Instead, we could simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes. Tiller’s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was to completely remove Tiller. With Tiller gone, the security model for Helm is radically simplified. Helm 3 now supports all the modern security, identity, and authorization features of modern Kubernetes. Helm's permissions are evaluated using your [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Cluster administrators can restrict user permissions at whatever granularity they see fit. Releases are still recorded in-cluster, and the rest of Helm's functionality remains. Read the next blog post [here](https://helm.sh/blog/helm-3-preview-pt3/) where we discuss chart repositories in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-04-29-helm-3-preview-pt3.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 3: Chart Repositories" slug: "helm-3-preview-pt3" authors: ["mattfisher"] date: "2019-04-29" --- This is part 3 of 7 of our *Helm 3 Preview: Charting Our Future* blog series, discussing chart repositories. (Check out our previous blog post on the gentle goodbye to Tiller [here](https://helm.sh/blog/helm-3-preview-pt2/).) At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index.yaml file and some packaged charts. While there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show: - Chart Repositories have a very hard time abstracting most of the security implementations required in a production environment. Having a standard API for authentication and authorization is very important in production scenarios. - Helm’s Chart provenance tools used for signing and verifying the integrity and origin of a chart are an optional piece of the Chart publishing process. - In multi-tenant scenarios, the same Chart can be uploaded by another tenant, costing twice the storage cost to store the same content. Smarter chart repositories have been designed to handle this, but it’s not a part of the formal specification. - Using a single index file for search, metadata information, and fetching Charts has made it difficult or clunky to design around in secure multi-tenant implementations. Docker’s [Distribution project](https://github.com/docker/distribution) (also known as Docker Registry v2) is the successor to the Docker Registry project, and is the de-facto toolset to pack, ship, store, and deliver Docker images. Many major cloud vendors have a product offering of the Distribution project, and with so many vendors offering the same product, the Distribution project has benefited from many years of hardening, security best practices, and battle-testing, making it one of the most successful unsung heroes of the open source world. But did you know that the Distribution project was designed to distribute any form of content, not just container images? Thanks to the efforts of the [Open Container Initiative (or OCI for short)](https://www.opencontainers.org/), Helm Charts can be hosted on any instance of Distribution. The work is experimental, with login support and other features considered "table stakes" for Helm 3 yet to be finished, but we're very excited to learn from previous discoveries that the OCI and Distribution teams have made over the years, learning through their mentorship and guidance on what it means to run a highly available service at scale. I wrote a more detailed deep-dive on some of the [upcoming changes to Helm Chart Repositories](https://blog.bacongobbler.com/post/2019-01-25-distributing-with-distribution/) if you'd like to read more on the subject. You can check out the next blog [here](https://helm.sh/blog/helm-3-preview-pt4/) where we discuss release management in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-05-02-helm-3-preview-pt4.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 4: Release Management" slug: "helm-3-preview-pt4" authors: ["mattfisher"] date: "2019-05-02" --- This is part 4 of 7 of our *Helm 3 Preview: Charting Our Future* blog series on release management. (Check out our previous blog post on the Helm chart repositories [here](https://helm.sh/blog/helm-3-preview-pt3/.). In Helm 3, an application's state is tracked in-cluster by a pair of objects: - The release object: represents an instance of an application - The release version secret: represents an application's desired state at a particular instance of time (the release of a new version, for example) A `helm install` creates a release object and a release version secret. A `helm upgrade` requires an existing release object (which it may modify) and creates a new release version secret that contains the new values and rendered manifest. The release object contains information about a release, where a release is a particular installation of a named chart and values. This object describes the top-level metadata about a release. The release object persists for the duration of an application lifecycle, and is the owner of all release version secrets, as well as of all objects that are directly created by the Helm chart. The release version secret ties a release to a series of revisions (install, upgrades, rollbacks, delete). In Helm 2, revisions were merely incremental. `helm install` created v1, a subsequent upgrade created v2, and so on. The release and release version secret were collapsed into a single object known as a revision. Revisions were stored in the same namespace as Tiller, meaning that each release name was "globally" namespaced; as a result, only one instance of a name could be used. For Helm 3, a release has one or more release version secrets associated with it. The release object always describes the current release deployed to Kubernetes. Each release version secret describes just one version of that release. An upgrade operation, for example, will create a new release version secret, and then modify the release object to point to this new version. Rollback operations can use older release version secrets to roll back a release to a previous state. With Tiller gone, Helm 3 stores release data in the same namespace as the release's destination. This change allows one to install a chart with the same release name in another namespace, and data is persisted between cluster upgrades/reboots in etcd. You can install Wordpress into namespace "foo" as well as namespace "bar", and both releases can be referred to as "wordpress". Speaking of Charts...read the next blog [here](https://helm.sh/blog/helm-3-preview-pt5/) where we discuss changes to chart dependencies in our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-05-06-helm-3-preview-pt5.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 5: Changes to Chart Dependencies" slug: "helm-3-preview-pt5" authors: ["mattfisher"] date: "2019-05-06" --- This is part 5 of 7 of our *Helm 3 Preview: Charting Our Future* blog series about chart dependencies and some subtle differences between Helm 2 and Helm 3. (Check out our previous blog post on release management [here](https://helm.sh/blog/helm-3-preview-pt4/).) Charts that were packaged (with `helm package`) for use with Helm 2 can be installed with Helm 3, but the chart development workflow received an overhaul, so some changes are necessary to continue developing charts with Helm 3. One of the components that changed was the chart dependency management system. The Chart dependency management system moved from requirements.yaml and requirements.lock to Chart.yaml and Chart.lock, meaning that charts that relied on the `helm dependency` command will need some tweaking to work in Helm 3. Let's take a look at an example. Let's add a dependency to a chart in Helm 2 and then look at how that changed in Helm 3. In Helm 2, this is how a requirements.yaml looked: ``` dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database ``` In Helm 3, the same dependency is expressed in your Chart.yaml: ``` dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database ``` Charts are still downloaded and placed in the charts/ directory, so subcharts vendored into the charts/ directory will continue to work without modification. Click [here](https://helm.sh/blog/helm-3-preview-pt6/) to read the next blog where we introduce library charts in the next part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-05-09-helm-3-preview-pt6.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 6: Introducing Library Charts" slug: "helm-3-preview-pt6" authors: ["mattfisher"] date: "2019-05-09" --- This is part 6 of 7 of our *Helm 3 Preview: Charting Our Future* blog series on library charts. You can find our previous blog post on the Helm chart dependencies [here](https://helm.sh/blog/helm-3-preview-pt5/). Helm 3 supports a class of chart called a "library chart". This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart's templates can only declare `define` elements. Globally scoped non-define content is simply ignored. This allows users to re-use and share snippets of code that can be re-used across many charts, avoiding redundancy and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Library charts are declared in the `dependencies` directive in Chart.yaml, and are installed and managed like any other chart. ``` dependencies: - name: mylib version: 1.x.x repository: quay.io ``` We're very excited to see the use cases this feature opens up for chart developers, as well as any best practices that arise from consuming library charts. Click [here](https://helm.sh/blog/helm-3-preview-pt7/) to read the final part of our *Helm 3 Preview: Charting Our Future* blog series over the course of 4 weeks. ================================================ FILE: blog/2019-05-13-helm-3-preview-pt7.md ================================================ --- title: "Helm 3 Preview: Charting Our Future – Part 7: What's Next?" slug: "helm-3-preview-pt7" authors: ["mattfisher"] date: "2019-05-13" --- This is the seventh and final part of our *Helm 3 Preview: Charting Our Future* blog series. Read our previous blog post on library charts [here](https://helm.sh/blog/helm-3-preview-pt6/). Helm 3.0.0-alpha.1 is the foundation upon which we'll begin to build the next version of Helm. The features shared over the last few weeks were some of the big promises we made for Helm 3. Many of those features are still in their early stages and that is OK; the idea of an alpha release is to test out an idea, gather feedback from early adopters, and validate those assumptions. Once the alpha has been released, we can start accepting patches from the community for Helm 3. We should have a stable foundation on which to build and accept new features, and users should feel empowered to open tickets and contribute fixes. In this blog series, I have tried to highlight some of the big improvements coming to Helm 3, but this list is by no means exhaustive. The full plan for Helm 3 includes features such as improved upgrade strategies, deeper integrations with OCI registries, and applying JSON schemas against chart values for validation purposes. We’re also taking a moment to clean up the codebase and updating parts that have languished over the last three years. If you feel like a topic was missed, we'd love to hear your thoughts! Feel free to join the discussion in [our Slack channels](https://kubernetes.slack.com): - `#helm-users` for questions and just to hang out with the community - `#helm-dev` for discussing PRs, code, and bugs You can also join and hang out in our weekly Public Developer Calls on Thursdays at 09:30PDT. The meeting is focused on discussing what the core maintainers and the community are working on, as well as any discussion topics for the week. Anyone is welcome to join this call and participate. The link is in the `#helm-dev` Slack channel. TTFN, ta ta for now! ================================================ FILE: blog/2019-06-10-get-helm-sh.md ================================================ --- title: "Announcing get.helm.sh" slug: "get-helm-sh" authors: ["mattfisher"] date: "2019-06-10" --- The Helm Client has long been available to download from Google Cloud Storage at the bucket . This bucket in Google Cloud has been used by Helm since before Kubernetes was part of the CNCF. The first release hosted on this bucket was Helm v2.0.0-alpha.5! Google has long been gracious in providing funding for this location. Since Helm started using it, Helm (as part of Kubernetes) moved into the CNCF, and then moved out from under the Kubernetes umbrella, becoming a sister project to Kubernetes within the CNCF. The CNCF is in the process of taking over the infrastructure for Kubernetes. It was time for Helm to move from a location funded by Google to one funded by the CNCF. Google Cloud buckets cannot be transferred between projects, which meant we could not transfer the bucket over to a CNCF account. We needed to move to a new location as part of the move. ## Where are we now? The Helm project now publishes client downloads to . All Helm releases from Helm v2.0.0-alpha.5 onwards are available for download, as well as the latest Helm 3 alpha.1 release. For backwards compatibility concerns, new releases of Helm 2 will continue to be published at the old URL, however we strongly encourage users to migrate. Going forward, this is the only location where you will find Helm 3; they are not being uploaded to the old storage bucket. Helm 3.0.0-alpha.1 builds are available there now. ## What do I need to do? If you're using the old URL in your CI pipeline, you can replace with . If you're using [the get script](https://helm.sh/docs/using_helm/#from-script), it is now [pulling from the new URL](https://github.com/helm/helm/blob/2ca025d48222d6fa188653e2ca5eda6ed799145c/scripts/get#L114), so no changes on your end are required. All the download URLs in our [GitHub releases](https://github.com/helm/helm/releases) have also been changed to use the new URL. ## What's under the hood? `get.helm.sh` has three main components: 1. [Azure Blob Storage](https://azure.microsoft.com/en-ca/services/storage/blobs/) 1. [Azure CDN](https://azure.microsoft.com/en-ca/services/cdn/) 1. The domain name `get.helm.sh` In our release pipeline, Helm 2 and Helm 3 downloads are [uploaded to Azure Blob Storage](https://github.com/helm/helm/commit/022c8869bee37d02cf01507c11c6cfc6d58a1eca) (Helm 2 downloads are also [uploaded to Google Cloud Storage](https://github.com/helm/helm/commit/95775d0c60804b3d3674510e1f57a30ca8074ddd) for backwards compatibility). Azure CDN serves that content, which is fronted with a custom domain name. ## Why the new location? As part of the move, we started considering some new features the community has been asking for: ### An official helm.sh URL During this transition, we wanted to ensure that we won't disrupt users a second time, asking them to change their deployment pipelines to point to a new location. We decided to place a URL we control in front of the storage provider. This way, we do not need to ask users to switch URLs again in the future. If the underlying storage provider needs to change at some point in the future, we can have the URL point at the new location without this level of disruption going forward. ### Content delivery at the edge is fronted by [Azure CDN](https://azure.microsoft.com/en-ca/services/cdn/), a Content Delivery Network that is globally available. This should provide faster downloads to those distributed around the world, not just to those located in the Eastern United States. It also provides availability in regions that were previously unavailable, such as... ### Availability in China China is a large market for the CNCF, and therefore a large market for Helm. Google Cloud Storage is not accessible in China, so users in that region interested in using Helm have set up mirrors to work around this problem. This is an area of concern in particular around adoption: As a user, I am now relying on an unofficial mirror to fetch my downloads, which comes with a certain level of risk I would not be subject to if I were fetching from the official release page like every other user. Azure CDN [can serve content to users in China](https://docs.microsoft.com/en-us/azure/cdn/cdn-china-delivery) using point-of-presence (POP) locations near China. With Helm downloads now available in China, we are seeing just how popular Helm is in that area thanks to... ### Download metrics One of the questions that keep popping up in our minds was how users are consuming Helm on a daily basis. The core maintainers were interested in answering the following questions: - what versions of Helm are being used? - what regions of the world are using Helm today? - How long does it take for the community to migrate over to a new version of Helm? - How many users are downloading Helm 3 vs Helm 2? Our new CDN provides a rich set of metrics can provide answers to these questions. While these metrics are only available to core maintainers at this time, we are discussing how we can share these metrics with the community similar to . ## Caveat: Tiller and Chart downloads Please note that this change is only for the Helm client downloads. Tiller has not moved from Google Container Registry, and the stable and incubator Helm chart repositories are still hosted on Google Cloud. If you have any questions about this change, please let us know. More information on this change can be found under [issue #5663](https://github.com/helm/helm/issues/5663). ================================================ FILE: blog/2019-08-27-helm-v3-beta.md ================================================ --- title: "Helm v3 Beta 1 Released" slug: "helm-v3-beta" authors: ["mattfarina"] date: "2019-08-27" --- Helm v3 development has hit a new milestone with the release of the [first beta](https://github.com/helm/helm/releases/tag/v3.0.0-beta.1). This is an especially important milestone because it is the end of the effort to refactor Helm v3. The last of the _intended_ breaking changes has landed. From this point on, Helm v3 is focused on bug fixes, stability, and preparing it for a stable release. If you are interested in Helm v3 now is a great time to test it out. If you find issues please file an issue if one has not already been filed. ## Notable changes since Helm v2 * Tiller has been removed. This simplifies the experience of using Helm. There is no more need to have cluster admin privileges or to install a Tiller in every namespace. With Tiller removed, Helm now uses the settings and access defined in the local kubeconfig file. * A name is now required on install or you can use the `--generate-name` flag to have one automatically generated. This is a reverse of the Helm v2 behavior. * The `helm init` command has been removed. It performed two primary functions. First, it installed Tiller. This is no longer needed. Second, it setup directories and repositories where Helm configuration lived. This is now automated. If the directory is not present it will be created. * The Helm home directory used to be located off a users home directory. There is a standard known as the [XDG Base Directory Specification](https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) that describes a standard method to handle these directories. Helm now follows the XDG specification. * The `stable` repository is no longer added by default. This repository will be deprecated during the life of Helm v3 and we are now moving to a distributed model of repositories that can be searched by the [Helm Hub](https://hub.helm.sh). * The `helm search` command has been refactored to have sub-commands that can search the local repositories and the Helm Hub. * Release names are now scoped to namespaces. In Helm v2 the names were scoped to the namespace Tiller was running in. When Tiller was running for an entire cluster the names were scoped to the cluster. Names are now scoped to the same namespace as the release. * JSON schemas can now be imposed on chart values and bundled with the chart. The schemas can be used for validating chart values. * A new API version of charts are available. This new `apiVersion` is `v2` and contains several changes including: * Requirements are now listed in the `Chart.yaml` file instead of the `requirements.yaml` file. * A `crd` directory has been added to charts for the placement of CRDs. These will be installed before the rendering of the templates is performed. Once the Kubernetes community has worked out more workflow details with CRDs more features can be added to Helm to support them. * The `crd-install` hook has been removed and will not work for Helm v2 charts. A "legacy" plugin will be released by the Helm project to support v1 charts with the `crd-install` hook. * Experimental feature gates are now supported. As new potential features are added to Helm they can be worked on as experiments and enabled using an environment variable. * Pushing and pulling charts from OCI registries is now an experimental feature. The final details of this feature are being worked out with the OCI on the proper use of the API. To access this feature set the environment variable `HELM_EXPERIMENTAL_OCI=1` needs to be set. * `helm serve` has been removed. * Helm now supports library charts. These charts are not meant to be installed but can be depended on and referenced by other charts. These were inspired by the [common chart](https://github.com/helm/charts/tree/master/incubator/common) in the incubator repository. * `helm test` received some major refactoring. This included the `test-success` hook's behavior coming in line with other hooks and the removal of the `test-failure` hook due to lack of use. * Several CLI changes have happened for usability including: * `helm inspect` is now `helm show` * `helm fetch` is now `helm pull` * `helm delete` is now `helm uninstall` * Instead of using the `--purge` flag on `helm uninstall` the behavior is to use the `--keep-history` if you want to keep the history. ## Helm v3 Next Steps The next steps in the road to a Helm v3 stable release will be to focus on fixing bugs and stability. More beta releases or release candidates will follow before making a final `3.0.0` release. ================================================ FILE: blog/2019-09-11-migrate-from-helm-v2-to-helm-v3.md ================================================ --- title: "How to migrate from Helm v2 to Helm v3" slug: "migrate-from-helm-v2-to-helm-v3" authors: ["rimasmocevicius"] date: "2019-09-11" --- ![Diagram how to migrate from Helm 2 to 3](images/helm-2to3.png) One of the most important parts of upgrading to a new major release of Helm is the migration of data. This is especially true of Helm v2 to v3 considering the architectural changes between the releases. This is where the [helm-2to3](https://github.com/helm/helm-2to3) plugin comes in. It helps with this migration by supporting: - Migration of Helm v2 configuration. - Migration of Helm v2 releases. - Clean up Helm v2 configuration, release data and Tiller deployment. ## Setting up Helm v3 As we do not want to override Helm v2 CLI binary, we need to perform an additional step to ensure that both CLI versions can co-exist until we are ready to remove Helm v2 CLI and all it's related data: Download latest Helm v3 release from [here](https://github.com/helm/helm/releases), rename the binary to `helm3` and store it in your path. We are ready to use `helm3`: ``` $ helm3 repo list Error: no repositories to show ``` As you see there are no repositories set as Helm v3 comes without `stable` repository setup by default, let's fix it up. ## helm-2to3 plugin `helm-2to3` plugin will allow us to migrate and cleanup Helm v2 configuration and releases to Helm v3 in-place. Installed Kubernetes objects will not be modified or removed. ### Installing Let's install it: ``` $ helm3 plugin install https://github.com/helm/helm-2to3 Downloading and installing helm-2to3 v0.2.0 ... https://github.com/helm/helm-2to3/releases/download/v0.2.0/helm-2to3_0.2.0_darwin_amd64.tar.gz Installed plugin: 2to3 ``` ``` $ helm3 plugin list NAME VERSION DESCRIPTION 2to3 0.2.0 migrate and cleanup Helm v2 configuration and releases in-place to Helm v3 ``` ``` $ helm3 2to3 Migrate and Cleanup Helm v2 configuration and releases in-place to Helm v3 Usage: 2to3 [command] Available Commands: cleanup cleanup Helm v2 configuration, release data and Tiller deployment convert migrate Helm v2 release in-place to Helm v3 help Help about any command move migrate Helm v2 configuration in-place to Helm v3 Flags: -h, --help help for 2to3 Use "2to3 [command] --help" for more information about a command. ``` Awesome. ### Plugin features Currently plugin supports: - Migration of Helm v2 configuration - Migration of Helm v2 releases - Clean up Helm v2 configuration, release data and Tiller deployment ## Migrate Helm v2 configuration First we need to migrate Helm v2 config and data folders: ``` $ helm3 2to3 move config -h migrate Helm v2 configuration in-place to Helm v3 Usage: 2to3 move config [flags] Flags: --dry-run simulate a command -h, --help help for move ``` It will migrate: - Chart starters - Repositories - Plugins The safest way is to start with --dry-run flag: ``` $ helm3 2to3 move config --dry-run 2019/11/14 14:54:04 NOTE: This is in dry-run mode, the following actions will not be executed. 2019/11/14 14:54:04 Run without --dry-run to take the actions described below: 2019/11/14 14:54:04 2019/11/14 14:54:04 WARNING: Helm v3 configuration maybe overwritten during this operation. 2019/11/14 14:54:04 [Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y 2019/11/14 14:54:12 Helm v2 configuration will be moved to Helm v3 configuration. 2019/11/14 14:54:12 [Helm 2] Home directory: /Users/rimas/.helm 2019/11/14 14:54:12 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm 2019/11/14 14:54:12 [Helm 3] Data directory: /Users/rimas/Library/helm 2019/11/14 14:54:12 [Helm 3] Create config folder "/Users/rimas/Library/Preferences/helm" . 2019/11/14 14:54:12 [Helm 2] repositories file "/Users/rimas/.helm/repository/repositories.yaml" will copy to [Helm 3] config folder "/Users/rimas/Library/Preferences/helm/repositories.yaml" . 2019/11/14 14:54:12 [Helm 3] Create data folder "/Users/rimas/Library/helm" . 2019/11/14 14:54:12 [Helm 2] plugins "/Users/rimas/.helm/plugins" will copy to [Helm 3] data folder "/Users/rimas/Library/helm/plugins" . 2019/11/14 14:54:12 [Helm 2] starters "/Users/rimas/.helm/starters" will copy to [Helm 3] data folder "/Users/rimas/Library/helm/starters" . ``` Cool, now let's do the actual migration: ``` $ helm3 2to3 move config WARNING: Helm v3 configuration maybe overwritten during this operation. [Move Config/confirm] Are you sure you want to move the v2 configuration? [y/N]: y 2019/11/14 14:55:00 Helm v2 configuration will be moved to Helm v3 configuration. 2019/11/14 14:55:00 [Helm 2] Home directory: /Users/rimas/.helm 2019/11/14 14:55:00 [Helm 3] Config directory: /Users/rimas/Library/Preferences/helm 2019/11/14 14:55:00 [Helm 3] Data directory: /Users/rimas/Library/helm 2019/11/14 14:55:00 [Helm 3] Create config folder "/Users/rimas/Library/Preferences/helm" . 2019/11/14 14:55:00 [Helm 3] Config folder "/Users/rimas/Library/Preferences/helm" created. 2019/11/14 14:55:00 [Helm 2] repositories file "/Users/rimas/.helm/repository/repositories.yaml" will copy to [Helm 3] config folder "/Users/rimas/Library/Preferences/helm/repositories.yaml" . 2019/11/14 14:55:00 [Helm 2] repositories file "/Users/rimas/.helm/repository/repositories.yaml" copied successfully to [Helm 3] config folder "/Users/rimas/Library/Preferences/helm/repositories.yaml" . 2019/11/14 14:55:00 [Helm 3] Create data folder "/Users/rimas/Library/helm" . 2019/11/14 14:55:00 [Helm 3] data folder "/Users/rimas/Library/helm" created. 2019/11/14 14:55:00 [Helm 2] plugins "/Users/rimas/.helm/plugins" will copy to [Helm 3] data folder "/Users/rimas/Library/helm/plugins" . 2019/11/14 14:55:00 [Helm 2] plugins "/Users/rimas/.helm/plugins" copied successfully to [Helm 3] data folder "/Users/rimas/Library/helm/plugins" . 2019/11/14 14:55:00 [Helm 2] starters "/Users/rimas/.helm/starters" will copy to [Helm 3] data folder "/Users/rimas/Library/helm/starters" . 2019/11/14 14:55:00 [Helm 2] starters "/Users/rimas/.helm/starters" copied successfully to [Helm 3] data folder "/Users/rimas/Library/helm/starters" . 2019/11/14 14:55:00 Helm v2 configuration was moved successfully to Helm v3 configuration. ``` Now let's run `helm3 repo list` again: ``` $ helm3 repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com jfrog https://charts.jfrog.io rimusz https://charts.rimusz.net buildkite https://buildkite.github.io/charts jetstack https://charts.jetstack.io odavid https://odavid.github.io/k8s-helm-charts elastic https://helm.elastic.co appscode https://charts.appscode.com/stable $ helm3 plugin list NAME VERSION DESCRIPTION 2to3 0.1.0 migrate Helm v2 configuration and releases in-place to Helm v3 edit 0.3.0 Edit a release. gcs 0.2.0 Provides Google Cloud Storage protocol support. https://github.com/vigles... linter 0.1.1 Helm plugin to find hardcoded passwords in values.yaml files monitor 0.3.0 Query at a given interval a Prometheus, ElasticSearch or Sentry instance... ``` Nice, now I can use the same Helm repositories and plugins which I have in Helm v2. **Note:** Please check that all Helm v2 plugins work fine with the Helm v3, and remove plugins that do not work. The move config will create the Helm v3 `config` and `data` folders if they don't exist, and will override the `repositories.yaml` file if it does exist. The plugin also supports non default Helm v2 `home` and Helm v3 `config` and `data` folders, an example of it's use: ``` $ export HELM_V2_HOME=$HOME/.helm2 $ export HELM_V3_CONFIG=$HOME/.helm3 $ export HELM_V3_DATA=$PWD/.helm3 $ helm3 2to3 move config ``` ## Migrate Helm v2 releases Now we are ready to start migrating releases. Let's check available options: ``` $ helm3 2to3 convert -h migrate Helm v2 release in-place to Helm v3 Usage: 2to3 convert [flags] RELEASE Flags: --delete-v2-releases v2 release versions are deleted after migration. By default, the v2 release versions are retained --dry-run simulate a command -h, --help help for convert -l, --label string label to select Tiller resources by (default "OWNER=TILLER") -s, --release-storage string v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets") --release-versions-max int limit the maximum number of versions converted per release. Use 0 for no limit (default 10) -t, --tiller-ns string namespace of Tiller (default "kube-system") --tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless ``` Nice, the plugin even supports the [Tillerless Helm v2](https://github.com/rimusz/helm-tiller). Let's check out for Helm v2 releases and pick one to test out the migration: ``` $ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE postgres 1 Thu Nov 14 15:01:00 2019 DEPLOYED postgresql-7.1.0 11.5.0 postgres redis 1 Thu Nov 14 15:02:12 2019 DEPLOYED redis-9.5.4 5.0.6 redis ``` The safest way of course to start with `--dry-run` flag: ``` $ helm3 2to3 convert --dry-run postgres 2019/11/14 15:03:17 NOTE: This is in dry-run mode, the following actions will not be executed. 2019/11/14 15:03:17 Run without --dry-run to take the actions described below: 2019/11/14 15:03:17 2019/11/14 15:03:17 Release "postgres" will be converted from Helm v2 to Helm v3. 2019/11/14 15:03:17 [Helm 3] Release "postgres" will be created. 2019/11/14 15:03:17 [Helm 3] ReleaseVersion "postgres.v1" will be created. ``` Now, let's run the actual migration: ``` $ helm3 2to3 convert postgres 2019/11/14 15:03:57 Release "postgres" will be converted from Helm v2 to Helm v3. 2019/11/14 15:03:57 [Helm 3] Release "postgres" will be created. 2019/11/14 15:03:57 [Helm 3] ReleaseVersion "postgres.v1" will be created. 2019/11/14 15:03:57 [Helm 3] ReleaseVersion "postgres.v1" created. 2019/11/14 15:03:57 [Helm 3] Release "postgres" created. 2019/11/14 15:03:57 Release "postgres" was converted successfully from Helm v2 to Helm v3. 2019/11/14 15:03:57 Note: The v2 release information still remains and should be removed to avoid conflicts with the migrated v3 release. 2019/11/14 15:03:57 v2 release information should only be removed using `helm 2to3` cleanup and when all releases have been migrated over. ``` Check out whether it was successful: ``` $ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE postgres 1 Thu Nov 14 15:01:00 2019 DEPLOYED postgresql-7.1.0 11.5.0 postgres redis 1 Thu Nov 14 15:02:12 2019 DEPLOYED redis-9.5.4 5.0.6 redis $ helm3 list -n postgres NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION postgres postgres 1 2019-11-14 13:01:00.188487 +0000 UTC deployed postgresql-7.1.0 11.5.0 ``` **Note:** As we did not specify `--delete-v2-releases` flag Helm v2 `postgres` release information was left in-tact, it can be deleted with `helm3 2to3 cleanup` later on. When are you ready to move all your releases, you can automate it with running `helm list` in a loop and applying `helm3 2to3 convert RELEASE` for each Helm v2 release. If you are using Tillerless Helm v2, just add `--tiller-out-cluster` to migrate the release: ``` $ helm3 2to3 convert postgres --tiller-out-cluster ``` Very cool and simple, right :-) ## Clean up of Helm v2 data The last step is cleaning up the old data. While this is not required, we strongly recommend it. Let's check available options: ``` $ helm3 2to3 cleanup -h cleanup Helm v2 configuration, release data and Tiller deployment Usage: 2to3 cleanup [flags] Flags: --config-cleanup if set, configuration cleanup performed --dry-run simulate a command -h, --help help for cleanup -l, --label string label to select Tiller resources by (default "OWNER=TILLER") --release-cleanup if set, release data cleanup performed -s, --release-storage string v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets") --tiller-cleanup if set, Tiller cleanup performed -t, --tiller-ns string namespace of Tiller (default "kube-system") --tiller-out-cluster when Tiller is not running in the cluster e.g. Tillerless ``` It will clean: - Configuration (Helm home directory) - v2 release data - Tiller deployment And of course the safest way is to start with `--dry-run` flag: ``` $ helm3 2to3 cleanup --dry-run 2019/11/14 15:06:59 NOTE: This is in dry-run mode, the following actions will not be executed. 2019/11/14 15:06:59 Run without --dry-run to take the actions described below: 2019/11/14 15:06:59 WARNING: "Helm v2 Configuration" "Release Data" "Release Data" will be removed. This will clean up all releases managed by Helm v2. It will not be possible to restore them if you haven't made a backup of the releases. Helm v2 may not be usable afterwards. [Cleanup/confirm] Are you sure you want to cleanup Helm v2 data? [y/N]: y 2019/11/14 15:07:01 Helm v2 data will be cleaned up. 2019/11/14 15:07:01 [Helm 2] Releases will be deleted. 2019/11/14 15:07:01 [Helm 2] ReleaseVersion "postgres.v1" will be deleted. 2019/11/14 15:07:01 [Helm 2] ReleaseVersion "redis.v1" will be deleted. 2019/11/14 15:07:01 [Helm 2] Home folder "/Users/rimasm/.helm" will be deleted. ``` It will show what releases going to be deleted, Tiller service to be removed from `kube-system` namespace and Helm v2 home folder will be deleted. When you are ready to clean up Hem v2 data, just run that command without `--dry-run` flag. **NOTE:** The `cleanup` command will remove the Helm v2 Configuration, Release Data and Tiller Deployment. It cleans up all releases managed by Helm v2. It will not be possible to restore them if you haven't made a backup of the releases. Helm v2 will not be usable afterwards. If you are using Tillerless Helm v2, just add `--tiller-out-cluster` to clean up Helm v2 data. The plugin also supports non default Helm v2 `home` data folder and Tiller releases `namespace`: ``` $ export HELM_V2_HOME=$PWD/.helm2 $ helm 2to3 cleanup --tiller-ns some_namespace ``` **Happy Helm v3 sailing** ================================================ FILE: blog/2019-10-22-helm-2150-released.md ================================================ --- title: "Helm 2.15.0 Released" authors: ["mattfisher"] date: "2019-10-22" --- [Helm 2.15.0](https://github.com/helm/helm/releases/tag/v2.15.0) was released last week. The 2.15.0 release of Helm introduces several improvements to `helm test`. Several commands - `helm search`, `helm repo list`, and `helm install` - received the `--output` flag for machine-readable output. In addition to these new features (and many more!), many bugs and edge cases in Helm continue to fixed by members of the community. Several parts of the codebase have been refactored for easier maintainability, usability, and better testing. As Helm moves towards Helm 3's first release, Helm 2 is now transitioning into "maintenance mode". Helm 2.15.0 will be the final feature release for Helm 2. ## Helm 2 support plan During the transition, we want to take into account any migration issues for users. We also want to clarify what actions may occur after the support contract ends for Helm 2, so that users will not be surprised or caught off guard. For Helm 2, we will continue to accept bug fixes and fix any security issues that arise, but no new features will be accepted. All feature development will be moved over to Helm 3. 6 months after Helm 3's public release, Helm 2 will stop accepting bug fixes. Only security issues will be accepted. 12 months after Helm 3's public release, support for Helm 2 will formally end. Download links for the Helm 2 client through Google Cloud Storage, the Docker image for Tiller stored in Google Container Registry, and the Google Cloud buckets for the stable and incubator chart repositories may no longer work at any point. Client downloads through get.helm.sh will continue to work, and we will distribute a Tiller image that will be made available at an alternative location which can be updated with `helm init --tiller-image`. ## The big branch switch Ever since Helm 3's initial development, the core maintainers and the community have been pushing commits for Helm 3 to the `dev-v3` branch, and pushing commits for Helm 2 to the `master` branch. As Helm 3 now becomes the main development branch for all future work, we decided to switch the main trunk of the Helm repository over to Helm 3's development branch. With Helm 2 transitioning into maintenance mode, now was a good opportunity to switch branches over. Earlier this week, the transition was completed with no downtime. Moving forward, bug fixes for Helm 2 should target the `dev-v2` branch. Features and bug fixes for Helm 3 should target the `master` branch. ## Parting thoughts The Helm team would like to thank the community for [nearly 3 years of contributions](https://github.com/helm/helm/releases/tag/v2.0.0) and [over 5,000 commits](https://github.com/helm/helm/tree/dev-v2) towards Helm 2 since its initial release. Onwards and upwards! ================================================ FILE: blog/2019-10-30-helm-symlink-security-notice.md ================================================ --- title: "Helm Vulnerability: Client Loading and Packaging Chart Directory Containing Malicious Symlinked Content [CVE-2019-18658]" authors: ["mattfarina"] date: "2019-10-30" --- Part of the process for Helm to become a graduated CNCF project is to complete an independent and third party security audit with the results being published. As part of the audit of Helm 3 a security issue was found that also impacts Helm v2. [Cure53](https://cure53.de/) performed the audit and found the issue. More about the audit will be covered in a future post. The vulnerability found impacts **all versions of Helm between Helm >=2.0.0 and < 2.15.2**. Helm commands that deal with loading a chart as a directory or packaging a chart provide an opportunity for a maliciously designed chart to include content not intended in the chart or to execute a denial of service (DOS) on the computer performing the packaging via the use of symlinks. No version of Tiller is known to be impacted. This is a client-only issue. The following Helm commands may unsafely handle malformed charts: `helm package`, `helm install`, `helm upgrade`, and `helm dependency build`. We are unaware of any public exploits caused by this issue. ## Details Helm charts can include symlinks. This feature provides a means of symlinking chart dependencies together when stored in a filesystem. Two types of symlinks can cause vulnerabilities. 1. A symlink to a specially crafted file on the targets system. For example, a file containing sensitive information. When someone runs `helm package` this symlinked file will be copied into the archive without any notification. When the packaged file is moved elsewhere, such as to a Helm repository, the sensitive file will be sent along. 2. A symlink to a special file, such as a device driver. For example, a symlink to `/dev/urandom`. This would cause a command like `helm install` or `helm package` to continuously read from `/dev/urandom` as it tries to create the payload. No Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not load chart directories. ## Workarounds A process work around can be used to mitigate the vulnerability. Do not load chart directories or package charts whose contents you do not trust or in an environment with sensitive information. ## Fix Update to Helm >= 2.15.2. As of Helm 2.15.2, Helm will log to output all of the symlinked files referenced when packaging a chart and it will return an error while failing to load chart directories containing symlinks to irregular files (e.g., device or unix socket). ================================================ FILE: blog/2019-11-04-helm-security-audit-results.md ================================================ --- title: "Helm Security Audit Results" authors: ["mattfarina"] date: "2019-11-04" --- Today, the Helm Maintainers are proud to announce that we have successfully completed a 3rd party security audit for Helm 3. Helm has been recommended for public deployment. A security audit is part of the graduation criteria for CNCF projects. Specifically, the [graduation criteria](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc#graduation-stage) says: > Have completed an independent and third party security audit with results published of similar scope and quality as the following example (including critical vulnerabilities addressed): https://github.com/envoyproxy/envoy#security-audit and all critical vulnerabilities need to be addressed before graduation. During October, the CNCF funded [Cure53](https://cure53.de/) to perform a security audit of Helm version 3. Cure53 has performed audits of other CNCF projects including Prometheus, Envoy, Jaeger, Notary, and others. A [report from the security audit is available in the Helm community repo](https://github.com/helm/community/blob/main/security-audit/HLM-01-report.pdf). We recommend that you take a look at it for the details. The report covers their process, what they reviewed, and what they found. Their review included, but was not limited to: * The programming language used along with patterns and the use of external libraries * Access control which is different in Helm v3 than in Helm v2 due to the removal of Tiller * How logging and monitoring are handled * Unit and regression testing * Documentation, including the security contacts and process * The process for fixing security issues * The software used for signing and verification of Helm charts * Manipulation of chart files * TLS handling for communications From the Cure53 analysis there was only one noteworthy finding and it did not lead not an exploit. While the audit and issue were found to be in Helm v3 we also found the issue was present in Helm v2. Since Helm v2 has stable releases we announced a [security vulnerability](https://helm.sh/blog/2019-10-30-helm-symlink-security-notice/) and created a CVE. The [entire report](https://github.com/helm/community/blob/main/security-audit/HLM-01-report.pdf) is worth reading as no summary can do it justice. Cure53 provided a conclusion as part of their summary which reads: > To conclude, in light of the findings stemming from this CNCF-funded project, Cure53 can only state that the Helm project projects the impression of being highly mature. This verdict is driven by a number of different factors described above and essentially means that Helm can be recommended for public deployment, particularly when properly configured and secured in accordance to recommendations specified by the development team. Security audits are one of the benefits of CNCF projects and we are grateful for them and the analysis performed by Cure53. This analysis has provided some concrete areas we can work to improve and given us confidence in what we have. ================================================ FILE: blog/2019-11-11-community-management.md ================================================ --- title: "Helm Community Management" authors: ["mattfarina"] date: "2019-11-11" --- [Devstats](https://helm.devstats.cncf.io/) and stats on GitHub are able to capture many different types of contributions to an open source project. But there is one type of contribution for which we have yet to figure out a good metric, and it has been essential for Helm's success. That is community management. Karen Chu has handled community management for Helm since the project was first announced at the inaugural KubeCon in San Francisco. Her work ranges from big things, like planning and executing two Helm Summits, down to smaller (but still essential) things like managing the [Helm twitter account](https://twitter.com/HelmPack). Until this point, Karen's role has been pseudo-official. There has been no Helm related title or sub-project of Helm for this work. We are happy to announce that we have now rectified the situation by formalizing community management as a sub-project of Helm with Karen as the person running the show. Community managers do so much to make open source successful. Dave Neary, a community architect at Red Hat, highlighted some of the areas of value they bring in [a post about the roles filled by a community manager](https://community.redhat.com/blog/2018/01/the-many-faces-of-the-community-manager/). He talked about activities ranging from partnerships to developer enablement. We look forward to Karen's continued contributions in this space! If you want to learn more about community management, Karen is part of a panel at KubeCon + CloudNativeCon North America 2019 entitled ["What’s Essential in an OSS Project Launch Playbook?"](https://sched.co/Uabt). ================================================ FILE: blog/2019-11-13-helm-3-released.md ================================================ --- title: "Helm 3.0.0 has been released!" slug: "helm-3-released" authors: ["mattfisher"] date: "2019-11-13" --- The Helm Team is proud to announce the first stable release of Helm 3. Helm 3 is the latest major release of the CLI tool. Helm 3 builds upon the success of Helm 2, continuing to meet the needs of the evolving ecosystem. The internal implementation of Helm 3 has changed considerably from Helm 2. The most apparent change is the removal of Tiller, but it's worth checking out the other changes by diving into the new release. A rich set of new features have been added as a result of the community's input and requirements. Some features have been deprecated or refactored in ways that make them incompatible with Helm 2. Some new experimental features have also been introduced, including OCI support. Additionally, the Helm Go SDK has been refactored for general use. The goal is to share and re-use code we've open sourced with the broader Go community. We are actively looking for feedback from other engineers integrating Helm in their own projects, and would love to hear from you in the [#helm-dev Kubernetes Slack channel](https://slack.k8s.io/). Here are some Helm 3 resources: - [Documentation](https://helm.sh/docs/) - [FAQ: Changes since Helm 2](https://helm.sh/docs/faq/#changes-since-helm-2) - [Installing Helm](https://helm.sh/docs/intro/install/) - [Documentation on Helm 2 to Helm 3 migration](https://helm.sh/docs/topics/v2_v3_migration/) - [Plugin to help migrate from Helm 2 to Helm 3](https://github.com/helm/helm-2to3) - Chat with developers and contributors in the [#helm-users Kubernetes Slack channel](https://slack.k8s.io/) - Please report bugs at ## What is Helm? Helm gives teams the tools they need to collaborate when creating, installing, and managing applications inside of Kubernetes. With Helm, you can... - Find prepackaged software (charts) to install and use - Easily create and host your own packages - Install packages into any Kubernetes cluster - Query the cluster to see what packages are installed and running - Update, delete, rollback, or view the history of installed packages Helm makes it easy to run applications inside Kubernetes. ## Let's see it! Assuming you have a Kubernetes cluster running and a correctly configured `kubectl`, working with Helm is a piece of cake. Helm makes it easy to search for new charts by adding repositories hosted by the community. ```bash $ helm repo add nginx https://helm.nginx.com/stable ``` Once you've added a few repositories, you can search for charts: ```bash $ helm search repo nginx-ingress NAME CHART VERSION APP VERSION DESCRIPTION nginx/nginx-ingress 0.3.7 1.5.7 NGINX Ingress Controller ``` Helm gives you a quick way to install that chart with `helm install`: ```bash $ helm install my-ingress-controller nginx/nginx-ingress ``` If we inspect the cluster with `kubectl`: ```bash $ kubectl get deployments ``` We have an ingress controller running! We can just as easily remove it with `helm uninstall my-ingress-controller`. Okay. You've tried some charts. You've customized a few. And now you're ready to build your own. Helm makes that part easy, too. ```bash $ helm create diy Creating diy ``` Now you have a new chart named `diy`. You could go to that directory and edit it, run `helm template` to view the rendered output, or install it with `helm install`. Want to submit it upstream to the [Helm Hub](https://hub.helm.sh/)? Please do! Make sure to follow the documentation on [adding your own repositories](https://github.com/helm/hub/blob/master/Repositories.md) to the Helm Hub. ## What changed in Helm 3? You may be asking yourself at this point: > How did the workflow change from Helm 2? If I run those commands with Helm 2, will I see the same output? Helm 2 described a workflow for creating, installing, and managing charts. Helm 3 builds upon that workflow, changing the underlying infrastructure to meet the needs of the evolving ecosystem. If you're comfortable with Helm 2, you'll feel right at home with Helm 3. To learn more about what changed under the hood, [check out the FAQ](https://helm.sh/docs/faq/) in the documentation. A list of changes and explanations for the changes involved are provided there. ## The Future of Helm The core maintainers are really excited to release Helm 3.0. Helm's next phase of development will see new features targeted toward stability and enhancements to existing features. Features on the road map include: - Enhanced functionality for `helm test` - Improvements to Helm's OCI integration - Enhanced functionality for the Go client libraries ### Helm 2 Support Plan In the Helm 2.15.0 release announcement, we shared details about the future plans for Helm 2. You can read more about those plans in [the announcement post](https://helm.sh/blog/2019-10-22-helm-2150-released/). ## Relation of Helm 3 to Helm 1 and 2 In November 2015, the first version of Helm was released at the first KubeCon. Modeled on the macOS software installer [Homebrew](https://brew.sh/), Helm 1 (known by the team as "Helm Classic") was designed to help individual developers create packages of Kubernetes resources and deploy them into a cluster. A few months later (January 2016), Deis’ core Helm team joined forces with Google, Skippbox, and (shortly thereafter) Bitnami to produce a new version of Helm that shifted emphasis from individuals to teams. Along the way, we applied many of the lessons we’d learned. The result was a tool designed to not only make teamwork a central value, but also meet the needs of a burgeoning community of Kubernetes users who are installing sophisticated applications. In June 2018, Helm [joined the Cloud Native Computing Foundation](https://helm.sh/blog/helm-enters-the-cncf/). Helm 3 became a joint community effort, with core maintainers including members from Microsoft, Samsung SDS, IBM, and Blood Orange. Since the first alpha release, Helm 3 has seen contributions from 37 different members of the community, spanning across many time zones. The end result is a tool that reflects the needs of its community as those change and evolve over time. ## Conclusion We set out to build a tool that is an on-ramp to Kubernetes. We wanted to make it easier for the Kubernetes user to create, share, and run production-grade workloads. Over 500 community members have contributed code to the Helm CLI since its inception. Thousands of community members actively maintain charts on the Helm Hub. There are a countless number of active community members. This is a credit to the colossal efforts of the Kubernetes community which has transformed this project from a simple Deis installer into a power tool for all Kubernetes users. Thank you all, and see you on GitHub! - The Helm Team :heart: ================================================ FILE: blog/2019-11-15-helm-at-cloudnativecon.md ================================================ --- title: "Helm at KubeCon + CloudNativeCon NA 2019" authors: ["mattfarina"] date: "2019-11-15" --- Next week is the annual [KubeCon and CloudNativeCon in North America](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/). The Helm project and maintainers have several things going on and we wanted to invite you to them. Helm will have two maintainer track sessions that focus on an [_Introduction to Helm_](https://sched.co/UajI) and a [_Helm 3 Deep Dive_](https://sched.co/Uagg). Anyone who is new to Helm or would be interested in learning how and why they should use Helm, please consider attending the _Introduction to Helm_. If you are curious about the [recently released Helm 3](https://helm.sh/blog/helm-3-released/), the _Helm 3 Deep Dive_ is for you. Please let others know about these talks if you think they will interest them! This year also marks the first time the Helm project will have their own project specific booth! If you want to talk with the maintainers or have other questions about the project, the booth will be an excellent space to meet the people who regularly work on the project. There are several exciting Helm-centric sessions from the community this year. For example, Ricarto Rocha from CERN will be presenting [_Managing Helm Deployments with Gitops at CERN_](https://sched.co/UabD). You can check the schedule to learn about other sessions in the [official schedule](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/schedule/). Going to be at the conference the weekend before it starts? [Cloud_Native Rejekts](https://cloud-native.rejekts.io/) will be going on and Taylor Thomas, one of the Helm project maintainers, will be presenting [_Advanced Interactions with Kubernetes (As Taught by Helm)_](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-na-2019/talk/SQ9DWX/). ================================================ FILE: blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md ================================================ --- title: "COVID-19: Extending Helm v2 Bug Fixes" slug: "covid-19-extending-helm-v2-bug-fixes" date: "2020-04-03" --- As our world comes together to fight the global pandemic, the Helm maintainers want to ensure that we're doing our part to help you maintain your critical systems while they are operating at peak demand in a time where normal development and operation schedules have had to be adjusted. When Helm v3 was released in November 2019, our original commitment was that we would offer six months of Helm v2 bug fixes, which would end May 13, 2020, followed by six more months of security fixes for Helm v2. Given the expectation that current priorities require a singular focus on fighting the pandemic, we now plan to release Helm v2 bug fixes for an extra three months, until August 13th, 2020, giving Helm users more time for serving their communities' most immediate needs. We will monitor the situation to see if any additional adjustments are needed due to these circumstances. All Helm v2 support is currently still planned to end November 13th (with the window for security-only fixes now planned for three months). Join us in our [community calls, chats, mailing lists, and GitHub repositories](https://github.com/helm/community/blob/main/communication.md) if there is anything we can do to help unblock you in critical work, and stay safe! ================================================ FILE: blog/2020-04-30-celebrating-helms-cncf-graduation.md ================================================ --- title: "Celebrating Helm's CNCF Graduation" slug: "celebrating-helms-cncf-graduation" authors: ["mattbutcher"] date: "2020-04-30" --- ![images/helmgraduation.png](images/helmgraduation.png) Today we are happy to see Helm [reach the final stage of the CNCF ladder](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). Helm has moved from the incubating level to the graduated level as a [CNCF project](https://www.cncf.io/projects/), alongside Kubernetes and other select projects. Given Helm's humble beginnings as a hackathon project at Deis, a small startup, we are ecstatic to see our little baby all grown up. And we have certainly learned a lot about coding, community, and organizational politics over the last five years. But those are not the big reasons why we are celebrating Helm's graduation. Several months after Helm got started, we became a sub-project of Kubernetes itself. It was early 2016, and in short order we had gone from a side project to a viable package manager in the Kubernetes ecosystem. While Kubernetes had focused on the SRE and DevOps story, not masking complexity, Helm took a different approach. During a meeting in February of 2016, [Michelle Noorali](https://twitter.com/michellenoorali) wrote the following phrase on our whiteboard: "Zero to dopamine in five minutes." That was our Helm mantra: We saw an opportunity to make Kubernetes more approachable to newcomers. If we did things right, users could install Helm and then within minutes be installing production-grade off-the-shelf components. These days, Helm is [used by over 70% of Kubernetes users](https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf), from college students to major cloud providers. But we are most proud when we hear stories of Kubernetes newcomers getting up and running quickly because of Helm. Be that as it may, Helm's graduation marks a second distinction. Since the first commits to Helm, we called it "the package manager for Kubernetes," meaning that our overall design focus would be enabling redistribution, installation, upgrade, and deletion of bundles of Kubernetes resource definitions. Our goal was to be for Kubernetes what homebrew is to macOS, apt-get is to Debian/Ubuntu, and Chocolatey is to Windows. At the time, it seemed like a modest goal. After all, Kubernetes (at version 1.2) had very few users. But Kubernetes exploded in popularity. A few notable companies began running it in production. Then major cloud providers built hosted Kubernetes offerings. And then large enterprises known for focusing on stability rather than shininess also began using Kubernetes in earnest. This was an acid test for Helm. Could we meet the needs of hundreds of thousands of users, all with different goals and desires? It appears so. The term "graduation" confers the idea that a notable set of requirements has been completed. While we are thrilled to have a tremendous user base, CNCF publishes a list of criteria designed to test for enterprise-readiness. Stability, security, healthy governance, strong community -- these things are an absolute necessity if a large open source project is to succeed. CNCF states that [projects](https://www.cncf.io/projects/) can only graduate when they demonstrate that they are ready for the mainstream majority of users. The list of criteria for moving from incubation to graduation defines what it means to be a stable open source project. Helm took the graduation criteria to heart. Helm didn't just pass our security review, we did so with flying colors. We didn't just qualify for the [CII badge](https://bestpractices.coreinfrastructure.org/en), we scored a [198% on the certification test](https://bestpractices.coreinfrastructure.org/en/projects?q=helm%20package%20manager). While we only needed two committers from two different companies, we have many, many contributors from all over the globe. And over the years we have repeatedly demonstrated our commitment to open and fair governance. And so we stand at this milestone. We completed the last requirement for graduation: the CNCF Technical Oversight Committee (TOC) has voted by supermajority in agreement that Helm is now a top-level project. So what changes are in store for Helm in the future? Process-wise, things will remain as they already are. We will continue our unwavering commitment to stability and compatibility from major version to major version. We have begun the very earliest investigations into what Helm 4 may have in store. And we are (as always) eager to welcome new participants into our community, from helpful users who want to share their experiences through seasoned experts who wish to contribute substantial time to the upkeep of the project. Moreover, we are excited for the [CNCF's Artifact Hub](https://devclass.com/2020/03/12/cncf-starts-new-artifact-hub/) project, which we believe will truly bring together several major movements within CNCF. We are excited to continue working with CNCF's community. We would like to continue our tradition of ending our Helm articles with a huge thank-you to the tens of thousands of community members who have, in ways small and large, contributed to the success of Helm. Here's to many more years of providing that "zero to dopamine in five minutes" experience to all Kubernetes users! ================================================ FILE: blog/2020-08-13-helm-v2-deprecation-timeline.md ================================================ --- title: "Helm v2 Deprecation Timeline" slug: "helm-v2-deprecation-timeline" authors: ["bridgetkromhout"] date: "2020-08-12" --- _[with a nod to Lewis Carroll...](https://www.jabberwocky.com/carroll/walrus.html)_ “The time has come,” the maintainers said, “To talk of software fates: Of upgrades -- and shipping Helm v3 -- Of bugfixes -- and k8s --” [Helm v3 was released in November 2019](/blog/helm-3-released/), the result of ongoing community effort to evolve Helm to meet the community’s needs. With a streamlined client-only experience, a renewed focus on security, and tighter integration with Kubernetes APIs, Helm v3 continues to provide production-tested package management for Kubernetes. And as a [graduated CNCF project](/blog/celebrating-helms-cncf-graduation/), Helm is a key part of the cloud native ecosystem. We recognize that rolling out a major version change in production requires time. The Helm maintainers committed to providing bugfixes for Helm v2 until May 2020 (which they [extended to August 2020](/blog/covid-19-extending-helm-v2-bug-fixes/)) and security patches for Helm v2 until November 2020. And now the bugfix window is closing; [Helm v2.16.10](https://github.com/helm/helm/releases/tag/v2.16.10) will be the final bugfix release and 2.17.0 will follow with the [download location updated](https://github.com/helm/helm/issues/8346). ## What does this mean for Helm users? _After August 13, 2020, you will see these changes:_ - If you’re still using Helm v2, you will want to [migrate to Helm v3](/blog/migrate-from-helm-v2-to-helm-v3/) now. Helm 3.2.4 is widely used and production-ready. While largely backwards-compatible, there are specific changes you’ll want to be aware of when carrying out your migration. - Starting now, ongoing support of Helm v2 is limited to the next three months of security patches. That means we will no longer be accepting pull requests for anything but verified security issues. - The `stable` and `incubator` repos will be de-listed from the Helm Hub, [introduced in December 2018](/blog/intro-helm-hub/). Find your preferred repositories on [Helm Hub](https://hub.helm.sh) to add them to your configs, and [track the migration of charts to their new decentralized locations](https://github.com/helm/charts/issues/21103). _After November 13, 2020, you will see these changes:_ - No further Helm v2 releases (even for security patches) - No further updates to [Helm v2 documentation](https://v2.helm.sh/docs), which will remain available for the present time but may be discontinued - Existing and new issues/PRs that are v2-specific will be closed - [Transitioning Helm release and chart hosting ownership to CNCF](https://github.com/helm/community/issues/114) | | | | - | - | | To Be Removed | Replacement | | Download links for the Helm v2 client through Google Cloud Storage | Client downloads through [get.helm.sh](/blog/get-helm-sh/)| | Docker image for Tiller stored in Google Container Registry | We will distribute a Tiller image that will be [made available at an alternative location](https://github.com/helm/helm/issues/8346) which can be updated with helm init --tiller-image. | | Google Cloud buckets for the stable and incubator chart repositories | “Stable” and “incubator” repositories discontinued; https://github.com/helm/charts marked as obsolete | The community has found Helm v3 to be a vastly improved experience, and community resources like the [helm-2to3 plugin](https://github.com/helm/helm-2to3) are available to assist you in your essential migration. Please ensure that you migrate to Helm v3 before the November 13th deadline, as operating software which no longer receives security patches is a risk best avoided. We want to take this moment to thank everyone in the community who has used Helm or contributed an issue or pull request to help improve it. Many great ideas that don’t fit into Helm itself have much success as [related ecosystem projects](/community/related). Every time you submit updates to the docs, you’re helping others get started and be more effective with Helm. Thank you all! ================================================ FILE: blog/2020-10-07-helm-hub-moving-artifact-hub.md ================================================ --- title: "Helm Hub Moving To Artifact Hub" slug: "helm-hub-moving-to-artifact-hub" authors: ["mattfarina"] date: "2020-10-07" --- Today, we are happy to announce that the Helm Hub is moving to the [Artifact Hub](https://artifacthub.io/). That means, when you go to the Helm Hub you will be redirected to the Artifact Hub. ## What This Means For You If you search the Helm Hub or list your charts in the Helm Hub you might wonder, what does this mean for me? The Artifact Hub lists all of the same charts the Helm Hub has listed. It provides search that is faster and includes [faceted search](https://en.wikipedia.org/wiki/Faceted_search). You should be able to discover charts in a similar way to what you did before. Searching continues to work with the Helm CLI, as well. There is more in the Artifact Hub than just searching for charts. You can get notifications via email or web hook when a chart is updated. You can find other artifacts and see related artifacts. The Artifact Hub provides more than the Helm Hub did. If you listed your chart repositories in the Helm Hub and didn't already have them listed in the Artifact Hub, they were automatically brought over. The Artifact Hub provides a means to claim your repository as well as list new ones. When listing a repository you can connect it to a user account or a multi-user organization. ## Why We Are Doing This The Helm Hub was built on the Monocular project. This project was built to handle a limited number of Helm repositories and was designed for a slightly different use case than a public listing of as many chart repositories as possible. It served the Helm project well but has begun to show some limitations as the number of Helm charts and repositories grew. We knew we needed to do something about this problem with the Helm Hub. The Artifact Hub came along as we were starting to experience growth issues. Instead of operating our own instance of the Artifact Hub or writing our own software to handle the scaling issues, we are deferring to the Artifact Hub to handle chart discovery and management. The Artifact Hub supports and promotes more of the CNCF ecosystem than just charts. ## Questions, Concerns, or Issues If you experience issues with the changeover please let us know. There are a few ways you can do this: 1. If the issue is claiming your chart repository on the Artifact Hub from the migration, please file an issue on the [Helm Hub repository](https://github.com/helm/hub). 2. Experiencing a problem with the Artifact Hub site, then you can file an issue with the [Artifact Hub project](https://github.com/artifacthub/hub). It is a CNCF project and open source. 3. Having problems using the Helm CLI to search the Artifact Hub? You can file an issue with [Helm](https://github.com/helm/helm). Note, URLs for charts will still begin with `hub.helm.sh`, by default, when found in search. ================================================ FILE: blog/2020-10-19-helm-turns-five.md ================================================ --- title: " Helm Turns 5, and GitHub Gives the Gift of Charts" slug: "helm-turns-five" authors: ["mattbutcher", "mattfarina"] date: "2020-10-19" --- ![Happy 5th Birthday Helm](images/happy-5th.png) Five years ago, in a hackathon at Deis (who has since been acquired by Microsoft) Helm was born. ``` commit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d Author: Matt Butcher Date: Mon Oct 19 17:43:26 2015 -0600 initial add ``` [This commit](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d) can be found on the helm-classic Git repository where the codebase for Helm v1 is located. This is the original Helm, before it merged with Deployment Manager and was folded into Kubernetes. This is where it all began. Since day one, the Helm project has relied upon GitHub for source control, pull request management, and issue tracking. As a graduated CNCF project, the Helm org now manages dozens of GitHub repositories. But when it came to hosting the packaged charts, we stored them in an object storage bucket hosted on Google Cloud. This historical decision reflects that at that time Google was one of the principal contributors to Helm. Recently, Google’s time of supporting the official Helm chart repository has come to a close. We are grateful for Google’s hosting the Helm chart repository these last few years. But this event has given us an opportunity to further integrate our chart development pipeline with GitHub. ![Hello Github Octocat!](images/octocat.png) So for today’s birthday celebration, we would like to announce that the Helm `stable` and `incubator` chart repositories will be directly hosted out of GitHub. Furthermore, GitHub Actions will power the pipeline for publishing charts. And thanks to GitHub’s blazingly fast network, chart downloads are faster than ever! We have even published official Helm GitHub Actions in the GitHub marketplace. Check out [Helm Chart Releaser](https://github.com/marketplace/actions/helm-chart-releaser) for a way to host Helm charts in GitHub. While Helm 2 is at the end of its support, we did also move the [official Tiller Docker images](https://github.com/orgs/helm/packages) to GitHub’s container registry. We are deeply appreciative of GitHub’s tooling and their support for open source projects of all sizes. Happy Birthday, Helm! ================================================ FILE: blog/2020-10-26-new-location-stable-incubator-charts.md ================================================ --- title: "New Location For Stable and Incubator Charts" slug: "new-location-stable-incubator-charts" authors: ["mattfarina"] date: "2020-10-26" --- [As previously announced](https://helm.sh/blog/helm-turns-five/), the stable and incubator repositories have moved to a new location. This post will update you on the new locations and provide directions to start using them. _**Important Note:** This does not affect the obsolescence timeline for the stable and incubator repositories that was announced in 2019. On November 13, 2020 the stable and incubator charts repository will reach the end of development and become archives. You can find that many of the charts have moved to other, community managed, repositories. You can discover these on the [Artifact Hub](https://artifacthub.io/). More information on the obsolescence will follow in future blog posts and communications._ The new location for the stable repository is https://charts.helm.sh/stable and the new location for the incubator repository is https://charts.helm.sh/incubator. If you use charts in either of these old locations below you MUST update the repositories you use before November 13, 2020. The new locations are hosted using GitHub pages. | Name | Old Location | New Location | | --------- | ------------ | ------------ | | stable | https://kubernetes-charts.storage.googleapis.com | https://charts.helm.sh/stable | | incubator | https://kubernetes-charts-incubator.storage.googleapis.com | https://charts.helm.sh/incubator | Along with the new locations, Helm v2.17.0 and v3.4.0 have been released to help you use the new location. You are encouraged to upgrade to the latest versions. ## Helm v3.4.0 Helm v3.4.0 will now detect if you have the stable and incubator repository configured with the old location and warn you that you need to update your configuration to the new location. You can do this using a single command. For example, to update the stable repository that was set with the name `stable` you can run: ``` helm repo add stable https://charts.helm.sh/stable --force-update ``` This command will also work on Helm v3 versions prior to v3.4.0. You can use it without updating to the latest Helm v3 release. In addition to that, if you try to use `helm repo add` to add one of the repositories at the old location Helm v3.4.0 and newer will fail to add the repository and warn you to use the new location. Instead of making it automatically add the new location we wanted to make people aware of the location change. If you have a reason to use one of the old locations you can use the new `--allow-deprecated-repos` flag to allow them to be used. The flag will only be useful for as long as the previous location is still operating. ## Helm v2.17.0 Helm v2 added the stable repository by default when `helm init` was run. This has led to a different solution for Helm v2, starting in v2.17.0. If you do not need the stable or local repositories, you can use the `--skip-repos` flag when running `helm init`. This is a new flag in v2.17.0. This can have some performance benefits in some use cases such as CI systems where you aren't using the stable repository. In v2.17.0, when `helm init` is run the new location is used instead of the old location. This is what will happen in CI systems that regularly run `helm init`. If you need to continue to use the old location, you can pass the new `--use-deprecated-stable-repository` flag to `helm init`. This will only work for as long as the old locations continue to operate. If you already have an old location configured for the stable or incubator repository, Helm will warn you that you need to switch to the new location. Doing this in Helm v2 is a little different from v3. You will need to use two commands. For example, to change the `stable` repository you can run: ``` helm repo rm stable helm repo add stable https://charts.helm.sh/stable ``` This command will work on Helm v2 versions prior to v2.17.0. You can use it without updating to the latest Helm v2 release. _Note: In addition to the stable and incubator repositories moving to GitHub Pages, the default location for [Tiller has moved to GitHub Container Repository (ghcr.io)](https://github.com/orgs/helm/packages/container/package/tiller). [Tiller is still available from GCR](https://gcr.io/kubernetes-helm/tiller) (its previous home). You can also get Tiller from [Docker Hub](https://hub.docker.com/r/helmpack/tiller) and [Quay](http://quay.io/helmpack/tiller). To specify a non-default location for Tiller you can use the `-i` or `--tiller-image` flag when running `helm init`._ ## Host Your Own Copy There are cases where you may control where Helm can make network calls to and you do not want Helm to make calls to GitHub pages. One option, if you need some charts from the stable or incubator repository, is to host a copy of the chart and chart versions you need in your own repository. You could host this repository with [ChartMuseum](https://github.com/helm/chartmuseum), [Harbor](https://goharbor.io/), a static web server, or another system. Scott Rigby, one of the Helm Org and Charts maintainers, has created [a script that can copy all or some of the charts and their histories](https://github.com/scottrigby/helm-adopt-package-history) (previous chart versions). This tool, and those like it, can be used to make copies of the charts you use. This can be served from an alternative location. In Helm v2, you can specify an alternative location for the stable repository when running `helm init` by using the `--stable-repo-url` flag. ================================================ FILE: blog/2020-10-30-charts-repo-deprecation.md ================================================ --- title: "Helm Chart Repository Deprecation Update" slug: "charts-repo-deprecation" authors: ["viciglesias"] date: "2020-10-30" --- Back in 2019, when the Helm v2 support timeline and end of life plan was announced, [the deprecation](https://github.com/helm/charts#deprecation-timeline) of the [helm/charts GitHub repository](https://github.com/helm/charts) was announced, as well. The primary reason for the deprecation is the significant increase in upkeep for the [repo maintainers](https://github.com/helm/charts/blob/master/OWNERS). Over the last couple of years the number of charts under maintenance increased from ~100 to 300+ causing a commensurate increase in pull requests and updates to the repo. Unfortunately, despite many efforts to automate review and maintenance tasks, the amount of time available from maintainers has not increased. When we announced the deprecation we also began to share the tools and guidance that we had used to maintain the helm/charts repo. For folks that want to host and maintain their own repositories you now have these tools available to streamline the process: - [Chart Testing](https://github.com/helm/chart-testing) provides linting and testing for PRs against your charts - [Chart Releaser](https://github.com/helm/chart-releaser) provides tooling to help you host your own chart repo with GitHub Releases and Pages used to host your artifacts - [Testing and Releasing Github Actions](https://github.com/helm?q=chart+action) to automate the tooling described above using GitHub Actions With these tools available we've enabled many charts to [migrate to their own repositories](https://github.com/helm/charts/issues/21103) for active maintenance. ## Key Dates and Recommended Actions There has been refinement to the plans and confusion/questions about what happens next, so we wanted to provide a timeline of key events and **recommended actions** moving forward: * Nov 2, 2020 - READMEs for all non-deprecated charts will get a note added, stating that they will no longer be updated * **RECOMMENDED ACTION** - If you depend on a chart in the Charts repository look for the new official location. If one does not exist, consider adopting the chart. * Nov 6, 2020 the stable and incubator charts repos will be removed from the [Artifact Hub](https://artifacthub.io/) * **RECOMMENDED ACTION** - None * Nov 13, 2020 - CI on the [helm/charts repository](https://github.com/helm/chart) will be disabled and no more Pull Requests will be accepted. * **RECOMMENDED ACTION** - For more info on the ongoing initiative to relocate charts to new repos please see [this issue](https://github.com/helm/charts/issues/21103). * *After* Nov 13, 2020 - Downloads of Charts at their old locations will be re-directed to the read-only archive available in GitHub Pages. The old locations may no longer be available after this date. * **RECOMMENDED ACTION** - See info on [switching to the archived stable and incubator charts](https://helm.sh/docs/faq/#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository). Keep in mind that these charts will no longer be updated with bug fixes or security patches. ## References * [Charts Repo Deprecation Timeline](https://github.com/helm/charts/issues/23944) * [Relocation of package history](https://github.com/helm/charts/issues/23850) * [Request to transition Helm Chart hosting to CNCF](https://github.com/helm/community/issues/114) ================================================ FILE: blog/2020-11-11-helm-release-process.md ================================================ --- title: "Helm’s First Patch Wednesday" slug: "helm-release-process" authors: ["mattfarina"] date: "2020-11-11" --- Helm recently adopted [a release schedule for minor and patch releases](https://github.com/helm/community/blob/main/hips/hip-0002.md). Today, the second Wednesday in November 2020, marks the first release under the new schedule. This release schedule provides predictability to those who use Helm, contribute to Helm, and maintain Helm. The release schedule generally follows these rules: * Patch releases happen on the 2nd Wednesday of the month when there isn't a major or minor release. This will happen if there are changes that could be released. * Minor releases will roughly align with Kubernetes releases and have three to four month development windows, as Kubernetes does. These releases will lag behind Kubernetes so that Helm can be updated and tested for any changes to Kubernetes. * When a minor version is released the next minor version will be scheduled. The date will be published to https://helm.sh/. For example, v3.5.0 is scheduled for Wednesday January 13th. Instead of a patch release that day there will be a minor release. * Security releases do not need to follow any of these rules. They will be released as needed. A calendar of upcoming dates for releases can be found on the calendar at https://helm.sh/calendar/release. This is a redirect to the calendar. More details can be found in [Helm Improvement Proposal 2](https://github.com/helm/community/blob/main/hips/hip-0002.md). ================================================ FILE: blog/2020-11-13-helm-2-becomes-unsupported.md ================================================ --- title: "Helm 2 and the Charts Project Are Now Unsupported" slug: "helm-2-becomes-unsupported" authors: ["mattbutcher"] date: "2020-11-13" --- A year ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released/), a major evolution in Helm's development. And we [announced](https://helm.sh/blog/2019-10-22-helm-2150-released/) at that time that Helm 2 would receive patches and security updates for a year. Here we are, one year later. Friday the 13th, 2020 seems like a fitting day to end support for a major version. And today, we are announcing the official end of support for Helm 2. The charts repository is also now read-only, with no further changes. From this point forward, the Helm team will devote all of its energy to Helm 3 and our ecosystem tools. In practice, this means the following: - **Helm 2** will receive no more updates (not even security patches). - The **Helm Charts** [GitHub project](https://github.com/helm/charts) will receive no more updates. - The Helm **Stable and Incubator charts** repositories have been moved to an archive. See [our blog post](https://helm.sh/blog/new-location-stable-incubator-charts/) for more. - **Helm 3** will [continue](https://github.com/helm/helm/releases) to add new features, fix bugs, and address security issues. - [Other Helm projects](https://github.com/helm) like our **GitHub actions** will continue feature development as well. - **Artifact Hub** is now the official location for [finding Helm charts](https://artifacthub.io/). We strongly discourage continued use of Helm 2, as it will be receiving no future security updates or patches. But if you need more time to migrate, we strongly encourage you to upgrade to Helm [2.17.0](https://github.com/helm/helm/releases/tag/v2.17.0), which has the final patches. For more, [check out the migration documentation](https://helm.sh/docs/topics/v2_v3_migration/). Finally, I would like to close with a heartfelt word of thanks to the dedicated people who have contributed to Helm and Charts over the years. ================================================ FILE: blog/2021-03-05-second-security-audit/index.md ================================================ --- title: "Helm 2nd Security Audit" slug: "helm-2nd-security-audit" authors: ["mattfarina"] date: "2021-03-05" --- Helm has now completed a second security audit, funded by the [CNCF](https://cncf.io). The [first audit](https://helm.sh/blog/2019-11-04-helm-security-audit-results/) focused on the source code for the Helm client along with the process Helm uses to handle security. The second audit, performed by [Trail of Bits](https://www.trailofbits.com/), looked at the source code for the Helm client along with a threat model for the use of Helm. The following diagram is from the [threat model](https://github.com/helm/community/blob/main/security-audit/Helm%20Threat%20Model%202020.pdf) and looks at the connections Helm makes along with how it stores files on the local filesystem. ![Thread model diagram](arch.png) As a result of the audit, the Helm security team worked on [a release](https://github.com/helm/helm/releases/tag/v3.3.2). We want to thank the CNCF for providing these security assessments. They provide an expert and outside look at projects, like Helm, so that we can have more security cloud native tooling. We also want to thank Trail of Bits for the assessment. It was a pleasure working with them. You can get the full reports for the [threat model](https://github.com/helm/community/blob/main/security-audit/Helm%20Threat%20Model%202020.pdf) and [security assessment](https://github.com/helm/community/blob/main/security-audit/Helm%20Final%20Report%202020.pdf) in the [Helm community repository](https://github.com/helm/community/tree/main/security-audit). ================================================ FILE: blog/2021-06-24-welcome-martin-hickey.md ================================================ --- title: "Martin Hickey Joins Helm Org Maintainers" slug: "welcome-martin-hickey" authors: ["mattbutcher"] date: "2021-06-24" --- Meet Helm's newest org maintainer: [Martin Hickey](https://hickeyma.github.io/). Martin has been a longtime Helm project maintainer. He was instrumental in the development of Helm 3, and has been one of the most active maintainers on the project. He is also one of the creators of the [Helm 2-to-3 migration plugin](https://github.com/helm/helm-2to3). This week, the Helm maintainers voted to elect Martin onto the Helm Org Maintainers board. In this new role, Martin will help shape not just Helm, but the many projects that are hosted together with Helm. As a first order of business, Martin will be migrating the [Map KubeAPIs plugin](https://github.com/hickeyma/helm-mapkubeapis) to the Helm organization. Congratulations to Martin! ================================================ FILE: blog/2022-01-11-welcome-karen-chu.md ================================================ --- title: "Karen Chu Joins Helm Org Maintainers" slug: "welcome-karen-chu" authors: ["mattbutcher"] date: "2022-01-11" --- The Helm organization is thrilled to introduce [Karen Chu](https://twitter.com/karenhchu) as the latest member of the [Helm org maintainers](https://github.com/helm/community/blob/main/governance/governance.md#helm-org-maintainers). She will be the [ninth committee member](https://github.com/helm/community/blob/main/MAINTAINERS.md). Karen has been active in the Helm ecosystem since day one when Rimas, Jack, and I first started the project. She was instrumental in Helm's early branding, organized both of the Helm Summits, and leads Helm's community management team. You may also know her from her Helm-adjacent work as the co-creator of the [Illustrated Children's Guide to Kubernetes](https://www.cncf.io/phippy/) series or her role as a CNCF ambassador. Last week, the Helm project maintainers voted to elect Karen onto the Helm org maintainers board. In this role, Karen will help shape the many projects that are hosted under the Helm umbrella, bringing her insights from the wider ecosystem to her leadership of the Helm organization. Congratulations to Karen! ================================================ FILE: blog/2022-02-28-storing-charts-in-oci.md ================================================ --- title: "Storing Helm Charts in OCI Registries" slug: "storing-charts-in-oci" authors: ["scottrigby", "joshdolitsky", "mattfarina"] date: "2022-02-28" --- With the release of Helm 3.8.0, Helm is able to store and work with charts in container registries, as an alternative to [Helm repositories](https://helm.sh/docs/topics/chart_repository/). This feature, which used to be an experimental feature, is now generally available. Over the past several years container registry developers have been working on ways to store other artifacts in container registries. To facilitate this in a cross platform manner, the Open Containers Initiative (OCI) - the organization that defines the specifications for containers - released their [distribution specification](https://specs.opencontainers.org/distribution-spec/?v=v1.0.0) which allowed other "artifacts" to be stored in registries. ## Common Storage Since OCI artifacts now makes it possible to store more than container images, you can store charts, images, and other artifacts in a single OCI registry. Sharing a common storage standard that's not specific to Helm allows greater interoperability between tools from the wider container ecosystem for security, identity and access management, and more. ## Working With Charts In Registries The combination of OCI artifact support in a registry and new functionality within Helm provides the capability to pull and push charts to and from a registry. You can also specify charts stored in OCI as a dependency in any `Chart.yaml` file. The following example illustrates logging into a registry and pushing a chart: ```text $ helm create demo Creating demo $ helm package demo Successfully packaged chart and saved it to: /tmp/demo-0.1.0.tgz $ echo "mypass" | helm registry login r.example.com -u myuser --password-stdin Login Succeeded $ helm push demo-0.1.0.tgz oci://r.example.com/myuser Pushed: r.example.com/myuser/demo:0.1.0 Digest: sha256:7ed393daf1ffc94803c08ffcbecb798fa58e786bebffbab02da5458f68d0ecb0 ``` More detail on [working with registries can be found in the Helm documentation](https://helm.sh/docs/topics/registries/). ## The Helm SDK The Helm SDK, which is useful for those building tools to integrate with Helm, also includes support to work with registries programmatically. The following example illustrates pushing a chart to a registry: ```go package main import ( "fmt" "io/ioutil" "helm.sh/helm/v3/pkg/registry" ) func check(err error) { if err != nil { panic(err) } } func main() { client, err := registry.NewClient() check(err) b, err := ioutil.ReadFile("demo-0.1.0.tgz") check(err) info, err := client.Push(b, "r.example.com/myuser/demo:0.1.0") check(err) fmt.Printf("Pushed: %s\n", info.Ref) fmt.Printf("Digest: %s\n", info.Manifest.Digest) } ``` More detail can be found in the [documentation for the registry package](https://pkg.go.dev/helm.sh/helm/v3/pkg/registry). ## Limitations There are some limitations when using registries to store charts compared to Helm repositories or storing container images in registries. Helm repositores can be added and searched from the local Helm client. This is similar to how repositories work with other package managers such as zypper or apt. When working with OCI registries, this is not an option. OCI based registries don't provide standard APIs to facilitate searching. While the OCI specification provides support for artifacts, not all registries support storing Helm charts or other artifacts that are not container images. Before choosing a registry, you should confirm whether it supports storing Helm charts. ## Artifact Hub Support [Artifact Hub](https://artifacthub.io/), another CNCF project, provides a means to search and discover cloud native assets, including charts. Helm charts stored in OCI based registries can be listed on Artifact Hub, which already knows how to work with them. More details on working with Artifact Hub and Helm charts in container registries can be found in their [documentation](https://artifacthub.io/docs/topics/repositories/#helm-charts-repositories). ## ORAS The [OCI Registry as Storage (ORAS) project](https://oras.land/), another CNCF project, is used by Helm as the underlying library for working with registries. The ORAS project bills itself as: > Registries are evolving as generic artifact stores. To enable this goal, the ORAS project provides a way to push and pull OCI Artifacts to and from OCI Registries. If you want to work with other artifacts in registries the ORAS project may provide some tools to help you. ## Thanks and Help Us Keep Improving Thanks to everyone who worked on adding support for Helm charts and OCI registries, from the initial experiment to bringing this to a full feature. Thanks especially for end user testing, bug reports and feature requests, and coordination between community members and maintainers across several CNCF projects. We hope this post helps give a good intro, and some things to consider when evaluating storing your Helm charts in OCI. See if it fits your needs, take it for a spin, and let us know what you think! ================================================ FILE: blog/2022-04-19-tools-to-manage-helm-declaratively.md ================================================ --- title: "Tools You Can Use To Manage Your Helm Releases Declaratively" slug: "tools-to-manage-helm-declaratively" authors: ["scottrigby", "mattfarina"] date: "2022-04-19" --- We regularly get questions from people who want tools or methods to manage their Helm releases in an environment. This post provides some insight and direction to help people get started. ## Why Helm Doesn't Have Tools To Do This You might wonder, why doesn't Helm provide tools to do this out of the box? Helm is a package manager. We often compare it to package managers for other platforms like apt, yum, zipper, homebrew, and others. All of these projects, Helm included, keep their scope within the realm of package management. Managing how instances of packages are run in an environment is a separate concern and one people have varying ideas about. For example, some people use Ansible, others use Terraform, some use both, and some use something entirely different. Different tools can even use different methods (e.g. some are push based and others pull based). _All of these are able work with the same package managers._ The Helm project strives to provide a package manager that works well with various other tools that can use a variety of different methods to manage releases. ## Declarative and Imperative In the Kubernetes space we talk about _declarative_ management. If you're not familiar with the concept, here is a brief explanation. With declarative management you _declare_ to the _system_ what you want the end state to look like. For example, that you want X number of instances of your workload to be running. The system then works to make this a reality and usually reports status on the progress of making the declared status a reality. Over time, the way the system makes the declared state a reality can change without the need for what you declare or the status of the progress to change. Imperative management has to do with telling the system what to do step by step. Instead of declaring what you want you tell the system each step to take to achieve the end goal. Kubernetes provides a means to do both [declarative and imperative management of resources](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/). As the Kubernetes community tends to prefer declarative management, when possible, the rest of this post is going to focus on declarative tools you can use with Helm. ## Tools The Kubernetes ecosystem has produced numerous projects of various styles to help you declaratively manage your Helm releases. To illustrate the options we will look at sister projects to Helm in the Cloud Native Computing Foundation (CNCF) and some more general open source projects. You can find more options in the [CNCF Landscape](https://landscape.cncf.io/). ### CNCF Projects The scope of this section is limited to [graduated and incubating](https://www.cncf.io/projects/) CNCF projects. There are over 100 CNCF projects and many of them are [sandbox projects](https://www.cncf.io/sandbox-projects/). You can learn more about the differences between types of projects in the [maturity level explanation](https://www.cncf.io/projects/#maturity-levels). The following projects are worth looking at: * [Flux Helm Controller](https://fluxcd.io/docs/components/helm/) - [Flux](https://fluxcd.io/) is a collection of projects that enable GitOps. One of the components provides a GitOps method to manage Helm releases. Flux natively supports Helm. * [Argo CD](https://github.com/argoproj/argo-cd) - The [Argo](https://argoproj.github.io/) project defines itself as providing "Open source tools for Kubernetes to run workflows, manage clusters, and do GitOps right." Argo CD is focused on declarative continuous delivery and has the ability to work with Helm charts. ### Other Projects There are many projects beyond the CNCF projects you can use to help you manage your Helm releases. The following set is an example and not exhaustive. * [Helmfile](https://github.com/helmfile/helmfile) - A declarative spec for deploying Helm charts. * [Captain](https://github.com/alauda/captain) - A Helm controller. * [Terraform Helm provider](https://github.com/hashicorp/terraform-provider-helm) - Enables you to manage Helm charts through Terraform. * [Orkestra](https://azure.github.io/orkestra/) - Built on other tools in this list, Orkestra adds a robust dependency graph for a related group of Helm releases and their subcharts, as well as a reverse DAG for specifying dependency requirements for rollbacks. * [Fleet](https://github.com/rancher/fleet) - A GitOps tool chain that works with Kubernetes manifests, Helm charts, and Kustomize. ### High-Level Tool Comparison There are some differences between the tools we've looked at so far. The following table provides some insight into their differences. This is not exhaustive and you should evaluate any tools you use yourself. | | Retains Helm release info | Supports Helm hooks | OCI support | Does not require Helm binary | | -- | -- | -- | -- | -- | | Flux Helm controller | ✅ | ✅ | 🚫[^1] | ✅ | | Argo CD | 🚫 | :warning:[^2] | ✅[^3] | 🚫 | | Helmfile | ✅ | :warning:[^4] | :warning:[^5] | 🚫[^6] | | Captain | ✅ | ✅ | :warning:[^7] | ✅ | | Terraform Helm provider | ✅ | :warning:[^8] | ✅ | ✅ | | Orkestra | ✅ | ✅ | 🚫[^9] | ✅ | | Fleet | ✅ | ✅ | 🚫[^10] | ✅ | _Note, this comparison is from when the blog post was published. Projects change over time and the feature set may change over time. You should evaluate the projects in their current state before choosing one._ ## Conclusion If you want to use a configuration manager with your Helm and Kubernetes configuration there are many choices. While the Helm project doesn't endorse one project over another, we do suggest using a configuration manager when it's appropriate. [^1]: Because Flux makes full use of the Helm SDK, as of Helm v3.8.0 Flux is now unblocked to add OCI artifact integration (Flux team members helped finish bringing OCI support out of experimental into a full feature in Helm). [RFC-0002](https://github.com/fluxcd/flux2/tree/main/rfcs/0002-helm-oci) is now marked as implementable, and work on this is now in progress for Flux. You can follow this fluxcd/source-controller issue [#669](https://github.com/fluxcd/source-controller/issues/669) for progress. [^2]: Because Argo does not retain Helm release information, there is an [attempt to map](https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-hooks) Helm hooks to ArgoCD hooks, however, there are far fewer Argo hooks and unmappable concepts such as no differentiation between install and upgrade. You can work around this by writing your charts specifically for ArgoCD, however hooks in commonly used community charts will not work. [^3]: ArgoCD shells out to the Helm CLI, only to render templates. This has allowed Argo to turn on Helm CLI's OCI feature before it was finished, for the same reason that it can not support Helm features beyond templating. Because of this, OCI is not part of the ArgoCD source architecture. [^4]: Helmfile has a custom concept of hooks, not necessarily mapped to Helm hooks. See readme [hooks section](https://github.com/helmfile/helmfile#hooks) and [this issue](https://github.com/roboll/helmfile/issues/1291) for clarification and work in progress. [^5]: Helmfile has experimental OCI support, without explicitly explaining to users that it sets `HELM_EXPERIMENTAL_OCI=1` before shelling out to the Helm CLI. See [#2112](https://github.com/roboll/helmfile/issues/2112) and [#2111](https://github.com/roboll/helmfile/issues/2111). [^6]: Helmfile parameterizes the Helm binary (default: `helm`). [^7]: Captain relies on a related project [alauda/oci-chartrepo](https://github.com/alauda/oci-chartrepo) to mix concepts of using oci registry as helm chart repo. [^8]: Terraform Helm provider has [some issues](https://github.com/hashicorp/terraform-provider-helm/issues/683) with Helm hooks and wait configurations. [^9]: Orkestra leverages Flux Helm Controller to reconcile the releases. See the note above about Flux Helm controller OCI status. Once a full implementation is released in Flux, Orkestra will also support OCI. [^10]: Fleet uses the Helm SDK. Once it uses a version of the Helm SDK that supports OCI registries, Fleet will inherit support. ================================================ FILE: blog/2022-10-14-helm-at-kubecon-na-22.md ================================================ --- title: "Helm @ KubeCon + CloudNativeCon NA '22" slug: "helm-at-kubecon-na-22" authors: ["karenchu"] date: "2022-10-14" --- The Helm maintainers are excited to be headed to KubeCon + CloudNativeCon NA '22 in Detroit, MI in a couple of weeks! As always, there will be a few different places you can find us! ## Helm Maintainer Track Talk: [Learn about Helm and Its Ecosystem](https://sched.co/182Ns) DATE: Thursday October 27 TIME: 11:00am - 11:35am EDT LOCATION: Room 410 A Maintainers [Matt Farina](https://twitter.com/mattfarina), [Karena Angell](https://twitter.com/karenaangell), [Scott Rigby](https://twitter.com/r6by), & [Andrew Block](https://twitter.com/sabre1041) will be doing a [Maintainer Track talk](https://sched.co/182Ns) introducing Helm itself and then doing a deep dive into the ecosystem around building packages, along with using Helm packages in clusters. ## Helm Booth in Project Pavilion WED OCT 26: 15:30 – 20:00 ET THUR OCT 27: 14:00 – 17:30 ET FRI Oct 28: 13:00 – 16:00 ET LOCATION: opposite side of the Fuzz booth, near the LitmusChaos/Flux/Cortex/Falco booths Our maintainers will be hanging out at our Helm project booth the second half of each day. We'd love to learn from the community how Helm is being used, what pain points exists, and what users are looking for in the future. Help us help you by sharing your thoughts in our [Helm User Survey](https://docs.google.com/forms/d/e/1FAIpQLSeR9fSlWShh49_URhAEPA88JVjlPiz1441CA1B2ySJGZg1dzQ/viewform), even if you're unable to drop by the booth. Now for the fun part – the Helm booth will be giving away 3D Helm stickers, glow-in-the-dark Helm stickers, Helm bike bells, or limited edition Helm + Carhartt beanies to stay warm while in Detroit! With that, we'll see the Helm community soon in-person! ================================================ FILE: blog/2022-11-14-welcome-yxxhero.md ================================================ --- title: "Helm welcomes yxxhero as our newest helm-www repo maintainer" slug: "welcome-yxxhero" authors: ["karenchu"] date: "2022-11-14" --- The Helm project is happy to welcome [yxxhero](https://github.com/yxxhero) as our newest maintainer for the helm-www repo! yxxhero has been a long time contributor to the Helm project over the years. With a supermajority vote from the existing maintainers, yxxhero will be joining to help with Helm documentation. With their background, yxxhero will continue to help strengthen both our simplified and traditional Chinese docs. Cheers to yxxhero! ================================================ FILE: blog/2023-03-31-helm-completes-fuzzing-security-audit.md ================================================ --- title: "Helm Completes Fuzzing Security Audit" slug: "helm-completes-fuzzing-security-audit" authors: ["adamkorczynski", "davidkorczynski", "martinhickey"] date: "2023-03-31 15:00:00" --- In the past year, the team at [Ada Logics](https://adalogics.com) has worked on integrating continuous fuzzing into the [Helm core project](https://github.com/helm/helm). This was an effort focused on improving the security posture of Helm and ensuring a continued good experience for Helm users. The fuzzing integration involved enrolling Helm in the [OSS-Fuzz project](https://github.com/cncf/cncf-fuzzing) and writing a set of fuzzers that further enriches the test coverage of Helm. In total, 38 fuzzers were written, and nine bugs were found (with eight fixed so far), demonstrating the work’s value for Helm both short term and long term. All fuzzers were implemented by way of [Go-fuzz](https://github.com/dvyukov/go-fuzz) and are run daily by OSS-Fuzz against the latest Helm commit to make sure Helm is continuously fuzz tested. The full report of the engagement can be found [here](https://github.com/helm/community/tree/main/security-audit/FUZZING_AUDIT_2022.pdf). [Helm](https://helm.sh) is described as the Kubernetes package manager. It helps simplify finding, sharing, and using software built for Kubernetes. Helm began as what is now known as [Helm Classic](https://github.com/helm/helm-classic), a Deis project begun in 2015 and introduced at the inaugural KubeCon. In January of 2016, the project merged with a GCS tool called Kubernetes Deployment Manager, and the project was moved under Kubernetes. Helm was promoted from a Kubernetes subproject to a full-fledged CNCF project in June 2018. Helm [graduated as a CNCF project in April 2020](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). [The CNCF annual survey of 2022](https://www.cncf.io/reports/cncf-annual-survey-2021) found that around 90% of companies are either using or evaluating Kubernetes, and Helm’s performance and security are important, for the continued business operations of these users. ## What is fuzzing? [Fuzzing](https://en.wikipedia.org/wiki/Fuzzing) is a technique for testing software for bugs and vulnerabilities by passing it pseudo-random data. The key idea is to write a fuzzing harness similar to a unit — or integration — test that will execute the application under test with some arbitrary input. The fuzzing engine that will run the fuzzing harness uses mutational algorithms to generate new inputs - also called "testcases" - that will cause the code under test to execute uniquely, i.e., generate inputs that trigger new code execution paths. The goal is then to observe if the code under test misbehaves in the event of any of the generated inputs. Fuzzing has been effective in uncovering reliability bugs and vulnerabilities in software for more than two decades, and open source software is increasingly adopting the technique. ## Helm fuzzing overview In this engagement, the goal was to write a set of fuzzers that would cover a lot of the Helm codebase and integrate the setup into the open source fuzzing service OSS-Fuzz. OSS-Fuzz is a free service offered by Google for critical open source projects to run their fuzzers continuously and report any crashes. Continuous analysis is important due to fuzzing relying on genetic algorithms, which effectively means the fuzzers will improve over time, and OSS-Fuzz will run the fuzzers daily indefinitely. In addition to this, continuous analysis is crucial for capturing any regressions. Helm is written in the Go programming language, making it safe from memory-corruptions. Fuzzing Go will find panics such as slice/index out of range, nil-pointer dereferences, invalid type assertions, timeouts, and out of memory. At the end of this engagement, nine issues were found, all but one of which were fixed. Refer to the report for a detailed breakdown of the issues. At the end of this engagement, the fuzzers provide significant coverage of the Helm project, including critical parts such as chart handling, release storage, and repositories. To write these fuzzers, Ada Logics used [go-fuzz-headers](https://github.com/AdaLogics/go-fuzz-headers) to deterministically create pseudo-random structs from the data provided by libFuzzer. ## Closing thoughts The Helm team is thankful to CNCF for providing the opportunity to work with Ada Logics to develop new fuzzers for Helm. The CNCF takes security seriously, and it previously funded two third-party security audits for the Helm project, [source code for the Helm client along with the process Helm uses to handle security](https://helm.sh/blog/2019-11-04-helm-security-audit-results/) and [source code for the Helm client along with a threat model for the use of Helm](https://helm.sh/blog/helm-2nd-security-audit/). We want to thank the following Helm maintainers who participated in this endeavour and provided fixes where required: [Matt Butcher](https://github.com/technosophos), [Martin Hickey](https://github.com/hickeyma), [Matt Farina](https://github.com/mattfarina) and [Scott Rigby](https://github.com/scottrigby). We would also like to mention and thank the Flux maintainers, especially [Paulo Gomes](https://github.com/pjbgf) for collaborating on an issue. The fuzzing findings and fixes are valuable add-ons to the previous conclusions of the security audits. The Helm project has efficient test suites, and code changes are backed by tests, but the newly developed fuzzers and findings have provided significant value to the project. During the fuzzing, only nine issues were found, which revalidated the high quality of the Helm code. The Helm team can now maintain the newly developed fuzzers and build on them to continue code quality and security. ================================================ FILE: blog/2023-05-15-helm-oci-mediatypes.md ================================================ --- title: "The Helm OCI MediaTypes" slug: "helm-oci-mediatypes" authors: ["andrewblock"] date: "2023-05-15" --- Helm introduced full support for storing charts within OCI registries as a distribution method beginning in version 3.8, and while this feature has been available for some time now, there is more underneath the hood than one may realize to make this capability all possible. A number of concepts, working in unison, make it possible to store content aside from traditional container images within OCI registries. This article will explore one of these important concepts, Media Types, their purpose, and how Helm’s own set of Media Types make it possible to extend the storage of charts beyond standard chart repositories to OCI registries. ## OCI Artifacts Even though the majority of content stored within OCI registries are container images, additional content types can also be stored. The [Open Container Initiative (OCI)](https://opencontainers.org) defines these other assets as “Artifacts” and the ability to make use of OCI registries to store arbitrary content types has fundamentally changed how content is distributed. Instead of requiring a separate repository management tool for each type of asset, the very same registry that is already present to house container images can be reused without requiring additional software or infrastructure resources. This not only simplifies operational concerns from a hosting perspective, but provides a more uniform method of distributing content. Helm has taken full advantage of the benefits of storing charts as OCI artifacts as it not only eliminates the complexity of managing a traditional chart repository, but simplifies the amount of resources that need to be maintained. When using a chart repository as a distribution and hosting solution, multiple assets need to be maintained: * The packaged chart * An optional provenance file * A repository index file Producing a Helm chart that is stored as an OCI artifact results in an asset with all of the necessary content packaged as a single atomic unit. The structure of the OCI artifact consists of the following three (3) key resources: * An OCI Image Config containing the contents of the Chart.yaml file * The packaged chart within an Image Layer * The provenance file (when included) as an Image Layer The composition of an OCI Helm Chart and the relationship of each of the aforementioned resources can be seen by inspecting the associated OCI Image Manifest. An example is displayed below: ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` This cross-section illustrates not only the components of an OCI based Helm Chart, but OCI based content in general. Each resource, whether it be a layer or a Config Manifest contain the same sets of properties within the Image Manifest. * Size – Content size * Digest – Content addressable reference signifying the algorithm and hash used * Media Type – Media Type of the referenced content The Media Type property is arguably the most significant property given the purpose of this discussion. Now that we see where they are referenced within OCI Artifacts, let’s review Media Types in further detail. ## Media Types and Their Significance Media Types, previously known as MIME (Multipurpose Internet Mail Extensions) Types have been around since the early days of the World Wide Web era as they identify file formats and content transmitted through the internet. Their structure consists of two concise sections separated by a slash (/): types and subtypes. Only a limited number of types are defined (10 in total) as they represent a broad use of the type itself. Subtypes are much more diverse and they are organized into a tree structure to enable a hierarchy of related types. A common Media Type that anyone who has experience with RESTful based communication is familiar with is `application/json` as it is used to indicate that the content being transmitted is in JSON format. By indicating a Media Type whenever content is being transferred, the format and its representation is understood by both producers and consumers. The OCI Image Specification contains several Media Types that represent the various structural elements of an image. These include: * `application/vnd.oci.image.index.v1+json` - Index Image * `application/vnd.oci.image.manifest.v1+json` - Image Manifest * `application/vnd.oci.image.layer.v1.tar+gzip` - gzip compressed Layer These provide a concrete example to aid in understanding the structural composition of a Media Type. Each of these fall within the `application` type as they are utilized by specific applications. The subtree here can be broken down into the following components: * `vnd` - The vendor tree which are associated with specific products * `oci` - The organization or company responsible * `image` - A short name for the type * `index/manifest/layer` - an optional subcomponent of the type * `v1` - enables the versioning of the schema * `json/tar+gzip` - Optional format signifier A more detailed description of the composition of a Media Type can be found [here](https://github.com/opencontainers/artifacts/blob/main/artifact-authors.md#defining-a-unique-artifact-type). ## Helm Media Types The Helm community has worked with the IANA to register three new Media Types representing each of the components comprising an OCI based Helm Chart. * [application/vnd.cncf.helm.config.v1+json](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.config.v1+json) * [application/vnd.cncf.helm.chart.content.v1.tar+gzip](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.content.v1.tar+gzip) * [application/vnd.cncf.helm.chart.provenance.v1.prov](https://www.iana.org/assignments/media-types/application/vnd.cncf.helm.chart.provenance.v1.prov) Similar to the OCI Media Types shown in the prior section, the Helm Media Types are also located within the vendor tree and use the abbreviation for the Cloud Native Computing Foundation (cncf) as the responsible organization. The remainder of the Media Type subtree is fairly self explanatory as it provides additional distinction to the type of content itself and the format. Anyone inspecting a resource within an OCI registry representing a Helm chart would be able to easily identify it as a Helm chart and understand how to interact with the content. For those interested in learning more about the Helm Media Types, including the low level technical details, can view the registration details within IANA which provides a wealth of information including the intended use and lower level data specification. Helm is certainly not alone in the use of OCI artifacts as a distribution method. Other prominent technologies, including Web Assembly (WASM) and Software Bill of Materials (SBOM’s), also leverage OCI artifacts. It is safe to say that we will see the continued adoption of OCI artifacts as a method of storing content by more and more projects and technologies moving forward. ## The Future for Helm’s OCI Media Types As anyone who has worked in software development, especially with regards to large, complex projects, can relate to the amount of time it takes for features to be implemented. Work surrounding OCI integration was originally introduced back in Helm version 3.5 and how OCI artifacts in general are stored and managed have evolved since that time. The OCI version 1.1 image specification provides not only additional structure, but guidance on how to manage OCI artifacts. As this specification is not only finalized, but adopted and implemented by registry providers, we will continue to see an increased adoption of the technology. The Helm project and community will continue to evolve with the rest of the industry so that Chart producers and consumers have not only the best experience possible, but can best leverage the available technology. ================================================ FILE: blog/2023-09-29-helm-3.13.md ================================================ --- title: "Helm 3.13" slug: "helm-3.13" authors: ["mattfarina"] date: "2023-09-29" --- Helm 3.13 brings some significant and useful changes for Helm users. This ranges from longtime bugs being fixed to some new features that can have an impact on performance. ## Dry-run & Template Can Connect To Servers The dry-run feature on install and upgrade, and Helm template has not been able to communicate with Kubernetes servers. This is for security and because Helm template was designed for template rendering alone. With Helm 3.13, there is now an opt-in option to communicate with Kubernetes by setting `--dry-run=server`. This tells Helm to communicate with the server for gathering information but not to perform updates. This flag also works on `helm template`. If you use `--dry-run` without setting a value it works as it did before. Helm SDK users will find a new property, named `DryRunOption`, that allows you to tell the SDK to communicate with the server. ## Values Handling Improvements Values handling has had a number of bugs filed about it. For example, importing values was inconsistent. Some of the handling even depended on ordering. Using `null` to remove properties was inconsistent, too. It worked in some cases but not others. That's fixed in Helm 3.13. The order you can expect for a value to be used is: 1. User specified values (e.g CLI) 2. Imported values from dependencies 3. Parent chart values 4. Sub-chart values ## JSON Indexes Helm repositories have an index in YAML containing details about the charts and versions of charts it contains. When this file grows large it can be expensive (e.g., processing time and memory) to parse. This is in part because YAML has anchors and aliases which are handy but cause more work to deal with. Those `index.yaml` files can now contain JSON instead of YAML. Helm will generate them when the `--json` flag is set. The `index.yaml` file is used so the same file location can continue to be used for backwards compatibility. The structure for the data is the same. Helm going all the way back to 3.0.0 can handle parsing `index.yaml` files with JSON instead of YAML. Tests were run on very large indexes to look at the perform difference. The results found that: - Helm 3 versions before 3.13: - Parsed JSON in ~80% the time of parsing YAML - Used ~93% the memory parsing JSON compared to YAML - Helm 3.13+, with special case handling to detect and handle JSON: - Parsed JSON in ~13% the time of parsing YAML - Used ~5% the memory parsing JSON compared to YAML ## Get Metadata Command `helm get` provides the ability to get information about a release in a cluster. It has been able to get values, notes, hooks, and the generated manifests. In addition to those it can now get information about the metadata of the chart the release is based on. To illustrate this, I installed WordPress and retrieved the metadata: ```shell $ helm get metadata wp NAME: wp CHART: wordpress VERSION: 17.1.13 APP_VERSION: 6.3.1 NAMESPACE: default REVISION: 1 STATUS: deployed DEPLOYED_AT: 2023-09-28T16:28:30-04:00 ``` ## And More... These are just some of the highlights. Helm 3.13 includes even more features. You can read the details in the [release notes](https://github.com/helm/helm/releases/tag/v3.13.0). ================================================ FILE: blog/2024-03-14-cve-2019-25210.md ================================================ --- title: "Response To CVE-2019-25210" slug: "response-CVE-2019-25210" authors: ["helmmaintainers"] date: "2024-03-14" --- [CVE-2019-25210](https://nvd.nist.gov/vuln/detail/CVE-2019-25210) was recently filed against the Helm project. This action was completed without engaging the Helm project and working through the [documented security process and team](https://github.com/helm/community/blob/main/SECURITY.md). The Helm project was given no notice before the disclosure was released which resulted in the inability to provide an appropriate statement beforehand. This post serves as the response from the Helm project. ## Not A Vulnerability In Helm The Helm project rejects this disclosure’s assertion of a vulnerability within Helm. The [advisory listing on GitHub](https://github.com/advisories/GHSA-jw44-4f3j-q396) lists the categorization as [CWE-200](https://cwe.mitre.org/data/definitions/200.html), which is for “Exposure of Sensitive Information to an Unauthorized Actor”. The [documentation for this CWE](https://cwe.mitre.org/data/definitions/200.html) notes that its use is discouraged due to frequent misuse. The description aligns with the implementation within Helm in this situation. The `--dry-run` flag, when used with `helm install` and `helm upgrade`, is designed to send all of the generated chart manifests to standard out that would normally be sent to the Kubernetes API. This is useful for multiple use cases, such as debugging the development of a chart (i.e. package). These manifests are generated from the chart logic. Kubernetes _Secrets_ have been designed by the Kubernetes project to be manifests, like any other resource. When generating manifests, including _Secrets_, there are times they need to be debugged in order to ensure the generated structure is correct. This functionality, used in many situations including local development environments, is not an issue. The output is not exposed to an unauthorized actor. In fact, the output is needed. If this functionality is used in an environment that captures the output for unauthorized actors, such as in a CI system, then the vulnerability is in the **_use of_** a tool that outputs this information, rather than in the tool itself. Consider a simple alternative situation. There is a Kubernetes manifest file containing both secret and non-secret information. `kubectl`, the Kubernetes CLI, is used in an attempt to apply the manifest to a cluster and the attempt fails. So, the `cat` utility is used to display the contents of the file containing the Secret. Is it the vulnerability in `cat` for displaying the information or in the CI setup for using `cat` to display secret information? The vulnerability is in the use of the tool rather than the tool itself. ## Helm Changes To provide greater clarity, the Helm maintainers have made two changes. 1. [Documentation has been updated to make the possible exposure of secret information explicit](https://github.com/helm/helm/pull/12859). 2. [ A flag has been added](https://github.com/helm/helm/pull/12871), which will be available in the next minor release, that will hide secret information in the dry-run output of these commands. ## Why A Delay In Response When the CVE listing was released and the Helm maintainers became aware, the team went to work evaluating the potential impacts. The Helm project takes security seriously. Some examples of this include: * [A documented security policy that enables someone to contact the security team with encrypted communications](https://github.com/helm/community/tree/main/security-audit). * [Two 3rd party security audits (on versions of Helm that contained this functionality)](https://github.com/helm/community/tree/main/security-audit). * [A fuzzing audit and continuous fuzzing has been set up](https://github.com/helm/community/tree/main/security-audit). * [Documented security assurance case](https://github.com/helm/community/tree/main/security-assurance-case), which is an OpenSSF best practices requirement on the way to a silver level. * Helm releases are signed by the maintainer who produced the release. Normally, a discussion about a security issue would stay internal to the Helm project. But, this listing was public and contentious. Helm maintainers contacted security professionals from multiple organizations and sought feedback on the situation prior to publicly commenting or performing any remediation work. ## Please Responsibly Contact The Helm Security Team The Helm security team is responsive. In this calendar year, there have been releases to address two CVEs responsibly reported. You can learn more about reporting security issues in the [documented process](https://github.com/helm/community/blob/main/SECURITY.md) and participate, when necessary, to keep the Helm project and community secure. ================================================ FILE: blog/2024-06-26-the-road-to-helm-4.md ================================================ --- title: "The Road to Helm 4" slug: "the-road-to-helm-4" authors: ["helmmaintainers"] date: "2024-07-10" --- We have been saying it for a while now – Helm is "stable software". That should not come as a surprise to anyone familiar with Kubernetes and the surrounding ecosystem as many within the Kubernetes community consider Helm to be the de-facto package manager. The use of Helm is far reaching: from open source community projects, to startups, to Fortune 500 organizations. Helm has become an essential component of build and deployment workflows that handle mission critical workloads. One of the primary tenets that the Helm project takes very seriously is its policy related to [backwards compatibility](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#semantic-versioning). This strict adherence towards limiting impacts that could adversely affect end consumers is one of the primary reasons why Helm has become such a stable project that the community can count on. Unfortunately, Helm’s backwards compatibility policy does impose limitations to the types of changes or features that can be introduced. It is important to note that Helm is not just a CLI tool, but it is also an SDK. The Helm SDK supports an entire ecosystem of solutions that have been developed to manage Helm content. Any breaking change could negatively impact one of those integrations. However, even with strong adherence to the types of changes that the project can make, Helm has been able to introduce new features over time since Helm 3 was released back in 2019. The first such feature, included in Helm 3.1.0, was [post rendering functionality](https://helm.sh/docs/topics/advanced), which allows end users to customize rendered manifests before being installed or upgraded by Helm. Allowing a post rendering step in the Helm release lifecycle was a game changer for both end users and chart maintainers alike. Users no longer have to patch, fork, or manually render chart templates locally to make their custom adjustments. As a result, chart maintainers no longer need to make their charts overly complicated to fit every possible use case under the sun. Since then, minor (new feature) versions of Helm have been released on a quarterly schedule, and continue to bring ever more functionality to end users. Another important new feature introduced during Helm 3 was the support for [OCI registries as a distribution method](https://helm.sh/docs/topics/registries/#using-an-oci-based-registry) for charts. Functionality for this experimental feature shipped with Helm 3.0.0 and became a fully functional feature in 3.8.0. Users of the CLI as well as the SDK could now confidently store charts using the same tried and true method as they store the container images. And, because charts stored in container registries follow OCI standards, Helm users and chart maintainers can use many of the same tools made for container images – which continue to be improved every day – to accomplish those tasks with their Helm charts too. Helm helped bring greater standardization to the wider Cloud Native ecosystem as it was one of the first projects that made use of OCI as a storage mechanism, which has helped popularize the use of OCI artifacts by other projects. A complete list of new Helm features can be found in the release notes of each minor version [here](https://github.com/helm/helm/releases). The success of Helm is partially related to the architectural changes that were introduced in Helm 3. Gone are the days of the server side component, Tiller (which limited the use of Helm within multi-tenant), and security conscious environments. Countless other enhancements were also introduced that set Helm version 3 apart from its predecessors. Businessman Marcus Lemonis said it best: “If you don’t evolve, you will die”. This sentiment is very much a fact, especially in the technology industry where new tools, approaches, and architectures are introduced with each passing day. It has been 5 years since the release of Helm version 3 and it has become clear, thanks to input from the community, that more impactful changes need to be made to the project so that Helm can continue to serve as an efficient package manager for Kubernetes. That being said, the Helm community is excited to announce the initial kickoff to pave a path toward Helm version 4. ## Helm 4 ContribFest at KubeCon EU 2024 It’s often asked: “Is Helm Popular?”. Based on responses from attendees at events, like KubeCon, who fill sessions relating to the project to maximum capacity, the answer continues to remain a resounding “YES”. At the 2024 KubeCon EU in Paris, the first steps towards soliciting feedback from the Open Source community regarding the next version of Helm occurred during the ContribFest in a session titled, “Building the Helm 4 Highway”. Clearly, there is an interest in evolving the capabilities that are part of the Helm project. Not only was the session full, but a number of compelling ideas were shared including adding support for additional templating languages other than golang, expanding the use of plugins, and increasing the level of support surrounding the secure software supply chain, such as additional methods of signing charts. The full list of ideas and topics from the ContribFest session can be found [here](https://docs.google.com/document/d/1WJ3K96fJeldKHoKhejWHDvCOTddEvY-RCtQBUaZ57FM/edit#heading=h.2xqu5w422ice). ## Getting Involved For those interested in playing a role in the next version of Helm (we’d love to have you), there are several different ways to participate! 1. Join the weekly Helm 4 Roadmap meeting Fridays at 19:00 UTC where members of the community share ideas, develop solutions, and collaborate surrounding the next version of Helm. 1. [Zoom Meeting](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09). 2. Participate in discussions in the [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) channel on the Kubernetes Slack, where members of the Helm community collaborate on Helm development efforts, including those focused on Helm version 4. 3. Submit an [issue](https://github.com/helm/helm/issues) within the Helm [GitHub repository](https://github.com/helm/helm). 4. Follow [@HelmPack](https://x.com/HelmPack) on Twitter/X for project updates. Helm helped define how to package and manage software for Kubernetes. But let’s not stop there - as we update and develop new features and capabilities in Helm 4, Helm will continue to be a tool that the community can continue to leverage confidently to find, share, and run software on Kubernetes. ================================================ FILE: blog/2024-07-16-helm2to3-becomes-unsupported.md ================================================ --- title: "Helm 2to3 is Now Unsupported" slug: "helm2to3-becomes-unsupported" authors: ["martinhickey"] date: "2024-07-16" --- Over four years ago, we [introduced Helm 3](https://helm.sh/blog/helm-3-released/), a major evolution in Helm's development. And we [announced](https://helm.sh/blog/2019-10-22-helm-2150-released/) at that time that Helm 2 would receive patches and security updates for a year. We also provided a [migration path to Helm 3 from Helm 2](https://helm.sh/docs/topics/v2_v3_migration/) and a tool [helm-2to3](https://github.com/helm/helm-2to3) to automate migration. One year later, [Helm 2 became unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). Here we are, over 3 years since Helm 2 became unsupported. It would be expected that all users should be migrated to Helm 3 by this time. Following consensus among the Helm org maintainers, we are announcing today the official end of support for the [helm-2to3](https://github.com/helm/helm-2to3) tool. In practice, this means that **Helm 2to3** will receive no more updates (not even security patches). We strongly discourage the use of the [helm-2to3](https://github.com/helm/helm-2to3) tool moving forward, as it will be receiving no future security updates or patches. We hope that it has been a useful tool to aid in the migration from Helm 2 to 3. ================================================ FILE: blog/2024-10-07-kubecon-na-24/index.md ================================================ --- title: "Helm at KubeCon/CloudNativeCon SLC" slug: "kubecon-slc" authors: ["mattfarina"] date: "2024-11-07" --- ![KubeCon / CloudNativeCon Logo](kubecon.png) Helm is going to be at KubeCon / CloudNativeCon North America in Salt Lake City. There will be something happening each day of the main conference, including: * Wednesday: * At a booth in the project pavilion from 3:15pm - 8pm. * At 7pm MST we are planning to cut a release, live. * Thursday: * At a project pavilion booth from 1:45pm - 5pm. * Session: [Contribfest: Helm 4: The Next Generation of the Kubernetes Package Manager](https://kccncna2024.sched.com/event/1howt) * Session: [The Path to Helm 4](https://kccncna2024.sched.com/event/1hoxU) * Friday: * 12:30pm - 2:30pm at the project pavilion If you want to talk with a maintainer to learn about Helm or just give feedback, the project pavilion is the perfect place to do that. If you want to learn about Helm v4 the session "The Path to Helm 4" is going to give you an overview. If you want to make your first contributions to Helm, the Contribfest session is a place to get started. If you're going to be in Salt Lake City, we hope to see you there. ================================================ FILE: blog/2024-11-08-experience-helm-release-kubecon-na-24.md ================================================ --- title: "Experience a Helm Release: Live at KubeCon + CloudNativeCon North America 2024!" slug: "experience-helm-release-kubecon-na-24" authors: ["andrewblock"] date: "2024-11-08" --- Have you ever wondered what it takes to perform a software release of one of the most popular tools in the Kubernetes community? While you may envision a series of complex steps or maybe even some black magic (some of which may be true), the release process is much more organized and streamlined than you may have envisioned. However, until you see it for yourself firsthand, these types of questions will continue to go unfulfilled. Seeing it really is believing it! Join maintainers and members of the Helm community at KubeCon + CloudNativeCon North America at the Demo Theater during the booth crawl on Wednesday November 13 at 7pm MST as we review the process involved to perform a release of the latest version of Helm so that it can be made available to the entire cloud native community. Along the way, you will learn about the associated activities, individuals, and processes involved with taking source code and transforming it into a consumable artifact for all across a myriad of supported runtimes and platforms. Whether you are a Helm aficionado or just have an interest in release engineering, this is a session that you certainly want to circle on your agendas! Not able to make it to KubeCon + CloudNativeCon North America? Don’t fret! The session will be recorded and made available at a later date. This release session is just one of several Helm related events taking place at KubeCon + CloudNativeCon North America 2024. A full overview can be found [here](/blog/kubecon-slc). ================================================ FILE: blog/2025-08-19-debian-helm-repository-move.md ================================================ --- title: "Debian/Ubuntu Helm Apt Repository Move" slug: "debian-helm-repository-move" authors: ["terryhowe"] date: "2025-08-19" --- If you are installing helm with Apt, be aware that the Debian/Ubuntu Helm Apt repository is moving. Previously the repository was hosted at [Balto](https://helm.baltorepo.com/) and now it will be hosted at [Buildkite](https://buildkite.com/). Update your APT key and references to the repository using the [new installation instructions](https://helm.sh/docs/intro/install/#from-apt-debianubuntu). ================================================ FILE: blog/2025-09-09-path-to-helm-v4.md ================================================ --- title: "Path To Releasing Helm v4" slug: "path-to-helm-v4" authors: ["mattfarina"] date: "2025-09-09" --- The [first Alpha for Helm v4](https://github.com/helm/helm/releases/tag/v4.0.0-alpha.1) has been released. Now that Helm v4 development is in the home stretch, we wanted to share the details on what's happening and how the broader community can get involved. ## Alpha Period With the start of September, there is a freeze on new major features for Helm v4. This begins the Alpha phase, where API breaking changes will still happen, but the focus turns to stability and making sure the existing changes work as expected. If you're a Helm user, during this period you can test out the current capabilities and provide feedback where things aren't working as expected. Just remember, this is alpha quality software and changes are still occurring. For Helm SDK users, now is a good time to look at the API to see if there are any concerns with the design changes along with any impacts to your efforts. The Alpha period runs through the month of September. ## Beta Period The beta period starts in October. At this point the focus is on stability in preparation for release. API breaking changes should be complete and the focus transitions to fixing any bugs to ensure there is a stable release. Testers should file bugs as they encounter any issues. Per [release schedule policy](/community/release_policy#major-releases), once the first beta version is available, the final 4.0.0 release date will be chosen and announced. ## Release Candidates At the end of October, the first release candidate will be created. This represents what we think will be released as Helm v4. If there are any major issues, they will be fixed and a new release candidate will be made. ## 🎉 Release 🎉 The release is planned for KubeCon + CloudNativeCon North America 2025. in mid November, which is 6 years after the release of Helm v3 and 10 years after the creation of Helm. More details on the release will come. ================================================ FILE: blog/2025-10-19-helm-turns-10/index.md ================================================ --- title: "Helm Turns 10" slug: "helm-turns-ten" authors: ["mattfarina"] date: "2025-10-19" --- Ten years ago, in a hackathon shortly after the release of Kubernetes 1.1.0, Helm was born. ``` commit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d Author: Matt Butcher Date: Mon Oct 19 17:43:26 2015 -0600 initial add ``` [The first commit](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d) can be found on the helm-classic Git repository where the codebase for Helm v1 is located. This is the original Helm, before it merged with Deployment Manager and was folded into the Kubernetes project. This commit was just the beginning. Helm would be shown off at the first KubeCon, just a few weeks later. From there Helm development would take off and a community of developers and charts would follow. Happy 10th Birthday, Helm! ![Happy 10th Birthday Helm](happy-10th.png) ================================================ FILE: blog/2025-11-04-helm-at-kubecon-na-25.md ================================================ --- title: "Helm @ KubeCon + CloudNativeCon NA '25" slug: "helm-at-kubecon-na-25" authors: ["karenchu"] date: "2025-11-04" --- The Helm team is headed to KubeCon + CloudNativeCon NA '25 in Atlanta, Georgia next week and it's truly a special one for us! This time around, as we celebrate our 10th birthday (fun fact, Helm was launched at the first KubeCon in 2015), we will also be releasing the highly anticipated Helm 4! Join us for a series of exciting activities throughout the week -- read on for more details! ## Helm Booth in Project Pavilion Don't miss out on meeting our project maintainers at the Helm booth - we'll be hanging out the second half of each day. Drop by to ask questions, learn about what's in Helm 4, and pick up special Hazel swag celebrating Helm's 10th birthday! * TUES Nov 11 @ 03:30 PM - 07:45 PM ET * WED Nov 12 @ 02:00 PM - 05:00 PM ET * THUR Nov 13 @ 12:30 PM - 02:00 PM ET LOCATION: 8B, back side of Flux and across from Argo ## Tuesday November 11, 2025 ### [Simplifying Advanced AI Model Serving on Kubernetes Using Helm Charts](https://sched.co/27FVb) TIME: 12:00 PM - 12:30 PM ET LOCATION: Building B | Level 4 | B401-402 SPEAKERS: [Ajay Vohra](https://kccncna2025.sched.com/speaker/ajayvohr) & [Caron Zhang](https://kccncna2025.sched.com/speaker/caronzh03) The AI model serving landscape on Kubernetes presents practitioners with an overwhelming array of technology choices: From inference servers like Ray Serve and Triton Inference Server, inference engines like vLLM, and orchestration platforms like Ray Cluster and KServe. While this diversity drives innovation, it also creates complexity. Teams often prematurely standardize on limited technology stacks to manage this complexity. This talk introduces an innovative Helm-based approach that abstracts the complexity of AI model serving while preserving the flexibility to leverage the best tools for each use case. Our solution is accelerator agnostic, and provides a consistent YAML interface for deploying and experimenting with various serving technologies. We'll demonstrate this approach through two concrete examples of multi-node, multi-accelerator model serving with auto scaling: 1/ Ray Serve + vLLM + Ray Cluster, and 2/ LeaderWorkerSet + Triton Inference Server + vLLM + Ray Cluster + HPA. ## Wednesday November 12, 2025 ### [Maintainer Track: Introducing Helm 4](https://sched.co/27Nme) TIME: 11:00 AM - 11:30 AM ET LOCATION: Building C | Level 3 | Georgia Ballroom 1 SPEAKERS: [Matt Farina](https://kccncna2025.sched.com/speaker/matt812) & [Robert Sirchia](https://kccncna2025.sched.com/speaker/robert_sirchia.28kd1wis) (Helm Maintainers) The wait is over! After six years with Helm v3, Helm v4 is finally here. In this session you'll learn about Helm v4, why there was 6 years between major versions (from backwards compatible feature development to maintainer ups and downs), what's new in Helm v4, how long Helm v3 will still be supported, and what comes next. Could that include a Helm v5? ### [Contribfest: Hands-On With Helm 4: Wasm Plugins, OCI, and Resource Sequencing. Oh My!](https://sched.co/27Nl0) TIME: 02:15pm - 03:30 PM ET LOCATION: Building B | Level 2 | B207 SPEAKERS: [Andrew Block](https://kccncna2025.sched.com/speaker/ablock2), [Scott Rigby](https://kccncna2025.sched.com/speaker/r6by), & [George Jenkins](https://kccncna2025.sched.com/speaker/gvjenkins) (Helm Maintainers) Join Helm maintainers for an interactive session contributing to core Helm and building integrations with some of Helm 4's emerging features. We'll guide contributors through creating Helm 4's newest enhancements including WebAssembly plugins, enhancements to how OCI content is manged, and implementing resource sequencing for controlled deployment order. Attendees will explore how to build Download/Postrender/CLI plugins in WebAssembly, develop capabilities related to changes to Helm's management of OCI content including repository prefixes and aliases, and use approaches for sequencing chart deployments beyond Helm's traditional mechanisms. This session is geared toward anyone interested in Helm development including leveraging and building upon some of the latest features associated with Helm 4! ### [Helm 4 Release Party](/helm-4-release-party/) TIME: 06:00 PM - 09:00 PM EST LOCATION: [Max Lager's Wood-Fired Grill & Brewery](https://www.google.com/maps/place/Max+Lager's+Wood-Fired+Grill+%26+Brewery/@33.7633384,-84.3869351,16z/data=!3m1!4b1!4m6!3m5!1s0x88f50479f0b45fe9:0x8c53b75958299abd!8m2!3d33.7633384!4d-84.3869351!16s%2Fm%2F01_23gr) [Replicated](https://www.replicated.com/) and the [CNCF](https://www.cncf.io/) are throwing a Helm 4 Release Party to celebrate the release of Helm 4! Drop by for a low country boil and hang out with the Helm project maintainers for the night! See the invitation [here](/helm-4-release-party/), and don't forget to save your spot – RSVP [here](https://replicated.typeform.com/helmparty). ## Thursday November 13, 2025 ### [Mission Abort: Intercepting Dangerous Deletes Before Helm Hits Apply](https://sched.co/27FeJ) TIME: 01:45 PM - 02:15 PM ET LOCATION: Building B | Level 5 | Thomas Murphy Ballroom 4 SPEAKERS: [Payal Godhani](https://kccncna2025.sched.com/speaker/godhanipayal) What if your next Helm deployment silently deletes a LoadBalancer, a Gateway, or an entire namespace? We’ve lived that nightmare—multiple times. In this talk, we’ll share how we turned painful Sev1 outages into a resilient, guardrail-first deployment strategy. By integrating Helm Diff and Argo CD Diff, we built a system that scans every deployment for destructive changes—like the removal of LoadBalancers, KGateways, Services, PVCs, or Namespaces—and blocks them unless explicitly approved. This second-layer approval acts as a safety circuit for your release pipelines. No guesswork. No blind deploys. Just real-time visibility into what’s about to break—before it actually does. Whether you’re managing a single cluster or an entire fleet, this talk will show you how to stop fearing Helm and start trusting it again. Because resilience isn’t about avoiding failure—it’s about learning, adapting, and building guardrails that protect everyone. ================================================ FILE: blog/2025-11-17-helm-4-released/index.md ================================================ --- title: "Helm 4 Released" slug: "helm-4-released" authors: ["mattfarina"] date: "2025-11-17" --- On Wednesday November 12th, during the [Helm 4 presentation at KubeCon + CloudNativeCon](https://sched.co/27Nme), [Helm v4.0.0](https://github.com/helm/helm/releases/tag/v4.0.0) was released. This is the first new major version of Helm in 6 years. ## What's New Helm v3 has served the Kubernetes community well for many years. During that time we saw new ways to use Helm, new applications installed via charts, the rise of [Artifact Hub](https://artifacthub.io/), and numerous tools that build on top of Helm. We also saw where we wanted to add features but the internal architecture of Helm didn't provide a path forward without breaking public APIs in the SDK. Helm 4 makes those changes to enable new features now and into the future. Some of the new features include: - Redesigned plugin system that supports Web Assembly based plugins - Post-renderers are now plugins - Server side apply is now supported - Improved resource watching, to support waiting, based on kstatus - Local Content-based caching (e.g. for charts) - Logging via slog enabling SDK logging to integrate with modern loggers - Reproducible/Idempotent builds of chart archives - Updated SDK API including support for multiple chart API versions (new experimental v3 chart API version coming soon) You can learn about more of the changes in the [Helm 4 Overview](/docs/overview). ## Helm v3 Support When a major version of software comes out, it takes awhile to make the transition. Helm v3 will continue to be supported to enable a clean transition period. The dates of continued support are: * Bug fixes until July 8th 2026. * Security fixes until November 11th 2026. Helm releases updates on Wednesdays (typically the 2nd Wednesday in a month) and these dates correspond with release schedule dates. During this time there will be **_NO_** features backported other than updates to the Kubernetes client libraries that enable support of new Kubernetes versions. ## Learn More You can learn about the Helm changes in the [overview](/docs/overview) or find all the changes in the [full changelog](/docs/changelog). The documentation shares many more details as you can find all the ways Helm has stayed the same and the new features you can take advantage of. ================================================ FILE: blog/authors.yml ================================================ adamkorczynski: name: Adam Korczynski image_url: https://github.com/AdamKorcz.png page: true socials: github: AdamKorcz linkedin: adam-korczynski-731909119 andrewblock: name: Andrew Block image_url: https://github.com/sabre1041.png page: true socials: github: sabre1041 linkedin: andrewsblock # keybase: sabre1041 website: https://t.co/utJRRBeHm1 bridgetkromhout: name: Bridget Kromhout image_url: https://github.com/bridgetkromhout.png page: true socials: github: bridgetkromhout linkedin: bridgetkromhout davidkorczynski: name: David Korczynski image_url: https://github.com/davidkorczynski.png page: true socials: github: davidkorczynski linkedin: david-korczynski-875a4957 helmmaintainers: name: Helm Maintainers image_url: https://raw.githubusercontent.com/helm/community/refs/heads/main/art/images/Logo-Tweak-Dark.png page: true socials: github: helm website: https://helm.sh joshdolitsky: name: Josh Dolitsky image_url: https://github.com/jdolitsky.png page: true socials: github: jdolitsky linkedin: jdolitsky # keybase: jdolitsky karenchu: name: Karen Chu image_url: https://github.com/karenhchu.png page: true socials: github: karenhchu linkedin: karenhchu martinhickey: name: Martin Hickey image_url: https://github.com/hickeyma.png page: true socials: github: hickeyma linkedin: martin-hickey-b64a374 website: https://hickeyma.github.io/ mattbutcher: name: Matt Butcher image_url: https://github.com/technosophos.png page: true socials: github: technosophos linkedin: mattbutcher # keybase: technosophos website: http://technosophos.com/ mattfarina: name: Matt Farina image_url: https://github.com/mattfarina.png page: true socials: github: mattfarina linkedin: matthewfarina # keybase: mattfarina website: https://mattfarina.com/ mattfisher: name: Matt Fisher image_url: https://github.com/bacongobbler.png page: true socials: github: bacongobbler linkedin: bacongobbler website: https://blog.bacongobbler.com/ rimasmocevicius: name: Rimas Mocevicius image_url: https://github.com/rimusz.png page: true socials: github: rimusz linkedin: rimantasmocevicius website: https://rimusz.net/ scottrigby: name: Scott Rigby image_url: https://github.com/scottrigby.png page: true socials: github: scottrigby linkedin: scottrigby # keybase: r6by website: http://basekamp.com/ terryhowe: name: Terry Howe image_url: https://github.com/terryhowe.png page: true socials: github: terryhowe linkedin: terrylhowe website: https://terryhowe.wordpress.com/ viciglesias: name: Vic Iglesias image_url: https://github.com/viglesiasce.png page: true socials: github: viglesiasce linkedin: viglesias ================================================ FILE: blog/helm-at-kubecon-eu-25.md ================================================ --- title: "Helm @ KubeCon + CloudNativeCon EU '25" slug: "helm-at-kubecon-eu-25" authors: ["karenchu"] date: "2025-03-31" --- It's that time of the year again – the Helm team is headed to KubeCon + CloudNativeCon EU '25 in London, UK this week from April 1 - 4! Helm 4 is in the works for later this year so be sure to join the conversation with our maintainers during our talk sessions and at our Helm booth in the Project Pavilion! See below for more details on all Helm-related activities throughout the week. ## Contribfest: [Expanding the Helm Ecosystem With Helm 4](https://sched.co/1tcyE) DATE: Wednesday April 2 TIME: 16:15 - 17:30 BST LOCATION: Level 3 | ICC Capital Suite 17 Are you passionate about Helm and looking for ways to contribute? Join Helm maintainers at this ContribFest session to help shape the future of the project and its ecosystem! This session focuses on three exciting initiatives: * Exploring the Helm Ecosystem * Building a Triage Team * Diving into Helm 4 Don't miss this session with [Scott](https://bsky.app/profile/r6by.bsky.social), [Robert](https://bsky.app/profile/sirchia.cloud), and [Ingy](https://bsky.app/profile/ingydotnet.bsky.social) for your chance at contributing to Helm 4 efforts! For more details on the Contribfest session, check the [session page](https://sched.co/1tcyE) for the latest updates. ## Helm Maintainer Track Talk: [Helm 4 You](https://sched.co/1td0b) DATE: Thursday April 3 TIME: 16:45 - 17:15 BST LOCATION: Level 3 | ICC Capital Suite 10-12 Join Helm maintainers [Matt Farina](https://bsky.app/profile/mattfarina.com) and [Andrew Block](https://bsky.app/profile/andyserver.com) as they provide an update on the next major version of Helm, the timelines, and the features being evaluated. They will also share how the community has been inspirational in helping make Helm 4 a reality. Since Helm continues to be a crucial component in the workflows of users and enterprises worldwide, a new version of Helm is only possible thanks to the continued collaboration from the Cloud Native community. Full details on the talk can be found on the [session page](https://sched.co/1td0b). ## Helm Booth in Project Pavilion WED April 2 @ 15:30 – 19:45 BST THUR April 3 @ 14:00 – 17:00 BST FRI April 4 @ 12:30 – 14:00 BST LOCATION: 2B, near the sticker wall + back side of Backstage Our maintainers and contributors will be staffing the Helm project booth during the second half of each day. Let us know how you're using Helm, what questions you have, and learn more about what's coming in Helm 4. We'll have Helm stickers and *custom Helm tea towels* to help us all remember our time in the UK! ## Helm Sessions from the Community Aside from sessions with our Helm maintainers, there are several talks from the cloud native ecosystem that touch on Helm – be sure to check these out as well ~ * [Project Lightning Talk: Kubeflow Helm Chart - Krzysztof Romanowski, Maintainer](https://sched.co/1tcvo) // Tuesday April 1, 2025 @ 12:34 - 12:39 BST // Platinum Suite | Level 3 * [Project Lightning Talk: Stir to Combine: Creating Porter Mixins - Sarah Christoff, Maintainer](https://sched.co/1tcws) // Tuesday April 1, 2025 @ 16:07 - 16:12 BST // Platinum Suite | Level 3 * [Poster Session: Helmless (PS 06): Fast Serverless Deployments Without the Overhead of Kubernetes and Terraform - Michael Reichenbach, 1KOMMA5°](https://sched.co/1txDf) // Wednesday April 2, 2025 @ 13:30 - 14:30 BST // Level 1 | Hall Entrance N8-N9 | Poster Pavilion * [Jaeger V2: OpenTelemetry at the Core of Modern Distributed Tracing - Jonah Kowall, Paessler](https://sched.co/1tcyZ) // Wednesday April 2, 2025 @ 17:00 - 17:30 BST // Level 3 | ICC Capital Suite 10-12 * [Into the Shopfloor: Moving Manufacturing Execution Systems To Kubernetes - Manuel Peuster & Andrei Traian Cucuruzac, Bosch Connected Industry](https://sched.co/1txEg) // Friday April 4, 2025 @ 11:45 - 12:15 BST // Level 1 | Hall Entrance N10 | Room E See everyone this week! ================================================ FILE: code-of-conduct.md ================================================ # Community Code of Conduct Helm follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). ================================================ FILE: community/MAINTAINERS.md ================================================ --- title: Helm Org Maintainers --- * [Karen Chu](https://github.com/karenhchu) * [Matt Butcher](https://github.com/technosophos) (chair) * [Matt Farina](https://github.com/mattfarina) * [Reinhard Nägele](https://github.com/unguiculus) * [Scott Rigby](https://github.com/scottrigby) ## Emeritus * [Adam Reese](https://github.com/adamreese) * [Adnan Abdulhussein](https://github.com/prydonius) * [Josh Dolitsky](https://github.com/jdolitsky) * [Martin Hickey](https://github.com/hickeyma) * [Matt Fisher](https://github.com/bacongobbler) * [Vic Iglesias](https://github.com/viglesiasce) ================================================ FILE: community/README.md ================================================ --- sidebar_position: 1 title: Helm Community --- Welcome to the Helm community! This is the starting point for becoming a contributor to the Helm project - improving docs, improving code, giving talks etc. ## Communicating The [communication](communication.md) page lists communication channels like chat, issues, mailing lists, meetings, conferences, etc. ## Assets - Helm logos are located at [cncf/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos) - Helm website and docs are located at [helm/helm-www](https://github.com/helm/helm-www) - Helm brand examples and guidelines: [art](/community/art) - Helm themed presentation template: [slides](https://github.com/helm/community/tree/main/slides) ## How Can I Help? #### First, you should join our communication forums: - Follow us on [Twitter](communication.md#social-media) - Join us on [Slack](communication.md#slack) - Subscribe to our [mailing lists](communication.md#mailing-lists) - Join the [weekly meeting](communication.md#meetings) #### Next, get set-up with the basics (if not already done so): - [Documentation](https://docs.helm.sh/) - [Issues](https://github.com/helm/helm/issues) - [PRs](https://github.com/helm/helm/pulls) - [Quickstart Guide](https://docs.helm.sh/using_helm/#quickstart) - [Developer Guide](https://docs.helm.sh/developers/) Now, you can get down to business! A good way to learn is: - Check out the code and look at code reviews. Documentation and test are part of the code base. - Try reproducing issues and get an overview of user problems. - Talk to people on Slack and ask questions. Areas you can start working on: - Documentation (like the text you are reading now) can always use improvement! - We can always do with more test coverage. - Review open PRs. Add comments, feedback or give a LGTM! - Try out some easy-to-fix bugs which may be marked with the [good first issue] tag - Just ask an [owner] for suggestions. #### Last but not least, we'd love to know what you want to see on the [Helm Blog](https://helm.sh/blog). Feel free to submit a blog post topic [here](blog-topics.md). ## Your First Contribution We recommend that you work on existing [issues] before attempting to develop a new feature. Find an existing issue (e.g. one marked [good first issue], or simply ask an [owner] for suggestions), and respond on the issue thread expressing interest in working on it. This helps other people know that the issue is active, and hopefully prevents duplicated efforts. Each commit must be signed off in git, as described by [the article](https://www.helm.sh/blog/helm-dco/index.html) describing Helm's switch to DCO. If you want to work on a new idea of relatively small scope: 1. Submit an issue describing your proposed change to the repo in question. 1. The repo owners will respond to your issue promptly. 1. If your proposed change is accepted, start work in your fork, signing off each commit as described above. 1. Submit a [pull request] containing a tested change. [good first issue]: https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22 [issues]: https://github.com/helm/helm/issues [pull request]: https://github.com/helm/helm/blob/main/CONTRIBUTING.md#pull-requests [owner]: https://github.com/kubernetes/helm/blob/main/OWNERS ================================================ FILE: community/SECURITY.md ================================================ --- sidebar_label: Helm Security title: Helm Security Process and Policy --- This document provides the details on the Helm security policy and details the processes surrounding security handling including a how to guide on reporting a security vulnerability for anything within the Helm organization. ## Report A Vulnerability We’re extremely grateful for security researchers and users who report vulnerabilities to the Helm community. All reports are thoroughly investigated by a set of Helm maintainers. To make a report please email the private security list at cncf-helm-security@lists.cncf.io with the details. You may, but are not required to, encrypt your email to this list using the PGP keys of security team members, listed below. | Name | Key URL | Fingerprint | |----------------|-------------------------------------------------------------------------------------------------|----------------------------------------------------| | Andrew Block | [link](https://keybase.io/sabre1041/pgp_keys.asc) | 2CE5 F1FB 9E8C 59B8 7BBD  5F2B 02DF E631 AEF3 5EBC | | George Jenkins | [link](https://keybase.io/gjenkins8/pgp_keys.asc) | C048 04B5 F250 1D25 CA69  A415 2945 4FC9 6455 D41E | | Matt Butcher | [link](https://keybase.io/technosophos/pgp_keys.asc) | ABA2 5295 98F6 626C 420D 335B 62F4 9E74 7D91 1B60 | | Matt Farina | [link](https://keybase.io/mattfarina/pgp_keys.asc) | 672C 657B E06B 4B30 969C 4A57 4614 49C2 5E36 B98E | | Robert Sirchia | [link](https://keys.openpgp.org/vks/v1/by-fingerprint/7FEC81FACC7FFB2A010ADD13C2D40F4D8196E874) | 7FEC81FACC7FFB2A010ADD13C2D40F4D8196E874 | ### When To Send A Report You think you have found a vulnerability in a Helm project or a dependency of a Helm project. This can be any of the repositories on the [Helm GitHub organization](https://github.com/helm). ### When Not To Send A Report * If a vulnerability has been found in an application deployed by a Helm Chart. Instead, contact the application maintainers * For guidance on securing Helm, please see the [documentation](https://helm.sh/docs/using_helm/#securing-your-helm-installation) or ask in one of the [support channels](/community#how-can-i-help) * You are looking for help applying security updates ### Security Vulnerability Response Each report will be reviewed and receipt acknowledged within 3 business days. This will set off the security review process detailed below. Any vulnerability information shared with the security team stays within the Helm project and will not be shared with others unless it is necessary to fix the issue. Information is shared only on a need to know basis. We ask that vulnerability reporter(s) act in good faith by not disclosing the issue to others. And we strive to act in good faith by acting swiftly, and by justly crediting the vulnerability reporter(s) in writing. As the security issue moves through triage, identification, and release the reporter of the security vulnerability will be notified. Additional questions about the vulnerability may also be asked of the reporter. ### Public Disclosure A public disclosure of security vulnerabilities is released alongside release updates or details that fix the vulnerability. We try to fully disclose vulnerabilities once a mitigation strategy is available. Our goal is to perform a release and public disclosure quickly and in a timetable that works well for users. For example, a release may be ready on a Friday but for the sake of users may be delayed to a Monday. CVEs will be assigned to vulnerabilities. Due to the process and time it takes to obtain a CVE ID, disclosures will happen first. Once the disclosure is public the process will begin to obtain a CVE ID. Once the ID has been assigned the disclosure will be updated. If the vulnerability reporter would like their name and details shared as part of the disclosure process we are happy to. We will ask permission and for the way the reporter would like to be identified. We appreciate vulnerability reports and would like to credit reporters if they would like the credit. ## Security Team Membership The security team is made up of a subset of the Helm project maintainers who are willing and able to respond to vulnerability reports. ### Responsibilities * Members MUST be active project maintainers on active (non-deprecated) Helm projects as defined in [the governance](governance/governance.md) * Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled * Members MUST keep the vulnerability details private and only share on a need to know basis ### Membership New members are required to be active maintainers of Helm projects who are willing to perform the responsibilities outlined above. The security team is a subset of the maintainers. Members can step down at any time and may join at any time. From time to time, Helm projects are deprecated. If at any time a security team member is found to be no longer be an active maintainer on active Helm projects, this individual will be removed from the security team. ## Patch and Release Team When a vulnerability comes in and is acknowledged, a team - including maintainers of the Helm project affected - will assembled to patch the vulnerability, release an update, and publish the vulnerability disclosure. This may expand beyond the security team as needed but will stay within the pool of Helm project maintainers. ## Disclosures Vulnerability disclosures are published as blog posts on the [Helm Blog](https://helm.sh/blog/) and emailed to the [Helm mailing list](https://lists.cncf.io/g/cncf-helm). The disclosures will contain an overview, details about the vulnerability, a fix for the vulnerability that will typically be an update, and optionally a workaround if one is available. Disclosures will be published on the same day as a release fixing the vulnerability after the release is published. ================================================ FILE: community/art/readme.md ================================================ --- title: Styleguide --- ## Logo The official Helm logo is found at the [CNCF/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos) repo. ![Logo-Tweak-Light](./images/Logo-Tweak-Light.png) ![Logo-Tweak-Dark](./images/Logo-Tweak-Dark.png) # Brand Colors ![Helm-3-Color-Palettes-Light](./images/Helm-3-Color-Palettes-Light.png) ![Helm-3-Color-Palettes-Dark](./images/Helm-3-Color-Palettes-Dark.png) ### Color Values ``` // primary navy #0F1689 // secondary blue-dark #090E6F blue-light #1B53C2 // shades shade-dark #050843 shade-mid #B7C2E9 shade-light #DBE1F3 // accents accent-blue #3B82BF accent-green #2F84A7 accent-red #95297C accent-yellow #D1AA9B ``` # Typography ![type-notes](./images/type-notes.png) * [Space Mono](https://fonts.google.com/specimen/Space+Mono) _(Google Fonts)_ * [Public Sans](https://public-sans.digital.gov/) _(USWDS)_ --- ## Examples: Example applications of the Helm brand to different assets. ![Typography](./images/Typography.png) Example typography. ![Example-Icon-Illustrations](./images/Example-Icon-Illustrations.png) Illustrations and icon examples. ![Helm-Summit](./images/Helm-Summit.png) --- ![Website-Exmple](./images/Example-Icon-Illustrations.png) Example for a website layout. ![Website-Exmple.png](./images/Website-Exmple.png) ================================================ FILE: community/blog-topics.md ================================================ --- title: Submit a topic for the Helm Blog --- 1. Helm 2 to 3 Migration (Blog Series) * 5 Useful Tips for Migrating to Helm 3 * Helm 2 to Helm 3 Migration Checklist * Rethinking Security for Helm 3 2. Helm Maintainer Spotlight (Blog Series) 3. Case Studies 4. Solution Guides 5. ================================================ FILE: community/code-of-conduct.md ================================================ --- title: Community Code of Conduct --- Helm follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). ================================================ FILE: community/communication.md ================================================ --- title: Communication --- The Helm community abides by the [CNCF code of conduct]. Here is an excerpt: > _As contributors and maintainers of this project, and in the interest > of fostering an open and welcoming community, we pledge to respect > all people who contribute through reporting issues, posting feature > requests, updating documentation, submitting pull requests or patches, > and other activities._ ## Social Media * [Twitter] * Pose questions and help answer them on [Slack] or [Stack Overflow]. ## Slack You can [request an invitation to the Kubernetes Slack](https://slack.kubernetes.io/). Most real time discussion happens at [#helm-users](https://kubernetes.slack.com/messages/C0NH30761) and [#charts](https://kubernetes.slack.com/messages/C6E3XH1ED). There is also a [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) channel for discussing development of Helm. ## Issues Issues are used as the primary method for tracking anything to do with the Helm project. See the [contributing guide](https://github.com/kubernetes/helm/blob/main/CONTRIBUTING.md#issues) for information on how to [file an issue] if you think you have found a bug or have a feature request. ## Mailing lists Development announcements and discussions appear on the Helm mailing list [cncf-helm] (send mail to `cncf-helm@lists.cncf.io`). ## Meetings The Helm community holds regular public meetings, including those supporting Helm client development and charts. You can [view the calendar of meetings](https://calendar.google.com/calendar/embed?src=s5anaqbm9kda435dnh5r8lj1l8%40group.calendar.google.com&ctz=America%2FLos_Angeles) and [subscribe via an ical](https://calendar.google.com/calendar/ical/s5anaqbm9kda435dnh5r8lj1l8%40group.calendar.google.com/public/basic.ics) feed. We have a [weekly development meeting] every Thursday at 9:30am US Pacific Time and all are welcome. Map that to your local time with this [timezone table]. We keep notes from each meeting on this [document](https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit?usp=sharing) for summaries of standups, discussion, and action items. Videos are available on the [Helm Community Meetings playlist]. ## Conferences Helm is one of the projects, represented at CloudNativeCon/KubeCon, held three times per year in Europe, Asia and North America. Information about these and other community events is available on the CNCF [events] pages. Also, the Helm community organizes the Helm-focused event - [Helm Summit], first edition of which has happened in Portland, Oregon in February 2018, [the second one](https://events19.linuxfoundation.org/events/helm-summit-2019/) - in Europe (Amsterdam, Netherlands) on September 11-12, 2019. [CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md [cncf-helm]: https://lists.cncf.io/g/cncf-helm/topics [events]: https://www.cncf.io/events/ [file an issue]: https://github.com/helm/helm/issues/new [kubernetes-sig-apps]: https://groups.google.com/forum/#!forum/kubernetes-sig-apps [Slack]: https://kubernetes.slack.com [Helm Summit]: https://helmsummitpdx-feb2018.splashthat.com/ [Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes-helm [timezone table]: https://www.google.com/search?q=0930+am+in+pst [Twitter]: https://twitter.com/helmpack [weekly development meeting]: https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09 [Helm Community Meetings playlist]: https://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0 [SIGs]: https://github.com/kubernetes/community/blob/master/sig-list.md [SIG-Apps]: https://github.com/kubernetes/community/tree/master/sig-apps ================================================ FILE: community/developers.md ================================================ --- title: Developer Setup description: Instructions for setting up your environment for developing Helm. sidebar_position: 2 --- This guide explains how to set up your environment for developing on Helm. ## Prerequisites - The latest version of Go - A Kubernetes cluster w/ kubectl (optional) - Git ## Building Helm We use Make to build our programs. The simplest way to get started is: ```console $ make ``` If required, this will first install dependencies and validate configuration. It will then compile `helm` and place it in `bin/helm`. To run Helm locally, you can run `bin/helm`. - Helm is known to run on macOS and most Linux distributions, including Alpine. ## Running tests To run all the tests, run `make test`. As a pre-requisite, you would need to have [golangci-lint](https://golangci-lint.run) installed. ## Running Locally You can update your path and add the path of your local helm binary. In an editor open your shell config file. Add the following line making sure you replace `` with your local bin directory. ``` bash export PATH=":$PATH" ``` This will allow you to run the locally built version of helm from your terminal. ## Contribution Guidelines We welcome contributions. This project has set up some guidelines in order to ensure that (a) code quality remains high, (b) the project remains consistent, and (c) contributions follow the open source legal requirements. Our intent is not to burden contributors, but to build elegant and high-quality open source code so that our users will benefit. Make sure you have read and understood the main CONTRIBUTING guide: ### Structure of the Code The code for the Helm project is organized as follows: - The individual programs are located in `cmd/`. Code inside of `cmd/` is not designed for library re-use. - Shared libraries are stored in `pkg/`. - The `scripts/` directory contains a number of utility scripts. Most of these are used by the CI/CD pipeline. Go dependency management is in flux, and it is likely to change during the course of Helm's lifecycle. We encourage developers to _not_ try to manually manage dependencies. Instead, we suggest relying upon the project's `Makefile` to do that for you. With Helm 3, it is recommended that you are on Go version 1.13 or later. ### Writing Documentation Since Helm 3, documentation has been moved to its own repository. When writing new features, please write accompanying documentation and submit it to the [helm-www](https://github.com/helm/helm-www) repository. One exception: [Helm CLI output (in English)](/docs/helm) is generated from the `helm` binary itself. See [Updating the Helm CLI Reference Docs](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) for instructions on how to generate this output. When translated, the CLI output is not generated and can be found in `/content//docs/helm`. ### Git Conventions We use Git for our version control system. The `main` branch is the home of the current development candidate. Releases are tagged. We accept changes to the code via GitHub Pull Requests (PRs). One workflow for doing this is as follows: 1. Fork the `github.com/helm/helm` repository into your GitHub account 2. `git clone` the forked repository into your desired directory 3. Create a new working branch (`git checkout -b feat/my-feature`) and do your work on that branch. 4. When you are ready for us to review, push your branch to GitHub, and then open a new pull request with us. For Git commit messages, we follow the [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html): ``` fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` Common commit types: - fix: Fix a bug or error - feat: Add a new feature - docs: Change documentation - test: Improve testing - ref: refactor existing code Common scopes: - helm: The Helm CLI - pkg/lint: The lint package. Follow a similar convention for any package - `*`: two or more scopes Read more: - The [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) were the inspiration for this section. - Karma Runner [defines](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) the semantic commit message idea. ### Go Conventions We follow the Go coding style standards very closely. Typically, running `go fmt` will make your code beautiful for you. We also typically follow the conventions recommended by `go lint` and `gometalinter`. Run `make test-style` to test the style conformance. Read more: - Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting). - The Go Wiki has a great article on [formatting](https://github.com/golang/go/wiki/CodeReviewComments). If you run the `make test` target, not only will unit tests be run, but so will style tests. If the `make test` target fails, even for stylistic reasons, your PR will not be considered ready for merging. ## Troubleshooting To troubleshoot issues and get help from the community, search for your question in the list of issues labeled [`question/support`](https://github.com/helm/helm/issues?q=is%3Aissue%20state%3Aopen%20label%3Aquestion%2Fsupport) in the helm repository. If you are not able to find an issue that addresses your question, either open a new issue or add a comment to a related issue to share your experience. For more information about contributing and searching issues in the helm repository, see [Issues](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#issues) in _Contributing Guidelines_. ================================================ FILE: community/governance/README.md ================================================ --- sidebar_label: Governance title: Governance Introduction id: helm-governance sidebar_position: 9 --- The Helm governance details areas such as: * Maintainer responsibilities * Types of maintainers (Org and Project) * How elections occur * Decision making * Code of Conduct handling For the full detail on the Helm governance see the document [governance.md](/community/governance/governance). The Helm Org Maintainers are documented in [the community repo Maintainers file](/community/MAINTAINERS). ## Projects The Helm governance refers to projects for the Helm project. The following Helm projects currently exist: * **Helm Core**: The Helm CLI and packages * **Charts**: Responsible for chart-related tooling (e.g., chart testing) * **ChartMuseum**: The chart repository server * **Web and Docs**: The Helm websites All other repositories are either archived or owned by the org maintainers. ================================================ FILE: community/governance/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-governance" } } ================================================ FILE: community/governance/governance.md ================================================ --- sidebar_label: Rules title: Governance Rules slug: governance --- The following document outlines how the Helm project governance operates. ## The Helm Project The Helm project is made up of several codebases and services with different release cycles that enable users to create, distribute, and operate packages in Kubernetes. These codebases include: * Helm - the package manager * Charts - community curated charts * Chartmuseum - a chart repository with support for pushing charts, auth, and more * chart-testing - container based chart testing tools The services provided include: * Documentation for those who want to create, distribute, depend on, and operate packages * Public chart collaboration ## Maintainers Structure There are two levels of maintainers for Helm. The Helm org maintainers oversee the overall project and its health. Project maintainers focus on a single codebase, a group of related codebases, a service (e.g., a website), or project to support the other projects (e.g., marketing or community management). For example, the chart maintainers manage the charts repository and a few repositories that support charts. Changes in maintainership have to be announced on the [Helm mailing list](https://lists.cncf.io/g/cncf-helm). ### Helm Org Maintainers The Helm Org maintainers are responsible for: * Maintaining the mission, vision, values, and scope of the project * Refining the governance and charter as needed * Making project level decisions * Resolving escalated project decisions when the subteam responsible is blocked * Managing the Helm brand * Controlling access to Helm assets such as source repositories, hosting, project calendars * Handling code of conduct violations * Deciding what sub-groups are part of the Helm project * Overseeing the resolution and disclosure of security issues * Managing financial decisions related to the project Changes to org maintainers use the following: * There will be between 3 and 9 people. * Any project maintainer of any active (non-archived) Helm organization project is eligible for a position as an org maintainer. * No one company or organization can employ a simple majority of the org maintainers * An org maintainer may step down by emailing the org maintainers mailing list. Within 7 calendar days the [helm mailing list](https://lists.cncf.io/g/cncf-helm) needs to be notified of the change * Org maintainers MUST remain active on the project. If they are unresponsive for > 3 months they will lose org maintainership unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other org maintainers agrees to extend the period to be greater than 3 months * When there is an opening for a new org maintainer, any person who has made a contribution to any repo under the Helm GitHub org may nominate a suitable project maintainer of an active project as a replacement * The nomination period will be three weeks starting the day after an org maintainer opening becomes available * The nomination must be made via the [public Helm mailing list](https://lists.cncf.io/g/cncf-helm/) * When nominated individual(s) agrees to be a candidate for maintainership, the project maintainers may vote * The voting period will be open for a minimum of three business days and will remain open until a super-majority of project maintainers has voted * Only current project maintainers of active projects are eligible to vote * When the number of nominated individuals matches the number of openings each individual needs to have a yes vote from a super-majority of those that voted * When there are more individuals than open positions voting will use [Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) ranking on [CIVS](http://civs.cs.cornell.edu/) using the [Schulze method](https://en.wikipedia.org/wiki/Schulze_method) * When an org maintainer steps down, they become an emeritus maintainer Once an org maintainer is elected, they remain a maintainer until stepping down (or, in rare cases, are removed). Voting for new maintainers occurs when necessary to fill vacancies. Any existing project maintainer is eligible to become an org maintainer. The Org Maintainers will select a chair to set agendas and call meetings of the Org Maintainers. ### Project Maintainers Project maintainers are responsible for activities surrounding the development and release of code, the operation of any services they own (e.g., the documentation site), or the tasks needed to execute their project (e.g., community management, setting up an event booth). Technical decisions for code resides with the project maintainers unless there is a decision related to cross maintainer groups that cannot be resolved by those groups. Those cases can be escalated to the org maintainers. In some cases a groups of maintainers are responsible for more than one repo (e.g., charts maintainers managing the charts, chart-testing, charts-tooling). In other cases the maintainers are responsible for a single project (e.g., chartmuseum). To be considered active maintainers, it is required for maintainers to be associated with at least one active, non-archived project. If only listed on archived projects, they become emeritus project maintainers and are no longer eligible to become org maintainers. Project maintainers do not need to be software developers. No explicit role is placed upon them and they can be anyone appropriate for the work being produced. For example, if a repository is for documentation it would be appropriate for maintainers to be editors. Changes to maintainers use the following: * A maintainer may step down by emailing the [Helm mailing list](https://lists.cncf.io/g/cncf-helm) * Maintainers MUST remain active. If they are unresponsive for > 3 months they will be automatically removed unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other project maintainers agrees to extend the period to be greater than 3 months * New maintainers can be added to a project by a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) vote of the existing maintainers. Nomination can happen on the public [Helm mailing list](https://lists.cncf.io/g/cncf-helm) with voting on the private maintainer list or it can happen from a pull request to the appropriate record of maintainer for the project (e.g., OWNERS file) with voting happening through approvals on the pull request. * While nomination will happen on the public [Helm mailing list](https://lists.cncf.io/g/cncf-helm), voting will happen on the private maintainer list. * When a project has no maintainers the Helm org maintainers become responsible for it and may archive the project or find new maintainers * When maintainers no longer maintain active projects due to project archival or removal, they become emeritus maintainers unless they join another Helm project as maintainers. ## Decision Making at the Helm org level When maintainers need to make decisions there are two ways decisions are made, unless described elsewhere. The default decision making process is [lazy-consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). This means that any decision is considered supported by the team making it as long as no one objects. Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. When a consensus cannot be found a maintainer can call for a [majority](https://en.wikipedia.org/wiki/Majority) vote on a decision. Many of the day-to-day project maintenance can be done by a lazy consensus model. But the following items must be called to vote: * Enforcing a CoC violation (super majority) * Removing a maintainer for any reason other than inactivity (super majority) * Changing the governance rules (this document) (super majority) * Licensing and intellectual property changes (including new logos, wordmarks) (simple majority) * Adding, archiving, or removing subprojects (simple majority) * Utilizing Helm/CNCF money for anything CNCF deems "not cheap and easy" (simple majority) Other decisions may, but do not need to be, called out and put up for decision on the [Helm mailing list](https://lists.cncf.io/g/cncf-helm) at any time and by anyone. By default, any decisions called to a vote will be for a _simple majority_ vote. ## Code of Conduct The code of conduct is overseen by the Helm project maintainers. Possible code of conduct violations should be emailed to the project maintainers at cncf-helm-maintainers@lists.cncf.io. If the possible violation is against one of the project maintainers that member will be recused from voting on the issue. Such issues must be escalated to the appropriate CNCF contact, and CNCF may choose to intervene. ## DCO and Licenses The following licenses and contributor agreements will be used for Helm projects: * [Apache 2.0](https://opensource.org/licenses/Apache-2.0) for code * [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/legalcode) for documentation * [Developer Certificate of Origin](https://developercertificate.org/) for new contributions ================================================ FILE: community/hips/README.md ================================================ --- title: Helm Improvement Proposals (HIPs) --- To learn more about the purpose of HIPs and how to go about writing a proposal, please start reading [HIP 1](hip-0001.md). ## Markdown for Proposals Original proposal source should be written in Markdown format, and the format is described in HIP 1. Older proposals were often written in a more mildly restricted markdown format and can be found in the [archives](archives/README.md). ## Existing HIPs - [hip-0001: Writing a HIP](hip-0001.md) - [hip-0002: Pre-defined release dates for Helm](hip-0002.md) - [hip-0003: How Projects Join the Helm Organization](hip-0003.md) - [hip-0004: Document backwards-compatibility rules](hip-0004.md) - [hip-0005: Helm Org Maintainers and Deprecated Projects](hip-0005.md) - [hip-0006: OCI Support](hip-0006.md) - [hip-0007: Document and Track maintainer groups](hip-0007.md) - [hip-0008: Add descriptions to custom completions](hip-0008.md) - [hip-0009: Transitioning Security Team Members on Project Deprecation](hip-0009.md) - [hip-0010: Distributed responsibility for picking](hip-0010.md) - [hip-0011: CRD Handling in Helm 3](hip-0011.md) - [hip-0012: Helm 4 Development Process](hip-0012.md) - [hip-0014: Helm Triage Maintainers](hip-0014.md) - [hip-0015: Annotation for Images used by Helm Charts](hip-0015.md) - [hip-0017: Helm OCI MediaType Registration](hip-0017.md) - [hip-0018: Include repository URL and tarball digest in chart's release metadata](hip-0018.md) - [hip-0019: New annotations for displaying hook output](hip-0019.md) - [hip-0020: H4HIP: Charts v3 Enablement](hip-0020.md) - [hip-0021: Enhanced logging library for Helm](hip-0021.md) - [hip-0022: Wait With kstatus](hip-0022.md) - [hip-0023: Utilize Server Side Apply for installs/upgrades](hip-0023.md) - [hip-0024: Improve the Helm Documentation](hip-0024.md) - [hip-0025: Better Support for Resource Creation Sequencing](hip-0025.md) - [hip-0026: H4HIP: Wasm plugin system](hip-0026.md) ================================================ FILE: community/hips/archives/README.md ================================================ --- title: Proposal Archives --- Here lies all of the proposals written prior to the new standard: proposal-0001. They are retained here for historical purposes. ================================================ FILE: community/hips/archives/helm/distributed-search.md ================================================ --- title: "Proposal: Search of Distributed Repositories" --- Repositories in Helm were designed to be distributed. Instead of a central repository, the concept was for many distributed repositories to exist. This was modeled after [Debian APT](https://en.wikipedia.org/wiki/APT_(Debian)). To kick start charts, the charts repository was created. Eventually there were the stable and incubator repositories with Helm automatically adding the stable repository. To visually view repositories the monocular project was created which was used to launch what is now hub.kubeapps.com. This site enabled the search of the stable and incubator repositories. With Helm's use of stable repository and the UI search focusing on the community provided charts the community as a whole moved towards a more centralized approach. When companies or others wanted to share their projects they put them into the community charts. This proposal is about enabling distributed repositories by making them and their packages discoverable. ## A Single Search Location The goal of this is to have a search site and API that enables the search of many public repositories. Private repositories are a separate scope and can operate with existing tools. Hosting of these repositories is also a non-goal. The public repositories would need to provide: 1. Valid repositories to the repository specification 1. A security point of contact for the repository 1. A general point of contact for issues 1. Some level of automation around handling the quality of the packages. This is still to be determined and there are more details in the tooling section below. End users would then be able to query, via the web or API, for charts with an experience containing the following characteristics: * Can perform a general text search for packages that queries across all listed repositories * In the details of the response on a chart there will be directions on: * Adding the repository to a local helm installation * Installing the chart without adding the repository * Metadata on repositories, charts, and provider organizations. The idea is that organizations do not need to wait on the community charts team to publish releases or use that process. Instead, package hosting can happen in a distributed manner while the packages can be discoverable. _Note, under the current more centralized approach there is a level of trust with the charts due to the CNCF oversight and known team handling the day to day activities. While this model loosens and distributes trust we have a goal of trying to keep trust high._ ## Tools Provided For Repository Maintainers To enable distributed repositories the Helm project will provide the following tools: ### Repository Tools Basic tools needed to run a repository along with pointers to 3rd party services and applications that can be used instead. For example, Codefresh chart repositories, powered by Chartmuseum, and Artifactory would be shared as options. ### Documentation In addition to tooling there needs to be documentation that covers: * How to run a repository on GitHub, Gitlab, and other similar code hosting services * Details on signing charts and how to integrate that into workflows * Suggestions on leveraging CI as part of repository hosting * A clearly documented repository specification ### Analysis Tools To help, and possibly enforce, quality of charts we need to provide tools that can perform an analysis of charts to help validate quality. These tools exist for the stable and incubator charts today. They will be packaged in a manner others can consume and leverage within their workflows. Note, work on this step has already begun and [can be found on GitHub](https://github.com/kubernetes-helm/chart-testing). ## Outstanding Actions The following are outstanding actions that need to be worked out but can happen after the proposal is accepted: * [ ] Decide on and document the requirements for listed repositories ## Organizational Management The Charts Maintainers team will be the directly responsible party for this system and it will be hosted by the Helm project. ================================================ FILE: community/hips/archives/helm/helm-v3/000-helm-v3.md ================================================ --- title: Helm 3 Design Proposal --- This document contains a proposal for Helm 3. It assumes deep familiarity with Helm 2, and assumes that much of Helm 2's architecture will simply carry over without major change. ## Summary - Tiller is gone, and there is only one functional component (`helm`) - Charts are updated with libraries, schematized values, and the ext directory - Helm will use a "lifecycle events" emitter/handler model. - Helm has an embedded Lua engine for scripting some event handlers. Scripts are stored in charts. - State is maintained with two types of object: Release and a release version Secret - Resources created by hooks will now be managed - For pull-based DevOps workflow, a new Helm Controller project will be started - Cross platform plugins in Lua that only have a runtime dependency on Helm - A complementary command to `helm fetch` to push packages to a repository ## Purpose The design presented herein is intended to begin with the [user profiles](../../../../user-profiles.md) identified for helm and match as many of the [user stories](./011-user_stories.md) as could be accommodated ## The Basic Architecture Helm 3 is a single-service architecture. One executable is responsible for implementing Helm. There is no client/server split, nor is the core processing logic distributed among components. The reference implementation of Helm 3 is a single command-line client with no in-cluster server or controller. This tool exposes command-line operations, and unilaterally handles the package management process. The reference implementation has two distinct parts: 1. The command line façade, which translates commands, subcommands, flags, and arguments into a Helm operation 2. The Helm library, which provides the logic for executing all Helm operations. By design, the Helm library _must_ be usable as a standalone library. In Appendix A, we specify a second implementation of Helm 3 that provides a controller-oriented model with no client. The Helm Controller provides a CRD-based façade to receive commands, but executes them via the Helm library. With this simplification, the following list comprises the components of Helm v3's core implementation: * Charts * Chart repositories * `helm`, the CLI * An extension mechanism (Lua scripts stored in the chart) * A new in-cluster CRD: Release In this model, Tiller is removed and there are no operators or controllers that run in-cluster. ## Command/Flag Differences from Helm 2 There are a few major (breaking) changes to the Helm CLI planned: - The `-n` flag will be remapped across the board to `--namespace`, not `-name`. This is for consistency with `kubectl`, which added `-n` after Helm 2 was released. - `helm install` will _require_ a name, unless `--generate-name` is specified. This inverts the default behavior for Helm 2. - `helm serve` and `helm reset` will be removed - `helm delete` will be renamed to `helm remove`, though `helm delete` will remain an alias. - `helm inspect` will be renamed `helm show`, though `helm inspect` will remain as an alias. Other changes to commands are described in their relevant sections within this document. ## Table of Contents 1. [Charts](./001-charts.md) 2. [Event System](./002-events.md) 3. [State Storage](./003-state.md) 4. [Hooks](./004-hooks.md) 5. [Plugins](./005-plugins.md) 6. [Repositories](./006-repositories.md) 7. [Security Considerations](./007-security.md) 8. [Appendix A: A Helm Controller](./008-controller.md) 9. [Appendix B: What Is A Package Manager](./009-package_manager.md) 10. [Appendix C: Removed Sections](010-removed.md) 11. [Appendix D: User Stories](011-user_stories.md) ================================================ FILE: community/hips/archives/helm/helm-v3/001-charts.md ================================================ --- title: Charts --- The chart architecture remains largely unchanged. The following changes are proposed to the existing chart format: - The ext/ directory and supporting requirements - Library charts - Schemata for values files ## The ext/ directory The `ext/` directory is a reserved directory in v3 charts. It is reserved for placing extension scripts. In Helm 3, Lua scripts are placed into `ext/lua/`. Examples of Lua scripts can be found below. ### Sandboxing Model When a chart is loaded, the script `chart.lua` in `ext/lua` will also be loaded. All subchart `ext/lua/chart.lua` scripts will be loaded into the same runtime, and then the top-level (parent) chart's `init()` function will be executed. With this construction, the parent chart will (a) have access to the objects in the child charts, and (b) be responsible for initializing child charts. Library support will be provided for simplifying this process: ```lua function init(events) { -- Initialize subcharts subchart.init(events) -- Do other stuff event.on("pre-load", 0.5, function () { print("pre-load event") }) } ``` This design will make it possible for top-level charts to strategically overrride the behavior of subcharts, or (as above) simply use them as-is. By default, the chart sandbox will be prepared with a minimal set of built-in libraries. These libraries will not include network, os, or filesystem access. The module system (e.g. `require()`) will only allow in-chart libraries to be loaded. Additional core libraries, such as os, network, and filesystem access, can be loaded only of they are specified in the `ext/permissions.yaml` file. ```yaml lua: - network - io ``` The above permissions file asks that the Lua interpreter grant permission to the `network` and `io` libraries. This request will require user confirmation. When users install charts that ask for additional permissions, they will be prompted to allow: ```console $ helm install stable/ishmael Chart "ishmael" is requesting the following additional permissions: - network: Access the network - io: Access the local filesystem Allow? (y, yes, n, no) > ``` An additional `-y`,`--yes` flag will allow global acceptance of permissions. For fine-grained control, a `--accept-perms [strings]` may be provided to allow a user to set a specific set of perms. If the chart asks for others, the install will fail: ``` $ helm install stable/ishmael --accept-perms network,io ``` The above will succeed if: - The chart does not request any permissions - The chart requires one or both of `network` and `io`, but no other permissions The above will fail if: - The chart asks for any permissions other than `network` or `io` When a chart contains subcharts, the presence of a `permissions.yaml` file will result in a permissions prompt even if the subchart's Lua code is overridden. This is because the overriding logic does not preclude the loading of the libraries. ## Library Charts Helm 3 supports a class of chart called a "library chart". This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart's templates can only declare `define` elements. Globally scoped non-`define` content is simply ignored. Library charts may also contain scripts (`ext/`). However, overlays are ignored. Library charts are stored in `library/` in a Helm chart. Helm may hoist the library charts in subcharts into the parent chart. Library charts are noted in the `library:` directive in the `requirements.yaml`. ```yaml requirements: - name: apache version: 1.2.3 repository: http://example.com/charts - name: mysql version: 3.2.1 repository: http://another.example.com/charts libraries: - name: common version: "^2.1.0" repository: http://another.example.com/charts ``` Libraries are semver ranged. When versions are processed, the highest global match is used. An incompatibility results in a failed chart render or build. > [name=Matt Farina] > How would library charts work with chart repositories? Or, maybe they aren't listed. If they are, is there a way to make them non-installable? > [name=Matt Butcher] > We could put a flag in the chart.yaml which would make such > a chart uninstallable. I'm not sure, though, whether that's > necessary. Installing a library would be a no-op on Helm's > side, so we could just have Helm output an error any time > there are no objects to install (as Helm v2 does now). > [name=Nikhil Manchanda] > I would think that library charts would still be listed in repositories in case you wanted to fetch / inspect them. For usability, maybe having a flag that would not display libraries when searching would be a good idea? > > [name=Adnan Abdulhussein] > I think we need a Chart.yaml field. Helm and other tools might want to differentiate between these in different ways. For example, does it make sense to include a non-library chart as a library in a parent chart? `helm search` should distinguish library charts and `helm install` should refuse to install a library chart. Other UIs like Kubeapps will also need to distinguish between library charts and normal charts. > [name=Matt Butcher] > I'm leaning Adnan's way... but if we do that, it will mean that you can't use a regular chart as a library chart ever. They will differe in kind, not merely in the way the requirements.yaml references them. Is that okay? > > [name=Adnan Abdulhussein] > I posed using a non-library chart as a library chart as a question, because I think it could be valid to use a non-library chart just for its helpers. Helm doesn't have to force dependencies marked as libraries in requirements.yaml to be marked as a library in Chart.yaml (it could produce a warning, though). So, I think a normal chart can be used as a library chart, but not the other way around. The main restriction being: you can't install a library chart. ### Lua in Library Charts Lua in library charts will be loaded as normal, and the `init()` functions will be executed by `subcharts.init()` (if called). It is considered bad (but legal) practice to include event handlers in library charts. ## Schematized Values Files In Helm 2, there is no schema that is applied to a values file. For Helm 3, a [JSON schema](http://json-schema.org/specification.html) can be applied to a values file to validate it. The JSON schema file can be generated from the source values file (e.g. by introspecting the YAML), or it can be hand-authored. For the sake of consistency, the JSON schema file will be stored as YAML data. The schema is stored in `values.schema.yaml`, parallel to `values.yaml`. > [name=Adnan Abdulhussein] > I'm wondering if there's a better way to do this that wouldn't mean having to maintain a separate file? Personally, I like the idea of annotating a values.yaml file with comments above a parameter to add schema, but that probably means implementing our own format rather than taking something like JSON schema. > [name=Matt Fisher] > I don't think there's a better way to do this unless we made values.yaml strongly typed. > > https://github.com/kubernetes/helm/issues/2431 also goes into some thoughts around this proposal, which also agreed that a JSON schema approach would be best. > > [name=Matt Butcher] > Schema could be optional, in addition to being autogenerated by default. For example, consider a simple `values.yaml` file: ```yaml name: frontend protocol: https port: 443 ``` This can be schematized into something like this: ```yaml title: Values type: object properties: name: description: Service name type: string protocol: type: string port: description: Port type: integer minimum: 0 image: description: Container Image type: object properties: repo: type: string tag: type: string required: - protocol - port ``` > [name=Adnan Abdulhussein] > Added an example to demonstrate what an object key would look like. IMO this is quite verbose. On the other hand, we could easily share schema for certain things (e.g. resources for Pods). In many cases, the base types in a YAML file can be used to derive a base schema. Thus it may be desirable to automatically derive schemata if they are not supplied. ================================================ FILE: community/hips/archives/helm/helm-v3/002-events.md ================================================ --- title: Event-Driven Architecture --- This document describes an architectural transition inside of Helm. The client-server model of Helm 2 will be replaced with a single event-driven model. High level logic will _emit events_, while event responders will _handle events_. Some event handlers will be internal-only. Other event handlers will be exposed to the new lifecycle events subsystem (with its Lua engine). Those events will be open to extension. ## The Lifecycle Events Architecture Helm 3 is internally reorganized around an event model. Some events are internal only, while others are exposed to the Lua scripting engine. In this latter case, chart authors may script certain behaviors. During various phases of an operation (like install), Helm will execute pre-defined events. Charts will have an opportunity to respond to these events. For example, during `helm install`, the process my look something like this: 1. Load chart 2. Merge values 3. Emit `pre-render` event 4. Render templates 5. Parse resulting manifest into objects 6. Emit `post-render` event 7. Validate all objects 8. Call `pre-install` event 9. Install the manifests into Kubernetes 10. Exit #### Scripting Event Handlers An embedded Lua interpreter can load scripts at runtime, which makes it possible to write code which can be stored inside of a chart, but executed in answer to a lifecycle event. In Lua, executing a particular hook might look something like this: ```lua -- events is used to register event handlers. events.on("pre-render", 0.5, function (_) -- Accessing an object print("got chart " + _.chart.name) -- Mutating an object _.values.myvalue = "My Value" end) ``` The event handler format is: `events.on(_)`, where `_` is a variable pointing to a context object (see next section). ### Script locations Scripts are stored inside charts. They are stored in charts for the following reasons: - Charts remain self-contained. There is no need to negotiate on which plugins a chart needs. - Dependency resolution is relegated to the chart scope - The ordering problem is clearly solved (see below) if the scripts are located inside of the chart. Lua scripts are stored in a chart's `ext/lua` folder. The `ext/lua/chart.lua` file is loaded automatically along with the chart, and it may `require()` in other Lua scripts. The order of loading goes like this: 1. Chart is verified (if requested) against `.prov` file 2. Chart is loaded into memory 3. Chart.yaml is parsed, validated, and loaded 4. `ext/lua/chart.lua` files are parsed and loaded into a runtime 5. `chart-loaded` event is fired on chart that was loaded > Note: Values from `-f` and `--set` are coalesced prior to chart loading. Charts and subcharts may each have Lua. When events are triggered, the event handler will do a depth-first execution of the `chart.lua` files, ending with the topmost `chart.lua` file. ## The Context Object for Events Every event will receive a context, which will contain data about that event. In pseudo-code, the context stucture looks like this: ```lua context = { -- Loaded from chart.yaml chart = { version = function () return "v2" end, name = function () return "alpine" end, version = function () return "1.1.0" end, description = function() return "This is an example chart." end, keywords = function() return { "alpine", "utility", "debugging" } end, home = function() return "https://docs.helm.sh" end, sources = function() return { "https://github.com/helm/helm" } end, maintainers = function() return { name = "M Butcher", email = "mbutcher@example.com", url = "http://mbutcher.example.com" } end, icon = function() return "https://example.com/alpine.svg" end, appVersion = function() return "3.8" end, kubernetesVersions = function() return ">1.9.0" end, }, -- All user-specified. None of these is hard-coded values = { rbac = { enabled = true }, image = { name = "alpine", tag = "3.8"} }, -- These are supplied by the system and the user release = { name = function() return "my-alpine" end }, -- Information about the cluster that Helm is currently -- targeting capabilities = { helmVersion = function() return "3.0.0-alpha.1" end, -- Kubernetes version, as reported by Kubernetes kubernetesVersion = function() return "1.10.0" end, apiVersions = function() return { "v1", "batch/v1", "batch/v2", "batch/v2beta1", -- ... } end }, -- Files specified in the chart, exclusing templates and -- the contents of ext/ files = { { name = "config.json", data = "{}" } }, -- Any gotopl files. Depending on the phase, modification of -- these may have no impact. templates = { { name = "pod.yaml", data = "apiVersion: v1\nkind: Pod\nname: {{.Release.Name }}\n#..." } }, dependencies = { {name = "nginx", version = "1.2.0", repository = "https://example.com/charts"} }, -- Depending on phase, this may contain the list of already -- rendered objects. It may be empty. Depending on the -- phase, the contents of this may, on return, be preserved. objects = { { apiVersion = "v1", kind = "Pod", name = "my-alpine" } } } ``` Note that some of the properties in the context are functions. These are implemented as functions because their values are immutable. (The implementation of the function is informational pseudo-code, and is not the real implementation.) > [name=Matt Butcher] > Options for subcharts: We can either collapse them into one top-level context or nest subcharts in a `charts = { context::new() }` way. > > [name=Stuart P. Bentley] > As a Lua developer, I don't see any reason why immutable values should be specified as functions - it introduces an arbitrary distinction between access to mutable and immutable values, and I could still just clobber the function by assigning over it. If you want to enforce a read-only constraint on the immutable fields, the proper way to do it would be to use a table with a `__index` metamethod/table for the immutable values (and a `__newindex` metamethod to stop them from being overwritten). ## Events This is meant to be an exhaustive list of the events that will be emitted in Helm 3. The following are events by command. If a command is not present, then that command is not slated for inclusion in Helm 3. For each command, the events are presented in the order that they occur. ### Create Events for `helm create`: - `pre-create` - `post-create` The `pre-create` event will receive a minimal context with no chart information. A `post-create` will receive the initialized chart. After a post-create, the chart will be written to the filesystem. ### Dependency Build - `pre-dependency-build` - `post-dependency-build` The `pre-` hook will have access to the base chart's context. The `pre-` hook will be able to modify the `dependencies` object before dependencies are resolved or fetched. The `post-` hook will have access to the context as it appears after all dependencies have been resolved. The results of this hook are _not_ written to the filesystem. ### Dependency [List, Update] No other `helm dependency *` commands have hooks ### Delete - `pre-delete` The `pre-delete` event will receive a minimal context. It will not receive the chart. ### Fetch There are no defined hooks for this command ### Get [manifests, values] There are no defined hooks for these commands ### History There are no defined hooks for this command ### Home There are no defined hooks for this command ### Init There are no defined hooks for this command ### Inspect There are no defined hooks for this command ### Install - `pre-render` - `post-render` - `pre-install` #### pre-/post-render The pre- and post-render events are common across several operations. `pre-render` occurs before the contents of the `context.templates` have been rendered. The `context.objects` array is thus empty prior to `pre-render`. The `post-render` occurs after templates have been rendered to objects. Any further modifications to `context.templates` are ignored. The `context.objects` array will contain object representations of the things created after the template run. #### pre-install The `pre-install` event fires after `post-render`, and will receive the context returned from post-render. This event only fires on the install command, and thus is for install-specific work. ### Lint - `pre-render` - `post-render` - `pre-lint` The `pre-lint` event is fired after post-render, and is only fired for lint. ### Package - `pre-package` The `pre-package` hook is fired immediately before the package operation, and changes to context may be written to the packaged chart, but not onto the filesystem. ### Plugin [*] There are no defined hooks for this command ### Repo [*] There are no defined hooks for this command ### Rollback _This is dependent on a possible re-architecting of `helm rollback` that will no longer include a render phase._ - `pre-render` - `post-render` - `pre-rollback` The `pre-rollback` event fires after the post-render, and with the same context. This event only fires on rollback. ### Search There are no defined hooks for this command ### Template - `pre-render` - `post-render` - `post-template` (name may change) The `post-template` event fires after post-render and receives the same context. It fires immediately before the output of the command is written to STDOUT. ### Test - `pre-render` - `post-render` - `pre-test` - `post-test` - `failed-test` `pre-test` is executed immediately before the test, and it may modify the charts prior to testing. `post-test` runs after the test. `failed-test` runs only if the test is marked failed. ### Upgrade - `pre-render` - `post-render` - `pre-upgrade` - `post-upgrade` The `pre-upgrade` event fires after `post-render`, receiving the same context. `post-upgrade` fires after the chart has been submitted to the server. These two events only fire during upgrades. ### Verify There are no defined hooks for this command ### Version There are no defined hooks for this command ================================================ FILE: community/hips/archives/helm/helm-v3/003-state.md ================================================ --- title: State Management --- This document explains how state management works in absense of Tiller. Largely, it is the same model with a few changes to eliminate conflicts during race conditions. ## State Storage In Helm v3, state is tracked in-cluster by a pair of objects: - The Release object (CRD): Represents an instance of an application - The release version Secret: Represents a version of an instance of an application A `helm install` creates an Application, a Release, and a Secret. A `helm upgrade` requires an existing Application and Release (which it may modify), and creates a new Secret that contains the new values and rendered manifest. ### Namespacing Changes With Tiller gone, there is no reason to default to storing data in `kube-system`. Instead, Helm 3 will store release data _in the same namespace as the release's destination_. Release and release version Secrets are stored **in the same namespace as the installed release itself**. In other words, if we install `nginx` into namespace `foo`, then both the Release and release version Secret will also be installed into namespace `foo`. For example, if no namespace is specified: ```console $ helm install -n foo bar # everything, including Release and Secret is installed into default namespace ``` There is now only one releavant namespace, and the _tiller namespace_ goes away: ```console $ helm install -n foo bar --namespace=dynamite # installs release, releaseVersion, and un-namespaced charts into dynamite namespace. ``` As with Helm 2, if a resource explicitly declares its own namespace (e.g. with metadata.namespace=something), then Helm will install it into that namespace. But since the owner references do not hold over namespaces, any such resource will basically become unmanaged. > [name=Taylor Thomas] > This could be problematic for users. I know that at Nike we are using the cross-namespace functionality and we won't be the only ones > > [name=Adnan Abdulhussein] > Should we add the concept of a un-namespaced ClusterRelease which is created for charts that are cross-namespace? > > [name=Matt Butcher] > Maybe we should confirm whether or not owner references hold across namespaces. Cuz maybe this isn't actually an issue. ### The Release Object The release object contains information about a release, where a release is _a particular installation of a named chart and values._ This object describes the top-level metadata about a release. At minimum, there are two necessary pieces of data a Release must track: - The name of the release - The currently deployed version (release version Secret) of this release The release object persists for the duration of an application lifecycle, and is the owner of all release version Secrets, as well as of all objects that are directly created by the Helm chart. (These relationships may be represented by owner references.) With this change, release names can now be scoped to namespace, instead of globally scoped as they were with Helm 2. ### The release version Secret The release version Secret ties a release to a series of revisions (install, upgrades, rollbacks, delete). In Helm 2, revisions were merely incremental. Install created release v1, a subsequent upgrade went to v2, and so on. And in Helm 2, the Release and release version Secret were collapsed into one. For Helm 3, a Release has one or more release version Secrets associated with it. The Release object always describes the current head release. Each release version Secret describes just one version of that release. An upgrade operation, for example, will create a new release version Secret, and then modify the Release object to point to this new version. Rollback operations can use older release version Secrets to roll back a release to a previous state. A release version secret will have the following metadata and data fields: | field | description | | -------- | -------- | | type | Always `helm.sh/release-version` | | metadata.name | The release name plus the version ULID | | metadata.labels.version | The ULID of the release | | metadata.labels.release | The name of the release | | data.userValues| The user-specified values | | data.chartValues | The default values specified in the chart | | data.manifest | The rendered manifest from this release | | data.chartSource | The source of the original chart | | data.chartName | The name and version of the original chart | Given the above, the following operations are redescribed: - `helm get manifest` gets `data.manifest` - `helm get values` gets `data.userValues` - `helm get values --all` gets `data.userValues` and `data.chartValues` - `helm upgrade --reuse-values` uses `data.userValues`and `data.chartValues` The owner reference of the secret will be set to the Release object. ### Versions are ULIDs, not incremented integers Helm 2 used incremented integers for version numbering. This is changing. Version increments are ULIDs, not SemVer or integer counters. This is to prevent any race conditions when two revisions are pushed in near proximity. The version incrementor need not be negotiated with ULID; each new ULID is time-bound, but unique. ================================================ FILE: community/hips/archives/helm/helm-v3/004-hooks.md ================================================ --- title: Hook Annotations --- In Helm 2, hook annotations could be placed on various manifests, and those annotations would result in special treatment. In Helm 2, resources with hook annotations were unmanaged. In Helm 3, the owner reference is set on those, and they will be removed when the chart is deleted. There will be a way to override the management policy by setting an annotation for `helm.sh/hook-policy: unmanaged` > [name=Taylor Thomas] Would hooks be needed anymore with the new eventing > system? I think all we would need is something that can translate Helm v2 > hooks into the new events behind the scenes ================================================ FILE: community/hips/archives/helm/helm-v3/005-plugins.md ================================================ --- title: Plugins --- The plugin model will undergo a few changes in order to make it possible to support a broader range of features along a broader range of platforms. Helm will also have the ability to install a pre-defined set of custom plugins via `helm init`. * [Plugin Format](#plugin-format) * [Installing Plugins](#installing-plugins) ## Plugin Format ### Standard Plugins The existing plugin model (based on `exec` to local binaries) will continue to be supported. The current YAML format for `plugin.yaml` will be extended as follows: ``` name: "last" version: "0.1.0" usage: "get the last release name" description: "get the last release name" command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" # New part: platformCommand: - os: linux arch: i386 command: "$HELM_BIN list --short --max 1 --date -r" - os: windows arch: amd64 command: "$HELM_BIN list --short --max 1 --date -r" ``` The `platformCommand` section defines OS/Architecture specific variations of a command. The following rules will apply to processing commands: - If platformCommand is present, it will be searched first. - If both OS and Arch match the current platform, search will stop and the command will be executed - If OS matches and there is no more specific match, the command will be executed - If no OS/Arch match is found, the default `command` will be executed - If no `command` is present and no matches are found in `platformCommand`, Helm will exit with an error. ### Lua Plugins The existing Helm plugin mechanism has enabled numerous extensions to Helm (e.g., [here](https://docs.helm.sh/related/#helm-plugins) and [here](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)). While this has been useful there have been two shortcomings: 1. Many plugins are written as shell scripts assuming a POSIX environment and familiar linux-style userland. Helm, and Kubernetes as a whole, supports windows where these plugins don't work natively. 2. Other plugins are written in a compiled language (e.g., Go) or a general scripting language (e.g., Python) that have system dependencies in order to work. These can have version complications as well (e.g., a system Python of 3 and a plugin Python need of 2.7). Along with Helm supporting Lua for scripting chart extensions, it will support plugins in Lua. These plugins will only have a dependency on Helm to run and can be ported cross platform. Lua plugins _are executed separately_ from chart-based Lua scripts. The pattern used for executing Lua plugins mirrors the pattern for writing command-line applications. A `main()` function will be executed with access to STDIN, STDOUT, STDERR, and all command-line parameters and options. #### Lua Plugin Sandboxing Like charts, each plugin will be executed in an isolated Lua sandbox. Unlike chart scripts, plugins will be granted access to all core libraries, and will not require security prompts to accept. ## Installing Plugins A single plugin can be installed via `helm plugin install`. A set of plugins can also be defined in a yaml file and installed during the `helm init` process by using a flag called `--plugins ` where `file.yaml` looks like this: ``` plugins: - name: helm-template url: https://github.com/technosophos/helm-template - name: helm-value-store url: https://github.com/skuid/helm-value-store - name: helm-diff url: https://github.com/databus23/helm-diff ``` The `name` field primarily exists in the list of plugins to easily identify plugins in the file. It is not used for anything else and does not have a functional purpose. ================================================ FILE: community/hips/archives/helm/helm-v3/006-repositories.md ================================================ --- title: Repositories --- The following changes will be made to the repository subsystem: - The `helm serve` command will be removed - A new `helm push` verb will be added for pushing charts to a repository - The index file will be JSON instead of YAML > This document is in-progress and needs input from Chart Museum. ## Pushing Charts To A Repository Several registries have emerged with support for Helm charts including ChartMuseum and Quay (via Application Registries) along with extras built on top of other systems, such as object storage (e.g., see the [S3 Plugin](https://github.com/hypnoglow/helm-s3)). These registries are asking for and could benefit from a capability to push packages from the Helm client. To support registries there will be a `helm push` command that works in a similar manner to `helm fetch`. It will support different systems via the URI/URL scheme and provide a default implementation for HTTP(S). Other systems, such as S3, can implement an uploader via a plugin for schemes Helm does not provide an implementation for. > [name=Matt Farina] There very well may be additional work here around > registry search and pluggable or otherwise extendable authenication > mechanisms. > > [name=Adnan Abdulhussein] What would the default HTTP(S) implementation be? > [name=Matt Fisher] Adnan, would you mind clarifying your comment a little? > > [name=Adnan Abdulhussein] Sorry, the proposal mentions there will be a > default implemention for `helm push` to a regular HTTP(S) chart repository. > It's unclear to me how this would actually work. > > [name=Adnan Abdulhussein] Sounds like this is something that will be fleshed > out more in Josh's proposal, so I'll wait for that :) ## Repository v2 Specification Helm v3 will use a second version of the repository specification. For backwards compatibility, v1 of the specification will be supported but deprecated. The new version of the repository specification will make the following changes from version 1. First, the `apiVersion` field will be incremented to `v2`. This will signal a breaking change. Second, the file format will be changed from YAML to JSON. JSON is more memory efficient than YAML to parse. This is in part due to anchors and references in YAML. Third, there will be 2 types of files. The `index.json` file will hold the top level details about the repository. Alongside that there will be JSON files for each chart in the repository. These chart JSON files will contain the details about the revisions of the chart. The following two examples illustrate index and chart JSON files: ```json { "apiVersion": "v2", "entries": { "artifactory": { "ref": "https://kubernetes-charts-incubator.storage.googleapis.com/artifactory.json", "stable": { "created": "2017-07-06T01:33:50.952Z", "description": "Universal Repository Manager supporting all major packaging formats,\nbuild tools and CI servers.", "digest": "249e27501dbfe1bd93d4039b04440f0ff19c707ba720540f391b5aefa3571455", "home": "https://www.jfrog.com/artifactory/", "icon": "https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png", "keywords": [ "artifactory", "jfrog" ], "maintainers": [ { "email": "[redacted]", "name": "[redacted]" } ], "name": "artifactory", "sources": [ "https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view", "https://github.com/JFrogDev" ], "urls": [ "https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.2.0.tgz" ], "version": "5.2.0" } } } } ``` The example above is of the `index.json` file. An entry here has two properties. The `ref` property is the location of the chart JSON file. This can be either a relative URL path relative to the `index.json` file or an absolute path to the file. The `stable` property contains the details about the latest stable release of the chart. The example below is the `artifactory.json` file referred to in the index. The information for each version of the is listed under versions. This is in a similar format to the repository v1 `entries` for a single chart. The different in format is that an object with versions as keys is used instead of an array as seen in the v1 specification. ```json { "apiVersion": "v2", "versions": { "5.2.0": { "created": "2017-07-06T01:33:50.952Z", "description": "Universal Repository Manager supporting all major packaging formats,\nbuild tools and CI servers.", "digest": "249e27501dbfe1bd93d4039b04440f0ff19c707ba720540f391b5aefa3571455", "home": "https://www.jfrog.com/artifactory/", "icon": "https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png", "keywords": [ "artifactory", "jfrog" ], "maintainers": [ { "email": "[redacted", "name": "[redacted" } ], "name": "artifactory", "sources": [ "https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view", "https://github.com/JFrogDev" ], "urls": [ "https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.2.0.tgz" ], "version": "5.2.0" }, "5.1.0": { "created": "2017-05-03T23:49:01.558Z", "description": "Universal Repository Manager supporting all major packaging formats,\nbuild tools and CI servers.", "digest": "1ce86533fca59c77e52d32138c80c332c5102557fd79f9af4afbbd7e93b9f105", "home": "https://www.jfrog.com/artifactory/", "icon": "https://raw.githubusercontent.com/JFrogDev/artifactory-dcos/master/images/jfrog_med.png", "keywords": [ "artifactory", "jfrog" ], "maintainers": [ { "email": "[redacted", "name": "[redacted" } ], "name": "artifactory", "sources": [ "https://bintray.com/jfrog/product/JFrog-Artifactory-Pro/view", "https://github.com/JFrogDev" ], "urls": [ "https://kubernetes-charts-incubator.storage.googleapis.com/artifactory-5.1.0.tgz" ], "version": "5.1.0" } ... } } ``` ================================================ FILE: community/hips/archives/helm/helm-v3/007-security.md ================================================ --- title: Security Considerations --- This architecture for Helm is more secure than Helm 2 (and equally secure to Helm Classic). The following security goals are met by this proposal: - Helm now runs with the ID and permissions of the UserAccount or ServiceAccount executing the commands. - RBAC can now be applied to each user - On-the-wire security is as secure as the cluster is configured to be (e.g. if KUBECONFIG is set up for mTLS, that's what we use) - Auditability is now a feature of the cluster, as each chart is "created by" the user who runs the request - In-cluster CRDs can be secured with RBAC, too, providing access controls for releases. ================================================ FILE: community/hips/archives/helm/helm-v3/008-controller.md ================================================ --- title: "Appendix A: A Helm Controller" --- > This section is a placeholder until a detailed proposal is written. This section describes a second implementation of Helm. The goal of this implementation is to provide a controller/CRD façade for the core Helm features. _However, defining the specifics of this controller was deemed outside of the scope of this proposal, which focuses on the reference implementation of the Helm CLI_. A client-only Helm follows a push-based model. To facilitate a pull-based model, we can also create a Helm controller that provides a CRD facade, but uses the Helm library. It is suggested that this (a) be a core Helm project, but (b) is kept separately from the main Helm codebase. This controller accepts Chart and values configuration as a new `HelmRequest` CRD, and then provides the following operations: - Install - Upgrade - Delete - Get - List Just like the client, the controller will operate on Release and release version Secret. For that reason, the Helm CLI and the Helm CRD can be used in conjunction, and RBACs can even be applied to lock down certain features for one or the other. (For example, Helm CLI may be restricted to only read functions, while the controller can perform read and write operations) > [name=Adnan Abdulhussein] How will the controller apply a user's RBAC > permissions when installing a chart? Or is this not possible, and the > controller will need to be restricted using service accounts? [name=Matt > Fisher] It is not possible to apply a user's RBAC permissions when installing > a chart via this model, which is why we decided to remove Tiller in Helm 3. This implementation will necessarily have some limitations and restrictions that the client Helm does not; namely, it will not be able to handle large charts because there is a 1M limit to CRD size. It is also assumed that the controller model may not choose to implement a number of the client features, such as dry runs, repository management, chart creation, etc. ================================================ FILE: community/hips/archives/helm/helm-v3/009-package_manager.md ================================================ --- title: "Appendix B: What Is a Package Manager?" --- If Helm is "the package manager for Kubernetes", we need to have a common explanation of what we mean by "package manager". Helm's notion of package management is informed by _operating system package managers_ such as: - [APT](https://www.debian.org/doc/manuals/debian-reference/ch02.en.html) - [RPM](http://rpm.org/documentation.html) - [Homebrew](https://docs.brew.sh/) - [APK](https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management) - [Portage](https://wiki.gentoo.org/wiki/Portage) - [Snap](https://docs.snapcraft.io/core/) It is important to not overzealously compare Helm to programming language library package managers, as such systems have a fundamentally different goal. Package managers such as Apt, Homebrew, and RPM provide the following services: - They define a package format - They define a package repository architecture - They define a security model (signing, verification, etc) - They specify a programming langugage (or languages) to be used for management logic (e.g. shell scripts, Ruby) - They manage the installation, upgrade, and deletion of a package - They provide dependency resolution features and version management - They expose configuration options that the user may override - They start services (e.g. when installing a database, the database is started) and often provide tooling for administrators to manage those services (e.g. systemd/upstart/sysV init scripts) - They provide tools to search, list, and discover packages - They implement (or make it easy to implement) environment-specific (os, processor, distro) optimizations - They provide an opinion as to how to best construct and maintain packages - They surface documentation (typically via output during installation) Package managers tend to involve all of these because it is important in package management to keep external dependencies to a minimum. Consequently, if Helm is to fit into such a paradigm, it is natural that Helm will provide at least most, if not all of these. Helm is not a configuration management tool (such as Chef or Puppet). Helm does provide certain features of such systems, though. Helm's templating and configuration model is a common feature of configuration managers (and also of package managers). ================================================ FILE: community/hips/archives/helm/helm-v3/010-removed.md ================================================ --- title: "Appendx C: Removed Sections" --- The following parts of the proposal have been removed. ## Overlays An earlier draft included a provision for overlaying templates within charts. This section was removed once we realized that the same thing can be easily accomplished using the `post-render` event and some trivial Lua. This appendix will be removed before the final proposal. ## Chart.yaml refactored as Kubernetes resource An earlier draft proposed formatting Chart.yaml as a Kubernetes resource. However, it became evident that there was no intention of installing the Chart.yaml into the cluster, at which point it did not make sense to retain that functionality. ## Application CRD Earlier drafts contained information about implementing the Application CRD proposal as a feature of Helm. While there is a plan to support Application CRD in Helm, it will not be a required feature of Helm. For that reason, it has been removed from the proposal. ## Alternatives to Lua extensions The following alternatives were proposed: - Implement lifecycle event handlers as containers in-cluster - Reimplement Helm in Python|Ruby|TypeScript|JavaScript - Extend Plugins to be event handlers ================================================ FILE: community/hips/archives/helm/helm-v3/011-user_stories.md ================================================ --- title: Helm v3 User Stories --- This document lists [user stories](https://en.wikipedia.org/wiki/User_story) for the development of Helm's 3rd major version. The user stories here are not a complete set for Helm but those that build upon Helm 2. The stories are grouped by role as defined in the [User profiles](../../../../user-profiles.md). ## 1. Application Operator 1. As an application operator, I want to be able to pull charts from within the cluster so that I can manage multiple clusters without exposing details to the CI system 1. As an application operator, I want to be able to pull charts, so that my dev team can bootstrap local envs easily (e.g. w/Minikube or Docker) 1. In order to have a secure system as an application operator, I want Helm to install/upgrade/delete based on the user’s credentials 1. In order to have a secure system as an application operator, I want to be able to see who ran a particular install or other operation 1. In order to have a secure system as an application operator, I want out-of-the-box “easy security” 1. In order to have a secure system as an application operator, I want RBACs done for me 1. In order to have a secure system as an application operator, I want to audit what charts have been deployed 1. In order to have a secure system as an application operator, I want a pull model so that I can manage multiple private clusters from one authoritative source 1. In order to have a secure system as an application operator, I want to enable RBAC on an in-cluster controller so that I can prevent external changes from happening 1. In order to easily get started as an application operator, I want to easily install and use Helm ## 2. Application Distributor 1. As an application distributor, I want to develop charts using a template engine of my choice (e.g., Jinja, KSonnet, JSonnet) 1. In order to have reusability as an application distributor, I want to use common libraries to build charts 1. As an application distributor, I want to be able to override chart templates (e.g., those in dependency charts) 1. As an application distributor, I want to intercept rendered YAML/JSON and do last-mile modifications (e.g. insert or remove) 1. As an application distributor, I want lifecycle hooks for pre- and post-render operations 1. As an application distributor, I want to be able to do simple variable substitution in values.yaml (and reference in --set) ## 3. Application Developer 1. As a application developer, I want to automatically pull charts so that my local env looks like production ## 4. Supporting Tool Developer 1. As a supporting tool developer, I want to interact with Helm without using gRPC. 1. As a supporting tool developer, I want to write plugins that intercept hooks 1. As a supporting tool developer, I want to be able to write alternate back-ends (for deploying) ## 5. Helm Developer 1. TBD ================================================ FILE: community/hips/archives/helm/helm-v3/012-chart-dev-stories.md ================================================ --- title: Chart v3 User Stories --- This document contains user stories for Helm3 Charts. User stories provide guidance, but are not necessarily a list of requirements. All stories in this document are implicitly prefaced with "As a Chart Developer..." and are of the form "As a _ROLE_ I want _TASK_ so that _GOAL_. ## General - I want to re-use Helm 2 charts so that I don't have to rebuild the same thing - I want to create charts the Helm 2 way so that I can continue developing the way I have been - I do not want to have to understand all the details of every subchart I use so that I can compose complex applications quickly ## Extensions/Lua These all assume a Lua engine, and describe things to be done in Lua scripts. See the current [events](002-events.md) and [chart structure](001-charts.md) proposals ### Values - I want programmatic access to subchart values so that I can access defaults - I want access to modify subchart values so that I can explicitly set a value for a subchart - I want late access to a subchart's values so that I can discover any values that a subchart's scripts computed - I want to use Lua to validate values before templates are rendered so that I can alert users to unexpected values before install fails - I want to use Lua to modify values in subcharts programmatically so that I can expose a top-level set of values and computer subchart values - I want to use Lua to alter subchart values so that I can read the values of one subchart and rewrite the values in another subchart (e.g. configuring a proxy based on the settings for a database or web server) - I want to be able to intercept values in a top-level chart before _and_ after a subchart's event handler executes so that I can pre-seed data, let the subchart calculate results, and then retrieve and use those results. (e.g. SSL certificate generation) ### Templates - I want to define template functions in Lua so that I can easily write custom template functions - I want to render templates using a different template engine so that I can use my preferred template engine * Option A: Template engine implemented in pure Lua * Option B: Template engine invoked via `exec` call - I want to intercept a template before it is rendered and be able to alter it so that I can dynamically replace parts of a template (example: regexp replace one template function/include with another) - I want to replace a template in a subchart before it is rendred so that I can rewrite part of a chart dynamically ### Rendered Manifests - I want to modify a generated manifest so that I can insert additional information (e.g. Istio sidecar) - I want to delete a generated manifest prior to it being loaded so that I can prevent an object from being created (e.g. subchart creates a manifest I don't want) - I want to add a new manifest post-render so that I can create an object based on the results of a render process (e.g. RBAC generation, service generation, storage class generation) ### Feature Discovery - I want to query Kubernetes to see if a CRD exists so that I can decide whether to include a CRD definition - I want to query whether a cluster supports RBAC so that I can decide whether to add RBAC rules - I want to query for StorageClass so that I can pick an appropriate one for my PVC - I want to look up DNS address (e.g. service discovery) so that I can find an endpoint, IP, or URL before installing/upgrading ### Events - I want to declare a function that responds to an event (e.g. "render") so that I can modify a chart/values at a particular point in the lifecycle - I want to allow subcharts to run their event handlers by default so that I don't have to read all of the subcharts to know what they do - I want to be able to turn off a subchart's lifecycle event by name so that I can disable a particular event handler - I want to turn off all event handlers for a chart so that I can prevent it from intercepting any events - I want to have an opportunity to initialize my chart's code every time it is loaded so that my chart can be initialized into a known state consistently - I want to be able to perform installation-specific actions before an install so that I can do custom install logic - I want to be able to perform post-installation actions so that I can set up an application (or notify the user about an installation) after the app has been submitted to Kubernetes - I want to be able to do upgrade-specific logic before the upgrade has been submitted to Kubernetes - I want to be able to do post-upgrade logic so that I can set up an app or notify a user - I want to do custom logic before an app is deleted so that I can prepare for a deletion - I want to do custom logic after a deletion so that I can ensure that a teardown is successful (e.g. if no other apps are using a namespace, delete teh namespace; if no other apps are using a CRD, delete the CRD definition...) - I want to be able to declare custom logic that determines whether an installed or upgrade application is considered _ready_. - I want to be able to perform specific logic when an application is considered ready. ### Lua Libraries and Access - I want to be able to break my Lua script into multiple files so that I can organize my code - I want to be able to import code from subcharts so that I can re-use existing code - I want to import existing pure Lua libraries that are stored in charts - I want to use standard Lua libraries that do not have access to network or filesystem - I want to optionally use network and filesystem libraries if approved by the user so that I can perform IO within a chart ## Library Charts - I want to use charts as template definition libraries so that I can re-use common template code - I want to use charts as containers for Lua libraries so that I can re-use Lua code ## Additional Considerations - There are charts like OpenStack that have dozens of subcharts (and sub-subcharts) ================================================ FILE: community/hips/archives/helm/helm-v3/research/package-manager-ux.md ================================================ --- title: Package Manager UX --- This document is for usability research on the UX and interaction interface for other package managers. (This re-creates some of the work done during the Helm 1 and Helm 2 planning cycles.) ## A Goal of Helm: Follow Existing Patterns To reduce the cognitive overhead of Helm, one of Helm's UX goals is to follow the patterns set down by other package managers. Matching the UX of `kubectl` is of secondary importance. In practice, this plays out as follows: - When considering Helm's package managemet operations, Helm _should_ follow the patterns and practices of other package management tools. - When working with Kubernetes-specific concepts (such as namespaces, pods, tunnels, etc.), Helm _should_ follow the patterns and practices of `kubectl` or other popular Kubernetes tools. - In more general circumstances, Helm _should_ follow the _de facto_ patterns found in contemporary Linux/UNIX tooling. Helm _should not_ follow the Plan9/Go patterns that are not broadly implemented in UNIX/Linux (e.g. `-long`). That Helm is implemented in Go does not _ipso facto_ mean that Helm must follow the opinions of a very small group of developers over the opinions of the vastly larger UNIX community. ## Package Managers and Their Characteristics The following table represents a summary of command line tooling for popular package managers. Package managers considered came in one of two types: _OS_ types install application/tool packages onto operating systems. _Lang_ types install language-specific packages (lirbaries, tools) into appropriate environments. | Tool | Type | Cmd | Install | Upgrade | Delete | Create | Repo Update | Search | About Pkg | | ---- | ---- | ------ | ------- | ------- | ------ | ------ | ----------- | ------ | --------- | | apt-get | OS | y | install | upgrade | remove | - | update | apt-cache search | apt-cache show | | yum | OS | y | install | update/upgrade | remove/erase | - | - | search | info | | brew | OS | y | install | upgrade | uninstall | create | update | search | info | | pacman | OS | n | --sync | --upgrade | --remove | - | --refresh | --query | --query | | emerge | OS | n | - | - | --unmerge | - | --sync | --search | --search | | choco | OS | y | install | upgrade | uninstall | new | ~update~ | search | info | | npm | Lang | y | install | update/upgrade | uninstall/rm | init/create | - | search | view/info/show | | pod | Lang | y | install | update | - | spec create | - | search | search | | pip | Lang | y | install | install -U | uninstall | - | - | search | show | | composer | Lang | y | install | update | remove | init | - | search | show | | kubectl | - | y | create | apply | delete | create | - | - | - | | helm 2 | CN | y | install | upgrade | delete | create | update | search | inspect | Note that `kubectl` is included for reference, though it is _not_ a package manager, and is not weighed into the results below. Other package managers looked at, but not deemed popular enough to be considered influencers: Mix (erlang), Cargo (Rust), Dep (Go), Glide (Go), GoFish (OS), CPAN (perl), Yarn (JavaScript), APK (Alpine Linux). Other than CPAN, we saw no major divergence from the table above (though we saw a few cases where `add` was used instead of `install`). ### Apt - Apt uses multiple tools. `apt-get` and `apt-cache` are the most frequently used. - Apt does not layer subcomments. There are only direct subcommands and flags - Create new packages with other tools ### Yum - Yum layers subcommands, but without a consistent pattern: - `yum clean headers` (NOUN VERB NOUN) - `yum version groupinfo` (NOUN NOUN NOUN) - `yum groups install` (NOUN NOUN VERB) - Yum syncs with remote repositories based on local configuration - Create new packages with RPM commands ### Brew No notes ### Pacman Arch Linux uses `pacman`, which uses options such as `--refresh` and `--sysupgrade` to change the behavior of its core commands (which are also specified as options). Commands in `pacman` are usually given as short options (where capital letters represent the commands): for example, to perform a system upgrade, one will usually run `pacman -Syu`, which is short for `pacman --sync --refresh --sysupgrade`. (To only refresh the package database, one instead runs `pacman -Fy`, short for `pacman --files --refresh`.) - `pacman` updates from remote repos as needed (when specified to do so by the user, usually as part of a `--sync` installation/upgrade operation). - Search is multi-modal, being able to describe packages as well as listing them ### Emerge (Portage) - Create new packages with `ebuild` - `emerge PKG` handles install and upgrade. In other words, installation is the default action ### choco (Chocolatey) - The `update` command is deprecated, and future version will sync differently ### NPM - Fun fact: `npm isntall` is an alias for `npm install`, as is `npm add` and `npm i`. - Update, upgrade, and up are aliases - Uninstall, remove, rm, and un are aliases - view, info, and show are aliases ### pod (cocoapods) - Supports subcommands, usually as NOUN NOUN VERB (`pod spec create`), but occasionally NOUN NOUN NOUN (`pod trunk info`) - I cannot find docs on how to remove a pod ### pip - A few commands have subcommands in the form NOUN NOUN VERB (`pip config get`) ### Composer Composer is the PHP package manager. - `composer` has only one level of commands, but uses flags for subcommands (`composer config --list`). - The exception to the above, though, is the `compoers global` command, which is NOUN NOUN VERB or NOUN NOUN NOUN. ### kubectl `kubectl` is not a package manager, but has subcommands that are similar to package managers - `create` combines generation and installation - Upgrading can be done several different ways, each with a separate verb: `apply`, `edit`, `patch`, `convert`, and `replace` - There is no standard pattern to `kubectl`'s subcommands: - `kubectl get` (NOUN VERB) - `kubectl logs` (NOUN NOUN) - `kubectl config view` (NOUN NOUN VERB) - `kubectl config current-context` (NOUN NOUN NOUN) - NOTE: It is claimed that `kubectl` uses NOUN VERB NOUN (`kubectl get pod foo`), but this is a misunderstanding: the kind argument is not a command component. It's an argument that depends on what kinds are installed. ## Analysis of Results Commonalities between package managers: - All of the tools except for `emerge` made install/upgrade/delete top level commands. (emerge is simpler; install is the default if no command is specified). - Many of these tools also had subcommands as well (e.g. `pod`, `composer`, `yum`), but did not choose to fold all commands into a particular pattern. - For subcommands, the `NOUN NOUN VERB` pattern was the most common, but definitely not the only option. - The only discernable pattern used for seperating top level and multi-level commands is: "popular operations are top level" - Not all the commands on top-level dealt with the same concepts (e.g. one command may operate on packages, while another operates on files). - Aliases are supported in a few tools - `upgrade` is general preferred over `update` for describing the process of installing a newer version of an existing package - For package managers that support synchronizing a local cache with a remote auhtority, `update` is the preferred term, in spite of its ambiguity. - For the package managers that support scaffolding out new packages, `create` is the most widely used term. - `show` and `info` are about equal in representation for showing package information. `inspect`, which Helm uses, is not represented in any other package manager. - For deleting a package, `remove` is the most common term, followed closely by `uninstall`. - None of the examined systems had more than three layers of commands: `CMD SUBCMD SUBCMD`. ## Recommendations for Helm 3 The following commands should be changed (with the old name aliased to the new name): - `helm delete` should be renamed `helm remove` - `helm inspect` should be renamed `helm show` While there is little to draw from, it might be prudent to rename `helm fetch` to `helm download`. After analyzing other package managers, it does not appear that grouping commands into "logical subgroups" is an appropriate action. No other tools that we could find do this. Subgroup usage is _ad hoc_. The convention Helm 2 used (subgroups for less popular commands) _appears_ to be the convention used industry-wide. No other changes are necessary for Helm to fit in with the common idioms found in package managers. _Note:_ The Helm 2 `reset` command is no longer present in Helm 3. Earlier discussions about renaming it are no longer relevant. ================================================ FILE: community/hips/archives/monocular/1.0-improvements.md ================================================ --- title: "Proposal: Monocular 1.0 - improvements and redefining project focus" --- Monocular was created to provide a simple interface to browse and discover charts in the stable and incubator community repositories, and a running instance of Monocular is setup at hub.kubeapps.com (originally kubeapps.com). As the Charts project moves to a [more distributed repository model](/community/hips/archives/helm/distributed-search), an instance of Monocular will be available at hub.helm.sh to serve as a home for community-contributed charts from multiple repositories. The current codebase has outgrown the initial requirements for the Monocular project, and this proposal is about making Monocular more robust and scalable, and redefining the focus of the project to suit the needs of the CNCF Helm Hub. ## Replacing the Monocular API server The current Monocular API server is a monolithic Go-based server which handles the periodic syncing and ingestion of charts, and serves a REST API to read chart data, manage configured repositories and handle in-cluster chart installations and management. This architecture has shown issues with scalability and flexibility that can be improved by splitting services out into separate components. The [Kubeapps project](https://github.com/kubeapps/kubeapps) includes components that will be contributed back to Monocular to achieve this. ### Storing chart metadata in a database In the current Monocular implementation, chart metadata is cached in memory. This has the requirement for repository syncing to be part of the API server process and also presents issues when scaling out the API server as each process holds an independent cache of the chart metadata. This will be changed to storing chart metadata in a database, so that each API server instance can retrieve the chart metadata from the same consistent store. MongoDB will be used to store the chart metadata as the NoSQL model makes it easy to dump chart metadata directly from repository indexes. ### Chartsvc [Chartsvc](https://github.com/kubeapps/kubeapps/tree/master/cmd/chartsvc) is a small Go API server built to read and serve chart information from a MongoDB database. This service will replace the existing API server for fetching metadata about charts. ### Syncing chart repositories One of the biggest scalability issues in Monocular today is the implementation for syncing chart repositories in the API server. Since the syncing is tied to the running of the API server, it is difficult to manage and debug when something goes wrong during the sync process. Bugs and issues can lead to the API server crashing. It is also not possible to manually trigger a repository sync. The [chart-repo](https://github.com/kubeapps/kubeapps/tree/master/cmd/chart-repo) tool can be run as a background job to populate a MongoDB database with chart metadata from a particular chart repository. Each configured chart repository will have a separate background job run periodically to sync the chart metadata. [The AppRepository Kubernetes CRD and controller](https://github.com/kubeapps/kubeapps/tree/master/cmd/apprepository-controller) will be used to manage the configured chart repositories and create [Kubernetes CronJobs and Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) to orchestrate the background jobs to run the chart-repo tool described above. This will make Kubernetes the default environment for operating Monocular, though it is possible to replace this component to orchestrate the background jobs in other ways on other platforms. ## Removing in-cluster support Monocular currently includes a basic implementation of in-cluster application management. If Monocular is deployed within a Kubernetes cluster, a feature flag can be enabled to allow the installation of charts directly through the UI. Providing a good solution for deploying and managing apps in-cluster is an orthogonal user experience to a public search and discovery site. There is other tooling that can support this usecase better (e.g. Helm CLI, [Kubeapps](https://github.com/kubeapps/kubeapps), [RedHat Automation Broker](https://blog.openshift.com/automation-broker-discovering-helm-charts/)). To focus on the CNCF Helm Hub user experience, support for in-cluster features will be dropped. A v0.7 (the current Monocular version) branch will be created prior to these changes so that this functionality can be used and supported for some time until users have fully migrated to another tool. ================================================ FILE: community/hips/hip-0001.md ================================================ --- title: Writing a HIP sidebar_label: "0001: Writing a HIP" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0001 | Writing a HIP | Matthew Fisher | 2020-08-13 | process | accepted | ## Abstract A HIP is a Helm Improvement Proposal. It is a design document providing information to the Helm community, or describing a new feature for a Helm project or its processes or environment. The proposal should provide a concise technical specification of the feature and a rationale for the feature. We intend HIPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into the project. The proposal author is responsible for building consensus within the community and documenting dissenting opinions. The system is heavily influenced by Python's Enhancement Proposal (PEP) system, hence the name. Given that Helm is a much (MUCH) smaller project than Python, there are a few changes in the HIP workflow to make it a looser format for proposals, most notably the lack of proposal "editors", a BDFL, and a much smaller review & resolution cycle. Because the proposals are maintained as markdown files in a versioned repository, their revision history is the historical record of the proposal. ## Audience The typical primary audience for proposals are the project maintainers for each Helm project, as well as the Helm project's org maintainers. However, other parts of the Helm community may also choose to use the process (particularly for informational proposals) to document expected conventions and to manage complex design coordination problems that require collaboration across multiple projects. ## HIP types There are three kinds of proposals: 1. A **feature** proposal describes a new feature or implementation for the Helm project. It may also describe an interoperability standard that will be supported by the Helm project. 1. An **informational** proposal describes a Helm design issue, or provides general guidelines or information to the Helm community, but does not propose a new feature. Informational proposals do not necessarily represent a Helm community consensus or recommendation, so users and implementers are free to ignore informational proposals or follow their advice. 1. A **process** proposal describes a process surrounding the Helm project, or proposes a change to (or an event in) a process. Process proposals are like feature proposals, but apply to areas other than the Helm project itself. They may propose an implementation, but not to Helm's codebase; they often require community consensus. Unlike informational proposals, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Helm development. ## HIP workflow ### Start with an idea The proposal process begins with a new idea for the Helm project. It is highly recommended that a single proposal contain a single key proposal or new idea. Small enhancements or patches often don't need a proposal and can be injected into a project's development workflow with a patch submission to the project's issue tracker. The more focused the proposal, the more successful it tends to be. As per Helm's governance, the project maintainers reserve the right to reject proposals if they appear too unfocused, too broad, or incomplete. If in doubt, split your proposal into several well-focused ones, or explain your proposal more clearly. Each proposal must have a champion -- someone who writes the proposal using the style and format described below, shepherds the discussions in the appropriate communication channels, and attempts to build community consensus around the idea. The proposal champion (a.k.a. author) should first attempt to ascertain whether the idea is proposal-able. Posting to the [cncf-helm][] mailing list is the best way to go about this. Vetting an idea publicly before going as far as writing a proposal is meant to save the potential author time. Many ideas have been brought forward for changing Helm that have been rejected for various reasons. Asking the Helm community first if an idea is original helps prevent wasting time on something that is guaranteed to be rejected based on prior discussions (searching the internet does not always do the trick). It also helps to make sure the idea is **applicable to the entire community and not just the author**. Just because an idea sounds good to the author does not mean it will work for most Helm users in most areas where Helm is used. Once the champion has asked the Helm community as to whether an idea has any chance of acceptance, a summary of the proposal should be presented to [cncf-helm][]. This gives the author a chance to flesh out the proposal as a high quality, well-formatted proposal, and to address initial concerns about the proposal. ### Submitting a HIP Following a discussion on [cncf-helm][], the proposal should be submitted as a proposal via a [GitHub pull request][pr]. The proposal must be written in proposal style as described below, else it will fail review immediately (although minor errors may be corrected by the maintainers). The standard HIP workflow is: - You, as the proposal author, fork the helm/community repository and create a new proposal - Proposals are written in [Markdown][markdown] - Push your proposal to your GitHub fork and [submit a pull request][pr]. Once the review process is complete, the reviewers will approve the proposal by commenting on the proposal with a "Looks good to me" ("LGTM" for short) and merge the proposal. (note that this is not the same as accepting your proposal!) The reviewers will not unreasonably deny a proposal. Reasons for denying proposal status include duplication of effort, being technically unsound, not providing proper motivation, not addressing backwards compatibility, or not in keeping with Helm's design. The core maintainers can be consulted during the approval phase. Once approved, proposal authors are responsible for collecting community feedback on a proposal before submitting a feature that satisfies the proposal for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate meetings for the topic, having the proposal author accept private comments in the early design phases, setting up a wiki page, etc. proposal authors should use their discretion here. ## What belongs in a successful HIP Each HIP should include the following parts: 1. Preamble - YAML style headers containing metadata about the proposal, including the proposal number, a short descriptive title, the author names, its current status, etc. 1. Abstract - a short (~200 word) description of the technical issue being addressed. 1. Specification - The technical specification should describe the syntax and semantics of any new feature. If the proposal describes a standard, the specification should be detailed enough to describe how other community members may re-implement the standard in their product. 1. Motivation - The motivation is critical for proposals that want to change Helm in a significant way. It should clearly explain why existing features are inadequate to address the problem that the proposal solves, as well as who and what profiles/roles are impacted by this proposal. Proposal submissions without sufficient motivation may be rejected outright. 1. Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other projects. 1. Backwards Compatibility - Helm projects follow [Semantic Versioning][semver]. Therefore, all proposals that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The proposal must explain how the author proposes to deal with these incompatibilities. Proposal submissions without a sufficient backwards compatibility treatise may be rejected outright. 1. Reference Implementation - The reference implementation must be completed before any proposal is given status "final", but it need not be completed before the proposal is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. The final implementation must include test code and documentation appropriate for the Helm project's reference or the community at large. ### Preamble Each proposal must begin with a [YAML][yaml] style header preamble. The headers must appear in the following order: Headers marked with "*" are optional and are described below. All other headers are required. ```yaml --- hip: title: "" authors: [ "" ] created: "2020-08-13" type: "" status: "" * helm-version: "" * requires: [ ] * replaces: * superseded-by: --- ``` The `authors` header lists the names, and optionally the email addresses of all the authors/owners of the proposal. The format of the author header value must be ```yaml authors: [ "John Doe ", "Jane Doe " ] ``` If the email address is included, and ```yaml authors: [ "John Doe", "Jane Doe" ] ``` If the address is not given. The `created` header records the date that the proposal was published to the Helm project on Github. The header should be in [RFC 3339][rfc3339] format, e.g. 2020-08-13. Proposals will typically have a `helm-version` header which indicates the version of Helm that the feature will be released with. Proposals without a `helm-version` header indicate interoperability standards that will initially be supported through external libraries and tools, and then supplemented by a later proposal to add support to the project's client library or Command Line Interface. Informational and process proposals do not need a `helm-version` header, and this header can be added after the implementation has been shipped and the proposal is marked as "final". Proposals may have a `requires` header, indicating the proposal numbers that this proposal ends on. The `type` header specifies the type of proposal: feature, informational, or process. The `status` header specifies which state the proposal is in. A proposal always begins in "draft" status, and the other statuses are explained below. Proposals with the `superseded` status may also have a `superseded-by` header indicating that a proposal has been rendered obsolete by a later document; the value is the number of the proposal that replaces the current document. The newer proposal must have a `replaces` header containing the number of the proposal that it rendered obsolete. ### Auxiliary files proposals may include auxiliary files such as diagrams. Such files must be named proposal-XXX-YY.ext, where "XXX" is the proposal number, "YY" is a serial number (starting at 01), and "ext" is replaced by the actual file extension (e.g. "png"). ## Sample template If you intend to submit a HIP, it is highly recommended to use this template to ensure that your HIP submission won't be automatically rejected because of form. ### How to use this template To use this template you must first decide whether your HIP is going to be an informational, process, or feature HIP. Most HIPs are of type "feature" because they propose a new feature for the Helm project or client library. Once you've decided which type of HIP yours is going to be, make a copy of this file and perform the following edits: - Do NOT change the `hip: 9999` header since you don't yet have a HIP number assigned... Yet. This is to prevent merge conflicts with other HIPs. - Change the `title` header to the title of your HIP. - Change the `authors` header to include your name(s), and optionally your email address(es). Be sure to follow the format carefully: your name must appear first, and it must not be contained in parentheses. Your email address may appear second (or it can be omitted) and if it appears, it must appear in angle brackets. It is okay to obfuscate your email address. - Change the `created` header to the current date, following [RFC 3339][rfc3339] format. - For feature HIPs, change the `type` header to "feature". - For informational HIPs, change the `type` header to "informational". - For process HIPs, change the `type` header to "process". - Do NOT change the `status` header from `draft`. - For feature HIPs, if your feature depends on the acceptance of some other currently in-development HIP, add a `requires` header right after the `status` header. The value should be the HIP number of the HIP yours depends on. Don't add this header if your dependent feature is described in a "final" HIP. - Add a `replaces` header if your HIP obsoletes an earlier HIP. The value of this header is the number of the HIP that your new HIP is replacing. Only add this header if the older HIP is in "final" form, i.e. is either accepted, final, or rejected. You aren't replacing an older open HIP if you're submitting a competing idea. - Now write your abstract, rationale, and other content for your HIP, replacing all this gobbledygook with your own text. - Update your references section. ```markdown --- hip: 9999 title: "" authors: [ "" ] created: "2020-08-13" type: "feature" status: "draft" --- ## Abstract A short (~200 word) description of the technical issue being addressed. ## Motivation Clearly explain why the existing design is inadequate to address the problem that the HIP solves. ## Rationale Describe why particular design decisions were made. ## Specification Describe the syntax and semantics of any new feature. ## Backwards compatibility Describe potential impact and severity on pre-existing code. ## Security implications How could a malicious user take advantage of this new feature? ## How to teach this How to teach users, new and experienced, how to apply the HIP to their work. ## Reference implementation Link to any existing implementation and details about its state, e.g. proof-of-concept. ## Rejected ideas Why certain ideas that were brought while discussing this HIP were not ultimately pursued. ## Open issues Any points that are still being decided/discussed. ## References A collection of URLs or materials used as references through the HIP. ``` ## Proposal review & resolution Once the authors have completed a proposal, they may request a review for style and consistency from the project maintainers. The final authority for proposal approval is the project maintainers responsible for the project the proposal is aimed at. However, whenever a new proposal is put forward, any project maintainer that believes they are suitably experienced to make the final decision on that proposal may offer to review the proposal, and they will have the authority to approve (or reject) that proposal. Individuals taking on this responsibility are free to seek additional guidance from other project maintainers at any time, and are also expected to take the advice and perspectives of other project maintainers into account. Such self-nominations are accepted by default, but may be explicitly declined by the project or org maintainers. Possible reasons for the maintainers declining another maintainer's review include, but are not limited to, perceptions of a potential conflict of interest (e.g. working for the same organisation as the proposal submitter), or simply considering another potential maintainer to be more appropriate. If project maintainers (or other community members) have concerns regarding the suitability of a reviewer for any given proposal, they may ask the org maintainers to review the case. To allow gathering of additional design and interface feedback before committing to long term stability for a feature or client library API, a HIP may also be marked as "provisional". This is short for "provisionally accepted", and indicates that the proposal has been accepted for inclusion in the reference implementation, but additional user feedback is needed before the full design can be considered "final". Unlike regular accepted proposals, provisionally accepted proposals may still be rejected **even after the related changes have been included in a project's release**. Wherever possible, it is considered preferable to reduce the scope of a proposal to avoid the need to rely on the "provisional" status (e.g. by deferring some features to later proposals), as this status can lead to version compatibility challenges in the wider Helm ecosystem. A proposal can also be assigned the status "deferred". The proposal author or a maintainer can assign the proposal this status when no progress is being made on the proposal. Once a proposal is deferred, a maintainer can re-assign it to draft status. A proposal can also be "rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. Feature and Informational proposals require at least 2 approvals from project maintainers. Process proposals require at least 2 approvals from Helm org maintainers. When a proposal is accepted or rejected, the proposal should be updated accordingly by updating the `status` field, and a link to any relevant information should be provided in the introduction. ## What to do after a proposal has been approved Once a proposal has been approved, the reference implementation must be completed. When the reference implementation is complete and incorporated into the project's source code repository, the status will be marked as "final". ## Transferring proposal ownership It occasionally becomes necessary to transfer ownership of proposals to a new champion. In general, it is preferable to retain the original author as a co-author of the transferred proposal, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the proposal process, or has fallen off the face of the earth (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because the author doesn't agree with the direction of the proposal. One aim of the proposal process is to try to build consensus around a proposal, but if that's not possible, an author can always submit a competing proposal. If you are interested in assuming ownership of a proposal, you can also do this via pull request. Fork the helm/community repository, make your ownership modification, and submit a pull request. You should also send a message asking to take over, addressed to both the original author and the org maintainers (`@helm/org-maintainers`). If the original author doesn't respond to email in a timely manner, the org maintainers will make a unilateral decision (it's not like these decisions can't be reversed). [cncf-helm]: mailto:cncf-helm@lists.cncf.io [markdown]: https://spec.commonmark.org/ [pr]: https://github.com/helm/community/pulls [rfc3339]: https://tools.ietf.org/html/rfc3339 [semver]: https://semver.org/spec/v2.0.0.html [yaml]: https://yaml.org/ ================================================ FILE: community/hips/hip-0002.md ================================================ --- title: Pre-defined release dates for Helm sidebar_label: "0002: Pre-defined release dates for Helm" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0002 | Pre-defined release dates for Helm | Marc Khouzam | 2020-09-04 | process | accepted | ## Abstract Have well-known cyclical release dates for Helm minor and patch releases. Have a published release date for a Helm major release, upon the availability of the first beta release. ## Motivation Contributors and users/organizations greatly appreciate knowing in advance when the next release will be available. It allows contributors to plan their work and organizations to schedule migration plans; it also provides users with clear timelines for access to bug fixes and features. ## Rationale Minor and patch releases for Helm normally occur a couple of times a year. They therefore lend themselves well to cyclical, pre-defined release dates. As it is not recommended to use Helm with a version of Kubernetes that is newer than the version Helm was compiled against ([see here][helm-skew]), there is value in aligning the date for Helm minor releases with [Kubernetes releases][kubernetes-dates], which state that "X.Y.0 occur 3 to 4 months after X.(Y-1).0". Helm major releases happen rarely and therefore do not lend themselves to pre-defined, cyclical release dates. However, upon the availability of the first beta version of a major release, a specific final release date should be chosen and announced. ## Specification ### Patch releases Patch releases should be done once a month on the second Wednesday of each month (assuming there are changes since the last release). A patch release to fix a high priority regression or security issue does not have to follow this schedule, but it is highly desirable that it is released on a Wednesday if possible. #### Cancelling a patch release A patch release should be cancelled: - if it falls within one week before the first release candidate (RC1) of an upcoming minor release - if it falls within four weeks following a minor release As an example, if Helm 3.9.0-rc.1 is scheduled for January 7th, 2022, the expectation is that no patch releases will be cut for Helm 3.8.x after December 31st, 2021. Similarly, if Helm 3.9.0 is released on January 16th, 2022, the expectation is that the 3.9.1 patch release will not be cut before February 13th, 2022. ### Minor releases For minor releases, it is not necessary to aim for dates that are the same every year. Instead, the following is proposed: * Once a Helm minor release is made, the release date of the next minor release must be announced. * To align with Kubernetes releases, a 4-month minor release cadence should be adopted (so at least 3 minor releases of Helm per year) Extra minor releases can be added to the schedule when needed. However: * An extra minor release should not change a planned minor release date, unless the planned release is less than 7 days away. This is to avoid postponing the release of features that are still on-going and planned according to the originally stated release date. * Extra minor releases should only be done for important reasons (as per judgment of the maintainers) to avoid increasing the burden on organizations that choose to upgrade at every release. ## Security implications Security releases do not follow any planned dates and should be done as soon as required. ## How to teach this * When a Helm minor release is made, the next minor release number and date should be chosen and announced at the same time. * The Helm website should have a page mentioning each planned release and its date. This page should be updated at each release. * The Helm website should have a page describing the process for release dates put forth in this HIP ## Reference implementation A reference implementation for this proposal to be accepted would entail: * Proposing a date of the next minor release * Posting a PR to helm-www which: * documents the next release date * updates the release check-list as per the new process * creates a page to document the details of this HIP for users * Creating a public online calendar so that maintainers can get release reminders and consumers can see the Helm release dates. The calendar shall contain: * monthly patch release dates * the next minor release date (or major release date if applicable) * dates when RCs must be created * it may be interesting to include kubernetes release dates if available * A link to the release calendar shall be added to helm-www [kubernetes-dates]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#minor-version-scheme-and-timeline [helm-skew]: https://helm.sh/docs/topics/version_skew/#supported-version-skew ================================================ FILE: community/hips/hip-0003.md ================================================ --- title: How Projects Join the Helm Organization sidebar_label: "0003: How Projects Join the Helm Organization" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0003 | How Projects Join the Helm Organization | Matt Butcher | 2020-09-30 | process | accepted | ## Abstract Helm is an organization with multiple projects. This document describes how new projects may be added to the Helm organization. ## Motivation Formalizing this process removes unspoken assumptions and makes it clear how to add a project to the Helm organization. ## Rationale Clarifying the process and the requirements will make it simpler, more consistent, and more transparent for projects to join the Helm organization. ### Legal Requirements Any project added must meet the CNCF's legal requirements, including licenses (Apache 2) and [CNCF intellectual property commitments][CNCF intellectual property commitments]. CNCF allows projects to choose [DCO or CLA][DCO or CLA]. ### Governance Requirements Any project added must (a) agree to be held accountable to Helm governance at the organizational level, and (b) have in place a formal project governance structure that meets the requirements set out by the Helm organization in the [Helm governance documents][Helm governance documents]. Additionally, governance requirements from CNCF must be adhered to. For example, any candidate project must use the [CNCF Code of Conduct][CNCF Code of Conduct]. We currently do not allow any projects to "bring their own" code of conduct or to make any additional changes to the existing CNCF code of conduct. ### Security Requirements Any project added must have security guidelines for how to report and resolve security issues. It is acceptable to merely use the existing [Helm security process][Helm security process] for this. But projects that require special or additional reporting may do so. ## Specification This is the process to submit a project for addition to the Helm organization. ### 1. Project opens issue The candidate project must open an issue in the [Helm community repository][Helm community repository] requesting that it join. This issue should provide: - A link back to the project - The GitHub user names of those in a governance role for that project - A short description (1-3 paragraphs) of why it makes sense to add to Helm - A short explanation of how the project is to be staffed going forward. ### 2. Helm Org Review The Helm organization owners will review the proposal. This process will likely involve some back-and-forth conversation with the owners of the project. ### 3. Helm Org Voting As stated in the [Helm governance documents][Helm governance documents], a candidate project must pass a supermajority vote before it is accepted into the Helm organization. If the Helm org maintainers vote to include the project, the project will be considered a _recommended Helm project_, and CNCF will be notified of our intentions. ### 4. CNCF Review CNCF will apply its reviews, including but not limited to intellectual property reviews. This process will be managed between designated Helm org maintainers and the CNCF, with the project being included as necessary. If this review fails, projects will be given the opportunity to comply with CNCF's requirements. Failure to comply, though, will remove the project from _recommended project_ status, and the process will discontinue. ### 5. Transition of Resources Once both Helm and CNCF have reviewed the project and approved, the project becomes a _transitional project_. Helm org maintainers will work with the transitional project to move resources, transfer requisite ownership, and make any other necessary changes. Helm org maintainers may choose to grant an incoming project a single position as a Helm org maintainer. ### 6. Completion At the completion of the transitional process, the project will be an official _Helm project_. At the next governance cycle, it will be granted representation as per the [Helm governance documents][Helm governance documents]. ## Backwards compatibility This change applies to all future project additions and implies no change to the status of existing projects. ## Security implications Not applicable. ## How to teach this The steps in the Specification will be available in [the Helm governance documents][Helm governance documents]. ## Reference implementation Not applicable. ## Rejected ideas None currently. ## Open issues None currently. ## References - [CNCF intellectual property commitments](https://github.com/cncf/foundation/blob/master/copyright-notices.md) - [DCO or CLA](https://www.cncf.io/services-for-projects/#legal-services) - [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) - [Helm security process](../SECURITY.md) - [Helm governance documents](../governance/governance.md) - [Helm community repository](http://github.com/helm/community) ================================================ FILE: community/hips/hip-0004.md ================================================ --- title: Document backwards-compatibility rules sidebar_label: "0004: Document backwards-compatibility rules" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0004 | Document backwards-compatibility rules | Marc Khouzam , Matt Butcher | 2020-09-18 | process | accepted | ## Abstract Define and document the backwards-compatibility rules that apply to Helm minor and patch releases. ## Motivation Helm aims to strictly respect [Semantic Versioning][semver], where minor and patch releases must be 100% backwards compatible. Backwards compatibility implies that when moving to a new backwards-compatible release: * tools (such as Continuous Integration tools) using the helm CLI will not require any changes * programs using the Helm Go API will continue to compile Some contributors to the Helm code base may not be comfortable with the details of what constitutes a compatibility-breaking change. Furthermore, in some cases, there can be a difference of opinion, even amongst the maintainers, on what constitutes such a change. Having a well-defined, documented set of backwards-compatibility rules for the Helm code-base will allow to: * avoid compatibility-breaking changes being merged by mistake * guide contributors in understanding helm's backwards-compatibility requirements * remove any uncertainty when it comes to enforcing backwards compatibility * provide a basis for discussion and possible updates to how helm handles backwards compatibility ## Rationale The maintainers have agreed that a formal definition of Helm's backwards-compatibility rules would be beneficial. ## Specification The following compatibility rules will apply to helm minor and patch releases: * exported Go APIs will remain compatible as per this [article][go-module-comp] * the exception to this rule is where Helm exposes Kubernetes APIs. Kubernetes APIs do not follow semantic versioning so Helm cannot enforce compatibility. * CLI commands and flags: * commands and flags are case-sensitive * commands and flags must not be removed * commands and flags must not be renamed * commands and flags must not be moved elsewhere in the command hierarchy * commands and flags cannot be "repurposed" to provide a different behavior than the original (even if deprecated) * flags must not change type. Exceptions are when the new type is a superset of the original type (e.g., int8 to int32, int to float, float to string) * these rules apply as much to the short name as to the long name of a flag, if present. Specifically, a short name cannot be changed in any way even if its long name is kept the same, and vice versa * CLI output: * the help text may change * the format of structured output (tables, JSON, YAML) must not change * errors can change if doing so increases their usability * a message containing a "bug" (including spelling errors, misinformation, or egregious grammar errors), can be fixed * return codes should not be changed unless they are incorrect * File formats (such as index.yaml, values.yaml, Chart.yaml): * No fields may be removed, added, or modified on the Chart.yaml file * No fields may be modified or removed in: * index.yaml * repositories.yaml * Any added fields must be accompanied by backward compatibility checks * No existing optional field can be made required (but a required field can be downgraded to optional) * If a field is added to a structured piece of data, it must be optional. No "new required" fields * We do not accept 3rd-party-specific fields (though we do facilitate them with things like annotations) This is grounds for rejecting an additive change in places where additions are allowed (e.g. like repositories.yaml) * Charts: * The handling of templates/ must not be changed * Reserved directory names (e.g. crds) must not be removed * No files or file types that are allowed may be changed to be disallowed * If an object or file type is added to a chart, it must also be optional (see requirements.yaml in Helm 2) * No files that were in the files object may be removed from the files object (in other words, a new file type may be added, but files cannot be removed from the files object just because they are instances of this new file type) * Templates (commands, functions, syntax, and variables): * Template functions cannot be removed * Return types of functions cannot change * A template function signature is additive (can add more parameters) if and only if the change is backwards compatible. E.g. sum int64 int64 can be changed to foo int64 int64 [int64] (where the new third parameter is optional). Likewise, print string could be changed to print any as long as any accepts a string and still treats it as it did before. But sum int64 int64 int64 could not be changed to sum int64 int64. * built-in directives, constants, and variables cannot be removed or changed in any way that would break an existing template * constants and variables that contain structured information cannot change the format of that structured information. (Example: if a built-in variable called ".Version" returned "helm-v1.2.3" it could not be changed to return "v1.2.3") * If a variable is changed to a function, it must not require any arguments or return a different return type than the original variable's value. (Example: If .Version was changed from a variable that returned v1.2.3, it can be changed to a function, but only if that function allows no parameters and when no parameters are specified, still returns in the format v1.2.3. * the template syntax cannot change except when the change is directly from the Go programming language (who has made such changes during Helm's history -- viz. adding the - whitespace chomp character and changing variables to become mutable). * occasionally, external template libraries or their dependencies have made breaking changes. We are now trying to avoid that. * Experimental Feature Flags: * From time to time, at the discretion of the core maintainers, new "experimental" features may be hidden behind one or more feature flags. An example of this in Helm 3.0.0 was the inclusion of experimental repository support. * Experimental features are not required to ensure backward compatibility for their feature set. (They cannot, however, break backward compatibility for other parts of Helm.) Thus, a new release of an existing experimental feature may break APIs, change its chart representations, or modify its command-line flags as long as it does not break the compatibility of non-experimental features. * Two experimental features are not required to be compatible with each other, though any feature must be compatible with all stable features before it can exit the experimental feature track. ## Security implications Compatibility rules may be broken or bent in the name of security. For example, if a flag once took an int64, but it was determined that doing so led to a buffer overflow, the datatype of that parameter could be changed. In some cases, entire functions, template commands, etc. could be altered or removed if deemed absolutely necessary. Files formats can change as well. Of course, it should go without saying that we as maintainers should do our best to not have this happen if at all possible. This caveat is mainly to inform the end users that in extreme cases, we will break compatibility. ## How to teach this * The list of compatibility rules should be published on helm.sh with a global explanation of the motivation behind to need to follow them * The list of compatibility rules should be used as a reference by maintainers when doing code reviews * During PR reviews, when appropriate, the reviewing maintainer should refer the contributor to the list of compatibility rules ## Reference implementation This HIP will serve as the document listing the backwards-compatibility rules. ## Open issues * Should Go's experimental [apidiff][apidiff] tool be used? The following [issue][apidiff-install] gives a couple of ways to install it. * There has never been a consensus on messages that are user-facing and informal or non-informational (e.g. "Happy Helming"). I most often vote against these changes, while others have voted for them. [Butcher] * In the past, we have allowed formatting changes to structured formats (JSON, YAML) when such changes were not considered _structural_ by the relevant specification. E.g. adding/removing whitespace in JSON documents. These days, we have been more resistant to that... but we have never explicitly said it is not allowed. [Butcher] * We do need to say something about "log" messages. We currently have no policy at all about log messages, and hence allow any changes to messages at the Debug and Warning levels. [Butcher] * Does breaking compatibility due to security require a major release? * Should the rules specifically mention the helm packages that must respect compatibility? (e.g., `pkg` for Go API, `cmd` for CLI) [semver]: https://semver.org/spec/v2.0.0.html [go-module-comp]: https://blog.golang.org/module-compatibility [apidiff]: https://pkg.go.dev/golang.org/x/exp/cmd/apidiff [apidiff-install]: https://github.com/golang/go/issues/34849 ================================================ FILE: community/hips/hip-0005.md ================================================ --- title: Helm Org Maintainers and Deprecated Projects sidebar_label: "0005: Helm Org Maintainers and Deprecated Projects" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 5 | Helm Org Maintainers and Deprecated Projects | Matt Butcher | 2020-09-24 | process | draft | ## Abstract This process proposal explains what happens to Helm organization maintainer slots when a project is deprecated. ## Motivation The current governance documents state that org maintainers may be selected from any of the official Helm projects. However, as the Helm organization matures, some projects are being deprecated. The governance docs are unclear what happens to org maintainers from deprecated projects, and whether deprecated projects may hold org maintainer seats. ## Rationale In the interest of keeping the Helm project thriving and alive, this HIP proposes that only non-deprecated projects are entitled to org maintainer seats. ## Specification To implement this, a new PR must be opened with the changes to the governance document. The changes must be adopted by 2/3 supermajority of the _current org maintainers_ (including those maintainers who may be attached to deprecated projects). The governance documentation for the Helm org will be updated as follows: - All references to org maintainer seats for projects will clarify that they apply only to non-deprecated projects - Text will clarify that when a project is deprecated, its org maintainers will be moved to Emeritus status _except_ where those maintainers may be able to keep their role because of their status on another Helm project, including the `helm/helm` project. - The definition of an active maintainer will also be revised to specify that the maintained project must not be deprecated ## Backwards compatibility N/A ## Security implications N/A ## How to teach this The [governance.md] document will be updated with precise language. ## Reference implementation The [governance.md] document will contain all associated changes. ## Rejected ideas ### 1. Allowing maintainers of deprecated projects to stay One might argue that maintainers of deprecated projects should be allowed to stay on as org maintainers. This option was considered. But the design of the org maintainers board was intended to give projects governing input into Helm. Essentially, allowing maintainers of deprecated projects to take these slots means essentially that non-owners will be given a say in Helm's direction. It would even be possible that non-owners could have a majority voting stake in the Helm project. This did not seem right. ### 2. Requiring maintainers of deprecated projects to go even if they represented other projects as well One might argue that if a maintainer was elected because of their involvement in project X, their org maintainership should be inextricably tied to X. However, as written, this proposal allows such a maintainer to simply stay on as a maintainer due to their affiliation with another project, Y. Our intention in forming the organizational maintainers was to give interested parties a voice in steering Helm. Because such a party would still be formally affiliated with a Helm project, we believe they fill the spirit of the original organizational motivations. Of course, this does not prevent a maintainer from voluntarily stepping down when their project is deprecated. ## Open issues N/A ## References [governance.md](/community/governance/governance) ================================================ FILE: community/hips/hip-0006.md ================================================ --- title: OCI Support sidebar_label: "0006: OCI Support" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0006 | OCI Support | Josh Dolitsky | 2020-07-21 | feature | accepted | ## Abstract This feature proposal outlines a concrete plan for finalizing Helm's [OCI](https://opencontainers.org/) integration, which has been available as an experimental feature since Helm 3.0.0. ## Motivation Until now, all OCI integration has been kept separate from the existing Helm user experience, and nested under the `helm chart` and `helm registry` subcommands. These subcommands were designed to mimic the user experience of the Docker CLI. For example, `helm chart list` is the equivalent of `docker images`. While this experimental feature set has succeeded in providing a "Docker-like" user experience, it is too far removed from existing Helm features and should be partially redesigned. In addition, there has not yet been a clear response to the following questions concerning Helm's OCI support: - What is the relationship between a chart version and registry tag? - Will this work with `helm install` / `helm upgrade` / `helm dependency`? - How will provenance files (`.prov`) be supported? - When will the experimental flag be removed? ## Rationale The true value of leveraging OCI specs has very little to do with the command-line experience (i.e. Docker). OCI registries provide a common API for all types of packages, and address several security and scalability concerns. Additionally, many companies and organizations have invested in the infrastructure surrounding their container registry. Storing Helm charts in a registry reduces the number of moving parts. By making Helm's OCI support more closely aligned with the way that Helm currently works, users will have a more stable experience and still benefit from the advantages of OCI. ## Specification The specification for this HIP is broken into six (6) major sections: 1. Implement `Getter` and introduce `Pusher` 2. Support for provenance files 3. Chart versions == OCI reference tags 4. Chart names == OCI reference basenames 5. Cache is removed 6. `helm chart` is removed, integrated into rest of CLI 7. Experimental until clear messaging from OCI ### 1. Implement `Getter` and introduce `Pusher` As of yet, the code related to registry support has been written standalone (see [internal/experimental/registry](https://github.com/helm/helm/tree/master/internal/experimental/registry)). The act of downloading a chart from an OCI registry should mimic what is already possible using downloader plugins. Using the protocol prefix `oci://` in any place where chart repos are referenced should work just by implementing a `Getter` for OCI. Currently there is no Helm-specific way to upload chart packages. Using the same model of `Getter`, a new interface called `Pusher` should be introduced, with a single built-in implementation (OCI). This opens the door for plugins to implement their own upload mechanism, and for Helm to add a new top-level upload command `helm push`. For example, plugins may include a new `uploaders` section in `plugin.yaml`, similar to the existing `downloaders` section (see ["Downloader Plugins"](https://helm.sh/docs/topics/plugins/#downloader-plugins)). This will also include a new, top-level subcommand, `helm push`, which will leverage this new functionality. This command will take, as its first argument, the path to a chart archive (`.tgz`), and as the second argument a URL pointing to a remote OCI registry. Here is an example of what the `helm push` UX will look like: ``` $ helm create mychart Creating mychart $ helm package mychart/ Successfully packaged chart and saved it to: /home/user/mychart-0.1.0.tgz $ helm push mychart-0.1.0.tgz oci://example.com/some/root/namespace The push refers to repository [oci://example.com/some/root/namespace/mychart] ref: oci://example.com/some/root/namespace/mychart:0.1.0 digest: 1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617 size: 2.4 KiB name: mychart version: 0.1.0 0.1.0: pushed to remote (1 layer, 2.4 KiB total) ``` ### 2. Support for provenance files Helm currently has the ability to verify package signatures, assuming the presence of a file suffixed with `.prov` sitting next to a chart `.tgz` in a repository. Support for this method of signature validation should be carried over into OCI storage. As the format of the OCI manifest is custom to Helm, Helm can also choose to modify the resulting manifest on upload when a chart is being signed (e.g. `helm push --sign`). As far as the low-level details, the `.prov` file will simply be stored as another layer on the manifest. If running `helm pull --verify oci://...`, the layer containing the provenance file will be retrieved from the registry. The order and total number of layers on the manifest is not significant. The list of layers will be inspected, and the first one found matching the media type of the provenance file will be used. If multiple layers containing the provenance file media type are found, an error will occur. The same applies to the chart layer. Here is an example of what a manifest will look like with a provenance file attached: ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ### 3. Chart versions == OCI reference tags To keep things simple, the version of a chart will be 1-to-1 with the tag used on registry references. Arbitrary tags will not be supported. This also means that tags are no longer necessary to be provided on the command-line in the form `:`. Instead, users can provide `--version `. ### 4. Chart names == OCI reference basenames Again, to keep things simple, the basename (the last segment of the URL path) on a registry reference should be equivalent to the chart name. For example, given a chart with the name `pepper` and the version `1.2.3`, users may run a command such as the following: ``` $ helm push pepper-1.2.3.tgz oci://r.myreg.io/mycharts ``` which would result in the following reference: ``` oci://r.myreg.io/mycharts/pepper:1.2.3 ``` By placing such restrictions on registry URLs and tags, Helm users are less likely to do "strange things" with charts in registries. ### 5. Cache is removed Since chart packages are small in size (<1mb), the cache is hard to justify. The cache was introduced only to provide a "Docker-like" experience. While this is neat, it does not provide the user with much value. By removing the cache, much of the existing OCI features can be cut down dramatically in size. This will make OCI features much more seamless with the existing Helm user experience. ### 6. `helm chart` is removed, integrated into rest of CLI Wherever possible, the subcommands provided by the new `helm chart` command should be integrated into existing Helm CLI commands. `helm chart pull` should be baked into `helm pull`, `helm chart push` should be `helm push` (new). Commands that work with the cache will be removed: `helm chart save`, `helm chart remove` and `helm chart export`. `helm registry` will be kept as is. This manages auth against OCI registries. ### 7. Experimental until clear messaging from OCI Considering that the rest of the items above are implemented and resolved, the OCI feature set will not be made generally available until there is clear messaging from the Open Container Initiative (OCI) regarding the way that Helm is using registries. The technical details of how Helm is using the OCI distribution spec must be further validated. It is currently unclear whether or not this is the correct way to publish an arbitrary artifact. Only after more clarity will these features be taken out of experimental mode and made generally available. ## Backwards compatibility Since the existing feature set is currently experimental, there will be no promise of backwards compatibility with prior OCI support (sorry!) ## Security implications Registry authentication introduces a new attack vector. Upon running `helm registry login`, these credentials can possibly be stored in an unencrypted JSON file. However, if your system supports Docker's credential helpers (such as `osxkeychain`), then no crendetials are stored in this file. Credentials are stored elsewhere, such as in the system's secure keychain. Here is an example of a registry config file using a credential helper: ``` { "auths": { "example.com": {} }, "credsStore": "osxkeychain" } ``` Here is an example of a registry config file without a credential helper: ``` { "auths": { "example.com": { "auth": "", "email": "" } } } ``` So, while a new attack vector has been introduced, it should not be considered any less safe than using `docker login`. In fact, he underlying code is leveraging docker/cli, and existing logins created with `docker login` are leveraged if not found in Helm's config. Note: this is already implemented in the current OCI feature set. ## How to teach this Following the implementation of all facets of this HIP, extensive documentation should be added to the Helm website on how to leverage OCI. Additionally, sites containing community charts, such as [Artifact Hub](https://artifacthub.io/), should enable providers to distribute charts over OCI, and display friendly copy-paste instructions for how to download an OCI-based chart. Helm and charts maintainers should be educated on how to make a transition from classic chart repositories to registries. In short the workflow for uploading a chart goes from `helm package` (+ custom upload) to `helm package && helm registry login && helm push`. ## Reference implementation The features are currently under development. Here are the following outstanding tasks: - We need to implement helm push, which does not exist - Helm needs to implement OCI Getter support so that helm dependency and helm pull can support OCI registries (see https://github.com/helm/helm/pull/8843) - Support for provenance files must be added - `helm chart save`, `helm chart export`, `helm chart list`, `helm chart remove`, `helm chart pull`, and `helm chart push` need to be removed - The Helm documentation for OCI support needs to be updated (https://helm.sh/docs/topics/registries/)) ## Rejected ideas ### Will I be able to use custom tags such as "latest"? The implications of this are not yet fully understood. For now, it will be strictly enforced that the tag on the reference will match the version found in `Chart.yaml`. This functionality may be added at a later time. ### Will I be able to pull a chart using the `:` syntax? It's unclear if users will be able to pull charts with a specific version using the `:` syntax (vs. `--version `). This seems relatively harmless to allow both, but this may have implications on dependencies and other areas. ## Open issues The issues below are still unresolved. ### What is the correct media type to use for the chart content layer? The media type for the chart content layer is currently `application/tar+gzip`, however it has been pointed out that [this is not an official type in the IANA database](https://www.iana.org/assignments/media-types/media-types.xhtml). Due to this, a unique media type will be used: `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. The only real issue with this is that the chart package is not technically a unique type. As in, a registry vendor could treat it as a typical gzipped tarball. ### What is the correct media type to use for the provenance file layer? Again, there doesn't appear to be an IANA media type for this type of file. Additionally, this file format appears unique to Helm. In this case, it seems the only option is to use a custom media type such as `application/vnd.cncf.helm.chart.provenance.v1.prov`. ## References The following links are used as references in this HIP: - [Open Container Initiative](https://opencontainers.org/) - [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec) - [List of IANA media types](https://www.iana.org/assignments/media-types/media-types.xhtml) - [Helm Documentation - Registries](https://helm.sh/docs/topics/registries/) - [Artifact Hub](https://artifacthub.io/) - [Existing standalone code for OCI support](https://github.com/helm/helm/tree/master/internal/experimental/registry) ================================================ FILE: community/hips/hip-0007.md ================================================ --- title: Document and Track maintainer groups sidebar_label: "0007: Document and Track maintainer groups" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0007 | Document and Track maintainer groups | Matt Farina , Scott Rigby | 2025-10-07 | process | draft | ## Abstract There are numerous Helm maintainer groups where each can have zero or more Git repositories associated with them. This process provides a centralized method to document and track the maintainer groups, maintainers, and associated repos. ## Motivation The current design uses a collection of documented and access controls to track this information while there are several gaps in the information. The Teams.md file attempted to track the different teams (i.e. maintainer groups, the org maintainers, etc). The repositories owned by a maintainer group, and the members of a group are not documented but are instead tracked via GitHub teams. The owners are scattered in various locations that are not consistent. In some cases they cannot be consistent (e.g. community management which does not have a GitHub repo). This has lead to confusion with the Org Maintainers and others. ## Rationale There is currently no consistent manner to document the codebases associated with a maintainer group or the members of a maintainer group. There are two examples we can look at for this situation. First, there are maintainer groups responsible for multiple repositories. Charts and the Org maintainers groups are two examples with multiple repositories. There is no location to publicly document this situation. Second, not all maintainer groups own a repository. Community management is an example of a maintainer group that does a significant amount of work without owning a source repository. This HIP aims to provide a single source of document to discover maintainer group repositories and owners. ## Specification The source of truth will be a YAML file name [`maintainer-groups.yaml`](https://github.com/helm/community/blob/main/maintainer-groups.yaml) stored at the root of the Helm community repository. It will have the following structure: ``` maintainerGroups: - name: Helm Core ownersLink: https://raw.githubusercontent.com/helm/helm/master/OWNERS repos: - https://github.com/helm/helm mailingList: cncf-helm-core-maintainers@lists.cncf.io - name: Charts owners: - unguiculus - ... emeritus: - foxish - ... repos: - https://github.com/helm/chart-releaser-action - https://github.com/helm/charts-repo-actions-demo - ... ``` A maintainer group can only have either `ownersLink` (a URL to the location of the owners list) or `owners` (a list of owners). It cannot have both. This enables those who do not have a Git repo (e.g., community managers) and those with multiple repos and no primary one (e.g., charts) to have a documented list. When `owners` is used it can have an accompanying `emeritus`. When `ownersLink` is used the emeritus is expected to be listed in that file. ## References * [Helm Governance](/community/governance/governance) documents maintainer groups. * The [Teams.md file can be referenced in the community history](https://github.com/helm/community/blob/ecedb3ddea57749580bc4800cb1492fce9c9b332/Teams.md). ================================================ FILE: community/hips/hip-0008.md ================================================ --- title: Add descriptions to custom completions sidebar_label: "0008: Add descriptions to custom completions" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0008 | Add descriptions to custom completions | Marc Khouzam | 2020-11-14 | feature | accepted | ## Abstract Provide (optional) descriptions for helm's custom completions. The goal is to help users be more efficient by providing useful information when doing auto-completion. ## Motivation Helm currently supports auto-completion for the following shells: `bash`, `zsh`, `fish`. Both the `zsh` and `fish` shells support descriptions for completions. For example, in the case of `zsh`: ``` $ helm s search -- search for a keyword in charts show -- show information of a chart status -- display the status of the named release ``` [The Cobra project][cobra project], which is used by Helm to define its commands and flags, automatically provides completion descriptions when completing those commands and flags. Those descriptions are based on the usage information specified by Helm. However, custom completions that are provided by helm itself currently don't include any descriptions. For example, when completing `helm status` it is helm that provides the list of releases, but this list does not include descriptions. ``` $ helm status n nginx nginx-ingress ``` Augmenting helm's custom completions with descriptions allows providing additional information to help users make their selection from the list of completions. ## Rationale The completions for some helm arguments do not always provide sufficient information for a user to know which value to choose. For instance, the name of a release is not always informative enough for the user to know which one to select. For example: ``` $ helm upgrade ngin nginx nginx2 ``` Clearly, in this case, the user needs to know the details of each release in advance as the difference between completion choices is not very helpful. ## Specification Here are proposed descriptions for the different types of custom completions: * chart names (for 'install', 'pull', 'show *', 'template', 'upgrade') * \ ``` $ helm install myrelease bitnami/c bitnami/cassandra -- Apache Cassandra is a free and open-source distributed database managemen bitnami/common -- A Library Helm Chart for grouping common logic between bitnami charts. Th bitnami/consul -- Highly available and distributed service discovery and key-value store de bitnami/contour -- Contour Ingress controller for Kubernetes ``` As the chart description will often be too long to fit on a single line, the shell will truncate the description to fit the shell's window. Note that each shell handles this case in its own way, where `zsh` truncates, while `fish` uses an ellipsis. * chart version (for '--version') * App: \, Created: \ ``` $ helm pull bitnami/nginx --version 7.1. 7.1.0 -- App: 1.19.2, Created: September 24, 2020 7.1.1 -- App: 1.19.3, Created: September 29, 2020 7.1.2 -- App: 1.19.3, Created: October 2, 2020 ``` * kubernetes context (for '--kube-context') * \ ``` $ helm --kube-context d default -- k3d-k3s-default dev -- development ``` * helm environment variables (for 'env') * \ (\) ``` $ helm env HELM_RE HELM_REGISTRY_CONFIG -- /me/Library/Preferences/helm/registry.json (Path to the registry configuration file) HELM_REPOSITORY_CACHE -- /me/Library/Caches/helm/repository (Path to the file containing cached repository indexes) HELM_REPOSITORY_CONFIG -- /me/Library/Preferences/helm/repositories.yaml (Path to the file containing repository names and URLs) ``` * plugin names (for 'plugin uninstall', 'plugin update') * \ ``` $ helm plugin uninstall 2to3 -- migrate and cleanup Helm v2 configuration and releases in-place to Helm v3 fullstatus -- provide status of resources part of the release ``` * release names (for 'get *', 'history', 'rollback', 'status', 'test', 'upgrade') * \-\ -> \ ``` $ helm status mynginx -- nginx-6.0.5 -> superseded nginx-ingress -- nginx-ingress-controller-5.4.4 -> deployed ``` * release revisions (for 'rollback', '--revision') * App: \, Chart: \-\ ``` $ helm rollback nginx-ingress 1 -- App: 0.34.1, Chart: nginx-ingress-controller-5.4.4 2 -- App: 0.40.2, Chart: nginx-ingress-controller-5.6.10 ``` * repo names (for 'repo remove' and completion of chart names) * \ ``` $ helm repo remove bitnami -- https://charts.bitnami.com/bitnami center -- https://repo.chartcenter.io stable -- https://charts.helm.sh/stable ``` * output formats (for '--output', '-o') * \ ``` $ helm status -o json -- Output result in JSON format table -- Output result in human-readable format yaml -- Output result in YAML format ``` Note that descriptions can be turned off by the user when generating the shell completion script using the `--no-descriptions` flag. ## Backwards compatibility Not applicable to shell auto-completion. In fact, this allows us to implement some descriptions and still be able to modify them later if different ones are requested. ## Security implications None ## How to teach this The new descriptions will automatically appear when using auto-completion, so no special effort needs to be made to teach this new feature. ## Reference implementation A PR will be opened to implement the proposed specification for descriptions of custom completions. ## Open issues None. It is worth clarifying that the bash shell does not support descriptions for auto-completion, so this feature will not apply to bash. That being said, there is a [PR open on the Cobra project][cobra pr] that adds descriptions for bash completions. [cobra project]: https://github.com/spf13/cobra [cobra pr]: https://github.com/spf13/cobra/pull/1146 ================================================ FILE: community/hips/hip-0009.md ================================================ --- title: Transitioning Security Team Members on Project Deprecation sidebar_label: "0009: Transitioning Security Team Members on Project Deprecation" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 9 | Transitioning Security Team Members on Project Deprecation | Matt Butcher | 2020-09-24 | process | draft | ## Abstract Helm maintains a security team composed of interested maintainers from Helm projects. This proposal clarifies that to be a member of the security team, one must be a maintainer of an active (non-deprecated) project. ## Motivation The existing security team documentation does not cover cases where a Helm project is marked deprecated. However, because the security team discusses sensitive and potentially damaging issues, the Helm project requires clarity on this point. ## Rationale This HIP suggests that security team members must be maintainers on _active_ Helm projects. ## Specification According to the current documentation in [SECURITY.md][SECURITY.md], the only requirements for security team members are as follows: * Members MUST be active project maintainers as defined in [the governance][governance] * Members SHOULD engage in each reported vulnerability, at a minimum to make sure it is being handled * Members MUST keep the vulnerability details private and only share on a need to know basis This proposal suggests that the first requirement be amended to read: > Members MUST be active project maintainers for an active project as defined in [the governance] Further, the [SECURITY.md][SECURITY.md] document should be updated to indicate that a security team member will be automatically removed if they are no longer affiliated with any active (non-deprecated) projects. ## Backwards compatibility N/A ## Security implications The primary reason for this change is that we view it as a compromise of our security posture to have vulnerability disclosures sent to non-maintainers. Making this change improves our security posture. ## How to teach this The change will be documented in [SECURITY.md][SECURITY.md] ## Reference implementation The change will be made in [SECURITY.md][SECURITY.md] ## Rejected ideas One might claim that security team members should be entitled to stay because of their past experience. While we do not want to downplay the role of experience, we do want to point out that it is unwise to allow unaffiliated individuals to have access to vulnerability disclosures. ## Open issues None currently. [SECURITY.md]: ../SECURITY.md [governance]: ../governance/governance.md ================================================ FILE: community/hips/hip-0010.md ================================================ --- title: Distributed responsibility for picking sidebar_label: "0010: Distributed responsibility for picking" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0010 | Distributed responsibility for picking | Marc Khouzam | 2021-01-28 | process | draft | ## Abstract The picking of PRs into a release branch is currently the responsibility of the maintainer cutting the release. It is usually the largest part of cutting a release. Improving the picking process would make cutting releases easier with a reduced risk of error. ## Motivation In the current picking process the maintainer that merges a PR is only required to tag that PR with a `needs-pick` label. The day of the patch release the maintainer cutting the release will go through each PR with a `needs-pick` label and manually cherry-pick it into the release branch. Once the cherry-pick is done, the `picked` label is added to the PR. There are multiple issues with this process: 1. Manual work for the maintainer doing the release to pick each relevant PR. 1. Possible merge conflicts during the cherry-picks as the code on master may have substantially diverged from the code in the release branch. This is particularly concerning as the maintainer cutting the release may not be the one who reviewed the PR in question and may not be familiar with its details, thus making resolving the conflicts difficult and error prone. 1. There is basically no soak time for the cherry-picks or merge conflict resolution code: some quick manual testing and the unit tests are the only tests these changes go through. ## Rationale By cherry-picking PRs as soon as they are merged into the master branch will allow to address the issues mentioned above. It will reduce the manual work required at release time, will reduce the risk of errors during merge conflicts, and will provide more time to soak the release branch content. ## Specification The pick process would be modified to the following: 1. Once a PR is merged into the master branch the `needs-pick` label will still be applied. This is to reduce the risk of forgetting to cherry-pick a PR. 1. Once the PR is merged into the master branch, it becomes the responsibility of the merging maintainer to cherry-pick it into the release branch; this should be done as soon as possible. The cherry-pick could also be done by another maintainer if desired. 1. Once the cherry-pick into the release branch is done, the cherry-picking maintainer should add the `picked` label in the original PR. 1. On a regular basis, or at least one week before a patch release date, the list of `needs-pick` PRs without a `picked` label should be verified in case any was forgotten. With this process, the release branch should always be in a state that is ready for release; the maintainer cutting the release does not need to perform any cherry-picking. For increased quality of patch releases, the release branch can be used by the community at any time, so as to verify no issues are present by the time the release day comes around. The maintainer doing the cherry-pick could optionally choose to create a PR targeting the release branch instead of directly pushing the cherry-pick. This option could be chosen to obtain a review, for example if merge conflicts were substantial. Such PRs would not need to follow the full PR process but could be merged at the discretion of the maintainers. ### Security releases Security releases are currently cut from the release branch and must only contain the security fix itself. However, with the proposed change to the pick-process, the release branch may contain new commits that should not be part of the security release. To address this, the security release process will require to create a new branch off the last release **tag**, apply the security fix to that new branch and then build the release from that branch. The security fix must also be applied to the release branch in preparation for a future patch release. ## Backwards compatibility N/A ## Security implications N/A ## How to teach this Each Helm core maintainer should be told about this new process and asked to read the HIP. ## Reference implementation A PR will be posted to update the release checklist to match the new process. ================================================ FILE: community/hips/hip-0011.md ================================================ --- title: CRD Handling in Helm 3 sidebar_label: "0011: CRD Handling in Helm 3" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0011 | CRD Handling in Helm 3 | Matt Butcher | 2021-03-26 | informational | final | ## Abstract This document talks about the problems the Helm team has had dealing with CRDs, and lays out criteria for how to move forward. While it discusses a few solution _paths_, it does not provide a single solution. It is also an instrument for ruling out solutions that do not match Helm's guiding principles. The most difficult problem in Helm's history has been how to handle Kubernetes CRDs. We've tried a variety of approaches, none of which has proven satisfactory to all users. Our current solution, while not comprehensive, is designed to privilege safety over flexibility. We are considering options for a Helm 4 time frame, and this document is a first step in that exercise. (Backward-compatible features for CRDs could still be merged into Helm 3.) ## Rationale This section, which makes up the bulk of this informational HIP, describes why we made the decisions we have made thus far. It highlights the challenges that we think any suitable implementation must address. And it may serve as a guide for those who wish to tackle the problem. ### The Core Problem The core problem is that CRDs (being a globally shared resource) are fragile. Once a CRD is installed, we typically have to assume (all other things being equal) that it is shared across namespaces and groups of users. For that reason, installing, modifying, and deleting CRDs is a process that has ramifications for all users and systems of that cluster. In spite of this, the Kubernetes API server is permissive about these CRDs. CRDs are mutable (even without a version change). When they are deleted, all instances of them are deleted without warning. They can be upgraded to be entirely incompatible with previous versions. And there is no way to programmatically inspect the CRDs in a cluster and determine whether they are used, how they are used, and by what. ### Users First: A Core Principal Over the years, several proposals have surfaced and been rejected for one reason: They did not protect the user from badly written charts. This section explains the reasoning process behind our decision-making. Helm distinguishes between at least two roles: - A chart author: A person filling this role _creates_ and _maintains_ Helm charts - A Helm user: This person installs and manages instances of charts #### The Chart Author Role We assume that a _chart author_ has three specific areas of domain knowledge: 1. How to model applications in Kubernetes 2. How to create Helm charts, including author templates 3. How the application they are packaging works In this case, we assume the chart author role includes knowledge of Kubernetes kinds, Helm template commands, and so on. We do not assume that chart authors have knowledge about the clusters into which their charts are deployed, knowledge of the source code for the packages they install, or knowledge of the extended toolchains that their users have employed. Furthermore, we do not assume that chart authors will always follow best practices or accommodate use cases that may be important to some class of users. In fact, the Helm security model urges us to include bad actors in the class of chart authors. (That is, there is or may be a small subclass of chart authors that have intentions counter to the desires of their target Helm users.) #### The Helm User Role Our assumptions about the base level of _Helm users_ are more modest. While some users may be experts, we do not assume that a Helm user _must_ be at that level. We do not assume they know much about Kubernetes or Helm--perhaps only enough to follow the Quickstart guide for Helm. With the base Helm user, we do not assume that they know what a Pod is, let alone a CRD. While we do assume that they know a little about YAML, we make no assumptions that they know about the Kubernetes flavor of YAML. #### The Importance of This Distinction Over time, our assumptions have shown themselves true. Many (perhaps even most) Helm users are new to Kubernetes, and we hear repeatedly that people have learned Kubernetes via Helm. Our issue queue is replete with examples of people who have installed Helm charts in production, but who are not Kubernetes experts by any measure. Chart authoring, on the other hand, has remained the domain of experienced Kubernetes users, and the questions we receive from chart authors indicate a high degree of comfort with Kubernetes itself. Some have attempted to argue that "really," the chart developer and the Helm user are the same person -- that most of the time, people build their own charts. Our usage information shows otherwise. The usage pattern we see most often with Helm is that a chart author is a different person than a Helm user. That is, most of the time, one group of persons creates charts, and another group of (non-overlapping) persons use the charts. As a consequence of this, we can assume that the _person using the chart does not know or understand the internals of the packages they install_. This is not merely a statement that they have not read the templates, but that they would not understand them even if they did, because they have not had to (nor should they have to) become fluent in the chart system to use the charts. And as a further consequence, we can say that _it is irrational to implement a solution that requires that the Helm user know and understand the internals of a chart_. It is irrational precisely because the empirical data shows that it is not the case that the majority of users understand their charts to that degree. One may easily draw analogy to other package managers: Most apt users do not know how apt packages work, and the same is true for RPM, Homebrew, Chocolatey and so on. When we consider solutions to this problem, then, it is incorrect to assume that a user should be responsible for mitigating poor choices made by a chart maintainer. This same justification has been used to develop many of Helm's core features. It is one of the reasons we go to great extremes to preserve backward compatibility from release to release. It is the reason we have built chart scanning tools, invested in best practices documentation, and built strong security measures into the template system. We will not ignore it for CRDs. ### CRDs and How They Are Used CRDs are shared global resources. A "shared global resource" is a resource that can be installed only once (globally, not within a namespace) and which may be used by multiple different things. CRDs have one canonical record, which covers all the different versions of that CRD. Originally, CRDs were designed for a very specific purpose: To make it possible to add new controllers to Kubernetes. For example, if `Deployment` does not do what you want, you can write an alternative resource definition backed by a custom controller. While this pattern has definitely been useful, some see CRDs as a generic data modeling tool. We have seen many cases where CRDs were used to store configuration, model non-Kubernetes objects, or even serve as a data storage layer consumed by applications. While we do not think this was the spirit in which CRDs were intended to be used, we acknowledge that they _are_ used in this way, and therefore it is Helm's responsibility to not foreclose such usage patterns. A CRD may have a schema attached, which dictates the structure of an instance of that CRD (called a Custom Resource, or CR). Each version on the CRD object may have a schema, as well as other metadata. Note that none of these fields are immutable on the CRD. So a schema may be changed without altering any other fields on the CRD, thus breaking existing resources. While the CRDs are installed and somewhat managed by Kubernetes, their functionality is dictated largely by the controllers that use those CRDs. Thus, we have to include in our discussion the _developers_ who write the CRDs and controllers. You are encouraged to read the [Kubernetes documentation on CRD versions](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) before continuing here. As you read, note how many versioning tasks are delegated to developers, and how the assumption is that the developers have a low degree of sharing and a high degree of visibility into the cluster. There is no discussion of how this works in multi-tenant clusters, and the assumption is always that there is only one controller per CRD per cluster. Even with these simplifying assumptions, the document points out how many discrete tasks must be undertaken to ensure compatibility. In our experience, very few implementations actually do the work this document requires. Also note that there is no discussion there of controllers that become out of date with CRDs, though that is a possible situation. (A conversion webhook may render a resource unusable to a controller when multiple controllers watch the same CRD.) From the outset, then, when _just_ considering a simple environment and the concerns of the CRD developer, we can see a number of difficult problems. Now we can add to this the usage patterns that are in practice today. In Kubernetes, the following CRD patterns have emerged: - Generic CRD: A single CRD "generalizes" a description of something, and any programs that need that generalized object can use that CRD. The CRD is thus a shared resource with no single controller. - CRD and Singleton Controller: A specific application defines a specific CRD that only it uses. Only one controller uses that CRD. - Common CRD: Two or more tightly coupled programs use a CRD to update information that is shared between the programs. Microservice architectures sometimes use this approach. (ConfigMaps and Secrets are also used this way, and the documentation for CRDs even suggests this as an alternative to ConfigMaps and Secrets in this capacity) - CRD and per-namespace controllers: One CRD is used globally, but each namespace that uses this CRD has its own controller which watches only that namespace. This strategy is done to reduce the cluster-level permissions the controller must have. As a special case, some controllers install and manage their own CRDs. For the most part, we won't deal with these here, as these do not pose a problem for Helm. The following facts about CRDs should be kept in mind throughout this paper: - CRDs are mutable. An operator can update versions, schemas, names, etc. on a CRD _ad hoc_. The API server will not enforce restrictions like it does on Deployments or other objects. - When a CR (CRD instance) is written to Kubernetes (on an update, for example), it will be _rewritten_ to the version that the CRD has marked as default. This means that backward compatibility can break merely by updating the default version on a CRD object. [See this section of the docs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#writing-reading-and-updating-versioned-customresourcedefinition-objects), which reveals a few other edge cases. - During a read operation, Kubernetes can rewrite an object version without rewriting the body of the CR. So you can get a resource that is marked with a version that it actually is not. - On a write operation, a version field may be permanently rewritten to a version other than the version given in the object to be written, but the body is not updated - A retrieved object may not match the schema of the version that is in its apiVersion field because of the above. - A developer can install a Kubernetes webhook that will auto-convert CRD fields. The controller does not have visibility into this conversion: It happens before the event triggers inside of Kubernetes. A quick glance through this section should reveal one stark fact: Everything that uses a CRD should (and perhaps must) use the same _version_ of the CRD as the one marked as the default for that cluster. This is the single most fragile aspect of the entire CRD system. ### How This Impacts Helm Helm has had a difficult time dealing with CRDs since the beginning. And over time, the decisions made on Kubernetes CRDs have made it more (not less) difficult for us to work with them. Originally, we believed that CRDs would be used as they were originally intended: As descriptors of controllers that added Kubernetes functionality. As such, we initially thought a CRD could simply be treated as regular resources _because it would always only ever be bundled with a single controller that ran cluster-wide_. But that has proven not to be the case. Furthermore, the (anti-)pattern of distributing a CRD with multiple pre-populated CR instances is now a regularly encountered phenomenon. As such, we have been forced to treat CRDs as a special class of resource because a CRD must be loaded into the Kubernetes API server before a CR can reference that CRD. As we have seen the usage of CRDs expand well beyond the original intent, the patterns listed in the previous section are not anomalies, but standard practices in the community. Thus, our original designs for CRD handling have been completely re-thought--first in Helm 2 with the addition of CRD hooks, and then again in Helm 3 with special `crds/` directories in Helm charts. Our current solution (Helm 3) supports installing CRDs, but does not support modifying or deleting CRDs. Those two operations currently must be done out of band. The sections below explain this decision. #### Installing CRDs There are a number of well-described issues with installing CRDs. Users must have broad permissions. A CRD must be fully installed before a manifest that references that CRD can be accepted by the Kubernetes API server. (However, a CR can be accepted before there is anything available to handle the CR event.) It is entirely possible for two different applications to require different versions of the same CRD, but no clear way to support or declare that need within Kubernetes. This is exacerbated by the fact that while a CRD is a global object, the controllers that listen for CRD events may be namespace-bound. This means that two instances of the same controller (in different namespaces) can use the same CRD definition. There is no way to query Kubernetes to discover this fact. All of these things present challenges for installing CRDs. Essentially, any installation process must have some kind of logic like "If the CRD exists, check to make sure that it is compatible with the version of the CRD that I need, and then proceed on my installation. Otherwise, attempt to install the CRD, and handle the case that I might not have permission to do so." After looking at several ways of making it easy for chart developers to do this, we alighted on a fairly easy (though inelegant) solution: Helm, as it stands today, provides a separate location in a chart to add CRDs. These will be uploaded _before the chart's templates are even rendered_ (thus avoiding verification issues with the discovery API). If the CRD exists or if the permissions do not allow it, the chart will fail before the application is deployed. Of course, users are unhappy with this for a host of reasons. They want CRDs templated (without understanding the race conditions). They want stronger version controls. They don't like having a separate directory for CRDs. We sympathize... but we currently have not devised a better solution for the aforementioned problems. > NOTE: There is no requirement that CRDs can only be placed in the `crds/` directory. They can be put along side other resources in the `templates/` directory. This was an intentional design choice to preserve backward compatibility. ### Deleting CRDs We'll delay talking about upgrades for just a moment, and skip to the easiest one: Deleting CRDs. Helm currently does not delete CRDs. The reasoning behind this decision is the trivial confluence of two aspects of CRDs: global resources and cascading deletes. The next two subsections explain these. #### Shared Global Resources Earlier, we looked at how Kubernetes CRDs are _shared global resources_. That is, only one resource describes the CRD and all of its versions, and that one resource is shared among all namespaces on a cluster. If application A and application B both rely on the same CRD, allowing application A to delete the CRD would be bad news for application B. While it's fairly harmless to allow the creation of a CRD by the first thing that wants it, it is bad to allow any dependent application to delete that CRD when that application cannot confirm that in so doing it will not cripple other applications that use the same CRD. However, there is actually no way to tell whether or not anything uses a CRD. That is an internal implementation detail of the controllers, which is entirely opaque to cluster operators, let alone to Helm. The Kubernetes API server _could_ remedy this situation, but does not. (Example: controllers could be required to indicate to the Kubernetes API server which CRDs they rely upon.) Even if Helm could determine whether a CRD was consumed by multiple Kubernetes applications, it could not tell which usages were required (application _depends_ on the CRD), optional (application can use the CRD if present), or incidental (application merely collects data). Again, this is because Kubernetes itself does not provide facilities for this (though it could). Therefore, there is no way to determine when it is safe to remove a CRD short of determining that the cluster itself is being destroyed. "But the user should know, and be allowed to delete when they want!" The _should_ in that sentence does a lot of work. Consider a multi-tenant cluster. Team A may install their application, which installs a CRD. But once that is installed, it is incumbent on Team A to work with all other cluster users (Team B, Team C, ...) to ensure that the CRD is unused before deleting the CRD. Helm is used in clusters that have thousands of cluster users. We cannot realistically assume that Team A can perform this step. Even more simply, there is no guarantee that Team A even knows that their chart installed a CRD. There are several cases to consider here: - Team A simply does not know that a chart has a CRD. After all, a user cannot be required to understand the details of every chart they install. This is complicated by the fact that a CRD could have been created in a subsequent upgrade or other circumstance that escaped Team A's notice - Team A has no realistic way to discover Team B, as RBACs or other measures hide Team B's accounts and resources from Team A - Team A _accidentally_ deletes a CRD by forcing a recreation operation or performing a destructive rollback (e.g. rollback to a version before the CRD was present). The frequent response to this point is to say, "users deserve to experience the outage if they uninstall a CRD." We do not think this is fair or accurate. Many times (especially in multi-tenant clusters), the team that uninstalls the CRD is not the group of people harmed. It's the _other_ cluster users. It is patently unfair to say "If Team A makes a mistake, Team B should pay the consequences even if they did nothing wrong." See the "Users First" section above. #### Cascading Deletions Another frightening aspect of CRDs that has prompted us to not support CRD deletion is the cascading effect: When a CRD is deleted, all of the instances of that CRD (the CRs) are deleted as well. Now consider this innocuous "fix": A chart is misbehaving. Something about the newest version is broken. The Helm user chooses one of the following actions: * rollback * force delete and recreation If the rollback goes to a version _prior to_ the CRD, it will initiate a destruction of the CRD. If the operator deletes and recreates, it will destroy the CRD. Either method will trigger the auto-deletion of all CRs for that CRD. Now imagine that deleting entails removing a CRD that has hundreds of in-production instances (think SSL certificates on a large cluster). Suddenly, not only is the CRD gone (if only for a moment), but all of the SSL certificates are gone as well! And those records won't automatically come back with the next (re-)install. Cluster operators will be forced to take extreme measures, like restoring from backups or recreating assets. Again, this is not a story friendly to our "users first" philosophy. ### Upgrading and Modifying CRDs This is perhaps the most vexed part of CRD handling. While the ramifications of deletion are straightforward, modifying CRDs is nuanced and complicated. If there was a way to require a one-to-one relationship between a controller and a CRD, upgrading would not be problematic. If it were the case that a CRD _must_ have exactly one controller, and that the lifecycle of the two was tightly coupled, upgrade would be trivial. However, this is not a requirement. In fact, previously we have shown multiple patterns that indicate multiple consumers of the same CRD--some of which may not even be controllers. Likewise, if there was a way that different versions of the same CRD could co-exist without being translated, and if those versions were immutable, then upgrades would also be fairly easy. That, however, is not the case. Kubernetes does weak auto-conversion of CRs, and provides a webhook facility for doing additional conversion. This greatly increases the complexity of upgrades. Because CRDs are mutable, it is possible for CRD manifests to change the behavior of a CRD without changing the version field on a CRD. While this case is easy to decry as bad practice, it is possible, and it (of course) occurs in the real world. Finally, as stated previously, there is no way for Helm (or any other process) to see which things on a cluster consume a given CRD. And there is certainly no way to determine what particular version of a CRD they consume. At best, there are weak inductive methods that could be used to say "during a given period, container X made a request to the API server that makes it look like it understands version X of CRD Y." But those methods are definitely non-trivial and non-exhaustive. This is something we view as a serious design flaw in Kubernetes itself. #### Upgrading CRDs Given the issues called out above, the core problem with upgrading a CRD instance is that Helm cannot determine whether upgrading a CRD will break other things in the cluster. It is worth calling out this fact again: CRDs are cluster-wide. A user may have no idea that by updating a Helm chart, it breaks other parts of the cluster that the user does not even have access to. For example, a user might have permissions to create CRDs, and permissions to do anything on that user's namespace, but not have even read access to any other namespaces on the cluster. Yet by updating the CRD, the user may break other things on the cluster to which the user has no access. It's not just multi-tenant clusters that can be dangerous, though. Even in a single-tenant cluster, with no way of seeing which things rely on a CRD, even a human operator might not be able to tell whether upgrading a CRD is safe, or whether other things on the cluster depend on that CRD's current version. Again, there is no way for a consumer (controller or otherwise) to indicate that it is consuming CRs for a particular CRD. _It is unrealistically expected that human operators will have knowledge of what CRDs are being consumed by which containers in the cluster_. The Helm view on this is that upgrading a CRD is something that an operator should do conscientiously. A manual upgrade of a CRD is safer because it requires the operator to at least be intentional about applying the specific change. Contrast that with the case where the CRD is "hidden" in a chart. In that case, the operator might be wholly unaware that running an upgrade will even touch a CRD. (The caveat here is that we do not believe Kubernetes provides a truly safe way to upgrade a CRD even when done by hand. Manual upgrades are merely _safer_ than automatic upgrades.) One frequently requested feature of CRDs is templating. Our concern with adding templating is that this particular story will become even more complicated by making it difficult for chart users to understand the extent to which a CRD will be modified during an upgrade. Small dynamic elements in a CRD schema could, for example, compound the complexity of having one CRD with multiple controllers. For example, if the schema attached to a CRD can be dynamically rendered, than a small change in a chart from version to version could result in the rewriting of a CRD schema in a non-intuitive way--and in a way that _breaks other things in the cluster_. And again, supporting templating here would make it incumbent on chart authors to be able to detect during an upgrade when the version of the CRD needs to increment (e.g. from `foo/v1beta12` to `foo/v1beta13`). We believe it is unrealistic to foist this responsibility on the chart author. In addition, there are some rather complex issues with the templating system that can cause either a race condition or an unexpected context during rendering of CRDs. But those may be rightly considered implementation details of Helm. Finally, note that flags on `helm upgrade` such as `--force`, `--wait`, and `--atomic` introduce additional complexity. For example, `--atomic` could allow a CRD to become active for a period, and then roll it back, but without repairing any CRs that were altered during the window that the CRD was active. In the worst cases, some suggested changes to Helm might actually cause the CRD to be _deleted and recreated_ during an upgrade, which would have the side-effect of deleting all CRs for that CRD. This, of course, could have dire unintended consequences. #### Rollbacks Rollbacks in Helm are a special kind of upgrade in which an old release is replayed over a newer release. Along with all of the drawbacks of upgrades, rollbacks present a few special challenges. If a CRD is rolled back, then the old version will overwrite the new version. There are two important cases here: (a) the older chart _does not have the CRD_, or (b) the older chart has an _older version of the CRD_. ##### Rollback target does not have the CRD Consider the case where we roll back from revision 2 to revision 1 of a release, and revision 2 introduced a CRD that was not present in revision 1. In this case, the _proper_ behavior for Helm is to _delete the CRD_ from revision 2 when rolling back to revision 1. As previously mentioned, that will cause a cascading delete of all CRs for that CRD. In some circumstances, this is as desired. But in other circumstances, this could destroy resources belonging to other consumers of that CRD, or even destroy data that was needed during a recovery (e.g. roll back to one version, then upgrade from there). Thus, there are multiple avenues in which undesirable destruction of data may occur. ##### Rollback target has an older version of the CRD In this case, both revision 1 and revision 2 have the CRD, but the version of the CRD changes between revisions. During a rollback, the proper behavior would be to roll back the CRD to its older version. But this is where Kubernetes' behavior gets interesting: - Any instance that was created as a new version will _stay_ as a new version, even though its `apiVersion` field will be rewritten to the old version. - Kubernetes' behavior in this situation is undefined when it comes to version sorting. If a CRD version existed, and then no longer exists, it is unclear how Kubernetes will behave. - It is unclear how the schemata will be applied in this case - It is also unclear what will happen if the version number of the CRD that was rolled back is then used again, but with a different CRD schema. In some cases, client users will see schema errors, but the stored version may persist with a non-compliant body until it is cleaned up by a user. Thus, rollbacks have a few special cases where the uncertainty of Kubernetes' behavior could cause issues that are exceedingly hard to debug. ## Rejected Ideas Proposed Solutions for Helm CRD Management In this section, we turn from enumerating problems to evaluating potential solutions. We understand that Helm users want a way to hide the complexity of CRDs and be able to do "simple things" like upgrade a CRD from one version to another without accidentally destroying data or harming other parts of the cluster. This has been a difficult goal to achieve though. As we progress through potential solutions, keep in mind the roles and caveats elaborated before: - Chart authors create charts - Helm users install and manage instances of those charts - We cannot assume that those roles are filled by the same person - We cannot assume, specifically, that a Helm user understands the inner workings of a chart or even of Kubernetes - We cannot assume that a Helm user looks at the contents of a chart - We cannot assume that a chart author knows the target cluster environment - We cannot assume that a chart author knows what other things will be running concurrently in the same cluster as the chart - We NEVER want to assert that it's "the users problem" to figure out when a chart operation (install, upgrade, delete, rollback) could cause a catastrophic cluster event reaching beyond the specific chart installation. The following kinds of solutions have been suggested: 1. Do not manage CRDs any differently than other resources 2. Helm should let chart authors control how CRDs are managed 3. Helm should let Helm users control how CRDs are managed 4. Helm should have deep special-case logic for handling CRDs Each of these is discussed below. ### No Special CRD Management In this solution, a CRD is treated no differently than any other Kubernetes kind. _Prima facie_, this solution sounds like a no-nonsense go-to. Just drop CRDs in like any other resource and let the world figure out how to do this. This was our initial approach, and it worked fine in cases where all a chart did was install the CRD and possibly the controller that consumed that CRD. In other words, it worked _only for_ the original CRD case for a global CRD and a single global controller for that CRD. But this strategy did not scale as CRD usage followed new patterns. Earlier in this document, we enumerated different CRD patterns that have emerged. Helm's original design does not work as soon as CRDs break out of the simple case. It failed for the following reasons: 1. CRDs alter the behavior of the API server. Specifically, discovery and validation change when a CRD is added or modified. 2. It is impossible to pre-verify a chart that has both a CRD and CRs for that CRD 3. `helm delete` becomes a very, very dangerous command, as it can destabilize a cluster by deleting a CRD 4. `helm upgrade` and `helm rollback` can have surprising consequences that are difficult to find and debug We still haven't solved #2, but by adding some special treatment of CRDs in Helm 3, we eliminated #3-4 and fixed #1. > **IMPORTANT**: It is still possible to use Helm this way. For CRD/Operator-only charts, this is a perfectly legitimate way of packaging. ### Chart Authors Have Control In this category, the assertion is that the _chart author_ should be able to declare the conditions under which a chart is created, upgrade, or deleted. For example, one chart author may stipulate that on an upgrade, their chart should avoid modifying the CRD. Another chart author, though, may choose that on upgrade, their chart will modify the existing CRD. The problems that this approach must address are: - How can a chart author know when it is safe to install, upgrade, or delete a CRD without harming the broader cluster? - How can massive data loss be prevented when a CRD is deleted? - How can two versions of the same chart (with different CRD versions) be safely installed on the same cluster? - Can the user opt to override this behavior if they detect an issue? (And if so, how?) As a broad category, this solution has been proposed several times. In fact, Helm 3 has a very weak version of this: If a CRD is stored in the `crds/` folder, by default it will be installed (and a user can skip with `--skip-crds`). This install only occurs if the CRD is not already present. If the CRD is present _it is not modified_. Following this strategy, _at worst_ the only package that sustains damage if the CRD is not at the right version is the package just installed. No existing behavior is broken. We frequently hear the complain that the above is not enough; that we _must_ also support updates and deletions. But no _specific comprehensive_ solution has surfaced that solves the problems above. Adherents of this view typically claim that users should merely accept the fact that a chart operation may destabilize an entire cluster by altering or deleting CRDs. We do not view that as an acceptable risk. ### Helm Users Have Control In this model, the creation, modification, and deletion of CRDs is under the explicit control of the Helm user. A chart may declare a CRD, but that CRD is not changed unless the user specifically requests it. One could imagine, in this model, the following commands and flags: ```console $ helm install --with-crds ... $ helm upgrade --allow-crd-modification ... $ helm delete --unsafe-delete-crds ... ``` But with this model, there are also problems: - How does the user even know when a chart has a CRD? (If the answer is "the user has to read the chart," this is a non-starter) - How does the user know whether it is safe to update a CRD? Or even that the CRD version or schema or fields have changed? - How does the user discover whether the CRD is in use in namespaces that the user does not have access to? - How does the user avoid catastrophic data loss on deletion? We have not discovered satisfactory answers to these questions, which has led us away from implementing this approach. ### Helm Itself Has Control This is probably the most ambitious of the proposed solutions, and unsurprisingly the most frequently recommended as well. In this case, Helm itself has highly specialized logic that allows it to make decisions about when to install, upgrade, and delete CRDs. Both users and chart developers are "off the hook" when it comes to decision-making. Helm just _knows_. As things currently stand, there is no way for us to implement this. Basically every problem raised in this document is unsolved for this particular proposal. Helm can reliably determine if a CRD already exists, and can install a CRD if it does not exist and if the Helm user has sufficient permissions. But we have been unable to devise any way to solve the myriad upgrade, rollback, and deletion problems as well as the upgrade-on-install case for a CRD that already exists. ## How To Teach This A critical challenge for Helm 3 has been to educate the Helm community about why the maintainers have made the choices we have made. Thee first step in teaching this has been to make the rationale generally accessible. We hope the present HIP accomplishes this. But beyond that, we may need to head off some common misconceptions directly. The remainder of this section discusses those. ### Nobody is "Blocked" on This It has been claimed that this issue is a "blocker" to using Helm. While we hear this claim on occasion, it stems from a misunderstanding. First, there are widely documented patterns and work-arounds for how to handle CRDs. The most common is the pattern of separating CRDs into a separate chart that then treats these CRDs as standard resources. Second, if that doesn't work for you, then there is a way to implement whatever system you want. Helm provides a plugin mechanism that can add new Helm commands. Third, Helm provides another mechanism that can send intermediate results to an external processor before issuing commands against the API server. This "post-render hook" system allows for custom processing in-flight. Finally, of course, Helm provides `helm template`, which allows users to render the chart into static YAML that they can then send to the cluster using their own tools. So there are _four separate avenues_ with which you can pursue implementing more advanced CRD handling. None of them require knowing Go or opening PRs or even getting feedback from the core maintainers. None of them require that you pass any of the quality gates enumerated above. You are free to handle CRDs however you want. To get you started, here are some useful links: - Read the [CRD Best Practices](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/) guide - Learn about [plugins](https://helm.sh/docs/topics/plugins/) - Use a [post-render](https://helm.sh/docs/topics/advanced/#post-rendering) - Export YAML with [helm template](https://helm.sh/docs/helm/helm_template/#helm-template) Helm maintainers are not trying to prevent usage of CRDs. As we've stated above, though, our quality bar is high because we have a lot of people depending on us. But we have provided ways for you to achieve your own goals without meeting our standards or objectives. And perhaps others would find use in the plugins or tools you provide. ### Helm Is Still Working On Thus, But We Cannot Solve It Alone CRDs continue to present a huge challenge to Kubernetes users in general. Helm perhaps has it worse than other projects, as Helm is a generic solution to a generic problem (Kubernetes package management). Helm knows nothing of a cluster's stability, intent, architecture, or the social organization around it. Thus, to Helm, a development cluster with one user is no different than a thousand-node multi-tenant cluster with rigid RBACs. We earnestly want to find a solution to the CRD problem, but we are adamant about not sacrificing Helm's usability in the name of flexibility. If a simple CRD operation like an upgrade or a delete can destroy data across a cluster, or can silently break dozens of applications, we simply choose not to provide that operation via Helm. If we can solve the problems presented above, we can support CRDs robustly. That is our desired goal. But in our estimation, Kubernetes is not yet mature enough for us to be able to do this. When we begin work on Helm 4, we will of course revisit the subject, but the guidelines in this document will still serve as guidance on Helm 4. ================================================ FILE: community/hips/hip-0012.md ================================================ --- title: Helm 4 Development Process sidebar_label: "0012: Helm 4 Development Process" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0012 | Helm 4 Development Process | Matt Butcher , George Jenkins , Matt Farina | 2021-04-02 | process | accepted | ## Abstract Helm 4 is planned as the next major version release of Helm. Continuing to evolve Helm in its role as the Kubernetes package manager. This HIP outlines the requirements and process for building Helm 4. It describes the scope of Helm 4 changes, with a focus on maintaining continuity within the Helm ecosystem. This HIP also aims for an open and productive process that enables Helm 4 to build upon the success of Helm 3. To continue advancing Helm and its ecosystem for the benefit of the Helm community. ## Motivation Helm 3 has been greatly successful, and Helm has built a significant ecosystem around the Helm client (CLI), charts, chart repositories, SDK, plugins, etc. As Kubernetes continues to grow and change, Helm needs to adapt while continuing to add new features and functionality to support its mission as Kubernetes' package manager. However, Helm has accumulated debt. One significant issue with Helm 3 is that making many (good) changes is overly difficult due to Helm's [HIP-0004](./hip-0004.md) backwards compatibility guarantees –- behavioral or API incompatible changes are not allowed during regular minor/patch version releases. Helm 4 as a major release allows the project to make breaking API and other changes, which will enable it to reduce technical debt and leverage newer capabilities of Kubernetes. However, Helm 4 must maintain continuity in the Helm ecosystem. It is crucial that Helm 4 be largely functionally/feature compatible with Helm 3. Significant functional breakage will prevent users from easily migrating to Helm 4 and, at best, delay Helm 4's uptake and incur costs for Helm's users. And at worst, could splinter the Helm ecosystem. The project also aims to timebox the Helm 4 release process. Given the limited community resources available to enact changes, it is considered more important to produce a Helm 4 release that can deliver significant benefits in a moderate timeframe than a prolonged process that takes too long to provide meaningful results. ## Rationale During the Helm 3 development process, Helm core maintainers received criticism that the process was not transparent enough. This proposal aims to outline a formal process for a successful Helm 4 release to address those criticisms. Further criticism included a lack of clarity regarding who was in charge and how decisions were being made, as well as uncertainty about the criteria used for determining when Helm 3 was complete. This document is intended to address these criticisms by presenting a clear plan for the timely delivery of a valuable Helm 4 release to the community. It describes the process in detail, providing both a roadmap for us to follow and a point of reference for community members to use when contributing changes. The process is based on the following ideas: - Requiring changes to be documented, either as reduced "Helm 4 proposals" (H4HIP) or standard HIPs. Allowing both Helm community members and maintainers to review them. This oversight ensures that changes are in line with this HIP, regarding their functional and architectural implementation. Additionally, documented changes enable contributors to independently implement agreed-upon proposals in coordination with the release engineer. - Requiring a timeboxed development effort intends to promote focus on the most valuable changes that the community and maintainers can deliver within a reasonable timeframe. It also aims to prevent an "open-ended" development cycle that might drag on or fizzle out. Ideally, the majority of changes will be proposed and agreed upon during the planning phase of the development cycle. However, amendments to the initial scope are permitted as long as they can fit within the agreed-upon timeframe. Explicitly allowing for scope amendments ensures that any changes are well thought out. For changes that don't make it into Helm 4's initial development cycle, they can included in Helm 4.x feature releases (subject to minor release compatibility guarantees). And for further changes, there will be a Helm 5 release of course! ## Specification ### The process / timelines Helm 4 development will consist of three main phases: 1. Planning 1. Feature development 1. Release preparation The timeline will be approximately: 1. Marking this HIP as "accepted" 1. Naming of a Release Engineer: Nov. 2024 1. Kick-off: KubeCon/CloudNativeCon North America 2024 (Nov. 2024, Salt Lake City) 1. Earliest that engineering can begin: Nov. 2024 1. Feature freeze for release preparation: By Aug. 2025 1. Expected release of Helm v4.0.0: By the week before KubeCon/CloudNativeCon North America 2025 (expected Nov. 2025) Helm v4.1.0 release will be 3 months later (expected Jan. 2026 for the above timeline). And from then on Helm 4 minor releases will follow the same release cadence as Helm v3, shadowing Kubernetes by approximately 1 month. Helm 3 will reach end of life 6-8 months after Helm 4 release (July 2026 estimated) ### Change suitability The Helm ecosystem is large, including not just the Helm CLI but also the SDK, Charts, and Chart repositories, plugins. Helm also has several [roles or personas](/community/user-profiles) for different user categories, from "Application Operators" to "Helm Developers." The Helm project must be careful in how it delivers changes without causing significant adverse impact to Helm's users or the overall Helm ecosystem. Therefore, while Helm 4 does not need to be semantically backwards compatible with Helm 3, it must not cause significant breakage for users who adopt Helm 4. Clear migration options and paths should be documented and presented for Helm 3 users to update to Helm 4. ### Change proposals To ensure that Helm 4 changes align with this HIP, Helm core maintainers will review proposals. These proposals can take the form of lighter-weight Helm 4-specific proposals "H4HIP"s, or standard HIPs suitable for Helm 4 implementation. Standard Helm HIPs that are marked suitable for Helm 4 will also be accepted. #### Helm 4 proposals (H4HIPs) A H4HIP is simply a reduced version of a standard Helm HIP. They follow the same format as a HIP, but the author can choose to skip sections they do not feel applicable. Intended to minimize the friction required for implementing small, functional changes in Helm 4 that do not warrant a full HIP process. And to allow categorization of changes specific to the Helm 4 process and changes. As well as to avoid feature development from Github issues. ### Compatibility Even though Helm 4 is a major version release not bound by [HIP-0004](./hip-0004.md) compatibility guarantees, it must remain largely feature/functionality compatible with Helm 3. Due to Helm's maturity and the extensive ecosystem built around its CLI, charts, SDK, etc. Where non-compatible changes are introduced, they should have migration documentation for equivalent functionality. Functionality removal should prefer deprecation over immediate removal. Behavioral changes that negatively impact a significant number of users without reasonable migration options cannot be allowed. Specific requirements for compatibility include the following: #### Compatibility with existing charts and releases While the tooling can evolve, Helm must maintain compatibility with existing charts and releases. A Helm 4 that cannot operate on Helm 3 charts (and vice versa) effectively becomes a different tool, which likely would diverge the Helm ecosystem. Specifically, charts deployable with Helm 3 should be deployable by Helm 4. Similarly, any existing chart (release) managed by Helm 3 must be upgradable by Helm 4. However, Helm 3 may not be able to manage releases created using later Helm 4.x series (which may introduce incompatible changes). Exceptions for already deprecated functionality, such as `requirements.yaml`, may be made. #### Compatibility with existing CLI workflows The Helm CLI is deeply integrated into thousands of release pipelines and automation systems, so while it can evolve, it must remain loosely compatible with existing users' workflows. A judgment call will be required by the release engineer and maintainers regarding how much a given change might impact user workflows. Possible mitigation strategies for those changes should also be considered. As a baseline, most "Application Operator" users of Helm 3 CLI should experience no disruption or minimal adjustments to their workflows during the upgrade to Helm 4. Changes should be clearly documented in a migration guide. More advanced users, such as "Application Developers," might be subject to more significant changes at the discretion of the release engineer and maintainers. ### The Release Engineer A single individual will oversee the planning and development phases of Helm 4. This person will be the _Release Engineer_. For Helm v4 the _Release Engineer_ will be Matt Farina. The person will have the following responsibilities: - Lead the kick-off meeting - Define the process for including features - Determine the timelines for development - Make the determination of when the project has indeed reached a milestone - Name and oversee releases - After the release, the release engineer will determine what the "intent" of a Helm behavior was (which informs determining whether an incoming breaking change is a feature or a bug fix) #### Determining Who Will Be Release Engineer To become the release engineer for the Helm project, an individual must be a core maintainer on project. The engineer must be an active core maintainer. Self-nominations are encouraged, and potential nominees must agree to their nomination. The Helm project maintainers will then decide which nominated maintainer should serve as the release engineer. If the release engineer is unable to fulfill their duties, the Helm project maintainers may select a replacement. #### Planning This phase begins when the release engineer is appointed. The goal of the planning phase is to have a specific period to prioritize writing and reviewing proposals. And enable time to focus on buidling, prioritizing and reviewing the major changes for Helm 4. The release engineer shall schedule a kick-off meeting, inviting all Helm maintainers from any Helm org project to attend. The release engineer may also decide who else to include and whether the meeting will be public. During the kick-off meeting, participants are encouraged to propose feature ideas and changes, with preference given to those already documented as HIPs. This process continues until the release engineer deems it sufficient, but for a minimum of two months, to allow ample community input. All proposed features and breaking changes must be described in a standard HIP or Helm 4 proposal (H4HIP). This approach offers several advantages: - All changes are documented - Changes undergo scrutiny before PR creation - A clear record of alternative considerations exists Minor non-functional changes for "bug fixes" or cleanup, as determined by core maintainers, do not require formal proposals. The outcome of the planning cycle is a well-documented list of approved HIPs detailing Helm 4's major changes. This list will serve as the foundation for working on Helm 4. Items which are readily agreeable for Helm 4 (as determined by the release engineer and core maintainers) may begin implementation during the planning phase. Cleanup and non-functional changes may proceed while in the planning phase. #### Feature Development During this phase, agreed-upon features and changes from the planning stage will be implemented. Breaking changes are permitted, as well as experimental features that may be removed before final release. The approval process for PRs remains as previously defined within the project, but any PR not aligned with the current plan must receive approval from the Release Engineer. Additional features can be propsed during the feature development phase, at the release engineers discretion. This phase concludes with Alpha releases, where new features can still be incorporated and breaking changes may be implemented at the release engineer's discretion. #### Release Preparation During this final phase, no new features will be added except for those deemed critical by the release engineer. The focus shifts towards bug fixes, documentation improvement, security audits and addresses, and preparation of the ecosystem, such as chart modifications. All Beta and Release Candidates (RC) are produced during this stage. Before the stable release, there will be a 4-6 week testing period for public feedback. The duration is determined based on the testing progress and the trust in the code leading up to the release candidate window. This phase concludes when Helm `v4.0.0` is released, but it must not be shorter than a three-month duration to ensure adequate time for ecosystem testing and feedback. ### Halting Helm 4 Development During the course of Helm 4 development, it may become clear that there is not enough justification for continuing development. Reasons could include insufficient feature HIPs or lack of sponsorship and support from Helm project maintainers. If this occurs, the Helm maintainers can hold a "circuit breaker" vote to temporarily halt Helm 4 development until a more suitable time arises. The procedure for stopping Helm 4 development requires a simple majority vote among the Helm project maintainers. ### Maintaining Helm 3 This section outlines how we will support Helm 3 throughout the Helm 4 development process. The Release Engineer retains the freedom to modify this approach for the sake of providing the best experience to Helm users. During the "Feature Development" phase of Helm 4, Helm 3 will continue to receive security, bug, and minor feature patches. During the Alpha, Beta, and RC phases of Helm 4, no feature patches will be applied to Helm 3 to avoid introducing Helm 4 features prematurely while Helm 4's features are locked. Helm 3 will receive bug fixes for 6-8 months following the release of Helm 4 and security fixes for one year from the day Helm 4 is made available. ## Backwards compatibility Nothing in this document contradicts our existing decision-making process. Specifically, [HIP-0004](./hip-0004.md) pertains only to minor and patch releases, not major version releases. This does not affect the PR review process or the HIP process, as both are expected to remain unchanged. ## How to teach this The plans for Helm 4 will to be announced during KubeCon/CloudNativeCon North America 2024 at both the Helm Maintainers talk and Helm 'contribfest'. The content of this HIP will be discussed publicly in the regular Helm Dev meetings, which are recorded. Throughout all stages of Helm 4 development, the Release Engineer is committed to providing updates on progress during no fewer than two Helm public dev calls per month. ## Rejected ideas Helm 3 was primarily developed using an informal version of the proposed process, but we were criticized for lacking documentation and transparency. This proposal presents an alternative to an "informal process," which might elicit similar criticism. Multiple release engineers were considered, but deemed inappropriate for two reasons: 1. The need for a singular authority in charge of architectural integrity and resolution 2. The lack of sufficient Helm core maintainers to justify a committee We entertained the idea of allowing a non-core maintainer to serve as release engineer, but rejected it due to these concerns: 1. A release engineer requires comprehensive knowledge of Helm's design, intents, and implementation, which is best ensured through maintainer status 2. A non-core maintainer is not bound by the core maintainer process, potentially introducing tension and exceptionalism We pondered enabling any Helm maintainer from any project to serve as the release engineer for Helm, but determined that the in-depth technical knowledge of the Helm core codebase is essential for this role's successful execution. We regard the release engineer position as more akin to an architect than a project manager. We considered restricting the release engineer role to org maintainers, but decided against it since their focus is on organizational (not technical) aspects of the project. Release engineering is beyond their charter. We debated abandoning the requirement for HIPs or written proposals for features and changes during the Helm 4 process, as we had done so in the past. However, we also faced pushback from the community regarding major changes being implemented without proper discussion. Furthermore, there is a lack of documentation detailing past decisions made in Helm 2, with only a few draft documents available in Helm 3. Therefore, HIPs and their lighter-weigtht couterparts "Helm 4 proposals" (H4HIPs) will serve as a platform for public discourse and provide a recorded decision-making process. While some may argue this adds unnecessary overhead, we believe the advantages far outweigh the burden. We considered eliminating the mandatory minimum durations for planning and release preparation periods. However, careful consideration is required during a major version transition on a project as impactful as Helm's. It is in the community's best interest for developers to proceed at a deliberate pace with clearly defined timeframes. ================================================ FILE: community/hips/hip-0014.md ================================================ --- title: Helm Triage Maintainers sidebar_label: "0014: Helm Triage Maintainers" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0014 | Helm Triage Maintainers | Matthew Fisher | 2021-07-06 | process | accepted | ## Abstract The existing Helm Project Maintainers have identified the need for a new "triage" role. This document lists out the responsibilities of this new role. ## Motivation Helm Project Maintainers are responsible for activities surrounding the development and release of code, the operation of any services they own (e.g. ), or the tasks needed to execute their project (e.g., community management, setting up an event booth). Introducing a new "Helm Triage Maintainer" role allows new project maintainers to join the project without the responsibilities of release management, service operation, or event management. This new role provides three benefits: 1. New Triage Maintainers can help maintain the project's day-to-day, such as responding to new tickets and review pull requests 2. Helm project maintainers' burden is reduced, allowing them to carry out higher-level tasks like coordinating software releases, organizing events, and maintaining production services. 3. Provides an easier on-ramp from community members, to Triage Maintainers, to project maintainers, to org maintainers. ## Rationale Project maintainers are looking for new members to join the project. However, community members have expressed in the past that they cannot commit more than a few hours per month to the project. Additionally, some project maintainers are concerned providing newer members the "keys to the castle" prior to a formal vetting process may introduce significant risk to the project's users. A new maintainer may be available to help maintain the project, but it may take several months before trust is established. ## Specification The new Triage Maintainer role is allowed to perform certain day-to-day tasks as a maintainer of the project, including: - attach labels to issues - assign issues to milestones - review and approve pull requests - nominate new Triage Maintainers - nominate new Core Maintainers The following roles and responsibilities are NOT allowed to be performed under this role: - merge pull requests - release new revisions of the Helm Client - operate any public-facing services, such as - - Mailing lists - Slack channels - The helm/helm GitHub project - organize official LF events (Helm Summit) - vote on governance-related topics (including membership votes) - become a member of the security team - receive access to the helm_project Keybase team - receive access to the cncf-helm-core-maintainers mailing list These restrictions can be waived if these responsibilities are performed under direct supervision of a Helm Project Maintainer. For example, if a Helm Triage Maintainer would like to learn the release process, they may "shadow" the Helm Project Maintainer that is assigned as the release engineer. Triage Maintainers may also join the Helm Summit Program Committee to help review CFPs, but cannot be assigned the role of Program Chair. The same rules about active maintainers applies to Triage Maintainers. Triage maintainers MUST remain active on the project. If they are unresponsive for > 3 months they will lose maintainer status unless a super-majority of the other project maintainers agrees to extend the period to be greater than 3 months. The same voting process as Core Maintainers apply to Triage Maintainers. Nominations are sent to the [public helm mailing list](https://lists.cncf.io/g/cncf-helm). Users must declare who they wish to nominate as Triage Maintainer. Self-nominations are accepted. Afterwards, the Core Maintainers call for a vote on the internal Core Maintainer mailing list. If a two-thirds majority agree to the vote, the nomination passes. ## Backwards compatibility Community members may still request for a vote to join as a full project maintainer. This new role provides an additional option to join the project at a lower commitment level. ## Security implications The role helps protect the Helm Client and its users from new maintainers with malicious intent to de-rail or otherwise "pwn" the project. As Helm is one of the CNCF's most popular projects, a certain level of care and caution should be taken when providing new members access to production services. This new role helps keep the list of maintainers with production system access to a minimum. ## How to teach this The contents of this HIP will be discussed in the public Helm Dev meeting, which is recorded. ## Rejected ideas The author considered whether a Triage Maintainer could perform the duties of a release engineer, but rejected as a release engineer needs detailed information about the project's design, intents, and implementation. These tenets are not necessarily required to be a Triage Maintainer. ## Open Questions All of the Helm project's secret credentials are stored in the helm_project Keybase team, which we currently use for cross-communication between other project maintainer groups. This is a shared team - every project maintainer (helm, helm-www, chartmuseum, etc.) has access to the credentials in that account. Should those credentials be moved elsewhere so we can invite Triage Maintainers to the channel, or should Triage Maintainers be restricted to the mailing list/slack channels? A: It's probably best to use the mailing list/slack channels for this role; the Triage Maintainer is (hopefully) a stepping stone to project maintainer, which requires access to Keybase. ## References - The Helm organization's [governance structure](/community/governance/governance) - The Helm organization's [team structure](https://github.com/helm/community/blob/main/maintainer-groups.yaml) ================================================ FILE: community/hips/hip-0015.md ================================================ --- title: Annotation for Images used by Helm Charts sidebar_label: "0015: Annotation for Images used by Helm Charts" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0015 | Annotation for Images used by Helm Charts | Tom Runyon , Scott Rigby , Andrew Block | 2021-10-07 | feature | draft | ## Abstract The images used by a Helm chart is not easily discoverable in the chart definition. When deploying Operators and CRDs, the images needed to instantate all the pods for a Helm release may not be present by templating the default values for a Helm chart, whic provides blockers when automatically discovering dependencies for Bill of Materials. ## Motivation Without a standard methodology for defining the images used by a chart, third party applications that require metadata for Helm Charts are using custom keys unique to their application, e.g. [Artifact Hub](https://artifacthub.io/docs/topics/annotations/helm/#supported-annotations) or [Openshift](https://docs.openshift.com/container-platform/4.8/operators/operator_sdk/osdk-generating-csvs.html#olm-enabling-operator-for-restricted-network_osdk-generating-csvs). By Standardizing metadata, charts can be built to be consumable by a varity of tools for metadata, bill of materials, airgap deployments, etc. Current solutions of dynamically discovering the images needed by templating the chart do not account for all possible templating paths for the chart, nor capture images that are deployed as part of an Operator paradigm and not defined explicitly as pods in the helm chart. ## Rationale The `helm.sh` prefix identifies the standard belonging to the Helm community, and the `/images` path clearly identifies the type of objects being identified. The annotation will define a string that can be parsed into a list that the chart maintainer will manage as they knowingly adjust the images needed for the chart's deployment. Each element of this image list will contain at least a `name` for the image as well as a location for the image in the `image` field. and an optional `dependency` field described in the specification. The elements _may_ have additional properties to meet additional use cases, such as the `whitelisted` field used by ArtifactHub, or providing a public key for signed images. The additional fields are not part of this standard, but how they get attached to each image _is_. ## Specification A helm chart would be define the images in the `annotations` field: ```yaml apiVersion: v1 version: 6.0.0 appVersion: 6.0.0 name: podinfo engine: gotpl description: Podinfo Helm chart for Kubernetes home: https://github.com/stefanprodan/podinfo maintainers: - email: stefanprodan@users.noreply.github.com name: stefanprodan sources: - https://github.com/stefanprodan/podinfo kubeVersion: ">=1.19.0-0" annotations: helm.sh/images: | - name: podinfo image: ghcr.io/stefanprodan/podinfo:6.0.0 - name: redis image: dockerhub.io/_/redis:6.0.8 whitelisted: true ``` When a chart contains a dependency or subchart, the expection is that the metadata of the dependency/sub chart will contain the `helm.sh/images` annotation to identify the images required by the dependency chart. If that isn't true, the top level chart can provide the images entry for that chart and use the optional `dependency` field to identify the sub chart that the image is used in. For example, the Bitnami Kafka chart would identify the images used in `common` and `zookeeper` as part of the `kafka` chart metadat: ```yaml annotations: category: Infrastructure images: | - name: kafka image: docker.io/bitnami/kafka:2.8.1-debian-10-r0 - name: kubectl image: docker.io/bitnami/kubectl:1.19.5-debian-10-r3 - name: shell image: docker.io/bitnami/bitnami-shell:10-debian-10-r199 - name: kafka-exporter image: docker.io/bitnami/kafka-exporter:1.4.2-debian-10-r5 - name: jmx-exporter image: docker.io/bitnami/bitnami/jmx-exporter:0.16.1-debian-10-r66 - name: zookeeper image: docker.io/bitnami/zookeeper:3.7.0-debian-10-r157 dependency: zookeeper - name: shell image: docker.io/bitnami/bitnami-shell:10-debian-10-r202 dependency: zookeeper apiVersion: v2 appVersion: 2.8.1 dependencies: - name: common repository: https://charts.bitnami.com/bitnami tags: - bitnami-common version: 1.x.x - condition: zookeeper.enabled name: zookeeper repository: https://charts.bitnami.com/bitnami version: 7.x.x description: Apache Kafka is a distributed streaming platform. engine: gotpl home: https://github.com/bitnami/charts/tree/master/bitnami/kafka icon: https://bitnami.com/assets/stacks/kafka/img/kafka-stack-220x234.png keywords: - kafka - zookeeper - streaming - producer - consumer maintainers: - email: containers@bitnami.com name: Bitnami name: kafka sources: - https://github.com/bitnami/bitnami-docker-kafka - https://kafka.apache.org/ version: 14.2.1 ``` It's worth noting that the `bitnami-shell` image is used in both zookeeper and kafka, but with different tags. ## Backwards compatibility Since there is no existing specification, the annotation will be optional to support backwards compatibility. ## Security implications Have to think about it, but don't see any. ## How to teach this The specification can be added to documentation around building helm charts, and exmaples of tools using this feature (e.g. ArtifactHub) would facilitate adoption/clarity on how its used. ## Rejected Ideas ### Helm Templating Discovery The methodology of dynamically discovering images used by a chart _can_ work in certain situations but also has limitations with images that are only used for certain use cases, as well as operator charts that don't expose the images needed as part of the rendered manifests. ================================================ FILE: community/hips/hip-0016.md ================================================ --- title: Add export-values directive (similar to import-values) sidebar_label: "0016: Add export-values directive (similar to import-values)" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0016 | Add export-values directive (similar to import-values) | Jan von Loewenstein , Johannes Dillmann , Pavel Busko , Philipp Stehle , Ralf Pannemans , Sumit Kulhadia | 2022-02-01 | feature | draft | ## Abstract Composing Helm charts using dependencies is currently limited because it is not possible to create a chart with a defined set of values and distribute them to subcharts. With the `import-values` directive, there is a mechanism in Helm to use the default values of a subchart as a value in the parent chart and define the name under which the subchart value is available in the parent chart. This HIP proposes an `export-values` directive which is similar to the [`import-values`][import-values] directive, and allows exporting values from the parent chart to the subchart and defining the name under which it should be available. With that the values of the parent chart and the values of the subcharts can be defined independently. Subcharts can use their local values exclusively and don't have to be aware of the usage as a subchart. Parent charts on the other hand, can provide a consistent configuration api to their users and orchestrate the exchange of values between the subcharts using `export-values`, `import-values` or a combination thereof. This change was discussed in [helm/#3242]. There were several attempts to implement this: [helm/#7477], [helm/#10059]. ## Specification With the proposed `export-values` directive, users are able to specify in the **parent** chart (snippet below) which and where values should be exported to the **subchart**. ```yaml # Chart.yaml: dependencies: - name: client version: 1.0.0 export-values: - parent: "port" child: "serverPort" - name: server version: 1.0.0 export-values: - parent: "port" child: "exposePort" - "server-config" ``` ```yaml # values.yaml port: 8080 exports: server-config: debug: true ``` ```yaml # charts/client/values.yaml serverPort: 9090 ``` ```yaml # charts/server/values.yaml exposePort: 80 debug: false ``` ### Value Precedence Because later changing the order of precedence between value-sources would be a breaking change (same input, but potentially different output), we should agree on an intuitive and user-friendly order of precedence before implementing this HIP. Suggested precedence: 1. Explicitly set for subchart value (`client.port`) 1. Explicitly set for parent chart's value (`port`) 1. default for parent chart's value (`values.yaml` in parent chart) 1. default for subchart value (`values.yaml` in subchart) For the example above, this would mean that `.Values.port`, `.Values.client.serverPort` and `.Values.server.exposePort` will default to `8080` unless e.g. `--set port=1234` is provided via flags, which would overwrite all these values. In contrast using e.g. `--set client.serverPort=42` would only overwrite the `.Values.client.serverPort` value. ### Combination with `import-values` It should be able to use both, `export-values` and `import-values` independently and in combination. It should also be possible to export a value which was imported from a third chart. ## Motivation Currently, it is not possible to compose charts using dependencies without leaking the structure of the values of the subcharts used. Users of a parent chart instead have to provide values to the subcharts directly. Alternatively, users can provide `global` values, but in that case the subcharts need to be aware of the fact that they are used as a dependency. In addition, `global` values are available globally as the name suggests and hence multiple subcharts have to have aligned value keys. As a result, the parent chart and its dependencies are rather tightly coupled. This HIP would allow to freely structure the values the user interacts with. The problem described above is less severe, if the subchart author, parent chart author and consumer are the same person or team. It becomes much more relevant for parent chart authors, that want to consume existing charts and provide it to a number of users without leaking the internal structure (i.e. the fact that it is using subcharts and how many) to the users. ## Rationale Using the same parent chart as in the [specification](#specification) without `export-value`, the `port` value must match and must be specified twice by the user. ```yaml # values.yaml client: serverPort: 8080 server: exposePort: 8080 ``` The proposed structure is not only cleaner for the user, but also less error prone since the port value is only maintained once. ## Backwards Compatibility On one hand this change won't break any existing Helm chart since it only adds new mechanisms. On the other hand installing a chart which requires this feature with older versions of Helm make it fail silently, as values won't be passed to the child. There is currently no way to specify a minimum Helm version. The current workaround is to add this to a parent chart template, which will fix the otherwise silent failure: `{{- if semverCompare ">3.10.0" .Capabilities.HelmVersion.Version }} {{- fail "This chart requires helm version 3.10.0 or higher" }} {{- end }}`. A built-in mechanism to specify a minimum Helm version for a chart could be introduced in a separate HIP. Until such time, the introduction of this `export-values` functionality would require documenting this workaround for chart authors who wish to make their parent charts depend on the Helm version that introduced this functionality. ## Reference Implementation TBD [helm/#3242]: https://github.com/helm/helm/issues/3242 [helm/#7477]: https://github.com/helm/helm/pull/7477 [helm/#10059]: https://github.com/helm/helm/pull/10059 [import-values]: https://helm.sh/docs/topics/charts/#importing-child-values-via-dependencies ================================================ FILE: community/hips/hip-0017.md ================================================ --- title: Helm OCI MediaType Registration sidebar_label: "0017: Helm OCI MediaType Registration" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0017 | Helm OCI MediaType Registration | Andrew Block | 2022-06-09 | informational | accepted | ## Abstract The use of OCI artifacts is one of the packaging methods available in Helm. A Helm OCI artifact is comprised of multiple component, each defined by a specific Media Type. Media Types are managed by the [Internet Assigned Numbers Authority (IANA)](https://www.iana.org) and each type should be registered with IANA so that it can not only be known by the organization, but also discoverable by end users. The canonical location for Helm Media Types information below is intended to be the IANA [application registry](https://www.iana.org/assignments/media-types/media-types.xhtml#application). This document describes the necessary fields that are associated within the [registration of a Media Type to IANA](https://www.iana.org/form/media-types) form. ## Motivation Support for the storage of Helm charts as OCI artifacts was released in released in General Availability (GA) in version 3.8.0 and with the continued adoption of this storage format, the specifications should be readily available for producers and consumers. Registration of Media Types with the Internet Assigned Numbers Authority has become a standard process within other technologies whom also make use of OCI artifacts so that not only the packaging types can be understood, but also documented. ## Rationale A Generally Available (GA) feature that implements a particular specification should account for its usage. Not only does the registration of Media Types to IANA follow a practice that has been implemented previously, but also provides a better understanding of the Helm project. ## Specification Each Media Type that Helm implements requires their own separate registration to IANA. The sections below detail the properties associated within the registration form for each of the Media Type's that will be submitted to IANA. ### Helm Config The [OCI config](https://github.com/opencontainers/image-spec/blob/main/config.md) containing a JSON formatted representation of the Helm `Chart.yaml` file.   |   ------ | ----- | Type Name | application | | Tree | Vendor Tree (vnd prefix) | | Subtype Name | `cncf.helm.config.v1+json` | | Required Parameters | Fields as required per the Chart.yaml definition | | Optional Parameters | Remaining fields which as defined within the Chart.yaml definition which are not noted as required | | Encoding Considerations | Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259](https://datatracker.ietf.org/doc/html/rfc8259). | | Security Considerations | Similar security concerns common to all JSON content types. See [RFC 7159 Section #12](https://tools.ietf.org/html/rfc7159#section-12) for additional information. The included content as defined by the Helm chart definition may include sensitive assets including personal contact information, source code repositories or other referenceable locations. | | Interoperability Consideration | N/A | | Published specification | [https://helm.sh/docs/topics/charts/#the-chartyaml-file](https://helm.sh/docs/topics/charts/#the-chartyaml-file) | | Application Usage | Internally within the Helm package manager as well as various interfacing applications | | Fragment Identifier Considerations | N/A | | Restrictions on Usage | N/A | | Provisional Registrations | N/A | | Additional Information |
  1. Deprecated alias names for this type: None
  2. Magic number(s): None
  3. File extension(s): .json
  4. Macintosh file type code: TEXT
  5. Object Identifiers: None
| | Intended Usage | Common | | Other Information and Comments | N/A | ### Helm Content Represents the packaged Helm chart.   |   ------ | ----- | Type Name | application | | Tree | Vendor Tree (vnd prefix) | | Subtype Name | `cncf.helm.chart.content.v1.tar+gzip` | | Required Parameters | N/A | | Optional Parameters | N/A | | Encoding Considerations | Binary | | Security Considerations | No security controls are enforced by Helm. The content of a Helm package is not intended to – but may potentially – contain resources that are sensitive in nature. | | Interoperability Consideration | N/A |` | Published specification | None | | Application Usage | Internally within the Helm package manager as well as various interfacing applications | | Fragment Identifier Considerations | N/A | | Restrictions on Usage | N/A | | Provisional Registrations | N/A | | Additional Information |
  1. Deprecated alias names for this type: None
  2. Magic number(s): None
  3. File extension(s): None
  4. Macintosh file type code: None
  5. Object Identifiers: None
| Intended Usage | Common | | Other Information and Comments | N/A | ### Helm Provenance Represents the Helm Provenance file associated with a signed chart.   |   ------ | ----- | Type Name | application | | Tree |Vendor Tree (vnd prefix) | | Subtype Name | `cncf.helm.chart.provenance.v1.prov` | | Required Parameters | Fields as specified within Helm provenance file definition | | Optional Parameters N/A | | Encoding Considerations | The utf-8 charset is always used for this type | | Security Considerations | The contents of a Helm provenance file contains a GnuPG detached ASCII-armored signature of the Helm chart definition file as well as the definition itself. The Helm chart definition may include sensitive assets including personal contact information, source code repositories or other referenceable locations. | Interoperability Consideration | N/A | | Published specification | | | Application Usage | Internally within the Helm package manager as well as various interfacing applications | | Fragment Identifier Considerations | N/A | | Restrictions on Usage | N/A | | Provisional Registrations | N/A | | Additional Information |
  1. Deprecated alias names for this type: None
  2. Magic number(s): None
  3. File extension(s): None
  4. Macintosh file type code: Text
  5. Object Identifiers: None
| | Intended Usage | Common | | Other Information and Comments | N/A | ## Backwards Compatibility N/A ## Security implications N/A ## Reference implementation The responses associated with each Media Type registration has been inspired by the previously registered [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml). ## Rejected ideas None ## Open issues None ## References Existing Media Types of similar category and purpose can be found within the list of registered [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml). The following are examples of media types that have been registered with IANA: * [json](https://www.iana.org/assignments/media-types/application/json) * [gzip](https://www.iana.org/assignments/media-types/application/gzip) * [wasm](https://www.iana.org/assignments/media-types/application/wasm) ================================================ FILE: community/hips/hip-0018.md ================================================ --- title: Add Repository URL and tarball digest to a chart's release metadata sidebar_label: "0018: Add Repository URL and tarball digest to a chart's release metadata" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 18 | Add Repository URL and tarball digest to a chart's release metadata | Luke Reed , Andy Suderman | 2021-11-24 | feature | draft | ## Abstract Currently there is no way of knowing the exact repository that a chart originated from for a given release. There are ways to guess by looking at the sources list in the chart metadata, but since this is provided via the `Chart.yaml` file, any forks of that repository will look identical. The only way to concretely know what the repository URL that was used at install/upgrade time is to populate a repository URL metadata field in the release during the install or upgrade. It should work for both traditional repositories behind an http web server, as well as an OCI compliant repository. The second part of this proposal would include the tarball digest of a chart in the metadata. This aspect is less fleshed out in code yet, but would be a nice alternative for installing a local chart from a tarball when the repository URL would not be known. The reason this is useful is because it can be used when interacting with other third-party databases, such as artifact-hub. ## Motivation The primary motivation is to have a helm-native way to track where a chart came from. Many of the motivations for this feature can be found in this issue: https://github.com/helm/helm/issues/4256. To note a couple: - An admin would like to know where a chart came from only by querying the cluster itself. Currently the only way to know where a chart came from is to keep track of it externally. - Third-party tooling that provides recommendations on helm upgrades can query the cluster to get the repository URL to aid in this recommendation. See [nova](https://github.com/FairwindsOps/nova) as an example. - This metadata field could also populate output for the `helm ls` command in the future. That may be outside the scope of this particular feature. ## Rationale In order to query for this in the cluster, the repository URL will need to be somewhere in the release object. The chart metadata portion of the release object already contains similar data and makes the most sense for this purpose. ## Specification Nothing would change from the user's perspective. With some modifications in the current code it's possible to add this metadata into the release object transparently. The current idea for this implementation is to add a field in both the `ChartDownloader` and `Metadata` (in the `pkg/chart/metadata.go` file) structs to hold the repository URL. The Downloader is the logical place to derive the proper URL and then populate the Metadata field. More specifically, the URL is included in the local repository index file for a locally named repository. For instance, running `helm repo add [NAME] [URL]` would add the repository to the index file with the `[URL]` passed as the real location to download charts. In the helm code, the downloader reads this file to find the URL which is what gets bubbled up to the release object. When installing from either a locally packaged chart, or a locally unpackaged chart (or folder), the repoURL will be set to the value `path` to indicate a local source. The chart metadata object would have new fields that looked like so: ``` "repoURL": "https://charts.fairwinds.com/stable" "tarballDigest": "sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9" ``` And an OCI compliant repository would look like this (example is using ECR): ``` "repoURL": "oci://${ACCOUNT_NUMBER}.dkr.ecr.us-east-1.amazonaws.com/goldilocks" "tarballDigest": "sha256:f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9f9a9" ``` ## Backwards compatibility There should be no impact to backwards compatibility. ## Security implications A potential security issue would be private repository URLs becoming present in a cluster via this implementation. A potential fix for this would be to add a command line argument that would keep this field in the release object empty, but that would introduce something a user has to change in their workflow which may not be desirable. Another way would be to attempt a DNS match against a publicly available DNS server and if it's not found, then we do not populate the repository URL field. Another option is to ignore this potential downside. Unclear if this would truly be an issue or not. Would love to have feedback on why it would be bad for an internal repository URL to be stored in the cluster. If it is decided not to store a private URL by default, we should add a flag to allow it. A potential positive is that including the tarballDigest would mean that utilities could independently verify that a chart has not been altered. However, a caveat should be noted here: There is no guarantee that helm will rebuild exactly the same tarball if presented exactly the same input data because some input metadata (timestamps, ordering) may change. So we wouldn't necessarily want to assume that just because a tarball has a different SHA, it's data has changed and thus it is untrustworthy. The exact handling of this is left to implementation. ## How to teach this The feature can be documented by describing how we get the URL (taken from the description in the [Specification](#specification) section). The usage of this URL is up to a user or third-party tool developer, but the URL would be included in the release object as one more informational piece with no prescribed usage. ## Reference implementation A PR has been created to show a possible implementation: https://github.com/helm/helm/pull/10369 ## Rejected ideas N/A. I don't know of any other ideas proposed for this feature. ## Open issues N/A for now. As for github issues, this is still open and would be solved by this feature: https://github.com/helm/helm/issues/4256 ## References - Github issue that would be fixed by this feature: https://github.com/helm/helm/issues/4256 - Github PR that proposes a solution for this: https://github.com/helm/helm/pull/10369 ================================================ FILE: community/hips/hip-0019.md ================================================ --- title: New annotations for displaying hook output sidebar_label: "0019: New annotations for displaying hook output" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 19 | New annotations for displaying hook output | Ian Zink | 2023-01-26 | feature | draft | ## Abstract This proposes a new annotation to indicate that the output from the hook should be displayed to the user. ## Motivation The one motivation for this HIP is the ability to display preflight checks before the main chart installs. This provides vital feedback to the user as to why a Helm chart can not be successfully installed. Often it is important to verify that the Kubernetes cluster you are deploying a Helm chart into has certain properties. You might need to know that it has an Ingress controller, a certain amount of ephemeral storage, memory, or CPUs available. You might want to validate the service key they provided was correct or that that database they entered is reachable. Letting a Helm install and/or upgrade fail, and then make the user debug this to see why it failed is a poor user experience. These things can all be done with checks enabled by the hook proposed in this HIP. Another common motivation for this HIP is to indicate that database migration output running as a hook should be visible to the user in the case of failure. In general, allowing chart developers to run jobs and present that feedback directly to the users could also open up additional use cases beyond just the preflight use case that motivated this HIP. I could imagine scenarios where maybe CVE warnings are presented or specific upgrade feedback is presented instead of just a Helm install failure. ## Rationale There are other ways that this could be implemented. For example, we could have a separate preflight hook type. However, this new hook type wouldn't be handled at all by previous versions of Helm. With this design, it requires minimal changes to Helm and allows for backwards compatibility. Another strategy could be for Helm to include Troubleshoot.sh as a dependent library, but this could result in too tight of a coupling between the projects and lower overall flexibility and adaptability. ## Specification Templates may include the following annotations on Jobs or Pods: ```yaml "helm.sh/hook": pre-install, pre-upgrade "helm.sh/hook-output-log-policy": hook-failed # or hook-succeeded or hook-failed,hook-succeeded ``` `helm.sh/hook-output-log-policy` would indicate that Helm should display the output of the Job to the user. Additionally, a new user flag should be created `--no-log-output` that would skip the output of logs. Additionally, there will be a new item added to the action SDK configuration to allow SDK consumers to get the output. By default this output will be discarded by writing to `io.Discard`, but an SDK consumer can overwrite the HookOutputFunc to provide a custom writer. ```go type Configuration struct { ... // Called with container name and returns and expects writer that will receive the log output HookOutputFunc func(namespace, pod, container string) io.Writer } ``` ## Backwards compatibility The only backwards compatibility concern would be that scripts parsing `helm install` output would see some additional text in the case of logs being output. The fact that notes already make the output unstructured should mitigate any concern here. Since we already are trusting chart developers to provide output in the form of notes, this is a logical extension of that that allows the developer to provide more dynamic output. The logs would be written to `stderr`, further mitigating any breaking changes to scripts using `helm` CLI. ## Security implications Potentially the preflight checks could check for security misconfigurations that could enhance the security of the chart deployment. ## How to teach this In the first instance, documentation plus the help text for `helm install` would explain the feature. An example template could be provided in documentation showing how to use this feature with a generic command used in a hook. A more advanced example showing how to use the new feature with Troubleshoot.sh to provide preflight checks could be linked in the documentation, provided directly in the documentation, or provided on the Troubleshoot.sh documentation site independently. ## Reference implementation [Pull Request for Documentation ](https://github.com/helm/helm-www/pull/1242) [Pull Request for Helm](https://github.com/helm/helm/pull/10309) - most upvoted open PR ## Rejected ideas N/A ## Open issues N/A ## References [Troubleshoot.sh](https://troubleshoot.sh/) - the tool that is the motivation for this HIP. [safe-install plugin](https://github.com/z4ce/helm-safe-install) - Plugin that provides a similiar experience to what I hope this HIP will provide natively. ## Reference - Examples Usage ### Example using `false` Template: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}-false-job" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: "helm.sh/hook": pre-install, pre-upgrade "helm.sh/hook-output-log-policy": hook-failed, hook-suceeded "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded, hook-failed spec: backoffLimit: 0 template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.18" command: ["sh", "-c", "echo foo ; false"] ``` What it should loook when running: ```text $ helm install ./ my-release Logs for pod: my-release-false-job-bgbz6, container: pre-install-job foo Error: INSTALLATION FAILED: failed pre-install: job failed: BackoffLimitExceeded ``` ### Example using Troubleshoot Preflight Checks ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}-preflight-job" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: "helm.sh/hook": pre-install, pre-upgrade "helm.sh/hook-output-log-policy": hook-failed "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded, hook-failed spec: backoffLimit: 0 template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never volumes: - name: preflights configMap: name: "{{ .Release.Name }}-preflight-config" containers: - name: post-install-job image: "replicated/preflight:latest" command: ["preflight", "--interactive=false", "/preflights/preflights.yaml"] volumeMounts: - name: preflights mountPath: /preflights --- apiVersion: v1 kind: ConfigMap metadata: annotations: "helm.sh/hook": pre-install, pre-upgrade "helm.sh/hook-weight": "-6" "helm.sh/hook-delete-policy": hook-succeeded, hook-failed labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" name: "{{ .Release.Name }}-preflight-config" data: preflights.yaml: | apiVersion: troubleshoot.sh/v1beta2 kind: Preflight metadata: name: preflight-tutorial spec: collectors: {{ if eq .Values.mariadb.enabled false }} - mysql: collectorName: mysql uri: '{{ .Values.externalDatabase.user }}:{{ .Values.externalDatabase.password }}@tcp({{ .Values.externalDatabase.host }}:{{ .Values.externalDatabase.port }})/{{ .Values.externalDatabase.database }}?tls=false' {{ end }} analyzers: - clusterVersion: outcomes: - fail: when: "< 1.16.0" message: The application requires at least Kubernetes 1.16.0, and recommends 1.18.0. uri: https://kubernetes.io - warn: when: "< 1.18.0" message: Your cluster meets the minimum version of Kubernetes, but we recommend you update to 1.18.0 or later. uri: https://kubernetes.io - pass: message: Your cluster meets the recommended and required versions of Kubernetes. {{ if eq .Values.mariadb.enabled false }} - mysql: checkName: Must be MySQL 8.x or later collectorName: mysql outcomes: - fail: when: connected == false message: Cannot connect to MySQL server - fail: when: version < 8.x message: The MySQL server must be at least version 8 - pass: message: The MySQL server is ready {{ end }} ``` Which should yield the following output to stdout: ```text $ helm install ./ my-release Logs for pod: my-release-preflight-job-bgbz6, container: pre-install-job --- FAIL: Required Kubernetes Version --- The application requires at least Kubernetes 1.16.0, and recommends 1.18.0. --- FAIL: Must be MySQL 8.x or later --- Cannot connect to MySQL server --- FAIL preflight-tutorial FAILED name: cluster-resources status: completed completed: 1 total: 3 name: mysql/mysql status: running completed: 1 total: 3 name: mysql/mysql status: completed completed: 2 total: 3 name: cluster-info status: running completed: 2 total: 3 name: cluster-info status: completed completed: 3 total: 3 Error: INSTALLATION FAILED: failed pre-install: job failed: BackoffLimitExceeded ``` ================================================ FILE: community/hips/hip-0020.md ================================================ --- title: "H4HIP: Charts v3 Enablement" sidebar_label: "0020: H4HIP: Charts v3 Enablement" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0020 | H4HIP: Charts v3 Enablement | Matt Farina | 2025-01-09 | feature | accepted | ## Abstract This HIP proposes the creation of charts v3, updating Helm to handle charts v2 and v3, and a timeline for the general availability of charts v3 that can happen after the release of Helm v4.0.0. ## Motivation Many of the proposed changes for Helm v4 affect charts. Layering these onto existing charts will sometimes cause chart installation and upgrade to happen differently in Helm v3 and Helm v4, as both will need to live side by side for a time. It also means that testing of charts for v3 can produce a different result when installed with Helm v4. In addition to the affects of the changes, Helm v4 development has a fixed timeline and making changes to Helm in addition to reworking charts is not likely to fit within that fixed window. Enabling the development of charts v3 to happen as an experiment that becomes generally available after the release of Helm v4 provides more time to continue the work and get feedback. The goal is to provide adequate time to work on chart changes while doing it in a way that enables trust in existing charts to run as they were tested. ## Rationale Charts v2 were created for Helm v3 and introduced minor changes. The code that handles the chart versions is the same with some checking to handle the differences. This handling ended up having numerous bugs that had to be worked out in patch releases. The chart changes being proposed for Helm v4 are more significant. Mixing those in alongside the current chart version handling will have trouble limiting bugs will enabling the changes and keeping existing charts functioning properly. The design specified here is meant to enable the current charts to work as expected while providing space for more radical changes. ## Specification Helm has numerous packages that do various things, from working with charts to storing release information. These packages all expect there to be one version of a particular thing. To support multiple versions of charts, the `chart`, `chartutil`, `engine`, and `release` packages will be made multi-version. (e.g., engine will have a v1 and v2 versions). In addition to enabling a new version of charts, this will enable the gotpl engine to evolve as needed to support the new version of charts. The `chartutil` may be combined with the `chart` package and the `releaseutil` package may be combined with the `release` package for simplification of the package structure. The versioning of the packages will follow the same structure that Kubernetes does with its APIs. This means a thing will have a directory and within it will be sub-directories for the versions. The version specific implementation will be in the version specific sub-directory. For example, ``` chart ├── v2 └── v3 ``` The version will not use a separate Git repository or Go modules. The reason for this is the added complexity of managing the repositories and modules is added work to manage changes which will slow down velocity, will make releases more complex, and make the Helm SDK more complicated to work with. The existing versions of these packages will be externally facing while the new versions will be developed in `internal` as experiments until they are complete enough for release. When ready for release, these packages will be moved to the public locations. To illustrate this, while in development the `chart` package will have the following structure: ``` internal/chart └── v3 pkg/chart └── v2 ``` Once the new chart packages have (a) a stable API and (b) are feature complete the structure will be merged to look like: ``` pkg/chart ├── v2 └── v3 ``` While in development, as an experiment, the `pkg/gates` package will be used to create an opt-in environment variable to enable a new chart version. This is how the OCI experimental feature was handled. ## Backwards compatibility This development and process is designed with backwards compatibility in mind. The package locations will change, which is ok in a major version of Helm. The existing charts will be preserved so that their installation process continues to work as expected from Helm v3. New features and changes to charts can be added in without impacting existing charts. While the new chart version is being developed and is going through breaking changes, the chart will be an opt-in feature which will enable us to warn users about the state of it. ## Security implications N/A ## How to teach this There are a few ways to teach this: 1. **Documentation**: The chart documentation will be updated to teach both versions of charts. 2. **Helm Create**: Helm create will be updated to use the new chart version and provide an example. 3. **Blog and Webinars**: The marketing options open to Helm will be used to share details and teach about the new chart version. ## Reference implementation N/A ## Rejected ideas An option to detect the chart version within existing code was seen as an option. This is how charts `apiVersion` is handled for `v1` and `v2`. This is problematic as large changes in charts will be difficult to work on and test to ensure nothing breaks across version. ## Open issues N/A ## References N/A ================================================ FILE: community/hips/hip-0021.md ================================================ --- title: Enhanced logging library for Helm sidebar_label: "0021: Enhanced logging library for Helm" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 21 | Enhanced logging library for Helm | Evans Mungai | 2024-11-22 | feature | draft | ## Abstract This proposal introduces an improved logging library for Helm CLI and SDK to enhance logging capabilities for troubleshooting, development, and debugging. By using newer logging features such as log formatting and different log levels, developers and CLI users gain flexibility when deciding how much logging information they want to consume, and in what format. The HIP also introduces the ability for SDK users to use their own logging library with the SDK. Users will be able to provide a logger implementing `slog.Handler` interface, allowing them to consume instrumented logs in the SDK. ## Motivation The current logging mechanism in Helm CLI and SDK lacks granularity and structure. Users and developers face difficulties when: - Troubleshooting Helm CLI commands due to inability to increase the details that can get logged. More logs come in handy when submitting bug reports for example. - Instrumenting Helm code with clear and consistent logging conventions for contributors, as well as consumers of CLI and SDK logs. - Inflexibility using a different logging library to what the SDK uses. There is no way, in code, to have client loggers consume logs produced by the SDK The proposed solution addresses these gaps by integrating a logging library that supports log levels and structured output, as well as a widely supported logger implementation interface for SDK users to consume. ## Rationale The following libraries were evaluated: 1. **`slog`:** - Provides log levels (`info`, `debug`, `error`, `warning`). More levels can be added - Offers structured logging. - Lightweight and straightforward to integrate. - Is part of Go standard library - Has `slog.Handler` interface that other logger implementations can implement to be `slog` compatible While these libraries meet all the requirements we want, `slog` is the preferred choice here. It provides all functionality that the other choices have but stands out since it has a wider adoption given that its part of Go standard library. This will be benefitial to SDK users who have their existing logger implementations present. They would either implement `slog.Handler` interface or add a dependency of an existing adapter logger implementation. ## Specification - Helm will instrument `debug`, `info`, `warning` and `error` log levels. These log levels will enable filtering of logs. - Logs will be written to `stderr` by the Helm CLI client. `stdout` will be left for output from operations. SDK users would choose where to write logs to through configuring the logger they pass to the SDK. - Ability to allow users to configure log levels and formatting through CLI flags or environment variables. - Helm SDK should not be instrumented with error logs. Instead, errors ought to be returned. Any logging of such errors should be left to clients to choose whether to log or not. - When invoking plugins and post-renderers, `HELM_LOG_LEVEL` and `HELM_LOG_FORMAT` environment variables would be set, allowing them to output the appropriate amount of logs and format to stderr. - There will be structured logging with two options. Raw text for humans to view, and JSON formatting that machines can consume. - Ability for SDK users to override the default logger implementation. The SDK will expect at logger that implements `slog.Handler` interface. ### Example: For code where there is no context the implementation of `slog` will be static and we will directly call `slog`. For example: ``` go import ( "log/slog" ) func MyFunc() { ... slog.Debug("test debug", "test key", "test value") ... } ``` ## Backwards Compatibility The current logging system, Golang's `log` package will be replaced by `slog`. ## Security Implications TBD ## How to Teach This 1. **Documentation Updates:** - Provide examples of using the new logging features in the Helm documentation. - Include a section on how to configure log levels and formats. - Document conventions of how to instrument logs. Specifically, what information should be in what log level. Also document that the SDK does not log errors. - Example for SDK users of how to override the default logger with their own implementation. For loggers that do not implement `slog.Handler`, document an example of how this can be done. - Document how plugins and post-renderers can inherit log levels and formatting from helm CLI client. 2. **CLI help text:** - Use Helm CLI help messages (`helm --help`) to inform users about the new logging options. ## Reference Implementation ## Rejected Ideas 1. **Sticking with the current logging system:** - Rejected due to lack of flexibility and limited usefulness for debugging. 2. klog and logr libraries were considered. They provide log levels and verbosity levels. They are used in kubernertes ecosystem. logr offers `logr.Handler` interface which logging libraries can implement. They however both fell short because they are external dependencies whilst slog is part of the standard library. ## Open Issues ## References - [Go’s slog Documentation](https://pkg.go.dev/log/slog) ================================================ FILE: community/hips/hip-0022.md ================================================ --- title: Wait With kstatus sidebar_label: "0022: Wait With kstatus" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** | |---|---|---|---|---|---|---| | 22 | Wait With kstatus | @austinabro321 | 2024-12-06 | feature | accepted | 4 | ## Abstract Currently the `--wait` flag on `helm install` and `helm upgrade` does not wait for all resources to be fully reconciled, and does not wait for custom resources (CRs) at all. By replacing the wait logic with [kstatus](https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md), Helm will achieve more intuitive waits, while simplifying its code and documentation. ## Motivation By introducing kstatus we will lower user friction with the `--wait` flag. Certain workflows require custom resources to be ready. There is no way to tell Helm to wait for custom resources to be ready, so anyone with this requirement must write their own logic to wait for their custom resources. Kstatus solves this by waiting for custom resources to have [the ready condition](https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md#the-ready-condition) set to true. Certain workflows requires resources to be fully reconciled, which does happen in the current `--wait` logic. For example, Helm waits for all new pods in an upgraded deployment to be ready. However, Helm does not wait for the previous pods in that deployment to be removed. Therefore, Helm will finish waiting even while old pods are still active. Since kstatus instead waits for all resources to be reconciled, the wait will not finish for a deployment until all of its new pods are ready and all of its old pods have been deleted. ## Rationale Leveraging a existing status management library maintained by the Kubernetes team will simplify the code and documentation that Helm needs to maintain and improve the functionality of `--wait`. ## Specification The Helm CLI will continue to use the existing `--wait` flag. The wait flag will be extended to accept `true|false|none|watcher|legacy`. When using `--wait` as flag with no argument, `--wait=true`, or `--wait=watcher` Helm will use the kstatus watcher described in this document. When using `--wait=legacy` Helm will use the current Helm 3 waiter. When using `--wait=false` or not using the `--wait` flag Helm not wait after deployments. Kstatus can be used with either a poller or a watcher. The poller runs on a specified interval and only requires "list" RBAC permissions for polled resources. The watcher reacts to [watch events](https://github.com/kubernetes/kubernetes/blob/90a45563ae1bab5868ee888432fec9aac2f7f8b1/staging/src/k8s.io/apimachinery/pkg/watch/watch.go#L55-L61) and requires "list" and "watch" RBAC permissions. This proposal uses the watcher as it responds slightly faster when all resources are ready, and it is very likely that users applying or deleting resources will have "watch" permissions on their resources. Any functions involving waits will be separated from the `kube.Interface` interface into the `kube.Waiter` interface. `kube.Waiter` will be embedded into `kube.Interface`. The client struct will embed the `Waiter` interface to allow calls to look like `client.Wait()` instead of `client.Waiter.Wait()`. `kube.New()` will accept a wait strategy to decide the wait implementation. There will be two implementation in the repo, `HelmWaiter` and `statusWaiter`. `HelmWaiter` is the legacy implementation. The `statusWaiter` will not be public so that if kstatus is ever deprecated or replaced a new implementation can be used without changing the public SDK. The new client will look like: ```go type Client struct { Factory Factory Log func(string, ...interface{}) Namespace string kubeClient *kubernetes.Clientset Waiter } type WaitStrategy int const ( StatusWaiter WaitStrategy = iota LegacyWaiter ) func New(getter genericclioptions.RESTClientGetter, ws WaitStrategy) (*Client, error) ``` The waiter interface will look like: ```go type Waiter interface { Wait(resources ResourceList, timeout time.Duration) error WaitWithJobs(resources ResourceList, timeout time.Duration) error WaitForDelete(resources ResourceList, timeout time.Duration) error WatchUntilReady(resources ResourceList, timeout time.Duration) error } ``` `Wait` will wait for all resources to be ready. This will include jobs, but this function not wait for jobs to be complete. `WaitWithJobs` will wait for all resources to be ready and all jobs to be complete. `WatchUntilReady` only waits for Pods and Jobs to complete. It is used for Helm hooks. This logic will stay the same. Calls to `Wait` and `WaitWithJobs` will not wait for paused deployments. This is consistent with the current logic. This is done because otherwise `helm upgrade --wait` on a paused deployment will never be ready, see [#5789](https://github.com/helm/helm/pull/5789). Kstatus does not natively output any logs. After each event, Helm will output a log message of one resources that's not ready. Only one resource is logged at a time so Helm doesn't overwhelm users with output. Note that the logs are only sent when called as a library, the CLI uses a noop logger for Kube operations. ## Backwards compatibility Waiting for custom resources and other previously not waited for resources could lead to charts timing out when using the new logic. The kstatus status watcher requires the "list" and "watch" RBAC permissions to watch a resource. The current Helm implementation only require "list" permissions for the resources they're watching. Kstatus and Helm require "list" permissions for some child resources. For instance, checking if a deployment is ready requires "list" permissions for the replicaset. There may be cases where the RBAC requirements for child resources differ between Kstatus and Helm, as an evaluation has not been conducted. Kstatus also watches more resources than Helm does. A user will need "list" and "watch" permissions to every resource that they are deploying. Currently, Helm only checks readiness of certain resources. See the [IsReady function](https://github.com/helm/helm/blob/0d66425d9a745d8a289b1a5ebb6ccc744436da95/pkg/kube/ready.go#L92) for details Below is the minimal set needed to watch a deployment with the status watcher. This can be verified by following instructions in this repo: https://github.com/AustinAbro321/kstatus-rbac-test. ```yaml rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["list", "watch"] - apiGroups: ["apps"] resources: ["replicasets"] verbs: ["list"] ``` ## Security implications Users will now need "watch" permissions on resources in their chart if the `--wait` flag is used. They will also need "list" and "watch" permissions for all resources they are deploying rather than just the resources that Helm currently waits for. ## How to teach this Replace the [existing wait documentation](https://helm.sh/docs/intro/using_helm/) by explaining that we use kstatus and pointing to the [kstatus documentation](https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md). This comes with the added benefit of not needing to maintain Helm specific wait documentation. ## Reference implementation seen here - https://github.com/helm/helm/pull/13604 ## Rejected ideas ## Open issues [8661](https://github.com/helm/helm/issues/8661) ## References existing wait documentation - https://helm.sh/docs/intro/using_helm/ kstatus documentation - https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md Zarf kstatus implementation - https://github.com/zarf-dev/zarf/blob/main/src/internal/healthchecks/healthchecks.go ================================================ FILE: community/hips/hip-0023.md ================================================ --- title: Utilize Server Side Apply for installs/upgrades sidebar_label: "0023: Utilize Server Side Apply for installs/upgrades" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** | |---|---|---|---|---|---|---| | 23 | Utilize Server Side Apply for installs/upgrades | George Jenkins | 2023-07-07 | feature | accepted | 4 | ## Abstract This HIP proposes Helm support Kubernetes' [Server-Side Apply][server-side-apply] (SSA) for [object](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-object) updates/management. ## Motivation Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches) process, enabling Helm to update objects which have been modified by other processes. Kubernetes now offers a similar server-side merge process, that yields several advantages over the client-side apply (CSA) methods that Helm and `kubectl` (for example) have traditionally utilized. Kubernetes has evolved this client-side merge process to be managed server-side, yielding several advantages over the client-side apply (CSA) methods that Helm and `kubectl` (for example) have traditionally utilized. The following describes the advantages of SSA from Kubernetes perspective, where SSA generally is considered to be superior: (See [KEP 555][kep555] and the Kubernetes [documentation][server-side-apply] for server-side apply's full motivation and detailed description) Helm supporting to SSA allows Helm users (chart operators) to realize the benefits of Kubernetes server-side field management for object updates. And enabling SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default)) will avoid users having to specifically enable SSA to realize its benefits. Finally, from a code maintenance benefit, SSA support may eventually allow Helm to eventually drop support for the strategic-merge patch CSA implementation/code. ## Rationale Kubernetes' has sigificant movement towards SSA as preferred method for object updates/management. Helm should adopt SSA in continuance with this trend, as it is unlikely client-side methods will continue to be improved upon. Nor will client side methods likely ever be able to provide the functional benefits of SSA. With Helm 4, it was decided to opt into utilizing SSA by default. Allowing chart operators to gain the benefit of SSA without needing to know about the server-side vs. client-side mechanisms. If during Helm 4 release candidate field usage, SSA as default is deemed to be unresolvably problematic, Helm 4 will revert to utilizing CSA by default. A CLI flag will allow users to override SSA opt-in and revert to utilizing CSA. Should a chart operator need for a particular circumstance. A chart release mechanism will allow Helm to track and follow SSA enablement for a given release. Tracking SSA enablement will allow Helm to automatically follow SSA enablement for a given release, and in particular revert to CSA (or SSA) during rollbacks if that prior release utilized CSA (or SSA). Additionally it was desirable to mimic `kubectl`'s CLI interface/flags. As a way for Helm to be consistent with an existing `kubectl` functionality that Kubernetes users may be familar with. ## Specification ### General Helm will add a new flag `--server-side=false|true|auto` to the install, upgrade and rollback commands (modeled after the like `kubectl apply` flag). And add a corresponding field to the respective install/upgrade/rollback SDK API objects. Helm will default to `true` for installs, enabling SSA. And `auto` for upgrade and rollbacks, where Helm will enable SSA based on the whether SSA was utilized for the prior release (see below). When enabled, Helm will submit object to the Kubernetes API server via SSA patches. If SSA or CSA is utilized for a release, this will be stored as a field in the release's metadata. If the field is unset when reading a prior release, this implies that the release was created with an old version of Helm utilizing CSA. ``` type Release struct { ApplyMethod *string `json:"apply_method,omitempty"` // "ssa" | "csa" } ``` If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new release's metadata will omit the indication of SSA usage (and so further upgrades/rollbacks will continue to use CSA by default). In a future version of Helm 4 CLI, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA for further releases). #### Custom resource objects Helm will utilize SSA for custom resource objects, which it previously [didn't merge](https://github.com/helm/helm/blob/1b260d0a796882a1e90f0fa3c832659dbe2e675c/pkg/kube/converter.go#L54-L69). The API server will [merge custom resources][ssa-crds based on CRD metadata. #### Conflicts and forcing It is possible that when Helm upgrades (or rollbacks) a chart, there will be a field conflict with another field manager. In this case, Helm will report the error for the conflict field(s) to the user. Helm will also add a new flag `--force-conflicts=false|true` (default `false`) to the install, upgrade and rollback commands (modeled after the life `kubectl apply` flag) And corresponding API objects field. When `true`, Helm will enabling overriding the field conflicts, setting field(s) to the charts values. And also make Helm the field manager for the conflicting field(s). The `--force-conflicts` flag documentation should explicity mention the downsides of conflict forcing ie. the chart update is overriding object values that another process is expecting to own/manage. For more details, see SSA documentation [Overwrite value, become sole manager][ssa-conflicts] (To note, `helm upgrade|rollback` commands already includes a `--force` flag, which tells Helm to replace objects during upgrade. However, given this different semantics of `--force`, a new flag is required) An additional special case includes rollbacks on failed upgrade (the `--atomic` flag). It is possible for Helm to attempt to rollback to a version which now has a conflict. For which the rollback will fail. Since rollbacks are "best effort" and can fail for other reasons as well, it seems best to treat this new rollback failure-case similarly (report to the user via logging and error). If the user specified `--force-conflicts` to the upgrade, the corresponding rollback should similarly force conflicts (this is the behavior of `--force`). If the rollback is to a release version which previously didn't have SSA enabled, the rollback install should also disable SSA. #### Special - `--dry-run=client` won't accurately simulate an install with SSA enabled. This is already often true even with the current merge strategy, but especially true of Server Side Apply. To accurately simulate an install with SSA enabled, instead use `--dry-run=server`. - If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error - Client-side API object validation isn't applicable when SSA is enabled (`helm install|upgrade --disable-openapi-validation`) - Hooks could be deployed with SSA. But as hook objects are not updated (create/delete only), they are not really affected - Stored release manifests should not change (they store the object as Helm intends) ### Implementation Helm will send object's manifests to the Kubernetes API server via SSA patches. Similar to `kubectl apply`. Utilizing the field manager name `"helm"`: https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L248 https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2f35/pkg/cmd/apply/apply.go#L564-L602 ## Backwards compatibility SSA should be generally compatible functionality-wise with CSA. The expectation is that SSA should generally produce equivalent Kubernetes objects as CSA. There four main behavioural differences for Helm switching to SSA: 1. The differences between object's manifests managed with SSA vs the existing three-way strategic merge process. SSA will enable: - Arrays will be merged - Removal of unset fields - Default values 2. Issues with a user enabling/disabling SSA over the lifetime of a release e.g. environment differences or older Helm clients which don't understand SSA 3. SSA will apply to custom resources 4. Field management ownership conflicts For 1., chart-operators may opt-out out of SSA. For 2., the user can control by ensuring SSA is consistently used within their environment. For 3., it is generally considered a limitation of Helm not updating custom resource objects, for which SSA is expected to be an improvement. For 4., the `--force-conflicts` flag exists. Additionally as noted, SSA isn't compatible with very old Kubernetes versions (1.22 GA / 1.17 Beta) ## Security implications There should not be any additional security concerns. Server-side apply and client-side apply should be equivalent security-wise. ## How to teach this Documentation for how Helm does object upgrades, and the advantages of SSA. Also documentation for the `--server-side=false|true|auto` and `--force-conflicts=false|true` flags, and the defaults for install/upgrades/rollbacks. And the corresponding documentation for the field(s) SDK API objects. ## Reference implementation Kubectl: - - Prototype (hack) for Helm: - ## Rejected ideas ### Chart field manager support This HIP defers including field manager support in charts. ie. Helm could enable applying multiple manifests for the same object with distinct field manager names. Either from the same chart, or different charts/releases. It is unclear how Helm users would interact with such a feature e.g. the chart developer might want/need to specify field manager names per output manifests in a chart. And `helm template` might somehow need to allow describing the object's field manager name in its output. And whether it would be needed to control per-manifest conflict forcing. Once more information is gathered on how chart developers might utilze explicit field manager support, a proposal introducing field manage support for charts could be written. ### Field ownership transfer Helm won't support ownership transfer of fields. Similar to the `kubectl` example: . Dissimilar to `kubectl`, Helm distinguishes between chart developers and chart operators. Chart developers may not consider, or may not even know, which fields may be overwritten (managed by) by another process in a user's Kubernetes cluster. Ownership transfer would likley first require charts have field manager support. As well as additional support for per-object conflicts resolution. ## Open issues ## References - Kubernetes SSA documentation: [https://kubernetes.io/docs/reference/using-api/server-side-apply/][server-side-apply] - KEP-555: Server-side apply: [https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/555-server-side-apply/README.md][kep555] - Strategic Merge Patch: [https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md][strategic-merge-patch] - Kubectl SSA default: - Structured Merge and Diff (`kubectl` client-side apply): - [server-side-apply]: https://kubernetes.io/docs/reference/using-api/server-side-apply/ [strategic-merge-patch]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md [kep555]: [ssa-conflicts]: [ssa-crds]: ================================================ FILE: community/hips/hip-0024.md ================================================ --- title: Improve the Helm Documentation sidebar_label: "0024: Improve the Helm Documentation" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0024 | Improve the Helm Documentation | Paige Calvert | 2025-05-07 | feature | draft | ## Abstract This HIP proposes making a set of improvements to the Helm documentation site (https://helm.sh/docs). The goal of these improvements is to make it easier to use and contribute to the Helm docs, which would ultimately make it easier for users to learn about, use, and contribute to Helm. This proposal focuses on improvements that can be made to the static site generator, the site's information architecture, and the Helm overview content available in the site. ## Motivation This proposal identifies the following key areas for improvement in the Helm documentation: - The functionality of the site is limited and in some cases is broken. For example, top-level pages like https://helm.sh/docs/howto/ are not accessible by clicking on the given heading in the sidebar. As another example, it is difficult for contributors to reorder sidebar content due to the use of weighted page ordering, rather than having a sidebar file where pages can be more easily reordered. - There is no comprehensive introductory page explaining Helm’s purpose, personas, common use cases, and so on. - The Helm docs are currently organized around top-level categories like Introduction, How-To, Topics, Best Practices, and so on. These categories do not reflect the ways that different user personas use Helm (like releasing with Helm, packaging an application with Helm, or installing with Helm). Content also appears to be inconsistently organized under each category. For example, there are only three pages under the How-To section. And, [Chart Development Tips and Tricks](https://helm.sh/docs/howto/charts_tips_and_tricks/) is under How-To, rather than under Best Practices. There are also discrepancies in the description of [How the documentation is organized](https://helm.sh/docs/#how-the-documentation-is-organized) and the top-level categories that actually appear in the live docs site. ## Rationale The following describes the rationale behind improving each of the key areas listed under Motivation above: - Modern open-source static site generators (like [Docusaurus](https://docusaurus.io/) or [MkDocs](https://www.mkdocs.org/)) offer easier maintenance, clearer sidebar management, and better support for documentation contributors. - A lack of clear, complete, and up-to-date Helm overview content leads to confusion for first-time users that want to understand Helm’s goals, features, and common use cases. - The current information architecture makes it more difficult for users to find the information they are looking for. It also makes it more difficult for contributors to understand how to organize new topics in the sidebar. Redesigning the information architecture would improve discoverability and usability, helping users find relevant content faster. ## Specification This HIP proposes the following: 1. **Evaluate static site generators and migrate the docs**: Evaluate, select, and migrate the Helm docs to a modern, open-source static site generator (like [Docusaurus](https://docusaurus.io/) or [MkDocs](https://www.mkdocs.org/)) that would improve ease-of-contribution and site functionality. 1. **Create a Helm overview page**: Add a new page to the introductory section of the docs that describes the Helm project, its goals, core concepts, user personas, and key use cases, clearly addressing the who/what/when/why for Helm. 1. **Redesign the docs information architecture**: Perform a content audit and design a new information architecture that is more intuitive, reflects common workflows for the different Helm user personas, improves content find-ability, and aligns with tech comm standards. Each of these items would be presented for review by the Helm community. These docs improvements could be published alongside the release of Helm 4. Implementations would include: - Migrate all the existing docs to the new site. - Create the new sidebar to reorganize the docs. - Write the updated Helm overview content. - Docs for Helm 4: 1. Drafted in a branch initially 2. Helm 4 released, merge the Helm 4 docs, and publish the new docs site. ## Backwards compatibility This change affects only the documentation site and does not impact the Helm CLI, Helm libraries, or chart formats. Legacy URLs will be redirected where necessary to preserve external links and bookmarks. ## Security implications There are no known security implications from this change, as it would affect only the public documentation and the docs toolchain. ## How to teach this - Add clear contribution guides and README instructions in the docs repo, including templates and guidelines for docs contributors - Promote the new docs structure and toolchain through Helm community channels and other documentation update announcements. ## Reference implementation No implementation has been made. This proposal recommends evaluating and choosing a new static site generator as part of the implementation process. Additionally, the specific information architecture and overview content improvements will be determined through a content audit and refined with Helm community feedback. ## Rejected ideas To limit scope, this proposal does not include making any significant changes to the docs content itself (including adding/removing content or making substantial content style improvements). The only exception is adding more complete overview content. ## Open issues The open issues for this HIP include the specific implementation strategy and timeline for each area for improvement, such as: - Creation of a roadmap/project plan to track progress - Selection of the static site generator - Static site generator migration strategy and timeline - The specific information and/or visuals to add to a new overview page - Completion of content audit - The specific information architecture improvements that should be made, such as the different categories where content should be grouped - The strategy and timeline for making information architecture improvements ## References - [Helm Documentation](https://helm.sh/docs) - [Docusaurus](https://docusaurus.io/) - [MkDocs](https://www.mkdocs.org/) ================================================ FILE: community/hips/hip-0025.md ================================================ --- title: Better Support for Resource Creation Sequencing sidebar_label: "0025: Better Support for Resource Creation Sequencing" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | |---|---|---|---|---|---| | 0025 | Better Support for Resource Creation Sequencing | Joe Beck , Evans Mungai | 2025-05-21 | feature | draft | ## Abstract This HIP proposes a new feature set in Chart v3 to provide [Application Distributors](/community/user-profiles#2-application-distributor)—a key Helm user profile—with a first-class mechanism for defining the deployment order of chart resources and subcharts. By default, Helm applies all rendered manifests simultaneously. This HIP introduces the ability for Helm to deploy resources in ordered batches and evaluate their readiness before proceeding. At a high level, this HIP proposes the following - Ability for chart authors to specify how to sequence deployment of **resources within a single chart** - Ability for chart authors to specify how to sequence **subcharts within a parent chart** - Ability for Helm operators and tool developers to enable sequencing behaviour using `--wait=ordered` CLI flag and `WaitStrategy=ordered` SDK parameter respectively The HIP only targets resources deployed in the Helm install phase. Resources deployed as hooks are not sequenced using changes proposed here. Any sequencing of hooks will still rely on using `"helm.sh/hook-weight"` annotations. Annotations added to resources in hooks will be ignored. ## Motivation The driving motivator here is to allow application distributors to control what order resources are bundled and sent to the K8s API server, referred to as resource sequencing for the rest of this HIP. Today, to accomplish resource sequencing, there are currently two main options: using Helm hooks, or building the sequencing logic into the application itself (e.g., using startup code or init containers). The existing hooks and weights can be tedious to build and maintain for application distributors, and built-in app sequencing can unnecessarily increase complexity of a Helm application that needs to be maintained by application distributors. Helm, as a package manager, should provide built-in mechanisms for sequencing resource deployment, reducing reliance on complex hooks or in-application logic. This will significantly improve the application distributor's experience. Additionally, Helm currently doesn't provide a way to sequence when chart dependencies are deployed and this featureset would ideally address this. ## Rationale The proposed design prioritizes simplicity and ease of use for both Helm developers and chart authors. It leverages familiar YAML patterns and Helm conventions, avoiding heavyweight solutions while offering powerful orchestration capabilities. ## Specification At a high level, allow Chart Developers to assign named dependencies to both their Helm templated resources and Helm chart dependencies that Helm then uses to generate a deployment sequence at installation time. For Helm CLI, the `--wait=ordered` flag will enable sequencing where resources are applied in groups. SDK users will also be able to enable sequencing by setting a `WaitStrategy` field. By default, resources are all applied at once which is the same behaviour in Chart v2. Each release will store information of whether sequencing was used or not. This information is used when performing uninstalls and rollbacks. ### Sequencing Execution Flow When sequencing is enabled, Helm installs resources in a structured order across both subcharts and resource-groups: **1. Subchart Ordering** Helm builds a dependency graph from definitions in `Chart.yaml`: * `helm.sh/depends-on/subcharts` key in `annotations` field * `depends-on` key on `dependencies` list entries Subcharts are installed in dependency order. Each subchart must be fully deployed and ready before its dependents begin. **2. Resource-Group Sequencing (Per Chart)** Within each chart (parent and subcharts), Helm builds a resource-group graph using: * `helm.sh/resource-group` * `helm.sh/depends-on/resource-groups` Resources in each group are deployed together, and Helm waits for all to be ready before continuing to the next group. **3. Unsequenced Resources** Resources that: * lack annotations, * depend on non-existent groups, or * belong to isolated groups will be deployed after all properly sequenced groups have been processed. If a resource includes sequencing annotations but falls into this unsequenced category due to misconfiguration (e.g., referencing missing groups), Helm will emit a warning to alert the user of the potential issue. *Additions to templates* The following annotations would be added to enable this. - `helm.sh/resource-group`: Annotation to declare a resource-group that a given resource belongs to. Any number of resources can belong to a group. A resource can only belong to one group. - `helm.sh/depends-on/resource-groups`: Annotation to declare resource-groups that must exist and in a ready state before this resource can be deployed. The order in which they are listed does not affect deployment sequencing. These annotations are only used for sequencing resources within the same chart. They do not influence or interact with resources across charts or subcharts. *Additions to Chart.yaml* * `helm.sh/depends-on/subcharts`: An annotation added to `Chart.yaml` to specify chart dependencies—identified by their `name` or `alias`—that must be fully deployed and in a ready state before the current chart resources can be installed. A dependent chart is considered ready only when all of its resources, including any defined sequencing, have been successfully deployed and marked ready. The order in which dependencies are listed has no effect on execution. - `depends-on`: A new field added to `Chart.yaml` `dependencies` fields that is meant to declare a list of subcharts, by `name` or `alias`, that need to be ready before the subchart in question get installed. This will be used to create a dependency graph for subcharts. The installation process would group resources in the same group and send them to the K8s API Server in one bundle, and once all resources are "ready", the next group would be installed. A resource-group would not be considered "ready" and the next group installed until all resources in that group are considered "ready". Readiness is described in a later section. A similar process would apply for upgrades. Uninstalls would function on the same resource-group order, but in reverse, where a resource-group is not uninstalled until all resource-groups that depend on it are first uninstalled. Upgrades would follow the same order as installation. #### Template examples: ```yaml # resource 1 metadata: name: db-service annotations: helm.sh/resource-group: database --- # resource 2 metadata: name: my-app annotations: helm.sh/resource-group: app helm.sh/depends-on/resource-groups: ["database", "queue"] --- # resource 3 metadata: name: queue-processor annotations: helm.sh/resource-group: queue helm.sh/depends-on/resource-groups: ["another-group"] ``` In this example, Helm would be responsible for resolving the annotations on these three resources and deploy all resources in the following order. Resources in `database` and `queue` resource-groups would be deployed at the same time. They would need to be ready before attempting to deploy `app` resource-group: ``` "database" group: [db-service] || "queue" group: || [queue-processor] || || || || \/ \/ \\ // \\ // \/ \/ "app" group: [my-app] ``` #### Chart dependencies example To control the order in which subcharts are installed, upgraded, or uninstalled, chart authors must use the `helm.sh/depends-on/subcharts` annotation or the `depends-on` field in the `Chart.yaml`. These declarations enable Helm to determine the correct sequencing of subchart operations, as illustrated below. ```yaml name: foo annotations: helm.sh/depends-on/subcharts: ["bar", "rabbitmq"] dependencies: - name: nginx version: "18.3.1" repository: "oci://registry-1.docker.io/bitnamicharts" - name: rabbitmq version: "9.3.1" repository: "oci://registry-1.docker.io/bitnamicharts" - name: bar # This is a subchart packaged with "foo" in charts dir. It's not pulled from a remote location version: "0.1.0" depends-on: ["nginx", "rabbitmq"] condition: bar.enabled ``` ``` [nginx] [rabbitmq] || || || || \/ \/ \\ // \/ \/ [bar] || || \/ [foo] ``` In this example, Helm will first install and wait for all resources of `nginx` and `rabbitmq` dependencies to be "ready" before attempting to install `bar` resources. Once all resources of `bar` are "ready" then and only then will `foo` chart resources be installed. `foo` would require `rabbitmq` to be ready but since the subchart resources would have been installed before `bar`, this requirement would have been fulfilled. This approach of building a directed acyclic graph (DAG) is prone to circular dependencies. During the templating phase, Helm will have logic to detect, and report any circular dependencies found in the chart templates. Helm will also provide a command to print the DAG for development and troubleshooting purposes. ### Readiness To enforce sequencing, Helm determines whether resources are “ready” before deploying dependent resources. By default, Helm uses [`kstatus`](https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md#the-ready-condition) library to assess readiness based on the resource’s type and `.status` field. Chart authors can optionally override this behavior using the following annotations: * `helm.sh/readiness-success`: A list of custom success conditions. If any are true, the resource is marked **ready**. * `helm.sh/readiness-failure`: A list of custom failure conditions. If any are true, the resource is marked **failed**, which takes precedence over any success check. Both `helm.sh/readiness-success` and `helm.sh/readiness-failure` must both be provided to override the default readiness logic. If only one is present, Helm will fall back to `kstatus` and emit a warning. Helm will also fail linting when only one of the two is defined, to prevent ambiguous readiness evaluation. #### JsonPath syntax The `readiness-success` and `readiness-failure` annotations accept lists of expressions with the format: ``` {} ``` Where: * `` is a [Kubernetes JSONPath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) query scoped to `.status`. * `` supports: `==`, `!=`, `<`, `<=`, `>`, `>=`. * `` is the expected literal for comparison. The value should be a scalor (string, number, boolean). Object comparisons will not be supported. ##### Example ```yaml kind: Job metadata: name: db-init annotations: helm.sh/readiness-success: ["{.succeeded} == 1", "{.succeeded} == 2"] helm.sh/readiness-failure: ["{.failed} >= 1"] status: succeeded: 1 ``` In this case, Helm will consider the resource ready because `.status.succeeded == 1`. If `.status.failed >= 1` had been true, the Job would instead be marked as failed. A resources readiness is checked if there is a resource that depends on it as per the sequencing DAG, otherwise the checks are ignored. Helm will wait up to a default of **1 minute** for a resource to either succeed or fail. If the resource does not reach a success or failure state within this period, the operation will time out, causing the chart install or upgrade to fail. This timeout can be customized using the `--readiness-timeout` CLI flag or the `ReadinessTimeout` field in the SDK. However, the specified readiness timeout must not exceed the overall `--timeout` value, which defines the maximum duration allowed for the entire chart installation or upgrade process. ### Sequencing order Resources with sequencing annotations in a chart would be deployed first followed by resources without. If the chart has a `helm.sh/depends-on/subcharts` annotation in the `Chart.yaml`, all resources of the defined subcharts would be deployed before deploying the main chart. If any sequencing annotations are defined in the subchart resources, Helm will enforce ordering of resources within. Sequencing of resources in a chart are sandboxed within the chart. Sequencing annotations will not affect resources in other charts. - Installs: Helm will install resources in the order defined by the DAG. If any of the readiness checks fail or timeout, the entire install would fail and the release marked as failed. If `--atomic`, or its SDK equivalent is used, a rollback to the last successful install would take place. - Uninstalls: Helm would uninstall resources in the reverse order they were installed, as per the sequencing order. The logic to delete each resource will not change. - Rollbacks: Helm will check from the release object whether the revision being rolled back to, was installed in a sequenced manner. If it was, Helm will respect and enforce this order when installing resources from that revision. When deleting unneeded resources of the revision being rolled back from, the reverse order is followed just like uninstalls. - `helm template` would print all resources in the order they would be deployed. Groups of resources in a resource-group would be delimited using a `## START resource-group: / ` comment indicating the beginning of each resource-group and `END resource-group: / `. ```yaml ## START resource-group: foo group1 # resource 1 metadata: name: foo annotations: helm.sh/resource-group: group1 --- # resource 2 metadata: name: bar annotations: helm.sh/resource-group: group1 ## END resource-group: foo group1 --- ## START resource-group: foo/bar group2 # resource 3 metadata: name: fizz annotations: helm.sh/resource-group: group2 helm.sh/depends-on/resource-groups: ["group1"] ## END resource-group: foo/bar group2 ``` ## Backwards compatibility Helm will continue to install/upgrade/uninstall/rollback all resources and dependencies at one go for all charts using `Charts v2` and below. ## Security implications None. ## How to teach this - Document how sequencing works in the official helm documentation website. Include ordering of Kubernetes resources that Helm enforces when applying resources to the cluster. Examples will be added to best demonstrate how this feature works. - Document how this feature works for SDK users. ## Reference implementation N/A ## Rejected ideas 1. A weight based system, similar to Helm hooks - Static numbering of the order is more challenging to develop and maintain - Modifying the order can lead to cascading changes. - Dynamically named system solves these problems for the application distributors. ## Open issues ## Prior raised issues - https://github.com/helm/helm/pull/12541 - https://github.com/helm/helm/pull/9534 - https://github.com/helm/helm/issues/8439 - https://github.com/helm/community/pull/230 ================================================ FILE: community/hips/hip-0026.md ================================================ --- title: "H4HIP: Wasm plugin system" sidebar_label: "0026: H4HIP: Wasm plugin system" --- | **HIP** | **Title** | **Author(s)** | **Created** | **Type** | **Status** | **Helm Version** | |---|---|---|---|---|---|---| | 0026 | H4HIP: Wasm plugin system | Scott Rigby , George Jenkins | 2025-02-17 | feature | draft | 4 | ## Abstract Helm is currently a monolithic application that is difficult to customize without changing the core codebase. This requires maintainers to review and accept every contribution, which is time-consuming and not scalable. This architectural proposal outlines a concrete plan to define a wider range of plugin types in Helm 4, so that users will be able to customize more default functionality in their own environment through alternative plugins. This will be accomplished through a new Wasm based plugin system. This will result in making Helm not only more extensible, but also more maintainable, allowing contributors to extend more of Helm's functionality via plugins rather than core changes to meet their needs more quickly. ## Scope This HIP will cover the overall vision for the new plugin system, and an [implementation plan](#implementation-plan) for initial plugin types introduced into this system. This will will allow more categories of Helm functionality to become extended through additional plugin types in the future. This HIP focuses primarily on CLI users. SDK users will not be required to use Wasm plugin functionality—it is expected that they may instead prefer to directly include Go libraries exposed by authors of those plugins. Additionally, this HIP does not address an idea raised to allow chart authors to define required plugins for a chart—that will be proposed in a follow-up HIP. ## Motivation Helm CLI users want to extend and modify Helm's default behaviors. This is evidenced by the [massive number of new feature pull requests](https://github.com/helm/helm/pulls) to Helm core. Helm 3 made some distance in addressing this issue through basic CLI plugins and other extensibility mechanisms, but these did not adequately address the end user need for customizing Helm's default behavior. ### Helm 3 plugins did not adequately address the problem this HIP solves Helm 3 plugins were limited to primarily CLI subcommand plugins, and apart from downloader plugins, the plugin system was not designed to extend other categories of Helm functionality. The [high-level goal](https://helm.sh/docs/topics/plugins/#an-overview) of the Helm 3 plugin system shows that plugins were intended to solve this problem: > Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool (and maintained by core Helm maintainers) However, Helm 3 plugins had the following limitations: - Because plugins are primarily intended to add new Helm CLI subcommands, the Helm 3 plugin architecure is not helpful for SDK users, nor Chart Authors, or for customizing the existing Helm core functionality. - Helm 3 plugins call a user-specified arbitrary binary through a subprocess, which does not allow Helm to limit the scope of these commands (see Wasm sandboxing under [Security implications](#security-implications) for how this will be resolved). Plugin maintainers must also be concerned about OS and architecture compatbility of pre-built binaries and scripts. - There is only one specialized type of Helm 3 plugin—**downloader plugins**—which comes closest to what Helm 4 is modeling its new plugin types after. Downloader plugins are called by Helm for a specific purpose and have a well-defined scope. The main limitation here is that it does not allow users to modify other default behaviors of Helm. ### Other Helm 3 customization options did not adequately address the problem this HIP solves either Apart from plugins, Helm 3 attempts to allow user customization globally and per command: - Globally: By overriding Helm environment variables that allow certain configurations, such as setting the backend storage driver (`HELM_DRIVER`) or the Bearer KubeToken used for authentication (`HELM_KUBETOKEN`). These can be found by running `helm --help` or in the [`helm` command documentation](https://helm.sh/docs/helm/helm/#synopsis). - Per command: By setting CLI flags and the equivalent SDK function options. This is the primary way Helm 3 allows user-defined configuration. It's important to note that command flags have proliferated over time in order to support backwards-compatibility within each previous MAJOR version of Helm. In addition to the high volume of open issues and PRs, these flags are clear evidence of the massive need for user-defined customization of Helm. While useful, all of these configuration approaches are limited and do not provide the level of extensibility users have requested without requiring their use cases to be built into Helm core. ## Specification This section outlines the Wasm based plugin system, and the plan to define a wider range of plugin types. ### Terminology - #### Plugin System The *entire* Helm 4 plugin architecture. - #### ApiVersion The version of the Plugin System. `legacy` is the Helm 3 legacy system.`v1` is the new Wasm Plugin System. This lets us make large updates within the same MAJOR version of Helm. - #### Plugin Type Which Helm functionality the plugin can extend. Examples: `subcommand`, `downloader`, `postrender` - #### Plugins The individual, optionally intallable, plugins themselves ### Directory Structure and Go Packages ```text pkg └── plugin ├── internal │   ├── legacy │   └── v1 └── *.go ``` ### Plugin System specification The [Plugin System](#plugin-system) is versioned becasue in order to not break Helm 3 plugins in Helm 4, while allowing the project to deprecate old versions and make future changes in a sane way. * `v1`: The new Wasm Plugin System * `legacy`: Legacy support for Helm 3 subprocess plugins; no new fields expected (deprecated in Helm 4, to be removed in Helm 5) * `pkg/plugin/*.go`: Public functions containing logic for plugin installation, pulling plugin metadata, plugin listing, the routing layer that decides which plugin system (legacy, Wasm) to use, and the [Plugin Type](#plugin-type) definitions. ### Plugin Types specification These are optional plugins that can be used to alter the default behavior of Helm. Some plugin types will support multiple plugins of the same type to extend behavior (for example, multiple download plugins to support different protocols used across multiple dependencies of the same chart), while others may support using a single plugin to replace certain default behavior outright. Initial plugins will be launched with the release of the new Plugin System, with the architecture making it now easier to achieve the longer-term goal of developing a wider range of plugin types. The initial plugin types will be: - **Download** For downloading a chart or subchart from a remote source using some other protocol than HTTP/S or OCI, such as [s3](https://artifacthub.io/packages/helm-plugin/s3/s3) or [git](https://artifacthub.io/packages/helm-plugin/git/helm-git). - **Postrender** The [Helm 3 post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering) functionality moved to the new Wasm plugin system. See [Security implications](#security-implications) section. - **CLI** The new plugin system will continue to allow users to build and install CLI plugins, which specify subcommands for the Helm CLI. However, these will also be run in Wasm sandbox rather than directly calling arbitrary executables as a subprocess as was done in Helm 3. This will require Helm 4 plugin developers to follow our tutorials for migrating their legacy CLI plugin to the new Wasm CLI plugin framework. ### Plugin specification `plugin.yaml` will be updated to include additional fields. These will be global across all plugins, with the exception of `config` which will vary depending on the plugin type. ```yaml apiVersion: v1 name: my-custom-postrender-plugin version: 0.1.0 type: postrender.plugins.helm.sh/v1 sourceURL: https://github.com/example/my-plugin config: {} ``` New fields: - `apiVersion`: This field is added to specify compatibility with the overall [Plugins System](#plugin-system) API. This will allow us to move to a new major version of Extism or other Wasm tooling independent of Helm major version. - `type`: added to specify the Plugin Type message schema version the plugin expects to handle. Versioning this allows it to be updated within the same MAJOR version of Helm. The proposed format is `PLUGIN_TYPE.plugins.helm.sh/PLUGIN_TYPE_VERSION`. - `sourceURL`: added to encourage best security practices. See [Security implications](#security-implications). - `config`: Per-plugin configuration allowable by it's [Plugin Type](#plugin-type) definition. ### Helm plugin commands specification - `helm plugin list` command will be updated to also show the type of plugin, whether or not it is core or custom, the plugin source, and signing key if any. Example output: ```console NAME VERSION TYPE SIGNED SOURCE_URL s3 1.2.3 download 862HB19B https://gitlab.com/someone/s3-helm-plugin kustomize 4.0.0 post-render 208DD36E https://github.com/helm/helm my-nodejs 0.1.0 post-render N/A N/A ``` - `helm plugin install` installs a plugin from a URL (see Distribution specification below) - `helm plugin update` will check for updates, then follow the same behavior of `plugin install` - `helm plugin sign` will use Helm 4's built-in provenance signing mechanisms as a convenience to sign a plugin - `helm plugin verify` will use Helm 4's built-in provenance mechanisms as a conveniencce to verify a signed plugin ### Distribution specification Helm will need to install/download plugins Wasm binaries. When users run `helm plugin install`, and other future methods. Helm will initially support installing plugins from http URLs, from version control systems, and the local filesystem, just as in Helm 3. The distribution format may either be discrete files (ie. filesystem or version control system), or packed tar archives (e.g. filesystem and URLs). Format described below. Eventually, it is recommended that Helm supports plugin distribution via OCI artifacts. And further distribtion schemes e.g. S3 could be supported via plugins themselves. #### Plugin distribution format A plugin comprises of the following filesystem structure (or a tar archive of): ``` . ├── [LICENSE] # Optional: plugin licence ├── NAME.wasm # Wasm binary └── plugin.yaml # Plugin manifest ``` ### Provenance specification Helm will require plugins to be signed, producing an error if an unsigned plugin is attempted to be installed. With an exception for the following situation: - Installing from the local filesystem (for local development) - When the user provides an `--allow-insecure-plugins` flag (see [Security implications](#security-implications)) Helm 4 will support the same provenance functionality for Plugins as Helm 3 supports for charts. See . When Helm supports additional signing mechanisms such as [sigstore](https://www.sigstore.dev/) based signing for charts, this will also be supported for plugins. To follow this initiative, see [Support additional signing mechanisms than PGP](https://github.com/helm/community/issues/325). ## Rationale The following apply to the Plugin API v1 (see `apiVersion` under [Plugin specification](#plugin-specification)): ### Technical reasoning for Wasm plugins For a plugin system to work, Helm must be able to "invoke" the plugin with a suitable message so that the plugin can perform its operation and return a result. The traditional "[foreign function interface](https://en.wikipedia.org/wiki/Foreign_function_interface)" problem ```mermaid sequenceDiagram participant h as Helm (Go) + Wasm runtime participant P as Plugin (Go, Rust, etc as .wasm) h->>P: Call exported function P->> h: Call imported function ``` For this, Helm 4 will be using 2 of the 3 main technologies that exist for interfacing with Wasm modules/components today (the 3rd option—WASI P2—is under [Rejected ideas](#rejected-ideas)). The two that will be used here are: 1. Native WASI P1 (POSIX/C-life FFI) [WASI P1](https://wasi.dev) defines a way for a module to export basic types in a C/POSIX style FFI. While simple, the caller has to manage much of the details, like converting internal structures into simple types (integers, pointers) and (manually) managing memory. 2. Message serialization/RPC (GRPC/protobuf, JSON, etc) Rather than trying to implement a rich FFI, either directly via WASI P1, or indirectly via WIT. Implement/utilize a simple FFI that uses a higher level serialization ie. serialization of internal types into e.g. protobufs or JSON and utilizing e.g. a simple FFI or GRPC or HTTP for the majority of message content. ### Technical reasoning using Extism for Wasm plugins For Wasm Plugin Interfacing, Helm 4 will be leveraging the Extism project. See and specifically the Extism [Go SDK](https://github.com/extism/go-sdk) and [Go PDK](https://github.com/extism/go-pdk). Extism is the most mature and well-supported Wasm plugin system today, has a large and growing ecosystem of supported languages and libraries, is actively maintained by a team of core contributors with a solid backwards compatibility policy, has a strong security focus, and makes Wasm plugin interfacing easier to implement than other systems. By chosing Extism, the new [XTP Bindgen](https://github.com/dylibso/xtp-bindgen) convenience tool will also be available for polyglot plugin developers to create bindings and codegen for their Extism Wasm host functions. See [additional information here](https://github.com/extism/go-pdk?tab=readme-ov-file#generating-bindings). ## Backwards compatibility Requirements for the new plugin system and the initial default plugins: - Helm 4 MUST continue to be as easy to install as Helm 3 - The default installation for Helm 4 MUST be "batteries-included". I.e., users will not need to take any additional installation steps for the new plugin system in order to use Helm's default functionality out of the box - Plugins used by Helm MUST be explicitly chosen by the end-user, and be clearly discoverable by the end user that they will be in use. This is to follow the [principle of least astonishment](https://en.wikipedia.org/wiki/Principle_of_least_astonishment) and make it easier for maintiners to support end users who may not be aware they or someone else has chosen to not use a certain portion of Helm's default behavior in their environment. - The new plugin system MUST NOT prevent SDK users from using the default functionality - A security plan approved by Helm's security team MUST be adopted for developing and releasing this new architecture model ## Security implications ### Summary The new plugins sytem will be based on Wasm for improved security over the previous subprocess plugin model in Helm 3, and for improved call and response options that allow extending more of Helm's functionality with plugins than was previously feasible. Additional steps are also taken to improve security: - Tools are added for signing and verifying plugins - Plugin authors are encouraged to follow best security practices (Helm will surface when these are not followed), and users are encouraged to take advantage of these - Helm will automaitcally attempt to verify the provenance signature of a plugin by default when it is first installed - [Helm 3 post-renderers](https://helm.sh/docs/topics/advanced/#post-rendering) will now also become a plugin type in the new Wasm plugin system ### Details In Helm 3, plugins required users to opt-in before using by manually installing. This put the responsibility on the user to ensure they trust the plugin authors, and verify by inspecting the source code. These plugins did not have a built-in provenance mechanism for signing or verifying as charts do. Since these plugins could call any executable, users could be spoofed by inspecting the source code in VCS, while the plugin called a compiled binary built from a different source. Security-minded users could address this if they wish by downloading the source and compiling themselves rather than using the upstream compiled Wasm file. This was also the case with Helm 3 post-renderers, which required passing the binary path. In Helm 4, users may still manually install plugins. Helm 4 will address this in the following ways: - Adds provenance signing and verifying options for plugins: Additionally, Helm 4 has built-in plugin provenance signing and verifying capability both through the CLI and SDK. This will make use of the same functionality for provenance that is supported for charts in Helm 4 (adding any additional methods like sigstore/cosign will be a separate HIP). - Security best practices encouraged and surfaced to end users: Plugin authors are expected to sign the plugins, clearly list their signing key(s) in the source code README, and give clear Wasm build instructions for their source code. For plugins that follow the above recommendations, end users are strongly encouraged to verify the provenance signature. Users may also inspect the source code before using plugins, and if they wish may build the Wasm plugin themselves. When a plugin is first installed using `plugin install` the CLI will exit with an informative error if a plugin is unsigned, and the user has not explicitly passed a flag (eg, `--allow-insecure-plugins`) to bypass this. Plugins installed from the local filesystem (from source as opposed to a tarball) are excepted from signing requirements, to enable local plugin devlopment. Assuming the plugin is signed (and not bypassed with the `--allow-insecure-plugins` flag), Helm will also attempt to verify the provenance signature BY DEFAULT when the plugin is first installed. If the signature is not found, or the signature is invalid, the user will be notified and the plugin will not be loaded. A user may pass a flag to bypass this verification check with an insecure flag too, but must explicitly do this to acknowledge they are bypassing the verification check. ## Implementation Plan Work for the plugin system will follow the [H4HIP: Helm 4 Development Process](/community/hips/hip-0012) timelines. 1. Marking this HIP as accepted (including security plan in this HIP approved by Helm's security team) 1. May. 2025: Engineering on this feature begins 1. Aug. 2025: Have inital work on all features included in the initial implementation, adhering to Feature freeze for Helm 4 release preparation 1. Nov. 2025: Initial offering feature complete by Helm v4.0.0 release 1. Post-release: Follow up HIPs for additional plugin types and features will match future Helm 4 Minor version release schedule ### Initial release of the new plugin system - [ ] Create initial version of new plugin package to load Wasm Extism plugins - [ ] Create message schemas for new plugins types: - [ ] `download.plugins.helm.sh/v1` - [ ] `postrender.plugins.helm.sh/v1` - [ ] `cli.plugins.helm.sh/v1` - [ ] Write host functions to invoke these initial defined Wasm plugin types ### Roadmap items that may be added in further HIPs - Additional plugin types for moving other Helm functionality to the plugin system - Allow plugins to be stored as OCI artifacts (in addition to HTTP, VCS, and local filesystem) - add Helm CLI command for plugins similar to `helm push` - Add new Helm plugin types to ArtifactHub.io - Move current Helm plugin kind to legacy and add a new Helm plugin artifact kind. To not pollute too much the list of top level kinds supported on ArtifactHub, plugins subtype (downloader, render, etc) could be a property of the plugin entry. This would also have the benefit of allowing publishers mixing plugins of multiple subtypes in the same Artifact Hub plugins catalog/repository. Regarding the plugins catalog structure, ideally ArtifactHub maintainers would like them to follow the same format they're using for most artifacts kinds supported these days. Here is an example: https://artifacthub.io/docs/topics/repositories/kubewarden-policies/. Reusing the same catalog format across artifacts kinds creates a unified experience for publishers when listing their content on Artifact Hub. It also simplifies maintenance on their side (they support +25 artifact kinds), making the project more sustainable. ## How to teach this - Create examples of each Plugin Type for the new plugin system that contributors can use as a model for their own plugins - `download`: OCI, HTTP/S - `postrender`: No default. We should write a very simple example to prove that the host function works - `cli`: No default. Similarly we should write a simple example proving the host function works - Write concise and easy to follow documentation for the new plugin system - Write a blog post outlining how the community will benefit from the new plugin system, which can link to the documentation and these examples - Create a presentation to propose for conference talks as another communition channel to make the community aware of the new plugin system - Reach out to authors of community plugin to encourage them to update to the new plugin types (examples could be moving the [s3 downloader plugin](https://artifacthub.io/packages/helm-plugin/s3/s3) to the new `download` type, and the [Helm Diff plugin](https://artifacthub.io/packages/helm-plugin/diff/helm-diff) to the new `cli` type) ## Reference implementation Two example Wasm plugins leveraging Extism have been prototyped. The first is an example downloader plugin, and the second is an example renderer plugin: - https://github.com/gjenkins8/helm-plugin-ocigetter - https://github.com/gjenkins8/helm-plugin-gotemplate-renderer/ The host functions are prototyped using Go testing, in `/testdriver/main_test.go` in each Git repo. These are fairly basic to start, but proves out that this capability works. Creating the proper interfaces will be part of the work implementing this HIP (see [Implementation Plan](#implementation-plan)). ## Rejected ideas 1. Using a subprocess plugin model. (The legacy Helm 3 subprocess system will be deprecated in Helm 4, and removed in Helm 5). This would have allowed us to avoid the need to write a migration path for existing CLI plugins, but is not as secure as the new Wasm plugin model that has since become feasible. For these reasons, we've also ruled out other available subprocess-based plugin systems such as [Hashcorp's go-plugin package](https://github.com/hashicorp/go-plugin). 1. Helm 4 will not create a central repository for plugins. This is a non-starter for the Helm project. Helm maintainers have learned from the experience of the formerly centralized charts repo that it does not scale well or enable eccosystem growth as much as a distributed community-managed model. See [/community/hips/archives/helm/distributed-search](/community/hips/archives/helm/distributed-search). 1. Helm 4 have ruled out the following technologies for plugin interfacing in Helm 4: - [WASI Preview 2](https://github.com/WebAssembly/WASI/tree/main/wasip2#readme) / [WIT IDL](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md) / [Wasm Component Model](https://github.com/webassembly/component-model) Problem: While it is production ready and in use by other projects, it is not yet supported by Extism's underlying Go tooling, Wazero. Without tooling like Extism, implementing the plugin model we're after would be a lot of additional work. It is likely that Wazero and therefore also Extism will support the Component model in time for Helm 5. The only other viable Component model alternative to Extism for our use case that we're aware of would be to use CGo to link in [Wasmtime](https://github.com/BytecodeAlliance/wasmtime), but that would likely require a high level of expertise to implement and maintain. - [Wazero](https://github.com/tetratelabs/wazero) directly Problem: With Wazero, all params are uint32, so any strings must be interpreted from that, which would be a significant amount of work to manage directly. This is one of the problems Extism solves, and is able to leverage Wazero in a viable way for our plugins use case. - [Wadge](https://wasmcloud.com/docs/developer/languages/go/components#wadge) in wasmCloud Problem: This is another CGo-based solution. Helm maintainers would like to avoid CGo due to complexity it would add for cross-compiling, debugging, and other issues. - [Web Assembly for Proxies (Go SDK)](https://github.com/proxy-wasm/proxy-wasm-go-sdk) Problem: This is largely Envoy-specific, used for their [Wasm HTTP filter plugin](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/wasm_filter), and does suit our use case well. - [Go native plugin system](https://pkg.go.dev/plugin) Problem: Go native plugins do not support Windows. For this reason alone, Helm can't use this solution. Additionally, go native plugins run as native code without any sandboxing restrictions. - [Embedded go interpreter (yaegi)](https://github.com/traefik/yaegi) Problem: Yaegi does not have full sandboxing like Wasm. See Note: Traefik uses this, so it seemed notable enough to mention. ## Open issues 1. What extra permissions would Helm 4 Wasm plugins need to provide to give CLI plugin authors parity with the subprocess model that allowed plugins to do anything to the user's environment? ## References Precedents: Helm [2.1.0](https://v2.helm.sh/docs/plugins/#downloader-plugins) introduced the Helm plugin concept, mainly as a way to add additinal helm CLI subcommands that are not part of the built-in Helm codebase. This is helpful for adding new one-off functions, but does not allow users to extend the default behavior of Helm. Later Helm [2.4.0](https://v2.helm.sh/docs/plugins/#downloader-plugins) introduced the downloader plugin, which did make Helm core functionality extensible—in this case allowing users to download a chart from other sources than HTTP/S repos by specifying any other protocols such as [s3](https://artifacthub.io/packages/helm-plugin/s3/s3) or [git](https://artifacthub.io/packages/helm-plugin/git/helm-git). ================================================ FILE: community/history.mdx ================================================ --- title: The History of the Project description: Provides a high-level overview of the project's history. sidebar_position: 5 --- Helm is a [graduated](https://helm.sh/blog/celebrating-helms-cncf-graduation/) [CNCF project](https://www.cncf.io/projects/). Helm began as what is now known as [Helm Classic](https://github.com/helm/helm-classic), a Deis project begun in 2015 and introduced at the inaugural KubeCon. In January of 2016, the project merged with a GCS tool called Kubernetes Deployment Manager, and the project was moved under [Kubernetes](https://kubernetes.io). As a result of the merging of codebases, Helm 2.0 was released later that year. The key feature of Deployment Manager that survived in Helm 2 was the server-side component, renamed from DM to Tiller for the final Helm 2.0 release. Helm was promoted from a Kubernetes subproject to a full-fledged CNCF project in June, 2018. Helm formed a top-level governing body and several projects were subsumed under the Helm project, including Monocular, the Helm Chart Repo, Chart Museum, and later the Helm Hub. When the Helm 3 development cycle began, Tiller was removed, bringing Helm closer to its original vision of being a client tool. Helm 3 was released in November 2019. Helm [graduated as a CNCF project in April 2020](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). The CNCF [Artifact Hub](https://artifacthub.io) replaced the [Helm Hub](https://hub.helm.sh) in October 2020. In 2025, the Helm project [celebrated its 10th anniversary](https://helm.sh/blog/helm-turns-ten/). [Helm v4.0.0](https://github.com/helm/helm/releases/tag/v4.0.0) was [released](https://helm.sh/blog/helm-4-released/) on November 12, 2025 at KubeCon + CloudNativeCon North America — the first new major version in six years. The release was driven by the need for architectural changes that could not be made without breaking the public SDK API. Key additions include a redesigned plugin system with WebAssembly support, Server-Side Apply, kstatus-based resource watching, content-based caching, reproducible chart builds, and an updated SDK API with support for multiple chart API versions. Existing charts remained backwards compatible. See the [Helm 4 Overview](/docs/overview) for more details. ================================================ FILE: community/incubator.md ================================================ --- title: Kubernetes Helm Incubator Process --- **Authors:** Brandon Philips , Sarah Novotny , Brian Grant ## Kubernetes Helm Incubator The [Kubernetes Helm](https://github.com/kubernetes-helm) project is where all new Helm-related projects should start. Once going through the incubation process explained in this doc they can become full Kubernetes Helm Community Projects. The process is designed to ensure that new projects have correct licensing, up-to-date boilerplate documents, a healthy community process, and are developed using accepted Kubernetes Community practices. ### Context New Kubernetes projects are getting added in an ad-hoc manner leading to confusion; see [this thread as an example](https://groups.google.com/forum/#!topic/kubernetes-dev/o6E1u-orDK8). ### Status This process is light on legalese, completely untested, and only works if people act as good neighbors and community members. It will evolve over time and the authors will try keeping the process light, fast, and objective. ## Does my project need to Incubate? ### Applications on top of Kubernetes Helm If you are building an Open Source application on top of Helm that is unrelated to the development, operation, monitoring, APIs, lifecycle, integration, or other primary concerns of the Kubernetes Helm project there is no reason to become a Kubernetes project. If you are unsure if your project is a good fit try running it by a few Kubernetes Special Interest Groups or kubernetes-dev@googlegroups.com. ## Entering Incubation To create a new project for incubation you must follow these steps: write a proposal, find a champion, gain acceptance into SIG-Apps, and finally get approval of a Sponsor. The Sponsor and Champion cannot be the same person. Your proposal should include two items. First, a README which outlines the problem to be solved, an example use case as-if the project existed, and a rough roadmap with timelines. Second, an OWNERS file that outlines the makeup of the initial team developing the project. Initially this can be one person but ideally has a 3 or more initial developers representing a few different companies or groups. You can use whatever tool you want to host and revise the proposal until the project is accepted to the Incubator: copy/paste from your text editor, Google Docs, GitHub gist, etc. Once the proposal is written you should identify a champion; this person must be listed as either a reviewer or approver in an OWNER file in the [Kubernetes Helm project](https://github.com/kubernetes/helm). Next, reach out to your potential champion via email to ask if they are interested in helping you through the Incubation process. Ideally some significant follow-up discussion happens via email, calls, or chat to improve the proposal before announcing it to the wider community. The next discussion should be on the Special Interest Group Apps mailing list. You should post the proposal to the SIG-Apps mailing list and wait for discussion for a few days. Iterate on the proposal as needed and if there is rough consensus that the project belongs in SIG-Apps then list SIG-Apps in the proposal README. If consensus isn't reached then identify another SIG and try again; repeat until a SIG is identified. The final process is to email kubernetes-dev@googlegroups.com to announce your intention to form a new Incubator project. Include your entire proposal in the body of the email and prefix the Subject with [Incubator]. Include links to your discussion on the accepted SIG mailing list to guide the discussion. Acceptance of the project into the Kubernetes Incubator happens once a Sponsor approves. Anyone listed as an approver in the top-level pkg OWNERS file https://github.com/kubernetes/kubernetes/blob/master/pkg/OWNERS can sponsor a project by replying to the kubernetes-dev discussion with LGTM. ## Creation of the Incubator Project Once your project is accepted someone will create a new GitHub repo for your project to use in the github.com/kubernetes-incubator organization. The first order of business is to add the following files to the repo: - a README from the accepted proposal - an OWNERS from the accepted proposal - a CONTRIBUTING file based on kubernetes/kubernetes - a code-of-conduct.md based on kubernetes/code-of-conduct.md - a LICENSE file with the Apache 2.0 license - a RELEASE.md file that talks about the process for releases A template project to start your project with these files can be found here: https://github.com/kubernetes/kubernetes-template-project ## Exiting Incubation An Incubator Project must exit 12 months from the date of acceptance in one of these three ways: - Graduate as a new Kubernetes Project - Merge with another Kubernetes Project - Retirement ### Graduation Both time and traction are required to graduate to becoming a new Kubernetes Community Project. It is expected that from the time that your project is accepted to a request for graduation the following criteria are met: - **Documented users:** the project tracks evidence from downloads, mailing lists, Twitter, blogs, GitHub issues, etc that the project has gained a user base - **Regular releases:** the project is making releases at least once every 3 months; although release should happen more often - **Incubation time:** a minimum of 6 months has passed since - **Healthy community:** a healthy number of users, contributors, and/or OWNERS outside of your own company have participated in the project. The Sponsor and Champion can make this call. - **Roadmap:** A roadmap for the next release is maintained; this can be in the form of a doc, GitHub milestones, or any other tool but it must be documented in the README When the OWNERS of the Incubator project determine they have met the criteria to graduate they should contact their Champion and Sponsor to discuss. If both the Sponsor and Champion agree that the above criteria have been met the project can graduate to become a Kubernetes Community Project and exit the Kubernetes Incubator. An announcement of graduation must be sent to the kubernetes-dev@googlegroups.com mailing list by the Champion. ### Merge At any point during Incubation a project can exit by merging the project with another Incubator Project or Kubernetes Community Project. The process to merge includes: 1. Incubator Project OWNERS notifying the project Champion and Sponsor 2. Once the Champion and Sponsor have been informed then email kubernetes-dev@googlegroups.com about the intention to exit through a merge ### Retirement If a project doesn't merge or graduate within 12 months it is retired. If a project fails to make a release for 6 months it is retired. Retired repos are moved to the github.com/kubernetes-incubator-retired organization. A warning email will be sent 3 weeks before the move to all people listed in the root OWNERS file, the Champion, and the Sponsor. A project can be re-incubated after retirement but must go through the process of Incubation Entry from the beginning, the same as any new project. ## FAQ **Q: What is the role of a Champion?** **A:** Potential Champions come from the set of all Kubernetes approvers and reviewers with the hope that they will be able to teach the Incubator Project about Kubernetes community norms and processes. The Champion is the primary point of contact for the Incubator Project team; and will help guide the team through the process. The majority of the mentorship, review, and advice will come from the Champion. Being a Champion is a significant amount of work and active participation in the sponsored project is encouraged. **Q: What is the role of the Sponsor?** **A:** Potential Sponsors come from the very small set of Kubernetes contributors that can approve any PR because they are listed as approvers in the `kubernetes/pkg` OWNERS file or the top-level OWNERS file. The idea is that by relying on this small set of Kubernetes Community members to make a determination on Incubator projects we will ensure that there is consistency around new projects joining the Incubator. Being a Sponsor is a minor advisory role. ## Existing Repos Based on the above process there are a number of repos under github.com/kubernetes we should handle through either grandfathering, a move to incubation, or retirement. This list is a rough draft, if you feel strongly about something being miscategorized please comment. **Projects to Move to Incubator** - github.com/helm/monocular - github.com/helm/rudder-appcontroller ## Thank You Large portions of this process and prose are inspired by the Apache Incubator process. ## Original Discussion https://groups.google.com/d/msg/kubernetes-dev/o6E1u-orDK8/SAqal_CeCgAJ ## Future Work - Expanding potential sources of champions outside of Kubernetes main repo ================================================ FILE: community/localization.md ================================================ --- title: "Localizing Helm Documentation" description: "Instructions for localizing the Helm documentation." aliases: ["/docs/localization/"] sidebar_position: 6 --- This guide explains how to localize the Helm documentation. ## Getting Started Contributions for translations use the same process as contributions for documentation. Translations are supplied through [pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) to the [helm-www](https://github.com/helm/helm-www) git repository and pull requests are reviewed by the team that manages the website. ### Two-letter Language Code Documentation is organized by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) for the language codes. For example, the two-letter code for Korean is `ko`. In content and configuration you will find the language code in use. Here are 3 examples: - In the `i18n` directory, there are subdirectories for each language code. The localized content for the language is in each subdirectory. - Localized content in each - For each language, there is a `code.json` file for each language with phrases used on the website. English, with a language code of `en`, is the default language and source for translations. ### Fork, Branch, Change, Pull Request To contribute translations start by [creating a fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) of the [helm-www repository](https://github.com/helm/helm-www) on GitHub. You will start by committing the changes to your fork. By default your fork will be set to work on the default branch known as `main`. Please use branches to develop your changes and create pull requests. If you are unfamiliar with branches you can [read about them in the GitHub documentation](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches). Once you have a branch make changes to add translations and localize the content to a language. Note, Helm uses a [Developers Certificate of Origin](https://developercertificate.org/). All commits need to have signoff. When making a commit you can use the `-s` or `--signoff` flag to use your Git configured name and email address to signoff on the commit. More details are available in the [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work) file. When you are ready, create a [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) with the translation back to the helm-www repository. Once a pull request has been created one of the maintainers will review it. Details on that process are in the [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md) file. ## Translating Content Localizing all of the Helm content is a large task. It is ok to start small. The translations can be expanded over time. The following describes the files/directories that are used to translate the docs content, blog content, and site elements in the Helm documentation site: - `i18n/` directory: - `code.json` used for translating React code in the site (including the landing page) - `i18n//docusaurus-plugin-content-blog` subdirectory with blog translations - `i18n//docusaurus-plugin-content-docs` subdirectory with: - Version subdirectories for docs content translations (eg `i18n//docusaurus-plugin-content-docs/version-3/`) - JSON files for each version of the docs with translations for the categories in the sidebar (eg, `current.json`, `version-3.json`, etc) - `i18n/docusaurus-theme-classic` subdirectory with `footer.json` and `navbar.json` files for translating the visible text in the site navbar and footer - The `i18n` key in the `docusaurus.config.js` file lists all the locales and exposes config options for the locale dropdown in the site navbar For more information, see [i18n - Introduction](https://docusaurus.io/docs/i18n/introduction) in the Docusaurus docs. ### Starting A New Language For a tutorial that walks you through how to translate site content, see [i18n - Tutorial](https://docusaurus.io/docs/i18n/tutorial) in the Docusaurus docs. To start a new language: 1. If you haven't already, install dependencies: ``` yarn install --frozen-lockfile ``` 1. Run the Docusaurus `write-translations` command. For example, to add the `fr` (French) locale: `yarn write-translations -- --locale fr`. This creates the required directory structure for the language and initializes the JSON translation files required to translate site elements like the navbar, footer, landing page, and sidebar. ``` yarn write-translations --locale ``` 1. Do the minimum translations for the new language: 1. Translate the `code.json` file. 1. In the `i18n/docusaurus-theme-classic` subdirectory, translate the `footer.json` and `navbar.json` files. 1. In the `docusaurus-plugin-content-blog/options.json`, translate the blog elements in the `options.json` file. 1. Add the language to the `i18n` key of the `docusaurus.config.js` file so that it appears in the dropdown in the navbar: ```yaml i18n: { defaultLocale: 'en', # add new language to this list of locales locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'], localeConfigs: { en: { htmlLang: 'en-us', label: 'English', }, de: { label: 'Deutsch', }, # new_lang { # label: 'Navbar label', # } }, }, ``` 1. (Optional) Translate docs or blog content. See _Translating_ below. 1. Test your changes by starting the localized site in dev mode, specifying the locale: ``` yarn start --locale fr ``` :::note Each locale is a distinct standalone single-page application. You can only preview one locale at a time. It is not possible to preview all locales at the same time. ::: ### Translating Before you translate docs content, review the following best practices and guidelines: * Translation tools can help with the process. This includes machine generated translations. Machine generated translations should be edited or otherwise reviewing for grammar and meaning by a native language speaker before publishing. * Do not add an untranslated copy of an English file to `i18n/[LANG]/plugin-content-docs` or `i18n/[LANG]/plugin-content-blog`. Once a language exists on the site, any untranslated pages will redirect to English automatically. Translation takes time, and you always want to be translating the most current version of the docs, not an outdated fork. * Make sure you remove any `aliases` lines from the header section. A line like `aliases: ["/docs/using_helm/"]` does not belong in the translations. Those are redirections for old links which don't exist for new pages. * Add anchor IDs to any headings using the format `## Example Heading {#example-anchor-id}`. The anchor IDs must be English language and match the anchor IDs of the corresponding heading in the English doc page. For example, `## 后端存储 {#storage-backends}` matches `## Storage backends {#storage-backends}`. This ensures that any anchor links to the headings still work in the translated version of the page. For more information, see [Anchor links to headings](https://github.com/helm/helm-www/blob/main/ARCHITECTURAL_DECISIONS.md#anchor-links-to-headings) in `ARCHITECTURAL_DECISIONS.md`. To translate docs and blog content: 1. Make sure that target locale exists in the `i18n` directory. If it doesn't, see _Starting a New Language_ above. 1. Copy one or more markdown files that you want to translate from `/docs` or `/versioned_docs` to the appropriate version folder in `i18n//docusaurus-plugin-content-docs`. For example, to translate `versioned_docs/version-3/example.md` into Korean: ```sh cp versioned_docs/version-3/topics/example.md i18n/ko/docusaurus-plugin-content-docs/version-3/topics/example.md ``` 1. Copy one or more markdown files that you want to translate from `/blog` to `i18n//docusaurus-plugin-content-blog`. For example, to translate `blog/2025-09-09-path-to-helm-v4.md` into Korean: ```sh cp blog/2025-09-09-path-to-helm-v4.md i18n/ko/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md ``` 1. If you haven't already, install dependencies: ``` yarn install --frozen-lockfile ``` 1. Test your changes by starting the localized site in dev mode, specifying the locale: ``` yarn start --locale ko ``` :::note Each locale is a distinct standalone single-page application. You can only preview one locale at a time. It is not possible to preview all locales at the same time. ::: ## Navigating Between Languages Users navigate between languages in the locale dropdown in the site navbar. The `i18n` key in the site global `docusaurus.config.js` file is where language navigation is configured. To add a new language, add the locale using the [two-letter language code](./localization/#two-letter-language-code) defined above. Example: ```yaml i18n: { defaultLocale: 'en', # add new language to this list of locales locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'], localeConfigs: { en: { htmlLang: 'en-us', label: 'English', }, de: { label: 'Deutsch', }, # new_lang { # label: 'Navbar label', # } }, }, ``` ================================================ FILE: community/meeting-notes/2017.md ================================================ --- title: Helm Minutes for 2017 --- ```txt December 14, 2017 Announcements Helm Summit CFP is open (are we extending deadline?) Helm 2.8 soon after Kubernetes 1.9 is released Standup: Justin: Issue triaging Michelle: KubeCon SIG-Apps meeting Deployments with injected values about the environment Helm summit planning and mailing list setup Steve: Lot of discussions a KubeCon Internal discussions about Helm and security, maybe some afterward discussions Looking over issue list Matt Farina Helm Status YAML/JSON output done How to pass in custom user agents? (For CI) OWNERS files for k/charts; instituting this as policy this week All k8s org projects will now have stale issue closer CircleCI fixed Matt Butcher KubeCon updates about SK, Alibaba, etc. Suggest skipping meetings for rest of year Matt Fisher Alibaba: Using a forked Kubernetes with Helm SIG-Apps Update and Deep Dive meetings: Good discussions on Helm dev summit, esp. On whether we should use CRDs Looking at Adam’s PR for 1.9 support Taylor Focusing on Helm summit Lots of sponsorship asks Triaging CFPs with Fisher, Adam, Michelle on Dec. 15 Some PR triaging Some ideas about CRDs that might prototype Adam PR for k8s 1.9 Heads up on remodeling of Kubernetes types [Fisher volunteered to pair] Discussion items Helm Summit [Michelle] Please submit CFPs https://helmsummitpdx-feb2018.splashthat.com/ Contact Taylor for CFP review When do we want the CFP deadline? Follow-up in the CFP discussion tomorrow Helm security mailing list and email [Michelle] Current: helm-security@deis.com What do we want the new address to be? Security mailing list? Google groups or mailman Fisher: Mailman usage is common in open source communities KubeCon update Kubernetes upgrades for 1.9, and how this breaks/changes Helm November 30, 2017 Announcements Helm Summit venue is locked in: The Evergreen in Portland, OR. 21-22 February 2017 There’s space enough for 200 people or less. It’s “super cute.” Nike is co-sponsoring with Microsoft. There or may not be Nike swag available. Standup: Taylor Working through backlog of PRs. Coordinating Nike side of sponsoring the summit. Reviewing Michelle’s Tiller plugin. Adam KubeCon preparation. Starting in on working on Kubernetes 1.9-related changes. Brian Steven Discussing Tiller security with internal teams considering using Helm. Michelle Working on a plugin called “secure-tiller” to lock down Tiller for a particular Kubernetes namespace. It deploys Role and RoleBinding objects to restrict Tiller’s permissions. She’s soliciting feedback on whether this pattern and convention is helpful and desired. Working on securing the venue for the Helm summit. Matt Fisher Triaging issues, including a few related to security. gRPC upgrade Should we wait until after KubeCon to release? Helm version 2.8 would bring parity with Kubernetes version 1.9. Matt Farina Working on slides for presentation at KubeCon. Sprig library interface oddities needed accommodation, for a pending release. Matt Butcher Cleared out PRs in the queue on Thanksgiving. Published the secure Tiller/TLS configuration blog post. There are coming changes to the Helm documentation site. KubeCon and the Helm Team Michelle is planning meetings, and wants to know who wants to participate. Lots of people new to Helm will be there. Keep that in mind when pitching Helm. Michelle is working on a “cheat sheet” to help explain what’s changing in Helm to keep pace with Kubernetes evolution. We’d like to find people who are not maintainers to speak on their use of Helm. Be on the lookout for experience reports, and encourage people to attend the Helm summit a couple of months later. Discussion Stepping down from core maintainership role gracefully: Introduce a new category for “emeritus” where one rescinds a previously-held voting role. Open an issue in which to discuss this procedure. The Kubernetes Steering Committee has guidelines that we could borrow. There are parties that may show up at KubeCon that will paint the Helm community in a bad light. We’ve been improving the documentation in preparation. Be professional, level-headed, and set a good example. Confrontation isn’t helpful. Matt Farina is willing to intervene and mediate. Action Items: Share documentation that addresses these concerns. November 16, 2017 Announcements Helm v2.7.2 Standup: Taylor Issue sherpa’ing Bug reported with tiller memory leaks Working with michelle on the helm dev summit Adam Released v2.7.1 Brian Triage the TLS issue that was released in v2.7.2 Steven Asked to place a discussion around pluggable tiller authentication backends Michelle Working on the helm dev summit side as usual Been going through the UX for setting up RBAC Matt Fisher Triaged issues for v2.7.1 Peer reviewed the patch for v2.7.2 Matt Farina Starting on work for helm status output as JSON Discussion Pluggable auth backends for tiller IBM wants to integrate their authentication/authorization backend to front tiller Some arch discussion around blocking direct access to tiller only to the authentication gateway IBM would like to open a ticket to discuss this proposal v2.7.3? The patch looks good, but there are concerns around the grpc-go PR being backwards-incomaptible between Helm patch releases November 9, 2017 Announcements None for today Standup: Taylor Looking at what items need to make it to the next Helm release Reviewed the "symlink-walk" piece that we needed to remove because it was part of the facebook-go dependencies. Looking pretty good. Matt Farina: Moving charts to a model where owners will be able to make PRs themselves. Still a little ways out to finalize this, since we need to move to Prow before this can happen Justin: Was Sherpa Tsar Merged an example for overrides Nikhil: Working on new chart for Portus Registry Will run it by folks once it's complete to get some feedback Discussion Topics Turning on RBAC by default (kensey - Issue 3098 in GitHub) Chart PR that was reviewed - reformat chart using RBAC (enable/disable + service account) Most of the other kubernetes teams have moved to use RBAC by default Ideally make a decision on this by next dev-meeting Helm Summit (Taylor) Current dates were oo close to KubeCon, so makes sense to reschedule Moved out to Feb 6th and 7th CFP deadline to moved out to a week after KubeCon The venue is still being finalized, should be safe to book travel once venue is finalized Assignments for next week Issue Sherrif - Taylor Notes - Justin Meeting Lead - November 2, 2017 Announcements Microsoft folks will be away all next week If you are a core maintainer and not already on the kubernetes-helm-core google group, please request access here Helm Summit CFP is open. Submit a CFP to speak at the summit here If you’re interested in helping with the schedule and sort CFP submissions, please contact Taylor Thomas Plans to release a v2.7.1 sometime in the near future Standups Matt Farina Got a few PRs merged on bringing out the app version and maintainer URL to Chart.yaml Raised a question about charts should be mutable or not; kubernetes/charts are currently mutable Matt Butcher Got ChartMuseum into helm’s incubator with Matt Farina Chatted with Farina about helm templating ideas Plans this week are to continue with helm comunity stuff Michelle Reached out to Sarah (Kubernetes) and Dan (CNCF) to advise on where we should post community meeting recordings Fisher Issue queue triaging Working on documentation Need alias for security leaks Taylor Issue sherpa this week Issue got dropped about deployments. One user is considering dropping helm due to this bug so we should strive to take a closer look into it Finalizing some venue stuff for the dev summit, looks like it’s going to be in downtown portland Adam Worked on trying to tamper down the PR queue along with Fisher Focusing on helping out Michelle on the helm dev summit Michelle Talking to lots of users last week on Helm Posted the presentation on helm from last week so others can learn Helm summit is on her list of TODOs: CFPs, venues, schedule etc. Reached out to Sarah and Dan(?) on how we want to upload the helm dev summit videos Justin Jumped into the context deadline exceeded issue Fisher has commented on that issue to *hopefully* move the conversation/troubleshooting forward Steven Helping people over the istio helm chart, how to get it installed into the cluster and how to add it to your own service using istio sidecar injection Found a bug when submitting a chart with no objects caused an error; there’s an argument forming around a chart should be installable even if no resources are deployed Discussion topics What other mailing lists do we need other than Kubernetes-helm-core for core team communications? Need alias for security leaks Justin: should we pre-seed discussion about what is on the table for breaking changes in Helm 3? We should rope in everyone on a 45 minute dev call to discuss what’s the scope of the project for helm 3, whether charts compatibility should break between Helm 2 and Helm 3, etc. Should we discuss about the helm summit at KubeCon? Yes Assignments for next week Issue Majaraja: Justin Meeeting notes: Steven Meeting lead: Taylor October 26th, 2017 Announcements Helm v2.7.0 was released this Monday Helm v2.8.0 is planned to go out after Kubernetes 1.9 in December as agreed upon last meeting Standups Adam Reese Released Helm v2.7 Brigade launch has been taking up most of his time this week Matt Fisher Also assisted with Helm v2.7 release Steven Harris Concerns around confusion with values.yaml -- there are a lot of different ways to configure values. --reuse-values, --set, changing values.yaml, `helm inspect values` Taylor Thomas Jumping back this week Working on the helm summit, hopefully more progress next week Needs some more help on reviewing CFPs for the summit: Fisher and Reese raised hands Matt Farina Has 2 PRs in helm related to charts Adam said that he will get to reviewing them this week Discussion topics Fisher wants to propose a talk about how to propose and document new features in helm at the dev summit in Jan One concern around Helm 3: chart compatibility. We should strive to be compatible with Helm 2 charts now that there are a lot of them Steven brought up the discussion from this week’s SIG-Apps meeting from Brian Grant Fisher and others will be attending the working group to discuss ideas proposed by Brian and see if these can be distilled into features for Helm 3 (or Kubernetes in general) Assignments for next week Issue sherpa: taylor Meeting notes: fisher Meeting lead: steven October 19th, 2017 Announcements Helm Summit Interest Survey is out: https://goo.gl/forms/UBTTS7JaoZpSzoar1 Cut the release for 2.7.0-rc1 - Thanks Fisher, Adam and Taylor Standups Matt Fisher Helped out with the release Tag was not being built on CircleCI, had to use API directly to cut the tag Same issue happening on Draft so it might be something related Currently looking through this issue to get tags to work again so we don’t have to do a manual API Post to build the tag Planning on doing the release notes and documenting how to do that Looking for any issues on the rc1 release but haven’t found any If all looks well, we could release by next week Michelle Noorali Issue Maharani this week Created a google group for the Helm core team Sent out Helm Summit Survey to gauge people’s interest in attending Link: https://goo.gl/forms/UBTTS7JaoZpSzoar1 44 responses so far Sending out CFP form today for the Helm Dev Summit Will create a google group for the Helm community at large Venue is looking to have a max capacity of 200 at this time, looking at other options Reach out to michelle if interested in setting schedule stuff for the summit Date might be changing to Jan 16th/17th Adam Reese Issue grooming, PR reviews Helped released 2.7-rc1 Justin Scott This week want to participate more in helm Interested in telepresence. Pretty cool, didn’t work Taylor More helm dev summit organizing Matt Farina Working with the charts team for loosening CI linter rules Matt Butcher Taylor had some impromptu helm things going All the Helmettes went to the KubeCon after party together, from core maintainers to new users Met with SK Telecom using Helm to deploy all their Openstack mega clusters Lots of discussions around what people like and don’t like about Helm Out on vacation next week Bitnami announced their new Kubeapps product Discussion topics Kubernetes 1.9 planning Wednesday December 13th The rc1 is set for 12/6 Look at releasing helm 2.8 at the end of the year Keep in mind KubeCon is Dec. 6-8 Helm 2.7.0 release date Looking at Monday or Tuesday of next week if no issues arise before then Venue options and preferences Fisher said that he’s interested in seeing the Nike campus :3 Assignments for next week Issue sherpa: Taylor Meeting Notes: Matt Fisher Meeting Leader: October 12th, 2017 Announcements Standups Adam K8s 1.8 support Working with Matt Farina on some PRs, will be following up this week Matt Fisher Steven Using helm around different environment-based values Looking into/reading about the CronJob issue Matt Butcher Had a meeting with App Registry and ChartMuseum Following up with ChartMuseum dev wants to put it into helm incubator Outcome of the meetings was there was strong ChartMuseum as the backend and Monocular as the front-end for a chart repository experience Launching new OSS so being busy for the next 2 weeks or so Justin Scott Playing around with telepresence (sorry Fisher) :P Taylor Issue sherpa this week Trying to lasso issues into the 2.7 release, continuing to assist in the RC Nick Got helm/tiller merged into SUSE’s CaaS platform Matt Farina Submitted a preemptive bug fix Updates on the charts repo: They are linting and running various static tests with Circle to automate all the things Discussion Secrets backend Docs Conversion from ConfigMaps to Secrets Decision is to go ahead and merge and add documentation outside of PR 2.7 Release Adam in charge of cutting release K8s support again….We need to support 1.7 and 1.8, which means supporting 2 API versions for this release This PR should probably be pulled off of 2.7 and fixed upstream RC release date: Monday, Oct. 16th Helm Summit Figuring out final details about the venue, should have news in the next few weeks FakeClient PR Some input and help needed. We need to make sure we help quickly on this Dashboard Authentication example Steve saw some code with using user roles to allow better access. Not the best option, but other apps are progressing with authentication See https://github.com/kubernetes/helm/pull/3025 Assignments for next week: Issue Sherpa: Michelle Meeting Lead: Fisher Note taker: Steve October 5th, 2017 Announcements Helm v2.6.2 Standups Matt Fisher Cut v2.6.2 with help from Adam Issue sherpa’ing Adam Reese Assisting Fisher on the Helm v2.6.2 release Working on porting k8s 1.8 support on top of Helm. There’s some nil errors occurring during testing Also an issue to do with docker/distribution in glide Fisher mentions that there is an open PR to switch over to dep which may fix that Taylor Working on PR support for 2.7 Need to figure out the 2.7 release timeline Want to get back on Helm commandeer stuff Matt Butcher Getting back onto the swing of things, been at conferences all last week Working/chatting with the creator of ChartMuseum Working with the service catalog team on sprig PRs which should get incorporated into Helm Mike Goodness Finished wrap-up on calico network policies at TicketMaster, so far so good Should be able to spend some time reviewing community PRs on charts Steven Jail chart tiller? Looking at checking tiller’s capabilities to check kubernetes api versions for conditional logic in charts Brian Just listening in this week Justin Working on different operators like prometheus Matt Farina Added CI to every chart PR, which runs `helm lint` on CircleCI Get meetings for ChartMuseum, AppRegistry etc. to sort through all of this Michelle (Matt Butcher speaking on behalf of her) Working with karen on helm dev summit Taylor is working with michelle on finding venues in portland Working with Fisher on creating a Helm-dev google group for notes, voting etc. Discussion Helm 2.7 timeline Butcher asks if there’s anything other than k8s 1.8 that should get in before we cut 2.7 Taylor mentions there’s the secrets backend that would be good to get in, but we’re still working on getting some documentation for that PR Matt Farina relays community unrest around the release delay between a kubernetes release and a helm release supporting that kubernetes release We should cut a release candidate once k8s 1.8 support is in Helm so users can test Helm on k8s 1.8 and try that out Assignments for next week: Issue Sherpa: Taylor (next week: michelle) Meeting Lead: Adam Note taker: Taylor September 28th, 2017 Announcements Standups Taylor Merged PRs that should be part of the patch release Fisher Issue sherping Facebook Go deps not compatible with Apache v2 or MIT license - need to pull these out Maciej Getting back to Helm-y stuff Resuming work on proposal of existing releases as chart deps Ramp up review counts Adam Just getting back up to speed after being ill :( Steven Using Helm quite a bit, new clusters coming online Scripts for installing and upgrading Helm Justin A couple issues Working on galera cluster operator Mike Working with Calico network policies using a chart Need to give the prometheus operator & alb ingress chart some love Adnan Something about CI? Discussion Facebook Go dependencies Include in patch release 2.6.2? Matt Farina: remove sooner than later Cutting patch release Some bug fixes still not merged Taylor to create 2.6.2 milestone Not sure we're in a position to release 2.7 next week 2.6.2 scheduled for tuesday or wednesday next week Authentication webhook Taylor to have chart to show for this Moving to offline discussion Declarative app management doc Discussed WG formation SIG-CLI meeting SIG-Apps and SIG-CLI effort, Helm should be involved Assignments for next week: Issue sherpa: Matt Fisher Meeting lead: Steven Note taker: Maciej September 14, 2017 Announcements Standups Steven Talked about application deployments using Helm and `kubectl rollout status` Lypht Asked about how to deploy charts sharing common values.yaml Taylor mentions https://github.com/skuid/helm-value-store Improved documentation on common charts? Adnan talked about possibility of `helm create` pulling in the common chart Mike Working on maintaining Helm chart PRs Working out the storageClass pattern for official charts Working on high quality, solidly reproducible charts Adnan Did a webinar yesterday with Helm, went rather well Matt Farina Talked about chart repositories at the last SIG-Apps meeting Different implementations: kubeless, app registry, traditional helm way Private chart repositories: app registry vs. dockerhub style Adnan: Perhaps incubate app registry as a Helm 3 “official” registry Adnan: perhaps just remove the concept of `helm repo update` and a local index.yaml? Spun out a larger discussion on Helm 3 chart hosting, migration paths for kubernetes/charts etc. Justin Issue triaging over the week Matt Fisher Issue triaging, assisting first-time contributors with their PRs Discussion Helm 3 chart hosting, as seen above Should we come up with a proposal template for proposals? Just want to push back-channel discussion over to the helm dev meetings, more lax proposals Assignments for next week: Issue sherpa: Justin Meeting lead: Taylor Note taker: Adnan September 7, 2017 [Recording] Announcements If you need edit access to this doc, let Michelle know 2.6.1 was released! Standups Maciej Worked on Rudder Federation Proposal for having existing releases be dependencies Adam Issue sherpa for the week Going to be looking at deployments not rolling Starting work on k8s 1.8 for Helm Butcher Working on releasing new sprig version Working with Openstack people on running Tiller as a DaemonSet Did something else small :) Michael Lots of chart PRs Michelle Reviewing PRs (specifically Amanda’s PR for indexing nested charts) Fisher Reviewing PRs, merged Helm template into core Should we add a kube version variable to template Steven Catching up on issues Trying out ksonnet Justin Working on writing tests for recursive builds (taking over another PR) Chart sorting Taylor PR reviews Needs another review on https://github.com/kubernetes/helm/pull/2721 Demos Helmet (Butcher) An intellisense completion tool for Helm on the command line https://github.com/technosophos/helmet Discussion Helm Summit Possible location Portland Georgia Happening in early January Kube version in Helm template Related PR: https://github.com/kubernetes/helm/pull/2898 We can mock things out like we do in tests. We would mock against the current kubernetes version we build against Template is no longer just for debugging, but also for rendering templates. It isn’t a preferred use case, but we are ok with adding in flags to enable this functionality Output formatting for Helm This is a complex issue that Adam already tried It might be cool to have, but there will be some work The main benefit would be viewing what the release looks like from a machine readable standpoint Helm dev meeting length Meeting will now start at 9:15 and go for 45 minutes Taylor to announce in channel Assignments for next week: Issue batman/butler: Butcher Meeting moderator: Adam Note taker: Fisher August 31, 2017 [Recording] Announcements One PR merged for 2.6.1, need to discuss when we want to release Standups Fisher Issue triaging, reviewing PRs. No significant feature work Butcher Asked about the `helm template` PR Justin mentioned it’s ready for review but not merged yet Working on chart stuff but not core Helm Michelle No issue updates for this week Updated the Deis youtube channel playlist Seeing if the channel playlist should live in CNCF or in the Kubernetes channel Maciej Working on federation rudder Adam Reviewed Maciej’s e2e PR, might want to hold off on merging until 2.6 is out to test tag release automation Possibly merge after 2.6, then do a couple test tags to make sure it goes through the whole release pipeline without blocking the impending release Brian Not present Taylor Was the issue maharaj this week, kudos to fisher and justin for triaging issues this week Doing PR reviews this week Chatting about secrets backend for Tiller, due to the size needs he asked for another review from the core team Robots are taking over Helm’s issue labels Butcher’s saying that we’ve been pushing back on moving over to the kubernetes-helm org for a while Any bots that are CNCF-related (like the CLA bot) could be pulled in once we move orgs Going to move forward with seeing how we can configure the PR sizing bot and see how we deal with them moving forward Lachie Not present Steven Working on Helm adoption internally Looking at integrating with artifactory Over the weekend had some time to look at some of the issues and PRs Adnan In the community repo, there’s a PR for meeting notes to reference the single google doc (this one) Discussion in the charts repo about moving away from annotations over to fields in the spec Lots of people are adding network policy stuff which is nice to see Justin General issue triaging Taking on the work for recursive build feature Demos Discussions Helm 2.5.1 issues to cherry pick? The subcharts being deleted when not present in requirements.yaml Possibly adding in the regex case-sensitive issue on helm search? https://github.com/kubernetes/helm/pull/2876 Fixup with relative index.yaml https://github.com/kubernetes/helm/pull/2862 Planning for next week Issues: Adam Reese Meeting moderator: Maciej Note taker: Taylor Thomas August 24, 2017 [Recording] No announcements 1 ticket for a 2.6.1 release, moving forward with 2.7.0 Standups Fisher Issue queue Taylor Working on scaffolding for helm commandeer Identified bug on helm delete, community member took this on after PR is out Would warrant 2.6.1 release Butcher Planning related stuff Beginning helm 3.0 phase the beginning of January Kubernetes Core has asked us if we would start releasing when kubernetes releases within a week or so of a Kubernetes release Lachie Is there anything we do could do as chart maintainers to start testing against kubernetes 1.8 Michelle Still waiting on initial cost projects for helm summit and helm core maintainer sessions. Will probably happen in January. Looking for sites. Looked into this PR: https://github.com/kubernetes/helm/pull/2824 Think it’d be best to nest helm readme command under helm inspect Helm Q&A time during next SIG Apps meeting. Here is the form. Adnan There is a discussion going on in charts around functions to be namespaced https://github.com/kubernetes/charts/issues/1785#issuecomment-323642628 Maciej Working on e2e tests https://github.com/kubernetes/helm/pull/2846 Created a framework, not about creating scenarios Using gingko For each test case, create new namespace Waiting on review and feedback Started writing proposal on using existing helm releases for dependencies Looking for feedback Demos Discussion Topics Look at Maciej’s proposal for re-using existing helm releases as dependencies Planning Issue Maharaja: Taylor Thomas Meeting moderator: Michelle Noorali Note taker: Matt Fisher / Matt Butcher Aug 17, 2017 Topics: Note taking Recording Helm Commandeer CircleCI/testing Automation of Homebrew, etc Volunteer for triage, note taking Taylor: • Helm comandeer Majiec: • e2e testing: basic framework for running and checking • Want to talk about CircleCI capacity for running these Fisher: • Issue triager for last week • Caught up on old untriaged issues Justin: • Closed a bunch of ancient issues • Little stuff like the manifest ordering patch Steve: • “Helm on Helm” to install Tiller via a chart • Issue queue managing Adnan: • 0.4.0 of Monocular released • New chart maintainer joined last week Lachie: • Azure installing Tiller by default, working on some similar RBAC stuff to Steve Michelle: • Community meeting with Karen Chu (MS) on organizing Helm Summit • Onboarding with Majiec Adam: • Release of 2.6 Butcher: • 2.6 stuff • Getting ready for 2.7 Ronan: • Documentation update run soon Note Taking and Recording: Where do we store notes? What do SIGs do? Google Doc for collaboration Rotating meeting leads and note taking every week is fine? Minutes will go in https://github.com/kubernetes-helm/community Next week’s… Meeting leader: Fisher Note taker: Michelle Issue Sherpa: Justin Recording: One of the SIG-Apps leads will record via Zoom Set up YouTube channel (Michelle) Each week, add link to the repo Helm Commandeer Adopt existing resources into a chart/release Use Case: Bootstrap cluster, install Tiller, then turn around and capture the bootstrapped resources as charts/resources Butcher/Scott: Capturing existing resources for already-deployed Kubernetes clusters Steve: Trimming out state information is painful. Might be nice to have a “spec” that an object can be imported into Majiec: Two arguments for doing this as a plugin instead: It can make use of Helm as libraries It forces improvements of the API Lachie: Concern is with starting to confuse what the “source of truth” is for features. Taylor: Okay, I do it as a plugin, with the goal of making it a “gold standard” plugin CircleCI/automation/etc Majiec: The discussion so far is that we are up to limits of CircleCI. But my own experience is that we have been able to run tests for about :30 in CircleCI. Maybe we still can run a Docker-in-Docker Kubernetes cluster Adam: I actually reserved you a dedicated e2e resource Scott: It would be great to be able to kick off building OS packages and have that trigger on releases, as an extension of release management. Fisher: Maybe you (Scott) and I can chat about that Lachie: Chart maintainers are also talking about that today Template Announcements Standup Discussion Assignments Issue Sherpa: Notes: Moderator: ``` ================================================ FILE: community/meeting-notes/2018.md ================================================ --- title: Helm Minutes for 2018 --- ```txt December 20, 2018 Announcements No meeting next week! Helm 3 repos working group, Wednesdays 8:30-9:00 am PST [link] Helm Hub is live! https://hub.helm.sh Helm 2.12.1 is out (decaf edition) Standup (kubecon was last week) Adam Giving update on Kubecon/Helm v3 The v3 talk was highly attended and engaged Matt Fisher Josh Matt Farina Michelle Scott Adnan Helm v3 Status https://github.com/helm/helm/projects/1 Tasks open for people to take on are tagged with “help wanted” In the past week we organized to update the details on the tasks Discussion Proposal for CRD Support We would like less intrusive changes to support CRDs Will CRDs become GA or overcome as TPRs were? Will look into patterns in current system that we could potentially use Helm 2 to 3 upgrade story A tool that can migrate from v2 config, as managed by tiller (configmaps/secrets), to the new v3 format Document what we need to do (proposal in community repo) Helm 3 repos update (Josh) TLDR; Helm charts will be able to be stored in an image registry https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/qYM84b0vays Assignments Issue Sherpa: Michelle Notes: Josh Moderator: Matt Farina December 6, 2018 Announcements Helm Deep Dive now 80 minutes (2 back to back time slots) at CloudNativeCon First half is the Helm 3 deep dive, second half is free-form discussion Helm 2.12.0-rc.2 has been released Standup Matt Fisher Working on the helm 2.12 release. Went through the PR queue to see if there are any fixes. RC2 has been release. Plan is to cut release over the next couple of days before KubeCon. Attending to the helm repository discussion Matt Farina Working on the hub to get launched Taking the charts in image repos to the OCI https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/U49AZRFo3tk Nikhil Back from paternity leave - just getting back into the swing of things. Josh Working on chartmuseum 0.8 with bearer auth support Continuing to moderate the helm repository discussion Now discussing with people at docker on the distribution API Brian Working on utilities on mapping Go values to Lua, deserializing back to YAML Adnan Working on the hub Post-kubecon, looking to add some CI to deploy to the helm hub repo Continuing development on monocular Justin Busy, hoping to help out with the issue queue/PR queue Taylor Helping fisher on the 2.12 release Want to have a discussion on adding contributors to help out on Helm 3 (onboarding) Michelle Putting together some slides on Helm 3, hub.helm.sh and Helm 2 for the KubeCon keynote update from Liz Helm v3 Status Adam has no voice/internet today, therefore no update this week Discussion: Taylor: on adding contributors to help out on Helm 3 (onboarding) Taylor: action item to talk to adam about discuss onboarding Some bugs that may need some love: 949, 990, 1098, 1168, 1193, 1237, 1354 Discussion: how do we want to handle long-standing issues that have gone stale? Farina: we should probably come up with a process for closing out issues to close an issue when it hasn’t been implemented in a given period of time from the community or the maintainers Action item: michelle will open a ticket for discussing the issue of closing long-standing feature requests How do we get proposals in? This process should be documented Action item: henry will open the issue to write up the docs Should we have another standup next week? Yes, one standup next week then cancel until the new year Assignments (for week after Kubecon - 20th ) Issue sherpa: matt, matt and michelle all working part-time Notes: (Nikhil can’t make this) Farina Moderator: taylor November 29, 2018 Announcements Recurring Helm 3 Repos discussion, Wednesdays 8am PST Standup Josh Setup weekly Helm 3 Repos discussion, Wednesdays 8am PST Had call #1, made some progress. Removing --version flag Keeping “helm repo add” Matt Farina Worked on Helm Intro slides for seattle Signed up for the project maintainers booth in seattle Matt Fisher Adam Helm v3 Status Helm repo stuff, not ready for Kubecon Requirements handling, cleanup. Merging arbitrary data. Pre-req for adding Lua to execution engine Discussion Fisher: Helm 2.12 release status 1 PR - feature flag to helm upgrade “--cleanup-on-fail” https://github.com/helm/helm/pull/4871 Needs few more reviews (Taylor + Fisher + ?) Can this make it in? https://github.com/helm/helm/pull/4709 (Jacob Legrone) Butcher: looks great Is there a plan for a helm contributors/maintainers social get-together, drinks (I volunteer to buy the first round!) at kubecon? [henrynash] CNCF booth? Microsoft Booth? Look for peoples hair MS Reactor event: https://open.microsoft.com/2018/11/21/microsoft-pre-kubecon-community-workshops/ Fixing bugs in v2 & v3 [mattfarina] For features - if they do not affect Helm 3, we consider merging If it solves for Helm 2 and 3, asking contributors if they are willing to add these things for Helm 3 Bugs - will be merged System wide plugins [mattfarina] SUSE wants to add this for envs that are unable to install plugins Can be handled by https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Adam: this is on Helm 3 project board , XDG configuration Given the increasing agenda length, if we are going to stick to a 30min call, maybe we should skip the Standup section? Alternatively do we need an hour call? [henrynash] Fisher: there was discussion on the cncf-helm-cartographers mailing list about everyone writing out their standup and dedicating the 30 minutes to discussion. If the standup topic requires input, it can be added to discussion items. Standup is good to give people chance to speak up, get people engaged Stef: comes to meeting to keep up with what were up to, also to be involved Technical-level discussions, fostering this type of community at SUSE Henry: Martin: just make standup shorter, main points in discussion Assignments Moderator: Josh Notes: Matt Fisher Issue Triage: Martin ^ may not have access to add labels etc November 22, 2018 Cancelled due to holidays November 15, 2018 ```yaml Announcements Brian is the bee’s knees: github.com/Azure/golua Because of Thanksgiving, this meeting will be skipped on Nov 22. Standup Josh Meeting on tuesday about the helm repo discussion, most people on the call are in favour as long as we can ensure that we have the resources to commit to that work Will send out an email to the CNCF mailing list Matt Fisher Been working on getting the helm 2.12 release out Michelle Trying to figure out two issues at the moment: the helm linter not linting subcharts as well as openshift SecurityContextConstraints (would love assistance on the latter) Brian Been working on golua as well as some debug facilities into the VM execution for the lua engine Spending the next few weeks focusing on the debugging library as well as panic traces in the lua VM Matt Butcher On the Helm 3 side, opening PRs on re-naming some of the commands Working on the Helm 3 conference stuff for KubeCon Seattle Attempting to make progress on a Helm 3 alpha release for KubeCon Seattle (tentative) 2 sessions for the core maintainers: intro and advanced sessions Working on a Helm Summit EU for spring 2019 Adnan Focusing on Monocular and kubeApps (butcher) are we planning on a KubeCon announcement for that one? (adnan) yeah, it’d be great to announce that in the intro (butcher) it might be getting a main stage annoucement Matt Farina We might be getting the main stage for KubeCon Working on a session for the Hub Issues triaging etc. Adam Reese Looking into integrating golua into Helm Mostly focusing on helm 3 Helm v3 Status Discussion Fixing bugs in v2 & v3 [mattfarina] What is the success criteria for going back to one issue triager? [bacongobbler] Will follow up in cncf-core-maintainers mailing list At what point can we reasonable close an issue for being stale/having no activity? From last week’s convo, we decided not to have a bot automatically close issues, but can we decide on a time limit that a triager can use. 6 months? 8 months? 1 year? [mnoorali] System wide plugins [mattfarina] https://github.com/helm/helm/pull/4871 [mattfarina] CRD lifecycle - Helm and deleting CRDs (doesn’t today) and CRD lifecycle [mattfarina] The crd-install hook only deals with the install lifecycle but there are open issues IRT CRDs with Helm. How should we approach this? Adam: we don’t do lifecycle management around CRDs because CRDs can be shared across multiple charts, so if we delete a CRD on a `helm delete`, then we could delete a CRD that could be dependent on other charts James: I agree, but with the introduction of the annotation, we’ve seen weird behaviour where if someone has created a CRD prior to a `helm install`, the CRD will get removed before being installed. We’re trying to figure out what we can do to make the situation better for istio/cert-controller Adam: I haven’t dug too deep into the CRD APIs, but perhaps an action item we can do is observe the behaviour how the Kubernetes API handles CRDs outside of Helm, and determine the expected behaviour? Perhaps even a few concrete use cases Mortent: would it be valuable to add a proposal for the solution in Helm 3? James and Adam: yeah, this might affect Helm 3 as well so if there are fixes that need to happen there we should get that in At IBM we have several hundred charts, and I hear this issue of CRD quite a lot - I’ll do a review and see if I can bring requirements to the table [henrynash] Given the increasing agenda length, if we are going to stick to a 30min call, maybe we should skip the Standup section? [henrynash] Adam: should we talk about this in 2 weeks at next standup? Henry - happy with that Given we are entering a period of large new features for helm, would it be beneficial to formally articulate/document how new features should be agreed for inclusion? Many open source projects have a spec repo (e.g.: https://github.com/openstack/keystone-specs), where the PR for a spec getting merged means that the feature and its architectural implementation is agreed. I guess our equivalent is the helm/community/proposals|helm-v3 ? However, it is not clear how such things really get accepted, what’s the threshold for sign off by maintainers etc. [henrynash] (let’s defer this to 2 weeks time) PR #4871? [farina & fisher] Adam: Let’s follow up offline Assignments Moderator: Fisher Notes: Josh Issue: Michelle & Fisher November 8, 2018 Announcements Because of Thanksgiving, this meeting will be skipped on Nov 22. Standup Matt Farina Specs repo, document how everything works Issue sherpa-ing this week, trying to bring down queue Changes to monocular to work w MongoDB over SSL, to support Helm Hub Matt Butcher SSL issue, CRLs not supported by GRPC/Go crypto libs (link?) Going away in Helm 3, so if somebody else wants to take it, go for it Formal specification for Helm 3 charts - to track what is and isnt supported Some parts of charts in Helm 2 are unclear/not documented Starting on Helm 3 CLI stuff soon Taylor Slide decks for Kubecon shanghai Ask taylor for help looking at PRs Michelle Reviewed old issues Parallel flag on Helm test, did testing (link?) More issue triage this week Josh Looking into a proposal that Steve put together involving repositories for v3 -> #55 Submitted another related proposal. Will talk about that in discussion. -> #57 Matt Fisher Issue triaging this week Primarily focused on PR queue Slating things for 2.12 RC release Adam Helm 3 CRDs Some PR reviews Adnan Working on Monocular w Farina Submitted PR to monocular to support Monocular chart still needs to allow Mongo params as secret vs. values Brian Stabilizing Lua VM Prototyping events code Helm v3 Status Project board: https://github.com/helm/helm/projects/1 Cards are being added linked to topics from the proposal in helm/community Will be converted to issues when people are ready Lua, charts format in progress Kubernetes-core removed as a dependency Discussion Helm v3 repository topics [jdolitsky] Community proposal #55 - merging helm repos and docker registries The basis of this proposal is for helm repositories to mimic the docker registry API more closely Looking on what is the right way to build it out further Jimmy: the problem I see is the backwards compatibility for the pre-existing repository system (referring to Helm 2 repositories) Fisher: the other issue comes in the form of OCI mediaType incompatibility (you can’t helm push quay.io/bacongobbler/helloworld and docker push quay.io/bacongobbler/helloworld) The quay implementation restricts repositories to a single mimetype to avoid this problem, but that has UX tradeoffs Follow-up: let’s set up a call to discuss this meeting (assigned to Josh Dolitsky) Community proposal #57 - Helm 3: push, login, capabilities api Assignments Moderator: Adam Notes: ? Issue: Michelle November 1, 2018 Announcements Josh and Scott are now Helm Org Maintainers [mattfarina] Standup Josh Working on chartmuseum 0.8 with token bearer auth support Worked on proposal with Azure folks on merging docker and helm repos Adam Last week in a company team offsite Matt Fisher In team offsite last week Doing triaging for v2.11.1 looking to see if we should patch release Michelle Responded to comments on helm test proposal (for v3) https://github.com/helm/community/pull/40 In team offsite last week Matt Butcher Team meetings last week Working on helm v3 command line argument changes Removed moniker naming Brian At team offsite Focused on Helm v3 lua integration Matt Farina Doing issue triaging last week Working on nested repositories for the Helm 3 proposals Taylor Writing slides for China and Helm deep dive Helm v3 Status Talked through the board When something in the proposal goes to being built we can: Convert existing cards to issues in the project When implementation happens we should add a link to an implementation issue where further details can be found in the proposal Discussion How can we handle the 500+ open issues? [mattfarina] Not going to add a stale issue closer yet but discussed Going to have multiple issue sherpas to bring the number down Issue #3943 - allow a fix for this in helm 2? [jdolitsky] This fix can go in as long as it’s opt-in and no APIs are changed in backward incompatible ways (including tiller api) Assignments Moderator: Matt Butcher Notes: Josh Dolitsky Issue: Matt Farina Matt Fisher October 25, 2018 Announcements Distributed charts repo search update via mailing list email Standup Josh Investigating helm login commands for different repository providers ChartMuseum has a PR for oracle storage backend Matt Farina Worked on some charts tooling Showcased helm repo audit Taylor Not much coding this week Prepping to talk in China about v3 Discussion Add weekly review of helm 3 github project to this meeting [Adam Reese] Issues needing some extra love: Potentially can try and close out: 4789, 4773 Need a response to: 4833, 4831, 4827, 4826, 4824, 4784, 4767, 4754, 4744, 4699, 4695, 4679, 4698, 4697, 4695, 4679 Assignments Moderator: Josh Notes: Matt Fisher Issue: Matt Farina October 18, 2018 Announcements No announcements for this week Standup Matt Farina Working on bringing back the PR sizing stuff Looking back on the hub stuff with adnan in the future Matt Fisher Not much to report this week Taylor Working on a talk for KubeCon Shanghai on an intro to Helm Also looking at doing a talk on a Helm 3 deep dive, also at KubeCon Shanghai Adam Started putting together a github project for Helm 3 work https://github.com/helm/helm/projects/1 Non-core maintainer standup Martin Hickey Dropped a few issues down in chat Issues potentially can try and close out: 4782, 4775, 4768, 4751, 4745, 4713, 4705, 4689 Issues need a response to (potential quick response): 4796, 4793, 4790, 4767, 4744, 4737, 4729, 4712, 4699, 4698, 4697, 4695, 4679 Discussion edX course… anyone interested in doing it? CNCF has $$ [Matt Farina] University-like material for education on Helm Taylor: I might be interested in it but not sure about the timeframe is on that Farina: let’s talk about this offline, but this opportunity just came up Should helm login support basic auth in addition to oauth? [Matt Farina] Adam: I’m not sure how difficult it’d be to add that in Farina: so we should probably support an oauth mechanism out of the box for now Helm container image? What base image (scratch, alpine, etc?) [Matt Farina] Tiller uses alpine, so we should probably re-use that Follow-up question: should we also push tiller images to quay/dockerhub? I think we’re at an acceptable time to push to both gcr and quay using CircleCI Linkerd2 has a different way to inject sidecars. How can we do this with Helm today? [Matt Farina] Adam: yeah, I don’t think we could accommodate this today, essentially linkerd2 needs to stream-edit the chart as it’s being applied Farina: could the event changes in Helm 3 help accommodate this? Adam: theoretically, yes Farina: perhaps it would be good to sit down with the linkerd folks Assignments Moderator: Taylor Notes: Farina Issue: Fisher October 11, 2018 Announcements Matt Butcher is the new chair of the org maintainers Standup Josh Looking into v2 repo index Challenges are that it is partitioned into multiple files Design work around things like nested chart directories needed Farina Working on getting the Hub site rolling Dco-labeler moved to charts AKS cluster Issues with AKS cluster Adnan Helm hub site Monocular 1.0 Cosmos DB Fisher Issue queue stuff Adam Have some PRs to go through, small changes, docs changes Out for a bit Focusing on helm 3 stuff tomorrow Kubernetes 1.12 merged Michelle Went through some PRs this morning 3805 and 1193 Brian Working on lua for Helm 3, continuing through the tests Notes and talking points for the use of Lua in Helm Justin A little issue triage Hoping to jump on some PRs soon Butcher Helm trademark move from Deis/MS to CNCF KubeCon Helm stuff Planning work on Helm Summit in the EU (spring next year) Discussion How can we better communicate around Helm v3 and let people help with it? [Matt Farina] [Henry Nash] Maybe at least add weekly item for an update on v3 development, calls for help, focus areas etc. ? Implementing index v2 Assignments Moderator: Adam Notes: Fisher Issue: Michelle October 4, 2018 Announcements Helm Org Maintainers vote link [Matt Butcher and Matt Farina] Standup Adnan Working on Monocular 1.0, migrating onto CircleCI because that’s what most teams are using it seems Josh In talks with the Azure Container Registry team in regards to API design Matt Farina Working on the hub site (hub.helm.sh) All the infra is there and ready (cert-manager, letsencrypt, ingress etc.) How do we store secret information? Want to chat about it today Matt Butcher Transferring the Helm trademark to the CNCF, working with the Microsoft lawyers for transferring the paperwork in time for KubeCon Working on the Helm 3 stuff with Adam and Brian Brian: working his way through implementing the Lua stdlib Vic I have been getting back into reviews on the charts repo. Matt Fisher Last week has been maintaining the issue queue, ensuring whether or not we need to do a v2.11.1 release Adam Last week has been focused on Helm 2 and Kubernetes 1.12 support Nothing ready to show yet, waiting on upstream to fix some things which should be coming out later today Non-core maintainers Martin Hickey Is it true that the Helm 3 codebase has been locked down to core maintainers? (adam) yeah, there’s a ton of refactoring going on in the core codebase, but there are a couple areas where help would be appreciated (documentation, testing infra possibly?) In terms of docs, what areas can we help? (adam) I’m currently looking at sharing some documentation around what’s changed, possible opening a github project to show what’s being worked on/what’s done/what’s in the backlog Markdown docs are stale in dev-v3, so updating the README or jumping into existing project work (docs site, CI infra, repository API working group) Discussion Encrypting secrets for sites and services [Matt Farina] Org maintainers - congrats! You are now responsible for the following [Josh]: Maintaining the mission, vision, values, and scope of the project What is it that Helm trying to solve? (mission) Where does Helm start and end? (scope) How will we get there? (vision) What do we need to embrace in order to succeed? (values) Refining the governance and charter as needed What can we do to make this process ultra-efficient? How do move fast and not break things? Making project level decisions How can we make sure people have necessary info in order to confidently vote? Which type of decisions are made at the subproject level? (eg. choice of CI, language, etc.) Resolving escalated project decisions when the subteam responsible is blocked What are the respective subteams? Who will be primary points of contact for each? Managing the Helm brand Websites, logos Documentation Tutorials and evangelism Twitter, social media, etc. ? Controlling access to Helm assets such as source repositories, hosting, project calendars Which tools will we use managing and sharing credentials? Handling code of conduct violations Violators will be publicly executed with a 2/3 vote Deciding what sub-groups are part of the Helm project Should this divide into more than just subprojects? (eg. testing committee) Overseeing the resolution and disclosure of security issues Majority of issues would related to Kubernetes in Helm 3 Does CNCF have a process in place for this? Managing financial decisions related to the project What types of things might cost money? How does being a CNCF project relate to this? Can companies or individuals contribute? How can we ensure that the direction of the project cannot be “bought”? Assignments Moderator: Josh Notes: Adnan Issue: Adam September 27, 2018 Announcements Helm 2.11 with Kubernetes 1.11 support was released Tomorrow is the last day for nominating Helm project maintainers Standup Adam On vacation last week Continued work on Helm 3 Started on Kubernetes 1.12 support Farina Working on getting the Hub cluster up and going Published a blog post on how to use chart-testing yourself! Moving bots under the helm org Butcher Provenance and crypto stuff Blog post for the Helm blog Staying on top of Helm 3 things Brian Get the lua implementation passing against the spec conformance test suite Issues around snapshotting values, ironed them out Continuing to wrap up lua implementation over the next few weeks Justin Issue triage, helped people close a few issues Adnan Monocular 1.0 close to cutting Working on moving the chart-repo and chartsvc to the Helm org, moving images to quay Fisher Going through Helm 2.11 release Ensuring RCs have been going through smoothly Stef SUSE working on a Helm mirror utility Discussion KubeCon Seattle Helm Talk Coordination [Matt Butcher] 3 talks: intro to Helm, draft, deep dive on Helm Reddit is going to talk about their story for getting into k8s, includes Helm Find out what Helm related talks will happen and put together a list in hackmd or somewhere Chart caching, using it, and content addressability https://github.com/helm/helm/issues/4618 [Matt Farina] Cache as-is doesn't work because could have same chart and version Use digest instead as cache key for Helm 2 Homebrew Helm problem Fixed and merged! Justin: Docs site search experience improvement Farina: Outstanding issue to move Helm docs out of tree to another repo Assignments Moderator: Adam Notes: Fisher Issue Sherpa: Justin September 20, 2018 Announcements Helm 2.11 RC4 released yesterday 1.11 Kubernetes support https://github.com/helm/helm/tree/v2.11.0-rc.4 Standup Justin Matt Butcher Putting together helm demos for ignite Brian Working on lua implementation Adam Values files stuff CRD, replacing secrets Tiller race conditions Michelle 2.11 release Matt Fisher 2.11 release Adnan Monocular 1.0 Cron jobs to sync chart repositories, more responsive Matt F Waiting for cluster, still being worked on Policy, workflow and tooling stuff for the Hub Docs for how to stand up a helm repo Chart-testing images now up on quay Josh Helm push and authentication Discussion Helm -push multiple provider support Something in index.yaml? Governance 1 week left for nominations, 9 people nominated and accepted 7 initial selection, but can have up to 9 https://gist.github.com/mattfarina/51056f5655dea3f0d60e20b37ccc79c2 Using Quay for chart testing https://quay.io/repository/helmpack/chart-testing Provides usage logs 2.11 official release date Bugs should be squashed Tuesday Sep 25th (unless explosions, Wed) Why Lua? Need to explain to users the reason for this Why not JS etc Write a post/doc that dives into depth Assignments Moderator: Matt Fisher Notes: Adnan Issue Sherpa: Justin September 13, 2018 Announcements Helm 2.11.0-rc.2 was released yesterday Helm Governance votes were complete last week Standup Michelle Issue triage Working on proposal for auto rollback feature Fisher Working on the Helm 2.11 release making sure that’s going through Adam Working on some of the Helm 3 design stuff with CRDs Out of town next week so will miss next week’s standup Matt Farina Working on the charts repository stuff, DCO labeling Throwing the charts-testing image on quay.io Working on putting a blog post on working with the charts-testing project Will be weighing in on the distributed search proposals Brian Working on the Lua VM implementation for Helm 3 Josh Closed a few ChartMuseum chart PRs Looking into authentication/authorization flow for Helm 3 Discussion Chart packaging system improvements (@gintas) Please see https://hackmd.io/Q8dyCyztRmW4_Xz9UFwuMQ Farina: what about the forking model? If you fork the chart and not change the ID (an implied change of this proposal), which cached version wins? You’ve got a non-reproducible cache pollution issue. The question becomes “how do we do caching/forking with this model?” We could run a hash on the chart and map it to that, perhaps Josh: hashing may be a problem with relative file path links in requirements.yaml (charts can change on disk) Farina: I’m not seeing what particular problems this proposal is trying to solve. Is there a human-readable write-up on the problem at-hand? Action item: reach out and follow up with @gintas on the core problem without trying to come up with a solution https://quay.io/helmpack/chart-testing/ is now public and we are archiving logs for long term via https://github.com/mattfarina/query-store-quay-logs (to be moved to the helm org after elections). But, only archiving aggregated stats (e.g., total pulls per day) rather than details because detailed as usernames mapped to IPs and other data. Thoughts? Fisher: does the CNCF have any policies/thoughts on statistics for CNCF projects (e.g. any policies that came out of devstats.cncf.io)? Farina: good question. I’ll follow up with them Adam and Matt: probably good to just track general trendlines rather than deep personal data on users. Josh: can we move the ChartMuseum image over to the quay repository? Farina: yeah! Travis Foster: hey, I’ve been looking into JSON parsers for Helm 3 https://github.com/helm/community/issues/49 Farina: thank you for taking a look into this! We’re looking for ways to looking into performance gains we can do with parsers so this is helpful. Assignments Moderator: Matt Farina Notes: Michelle Issue Sherpa: Matt Fisher September 6, 2018 Announcements Governance has enough votes to pass! Acceptance window closes today at 5 pm Pacific Standup Taylor At Open Source Summit last week 2.11 PRs this week Josh Exploring Helm login and authorization flows. Been talking to Matt Farina and some of the people on the Microsoft Containers team Adnan Merged the Monocular 1.0 proposal Matt Fisher At Open Source Summit last week Working on 2.11 PRs this week. Matt Farina Working on Governance this week Charts testing image work. Not going to put it on Docker Hub and going to put it on Quay instead. Going to write a tool to pull the logs from Quay and upload to storage Michelle Working on proposal for auto-rollback when releases fail Adam (vicariously through Michelle) Working on Helm 3 Discussion Helm 2.11 release 3 PRs left in the queue before we can cut a release, all ready to go: https://github.com/helm/helm/milestone/55 Should we pull https://github.com/helm/helm/pull/4468 off the milestone? (fisher) We are ok with pushing this off to 2.12 so we can hammer out some design issues. RE: PR #4590, was there a technical reason we use cmd.PersistentFlags() in certain commands vs cmd.Flags()? (fisher) PersistentFlags used so all subcommands can inherit the flag. Fisher is going to go back and change this for some of the new code “maven-like dependency system” for charts (josh via gintas) org.apache:kafka:1.0.0 -> ~/.helm/repository/org/kafka/1.0.0/kafka--1.0.0.tar.gz Possibly adding dependency caching Josh is going to work with a few others to create an issue on this (Henry Nash): As a newbie, have some questions about how the overall community works etc. IBM is starting to use Helm a lot and wanted to get involved Assignments Moderator: Josh Notes: Fisher Issue Sherpa: Michelle August 30, 2018 Announcements Switched to the DCO from the CLA Blog post here Standup Adnan PR’ed Monocular 1.0 proposal Matt Fisher At Open Source Summit NA Paired with Taylor around 2.11 release, triaging issues Brian Hardock Lua work for Helm 3.0 Michelle Working solution for Issues #3805 and #1193 Vic Worked with folks at Replicated Ship Their business is to ship software to vendors Did presentation at SIG Apps Worked on how to do customization around helm charts for different environments. “Last-mile customizations” Matt Farina DCO change + prep work for DCO change Follow up issues on charts automation Made changes to governance doc Matt Butcher Worked on governance docs with Farina Josh Giving a short talk on helm 3 in SF Adam Working on refactoring for Helm 3. Got a bunch of stuff merged. New API for dealing with charts and releases Setting up for Lua stuff Working on upgrade issue with Fisher and Michelle Discussion Estimating the Airspeed Velocity of an Unladen Swallow Bumped to next week Should we use something like https://github.com/ericchiang/k8s instead of client-go for helm v3? (Farina) Client-go has some well known pain points Butcher: is it still being maintained? Not sure Would it be practical to use an alternative client to client-go in helm 3? Butcher tried it. His findings: Pervasive change Eric made some really insightful changes but that create a somewhat cumbersome experience For example, pointer to all the fields This is the approach that apache thrift took To use this library, some things are more cumbersome for the user Some parts of the library didn’t feel 100% done Pros: dep ensure took like 5 seconds Adam: what is driving this? Farina: Making upgrades easier. This is the time to make breaking changes, so let’s entertain the idea. Adam: will take a look at it this week Docker Hub vs alternatives for public image distribution (Farina) On the charts side, we are going to distribute the chart testing library. Been thinking about where is the right place to store it and point people to. Went out on the email list Butcher: DOCKERHUB Quay will tell us if there are vulnerabilities Michelle: security is nice. Cool. Fisher: DockerHub seems to be ubiquitous Deis Workflow had a tough time trying to figure out metrics like image download count. Didn’t know if it was actually accurate. Metrics not a blocker if the discoverability is the primary driver for this. What is the best place to store images to get metrics? Metadata points in ACR but it’s not public so it’s not an option A wild Taylor appears in the meeting Is DCO required for a PR with a CLA that was submitted before the DCO took place? Should not be required. PRs are covered before Assignments Moderator: Michelle Notes: Taylor Sherpa: Fisher August 23, 2018 Announcements Standup Fisher Monitoring 2.10 release and making sure everything is going as planned Matt Butcher Issue sherpa for this week, nothing significant to report Working with Matt Farina on the governance proposal Talking with Brian and Adam on some of the Helm 3/Lua stuff Adam Continuing work on refactoring Helm 3, looking into breaking things into smaller chunks to move things upstream Merged Kubernetes 1.11 support into master and the dev-v3 branch Michelle Reviewing Helm PRs Re-named the helm-secure plugin to helm-rbac Taylor Doing some PR review work There is an open PR for recursive build option, code looks good but there may some eyes on it Asked Matt Farina if he can help take a look at it Adnan Working on a proposal for changes to Monocular Fisher Released helm v2.10.0 Scouring the issue queue to make sure there’s any issues where we may need to cut a v2.10.1, so far doesn’t look like there’s any Josh Traveling etc last week Working with helm repository authentication stuff Planning to add “helm push” API spec to specs repo soon Meeting w/ Zach (on Matt Farinas team) today about Chartmuseum bearer-auth PR and next steps. People have been asking for this more and more often. This will also tie into “helm login” proposal Giving a talk on Helm 3 next week.. What do I need to know? Going off of Matt Butcher’s post (https://sweetcode.io/a-first-look-at-the-helm-3-plan/) Chartmuseum website to launch possibly next week. Preview: https://codefresh-io.github.io/chartmuseum-www/ Matt Farina Working on the governance model as well as the switch to the DCO Justin Won’t be available for 3 days Someone at istio was being blocked with https://github.com/helm/helm/issues/3805 Adam: this would be a major breaking change to how Tiller works for Helm 2, but it could be a possibility for Helm 3 There are a ton of edge cases around the different merge strategies Farina: what about server-side apply? Adam: same problem, it would be a very large technical challenge to manage different upgrade strategies for Helm 2 Discussion Question: how does helm plan to address auto-generated configuration on `helm install`? E.g. autogenerated passwords in the postgres chart Farina: we should come up with a convention. Butcher: I would guess doing a pre-install hook to install a Configmap to autogenerate a password and place it in there DCO? Butcher: DCOs require all commits need to be signed? Adam and Farina: yes https://github.com/mattfarina/brigade-test-project/pull/1 https://github.com/probot/dco Farina: asking michelle if they can pair on this on Monday? Michelle: yes Helm v3 or hub: enforce or notify if immutability changed? Farina: if the digest changes, should we notify if someone broke This is referring to changing an existing chart in-place, not bumping the version Michelle in chat: then yes, we should put a warning in Adam: the one thing we may want to think about is when charts are in development. Farina: we could do a digest diff on a `helm repo update`? Farina: we should probably think this one through “helm login” - How do we envision this to work? Anybody interested in a call to address this in detail? Josh will put out an email to discuss this topic Butcher: can we start on the next Helm release since k8s 1.11 support is done and we have a few minor features committed already? Fisher: sure Butcher: there’s a lot of people asking for it, so we should cut an RC Taylor: we should go through the PR queue before we cut an RC as there’s been a few requests Assignments Moderator: adam Notes: michelle Sherpa: justin August 16, 2018 Announcements Slack is down, meeting link needs update. Standup Taylor PR work, with follow-ups today and tomorrow Matt Farina Chart PR queue reduced. Now below 400 DCO chart automation is a blocker to widespread DCO adoption. Distributed chart site is underway. Looking at hosting Link for this meeting is wrong in Helm repo README. Will fix. Butcher Main focus right now is on Helm governance, CNCF deadline is September Working with one of Microsoft’s engineers on a bug with `helm ls` Next week: continue to focus on governance and focus on next release for Helm Helm 3 related work (reporting for Adam): onto the Helm 3 loading and rendering logic In-memory tree structure is structured rather than flat Lua side (Brian): the core engine is about halfway there, working on Lua 5.3 support Matt Fisher Mostly issue queue and release management Should the issue go in RC4 or are we good to go with 2.10.0? Adnan Changes to Monocular with the hub stuff Nikhil Out last week. Getting back into things. Michelle Mainly responding to GitHub issues Will respond to comments on test proposal in the helm/community repo this week Josh PR out for ChartMuseum bearer auth Exploring approaches for values management Should we add ChartMuseum API for fetching/saving value sets? Allow for diff key-value backends (Consul, Vault) “helm config” plugin that works with API described above to fetch value sets and save the to .yaml file prior to helm install Going to get involved in specs repo as it relates to helm push, helm login ChartMuseum website coming soon - can we open source it under helm org? Demo Charthub (Paul Czarkowski) Easy way to host chart-repos using GitHub releases. [Adnan] may be interesting to use this as the base for the “github bot” Discussion Longer meeting? Should we start 30 min earlier? Are we letting meetings run long because we don’t do well time-boxing items, or do we just have a lot of agenda items. There seems to be more material to discuss. With Helm 3 and the hub, there is more “stuff” to discuss. Should https://github.com/helm/helm/pull/4473 be thrown into the release branch and cut rc.4, or cut v2.10.0 without it? [Taylor] would prefer to see a 2.10.1 with this fix in it [Fisher] would like to cut a 2.10.0 today Assignments Moderator: Farina Notes: Fisher Sherpa: Butcher August 9, 2018 Announcements Helm v2.10.0-rc.3 was released yesterday Standup Butcher Staying on top of issues Research for Helm v3 command line UX, PR in helm/community repo Suggested a few edits See doc for analysis Turning attention back to governance. There is a draft out there. Looking at Lua things Brian Hardock Building a Lua implementation for Helm v3 Focused on the virtual machine / interpreter for Lua and writing the backend Had conversations on design with Butcher Fisher Majority of work has been related to the release candidate Helm issue #1968 - meta issue on the build system and the infrastructure around it Moderate discussion on building helm for different architectures Continuing work on release candidate and watching for regression and going forward with that process Taylor Clearing out the PR queue as much as possible Continuing clearing out the PRs We are not currently accepting PRs against the helm3-dev branch There is a massive internal core refactor which is why we’re holding off on merging any PRs (Farina) Farina Kubernetes came out with recommended labels similar to our own and did a PR to update our docs with that Following up on governance related items Following up on charts Adnan Getting next release of KubeApps.com out Adam Heads down on refactor work for v3. Close to having the public API part down for helm v3. Watching for feedback on the PR for supporting kubernetes 1.11 work (Taylor) Doing more testing against AKS right now Vic Plugging back in Will work on Kubernetes 1.11 verification Working on figuring out how to ease use cases observed and pain points from helm 3 Michelle Reviewed a bunch of PRs, especially patches for release candidate PR’ed helm test plan/proposal for helm v3 Reviewing long term governance plan Josh Added Helm 3 proposal for helm push Trying to tackle repo authentication design w/ Farina and friends Helm-push plugin updates (Harbor project etc) CNCF Webinar w Stef! https://www.youtube.com/watch?v=u3VqswB-TJo&feature=youtu.be Discussion How are the changes/testing coming along for kubernetes 1.11 support? Where do we need more help? (michelle) Coming along well. Adam already updated. Please help if you can. Specs repo, helm push/login Clear specification for authentication and uploads by default ChartMuseum will be responsible for implementing this spec, but others can BYO-API How do we does the auths Will pull in JFrog and some other people for their experience (Matt Farina): Would like to get the specs repo moving. Being voted on now. Especially important for distributed search. Hub update? Is there any movement on putting forth a monocular instance to start the hub (Farina): yes there is movement Need to find location where it will be hosted CNCF has a bare metal as a service option Few other ways we can go between sponsored hosting from a company or through the CNCF Farina is chasing down funding Guidelines for inclusion What guidelines should be there to be included Reinhard (chart maintainer) is working on this CNCF will look at this as well Adnan will also help because Bitnami has experience in managing chart repositories There was an email sent out to the maintainers to figure out a name Adnan has been looking into resource requirements for hosting monocular Very little resources required Guides about creating your own repositories Started with how to host your repo on GitHub Key focus on documentation This is distributed search not proxying for repos First version will be a monocular instance and we will improve from there Assignments Issue Sherpa: Matt Fisher Notes: Josh Dolitsky Moderator: Taylor August 2, 2018 Announcements Helm RC2 was released earlier this week. RC Standup Nikhil Getting back from an internal all-hands Will be testing out the release candidates Adam Opened a PR for k8s 1.11 support, could use heavy testing. Testing different k8s versions with it. Wait testing. Anyone with cycles who could help will be appreciated Other Helm3 stuff Brian LUA stuff for Helm3 Fisher Making sure helm2 RCs are going through, move along the 2.10 cycle Paired with Adam for the k8s 1.11 support. Keep moving through the RC2 => RC3, but has already been approved, just needs merge. Justin Some issue triage this week Butcher On vacation last week Getting close on the Helm Governance Proposal -- should have something on the next couple of weeks. (deadline in Sept) Working with Ronan to get various helm accounts shifted over to CNCF Item on to-do list to figure out where to move our docker image to. Also an open issue on where to host our helm binaries. The crucial thing here is metrics -- we’d like to host it where we’d be able to get rich metrics around downloads. Need to co-operate with k8s here Adnan Working with Scott Rigby to figure out how to make standing up distributed chart repos as easy as possible. More on this soon Discussion Update strategy in helm v3. See issue #3805 (michelle) Adam’s been working a bit on a prototype to evaluate this. Pretty close to spiking it out, when he should have a better idea about this. `--strict` flag on `helm repo update` to return non-zero exit code on failure PR #4348 Release Helm 2.10.0 today after merging PR #4364? (fisher) Already discussed cutting an RC3 before doing a 2.10.0 Release without Adam’s patch for k8s 1.11. Doing so would break semver, so we shouldn’t do this. Proposal to port GoFish as a Helm 3 plugin manager (fisher) https://github.com/helm/community/blob/master/helm-v3/005-plugins.md Is the community repo the right place for this? Yes! When we have something in an issue queue that’s possibly a bug, currently we mark it as question/support. Can we have a new tag “Unconfirmed” where we can mark it as an unconfirmed bug, and then remove the tag? Yes https://github.com/kubernetes/kubernetes/labels/priority%2Fawaiting-more-evidence Helm v3 update: Ongoing work on the LUA engine Proposals in helm/community are flowing, will spend some time next couple of weeks going through them. No definitive ETA yet, but it would be nice to be able to show some of the newer features during KubeCon (Adnan) Vic is holding a discussion around last-mile customisations to charts in next Monday's SIG Apps call. Also Stefan Prodan from WeaveWorks will be demoing Helm git-ops. July 26, 2018 Announcements Finally finished move of all the helm repos to the Helm org Distributed search proposal passed with a majority of votes Voted Rimus (sp?) as an emeritus member Standup Butcher Issue sherpa trying to stay on top of issue queue Merged PRs -- were a couple of features Helm 3 design LUA stuff with Brian Adam Been working on getting the 1.11 kubernetes support ready Josh Been trying to keep up with email list Been a lot of activity around repo discussions: Taylor Vacation Working on PR stuff tomorrow Justin Was at vacation Getting back into the flow of things Farina: Need to figure out logistics of moving from CLA to DCO When we left k8s we lost auto-sizing, have been figuring out how to bring the sizing back. Chris is going to try and chase down how to use ProBot so that we can get some of this back. Working on update notifications -- how to tell folks that they have a helm update for them. Discussion Can folks (non core-maintainers) add/remove labels on the helm/helm repo right now? (michelle) Non-core shouldn’t have access to do this. There used to be a bot that we could use. The automation in place used to be able to allow folks to do this, but it was k8s specific. Helm proposals Installing custom plugin sets: (Taylor) Two thumbs up How do we do version handling? How do we discover the version. (Butcher) It might be good to not even handle versions for a first pass Helm v2 repositories https://github.com/helm/community/pull/27 Two file approach -- idea is to do this to improve performance so that we’re able to do a lazy fetch If you use a relative URL, don’t you lose context of the base URL? If you have it in more than one URL the relative URL works across http / https. Are we going to host keywords / maintainers from the current charts repo into the top-level file? How do we consider what is latest? (eg. 5.1.3 vs 5.1.4-alpha1). We might want to change it from “latest” to “stable” to address this Improved signing https://github.com/helm/community/pull/20 Generate GPG keys for you so that you can sign charts (default is on). Move closer to making verification a part of the helm repo experience. Main thing here is whether storing the public key is okay to store in the charts or not. We don’t need to take an external dependency on GPG -- go already has libs that we use (already in the code). Update notifications Stale issue automation Assignments Issue Sherpa: Justin Notes: Nikhil Moderator: Butcher July 19, 2018 Announcements Need helm doing some research into possible bugs from the issue queue. If you have time today, please reach out to Michelle Accelerated move to Helm org (github.com/helm/helm) Still having some CLA/CicleCI issues Seems like it might be an issue with CLA-Bot Standup: Discussion Governance Matt Farina's proposal for a new governance structure https://hackmd.io/s/B1BksVYW7# Bootstrapping process for project maintainer elections Still need to figure out how to do this fairly and equally Project maintainers need to be codebase maintainers A codebase maintainer may not want to/be suitable to be a project maintainer Codebase maintainers have skin in the game and care about the project direction Codebase maintainers don't need to be software engineers, Helm has a history of maintainers that didn't contribute software but have contributed in other ways Experience matters here, want ideas and psychology to bubble up to project maintainership Don't want to end up with top-down maintainership Sub-projects have a lot of freedom in adding maintainers - simple majority vote Action: Make it more explicit that codebase maintainers don't need to be software engineers Okay to have an even number of project maintainers for a short amount of time, if someone steps down before replacement found Maintainers only removed if they become unresponsive Bootstrapping project maintainers Different weights for different projects? Ghost period for code maintainers should be shorter? Set an upper limit, but let codebases choose lower limits if desired CNCF CoC - email contact in the CoC doc Better nomenclature for project & codebase maintainers - repo & org maintainers? Chartmuseum UI Orgs and Authz Assignments Issue Sherpa: Butcher Notes: Nikhil Moderator: Fisher July 12, 2018 Announcements Standup Taylor: Getting back into doing Helm stuff. Digging into PRs and notifications Then looking into Helm 3 stuff Adnan: Discussions around charts - especially distributed repository proposal. There were some ideas in the charts call this week which is recorded. More conversations with Scott Rigby Work with Kube CRD and Tiller Proxy Nikhil: Not much going on with Helm this last week Just touching base with issue comments and PRs Michelle: Knowledge transfer with Adam on the changes for k8s 1.11 Working on the proposal for what Helm tests should look like for Helm v3. Looking at issue queue for what people were requesting. Looking to get the proposal Brian: Fix the 1.10 RC for helm list, Looking into the TLS security support question. Turned out to be a documentation issue Farina: Notifications: Working on how we can notify people when new versions of Helm are out. Using mini-kube as a model for this. Verification work with the proxy (using kubeapps model). This is interesting especially with the multi-tiller approach that most people use. Lots of emails around governance Discussion Moving docs [Matt Farina] Docs repo? Currently docs live in the helm repo itself. Would be nice to add translation, etc. Keeping this in mind does it make sense to move docs to their own repo? Markdown vs Asciidoc: Conversation with a few other folks about this: Markdown is more popular, asciidoc is more technical? There are tools that can switch between the two. Example of kube-builder http://book.kubebuilder.io Nice to be able to do side-by-side code and docs. Built in i18n with gitbook [Taylor]: In support of moving the docs to own repo [Michelle] Helm v2 vs v3 docs -- will they live in the same repo in different directories? Docker compose does a good job of splitting out the docs for different versions. Gitbook vs other tool? https://github.com/kubernetes/helm/issues/4100 Multi-lingual K8s recommended labels. Do we switch? When? https://github.com/kubernetes/website/pull/8703 [Matt Farina] Helm has standard labels, almost one:one with the ones listed here, but having different names. What is the best way to proceed here? Adding annotations makes sense, but labels changes people’s deployments so the change is more intensive. Governance esp w.r.t related projects: Separation of concerns project maintainers vs. codebase maintainers CNCF projects are expected to follow standard set of CI / Automation practices. (https://bestpractices.coreinfrastructure.org/en) We will probably need to get to a certain state on this in the future. Assignments Issue sherpa: Michelle Notes: Adnan Meeting Moderator: Nikhil July 5, 2018 Announcements Devoting time to discussion, skipping standups Discussion Discussion on k8s 1.11 support for Helm Update on current state of k8s 1.11 backwards incompatibilities Generated Go code in k8s/k8s has been removed, making it unusable as a package: https://github.com/kubernetes/kubernetes/pull/62432 Removed the client-side reaper in favour of the server-side reaper. Because Helm prior releases, we need that for 1.10 support The entire factory/builder packages in kubernetes/kubernetes were rewritten and are totally different between 1.10 and 1.11 The printer was rewritten and requires significant refactoring Proposal (adam): due to backwards incompatibility and significant engineering effort, I propose Helm 2 only supports Kubernetes 1.10, punting k8s 1.11 to Helm 3 Another option: remove k8s/k8s as a dependency, and vendor the k8s 1.10 code directly into Helm 2 as a crutch Apparently service catalog has already gone with this approach Butcher: (giving some context on kube-lego and cert-manager) I don’t think we should go with solution 1. It puts our community in a bad position: Helm 3 isn’t ready, and Helm 2 would be in limbo Adam: ok, I can go take a look at forking kubernetes/kubernetes so we have the packages for handling backwards compatibility Farina: I’m going to take these issues up to SIG Architecture and SIG Release Michelle (in chat): you think we should bring this up in SIG apps and see what other tools might be struggling with changes from this kubernetes release? Farina: on the agenda for next SIG Apps Fisher: Do we want to have a strategy for communication with the community for this? Farina: Better to over-communicate than under. Adam: Go/no-go by end of the week. Farina: based on this we can craft some messaging to the community next week. Assignments Issue sherpa: Justin Notes: Nikhil Meeting Moderator: Michelle June 28, 2018 Announcements v2.10.0-rc.1 released Standup Justin: Issue Sherpaing Working on CRD issue Adam: Released v2.10.0-rc1 Still been working on some of the Helm 3 stuff Pairing with Brian on some things to help through some of the design choices Working on k8s 1.11 support into Helm, but it’s so vastly different than 1.10 so it was unable to make it into the release Brian: Paired with Adam, and I loved it! Josh: Nothing to report Adnan: Nothing to report Matt Fisher: On vacation last week Testing RC.1 Discussion Kubernetes v1.11 support Assignments: Issue sherpa: Justin Notes: Matt Fisher Meeting Moderator: Adam June 21, 2018 Announcements Standup Nikhil: Issue sherpa last week - support related things Talk about cutting a new release? Matt Farina: Migration to Helm org Michelle opened up an issue moving from CLA to DCO that needs follow up. Some work on index files and performance - splitting up files and moving to JSON could yield a lot of benefits so exploring those options. Upcoming v2 proposal spec around this. Adam: Out sick last week. Being pulled into other things since Butcher’s out. Helping with Helm 3 refactoring Fisher: Issue queue + triage Had a good session with Nik helping with Issue Sherpa handoff, and process regarding labels while sherpa’ing Josh Dolitsky Keeping up with all the stuff Matt Farina’s been posting with distributed search Wants a heads up on any CNCF stuff going on Farina mentioned about copyright headers Question: is there any hold-up on moving to the github org Farina: one hold-up is the Linux CLA bot hasn’t; once it’s fixed we can start moving over Adnan Been looking over the distributed search proposal and the application CRD Justin Scott Been heads down on internal projects, LGTM’d a few PRs Discussion Next helm release? Talk about cutting a helm 2.10 with the changes present in master K8s 1.11 client APIs broke a lot of things from initial testing Come up with an announcement on the helm-users mailing list on if we’re adding 1.11 support Helm 3 tickets There’s been a few tickets raised on Helm 3 topics; are we ready for these? Answer: no, redirect users to #helm-dev or the helm/community proposals at this point Things are expected to break (and break often); we’re not ready feedback until the first alpha release Zoom issues - people on hold? The meeting moderator now needed to allow folks explicitly into the meeting, and folks are on hold until the moderator allows them in Farina: Default k8s settings for zoom are changing to make things much more restrictive, and moderators need to explicitly let people in. This is around the push to stop bad actors, but meeting chairs need to keep an eye out for folks trying to join. It might be effective to have co-hosts so that we can have multiple people keeping an eye out to let people on hold to join in. Assignments: Issue sherpa: Justin Notes: Adam Meeting Moderator: Fisher June 14, 2018 Announcements Standup Fisher: Was at offsite last week Working mostly on Issue queue / PRs Fix for: https://github.com/kubernetes/helm/pull/4146 Adnan: Need to check out Helm v3, and got feedback on Helm CNCF move At DockerCon this week Nikhil Taking a look at the helm 3 branch, looking at particular the lua stuff Adam Out for last couple of weeks Looking into some pieces of helm that weren’t touched before (requirements) Need to look at treatment of Helm subcharts internally (needed for LUA) Butcher Pairing with Adam on the tech side for Helm v3 -- taking a deep pass through the lower code base before building the upper layers Will be out next couple of weeks (including at ContainerCon China) CNCF Helm transition is going well, but slowly -- turning over various properties (web, DNS, Twitter handle, etc). Put in place a provisional Helm governance model. Provisional governance structure is for 90 days until we can come up with something more formal and structured. Things that have moved over officially: Helm Charts Chart testing tools ChartMusuem Everyday conversation will stay in Kubernetes Slack. Will be running an article in https://sweetcode.io/ on Helm 3 Taylor Not much on Helm, mostly working on AKS GA Hope to jump back in after next couple of weeks Discussion How can we better manage issue triaging with the issue queue getting so large? Something that came up last week. Currently ~400 issues, ~90 open PRs. What’s our level of priority for issues / PRs coming in. 4 categories: Bugs, Support Tickets, Features, Whatever else? 59 open bugs (most are fairly low pri), but there are a couple of high pri ones Thought is: make handling bugs as P1 for issue sherpas since it’s hard to focus on everything. (Adam) Another idea: talk about high-pri bugs during meeting. Charts distributed repo proposal - please leave feedback https://github.com/kubernetes-helm/community/pull/24 Assignments Issue sherpa: Nikhil Notes: Fisher Meeting moderator: Adnan June 7, 2018 Announcements Standup Taylor: Not much this week Discovered issue with --wait Nikhil Issue sherpa, spent some time on some issues and looked into a few PRs Adnan Plan to take a look at the Helm v3 branch, and the canary Not much else apart from that Discussion Stef: Issue with “Connection Reset” caused by difference of versions between Helm and Tiller Assignments Notes: Taylor Meeting Moderator: Nikhil Issue Sherpa: Fisher May 31, 2018 Announcements Standup Matt Fisher Issue triage + PR Some windows related stuff Brian Nothing to report Taylor Trying to make time to fix the helm wait stuff Justin Nothing to report Nikhil Started pulling down on the dev-v3 branch and making his way through the branch to see what’s changed Adnan Interested to see what’s going on in the dev-v3 branch, otherwise working on other work Matt Farina Worked on the helm proposal to the CNCF, fair amount of discussion going on in that PR. Discussion is still ongoing The community charts sync broke due to a breaking change in the system Fixed by using CircleCI rather than Jenkins thanks with help by Adnan Discussion: Folks are in summer mode! Not much tabled to discuss this week. Assignments Moderator: Taylor Thomas Issue Sherpa: Nikhil Note taking: Matt Fisher May 24, 2018 Announcements Helm and CNCF [Matt Farina] After last week’s incident, we are going to be stricter with how we can handle this in the k8s community. Sorry to all about last week’s incident, but we should now be in a better place to handle something like this if it happens on a CNCF community call again. Standup Taylor: Not much, mostly working on the wait-flag stuff Might be busy over the next couple of weeks Adam Working on Helm 3 stuff Trying to split up the tight coupling of templating and resources Next week on vacation Nikhil Mostly out last week, getting back into the swing of things this week Butcher PR on the LUA stuff for Helm 3 (Core event handler) Talked with Adam about things like helm install which has grown organically -- so we need to do a little ‘topiary’. Jdolitsky Managed Helm Repos We also now have auth for ChartMuseum using a bearer-token in the header Worked on helm-push/helm-login/performance of index.yaml Farina Happy to take on the proposal of the index.yaml Starting to poke at i18n, filed a few issues against doc, i18n, etc. Looking into finding a framework to do the translation. Fisher Mostly on vacation last week - got back this week Hoping to take a look at Helm3 discussions and get involved with that this week Discussion (Taylor) Wait-flag returning true if the app can’t start. Not sure if it’s worth it to keep the --wait flag around. Want to get input from community, and maintainers on whether it is a good idea to remove this. (Farina) On the community charts side, they had to write their own solution, but something like the wait flag is a better solution. Do understand the brittle nature of it, but it is useful. (Adam) There is a effort upstream that we might be able to piggy-back on (https://github.com/kubernetes/kubernetes/pull/64034) -- so we might be able to leverage some of that. Maybe we should review what’s going on there, and get caught up on discussions. (Fisher) What’s the status of wait flag on v1? (Farina) There’s a storage bug that’s preventing old API versions from being removed. Hopefully that will be solved so that we don’t need to support older versions of the API / deployments? Probably a good idea to see in what direction the upstream effort is going before making an informed call here. Josh Demo https://github.com/chartmuseum/helm-push Assignments Issue Maharaj Butcher Notes Fisher Meeting Moderator Nikhil May 17, 2018 Announcements Helm and CNCF [Matt Farina] Standup Taylor Debug --wait flag Opened PR for release process Nikhil Issue sherpa duty Fisher Vacation Defining first issues with Farina Adam Helm3 refactoring Review PR’s Michelle Review PR’s Butcher: Vacation PR reviews with Adam PR for CRD support in helm2 Farina Looking into making chart repo more distributed Language support for helm Demo Josh with Chartmuseum Discussion Kubernetes Apps Survey Results for Helm [Matt Farina] Issues with the wait flag [Taylor] Assignments Issue/PR sherpa: Michelle Notes Nikhil Meeting Moderator Fisher May 10, 2018 Announcements 3.0 dev branch is sorta open but in code cleanup phase Codefresh just announced managed Helm repos -- awesome! Standup Nikhil Has not done much in the last week Volunteered to do issue/pr sherpa Reviewed oauth work with Josh Adam Holding fort when folks were at KubeCon Focusing on Helm3 stuff with refactoring Farina Digging into the charts craziness Almost 300 open PRs Added a discussion topic to figure out how we can manage some of this craziness Hope to chat with Josh and present a PR to help with this Butcher Picked up some of the Issue Sherpa this week At KubeCon -- spoke to a few Chart maintainers to talk about some of the alternatives to what we have currently. Propose people interested in this problem, meet up during Chart Office Hours (next week on Tuesday?) Open PRs for CRDs that needs reviews -- might need to pair with someone Has a POC for LUA scripting for Helm v3 Taylor Proposal idea for how we want to do releases Looking into PR templates / Issue Templates Discussion Proposal idea for how we want to do releases [JTT] The dev call after the release is the next (bootstrap) call for the next release. Each dev call have a 5/10 minute discussion for features where we discuss whether we pull merged PRs into the next release of a later release. Is this adding unnecessary process which will be overhead for us? Taylor will write up the process and make a PR to Helm to kick off more discussion for next week. Distributed charts vs central hosting vs a combo [Matt Farina] Charts Office Hours are at 9am PST 10 am Mountain on Tuesdays Whole lot of work to curate charts and get people to curate charts and maintain. People tend to get burnt out. So the central repo model doesn’t really scale that well. PHP packages have distributed hosting -- can we have some sort of distributed mechanism to do a similar thing for charts that is distributed, but has a central discovery -- so central metadata, with the actual charts living off in a different location. More discussion next week That _is_ a different project, so technically they would make a decision on this, but we should weigh-in during Charts office hours Assignments Issue/PR sherpa: Nikhil Notes: Adam Meeting Moderator: Taylor May 4, 2018 Canceled due to KubeCon April 26, 2018 [recording] Announcements Helm 2.9.0-rc5 was released last afternoon Helm dev call canceled for next week Standup Adam Been doing work on Helm 3 refactoring, pulling out gRPC and old commands we had Paired with Fisher on some bugs for the Helm 2 release and issues upon request Taylor Haven’t done much, switched over to Microsoft so have been onboarding onto his team over there Matt Farina Been looking onto the community charts scalability problem Looking into chart repository scalability issues, like switching to JSON for index files Might have stronger opinions after KubeCon Matt Butcher Been issue sherpa this week, triaging issues for Helm 2 Pairing with Adam on Helm 3 stuff Automated helm.sh and docs.helm.sh this week Have a couple items to work on for the Helm 3 spec doc while in Copenhagen Justin Scott Issue triaging Identified an issue around import-values, will look further into the ticket Michelle Been travelling this week Matt Fisher Been cutting release candidates as needed this week Want to cut a 2.9.0 by the end of this week, but we should probably discuss this Demo Josh with push to chartmuseum Discussion Helm material from Kubernetes Apps Survey More Helm Maintainers for the issue queue? Should we cut Helm 2.9.0 prior to KubeCon? Testing coverage (Adam) Assignments Issue Sherpa Adam Reese, party of 1 PR Sherpas Adam Reese, party of 1 Notes Matt Farina (for the week after KubeCon) Moderator Matt Fisher (for the week after KubeCon) April 19, 2018 [recording] Announcements Application survey date extended until Monday - https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform Standup Michelle Issue sherpaing and fixing bugs Matt Fisher Worked on fixing bugs There’s a PR to add flags to pkg that was merged and then reverted because it broke compatibility Working on getting RC4 out and fixing bugs to do that Nikhil Didn’t do much Helm related this week Farina Not much directly related with Helm If anyone wants to work on Dashboard (SIG-UI), they’re looking for folks (Currently Angular 1 with PR to update it). Low barrier to entry. Butcher Reviewing PRs for Helm 2 One PR open on spec for Helm 3 around on security Going to proposes changes to where releases are stored Adam A few patches in for the RCs Working on Helm 3 looking to factor out gRPC and remove tiller binary Looking for feature parity with a single binary Brian Paired with Adam on helm 3 refactor Josh Dolitsky Built a plugin for chartmuseum push Discussion Issue Sherpa’ing with a second person was really good -- maybe we should institute a buddy system When do we open up ‘the branch’ (referring to v3 branch)? Few things to consider - How to handle feature requests coming in. Bugfixes, do we need to cherry-pick bugfixes into both? How do we deal with this since it looks pretty different (eg. no longer protobufs, no longer generated code, etc) How / when do we define a freeze for Helm v2 features? Lots of folks still using Helm 2 (Fisher) Maybe have a window (of a couple weeks or so) where we allow features for Helm 2, after which we only allow features in Helm 3. (Farina) Maybe have a cutoff date which we tell contributors about? (Michelle) Some folks might want to continue with Helm v2 and not Helm v3. Adam is pointing out concern for the end user vs concern for contributors. Michelle is in favor of a helm 2 feature freeze date. Will use labels to track incoming features to make sure they get mapped to helm 3 “1. Window for getting in feature requests before the v3 requirement 2. Labeling features in Helm 2 that we need to forward-port, so we can track those” Issue sherpas can respond to Helm 3 branch PR requests appropriately. Let’s schedule Josh’s demo for next week, for lack of time. Assignments Issue Sherpa: Matt Butcher PR Sherpas: Notes: Fisher Moderator: Michelle Noorali April 12, 2018 [recording] Announcements Application Survey https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform All results will be publicly available Standup Taylor Reviewing PRs Still need some help reviewing PRs Justin Put some labels on issues Matt Fisher Working on release Influx of stuff coming in which is great because we’re getting feedback on release candidates Issue sherpa - aggressively closing issues Common issues with bare metal clusters. Maybe there is something address in upstream Kubernetes documentation Still triaging issues for bugs related to RC Matt Butcher Operating Kubernetes clusters with aid from hat Some light reviewing on PRs Added to Helm 3 proposal some things about strengthening signature verifications. Make sane security defaults for signatures. Will make repositories do some leg work to set up signing/security. Adam Reese Sick. Working on PoC work around Helm 3 proposal. Looking at how to refactor out some gRPC stuff to make easier transition to client only architecture Michelle Following up on issues Sent request in for Brian Hardock Not too much Matt Farina Comparing memory allocation of YAML/JSON parsers TLDR; we’re using the worst. Will post result Might be worthwhile looking at a better YAML parser TLDR from chat; Matt Farina is a nerd and everyone loves it Josh Dolitsky JWT validation in chart museum working Helm push plugin working on oauth flow Discussion RC 4 from master? (Fisher) Lots of activity has happened since the release of the first 2.9.0 RC There’s a lot of features released in there Should we cut from master with changes included and features or should we continue to cherry-pick? Adam: let’s follow semver Matt Farina: we have lots of silent users so let’s now throw them off Michelle: Agree with Adam and cool with doing a quick 2.10 release with new features Taylor: If people want the latest, they can use canary In agreement on how to go forward. Cherry-pick and no new features. Action Item: Let’s make that clearer in documentation either in FAQ or CONTRIBUTING.md Assignments Issue Sherpa: Michelle Noorali PR Sherpas: Matt Fisher part-time sherpas Matt Butcher Taylor Thomas Adam Reese Notes: Matt Farina Moderator: Adam Reese April 5, 2018 Announcements The AppDef WG has put out a survey at https://docs.google.com/forms/d/e/1FAIpQLSeetP_EnzMjAayR73sbpHDtfxnAzT6Y0wzCCvrP4C1uLa1u0Q/viewform Helm 2.9.0 rc1 and rc2 were released this week (thanks Farina and Fisher!). The notification Standup Taylor PRs this week -- trying to get stuff merged We now have a release branch, so we don’t need to wait for the RC cycle to be done Michelle Was issue sherpa this week, mostly just triaging issues and fixing bugs Have several items for discussion at the end of this call Nikhil Couple good convos with Josh on ChartMuseum auth stuff Adnan Pass Fisher Triaging issues, helping out with release Couple of bugs with the release checklist. Opened an issue yesterday to look into. If there is an issue that needs to be picked into a release, please use the ‘needs-pick’ tag where x is the release. Josh New chartmuseum release this week. 0.5.1 which lets you serve multiple chartmuseum repos Putting together notes on helm push as next steps Discussion How do we respond to semver issues like this (Michelle) If you use the kubeversion field and you have a constraint like >=1.8.0 this becomes incompatible with GKE’s versioning. How do we respond / have we responded to these kinds of issues in the past. One of the solutions was to add something like -r0 and making it pre-release (Farina might know more about this option -- this might be something that CoreOS/Rancher do) There are over 300 open issues and over 80 open PRs. Should we do a week or two of having two sherpas to help clean out the backlog after 2.9.0 goes out? (Michelle) (Taylor) Issues might not be much of a problem -- but we should definitely look into getting people to jump on and close PRs. The issue queue tends to self manage especially with fetja-bot and us noticing when things go stale. (Fisher) It would be nice to make the community a bit more self-sustainable. Fully agree with prioritizing PRs over issue queue. (Michelle) Do we want to have a dedicated person looking at PRs? Taylor volunteered, but was decided not to make it a formal role just yet. Vote on combined maintainers mailing list here (Michelle) Two options right now (suggestions welcome!): charts-and-helm-maintainers@lists.cncf.io helm-cartographers@lists.cncf.io (Adnan) Discussion on charts collecting analytics - https://github.com/kubernetes/charts/issues/4697 Heads up that this discussion is happening - folks interested please join in at the next charts call where this will probably come up. (Fisher) One considerations is that Helm install doesn’t have a really good way of notifying the users that some analytics are being enabled -- this is especially true especially in the case of dependent charts. (Adnan) The dependency chart might be a problem since the parent chart could set the on/off flag and users might not necessarily know about it. (Fisher) It would be nice to make it blatantly obvious that we were turning on analytics (eg. homebrew, etc.). (Kensey) CoreOS has one flag for all projects to turn off analytics -- would be good to standardize Assignments Issue Sherpa: Matt Fisher PR Sherpas: Taylor Nikhil Notes: Michelle Moderator: Taylor March 29, 2018 Announcements Bacongobbler: Adam, Michelle, Fisher tested Kubernetes 1.10, so it is merged. When should we cut the Helm 2.9 release? Standup Adam: I am going to miss standup, my 2 updates: merged kube 1.10 support and worked on a POC of the helm3 ext model. As always, dont trust anything @mattfarina says about me Michelle: Testing of 1.10 Investigating another issue #3655 Nik: Looking at Docker Registry token format for registry planning for Chart Museum Investigating how PIP/pypy do things (and launchpad) Justin: Helm issue queue triaging Butcher Helm v3 work + prototyping with Adam Embedding LUA, eliminating grpc -- get clear on some of the areas for the Helm v3 proposal Taylor Working on a few PRs this week Matt Farina Helm Survey for end users Adnan Charts work on owners/maintainers Check if any chart maintainers want to go emeritus Brian Hardock Fix on Helm List due to gRPC threshold, working on tests now Matt Fisher Testing 1.10 and issue triaging Also a little Lua experimentation just to get comfortable with embedding Lua in Go Discussion What do we want to name the mailing list for both charts maintainers and helm maintainers? Is it public or private? [Michelle] Think about this one, we can decide further next week. CNCF landscape [Matt Farina] Uploaders for Plugins [Josh D] How to implement ‘helm push’ Farina: I was thinking of doing it over http/https downloaders, so that plugins can implement custom push uploaders. Josh: See #18 on the community repo, which could also provide indexers to tackle search scale issues, maybe others. Farina: Some survey questions are relevant to this. I’d like to keep push and index separate so that we might be able to do push in Helm 2. Index is more complex/debatable. Josh: Maybe make chart museum method the default, and allow plugins to override Fisher: jFrog is also interested, maybe in basic auth because that’s the only available kind Farina: Maybe we should ship with oauth support and token auth too Josh: What if we don’t have a default implementation? Call for next Monday after sig apps: https://calendar.google.com/event?action=TEMPLATE&tmeid=NDA3a2NsbzlxaWdpcnNuMm41NzNsdnFqaDggY29kZWZyZXNoLmlvX3BmbmlqajVrbjFmYzhqMnJtMXYwbWJoaTIwQGc&tmsrc=codefresh.io_pfnijj5kn1fc8j2rm1v0mbhi20%40group.calendar.google.com TODO: Schedule call -- Josh Dolitsky Branch naming for Helm 3 [Butcher] Tentative plan is to have a place for Helm v3 code to land prior to KubeCon EU (beginning of May). We had some ideas on how we want to branch for v3. Farina and Butcher looked at data and found a substantial amount of folks cloning helm master. Normal weekday 150 - 180 unique cloners. Points to not breaking master and leaving as is. => v3 code should live in a different branch. ‘v3’ is as good a name as any for the branch name. Farina: We should think about how the branch name plays with dependency management tools like glide, dep, etc. Butcher: Maybe we should do something like dev-v3. Lots of suggestions for branch names in the chat -- seems that there was some consensus on dev-v3. Butcher will send a message out to the https://lists.cncf.io/g/cncf-kubernetes-helm list. Assignments Issue Sherpa: Michelle Noorali Notes: Nikhil Moderator: Taylor March 22, 2018 Announcements Helm v3 discussions are making progress. Standup Adam: Been working on 1.10 support for Helm. This is now tested. Worked on vetting LUA models with Butcher. Fisher: Pushing through the JFrog remote authentication support for Helm -- that’s done. Mostly issue triage in addition to that Taylor: Was a bit busy this week. Will take on some more PRs from the PR queue this week -- keep an eye out for reviews especially on mediums and larges. Going to start trying to look at Justin Been pretty busy, so mostly been some issue triaging. Maybe talk about some regressions that have been creeping up with Helm. Butcher Mostly focused on Helm 3 Broke the document out into smaller proposals Backed out format for chart.yaml -- going to just use the application CRD format so there is less of a learning curve for Helm 3 users Also been vetting ideas around the LUA extension model -- vetted the loading process, runtime startup, and being able to embed into k8s objects. Cleared the way to say LUA would be the scripting language. Also simplified the event model this week. Will keep working at that this week. Farina Some more of the Helm 3 stuff Working on charts -- merged a couple of features upstream wrt better validation of files, linting, etc. Nikhil Moved ChartMuseum to dep Looked at a few PRs and the issue queue. Plan to work on some of the repo auth pieces this next week. Discussion (Josh) Helm repo proposal: https://github.com/kubernetes-helm/community/pull/18 https://github.com/jdolitsky/community/blob/ebf12b58dec108f85c582369d937100d591f7cdc/helm-v3/006-repositories.md Methods for authentication -- suggestion to add a helm config for authentication (Fisher) Have we looked at different authentication models eg. pypi authentication for pip packages? Another thing to think about is being able to auth against different repos. This has ramifications on helm search -- you would not be able to search against multiple repos. Do you do search locally, or do you do search against service providers? This changes the UX in subtle ways since you need to be able to search against certain repos. It would be good to know how people are actually using helm search. This has similarities with search with pypi -- might be useful to take a look at them too. During the transition between Helm v2 and v3, it’s really important to be able to search through existing charts and retain backwards compatibility with them. (Farina) Do we have concrete requirements from users? Should we go out to users and poll for requirements -- what are the differences in requirements between startups / enterprises. (Michael Hrivnak -- Welcome!): There is a tremendous amount of value to be had to not requiring a separate service for repositories. Also for enterprise users, they will require content on site. So anything we can do to help with that will be useful. (Josh) Demo for ChartMuseum multi-tenancy Assignments Issue Sherpa: Justin Notes: Butcher Moderator: Fisher March 15, 2018 Announcements We had a v2.8.2 release go out last week Standup Matt Fisher Helm issue queue stuff Got a repro for a Helm rollback issue that he’s helping to track down Nikhil Spent time looking through the Helm 3 proposal Helm issue queue stuff Matt Farina Working on the Helm 3 User Stories and User Profile docs Adnan Reviewing the Helm 3 proposal, user stories Taylor Issue sherpa for this week Question about --reuse-values and its intended behaviour https://github.com/kubernetes/helm/issues/3685 Justin Out for a week travelling Taking a look at the Helm 3 proposal Matt Butcher Merged stuff on emeritus core maintainers Addressing comments on the Helm 3 proposal, moving progress along Plan for the next week is to help move the Helm 3 stuff along Kensey asked https://github.com/kubernetes/charts/issues/4067 for best practices on networking best practices Discussion Matt Farina brought up the Helm 3 user stories, saying this is an initial set of user stories to give us direction for whom and for what reasons to help drive Helm 3 Helm 3 Proposal https://hackmd.io/YvQCGazPRNanSugJV-rbSg Proposing a client-only model, tiller is gone Internally, Helm will be restructured around events Adam mentions notes about Lua Lua is the easiest to embed Brian Grant asks if they’ve looked at alternatives like Skylark Have not looked at Skylark, but they’ve looked at Javascript and found some limitations with regards to constantly catching up with ECMA 6 spec, whereas Lua was designed for embedding One appendix is to propose using the Lua engine for Helm plugins Include a `helm push` verb to push helm charts to a repository Talking to Josh Dolitsky and the ChartMuseum team on defining the spec for `helm push` Farina notes there’s a lot of proposals also in the Helm issue queue. They’re not noted in the proposal, but they are not being discarded Next steps: how to break this up into sizeable chunks/proposals Throw in a milestone? Move it to issues? Dump into enhancement proposals/documentation? Brian asks whether development would happen in the main helm repo Lazy consensus says yes, we should have a 2.x mainline branch and run Helm 3 development on master Matt Butcher will publish the Helm 3 proposal in the community repository Josh added multi-tenancy to ChartMuseum! Not ready for primetime, but available for preview Assignments Issue Sherpa: Matt Fisher Notes: Nikhil Moderator: Matt Butcher March 8, 2018 Announcements Adam and Butcher have been working on a proposal for Helm 3. Should be ready by next week, when we can discuss it. Taylor has seen a sneak preview. Taylor gave a brief des Standup Taylor: Going over the Helm 3 proposal stuff Blog post about the Helm Summit Will have more time this week for PRs + issues. Nikhil Doing some investigation on how OAuth works so he can propose ideas to chartmuseum and other chart repository work Spent some time responding to Issues Michelle Was at the OSLS for the last few days Working on fetja bot Need to revisit who should join which mailing list -- maybe create a different ML for the chart maintainers. Added Matt admins to the ML. Fisher Last week worked hard on reviewing PRs Moving forward on discussions on the upgrade bug, and helm init --wait. After discussions with Bryan, Adam, etc came up with solutions that were a lot cleaner that made use of grpc solutions (cool!) This week, want to pair with Adam on some of the PRs already in the pipeline. Ronan and Fisher are working on the docs.sh documentation site which is on an old Deis site, trying to move it over to Azure resources. Laptop under someone’s desk => Cloud. Farina: Working on getting documentation from the summit together The user profiles have now been documented at https://github.com/kubernetes-helm/community/blob/master/user-profiles.md Working on proposing other documentation from the summit. Poking at the Helm v3 proposal as well. Adam Was issue sherpa this week. Thanks to others who jumped in on that. Also worked on the v3 proposal. Tried to collect all the requirements from the Helm summit and work off of that. Polished that up and put it into documentation based on which we can have a meaningful discussion about. “Too much change could be a bad thing” -- Helm is kicking off, and we might not want to disrupt much. (Something to keep in mind). Will be pairing to review a couple of hot PRs with Fisher. Brian Pairing with Fisher on the Helm wait stuff with the ping using proto health check specification Discussion Templating in values.yaml file (see #1978, #2133, #2492, #3252, and https://image.ibb.co/k9Xo07/tpl.png) Folks would like to go down the road of being able to templatize values.yaml files. Is there a way of going about doing something like that? Is there a primary use-case for this? The use-cases are documented in the multiple open issues. Adam: Maybe comes across as an anti-pattern with One solid use case: Ability to pass the name of a parent chart to a child chart. Does it make sense to solve this use case without templatizing values.yaml? Other use case: Want to be able to set a value in values.yaml and use that over and over again, later on. Taylor: Maybe implement this as an alpha feature (as a plugin): if a lot of people use it and find value, maybe move forward then since that may be something that the community wants. Fisher: Two problems: There are no standard go libs for this. Also in this case people want to render values files before sending to helm. Can we use a plugin to solve some of this (at least initially?) Adam: It might be possible to get the info in there (eg. parent chart) in a more structured way, rather than by having to templatize values files -- the latter would likely end up with debugging FSM nightmares. Next steps: read through the issues, to understand the use cases before we can have a deeper discussion next week. Farina will reach out to rheinhardt to get a better idea for use-cases. Reconnect to tiller on transport error (TODO: issue number -- Farina will follow up) There are cases where the connection to tiller gets broken. Experiencing this on chart CI and is an outstanding issue. Suggestion: helm and tiller support a connection via a service that’s created. With CI, it’s good to set up a service and point helm to that service -- you can also use a global portforward. This might be worth looking into for CI. Default helm init might already do this -- something to check. Another option could be to keep the tunnel open. Does grpc have an auto-reconnect that we can use? We see the error in less than a minute on the CI tests so it’s not very long. E2e tests (see #2846) Adam will take it over -- has already rebased it. A few more things to clean up. Initial rebase (#3636) Index.yaml v2 proposal (#3557) Farina: Can we get more eyeballs on this? This goes hand-in-hand with the scaling discussion for chart repositories. Has implications on the growing size of the community charts repositories. We will try and cover this a bit more during the next meeting. ChartMuseum OAuth discussion: https://github.com/kubernetes-helm/chartmuseum/issues/59 Assignments Issue Sherpa: Taylor with Michelle as assistant to the regional sherpa! :) Notes: Fisher Moderator: Adam March 1, 2018 Announcements Helm Summit was awesome last week; nice job everyone! Thanks to Fisher for closing a massive amount of PRs Standup Fisher: Post summit stuff Reviewing blog post with Taylor Follow up with Karen (Microsoft) on post-summit feedback email Looked at an merged a whole bunch of PRs (Thanks Fisher!) This week: More PRs + Follow up on Helm 3 discussions, and next steps from notes from the Summit Taylor: Distilling requirements for Helm 3 from unconference discussions Should discuss these requirements in a follow-up meeting Nikhil: Issue sherpa’ing this week Post Helm 3 discussions with josh Dolitsky on ChartMuseum multi-tenancy stuff, feedback Will have a follow-up discussion with Josh on auth in ChartMuseum Adam: Did a few PR reviews Fixed a few bugs with Helm plugins Updated all his plugins Bucher and Adam got together, writing and sketching a proposal for Helm 3 with a few decision trees, which should be good for discussions Butcher’s away in Texas this week, so it might not be finished until next week Justin: Popped in late, talking about triaging issues this week Proposed an issue template on kubernetes-helm-core for Helm Largely positive feedback on the proposal, so Taylor asks about proposing a PR to it Asked about Brian Grant’s proposal, which Discussion Fisher: talk about https://github.com/kubernetes/helm/pull/3437 Adam explained how upgrading as if it was a fresh install won’t work due to the install being in an unknown state Fisher agreed Taylor proposed perhaps this would be a good feature flag instead? That way users can opt into destructive behaviour Adam and Fisher both agreed that would be a good proposal Adam will bring some context back into the PR so we can hopefully steer the conversation in that direction Nikhil: When sherpa’ing, how can we determine which features should be frozen from fejta-bot? Adam and Taylor provided context and info on asking questions about older issues on helm-dev Pairing sessions are great for this! Nikhil agreed Assignments Issue Sherpa: Adam Notes: Nikhil Moderator: Taylor? February 15, 2018 Announcements Helm summit next week! http://helmsummitpdx-feb2018.splashthat.com Get your tickets if you don’t already have them! Standup Justin Mostly issues and PRs Is excited(?) to be the AV guy at the summit at 7:30. :) We appreciate the contributions. There will be coffee! Matt Butcher Helm summit things Collecting some feedback on what are currently the most requested features for Helm -- to try and steer the Helm 3 discussion that way. What is the long term structure / governance model for Helm? Is this something we want to discuss at the summit? Open question: Is it better to lay down (discuss) suggested requirements, rather than dictate solutions for Helm 3? Matt Fisher Majority of the work was helping out with the Dev summit Working with Ronan? To figure out logistics regarding the summit. Michelle Worked on reviewing PR (https://github.com/kubernetes/helm/pull/3206) -- is now up for review Updated the readme with the latest mailing lists from CNCF. Focused on making sure they’re set up correctly this week as well. There are multiple lists -- users, reviewers, power users, etc. Please join any relevant mailing lists. https://lists.cncf.io/g/cncf-kubernetes-helm https://lists.cncf.io/g/cncf-kubernetes-helm-power-users https://lists.cncf.io/g/cncf-kubernetes-helm-security https://lists.cncf.io/g/cncf-kubernetes-helm-maintainers Also working on speaker stuff for Helm summit Taylor Working on Helm summit things -- big shout out to all the folks working on Helm summit items (Michelle, Adam, Fisher, everyone else) Nikhil Working on updating SUSE’s version of helm along with ChartMuseum Working on his talk for the summit (Nikhil: Thanks Fisher for noting this down while I was speaking!) Adam More summit stuff Focused on summit talks and speaker work items Brian Hardock Just listening in this week Discussion There are some bugs in 2.8 Helm list maximum client size exceeded (Justin’s case -- actually exceeding the 20 MB limit) 2.7 -> 2.8 bumped grpc, which made the client and server use the same size. Balboa has a new PR which updated the server client-receive size as well (apparently there are 3 settings that need to be updated). If this does fix it, does this warrant a 2.8.2, and if so -- do we wait until the summit to cut a 2.8.2? Taylor / Butcher / Nikhil: Doesn’t seem like too many folks are affected by this - so probably prudent to wait until after summit. Don’t need a dev call next week since we’ll be at the summit. Michelle will send out an announcement on the ML and _all the places_, that we are at the summit next week, so things might be a bit slow. Taylor: Maybe we should also put a message in the dev channel that we are at the summit, in case some high-pri issues do come up. (“Emergency mode”) Assignments (NOTE - assignments are for March 1st -- the week _after_ the summit) Issue sherpa: Nikhil Notes: Michelle Moderator: Adam February 8, 2018 Announcements Helm summit it comes soon. Tell your friends. http://helmsummitpdx-feb2018.splashthat.com Standup Justin Issue triaging Tried to generate the docs site working on issues and it failed. We have an issue Matt Farina Prepping for Helm summit talks Fixed charts CI woes (ran out of resources due to memory leak) PR to fix GRPC bug from update Reviewing 2.8.1 issues/PRs Being involved with KEP and CRD discussions for application type. Matt Butcher Looking into images to docker hub and other places for put binaries for better metrics that are public Looking to clear some schedule time for helm development Matt Fisher Triaged things for 2.8.1 Dove into bug of multiple releases being marked as deployed Going to pair with Butcher on keynote which isn’t done yet Going to work to get 2.8.1 out Michelle Reviewed on auth PR (by jfrog) Will be around to review more things CNCF requested mailing lists are setup Taylor Helm summit- all the things! Nikhil Issue triage Worked on issue with chartmuseum on helm and updates Worked on his helm summit talk Adam Behind on everything so not too much to report. Took time off Discussion Discussed https://github.com/kubernetes/helm/issues/3242 2.8.1 burn down There are two PRs left that need reviewing Mailing lists Didn’t get many people biting on power users list but will announce at the summit Helm site CI is still deis and needs to move elsewhere as that is going away in March Assignments Issue sherpa: Matt Butcher Notes: Nikhil Moderator: Matt Fisher February 1, 2018 Announcements Standup Justin Mostly looking at issues Looking at reuse values bug Trying to help people having one-off issues. Matt Farina Upgrade bug for 2.8.0 which might hit people. Might need to issue a fix and cut a 2.8.1 release for issue 3382 Odd testing scenarios and poking at CI things. Taylor Was mostly doing Helm Summit stuff Might not have too much time for issue sherpa given the Summit tasks Nikhil Looking at issues and PRs Progress towards Helm Summit talk Discussion Kubernetes is going to shift away from the term “Master” (eg. drupal went with primary and replica, etc.) Propose to use something like API Server / Control Plane. There are places in docs where we use the term “Master” -- this needs to be updated. Need a few more eyes on issue 3382 to figure out why upgrades are failing. Seems to be an issue with patch metadata. We fixed a bug where we forgot to bump the version of the helm cli internally. And a couple of other bugs. Do we fix 3382 and cut a 2.8.1, or do we cut 2.8.1 without a fix for this since there are other fixes that we want to get out? Was specifically asked to be noted that we finished 10 minutes early without MS folks around ;) Assignments Issue sherpa: Justin Notes: Matt Farina Moderator: Taylor January 25, 2018 Announcements Helm Summit registration is open Standup Matt Fisher Paired with Farina on release cutting for 2.8.0 off RC1 Issues are coming in related to Kubernetes 1.9.0 libraries Issue triaging this week, not around next week as much Aggressively reviewing PRs Adnan Interesting things going on in the chart repo Working on Kube Apps related things New dashboard rewrite Taylor Helm Summit Working on CRD talk for Helm Summit. Will ping asking for feedback Matt Farina Followed along on the release process which is nicely documented Issue open about signing Helm releases. Looking at that more closely and how other projects to do this to respond. Poking at bug on helm 2.8.0 that has to do with Helm upgrades. On the charts side, usual stuff Also documenting more processes on the charts repo Also documenting public chart best practices Helps give people clearer idea on expectations Matt Butcher Brian Hardock Listening today Nikhil Issue triaging this week In Germany this week talking about Helm at SUSE Preparing for the Helm Summit Michelle Noorali Helm summit schedule is live, schedule is up 44% of the available tickets have been sold Discussion Onboarding documents Put in Kubernetes-Helm org in the community repo Transparent governance Helm Summit Core maintainers who will be there Matt Butcher, Matt Fisher, Matt Farina, Brian Hardock, Nikhil There will be a Q&A with a core maintainer Matt Fisher volunteered for unconference organization Miguel and Scott Rigby (Taylor) How we publicize RCs that may have prevent bugs Let’s collect a group of Helm power users to test RCs Problem with testing charts in RCs CNCF is switching over to groups.io and may be able to set up some mailing lists for us Michelle to follow up CNCF has already switched (https://lists.cncf.io/g/main) - thnx for the link Farina Assignments Issue sherpa: Matt Fisher Notes: Nikhil Moderator: January 18, 2018 Announcements Helm Dev Summit CFP acceptance letters have been sent out, just finalizing the details and schedule Tickets are set at $75, anyone who RSVP’d will get an email with the link Standup Taylor Working primarily on Helm Summit stuff Finalizing some of those details this coming week Has a lightning talk; would like to bug others for feedback Matt Farina Found out that .Capabilities.GitVersion is missing for testing purposes Currentl workflow is string comparison so x.9 > x.10 Nikhil Shadowed the issue queue w/ Matt Fisher Reminded that he will be out next week, putting information together for SUSE folks Wanted to follow up with Butcher on the onboarding documentation Matt Butcher Wanted to announce that Matt Farina and Nikhil are both core maintainers Been on the customer front talking about helm Nailed down a bug with `helm list` in related to rolling back and recovering lost errors Looking to hire Helm developers @ Microsoft Adam Mostly on vacation last week and the following week Pairing with Matt Butcher on the `helm list` bug Helm 2.8 release stuff Matt Fisher CFP submission scheduling Discussion Come to a final decision on how we are going to use test-infra and any concerns we have with it Farina gave a demo on https://prow.k8s.io/plugin-help.html Butcher: can we version pin plugins/opt out of new features e.g. new labels introduced in the label plugin? Farina: policy on how we roll this out is discussing right now in SIG test infra Feedback: adding too much heavy-handed test automation is not required for smaller projects like Helm; it does not need a whole lot of tooling because the process is intentionally simple Farina is hoping more people to come to SIG contribex to provide this feedback Best option is to look at the plugin repo to see what we can opt in (and out) of Building for other architectures Opinions on releasing a separate docker image for Helm vs Tiller? Going forward with splitting into separate docker images Looking forward to supporting alternate architectures Publish these images to Dockerhub? Conversations leaned towards “yes” Helm v2.8 release Planning to cut the release next week, Fisher will take the lead. Farina and Taylor are interested in pairing to understand the release process Assignments Issue Sherpa: Nikhil Meeting Lead: Matt Butcher Meeting Notes: Michelle (voluntold) January 11, 2018 [Recording] Announcements Helm 2.8.0-rc1 is released Helm 2.8.0 is being targeted for release next week Standup Matt Fisher Helm Summit CFP reviewing Justin Reviewed some PRs Taylor Reviewing CFPs, helm summit stuff Nik PR reviews Worked with Matt Butcher to put together some material to talk about Helm at SUSE This week wants to work on learning how to issue czar Michelle Helm Summit CFP review and planning Same thing for this week Reminder: there is a core maintainer meeting the night before the Helm Summit Matt Farina Helped merge the feature for the supported Kubernetes versions for a chart Adam Helm Summit CFP reviewing This week is more Helm Summit stuff Getting ready for 2.8 release Discussion RBAC best practices changes Do we create a service account for each service by default (in Tiller)? A service account per service is a pretty good idea There is a debate about whether or not we should have Tiller do this. The resolution is that we go forward with adding service account creation in the charts themselves and not tiller Feedback requested: Common labels (mattfarina) Common labels allow for some really good possibilities for visualization K8s tooling (/lgtm, /approve and owners file changes) (mattfarina) Kubernetes is wanting everyone to use the test-infra tools. Do we want to use them? There are some useful testing functions that the tools enable, like tests right before a merge If we have issues with having these enforced, we need to let people know at https://github.com/kubernetes/test-infra CRD stuff (Justin) Moved to next week. This is about changing the validation piece so CRDs function properly We are ok if someone wants to refactor the validation Assignments Issue Czar: Matt Fisher with Nik Meeting Notes: Michelle Meeting Lead: Taylor January 4, 2018 Announcements Helm Summit CFP is officially closed Standup Taylor Mostly working on clearing out notifications on github Reviewed adam’s PR for kube 1.9 Reviewing CFPs for the Helm Summit Matt Butcher 2.8 release planning is priority Matt Fisher See Taylor’s standup Slicknik Wants to sync up with butcher to ramp up SUSE on Helm Adam See Taylor’s standup Discussion Paul (withnale) talked about https://github.com/kubernetes/helm/pull/3243 Butcher and Taylor mention it would be good to get Justin Scott to take a look at this Helm 2.8 Nothing else blocking except for 1.9 support We should continue to cut an RC like the last few releases Assignments Issue sherpa: Matt Butcher Note Taker: Taylor Meeting Lead: Adam Reese ``` ================================================ FILE: community/meeting-notes/2019.md ================================================ --- title: Helm Minutes for 2019 --- ```txt December 26, 2019 Cancelled for the holidays December 19, 2019 Announcements Helm 3.0.2 has been released: https://github.com/helm/helm/releases/tag/v3.0.2 Helm dev calls resume 2nd week of January, the 9th ChartMuseum v0.11.0 released, works w/ Helm 3 Standup Matt Butcher Cut the 3.0.2 bug fix release 3.1.0 release set for end of January (tentatively) Matt Fisher Consultation on the issue queue Josh Dolitsky New release of chartmuseum based on Helm 2.16.1 which broke backwards compatibility, so working with community members on that helm-push now has Helm 3 support Taylor Thomas Issue triaging Proposal for post-render hooks: https://github.com/helm/helm/issues/7260 Support for Kustomize PR: https://github.com/helm/helm/pull/7259 Discussion Taylor’s post-render proposal Specify a binary with --post-renderer= on install The binary must take stdin and return kubernetes yaml on stdout If you opt-into a post-render, you’re stuck with it for the release’s lifetime Will remove checks on if a release used post-renderer for now, will add in later as feature if needed Need review from other maintainers What’s for dinner for _______? ? Assignments: [Determined Jan 9 - Fisher Moderator, Josh D notes] December 12, 2019 Announcements Helm 3.0.1 has been released Standup Marc: Improvements to completion -- in Cobra itself. It will be a surprise! Josh: Introducing Peter, who will be working with Josh. Chart Museum 0.10 is incompatible with Helm 3, so working on upgrading it. Fisher: ONE BAZILLION ISSUES TRIAGED. Pass through old support questions that were stale Taylor: Backlog on issues and PRs. Next week: Proposal for post-render hooks with Replicated. Example with Kustomize coming soon. Farina: 3.0.1 released, then at Kubernetes Forum in Seoul doing a Helm presentation. Butcher: Discovery client bug, PR triaging Martin: Working through the PR queue, and triaging issues Community: Anukul: Issue #3276 (external files to chart deployments). Can we discuss here? https://github.com/helm/helm/issues/3276 Sandip: Second time on the call, and interested in contributing as well. Scott (chat): PS sorry I was late for standup everyone, one thing I think I should at least mention is that Reinhard & I have been working on Chart Repo automation actions: Demo: https://github.com/helm/charts-repo-actions-demo (intended to not only demo and test the actions, but help chart maintainers how to easily become chart repo maintainers in a few easy steps) @helm/kind-action @helm/chart-testing-action @helm/chart-releaser-action Discussion #3276: Proposed possible implementation. Pass in files from a commandline flag, then a template can access those particular files if they were passed in. Fisher: Can we have the user opt-in to including files at install time so that the user is totally aware of what files are added Anukul: Yeah, we can talk about this offline “Lookup” function: https://github.com/helm/helm/pull/6752 [Taylor] Ability to look up data from inside the cluster during template rendering Need to vet security of this Josh: How does this handle the (offline) ‘helm template’ case? Taylor: We should follow up on that in the issue “helm env and XDG_* vars” https://github.com/helm/helm/pull/6892 [Marc] Marc: Was hoping Adam would be here. Will continue on the issue queue. Next Cobra release will print the help text on stderr. Any foreseen issue? [Marc] Change that causes all help text to go to stderr Marc: Could bring it up in Cobra as a breaking change? Fisher (chat): Should look into whether this is configurable in Cobra itself Assignments Notes: Moderator: December 5, 2019 Announcements New Helm Client Maintainer Chartmuseum 0.10 is out Standup Martin Getting back into things after a long return from KubeCon Triaging and reviewing the things Josh Released chartmuseum Scrubbing issue queue for registry things Farina Triaging PRs for a 3.0.1 release Marc Working on autocompletion for plugins Butcher Giving team update. Many people are using their use it or lose it vacation time. Slow down in velocity Finished last conference of the year Not much done since KubeCon/CloudNativeCon Karuppiah Working on pull plugin for chartmuseum Discussion Chartutil unmarshiling to json.Number issue - https://github.com/helm/helm/pull/6888 [mattfarina] Releasing 3.0.1 [mattfarina] Matt Farina will get a release out S390x releases? [mattfarina] Martin is going to chase this down We are tentative to own and support releases we cannot test or debug https://github.com/helm/helm/pull/6988 https://github.com/helm/helm/pull/7096 Discovery client errors [technosophos] Go modules/Oras lib update [jdolitsky] People having issues using Helm 3 as a lib due to docker/distribution replace Maybe this will fix: https://github.com/helm/helm/pull/6862 Assignments Notes: Butcher Moderator: Martin November 14, 2019 Announcements No meeting for the next 2 weeks Helm 3.0.0 has been released https://helm.sh/blog/helm-3-released/ Helm 2.16.1 has been released https://github.com/helm/helm/releases/tag/v2.16.1 KubeCon sessions for next week Scott is doing a maintainer’s booth Farina and Josh: Helm intro session Taylor and Martin: Helm deep dive CERN is giving a Helm talk Michelle will be talking to analysts during the event Michelle will be hosting a few panels: TOC and end user Signup sheet: https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit#heading=h.y5ll0uc2osyi Standup Josh Started using helm 3 and helmfile this week Taylor Polishing up kubecon talks, continuing to do so next week Martin Been dealing with a bunch of miscellaneous issues at work. Broken laptop, server issues, etc. Updated migration plugin for Helm ga Prepping for KubeCon Matt Fisher Managing the helm 3 release Adam Reese Taking a look at managed hook proposal Matt Butcher Working through a whole bunch of the documentation for Helm 3 Attending kubecon next week Matt Farina Got the blog post and governance changes out for the community management role Triaging hub.helm.sh requests Scott Working on a stable and incubator charts repo deprecation policy, aligning with the helm 2 deprecation policy Michelle Prepping for Kubecon Discussion Interest in a “helm import” tool for existing resources? (to help migrate from helm template | kubectl apply -f type workflows) (jacob) Jacob to follow up with taylor on the `helm commandeer` plugin Question about hooks for community charts v2 compatibility Scott to follow up with adam Ok time to update go modules? / Does anybody know how to update Go modules? Farina: yes Assignments (3 weeks from now) Notes: Farina Moderator: Fisher November 7, 2019 Announcements 3.0.0-rc.3 has been released _should_ be the last one 2.16.0 has been released Due to breaking changes, it needed to be a major version Standup Fisher working with Martin & Rimas - mini-consulting - found issues with some releases not being created/propagated over Adam PR reviews, and anything that comes up before the release Butcher gave talks at Open Source Summit on Helm & community with Karen Helping Farina get ready for kubecon Running through the docs with a new user’s eyes Farina Slides! Preparing for the conference Helm hub - reviews for v3 Reviews and other helping in prep for v3 release Bridget Out earlier this week at VelocityConf Berlin ING is doing interesting stuff with Helm Helping Lachie get ready for his QCon SF Helm talk Martin Focused on Helm 3 & bugs Working on deep dive with Taylor for KubeCon Commenting on Fisher’s blog post for Helm 3 Michelle She’s back! Volunteering with a non-profit _using_ Helm - good perspective Available to help with PRs Jacob Planning to look over current docs on Helm test/hooks Planning to open a PR to fix referencing images by digest in the default starter chart Scott Rigby Worked on chart testing repo this week with Reinhard Aligned branches with helm/helm’s current branching scheme We are in the process of upgrading chart testing to Helm v3 Taylor Working with Martin on talk for KubeCon San Diego Working on an advanced k8s talk for cloud native rejects bugs/PRs! Discussion 2.16.1 release [Taylor] - 2.16.1 milestone Schema issue in the issue queue - fix merged in, undergoing testing - breaking some of the major charts like Prometheus. Let’s cut release today [Taylor and Fisher will pair on issues and cut release] Is a `helm status` bug a regression? Or did something else break in the k8s client libraries? KubeCon/CloudNativeCon booth [Farina] Sign up! We need people to pick time(s) to be there. Helm 3 Presser update [Farina] The CNCF is waiting on what we plan to announce Butcher: Microsoft will have an Open at Microsoft blog post about it. [Bridget is writing it] Question about Helm v3 compatibility with community helm/charts that I may have missed: are we still planning something like this: > A “legacy” plugin will be released by the Helm project to support v1 charts with the crd-install hook Farina: we will need to help the community repo and document the dual pattern. Let’s automate/simplify so we don’t make it too hard on the community. Scott is working on this. Helm template not rendering notes in 3: https://github.com/helm/helm/issues/6901 Martin: this has been answered Assignments Notes: Fisher Moderator: Scott October 31, 2019 Announcements 3.0.0-rc.1 has been released! rc.2 to follow 2.15.2 released. See https://helm.sh/blog/2019-10-30-helm-symlink-security-notice/ 2.16.0-rc.2 has been released Standup Taylor Working on PRs, working on issues, etc. Keeping an eye on the queue Josh (in costume) Been spending time on the OCI mailing list to make sure our strategy is good for charts in OCI repos Martin Doing bits of this and that (spending time in issues and PR reviews) Bridget In Belgium with lots of delicious chocolate Doing a helm talk at a k8s meetup Matt Farina Cutting releases and doing odds and ends to help get releases and prereleases out Adam Tying up loose ends on v3 including dependency updates Scott Been out sick. PR reviews and online help since back Matt Fisher Working on ins and outs of getting releases out and fixing things up Working with 2-to-3 migration process Triaging bugs Discussion Do we think we have a good handle on the queue to warrant pushing out a 3.0.0-rc.2 by EOD tomorrow, or should we push out to Monday? [fisher] Adam suggest we use a time box when cutting RCs. Not doing this for the 3.0.0 Assignments Notes Bridget Moderator Taylor October 24, 2019 Announcements: Helm 3 beta.5 released 🎺 Helm 2.15.0 released 🎺 Helm 2.15.1 released 🎺 GitHub branches changes: 🎺 2.x: `master` → `dev-v2` 3.x: `dev-v3` → `master` Helm 2.x now in maintenance mode - bug fixes only accepted Helm Security Audit current status [fisher] We should see the full report within the next week Standup: Matt Farina Working on PR reviews, triage Upgraded the kubernetes cluster for Helm Hub Fixed a few issues related to CronJobs in the cluster Taylor Reviewing PRs and shepherding things through to cut Helm releases Working on documentation for Helm 3 Matt Fisher Working on triaging issues for the Helm release milestones (2.15, beta.5) Matt Butcher Away at OSS Lyon, France this week Martin Bug triage PR reviews Looking to follow up with the other core maintainers to help out with the RC Jacob Working with a coworker on a particular PR in regards to `helm template` in Helm 3 Discussion: Helm 3 GA: [martin] Notification to CNCF RC1 release date GA release date Farina: when we go out with 3.0, this is a BIG thing so we want to maximize press coverage. We need to notify the CNCF to give them lead time for blog posts, press time, etc. We have to coordinate with partners Fisher: On the site design, Ronan is free right now but may be pulled in other directions as KubeCon NA comes closer ????? Change related to OCI mediatypes: [josh] https://github.com/helm/helm/pull/6779 Assignments: Notes: Farina Moderator: Fisher October 17, 2019 Announcements Standup Taylor PR Reviews Working on some PRs like around a “funky” situation with time: feat(*): Adds custom time package for better marshalling. Working on a lint PR Martin Worked on a few PRs and PR reviews Did some triaging Matt Farina Worked with folks on the Helm security audit which is ongoing Triagied issues with the Helm Hub Matt Fisher Worked on v3 including the 3 way merge Going to continue on with v3 beta 5 work Discussion: Will Helm v2 CRDs work in Helm v3? [martin] No. The CRD install is different in each. This needs to be documented We were/are planning to have a legacy plugin that will bring about compatibility but work has not happened on that, yet How should `repo update` resolve v3 repository file: [martin] https://github.com/helm/helm/issues/6644 Release updates Release.Time and Release.Revision discussion Jacob asked to have it back because he uses it with backups and to pull the right backup Assignments Notes: Matt Fisher Moderator: Martin October 10, 2019 Announcements If you are a project maintainer, you now have triage access everywhere in the Helm org Helm 3 security audit starts today This is needed for graduation V3 beta.4 contains an important security fix Standup Taylor Working on porting features over from Helm 2 to Helm 3 This next week spending more on ports and outstanding work for beta.5 Adam Merged PRs on open API validations Making sure there aren’t any other loose ends for v3 Matt Fisher Working on paring down the PR queue, closing old PRs and triaging ones needed in 2.15. One more outstanding PR for 2.15 Working on finishing up 2.15 and beta.5 this next week Matt Farina Worked on getting the security audit work rolling Working through go modules issues and cleanup Working on Helm Hub stuff as well There are some scaling and storage issues Jacob Saving time for discussion Martin Working on v3 ports PR reviews! Updating the migration plugin against beta.4, including updating go modules Discussion What versions of Kubernetes is Helm supporting? [mattfarina] Note, Google Cloud, Azure, and AWS ship n-2 as their latest stable Example: https://github.com/helm/helm/pull/6590 If we stick with n-1 we’d be excluding all public cloud providers All maintainers present in the call are ok with n-2. Farina is going to send out an email to Helm Maintainers for a vote How should Helm v3 cache work? [martin] In v3, repository file (repositories.yaml) seems to be empty for cache property for repo entries The repositories.yaml file is missing the cache property. This is different per system due to the XDG spec, which allows you to change which directory to look in. Caching should still work Adam is going to look it up to validate When migrate from v2 to v3, repository cache is not updated in repo file following `helm repo update` https://github.com/helm/helm/pull/6488#issuecomment-539468075 Helm test and hooks roadmap for v3 release [jacob] See presentation for full proposal There is an open PR to remove the cleanup command Hooks will be recreated (idempotent) by default and other resources will be updated as needed Helm 2.x and 3.x [martin] When going to release Beta 5? Beta.5 is following the same roadmap as beta.4 (which was released due to a needed security patch) We are waiting for beta.5 until 2.15 is released Do we lock down merges until we have new branches available? Branch names post 2.15 release? For example, master → 2.x, dev-v3 → master & dev-v3 → 3.0 (3.0 GA) Dates: 2.15 RC today or tomorrow 2.15 by next wednesday Switch branches right after 2.15 (shoot for thursday) Beta.5 will be released before branch cut over (shoot for thursday) We’ll cut the v3 RC as soon as we are ready after that so we have a longer RC time for people to try it in prod Assignments Notes: Matt Fisher Moderator: Adam October 3, 2019 Announcements A vote went through in the org maintainers list: anyone who is a project maintainer in the Helm organization will now be granted the Triage role across all Helm projects. This is to help with triaging efforts across projects Standup Adam Reese Working on a few Helm 3 PRs around flag parsing and environment variable processing Matt Fisher Pairing with Bridget on Helm 2 PR queue - figuring out what is in there, what could go into 2.15, resolving old issues. Not too much to report on Helm 3 this week Martin Hickey PR review/triaging Starting to pour over som older PRs and see where they are in terms of merging status. One of them is the release checklist Helping out with the Helm 2 -> Helm 3 PR port process Taylor Thomas Working on a major refactor in Helm 3 that standardizes how Helm displays information. We had 2 printers; now we have 1 Reviewing PRs as they come in Matt Butcher Working on migrating some internal charts from Helm 2 -> Helm 3 for testing purposes Working on updating the Helm 3 documentation around XDG Bridget Kromhout Pairing with Fisher on a bunch of Helm 2 PRs ~20% of the old PRs were cleared up in the past few days Added a few PRs to the discussion list for further questions Matt Farina Working on migrating helm/helm over to Go Modules, which has been fun Should have a workable PR with an up-to-date modules in the next few days Discussion Issue Triage/Discussion helm template refactor and remove dependency on install. Ideas on how to go about it. Action item: open up a WIP PR so we can give some actionable feedback Moving initActionConfig to pkg: https://github.com/helm/helm/pull/6341 from aaronmell (Note: We set up the expectation this would get in, and the submitter is asking.) Adam: I can give an update on this one Fix chartutil.Save returning empty path when passing a non-existent directory (Resolves #6344): https://github.com/helm/helm/pull/6360 from wxdao (Note: We told the submitter this bugfix would get considered; actively working on it today.) Overall, I think we need to step in and respond, telling them that we need to feat(cmd/helm): use alternative ports on `helm init`: https://github.com/helm/helm/pull/5847 from mnkyl (Note: This is Tiller-related but seems ready for review. So we either merge or reject now, it seems.) Fisher will look at this. fix repo url being decoded: https://github.com/helm/helm/pull/6060 from karuppiah7890 (Note: Looks like the submitter is hoping for a review and actively working on it.) Matt Farina: I’ve already commented and they’re asking for me. I’ll look at it. add AppVersion column to the history command: https://github.com/helm/helm/pull/5069 from adshmh (Note: Is there a reason this is not merged, other than the docs conflict that crept in over time? Looks like it needs a second maintainer to look at it?) Matt Farina: I’ll take a look at this one Taylor: I can port to v3 when done Release Metadata https://github.com/helm/helm/issues/6464 [Taylor] Action item: Fisher will follow up in the issue with the discussion that occurred in the meeting (link to youtube) Possible 2.15 Release Date [Fisher/Taylor/Bridget] Suggestion: mid-october cut 2.15 branch (Oct 16?), switch the dev-v3 over to master cut beta 4 first consider a Helm 3 release candidate for Halloween (or right before KubeCon mid-Nov) Can we also discuss 3.x release date [Martin] We need to cut beta 4 first Create a 3.1 milestone Assignments Notes: Taylor Moderator: Martin September 26, 2019 Announcements Beta 4 date? - coming out fairly soon (discuss at standup) Standup Taylor Thomas: porting features from v2 to v3 - small refactors - adding back in missing validations Tying up 2.15 milestone & releasing that - which should be the last feature release of Helm2 Josh Dolitsky Diving down OCI harbo(u?)r rabbit hole Bridget Kromhout Working on communications around Helm 3 ticket items Matt Farina Helm hub install/search issues (redirect needed; in progress) Hoping to start go modules on Helm Matt Fisher Triaging, porting features Working towards next beta milestone Adam Reese OpenAPI validation - adding back, finding small bugs Matt Butcher InfoQ will publish an article about Helm Summit tomorrow (after interviewing Butcher) Martin Hickey Working on migration feature and docs (yay) Reviews for ports Looking at k8s 1.16 breaking changes Jacob Has a PR open for moving test run subcommands: https://github.com/helm/helm/pull/6363 Triage -[moving to discussion this time] Discussion v2.15 [Taylor] Current plan is this will be the last feature release (we could then close all v2 _feature_ PRs - bugs will still get worked, just not “exciting new thing”. Helm channels: Slack, mailing list, etc - letting people know We will probably have to stay on current client go libraries until k8s 1.17 comes out. v3 label, project board, etc (Bridget) What does “ bacongobbler added the v3 label 3 days ago” imply? The Helm 3 project board has a small subset of what’s tagged v3. The v3 label on PRs does not seem to imply it will be merged _before_ v3. Farina: “V3” as a label doesn’t imply any commitment Fisher: Github has a feature that allows one to add description for labels - let’s add more info to the v3 label. And let’s update the contributing docs. Farina + Adam: let’s flag everything v2 or v3 timeboxed segment where we look at outstanding issues/PRs https://github.com/helm/helm/pull/6504 - technically a breaking change - but we said beta could have those! So it should be okay? Farina will add some labels for v2/v3 Marckhouzam: auto-completion for the v2/v3 migration https://github.com/helm/helm/issues/6474 What is the priority? Adam appreciates and will review. But should v2 patches get added so autocomplete works properly on both sides? Josh D: if autocomplete is not working it’s a bug Matt Farina: Happy to review these. Marc & Martin discussing autocomplete speed (10ms vs 60ms) Assignments Notes: Fisher Moderator: Farina September 19, 2019 Announcements Helm summit Helm 2to3 plugin moved to Helm Org: https://github.com/helm/helm-2to3 Standup Adnan Not much to report Matt Butcher Was at Helm Summit last week Starting light planning for next Helm summit Matt Farina Semver v3 out and sprig v3 in works. Both using go modules Working on monocular redirects to work with helm install for helm hub and removing chartsvc from search url Taylor Looking into bugs and features for Helm v3 Was at the summit last week Jacob Using helm v3 for past 3 weeks! Working on test subcommand Martin Helm summit last week Cleanup capability in 2to3 plugin Going to get back to migration docs Triaging in the queue Discussion What about adding kubectl as dependency for zsh completions. See https://github.com/helm/helm/pull/6408 [mattfarina] Will check with Adam who has worked on this Validate that the absence of kubectl does not cause any issues so this is only additive Edge case issue https://github.com/helm/helm/issues/6435 [martin]: If Helm 2 and Helm 3 manage the same cluster concurrently And Helm 2 release data is stored as secrets in the cluster And Helm 2 has release(s) stored in namespace of the release Helm 3 stores release as secret in the namespace of release Helm 3 will not list any such v2 releases as different labels used With Helm 3 you can try to install with name already used in v2 and it errors out Issues also occurs for migrating data meaning that release cannot be migrated Should Helm 3 to use a different naming convention for release versions? Are we still integrating new functionality into v2 like https://github.com/helm/helm/pull/5704? [martin] Looking to 2.15 as last feature release for v2 Taylor to email maintainers on this and moving dev-v3 to master and documenting the stance on v2 features and v3 dev [Bridget can help write this up] Deprecating the --recreate-pods flag https://github.com/helm/helm/issues/1702 [Taylor] Taylor would document the replacement No push back Triage role and the Helm org… https://help.github.com/en/articles/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level [mattfarina] Assignments Notes: Bridget Moderator: Taylor September 12, 2019 No meeting due to the Helm summit in Amsterdam September 5, 2019 Announcements Make sure to register for Helm Summit! - https://events.linuxfoundation.org/events/helm-summit-2019/ Butcher: there is a 20% discount code “HELM19G20” Next week in Amsterdam, The Netherlands Community and core maintainers Standup Taylor: Preparing for Helm summit PR reviews Paired with Butcher on some CRD stuff Matt Fisher: Back from honeymoon! Congrats! Preparing for Helm summit PR reviews Adam: PR reviews Doing fixes Martin: Migration work PR reviews Starting to pull up some v2 work around scaffold charts Matt Farina: Bug triage PR reviews Helm hub work Jacob: Helm test proposal Looking to refactor Helm test Josh: Preparing for Helm summit Matt Butcher: Working on CRDs with Taylor Preparing for Helm summit Discussion Will we have a meeting during the summit? Next week dev meeting is cancelled due to Helm summit Beta 3 release [Taylor]: Cut a release before going to summit to pickup work Beta 4 and RC release timelines [Taylor]: Pull up any v2 work and get it stable for Beta 4 before rc1 Work to make it stable for GA Should “helm-2to3” plugin be added to Helm org [Martin]: https://github.com/hickeyma/helm-2to3/issues/14: Yes, pull it Martin to send mail to Helm Org Maintainers to vote to get it added If/When added to Helm org, Helm core maintainer become owners Test subcommand beta status? [Jacob] Remove `run` from `helm test run` (Jacob before beta.4) Remove the cleanup flag (Jacob before beta.4) Make it useable by Helm 3 Any breaking changes are feature gated https://github.com/helm/helm/issues/5654 `helm template` Breaking change? Need `validate` flag now to use Matt Butcher/Jacob to look at it Jacob to file a new issue One-minute summary of the CNCF review [butcher]: Matt Butcher and Farina delivered to CNCF Very successful meeting and CNCF very happy with progress Security audit in October Looking to move from incubator project to Fully fledged project by EOY Assignments [for September 19th] Notes: Matt Farina Moderator: Josh August 29, 2019 - Moderator: Adam - Notes: Vibhav Announcements - Helm v3.0.0-beta.{1,2} released: Thanks Taylor & Adam. - Standup - Butcher - Open Source Summit talk with Karen Chu about lessons from open source (focused on the Helm project) - Josh: - Working on ORAS - Martin - PR reviews - Bug triaging - Getting ready for helm summit - Matt Farina - Getting ready for helm summit, - if you hit 501 jobs in the cluster in helm hub cron jobs stop working. Fix: reduce the number of jobs - Bridget - Talks in Open source summit - Getting ready for helm summit - Discussion - [Josh] https://github.com/helm/acceptance-testing - Define goals - [Martin] Discuss goals for Helm 2 to Helm 3 Migration: - Feature: https://github.com/helm/helm/issues/5892 - Doc: https://github.com/helm/helm/pull/5582 - Helm v2 releases in-place to Helm v3: - Proposal: https://github.com/helm/helm/issues/6154 - Plugin: https://github.com/hickeyma/helm-2to3 - Assignments: - [Bridget] - figure out what’s more common - “dry run” or “template” - in the wider ecosystem (https://github.com/helm/helm/issues/6290) - Notes: - Moderator: August 22, 2019 moderator: matt farina notes: scott Announcements Make sure to register for Helm Summit! - https://events.linuxfoundation.org/events/helm-summit-2019/ There is a 20% discount code “HELM19G20” Standup Josh Registry should be good for beta Adam Working on removing helm init. Changing how config is passed around Trying to get all unit tests to pass Scott Chart PRs & slack help Helped with Azure image updating for Helm Hub Issue on Helmfile and Helm org: https://github.com/roboll/helmfile/issues/758 Matt Farina updated helm hub cert-manager (older version made excessive api calls, will be deprecated soon) upgraded helm version to v2.14.3, and docker image for that Helm issue triaging Jacob helm test for v3 can create configmaps and secrets at the same time documenting follow-up work to document cleanup policy. Working on proposal for that Discussion Captain CRD+Controller for Helm 3 [Some folks from Alauda] https://github.com/alauda/captain https://github.com/helm/acceptance-testing Move to next week Wants to define project goals Assignments Notes: Vibhav Moderator: Adam August 15, 2019 Announcements Make sure to register for Helm Summit! - https://events.linuxfoundation.org/events/helm-summit-2019/ Butcher: there is a 20% discount code “HELM19G20” Josh now a Helm Core maintainer - congrats! Standup Butcher: Fisher did a major issue-queue pruning Triage, clearnining, getting ready for Helm 3 beta 1 milestone Farina and Butcher worked on security audit uncovered problem with CRDs Taylor: Bugs and beta 1 release notes Go 1.12.8 was breaking… everything (so, rebase your open PRs against v3 - and check all your go projects) Finishing open PRs and cutting beta very soon Farina: getting search stuff completed - `helm search` in v3 shows what you can search (registries, hub, monocular instances if you pass the URL) Bridget: getting ready for Open Source Summit talk about Helm 3 Adam: code reviews, pairing, helm init feature (lazy-creating config files and system directories as needed) Vibhav Bobde: question re: storage classes - is it a good idea to wait on provisioners in storage classes? (sent a PR recently) Nick Huanca - asking about adding a flag to show all values or supplied values in template debug Wrote “reckoner” - would like compatibility Adam: let’s make sure we have machine-parsable output Discussion CRDs in Helm 3 [Taylor and Adam] Taylor: “Everybody’s favorite topic in k8s-land - CRDs!” As we factor out how manifests are rendered, there isn’t a clear path/common use/install/manage pattern for CRDs Farina: CRDs allow you to extend the k8s API, so they’re good for cluster extensions, but they need more access than you usually want to give to app developers. Lack of definition in the space about how this should work - but we’re using CRDs far beyond their original intents, and in many enterprise environments, installing an operator is a cross-team administrative task. Also, across namespaces may not work as expected (is the CRD available?) Farina: Helm v3 likely can’t “solve” things that are still beta in k8s itself. Adam: Helm can’t validate API objects in the cluster, due to order-of-operations - before we can parse a CRD object we have to render the manifests, and then you can create API resources that weren’t available when you did the rendering - we can’t render before we install. Possible solution: break out CRDs into a defined space in the chart? And then CRD management happens first, so the rest of the rendering then works correctly? Butcher: “There’s also that peculiar pattern where the controller installs its CRD. Then we can’t load CRD instances until the controller is running” Taylor: Making assumptions in Helm 2 that turned out to be invalid means we’re looking to the community to ensure we go the direction they want (instead of trying to impose a standard). Adam: projects wanting clean install steps are interested in answers on CRDs, but application operations is where the problems show up. Farina: a human way to make the experience of interacting with this better - better error messages, better docs Bridget: good point - if people have to choose between “hello world is easy” and “production is safe” the answer is clear, but it would be nice to have both. Farina: let’s help people understand how to use Helm in production Vibhav: we don’t want people to use CRDs by mistake or without understanding them. Assignments Notes: ?? [a number of people are at Open Source Summit] Moderator: Matt Farina August 8, 2019 Announcements Make sure to register for Helm Summit! - https://events.linuxfoundation.org/events/helm-summit-2019/ Standup Butcher Working with Farina on the security audit for the Helm 3 codebase Security audit is slated for the beginning of October Helm administrivia Fisher Looking at what is needed for the beta.1 milestone Taylor Working on the same things as Fisher Fixing bugs in Helm 3/Helm 2 Working on items to get the beta out the door Adam Focused on code reviews this week Next week working on removing “helm init” Josh Working with Farina and Fisher on OCI work and how it is going to land in beta Farina Updating our security list PR reviews! Discussion Bringing v2 features merged after v3 branch to v3. https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=label%3A%22Needs+v3+fix%22 Doc changes Most code ones are taken care of Do we remove or add the label when complete? Adam: We should have a second label to indicate it is done Taylor will be adding “v3 port complete” label and going through the list of tagged changes Helm security audit update [Matt Farina / Matt Butcher] Which code areas should we be checking? Tlsutil Chart provenance New registry code Templating (no break-outs) Security issues will be reported in real time to the security mailing list For clarity: This audit is part of the requirements for CNCF graduation Intro to Helm talk at KubeCon SD [Taylor] Farina is going to join Josh for giving the Intro talk Taylor will start a thread with Nanci at the CNCF to get the talk transferred to them Registry updates Experimental flag for inclusion We are all ok with including the OCI work with a feature flag, which means we need to add in feature flag functionality to Helm Status of remaining tasks Export errors bug: DONE Issue: https://github.com/helm/helm/issues/5757 Layers finalization: almost done Issue: https://github.com/helm/helm/issues/6141 oci-layout: almost done Issue: https://github.com/helm/helm/issues/6068 Helm Hub search [mattfarina] The goal would be to have the default search tie into the helm hub search Fisher: This would be a good UX for users Assignments Notes: Bridget Moderator: Adam August 1, 2019 Announcements Helm 2.14.3 is out [Matt Fisher] Standup Matt Fisher Working with Taylor on some helm v3 issues. The design for 3-way merge patch (PR available). Still needs docs. Adnan Not much to report Discussion on stable and helm v3 https://lists.cncf.io/g/cncf-helm/topic/psa_helm_v3_and_the_stable/32656951?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32656951 Josh Working on chartmuseum Getting OCI related tasks for beta Martin Working on charts v2 api. First PR is up Enabled checking for the test styling Working on migrations Scott A github app for chart releases Taylor Working on 2.14.3 (a CRD change). The helm v3 version of the change still needs to land Kubeclient change Working on 3 way merge changes Matt Farina Removing the stable repository from Helm 3 has been merged Background context: the stable repository has been hosted by Google’s account, making it difficult to migrate The chart repository has become unsustainable for the charts maintainers (ERR_FIREHOSE) Working on a process for making the gpg keys public in a KEYS file Jacob LeGrone Working on proposed changes to testing for helm v3 Discussion Helm v2 support window once v3 is out [mattfarina] Bridget noted the shopping and tax season issues Suggestion is 6 months of bug fixes, following 6 months of security releases After one year, following v3, no longer supported. Download location in Google may (will?) go away. We should have a backup for people but it may require changes in their use TODO(mattfarina): Create a support proposal and put out for review TODO(mattfarina): Email helm mailing list on this Final pre-3.0-beta OCI tasks! OCI layout: helm/helm#6068 Layers/meta decision: helm/helm#6141 This impacts signing charts which still needs to be worked out for OCI storage ArgoCD demo/consultation [Alex Collins] Helm v3 3 way merge [Taylor] Assignments Notes: Taylor Thomas Moderator: Matt Farina July 25, 2019 Announcements Helm 3.0.0-alpha.2 was released earlier this week (Matt Fisher) Standup Scott charts PRs Martin Looking at release information between Helm 2 and Helm 3 Putting together a proposal for migration Taylor Refactoring the internal kube client libraries in Helm 3 Adding back --cleanup-on-fail Also following up on the issue where resources sometimes don’t update. More information has been shared by the community Matt Farina Helm Hub work for the last week Michelle Working through the helm test proposal Jacob worked on last week Josh Opened a new acceptance test suite repository: https://github.com/helm/acceptance-testing Working with Fisher on a list of work items to complete for the beta Matt Fisher Released alpha.2 Working on doing some release planning for beta.1 Discussion Ian https://github.com/helm/helm/pull/6066 Action item: Matt Fisher will take a closer look at this one this week (or early next week) A KEYS file for signed releases… https://github.com/helm/helm/issues/6015 [farina] Yes, this sounds like a good thing to do In the future we may move to notary, but we still need to implement this for Helm 2 Work remaining for Helm 3 and how best to share the load? [martin] Linking “Helm Hub China”, request to review [harry]: https://github.com/helm/charts/pull/15004, https://github.com/helm/monocular/pull/640 (Q: where will be the best place so ppl in China could see the mirror hub?) A: maybe both, we could follow up on the PR to see how to link We are also translating (localized) Helm v3 Doc in Chinese The helm official docs want to move to have translations https://github.com/helm/helm/issues/5994 (helm controller and CRD) [Hang Yan] Scott to follow up with Hang to set up a meeting, or as a demo for next week’s dev call Assignments Notes: Moderator: Matt Fisher July 18, 2019 Announcements Helm Summit Update (fisher) Schedule is available https://helmsummit2019.sched.com/ Speakers have been notified Next steps: review diversity scholarships, sponsorships 2.14.2 released Standup Matt Fisher: Helm Summit planning Release planning for 3.0-beta Scott: Reviewing chart tooling, also PR reviews/merges for helm/charts Matt Butcher: Meetings for CNCF Graduation Bridget joined team to work on docs Helmfile looking to join the Helm Org Working on getting our KubeCon SD sessions setup Matt Farina: PR reviews Adam: This week: reviewing a few PRs Talking to taylor about some apply design stuff Pulling out some features from his XDG PR (like the --namespace fix) Michelle: Helm Test: reviewing proposal from Jacob Taylor: Atomic flag feature Working with Adam and it was amazing Martin: v2 to v3 migration proposal Cut 2.14.2 release General PR, issue work Discussion Making Helm easier to use as a Go library and the work required (Taylor) Helm testing proposal https://github.com/helm/helm/issues/6020 (Jacob) Merging PRs procedure: PR has one LGTM (small, medium), two LGTMs (large+) OR 2 LGTMs? (Martin) Assignments Notes: Matt Fisher Moderator: Scott July 11, 2019 Announcements 2.14.2 is coming (today? lol) Helm Summit CFP notifications will go out Monday Helm Summit schedule final touches happening, coming out soon We will be bumping the chart API version to v2, because new charts made for helm v3 won't work with the v1 charts API Standup Taylor: almost done moving atomic flag to help 3 will work on 3 way diff merge helped a bit on 2.14.2 Scott: Nothing to report for this week Martin: issue triage/pr review/ workspace answers migration stuff on backburner, will try to get back to it need some issue triage help Matt farina: not much this week except merging stuff into helm hub and some triage help Josh (via Taylor): working on kind acceptance test suite Adam: working on helm init (can remove command) catching up on code reviews Bridget: Offer to help w kubecon NA CFPs, due Friday Matt Fisher (via Martin): working on helm summit schedule planning Via slack "RE: bumping apiVersion to v2, yes, I agree that's something we should do for Helm 3, especially if the default output of `helm create` won't work for Helm 2." Discussion Helm v3 charts, is it time to increment the chart apiVersion to v2? https://github.com/helm/helm/issues/5907 Example changes: requirements.lock now Chart.lock Requirements now in Chart.yaml Michelle has proposed a chart test breaking change Release object in templates has changed (Time dropped but sprig function coming to templates to return exact same feature in use) Someone is working on a Helm v3 controller - https://github.com/helm/helm/issues/5994 https://github.com/fluxcd, too Are the changes to the test architecture documented somewhere (proposal? v3*.md?). Any updates on planning for Lua engine stuff? (curious about chart template post-render options. No rush 😅) Answer: other Helm v3 features are prioritized to get out for initial helm release, breaking changes etc, and most importantly Tillerless. Lua can be an upcoming MINOR version, and work can start at some point after the initial v3 release. Assignments Notes: Adam Moderator: Martin June 27, 2019 Announcements None for today Standup Nikhil: Not much last week Follow up on PR reviews / Issues this week Josh: Helm.sh follow up Not too much else Taylor Ready to jump to Helm 3 things Plan to cut 2.14.2 on Monday with Martin’s help If there are some bug fixes that need to make it to this release please let Taylor / Martin know! Scott Coalesce values fix added to 2.14.2 Martin Digging in to a lot of PR reviews and issue triage Fixed an issue with templating on the v3 branch. This was causing unit tests to fail Also made some progress on the migration work Jacob Michelle has an updated helm testing proposal. Would be good to get feedback from a wider audience around this. Michelle Working on helm test -- this week was helm test cleanup Going to get on a zoom with Jacob to go into detail on helm test. Will drop a link in the #helm-dev channel Would love some more feedback on the helm test PR Discussion Need a label or a way to assign community members to issues (michelle) Was talking to someone in the community about an issue, and she wanted to take over the issue, but there was no way to assign it to them. Need to look into what administrative controls GitHub has for this? Will look into what k8s does here and should have an update soon Community member asking when alpha.2 is scheduled for (martin) (Find alpha.2 issue to add here) We’re working on this as hard as possible. We’ve deferred features to post 3.0 (e.g. LUA) so that we can get the critical pieces out. E.g. atomic flag, 3-way diff, etc. Might be a couple of months. We are trying to get a release out the door for this. Helm Testing Proposal: [Martin] Brought up backwards compatibility; what happens in cases of test success/failure (ideally failure keeps resources around, success cleans up -- or this can be based on a flag). [Michelle] Conditionals become hairy and hard to understand -- so maybe having a seperate cleanup command is good here? Maybe this needs more discussion -- let’s open an issue up on this. How much of this is based on the cleanup flag? What if we have a seperate cleanup action (e.g. && cleanup) that we can do explicitly. [Jacob] Re test cleanup: https://github.com/helm/community/pull/90#discussion_r297374923 The second test proposal is based on a lot of feedback and conversations. The first one should be closed shortly. Lots of people are using this very often, and is very popular -- so thanks for driving this Michelle! [Michelle] Current implementation just has to have the right annotation, doesn’t need to have the tests in the templates test directory -- this has an implication on backwards compatibility. Assignments Moderator: Taylor Notes: Josh June 20, 2019 Announcements Helm Summit update Standup Taylor Have been working on troubleshooting an issue where certain objects aren’t being updated on an upgrade (for Helm 2) Some of the folks over at Mattermost have a reproducible case, so working with them Josh This week, been giving talks/evangelising Helm in the midwest Hoping to connect with Matt Fisher on the registry work going on in Helm 3 Martin Concentrating on the migration work from Helm 2 to Helm 3 Looking on the release metadata differences between Helm 2 and Helm 3 PR reviews Matt Fisher Diving into the downloader package for Helm 3 Lots of cruft in there, so cleaning up the code Working on Helm summit Matt Farina Releasing a new version of sprig Working on the capabilities object for Helm 3 Reviewing PRs Discussion Helm 3 OCI: enforcement of tags (joshua) OCI does not have a ruleset on the tag pushed The current context in Helm is to not push non-semver tags Do we want to allow semver-incompatible tags? (fisher and farina) if we do support those, then it makes the dependency resolution problem much harder If there’s enough demand, perhaps we should come up with a proposal to the UX so we can capture that use case New docs: https://v3.helm.sh/docs/developing_charts/#registries PR reviews (matt and adam) Current status: Helm 2 requires 2 LGTMs on PRs size/L or higher. Helm 3 requires 2 LGTMs on *all* PRs How do we get more people to jump in on PR reviews? What can we do to incentivize folks to review PRs? Taylor: perhaps it’s not the PR review itself, but the lack of coverage on tests that are causing blocks on PR reviews? Could we implement some form of acceptance test suite? Action item: farina to bring it back to the mailing list? Should we cut 2.14.2 when this PR lands? https://github.com/helm/helm/pull/5532 (Taylor) Kubernetes 1.15 was just released yesterday. Should we wait on merging support for that before cutting a new release? There may not be enough release maintainers around to cut a 2.15 any time soon Action item: taylor to follow up with Martin on a 2.14.2 release Josh: I’m planning on cutting a new release of ChartMuseum soon. It’d be great to put that onto https://get.helm.sh. How can we accomplish that? Fisher: actually I’ve been wanting to write some documentation on the architecture, how to upload assets there, etc. Getting ChartMuseum onboard would be a great “pilot program” so we can start getting that documentation for onboarding other projects Action item: Josh to follow up with Fisher Assignments Moderator: Martin Notes: Matt Fisher June 13, 2019 Announcements Helm Summit Co-chair committee met up this week. Program Committee is currently reviewing proposals. After that, chairs will assemble the schedule. Standup Matt Fisher Taking a look at one of the helm 3 refactors: the OCI registry integration Taking a closer look at the getter package for fetching helm charts and refactoring Going through helm 3 PRs Matt Butcher Keeping tabs on a few things in the helm issue queue Adam Working on the XDG base directory specification + removal of `helm init` Michelle Noorali Working on `helm test`, currently refactoring Martin Hickey Updated the release checklist from 2.14.0 Testing around the v2 to v3 migration, working on a migration doc Some issues around release metadata Taylor Reviewing CFPs on the Helm Summit Looking at the coalescing tables refactor in Helm 2 Ramping up on Helm 3 Josh Giving Helm talks next week with Bridget Scott Same as taylor this week Matt Farina Working on detecting objects in the capabilities object Working on Helm Hub for Helm 3 Discussion Proposal to drop the title “issue sherpa” (fisher) Is this a shared responsibility? Michelle: we should still have someone on-call to ensure someone is taking a look at security-related issues Farina: we do have a process in place about who is responsible for security issues (in helm/community, SECURITY.md) Action item: fisher to bring it to the core maintainers mailing list v2 release object from state not loading in v3 (martin) This is in relation to the release object stored in the namespace, not the rendering engine itself Part of it is because we were encoding the gRPC protobuf. Once that was removed, we are now only encoding the JSON object. For example, enums If we’re planning on migrating Helm release objects from Helm 2 to Helm 3, we should work on a migration plugin that reads old release objects and spits out Helm 3 release objects. Action item: it’s suggested to write a proposal on how the complexities between the differences between Helm 2 and Helm 3’s object metadata and a planned proposal for moving forward (martin) CRDs - https://github.com/helm/helm/issues/5871 (farina) Idea from adnan. Farina threw something up to the mailing list for a call-to-action from community feedback If you have comments/feedback, please chime in on that PR Unsetting values keys for Helm 3: https://github.com/helm/helm/issues/5834 How do we want to address this? Deprecation or remove it? Farina: how would you unset it in a values.yaml file? Adam: when you set a value, that value is persisted throughout the release history. If it’s explicitly set as `nil`, then we can explicitly check for new values A simple example of this is probes. It’s becoming increasingly common to unset values for execute vs http probes If time, check in about Lua chart post-render overrides (Scott) Assignments Issue Sherpa Moderator Scott Notes Michelle June 6, 2019 Announcements Helm has a new home for downloads: https://get.helm.sh Three main benefits to this move: No more changes required for users if we have to switch storage providers in the future Users in China can now download the Helm client using official download URLs. No mirrors required! Global content delivery via CDN. Downloads should be faster across the globe. Helm Summit CFPs are closed now Program Committee is reviewing the CFPs. June 14/15 is when the reviews finish and the co-chairs will do the scheduling. More to come. Standup Brian Mic not working Moving and Lua work Matt Butcher Gone all week. Just been tracking issues Matt Farina Working on being able to detect individual resources Looking into popping those up into the capabilities object for checking if resources exist The Helm Hub is receiving about 5-6 new repos per week, so working on some of the growing pains over in monocular Michelle Working on helm test refactor Updated the helm test proposal based on feedback Updated people interested in helping with helm test work Matt Fisher Migrated to get.helm.sh. No downtime or issues. Yay! Working on community PRs for Helm. In particular Helm Discussion Alibaba Cloud hopes to book a slot to share a bit about its “Helm Hub China” project which is non-profit mirror of hub.helm.sh in China with speedup and localization. (Lei Zhang) Slides: https://speakerdeck.com/resouer/helm-hub-china-project-from-alibaba-cloud Things hosted in Google & S3, like charts and images in them, are not available in China Localization! That includes content in charts? Yes! We: 1. periodically clone charts from hub.helm.sh, 2. replace unavailable contents (storage, registry etc) in the yaml, 3. CI verify the Charts can run on a local k8s 4. publish “localized” Charts to Helm Hub China portal Built on chartmuseum, free to use, storage in Alibaba Preview at developer.aliyun.com/hub Still in development We would like to link to this when it launches Unsetting values keys for Helm 3: https://github.com/helm/helm/issues/5834 (Taylor) (fisher): Taylor is out today due to on-call work last night. He mentioned Scott may be able to talk about this Assignments Issue Sherpa: Moderator: Matt Farina Notes: Matt Fisher May 30, 2019 Announcements Everyone survived KubeCon Helm Summit CFPs are due 5/31 Please submit CFPs, especially use cases for Helm! Helm Hub charts available over registry here to play with: bundle.bar Standup Taylor KubeCon Working on CFP Helm 3 tasks Butcher Reviewing PRs this week Will be out next week, so not much Josh Issue sherpa last week, looking into a few issues with Regis Nikhil Watching KubeCon videos and responding to issues Scott Fixed Helm Hub automation. Thanks to Matt for reviewing Want to understand what we will be able to do with LUA for charts for Helmv3 (can discuss afterwards) Brian Been moving, so a lot of packing Hoping to get back to Lua development for Alpha2 Looking into the go reflect layer Fisher At Kubecon, Deep dive with Adam + Intro with Michelle Expense reports, getting back into the swing of things Martin At Kubecon last week as well Issue triage, PR reviews, and answering questions in Slack Is next week the review of CFPs? [Fisher] Hoping to get more information out on this from the Program committee ~Wednesday next week Updates to the release checklist, and get back to migration Farina Charts and Helm hub Helm hub is now automated! Yay! Discussion Features added to Helm 3 project board so community can help deliver Helm 3 release [martin] Created this so folks can pick up features off the board and work on it. Board is at: https://github.com/helm/helm/projects/1 Core things that we want to get done now; can build on top of it later (e.g. XDG directory changes will break compat, but will be good) We have a window to get changes in that have a potential to be backwards incompatible. Signing and container repos [matt farina] How do we go about sticking charts in container repos Provenance file has hash of package, signed using gpg keys Container repos don’t necessarily have the same hash in different container repos (e.g. docker-distribution, quay, etc.) Interesting conversation with OCI folks: Why does the hash change across container registries. There is the index, and the container layers + metadata. The index changes over time, but the content is unchanged? Radu has been looking at this as well for CNAB (how do we sign the bundle and get one signature that we can use to verify across repositories). How does this work with tuf and notary? We have alternatives to GPG keys as well -- some folks want to use PKI instead. Helm is different in one way -- you can sign locally and upload the chart and provenance separately. This is because the hash doesn’t contain the name of the repository. Could also look into some of the other things like hierarchical key distribution vs. flat. Registry things undiscussed [josh] This is a longer discussion, so probably a better idea to schedule a 30+ minute slot to hash this out. Play with bundle.bar -- there are now ~600 charts 2.14 + Azure issue? [josh] https://github.com/helm/helm/issues/5788 Issue where helm keeps logging out when login is done with az-cli Since this is an ecosystem problem, this will be a problem with kubectl Looks like an issue with a backwards incompatible change with client-go Check to see if there is a corresponding issue with Assignments Moderator: Matt Fisher Notes: Matt Farina Issue Sherpa: Matt Fisher May 16, 2019 Announcements v3.0.0-alpha.1 released (Hooray!) 🎉 v2.14.0 released ☘️ KubeCon/Cloud Native Con EU Barcelona, Mon 20 - Thu 23 May (next week) - No dev meeting next week (23rd) CFPs due May 31st Standup Butcher PR reviewing for v3 Fisher Working on v3 Alpha.1 v2.14.0 pairing with Martin Preparing for KubeCon Helm 101 and deep dive talks Michelle Preparing for KubeCon WIP: helm test framework Adam Working on v3 Alpha.1 Preparing for KubeCon Taylor PR review Preparing for Helm workshop on Monday at KubeCon Martin Yay last library/charts functionality went in! Also fixed the dry-run output for v3. Shadowed v2.14.0 release to get that out the door. Nikhil Issue sherpa PR reviews Farina Cleanup of owner files Issues PRs (lint work etc.) Discussion Karen is looking to do more with our community blog. We’d like to make it easier to contribute blog post topics. PR #84 is a place to start. It adds a document that people can us to contribute blog post topics. We can iterate on this process and create a full fledge form, blog contribution guide. Thoughts? (Michelle) Seems like a good approach Michelle to chat again with Karen Some topic raised in community (Martin): Multiple environment best practices Micro-services best practices History/state stored details We should create a helm org maintainers mailing list if that’s not already a thing and publish it on the communication doc of the Helm community repo so people know where to have discussions around cross cutting topics that concern the helm community and github org. (Michelle) (fisher) I believe this already exists, we just need to document it: cncf-helm-maintainers@lists.cncf.io (michelle) that is for helm core maintainers I believe. We need one just for org maintainers in case people higher order concerns and concerns across multiple projects. I don’t see where the cncf-helm-maintainers mailing list info is published. We should also make the goal of the mailing lists clearer. cncf-helm-core-maintainers@lists.cncf.io is for core maintainers, but cncf-helm-maintainers is for org maintainers. It’s a little unclear for sure [Action] Farina to document the different mailing lists People have been asking how to help and get involved. We could have a github project board for “roles” that we need. i.e. “someone to triage helm 2 issues”, “someone to triage helm 3 issues”, someone to help with release management”, “someone to help us figure out a release planning process”, etc. Kubernetes has a role board for this. (Michelle) Assignments (for the 30th (week after KubeCon)) Moderator: Adam Notes: Nikhil Issue Sherpa: Josh May 09, 2019 Announcements CFP May 31st Standup Adam Missed last week due to a team meeting Working on some core reviews, prepping for the first alpha release Published a proposal on the v3 release rollout Josh Working on the oras project, getting things like `helm registry login` implemented for Helm 3 Martin Mostly working on PR reviews Thinking of the v2 -> v3 migration document Matt Fisher Missed last week due to a team meeting Figured out things left for Alpha release Worked on proposal Working on solution for moving out of Google Cloud Storage Brian Missed last week due to a team meeting Working on conversion packages from Go to Lua Working on prototype code for Alpha 2 Matt Farina Issue sherpa Pulling over v2 commits needed for v3 Matt Butcher CNCF meetings for graduation Security audit after Beta 1 of Helm 3 Good progress on graduation and good feedback New branding for Helm 3 release inc. CNCF org look and feel KubeConEU sessions and workshops filling up Org maintainers maturing Some PR reviews Discussion Proposal: Rollout of v3 release #5695 (adam) High level plan of deliverables Can add comments to the issue Helm 2: Anything else we should get in before we cut v2.14.0-rc.1? (fisher) We should get in the postgres storage layer PR in (butcher to review): https://github.com/helm/helm/pull/5371 Demo: https://get.helm.sh (fisher) Nice demo :) Opinionated OCI namespacing/versioning + dropping search + repo subcommand as plugin (josh) Assignments Moderator: Matt Farina Notes: Josh (Martin to deputize) Issue Sherpa: Nikhil May 02, 2019 Announcements Standup Farina Working on search (starting with API on Monocular/helm hub) Sprig and SemVer new major release planning with Dr. Butcher Butcher His team putting out a series of Helm 3 blog posts on the MS blog Most of his team at DockerCon and breakout to work on Helm 3 Looking for Alpha v1 by KubeCon EU Martin Triaged issues Issues to v2 and v3 on scaffolding charts From the community Morten Issues with proto files and get the generation and tests working Working on a fix Discussion https://github.com/helm/helm/issues/5664 Can’t switch default behavior because it would break scripts using helm in the wild A flag could be added for this feature to opt-in to it https://github.com/helm/helm/issues/5650 We don’t have a precedence for doing this. The pattern we have is to link to external related docs How is Helm going to handle CRDs? We needs docs on CRDs Ability to detect if CRD is installed as part of crd-install hook and/or capabilities CRDs are HARD! [farina 2019] Assignments Moderator: Butcher Notes: Martin Issue Sherpa: Farina April 25, 2019 Announcements Helm Summit update [Michelle] Helm summit CFPs are now open at: https://events.linuxfoundation.org/events/helm-summit-2019/program/call-for-proposals/ Priyanka Sharma Standup Taylor Thomas Working on PRs this week, reviewing feature PRs Should think about cutting 2.14 after KubeCon at least the rc for it Farina Monocular search API work to tie it into helm search for v3 Foxish has become inactive on charts… moved to emeratus Reviewed PRs, yo Nikhil Out last week Getting back into the swing of things Martin Out last week Getting back into things Did some PR reviews and put in a few PRs Made it to the program committee! Woo Will go back to working on the helm v2 -> v3 migration docs Michelle Helm test PR is in - works now! Trying to finish up refactor, so others can jump in as well. Also working on the Helm Summit stuff Butcher Out last week Took a look at a bunch of code that Brian wrote on the lua repo Will meet with Adam later today Brian Working on the lua runtime Getting all of the latest code out Adam Reviewing PRs Longer reviews because PRs are touching similar parts of the codebase Getting those reviews finished up this week Ian Getting new tests in before EOD for testing for subcharts on the schema validation PR Dan Garfield Chatted with Josh about migrating CICD to use codefresh Started working on the migration Hoping to get things in a place to review by next week Scott Rigby Looking at the doc this afternoon There is a regression from something added to helm values coalescing. It’s a key deletion issue. Someone else took that on to fix it. Reviewing that PR. Will paste in helm-dev. Would like another person to review that. Discussion How detailed should our CONTRIBUTING guide be? https://github.com/helm/helm/pull/5346 This PR may target different audiences specifically people who are not familiar with GitHub. Is that what we want? [Martin] [michelle] Copy/paste command options are nice for even power users of GitHub [Taylor] Matt Farina will follow up and merge PR $schema in values for json schema? https://github.com/helm/helm/pull/5350#issuecomment-485852606 Multiple editors support the top level $schema line but it’s not part of the official spec. Informal thing. If someone copies/pastes a values file, they still want that validation but it’s again not part of the official spec Matt Farina will open a separate issue so we can have an async discussion on it and sit on it for a few days https://github.com/helm/helm/pull/5601 [Adam] This is something that is used in the stable charts today. Do we want to break compatibility with v2 here? We could potentially create tooling to convert charts V3, migration and users [Martin] Assignments Moderator: Taylor Thomas Notes: Matt Farina Issue Sherpa: Martin Hickey April 18, 2019 Announcements Helm Summit update September 11-12, 2018 in Amsterdam CFP form and conference website is live Be on the lookout for program committee notifications Link: https://events.linuxfoundation.org/events/helm-summit-2019/ Standup Fisher Working with Ronan. Ronan has been working on the Helm 3 design work and the Helm Summit logo. Trying to get multiple different versions of the helm documentation available on helm.sh so that you can click between versions for documentation Looking at how Jaeger has done it for their documentation Working with Bridget as well on this stuff Re-integrating OCI work into top level commands. Helm package,etc. Michelle Pretty deep into the internals of `helm test` for Helm 3 Using client-go for watching the test pods Trying to refactor the unit tests for the working test run commands Josh Submitted the initial PR for registry login: https://github.com/helm/helm/pull/5597 Brian pushed branch to Azure/golua with the Go API changes. Working to solidify the function binding interface to finalize the standard libraries. Need to address runtime information collection on an error when unwinding the stack Adam Out last week with Flu Catching up on PR reviews and getting back up to speed Dan Garfield CodeFresh is interested in offering a grant to the Helm project to use for CI/CD and chart repository hosting Michelle: let’s follow up in the mailing list, and set up a meeting to determine what conversations we need to have RE: grants Ian Howell Made progress on schema validation Discussion Release/ReleaseVersion CRDs status+questions (Josh) Tillerless right now is still using configmaps/secrets/in-memory. Same as Tiller was. Switch to CRD would ideally be in alpha but if it has to get bumped, it may. Concern over RBAC and permission model Now, RBAC is mapped to user. RBAC will be identical to what kubectl does right now Define what Helm creates for you and give an overview on what permissions a cluster admin should give a user Josh will create a follow up issue Alpha.1 release (michelle) Looking at the board, most things for alpha.1 are in the review phase now. Should take about a week and a half Assignments Moderator: Adam Notes: Michelle Issue Sherpa: Fisher will follow up on mailing list for people April 11, 2019 Announcements Helm Summit EU updates [michelle] Helm Summit Program Committee form is now closed and will be announced soon. Helm venue and dates have been confirmed for September 11-12, 2019 in Amsterdam. lHelm Summit website will be launched next week along with the CFP form. Be thinking of topics for sessions, lightning talks, and tutorials/workshops. Standup Taylor Working on issue triage/PR triage this week Going to work on replicating a particular PR next week WOuld be great if someone with bash autocompletion could take a look at https://github.com/helm/helm/pull/5562 Josh Back from holidays Working on the oras project on the `helm login` stuff Matt Butcher Working on things related to the timeline and the Lua stuff Kubecon will be alpha.1 After Kubecon, we’ll be transitioning to further alpha releases (possible 3?) That should bring us to a beta around July That should be the time when we get a CNCF security audit, which should bring us to CNCF graduation Brian and I paired on Lua integration yesterday. Found a significant recursion issue where the stack isn’t being copied, so Brian’s working on a fix Matt Fisher Program committee stuff squared away for Helm Summit Paired with Josh on the oras project and getting up to speed on what needs to be done Specifically interested in credential handling Review PR #5441 (not rendering templates inside of library chart) is on the list of things to review Pairing with Ronan on getting alpha documentation for Helm v3 Martin Working on some PR/issue reviews and triaging this week Jumped in on the v2 -> v3 migration doc this week Michelle Working on Helm Summit stuff with Fisher, Karen, Ronan Picked up some of the helm test work Found a few rendering errors so diving a little deeper into the rendering/label selection code Scott Helping Reinhard with the charts-testing project Working to automate the Helm Hub Discussion What’s the process for creating new slack channels now that we’re part of the CNCF? [fisher] For context, Helm is now part of the CNCF. There exists a CNCF Slack, but Helm slack channels still exist in the Kubernetes slack. We have not had to create a channel since the CNCF migration, but Scott Rigby wants to create a channel for helm/chart-releaser Lachie mentioned last time he checked in January, the CNCF slack is only for CNCF related business and temporary channels on an ad-hoc basis CNCF projects like OPA and Kubernetes should manage and maintain their own Slack workspace Fisher will ask Scott to ask the Kubernetes org if they’ll create a channel for him Credential helpers for `helm login`? [fisher] Fisher and josh will pair together, but it looks like they work out of the box Assignments Moderator: Taylor Notes: Michelle Noorali Issue Sherpa: Matt Fisher April 4, 2019 Announcements Martin has been voted in as a core maintainer Standup Taylor: PRs this week, around the atomic flag Review deleting resources Continue on with PR reviews Martin Working on 2 PRs for the `make docs` target for Helm 3 Lib charts and app version are ready for review on Helm 3 Fisher: will definitely take a look at those, just have some things working on at the moment Investigating a bug around removing a service account and how it isn’t removed from child dependencies (pods relying on the service account) Looking into another PR with `helm list`for Helm 3: Matt Fisher: Refactors in Helm 3 Looking at OCI integrations (refactoring). Full integrations of repo with Helm CLI. Blog post with Bridget for KubeCon EU Brian: Final integrations of the GO Lua projects Update soon in repo Adam: Working with PRs ands issues in Helm 3 Fleshing out idea of removing helm init and lazy creating Charts rendering as atomic units in progress Discussion Update on Helm 3 development progress [fisher] Assignments Moderator: Martin Notes: Matt Fisher Issue Sherpa: Taylor March 28, 2019 Announcements http://www.cloudnativeday.ca/en/program/ is looking for Helm speakers Helm program committee form still open for a day for Helm Summit… https://docs.google.com/forms/d/e/1FAIpQLSeMWnylHu1Yi6SmwKYvitrJxqNpBVAVXtMunjaiqkNAGkeG7g/viewform Standup Michelle Working on `helm test run`. Making it work. Looking into using k8s Jobs Threw out helm test results for now because there are a lot of decisions around storage that need to be made and it’s not necessary right now. Brian Working on the path forward for Lua. Finishing up stdlib for lua tables. Defining api for getting values out of lua into go. Fisher Booked travel for giving KubeCon deep dive talk with Adam JSONSchema research Reviewed Ian’s PR Reviewing plugin arch Butcher On Vaca all last week. Missed everyone esp Adam Taylor MOVED HOUSES! Working with go modules, having a blast. Nikhil Away last week, this week reviewing issues and PR’s Adam Been doing prep for KubeCon EU, thinking about the deep dive session Doing some PR reviews around some of the Helm 3 architecture changes Looking over the client architecture with a fine-toothed comb (event interrupts, for example) Matt Farina Working on the Go modules stuff Found some issues with Go modules so we’re holding off, but we’ll have to keep a close eye on upstream work in this regard Let the community test it out and provide feedback Taylor: I have another PR with Go modules. Should we close this? https://github.com/helm/helm/pull/5520 Farina: looks like that’s for master vs. Helm 3 Discussion Is ‘make docs’ target still relevant? Ref: https://github.com/helm/helm/pull/5458 Intent was to keep the target around so that users can have the option of generating docs There is an effort for helm v3 to take the docs under a different location Mhickey will take it offline with folks to work out what the PR needs to evolve to. Lua in Helm v3 and golua [mattfarina] There are a few bug fixes that need another review for Helm 2.14 [fisher]: https://github.com/helm/helm/pull/4871 https://github.com/helm/helm/pull/5112 https://github.com/helm/helm/pull/5395 Assignments Issue sherpa: Nikhil Moderator: Matt Fisher Notes: Martin March 21, 2019 Announcements 2.13.1 Standup Josh There was a chartmuseum bug that affected Harbour, waiting on a response from them Continuing work on the Helm 3 repo docs Matt Farina Poking at Go modules a bit, as the next version of Go enables it by default Brian Working on the Go Lua standard libraries based on some of the core changes over the past few months Pairing with adam today on the lua implementation for Helm Matt Fisher Working on the XDG base directory PR Lightly reviewed Ian Howell’s schema values PR, need to manually review Working on a Helm 3 high-level overview blog post Matt Butcher On vacation for the next week Discussion Lua timeline/milestones [josh] Wanted to clear up some of the story for Lua in far as Alpha is concerned Brian: so the current idea is to use it as an overlay as part of the rendering engine Josh: based on prior information (Matt Butcher’s blog post on sweetcode), I thought we could pass in a chart metadata, values etc. into the lua engine to generate pods. Fisher: can we propose to discuss this next week? We don’t have a physical integration of Helm and Lua at this point yet General consensus is to table the discussion once we have a Helm/Lua integration Helm 2.13.1 release [fisher] Matt Fisher will go ahead and release 2.13.1 Assignments Issue sherpa: Matt Fisher Moderator: Matt Farina Notes: Adam Reese March 14, 2019 Announcements Standup Josh Met with a few people this week about the Lua subsystem to discuss how that relates to Helm 3 Working on the Helm 3 repository documentation Matt Butcher Helm Summit planning (EU) Sprig updates PR reviewing on community PRs Martin Sherpa-ing PR reviews PR for standard application charts (library charts) #5441 Helping on slack channels Adam Met with people about docs changes (v2->v3 changes) Label for PRs that require a Vanity import path Scott Fixed Helm Hub search Looking into Hub deployment automation LastPass setup CNCF prefers we use this Fisher Helm 3! Refactoring “helm template” to action pkg Major action pkg refactor (thx adam) Community PRs PR for storing Helm Home in XDG spec https://github.com/helm/helm/pull/5443 This coming week working on FAQ, planning etc Justin Triage, catching up starting tmrw Discussion Deprecate “helm search” in Helm 3? [josh] Sent a message to mailing list asking if anyone uses this and received no response Has no function in a CI/automation setting “Underpowered” since it only looks at local cache Users can go to hub.helm.sh Once remote search is rolled into OCI, we can add this feature back (in 3.1, 3.2 etc.) Should we cherry-pick https://github.com/helm/helm/pull/5423 into 2.13.1? [fisher] Vanity import path #5440 [adam] “helm.sh/helm” Separates Helm 2 and Helm 3 in go path Open PRs will have to rebase There is a sed script to do this Will enable other proj under the Helm org When should we cut a 2.13.1? [fisher] Lua timeline [josh] Assignments Issue sherpa: Martin/Justin Moderator: Josh Notes: Matt Fisher March 7, 2019 Announcements Program Committee Applications are now open. Please fill out this form if you’re interested. Deadline to apply is March 29th, 2019. [michelle] Helm Summit update [michelle] Planning on Helm Summit 2nd week of September Venue in Amsterdam is on hold -- things are looking good. Look above for program committee application. Help conference chairs review CFPs. Adam / Fisher are two of the three co-chairs, we’re looking for a 3rd from the community (fill out the checkbox at the end) Standup Butcher Opened a PR on Helm 2 to update the version of sprig to one that should be used. Nikhil Working with a customer engagement so nothing to report this week Adam Past week -- Helm 3 momentum picking up. More to come during the Helm 3 discussion. Lot of refactoring of the engine package - diving in to the go-templates package. Michelle Took some time to work on helm-test. Helm test run is now a subcommand. Digging more into getting the test response back. Refactoring the initial proposal for helm test. Revising the proposal to continue using anotations and adding support for test suites Fisher Pairing with folks to figure out Helm 3 project planning. Late last week - bigger refactor for action package. Will return to that to figure out what can be pulled out to make it cleaner. Adnan Not much this week Josh Not a huge lot, still trying to mess with LUA and connect with Brian Get Helm repo docs out by end of the week. Martin Libchart -- should have a PR by tomorrow. Looking at a few issues on the Slack channel and answered a few questions Took a look at issues tagged with good first issues and have some feedback -- some of these have changes and might not be good first issues any longer. Farina A lot of chart stuff including reviews. Helped Fisher with some Windows stuff and was psyched! Security process for the Helm org document is up. A big shout-out to Fisher for getting the Helm 3 project plan organized! Discussion Make crd-install hook idempotent [mattfarina] Charts repo is seeing issue from this Error if the content is different on first pass In the future we could discuss a flag that allows overwriting if different Was also proposed over on https://github.com/helm/community/pull/64 Discussion: Make CRD hook idempotent -- could this be a problem? Should work, but the trick is deleting the CRDs. Case where 2 things install the same CRD => we should be able to achieve this including for Helm3. (Adnan) built a workaround Helm 3 status update [fisher] 👈 https://github.com/helm/helm/projects/1 The goal is to understand what are the things we are quantifying for an alpha release of Helm 3. Paired with core-maintainers to figure out what should be in an alpha release. What we have currently, and what we would like to have in there. When we go through this backlog, we should be able to cut an alpha release. Feedback / Comments: This is awesome! Thanks! Changes with Helm 3 fall into different buckets. E.g. LUA, repo, tillerless, etc. Does it make sense to make labels for these bigger “themes”. Might be difficult to do since lines are sometime blurred between components. E.g. refactoring of the engine piece. This would help with filtering by theme -- especially as we add more items to the board. There might be a parallel with SIGs, perhaps? This might be a good thing to add at some point later perhaps when we go from alpha => beta. (fisher / josh) Let’s table the discussion for now and revisit this once we are a bit further along. #helm slack channel moderators, we need them [mattfarina] https://github.com/kubernetes/community/blob/master/communication/moderation.md We’re in k8s Slack and they are looking for moderators. Especially in EMEA / APAC region time-zones. Don’t need to necessarily need be core maintainers. It would be good if anyone in the community can be Slack moderators. Request for feedback on resource policy PR: https://github.com/helm/helm/pull/5092 Has to do with deleting manifests. Call to folks who understand this space to comment. First commit is what’s changing in the application logic. There might have been some uncaught changes -- so might be good to run some manual tests. Fisher will have some time to hopefully take this on last week. Assignments Issue sherpa: Martin Moderator: Fisher (/ Adam, tag team) Notes: Josh February 28, 2019 Announcements Helm 2.13.0 was released yesterday The first release that is PGP signed. Go try it out! Standup Michelle: Helm v3 test Taylor Today will be trying to get through a PR from a community member Josh Diving deep into GoLua Going to experiment with embedding the Lua engine in Helm 3 Fisher Paired with Farina on the Helm 2.13 release Working on the Helm 3 action package refactor Butcher Kubernetes meetup in Boulder with ReactiveOps Might be a good team to contact on the action package refactor Brian Working on the GoLua compiler for parity with luac Using the output from gluac against the lua runtime for testing Moving some code around but should hopefully be merged in the next few days Pairing with Josh next week on Helm and Lua Martin Working through some PRs to close them out Issue triaging Matt Farina Working on CII best practices for CNCF graduation Ian Howell Working on the JSON schema Question: should we generate a JSON schema out of the gate? Solution: there’s not a great answer for this but Ian’s been playing with a few solutions. Play around a bit and see what happens Nikhil Nothing to report this week Discussion v3 contributor work (mhickey) Fisher and Adam working on this to get some of the initial pieces out (client-package, v3-board) so that we can move forward. Would be useful to have a discussion, perhaps on another call, about helm 3 specific pieces. Perhaps an hour long backlog grooming session (post-it note style?). Schedule a time for this when Adam is back? How can other contributors help with this, to get this unstuck / moving? Fisher will come up with a workable list of helm v3 basic issues and float it to the rest of the team. Good first issues (mhickey) We have about 9 of them, 6/7 of which are somewhat stale. Mhickey will put in some comments and float it to other folks on the project. List of good first issues: https://github.com/helm/helm/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 OCI Update - not much to share. Folks were okay with using the manifest / index at the top layer (Steve / Jimmie’s proposal) Not clear if there are any changes here. There were some discussions on the index and the media-type on yesterday’s call. Would be useful to look through the notes of yesterday’s call. Notes from yesterday’s OCI call: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2019/opencontainers.2019-02-27-21.59.html Latest Proposal using manifest.config.mediaType but no solution at the index: https://github.com/SteveLasker/RegistryArtifactTypes/blob/master/mediaTypes.md Farina will try to jump in and get some clarity here. Assignments Issue sherpa: Matt Fisher Moderator: Farina Notes: Nikhil February 21, 2019 Announcements Helm 2.13.0-rc.2 was released Tuesday Helm Summit Update: Waiting on CNCF to get back Looking at costs etc. Might know more by early next week Standup: Josh: Looking at the LUA language Adnan: Looked at library charts. Added comment to the issue. Michelle: Collecting feedback from CNCF projects for improvement Continue on Helm test Nikhil: Looking into v3 work Matt Farina: Reviews Crypto signing delivered with Matt Fisher Taylor: Going to be reviewing this week Brian: Meta tables in lua to override operators Adam: Working on builder to manipulate charts in lua Populate issue Matt Fisher: PR reviews Helm v3 action package refactoring Martin: Library chart feature merged Scott: Laser github app Discussion Lua plans? https://github.com/jdolitsky/goluamapper Brian working on an idiomatic go interface in lua Not going to be modelling charts at start with lua Design shortly on the syntax of lua in charts 1MB limit w/ no tiller?, In Helm dev question about map being too big etcd limit: 1M . Not a limitation of Helm. All Kubs objects have this issue. https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/limit.md#request-size-limit Some discussions on using an alternative backend to etcd Assignments Issue sherpa: Martin Moderator: Taylor (not Josh) Notes: Nikhil February 14, 2019 Announcements Helm 2.13.0-rc.1 was released yesterday Helm repo working group call cancelled. Now gone to the OCI space. Join CNCF #artifact-registry Helm Summit Update Working with CNCF on a venue for September May need sponsors If your company would be willing, please contact Michelle and I will get you in touch with the right people Standup Michelle Merged PRs Working on POC for Helm test v3 Iterating on the initial helm test proposal for v3 Butcher Working on grpc changes Reviewed martins patch Discussion Scott: The Helm Community Incubator page hasn't updated in 2 years. Let's discuss what should be updated, if that hasn't already been done elsewhere? Adam: 2 LGTM policy for dev-v3 branch Fisher: will add this to the CONTRIBUTING.md in dev-v3 Asking for status: What is the status for Helm Summit 2019? Discussed in announcements Fisher: bringing back up issue #2039. How do we want to cryptographically sign Helm releases? Butcher: TUF/Notary looks like the right approach for v3 For v2 we probably want to cryptographically sign all the assets and upload the signatures via Circle Support "delete" resource policy in Helm 2? (PR) Fisher will have a look at it next week Assignments Issue sherpa: matt fisher Moderator: adam Notes: martin February 7, 2019 Announcements Good First Issue App added Twitter account will tweet out our issues if we put a label on it Standup Josh Helm 3 initial registry stuff merged! See PR #5243 We’ll have to continue the discussion around how this will affect the rest of the Helm commands Matt Farina Merged some PRs, talked on some OCI stuff Michelle Going to work on some new helm test stuff Brian Isolating difficult APIs in lua spec for manipulating tables Hybrid array+hashtable Refactoring on call stack to support proper tail recursion Matt Fisher Helm 3 PR reviews, PR reviews Looking at some Helm 3 things this coming week Giving dev-v3 a try on Windows, found some bugs CFPs! Taylor Wasn’t able to do much this week. Will be back to issue stuff and PRs this next week Nikhil Looking into curating issues in issue queue Adam Helm 3 stuff, mostly code reviews Organizing top-level stuff Martin Mix btw v2 and v3 Triaging a bunch of issues Starting on PR reviews V3: broke down PR for - Discussion What’s the status on #5210? Are we ready to cut a v2.13.0? [fisher] Upgrading GRPC for better TLS connection handling Need to check w Matt Butcher When the protos changes, people need to recompile their clients Is there a way for us to fix issues without updating grpc? Some community members are asking to cherry-pick a few PRs into a v2.12.4, most notably #5186. Should we cut a v2.12.4, and if so, are there other patches that need to be cherry-picked? [fisher] What’s the timeline for 2.13? Fisher will check with Butcher offline on the prior discussion item to get an idea how far out we are from a 2.13 Is this proposal are runner for v2/v3: https://github.com/helm/helm/issues/3279 ?[mhickey] Different than other tests, leaves pods around Take a look at v3 proposal (link me) Helm Summit update [michelle] Still confirming an Amsterdam venue 2nd week of september Working on program committee application GSoC ?? [josh] Ooo missed the deadline (yesterday) Assignments Issue Sherpa Fisher Adam (v3) Martin (v2) Moderator: Adam+Michelle COMBO Notes: Martin January 31, 2019 Announcements Standups Brian Working on refactoring Matt Farina Adnan Abdulhussein Michelle Noorali Taylor Reviewed atomic flag PR Working on issues/PR this week Martin v3 work: Lib chart feature Helm v3 status https://github.com/helm/helm/projects/1 Initial registry support PR: https://github.com/helm/helm/pull/5243 Discussion Consider installing https://github.com/rajatjindal/goodfirstissue for helm org (Rajat) What is Helm support of CRDs? Can it handle large CRDs? Open issue: https://github.com/helm/helm/issues/4697 This will need to go to SIG Apps because of the wider scope of what this will affect. Helm Summit Update Working on locking down the venue and getting the CFP things ready https://github.com/helm/helm/issues/3279 : Proposal for v2/v3? https://github.com/helm/helm/issues/5242 CNAB Assignments Issue Sherpa: Nik Notes: Josh Moderator: Adam January 24, 2019 Announcements CVEs for Helm+ChartMuseum vulns Helm: (link me) ChartMuseum: (link me) Helm Summit is being rescheduled from March to the second week of September Need more time to lock down venue + give travel time to attendees Standups Michelle Issues and PRs triaging Active in #helm-dev Scott Met w farina about Helm Hub deployment automation Setup on CNCF service Matt Butcher https://github.com/helm/helm/issues/3480 : connect btw helm+tiller having issues, unsure why. “write: broken pipe” Matt Fisher Investigated #3480 Helm 3 repo discussions Trying to offload some work from Adam OCI docs based on meeting yesterday Josh OCI/Helm repo convos Need to look into search + auth Working on dev-v3 fork for push/pull Matt Farina Helm Hub: how do we scale? # of charts, user experience, etc Potentially contractors from CNCF OCI fun, specs Nikhil Closed out a couple issues, sherpa-ing some others Adnan Monocular issue/PRs Martin Issue sherpa-ing, passing things along Closed out some PRs Looking into v3 features Helm v3 status https://github.com/helm/helm/projects/1 Discussion Could we recap our approach to how we handle v2 fixes while the v3 branch is not yet accepting fixes (or maybe it is accepting them?). Is there a list of fixes waiting to be merged? Is there a tag that we should apply to v2 fixes that need to be ported across later? Etc. etc. (henrynash) We need a clear policy...which is that v3 IS accepting fixes. New label: #needs-v3-fix Place this info somewhere, contributing.md (henrynash to do) What is Helm support of CRDs? Can it handle large CRDs? Open issue: https://github.com/helm/helm/issues/4697 Need to punt to next week when Adam returns. He had some actions on this and we don’t know the state ChartMuseum + Monocular in Helm 3? Monocular: need to change to own the Helm Hub experience ChartMuseum: ??? What do we invest in terms of Google Summer of Code Google Summer of Code: what projects should we propose? Deadline for org submission: Feb 6 Deadline for students: April 9 Assignments Issue Sherpa: Nikhil Michelle Notes: Michelle Moderator: Fisher January 17, 2019 Announcements Helm and ChartMuseum security releases out Standups Nikhil (had to miss call due to a conflict) Last week, mostly worked on curating our issue queue. Hope to have some time to spend on it this week as well. Fisher: had to miss due to an AKS all hands Last week: participating in the helm 3 repo discussions, getting ramped up with Helm Summit committee prep, triaging tickets This week: wants to write a blog post on the current status of the Helm 3 repo discussions Butcher: had to miss due to an AKS all hands Farina: ChartMuseum and Helm security release work Took charts in container registries to the OCI for direction. Jimmy Z has a strawman that was generally accepted at the OCI meeting Josh ChartMuseum security release v0.8.1 Chart-scanner to check for the vuln: https://github.com/chartmuseum/chart-scanner Things moving along w Helm 3 repos stuff, chats w OCI team Life status changes Martin Delivered a feature for v3 Did issue queue triaging Helm v3 status https://github.com/helm/helm/projects/1 Discussion Helm can have an intro and/or deep dive in KubeCon+CloudNativeCon Barcelona. Who from the core team is interested in submitting to do an intro and/or deep dive? 2 maintainers per slot. [Michelle] Should we support the --token and --insecure flags on helm v3? These are flags on kubectl. https://github.com/helm/helm/issues/5159 Discussion on Bazel in helm… https://github.com/helm/helm/issues/5160 Likely pushing to a plugin Assignments Issue Sherpa: Martin + Adam Notes: Josh Moderator: Farina January 10, 2019 Announcements KubeCon+CloudNativeCon Barcelona is in May and CFPs are due Jan 18th. Reach out to Michelle for CFP reviews if you’re interested in submitting and would like some help/guidance/advice. Parallel flag PR got merged on helm test! Woot! Standup Josh Been working on getting helm push/pull working. Has a working example! Should be ready to PR in a week Fisher Not too much to report this week. Going in to the helm 3 repo discussion and continued issue triaging Michelle Been issue triaging on issues for the past few weeks If you aren’t working on Helm 3, we need your help to triage the large number of issues that still need it Triaging #5118 Scott Helping in the different repos as time permits Working on a tool to help people get a helm repo from a git repo is on hold Adnan Not much for this week Adam Pretty much just Helm 3 work Matt Farina Working in the fun filled world of process. Need to get process things in place like a security reporting process before we can graduate Have been meeting with the OCI people Nikhil Just got back from holidays, not too much to report from last week Will be issue triaging this week Taylor Try to spend a little time tomorrow to triage the issue queue Butcher Trying to stay on top of the repo stuff Doing a bunch of Helm 3 work Getting close to having Helm Summit EU dates Brian Getting back into the swing of things after holidays Helm v3 status https://github.com/helm/helm/projects/1 Merged a few PRs in to the v3 branch Matt Farina is working on an actions package so other projects can consume it if desired Code cleanup around build targets, makefile, infrastructure Adam is focusing on the chartutils package Discussion Helm Summit 2019 - When? Where? How to help [carlos] Michelle and Adam volunteered to start getting things rolling with CFP and the like Should we cut a v2.12.2 with https://github.com/helm/helm/pull/5132? [fisher] We should validate that this is the same validation that k8s uses Is this something that should be documented vs. a bug fix? There was a new name restriction put in place for 2.12.0. This wasn’t quite up to spec to support subdomains All hands on deck with issue triage and PR review [michelle] If you’re a core maintainer and not working on helm v3, please help in the issue and PR queues this week. If you’re a community member and would like to help, please help with issue triage or reviewing PRs. Leave comments on the PR or an LGTM in a comment on the PR. If you’re ready to put a label on an issue, tag Michelle. If you’ve given an LGTM on a PR and need another lgtm, tag Michelle in the github comment on the PR. Helm 3 repos working group update Go lib “oras” for pushing any file to OCI-friendly registry: https://github.com/shizhMSFT/oras Demo: Cleaning up hooks - https://github.com/helm/charts/pull/10400 [adnan] Should Helm CLI should have an option to delete hooks & other dependent things on delete Assignments Issue Sherpa: Michelle + Nikhil + everyone Notes: Scott Moderator: Adam January 3, 2019 Announcements Helm 3 repos Oras: POC pushing arbitrary data to a container registry https://github.com/shizhMSFT/oras Standup Taylor Working on diff issues and PRs as needed Michelle Triaging issues Wants to pair with people interested in issue triage Brian Coroutines for Lua VM, Lua compiler Fisher Knows rust now Josh Worked on oras ? Helm v3 status Likely same place as pre xmas Discussion Organize/sort release notes #5119 Bugs and features are not distinguished Also see https://goreleaser.com Feedback https://github.com/helm/helm/pull/5110 Adding things to “helm create” Need to work w charts maintainers They have been assigned to the issue Helm repo updates Working w OCI on next steps Whitelisting mediatypes Search spec, to support “helm search” against only charts (not images) #opencontainers IRC channel on freenode OCI mailing list: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev Assignments Issue Sherpa (2): 1: Matt Fisher 2: Michelle Notes: Taylor Moderator: Josh ``` ================================================ FILE: community/meeting-notes/2020.md ================================================ --- title: Helm Minutes for 2020 --- ```txt December 17, 2020 Assignments for this meeting Moderator: Marc Notes: Karena Issue Triage: Butcher Announcements 3.5.0 Milestone · GitHub - 3.5 RC1 will be cut on Monday Jan 4 2021, and 3.5 will be released Wednesday Jan 13 2021. Half PRs still open OCI- found issues, Farina will work on it over the break Whatever gets in this year is what will land This is the last Helm weekly developer call of 2020; no call on Dec 24 or Dec 31; the Helm weekly developer call will resume on Jan 7 2021. Discussion [Joe Julian] I’m off the rest of the year. Can I please get my PR merged before I go since I won’t be around to keep rebasing it before RC1? Reduce linting severity for users of out-of-date kubernetes #8608 Bridget: it’s in the 3.5.0 milestone - when do those get reviewed/merged? Farina: hopefully reviewed by end of the week December is a terrible time to get features into Helm Farina: with mature projects, esp this time of year, takes longer. Slower at merging since reviewing with other maintainers to consider implications Joe: concerned since using a fork for their linter now Joe: wondering as first time contributor what should have done differently Farina: thank you for the feedback [Shoubhik Bose] Engineering architect for GitOps Would like to have more disciplined approach to contributing Best way to understand from list of PRs for where to contribute? Looking at milestones [Bridget] yes, looking at milestones is great [Farina] one of best - look at PRs and walkthrough Start walking through and test Give feedback - not just when something is wrong, but when something is good For people who want to be maintainers - get the title once you’re already doing it [Bridget] what if we run a new Helm maintainer workshop Walk through the process Have more senior maintainers act as mentors Bridget to work with Butcher and CNCF Assignments for next meeting (Jan 7th!) Moderator: Bridget Notes: Karena Issue Triage: [at least 3 needed] Matt Farina Shoubhik for non-core maintainer issue triage Josh for 3.5 issues December 10, 2020 Assignments for this meeting Moderator: Marc K Notes: Bridget Kromhout Issue Triage: Matt Farina Announcements Helm 3.4.2 patch release yesterday 3.5.0 Milestone · GitHub - 3.5 RC1 will be cut on Monday Jan 4 2021, and 3.5 will be released Wednesday Jan 13 2021. The last Helm weekly developer call of 2020 will be next week on Dec 17; no call on Dec 24 or Dec 31; the Helm weekly developer call will resume on Jan 7 2021. K8s.dev contributor celebration this friday -> sunday https://www.kubernetes.dev/events/kcc2020/ Kubecon CFP closes Sunday 13th 11:59p. https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/#overview Bridget volunteers to review your talk proposal! Discussion [Tim St. Clair] - Helm 4, modularity, and pluggable templating. Tim St Clair: Saw KubeCon NA 2020 talk about past/present/future Tim St Clair: Is familiar with templating issues Tim St Clair: Used to be Heptio/RH, and in vmware they’re seeing ytt - but the templating theme keeps repeating itself Tim St Clair: Interested in an abstraction layer around charts itself Farina: in Helm 2 we had a mechanism for setting templating engine - “engineyard” Farina: and nobody ever extended it! Existed, and nobody used it Tim: in this moment, the demand is now here Butcher: the right step is probably a HIP - now is a good time Fisher: possible opportunity of revving to API v3. Fisher: in a HIP we could discuss backwards compat, use cases, post-rendering Marc: Tim, would you also be providing implementation? Tim: I’d be working with a team to do so Helm v3.5.0 [Farina] - this is less than a month away - the core maintainers should please review over the next two weeks This is a small release but we do want to get it ready Helm meeting calendar vs Helm release calendar [Marc] Fisher: no objection to merging - we also use github milestones to communicate Farina: calendar is also for us Introductions Mark Fisher, Aaron Hurley, John Ryan - Tanzu team - https://github.com/helm/community/blob/master/hips/hip-0001.md Karena Angell - Red Hat Joe Julian - d2IQ - Helm needs for their customers Storage backend needs: https://github.com/helm/helm/issues/8977 [Joe Julian] Joe Julian - label selectors don’t work - either break up by namespaces or query the predictable-name releases by name Butcher: there is a pluggable system for alternative data stores John Ryan: how about WASM, Lua, etc? Butcher: web assembly is an idea on the table Assignments for next meeting Moderator: Marc Notes: Karena Issue Triage: Butcher December 3, 2020 Assignments for this meeting Moderator: Josh Dolitsky Notes: Dan Garfield Issue Triage: Bridget, Fisher, Martin Announcements Next patch release (3.4.2) will be Wednesday Dec 9 - add relevant issues/PRs to https://github.com/helm/helm/milestone/106 [Bridget] [Dan] Few things still need to happen in milestone. Review bugs in issue queue for 3.4.2 Tuesday is last day to put in Interested in being a Helm maintainer, reach out to Farina, shadow on Wednesday release available. Discussion Chart Examples in Docs [Bridget] [Bridget] We now have a request to update docs to refer to something other than deprecated charts (https://github.com/helm/helm-www/issues/965) [Bridget] Adam and I previously discussed a helm-org repo with illustrative example charts [Bridget] Not intended to be supported as production-ready, but meant to forestall the inevitable changes if we point to a third party [Bridget] any objection to us creating that repo under the helm org? Currently used repos are called chart-release and chart-testing - perhaps we could call it chart-examples? [Dan] How do we handle mentioning deprecated charts… Farina: Take something like ChartMuseum and point to it as example Farina: Or… Create examples repository and use it as example charts, use providence files etc all best practices. [Josh] Should we have examples of more than just charts? Farina: Let’s make sure we can use CI to test things, so, keep separate repos Resolution: yes, let’s have examples showing best practices including chart signing, and not claiming to be production-grade. Bridget, Farina, Garfield to tackle after holidays. Re: examples, we had a similar discussion here at Hashi about standardizing demos, and it ended up an internal group wrote an app ("HashiCups") just to be the example app for product demos. Probably not necessary to write a whole fake coffee shop storefront like our group did but it might be useful to have something like a "Helm guestbook" that exists just to be an example app for Helm chart examples. Passing arguments to post-renderer [Marc] (https://github.com/helm/helm/pull/9047) Idea is to split on space: --post-renderer "kubectl kustomize calico/kustomize" Backwards-compatibility issue? --post-renderer "./my binary.exe" Do we need a flag e.g., --post-renderer-args [Farina] breaking on a space is potentially unreliable, use environment variables instead [Marc] Fisher: https://github.com/helm/helm/blob/d3d1ceab4f30ef792195f6a2b0fbf36a3b300340/pkg/postrender/exec.go#L45-L67 [Josh] I vote to have the flag because you can’t always predict the binary you’re using. Use env if you control the binary, but the flag would be useful for the edge case [Marc] the goal here is to allow usage of “kubectl kustomize” as a post-renderer Resolution: Marc will review and comment in the PR Moving size labels to GitHub action [Farina] Currently a service hosted in helm hub cluster [Farina] Our size labels all come from a deprecated repo. Want to port into Github Actions instead [Fisher] Github Actions have been very reliable. Very in favor Conclusion: Farina will start working on moving sizing labels to github actions [Fisher] LGTM Translation PRs… when multiple people are committers and the lgtm comes from a committer? [Farina] [Fisher] We have LGTM’d our own PRs before when pair programming on a fix, but context is everything though… LGTM’ing your own code doesn’t seem to match up with the code review process. Is the committer LGTM’ing another author’s code and they only provided a few edits, or were they the original author? [Bridget] I review a lot of translation PRs. I compare the final result’s google translate with the English original to get a rough sense of what’s there, and comment if there’s an issue like a section being skipped. [Bridget] Issues arise in particular if they forked some time ago and are translating an old version of the page. [Bridget] I would like to recruit more maintainers from the various language groups for them to do this step, but I would want to formalize this final side-by-side check as part of the process. [Bridget] Can we get some of the people reviewing to be maintainers to actually check. When translations are behind it causes drift. Can we formalize steps. Conclusion: Garfield will go do some investigation into what might work best and discuss with Bridget and come back. [Josh] Congrats to Bridget and Fisher for winning the CNCF chopping wood and carrying water award! [dlipovetsky] action.List client is unable to return a list of all releases (#9028) [Fisher] Helm CLI does rely on statemask for filtering releases etc in the action package. Under CMD/helm/lists/go it calls action and returns. I *believe* the statemask is what’s setting the filtering. That might be a place to start looking for bugs. Issues with statemask in the past and design concerns with backwards compatibility. Open Discussion Assignments for next meeting Moderator: Marc K Notes: Dan Garfield Issue Triage: Matt Farina [no meetings Nov 19 2020 (KubeCon) or Nov 26 2020 (Thanksgiving)] November 12, 2020 Assignments for this meeting Moderator: Martin Hickey Notes: Josh Dolitsky Announcements Artifact Hub has experimental support for OCI charts [Farina] Using oci:// you can add in the artifact hub your OCI repo Security scanning supported https://artifacthub.io/ Helm 3.4.1 released - https://github.com/helm/helm/releases/tag/v3.4.1 First of release cycle Helm blog: https://helm.sh/blog/helm-release-process/ “First Patch Wednesday” Helm v2 EOL and stable/incubator repositories deprecated on this Friday 13th November Blog post by Butcher in progress Thats tomorrow charts.helm.sh new home for stable and incubator Kudos Matt and Scott (and charts maintainers) Please use Helm 3, no longer will receive fixes on Helm 2 tomorrow, friday the 13th Martin is OK with Tiller KubeCon/CloudNativeCon next week (17th - 20th Nov) Helm sessions: (link me) https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/ Butcher+Farina+Bridget https://kccncna20.sched.com/event/ekHz/helm-past-present-future-matt-butcher-bridget-kromhout-microsoft-matt-farina-rancher-labs?iframe=no&w=100%&sidebar=yes&bg=no Wednesday, November 18 • 4:55pm - 5:30pm Booth duty - bring your questions! Office hours Slot 1: Wednesday, November 18 • 3:00pm - 3:45pm Slot 2: Thursday, November 19 • 5:00pm - 5:45pm Slot 3: Friday, November 20 • 3:00pm - 3:45pm Discussion Request for Helm mapkubeapis plugin to join the Helm Org https://github.com/helm/community/issues/157 [Martin] Following the new HIP process, #? Farina to take a look and help drive it along Upcoming call schedule Will there be a dev weekly call next week (conf week)? [Martin] [Bridget] Keynotes start on Thursday Nov 19 at 1pm Eastern: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/schedule/ - Helm call is 12:30-1pm Eastern, so might not conflict badly? [Bridget] should we cancel the meeting for Nov 26 - US Thanksgiving? And Dec 24 (Christmas Eve), and Dec 31 (NYE)? We could have the last meeting of 2020 on Dec 17, then resume on Jan 7? [fisher] yes. We usually cancel dev call meetings on US federal holidays as well as the week during/after KubeCon NA when most of the maintainers are present. [Bridget] No meeting Nov 19, Nov 26; yes meeting Dec 3, Dec 10, Dec 17; no meeting Dec 24, Dec 31; Yes meeting Jan 7 and going forward. Do we have better/more stats on chart downloads now? [Bridget] Nope! Because GitHub Pages Charts that upgrade with an issue when the previous version used a deprecated API. Ref https://github.com/helm/helm/issues/9014 [Martin] Something using deployment appbeta (old thing), when you upgrade the chart, the old thing is not deleted due to new API versions “Documenting is better than magic” (lets document this edge case) Link to release calendar on helm.sh? [Marc] Marc will make a PR Assignments for next meeting (Dec 3) Moderator: Josh Dolitsky Notes: Dan Garfield Issue Triage: Bridget, Fisher, Martin November 5, 2020 Assignments for this meeting Moderator: Marc K Notes: Bridget Kromhout Issue Triage: TBD Announcements Farina: the stable and incubator repos are about to leave artifact hub Farina: we cut the 3.4.1 release on Wednesday Discussion Deprecation(s) Status Check [Bridget] 8 days to go Do we want a super-minimal blog post that just explains that if you do nothing else, you should do this: helm repo rm stable helm repo add stable https://charts.helm.sh/stable Farina: maybe a blog post to pull their stuff out of stable and incubator? Git history? Joe Julian: remind people to check requirements yaml Bridget: reach out to Scott Rigby and Matt Farina; draft last-minute tactical “what you must do” blog post. How do we communicate essential info about changes with people we’re missing via our usual channels? [Farina] Bridget] AKS emailed customers; GKE can’t do that but will do outreach [Farina] Do we have any Digital Ocean contacts? Farina: Minikube builds in a pop-up Marc: in a deprecation you can mention it in the tool itself Paul C: corporate users aren’t big fans of MOTD from internet Bridget: get their service providers to reach out, when possible? Martin: get people the message when they upgrade their tool Marc: perhaps optionally enable “helm announcement”? Farina: will consider and start a HIP From Paul Czarkowski to Everyone: (11:43 AM) a bit left field I just thought of we could have an announcements field in the index.yml of chart repos, and any time a person does a `helm repo update` they'd get a printout of the announcements. From Paul Czarkowski to Everyone: (11:44 AM) then we could have an announcements repo that has an index.yaml but no charts so people can subscribe to announcements by adding the repo Release histories not pruned. Since they are failures… should they be? https://github.com/helm/helm/pull/8881 [Farina] Farina: pruning only happens after a good installation - could end up with many failed Joe Julian: happens thousands of times in CI/CD Martin: technically a bug - but the logic from the last deployed release is valid Marc: let’s continue the discussion in the PR Lint all docs in Multi-doc yaml, should we include a new parser `k8s.io/apimachinery/pkg/util/yaml` ? https://github.com/helm/helm/pull/8862 [Martin] Should https://github.com/helm/helm/pull/8913 be merged to fix https://github.com/helm/helm/issues/8621 and new issue opened to cover other issues raised? Farina: two cases: if you have an empty template, or multiple docs in the yaml file - maybe there is an existing issue for the “multiple” case? Farina: we should merge both Joe Julian: I think the one you're thinking of talked about multiple empty documents in the file: --- --- --- Are internal commands subject to backwards-compatibility (helm docs) [Marc] Farina: Let’s put it behind a flag What’s the best source of replacement examples for the docs? (assuming we may not want to point at stable anymore) [Bridget] Farina: sounds good - could document best practices Bridget: who’s got questions or concerns around the changes? Joe Julian: we’ve been telling customers they have to upgrade Martin: you don’t have to change the version of Helm - but do have to point to the right places Marc: at a minimum, 2.17 would be important because of Tiller. Farina: we don’t have a solid date on when the GCR buckets will stop working Joe Thompson: question about the deprecation - what’s the emergency procedure in place? Farina: the current plan is every chart will point to an archive that gives an error Dan Garfield: should we yank it early? Bridget: let’s not make breaking changes during shopping holiday change freeze Martin: and remember, the archived charts will still exist. Paul: let’s not disrupt people for no reason Farina: charts.helm.sh is going nowhere. The google location is what we don’t control. Martin: so, change your URLs to charts.helm.sh! Assignments for next meeting Moderator: Martin Hickey Notes: Josh Issue Triage: Farina October 29, 2020 Assignments for this meeting Moderator: Adam Reese Notes: Bridget Kromhout Issue Triage: Matt Fisher & Bridget Kromhout Announcements 3.4 & 2.17 [Farina] upgrade! Discussion Deprecation(s) Update [Farina] Farina: Friday November 13th, Helm v2 support ends and charts stable/incubator go into archive mode Farina: Blog post going out tomorrow Farina: CNCF will post things Friday and Monday - also, Kube Weekly Farina: Removing stable and incubator from artifact hub on Nov 6th [Scott] discoverability will increase as charts get relocated to new repos Farina: helm/helm CI won’t break with the Docker changes Helm Hub -> Artifact Hub move [Farina] Can we get this PR looked at for the 3.5 milestone or before? Replace Helm Hub with Artifact Hub · Issue #8626 · helm/helm [Bridget] Farina: it pays to add your items early! Farina: we as a whole get the traffic to hub.helm.sh and are redirecting it to artifact hub - other choices include passing DNS to artifact hub in terms of them doing the redirect Bridget: does this affect stats? Farina: we can get that now (though it’s not super useful data - unsure what some of these queries are) Scott: of course we want to decrease our maintenance burden but we might want data Butcher: we shouldn’t be in the critical path - let’s instead help Artifact Hub craft good stats/reporting Farina: reach out to artifact hub maintainers for stats/data Farina: let’s redirect to artifact hub (affirmed by the call) Dependabot k8s patch updates and Helm patch releases [Farina] Check on packages that have bugfixes, if we consume them Fisher: sometimes these affect helm - a recent client release did Adam: let’s look at them and (usually) merge Focus on recruiting new maintainers [Butcher] Butcher: let’s form a sub-team to strategize about solving this Bridget: volunteers Adam: people may not want new commitments this time of year Fisher: we could start doing up-front work on docs and testing Karena Angell [Red Hat] would like to be more involved - wants clarity on what the Helm community _needs_. (Pradeepto B, in chat, is also on her team.) Butcher: as a group we need to identify who would make good core maintainers Butcher: we can mention it on calls Farina: have we documented being a maintainer? Adam: yes - it’s documented (https://github.com/helm/community/blob/master/helm-maintainers-onboarding-guide.md) Bridget & Farina will follow up with docs Generating docs for helm-www (not done for 3.4?) [Marc] https://helm.sh/docs/helm/ v2? https://github.com/helm/helm/issues/8869 [Bridget] this is a manual process - https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs Bridget and Marc will sync update chart repository dependency references https://github.com/helm/charts/issues/23971 [Marc] Farina and Scott will pair on this [joe] Can I get this merged? Reduce linting severity for users of out-of-date kubernetes · Issue #8608 · helm/helm Deprecated APIs were the reason originally - upstream has now started keeping this data, and this is useful Fisher: this has one LGTM - Adam will look at it Farina: added to the 3.5 milestone Assignments for next meeting Moderator: Marc Notes: Bridget Kromhout Issue Triage: TBD October 22, 2020 Assignments for this meeting Moderator: Fisher Notes: Martin Issue Triage: Farina Announcements (none this week) Discussion Helm v3.4 and v2.17 [Farina] RC1s out Plan is to release on Monday & blog post Monday as well Main release features: Default location for Tiller is GHCR (not to be confused with GCR!) New helm repo location Criteria to accept dependabot PR [Marc] Cobra 1.1.1 https://github.com/helm/helm/pull/8916 What is the criteria for sub-dependencies brought in by dependabot? [Marc] Is test passing sufficient? Fisher thinks for the most part it is good to merge There can be exceptions like k8s from time to time [Fisher] Need to check if licenses are acceptable [Farina] HIP 0002: Announced release dates [Marc] Ok to announce 3.5 for January 13th, 2021 once 3.4 released? Ok to start monthly cycle for patch releases once v2 is done? https://github.com/helm/helm-www/pull/869 Once 3.4 is released, then we would like to start announcing major releases. Also patch release announcements. Is this ok to go? [Marc] Added those milestones and added dates to them [Farina] We should add a calendar to add the dates in place. Marc is going to add the calendar to the HIP. Helm Charts Repo Switchover timeline [Vic] Move charts storage over to GH Pages Implement URL switchover in Helm 2.17 Move index.yaml in GCS to point to new GH pages URLs Create specially crafted chart that presents users with a hard failure Mark all charts as deprecated Switch index.yaml to point all charts to the specially crafted chart Reduce the size of the index.yaml Disable public access to buckets Chart producers: Repos switching but need to move charts to new host [Farina] Chart consumers: Switching stable/incubator but repo is going to become an archive [Farina] Ongoing plan: Martin points out that some still haven’t changed - who then are (by default) archived “Band aid” needs to be ripped off wrt obsolescence of charts. So charts are messaged that the charts are deprecated. [Farina] Message so that users know that charts are deprecated [Dan] Lint warning when no `templates` directory. Should this be removed as you don’t need it for a valid chart Ref: https://github.com/helm/helm/issues/8033 [Martin] Answer in the issue [Farina] [Fisher] Assignments for next meeting Moderator: Adam Reese Notes: Bridget Kromhout Issue Triage: Matt Fisher & Bridget Kromhout October 15, 2020 Assignments for this meeting Moderator: Marc Notes: Bridget Issue Triage: Martin & Farina Announcements Helm turns 5. Started Oct 19, 2015 (first committed). [Farina] Butcher points out it’s like 80 in internet years Discussion Stable and Incubator repos [Farina] Should we consider extending the date to make helm/charts read-only, since it has taken longer than expected to relocate stable charts [Scott] Scott: personally I'm of two minds about this. On one hand extending this could help keep end users happy while the charts relocation effort is continued / escalated. OTOH, it may make chart maintainers feel why bother to help relocate. I would say if we consider this, it would be capped to specific number of months Paul: read only timeline is still good IMO Much discussion on TOC list etc Farina: lesson learned: don’t use a bucket name - use custom domains/CDNs for flexibility Farina: Kubernetes credits for GCP only apply to k8s itself, not other CNCF projects, so it’s a funding issue to keep these from Butcher: GitHub has raised bandwidth caps to allow for chart repos - we will make public announcement/thanks next week Scott: about 45min to pull down the index file - in-flight Farina: should we update the URL in people’s configs? Vic: ideas on what we can do - we can’t change the response offered by cloud storage. But a better experience would be ideal (like changing index file, or possibly better: changing the index to point to a chart that has a require field that won’t in their files, but points them at docs to help them fix this.) Martin: option 2 good, because otherwise people will never update Vic: this is a happy medium - but my main concern is not wanting to blow away their resources. Fisher: are there any stable or incubator charts signed by chart authors, which might lead to a failure? Farina: no, nothing is signed. Fisher: Can we swap out what they receive without telling them? Bridget: If we’d had a custom domain in the first place they’d never know when we swap out back-ends, unless it breaks Vic: a hard fail is safest and a message telling them the path forward Farina: we need some kind of direction in 2.17 that tells people what to do. Butcher: what was the argument against automatic, other than proxies? Joe Julian: many customers are behind proxies with air-gapped clusters Farina: proxies sometimes limit domains/routing - we should print a message in logs Farina: we will add something to 2.17 and 3.4 for this. Also: how do we handle stable/incubator? 1 - do nothing/404 2 - redirect to new download locations (will err eventually) 3 - we could craft a required with a variable that does not exist to throw an exception - but needs investigation/testing Timeline: we need a solution before Nov 13 2 weeks before, we could have all charts fail or could give a message Fisher: client caches locally so without helm repo update, we won’t have them getting updates to their local Let’s bring this to chat/cartographers list Farina will look into whether this kind of chart action breaks a cluster. Vic looking into how much the bill is the index file vs something else Farina: there is metadata not used - could save bandwidth there Butcher: on the hook to start the PR for changes to helm 2 and 3 to deal with the stable and incubator repos - docs page for www Deferred to next week: Helm v3.4 and v2.17 [Farina] Impacts of gopkg.in/yaml.v2 v2.3.0 [Marc] Dependency of Cobra 1.1 https://github.com/helm/helm/pull/8890 HIP 0002: Announced release dates [Marc] Waiting for 3.4 https://github.com/helm/helm-www/pull/869 Helm Charts Repo Switchover timeline: Move charts storage over to GH Pages Implement URL switchover in Helm 2.17 Move index.yaml in GCS to point to new GH pages URLs Create specially crafted chart that presents users with a hard failure Switch index.yaml to point all charts to the specially crafted chart Reduce the size of the index.yaml Disable public access to buckets Assignments for next meeting Moderator: Fisher Notes: Martin Issue Triage: Farina October 8, 2020 Assignments for this meeting Moderator: Marc Notes: Josh Issue Triage: Farina Announcements Artifact Hub takes over for Helm Hub [Bridget]: https://helm.sh/blog/helm-hub-moving-to-artifact-hub/ (some docs updates pending) There was a CNCF blog post about "Important Helm Repo Changes & v2 End of Support in November": [Scott] https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/ From Dan Went out in the newsletter Discussion Helm Lightning Talk @ KubeCon [Karen] Deadline to fill out the form is Oct 11 15 minute format Does anyone have ideas? Highlight something special? Bridget: Karen talks w/ each maintainer about something specific Will be pre-recorded Helm Workshop: v2 to v3 - Oct 21 [Karen] 112 attendees registered to participate, as of this morning! please sign up on Google sheets so we know you'll be there to help! We need to register too (it’s free and easy with your existing LF account): https://events.linuxfoundation.org/helm-v3-workshop/ Still need “runners” - Can expand to non-maintainers if needed Swag will be involved Helm Project Pavilion/Office Hours [Karen]Three 45-min office hours Last kubecon, was not effective. Numbers disappointing, 3 clickthroughs according to stats Instead of this we could do office hours (3 45min sessions) Martin: it worked in San Diego (in person) 3.4 release planning [Farina] 3.5 planned for january Kube 1.19 support not in a release yet 3.4 Milestone: https://github.com/helm/helm/milestone/94 7 open items “Test” -scott 😂 Farina: Let’s set a date: next wednesday: 10/14/2020 Martin: update modules in 2.x? Should the 3.4 release include https://github.com/helm/helm/pull/8626 (Artifact Hub update) [Scott] No hub search in 2.x 👍 Updated note above Farina: let’s cut 2.17.0 before 3.4 so the most current is a 3.x Jobs and --wait flag [Farina] https://github.com/helm/helm-www/pull/884#discussion_r501849243 If a job is part of a hook, it waits. But if part of a chart - relies on --wait flag People have diff views on what wait means Special case for jobs? Scott: could break alot of charts Maybe new flag? --wait-jobs or --wait-for-jobs “How Projects Join the Helm Organization” proposal by Matt Butcher seeks your input and LGTMs: https://github.com/helm/community/pull/149 [Bridget] Bridget has impersonated dr. butcher 2 approvals from org maintainers needed Slack integration - let’s give this a yes (my recommendation - I don’t see a down side) or a no: [Bridget] https://github.com/helm/helm/issues/8610 Low-hanging fruit to make people happy Allows people to view issues within slack OCI Pull PR: https://github.com/helm/helm/pull/8843 [Josh] Slight miscommunication but resolved Could base change atop original work so contributor gets points in the commit history https://stackoverflow.com/questions/7442112/how-to-attribute-a-single-commit-to-multiple-developers Could credit him in notes Martin: API deprecation notes - may need issue Assignments for next meeting Moderator: Marc Notes: Butcher Issue Triage: Martin & Farina October 1, 2020 Assignments for this meeting Moderator: Adam Notes: Scott Issue Triage: Farina Announcements (items of general interest like releases, requiring no discussion) “How Projects Join the Helm Organization” proposal by Matt Butcher is now ready for org maintainer review: https://github.com/helm/community/pull/149 [Bridget] Please review! Helm maintainer session for KubeCon North America 2020: https://sched.co/ekHz [Bridget] Wednesday, November 18 • 4:55pm - 5:30pm Eastern - a good time to be in the CNCF Slack channel for the maintainer track so as to discuss/answer questions (during and after) Removal of governance section on first org maintainers election [Farina] https://github.com/helm/community/pull/148 PR in - votes in - will be removing that section. Discussion Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Deferred from last week: Announcing migration needs in CNCF blog/newsletter [Dan Garfield] Current draft here https://docs.google.com/document/d/1D_cbuxObeD6yjKUmfcRjF_i1gyKnGZxG3intv57xw1A/edit?usp=sharing Deadline October 5th Reviewed already by some Helm team members (thanks Karen, Bridget, Josh) Dan will work with Scott (and Matt Farina if he has time?) in Slack before the deadline Deferred from last week: Helm Hub -> Artifact Hub timeline [Farina] Hoping to do next week. Defer again to next week Deferred from last week: Slack integration - do we want to allow this? [Bridget] https://github.com/helm/helm/issues/8610 Is there any good reason to say no to this? Please look if you can End User Story for KubeCon Keynote Project Highlight [Karen] Due Oct 5 Any ideas? If so, please pass along to Bridget and Karen Helm Workshop: v2 to v3 - Oct 21 [Karen] Living Event doc Still need help with staffing presentations (2) and runners (10) for workshop Feature detection in Helm (lookup function) https://github.com/helm/helm/issues/8834 [Farina] Looking for a possible hack for older versions of Helm 3 before version was introduced Adam will think about it [feature] add option to force/override "Release.Service" back to "Tiller" [Bridget] https://github.com/helm/helm/issues/7211 - possible blocker for migration from v2 to v3 - thoughts? Farina: could probably add a flag? Adam: should this be built into Helm, though? Farina: tear down/standup replacement is the only fix for this, because of match label immutability (specifically, the user template added a changing field into a match label) Scott: https://github.com/helm/helm/issues/7173#issuecomment-562648387 addresses some of this. Specifically linking to https://github.com/helm/helm/issues/7082 To be continued Assignments for next meeting Moderator: Marc Khouzam Notes: Josh Dolitsky Issue Triage: Matt Farina September 24, 2020 Assignments for this meeting Moderator: Martin Notes: Bridget Issue Triage: Farina Announcements (items of general interest like releases, requiring no discussion) Helm v2.16.12 and Helm v3.3.4 have been released https://github.com/helm/helm/releases/tag/v2.16.12 https://github.com/helm/helm/releases/tag/v3.3.4 Patch releases; thanks to Farina and Fisher. Fisher: It might be important to note that 3.3.2 was the initial release with the security fixes, and 3.3.3/3.3.4 were regression fixes Zoom call password [Farina] Zoom will require passwords or waiting rooms across all CNCF Discussion Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Stable and incubator repositories being removed in November. What is the plan for users? [Martin] Martin: we had been assuming that in orgs people create their own or fork, but they seem to be using the community repos quite a lot - is the best way to do this a detailed document on how to migrate? Farina: we probably have to spend October on a major campaign of informing people on how to migrate - it’s not cost-feasible to run them centrally Martin: the message has gone out but we need a good migration path for people. Fisher: Karen is the community manager around comms Farina: Helm 2.17 will have a flag to disable adding the stable and incubator so `helm init` won’t automatically err out, and get tiller image from the github container repository Adam: what about releases? Farina: get.helm.sh is in azure but if someone is using the old location then yes that will fail Fisher: we have a clean migration path and blog post for that (over the last year and a half) Farina: the 8-meg helm init index.yaml for helm 2 is a big part of the bandwidth Scott: happy to help with migration path for charts Farina: will work with Scott on that Marc: where to continue discussion? Farina: let’s continue discussion in the charts repo in an issue Deferred from last week: HIP 002 -- Fixed release dates: https://github.com/helm/community/pull/143 [Marc] Marc: Getting close to an agreement - we need to agree on a date and publish it Farina: may be related to k8s 1.20 then? Or something off 1.19? Butcher: we should cut a 3.3.4 with 1.19 support Farina: let’s start with the approval of a HIP - we need to look at date possibilities in the coming weeks Fisher: project and org maintainers can approve these HIPs - final approval details pending Security patches can lead to unexpected problems. How can we mitigate these with previewing upcoming changes? [Bridget] https://github.com/helm/community/issues/128 Farina will follow up with the CNCF to get the list set up Farina: We will need to handle the vetting process for list members - k8s uses a vouching system Dan: can we use the k8s list? Farina: the CNCF requires specifics around being a certified distro - Helm repos will have different criteria so this can’t be a subset of the k8s list Butcher: let’s exercise caution and due diligence here Martin: we will revisit over coming months End User Story for KubeCon Keynote Project Highlight [Karen] Due Oct 5 Focus on graduated projects - to be highlighted during keynotes, focus on end user stories Helm v2-to-v3 Hands-on Workshop - Oct 21 [Karen] Need to decide on content + confirm who can help Working with CNCF - this will be an official CNCF event Format: two presentations and hands-on workshop - perhaps 9-1:30 (pacific time) - Karen looking to find out who can help with the workshop portion - going to use the zoom webinar platform, so we would like maintainers to be hands-on If free, attendees might flake out? Scott: “Maybe also a git repo for the workshop? Would we want a step-by-step like that? It seems to be a useful pattern for a lot of hands-on workshops” Volunteer/Staffing doc -- https://docs.google.com/spreadsheets/d/1IbZkM_eKiCeOc01lVxCXu1-aiBKNj-9SqP_Swn09rLs/edit?usp=sharing Out of time: Announcing migration needs in CNCF blog/newsletter [Dan Garfield] Current draft here https://docs.google.com/document/d/1D_cbuxObeD6yjKUmfcRjF_i1gyKnGZxG3intv57xw1A/edit?usp=sharing Deadline October 5th Helm Hub -> Artifact Hub timeline [Farina] Slack integration - do we want to allow this? [Bridget] https://github.com/helm/helm/issues/8610 Skip discussion - resolved - Various v2-deprecation-related issues [Bridget] [Skip discussion - resolved on GitHub] Helm v2 deprecation progress [Bridget] Do we want to think about https://github.com/helm/helm/issues/7239 - the ability to mark a chart as v3-incompat? [Bridget] [fisher] I closed the issue. There has not been any activity since it was opened last December. [Skip discussion - resolved on GitHub] https://github.com/helm/helm/pull/8363 [Bridget] - “Helm --wait should wait for all manifest resources to be ready; However helm doesn't wait for jobs to be completed when job appears in the manifest, not in the hooks” Can we review this and see if it should move forward? [fisher] I’ve added it to the next Helm 3 milestone for review. [Skip discussion - resolved on GitHub] Can we get a review on Allow helm test to run a subset of tests #8484? [Bridget] It could close an old issue [fisher] I’ve added it to the 3.4.0 milestone for review. [Skip discussion - resolved on GitHub] Is executing hooks in parallel useful? Should we solicit more help here? [Bridget] https://github.com/helm/helm/pull/7792 [fisher] I’ve closed the PR and pointed out how users can move this proposal forward. Assignments for next meeting Moderator: Adam Notes: Scott Issue Triage: Farina September 17, 2020 Assignments for this meeting Moderator: Marc Notes: Bridget Issue Triage: Farina, Josh, and Fisher Announcements (items of general interest like releases, requiring no discussion) CNCF CD Radar (Helm is on it) https://radar.cncf.io/2020-06-continuous-delivery [Farina] Though Helm isn’t a CD tool it was listed as “Adopt” Contacted the end users to ask them for feedback on Helm [Farina] Radar was put out by “end users” so Farina reached out to that mailing list for feedback QCon Plus Helm Session https://plus.qconferences.com/ [Bridget] Voluntold Butcher & Farina Discussed stable repo GCP hosting costs with Vic [Scott] Costs are not small - chart version package history will need a different solution as this is not going to be sustainable after Nov 13 Perhaps we could revisit moving their past packages/index file to github hosting? Butcher likes this idea & will help investigate Talked with ASF about the possibility of hosting charts that install Apache projects [Scott] They don't currently have a policy that allows this. Here is a proposal based on those conversations to update their policies on "convenience packages" like Helm (it references Helm as well as other packages): https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages Please comment if you're interested Licensing/ownership considerations Discussion Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Conversation about Helm’s governance [Butcher] Butcher: two issues. 1) the official org governance structure allocates org maintainership based on which project you’re affiliated with - we need to revise this as projects are sunsetted 2) we also don’t have a project for managing the security team and we should probably add other core maintainers as the project grows - we have no documented process for that either. Scott and Farina and Martin volunteering to help; also Dan Garfield is willing to help (he’s working on this with the Argo team right now) Fisher doesn’t think we need to address finance or security org-wide but need to reach out to sub-projects as needed, to provide opportunities for other parties to join in security review helm/helm call for vote open on 2 approvals for community PRs [Farina] Farina: we’ve had some commits merged that warranted further discussion - it would be better to catch some issues earlier on Fisher: we changed this for Helm’s velocity - stability is more important now Martin: it’s a sticky wicket when you get into backwards-compat Changing vs extending error strings [Marc] - is this okay? Fisher: if the error message is output being parsed, then changing it could break scripts - so additive is different from changing/removing - also, changing error types can cause problems for other packages that import, etc (depends on context) Butcher: perhaps this needs more discussion (as go the language will routinely change error text) Process HIP could be the path forward! Marc will star;t will need input from other maintainers Decision on whether the merged PR fixing the few remaining stdout to c.Log is considered a PATCH or MAJOR (whether it should be rolled back until Helm 4, or ok to stay) [Scott] https://github.com/helm/helm/pull/8437 This one seemed really on the edge for the team, as format was changed (grep should still work), but it is a difference. In keybase nearly everyone seemed to go either way on this one Fisher: we can work on this in parallel Docs translations quirk [Bridget] An ever-growing number of PRs (https://github.com/helm/helm-www/pulls?q=is%3Apr+is%3Aopen+label%3Atranslation) for translations of https://helm.sh/docs/helm/ are waiting for merge because the English pages are auto-generated by the cli and then stored on the website, which cannot currently be done for other languages - is it okay to put translations of some of these docs on the website, with the understanding that (for the foreseeable future) they won’t be generated by or visible in the cli? Vetting language-specific contributors Translation community Helm v2 deprecation tasks [Bridget] Default tiller image location https://github.com/helm/helm/issues/7211 (heritage=Tiller issue) Farina: GitHub container registry will be the default, with mirrors on quay and dockerhub Blog post and announcement with CNCF [Dan Garfield] Dan: Started drafting blog post to clarify what will help people who find that their tiller location is gone Bridget: https://helm.sh/blog/helm-v2-deprecation-timeline/ Marc: we need to clarify what the user experience change is Scott: From Keybase, Paul & I have volunteered to work on a post for updating from stable to elsewhere (mostly a how-to for chart maintainers. But also can be helpful for end users Martin: we have to talk about this again next week Scott: Here’s the issue to follow: https://github.com/helm/charts/issues/21103💯 Deferred to next week: HIP 002 -- Fixed release dates: https://github.com/helm/community/pull/143 [Marc] Assignments for next meeting Moderator: Martin Notes: Scott Issue Triage: Farina September 10, 2020 Assignments for this meeting Moderator: Marc Notes: Martin Issue Triage: Farina and Fisher (shared triage; both are in and out this week) Announcements (items of general interest like releases, requiring no discussion) Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) De-listing stable and incubator from Helm Hub as planned? (followup from last week) [Farina] Two current thoughts on migration plan for users: 1) chartcenter is hosting a “mirror” of the stable and incubator repositories 2) storing this ourselves in S3 Josh: does this mean new URLs? Farina: yes. We cannot move google cloud storage buckets from one to another, preventing us from migrating the URL in a clean fashion Fisher: has there been a discussion over with the chart maintainers on which path seems worth investigating? Farina: this is something we need to talk more about there Marc: the one thing that’s a bummer about all this is the guarantee that there is a “stable” repository I can depend on Farina: the hard discussion here has to do with billing. Google has been sponsoring the bucket hosting the charts. Google is now no longer willing to pay for the bucket. If there is a partner willing to pay for a chart repository then we’d be happy to work with them on that HIP for fixed release dates - https://github.com/helm/community/pull/143 [Marc] I tried to put the basic ideas in a HIP - Butcher: the two things I wanted to ask were: 1) do we always want to discuss security fixes are always as patch releases, and 2) do we want to commit to a new minor release after a Kubernetes release (1 month after or some time after) Farina: one of the risks was that updating client-go has been a major paint point. Some releases have certainly taken a month to update Fisher and farina: FWIW, we’ve received backlash for releasing security fixes in a minor release only, so it might be worth making it a point to always cut patch releases in the case of a security fix Helm security audit [butcher] We are in the last phases of our security audit. As a reminder, each year the CNCF sponsors a security audit There will be two reports: an architectural report, and a code report Two questions: do we want to disclose it to the security maintainers before releasing to the public? Farina: first opinion, we should release it to the other security maintainers to reduce that bus factor Fisher: who is on the security maintainers list? Farina: myself, butcher, fisher, adnan, nikhil, and vic Storing Tiller after GCR [farina] Tiller is now in Quay. We’re looking to move to Github Container Registry (farina had to leave at this point) Dan Garfield: We should release a coordinated message on the CNCF newsletter, publish on the release notes, make it clear in `helm init --upgrade`, etc. This way we won’t have users upset when their tiller instances restart and it goes into CrashLoopBackoff Question about governance of Helm and deprecating chart repo [Butcher] Punted to next week to discuss governance Related: Security group membership Assignments for next meeting Moderator: Marc Notes: Bridget (unless someone else claims it!) Issue Triage: Farina, Fisher, and Josh September 3, 2020 Assignments for this meeting Moderator: Marc Notes: Bridget Issue Triage: Butcher Announcements (items of general interest like releases, requiring no discussion) 3.3.1 released: https://github.com/helm/helm/releases/tag/v3.3.1 Farina: we wanted to get the cert-manager issue fixed Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) De-listing stable and incubator from Helm Hub as planned? [Scott & Farina] Progress of finding new homes for stable charts: https://github.com/helm/charts/issues/21103 Stated on 20 Aug that further discussion was needed Aug 27: stable/incubator becoming unavailable? Blog? [Marc] Aug 27: Blog post (Farina + Bridget), docs updates, artifact hub switch Aug 27: Revisit next week Sept 3: Bridget can participate in blog post writing and docs updating starting Sept 14 Farina: Many charts have not found new homes - do we want to remove it now? We’re running out of time here Martin: there were questions around the prometheus chart - large community - Scott working on moving that - we need a clear path forward Farina: reminder: Nov 13th the bucket will (likely) be garbage-collected - we have an issue on the community repo around moving that elsewhere Farina: maybe something useful would be a tool to grab the history for a chart and download it etc Marc: what do we do if important charts aren’t relocated yet? Farina: we need to make a good plan to move these - I can start work on this Tuesday - JFrog has volunteered on some of these (chart center has a cache) Martin: charts are where the value of Helm is seen - we need to make sure people have options Farina: valuable to talk about a new way to replace the stable/incubator repos - I see the problem but the community needs to come up with the answer Fisher: it’s not like the source code is going away either - there are alternatives but we have to figure out how to support going forward - have we reached out? A question for the chart maintainers team. Bridget: so we’re moving away from centralized ownership Farina: Scott is working on a checklist to move to new owners Farina: will send out an email to the chart maintainer mailing list after this Farina: let’s talk about this again next week. What remains to be done before we can make HIP official? At least a dozen stale issues could easily be resolved with a suggestion to follow the newly-formalized HIP process, once it’s merged. [Bridget] https://github.com/helm/community/pull/140 Deferred from Aug 27 Fisher: proposal itself is ready - at this point, we need quorum from org maintainers. (PR review and approval) Fisher: Let’s seek consensus and ensure it’s not too heavy-handed Farina: Fisher, can you send an email to cartographers? Fisher: yes Dependabot: https://github.com/helm/helm/pull/8574 [Marc] Deferred from Aug 27 Marc: I think Fisher wanted feedback? Fisher: I’ve seen cases where dependabot creates PRs for security issues and thus makes it public - sending an email can be safer Fisher: in a couple cases I’ve seen lots of visibility around npm vulns. Farina: Docker packages where we don’t use the runtime part have CVEs that don’t impact us - but we would see said CVEs Bridget: it doesn’t nag - just tells you on each version Farina: if it’s a problem we can turn it off Fisher: I’m fine with a trial run - it doesn’t rewrite code, just submits PRs Fisher: let’s give it a try and we can discuss further if it proves necessary Application version as container tag? [Farina] https://github.com/helm/helm/pull/8562 Farina: version vs packaging are not the same Farina: an annotation might be for the application version, not the container tag version - this PR may be a problem vis a vis separation of concerns? Farina: we may need to communicate more clearly on these matters Marc: so an empty version is better? Farina: no, it’s better to have no annotation at all Bridget: point of order - will we need to revert that PR? Martin: I volunteer to do it as I merged it in first place - reverting it back may be the best action. Moving images from DockerHub to GitHub? [Bridget] https://github.blog/2020-09-01-introducing-github-container-registry Bridget: should we move to this? Farina: do we have access to this beta feature? Fisher: in my tests we have access - it is available to everyone who has packages (as long as you have a token, if you have read access to the API, and you can see /organization) Farina: I’ll test if we can migrate everything Fisher: we should make sure we loop the CNCF in Bridget: currently no limits on public Farina: we’d want to avoid hitting a limit but no limit is documented yet Allow templating in value files? Yes or no? [Martin] https://github.com/helm/helm/pull/6876 Martin: this is a huge PR, now broken into three - the big question is what is our opinion on this? Do we want to allow this or tell the person now? Fisher: there is an issue of cyclic dependencies here - where does Helm’s role end? Templating in a values.yaml file means you need to render before passing into chart, then re-rendering again, and where does it stop? Perhaps that’s a better case for an external tool to do, and have Helm do rendering once? Farina: there’s separation of concerns here, and I wondered how that PR fit into workflows - this is a great thing for a HIP - the why, the how, how it fits in, dealing with concerns. Little pieces that fit together. Farina: let’s pause on this until we can suggest they create a HIP Fisher: I will take the action to explain this pause/conversation to them Assignments for next meeting Moderator: Marc Notes: Martin Issue Triage: Farina can help and The Canadian can also help (we have a Labour Day in Canada as well) and Martin also August 27, 2020 Assignments for this meeting Moderator: Matt Butcher Notes: Bridget Issue Triage: Butcher, Bridget Announcements (items of general interest like releases, requiring no discussion) Anonymized questions available for your perusal from Marc & Bridget’s KubeCon EU Intro to Helm session; Bridget sorted them into topics and will use these as inspiration for blog posts/doc updates: https://docs.google.com/spreadsheets/d/1JHIxdnajgY_4BC8OCoQc-WMQJsSdeWLcsprxCLO10jI/edit?usp=sharing [Bridget] Butcher: also if you have numbers from your Helm session, drop them in here - Intro to Helm got ~566 Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Should the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin] (deferred from 20 Aug, to when Martin is here) Martin: We couldn’t find a nice solution, so we still need the plugin - should that be in the Helm org as it’s necessary (instead of in Martin’s github?) Butcher: related - helmfile has also asked - we need documented guidelines Farina: helmfile is not apache2 licensed - that’s the big blocker Butcher: if anyone can document the basics in a helm community PR, that would be a good start Farina: Martin’s is apache2 so that’s not an issue Butcher: we could use Martin’s as a test run for the process Farina: who would like to write this up? I’ll take the followup action Slack app integration? https://github.com/helm/helm/issues/8610 [Farina] (skipped on 20 Aug) Farina: we can deal with it on GitHub Bump to Kubernetes v1.18 in Helm v2 [Martin] This has repercussions for projects that use both Helm v2 and v3 APIs as some k8s API calls would be broken through the Helm v2 API when using latest Helm v3 as a dependency This would mean not being able to upgrade above Helm 3.1.x Example: https://github.com/hickeyma/helm-mapkubeapis Martin: in 3.2 we bumped Helm 3 to 1.18 - some APIs changed Martin: however, Helm v2 doesn’t require 1.18 - so there will be issues (v2 was on 1.16) - is this something we should do? I can take the action to do it. Farina: we have 2.17 that needs to come out that takes us off Google for storage, so something else could in theory go in there? Bridget: how do we know this doesn’t come with regressions? Butcher: we need to decide if we’re changing our minds on adding k8s compat that isn’t security, and decide Dan Garfield: do we have stats on how many people are still pulling those images? Farina: I can try to pull that as we discuss other things Highest item: v2.14.3 - the most widely-downloaded - some CI system Then. 3.x Three diff 2.x are still in the top ten De-listing stable and incubator from Helm Hub as planned? [Scott] Progress of finding new homes for stable charts: https://github.com/helm/charts/issues/21103 Stated on 20 Aug that further discussion was needed stable/incubator becoming unavailable? Blog? [Marc] Blog post (Farina + Bridget), docs updates, artifact hub switch Revisit next week Open question about Helm Hub -> Artifact Hub move: should we keep hub.helm.sh as the default endpoint even after pointing that to artifacthub.io? [scott] upside: helm org retains control should we need to point elsewhere in future (though we can also always just update the client in backwards-compatible way as in this PR: https://github.com/helm/helm/pull/8626 downside: users will be redirected to an eventual different domain than they see in `helm search hub` output Farina: when we move forward we will have a redirect, but should we change the helm code? Bridget: I don’t see a downside Butcher: let’s set a time to do the domain name switch and do a release that follows the redirects, then migrate at a time that we could message enough so nobody could be surprised Bridget: let’s keep control of the URL Martin: agreed Butcher: so we wouldn’t change the domain name at least until it goes from sandbox to incubation Farina: we can do something in the messaging to make that more clear Butcher: staying on same domain for now - someone can propose a transition plan for when artifact hub hits incubation Taking over a contribution inactive since July 7th 2020? [Marc] https://github.com/helm/helm/pull/8111 Farina: I would ask on the PR about taking it over, then specify an amount of time to take it over - then do a new PR with commits pulled over and close old one and point to new one. Marc: needs a rebase 3.3.1 release date? Cert-manager users are apparently affected by an issue which 3.3.1 would resolve for them. [Bridget] https://github.com/helm/helm/issues/8594#issuecomment-674754119 Matt Farina can do Monday - Josh D to shadow What remains to be done before we can make HIP official? At least a dozen stale issues could easily be resolved with a suggestion to follow the newly-formalized HIP process, once it’s merged. [Bridget] https://github.com/helm/community/pull/140 defer Dependabot: https://github.com/helm/helm/pull/8574 [Marc] defer Assignments for next meeting Moderator: Marc Notes: Bridget Issue Triage: Butcher August 20, 2020 Assignments for this meeting Moderator: Marc Khouzam Notes: Scott Issue Triage: Fisher Announcements (items of general interest like releases, requiring no discussion) Introducing the stale issue bot: https://github.com/helm/helm/pull/8521 (added to announcements by Bridget; credit to Fisher) Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Helm Hub -> Artifact Hub [Farina] Paul, Scott, Farina met with AH maintainers on moving HelmHub to AH. The plan is here and open for a vote: https://github.com/helm/hub/issues/439 Goal is to make sure we don’t drop any repos AH will be compliant to Helm’s search API HH will be redirected to AH when things are stable. Then HH will be removed. And we will do a blog post announcing the change AH already has migration automated, things are moving quickly. Provisional PR: https://github.com/helm/helm/pull/8626 Should the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin] (defer to when Martin is here) Dependabot: https://github.com/helm/helm/pull/8574 [Marc] (defer to when Martin and Fisher are here) Tiller in Docker Hub or GitHub container registry? [Farina] Dan Garfield notes danger in moving locations, as experienced at Codefresh Matt Farina: we need to move it from the google storage bucket regardless. The open questions are about whether GitHub registry will do what we need Matt Butcher: in favor of GitHub registry, will do what we need Paul C: agree with github Dan G: limits for open source projects? Matt Farina: GH says free for public repos Mattt B: if anyone wants to list alternatives, please do Slack app integration? https://github.com/helm/helm/issues/8610 [Farina] (skip) Publishing the KubeConEU recordings/demos? [Marc] Helm youtube channel https://www.youtube.com/helmpack Bridget, Paul in favor of hosting our own high res verisions Announced release dates https://github.com/helm/community/issues/141 [Marc] Butcher: from CNCF meeting, 4 releases annually, with at least 2 of them being minor releases De-listing stable and incubator from Helm Hub as planned? [Scott] Progress of finding new homes for stable charts: https://github.com/helm/charts/issues/21103 Will bring up again next week in the meantime continue discussion via Slack and mailing list Assignments for next meeting Moderator: Butcher Notes: Bridget Issue Triage: Butcher, Bridget August 13, 2020 Assignments for this meeting Moderator: Martin Notes: Paul Issue Triage: Announcements (items of general interest like releases, requiring no discussion) Helm 3.3.0 released Helm 2.16.10 released & Helm v2 deprecation timeline to inform people about: https://twitter.com/HelmPack/status/1293694958432481280 [Bridget] ^ thanks to Matt Farina for cutting the releases & Bridget for the blog post Final cut of helm 2 will be 2.17 Join CNCF Slack if you want to talk to Helm intro & deep dive session attendees! Invites: https:///slack.cncf.io , Slack https://cloud-native.slack.com, Channel #2-kubecon-maintainer Join the slacks for a bit before and up to 15 mins later, help with chat and questions. A few more Maintainer signups needed for virtual Helm project pavilion at KubeCon EU: https://docs.google.com/spreadsheets/d/1qQ067_AeU274sDiu1nwGBeBfwt1q5H3k5UojlOZFV9s/edit#gid=0 [Karen] The yellow slots are the “high priority” ones - please prioritize those ones; if you sign up and want a free pass, let Butcher or Karen know - Helm GitHub Actions have all released v1.0.0 [Scott] kind action ( start up a cluster that lives for the further tests such as `helm install` `helm test` Chart-testing - lint + install on just the changed charts ( monorepo ) Doesn’t test upgrade by default, but functionality is in the testing tool. Chart-releaser - creates chart package, adds binary to github release, updates index.yml in to gh-pages. Scott is driving the rehome of prometheus charts, and is showing off how great the actions are. Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Next version - we already have 10 closed items (and no open items) in the milestone for 3.3.1 (https://github.com/helm/helm/milestone/97?closed=1) - what date are we aiming at releasing it? [ Bridget] End of August after Farina and Butcher are back from vacation Road-testing 3.3.0 may give us more End aug, start Sept May allow us to make choice between 3.3.1 and 3.4.0 (kubecon might surface bugs or features needed for release) Marc suggests we should do fixed dates for feature releases. Quarterly minor cadence? [Martin] - move this discussion to next week Security Mitigation spec/file proposal https://github.com/helm/community/pull/139 [Rimas] Also see this discussion thread https://kubernetes.slack.com/archives/C0NH30761/p1596744481096000 Rimas shares reference example on screen (see recording) chartcenter UI lists CVEs that affect a chart If mitigation file exists, will display notes/comments/etc from that file per CVE [Fisher] what’s the rationale, how do others use it? Value prop is there. Do we make this an openstandard, need helm community agreement. Proposed change to the Helm community proposals: https://github.com/helm/community/pull/140 [fisher] Fisher talks to need for a proposal on how to create proposals, inspired by Rimas security Mitigation proposal. Inspired by PEP, KEP, DEP … but lightened up. [martin] sounds great, but we’re out of time for further discussion this call. (out of time for this week) Should the “mapkubeapis” plugin be moved to Helm org (https://github.com/hickeyma/helm-mapkubeapis) ? [Martin] Stale issue bot: https://github.com/helm/helm/pull/8521 [fisher] It is August 13th. We’re now entering the “security fix only” stage of Helm 2 support. Should we close out issues, support questions and bug reports related to Helm 2 at this time? [fisher] Assignments for next meeting Moderator: Marc Khouzam Notes: Bridget Issue Triage: Fisher August 6, 2020 Assignments for this meeting Moderator: Adam Notes: Butcher Issue Triage: Fisher Announcements (items of general interest like releases, requiring no discussion) Helm 3.3.0 release plan? Possibly ready [Bridget will follow up with Fisher/Farina] 2.16.10 on the 12th? Farina will release, Bridget will have blog post (with an unwitting Adam on the assist) Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Maintainer signups wanted for virtual Helm project pavilion at KubeCon EU: https://docs.google.com/spreadsheets/d/1qQ067_AeU274sDiu1nwGBeBfwt1q5H3k5UojlOZFV9s/edit#gid=0 [Karen] Bridget: Free passes if you sign up! Butcher: The yellow slots are the “high priority” ones - please prioritize those ones; if you sign up and want a free pass, let Butcher or Karen know This is a casual question/answer session on the Intrado platform. Nothing fancy. Unanswered question: is it text-only or is there video? (Bridget to investigate) Answer: text-only; must be listed as “booth staff” to answer. How best to implement `untar` capability for `dependency update` https://github.com/helm/helm/pull/8499 [Martin] When you do an update, you can --untar it. The capability is in the CLI instead of in the library. Would like input from other maintainers because it seems to modify the download manager, which breaks compatibility. So it might not be viable for Helm 3 Adam will review. Adam listed a few issues that could come up with local v. remote dependencies V2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget] Ongoing triage of v2 issues (7 open) and v2 PRs (three open) Need quick review before it is too late Quick update on Security audit Butcher: one team audits architecture, while another goes through the go code and runs a number of security scanners Butcher: Trail of Bits found a long-standing bug in macOS (undetected for 10 years!) while doing this audit for Helm. CNCF agreed to have them improve docs too. They are going to make security recommendations for Helm 4. Assignments for next meeting Moderator: Martin Notes: Paul. Issue Triage: July 30, 2020 Assignments for this meeting Moderator: Farina Notes: Fisher Issue Triage: Announcements (items of general interest like releases, requiring no discussion) Helm 3.3.0 release status [Farina] 3.3.0-rc.2 was released yesterday Looking for a volunteer to release 3.3.0 Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Timing for next 2.16.x release? [Bridget] Fisher: perhaps we should wait until August 13 Farina: Do we want a 2.17.0? Farina points out we need to garbage-collect old docker location Fisher: so we’ll have two releases then Farina: 2.17.0 likely to go the week of Aug 13 Please add your thoughts today for Marc and Bridget’s KubeCon EU “Intro to Helm”, to be used in a “pop-up video” style! (Must finish editing and upload tomorrow, July 31) https://docs.google.com/document/d/1qZ1Srjfio7umKe1DbOt8iRgIQoRELQZq0yLdBTL99BM/edit?usp=sharing [Bridget] If you leave any comments in the google doc today, those will be added to the video as “pop-ups” PR https://github.com/helm/helm/pull/8529 [Martin] Does this break backward compatibility? [fisher] in general, new output that does not break existing use cases should be fine (like adding new columns to `helm list`) The trick here is that `helm status` is plain text - no formatting applied here [farina] there are a few bugs in `helm status` right now which can change the output, so this output can change I would ping Matt Butcher on this particular topic - he may have more historical context on whether this may be a breaking change [fisher] what output from helm status, if breaking, is to be considered here? Two weeks to go! V2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget] Ongoing triage of v2 issues (7 open) and v2 PRs (one open) Bridget will start draft of v2 EOL/migration blog post this week Farina: 2.16.10 the last bugfix release mid-August, 2.17.0 thereafter. Fisher: MSFT folks in virtual offsite Aug 11-12. Farina: can cut 2.16.10 on the 12th and Bridget can get blog post in. Assignments for next meeting Moderator: Adam Notes: Butcher Issue Triage: Fisher July 23, 2020 Assignments for this meeting Moderator: Bridget Notes: Scott Issue Triage: Josh Announcements (items of general interest like releases, requiring no discussion) Helm 3.3.0 release status [fisher] Release blocker: https://github.com/helm/helm/issues/8467#issuecomment-662502567 Still in progress Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) OCI Support Updates [Josh] Proposal doc: https://github.com/jdolitsky/community/blob/oci-support-updates/proposals/oci-support-updates.md Community repo PR: https://github.com/helm/community/pull/136 Summary: Implement `Getter` and introduce `Pusher` Support for provenance files Chart versions == OCI reference tags Chart names == OCI reference basenames `helm chart` is removed, integrated into rest of CLI Experimental until clear messaging from OCI The goal was to get the base case to be in line with the chart repository API. It doesn't preclude expanding to address other use cases Cache may also be removed, since the tech debt cost may outweigh the benefits Jacob: Q: do we plan to support digest references? We need this use case A: let's address that in the proposal. If not a breaking change, we could introduce post-stable Github’s /releases/latest API - we’re now up to 10 issues closed on the same subject. Should we consider using github’s “pin issue” feature for these threads? [fisher] https://github.com/helm/helm/issues/8502 Could we solve the problem by retagging the 3.x release? https://stackoverflow.com/questions/22822586/swap-latest-release-on-github [Marc] A concern with re-creating tags is breaking other systems like homebrew etc Also, it would be mis-leading to users to advertise a different date than the actual release date Jacob LeGrone: have we looked at server-side apply? https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/ Assignments for next meeting Moderator: Farina Notes: Fisher Issue Triage: July 16, 2020 Assignments for this meeting Moderator: Adam Notes: Bridget Issue Triage: TBD Announcements (items of general interest like releases, requiring no discussion) KubeCon EU Intro session to be recorded by Marc & Bridget - comments requested: https://docs.google.com/document/d/1giuqSbesC00illJAAHSZF95hXuzXKVfr8UgfyqH5Hkk/edit?usp=sharing [Bridget] Release checklist updates in progress; please review https://github.com/helm/helm-www/pull/749 [Bridget] Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) When shall we finalize the 3.3.0 release? How about 2.16.10 and/or 2.17.0? [Bridget] Farina: Possible issue with the release candidate - we need to chase this down: https://github.com/helm/helm/issues/8467 Farina: We do need to add some features for 2.x - skip repos, provide tiller from elsewhere - those need to be completed for 2.17 Farina: tiller available on dockerhub now Farina: 2.16.x could go out at any time Support non conformant Kubernetes objects [Martin]: https://github.com/helm/helm/issues/8439 Martin thinks there are interrelated issues - asks Ashok (community member) to introduce topic Ashok clarifies the benefits of adding weighting/ordering Adam asks if this is for just custom resources Ashok clarifies that it’s for all resources Farina points out the issues with sort order when you get outside built-in resources - people want to order things differently than the default - requires consideration of dependencies Adam points out we don’t separate dependent chart objects from parent chart objects Farina’s proposed solution: top-level chart could specify order (with an advanced feature toggled on) Adam: if ordering is dependent, how do upgrades work? Farina: use the sort ordering in the chart Adam: need to consider how to deal with dependent objects if parents get upgraded Farina: solved with config maps - could expand to dependencies - put metadata in Chart.yaml [long discussion] Concept from Paul: My idea for a KindOrder resource wouldn't require a CRD tho ... just telling helm that the resource is for it ... not the kube cluster ... helm would render and consume anything with helm.sh/*, but not apply to the cluster Why would we expose that in a CRD like object? Why not just as metadata in the _Chart.yaml_ file? [Farina] https://github.com/helm/helm/pull/8441 Discussion will continue in https://github.com/helm/helm/pull/8448 Recreate upgrade strategy [Martin]: https://github.com/helm/helm/pull/7431 delete/recreate is a sufficient solution (Butcher in https://github.com/helm/helm/pull/7431#issuecomment-658440433) Should it and any other similar issues/PRs be closed? V2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget] Ongoing triage of v2 issues and v2 PRs This doc’s ownership [Farina] Bridget just had Michelle move it to Butcher - done Resolver vs manager internal cache vs making user manually add repos for deps? [Farina] https://github.com/helm/helm/issues/8449 Farina: Possible fixes: internal cache, error out Adam: related was a backwards-compat issue Farina: whatever we do it will break some CI toolchains Followup: look at the issue and see what you can add - we want to fix this but be as non-invasive as possible. [moving to next week] OCI Update after maintainer chat early this week [Josh] We should implement a new interface GetterPusher - similar to Getter but with upload capabilities (also implements Getter). This will allow using oci:// everywhere where chart repos are referenced Provenance files will be supported. They will be stored on the manifest as a second layer. If using “helm pull --verify”, 2nd layer will be assumed to be the prov file, and validated Registry reference tags will be 1-to-1 with chart version (for now). Later on, we may support arbitrary tags, but not until this is more stable Registry reference basenames will be 1-to-1 with chart name Most “helm chart” commands should be removed where possible. For example “helm chart save” -> “helm package --save-oci” As a criteria for removing experimental flag: all of above should be implemented, distribution-spec should release v1.0, and there should be clear language on OCI side supporting Helm’s use of “artifacts” / media-types Assignments for next meeting Moderator: Farina Notes: Scott Issue Triage: Josh July 9, 2020 Assignments for this meeting Moderator: Bridget Notes: Martin Issue Triage: Fisher, Martin, Bridget Announcements (items of general interest like releases, requiring no discussion) 3.3.0 rc.1 available for testing: https://github.com/helm/helm/releases/tag/v3.3.0-rc.1 [Fisher] Please try it out Open for week or so Reminder to store blog topics here as we plan to put out more blog content in the next year: https://github.com/helm/community/blob/master/blog-topics.md [Karen] Ronan pulled the top docs search terms over the last 90 days: https://github.com/helm/helm-www/issues/266#issuecomment-655756770 [Bridget] Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Switching `master` to `main|trunk` https://github.com/helm/helm/issues/8412 [Matt Fisher] Any possible issue about moving over? Test and research to avoid any downtime/issues Fisher to investigate further Some background: https://github.com/chancancode/branch-rename/ V2 end-of-support progress: https://github.com/helm/helm/issues/8343 [Bridget] Ongoing triage of v2 issues and v2 PRs Does https://github.com/helm/helm/issues/6710 need a v3 tag? (We may or may not fix it for v2, but it lacks a v3 tag and people claim it affects v3.) When do we want to release 2.16.10? Can we get a second review on https://github.com/helm/helm/pull/7360 to unblock that? Is there anything else we want to get in? The “latest” problem: if we’re releasing 2.x and 3.x close to each other in time, we should do 2.x first? This affects what shows as https://github.com/helm/helm/releases/latest and on the https://github.com/helm/helm highlighted as “Latest”. Ongoing docs updates Triage party … Jul 15 10am … based on 2 responses. Do we want to go forward with it ? Bridget will do a triage of issues/prs to add labels for 2.x Paul will do triage of labelled 2.x and close or add to existing helm2 eol issue tasks. Helm Project Pavilion at KubeCon EU Virtual Karen thinks we should do it Office hours on zoom Need volunteers to sign up Karen to follow up on this OCI discussion https://github.com/helm/helm/issues/8387 [Josh] Need discussion with Fisher and Farina at least to help progress Need maintainers to make a call to get there Josh to set-up a meeting with maintainers, doodle to get a timeslot Known issues with EINTR introduced in Go 1.14: https://golang.org/doc/go1.14#runtime [Martin] Go 1.14 changed how it wraps system calls for interrupts This is an issue for k8s - is it an issue for Helm? Fisher: yes, this is an issue for plugins Martin: if there is an interrupt/capture we are safe - are we doing any waits when creating k8s resource? Fisher: I don’t think this affects us… “famous last words” Martin to track in an issue Kubecon Helm deep dive (scott/paul) … any specific call outs ? Helm 2to3 plugin (demo) Helm postrender hook (demo) Thanks/<3’s for Michelle Thoughts on growing core maintainership [Karen] Karen talking about making it a public announcement Karen to market this initiaitive Assignments for next meeting Moderator: Adam Notes: Bridget Issue Triage: TBD July 2, 2020 Assignments for this meeting Moderator: Marc Notes: Bridget Issue Triage: Fisher Announcements (items of general interest like releases, requiring no discussion) Intro to Helm KubeCon EU session input - will have script and draft video for review in mind-July - presenting session with Marc [Bridget] Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) 3.3.0 date? Open PRs on the milestone: https://github.com/helm/helm/pulls?q=is%3Aopen+is%3Apr+milestone%3A3.3.0 [Bridget] Fisher: RC1: not this week because of holidays - probably better to do Tuesday of next week - or slightly later Farina: we’ve got most things in that we wanted - let’s cut this Tuesday V2 EOL progress: https://github.com/helm/helm/issues/8343 [Bridget] Can we merge Add Apt (Deb/Ubuntu) installation instructions for Helm 2 #8136? Farina will fix the v2 version Who can review fix(tiller): Avoid corrupting storage via a lock #7360? (it also has a v3 fix: https://github.com/helm/helm/pull/7322) Who can review [v2] fix stack overflow error in helm template. #7185? (It has a v3 fix too: https://github.com/helm/helm/pull/7184) Fisher says we need to determine if the v3 parts should be merged, then look at v2 as well V2-related issues: https://github.com/helm/helm/issues?q=is%3Aopen+is%3Aissue+label%3Av2.x Don't forget to fill out doodle for times for helm 2 triage party. Paul is out again today, surprise errands. But wants to finalize date. https://doodle.com/poll/ke3vygaf75gmh53f With new 3-way merge, how about “helm restore” == “helm rollback ”? [Marc] Fisher: rollback logic is intended to preserve any ad-hoc changes Adam: upgrade a release passing in the same info - might be nice to have a “helm validate” to see if what’s in-cluster matches the release Fisher: detect drifts in state Adam: let user decide on best remedy Joe Thompson: use cases to deal with drift - 1) keep changes 2) want easy undo Fisher: find all the patches that helm does during an upgrade, take output, do selective logic? Joe T: no, I just want to reset to a known state - either a patch or a reset Adam: how does this differ from `helm delete && helm install`? Joe T: will create an issue to delineate differences from past request Fisher: a rollback is an upgrade using internal chart metadata, patching release with an old version’s info - usually going back one release Intros for interns to learn about the roles Helm maintainers play Assignments for next meeting Moderator: Adam Notes: Martin Issue Triage: Fisher, Martin, Bridget June 25, 2020 Assignments for this meeting Moderator: Marc Notes: Josh Issue Triage: Matt Fisher Announcements (items of general interest like releases, requiring no discussion) Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Helm 2 Triage Party [Paul, who has a conflict today] Paul is putting together a Triage Party for Helm 2 to try finalize it out. Suggested dates (best efforts for both US and EU times) at this doodle - https://doodle.com/poll/ke3vygaf75gmh53f. I’d like to be decided before the next meeting. Likely use Triage Party to organize. We might want to look at using it longer term to help organize daily/weekly triage. Example running on Paul’s k8s cluster - http://ad4d22aeea574488f86a87f53a180704-1568206551.us-east-2.elb.amazonaws.com/s/v2 Expected timeline for 3.3? [Marc] Currently for 3.4 but could be moved up: Fish completion https://github.com/helm/helm/pull/8111 which requires: Subcommands for the completion command https://github.com/helm/helm/pull/8314 Milestone: https://github.com/helm/helm/pulls?q=is%3Aopen+is%3Apr+milestone%3A3.3.0 Matt Fisher: looking into this yesterday, some things waiting on reviews, others maybe need to be rethought. Josh: maybe do this on this call Matt Fisher will bring up on the mailing list the need for a hard date to cut 3.3 Do we need a v2 release to merge v2 docs? [Bridget, who has a conflict today] The PR in question: https://github.com/helm/helm/pull/8323 Trying to understand what the next steps are here [fisher]: PRs just need to be merged to the dev-v2 branch and v2.helm.sh should rebuild itself from there Matt Fisher: this should be resolved, unusual situation Adding more labels to the release secret… https://github.com/helm/helm/pull/8272 [Farina] Discussion around the security concerns of this - a RBAC role that had just “List” on secrets would be given now extra information (chart name and version) which might be used to determine version used and find exploits Josh: Can this be configurable? Fisher: It would take a rethinking of storage implementation Farina: maybe there is some other way to do this V2 EOL tracking issue https://github.com/helm/helm/issues/8343 [Farina] Should we make tiller undownloadable (the container image)? This might create a large number of support questions Assignments for next meeting Moderator: Marc Notes: Bridget Issue Triage: Fisher June 18, 2020 Assignments for this meeting Moderator: Martin Hickey Notes: Matt Fisher /Bridget Issue Triage: Josh Dolitsky Announcements (items of general interest like releases, requiring no discussion) 3.2.4 and 2.16.9 released Possible 3.3.0 RC1? Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Some repos in https://github.com/helm/ haven’t been updated since 2018 - does someone want to mark them as archived? [Bridget] Adam: some maybe - for others we might want to accept issues - we need to review them to see Bugfixes for v2 were going to end May 13, but now they are planned to end Aug 13. That is less than 2 months away. Can we get some maintainer eyes on ones like https://github.com/helm/helm/pull/7360? (7 open v2.x PRs; 16 open v2.x issues [Bridget] Paul C will organize a bug-bash cleanup party for 2.x Subcommands for the completion command https://github.com/helm/helm/pull/8314 [Marc] Who needs to be involved for this type of change? Adam thinks this shouldn’t be an issue - think of it like the API - if it’s refactoring but no CLI changes that’s fine Blocking contribution for Fish completion https://github.com/helm/helm/pull/8111 Too late for 3.3? Adam: Time to season isn’t as critical - we can review for 3.3 if it’s in soon Marc: it’s also not super time-critical `tpl` function is non performant for Umbrella chart which contains large number of sub-charts (120 in this case) Ref to: https://github.com/helm/helm/issues/8002 Confirmed by Matt Butcher Adam: the bug report was around performance Martin: listed as bug/help-wanted Need reviewer on https://github.com/helm/acceptance-testing/pull/84 and feedback on https://github.com/helm/acceptance-testing/pull/81#issuecomment-643952826 [Predrag] Marc looking at it in limited time How to properly handle force-pushing in a review? [Marc] Fisher: ends up being a full re-review - lacks context of what changed since last review Adam: github allows squashing for more useful history later Martin: multiple commits in a PR makes cutting the release challenging - squash at the end is helpful YouTube playlist Marked as private by default Need to follow up [Bridget will check] Assignments for next meeting Moderator: Marc Notes: Martin Issue Triage: Matt Fisher June 11, 2020 Assignments for this meeting Moderator: Matt Fisher Notes: Josh Dolitsky Issue Triage: Matt Farina Announcements (items of general interest like releases, requiring no discussion) Helm 2.16.8 was released yesterday [Fisher] Security issue that affect 32-bit arch on older version of Go, CVE for 1.13.6 and below Helm 3.2.3 was released [Farina] 3.2.2 botched due to release hiccup, 3.2.3 has everything meant to be in 3.2.2 CNCF webinar tomorrow - join and heckle! https://www.cncf.io/webinars/cncf-project-webinar-charting-your-voyage-to-helm-3/ [Bridget] Tell your friends! Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) The use of .Files.Get (and other methods) in templates from subcharts but being called in parents. What should the scope of .Files be? The subchart or the parent? https://github.com/helm/helm/issues/8266 [Farina] .File.Get scoping is in whichever chart you are operating on Will this break peoples current expectations We should at least try to understand it and document current functionality Afterwards, maybe we can take action on Helm 3. Need to ensure backwards compatibility so as not to affect older charts Large release objects, again… https://github.com/helm/helm/issues/8281 [Farina] Wasn’t there an issue to remove manifests from release objects? (Bridget adds: Do we want to finish https://github.com/helm/helm-www/pull/538/ https://github.com/helm/helm-www/pull/558 without the input of the original submitter, who is slow to reply? (We were waiting for the 3.2 release which has happened.)) Manifests are each base64 encoded, then gzipped. Can we just not base64 encode it so gzip could work better? [farina] If we change underlying storage, it would break migration from 2-to-3 [martin] People trying to use Helm as a higher-level tool (like Chef), we should document strategies [Farina] This has been an issue for a long time, maybe there is something we can do to optimize the storage (i.e. double storing things) [Adam] Allow other storage backends? [Bridget] 3.3.0 release? [Farina] Please maintainers, review PRs in the milestone Link: https://github.com/helm/helm/milestone/89 Release candidate possibly next Thursday New feature: Add external files to a chart install https://github.com/helm/helm/pull/8227 requested in https://github.com/helm/helm/issues/3276 [Vlad] Probably not slated for 3.3, will add to 3.4.0 [Fisher] Assignments for next meeting Moderator: Martin Hickey Notes: Matt Fisher Issue Triage: Josh June 4, 2020 Assignments for this meeting Moderator: Adam Notes: Bridget Issue Triage: TBD Announcements (items of general interest like releases, requiring no discussion) Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) BLM support statement for Twitter and/or Helm website [Karen] Is this something we need to run past CNCF? [fisher] Linkerd and Prometheus already have tweets [Bridget] Discussion - all agree: We should check with the CNCF and follow their guidance. Bridget to follow up. Discussion of changes in unit tests for chart fixtures [Adam Reese] Continuing from last week Adam will open an issue to continue the discussion Wants to change the practices around test fixtures How do we want to document the methods of Linux installs for the various distros? https://github.com/helm/helm-www/pull/641 [Matt Farina] Farina: Do we want to point to a startup’s installation that is not a well-known source? Adam: we could use a link instead of copy-paste instructions. Martin: we shouldn’t include a link if we’re unsure about the source Farina: “reputation” is a squishy thing Adam: even with homebrew we don’t control what goes into the installation process Farina: is referencing a third party a recommendation of the third party? Helm is providing links to third parties, ymmv, not an endorsement. Josh: do we want to release our own fpm, deb, rpm, etc? https://github.com/jordansissel/fpm Adam: we had requests for snap, etc - hard to draw a line. Farina: will take action to update install docs to say the Helm community and link (not copypasta) Farina: Packaging matters but also working with every packaging system increases complexity. Farina and Butcher - please ack if all points are clear now in https://github.com/helm/helm/issues/8175 [Predrag] Farina: I’ll look through it and consider - will look at implications 3.3.0: let’s set a date. [Bridget] Farina: will start reviewing Adam: add anything to milestone for next release OCI: let’s get “install chart from registry” in. [Bridget] https://github.com/helm/helm/pull/7613 #7613 does not implement this, but it's a prerequisite [Josh] https://github.com/helm/helm/issues/6982 We sign release artifacts but nobody verifies the signatures! PR to add GPG verify in install script on Linux https://github.com/helm/helm/pull/7944 [Josh] Misc. OCI-related PRs (* can we get these ones in for 3.3?) [Josh] * Unique digests (bug): https://github.com/helm/helm/pull/8216 * Crashing “helm chart list” (bug): https://github.com/helm/helm/pull/8220 * Tags that look like ports (bug): https://github.com/helm/helm/pull/8199 * Improve repo parsing (bug): https://github.com/helm/helm/pull/8089 Appears a duplicate of https://github.com/helm/helm/pull/7236 ? * Fix for --registry-config (bug): https://github.com/helm/helm/pull/7356 * Display manifest digest instead: https://github.com/helm/helm/pull/8249 Built on top of #8216, should be merged after * oci:// dependencies + Getter: https://github.com/helm/helm/pull/7613 This the same one from Bridget’s topic Related: git dependencies: https://github.com/helm/helm/pull/6734 Experimental Notary support: https://github.com/helm/helm/pull/7829 Custom TLS config: https://github.com/helm/helm/pull/7844 Assignments for next meeting Moderator: Marc Notes: Josh Issue Triage: Farina May 28, 2020 Assignments for this meeting Moderator: Adam Notes: Martin Issue Triage: Fisher and Bridget Announcements (items of general interest like releases, requiring no discussion) Help with Q&A at today’s “Hands-on Helm” session at DockerCon! [Bridget] Free registration for DockerCon 2020: https://docker.events.cube365.net/docker/dockercon and look for email with subject “Registration Confirmation: DockerCon 2020 LIVE”; click link in email to log in. Navigate to Jessica Deen’s Hands-on Helm session: https://docker.events.cube365.net/docker/dockercon/content/Videos/ZbxZrH75SKqf78x2S - it’s a 30min session from 12:30pm-1pm Pacific (3:30pm-4pm Eastern) Hang out with Bridget in the live chat and share your opinions/answer questions! Discussion (Suggest five-minute discussions with a sentence or two about what you’d like to discuss, a link to the issue(s), and your name. Discussion suggestions may be moved to future weeks or GitHub, if warranted.) Discussion of changes in unit tests for chart fixtures [Adam Reese] Will talk again next week and maybe have a pattern Referencing chart fixtures in other packages etc. So Adam did a review and refactor Smaller text fixtures and keep in memory - Martin suggests documenting some patterns of how we suggest doing this Goal: to reduce code bloat of unit tests (Farina is out - carry over to next week) How do we want to document the methods of Linux installs for the various distros? https://github.com/helm/helm-www/pull/641 [Matt Farina] Followup from May 14th: There is a proposal around managing repository configuration in cluster; thoughts? https://github.com/helm/helm/issues/8175 [Predrag] Predrag to reach out again on GH to Farina and Butcher https://github.com/helm/helm/issues/7877 was closed but raises a possibility that would be nice to support of reusing the installed version of a chart [Joe Thompson] Why specify the chart instead of the chart embedded in the release? Taylor says we don’t have metadata for that, but we do have a proposal Adam thinks this is possible, Martin not so sure Joe is going to take a stab at a proposal Making the best of Cobra 1.0 for completion https://github.com/helm/helm/pull/8131 . How about a “Completion 101” session to get more maintainers up to speed? [Marc] Patch gets rid of some overhead code and move to Cobra 1.0 To help get patch reviewed, Marc is willing to do a 101 session around completion OCI topics [josh]: Regression since 3.0.3, non-identical digests for identical charts: Issue: https://github.com/helm/helm/issues/8212 PR: https://github.com/helm/helm/pull/8216 Larger issue pointed out by Matt Fisher, “`helm package` should produce bitwise-deterministic tar files”: https://github.com/helm/helm/issues/3612 Adam says this is probably a bug When you tar something order of files are not guaranteed Maybe sort files before performing tar Could it be because of packaging dependencies also? oci:// chart dependencies PR: https://github.com/helm/helm/pull/7613 Josh looking for maintainers to review and get merged “helm chart list” with large cache causes “too many open files” - issue+fix coming Show digest for chart, or manifest? Or both? Digest is being shown for the chart and not Assignments for next meeting Moderator: Adam Notes: Bridget Issue Triage: TBD May 21, 2020 Assignments for this meeting Moderator: Bridget Notes: Farina Issue Triage: Butcher Announcements (items of general interest like releases, requiring no discussion) Helm project journey going to be released next week [Farina] CNCF spotlight on Helm sometime in June [Farina] Helm webinar June 12 [Farina] Discussion (include issue links and your name) (To ensure enough time for discussion items, we may not do a formal standup depending on the number of items. Please add discussion items as desired.) Request for a role (moderator/notes) to upload recordings to youtube playlist [Jeff] Fisher is working on this using automation around Splain The videos are uploaded as private and someone needs to make them public Timeline of merging docs (helm-www) prior to a release? [Josh] There was a case where docs were merged prior to a feature We have a longer issue of versioning for docs we are looking for someone to help with Suggestion, when a new feature is documented we should document the version it’s available in. Martin suggested a GitHub milestone for docs. Return ChartLoader Interface instead of the Chart Path when using LocateChart API. [Vibhav] https://github.com/helm/helm/pull/7601 Fisher: additional context is required Adam: will take a look Farina: we will not change function signatures or returns, but old deprecated functions will remain New helm options and/or removing klog flags [Marc]: https://github.com/helm/helm/pull/8067 https://github.com/helm/helm/pull/8095 Grouping commands was reverted but Marc thinks the command grouping needs to be back in. No urgency on making these changes Needs to be reconciled with Adams other work. I was looking into a bug about dependencies.enabled flag, which led me to find some code that didn't seem to get ported to v3 very well, which is corroborated by some of the other open issues. [Jeff] https://github.com/helm/helm/issues/8155 https://github.com/helm/helm/issues/7908 https://github.com/helm/helm/issues/7389 https://github.com/helm/helm/issues/5780 https://github.com/helm/helm/issues/8118 https://github.com/helm/helm/issues/7993 In the short term, I'd like to get some clarification if we should enable the enabled flag (https://github.com/helm/helm/pull/8138 ) or instead remove it from the documentation. Butcher has done some auditing - broken in several places Butcher has blocked off a sprint to take a look into this once the lint work is in A classic issue from Farina - Add Warning when installing or upgrading a deprecated chart #3724 [Bridget] https://github.com/helm/helm/issues/3724 fixed in v3 but the committer doesn’t seem to have come back to fix it in v2. Do we want this warning in before we stop making bugfix changes to v2, given that deprecations are bound to be common for v2 users over time? If so, maybe we get a volunteer to backport the fix instead of waiting for that committer? (looks like Martin may have some context) We agreed this should go into v2 [we ran out of time at this point] Linux installs [Farina] https://github.com/helm/helm-www/pull/641 Followup from the last week: Managing repository configuration in cluster https://github.com/helm/helm/issues/8175 [Predrag not able to attend today], please share your feedback on the issue (if time permits) https://github.com/helm/helm/issues/7877 was closed but raises a possibility that would be nice to support of reusing the installed version of a chart [Joe Thompson] Assignments for next meeting Moderator: Adam Notes: Martin Issue Triage: Fisher and Bridget May 14, 2020 Assignments for this meeting Moderator: Josh Dolitsky Notes: Bridget Kromhout Issue Triage: Matt Farina Announcements (items of general interest like releases, requiring no discussion) V 3.2.1 released Discussion (include issue links and your name) (To ensure enough time for discussion items, we may not do a formal standup depending on the number of items. Please add discussion items as desired.) make test-style seems to fail and be ignored on circle-ci https://circleci.com/gh/helm/helm/12123 [Marc] Fisher will help; this is fixed on master for now according to Marc Fisher says the warnings may need to be handled differently Review needed for plugin loading refactor https://github.com/helm/helm/pull/7906. [Marc] Blocks: Contribution https://github.com/helm/helm/pull/8111 from a new contrib - blocked by existing PR (we should avoid breaking plugin completion) Fish completion Dropping the internal package “completion” Improved custom completion (adding descriptions) Upcoming improved Zsh completion (with descriptions) Does someone have time to look at this now or pair with Marc? Fisher and Marc will look at this together (Scott R may join as well) Managing repository configuration in cluster (alternative to .config/helm/repositories.yaml), elevator pitch [Predrag] At Red Hat they’ve been looking at options to store/read helm charts from a repo instead of a local file Does this make sense for the community upstream? Fisher: use case vs local fs? Predrag: centrally administered configs Fisher: similar projects exist Predrag: they’re complimentary but not the same - in this case, not forbidding local repos but want to whitelist an approved set of repositories - this pre-populates configuration Farina: is the use case a read-only env? Or to help a new dev get running more quickly? (Yes) Butcher: Also this eases sharing between teams of devs Farina: helm fetch/install work with a URL without you needing to add the repository first, for CI use cases Predrag: this is more to share pre-defined configuration for developers Marc: centralizing repo choices for a cluster is good but then may be inconsistent between clusters. This could actually be a feature, where only some repos are allowed for some clusters? Farina: a typed secret could be better than a CRD, since some can’t use that. Rigby: also would the CRDs be namespaced? If not, doesn't that move away from the goal of moving helm from cluster-wide to namespace only? Rigby: Also in general, doesn't this also move away from Helm's move to client-only? It sounds interesting in general, though my thought is similar to Matt Fisher's (related more to operator CRDs like fluxcd) Pred: Will follow up with an issue Artifact stability/OCI: where are we? Let’s make a checklist and get there - there are open issues but I don’t see a summary of the status. [Bridget] Josh D: This was main part of OCI meeting discussion yesterday: https://www.youtube.com/watch?v=E9WNkklCmuc Josh: Farina was named - the OCI meeting said it needed a list from us of what it takes to remove the experimental flag Bridget: yes - let’s figure out our plan/make sure it’s visible Josh D: OCI dependency PR? https://github.com/helm/helm/pull/7613 Farina: is this a spec waiting for everyone to use it, or can it be depended on? (Is it “trusted” or “already there”?) Farina: Distribution spec is concerned with container images. Is the artifact spec something we can stably rely on? Josh: Helm will drive a lot of this - we could call it a best practices guide and say “this is how helm is using the API” Farina: we’ll be going off the documented beaten path if we stick things that aren’t images in Fisher: Docker Distribution can be more compliant Butcher: the main reason we don’t want to move the experimental flag off is that there is a lot of documentation to do because not all repositories are OCI-compliant and allow chart types. We shouldn’t remove an experimental flag and confuse average users. Farina: The alternative option here is to discuss pulling the artifacts proposal out of OCI entirely and rely on chartmuseum/harbor to support that functionalit yBut then we lose out on those OCI compatibility guarantees we were touting at Helm 2 Josh: will take action to try to explain more clearly. [This is as far as we got. Pushing other topics to next week. --Bridget] Return ChartLoader Interface instead of the Chart Path when using LocateChart API. [Vibhav] https://github.com/helm/helm/pull/7601 Timeline of merging docs (helm-www) prior to a release? [Josh] Request for a role (moderator/notes) to upload recordings to youtube playlist [Jeff] Assignments for next meeting Moderator: Bridget Notes: Farina Issue Triage: Butcher May 7, 2020 Assignments for this meeting Moderator: Martin Hickey Notes: Matt Farina Issue Triage: Matt Fisher Announcements (items of general interest like releases, requiring no discussion) (Team Microsoft is on vacation today, so none of us are on this call) Cutting 3.2.1 release Discussion (include issue links and your name) (To ensure enough time for discussion items, we may not do a formal standup depending on the number of items. Please add discussion items as desired.) Install charts with HELM_REPOSITORY_CACHE=off (vibhav) https://github.com/helm/helm/issues/7545 https://github.com/helm/helm/pull/7601 The goal of this effort is to be able to run helm install/upgrade/template in a read-only file system. Kubernetes config would be injected via an injected volume (e.g., when running in a pod). For this use case a full url or path would need to be passed to Helm to install. This would bypass registries. How would this be tested? Do we need a test run in a read-only environment? Might be useful for making chart-test github actions read only … and those would then help verify it works. OCI - what are the steps to get off of experimental (josh) Issues left before distribution-spec 1.0: https://github.com/opencontainers/distribution-spec/milestone/3 OCI charts as dependencies: https://github.com/helm/helm/pull/7613 Current registry support: https://helm.sh/docs/topics/registries/ [farina] the issue that’s a blocker is the lack of stability out of the OCI on storing artifacts. Will it change? What guarantees of a stable API are there? We are waiting on the OCI. [josh] is interested in a better configuration experience other than environment variables. Possibly something like the way git does it. The hold up isn’t the UX (which we could work on). It’s OCI artifact stability Assignments for next meeting Moderator: Josh Notes: Bridget Kromhout (unless someone present at the May 7th meeting really wants it!) Issue Triage: Matt Farina April 30, 2020 Assignments for this meeting (Matt^3!) Moderator: Matt Farina Notes: Matt Fisher Issue Triage: Matt Butcher Announcements (items of general interest like releases, requiring no discussion) Graduation!!!!!!!! https://twitter.com/HelmPack/status/1255892071002411009 Bridget: Mention @helmpack in your tweets if you want (if you write a blog post or something) Discussion (include issue links and your name) (To ensure enough time for discussion items, we may not do a formal standup depending on the number of items. Please add discussion items as desired.) (moved from April 23) XDG_DATA_DIRS Support https://github.com/helm/helm/issues/7529 [Vibhav] Farina: should be in in the next month or so Paul C: encourages summary; Farina summarizes: tldr, we’re adding better support in Helm for multiple directories and/or overriding it (confirmed for April 30) Demo: Paul’s helmfile-starter-kit demo (https://github.com/paulczar/helmfile-starter-kit) - demo and discussion expected to take 10 min [Paul C] Good way to use https://github.com/roboll/helmfile Celebrating! Assignments for next meeting Moderator: Martin Notes: Farina Issue Triage: Fisher April 23, 2020 Assignments for this meeting Moderator: Adam Notes: Farina Issue Triage: Fisher, Adam Announcements To ensure enough time for discussion items, we will not do a formal standup. Please add discussion items as desired. [Bridget] Releases this week: 3.2.0, 3.1.3 [Matt Farina] CVE button! Neat features! CNCF Graduation - ready your blog posts! [Bridget] Probably next week - we don’t have exact timing set by the CNCF yet Discussion (include issue links and your name) Means to override the XDG Base Directory Specification: https://github.com/helm/helm/issues/7919 [Martin] Action items remain Seems can set specific Helm env vars Can I add helm to the list of projects using Cobra? https://github.com/spf13/cobra/blob/master/projects_using_cobra.md [Marc] Yes; everyone agrees this is a good thing Contributor Beginner’s guide: Logging in different packages? [Marc] Farina mentioned a need for a beginner’s guide Questions answered for new maintainers and users PR template from Helm 2 needs to be added for Helm 3 - Bridget will take as action item to solve problem of drive-by PRs sans info. Doc on k8s APIs (https://github.com/helm/helm-www/pull/559) [Martin] Looking for reviews on it Adam will look at it Mystery Circle CI failure [Josh] See https://github.com/helm/helm/pull/7613#issuecomment-617984152 Failure: https://circleci.com/gh/helm/helm/11875 Any reason not to upgrade Go version to 1.14+ ? Josh will try updating to 1.14 PGP signature verification in install script [Josh] PR/discussion: https://github.com/helm/helm/pull/7944 Disabled by default, enable with VERIFY_SIGNATURES=true Current plan: Fetch KEYS files from GitHub, @master (all maintainers keys) Create a temporary keyring, import KEYS file Fetch .asc files for .tar.gz and .shasum on release Verify the .asc files against temporary keyring using gpg Delete temporary keyring Github actions suggested; Josh will chase down `helm dep up` seems to traverse directories all over - file an issue? (Joe Thompson) Must dependencies be documented in charts.yaml? (in theory, yes) Will start a more general issue to describe this re: dependency resolvers Mini-retro on no standup (started with 3 minutes to go) [Bridget] Pro-standup: it’s a point of connection with each other Anti-standup: if lacking a specific accomplishment, one may feel like skipping the call Resolution: for now, let’s see how many discussion items there are Assignments for next meeting Moderator: Matt Farina Notes: Matt Fisher Issue Triage: Matt Butcher April 16, 2020 Assignments for this meeting: Moderator: Matt Fisher Notes: Bridget Issue Triage: Butcher, Josh D Announcements 2.16.6 released: https://github.com/helm/helm/releases/tag/v2.16.6 Fixed one issue; there’s another issue in there [Farina] Standup Martin Hickey Triage, PR reviews implementation in plugin for removing deprecated APIs for supported ones (for v2) - similar to how it’s done in v3 Josh Dolitsky Issue triage Marc Cobra 1.0 is out - custom go completion - but cannot move Helm to it because of breaking plugin completion (#7906) Matt Farina Working on translations process - first file being translated into Korean landed in helm-www! Also release, and PR triaging, and docs. TOS having discussions about graduation - waiting for TOC to call a vote, which takes about 5 days and then PR Matt Butcher Issue queue - getting 3.2 ready Bridget Graduation Blog Post and preparations - PR cycle is slow but we’re getting started Paul C Presentation on allthetalks - building a chart Matt Fisher Providing context on issues Discussion Transition Helm release and chart hosting ownership to CNCF [mattfarina] https://github.com/helm/community/issues/114 Affects charts repository - looking for a process to handle moving this Hosting this is financially non-trivial Technical considerations around moving buckets This affects helm downloads, chart downloads, and CI Ihor and Chris A have eyes on this Org, charts, and core maintainers are all impacted by this So stable going away - what's a “stablish” repo to share? Bitnami? [josh] Probably good to use Bitnami [Farina] Action item: heads up! Keep an eye on the issue. Breaking change to upstream merge library (template function) [mattfarina] Sprig uses merge-go which made a breaking change Farina mentions an issue: https://github.com/imdario/mergo/issues/139 Documentation never matched implementation and now it’s creating problems - do we pin to the working version, file an issue, and add tests to ensure safety? (Probably - we need to exclude this non-working version.) Helm 3.2 - Finalizing the Issue List [Butcher] https://github.com/helm/helm/milestone/83 Let’s cut the RC late today/tomorrow Moving to next time: Means to override the XDG Base Directory Specification: https://github.com/helm/helm/issues/7919 (martin) Paul’s helmfile-starter-kit demo (https://github.com/paulczar/helmfile-starter-kit) XDG_DATA_DIRS Support https://github.com/helm/helm/issues/7529 [added by Vibhav] CRDs not uninstalled upon uninstall. Is this by Design?[vibhav] Fisher: yes, this is by design. https://helm.sh/docs/topics/charts/#limitations-on-crds Cool thanks :) Beginner’s guide: Logging in different packages? [Marc] Assignments for next meeting Moderator: Adam Notes: Farina Issue Triage: Fisher, Adam April 9, 2020 Assignments for this meeting: Moderator: Martin Notes: Matt Fisher Issue triage: Matt Butcher Announcements Zero comments in public comment period (which is good!) - Farina will follow up with Justin Cormack as to next steps (we’re in the “voting” period) Standup Matt Farina Typical issue triage/PR review Working through the PGP release signature process There’s something going on with our GPG signing process that’s causing the verification process to fail Joe Thompson: has been looking into this as part of his course material Looking into korean translation for the helm docs Matt Fisher Issue triage Marc Khouzam Completion PRs being merged Josh Dolitsky OCI work Matt Butcher Been monitoring the CNCF graduation voting process Pairing with Adam on some of the bigger PRs out there for Helm Working with Adam on the Kubernetes 1.18 version bump PR Bridget Kromhout Got blog post out with Farina about the bugfixes for another three months Starting to think about a blog post for the graduation announcement Martin Hickey Concentrated mostly on issue 7219, which is around deprecated workload apiVersions Working on a plugin to help ease this issue There’s a PR sitting out there that Martin’s looking to merge: #7024 Discussion In-memory Cache PR Vibhav: Looking to give a demo on the in-memory cache demo Predrag: Further elaboration on the use case for the in-memory cache: we’re looking to run Helm in an environment without access to the filesystem Matt Farina: the pluggable proposal can be discussed offline - https://github.com/helm/helm/issues/7545 Allow patching/updating CRD resources after first install (https://github.com/helm/helm/issues/7735) [Martin] James Munnelly to pitch proposal (parking this - no word back from James) Is the SQL storage backend supported or beta? Fisher: this is available in a pull request: https://github.com/helm/helm/pull/7635 Some serious security issues were found in the PR. They’re irrelevant for Helm 2, but was introduced when porting to Helm 3. I think it needs another review At that time when originally added, only postgres was available Butcher still doesn’t think this is out of beta Need second reviewer on https://github.com/helm/helm/pull/7791 (multiple repo remove) [Marc] Making unit tests results less dependent on test environment setup (e.g. run tests under an arbitrary UID, local kubeconfig file should not be used, assume nothing about default namespace, etc…) [predrag] This is in reference to `helm test` We’re looking for help to review some of the use cases we have on our end Matt Butcher volunteered to help look into these use cases Assignments for next meeting Moderator: Matt Fisher Notes: Bridget Issue Triage: Butcher, Josh D April 2, 2020 Assignments for this meeting: Moderator: Adam Reese Notes: Josh Dolitsky Issue triage: Matt Farina Announcements 2.16.5 - released with new fixes and bugs! ChartMuseum 0.12 released Friday Standup Josh Dolitsky ChartMuseum 0.12 released Friday Matt Fisher PR reviews and triage Bridget No update (just helped with blog post which is going out this week) Matt Butcher Blog on Helm+Operators Pairing w/ Adam on some bugs Version inconsistencies with k8s Matt Farina Fix issue w/ Kubernetes 1.15 Working on - Give resource info in helm status back SOMETIMES things blow up Looking into support for translations (on docs) Marc K Review on cobra completions coming soon Martin Triage PR reviews Adam Pairing, issues queue, PR reviews Version breaking issues with Kubernetes, Very frustrated. Discussion Plan for the Security Story, it is a good time as this can be taken alongside the design of Notary v2. [Vibhav] Pushed to next week (vibhav gone) Thoughts on extending the support period for Helm 2, given that the global situation might be leading to code freezes and thus enterprises not moving off Helm 2 to Helm 3 with alacrity? [Bridget] The original plan was bug fixes for 6 months after the Helm 3 initial release (ending May 13 2020) and a year of security fixes (ending Nov 13 2020) Can we measure the number of Helm 2 users remaining (downloads, other metrics)? Butcher: maybe lets push back bug fixes by about 3 months All: agree Action: blog post on helm.sh Matt Farina + Bridget to take Allow patching/updating CRD resources after first install (https://github.com/helm/helm/issues/7735) [martin] James Munnelly to pitch proposal Push to next week (james gone) Cache Drivers for Helm. Pushed to next week (no link no vibhav) [Ken Perkins] I’m hoping to discuss extensible labels for release artifacts (secret/configmap storage driver) as a way to have consistent labeling across all resources related to a release (useable with selectors), https://github.com/helm/helm/issues/7007 Context - doing backup using Velero, needs more granular backup Velero: https://velero.io/ The release driver for secrets plus configmaps is hardcoded No ability, unilaterally, to get labels defined by user Adam: there has been discussion on this previously 1. Policy on not wanting to touch resources, fully unopinionated Haven't found clean way to do this Jacob: There is a PR using annotations vs labels Link: https://github.com/helm/helm/pull/7649 Merged but unreleased, in 3.2 milestone Ken: annotations might not cover it Adam: in favor of labels option being added, but was unable to find a clean way to do so previously Matt Farina: this may be doable with postrenderers Adam: labels - will make upgrade much easier Assignments for next meeting: Moderator: Martin Notes: Matt Fisher Issue triage: Matt Butcher March 26, 2020 Assignments for this meeting: Moderator: Josh Dolitsky Notes: Matt Fisher Issue triage: [help wanted] Announcements Helm v2.16.4 and v2.16.5 released [mattfarina]. 2.16.4 contained an issue when working with Kubernetes 1.15 Standup Marc Disrupted with COVID-19 Continuing to hope for fish completion PR review https://github.com/helm/helm/pull/7690 Matt Butcher Away all last week Adam Disrupted by COVID-19, nothing to report this week Bridget Mostly focused on SMI things Matt Farina Cut Helm 2.14.4 and 2.14.5 Issue and PR triage Martin Issue and PR triage Fix for the helm 2to3 plugin (some tests weren’t migrating over) Matt Fisher Issue triage; another open source project Bug reviews Scott Rigby We have RC releases out for chart-releaser and updated the github actions around that More work on the chart repositories (tracking issue) Worked on a PR to make downloading different Helm 3 binaries easier Jacob LeGrone Have an internal change of `helm commandeer`, will open a PR eventually once that’s ready to go Josh Dolitsky Fighting with Go 1.14 and tests Advancing the OCI spec Discussion Notary / TUF compatibility or support ( how do we go about it ? ) [Vibhav] Pushed from last week Discussed with Radu on some of the design discussions around Notary/TUF support Question raised to the call: are we looking to get the experimental OCI feature into a stable feature? Josh D and others have been working on ORAS - works for arbitrary artifacts: https://github.com/deislabs/oras Josh D: “There is also an ongoing “notary v2” discussion going on in OCI #notary-v2 channel in CNCF slack” Butcher: definition of stable: a security story, finalized OCI, community momentum Farina: let’s not move-fast-break-things - real enterprises use Helm Butcher: in summary, this would be a great time to talk about Notary/TUF support in the experimental OCI support, as that would be required for GA Some PRs needing just a bit of attention: Install / Template Charts without downloading to filesystem https://github.com/helm/helm/pull/7601 needs small input @mattfarina [Marc] Will need a bigger discussion Can we get some maintainer eyes on this PR? https://github.com/helm/helm/pull/7743 - Joe Thompson Farina will look at it Cut a release candidate for 3.2.0? - Jacob Martin: Can we get 7635 in? It’s on the milestone so we can get that one in First class image referencing support proposal presentation https://github.com/helm/helm/issues/7754 - Konstantin Semenov Presentation (5 min): https://www.icloud.com/iclouddrive/0teMaUh1a8whndQ8vgEyzKVww#Helm_image_reference_proposal Farina: we’ll mull it over Butcher: backward compat is important [this is all we got to] Diff in Helm History Command https://github.com/helm/helm/issues/7828 Thoughts on extending the support period for Helm 2, given that the global situation might be leading to code freezes and thus enterprises not moving off Helm 2 to Helm 3 with alacrity? [Bridget] Assignments for next meeting: Moderator: Adam Reese Notes: Josh D Issue triage: Matt Farina March 19, 2020 Assignments for this meeting: Moderator: Matt Fisher Notes: Bridget Issue triage: Matt Butcher / Bridget Announcements 2.16.4 release is delayed by printers (not the paper kind), per Farina Some k8s environments cannot use 2.16 right now, so this is time-sensitive Fisher and Farina will discuss Standup Matt Farina Printers! Trying to get things to display correctly (affects Helm 2 and 3 both) Have submitted Helm for CNCF graduation Process being revamped TOC member (non-Michelle, as she’s a maintainer) needs to pick up and evaluate our request - breaking news! It’s Justin Cormack of Docker! Martin Hickey Created a doc around storage backends - hoping to get it in for 3.2 Looking at plugin fixes to help with side-by-side (not entirely cleaning up) PR reviews and bug triaging Bridget Kromhout No Helm; all SMI stuff this week Taylor Thomas Reviewing Farina’s printer PR Causing earthquakes in Utah, for maximum hilarity :) Marc Khouzam Refactoring completion tests to cover Fish completion Josh Dolitsky Triage - possibly breaking changes in chart dependencies from registries Jacob LeGrone Got PR in for automatically adopting resources - hoping for Martin’s feedback - planning to add an import command to annotate existing resources Matt Fisher PR review - behavioral assumption changes, though not breaking per se (will sync with Josh D) Discussion Helm v2 utility library (https://github.com/maorfr/helm-plugin-utils/) request move to Helm org [Martin] - carry over from last week Farina is working on an email Martin is waiting for. Notary / TUF compatibility or support ( how do we go about it ? ) [Vibhav] Push to next week Some PRs needing just a bit of attention: Install / Template Charts without downloading to filesystem https://github.com/helm/helm/pull/7601 needs small input @mattfarina [Marc] Will need a bigger discussion Use repository-cache if specified https://github.com/helm/helm/pull/7166 @bacongobbler [Marc] Make side-by-side versions easier - https://github.com/helm/helm/pull/7752 [Bridget] Present what Codefresh is doing for Helm 3 and collect feedback for the team [Dan Garfield] Numerous codefresh users particularly in Europe getting ready for Helm 3 - Jessica Deen did a recent presentation using codefresh & Helm 3 Demo Time for feedback ran out - Bridget directed them to open an issue if desired for discussion Assignments for next meeting: Moderator: Josh Dolitsky Notes: Matt Fisher Issue triage: [help wanted] March 12, 2020 Assignments for this meeting: Moderator: Matt Butcher Notes: Scott Rigby Issue triage: Matt Fisher, Bridget Kromhout Announcements Early access to CNCF Hub is available: https://hub.cncf.io/ Standup Bridget: not much this week Taylor: Triage Matt Fisher: Triage, follow ups Adam: spent more time on deprecated k8s API versions Marc: Added completion to 2to3 plugin. Finished fish shell completion. Reviewing in-memory cache concept Martin: also quiet week. A few things around migration plugin. Added in capability to remove a release on cleanup. Good to see people using it, giving feedback etc. Thanks to Fisher for review of docs on library charts Scott: not much this week, heads down. Yay about cncf hub! Jacob: Worked on ownership issue. Adds a few new annotations we'd need to commit to, so please have a look. https://github.com/helm/helm/pull/7649 After merge, plans to work on import command (commandeer) https://github.com/helm/helm/issues/2730 Josh: not much to add. Hoping to get eyes on a PR: sourcing dependency charts from OCI https://github.com/helm/helm/pull/7613 Matt Butcher: Presenting to ToC on Tuesday Discussion Release 3.1.2? [Farina] Will cut later today [probably by Farina] unless someone else get there first Vision for HelmHub: how to choose the right chart for a product? [Marc] The stable and incubator Helm chart repositories, currently listed on the Helm Hub, have begun a 1 year deprecation timeline. After 6 months they will be de-listed from the Hub (soon to be CNCF hub). See helm/charts > Status of the Project and Deprecation Timeline The Helm Hub has a process for Adding distributed Helm repos, and the stable and incubator repos have a process for Deprecating a Chart once this is completed Orgs and individuals can host distributed Helm repos however they wish, but if they want to use Helm-created tools (chart testing, releasing, etc) they can follow this example to use Helm Chart repo Actions: https://github.com/helm/charts-repo-actions-demo There is a stub issue to help track migration, here https://github.com/helm/charts/issues/21103 (this will be fleshed out soon. While each deprecated chart README links to it's new home, this issue primarily to help the community see the migration at a glance) We have engaged with a number of orgs who develop the apps to host charts for those apps (here is a working list that will be added to that github issue soon https://hackmd.io/VgK7_DUpS6CLLT4HSncmDg) Helm.sh used to have a link to the sig-apps meeting recordings (not helm-specific) but now just points to https://github.com/helm/community/blob/master/communication.md#meetings - do we have a specific link or playlist we want to publish for the Helm dev call? These get recorded - but where do people watch them? [Bridget] / Posting Helm dev call videos [Marc] https://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0 Fisher will migrate videos from Zoom to Youtube Adam points out there’s a doc in keybase with the necessary info Helm v2 utility library (https://github.com/maorfr/helm-plugin-utils/) request move to Helm org [Martin] Discuss next week Docs: Improvement of library chart docs https://github.com/helm/helm-www/pull/526 [Martin] One review done by Matt Fisher. Can we get another core maintainer review? Plugin shell-completion (which is in 3.2) https://github.com/helm/helm-www/pull/506 [Marc] Fisher just approved and merged Follow-up meeting on kube 1.16^ [Marc] Adam will talk to Farina Please include Martin and Marc Should we split this file by decade? 😁 Slow on a phone in the subway. [Marc] Butcher: we could migrate past years to a markdown doc in github - Marc to open issue in community repo Please take a critical look at https://github.com/helm/helm/pull/7649 (resource adoption)! [Jacob] Assignments for next meeting: Moderator: Matt Fisher Notes: Bridget Issue triage: Matt Butcher / Bridget March 5, 2020 Assignments for this meeting: Moderator: Adam Notes: Matt Farina Issue triage: Josh Matt Farina Announcements none Standup Matt Fisher Looking at PRs for upcoming milestones to see where we’re at Looking at a PR that does `--force` Josh D Issue sherpa-ing Did not complete Chart Museum release Matt Butcher Helm graduation tasks - shoutout to Michelle Noorali for her help on that Helm Security Assurance case - to get CII Silver badge Possibly not here next week if traveling Matt Farina Has been working on Helm graduation (less pressure due to KubeCon delay) Helm is on a list with other projects for graduation consideration March 17th. (Hopefully security assurance is done by then.) Working on pitch deck for 17th. Helped with issue triage this week. Martin Library charts docs work PR reviews Scott Chart testing/release work with Reinhard Worked to move charts out of charts repo (e.g., working with nginx project maintainers to host the chart) Paul Both KubeApps and Helmfile now support Helm 3. PR in to script craft release notes: https://github.com/helm/helm/pull/7636 Jacob PR open around resource ownership. Make helm more intelligent on adopting resources. Needs work still. Bridget KubeCon EU work (intro to Helm maintainer session with Reinhard) is now put off Adam Worked on upgrading Kubernetes and depreciated K8s resources Discussion Kubernetes broken versioning [Adam] https://github.com/helm/helm/issues/7219 We rely on the libraries kubectl uses - and that no longer supports some old versions Farina: this problem is going to keep happening/get worse (because the API server/kubectl won’t work with older versions) Farina: should we add Helm lint rules around this? Fisher: yes; we should give a warning/message in these cases Adam: we could build a binary outside of helm for conversion [new meeting warranted] [ran out of time] Release 3.1.2? [Farina] Vision for HelmHub: how to choose the right chart for a product? [Marc] Helm.sh has a link to the sig-apps meetings - do we have a specific link or playlist we want to publish for the Helm dev call? [Bridget] Issue triage: how’s it going? Trends? Thoughts? [Bridget] Assignments for next meeting: Moderator: Matt Farina Notes: Scott Rigby Issue triage: Matt Fisher, Bridget Kromhout Feb 27, 2020 Assignments for this meeting: Moderator: Josh Notes: Martin Issue triage: Farina Announcements Fisher, Taylor, and Bridget are at an event today so won’t be on the call Farina did a webinar on Helm security: https://www.cncf.io/webinars/helm-security-a-look-below-deck/ Standup Marc: Cobra is very open to Go completion Adding support in Helm for Fish Adam: Reviewed some PRs Pushed a PR for fixing a lib Jacob: Resource ownership issues Matt Farina: Issue sherpa this week Lots of support questions Martin: Some PR reviews Some bug triaging Josh Talking ChartMuseum bugs One is: Storage cache issue New release of CM on the way Discussion Contributing Guide? https://github.com/helm/helm/issues/7585 [discussion suggested by Bridget, based on issue opened by Matt Farina] How do we handle things at project level? All the bits and pieces. Then handle things at code level? Maybe better code doc/GoDoc. How do you dive in? How you get started? How do you lower the barrier? Farina to maybe drive this outside of the weekly meeting? Gpg signing [mattfarina] https://github.com/helm/helm/issues/7599 Best practice for handling kube 1.16 removed APIs? Helm v2 or Helm v3? [Marc] Big issue we need to be able to handle Vanilla `kubectl` can handle this, Helm needs to be able to diff against deprecated api to new api in cluster Adama to investigate CRDs not available during `dry-run`: https://github.com/helm/helm/issues/7449 [martin] Do we document that this is a limitation? Should this issue be marked as a feature? Resource ownership refactor https://github.com/helm/helm/pull/7649 Resource ownership does not guarantee exclusivity https://github.com/helm/helm/issues/7699 Assignments for next meeting: Moderator: Adam Notes: Matt Farina Issue triage: Josh Matt Farina Feb 20, 2020 Assignments for this meeting: Moderator: Adam Notes: Bridget Announcements - none! Standup Martin Migration plugin: Kube context/kubeconfig can be set on the fly now Fun bug found about back-end storage (we weren’t catching setting that with args) Possibly need to release 3.1.1 - error not being propagated up correctly Fisher PR reviews Marc Completion coded in go - posted to cobra Working on k8s 1.16 at work - so dealing with challenges that are showing up in Helm issues - Bridget Working on Intro to Helm for KubeCon EU with Reinhard Farina Helm Hub - linting - github actions Webinar on Helm security Finding issues - putting issues into backlog Jacob Working on a bug to update resources to new API versions that exist in the cluster May suggest a new ownership heuristic soon (opt-in with label or env variable) (Fisher: maybe as a lookup) Adam PR reviews/merges XDG discussion with Farina Discussion Restore issue triage position? [mattfarina] Assign specific person/persons to do triage for a specific week Fisher: can we do assignments async on the maintainers list? Bridget: we should document how to do the triaging Farina: maintainers who aren’t core maintainers could also sign up Martin: new core maintainers can learn how to triage by pairing Farina: let’s start by reinstating the role and writing docs Add a “NEWS” file to help with release notes? https://github.com/helm/helm/issues/7581 [Marc] Merge conflicts mean a single file is a challenge Adam suggests an update to the github template Fisher will link to another tool that helps. What versions of Helm should be in docs? https://github.com/helm/helm-www/issues/497 [mattfarina] Fisher: Ronan added version dropdown list between individual versions - 2.14 does not have a specific need to be on there Adam: we’re constantly changing docs (not synced with specific versions) Farina: k8s does it with each minor release but each release is a breaking change - let’s remove the process and just have “helm 2” and “helm 3” but in helm 3 docs, specify minor version when the change came in Adam - include a section for anything that’s changed in the docs Fisher: bring it back to Ronan Farina: will continue convo with Ronan Note: topics after this point were not discussed on Feb 20 and are being suggested for Feb 27 Should we cut 3.1.1? [martin] Errors not being propagated from template/install/list Contributing Guide? https://github.com/helm/helm/issues/7585 [Bridget, based on issue opened by Matt Farina] Gpg signing [mattfarina] Porting of sql storage driver https://github.com/helm/helm/pull/7635 [martin] Namespaces and user access Best practice for handling kube 1.16 removed APIs? Helm v2 or Helm v3? [Marc] Assignments for next meeting: Moderator: Josh Notes: Martin Issue triage: Farina Feb 13, 2020 Assignments for this meeting: Moderator: Martin Hickey Notes: Matt Fisher Announcements Helm 3.1.0 released today: https://github.com/helm/helm/releases/tag/v3.1.0 Standup Matt Farina Cut the 3.1.0 release, issue triaging, bug fixes Matt Fisher Triaging PRs for the 3.1.0 release, issue triaging, PR reviews Adam Reese Nothing to report this week Taylor Thomas Post-render work, giving a talk next week Scott Rigby Working on some demos with Helm 3 and the new github actions Might work on some demos for the new post-render feature Got around to pinging people in SIG-PM regarding the “kubernetes helm charts” repo naming suggestions Matt Butcher Kubecon stuff: working on the project maintainer’s booth for AMS Taking a look at managed hooks a little bit to resurrect the architecture Helm CNCF graduation is moving through the process Action item: need to fill out the ADOPTERS.md file in helm/helm Need to spend some time to fix the gpg signing key for past helm releases Marc Khouzam Working on PRs: namespaced memory drivers and pre-populating the memory driver for test infra Jacob LeGrone Hoping to compile an experience doc for his org Martin Hickey Looking into some bugs regarding passing along the kube context for the migration plugin Facilitating discussion around contributing a new project to the helm org Discussion Scott Morgan: I’ve had a PR sitting around for a while. Looking to find a core maintainer to move this around (7060) Martin: how come the apiVersion had to be updated? `helm lint` should work with older chart APIs Fisher: to resolve this, let’s add this to 3.2.0 so we can review it for the next release Travis raines: https://github.com/helm/chart-testing/issues/202 Taylor: I’ll have to dig into this one a little more. --wait can be a bit of a finicky thing and can’t tell what’s the issue immediately https://github.com/helm/helm/pull/6920 “helm upgrade --install” purposefully ignores installation errors. Why? [Marc] Butcher: I’ll review this offline Should helm env show XDG paths? https://github.com/helm/helm/pull/6892 Result of offline discussion between Farina and Adam? [Marc] Farina: we shouldn’t be showing XDG-related environment variables. We should expose it as a Helm-specific variable in its place Action item: farina to push a PR Should Helm transform API versions? https://github.com/helm/helm/pull/7575 [Farina] Farina: the code has changed significantly since it was originally posted, so I can’t start a discussion on this. We’ll have to revisit this PR before discussing. Assignments for next meeting: Moderator: Adam Notes: Bridget Feb 6, 2020 Announcements Sessions scheduled for KubeCon EU (Bridget, credit to Karen Chu): Intro: https://sched.co/Zx1Z Deep Dive: https://sched.co/Zx4K Standup Farina Triaging issue queue & pull requests Adding items to 3.1.0 at this point Looking at translations for the website right now Helm hub growing Marc Posted a PR for memory driver to support namespaces - wants to preload releases in memory driver Autocompletion for plugins Adam Catching up - getting back into Helm Martin Fix around lockfiles In Ghent for config mgmt camp to speak about Helm with Taylor Fisher Helm website changes around updating helm commands in the docs Working with Ronan to have good fallbacks for deprecated commands High-level items & focus on 3.1 Taylor Config mgmt camp with Martin - worked up good advanced helm demos Working on post-render Working on devopsdays Guad. talk (in Spanish!) about Helm Butcher Working on TOC review docs for graduation - researching “security assurance” cases & markdown doc with list of companies using Helm Triaging issues/reviewing PRs - kudos to Martin on a tricky one! Bridget KubeCon EU talks, yay! Discussion When should we cut the 3.1.0 RC? (Farina, Bridget) RC 3.1 tomorrow (Feb 7) - Farina willing to cut the release Release 3.1: tentatively, Feb 13 RC 3.2 March 11, release March 18 One last sync up on post render [Taylor] Farina considered this to be for one-off scripts and trying to understand use case Martin: this capability has some inherent risks - perhaps we should document more than restrict Farina wants a good pattern for this; Taylor is going to comment/explain future enchancements. What should we do with https://github.com/helm/helm/issues/6794? [Taylor] Namespace mechanism is more declarative than before - but might be okay? [Taylor] Farina: you’re moving namespace choices from one role to another with this change Fisher: The role conflicts aren’t fixed by this PR - the lookup functionality is the same. Farina suggesting an opt-in flag for auto-creation Adam: it was a much-desired feature to limit releases to a namespace Should helm-plugin-utils (https://github.com/maorfr/helm-plugin-utils) be moved to Helm org? [Maor/Martin] Fisher: is this a Helm2-only plugin? If so we’d want that to be clear Farina: there is no license on this repo yet Should helm env show XDG paths? https://github.com/helm/helm/pull/6892 [Marc] Marc: XDG paths get default values when no set, which are hard to discern Farina: debugging is difficult for XDG - this workaround would make our lives easier Adam: XDG is unix/linux specific, so we probably want to call this “config root directory” or some such Farina: we have an issue about setting locations - the ability to use multiple path separators doesn’t currently work Adam & Farina will follow up offline Update on --name flag https://github.com/helm/helm/issues/7345 [Marc] Marc: Farina noted that many READMEs mention this Fisher: core maintainers are making design decisions - we’ll listen but not change based on one community member’s opinion [note: meeting ran 45min so we could discuss items d, e, and f] Assignments for next meeting: Moderator: Martin Hickey Notes: Matt Fisher January 30, 2020 Announcements Jan 29 release of 3.0.3 by Matt Farina: https://github.com/helm/helm/releases/tag/v3.0.3 Standup Marc Skip - internet connection flaky Farina 3.0.3 release Issue and PR triaging and reviewing Butcher Issue queue triaging Martin Working on issue where hash was created in helm v2 and now trying to validate with helm v3. Working on a fix with tests Working on setting kubectx or kubecfg as part of migration (plugin) Triaging and reviews Taylor Working through his backlog Working on post-render feature with a target on 3.1.0 Created a repo of advanced Helm demos for an upcoming talk Fisher Issue triaging and PR queue. Trying to poke some PRs and make sure they have what they need to move on Bridget Learning about release process Discussion Let’s discuss a date for 3.1.0 (Farina) Farina: Can we do this in mid-Feb? Taylor: let’s make sure the k8s libraries are updated Yes: Joe Langford did this Fisher: let’s check a few regressions, but yes, this could work Farina: by the call next week, we’ll know when we can cut the RC Fisher: will put some PRs for discussion in the helm dev channel Prettify Updated time in helm ls [Martin]: https://github.com/helm/helm/pull/7024 Breaking change or not? Helmsman (a 3rd party tool) is consuming the table and the time Potential path forward: Move to local timezone and remove the fraction of a second. It’s same format with difference in accuracy See what this means for helmsman and parsing the information Would be nice for ls and history to be consistent Dependency digest differs between Helm 2 and 3: https://github.com/helm/helm/pull/7261 [Martin] Need review and feedback if right approach Fisher: consistent calculation? Farina: there is a complication around dependencies with v1 vs v3 of library Martin: some reverse engineering of hash Farina will review Update on --name flag https://github.com/helm/helm/issues/7345 [Farina] Farina: lots of charts use this - we can make it a hidden flag Fisher: Helm 3’s refactoring of argument/flag parsing is less complex so this is more straightforward for the CLI - we still have to look at the SDK (might be okay) Farina: we’re less worried about the SDK and more about copypasta 3tutorials Taylor: let’s be careful of precedent Fisher: let’s assert this is a case-by-case decision, and not a precedent Farina: a valid case exists here, and they get a deprecation message. This isn’t a “we support it forever” scenario. Assignments Moderator: Matt Fisher Notes: Bridget (unless someone else wants to!) January 23, 2020 Announcements Standup Josh: Shifting focus to make OCI distribution mature Help get OCI out of experimental Marc: PR on bash completion in Go now merged Porting support to Cobra Adapting patch for helm plugins (bash completion) Bridget: Thinking about issues and PRs Scott: Connected with Farina on ingress-nginx project Jaeger and Kong using new Helm actions Farina asks: do we want a blog post about actions? Scott thinks yes, now might be the time Jacob: New proposal for test: Upgrade and downgrade Issue on way Martin: Bug triaging, PR review, issues on Slack Pushed some PRs with fixes for release checklist - brought v2 fixes in to v3 Fixed a bug in helm plugin utils project Preparing talk with Taylor for config mgmt camp in Ghent Farina: Reviewing in Helm Hub Helm core Discussion Question about SA by default in `helm create`. Is it considered a good practice for every workload to run on its own SA even before RBAC resources are needed (PR where this was added), and if so, why? [Scott]: Curious what practice why to create a SA everytime for deploy a chart Farina said he reviewed this and he thought this pattern was being used commonly in the chart repo No chart maintainers chimed in when Farina asked Scott will raise an issue if it needs a change Upgrade from failed releases: https://github.com/helm/helm/issues/5595 [Martin] Several issues - releases can get into a state that can’t move on; people can be using deprecated APIs We’ll have this issue for open a while, for discussion Jacob to add comment on how this can fail on first attempt to deploy Reintroducing --name flag? https://github.com/helm/helm/issues/7345 [Farina] Martin: we need to be cautious about deprecation now that the (metaphorical) horse has bolted - the release is out. Marc agrees with Martin’s opinion Farina to add a comment to the PR that we have broken compatibility which is allowed. There is a way to work on this. Could set a precedence of adding back in deprecated items which is not a great idea Community member would like to add Deb and RPM packages for Helm: https://github.com/helm/helm/issues/7003#issuecomment-577527262 [Martin] Martin: Is this something we want? They’re talking about hosting somewhere - do we actively support this or remain neutral/they support+we link? Farina: Hosting elsewhere could cause a trust issue depending on who - we’d want to be clear that it’s a third party Martin: choice is between running it ourselves and pointing to a third party Farina: Point out to them that this is third party and he is totally responsible (unless we have maintainers who want to take it on with him) 3.0.3 and 3.1.0 releases? [Farina] Bridget to shadow Farina to get 3.0.3 release out this coming week Discuss next week a date for 3.1.0 Assignments Moderator: Bridget Notes: Farina (or Josh D) January 16, 2020 Announcements We did a CNCF webinar: https://www.cncf.io/webinars/a-conversation-about-helm-3/ Standup Matt Fisher CNCF webinar Marc Big patch (discussion topic to follow) Discussing with Fisher about working with memory driver Hoping to pre-load it with something (but doesn’t handle namespaces - worried about API compat) We can add but cannot alter methods Butcher thinks this is an oversight/bug Matt Butcher Webinar Working on getting us closer to graduation Matt Farina Mostly reviews & triaging - Helm & Helm Hub Bridget Focused right now on content for the documentation Webinar Martin Linux on s390x Deprecated APIs (for discussion) Failed deployments - can we help? Make announcements? [something I missed which people love] PR review Jacob All good! Taylor Thomas Webinar Postrender Feedback to address from community members Working on talks for configmgmt camp and devopsdays Guadalajara Ping him if you need him on specific PRs Discussion Auto-completion re-written in Go https://github.com/helm/helm/pull/7323 [Matt Farina] Moving it to Go lets us remove kubectl as a dependency Request: please take a look/review this - it’s a big change Fisher will be taking a look & put it on the 3.1 milestone What should be done about the version on master? "unreleased" is currently not being added [Marc] Marc was unsure how to post a version to show something would be off master - like “3.0 unreleased” like it used to. Fisher explains he & Adam refactored the internal version packaging so the stable release would not have “unreleased” hardcoded Fisher: In the makefile there’s a way to specify “unreleased” when not being built from a tag - we should add that (back). Action item for Fisher: open an issue explaining the problem and suggested solution Handle CRD ingress resources https://github.com/helm/helm/issues/5574 [Matt Farina provided feedback] Farina commented on this last May but uncertain why it’s on this list today Martin added it today, to see if we can give a more complete answer now Farina says we need more eyes on work that will affect CRDs - they’re still challenging community charts Helm 3 backwards compatibility is complete (to the best of our knowledge). Does anyone know of other issues that have since come up that aren't listed here? https://github.com/helm/charts/issues/19008 [Scott] Fisher: that is a pretty comprehensive issue list Hook up Linux s390x as CI platform: https://github.com/helm/helm/pull/7096 [Martin] Submitter was asking about hooking a particular test into our CI pipeline Farina mentions github actions and “self-hosted runners” as an option Martin wonders if we _want_ this to be automated Fisher points out that the ARM architecture testing was hosted by a third-party community project (without official support) - could we have the community members who are interested in s390x do the testing? Martin mentions that we aren’t automatically running other platforms’ tests either. Fisher: the same argument can be made for PPC arch Butcher: the problem with new architectures: we cannot guarantee reliability on archs that the core team can’t access Farina: so, we document to avoid confusion K8s 1.16 and deprecated APIs: https://github.com/helm/helm/issues/7219 [Martin] Martin: This is going to be a big issue for people in production A community member might work on a plugin for this (like the helm 2to3 plugin) This is going to be messy - there’s no clean delineation Fisher: other issues like migration of one chart from an older to newer api version - k8s upgrades objects from 1.15 to 1.16, so making it easier for release objects would be good Farina: other issues are coming - helm upgrade *should* allow All The Things to work (if we can find a way) Bridget: can we recommend replace instead of upgrade? Fisher: we should look at the k8s strategy for API version upgrades - this is going to happen with ingress and more Martin: we’ll keep an eye on this Assignments Moderator: Farina Notes: Martin January 9, 2020 Announcements CNCF webinar on Helm 3 w/ maintainers next Tuesday (Jan. 14) https://www.cncf.io/webinars/a-conversation-about-helm-3/ Standup Marc Cobra help text on stderr has been reverted to stdout What is the “needs pick” process? Fisher: release triaging for next patch release, tracking what’s been cherry-picked into patch branch Taylor: Step 1 -> Add to correct milestone. Step 2 -> Add the “needs pick” label to the PR Working on shell completion Taylor Post-render PR tidying, getting feedback addressed Josh Closed a few chartmuseum bugs Matt Butcher PR - making sure we don't use old directories. Discovery client: make sure last set of fixes work If you had stale API endpoint declared, it failed to initialized, causing chart rendering to fail Martin PR reviews, looking at defects Looking at Taylor’s proposal Scott In a large room Helm actions work, working with orgs to move charts from community repo to use their own, using action when possible Jacob Helm rollout logs, adding more watchers for readiness. Getting more logs to the end user without having to use kubectl Bridget Helm 101 content for upcoming workshops, getting it into a repo for anybody to run Matt Fisher Panel next week Tuesday w/ other maintainers https://www.cncf.io/webinars/a-conversation-about-helm-3/ PR reviewing Feedback on issue queue, making sure things are triaged Figuring out what's the story w/ 2.16.2 and 3.0.3, as well as 3.1.0 release Discussion https://github.com/helm/helm/pull/6752 needs some reviews [Taylor] We should discuss its behavior with `helm template` Butcher: the right thing to do is to throw errors vs. default values Taylor: are we ok w/ this? FIsher: curious if this solves anyones issues Taylor: maybe post-render is the better option Martin: we may not want this capability Taylor: this feels like --wait - took 2 years to make it work properly, so we should be cautious Bridget: lets not surprise people in unpleasant ways https://github.com/helm/helm/issues/7260 [Taylor] Updates on this proposal Need to decide on how long we should leave open for comment Fisher: Is there a precedent in other orgs (python) for long features left open for discussion? Post-render hooks - the ability to add in extra resources after the fact Bridget: “we are putting the burden of repeatability on the end user to ensure they are using the correct post-renderer every time” is this going to be okay given sufficient docs? Taylor: will probably leave open for 2 weeks https://github.com/helm/helm/pull/7320 [Taylor] When migrating from 2 to 3, when moving CRDs to crd/ directory, their CRDs will be deleted. We’ve always said (in docs etc.) we will not delete CRDs Taylor: rather user angry over not working, vs. things being deleted w/out their knowledge Auto-completion re-written in Go https://github.com/helm/helm/pull/7323 Kubernetes nginx-ingress chart [Scott] What should be done about the version on master? "unreleased" is currently not being added [Marc] Assignments Moderator: taylor Notes: Bridget January 2, 2020 Cancelled for the holidays ``` ================================================ FILE: community/meeting-notes/2021.md ================================================ --- title: Helm Minutes for 2021 --- ```txt December 16, 2021 Assignments for this meeting Moderator: Butcher Notes: Karena Issue Triage: was unassigned for the week that ended today Announcements This is the last meeting of 2021 no Helm call on Dec 23 or Dec 30 We will resume this call on Thursday January 6, 2022. Next release: minor release 3.8 on Jan 19, 2022 Not a patch release Milestone in progress (review PRs, ideally by Jan 10!): https://github.com/helm/helm/milestone/113 Release candidate goes out Jan 10 (monday before) Discussion [Karen] KubeCon CFP reminder, May 17-20, Valencia Spain - Hybrid Event Deadline is tomorrow, December 16 - https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/ Maintainers talk deadline is later in January If two talks: Panel + Non-panel (in the past, could be two co-speaker talks) Early bird pricing ends January 7 [Karena] cfp topics? [Scott] helm 4, sdk improvements for extending to other tools [Butcher] I have also heard that they are looking for good case-study or “this is how we use Helm” talks from people CNCF describes as “users” rather than “contributors" [Farina] idea for Scott … flux, helm controller .. ‘how we built something using the helm sdk’ [Scott] workarounds they might be able to highlight, improvements? [Andrew] oci level distributions … how client model might change, how package, etc. [Scott] OCI alignment [Farina] List of things: https://github.com/helm/helm/issues/10393 When fall back don’t pass url, pass directory (think is a minor issue) [Butcher] correct fall back sequence [Farina] version range support.. Only one unsure about Work w ORAS team to satisfy version range support Assignments for next meeting - Jan 6, first meeting of 2022! Moderator: Karena Notes: Bridget Issue Triage: Dec 16-Dec 23 (Allen Bai), Dec 23-Dec 30 (Scott), Dec 30-Jan 6 (Butcher) December 9, 2021 Assignments for this meeting Moderator: Marc Notes: Bridget Issue Triage: Farina Announcements 3.7.2 was released yesterday Butcher: mostly dependency updates but also some bugfixes Meeting next week, then a break until January Discussion [Paul Vollmer] demo of helm-playground, a webapp to render helm charts in the browser. https://paulvollmer.net/helm-playground Early stages - interested in feedback on https://github.com/paulvollmer/helm-playground Tool for testing/quick iteration Renders automatically when changing values Perhaps we could set up play.helm.sh eventually - what’s the next step to bring this to the community? Currently no data recorded/only local WASM Next step: HIP to incorporate this into helm docs [Butcher] compare to vscode plugin for helm, to see how to incorporate with IDE D Peraza - could incorporate helm test Butcher: be interesting to be able to upload a chart or template Paul: goal is to allow people to see results immediately Butcher: webassembly is an interesting way to package up templates [suggested by Bridget] any update from Farina, Josh, and Butcher’s discussion of Moving OCI integration from experimental to full feature · Issue #10393 · helm/helm They met and triaged the list in that issue; currently 6 items need to happen: Adopt Helm best practice for altering build affix in versions when pushing to OCI #10166 Move internal/experimental/registry out of internal package #9188 Documentation only: Helm v3.7.0 OCI Helm push to ecr gives 404 Not found #10169 (comment) Forthcoming issue: @jdolitsky re DOCKER_CONFIG OCI: no version range support for dependencies/helm install #9694 helm registry login cannot use existing config file for authentication #10156 [Bridget] do we want to get a second review of https://github.com/helm/helm/pull/9318 and get this bugfix for Helm pull fails if pulling from a repository that redirects to another domain · Issue #9317 · helm/helm merged in for 3.8? Mentioned - we shall see Assignments for next meeting - Dec 16, last meeting of 2021! Moderator: Butcher Notes: Karena Issue Triage: TBD December 2, 2021 Assignments for this meeting Moderator: Farina Notes: Karena Issue Triage: week 1 Scott, then week 2 Butcher Announcements 3.7.2 scheduled for Dec 8 - https://github.com/helm/helm/milestone/115 Second wednesday of every month [Bridget] when to get in any last minute items? [Farina] end of this week is the best - has to be a bug (not feature) Discussion [Bridget] Schedule for the rest of this year(!) Thursday Dec 9 - meeting as normal Thursday Dec 16 - meeting as normal Thursday Dec 23 - cancelled Thursday Dec 30 - cancelled Thursday Jan 6 - back to normal [Josh] If OCI will not ship for 3.8 due to various reasons, consider transferring internal/experimental/registry/ into new Go module “helm.sh/registry” (github.com/helm/registry) so vendors can start innovating and improving Josh/Scott/Farina met to discuss getting OCI out of experimental Concerns: lack of dev resources / feature gaps https://github.com/helm/helm/issues/10393 Version ranges .. not finished Business logic to implement api’s ..? Lessons learned: more proj mgmt What is the MVP? [Josh] need document to clearly outline the requirements and issues to work on Alias support: https://github.com/helm/helm/issues/10013 [Farina] Need to go through the list to determine what still needs to be worked on, what needs to be added, etc. [Joe Julian] distinction between sufficient API and feature complete Farina/Josh/Butcher meeting this week to discuss further Additional topics? [Luke] https://github.com/helm/community/pull/224 if there is time Release objects stored wherever they are stored [Farina] strict decoding of yaml objects .. unsure if do that with release objects. Okay with recording in a release object. Generally okay but wants to look into more details to verify. [Butcher] could potentially put behind a feature flag .. question: will it break the API on the release object? Build processes would have to take on the burden of building the tar balls [Farina] digest checking and reproducible digests would be great .. want to keep in scope Defer to next week when Kent can join [Bridget] Kent Rancourt asking about introducing new template file: https://github.com/helm/helm/issues/10074#issuecomment-973097624 Assignments for next meeting Moderator: Marc (and Butcher on dec 16) Notes: Bridget Issue Triage: Farina November 25, 2021 - no meeting (US Thanksgiving) November 18, 2021 Assignments for this meeting Moderator: Butcher Notes: Bridget Issue Triage: Farina Announcements [Bridget] no Helm call next week for US Thanksgiving Thursday Nov 25 [Bridget] 3.7.2 scheduled for Dec 8 - https://github.com/helm/helm/milestone/115 Add your bugfixes now! Patches have been added already! Get those k8s dependency fixes in, with a single PR to cover the content of those automated dependabot PRs - help wanted on that PR [Farina] Allen Bai as Triage Maintainer Congrats! Next step: PRing in himself to https://github.com/helm/helm/blob/main/OWNERS#L12 Thanks to all for patience as voting can take time Discussion [Scott] OCI update upgrade oras to 0.5.0, refactor client oci logic to use new oras.Copy() #10294 ORAS project meeting today Plan to cover ORAS project community maturity #9 Josh: experimental features will wait for after 1.0 Farina: we’re interested in the Go API also semver contract Dependency issues - older k8s packages being imported - keep eye on containerd versioning WIP to remove containerd dep https://github.com/oras-project/oras-go/issues/52 Thanks to Josh, Farina, and all working to get this over the finish line Josh: number 1 request for OCI is semver matching https://github.com/oras-project/oras-go/issues/47 [Farina] An alternative template delimiter - https://github.com/helm/helm/pull/10299 Other systems like Prometheus have options like this However, affects execution [Butcher] Also might cause a breaking change - a silent failure if a chart couldn’t be rendered Scott - new chart version? Butcher: yes, this is a severe breaking change to templates - we’d have to do a version increment on charts. Farine will update issue Butcher: likely we’d want a HIP for this as well [Farina] Reproducible builds (and further security things) https://reproducible-builds.org/ https://slsa.dev/ Joe J: https://twitter.com/puerco/status/1461176447742226440 SLSA in this month’s patch releases of k8s We’ve had PRs in the past but would need tests etc [Scott] yes, as long as we feature-flag this [David P] does the tar spec claim it will create the same digest output? [Farina] Go sort order issues, and the timestamp, are why this varies [Scott] chart repo automation currently has to work around this Defer to Dec 2 [Bridget] Kent Rancourt asking about introducing new template file: https://github.com/helm/helm/issues/10074#issuecomment-973097624 Assignments for next meeting (no meeting Nov 25 - next meeting Dec 2) Moderator: Farina Notes: Josh Issue Triage: week 1 Scott, then week 2 Butcher November 11, 2021 Assignments for this meeting Moderator: Karena Notes: Butcher Issue Triage: Scott shadowing Martin Announcements [Marc] Welcome yxxhero as new triage maintainer! Vote was a while back, but he is now officially in OWNERS file Still some open votes for the maintainers, so vote now! [Marc] Patch release cancelled for this month - No new commits since 3.7.1 There were no committed changes, so nothing to release. Farina: We will discuss getting some momentum [Bridget] no Helm call for US Thanksgiving Thursday Nov 25 Just a reminder that since many maintainers are in US, we will cancel that meeting Karena: We had discussed canceling some other meetings during the holiday season Discussion [Bridget] Josh opened an issue to discuss what we’d like to see in OCI support: https://github.com/helm/helm/issues/10312 - any new thoughts? Next steps? Josh opened an issue for what should be coming, and it would be good to get some opinions recorded. We can return to discussion when Josh is present. [Bridget] Can someone check and perhaps merge the current dependabot PRs? (do we want this to be part of triage tasks for the week?) There are several Dependabot PRs that should get some attention. And the longer we wait, the harder they are to merge. Could this be considered triage work? [Farina] How do we get more merged? Core maintainers are quite busy right now (with other things), and with no single corp overseeing Helm, we need to come up with a way to get people engaged in reviewing/merging We have more maintainers, but not enough to make a big difference here So what can we do to help with that? Dpereza: Will more maintainers fix this? Farina: Maybe, but that does require more work dpereza: RH does indeed have interest in doing more than this, but we’re unclear on how to start that. What do we do TODAY to set us up to be stronger maintainers in the future? (There are 3-5 people on this team) Farina: I will help get this going. Feel free to come bug me to help you. I’m in ALL the Slacks. Karena: What about the dependabot PRs? Bridget: Can these be triage tasks? Or are they more than that? Farina: Three of them need to be combined into one big PR, and that will require someone to actually do the work. One big k8s library update. Marc: Someone from RedHat did this k8s merge in the past. Does anyone remember who? [Will look up] Farina will write the Help Wanted issue for tracking the k8s upgrade Marc: It was Shoubik who had done some in the past. Discussion about asking Shoubik to do this again (David will follow up). [Bridget] What do we think of this Slack integration request? https://github.com/helm/helm/issues/10291 Installing the slack app on the repo… do we want to do this? Do projects do this? Is this a good idea? Does anyone want to investigate? Butcher: I will track this one Assignments for next meeting Moderator: Butcher Notes: Bridget Issue Triage: Farina November 4, 2021 Assignments for this meeting Moderator: Martin Hickey Notes: Bridget Kromhout Issue Triage: Scott Rigby - will reach out to other folks for backup Announcements [Bridget] Next scheduled release: 3.8.0 on January 12th, 2022 https://github.com/helm/helm/milestone/113 - review items in there! Is 3.7.2 still planned for Nov 10? https://github.com/helm/helm/milestone/115 has no items in it yet [fisher] No. we preemptively create the milestone per HIP 2: https://github.com/helm/community/blob/main/hips/hip-0002.md . If nothing is scheduled for a milestone, then we have nothing to release [bridget] okay. I wasn’t sure how late an item could be added. [Fisher] when we have nothing to release we extend the date Discussion [Bridget] Upcoming holidays - shall we cancel this call for US Thanksgiving on Thursday Nov 25? [yes] Thursday Dec 23? perhaps Thursday Dec 30? [let’s ask closer to the date] Bridget and Karena will be out for all three Fisher: generally speaking most people won’t be at the calls these dates Martin: I will also be out Resolution: We will cancel the Nov 25th call and ask about the December ones closer to the time. [Bridget] does anyone know offhand if the OCI support as of 3.7.1 fixes this bug? https://github.com/helm/helm/issues/8090 [fisher] that should be fixed as of Helm 3.7+. Added a comment We can revisit this if it doesn’t work in 3.7+ [Josh] clarity around :version versus --version: https://github.com/helm/helm/issues/8090#issuecomment-961222358 [Scott] update on ORAS/Helm OCI progress upgrade oras to 0.5.0, refactor client oci logic to use new oras.Copy() Josh D, can we connect on how to update the test? Josh: new API in oras makes it more flexible - this PR validates it still works with the new API - but there is an issue with how layers are sorted - perhaps need to hear from Farina? But it may not matter. [Fisher] possibly docker may rely on order for layers - “if docker relies on layers being ordered in a certain way because of the nature of a copy-on-write filesystem” Scott: PR in question: https://github.com/helm/helm/pull/10294 Assignments for next meeting Moderator: Karena Notes: Butcher Issue Triage: Scott shadowing Martin October 28, 2021 Assignments for this meeting Moderator: Marc Notes: Karena Issue Triage: Scott shadowing Farina Announcements [Marc] New triage maintainer: yxxhero Welcome! [Karena] KubeCon Maintainer Session - Combined views (in-person + virtual): 1223 Discussion [Marc] Should triage maintainers be added to the OWNERS file? [Farina] makes sense to have it AI: Marc to send email to maintainers [Josh (who cannot attend)] Merge me! https://github.com/helm/helm-www/pull/1228 Several issues is the queue related to OCI may be prevented, since the current registry docs are misleading/contain old commands People have command line documentation old vs. new [Scott] I am reviewing [Adam] - PRs to bump https://github.com/helm/helm-www/pull/1228 Labeling releases: https://github.com/helm/helm/pull/8099 Alternatively https://github.com/helm/helm/pull/9560 [Farina] Expectations: next minor release (January) for these PRs [David Peraza] question on pre-GA install [Farina] k8s versions look semantic but are not semantic Helm uses a semver check According to semver, use ascii character map so start w/ using zero [Farina] could have better help documentation [Scott] quick update from last week on Helm OCI & ORAS dependency. Moving forward! Communicating closely w ORAS maintainers (Josh, Sajay, Avi etc) and collabing with volunteers (David P, Andy Block, Josh Wolf, Tom Runyon) [Marc] Triage maintainers Voting on Allen too And Scott Assignments for next meeting Moderator: Matt Farina Notes: Bridget Kromhout Issue Triage: Scott Rigby - will reach out to other folks for backup October 21, 2021 Assignments for this meeting Moderator: Bridget Notes: Scott Issue Triage: Farina Announcements [Bridget] 3.7.1 patch release went out last week. Next scheduled release: 3.8.0 in January https://github.com/helm/helm/milestone/113 Discussion [Bridget] does someone want to check and approve/comment on the outstanding dependabot PRs? https://github.com/helm/helm/pulls/app%2Fdependabot Dependabot will keep them up to date, so if they’re still open, we can review and merge them [Scott] feedback on OCI status Issue, SDK users can not import helm's OCI support, because it is EXPERIMENTAL (note this is by design for now for a good reason) quick note on earlier idea for helm/registry breakout proposal. Chat prior to HIP Met with Josh & Matt Farina before and during KubeCon Now: prefer to instead help push Helm OCI support over the finish line. Shoot for January Scott: people should not be using experimental features in production, but they are. Next steps: the gaps are almost all closed, so suggest we push over the finish line. Biggest blocker: oras backwards compatibility Target: the January 3.8.0 release Volunteers: Scott Andrew Block David Peraza Josh Wolf [Scott] will push this forward set up a simple collaborative process for the busy folks who want to help (scheduled meeting? just async? whatever is pragmatic & easiest) start with checklist of required things to do coordinate with Bridget coordinate with other ppl who have volunteered to collaborate on this coordinate with Josh for reviews [David] New member asked to bring this up in call: https://github.com/helm/helm/pulls/mmulholla Will follow up (we were KubeCon-ing last week) [Farina] summary of community online meeting during KubeCon OCI and CRD questions as usual [Bridget] HIP review: https://github.com/helm/community/pulls Anyone can comment Assignments for next meeting Moderator: Marc Notes: Karena Issue Triage: Scott shadowing Farina October 14, 2021 Cancelled due to KubeCon :-) Join office hours on Bevy instead! Tuesday, October 12 • 9:00am - 9:45am Pacific Friday, October 15 • 10:30am - 11:15am Pacific October 7, 2021 Assignments for this meeting Moderator: Karena Notes: Scott Issue Triage: Farina Announcements [Bridget] reminder: no Thursday Oct 14th Helm weekly dev call due to KubeCon Join office hours on Bevy instead! Tuesday, October 12 • 9:00am - 9:45am Pacific Friday, October 15 • 10:30am - 11:15am Pacific [Farina] 3.7.1 patch release next week (being cut by Farina) Cutting this on Wednesday next week : https://github.com/helm/helm/milestone/114 https://helm.sh/docs/community/release_checklist/ Marc: new pick and push process Discussion [Nick Jennings/Ramindar/Dhanashree] Surfacing container logs in Helm? https://github.com/helm/helm/pull/7728 and https://github.com/helm/helm/issues/5952 Matt Farina: check out the https://github.com/helm/chart-testing project Joe: could potentially be a helm plugin. Not yet sure if you do it within the atomic loop (though you could if you made your own command). Matt Farina: Nick is looking to do something that's not custom Joe: agree, though it could start out custom prior to a HIP Nick: agree that would be a good way to move ahead Marc: legit use case though right? Matt Farina: workaround is not use atomic flag, and manage the rollback logic on one's own (follow Unix philosophy of "do one thing well", rather than complexity of single command with all of those flags) Karena: ensuring there is a clear next step Nick: yes recommending partners either to not use atomic flag, or re-run without atomic flag on failure. And the next step is either 1. HIP, or 2. Helm plugin. Matt Farina recommends again looking at helm-testing project because surfacing some of those logs for testing has already been done [Tom Runyon] Standardize Annotations to identify images used by Helm Chart. ArtifactHub uses the annotation `artifacthub.io/images` to identify images used by the chart [Reference]. This helps ArtifactHub show the scan results that are not clearly visible by rendering/templating the chart e.g. here. Other use cases exist (e.g. bundling artifacts for airgapped/off line deployments, generating SBOMs, etc) and having a global (helm) standard would facilitate tooling built around the specification of images required to use the chart. Proposed: `helm.sh/images` as seen below: Andrew Block: this is important for Red Hat - “related images” - https://docs.openshift.com/container-platform/4.8/operators/operator_sdk/osdk-generating-csvs.html#olm-enabling-operator-for-restricted-network_osdk-generating-csvs Scott Rigby: agrees there should be a standard - this doesn’t require much from Helm other than stating something is “supported” Farina: we’d need to agree and document Tom R: happy to do that work Farina: this would definitely need to be a HIP and I would be supportive of it (move to Oct 21?) [Scott] If time, feedback on earlier idea for helm/registry breakout proposal. Chat prior to HIP Assignments for next meeting (Oct 21! No meeting Oct 14) Moderator: Bridget (or other!) Notes: Karena Issue Triage: Farina for week 1; someone needed for week 2 September 30, 2021 Assignments for this meeting Moderator: Scott Notes: Bridget Issue Triage: Butcher Announcements [Bridget] Hosts needed for KubeCon online office hours (held on Bevy): Tuesday, October 12 • 9:00am - 9:45am Pacific (to be led by Matt Farina) Friday, October 15 • 10:30am - 11:15am Pacific (to be led by…?) [Bridget] 3.7.1 patch release would be during KubeCon - schedule adjustment? Farina: I can still cut this release that day [Bridget] reminder: no Thursday Oct 14th Helm weekly dev call due to KubeCon [Scott] Oct 5th 10 AM PST, Martin & Scott present a feature showcase on Helm + Flux at CloudNative @Scale SF: https://twitter.com/r6by/status/1443596965946744839 Discussion [Farina] Artifact Hub storing validation in OCI registry for charts there… - “The repository metadata file can now be added to Helm OCI repositories. This allows using features like verified publisher or ownership claim on OCI based repos. For more information about how to add it to your repository please see the Helm OCI section in the repositories documentation.” Artifact Hub asking for input/feedback on this feature, and asking you to add the metadata files - similar to provenance files This is different from “verified publisher” - see https://artifacthub.io/docs/topics/repositories/ - important for businesses etc [Bridget] Inactive repo cleanup - I’m proposing we archive three repos due to minimal content and no activity: https://github.com/helm/query-store-quay-logs - Farina: running this stopped working - nobody noticed - Farina will send out a lazy-consensus and run it by the charts team https://github.com/helm/repo-audit - was a tool intended for audit/features - unsure about what we should do about this - perhaps there is a way to do this via artifact hub - check for digest changes/security/provenance files/chart-testing-tool/etc - interesting to dperaza - Farina will change master branch to main https://github.com/helm/specs - based on a request to document specs - Farina believes we need to do this - Farina will change master branch to main [Bridget] OCI/mediatype question - do we know what we want to do with https://github.com/helm/helm/pull/10182#issuecomment-927377309? Farina: this is an issue with user confusion around experimental features - plugins will be a more clear delineation in the future [Scott] who wants to make a PR against Helm Governance for using the private maintainers list for new maintainers voting. [Bridget] I already have a PR open against governance to update from last year’s HIP-005: https://github.com/helm/community/pull/210 Bridget will request that clarification - according to farina, self-nominations should happen on public list, then vote on private list Assignments for next meeting Moderator: Karena Notes: Scott Issue Triage: Farina September 23, 2021 Assignments for this meeting Moderator: Matt Farina Notes: Bridget Issue Triage: TBD Announcements [Bridget] Karen Chu has added the last year of meeting recordings to the playlist linked on https://github.com/helm/community/blob/main/communication.md#meetings Discussion [Bridget] September is proposed as a Helm 4 decision time - what is our next move? (Brought up by Butcher at the Sept 7 meeting - defined in HIP 12) [Bridget] The original plan mentioned possible kickoff activities at kubecon north america 2021, which is fast approaching. Butcher: the plan is for a release engineer and perhaps also a PM/architect role - the HIP said we’d have this person in place by the end of September - thus far we are slipping timeline-wise - perhaps we need to revisit post-holiday-season. Butcher so perhaps we amend HIP-12 with a redefinition of the roles to two instead of one, and for a resumption post-holidays Action item: Butcher to carry out HIP replacement (lol) [Bridget] 3.7.1 for bugfixes? OCI: Allow any mediatype for layers on download #10176 [Josh] old charts being rejected is not ideal, but this bugfix would allow less-strict checking. [Farina] debated in the original issue as to whether we should accept the old media type as well - what’s changed? [Josh] the community reaction has motivated this increase in flexibility [Farina] we should log deprecated media type - patch is in a couple weeks [Farina] instead of experiments, we should look at plugins in the future (because of how this has been treated) [Josh] helm-push plugin is broken due to “helm push” https://github.com/helm/helm/issues/10175 Action item: Josh will submit update for the patch release [Karen Chu] Helm at KubeCon Ways to participate Online office hours (RSVP - held on Bevy): Tuesday, October 12 • 9:00am - 9:45am Pacific and Friday, October 15 • 10:30am - 11:15am Pacific Hosts needed! Please sign up here and we can connect you with CNCF - Karen will connect with you to ensure you are signed up on Bevy. Maintainer session: Wednesday October 13, 2021 11:00am - 11:35am PDT Concourse Hall 150 ABC + Online Project Pavilion booth Online In person - possible to sign up for participation (we have it half the day - mornings each day) [Andrew Block] Helm + Sigstore: Presentation plus very short demo Helm Sigstore Plugin Demo: https://www.youtube.com/watch?v=cjY26RRHpo8 Sigstore is not SIG Storage cosign, rekor, fulcio https://github.com/sigstore/helm-sigstore Scott Rigby: please join the Helm chart talk at KubeCon Assignments for next meeting Moderator: Scott Notes: Karena Issue Triage: Butcher September 16, 2021 Assignments for this meeting Moderator: Karena Notes: Bridget Issue Triage: Fisher Announcements Helm 3.7.0 has been released https://github.com/helm/helm/releases/tag/v3.7.0 Fisher: community identified code regressions, which are now fixed - RC3 was cut and now we’ve released 3.7.0 [Marc] should we clarify the breaking change further (OCI charts only)? Fisher: yes, there are significant changes to the experimental OCI support - see the HIP on the OCI support: https://github.com/helm/community/blob/main/hips/hip-0006.md Charts will need re-uploading Fisher: documentation needs to be updated in accordance with this change [Marc] we may need to clarify the release notes Farina: Josh D did a gist on how to update: https://gist.github.com/jdolitsky/66e0768ceedb6eab7395422e86e16a53 Action item: Release notes update by Marc Discussion Helm 3.8.0 release date [fisher] I looked at the calendar and tentatively scheduled it for January 12, 2022 (second Wednesday, four months from now). Lazy consensus vote? Fisher: the HIP says quarterly - 4 months from now would land in January Farina: January is good - but Jan 3 would be too soon to cut the release - let’s push a week - RC 2nd Wed in Jan, Release 3rd Wed in Jan Action item: Fisher will send email & update the release calendar Marc will add Fisher to the calendar [Karena] Triage shadowing session [Karena] pairing is challenging - can we schedule a session for walking people through triage? [Fisher] perhaps we need to define what this is? [Bridget] Do we want a one-off triage onboarding/shadow session? [dperaza] Async would be valuable as well, but I would attend a one-off orientation Stephane: also please record the session and document it Karena: resolution: [Bridget] KubeCon logistics Shall we cancel the Thursday Oct 14th Helm weekly dev call? [yes] Who wants to host online office hours, Friday Oct 15 10:30am-11:15am pacific, https://sched.co/mtNO? [Maybe Farina but let’s check later] Who’ll be onsite for KubeCon? (We have an in-person project pavilion spot.) [Karena] Please comment here if you’re going to be onsite in Los Angeles Bridget: I’m planning to be there Karena: I’ll be there! [Marc]: Wondering if dynamic completion of plugins could have security implications? https://helm.sh/docs/topics/plugins/#dynamic-completion Butcher: Helm can’t secure unknown 3rd-party code on behalf of the user [Karena] Helm youtube channel Who maintains/uploads community videos? [fisher] The CNCF provided a zoom plugin that will automatically upload Zoom recordings to YouTube. They own the account, but have shared access to myself and Karen (Helm Community Manager) [Scott] progress on helm session technical focus on charts [Bridget] Skipped this so pulling it out to highlight it 💖 Building, publishing, sharing charts! [David] Can we demo sig-store for the community call? Fisher: we’ve had demos here before but it’s nice to have a video ahead of time to pre-watch and then discuss on the call Farina: a recorded demo on youtube is far easier to share Assignments for next meeting Moderator: Matt Farina Notes: Bridget Issue Triage: TBD September 9, 2021 Assignments for this meeting Moderator: Matt Fisher Notes: Karena Angell Issue Triage: Matt Butcher Announcements [fisher] Helm 3.7.0 delayed due to a few code regressions Cut 3.7.0-rc.3 and look to release 3.7.0 after that Next hour, release candidate is out Next Tuesday for 3.7.0 GA Discussion [fisher] Helm 3.7.0-rc.2 update [fisher] there is a fix available now available for #10112: https://github.com/helm/helm/pull/10117 Reviewed and approved [Bridget] Helm at KubeCon NA 2021 - updates? Project talk: Helm: The Charts and the Curious - https://sched.co/lV7H Helm project booth Online office hours Friday, https://sched.co/mtNO Scott, Paul, Carlos, Karena are giving a talk on how to improve your chart workflow - focused on people who are looking to better automate their talks, join us online or at kubecon [Bridget] Triage maintainer nominations - updates? One is being onboarded If anyone else - there’s a HIP: https://github.com/helm/community/blob/main/hips/hip-0014.md [Bridget] Self-nominate! It’s easy and fun! Don’t have to be proficient in Go or Helm - it’s a good way to learn Joe Julian & Scott Rigby interested [Andrew Block] Sigstore + Helm - https://www.sigstore.dev/ Sigstore for signing/verifying content Helm package signing https://medium.com/@sabre1041/setting-up-your-own-rekor-transparency-log-server-using-helm-fc7bbeafb59c https://medium.com/@sabre1041/integrating-helm-into-the-sigstore-project-d51564ea001f Sign Helm charts - not rewriting how they are signed today - taking content and publishing to a transparency log Interested in feedback - future presentation will demo to the group Farina: would love to see Helm work published to transparency log Pgp keys? Farina: pgp was when we created things - integration with gpg not as good anymore Josh: helm push - if sees file, will upload over oci distribution … would be cool to detect sigstore plugin Assignments for next meeting Moderator: Karena Notes: Butcher Issue Triage: Fisher September 2, 2021 Assignments for this meeting Moderator: Martin Notes: Karena Issue Triage: Farina Announcements 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Revamped OCI integration Breaking change to previous OCI experiment Under experimental flag Josh dolitsky Useability Any volunteers to test?? API changes: push/pull from registry, certain manifests pull from there (breaking change) Action package - tried to move some of the api stuff out “should be” clearly documented CRDs out of the chart - helm show crds SIGTERMS on upgrade/install Discussion [Itai Spiegel] Including external files in chart. https://github.com/helm/helm/pull/10077 Broke api compatibility - PR not ready for review yet [Butcher] Helm 4 Release Manager “It is time!” Release manager - most of architectural decisions Roadmarkers PM’y but more architect role 25-30 hours of work per week Decide by end of september - go/no-go then Or nominate Adam ;) Needs to be existing maintainer of helm/helm code base Requires some coding and managing PRs with PR authors David: break up the role? Andy: cover multiple geos Julian: 30 hours per week for how long? 6 months? Butcher: We could also break it into PM-like tasks and coding tasks, and create two distinct roles Once decide on person(s), can kick off the process What are the bounds for this release? [Scott] Feedback on HIP process for detecting changes to objects that are the result of a Helm release (rather than only mutations to the storage like helm-diff) Command that compares helm storage state with a live cluster state Helm controller from flux and Helm operator had to do a lot of workarounds to ascertain the info - should this be a HIP? Farina: Helm 3 - 3-way merge patch Mutating web hooks E.g. Service mesh A tool like this might fail / raise those thing instantly in a case like this Farina: what’s the use case? Butcher: And Kubernetes itself mutates things (in ways that change from k8s release to k8s release) Butcher: a HIP sounds like a great way to discuss this [Karena] Blog post for this release Loves the mentions so far about what's landing in this release Any other notes over the next 3 mins? Farina: a bunch of new features. Maybe have time to craft full release notes Wednesday? Will have to look at closed pull requests because there were so many Assignments for next meeting Moderator: (Bridget if no other volunteers) Notes: Karena Issue Triage: Matt Butcher August 26, 2021 Assignments for this meeting Moderator: Adam Notes: Bridget Issue Triage: unassigned Announcements 3.7.0 RC scheduled for Mon Aug 30 (next week!), with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Call to action: review (and/or update) PRs for 3.7.0 Discussion [Farina] Download cache HIP and security… https://github.com/helm/community/pull/185 [Farina] Possible security issue if index.yaml file intercepted/changed, leading to a wrong version being installed [Farina] Perhaps checking which version is being requested would mitigate? [Butcher] that reduces the risk to local filesystem attacks [Farina] this cache also covers cache environment variables [Butcher] we have extraneous cache environment variables [Martin] for helm 4 - one cache to rule them all! [Karena] how does this tie back to the overall security story? [Farina] many factors for security - like signed indexes - but yes, a security-centered approach is wise [Farina] we should discuss https://github.com/sigstore/helm-charts [Karena] Andy would like to come on to discuss [David Peraza] let’s discuss/bring in more folks [Farina] We could look into more caching items before Helm v4 [Martin] Would functionality to clean failed revisions be useful? Came up as a conversation in https://github.com/helm/helm/issues/10056. [Farina] In Helm 3 there is a limit of 10 by default [Martin] Failed revisions that people want the ability to clean up [Farina] We don’t garbage-collect if all the release objects are failures [Farina] perhaps we should start with a garbage-collection plugin? [Martin] that is better than telling people to edit the cluster directly [Farina] a plugin called `gc` would be a good place to start [Martin] will raise as a feature and see if someone has the bandwidth [Farina] Helm v4 - context, dependency injection container, or something else… not being able to get to information we didn’t know we needed is making the SDK hard or unusable for non-Helm apps. See https://github.com/helm/helm/pull/10008 as an example. Looking for way to solve this in v4. [Farina] plugin can have wrong directory due to tight coupling [Farina] dependency injection may be the way to do this [Farina] hypper work has shown this currently has some issues but we don’t have a way to avoid it now - perhaps in v4 we can change it. [Butcher] context object or directory perhaps, but building a dependency injection pattern may be useful [Farina] context or CLI will both work interactively vs in a CI pipeline [Butcher] possibilities chainable context tuple pattern [Karena] Do we want to have a working group at KubeCon? [Butcher] Karen did request space for a planning session [Martin] remote participation options? [Bridget] I can join a device from an in-person session as needed [Martin] Do changes to an interface break backwards compatibility according to Go conventions? We have precedent in Helm 3 where an interface was changed in https://github.com/helm/helm/pull/8363. Should we therefore allow it to be changed in https://github.com/helm/helm/pull/9702? Can’t see it mentioned in the backwards compatibility HIP: https://github.com/helm/community/blob/main/hips/hip-0004.md https://go.dev/blog/module-compatibility [Martin] we can probably get this in for 3.7 [Farina] this isn’t documented in the backward-compatibility rules [Butcher] but it is documented in go’s guidelines [Adam] modifying an interface is a breaking change [Martin] we did merge a PR that breaks the interface [Bridget] do we have any update on adding triage maintainers? [Farina] Need a few more votes from maintainers for the first candidate Assignments for next meeting Moderator: Martin Notes: Karena Issue Triage: Farina August 19, 2021 Assignments for this meeting Moderator: Bridget Kromhout Notes: Matt Fisher Issue Triage: TBD Announcements 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Call to action: review PRs for 3.7.0 New FAQ entry for tiller download questions: https://helm.sh/docs/faq/troubleshooting/#tiller-installations-stopped-working-and-access-is-denied Discussion [Itai Spiegel] Add --include-file flag for external files: https://github.com/helm/helm/pull/8841 Writing a helm chart for deploying applications, using the first helm chart as a dependency Looking for a summary of Helm’s architecture to help move the feature forward [Fisher] recommended step - first, reach out to the original author of the PR - perhaps you can see if their timeline matches yours Itai: yes, I sent him email with no response [Fisher] It’s fair to work on an alternative if you don’t hear back Adam - he can open a new PR with the existing commits (Butcher: as long as the DCO is in place from the original committer) Adam (on rollback): when you send up files on an install, these files are added as templates, not configuration in parts of the chart Additionally, there is a security concern of including files Itai: we’re fine with this. The security concerns is not important in our case. Bridget: just because security concerns are not important in this use case doesn’t mean we shouldn’t be concerned about security leaks Itai: okay. So I’ll go and test/document this with regards to `helm rollback` [Bridget] progress on OCI support - https://github.com/helm/helm/pull/9782 [Fisher] Adam, Butcher, and I have reviewed this PR in detail - the only removals are internal so in terms of public packages, nothing has changed - one change to adjust, and another PR to merge first. Adam & Fisher to pair [Bridget] Call-to-action to contact Josh Dolitsky later [emailed] [Stephane] next steps for https://github.com/helm/helm/pull/9180 Had some conversations with FIsher about how to get this into Helm 3.7.0 [bridget] added to Helm 3.7.0 for visibility Assignments for next meeting Moderator: Adam Notes: Karena Issue Triage: TBD August 12, 2021 Assignments for this meeting Moderator: Adam Reese Notes: Bridget Kromhout Issue Triage: Matt Farina Announcements 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 patch release (3.6.4) scheduled for Wed August 11 has not occurred: https://github.com/helm/helm/milestone/112 PRs were not in shape for merging Cancel 3.6.4 and move those items to the 3.7.0 milestone? Farina will do this cleanup step Call to action: review PRs for 3.7.0 Discussion [Fisher] HIP 14 (Helm Triage Maintainers) update https://github.com/helm/community/blob/main/hips/hip-0014.md Let’s sign on new maintainers at a lower commitment level, to help with PR review and triage This role does not handle release management or event coordination HIP is approved - Fisher has created github “Team” Some candidates in the pipeline Nominate candidates using the same process as for core maintainers Action item: PR this clarification in - this role falls under https://github.com/helm/community/blob/main/governance/governance.md#project-maintainers specifically for helm/helm [Martin] Generate `values.schema.json` during `helm create` https://github.com/helm/helm/issues/10009 Should this be added or do we keep the scaffold chart simple and the basics to better help users onboarding to Helm? Adam: “create” should be as simple as possible - let’s not add to the base “create” command Fisher: https://github.com/karuppiah7890/helm-schema-gen - this plugin is not currently maintained, but this discussion happened before Farina: “create” is already too complex - Helm 4 could make that simpler - but starter templates could also be easier. Fisher: compare https://github.com/cargo-generate/cargo-generate - values schemas can be quite opinionated Martin: next steps - I might create a proposal and perhaps a HIP for Helm 4 Scott: we’ve talked about a “wizard” before but that is too much complexity for helm itself (as opposed to being a plugin) Fisher: yeoman is great for creating wizard-like templates. we've been using it in a few projects. https://yeoman.io/ Scott: docs improvements ideas could be migrated over from the legacy charts repo Martin is going to carry this discussion forward (helm create, templates, best practices, wizards…) Adam: the `helm create` command is tied with our backwards-compat constraints, so let’s keep it simple to put the practices elsewhere, to preserve optionality Scott: Decoupling that could make backwards compatibility for v4 easier to maintain [Martin] `helm repo update` commands return exit code 0 regardless of errors or not https://github.com/helm/helm/issues/10016 [Martin] Code implemented to just output any errors but does not return an error back to cobra. Is this expected behaviour? [fisher] dropped a comment in the ticket providing some historical context Fisher: “helm serve” was mostly a convenience but this behavior might be a workaround for that Fisher: define “failure” - what if _some_ updates succeed and others (like helm serve) don’t and that is expected? Fisher: we could consider this change for Helm 4 with a HIP - let’s not surprise people by changing 5-year-old behavior. Martin: agreed, this is how it works, but maybe we reconsider this for Helm 4 Fisher: _all_ failing definitely is exit code 1, but it’s ambiguous after that (as to if we need _any_ or _all_ to succeed). Farina: it’s possible that a CI system could end up silently succeeding in doing a non-update (which could surprise unfortunately). Let’s get a HIP with a good case with examples of apt and similar [Bridget] should we create a new blog post or FAQ item with the current status of tiller images to point people to when they’re asking, now that the legacy storage bucket is starting to be cleared out? Action item: Bridget to write updated FAQ entry Assignments for next meeting Moderator: Bridget Kromhout Notes: Matt Fisher Issue Triage: TBD August 5, 2021 Assignments for this meeting Moderator: Marc K Notes: Jasper Issue Triage: Matt Farina Announcements Next patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Discussion [Bridget] is there an open issue or HIP that relates to “OSI model for signatures”? A note at the end of https://helm.sh/docs/topics/provenance/ implies there might be, but I do not see it. [Farina] Unlikely going down this path. May go down sigstore path. [Shoubhik] https://github.com/sigstore/helm-sigstore Doc needs to be updated to reflect latest. [action item: Bridget] [Farina] Helm 4 (and the release engineer) Target Oct 2021 HIP 12: https://github.com/helm/community/blob/main/hips/hip-0012.md Need to identify Release Engineer for Helm 4 Require to be Helm/helm maintainer to be release engineer Role and responsibilities: Person who oversees Helm 4 from technical coordination [Scott] Want to help with SDK component. Can help wrangle and flesh out SDK-related stories (I have a new vested interest in this side of things, as I'm also co-maintaining Flux, specifically will help maintain the Flux Helm Controller) [Martin] Do we have enough stories, features for Helm 4? Defined in HIP on how to short circuit progres to halt development Kick off meeting to be scheduled [Shoubhik] When should we discuss what will go into Helm 4 [Farina] Opportunity for breaking changes. Require HIP to describe request Consider topic of Helm Releases on cluster [Farina] Helm is a package manager and does not enforce a specific style. Need to understand how it works in a specific scenario. [David] Helm having multiple resources in templates but the user does not have permission to perform action [Farina] Helm work like other tools and depends on user permissions, Helm stores releases in secret. Can have a limiting experience. Helm can store information in other locations (eg configmap). Can we improve the experience earlier during or before the installation [Paul C] Opportunity for a plugin to perform this check Consider split responsibilities to install different components of a chart [Farina] This is release management and beyond scope of a package manager [Scott] SDK issues. For example, race conditions when using SDK for storage locking within package. Locking could be moved to the CLI. Here is a related issue in helm/helm, but we have many more in fluxcd This may be fixed by https://github.com/helm/helm/pull/9180 [Farina] Opportunities to improve Helm 4 CLI and SDK Need to brainstorm for using SDK to flush out stories Action item for Scott to lead Need to consider alternatives on how to capture this feedback. [Marc] PR to add some completion descriptions (HIP 8) For 3.7? https://github.com/helm/helm/pull/9421 https://github.com/helm/community/blob/main/hips/hip-0008.md [Bridget] Where to track Helm 4 ideas? Attached to a HIP or create separate HIPs? [Farina] use HIP to track all changes Assignments for next meeting Moderator: Scott Rigby Notes: Bridget Kromhout Issue Triage: Matt Farina July 29, 2021 Assignments for this meeting Moderator: Marc Khouzam Notes: Karena Angell Issue Triage: Matt Fisher/Martin Announcements Next patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Discussion [Martin] Support for bearer token authentication https://github.com/helm/helm/pull/8447 Farina: it’s stale because it still needs work Farina: want to pass via stdin, need to be security conscious Farina: just need to think through the implementation details in the PR AI - Farina to follow-up [Martin] Go SDK installing Kubernetes resources to the wrong namespaces https://github.com/helm/helm/issues/8780 Farina: two namespaces - k8s resources diff than the records; can only set it once when you instantiate Need to instantiate k8s client with new namespace Farina: no way to change this until Helm v4 Farina: there is a very ugly way (running long running services that want to keep doing things) to do this currently, Helm v4 would be to simplify this AI - Farina to share code (from https://github.com/rancher-sandbox/hypper) where it’s done Farina: initializing isn’t setting it right Assignments for next meeting Moderator: Scott Rigby Notes: Jasper Issue Triage: Matt Farina July 22, 2021 Assignments for this meeting Moderator: Martin Hickey Notes: Karena Angell Issue Triage: Martin Hickey/Matt Fisher Announcements Next patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Discussion [Martin] Install chart from remote repo should it get the latest dependencies https://github.com/helm/helm/issues/9962 If helm repo add and then the person says helm install Fisher: expectation, would fetch during build or helm dependency update Andrew: hard dependencies Fisher: shouldn’t run a helm install and have it run and get any dependencies without you knowing Fisher: further inspection needed AI: ill look into more [Martin] Helm create a namespace from template which it installs into https://github.com/helm/helm/issues/9965 Namespace plus custom labels Fisher: tricky problem to solve Fisher: Helm 1&2, original assumption, installed by Sys Admin People didn’t setup acl’s for their grpc endpoints Mitigated in 1&2, things stored in release record vs release namespace Changed in Helm 3, user installs Resource quotas in namespaces, etc Helm 3 - move to kubectl approach Create namespace ahead of time Same as CRD problem Fisher: Documentation? How to manage namespaces outside the chart Fisher: namespace mgmt recommendation - one is to use helmfile [Martin] Adopt resources to a release https://github.com/helm/helm/issues/9958 : Any docs for this feature? Potential bug: https://github.com/helm/helm/issues/9958 Issue with migrated releases because labels/annotations didn’t exist prior to Helm 3.2.0 Fisher: If you can get hold of Jacob, best person to talk to Fisher: Alternative, look through the code and create a HIP A little familiar with the code AI: Martin to reach out to Jacob [Karena] Helm 3.7 blog / release themes: Any themes popping up for next major release Do people think it is a good idea? Do anyone want to work with Karena to create a blog of it? Fisher: happy to help Open Initiative PR? Also look at Helm 4 HIPs Fall? Helm 4 discussions starting [Fisher] call for more reviews on Helm Triage Maintainers HIP https://github.com/helm/community/pull/199 Martin: should look at it too Assignments for next meeting Moderator: Marc Khouzam Notes: Karena Angell Issue Triage: Matt Fisher July 15, 2021 Assignments for this meeting Moderator: Bridget Kromhout Notes: Jasper Chui Issue Triage: Matt Farina Announcements [Farina] Yesterday (Wed July 14) patch release (3.6.3): https://github.com/helm/helm/releases/tag/v3.6.3 [Farina] Next patch release (3.6.4) scheduled for Wed August 11: https://github.com/helm/helm/milestone/112 [Farina] 3.7.0 RC scheduled for Mon Aug 30, with 3.7.0 release Wednesday Sept 8: https://github.com/helm/helm/milestone/111 Discussion [Bridget] repo cleanup project We merged https://github.com/helm/monocular/pull/691/ - should the repo be archived in the github UI? [Farina] We can click the clicky should we archive https://github.com/helm/query-store-quay-logs ? [Farina] Need to check if its still in use Used to store metrics for quay Data kept for 2 months from public source. Source of data into this repo [Farina] 3-way merge patch and CRs https://github.com/helm/helm/issues/9937 (feature or bug)? Need to clarify expected use case Not intended for CR [Adam] Written when kubernetes does not support 3 way merge Behaviour has changed and needs to be updated Which release should include this Documentation is too general [Martin] Inconsistency bug and documentation bug, could break backwards compatibility [Bridget] Open issues in repo to address the documentation bug Target fix for Helm v4 [Farina] Feature change needs to be included in major release behaviour change needs to be behind a flag [Marc] Building in Kubernetes without Docker, any experiences? Build container in a kubernetes cluster [Andrew Block] Use Shipwright and Buildah [Josh] use Kaniko [Farina] Docs bug or Helm bug with no repo dependencies… https://github.com/helm/helm/issues/9928 Sub chart in a chart can only exist in a directory in a repository not a chart archive. Doc says that it could [Adam] Would work if it’s listed as a dependency [Farina] It is not a dependency [David] Doc bug and feature to support archive in future release [Martin] How did it work in 3.x? [Farina] Checked original source. It is not a regression [Farina] version field and file:// in dependencies… should it be optional? It was until a recent bugfix but it’s not documented as optional… https://github.com/helm/helm/issues/9944 PR already submitted to fix Is this a doc defect for a file? Suggestion: Update doc to mark this as optional in the file scheme Next step: Version is required and not optional Identify as a bug to be addressed Assignments for next meeting (note: Farina, Bridget, and Adam will be gone - volunteers needed) Moderator: Martin Hickey Notes: Karena Angell Issue Triage: Martin Hickey July 8, 2021 Assignments for this meeting Moderator: Adam Notes: Karena Issue Triage: Farina Announcements Next patch release (3.6.3) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 Farina: one more pass at PRs this week then gtg Discussion [Farina] indexes in OCI registries (continued from last week) Butcher: they’re storing the apt index in an image layer Experiment with a plug-in [Farina] --repo flag and username/password https://github.com/helm/helm/issues/9599 and https://github.com/helm/helm/pull/9760 Note, this same idea would apply to `helm install` and `helm upgrade` https://github.com/helm/helm/issues/9599 Doesn’t do set when `helm repo add` Is it a bug but is anything else actually using it? Bug or feature change? Fisher: feature addition in helm 3, PR merge Farina: like it, when should it be released? AI: Farina to dig into it to look if is a regression or needs to be in 3.7 Adam: should apply to any repo [Farina] Move to GH Actions… https://github.com/helm/helm/issues/9921 Example of CI issues… https://github.com/helm/helm/pull/9763 Takes 30 mins / timeouts on linting CircleCI performance issues Fisher: this is going to get worse over time, GitHub Actions could help run tasks in parallel Josh: GH action for golang ci lint tool - maybe consider Farina: linter deprecated error? Adam: open PRs will have to rebase on it Josh: if use GH Actions, can keep running Circle in parallel Farina: start doing Windows testing in GH Actions [Fisher] HIP: Helm Triage Maintainers https://github.com/helm/community/pull/199 Intermediary role? Help triage, shadow [Bridget] relevant to Adding HIP 7 to document subprojects https://github.com/helm/community/pull/156 as well? Roles for charts maintainers? [Marc] Is updating a single repo safe? https://github.com/helm/helm/pull/9845 What happens if you update in one repo, will it update all? Marc: recipe does a helm repo add (which doesn’t do an update) Helm repo add; helm repo update Andrew: wants more control over when to update Marc: risk in inconsistency Farina: dependency mgmt handled, thinks it’s okay Reduce bandwidth, and mem [Scott] Maintainers track talk for KubeCon NA Technical talk focusing on Charts for the Application Distributor role (working doc for anyone interested in contributing to content we end up talking about). We'll schedule some collab sessions for slides etc CTA: any topics you think should be covered? Speak up! [Marc] Dependabot details? Why hasn’t it picked up Cobra 1.2.1? Too many dependabot issues? Please create a PR! Assignments for next meeting Moderator: Matt Fisher Notes: Jasper Chui Issue Triage: Matt Farina July 1, 2021 Assignments for this meeting Moderator: Bridget Notes: Butcher Issue Triage: Fisher Announcements Farina: releases Released 3.6.2 as fix for regression this week. Fixes a bug that became more pronounced by security fix Next patch release (3.6.3) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 Ask: Maintainers, please review PRs in that milestone Discussion [Bridget] helm org cleanup continues Can we complete https://github.com/helm/hub/pull/484 so we can archive the helm/hub repo? Bridget: Process was started but not complete. Anything blocking completion? Can we archive https://github.com/helm/repo-audit ? Seems to be an experiment that may be concluded. Bridget: Any reason not to archive? Farina: This was started for helm hub and charts to audit and make suggestions. For example, checks digests in index file. I don’t know if people still want to build this. Part of chart maintainers projects [Farina] Automatically adding repos during build processes… https://github.com/helm/helm/issues/9840 and https://github.com/helm/helm/pull/9841 Certain commands will error out if a repo has not been added, forcing the user to add the repo manually These issues want to add a repo on the fly, but that causes a security issue. (A new source of dependencies is added to your system at the chart author’s whim) Butcher: this can mask the source of untrusted packages - with the recent software supply chain attacks, this is particularly inadvisable Joe T: this is similar to distro package naming conflicts [Adam] annotations nested in List objects are not respected https://github.com/helm/helm/issues/9829 (continued from last week) Adam: Annotations on items within a Kubernetes list objects are not respected. Only top-level items on a Kubernetes manifest. This is because during the top parse of an object, we only check its object metadata. What we should do is respect annotations on objects embedded in the list. Paul: It seems fair to say that we only respect annotations on the top-level object, and ignore the items in the list Farina: A “keep” on a nested item in a list: How would we handle that? Adam: We’d have to do something like “if this is a list, then iterate on the items in the list.” and that will actually turn very complex over the lifetime of an installation. So I would prefer what Paul suggested. Farina: The alternative seems to be complicated and brittle logic. We could do something in `helm lint` to warn a user of this. And update docs. [Bridget] https://github.com/helm/community/pull/172 Proposal for HIP-0010 on the distributed pick process - we have a second LGTM now - can we merge? Bridget: We think this is ready to merge. Farina: I will do one final review and merge [Farina] indexes in OCI registries (continued from last week) Quick review of where we ended last week. Farina: Should we support indexes inside of an OCI registry, ignoring the locking problem? And how do we support searching, version resolving, etc. The main thing is that we want to continue supporting all of the features available outside OCI registries now Josh: In OCI, can list tags on a namespace, which means we could list versions if we knew the name of the chart. Index files in OCI today would suffer the same race condition that we have today. With my current PR, we are adding extra rules to OCI so that the chart name MUST be the last element in the name, but we could reserve other parts of the namespace for other things -- like putting the YAML file. If we could host a list of just the basenames and not versions… We could add an extension to the Docker Distro server… Farina: Would prefer not to need registry-side add-ons Josh: Could, for example, create a list object that would list all of the chart names for a given user… Farina: But… (I missed the objection) Josh: We could make a new media type for the existing index file and store/retrieve that, pointing to the full blob path Farina: If you have a namespace, can you list all the things in it? Josh: No. And by design it seems changes to the spec will take longer [Butcher: See Vincent’s email on OCI dist list two weeks ago] Farina: The search functionality is the outstanding problem. Apt transport on OCI has come around recently. Curious how that works. https://github.com/AkihiroSuda/apt-transport-oci Josh: Only thing in the Discovery API on OCI Dist is which tags for a given object. Assignments for next meeting Moderator: Adam Notes: Karena Issue Triage: Farina June 24, 2021 Assignments for this meeting Moderator: Scott Notes: Karena (Andy in for Karena) Issue Triage: Adam Announcements Farina: Next patch release (3.6.2) scheduled for Wednesday July 14th: https://github.com/helm/helm/milestone/110 Looking for reviewers Butcher: Congrats to Martin for becoming an Org Maintainer for Helm! https://twitter.com/HelmPack/status/1408093811050311689 - also bringing in https://github.com/hickeyma/helm-mapkubeapis Discussion [Bridget] What remains before we can archive the helm/hub repo? See question in https://github.com/helm/hub/issues/439#issuecomment-820598759 Final steps have been complete and archive can be completed Deprecation notice needs to be added Action: Scott will PR in the “Obsolete” and click the “archive repo” in settings. PR: https://github.com/helm/hub/pull/484 [Farina] managedFields and manager… https://github.com/helm/helm/issues/9859 New field in metadata Added in 1.18 and displayed in kubectl output. Hidden starting in 1.21 New field for Helm to be created to denote the tool that performed the action [Farina] indexes in OCI registries Challenge is that no metadata can be queried (no search API) https://hypper.io/ is talking about putting index files into OCI registries Fisher: review of HIP 6 OCI PR is ongoing Challenge in a race condition and locking What is managing the creation of the index? Helm CLI? What about those not using the CLI Josh: Why are we trying to implement a search mechanism? Farina: Its important to be able to determine what is available and what specific versions Scott: to follow-up next time OCI/Helm semver question: how do we want to handle chart semver metadata (+) as it's illegal in OCI spec? Topic to be continued next week or in another forum [Adam] annotations nested in List objects are not respected https://github.com/helm/helm/issues/9829 Only looks at top-level object Maybe: cascade down? Would be breaking change If anyone has any thoughts, provide details in the issue and follow up next week. [Can move to next week] [Bridget] https://github.com/helm/community/pull/172 Proposal for HIP-0010 on the distributed pick process - we need a second LGTM, I think? Can we move this one forward? Assignments for next meeting Moderator: Bridget Notes: Scott Issue Triage: Fisher June 17, 2021 Assignments for this meeting Moderator: Matt Farina Notes: Bridget Issue Triage: Adam Announcements [Farina] Helm 3.6.1 released. This was a security release (affects usernames/passwords for repositories) Added a new flag to preserve the old behavior when needed Next patch release scheduled for Wednesday July 14th Discussion [Bridget] HIP 6 OCI changes in flight for 3.7.0 (End of August): https://github.com/helm/helm/pull/9782 - please review! Josh: thanks for comments Butcher: yesterday we tri-paired (Adam: tri-pairitops!) Too large to review in one pass - we started with running everything, then looked at impacts on public API and actions Josh: will respond to the first round of comments Josh: tests: https://github.com/bloodorangeio/acceptance-testing/blob/hip-6-push/testsuites/registries.robot Butcher: read the HIP before trying this out - the HIP dictates the UX [Bridget] HIP 4 - can we merge this in? Question for Marc/others https://github.com/helm/community/pull/145#issuecomment-848912289 Needs a confirmation about not being able to change *.yaml at all Needs another approval Marc: this is the backwards-compat HIP - one unaddressed concern about yaml compat Farina: we use strict parsing now, for security reasons - for those files we’re locked into the current schemas but can use annotations if we need to add things before Helm v4 Butcher: the security audit is here: https://github.com/helm/community/tree/main/security-audit Scott: we need to update the docs Fisher: this is due to limitations in yaml parsing libraries and how they handle duplicate keys - if someone wants to contrib that to the yaml parsing lib we could relax it in Helm v4 Scott: I will update the docs Marc: I’ll reach out if I don’t see it there Butcher: I’ll add the list to that comment thread on the issue Farina: once that’s in, I’ll review it. [Marc] Why was updating a single repo removed in helm v3? “helm repo update ” Missing PR? https://github.com/helm/helm/pull/5182 With many repos configured on my machine, a script would benefit from only updating the repo it cares about Or helm repo add could cause an automatic update when repo exists? Farina: This appears to have not been brought over to v3 - this would be an easy feature request to port over Fisher: possible considerations around chart locking, but I don’t think we _chose_ to not port this. [Josh] mailing list votes - should we add reminders to this call? Farina: someone needs to track down all potential votes Butcher: the project adoption one will be simple majority (4 org maintainers) Mailing list vote this time for Martin Assignments for next meeting Moderator: Scott Notes: Karena Issue Triage: Adam June 10, 2021 Assignments for this meeting Moderator: Marc Notes: Jasper Issue Triage: Matt Farina Announcements No patch release yesterday, as it would have been within 4 weeks after a minor release Next patch release scheduled for Wednesday July 14th Summer vacations make things quiet at the helm! [Farina] Tend to see some slow down in the summer Discussion [Bridget] HIP 6 OCI changes in flight for 3.7.0 (End of August): https://github.com/helm/helm/pull/9782 [Farina] Make OCI available as GA Please review PR [Marc] What can be changed? [Farina/Adam] As long as it doesn’t have UI impact can be changed [Farina] Some experimental commands are available when experimental mode is enabled HIP (4?) in flight that defines what can change Maintainers to Review and determine next steps [Farina] Target end of July to ensure it doesn’t break anything. [Joe] A number of files are being modified and removed Does impact public API [Martin M] PR backlog (154 PRs open) What is the plan to bring this down to a manageable level? [Farina] Usually hovers around ~100 Hoping to start going through these PRs if someone else can take over triage Steps to maintainer is to provide constructive feedback on PR review Anyone can provide review [David] Should we wait until tests are passing? Security scan is gated but should not stop reviews [David] Testing and verifying fix will be useful [Farina] ensure test format is consistent with other tests [Bridget] Chartmuseum repos proposed for Helm org membership: https://github.com/helm/community/issues/191 [Marc] Martin will cherry pick for next release Release branch will be ready by day of release 7 PRs in 3.6.1 milestones that are not reviewed [Farina] Will try to review to get it in Any help is appreciated Assignments for next meeting Moderator: Matt Farina Notes: Bridget Issue Triage: Adam June 3, 2021 Assignments for this meeting Moderator: Scott Rigby Notes: Matt Fisher Issue Triage: Matt Butcher Announcements [none] Discussion [Josh] Various HIP 6 questions Experimental flag, internal/ vs. pkg/, removal of “helm chart” “Pusher” interface - implement uploader plugins identical to downloader plugins? Multiple requests made to fetch .prov, even though both chart and prov can be fetched at once [fisher] is there a way to pass along the chart cache here? There’s a HIP open about provenance/chart caching that could help here too. Is there a way in memory to extract chart metadata from .tgz raw bytes? [fisher] I believe pkg/chart/loader has functions for this “read” function - reader interface [fisher] https://github.com/helm/helm/blob/bf486a25cdc12017c7dac74d1582a8a16acd37ea/pkg/chart/loader/archive.go#L188-L189 Output for “helm push” / “helm pull” - what info should we print to console? We have the chart metadata as well as the digest+size for the following OCI layers: manifest, config, chart, prov [fisher] would this be useful to append as a PR to HIP 6? Add --digest= flag on “helm pull” to verify manifest digest? Later? The registry client not enforcing ref name - should people be able to push/pull charts wherever to/from they want when using it as a library? [josh] looking for feedback on these items [farina] we probably need to have all the new work land under “experimental” before we move to GA. Once made public, changes cannot be made until Helm 4 [josh] the underlying client is being completely overhauled, so it would be easier to change it all underneath. Is this OK? [fisher] while it’s experimental, we can make whatever changes make sense - go ahead if needed to move the experiment forward [scott] are there any thoughts on pulling out the registry package into a separate library/repository? [josh/farina] I think the ORAS project handles this ORAS: https://github.com/oras-project/oras [farina] when can that become available for other projects? What are the requirements for removing experimental flag? [Simon K] Anything else needed for https://github.com/helm/helm/pull/9713 (brought up by David last time)? Next steps? [fisher] will need two maintainers to review it (cdndoit18 is not a maintainer) Adding a reproducible test case is a great way to help people see more [Paul] Does anyone want to enter a Helm team for CNCFaceoff (https://twitter.com/mattstratton/status/1397565630975463432 ) [bridget] If they do, how should they reach out? There’s a form in the tweet thread. - https://twitter.com/mattstratton/status/1397567060012580864 [Bridget] notification emails from ArtifactHub - do we need to do any followup? [farina] most of these emails come from charts that were in Helm Hub. It’s been more chatty because it’s scanning everything by default. I’ve been cleaning up these notifications as it’s out of our hands [farina] if you post something on Artifact Hub, you can subscribe to notifications to be informed of any security issues Assignments for next meeting Moderator: [Bridget if nobody else volunteers] Notes: Jasper Issue Triage: Matt Farina May 27, 2021 Assignments for this meeting Moderator: Adam Reese Notes: Karena Angell Issue Triage: Matt Farina Announcements [Farina] 3.6.0 is released [Farina] the release date for 3.7 is set to Wednesday September 8, 2021 Kubernetes 1.22 is scheduled for August 4th; this gives us time to test. Looking ahead: there will be one more k8s release in 2021 (1.23) [Butcher] Emeritus maintainers Thanks, Vic & Brian! Martin Hickey has been nominated as a new org maintainer Discussion [Farina] Generating reproducible tarball fix - https://github.com/helm/helm/pull/9674 Is it a breaking change to drop the timestamp? Fisher: need to address a couple of things in the PR before moving forward. Spend time writing a unit test would be helpful Farina: agree, need more testing - concerned removing the date could be a breaking change. Focus on whether stripping the date is a breaking change. Butcher: Because some people use the hash to see when the tar has been rebuilt, even if its contents were the same Butcher: And the Go implementation is different than BSD and Gnu tar, too Scott: https://github.com/helm/helm/pull/9674#discussion_r640793402 Maybe feature flag could solve it Follow-up: Farina going to go back and address some things in PR [David P] Wanted to bring attention to https://github.com/helm/helm/pull/9713 as being blocked from running the gate checks cause it is a first time contributor. He will benefit from the automation to improve the PR as needed. [fisher] approved. Fisher: more nuanced - bitcoin mining! Marc: trust github automation? [Adam] Global values https://github.com/helm/helm/pull/9333 Needs another maintainer’s eyes on it Fisher: wants to proceed with caution [Scott] If time, Farina do we want to discuss KubeCon NA session ideas on this call? Farina: tech focused talk on charts Fisher: yes, if other CfP doesn’t get accepted AI: Farina will start a doc Assignments for next meeting Moderator: Scott Rigby Notes: Matt Fisher Issue Triage: Matt Butcher May 20, 2021 Assignments for this meeting Moderator: Marc Khouzam Notes: Jasper Chui Issue Triage: Matt Farina Announcements [Farina] Next release is 3.6.0, planned for next week: Wednesday May 26th RC available for your evaluation: https://github.com/helm/helm/releases/tag/v3.6.0-rc.1 Please test it out and let us know if there are any issues [Bridget] Helm at KubeCon EU was a huge hit! Thanks to all who participated; start thinking about KubeCon North America! Numbers from Karen Chu: Tuesday, May 4 Helm office hours attendees: 458 Wednesday, May 5 Helm office hours attendees: 312 Thursday, May 6 Helm office hours attendees: 233 Helm project booth visitors: 1,233 [Karena] KubeCon NA - CfP deadline is this Sunday 11:59 PM PDT Bridget is happy to review any proposals [Bridget] Thanks to Karena for her work revising the FAQ on the docs site. It was previously focused on helm2->3, and she’s making it a more general FAQ. Looking for additional topics to document [Farina] Vic stepped down from Helm org maintainership Credit for the CI infrastructure for stable/incubator - thank you! Discussion [Bridget] Reminder about the Helm repo audit - if you think you have repos to archive, you may be right! Please take a look; let’s keep moving this along. [Marc] For Josh, regarding acceptance testing repo [Josh] Needing updates HELP WANTED [Farina] Pull sizer: designate size of issues Should not be deprecated as there are no alternatives Help needed to determine if there are GitHub actions that could be used to achieve this function [Bridget] Have you commented on all HIPs of interest to you? https://github.com/helm/community/pulls has various HIPs to check out. [Butcher] Continuing discussion for HIP for Helm 4 planning and development process (HIP0012) [Bridget] Should we defer to next week? [Farina] Highlights approach for Helm 4, including roles and responsibilities Feedback is useful [Martin] May need additional updates to branching. Waiting on feedback from Matt Fisher [Bridget] Should we say lazy consensus by next week? [Farina] Need approvals from 2 helm/helm maintainers [Josh] Is there a requirement to push for Helm 4 [Farina] Opportunity for breaking changes, api changes, clean up. Requests from the community. [Martin] Need a list of PRs before Helm 4 kicks off [S Bose] Support for the --hide-secrets flag, PR is good to go https://github.com/helm/helm/pull/9130 Bridget: should this go in milestone 3.6.1? 3.7.0? [Farina] Requires approval from two maintainers Soonest is 3.7.0 as it is a feature addition Possibly 3.7.0 (September 8). Month after next k8s release [David P] Pipeline doesn’t run and need approval from maintainer to approve [Farina] This is a good forum to raise this New requirement from Github within last few weeks Bridget: https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/ [Bridget] Welcome Annie Wang, new intern on Bridget’s team Assignments for next meeting Moderator: Adam Reese Notes: Karena Angell Issue Triage: Matt Farina May 13, 2021 Assignments for this meeting Moderator: Adam Reese Notes: Karena Angell Issue Triage: (2 weeks) - Butcher, Fisher Announcements [Bridget & Farina] Next release will be 3.6.0 RC planned to be cut Monday May 17th release planned for Wednesday May 26th [Bridget & Butcher] Butcher’s HIP for Helm 4 planning and development process (HIP0012) has one more week for discussion Discussion [farina] HIP on caching https://github.com/helm/community/pull/185 Currently - when pull or install, chart is stuck in cache with index files - creates conflicts HIP - local cache w/ content addressability Also helps w/ people who download the same charts over and over again Needs two maintainers to look at Matt Fisher ?? Also, look at to make sure there isn’t anything that can go horribly wrong [farina] Hypper Demo https://hypper.io/ Built on top of Helm For cluster admins Install charts into separate namespaces Joe J: shared dependencies but different values? Farina: still working through that Farina: currently, can alter namespace name and release Bridget: use cases? Farina: used by tooling, structured like helm, future wrap the sdk [karena] new FAQs from office hour sessions Assignments for next meeting Moderator: Marc Khouzam Notes: Jasper Chui Issue Triage: Matt Farina May 6, 2021 Cancelled this week - KubeCon EU (various Helm sessions and office hours - https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/) April 29, 2021 Assignments for this meeting Moderator: Marc Khouzam Notes: Matt Fisher Issue Triage: unassigned Announcements [Bridget] Next release will be 3.6.0 RC planned to be cut Monday May 17th release planned for Wednesday May 26th [Bridget] Helm org repo audit continues [Bridget] Sign up to participate in KubeCon EU next week: https://docs.google.com/spreadsheets/d/1yJyvuzHoOoQk0yiGGUXPfDUCo_mO_UWyryFURc1HOX4/edit?usp=sharing “Meet the maintainer” means staffing the booth in the KubeCon EU event platform “Project office hours” are held on Bevy [Bridget] Not having this meeting next week Thursday May 6, due to KubeCon EU. On Thursday we do have the KubeCon EU maintainer session with live chat, as well as the office hours session, for all your Helm-meeting needs. Discussion [Marc] Backwards-compatibility for yaml files (Hip 0004): https://github.com/helm/community/pull/145 Fisher: security issue based on unexpected overwrites Fisher: solved by strict field checking Karena: documentation of this limitation would be good Marc: why can’t we introduce optional fields? Fisher: older versions of Helm would have no notion of this field. Introducing a new field would break strict parsing Fisher: let’s be cautious about circumventing security - avoid footguns Adam: when strict checking is enabled, it doesn’t error out. It just ignore those fields. Right Fisher: I believe strict checking does tell YAML to error out on those fields. By default those fields are ignored [Marc] Hip 0010 for distributed pick process: https://github.com/helm/community/pull/172 Marc: This is ready for review. I left if there for when anyone has time to review [Josh] Registry support + OCI Distribution + ORAS updates HIP 006: https://github.com/helm/community/blob/main/hips/hip-0006.md The Distribution spec was put up for a 1.0 vote this week There is a movement to move the oras project as a CNCF sandbox project I will be working on the reference implementation for HIP 6. Expect that to be coming in the next month or so Fisher: is the artifacts proposal part of the v1.0 vote or is that separate? Josh: putting Helm charts in a registry is not an official part of the “spec”. That being said cloud vendors are supporting these solutions. So it’s not part of the vote but it’s in there. Josh: I would ask if you can join the OCI meeting and ask about that Paul: does harbor support Helm charts in the registry? Josh: short answer yes [Joe] I tried asking in slack, but can this get into 3.6? https://github.com/helm/helm/pull/9425 There's no functional change, but it does create a public library that can be used to check the release readiness after the initial deploy. This will unblock a readiness plugin I want to write, and a fluxcd capability that we need. [Bridget] let’s try to get it some reviews after KubeCon EU? Added to the 3.6.0 milestone for review Assignments for next meeting (Thursday May 13th) Moderator: Adam Reese Notes: Karena Angell Issue Triage: (2 weeks) - Butcher, Fisher April 22, 2021 Assignments for this meeting Moderator: Matt Farina Notes: Karena Angell Issue Triage: Matt Fisher, Joe Julian (shadow) Announcements [Farina] Next release will be 3.6.0 Target for Wednesday, May 26th for Kubernetes 1.21 Monday of the week before, RC will be cut - May 17th Discussion [Butcher] HIP for Helm 4 planning and development process (HIP0012) What will be selected for development When will it be worked on How to stop the process if necessary (lack of community resources/involvement) Acceptance: project maintainers Mid to end of May - May 20th dev meeting, finalize comments/acceptance Someone needs to make sure they’re looking at all the HIPs and they work well together Shoubhik: High level themes for Helm 4? Farina: separate process from content, but sdk changes, feature changes, etc. Farina: define process first and pull those discussions into the bigger picture strategy for Helm 4 [Bridget] Helm org repo audit progress Can we archive helm/hub and other inactive repos? Let’s finish the branch rename for active repos Progressing and will continue to progress Farina: will help after KubeCon/CNcon [jannfis/shoubhik] Helm integration with Argo CD Want to talk about https://github.com/helm/helm/pull/9040 We need --kube-version for “helm template” badly Jann: Maintainer for Argo CD, in Argo community, some people are having difficulties installing charts Fisher: validate flag - grabs kube version from live k8s cluster - possibility? Jann: separate isolated process for processing manifests using a repo server, no live info from cluster - security requirement Farina: is there a conflict setting the kube version and validating? Maybe specify can only have one or the other Farina AI: will add to backlog for 3.6.0 [Bridget added to the milestone for review, as of April 29, 2021] Shoubhik volunteering to dive deeper into use cases Fisher: Helm 2 did not do openapi validation [shoubhik] Curiosity question :) What’s the due diligence needed when we do kubernetes version bumps? https://github.com/helm/helm/pull/9595 [Srishti] question : I had a question around the issue I recently raised https://github.com/helm/helm/issues/9620 Farina: you can still put CRDs in the templates directory Farina: You can use a separate chart to template crds: https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-2-separate-charts Farina: STRONGLY suggest reading the CRDs HIP: https://github.com/helm/community/blob/main/hips/hip-0011.md Joe Julian: important reason for CRD templating: conversion webhooks Butcher: no changes to CRDs for the rest of Helm 3 lifecycle, Helm 4 HIPs would be a good place to discuss [dperaza] question: Recording for last contributor summit out? [Bridget] CNCF will release that; Helm maintainers don’t control the timing. We expect it around the end of the month. [Scott] I’ll be archiving some repos that I understand were already discussed, and will update the spreadsheet accordingly! :-) Thanks Bridget for the reminder Also PS, I still have not deleted the old meeting time event from my calendar, so when I’m super busy I sometimes come a half hour late. Finally deleting that now lol Assignments for next meeting Moderator: Marc Khouzam Notes: Matt Fisher Issue Triage: April 15, 2021 Assignments for this meeting Moderator: Bridget Notes: Jasper Issue Triage: Butcher Announcements [Bridget] Branch rename (to “main”) in progress for repos under https://github.com/helm check your repos and rename if need be! Instructions: https://github.com/github/renaming Working checklist: https://docs.google.com/spreadsheets/d/13OjQnpzCRrdFtJ6nhzO7c7JmsKjnyJ48y63ry1GmP14/edit?usp=sharing [Farina] v3.5.4 released Next release 3.6.0 Target for May for Kubernetes 1.21 Discussion [Marc] Blog about DockerHub rate limits (see last week) Should we clarify to community if they may think it is caused by Helm? Could use a blog to inform community [Joe T] Starting to collect details, could put towards google docs [Fisher] Rate limit has been in place since last October [Farina] Are we seeing any complaints? [Bridget] Not directly, just hearing from community [Bridget] To review docs and update as appropriate [Farina] Shameless plug: I’ll be presenting a new project based on Helm and charts ... next wednesday in the Rancher meetup… https://info.rancher.com/online-meetup-april2021 [Bridget] Should we use the GitHub “archive” setting on helm/charts and helm/monocular, among others? (https://docs.google.com/spreadsheets/d/13OjQnpzCRrdFtJ6nhzO7c7JmsKjnyJ48y63ry1GmP14/edit?usp=sharing) [Farina] Has a list of repos to be archived Monocular: Ready to be archived. Need to inform community Bridget to connect with Farina to create list of repos to be archived [Butcher] Only maintainers can / should archive repos [Marc K] What is the process to identify which PR to include in a release? [Farina] Only the PRs that were closed [Butcher] https://github.com/helm/community/pull/145 - backward-compat HIP [Fisher] Needs to be approved by core maintainer [Marc K] Are referenced implementations required? [Fisher] If HIP requires one then it should Marc to remove referenced implementation section [Marc] Should we have a master list of what cannot change? [Butcher] Agree that it should be in the www documentation. Not required before HIP is approved. [Fisher] Question deferred to future discussion [Marc] HIP will be used for backward compatibility criteria [Bridget] PRs to be reviewed Assignments for next meeting Moderator: Matt Farina Notes: Karena Issue Triage: Matt Fisher, Joe Julian (shadow) April 8, 2021 Assignments for this meeting Moderator: Marc K Notes: Karena A Issue Triage: Adam and Bridget Announcements [Bridget] Branch rename (to “main”) in progress for repos under https://github.com/helm check your repos and rename if need be! Instructions: https://github.com/github/renaming [Bridget] Helm Contributor Summit is a wrap! CNCF will publish videos. Shout out to Karen Chu and Matt Butcher for all their work putting it together. [Bridget] get those bug fixes in! 3.5.4 will contain only bug fixes and be released on April 14, 2021 New “pick” process should help with release Marc wants to help w/ release AI: Whoever is cutting the release, pull Marc in Discussion [Bridget] Dockerhub rate limiting and defaults Potential problem (in https://docs.microsoft.com/en-us/azure/aks/ingress-basic#create-an-ingress-controller) to use a helm chart that points to dockerhub which may have rate limiting (https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/values.yaml#L494) Potential change: https://github.com/kubernetes/ingress-nginx/pull/7018/files (to decouple the registry and repository) Anything else to consider here? [fisher] the CNCF struck a deal with DockerHub so that any CNCF projects will not be rate limited. ingress-nginx and others may fall into that category. https://github.com/cncf/servicedesk#my-project-is-affected-by-the-docker-hub-rate-limits-policy-changes-what-can-i-do Bridget: where should this be documented? ArtifactHub? Helm docs? Karena: blog post, Scott +1 Scott Rigby: we can communicate to users about how this might affect them - charts have images configurable for helm values Joe Julian: Helm users might not be k8s admins and might not know about dockerhub rate limits - pointing it out in documentation might be useful Scott: even people who use k8s frequently, they might not know where in the supply chain it’s pulled from Bridget: cya for Helm, not a prob created by Helm Joe J: be aware of your rate limits Joe Thompson: It would be nice if Docker themselves displayed something in the docker logs about "rate limit in effect for this repo" but I dunno if that's even possible with the way Docker works. Joe: “Turns out they do! https://docs.docker.com/docker-hub/download-rate-limit/#how-can-i-check-my-current-rate” AI: Blog post, start a draft next week, volunteers? Assignments for next meeting Moderator: Bridget Notes: Jasper Issue Triage: Butcher April 1 2021 Assignments for this meeting Moderator: Adam Reese Notes: Karena Angell Issue Triage: Matt Farina Announcements [Martin] Rename of “main” branch Mostly redirection Look at Helm slack channel for details GitHub will pop-up info too Bridget: clean up for others? Martin: yes, maintainer by maintainer AI Maintainers AI: Update your repos [Farina] Archiving of Monocular Blog tbd saying ‘use ArtifactHub instead of Monocular’ [Karena] Contributor Summit on Tuesday! April 6 Discussion [Farina] The --dependency-update flag, it’s docs, and it is not matching its functionality… https://github.com/helm/helm/issues/9545 Create documentation that says ‘only updates in this case’ Create another flag that updates everything Clean up in Helm 4 Only returns if there are missing dependencies: https://github.com/helm/helm/blob/213a7df2dcd07e8d49fc6acf8a53a540c661ed53/cmd/helm/install.go#L216 Bug since Helm 2.9 or .. ? Joe T: deprecate the old flag, define 2 new flags Farina: no deprecation cycle, mark for removal in Helm v4 Farina AI: Document the ticket to remove [Marc] HIP-0010: "Cherry-pick a PR into the release branch right after it is merged into main" Marc AI: add a section for the security patch [Farina] chart cache in helm https://github.com/helm/helm/issues/9561 Index.yaml, use digest to go look at cache Bridget: bandwidth discussion, what gets cached, what doesn’t Farina: that was about binaries, so prob no impact Scott: careful with changes in index.yaml, sounds good [Karena] Investigate artifact signing? https://sigstore.dev/what_is_sigstore/ Farina: provenance files are pgp signed Farina AI: Go learn about it Assignments for next meeting Moderator: Marc K Notes: Karena A Issue Triage: Adam and Bridget March 25, 2021 Assignments for this meeting Moderator: Martin Hickey Notes: Jasper Chui Issue Triage: Matt Butcher Announcements [Bridget] get those bug fixes in! 3.5.4 will contain only bug fixes and be released on April 14, 2021 When would we like to cut an RC? [Farina] No RC for Patch 3.6.0 is the next feature release and will be released on May 26, 2021 Depending on k8s release schedule (on track) Followup end of April on release status Contributor Summit April 6, 2021 Helm Contributor Summit - Tues Apr 6, 2021 Register: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ [Bridget] Reach out to Karen if you want to register as an organizer [Fisher] Need an LF account to register as an organizer Discussion [Farina] Archiving Monocular https://github.com/helm/monocular (Web UI for Helm Chart repositories) Maintainers are in agreement to archive project Target next week to archive Replaced by Artifacthub.io Documents to be updated: https://helm.sh/docs/community/related/#additional-tools [Farina] Hackweek project: How to navigate source code - https://codeengineered.com/blog/2021/helm-vid-series/ Assignments for next meeting Moderator: Adam Reese Notes: Karena Angell Issue Triage: Matt Farina March 18, 2021 Assignments for this meeting Moderator: Josh D Notes: Bridget K Issue Triage: Josh Dolitsky Announcements Discussion [Marc] Details of the “needs-pick” process? Label goes on bugs that need to go into a patch release (not a minor) What if no patch release until minor release? [fisher] If there’s no need to cherry-pick, then we remove the “needs-pick” label. Not features (features don’t go into patch releases) Does a milestone need to be added/created? [fisher] For a patch release, yes. What query to use? is:pr label:needs-pick -label:picked [fisher] it looks like a number of PRs need to be triaged in that query. Butcher: ideally, add “picked” and remove “needs-pick” Marc: found some needs-pick and they ended up in a minor release Butcher: minor-release might not mark as picked for those pre-picked for a patch release - from the last minor onwards is likely the only that need it Resolution: Marc will change labels as desired to correct inconsistencies [Simon Croome] - Linter name validation rules: https://github.com/helm/helm/pull/9416 Simon: in 3.3.0, change to add name validation Simon: PRs in place to try to correct this (inferring from k8s API is challenging - match on object Kind?) Simon: hoping to get movement on this as it’s blocking us from doing releases Butcher: Adam can look at PR Josh: can you pool the cases from k8s? Butcher: API server in k8s does validation after determining if validation is well-formed Bridget: 3.5.4 will contain only bug fixes and be released on April 14, 2021 - can we get this PR reviewed by then? Butcher: yes, this goes in bugfix. Josh to look first, then Adam [Butcher] Helm Contributor Summit - Tues Apr 6, 2021 Register: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ [Farina] Dropping support for Go < 1.14 … https://github.com/helm/helm/pull/9355 Farina: Cobra dropped below 1.14 support Marc: confirms that Cobra won’t confirm 1.14 soon but this hasn’t happened yet Farina: the only supported Go versions are 1.15 and 1.16 Butcher: GitHub had a security alert - we audited and are fine. Josh: I was doing triage this week - do we have rules around squashing vs merge commits Farina: no consistency Butcher: we had a rule about squashing but haven’t enforced it in at least two years Josh: sounds like we don’t have an answer to this? Discussion ensues and we find that Butcher, Farina, Bridget, Joe, and more all dislike squashing and history rewrites, so we are not going to mandate any of that. Assignments for next meeting Moderator: Marc K Notes: Jasper Chui Issue Triage: Matt Butcher March 11, 2021 Assignments for this meeting Moderator: Josh Notes: Karena Issue Triage: Butcher Announcements [Farina] Helm 3.5.3 released 3.5.4 will contain only bug fixes and be released on April 14, 2021 3.6.0 is the next feature release and will be released on May 26, 2021. [Bridget] get.helm.sh funding renewed [Butcher & Karen] Helm Contributor Summit - Tues Apr 6, 2021 Register: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ [Bridget] KubeCon EU 2021 Helm content: Helm Users! What Flux 2 Can Do For You - Scott Rigby & Kingdon Barrett, Weaveworks Mainly for Helm-only users Taking the Helm: Becoming a Maintainer - Bridget Kromhout & Matt Butcher, Microsoft; Karena Angell, Red Hat; Matt Farina, Rancher Labs Office hours (Karen arranging) Helm project pavilion booth (Karen arranging) [Farina] Helm 2nd security audit - https://helm.sh/blog/helm-2nd-security-audit/ Also includes threat analysis Discussion [Adam] Helm examples repo https://github.com/helm/examples Created a straw man - looking for any help Bridget: former stable/incubating repo is a good place to start for any docs help Farina: let’s use best practices Scott: volunteering to help / charts team would be good volunteers too AI: Scott to start an issue in the repo for brainstorming Scott: GH Discussions? Bridget: Not now - the tldr is I’ve seen other projects turn it on, find it unmaintainable, turn it off, and find out that they’ve now hidden all the past discussions. Sounds not quite ready for prime time. [Bridget] get.helm.sh download metrics: how should we surface them? Fisher: using verizon cdn, unsure how to pull metrics, maybe could scrape the mgmt portal AI: no AI [Devdatta Kulkarni] highlighting KubePlus (https://github.com/cloud-ark/kubeplus) Presentation: https://github.com/cloud-ark/kubeplus/blob/master/KubePlus-presentation.pdf Multi-tenant application stacks Wrap api around the Helm chart Butcher: resourcePolicy sounds like a good idea Able to collect consumption metrics now Might be interesting to folks from Orkestra (https://github.com/Azure/orkestra) [Joe] Issue w storage size for secrets Fisher: opt in to configmaps, move from 2 to 3 Fisher: talking about alternate storage backends (like mysql) https://helm.sh/docs/topics/advoanced/#configmap-storage-backend Postponed to March 18 [Marc] Details of the “needs-pick” process? Label goes on bugs that need to go into a patch release (not a minor) What if no patch release until minor release? Not features (features don’t go into patch releases) Does a milestone need to be added/created? What query to use? is:pr label:needs-pick -label:picked Assignments for next meeting Moderator: Matt Farina Notes: Scott Rigby Issue Triage: Josh Dolitsky March 4, 2021 Assignments for this meeting Moderator: Bridget Notes: Butcher Issue Triage: Fisher Announcements [Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 Cut-off for the Helm release is tomorrow, Mar 5 Only two issues in the milestone, and changes have not been made, so may be removed from release [Butcher & Karen] Helm Contributor Summit - Tues Apr 6, 2021 Register: https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ Workshop to help new contributors and those who may want to become maintainers TA-style maintainers needed for Q&A during chat KubeCon EU: Karen arranging booth and office hours; Bridget arranging recording of contributor-onboarding maintainer session: https://sched.co/iE6C Office hours: Zoom calls at specific times where people can join and chat Karen will tell us when it is time to sign up Karena, Bridget, and “various Matts” will do a talk Discussion [Bridget] followup on Brendan’s idea about a Helm label project? Butcher’s action item was to send info to Farina who was going to talk to sig-apps Next SIG-Apps meeting is next Monday [Scott & Farina] progress on opening up the functions to the SDK? Blocked on OCI experimental flag Josh: There is a branch open with some Push (abstraction) work. Oras is also going through some changes to make it more CNCF-supported (maybe part of the distribution project). [Karena] Update on CI/CD? Farina: Issue is that GitHub actions are pulling Helm fresh each time Caching is not as airtight as it should be… no best practices. So we are stalled Shoubhik will take a look at it. “Is there an issue to look at?” Farina: Maybe on www repo? Brief discussion on docs for release process https://helm.sh/docs/community/release_checklist/ Assignments for next meeting Moderator: Josh Notes: Karena Issue Triage: Butcher February 25, 2021 Assignments for this meeting Moderator: Marc K Notes: Scott Issue Triage: Matt Farina Announcements [Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 Review issues/pr and add to milestone as appropriate Target week before (March 3) due date Discussion [Butcher & Karen] Helm Contributor’s Summit - Tues Apr 6, 2021 Website is live! https://community.cncf.io/events/details/cncf-cncf-helm-community-presents-helm-contributor-summit-2021/#/ Need volunteers to present Registration on the website Single track. See Agenda on website One goal of this is to help those contributors who may eventually become maintainers Plan to work w CNCF to have a dedicated slack channel for this event. People can ask Qs there, and TAs can jump in and answer questions without interrupting the speaker. "backchannel" No cost for attending the event [Farina] How much of this covers parts of the Helm project that aren't helm/helm (chartmuseum, chart-releaser, etc) [Butcher] mainly focused on Helm org, community repo, documentation, and helm/helm (the biggest process load) Need more maintainers to help organize [Scott] happy to help with various things, including charts and tooling related repos [Butcher] Brendan’s idea about a Helm label project k8s in general is trying to come up with more labels, but no org happy to take that on Brendan thought, since Helm is how most people organize their manifests, could Helm help canonicalize this? Butcher talked with a few people already, but this would be the forum Farina: if it's not documented somewhere, I think that would be great example "icon" - no standard label for application icon yet Farina (re SIG Apps): would this be better to expand in k8s common labels there, or here? [Joe J] was thinking SIG Apps so that it can be used in other projects e.g. kudo Farina will take this to SIG Apps to see if that is the right place. If not will bring it back to here [Fisher] if it comes back to here, a HIP is a good way to go [Farina] would like to see this at a higher level, not buried in documentation. One nice thing in `helm create` it populates these for you. Otherwise these are ont easily discoverable [Scott] What steps are needed to open up the functions to the SDK getter is already open one thing that would help open up is the registry client currently in internal package in helm Scott: Yes we have semver contracts and don’t want to screw those up - but what do we need to get the OCI support finished? Farina in same boat. but 2 things would like to have before we make public 1. APIs solidified. Not sure if done, must talk w Josh 2. doesn't want to use logrus as a dependency because they're not in maintenance mode. Ideally would not like to pull this in 3. Really like to see ORAS repo (https://github.com/deislabs/oras) moved out of deislabs and into its own org Fisher OCI is still considered a draft. Scott: can we keep the experimental flag but also make functions avail to SDK? Fisher: some things (like catalog items) changing over time - if stable, we won’t break compatibility Scott: hmmm.. Own package/repo for versioning? Farina: Scott, do you have time? Action item: Farina and Scott to connect and write a plan. Assignments for next meeting Moderator: Bridget Notes: Butcher Issue Triage: Fisher February 18, 2021 Assignments for this meeting Moderator: Scott Notes: Jasper Issue Triage: Matt Farina Announcements [Bridget] 3.5.3 milestone due March 10, 2021: https://github.com/helm/helm/milestone/107 Review issues/pr and add to milestone as appropriate Target week before (March 3) due date Discussion [Marc] HIP for a distributed pick process https://github.com/helm/community/pull/172 Process for Patch release identify needs-pick labelled items to include Person approves into master also responsible for including in release branch [Farina] What would be the process to handle a security release? Create a separate branch for Security Release based on previous release Does this work for the two recent security releases? Discuss proposal on how to handle releases and branches under different scenarios Merge back commits from hot fix branch back to master Looking for reviewers and feedback [Marc] HIP for descriptions for custom completions https://github.com/helm/community/pull/161 Cobra has improved handling auto complete Where does the description come from? Pulls from various sources Looking for reviewers and feedback Scott: I'll look closer from a charts end user POV [Bridget] good first issue label - can we revisit this one? https://github.com/helm/helm/labels/good%20first%20issue is very stale Looking for additional issues that could be labelled with “good first issue” Assignments for next meeting Moderator: Marc K Notes: Scott Issue Triage: Matt Farina February 11, 2021 Assignments for this meeting Moderator: Bridget Notes: Karena Issue Triage: Matt Butcher Announcements Artifact Hub: Values Schema Reference [Farina] https://blog.artifacthub.io/blog/helm-values-schema-reference/ Discussion When a release fails to update (after the upgrade of Kubernetes manifests) should we display a message or return an error [Farina] Inconsistent between Install and Upgrade/rollback On Install we display a message to debug log Comment in action install says… // This is a tricky case. The release has been created, but the result // cannot be recorded. The truest thing to tell the user is that the // release was created. However, the user will not be able to do anything // further with this release. // // One possible strategy would be to do a timed retry to see if we can get // this stored in the future. On upgrade/rollback we return an error It will upgrade all the k8s assets, doesn’t actually store the secret [M Butcher] Failure of etcd to store something If recorded, will show installing [Farina] Just return a non 0 exit code https://github.com/helm/helm/pull/9131 is looking to add a case where another error could be returned on upgrade/rollback [Scott] should this be a bugfix? GitHub Discussions [Farina] Disabling github discussions: https://github.com/dotnet/aspnetcore/issues/29935 [Bridget] What happens to existing discussions? [Scott] Will test Discussions last longer than issues Homebrew is using discussions [M Butcher] Is GH Discussions basically “Stack Overflow by GitHub” [Bridget] yes, but don't have the management granularity, would it make it harder for ourselves? [Scott] has default categories, can change categories at any point Threaded answers, user or maintainer can select the correct answer [Josh/Bridget] more things to check / more work for the community/maintainers? [Farina] Will send to helm mailing list and other maintainers, revisit in a week or two. Better CI practices [Farina & Butcher] Costs a lot for downloads every month Example: homebrew ~ $25k/mo Document best practices [Scott] GH actions have artifacts, will look into also look into caching across jobs [Bridget] define how to be more prescriptive TO DO: “CI Best Practices” on helm docs Question about CRDs during helm upgrade [Scott] If a CRD exists we don’t try to apply it - but what about updates? Could we have a similar functionality on “helm upgrade” to what we have on “helm install”? Read: https://github.com/helm/community/blob/f9e06c16d89ccea1bea77c01a6a96ae3b309f823/architecture/crds.md Explains pitfalls of handling crd’s Farina has opinions :) Assignments for next meeting Moderator: Scott Notes: Jasper Issue Triage: Farina February 4, 2021 Assignments for this meeting Moderator: Adam Reese Notes: Jasper Chui Issue Triage: Matt Farina Announcements ChartMuseum v0.13.0 released today (currently in progress..) Follows Helm’s release process: same artifact store (get.helm.sh), installer script, release notes, signatures, etc. Docker image on GitHub Container Registry Discussion Cancelling patch release of Feb 10th? (4 weeks after 3.5.0) [Marc] policy https://helm.sh/docs/topics/release_policy/#patch-releases Should this be cancelled per policy [Butcher] Security team scheduled release today so it makes sense to cancel patch release Next patch will be in March Patches in current release will be bumped to 3.5.3 HIP for a distributed pick process https://github.com/helm/community/pull/172 [Marc] Please review, if approved will impact all maintainers Recent intermittent CircleCI failures - perhaps we need to consider changes to the build pipeline? [Bridget] [Butcher] Security issue was found and should be fixed today Chart releaser action docs update? https://github.com/helm/helm-www/pull/928 [Bridget] Scott says circle back [Scott] Reviewed and will leave suggestions for owner to review Creating a 4.0 milestone? [Marc] 4.0 should be delayed as long as possible but good to have community to start tracking [Butcher] Milestone 3.0 was opened a year before so good to do the same for 4.0 [Bridget] Label already exists for 4.0 https://github.com/helm/helm/labels/v4.x Label is sufficient to track 4.0 work --hide-secrets https://github.com/helm/helm/pull/9130 Discussion on the state of the PR [Shoubhik] Does not work for template but works for Helm Install [Adam] Important for this to work with templates Quick update on planning the contributor summit [Butcher] Topics: How to contribute to project, How to become core maintainer Curriculum in progress (Butcher, Bridget, Karen) Talk to CNCF to determine timeframe for sessions Talk to this (Bridget, Karen, Butcher) if you are interested in presenting, working on curriculum Assignments for next meeting Moderator: Scott Notes: Bridget Issue Triage: Butcher January 28, 2021 Assignments for this meeting Moderator: Bridget Notes: Jasper Issue Triage: Josh Dolitsky Announcements 3.5.1 milestone in progress Rebuild of 3.5.0 with new version of Go (today) with security updates No other patches Patches and updates will become 3.5.2 Learning Helm [written by Matts and Josh] Covers introduction and how to use it Commands of Helm Position within CNCF Charts Registries and plugin Appendix on differences between v2 and v3 To be published soon Discussion Storage improvement brainstorming [Joe Julian] https://github.com/stedolan/jq/issues/2257 Config and secrets can be very large Helm v3: limits to history of 10 items Exception if its failing: capture failure log Helm used to use Config maps, want Helm to be usable out of box Used secrets as it is simple and just works Alternative (CRD) may require additional permissions Alternative postgres Looking for alternatives that could fit requirement to be used out of box Etcd pulls entire dataset Split secrets into two parts Split manifest into its own object (separate namespace) Config: helm release, secret: metadata Where would Values go? Secrets stored in secrets (can be referenced) [Igor] Confirm that we are trying to simplify how to store runtime data? Alternatives: postgres service, sqllite, aggregated api server [Matt] Enterprise wanted simpler format [Matt] different than programming locally Helm is a package manager (need to keep this space) Need higher level tool to manage complexity (ansible, chef, flux helm operator) Need to make sure when we scale up we handle the simpler case and need to reduce complexity for easy Simple case easy to use with Helm, don’t want to optimize for the complex case [Igor] Just to be clear: I wasn't raising the point Helm should do more than it does, what I'm saying is there are several ways of interacting with a store, from going "secrets" to CRDs; when using CRDs there is the alternative of storing the runtime data in Etcd (with its limitations) or promote it to a cluster wide aggregated API, where the limitations of Etcd and some other complexities could be avoided. Joe to open an issue to continue the conversation to determine next step (HIP or PR) Test failure in https://github.com/helm/helm/pull/9276 - apparent mismatch between testing/mariadb 0.3.0-0565674 and testing/mariadb 0.3.0 - action needed? [Bridget] in https://app.circleci.com/pipelines/github/helm/helm/2106/workflows/fad17fdc-61dd-4558-9704-b6d930568cc6/jobs/13653 --- FAIL: TestSearchRepositoriesCmd/search_for_'maria',_expect_one_match_with_semver_begin_with_zero_development_version (0.00s) helm_test.go:61: running cmd (attempt 1): search repo maria --devel --repository-config testdata/helmhome/helm/repositories.yaml --repository-cache testdata/helmhome/helm/repository helm_test.go:67: does not match golden file testdata/output/search-semver-pre-zero-devel-release.txt [Fisher] just a test fluke - never seen it before. Likely just a rebase error. Re-running the test suite passed. Hiding secrets - is this a blocker we should resolve quickly? [Bridget] https://github.com/helm/helm/pull/9130 [Farina] Should hide secrets in log Should this be in next release as low hanging fruit [Farina] Should look into this issue [Shoubhik] Can take a look into this issue : Done [Scott] fun question: what blockers would we have to revisit the idea of installing missing CRDs from the /crds dir at the version level [Farina] What do you mean by version level? CRD capture all version info in each CRD Creating a 4.0 milestone to track any feature needing a major release [Marc] (but we should avoid a 4.0 as long as possible in my opinion) [Shoubhik] Should not signify that its coming [Farina] There could be a mismatch [Bridget] Stick with milestone 4.0 [Karena] Charts Chat - is that still active, I have a standing conflict and the notes doc was last updated in 2019 Is this still happening? [Farina] Should be cancelled. Meeting has not been held since 2019. [Farina] Meeting has been cancelled. [Karena] If people still need help with Charts should they be directed to this meeting? Direct to charts channel in community slack [Farina] Topics has been covered in this meeting or directly in issues Assignments for next meeting Moderator: Adam Reese Notes: Karena Issue Triage: Matt Farina January 21, 2021 Assignments for this meeting Moderator: Matt Farina Notes: Karena Issue Triage: Matt Butcher Announcements None this week Discussion 3.5.1- https://github.com/helm/helm/milestone/107 Patch fix milestone Updating kube libraries for 1.20.2 Maintainer doesn’t have to do the upgrades for the libraries Usually aren’t breaking Volunteer? Shoubhik will attempt If need to release Go security patch, 3.5.1 will only the security patch and 3.5.2 will be the rest Performance improvements [Farina] Index.yaml updates Previously, 8mb yaml file - slow to parse Json so much faster to parse, both in memory and operations Index.json to cut down on processing time (vs index.yaml) [Matt Fisher] Redirect? (might be a breaking change) Farina: perhaps a start - look at what’s on artifact hub. Explore further. Helm repositories with Git [Igor] Suggestion: parse tar balls on the fly - grab directly from git [Igor] Example: https://github.com/otaviof/chart-streams [Bridget] GitHub pages example: https://helm.sh/docs/topics/chart_repository/#github-pages-example [Farina] Helm is meant to be simple and like seeing people using the API [Matt Fisher] there’s a section in documentation to point to projects Nice that it demonstrates the chart repository api [Bridget] here is where you can PR in a link: https://github.com/helm/helm-www/blob/master/content/en/docs/community/related.md [Josh Dolitsky] Similar, but using plugin vs. http(s): https://github.com/aslafy-z/helm-git Storage improvement brainstorming [Joe Julian - deferring a week] Assignments for next meeting Moderator: Bridget Notes: Jasper Issue Triage: Josh Dolitsky January 14, 2021 Assignments for this meeting Moderator: Marc K Notes: Bridget Issue Triage: Shoubhik, tbd Announcements 3.5.0 released [Farina] - https://github.com/helm/helm/releases/tag/v3.5.0 Bridget to coordinate a blog post; Farina to review 3.5.1 milestone: https://github.com/helm/helm/milestone/107 (second Wed in Feb) Date for next minor release [Marc] 3.6 RC1: Monday May 17th, 2021 3.6 final release: Wednesday May 26th, 2021 Marc to update calendar Helm plugins in Artifact Hub [Farina] (for example, https://artifacthub.io/packages/helm-plugin/helm-2to3/2to3) List and search - artifact hub is like a search engine To do: add this to helm docs Discussion Dependabot recommendations (https://github.com/helm/helm/pulls/app%2Fdependabot) - what action do we want to take? [Bridget] bump k8s.io/[various] from 0.20.1 to 0.20.2 https://github.com/stretchr/testify update Older containerd issue Farina: we shouldn’t do the k8s ones through dependabot - we should do these - cherry-pick into 3.5.1 But the containerd one is a tough one - a transitive dependency we need to update - we ideally would prefer ORAS to update this The testify one could probably be merged & marked as needs-pick - may work best for 3.6 not 3.5.x Picks for patches [Farina] Marking “needs pick” and then picking them - not a long period of sitting in the branch More difficult if the main branch has diverged far from the release branch Ideally, whoever merges marks as needs pick and pushes to release branch - would make patch releases quicker Marc: we could move this towards a “make release” if this were made more consistent Butcher: now that we do releases more consistently, we can pick onto the branch sooner rather than later Marc: how about a process HIP to document this? (willing to write it but others can help) Plugin discussion for artifact hub [Butcher] Butcher: Might we want “helm plugin search”? Farina: artifact hub is API driven so external tools are entirely possible Butcher: we could do this as a feature HIP Bucket redirections [Butcher] Farina: no problem thus far KubeCon video [Bridget] Should be a sea shanty Helm 4 wishlist Date formatting [issues open already] [Bridget] Storage - too large of release storage objects bring kubernetes api to its knees [Joe Julian] Farina: we should iterate on this in an experimental fashion in v3 Could do a tool to migrate from secrets to postgres Context-specific storage options instead of env variables Joe Julian: also we read all the secrets to get metadata but just need the metadata itself Joe Thompson: 1meg request limit also is an issue Igor Sutton Lopes: can we use something other than etcd? Farina: we can’t assume people can install anywhere other than their clusters Igor: alternative backends for storage - discussion for next week Farina: with secrets we have encryption, so we have to consider that and not just push secrets to git - could be opt-in Assignments for next meeting Moderator: Farina Notes: Karena Issue Triage: Butcher January 7, 2021 Assignments for this meeting Moderator: Bridget Notes: Karena Issue Triage: Farina/Josh/Shoubhik Announcements 3.5.0 Milestone · GitHub - 3.5 RC2 (https://github.com/helm/helm/releases/tag/v3.5.0-rc.2) was cut on Wednesday Jan 6 2021, and 3.5 will be released Wednesday Jan 13 2021. Discussion We must select the date for the next minor release [Marc] Move discussion to the mailing list for consensus? [Farina] april 19-23 is release week, suggesting May 12, first week after KubeCon Europe (virtual) Tentative date: Big risk - any changes from kube release Want to make sure follow a quarterly release cadence [marc, farina] suggesting follow new kube release schedule - 3 x’s a year [farina] suggesting May 26, rc1 would be May 17 [marc] to send email to maintainer list [shoubhik] how to check api changes? Check docs, not easy question [bridget] would you like to check api questions that may affect helm? [farina] any k8s go api changes could break anything for helm Tracking changes may be more work than just fixing what’s breaking When should a patch release be cancelled? [Marc] https://github.com/helm/community/issues/160 Final point to finish HIP2 (Pre-defined release dates for Helm) https://github.com/helm/community/blob/master/hips/hip-0002.md [fisher] justification to cancel a patch release? [farina] canceled patch release because minor release (superseded) [fisher] patch release == low severity bugs that affect the smallest number of users [bridget] if within x days, judgement call If within 7 days, wait for minor release to save time for release managers Needs more discussion Asset pipeline: https://github.com/helm/helm/pull/8697/ - let’s discuss “add Asset Transparency action for GitHub releases” in regards to our CI/CD [Butcher] Asset Transparency project [butcher] if generally in favor, would like to get merged Please look at and comment so decision can be made w/i the next week Contributor Workshop [bridget] working w CNCF to schedule the workshop [Butcher] 2-block format 1 - Non-maintainer 2 - People who are interested in becoming a core maintainer Karen has already reached out to people who have done this before Timeline: Late first quarter, early second quarter Who wants to volunteer from core maintainers for Kube preso? Martin? Bridget will coordinate Assignments for next meeting Moderator: Marc Notes: Josh Issue Triage: Shoubhik (non-maintainer issues), tbd ``` ================================================ FILE: community/meeting-notes/index.mdx ================================================ --- title: Archived Meeting Notes --- Here are all of the archived Helm meeting notes prior to 2022. They are retained here for historical purposes. For current Helm dev meeting agenda and notes, see [this Google Doc](https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit?usp=sharing). import DocCardList from "@theme/DocCardList"; ================================================ FILE: community/related.md ================================================ --- title: Related Projects and Documentation description: third-party tools, plugins and documentation provided by the community! sidebar_position: 4 --- The Helm community has produced many extra tools, plugins, and documentation about Helm. We love to hear about these projects. If you have anything you'd like to add to this list, please open an [issue](https://github.com/helm/helm-www/issues) or [pull request](https://github.com/helm/helm-www/pulls). ## Helm Plugins {#helm-plugins} - [helm-adopt](https://github.com/HamzaZo/helm-adopt) - A helm v3 plugin to adopt existing k8s resources into a new generated helm chart. - [helm-cel](https://github.com/idsulik/helm-cel) - Plugin that uses Common Expression Language (CEL) to validate values. - [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) - Snapshot testing plugin for Helm charts. - [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade` as a coloured diff - [Helm Dt](https://github.com/vmware-labs/distribution-tooling-for-helm) - Plugin that helps distributing Helm charts across OCI registries and on Air gap environments - [Helm Dashboard](https://github.com/komodorio/helm-dashboard) - GUI for Helm, visualize releases and repositories, manifest diffs - [helm-gcs](https://github.com/hayorov/helm-gcs) - Plugin to manage repositories on Google Cloud Storage - [helm-git](https://github.com/aslafy-z/helm-git) - Install charts and retrieve values files from your Git repositories - [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm Charts from hiera using k8comp - [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - Update helm release metadata to replace deprecated or removed Kubernetes APIs - [helm-migrate-values](https://github.com/OctopusDeployLabs/helm-migrate-values) - Plugin to migrate user-specified values across Helm chart versions to handle breaking schema changes in `values.yaml` - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to monitor a release and rollback based on Prometheus/ElasticSearch query - [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) - Plugin for Release management, Update release values, pulls(re-creates) helm Charts from deployed releases, set helm release TTL. - [helm-s3](https://github.com/hypnoglow/helm-s3) - Helm plugin that allows to use AWS S3 as a [private] chart repository - [helm-secrets](https://github.com/jkroepke/helm-secrets) - Plugin to manage and store secrets safely (based on [sops](https://github.com/mozilla/sops)) - [helm-sigstore](https://github.com/sigstore/helm-sigstore) - Plugin for Helm to integrate the [sigstore](https://sigstore.dev/) ecosystem. Search, upload and verify signed Helm charts. - [helm-tanka](https://github.com/Duologic/helm-tanka) - A Helm plugin for rendering Tanka/Jsonnet inside Helm charts. - [hc-unit](https://github.com/xchapter7x/hcunit) - Plugin for unit testing charts locally using OPA (Open Policy Agent) & Rego - [helm-unittest](https://github.com/helm-unittest/helm-unittest) - Plugin for unit testing chart locally with YAML - [helm-val](https://github.com/HamzaZo/helm-val) - A plugin to get values from a previous release. - [helm-external-val](https://github.com/kuuji/helm-external-val) - A plugin that fetches helm values from external sources (configMaps, Secrets, etc.) - [helm-images](https://github.com/nikhilsbhat/helm-images) - Helm plugin to fetch all possible images from the chart before deployment or from a deployed release - [helm-drift](https://github.com/nikhilsbhat/helm-drift) - Helm plugin that identifies the configuration that has drifted from the Helm chart - [helm-tui](https://github.com/pidanou/helm-tui) - A light UI to manage your Helm assets without leaving the terminal We also encourage GitHub authors to use the [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) tag on their plugin repositories. ## Additional Tools Tools layered on top of Helm. - [Aptakube](https://aptakube.com) - Desktop UI for Kubernetes and Helm Releases - [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - Manage prefixed releases throughout various Kubernetes namespaces, and removes completed jobs for complex deployments - [avionix](https://github.com/zbrookle/avionix) - Python interface for generating Helm charts and Kubernetes yaml, allowing for inheritance and less duplication of code - [Botkube](https://botkube.io) - Run Helm commands directly from Slack, Discord, Microsoft Teams, and Mattermost. - [Captain](https://github.com/alauda/captain) - A Helm3 Controller using HelmRequest and Release CRD - [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from existing Kubernetes resources. - [ChartMuseum](https://github.com/helm/chartmuseum) - Helm Chart Repository with support for Amazon S3 and Google Cloud Storage - [chart-registry](https://github.com/hangyan/chart-registry) - Helm Charts Hosts on OCI Registry - [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management platform with UI dashboards for managing Helm charts and releases - ⁠[Cyclops](https://cyclops-ui.com) - Dynamic Kubernetes UI rendering based on Helm charts - [Flux](https://fluxcd.io/docs/components/helm/) - Continuous and progressive delivery from Git to Kubernetes. - [Helmfile](https://github.com/helmfile/helmfile) - Helmfile is a declarative spec for deploying helm charts - [Helmper](https://github.com/ChristofferNissen/helmper) - Helmper helps you import Helm Charts - including all OCI artifacts(images), to your own OCI registries. Helmper also facilitates security scanning and patching of OCI images. Helmper utilizes Helm, Oras, Trivy, Copacetic and Buildkitd. - [Helmsman](https://github.com/Praqma/helmsman) - Helmsman is a helm-charts-as-code tool which enables installing/upgrading/protecting/moving/deleting releases from version controlled desired state files (described in a simple TOML format) - [HULL](https://github.com/vidispine/hull) - This library chart provides a ready-to-use interface for specifying all Kubernetes objects directly in the `values.yaml`. It removes the need to write any templates for your charts and comes with many additional features to simplify Helm chart creation and usage. - [K8Studio](https://k8studio.io) - Desktop UI for Managing Kubernetes Clusters with Integrated Helm Manager. - [Konveyor Move2Kube](https://konveyor.io/move2kube/) - Generate Helm charts for your existing projects. - [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper takes a set of Helm Chart references with values (a desired state), and realizes this in a Kubernetes cluster." - [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart repositories - [Monokle](https://monokle.io) - Desktop tool for creating, debugging and deploying Kubernetes resources and Helm Charts - [Orkestra](https://azure.github.io/orkestra/) - A cloud-native Release Orchestration and Lifecycle Management (LCM) platform for a related group of Helm releases and their subcharts - [Tanka](https://tanka.dev/helm) - Grafana Tanka configures Kubernetes resources through Jsonnet with the ability to consume Helm Charts - [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - The Helm provider for HashiCorp Terraform enables lifecycle management of Helm Charts with a declarative infrastructure-as-code syntax. The Helm provider is often paired the other Terraform providers, like the Kubernetes provider, to create a common workflow across all infrastructure services. - [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin for Kubernetes and Helm ## Helm Included Platforms, distributions, and services that include Helm support. - [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client - [Jenkins X](https://jenkins-x.io/) - open source automated CI/CD for Kubernetes which uses Helm for [promoting](https://jenkins-x.io/docs/getting-started/promotion/) applications through environments via GitOps ## Misc Grab bag of useful things for Chart authors and Helm users. - [Await](https://github.com/saltside/await) - Docker image to "await" different conditions--especially useful for init containers. [More Info](https://blog.slashdeploy.com/2017/02/16/introducing-await/) ================================================ FILE: community/release_checklist.md ================================================ --- title: Maintainer Release Checklist description: Checklist for maintainers when releasing the next version of Helm. --- # A Maintainer's Guide to Releasing Helm Time for a new Helm release! As a Helm maintainer cutting a release, you are the best person to update this release checklist should your experiences vary from what's documented here. All releases will be of the form vX.Y.Z where X is the major version number, Y is the minor version number and Z is the patch release number. This project strictly follows [semantic versioning](https://semver.org/) so following this step is critical. Helm announces in advance the date of its next minor release. Every effort should be made to respect the announced date. Furthermore, when starting the release process, the date for the next release should have been selected as it will be used in the release process. These directions will cover initial configuration followed by the release process for three different kinds of releases: * Major Releases - released less frequently - have breaking changes * Minor Releases - released every 3 to 4 months - no breaking changes * Patch Releases - released monthly - do not require all steps in this guide [Initial Configuration](#initial-configuration) 1. [Create the Release Branch](#1-create-the-release-branch) 2. [Major/Minor releases: Change the Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git) 3. [Major/Minor releases: Commit and Push the Release Branch](#3-majorminor-releases-commit-and-push-the-release-branch) 4. [Major/Minor releases: Create a Release Candidate](#4-majorminor-releases-create-a-release-candidate) 5. [Major/Minor releases: Iterate on Successive Release Candidates](#5-majorminor-releases-iterate-on-successive-release-candidates) 6. [Finalize the Release](#6-finalize-the-release) 7. [Write the Release Notes](#7-write-the-release-notes) 8. [PGP Sign the downloads](#8-pgp-sign-the-downloads) 9. [Publish Release](#9-publish-release) 10. [Update Docs](#10-update-docs) 11. [Tell the Community](#11-tell-the-community) ## Initial Configuration ### Set Up Git Remote It is important to note that this document assumes that the git remote in your repository that corresponds to is named "upstream". If yours is not (for example, if you've chosen to name it "origin" or something similar instead), be sure to adjust the listed snippets for your local environment accordingly. If you are not sure what your upstream remote is named, use a command like `git remote -v` to find out. If you don't have an [upstream remote](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork) , you can add one using something like: ```shell git remote add upstream git@github.com:helm/helm.git ``` ### Set Up Environment Variables In this doc, we are going to reference a few environment variables as well, which you may want to set for convenience. For major/minor releases, use the following: ```shell export RELEASE_NAME=vX.Y.0 export RELEASE_BRANCH_NAME="release-X.Y" export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" ``` If you are creating a patch release, use the following instead: ```shell export PREVIOUS_PATCH_RELEASE=vX.Y.Z export RELEASE_NAME=vX.Y.Z+1 export RELEASE_BRANCH_NAME="release-X.Y" ``` ### Set Up Signing Key We are also going to be adding security and verification of the release process by hashing the binaries and providing signature files. We perform this using [GitHub and GPG](https://help.github.com/en/articles/about-commit-signature-verification). If you do not have GPG already setup you can follow these steps: 1. [Install GPG](https://gnupg.org/index.html) 2. [Generate GPG key](https://help.github.com/en/articles/generating-a-new-gpg-key) 3. [Add key to GitHub account](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) 4. [Set signing key in Git](https://help.github.com/en/articles/telling-git-about-your-signing-key) Once you have a signing key you need to add it to the KEYS file at the root of the repository. The instructions for adding it to the KEYS file are in the file. If you have not done so already, you need to add your public key to the keyserver network. If you use GnuPG you can follow the [instructions provided by Debian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver). ## 1. Create the Release Branch ### Major/Minor Releases Major releases are for new feature additions and behavioral changes *that break backwards compatibility*. Minor releases are for new feature additions that do not break backwards compatibility. To create a major or minor release, start by creating a `release-X.Y` branch from main. ```shell git fetch upstream git checkout upstream/main git checkout -b $RELEASE_BRANCH_NAME ``` This new branch is going to be the base for the release, which we are going to iterate upon later. Verify that a [helm/helm milestone](https://github.com/helm/helm/milestones) for the release exists on GitHub (creating it if necessary). Make sure PRs and issues for this release are in this milestone. For major & minor releases, move on to step 2: [Major/Minor releases: Change the Version Number in Git](#2-majorminor-releases-change-the-version-number-in-git). ### Patch releases Patch releases are a few critical cherry-picked fixes to existing releases. Start by creating a `release-X.Y` branch: ```shell git fetch upstream git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME ``` From here, we can cherry-pick the commits we want to bring into the patch release: ```shell # get the commits ids we want to cherry-pick git log --oneline # cherry-pick the commits starting from the oldest one, without including merge commits git cherry-pick -x ``` After the commits have been cherry picked the release branch needs to be pushed. ```shell git push upstream $RELEASE_BRANCH_NAME ``` Pushing the branch will cause the tests to run. Make sure they pass prior to creating the tag. This new tag is going to be the base for the patch release. Creating a [helm/helm milestone](https://github.com/helm/helm/milestones) is optional for patch releases. Make sure to check [GitHub Actions](https://github.com/helm/helm/actions) to see that the release passed CI before proceeding. Patch releases can skip steps 2-5 and proceed to step 6 to [Finalize the Release](#6-finalize-the-release). ## 2. Major/Minor releases: Change the Version Number in Git When doing a major or minor release, make sure to update `internal/version/version.go` with the new release version. ```shell $ git diff internal/version/version.go diff --git a/internal/version/version.go b/internal/version/version.go index 712aae64..c1ed191e 100644 --- a/internal/version/version.go +++ b/internal/version/version.go @@ -30,7 +30,7 @@ var ( // Increment major number for new feature additions and behavioral changes. // Increment minor number for bug fixes and performance enhancements. // Increment patch number for critical fixes to existing releases. - version = "v3.3" + version = "v3.4" // metadata is extra build time data metadata = "" ``` In addition to updating the version within the `version.go` file, you will also need to update corresponding tests that are using that version number. * `cmd/helm/testdata/output/version.txt` * `cmd/helm/testdata/output/version-client.txt` * `cmd/helm/testdata/output/version-client-shorthand.txt` * `cmd/helm/testdata/output/version-short.txt` * `cmd/helm/testdata/output/version-template.txt` * `pkg/chartutil/capabilities_test.go` ```shell git add . git commit -m "bump version to $RELEASE_NAME" ``` This will update it for the $RELEASE_BRANCH_NAME only. You will also need to pull this change into the main branch for when the next release is being created, as in [this example of 3.2 to 3.3](https://github.com/helm/helm/pull/8411/files), and add it to the milestone for the next release. ```shell # get the last commit id i.e. commit to bump the version git log --format="%H" -n 1 # create new branch off main git checkout main git checkout -b bump-version- # cherry pick the commit using id from first command git cherry-pick -x # commit the change git push origin bump-version- ``` ## 3. Major/Minor releases: Commit and Push the Release Branch In order for others to start testing, we can now push the release branch upstream and start the test process. ```shell git push upstream $RELEASE_BRANCH_NAME ``` Make sure to check [GitHub Actions](https://github.com/helm/helm/actions) to see that the release passed CI before proceeding. If anyone is available, let others peer-review the branch before continuing to ensure that all the proper changes have been made and all of the commits for the release are there. ## 4. Major/Minor releases: Create a Release Candidate Now that the release branch is out and ready, it is time to start creating and iterating on release candidates. ```shell git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` GitHub Actions will automatically create a tagged release image and client binary to test with. For testers, the process to start testing after GitHub Actions finishes building the artifacts involves the following steps to grab the client: linux/amd64, using /bin/bash: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz ``` darwin/amd64, using Terminal.app: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz ``` windows/amd64, using PowerShell: ```shell PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" ``` Then, unpack and move the binary to somewhere on your $PATH, or move it somewhere and add it to your $PATH (e.g. /usr/local/bin/helm for linux/macOS, C:\Program Files\helm\helm.exe for Windows). ## 5. Major/Minor releases: Iterate on Successive Release Candidates Spend several days explicitly investing time and resources to try and break helm in every possible way, documenting any findings pertinent to the release. This time should be spent testing and finding ways in which the release might have caused various features or upgrade environments to have issues, not coding. During this time, the release is in code freeze, and any additional code changes will be pushed out to the next release. During this phase, the $RELEASE_BRANCH_NAME branch will keep evolving as you will produce new release candidates. The frequency of new candidates is up to the release manager: use your best judgement taking into account the severity of reported issues, testers' availability, and the release deadline date. Generally speaking, it is better to let a release roll over the deadline than to ship a broken release. Each time you'll want to produce a new release candidate, you will start by adding commits to the branch by cherry-picking from main: ```shell git cherry-pick -x ``` You will also want to push the branch to GitHub and ensure it passes CI. After that, tag it and notify users of the new release candidate: ```shell export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` Once pushed to GitHub, check to ensure the branch with this tag builds in CI. From here on just repeat this process, continuously testing until you're happy with the release candidate. For a release candidate, we don't write the full notes, but you can scaffold out some [release notes](#7-write-the-release-notes). ## 6. Finalize the Release When you're finally happy with the quality of a release candidate, you can move on and create the real thing. Double-check one last time to make sure everything is in order, then finally push the release tag. ```shell git checkout $RELEASE_BRANCH_NAME git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" git push upstream $RELEASE_NAME ``` Verify that the release succeeded in [GitHub Actions](https://github.com/helm/helm/actions). If not, you will need to fix the release and push the release again. As the CI job will take some time to run, you can move on to writing release notes while you wait for it to complete. ## 7. Write the Release Notes We will auto-generate a changelog based on the commits that occurred during a release cycle, but it is usually more beneficial to the end-user if the release notes are hand-written by a human being/marketing team/dog. If you're releasing a major/minor release, listing notable user-facing features is usually sufficient. For patch releases, do the same, but make note of the symptoms and who is affected. The release notes should include the version and planned date of the next release. An example release note for a minor release would look like this: ```markdown ## vX.Y.Z Helm vX.Y.Z is a feature release. This release, we focused on . Users are encouraged to upgrade for the best experience. The community keeps growing, and we'd love to see you there! - Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com): - `#helm-users` for questions and just to hang out - `#helm-dev` for discussing PRs, code, and bugs - Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622) - Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0) ## Notable Changes - Kubernetes 1.16 is now supported including new manifest apiVersions - Sprig was upgraded to 2.22 ## Installation and Upgrading Download Helm X.Y. The common platform binaries are here: - [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) - [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) - [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) - [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) The [Quickstart Guide](/intro/quickstart.md) will get you going from there. For **upgrade instructions** or detailed installation notes, check the [install guide](/intro/install.mdx). You can also use a [script to install](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4) on any system with `bash`. ## What's Next - vX.Y.Z+1 will contain only bug fixes and is planned for . - vX.Y+1.0 is the next feature release and is planned for . This release will focus on ... ## Changelog - chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) - fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) ``` A partially completed set of release notes including the changelog can be created by running the following command: ```shell export VERSION="$RELEASE_NAME" export PREVIOUS_RELEASE=vX.Y.Z make clean make fetch-dist make release-notes ``` This will create a good baseline set of release notes to which you should just need to fill out the **Notable Changes** and **What's next** sections. Feel free to add your voice to the release notes; it's nice for people to think we're not all robots. You should also double check the URLs and checksums are correct in the auto-generated release notes. Once finished, go into GitHub to [helm/helm releases](https://github.com/helm/helm/releases) and edit the release notes for the tagged release with the notes written here. For target branch, set to $RELEASE_BRANCH_NAME. It is now worth getting other people to take a look at the release notes before the release is published. Send a request out to [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) for review. It is always beneficial as it can be easy to miss something. ## 8. PGP Sign the downloads While hashes provide a signature that the content of the downloads is what it was generated, signed packages provide traceability of where the package came from. To do this, run the following `make` commands: ```shell export VERSION="$RELEASE_NAME" make clean # if not already run make fetch-dist # if not already run make sign ``` This will generate ascii armored signature files for each of the files pushed by CI. All of the signature files (`*.asc`) need to be uploaded to the release on GitHub (attach binaries). ## 9. Publish Release Time to make the release official! After the release notes are saved on GitHub, the CI build is completed, and you've added the signature files to the release, you can hit "Publish" on the release. This publishes the release, listing it as "latest", and shows this release on the front page of the [helm/helm](https://github.com/helm/helm) repo. ## 10. Update Docs The [Helm website docs section](https://helm.sh/docs) lists the Helm versions for the docs. Major, minor, and patch versions need to be updated on the site. The date for the next minor release is also published on the site and must be updated. To do that create a pull request against the [helm-www repository](https://github.com/helm/helm-www). In the `config.toml` file find the proper `params.versions` section and update the Helm version, like in this example of [updating the current version](https://github.com/helm/helm-www/pull/676/files). In the same `config.toml` file, update the `params.nextversion` section. Close the [helm/helm milestone](https://github.com/helm/helm/milestones) for the release, if applicable. Update the [version skew](https://github.com/helm/helm-www/blob/main/docs/topics/version_skew.mdx) for major and minor releases. Update the release calendar [here](https://helm.sh/calendar/release): * create an entry for the next minor release with a reminder for that day at 5pm GMT * create an entry for the RC1 of the next minor release on the Monday of the week before the planned release, with a reminder for that day at 5pm GMT ## 11. Tell the Community Congratulations! You're done. Go grab yourself a $DRINK_OF_CHOICE. You've earned it. After enjoying a nice $DRINK_OF_CHOICE, go forth and announce the new release in Slack and on Twitter with a link to the [release on GitHub](https://github.com/helm/helm/releases). Optionally, write a blog post about the new release and showcase some of the new features on there! ================================================ FILE: community/release_policy.md ================================================ --- title: "Release schedule policy" description: "Describes Helm's release schedule policy." --- For the benefit of its users, Helm defines and announces release dates in advance. This document describes the policy governing Helm's release schedule. ## Release calendar A public calendar showing the upcoming Helm releases can be found [here](https://helm.sh/calendar/release). ## Semantic versioning Helm versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, following [Semantic Versioning](https://semver.org/spec/v2.0.0.html) terminology. ## Patch releases Patch releases provide users with bug fixes and security fixes. They do not contain new features. A new patch release relating to the latest minor/major release will normally be done once a month on the second Wednesday of each month. A patch release to fix a high priority regression or security issue can be done whenever needed. A scheduled patch release will be cancelled for any of the following reasons: - if there is no new content since the previous release - if the patch release date falls within one week before the first release candidate (RC1) of an upcoming minor release - if the patch release date falls within four weeks following a minor release - if a major or minor release is scheduled for the same month ## Minor releases Minor releases contain security and bug fixes as well as new features. They are backwards compatible with respect to the API and the CLI usage. To align with Kubernetes releases, a minor helm release will be done every 4 months (3 releases a year). Extra minor releases can be done if needed but will not affect the timeline of an announced future release, unless the announced release is less than 7 days away. At the same time as a release is published, the date of the next minor release will be announced and posted to Helm's main web page. ## Major releases Major releases contain breaking changes. Such releases are rare but are sometimes necessary to allow helm to continue to evolve in important new directions. Major releases can be difficult to plan. With that in mind, a final release date will only be chosen and announced once the first beta version of such a release is available. ================================================ FILE: community/stable-repo-charts-new-locations.md ================================================ --- title: Stable chart repo new locations --- ## First try Artifact Hub The canonical source for Helm charts is the [Artifact Hub](https://artifacthub.io/), an aggregator for distributed chart repos. - [Chart end users](https://github.com/helm/community/blob/main/user-profiles.md#1-application-operator) looking for charts should look there. - [Chart contributors and maintainers](https://github.com/helm/community/blob/main/user-profiles.md#2-application-distributor) – people who want to contribute features or fixes to individual chart source code, or help to maintain them – may also look there. Many existing chart maintainers list the chart source in the Artifact Hub `links` metadata, but this is optional and many do not. ## Ongoing effort to relocate charts to new repos If you read this far, this file is a continuation of an ongoing effort to [relocate charts to new repos](https://github.com/helm/charts/issues/21103). It continues to serve two needs: 1. Points end users for the now archived `stable` or `incubator` charts ([the releases prior to November 13, 2020](https://helm.sh/blog/new-location-stable-incubator-charts/)) to new chart locations, so the users can upgrade to newer and currently maintained versions of those charts. 2. Helps previous and/or potential new chart maintainers coordinate where to continue maintaining the chart source and repo automation tooling for each chart (or set of related charts) as a community. Thanks for your continuing work on Helm charts! ✨ We will maintain this file until these needs are solved in another way, or are no longer necessary to solve, whichever comes first 🤝 ## Brief history to avoid confusion When `helm/charts` stable and incubator [support plan](https://github.com/helm/charts/blob/master/README.md#status-of-the-project) and [Deprecation Timeline](https://github.com/helm/charts/blob/master/README.md#deprecation-timeline) were announced, the community (chart OWNERS, organizations, groups or individuals who want to host charts) began moving the source of those charts to new Helm repos according to the [Search of Distributed Repositories proposal](https://github.com/helm/community/blob/main/hips/archives/helm/distributed-search.md). Those archived chart releases were listed first on the (now deprecated) [Helm Hub](https://hub.helm.sh/), and now on [Artifact Hub](#first-try-artifact-hub) along with the new versions of actively maintained chart source code hosted elsewhere. The table below was moved from the now in GitHub to help the community contribute to tracking this migration through Pull Requests. ## Status of relocated charts ### Notes on updating lists below 1. List all charts: ```bash find -d stable/ -mindepth 1 -maxdepth 1 ``` 2. List all charts marked `deprecated`: ```bash grep -l 'deprecated: true' stable/*/Chart.yaml | xargs -I {} dirname {} ``` 3. Manually check each deprecated chart for status and deprecation issue link, and update applicable table and non-applicable list accordingly (apart from the flag above, the deprecation process is not consistent enough to automate this check) ### Non-applicable (purposefully deprecated) - stable/acs-engine-autoscaler - stable/ark - stable/aws-cluster-autoscaler - stable/dask-distributed - stable/gcloud-endpoints - stable/kube-lego - stable/magic-namespace - stable/mongodb-replicaset (#23747) - stable/nginx-lego - stable/rabbitmq-ha (#23746) - stable/sematext-docker-agent ### Applicable | Chart | Status | Issue/PR | | -- | -- | -- | |
  • [ ] stable/aerospike
| STATUS | URL | |
  • [ ] stable/airflow
| in progress: discussion started | https://github.com/apache/airflow/issues/10523 | |
  • [x] stable/ambassador
| done | https://github.com/datawire/ambassador-chart/issues/9 | |
  • [x] stable/anchore-engine
| done | https://github.com/helm/charts/pull/23509 | |
  • [ ] stable/apm-server
| STATUS | URL | |
  • [x] stable/artifactory
| done | https://github.com/helm/charts/pull/7627 | |
  • [x] stable/artifactory-ha
| done | https://github.com/helm/charts/pull/7627 | |
  • [ ] stable/atlantis
| STATUS | URL | |
  • [ ] stable/auditbeat
| STATUS | URL | |
  • [ ] stable/aws-iam-authenticator
| STATUS | URL | |
  • [ ] stable/bitcoind
| STATUS | URL | |
  • [ ] stable/bookstack
| STATUS | URL | |
  • [x] stable/buildkite
| done | https://github.com/helm/charts/pull/9200 | |
  • [ ] stable/burrow
| STATUS | URL | |
  • [ ] stable/centrifugo
| STATUS | URL | |
  • [ ] stable/cerebro
| STATUS | URL | |
  • [x] stable/cert-manager
| done | https://github.com/helm/charts/pull/12970 | |
  • [ ] stable/chaoskube
| STATUS | URL | |
  • [ ] stable/chartmuseum
| STATUS | URL | |
  • [x] stable/chronograf
| done | https://github.com/helm/charts/pull/21233 | |
  • [ ] stable/clamav
| STATUS | URL | |
  • [ ] stable/cloudserver
| STATUS | URL | |
  • [x] stable/cluster-autoscaler
| done | https://github.com/kubernetes/autoscaler/pull/3341 | |
  • [ ] stable/cluster-overprovisioner
| in progress | https://github.com/helm/charts/pull/23586 | |
  • [x] stable/cockroachdb
| done | https://github.com/helm/charts/pull/23000 | |
  • [ ] stable/collabora-code
| STATUS | URL | |
  • [x] stable/concourse
| done | https://github.com/helm/charts/pull/19128 | |
  • [x] stable/consul
| done | https://github.com/helm/charts/pull/22696 | |
  • [ ] stable/contour
| STATUS | URL | |
  • [ ] stable/coredns
| in progress | https://github.com/coredns/coredns/issues/3905 | |
  • [ ] stable/cosbench
| STATUS | URL | |
  • [ ] stable/coscale
| STATUS | URL | |
  • [ ] stable/couchbase-operator
| STATUS | URL | |
  • [x] stable/couchdb
| done | https://github.com/helm/charts/pull/18079 | |
  • [x] stable/dask
| done | https://github.com/helm/charts/pull/18419 | |
  • [X] stable/datadog
| done | https://github.com/helm/charts/pull/23384 | |
  • [ ] stable/dex
| STATUS | URL | |
  • [ ] stable/distributed-jmeter
| STATUS | URL | |
  • [ ] stable/distributed-tensorflow
| STATUS | URL | |
  • [x] stable/distribution
| done | https://github.com/helm/charts/pull/7627 | |
  • [x] stable/dmarc2logstash
| done | https://github.com/helm/charts/pull/22524 | |
  • [ ] stable/docker-registry
| STATUS | URL | |
  • [x] stable/dokuwiki
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/drone
| done | https://github.com/helm/charts/pull/21151 | |
  • [x] stable/drupal
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/efs-provisioner
| STATUS | URL | |
  • [x] stable/elastabot
| done | https://github.com/helm/charts/pull/22676 | |
  • [x] stable/elastalert
| done | https://github.com/helm/charts/pull/22689 | |
  • [ ] stable/elastic-stack
| STATUS | URL | |
  • [x] stable/elasticsearch
| done | https://github.com/helm/charts/pull/21955 | |
  • [ ] stable/elasticsearch-curator
| STATUS | URL | |
  • [ ] stable/elasticsearch-exporter
| STATUS | URL | |
  • [ ] stable/envoy
| STATUS | URL | |
  • [ ] stable/etcd-operator
| STATUS | URL | |
  • [ ] stable/ethereum
| STATUS | URL | |
  • [ ] stable/eventrouter
| STATUS | URL | |
  • [ ] stable/express-gateway
| STATUS | URL | |
  • [x] stable/external-dns
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/factorio
| STATUS | URL | |
  • [ ] stable/filebeat
| STATUS | URL | |
  • [ ] stable/fluent-bit
| migrated: need to deprecate chart with migration path | https://github.com/helm/charts/issues/21235 | |
  • [ ] stable/fluentd
| migrated: need to deprecate chart with migration path | https://github.com/helm/charts/issues/21235 | |
  • [x] stable/fluentd-elasticsearch
| done | https://github.com/helm/charts/pull/10354 | |
  • [x] stable/g2
| done | https://github.com/helm/charts/pull/4957 | |
  • [ ] stable/gangway
| STATUS | URL | |
  • [ ] stable/gce-ingress
| STATUS | URL | |
  • [x] stable/gcloud-sqlproxy
| done | https://github.com/helm/charts/pull/9219 | |
  • [ ] stable/gcp-night-king
| STATUS | URL | |
  • [x] stable/ghost
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/gitlab-ce
| done | https://github.com/helm/charts/pull/1876 | |
  • [x] stable/gitlab-ee
| done | https://github.com/helm/charts/pull/1876 | |
  • [ ] stable/gocd
| STATUS | URL | |
  • [ ] stable/goldpinger
| STATUS | URL | |
  • [x] stable/grafana
| done | https://github.com/helm/charts/pull/23662 | |
  • [x] stable/graphite
| done | https://github.com/helm/charts/pull/10350 | |
  • [x] stable/graylog
| done | helm/charts#24011 | |
  • [ ] stable/hackmd
| STATUS | URL | |
  • [ ] stable/hadoop
| STATUS | URL | |
  • [x] stable/hazelcast
| done | https://github.com/helm/charts/pull/22797 | |
  • [x] stable/hazelcast-jet
| done | https://github.com/helm/charts/pull/22798 | |
  • [ ] stable/heapster
| STATUS | URL | |
  • [ ] stable/heartbeat
| STATUS | URL | |
  • [x] stable/helm-exporter
| migrated: need to update README | https://github.com/helm/charts/pull/20376 | |
  • [ ] stable/hl-composer
| STATUS | URL | |
  • [ ] stable/hlf-ca
| STATUS | URL | |
  • [ ] stable/hlf-couchdb
| STATUS | URL | |
  • [ ] stable/hlf-ord
| STATUS | URL | |
  • [ ] stable/hlf-peer
| STATUS | URL | |
  • [ ] stable/hoard
| STATUS | URL | |
  • [x] stable/home-assistant
| done | https://github.com/helm/charts/pull/22745 | |
  • [ ] stable/horovod
| STATUS | URL | |
  • [ ] stable/hubot
| STATUS | URL | |
  • [ ] stable/ignite
| STATUS | URL | |
  • [ ] stable/inbucket
| STATUS | URL | |
  • [x] stable/influxdb
| done | https://github.com/influxdata/helm-charts | |
  • [ ] stable/ingressmonitorcontroller
| STATUS | URL | |
  • [ ] stable/instana-agent
| STATUS | URL | |
  • [ ] stable/ipfs
| STATUS | URL | |
  • [x] stable/jaeger-operator
| done | https://github.com/helm/charts/pull/19636 | |
  • [ ] stable/janusgraph
| STATUS | URL | |
  • [x] stable/jasperreports
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/jenkins
| done | https://github.com/helm/charts/issues/23562 | |
  • [x] stable/joomla
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/k8s-spot-rescheduler
| STATUS | URL | |
  • [ ] stable/k8s-spot-termination-handler
| STATUS | URL | |
  • [ ] stable/kafka-manager
| STATUS | URL | |
  • [ ] stable/kanister-operator
| STATUS | URL | |
  • [x] stable/kapacitor
| done | https://github.com/helm/charts/pull/21234 | |
  • [ ] stable/karma
| STATUS | URL | |
  • [ ] stable/katafygio
| STATUS | URL | |
  • [x] stable/keel
| done | https://github.com/helm/charts/pull/9514 | |
  • [x] stable/keycloak
| done | https://github.com/helm/charts/pull/13316 | |
  • [x] stable/kiam
| done | https://github.com/helm/charts/pull/17959 | |
  • [ ] stable/kibana
| in progress | https://github.com/helm/charts/pull/23844 | |
  • [x] stable/kong
| done | https://github.com/helm/charts/pull/20149 | |
  • [ ] stable/kube2iam
| in progress: conversation started | https://github.com/jtblin/kube2iam/issues/277 | |
  • [ ] stable/kube-hunter
| STATUS | URL | |
  • [ ] stable/kube-ops-view
| STATUS | URL | |
  • [ ] stable/kube-slack
| STATUS | URL | |
  • [ ] stable/kube-state-metrics
| in progress | https://github.com/kubernetes/kube-state-metrics/issues/1153 | |
  • [x] stable/kubed
| done | https://github.com/helm/charts/pull/4957 | |
  • [x] stable/kubedb
| done | https://github.com/helm/charts/pull/4957 | |
  • [x] stable/kuberhealthy
| done | https://github.com/helm/charts/pull/23919 | |
  • [x] stable/kubernetes-dashboard
| done | https://github.com/helm/charts/pull/22627 | |
  • [ ] stable/kuberos
| STATUS | URL | |
  • [x] stable/kubewatch
| done | https://github.com/helm/charts/issues/20969 | |
  • [X] stable/kured
| done | https://github.com/weaveworks/kured/pull/150 | |
  • [ ] stable/lamp
| STATUS | URL | |
  • [ ] stable/linkerd
| STATUS | URL | |
  • [ ] stable/locust
| STATUS | URL | |
  • [ ] stable/logdna-agent
| STATUS | URL | |
  • [ ] stable/logstash
| STATUS | URL | |
  • [ ] stable/luigi
| STATUS | URL | |
  • [x] stable/magento
| done | https://github.com/helm/charts/pull/14555 | |
  • [ ] stable/magic-ip-address
| STATUS | URL | |
  • [x] stable/mailhog
| done | https://github.com/helm/charts/pull/13315 | |
  • [x] stable/mariadb
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/mattermost-team-edition
| done | https://github.com/helm/charts/pull/13540 | |
  • [ ] stable/mcrouter
| STATUS | URL | |
  • [x] stable/mediawiki
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/memcached
| STATUS | URL | |
  • [ ] stable/mercure
| STATUS | URL | |
  • [ ] stable/metabase
| STATUS | URL | |
  • [x] stable/metallb
| done | https://github.com/helm/charts/pull/23486 | |
  • [ ] stable/metricbeat
| STATUS | URL | |
  • [ ] stable/metrics-server
| in progress | https://github.com/kubernetes-sigs/metrics-server/issues/572 | |
  • [ ] stable/minecraft
| STATUS | URL | |
  • [x] stable/minio
| done | https://charts.min.io | |
  • [x] stable/mission-control
| done | https://github.com/helm/charts/pull/7627 | |
  • [x] stable/mongodb
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/moodle
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/msoms
| in progress: discussion started | https://github.com/microsoft/charts/issues/19 | |
  • [ ] stable/mssql-linux
| in progress: discussion started | https://github.com/microsoft/charts/issues/19 | |
  • [ ] stable/mysql
| STATUS | URL | |
  • [x] stable/mysqldump
| done | https://github.com/helm/charts/pull/23840 | |
  • [ ] stable/namerd
| STATUS | URL | |
  • [x] stable/nats
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/neo4j
| done | https://github.com/helm/charts/pull/22437 | |
  • [ ] stable/newrelic-infrastructure
| STATUS | URL | |
  • [ ] stable/nextcloud
| done | https://github.com/helm/charts/pull/23627 | |
  • [ ] stable/nfs-client-provisioner
| STATUS | URL | |
  • [ ] stable/nfs-server-provisioner
| STATUS | URL | |
  • [x] stable/nginx-ingress
| done | https://github.com/helm/charts/pull/22823 | |
  • [ ] stable/nginx-ldapauth-proxy
| STATUS | URL | |
  • [ ] stable/node-problem-detector
| STATUS | URL | |
  • [x] stable/node-red
| done | https://github.com/helm/charts/pull/22739 | |
  • [ ] stable/oauth2-proxy
| STATUS | URL | |
  • [x] stable/odoo
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/opa
| STATUS | URL | |
  • [x] stable/opencart
| done | https://github.com/helm/charts/issues/20969 | |
  • [X] stable/openebs
| done | https://github.com/helm/charts/pull/22860 | |
  • [ ] stable/openiban
| STATUS | URL | |
  • [ ] stable/openldap
| STATUS | URL | |
  • [ ] stable/openvpn
| STATUS | URL | |
  • [x] stable/orangehrm
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/osclass
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/owncloud
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/pachyderm
| STATUS | URL | |
  • [x] stable/parse
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/percona
| STATUS | URL | |
  • [ ] stable/percona-xtradb-cluster
| STATUS | URL | |
  • [x] stable/pgadmin
| done | https://github.com/helm/charts/pull/21275 | |
  • [x] stable/phabricator
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/phpbb
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/phpmyadmin
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/pomerium
| STATUS | URL | |
  • [x] stable/postgresql
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/prestashop
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/presto
| STATUS | URL | |
  • [ ] stable/prisma
| STATUS | URL | |
  • [x] stable/prometheus
| done | https://github.com/helm/charts/pull/23692 | |
  • [x] stable/prometheus-adapter
| done | https://github.com/helm/charts/pull/23694 | |
  • [x] stable/prometheus-blackbox-exporter
| done | https://github.com/helm/charts/pull/23695 | |
  • [x] stable/prometheus-cloudwatch-exporter
| done | https://github.com/helm/charts/pull/23696 | |
  • [x] stable/prometheus-consul-exporter
| done | https://github.com/helm/charts/pull/23697 | |
  • [x] stable/prometheus-couchdb-exporter
| done | https://github.com/helm/charts/pull/23698 | |
  • [x] stable/prometheus-mongodb-exporter
| done | https://github.com/helm/charts/pull/23699 | |
  • [x] stable/prometheus-mysql-exporter
| done | https://github.com/helm/charts/pull/23700 | |
  • [x] stable/prometheus-nats-exporter
| done | https://github.com/helm/charts/pull/23701 | |
  • [x] stable/prometheus-node-exporter
| done | https://github.com/helm/charts/pull/23702 | |
  • [x] stable/prometheus-operator
| done | https://github.com/helm/charts/pull/23738 | |
  • [x] stable/prometheus-postgres-exporter
| done | https://github.com/helm/charts/pull/23703 | |
  • [x] stable/prometheus-pushgateway
| done | https://github.com/helm/charts/pull/23704 | |
  • [x] stable/prometheus-rabbitmq-exporter
| done | https://github.com/helm/charts/pull/23705 | |
  • [x] stable/prometheus-redis-exporter
| done | https://github.com/helm/charts/pull/23706 | |
  • [x] stable/prometheus-snmp-exporter
| done | https://github.com/helm/charts/pull/23708 | |
  • [x] stable/prometheus-to-sd
| done | https://github.com/helm/charts/pull/23707 | |
  • [ ] stable/quassel
| STATUS | URL | |
  • [x] stable/rabbitmq
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/redis
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/redis-ha
| STATUS | URL | |
  • [x] stable/redmine
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/reloader
| done | https://github.com/helm/charts/pull/23595 | |
  • [ ] stable/rethinkdb
| STATUS | URL | |
  • [ ] stable/risk-advisor
| STATUS | URL | |
  • [ ] stable/rocketchat
| STATUS | URL | |
  • [ ] stable/rookout
| STATUS | URL | |
  • [ ] stable/sapho
| STATUS | URL | |
  • [ ] stable/satisfy
| STATUS | URL | |
  • [ ] stable/schema-registry-ui
| STATUS | URL | |
  • [ ] stable/sealed-secrets
| Discussion ongoing - not settled | https://github.com/bitnami-labs/sealed-secrets/issues/389 | |
  • [x] stable/searchlight
| done | https://github.com/helm/charts/pull/4957 | |
  • [ ] stable/selenium
| STATUS | URL | |
  • [ ] stable/sematext-agent
| STATUS | URL | |
  • [ ] stable/sensu
| STATUS | URL | |
  • [ ] stable/sentry
| STATUS | URL | |
  • [ ] stable/seq
| STATUS | URL | |
  • [x] stable/signalfx-agent
| done | https://github.com/helm/charts/pull/13586 | |
  • [ ] stable/signalsciences
| STATUS | URL | |
  • [ ] stable/socat-tunneller
| STATUS | URL | |
  • [x] stable/sonarqube
| done | https://github.com/helm/charts/pull/21007 | |
  • [x] stable/sonatype-nexus
| done | https://github.com/helm/charts/pull/21255 | |
  • [ ] stable/spark
| STATUS | URL | |
  • [ ] stable/spark-history-server
| STATUS | URL | |
  • [ ] stable/spartakus
| STATUS | URL | |
  • [ ] stable/spinnaker
| STATUS | URL | |
  • [ ] stable/spotify-docker-gc
| STATUS | URL | |
  • [ ] stable/spring-cloud-data-flow
| STATUS | URL | |
  • [ ] stable/stackdriver-exporter
| STATUS | URL | |
  • [x] stable/stash
| done | https://github.com/helm/charts/pull/4957 | |
  • [ ] stable/stellar-core
| STATUS | URL | |
  • [ ] stable/stolon
| STATUS | URL | |
  • [x] stable/suitecrm
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/sumokube
| STATUS | URL | |
  • [ ] stable/sumologic-fluentd
| STATUS | URL | |
  • [ ] stable/superset
| STATUS | URL | |
  • [x] stable/swift
| done | https://github.com/helm/charts/pull/4957 | |
  • [ ] stable/sysdig
| STATUS | URL | |
  • [x] stable/telegraf
| done | https://github.com/helm/charts/pull/21232 | |
  • [ ] stable/tensorflow-notebook
| STATUS | URL | |
  • [ ] stable/tensorflow-serving
| STATUS | URL | |
  • [ ] stable/terracotta
| STATUS | URL | |
  • [x] stable/testlink
| done | https://github.com/helm/charts/issues/20969 | |
  • [ ] stable/tomcat
| STATUS | URL | |
  • [ ] stable/traefik
| STATUS | URL | |
  • [ ] stable/uchiwa
| STATUS | URL | |
  • [ ] stable/unbound
| STATUS | URL | |
  • [x] stable/unifi
| done | https://github.com/helm/charts/pull/23714 | |
  • [ ] stable/vault-operator
| STATUS | URL | |
  • [x] stable/velero
| done | https://github.com/helm/charts/pull/19719 | |
  • [ ] stable/verdaccio
| STATUS | URL | |
  • [x] stable/voyager
| done | https://github.com/helm/charts/pull/4957 | |
  • [ ] stable/vsphere-cpi
| STATUS | URL | |
  • [x] stable/wavefront
| done | https://github.com/helm/charts/pull/20055 | |
  • [ ] stable/weave-cloud
| STATUS | URL | |
  • [ ] stable/weave-scope
| in progress: discussion underway | https://github.com/weaveworks/scope/issues/3807 | |
  • [x] stable/wordpress
| done | https://github.com/helm/charts/issues/20969 | |
  • [x] stable/xray
| done | https://github.com/helm/charts/pull/7627 | |
  • [ ] stable/zeppelin
| STATUS | URL | |
  • [ ] stable/zetcd
| STATUS | URL | ================================================ FILE: community/user-profiles.md ================================================ --- title: User Profiles --- The purpose of this document is to aid in the development of Helm features by evaluating Helm features against those who will be using them. When considering requirements and implementation solutions it's useful look at who uses Helm to have a better understanding of how something should work. The Helm user profiles describe the different types of users and contributors to Helm along with the order of priority they have relative to each other. The ordering is because nothing can share the exact same priority and we want to convey that. ## Preface * What's described here are user profiles as opposed to [personas](https://en.wikipedia.org/wiki/Persona#In_user_experience_design). Personas are example actors rather than general categories. * Kubernetes Cluster Operators are out of scope for this document. A cluster operator is one who manages the operation of a Kubernetes cluster that applications can run in. ## Profiles Profiles describe a type of role a user may perform. A real person may perform more than one role and have more than one profile apply to them. How this mapping works between profiles and real people can vary between companies and other organizations. To handle this variation we focus on the user profiles rather than how they may map to people in these different organizations. ### 1. Application Operator Application operators take an application and operate it within a Kubernetes cluster. For example, the operation of WordPress and MySQL. This is not to be confused with the role of a Kubernetes cluster operator (see the preface above for more detail). ### 2. Application Distributor Distributors are people who package an application for someone else to operate. Examples of this would be those who maintainer [Community Charts](https://github.com/kubernetes/charts) such as WordPress and Datadog. ### 3. Application Developer An application developer writes the software for an application. They are typically not concerned with where the application is running as applications can often be run more than one environment (e.g., many applications can be run in a virtual machine or a container). Examples of this include the developers of WordPress and MySQL. ### 4. Supporting Tool Developer Supporting tool developers build tools adjacent to Helm such as a linter, Helm plugin, or even kubectl. These are developers building complementary things that can be used along with Helm. ### 5. Helm Developer Helm developers are those who develop Helm itself. That includes core maintainers along with anyone else who fixes a bug or updates docs. Generally speaking, the developers of Helm consider the end users above themselves when looking at requirements and implementation strategies. ## Profiles Not In Scope Some user profiles are not considered in scope for Helm. That does not mean a real person who multiple profiles apply to is not considered a supported user. Rather, the out of scope profiles apply to roles that are not typically supported. ## Cluster Operator A cluster operator stands up and operates a Kubernetes cluster. This includes elements such as the control plane, nodes, and elements in the stack below these. It does not include applications running on Kubernetes as those are handled by the _Application Operator_ profile. ================================================ FILE: docs/_v4-in-progress.mdx ================================================ :::warning This page has not yet been updated for Helm 4. Some of the content might be inaccurate or not applicable to Helm 4. For more information about the Helm 4 new features, improvements, and breaking changes, see [Helm 4 Overview](/overview.md). ::: ================================================ FILE: docs/changelog.md ================================================ --- sidebar_position: 2 sidebar_label: Full Changelog --- # Helm 4 Full Changelog **Scope**: 290 PRs from (`v4.0.0-rc.1`) compared to `v3.19.0` **v4-only**: 257 PRs (33 backported to v3 excluded) See the [Overview](/overview.md) for an actionable summary of these changes. ## New Features New features in Helm 4 that were not backported to v3 | PR | Date | Author | Title | |---|---|---|---| | #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations | | #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise | | #31338 | 2025-10-21 | yzewei | Add loongarch64 support | | #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version | | #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml | | #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions | | #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context | | #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default | | #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions | | #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` | | #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command | | #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build | | #31217 | 2025-09-01 | scottrigby | BREAKING CHANGE: [HIP-0026] Move Postrenderer to a plugin type | | #31196 | 2025-08-31 | scottrigby | BREAKING CHANGE: [HIP-0026] Remove unnecessary file i/o operations from signing and verifying | | #31176 | 2025-08-30 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin packaging, signing, and verification | | #31194 | 2025-08-28 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Plugin extism/v1 runtime | | #30812 | 2025-08-27 | gjenkins8 | BREAKING CHANGE: HIP-0023: Helm support server-side apply | | #31174 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin tarball support for HTTP and local installers | | #31172 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin OCI installer | | #31146 | 2025-08-23 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin types and plugin apiVersion v1 | | #31145 | 2025-08-22 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin runtime interface | | #31142 | 2025-08-21 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Move pkg/plugin -> internal/plugin | | #31030 | 2025-08-14 | gjenkins8 | BREAKING CHANGE: HIP-0023: Kube client support server-side apply | | #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator | | #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues | | #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory | | #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses | | #31057 | 2025-07-18 | danilobuerger | Pass credentials when either chart repo or repo dont specify a port but it matches the default port of that scheme | | #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist | | #31011 | 2025-07-17 | yalosev | feature: add labels to metadata | | #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory | | #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks | | #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates | | #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions | | #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs | | #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 | | #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states | | #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog | | #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher | | #13617 | 2025-02-27 | AustinAbro321 | BREAKING CHANGE: Refactor cmd/helm to allow library usage | | #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output | | #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files | | #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value | | #30294 | 2025-02-19 | Zhanweelee | Supports json arguments | | #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext | | #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable | ## Bug Fixes Fixes in Helm 4 that were not backported to v3 | PR | Date | Author | Title | |---|---|---|---| | #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds | | #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package | | #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema | | #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy | | #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails | | #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil | | #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing | | #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle | | #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script | | #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test | | #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names | | #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided | | #31334 | 2025-09-30 | fleaz | Fix typo in bug-report issue template | | #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name | | #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) | | #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command | | #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 | | #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry | | #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message | | #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close | | #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count | | #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow | | #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr | | #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references | | #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests | | #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` | | #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config | | #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI | | #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata | | #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race | | #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 | | #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory | | #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test | | #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands | | #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors | | #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. | | #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex | | #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex | | #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME | | #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex | | #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources | | #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration | | #30884 | 2025-05-21 | mattfarina | Reverting fix "renders int as float" | | #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache | | #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message | | #30842 | 2025-05-15 | ayushontop | Fix : No repository is not an error,use the helm repo list command ,if there is no repository,it should not be an error #30606 | | #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors | | #30803 | 2025-04-25 | mattfarina | Fixing windows build | | #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test | | #30777 | 2025-04-23 | ryanhockstad | fix: null merge | | #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies | | #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly | | #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks | | #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. | | #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors | | #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test | | #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain | | #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts | | #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering | | #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured | | #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified | | #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos | | #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR | | #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` | | #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin | | #13425 | 2024-11-15 | MathieuCesbron | Fix typo "re-use" to "reuse" | ## Refactor/Cleanup Code quality improvements and modernization | PR | Date | Author | Title | |---|---|---|---| | #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions | | #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed | | #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage | | #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor | | #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format | | #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go | | #31391 | 2025-10-15 | TerryHowe | chore: rename test registry | | #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature | | #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up | | #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object | | #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file | | #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces | | #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions | | #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations | | #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify | | #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema | | #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check | | #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer | | #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment | | #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command | | #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning | | #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory | | #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option | | #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions | | #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser | | #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed | | #31287 | 2025-09-16 | miledxz | improve fileutil test coverage | | #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder | | #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix | | #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient | | #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package | | #31225 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move lint pkg to be part of each chart version | | #31220 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: refactor: utilize `pluginTypesIndex` for config unmarshalling | | #31219 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: Remove 'SetupPluginEnv' | | #31216 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move to versioned packages | | #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value | | #31218 | 2025-09-01 | gjenkins8 | BREAKING CHANGE: Remove legacy Command/Hooks from v1 Subprocess (#23) | | #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace | | #31178 | 2025-08-28 | mattfarina | Add content cache to helm env | | #31165 | 2025-08-22 | mattfarina | BREAKING CHANGE: Initial addition of content based cache | | #13629 | 2025-08-22 | gjenkins8 | BREAKING CHANGE: Rename 'atomic' -> 'rollback-on-failure' | | #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 | | #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf | | #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment | | #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code | | #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go | | #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. | | #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable | | #30982 | 2025-08-05 | gjenkins8 | BREAKING CHANGE: Rename 'force' to 'force-replace' | | #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module | | #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 | | #31081 | 2025-07-25 | mattfarina | BREAKING CHANGE: Initial addition of v3 charts | | #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' | | #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq | | #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging | | #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file | | #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' | | #31023 | 2025-07-03 | gjenkins8 | BREAKING CHANGE: Remove deprecated '--create-pods' flag | | #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher | | #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable | | #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter | | #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings | | #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost | | #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter | | #30863 | 2025-05-16 | mattfarina | Adding test for list command | | #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling | | #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage | | #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter | | #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica | | #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code | | #13460 | 2025-04-23 | justenstall | fix: replace "github.com/pkg/errors" with stdlib "errors" package | | #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error | | #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency | | #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` | | #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points | | #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules | | #30749 | 2025-04-11 | mattfarina | BREAKING CHANGE: Removing the alpine test chart | | #30686 | 2025-04-11 | mattfarina | BREAKING CHANGE: Remove deprecated code | | #30736 | 2025-04-09 | robertsirc | manually updating go.mod file | | #13458 | 2025-04-05 | thudi | BREAKING CHANGE: #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation | | #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client | | #30603 | 2025-03-21 | robertsirc | converting inline log to slog | | #30699 | 2025-03-21 | mattfarina | Error when failed repo update. | | #30592 | 2025-02-28 | robertsirc | changing from log to slog | | #30589 | 2025-02-26 | mattfarina | BREAKING CHANGE: Move pkg/release to pkg/release/v1 to support v3 charts | | #30586 | 2025-02-25 | mattfarina | BREAKING CHANGE: Move pkg/chart to pkg/chart/v2 to prepare for v3 charts | | #30585 | 2025-02-25 | robertsirc | removing old apis | | #30580 | 2025-02-24 | mattfarina | BREAKING CHANGE: Move pkg/releaseutil to pkg/release/util | | #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times | | #30567 | 2025-02-21 | mattfarina | BREAKING CHANGE: Moving chartutil to chart/util | | #30566 | 2025-02-21 | robertsirc | remove unused config.go | | #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors | | #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra | | #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code | | #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern | | #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` | | #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions | | #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint | | #13494 | 2025-01-18 | gjenkins8 | BREAKING CHANGE: Remove deprecated `repo add --no-update` flag | | #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code | | #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` | | #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function | | #13611 | 2025-01-07 | mattfarina | BREAKING CHANGE: Updating the internal version to v4 | | #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions | | #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` | | #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` | | #13573 | 2024-12-27 | mattfarina | BREAKING CHANGE: Updating to helm.sh/helm/v4 | | #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags | ## Other Infrastructure and project management improvements | PR | Date | Author | Title | |---|---|---|---| | #31197 | 2025-09-03 | tzchenxixi | chore: fix function name | | #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow | | #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow | | #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link | | #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go | | #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README | | #31002 | 2025-06-26 | curlwget | chore: fix function in comment | | #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates | | #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment | | #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 | | #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` | | #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge | | #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action | | #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration | | #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure | | #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow | | #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer | | #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment | | #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking | | #30693 | 2025-03-20 | linghuying | chore: make function comment match function name | | #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net | | #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' | | #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link | | #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info | | #30497 | 2025-02-12 | robertsirc | adding-my-key | | #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm | | #13653 | 2025-01-23 | petercover | chore: fix some comments | | #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation | | #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch | | #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo | | #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list | | #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules | | #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md | | #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore | | #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 | ## v4 Changes Also Backported to v3 These PRs were included in v4 but were also backported to v3 releases ### New Features (Backported) | PR | Date | Author | Title | |---|---|---|---| | #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format | | #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template | | #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error | | #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling | | #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest | | #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields | | #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support | | #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output | ### Bug Fixes (Backported) | PR | Date | Author | Title | |---|---|---|---| | #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 | | #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() | | #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth | | #31115 | 2025-08-18 | banjoh | fix: use username and password if provided | | #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning | | #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls | | #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original | | #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 | | #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport | | #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login | | #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet | | #30905 | 2025-05-23 | robertsirc | forward porting 30902 | | #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store | | #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 | | #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure | | #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs | | #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match | ### Refactor/Cleanup (Backported) | PR | Date | Author | Title | |---|---|---|---| | #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 | | #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 | | #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 | | #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 | | #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface | ### Other (Backported) | PR | Date | Author | Title | |---|---|---|---| | #30775 | 2025-04-19 | benoittgt | Bump toml | | #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float | | #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 | ================================================ FILE: docs/chart_best_practices/conventions.md ================================================ --- title: General Conventions description: General conventions for charts. sidebar_position: 1 --- This part of the Best Practices Guide explains general conventions. ## Chart Names Chart names must be lower case letters and numbers. Words _may_ be separated with dashes (-): Examples: ``` drupal nginx-lego aws-cluster-autoscaler ``` Neither uppercase letters nor underscores can be used in chart names. Dots should not be used in chart names. ## Version Numbers Wherever possible, Helm uses [SemVer 2](https://semver.org) to represent version numbers. (Note that Docker image tags do not necessarily follow SemVer, and are thus considered an unfortunate exception to the rule.) When SemVer versions are stored in Kubernetes labels, we conventionally alter the `+` character to an `_` character, as labels do not allow the `+` sign as a value. ## Formatting YAML YAML files should be indented using _two spaces_ (and never tabs). ## Usage of the Words Helm and Chart There are a few conventions for using the words _Helm_ and _helm_. - _Helm_ refers to the project as a whole - `helm` refers to the client-side command - The term `chart` does not need to be capitalized, as it is not a proper noun - However, `Chart.yaml` does need to be capitalized because the file name is case sensitive When in doubt, use _Helm_ (with an uppercase 'H'). ## Chart templates and namespaces Avoid defining the `namespace` property in the `metadata` section of your chart templates. The namespace to apply rendered templates to should be specified in the call to a Kubernetes client via the flag like `--namespace`. Helm is rendering your templates as-is and sending them off to the Kubernetes client, whether it be Helm itself or another program (kubectl, flux, spinnaker, etc). ================================================ FILE: docs/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: How to handle creating and using CRDs. sidebar_position: 7 --- This section of the Best Practices Guide deals with creating and using Custom Resource Definition objects. When working with Custom Resource Definitions (CRDs), it is important to distinguish two different pieces: - There is a declaration of a CRD. This is the YAML file that has the kind `CustomResourceDefinition` - Then there are resources that _use_ the CRD. Say a CRD defines `foo.example.com/v1`. Any resource that has `apiVersion: example.com/v1` and kind `Foo` is a resource that uses the CRD. ## Install a CRD Declaration Before Using the Resource Helm is optimized to load as many resources into Kubernetes as fast as possible. By design, Kubernetes can take an entire set of manifests and bring them all online (this is called the reconciliation loop). But there's a difference with CRDs. For a CRD, the declaration must be registered before any resources of that CRDs kind(s) can be used. And the registration process sometimes takes a few seconds. ### Method 1: Let `helm` Do It For You With the arrival of Helm 3, we removed the old `crd-install` hooks for a more simple methodology. There is now a special directory called `crds` that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a `helm install` for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the `--skip-crds` flag. #### Some caveats (and explanations) There is no support at this time for upgrading or deleting CRDs using Helm. This was an explicit decision after much community discussion due to the danger for unintentional data loss. Furthermore, there is currently no community consensus around how to handle CRDs and their lifecycle. As this evolves, Helm will add support for those use cases. The `--dry-run` flag of `helm install` and `helm upgrade` is not currently supported for CRDs. The purpose of "Dry Run" is to validate that the output of the chart will actually work if sent to the server. But CRDs are a modification of the server's behavior. Helm cannot install the CRD on a dry run, so the discovery client will not know about that Custom Resource (CR), and validation will fail. You can alternatively move the CRDs to their own chart or use `helm template` instead. Another important point to consider in the discussion around CRD support is how the rendering of templates is handled. One of the distinct disadvantages of the `crd-install` method used in Helm 2 was the inability to properly validate charts due to changing API availability (a CRD is actually adding another available API to your Kubernetes cluster). If a chart installed a CRD, `helm` no longer had a valid set of API versions to work against. This is also the reason behind removing templating support from CRDs. With the new `crds` method of CRD installation, we now ensure that `helm` has completely valid information about the current state of the cluster. ### Method 2: Separate Charts Another way to do this is to put the CRD definition in one chart, and then put any resources that use that CRD in _another_ chart. In this method, each chart must be installed separately. However, this workflow may be more useful for cluster operators who have admin access to a cluster ================================================ FILE: docs/chart_best_practices/dependencies.mdx ================================================ --- title: Dependencies description: Covers best practices for Chart dependencies. sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" This section of the guide covers best practices for `dependencies` declared in `Chart.yaml`. ## Versions Where possible, use version ranges instead of pinning to an exact version. The suggested default is to use a patch-level version match: ```yaml version: ~1.2.3 ``` This will match version `1.2.3` and any patches to that release. In other words, `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0` For the complete version matching syntax, please see the [semver documentation](https://github.com/Masterminds/semver#checking-version-constraints). ### Prerelease versions The above versioning constraints will not match on pre-release versions. For example `version: ~1.2.3` will match `version: ~1.2.4` but not `version: ~1.2.3-1`. The following provides a pre-release as well as patch-level matching: ```yaml version: ~1.2.3-0 ``` ### Repository URLs Where possible, use `https://` repository URLs, followed by `http://` URLs. If the repository has been added to the repository index file, the repository name can be used as an alias of URL. Use `alias:` or `@` followed by repository names. File URLs (`file://...`) are considered a "special case" for charts that are assembled by a fixed deployment pipeline. When using [downloader plugins](/topics/plugins.mdx#downloader-plugins) the URL scheme will be specific to the plugin. Note, a user of the chart will need to have a plugin supporting the scheme installed to update or build the dependency. Helm cannot perform dependency management operations on the dependency when the `repository` field is left blank. In that case Helm will assume the dependency is in a sub-directory of the `charts` folder with the name being the same as the `name` property for the dependency. ## Conditions and Tags Conditions or tags should be added to any dependencies that _are optional_. Note that by default a `condition` is `true`. The preferred form of a condition is: ```yaml condition: somechart.enabled ``` Where `somechart` is the chart name of the dependency. When multiple subcharts (dependencies) together provide an optional or swappable feature, those charts should share the same tags. For example, if both `nginx` and `memcached` together provide performance optimizations for the main app in the chart, and are required to both be present when that feature is enabled, then they should both have a tags section like this: ```yaml tags: - webaccelerator ``` This allows a user to turn that feature on and off with one tag. ================================================ FILE: docs/chart_best_practices/index.mdx ================================================ --- title: Best Practices sidebar: true sidebar_position: 4 --- # The Chart Best Practices Guide This guide covers the Helm Team's considered best practices for creating charts. It focuses on how charts should be structured. We focus primarily on best practices for charts that may be publicly deployed. We know that many charts are for internal-use only, and authors of such charts may find that their internal interests override our suggestions here. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/chart_best_practices/labels.md ================================================ --- title: Labels and Annotations description: Covers best practices for using labels and annotations in your Chart. sidebar_position: 5 --- This part of the Best Practices Guide discusses the best practices for using labels and annotations in your chart. ## Is it a Label or an Annotation? An item of metadata should be a label under the following conditions: - It is used by Kubernetes to identify this resource - It is useful to expose to operators for the purpose of querying the system. For example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that operators can conveniently find all of the instances of a particular chart to use. If an item of metadata is not used for querying, it should be set as an annotation instead. Helm hooks are always annotations. ## Standard Labels The following table defines common labels that Helm charts use. Helm itself never requires that a particular label be present. Labels that are marked REC are recommended, and _should_ be placed onto a chart for global consistency. Those marked OPT are optional. These are idiomatic or commonly in use, but are not relied upon frequently for operational purposes. Name|Status|Description -----|------|---------- `app.kubernetes.io/name` | REC | This should be the app name, reflecting the entire app. Usually `{{ template "name" . }}` is used for this. This is used by many Kubernetes manifests, and is not Helm-specific. `helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Helm. `app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application. `app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | This is a common label for marking the different roles that pieces may play in an application. For example, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | When multiple charts or pieces of software are used together to make one application. For example, application software and a database to produce a website. This can be set to the top level application being supported. You can find more information on the Kubernetes labels, prefixed with `app.kubernetes.io`, in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: docs/chart_best_practices/pods.md ================================================ --- title: Pods and PodTemplates description: Discusses formatting the Pod and PodTemplate portions in Chart manifests. sidebar_position: 6 --- This part of the Best Practices Guide discusses formatting the Pod and PodTemplate portions in chart manifests. The following (non-exhaustive) list of resources use PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images A container image should use a fixed tag or the SHA of the image. It should not use the tags `latest`, `head`, `canary`, or other tags that are designed to be "floating". Images _may_ be defined in the `values.yaml` file to make it easy to swap out images. ```yaml image: {{ .Values.redisImage | quote }} ``` An image and a tag _may_ be defined in `values.yaml` as two separate fields: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing the following in your `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` And `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Similarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is not defined at all. If you want a value other than `IfNotPresent`, simply update the value in `values.yaml` to your desired value. ## PodTemplates Should Declare Selectors All PodTemplate sections should specify a selector. For example: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` This is a good practice because it makes the relationship between the set and the pod. But this is even more important for sets like Deployment. Without this, the _entire_ set of labels is used to select matching pods, and this will break if you use labels that change, like version or release date. ================================================ FILE: docs/chart_best_practices/rbac.md ================================================ --- title: Role-Based Access Control description: Discusses the creation and formatting of RBAC resources in Chart manifests. sidebar_position: 8 --- This part of the Best Practices Guide discusses the creation and formatting of RBAC resources in chart manifests. RBAC resources are: - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## YAML Configuration RBAC and ServiceAccount configuration should happen under separate keys. They are separate things. Splitting these two concepts out in the YAML disambiguates them and makes this clearer. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` This structure can be extended for more complex charts that require multiple ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC Resources Should be Created by Default `rbac.create` should be a boolean value controlling whether RBAC resources are created. The default should be `true`. Users who wish to manage RBAC access controls themselves can set this value to `false` (in which case see below). ## Using RBAC Resources `serviceAccount.name` should be set to the name of the ServiceAccount to be used by access-controlled resources created by the chart. If `serviceAccount.create` is true, then a ServiceAccount with this name should be created. If the name is not set, then a name is generated using the `fullname` template, If `serviceAccount.create` is false, then it should not be created, but it should still be associated with the same resources so that manually-created RBAC resources created later that reference it will function correctly. If `serviceAccount.create` is false and the name is not specified, then the default ServiceAccount is used. The following helper template should be used for the ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: docs/chart_best_practices/templates.md ================================================ --- title: Templates description: A closer look at best practices surrounding templates. sidebar_position: 3 --- This part of the Best Practices Guide focuses on templates. ## Structure of `templates/` The `templates/` directory should be structured as follows: - Template files should have the extension `.yaml` if they produce YAML output. The extension `.tpl` may be used for template files that produce no formatted content. - Template file names should use dashed notation (`my-example-configmap.yaml`), not camelcase. - Each resource definition should be in its own template file. - Template file names should reflect the resource kind in the name. e.g. `foo-pod.yaml`, `bar-svc.yaml` ## Names of Defined Templates Defined templates (templates created inside a `{{ define }} ` directive) are globally accessible. That means that a chart and all of its subcharts will have access to all of the templates created with `{{ define }}`. For that reason, _all defined template names should be namespaced._ Correct: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorrect: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` It is highly recommended that new charts are created via `helm create` command as the template names are automatically defined as per this best practice. ## Formatting Templates Templates should be indented using _two spaces_ (never tabs). Template directives should have whitespace after the opening braces and before the closing braces: Correct: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorrect: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Templates should chomp whitespace where possible: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Blocks (such as control structures) may be indented to indicate flow of the template code. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` However, since YAML is a whitespace-oriented language, it is often not possible for code indentation to follow that convention. ## Whitespace in Generated Templates It is preferable to keep the amount of whitespace in generated templates to a minimum. In particular, numerous blank lines should not appear adjacent to each other. But occasional empty lines (particularly between logical sections) is fine. This is best: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` This is okay: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` But this should be avoided: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Comments (YAML Comments vs. Template Comments) Both YAML and Helm Templates have comment markers. YAML comments: ```yaml # This is a comment type: sprocket ``` Template Comments: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` Template comments should be used when documenting features of a template, such as explaining a defined template: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Inside of templates, YAML comments may be used when it is useful for Helm users to (possibly) see the comments during debugging. ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` The comment above is visible when the user runs `helm install --debug`, while comments specified in `{{- /* */}}` sections are not. Beware of adding `#` YAML comments on template sections containing Helm values that may be required by certain template functions. For example, if `required` function is introduced to the above example, and `maxMem` is unset, then a `#` YAML comment will introduce a rendering error. Correct: `helm template` does not render this block ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Incorrect: `helm template` returns `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Review [Debugging Templates](/chart_template_guide/debugging.md) for another example of this behavior of how YAML comments are left intact. ## Use of JSON in Templates and Template Output YAML is a superset of JSON. In some cases, using a JSON syntax can be more readable than other YAML representations. For example, this YAML is closer to the normal YAML method of expressing lists: ```yaml arguments: - "--dirname" - "/foo" ``` But it is easier to read when collapsed into a JSON list style: ```yaml arguments: ["--dirname", "/foo"] ``` Using JSON for increased legibility is good. However, JSON syntax should not be used for representing more complex constructs. When dealing with pure JSON embedded inside of YAML (such as init container configuration), it is of course appropriate to use the JSON format. ================================================ FILE: docs/chart_best_practices/values.md ================================================ --- title: Values description: Focuses on how you should structure and use your values. sidebar_position: 2 --- This part of the best practices guide covers using values. In this part of the guide, we provide recommendations on how you should structure and use your values, with focus on designing a chart's `values.yaml` file. ## Naming Conventions Variable names should begin with a lowercase letter, and words should be separated with camelcase: Correct: ```yaml chicken: true chickenNoodleSoup: true ``` Incorrect: ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` Note that all of Helm's built-in variables begin with an uppercase letter to easily distinguish them from user-defined values: `.Release.Name`, `.Capabilities.KubeVersion`. ## Flat or Nested Values YAML is a flexible format, and values may be nested deeply or flattened. Nested: ```yaml server: name: nginx port: 80 ``` Flat: ```yaml serverName: nginx serverPort: 80 ``` In most cases, flat should be favored over nested. The reason for this is that it is simpler for template developers and users. For optimal safety, a nested value must be checked at every level: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` For every layer of nesting, an existence check must be done. But for flat configuration, such checks can be skipped, making the template easier to read and use. ``` {{ default "none" .Values.serverName }} ``` When there are a large number of related variables, and at least one of them is non-optional, nested values may be used to improve readability. ## Make Types Clear YAML's type coercion rules are sometimes counterintuitive. For example, `foo: false` is not the same as `foo: "false"`. Large integers like `foo: 12345678` will get converted to scientific notation in some cases. The easiest way to avoid type conversion errors is to be explicit about strings, and implicit about everything else. Or, in short, _quote all strings_. Often, to avoid the integer casting issues, it is advantageous to store your integers as strings as well, and use `{{ int $value }}` in the template to convert from a string back to an integer. In most cases, explicit type tags are respected, so `foo: !!string 1234` should treat `1234` as a string. _However_, the YAML parser consumes tags, so the type data is lost after one parse. ## Consider How Users Will Use Your Values There are three potential sources of values: - A chart's `values.yaml` file - A values file supplied by `helm install -f` or `helm upgrade -f` - The values passed to a `--set` or `--set-string` flag on `helm install` or `helm upgrade` When designing the structure of your values, keep in mind that users of your chart may want to override them via either the `-f` flag or with the `--set` option. Since `--set` is more limited in expressiveness, the first guidelines for writing your `values.yaml` file is _make it easy to override from `--set`_. For this reason, it's often better to structure your values file using maps. Difficult to use with `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` The above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5, accessing the port on foo is `--set servers[0].port=80`. Not only is it harder for the user to figure out, but it is prone to errors if at some later time the order of the `servers` is changed. Easy to use: ```yaml servers: foo: port: 80 bar: port: 81 ``` Accessing foo's port is much more obvious: `--set servers.foo.port=80`. ## Document `values.yaml` Every defined property in `values.yaml` should be documented. The documentation string should begin with the name of the property that it describes, and then give at least a one-sentence description. Incorrect: ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` Correct: ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation, and will enable documentation tools to reliably correlate doc strings with the parameters they describe. ================================================ FILE: docs/chart_template_guide/accessing_files.md ================================================ --- title: Accessing Files Inside Templates description: How to access files from within a template. sidebar_position: 10 --- In the previous section we looked at several ways to create and access named templates. This makes it easy to import one template from within another template. But sometimes it is desirable to import a _file that is not a template_ and inject its contents without sending the contents through the template renderer. Helm provides access to files through the `.Files` object. Before we get going with the template examples, though, there are a few things to note about how this works: - It is okay to add extra files to your Helm chart. These files will be bundled. Be careful, though. Charts must be smaller than 1M because of the storage limitations of Kubernetes objects. - Some files cannot be accessed through the `.Files` object, usually for security reasons. - Files in `templates/` cannot be accessed. - Files excluded using `.helmignore` cannot be accessed. - Files outside of a Helm application [subchart](/chart_template_guide/subcharts_and_globals.md), including those of the parent, cannot be accessed - Charts do not preserve UNIX mode information, so file-level permissions will have no impact on the availability of a file when it comes to the `.Files` object. - [Basic example](#basic-example) - [Path helpers](#path-helpers) - [Glob patterns](#glob-patterns) - [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions) - [Encoding](#encoding) - [Lines](#lines) ## Basic example With those caveats behind, let's write a template that reads three files into our ConfigMap. To get started, we will add three files to the chart, putting all three directly inside of the `mychart/` directory. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Each of these is a simple TOML file (think old-school Windows INI files). We know the names of these files, so we can use a `range` function to loop through them and inject their contents into our ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` This ConfigMap uses several of the techniques discussed in previous sections. For example, we create a `$files` variable to hold a reference to the `.Files` object. We also use the `tuple` function to create a list of files that we loop through. Then we print each file name (`{{ . }}: |-`) followed by the contents of the file `{{ $files.Get . }}`. Running this template will produce a single ConfigMap with the contents of all three files: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Path helpers When working with files, it can be very useful to perform some standard operations on the file paths themselves. To help with this, Helm imports many of the functions from Go's [path](https://golang.org/pkg/path/) package for your use. They are all accessible with the same names as in the Go package, but with a lowercase first letter. For example, `Base` becomes `base`, etc. The imported functions are: - Base - Dir - Ext - IsAbs - Clean ## Glob patterns As your chart grows, you may find you have a greater need to organize your files more, and so we provide a `Files.Glob(pattern string)` method to assist in extracting certain files with all the flexibility of [glob patterns](https://godoc.org/github.com/gobwas/glob). `.Glob` returns a `Files` type, so you may call any of the `Files` methods on the returned object. For example, imagine the directory structure: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` You have multiple options with Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Or ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap and Secrets utility functions (Available Helm 2.0.2 and after) It is very common to want to place file content into both ConfigMaps and Secrets, for mounting into your pods at run time. To help with this, we provide a couple utility methods on the `Files` type. For further organization, it is especially useful to use these methods in conjunction with the `Glob` method. Given the directory structure from the [Glob](#glob-patterns) example above: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Encoding You can import a file and have the template base-64 encode it to ensure successful transmission: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` The above will take the same `config1.toml` file we used before and encode it: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Lines Sometimes it is desirable to access each line of a file in your template. We provide a convenient `Lines` method for this. You can loop through `Lines` using a `range` function: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` There is no way to pass files external to the chart during `helm install`. So if you are asking users to supply data, it must be loaded using `helm install -f` or `helm install --set`. This discussion wraps up our dive into the tools and techniques for writing Helm templates. In the next section we will see how you can use one special file, `templates/NOTES.txt`, to send post-installation instructions to the users of your chart. ================================================ FILE: docs/chart_template_guide/builtin_objects.md ================================================ --- title: Built-in Objects description: Built-in objects available to templates. sidebar_position: 3 --- Objects are passed into a template from the template engine. And your code can pass objects around (we'll see examples when we look at the `with` and `range` statements). There are even a few ways to create new objects within your templates, like with the `tuple` function we'll see later. Objects can be simple, and have just one value. Or they can contain other objects or functions. For example, the `Release` object contains several objects (like `Release.Name`) and the `Files` object has a few functions. In the previous section, we use `{{ .Release.Name }}` to insert the name of a release into a template. `Release` is one of the top-level objects that you can access in your templates. - `Release`: This object describes the release itself. It has several objects inside of it: - `Release.Name`: The release name - `Release.Namespace`: The namespace to be released into (if the manifest doesn’t override) - `Release.IsUpgrade`: This is set to `true` if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to `true` if the current operation is an install. - `Release.Revision`: The revision number for this release. On install, this is 1, and it is incremented with each upgrade and rollback. - `Release.Service`: The service that is rendering the present template. On Helm, this is always `Helm`. - `Values`: Values passed into the template from the `values.yaml` file and from user-supplied files. By default, `Values` is empty. - `Chart`: The contents of the `Chart.yaml` file. Any data in `Chart.yaml` will be accessible here. For example `{{ .Chart.Name }}-{{ .Chart.Version }}` will print out the `mychart-0.1.0`. - The available fields are listed in the [Charts Guide](/topics/charts.mdx#the-chartyaml-file) - `Subcharts`: This provides access to the scope (.Values, .Charts, .Releases etc.) of subcharts to the parent. For example `.Subcharts.mySubChart.myValue` to access the `myValue` in the `mySubChart` chart. - `Files`: This provides access to all non-special files in a chart. While you cannot use it to access templates, you can use it to access other files in the chart. See the section [Accessing Files](/chart_template_guide/accessing_files.md) for more. - `Files.Get` is a function for getting a file by name (`.Files.Get config.ini`) - `Files.GetBytes` is a function for getting the contents of a file as an array of bytes instead of as a string. This is useful for things like images. - `Files.Glob` is a function that returns a list of files whose names match the given shell glob pattern. - `Files.Lines` is a function that reads a file line-by-line. This is useful for iterating over each line in a file. - `Files.AsSecrets` is a function that returns the file bodies as Base 64 encoded strings. - `Files.AsConfig` is a function that returns file bodies as a YAML map. - `Capabilities`: This provides information about what capabilities the Kubernetes cluster supports. - `Capabilities.APIVersions` is a set of versions. - `Capabilities.APIVersions.Has $version` indicates whether a version (e.g., `batch/v1`) or resource (e.g., `apps/v1/Deployment`) is available on the cluster. - `Capabilities.KubeVersion` and `Capabilities.KubeVersion.Version` is the Kubernetes version. - `Capabilities.KubeVersion.Major` is the Kubernetes major version. - `Capabilities.KubeVersion.Minor` is the Kubernetes minor version. - `Capabilities.HelmVersion` is the object containing the Helm Version details, it is the same output of `helm version`. - `Capabilities.HelmVersion.Version` is the current Helm version in semver format. - `Capabilities.HelmVersion.GitCommit` is the Helm git sha1. - `Capabilities.HelmVersion.GitTreeState` is the state of the Helm git tree. - `Capabilities.HelmVersion.GoVersion` is the version of the Go compiler used. - `Template`: Contains information about the current template that is being executed - `Template.Name`: A namespaced file path to the current template (e.g. `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`). The built-in values always begin with a capital letter. This is in keeping with Go's naming convention. When you create your own names, you are free to use a convention that suits your team. Some teams, like many whose charts you may see on [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choose to use only initial lower case letters in order to distinguish local names from those built-in. In this guide, we follow that convention. ================================================ FILE: docs/chart_template_guide/control_structures.md ================================================ --- title: Flow Control description: A quick overview on the flow structure within templates. sidebar_position: 7 --- Control structures (called "actions" in template parlance) provide you, the template author, with the ability to control the flow of a template's generation. Helm's template language provides the following control structures: - `if`/`else` for creating conditional blocks - `with` to specify a scope - `range`, which provides a "for each"-style loop In addition to these, it provides a few actions for declaring and using named template segments: - `define` declares a new named template inside of your template - `template` imports a named template - `block` declares a special kind of fillable template area In this section, we'll talk about `if`, `with`, and `range`. The others are covered in the "Named Templates" section later in this guide. ## If/Else The first control structure we'll look at is for conditionally including blocks of text in a template. This is the `if`/`else` block. The basic structure for a conditional looks like this: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Notice that we're now talking about _pipelines_ instead of values. The reason for this is to make it clear that control structures can execute an entire pipeline, not just evaluate a value. A pipeline is evaluated as _false_ if the value is: - a boolean false - a numeric zero - an empty string - a `nil` (empty or null) - an empty collection (`map`, `slice`, `tuple`, `dict`, `array`) Under all other conditions, the condition is true. Let's add a simple conditional to our ConfigMap. We'll add another setting if the drink is set to coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Since we commented out `drink: coffee` in our last example, the output should not include a `mug: "true"` flag. But if we add that line back into our `values.yaml` file, the output should look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Controlling Whitespace While we're looking at conditionals, we should take a quick look at the way whitespace is controlled in templates. Let's take the previous example and format it to be a little easier to read: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Initially, this looks good. But if we run it through the template engine, we'll get an unfortunate result: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` What happened? We generated incorrect YAML because of the whitespacing above. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` is incorrectly indented. Let's simply out-dent that one line, and re-run: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` When we sent that, we'll get YAML that is valid, but still looks a little funny: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Notice that we received a few empty lines in our YAML. Why? When the template engine runs, it _removes_ the contents inside of `{{` and `}}`, but it leaves the remaining whitespace exactly as is. YAML ascribes meaning to whitespace, so managing the whitespace becomes pretty important. Fortunately, Helm templates have a few tools to help. First, the curly brace syntax of template declarations can be modified with special characters to tell the template engine to chomp whitespace. `{{- ` (with the dash and space added) indicates that whitespace should be chomped left, while ` -}}` means whitespace to the right should be consumed. _Be careful! Newlines are whitespace!_ > Make sure there is a space between the `-` and the rest of your directive. > `{{- 3 }}` means "trim left whitespace and print 3" while `{{-3 }}` means > "print -3". Using this syntax, we can modify our template to get rid of those new lines: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Just for the sake of making this point clear, let's adjust the above, and substitute an `*` for each whitespace that will be deleted following this rule. An `*` at the end of the line indicates a newline character that would be removed ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Keeping that in mind, we can run our template through Helm and see the result: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Be careful with the chomping modifiers. It is easy to accidentally do things like this: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` That will produce `food: "PIZZA"mug: "true"` because it consumed newlines on both sides. > For the details on whitespace control in templates, see the [Official Go > template documentation](https://godoc.org/text/template) Finally, sometimes it's easier to tell the template system how to indent for you instead of trying to master the spacing of template directives. For that reason, you may sometimes find it useful to use the `indent` function (`{{ indent 2 "mug:true" }}`). ## Modifying scope using `with` The next control structure to look at is the `with` action. This controls variable scoping. Recall that `.` is a reference to _the current scope_. So `.Values` tells the template to find the `Values` object in the current scope. The syntax for `with` is similar to a simple `if` statement: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Scopes can be changed. `with` can allow you to set the current scope (`.`) to a particular object. For example, we've been working with `.Values.favorite`. Let's rewrite our ConfigMap to alter the `.` scope to point to `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Note that this example omits the `mug` output from the previous exercise to focus on `with` scoping. The `with` block only executes if `.Values.favorite` is not empty, so a separate outer `if` guard is not needed. Notice that now we can reference `.drink` and `.food` without qualifying them. That is because the `with` statement sets `.` to point to `.Values.favorite`. The `.` is reset to its previous scope after `{{ end }}`. But here's a note of caution! Inside of the restricted scope, you will not be able to access the other objects from the parent scope using `.`. This, for example, will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` It will produce an error because `Release.Name` is not inside of the restricted scope for `.`. However, if we swap the last two lines, all will work as expected because the scope is reset after `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Or, we can use `$` for accessing the object `Release.Name` from the parent scope. `$` is mapped to the root scope when template execution begins and it does not change during template execution. The following would work as well: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` After looking at `range`, we will take a look at template variables, which offer one solution to the scoping issue above. ## Looping with the `range` action Many programming languages have support for looping using `for` loops, `foreach` loops, or similar functional mechanisms. In Helm's template language, the way to iterate through a collection is to use the `range` operator. To start, let's add a list of pizza toppings to our `values.yaml` file: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Now we have a list (called a `slice` in templates) of `pizzaToppings`. We can modify our template to print this list into our ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` We can use `$` for accessing the list `Values.pizzaToppings` from the parent scope. `$` is mapped to the root scope when template execution begins and it does not change during template execution. The following would work as well: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Let's take a closer look at the `toppings:` list. The `range` function will "range over" (iterate through) the `pizzaToppings` list. But now something interesting happens. Just like `with` sets the scope of `.`, so does a `range` operator. Each time through the loop, `.` is set to the current pizza topping. That is, the first time, `.` is set to `mushrooms`. The second iteration it is set to `cheese`, and so on. We can send the value of `.` directly down a pipeline, so when we do `{{ . | title | quote }}`, it sends `.` to `title` (title case function) and then to `quote`. If we run this template, the output will be: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Now, in this example we've done something tricky. The `toppings: |-` line is declaring a multi-line string. So our list of toppings is actually not a YAML list. It's a big string. Why would we do this? Because the data in ConfigMaps `data` is composed of key/value pairs, where both the key and the value are simple strings. To understand why this is the case, take a look at the [Kubernetes ConfigMap docs](https://kubernetes.io/docs/concepts/configuration/configmap/). For us, though, this detail doesn't matter much. > The `|-` marker in YAML takes a multi-line string. This can be a useful > technique for embedding big blocks of data inside of your manifests, as > exemplified here. Sometimes it's useful to be able to quickly make a list inside of your template, and then iterate over that list. Helm templates have a function to make this easy: `tuple`. In computer science, a tuple is a list-like collection of fixed size, but with arbitrary data types. This roughly conveys the way a `tuple` is used. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` The above will produce this: ```yaml sizes: |- - small - medium - large ``` In addition to lists and tuples, `range` can be used to iterate over collections that have a key and a value (like a `map` or `dict`). We'll see how to do that in the next section when we introduce template variables. ================================================ FILE: docs/chart_template_guide/data_types.md ================================================ --- title: "Appendix: Go Data Types and Templates" description: A quick overview on variables in templates. sidebar_position: 16 --- The Helm template language is implemented in the strongly typed Go programming language. For that reason, variables in templates are _typed_. For the most part, variables will be exposed as one of the following types: - string: A string of text - bool: a `true` or `false` - int: An integer value (there are also 8, 16, 32, and 64 bit signed and unsigned variants of this) - float64: a 64-bit floating point value (there are also 8, 16, and 32 bit varieties of this) - a byte slice (`[]byte`), often used to hold (potentially) binary data - struct: an object with properties and methods - a slice (indexed list) of one of the previous types - a string-keyed map (`map[string]interface{}`) where the value is one of the previous types There are many other types in Go, and sometimes you will have to convert between them in your templates. The easiest way to debug an object's type is to pass it through `printf "%T"` in a template, which will print the type. Also see the `typeOf` and `kindOf` functions. ================================================ FILE: docs/chart_template_guide/debugging.md ================================================ --- title: Debugging Templates description: Troubleshooting charts that are failing to deploy. sidebar_position: 13 --- Debugging templates can be tricky because the rendered templates are sent to the Kubernetes API server, which may reject the YAML files for reasons other than formatting. There are a few commands that can help you debug. - `helm lint` is your go-to tool for verifying that your chart follows best practices - `helm template --debug` will test rendering chart templates locally. - `helm install --dry-run --debug` will also render your chart locally without installing it, but will also check if conflicting resources are already running on the cluster. Setting `--dry-run=server` will additionally execute any `lookup` in your chart towards the server. - `helm get manifest`: This is a good way to see what templates are installed on the server. When your YAML is failing to parse, but you want to see what is generated, one easy way to retrieve the YAML is to comment out the problem section in the template, and then re-run `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` The above will be rendered and returned with the comments intact: ```yaml apiVersion: v2 # some: problem section # "bar" ``` This provides a quick way of viewing the generated content without YAML parse errors blocking. ================================================ FILE: docs/chart_template_guide/function_list.mdx ================================================ --- title: Template Function List description: A list of template functions available in Helm sidebar_position: 6 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm includes many template functions you can take advantage of in templates. They are listed here and broken down by the following categories: * [Cryptographic and Security](#cryptographic-and-security-functions) * [Date](#date-functions) * [Dictionaries](#dictionaries-and-dict-functions) * [Encoding](#encoding-functions) * [File Path](#file-path-functions) * [Kubernetes and Chart](#kubernetes-and-chart-functions) * [Logic and Flow Control](#logic-and-flow-control-functions) * [Lists](#lists-and-list-functions) * [Math](#math-functions) * [Float Math](#float-math-functions) * [Network](#network-functions) * [Reflection](#reflection-functions) * [Regular Expressions](#regular-expressions) * [Semantic Versions](#semantic-version-functions) * [String](#string-functions) * [Type Conversion](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## Logic and Flow Control Functions Helm includes numerous logic and control flow functions including [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), and [required](#required). ### and Returns the boolean AND of two or more arguments (the first empty argument, or the last argument). ``` and .Arg1 .Arg2 ``` ### or Returns the boolean OR of two or more arguments (the first non-empty argument, or the last argument). ``` or .Arg1 .Arg2 ``` ### not Returns the boolean negation of its argument. ``` not .Arg ``` ### eq Returns the boolean equality of the arguments (e.g., Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Returns the boolean inequality of the arguments (e.g., Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Returns a boolean true if the first argument is less than the second. False is returned otherwise (e.g., Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Returns a boolean true if the first argument is less than or equal to the second. False is returned otherwise (e.g., Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Returns a boolean true if the first argument is greater than the second. False is returned otherwise (e.g., Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Returns a boolean true if the first argument is greater than or equal to the second. False is returned otherwise (e.g., Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default To set a simple default value, use `default`: ``` default "foo" .Bar ``` In the above, if `.Bar` evaluates to a non-empty value, it will be used. But if it is empty, `foo` will be returned instead. The definition of "empty" depends on type: - Numeric: 0 - String: "" - Lists: `[]` - Dicts: `{}` - Boolean: `false` - And always `nil` (aka null) For structs, there is no definition of empty, so a struct will never return the default. ### required Specify values that must be set with `required`: ``` required "A valid foo is required!" .Bar ``` If `.Bar` is empty or not defined (see [default](#default) on how this is evaluated), the template will not render and will return the error message supplied instead. ### empty The `empty` function returns `true` if the given value is considered empty, and `false` otherwise. The empty values are listed in the `default` section. ``` empty .Foo ``` Note that in Go template conditionals, emptiness is calculated for you. Thus, you rarely need `if not empty .Foo`. Instead, just use `if .Foo`. ### fail Unconditionally returns an empty `string` and an `error` with the specified text. This is useful in scenarios where other conditionals have determined that template rendering should fail. ``` fail "Please accept the end user license agreement" ``` ### coalesce The `coalesce` function takes a list of values and returns the first non-empty one. ``` coalesce 0 1 2 ``` The above returns `1`. This function is useful for scanning through multiple variables or values: ``` coalesce .name .parent.name "Matt" ``` The above will first check to see if `.name` is empty. If it is not, it will return that value. If it _is_ empty, `coalesce` will evaluate `.parent.name` for emptiness. Finally, if both `.name` and `.parent.name` are empty, it will return `Matt`. ### ternary The `ternary` function takes two values, and a test value. If the test value is true, the first value will be returned. If the test value is empty, the second value will be returned. This is similar to the ternary operator in C and other programming languages. #### true test value ``` ternary "foo" "bar" true ``` or ``` true | ternary "foo" "bar" ``` The above returns `"foo"`. #### false test value ``` ternary "foo" "bar" false ``` or ``` false | ternary "foo" "bar" ``` The above returns `"bar"`. ## String Functions Helm includes the following string functions: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), and [wrapWith](#wrapwith). ### print Returns a string from the combination of its parts. ``` print "Matt has " .Dogs " dogs" ``` Types that are not strings are converted to strings where possible. Note, when two arguments next to each other are not strings a space is added between them. ### println Works the same way as [print](#print) but adds a new line at the end. ### printf Returns a string based on a formatting string and the arguments to pass to it in order. ``` printf "%s has %d dogs." .Name .NumberDogs ``` The placeholder to use depends on the type for the argument being passed in. This includes: General purpose: * `%v` the value in a default format * when printing dicts, the plus flag (%+v) adds field names * `%%` a literal percent sign; consumes no value Boolean: * `%t` the word true or false Integer: * `%b` base 2 * `%c` the character represented by the corresponding Unicode code point * `%d` base 10 * `%o` base 8 * `%O` base 8 with 0o prefix * `%q` a single-quoted character literal safely escaped * `%x` base 16, with lower-case letters for a-f * `%X` base 16, with upper-case letters for A-F * `%U` Unicode format: U+1234; same as "U+%04X" Floating-point and complex constituents: * `%b` decimal less scientific notation with exponent a power of two, e.g. -123456p-78 * `%e` scientific notation, e.g. -1.234456e+78 * `%E` scientific notation, e.g. -1.234456E+78 * `%f` decimal point but no exponent, e.g. 123.456 * `%F` synonym for %f * `%g` %e for large exponents, %f otherwise. * `%G` %E for large exponents, %F otherwise * `%x` hexadecimal notation (with decimal power of two exponent), e.g. -0x1.23abcp+20 * `%X` upper-case hexadecimal notation, e.g. -0X1.23ABCP+20 String and slice of bytes (treated equivalently with these verbs): * `%s` the uninterpreted bytes of the string or slice * `%q` a double-quoted string safely escaped * `%x` base 16, lower-case, two characters per byte * `%X` base 16, upper-case, two characters per byte Slice: * `%p` address of 0th element in base 16 notation, with leading 0x ### trim The `trim` function removes white space from both sides of a string: ``` trim " hello " ``` The above produces `hello` ### trimAll Removes the given characters from the front and back of a string: ``` trimAll "$" "$5.00" ``` The above returns `5.00` (as a string). ### trimPrefix Trim just the prefix from a string: ``` trimPrefix "-" "-hello" ``` The above returns `hello` ### trimSuffix Trim just the suffix from a string: ``` trimSuffix "-" "hello-" ``` The above returns `hello` ### lower Convert the entire string to lowercase: ``` lower "HELLO" ``` The above returns `hello` ### upper Convert the entire string to uppercase: ``` upper "hello" ``` The above returns `HELLO` ### title Convert to title case: ``` title "hello world" ``` The above returns `Hello World` ### untitle Remove title casing. `untitle "Hello World"` produces `hello world`. ### repeat Repeat a string multiple times: ``` repeat 3 "hello" ``` The above returns `hellohellohello` ### substr Get a substring from a string. It takes three parameters: - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` The above returns `hello` ### nospace Remove all whitespace from a string. ``` nospace "hello w o r l d" ``` The above returns `helloworld` ### trunc Truncate a string ``` trunc 5 "hello world" ``` The above produces `hello`. ``` trunc -5 "hello world" ``` The above produces `world`. ### abbrev Truncate a string with ellipses (`...`) Parameters: - max length - the string ``` abbrev 5 "hello world" ``` The above returns `he...`, since it counts the width of the ellipses against the maximum length. ### abbrevboth Abbreviate both sides: ``` abbrevboth 5 10 "1234 5678 9123" ``` the above produces `...5678...` It takes: - left offset - max length - the string ### initials Given multiple words, take the first letter of each word and combine. ``` initials "First Try" ``` The above returns `FT` ### randAlphaNum, randAlpha, randNumeric, and randAscii These four functions generate cryptographically secure (uses ```crypto/rand```) random strings, but with different base character sets: - `randAlphaNum` uses `0-9a-zA-Z` - `randAlpha` uses `a-zA-Z` - `randNumeric` uses `0-9` - `randAscii` uses all printable ASCII characters Each of them takes one parameter: the integer length of the string. ``` randNumeric 3 ``` The above will produce a random string with three digits. ### wrap Wrap text at a given column count: ``` wrap 80 $someText ``` The above will wrap the string in `$someText` at 80 columns. ### wrapWith `wrapWith` works as `wrap`, but lets you specify the string to wrap with. (`wrap` uses `\n`) ``` wrapWith 5 "\t" "Hello World" ``` The above produces `Hello World` (where the whitespace is an ASCII tab character) ### contains Test to see if one string is contained inside of another: ``` contains "cat" "catch" ``` The above returns `true` because `catch` contains `cat`. ### hasPrefix and hasSuffix The `hasPrefix` and `hasSuffix` functions test whether a string has a given prefix or suffix: ``` hasPrefix "cat" "catch" ``` The above returns `true` because `catch` has the prefix `cat`. ### quote and squote These functions wrap a string in double quotes (`quote`) or single quotes (`squote`). ### cat The `cat` function concatenates multiple strings together into one, separating them with spaces: ``` cat "hello" "beautiful" "world" ``` The above produces `hello beautiful world` ### indent The `indent` function indents every line in a given string to the specified indent width. This is useful when aligning multi-line strings: ``` indent 4 $lots_of_text ``` The above will indent every line of text by 4 space characters. ### nindent The `nindent` function is the same as the indent function, but prepends a new line to the beginning of the string. ``` nindent 4 $lots_of_text ``` The above will indent every line of text by 4 space characters and add a new line to the beginning. ### replace Perform simple string replacement. It takes three arguments: - string to replace - string to replace with - source string ``` "I Am Henry VIII" | replace " " "-" ``` The above will produce `I-Am-Henry-VIII` ### plural Pluralize a string. ``` len $fish | plural "one anchovy" "many anchovies" ``` In the above, if the length of the string is 1, the first argument will be printed (`one anchovy`). Otherwise, the second argument will be printed (`many anchovies`). The arguments are: - singular string - plural string - length integer NOTE: Helm does not currently support languages with more complex pluralization rules. And `0` is considered a plural because the English language treats it as such (`zero anchovies`). ### snakecase Convert string from camelCase to snake_case. ``` snakecase "FirstName" ``` This above will produce `first_name`. ### camelcase Convert string from snake_case to CamelCase ``` camelcase "http_server" ``` This above will produce `HttpServer`. ### kebabcase Convert string from camelCase to kebab-case. ``` kebabcase "FirstName" ``` This above will produce `first-name`. ### swapcase Swap the case of a string using a word based algorithm. Conversion algorithm: - Upper case character converts to Lower case - Title case character converts to Lower case - Lower case character after Whitespace or at start converts to Title case - Other Lower case character converts to Upper case - Whitespace is defined by unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` This above will produce `tHIS iS a.tEST`. ### shuffle Shuffle a string. ``` shuffle "hello" ``` The above will randomize the letters in `hello`, perhaps producing `oelhl`. ## Type Conversion Functions The following type conversion functions are provided by Helm: - `atoi`: Convert a string to an integer. - `float64`: Convert to a `float64`. - `int`: Convert to an `int` at the system's width. - `int64`: Convert to an `int64`. - `toDecimal`: Convert a unix octal to a `int64`. - `toString`: Convert to a string. - `toStrings`: Convert a list, slice, or array to a list of strings. - `toJson` (`mustToJson`): Convert list, slice, array, dict, or object to JSON. - `toPrettyJson` (`mustToPrettyJson`): Convert list, slice, array, dict, or object to indented JSON. - `toRawJson` (`mustToRawJson`): Convert list, slice, array, dict, or object to JSON with HTML characters unescaped. - `fromYaml`: Convert a YAML string to an object. - `fromJson`: Convert a JSON string to an object. - `fromJsonArray`: Convert a JSON array to a list. - `toYaml`: Convert list, slice, array, dict, or object to indented yaml, can be used to copy chunks of yaml from any source. This function is equivalent to GoLang yaml.Marshal function, see docs here: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Convert list, slice, array, dict, or object to indented yaml. Equivalent to `toYaml` but will additionally indent lists by 2 spaces. - `toToml` (`mustToToml`): Convert list, slice, array, dict, or object to toml, can be used to copy chunks of toml from any source. - `fromYamlArray`: Convert a YAML array to a list. Only `atoi` requires that the input be a specific type. The others will attempt to convert from any type to the destination type. For example, `int64` can convert floats to ints, and it can also convert strings to ints. ### toStrings Given a list-like collection, produce a slice of strings. ``` list 1 2 3 | toStrings ``` The above converts `1` to `"1"`, `2` to `"2"`, and so on, and then returns them as a list. ### toDecimal Given a unix octal permission, produce a decimal. ``` "0777" | toDecimal ``` The above converts `0777` to `511` and returns the value as an int64. ### toJson, mustToJson The `toJson` function encodes an item into a JSON string. If the item cannot be converted to JSON the function will return an empty string. `mustToJson` will return an error in case the item cannot be encoded in JSON. ``` toJson .Item ``` The above returns JSON string representation of `.Item`. ### toPrettyJson, mustToPrettyJson The `toPrettyJson` function encodes an item into a pretty (indented) JSON string. ``` toPrettyJson .Item ``` The above returns indented JSON string representation of `.Item`. ### toRawJson, mustToRawJson The `toRawJson` function encodes an item into JSON string with HTML characters unescaped. ``` toRawJson .Item ``` The above returns unescaped JSON string representation of `.Item`. ### fromYaml The `fromYaml` function takes a YAML string and returns an object that can be used in templates. `File at: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson The `fromJson` function takes a JSON string and returns an object that can be used in templates. `File at: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray The `fromJsonArray` function takes a JSON Array and returns a list that can be used in templates. `File at: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty The `toYaml` and `toYamlPretty` functions encode an object (list, slice, array, dict, or object) into an indented YAML string. > Note that `toYamlPretty` is functionally equivalent but will output YAML with additional indents for list elements ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray The `fromYamlArray` function takes a YAML Array and returns a list that can be used in templates. `File at: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toToml, mustToToml The `toToml` function encodes an item into a TOML string. If the item cannot be converted to TOML the function will return an empty string. `mustToToml` will return an error in case the item cannot be encoded in TOML. ``` toToml .Item ``` The above returns TOML string representation of `.Item`. ## Regular Expressions Helm includes the following regular expression functions: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Returns true if the input string contains any match of the regular expression. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` The above produces `true` `regexMatch` panics if there is a problem and `mustRegexMatch` returns an error to the template engine if there is a problem. ### regexFindAll, mustRegexFindAll Returns a slice of all matches of the regular expression in the input string. The last parameter n determines the number of substrings to return, where -1 means return all matches ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` The above produces `[2 4 6 8]` `regexFindAll` panics if there is a problem and `mustRegexFindAll` returns an error to the template engine if there is a problem. ### regexFind, mustRegexFind Return the first (left most) match of the regular expression in the input string ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` The above produces `d1` `regexFind` panics if there is a problem and `mustRegexFind` returns an error to the template engine if there is a problem. ### regexReplaceAll, mustRegexReplaceAll Returns a copy of the input string, replacing matches of the Regexp with the replacement string replacement. Inside string replacement, $ signs are interpreted as in Expand, so for instance $1 represents the text of the first submatch. The first argument is ``, second is ``, and third is ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` The above produces `-W-xxW-` `regexReplaceAll` panics if there is a problem and `mustRegexReplaceAll` returns an error to the template engine if there is a problem. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Returns a copy of the input string, replacing matches of the Regexp with the replacement string replacement. The replacement string is substituted directly, without using Expand. The first argument is ``, second is ``, and third is ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` The above produces `-${1}-${1}-` `regexReplaceAllLiteral` panics if there is a problem and `mustRegexReplaceAllLiteral` returns an error to the template engine if there is a problem. ### regexSplit, mustRegexSplit Slices the input string into substrings separated by the expression and returns a slice of the substrings between those expression matches. The last parameter `n` determines the number of substrings to return, where `-1` means return all matches ``` regexSplit "z+" "pizza" -1 ``` The above produces `[pi a]` `regexSplit` panics if there is a problem and `mustRegexSplit` returns an error to the template engine if there is a problem. ## Cryptographic and Security Functions Helm provides some advanced cryptographic functions. They include [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), and [sha256sum](#sha256sum). ### sha1sum The `sha1sum` function receives a string, and computes it's SHA1 digest. ``` sha1sum "Hello world!" ``` ### sha256sum The `sha256sum` function receives a string, and computes it's SHA256 digest. ``` sha256sum "Hello world!" ``` The above will compute the SHA 256 sum in an "ASCII armored" format that is safe to print. ### adler32sum The `adler32sum` function receives a string, and computes its Adler-32 checksum. ``` adler32sum "Hello world!" ``` ### htpasswd The `htpasswd` function takes a `username` and `password` and generates a `bcrypt` hash of the password. The result can be used for basic authentication on an [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Note that it is insecure to store the password directly in the template. ### randBytes The randBytes function accepts a count N and generates a cryptographically secure (uses crypto/rand) random sequence of N bytes. The sequence is returned as a base64 encoded string. ``` randBytes 24 ``` ### derivePassword The `derivePassword` function can be used to derive a specific password based on some shared "master password" constraints. The algorithm for this is [well specified](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Note that it is considered insecure to store the parts directly in the template. ### genPrivateKey The `genPrivateKey` function generates a new private key encoded into a PEM block. It takes one of the values for its first param: - `ecdsa`: Generate an elliptic curve DSA key (P256) - `dsa`: Generate a DSA key (L2048N256) - `rsa`: Generate an RSA 4096 key ### buildCustomCert The `buildCustomCert` function allows customizing the certificate. It takes the following string parameters: - A base64 encoded PEM format certificate - A base64 encoded PEM format private key It returns a certificate object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Note that the returned object can be passed to the `genSignedCert` function to sign a certificate using this CA. ### genCA The `genCA` function generates a new, self-signed x509 certificate authority. It takes the following parameters: - Subject's common name (cn) - Cert validity duration in days It returns an object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $ca := genCA "foo-ca" 365 ``` Note that the returned object can be passed to the `genSignedCert` function to sign a certificate using this CA. ### genSelfSignedCert The `genSelfSignedCert` function generates a new, self-signed x509 certificate. It takes the following parameters: - Subject's common name (cn) - Optional list of IPs; may be nil - Optional list of alternate DNS names; may be nil - Cert validity duration in days It returns an object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert The `genSignedCert` function generates a new, x509 certificate signed by the specified CA. It takes the following parameters: - Subject's common name (cn) - Optional list of IPs; may be nil - Optional list of alternate DNS names; may be nil - Cert validity duration in days - CA (see `genCA`) Example: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES The `encryptAES` function encrypts text with AES-256 CBC and returns a base64 encoded string. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES The `decryptAES` function receives a base64 string encoded by the AES-256 CBC algorithm and returns the decoded text. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Date Functions Helm includes the following date functions you can use in templates: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch). ### now The current date/time. Use this in conjunction with other date functions. ### ago The `ago` function returns duration from time. Now in seconds resolution. ``` ago .CreatedAt ``` returns in `time.Duration` String() format ``` 2h34m7s ``` ### date The `date` function formats a date. Format the date to YEAR-MONTH-DAY: ``` now | date "2006-01-02" ``` Date formatting in Go is a [little bit different](https://pauladamsmith.com/blog/2011/05/go_time.html). In short, take this as the base date: ``` Mon Jan 2 15:04:05 MST 2006 ``` Write it in the format you want. Above, `2006-01-02` is the same date, but in the format we want. ### dateInZone Same as `date`, but with a timezone. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formats a given amount of seconds as a `time.Duration`. This returns 1m35s ``` duration "95" ``` ### durationRound Rounds a given duration to the most significant unit. Strings and `time.Duration` gets parsed as a duration, while a `time.Time` is calculated as the duration since. This return 2h ``` durationRound "2h10m5s" ``` This returns 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Returns the seconds since the unix epoch for a `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify The `dateModify` takes a modification and a date and returns the timestamp. Subtract an hour and thirty minutes from the current time: ``` now | dateModify "-1.5h" ``` If the modification format is wrong `dateModify` will return the date unmodified. `mustDateModify` will return an error otherwise. ### htmlDate The `htmlDate` function formats a date for inserting into an HTML date picker input field. ``` now | htmlDate ``` ### htmlDateInZone Same as htmlDate, but with a timezone. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` converts a string to a date. The first argument is the date layout and the second the date string. If the string can't be convert it returns the zero value. `mustToDate` will return an error in case the string cannot be converted. This is useful when you want to convert a string date to another format (using pipe). The example below converts "2017-12-31" to "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Dictionaries and Dict Functions Helm provides a key/value storage type called a `dict` (short for "dictionary", as in Python). A `dict` is an _unordered_ type. The key to a dictionary **must be a string**. However, the value can be any type, even another `dict` or `list`. Unlike `list`s, `dict`s are not immutable. The `set` and `unset` functions will modify the contents of a dictionary. Helm provides the following functions to support working with dicts: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), and [values](#values). ### dict Creating dictionaries is done by calling the `dict` function and passing it a list of pairs. The following creates a dictionary with three items: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Given a map and a key, get the value from the map. ``` get $myDict "name1" ``` The above returns `"value1"` Note that if the key is not found, this operation will simply return `""`. No error will be generated. ### set Use `set` to add a new key/value pair to a dictionary. ``` $_ := set $myDict "name4" "value4" ``` Note that `set` _returns the dictionary_ (a requirement of Go template functions), so you may need to trap the value as done above with the `$_` assignment. ### unset Given a map and a key, delete the key from the map. ``` $_ := unset $myDict "name4" ``` As with `set`, this returns the dictionary. Note that if the key is not found, this operation will simply return. No error will be generated. ### hasKey The `hasKey` function returns `true` if the given dict contains the given key. ``` hasKey $myDict "name1" ``` If the key is not found, this returns `false`. ### pluck The `pluck` function makes it possible to give one key and multiple maps, and get a list of all of the matches: ``` pluck "name1" $myDict $myOtherDict ``` The above will return a `list` containing every found value (`[value1 otherValue1]`). If the given key is _not found_ in a map, that map will not have an item in the list (and the length of the returned list will be less than the number of dicts in the call to `pluck`). If the key is _found_ but the value is an empty value, that value will be inserted. A common idiom in Helm templates is to use `pluck... | first` to get the first matching key out of a collection of dictionaries. ### dig The `dig` function traverses a nested set of dicts, selecting keys from a list of values. It returns a default value if any of the keys are not found at the associated dict. ``` dig "user" "role" "humanName" "guest" $dict ``` Given a dict structured like ``` { user: { role: { humanName: "curator" } } } ``` the above would return `"curator"`. If the dict lacked even a `user` field, the result would be `"guest"`. Dig can be very useful in cases where you'd like to avoid guard clauses, especially since Go's template package's `and` doesn't shortcut. For instance `and a.maybeNil a.maybeNil.iNeedThis` will always evaluate `a.maybeNil.iNeedThis`, and panic if `a` lacks a `maybeNil` field.) `dig` accepts its dict argument last in order to support pipelining. For instance: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Merge two or more dictionaries into one, giving precedence to the dest dictionary: Given: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` will result in: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` This is a deep merge operation but not a deep copy operation. Nested objects that are merged are the same instance on both dicts. If you want a deep copy along with the merge, then use the `deepCopy` function along with merging. For example, ``` deepCopy $source | merge $dest ``` `mustMerge` will return an error in case of unsuccessful merge. ### mergeOverwrite, mustMergeOverwrite Merge two or more dictionaries into one, giving precedence from **right to left**, effectively overwriting values in the dest dictionary: Given: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` will result in: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` This is a deep merge operation but not a deep copy operation. Nested objects that are merged are the same instance on both dicts. If you want a deep copy along with the merge then use the `deepCopy` function along with merging. For example, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` will return an error in case of unsuccessful merge. ### keys The `keys` function will return a `list` of all of the keys in one or more `dict` types. Since a dictionary is _unordered_, the keys will not be in a predictable order. They can be sorted with `sortAlpha`. ``` keys $myDict | sortAlpha ``` When supplying multiple dictionaries, the keys will be concatenated. Use the `uniq` function along with `sortAlpha` to get a unique, sorted list of keys. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick The `pick` function selects just the given keys out of a dictionary, creating a new `dict`. ``` $new := pick $myDict "name1" "name2" ``` The above returns `{name1: value1, name2: value2}` ### omit The `omit` function is similar to `pick`, except it returns a new `dict` with all the keys that _do not_ match the given keys. ``` $new := omit $myDict "name1" "name3" ``` The above returns `{name2: value2}` ### values The `values` function is similar to `keys`, except it returns a new `list` with all the values of the source `dict` (only one dictionary is supported). ``` $vals := values $myDict ``` The above returns `list["value1", "value2", "value 3"]`. Note that the `values` function gives no guarantees about the result ordering; if you care about this, then use `sortAlpha`. ### deepCopy, mustDeepCopy The `deepCopy` and `mustDeepCopy` functions take a value and make a deep copy of the value. This includes dicts and other structures. `deepCopy` panics when there is a problem, while `mustDeepCopy` returns an error to the template system when there is an error. ``` dict "a" 1 "b" 2 | deepCopy ``` ### A Note on Dict Internals A `dict` is implemented in Go as a `map[string]interface{}`. Go developers can pass `map[string]interface{}` values into the context to make them available to templates as `dict`s. ## Encoding Functions Helm has the following encoding and decoding functions: - `b64enc`/`b64dec`: Encode or decode with Base64 - `b32enc`/`b32dec`: Encode or decode with Base32 ## Lists and List Functions Helm provides a simple `list` type that can contain arbitrary sequential lists of data. This is similar to arrays or slices, but lists are designed to be used as immutable data types. Create a list of integers: ``` $myList := list 1 2 3 4 5 ``` The above creates a list of `[1 2 3 4 5]`. Helm provides the following list functions: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), and [without (mustWithout)](#without-mustwithout). ### first, mustFirst To get the head item on a list, use `first`. `first $myList` returns `1` `first` panics if there is a problem, while `mustFirst` returns an error to the template engine if there is a problem. ### rest, mustRest To get the tail of the list (everything but the first item), use `rest`. `rest $myList` returns `[2 3 4 5]` `rest` panics if there is a problem, while `mustRest` returns an error to the template engine if there is a problem. ### last, mustLast To get the last item on a list, use `last`: `last $myList` returns `5`. This is roughly analogous to reversing a list and then calling `first`. ### initial, mustInitial This compliments `last` by returning all _but_ the last element. `initial $myList` returns `[1 2 3 4]`. `initial` panics if there is a problem, while `mustInitial` returns an error to the template engine if there is a problem. ### append, mustAppend Append a new item to an existing list, creating a new list. ``` $new = append $myList 6 ``` The above would set `$new` to `[1 2 3 4 5 6]`. `$myList` would remain unaltered. `append` panics if there is a problem, while `mustAppend` returns an error to the template engine if there is a problem. ### prepend, mustPrepend Push an element onto the front of a list, creating a new list. ``` prepend $myList 0 ``` The above would produce `[0 1 2 3 4 5]`. `$myList` would remain unaltered. `prepend` panics if there is a problem, while `mustPrepend` returns an error to the template engine if there is a problem. ### concat Concatenate arbitrary number of lists into one. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` The above would produce `[1 2 3 4 5 6 7 8]`. `$myList` would remain unaltered. ### reverse, mustReverse Produce a new list with the reversed elements of the given list. ``` reverse $myList ``` The above would generate the list `[5 4 3 2 1]`. `reverse` panics if there is a problem, while `mustReverse` returns an error to the template engine if there is a problem. ### uniq, mustUniq Generate a list with all of the duplicates removed. ``` list 1 1 1 2 | uniq ``` The above would produce `[1 2]` `uniq` panics if there is a problem, while `mustUniq` returns an error to the template engine if there is a problem. ### without, mustWithout The `without` function filters items out of a list. ``` without $myList 3 ``` The above would produce `[1 2 4 5]` `without` can take more than one filter: ``` without $myList 1 3 5 ``` That would produce `[2 4]` `without` panics if there is a problem, while `mustWithout` returns an error to the template engine if there is a problem. ### has, mustHas Test to see if a list has a particular element. ``` has 4 $myList ``` The above would return `true`, while `has "hello" $myList` would return false. `has` panics if there is a problem, while `mustHas` returns an error to the template engine if there is a problem. ### compact, mustCompact Accepts a list and removes entries with empty values. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` will return a new list with the empty (i.e., "") item removed. `compact` panics if there is a problem and `mustCompact` returns an error to the template engine if there is a problem. ### index To get the nth element of a list, use `index list [n]`. To index into multi-dimensional lists, use `index list [n] [m] ...` - `index $myList 0` returns `1`. It is the same as `myList[0]` - `index $myList 0 1` would be the same as `myList[0][1]` ### slice, mustSlice To get partial elements of a list, use `slice list [n] [m]`. It is equivalent of `list[n:m]`. - `slice $myList` returns `[1 2 3 4 5]`. It is same as `myList[:]`. - `slice $myList 3` returns `[4 5]`. It is same as `myList[3:]`. - `slice $myList 1 3` returns `[2 3]`. It is same as `myList[1:3]`. - `slice $myList 0 3` returns `[1 2 3]`. It is same as `myList[:3]`. `slice` panics if there is a problem, while `mustSlice` returns an error to the template engine if there is a problem. ### until The `until` function builds a range of integers. ``` until 5 ``` The above generates the list `[0, 1, 2, 3, 4]`. This is useful for looping with `range $i, $e := until 5`. ### untilStep Like `until`, `untilStep` generates a list of counting integers. But it allows you to define a start, stop, and step: ``` untilStep 3 6 2 ``` The above will produce `[3 5]` by starting with 3, and adding 2 until it is equal or greater than 6. This is similar to Python's `range` function. ### seq Works like the bash `seq` command. * 1 parameter (end) - will generate all counting integers between 1 and `end` inclusive. * 2 parameters (start, end) - will generate all counting integers between `start` and `end` inclusive incrementing or decrementing by 1. * 3 parameters (start, step, end) - will generate all counting integers between `start` and `end` inclusive incrementing or decrementing by `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk To split a list into chunks of given size, use `chunk size list`. This is useful for pagination. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` This produces list of lists `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Math Functions All math functions operate on `int64` values unless specified otherwise. The following math functions are available: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub). ### add Sum numbers with `add`. Accepts two or more inputs. ``` add 1 2 3 ``` ### add1 To increment by 1, use `add1`. ### sub To subtract, use `sub`. ### div Perform integer division with `div`. ### mod Modulo with `mod`. ### mul Multiply with `mul`. Accepts two or more inputs. ``` mul 1 2 3 ``` ### max Return the largest of a series of integers. This will return `3`: ``` max 1 2 3 ``` ### min Return the smallest of a series of integers. `min 1 2 3` will return `1`. ### len Returns the length of the argument as an integer. ``` len .Arg ``` ## Float Math Functions All math functions operate on `float64` values. ### addf Sum numbers with `addf` This will return `5.5`: ``` addf 1.5 2 2 ``` ### add1f To increment by 1, use `add1f` ### subf To subtract, use `subf` This is equivalent to `7.5 - 2 - 3` and will return `2.5`: ``` subf 7.5 2 3 ``` ### divf Perform integer division with `divf` This is equivalent to `10 / 2 / 4` and will return `1.25`: ``` divf 10 2 4 ``` ### mulf Multiply with `mulf` This will return `6`: ``` mulf 1.5 2 2 ``` ### maxf Return the largest of a series of floats: This will return `3`: ``` maxf 1 2.5 3 ``` ### minf Return the smallest of a series of floats. This will return `1.5`: ``` minf 1.5 2 3 ``` ### floor Returns the greatest float value less than or equal to input value. `floor 123.9999` will return `123.0`. ### ceil Returns the greatest float value greater than or equal to input value. `ceil 123.001` will return `124.0`. ### round Returns a float value with the remainder rounded to the given number to digits after the decimal point. `round 123.555555 3` will return `123.556`. ## Network Functions Helm has a single network function, `getHostByName`. The `getHostByName` receives a domain name and returns the ip address. `getHostByName "www.google.com"` would return the corresponding ip address of `www.google.com`. This function requires the `--enable-dns` option to be passed on the helm command line. ## File Path Functions While Helm template functions do not grant access to the filesystem, they do provide functions for working with strings that follow file path conventions. Those include [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), and [isAbs](#isabs). ### base Return the last element of a path. ``` base "foo/bar/baz" ``` The above prints "baz". ### dir Return the directory, stripping the last part of the path. So `dir "foo/bar/baz"` returns `foo/bar`. ### clean Clean up a path. ``` clean "foo/bar/../baz" ``` The above resolves the `..` and returns `foo/baz`. ### ext Return the file extension. ``` ext "foo.bar" ``` The above returns `.bar`. ### isAbs To check whether a file path is absolute, use `isAbs`. ## Reflection Functions Helm provides rudimentary reflection tools. These help advanced template developers understand the underlying Go type information for a particular value. Helm is written in Go and is strongly typed. The type system applies within templates. Go has several primitive _kinds_, like `string`, `slice`, `int64`, and `bool`. Go has an open _type_ system that allows developers to create their own types. Helm provides a set of functions for each via [kind functions](#kind-functions) and [type functions](#type-functions). A [deepEqual](#deepequal) function is also provided to compare to values. ### Kind Functions There are two Kind functions: `kindOf` returns the kind of an object. ``` kindOf "hello" ``` The above would return `string`. For simple tests (like in `if` blocks), the `kindIs` function will let you verify that a value is a particular kind: ``` kindIs "int" 123 ``` The above will return `true`. ### Type Functions Types are slightly harder to work with, so there are three different functions: - `typeOf` returns the underlying type of a value: `typeOf $foo` - `typeIs` is like `kindIs`, but for types: `typeIs "*io.Buffer" $myVal` - `typeIsLike` works as `typeIs`, except that it also dereferences pointers **Note:** None of these can test whether or not something implements a given interface, since doing so would require compiling the interface in ahead of time. ### deepEqual `deepEqual` returns true if two values are ["deeply equal"](https://golang.org/pkg/reflect/#DeepEqual) Works for non-primitive types as well (compared to the built-in `eq`). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` The above will return `true`. ## Semantic Version Functions Some version schemes are easily parseable and comparable. Helm provides functions for working with [SemVer 2](http://semver.org) versions. These include [semver](#semver) and [semverCompare](#semvercompare). Below you will also find details on using ranges for comparisons. ### semver The `semver` function parses a string into a Semantic Version: ``` $version := semver "1.2.3-alpha.1+123" ``` _If the parser fails, it will cause template execution to halt with an error._ At this point, `$version` is a pointer to a `Version` object with the following properties: - `$version.Major`: The major number (`1` above) - `$version.Minor`: The minor number (`2` above) - `$version.Patch`: The patch number (`3` above) - `$version.Prerelease`: The prerelease (`alpha.1` above) - `$version.Metadata`: The build metadata (`123` above) - `$version.Original`: The original version as a string Additionally, you can compare a `Version` to another `version` using the `Compare` function: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` The above will return `-1`. The return values are: - `-1` if the given semver is greater than the semver whose `Compare` method was called - `1` if the version who's `Compare` function was called is greater. - `0` if they are the same version (Note that in SemVer, the `Metadata` field is not compared during version comparison operations.) ### semverCompare A more robust comparison function is provided as `semverCompare`. This version supports version ranges: - `semverCompare "1.2.3" "1.2.3"` checks for an exact match - `semverCompare "~1.2.0" "1.2.3"` checks that the major and minor versions match, and that the patch number of the second version is _greater than or equal to_ the first parameter. The SemVer functions use the [Masterminds semver library](https://github.com/Masterminds/semver), from the creators of Sprig. ### Basic Comparisons There are two elements to the comparisons. First, a comparison string is a list of space or comma separated AND comparisons. These are then separated by || (OR) comparisons. For example, `">= 1.2 < 3.0.0 || >= 4.2.3"` is looking for a comparison that's greater than or equal to 1.2 and less than 3.0.0 or is greater than or equal to 4.2.3. The basic comparisons are: - `=`: equal (aliased to no operator) - `!=`: not equal - `>`: greater than - `<`: less than - `>=`: greater than or equal to - `<=`: less than or equal to ### Working With Prerelease Versions Pre-releases, for those not familiar with them, are used for software releases prior to stable or generally available releases. Examples of prereleases include development, alpha, beta, and release candidate releases. A prerelease may be a version such as `1.2.3-beta.1`, while the stable release would be `1.2.3`. In the order of precedence, prereleases come before their associated releases. In this example `1.2.3-beta.1 < 1.2.3`. According to the Semantic Version specification prereleases may not be API compliant with their release counterpart. It says, > A pre-release version indicates that the version is unstable and might not > satisfy the intended compatibility requirements as denoted by its associated > normal version. SemVer comparisons using constraints without a prerelease comparator will skip prerelease versions. For example, `>=1.2.3` will skip prereleases when looking at a list of releases, while `>=1.2.3-0` will evaluate and find prereleases. The reason for the `0` as a pre-release version in the example comparison is because pre-releases can only contain ASCII alphanumerics and hyphens (along with `.` separators), per the spec. Sorting happens in ASCII sort order, again per the spec. The lowest character is a `0` in ASCII sort order (see an [ASCII Table](http://www.asciitable.com/)) Understanding ASCII sort ordering is important because A-Z comes before a-z. That means `>=1.2.3-BETA` will return `1.2.3-alpha`. What you might expect from case sensitivity doesn't apply here. This is due to ASCII sort ordering which is what the spec specifies. ### Hyphen Range Comparisons There are multiple methods to handle ranges and the first is hyphens ranges. These look like: - `1.2 - 1.4.5` which is equivalent to `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` which is equivalent to `>= 2.3.4 <= 4.5` ### Wildcards In Comparisons The `x`, `X`, and `*` characters can be used as a wildcard character. This works for all comparison operators. When used on the `=` operator it falls back to the patch level comparison (see tilde below). For example, - `1.2.x` is equivalent to `>= 1.2.0, < 1.3.0` - `>= 1.2.x` is equivalent to `>= 1.2.0` - `<= 2.x` is equivalent to `< 3` - `*` is equivalent to `>= 0.0.0` ### Tilde Range Comparisons (Patch) The tilde (`~`) comparison operator is for patch level ranges when a minor version is specified and major level changes when the minor number is missing. For example, - `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0` - `~1` is equivalent to `>= 1, < 2` - `~2.3` is equivalent to `>= 2.3, < 2.4` - `~1.2.x` is equivalent to `>= 1.2.0, < 1.3.0` - `~1.x` is equivalent to `>= 1, < 2` ### Caret Range Comparisons (Major) The caret (`^`) comparison operator is for major level changes once a stable (1.0.0) release has occurred. Prior to a 1.0.0 release the minor versions acts as the API stability level. This is useful when comparisons of API versions as a major change is API breaking. For example, - `^1.2.3` is equivalent to `>= 1.2.3, < 2.0.0` - `^1.2.x` is equivalent to `>= 1.2.0, < 2.0.0` - `^2.3` is equivalent to `>= 2.3, < 3` - `^2.x` is equivalent to `>= 2.0.0, < 3` - `^0.2.3` is equivalent to `>=0.2.3 <0.3.0` - `^0.2` is equivalent to `>=0.2.0 <0.3.0` - `^0.0.3` is equivalent to `>=0.0.3 <0.0.4` - `^0.0` is equivalent to `>=0.0.0 <0.1.0` - `^0` is equivalent to `>=0.0.0 <1.0.0` ## URL Functions Helm includes the [urlParse](#urlparse), [urlJoin](#urljoin), and [urlquery](#urlquery) functions enabling you to work with URL parts. ### urlParse Parses string for URL and produces dict with URL parts ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` The above returns a dict, containing URL object: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` This is implemented used the URL packages from the Go standard library. For more info, check https://golang.org/pkg/net/url/#URL ### urlJoin Joins map (produced by `urlParse`) to produce URL string ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` The above returns the following string: ``` http://host:80/path?query#fragment ``` ### urlquery Returns the escaped version of the value passed in as an argument so that it is suitable for embedding in the query portion of a URL. ``` $var := urlquery "string for query" ``` ## UUID Functions Helm can generate UUID v4 universally unique IDs. ``` uuidv4 ``` The above returns a new UUID of the v4 (randomly generated) type. ## Kubernetes and Chart Functions Helm includes functions for working with Kubernetes including [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#file-functions), and [lookup](#lookup). ### lookup `lookup` is used to look up resource in a running cluster. When used with the `helm template` command it always returns an empty response. You can find more detail in the [documentation on the lookup function](/chart_template_guide/functions_and_pipelines.mdx#using-the-lookup-function). ### .Capabilities.APIVersions.Has Returns if an API version or resource is available in a cluster. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` More information is available on the [built-in object documentation](/chart_template_guide/builtin_objects.md). ### File Functions There are several functions that enable you to get to non-special files within a chart. For example, to access application configuration files. These are documented in [Accessing Files Inside Templates](/chart_template_guide/accessing_files.md). _Note, the documentation for many of these functions come from [Sprig](https://github.com/Masterminds/sprig). Sprig is a template function library available to Go applications._ ================================================ FILE: docs/chart_template_guide/functions_and_pipelines.mdx ================================================ --- title: Template Functions and Pipelines description: Using functions in templates. sidebar_position: 5 --- import Helm4 from "/docs/_v4-in-progress.mdx" So far, we've seen how to place information into a template. But that information is placed into the template unmodified. Sometimes we want to transform the supplied data in a way that makes it more usable to us. Let's start with a best practice: When injecting strings from the `.Values` object into the template, we ought to quote these strings. We can do that by calling the `quote` function in the template directive: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Template functions follow the syntax `functionName arg1 arg2...`. In the snippet above, `quote .Values.favorite.drink` calls the `quote` function and passes it a single argument. Helm has over 60 available functions. Some of them are defined by the [Go template language](https://godoc.org/text/template) itself. Most of the others are part of the [Sprig template library](https://masterminds.github.io/sprig/). We'll see many of them as we progress through the examples. > While we talk about the "Helm template language" as if it is Helm-specific, it > is actually a combination of the Go template language, some extra functions, > and a variety of wrappers to expose certain objects to the templates. Many > resources on Go templates may be helpful as you learn about templating. ## Pipelines One of the powerful features of the template language is its concept of _pipelines_. Drawing on a concept from UNIX, pipelines are a tool for chaining together a series of template commands to compactly express a series of transformations. In other words, pipelines are an efficient way of getting several things done in sequence. Let's rewrite the above example using a pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` In this example, instead of calling `quote ARGUMENT`, we inverted the order. We "sent" the argument to the function using a pipeline (`|`): `.Values.favorite.drink | quote`. Using pipelines, we can chain several functions together: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Inverting the order is a common practice in templates. You will see `.val | > quote` more often than `quote .val`. Either practice is fine. When evaluated, that template will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Note that our original `pizza` has now been transformed to `"PIZZA"`. When pipelining arguments like this, the result of the first evaluation (`.Values.favorite.drink`) is sent as the _last argument to the function_. We can modify the drink example above to illustrate with a function that takes two arguments: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` The `repeat` function will echo the given string the given number of times, so we will get this for output: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Using the `default` function One function frequently used in templates is the `default` function: `default DEFAULT_VALUE GIVEN_VALUE`. This function allows you to specify a default value inside of the template, in case the value is omitted. Let's use it to modify the drink example above: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` If we run this as normal, we'll get our `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Now, we will remove the favorite drink setting from `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Now re-running `helm install --dry-run --debug fair-worm ./mychart` will produce this YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` In an actual chart, all static default values should live in the `values.yaml`, and should not be repeated using the `default` command (otherwise they would be redundant). However, the `default` command is perfect for computed values, which cannot be declared inside `values.yaml`. For example: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` In some places, an `if` conditional guard may be better suited than `default`. We'll see those in the next section. Template functions and pipelines are a powerful way to transform information and then insert it into your YAML. But sometimes it's necessary to add some template logic that is a little more sophisticated than just inserting a string. In the next section we will look at the control structures provided by the template language. ## Using the `lookup` function The `lookup` function can be used to _look up_ resources in a running cluster. The synopsis of the lookup function is `lookup apiVersion, kind, namespace, name -> resource or resource list`. | parameter | type | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Both `name` and `namespace` are optional and can be passed as an empty string (`""`). However, if you're working with a namespace-scoped resource, both `name` and `namespace` must be specified. The following combination of parameters are possible: | Behavior | Lookup function | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | When `lookup` returns an object, it will return a dictionary. This dictionary can be further navigated to extract specific values. The following example will return the annotations present for the `mynamespace` object: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` When `lookup` returns a list of objects, it is possible to access the object list via the `items` field: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` When no object is found, an empty value is returned. This can be used to check for the existence of an object. The `lookup` function uses Helm's existing Kubernetes connection configuration to query Kubernetes. If any error is returned when interacting with calling the API server (for example due to lack of permission to access a resource), Helm's template processing will fail. Keep in mind that Helm is not supposed to contact the Kubernetes API Server during a `helm template|install|upgrade|delete|rollback --dry-run` operation. To test `lookup` against a running cluster, `helm template|install|upgrade|delete|rollback --dry-run=server` should be used instead to allow cluster connection. ## Operators are functions For templates, the operators (`eq`, `ne`, `lt`, `gt`, `and`, `or` and so on) are all implemented as functions. In pipelines, operations can be grouped with parentheses (`(`, and `)`). Now we can turn from functions and pipelines to flow control with conditions, loops, and scope modifiers. ================================================ FILE: docs/chart_template_guide/getting_started.md ================================================ --- title: Getting Started description: A quick guide on Chart templates. sidebar_position: 2 --- In this section of the guide, we'll create a chart and then add a first template. The chart we created here will be used throughout the rest of the guide. To get going, let's take a brief look at a Helm chart. ## Charts As described in the [Charts Guide](/topics/charts.mdx), Helm charts are structured like this: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` The `templates/` directory is for template files. When Helm evaluates a chart, it will send all of the files in the `templates/` directory through the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes. The `values.yaml` file is also important to templates. This file contains the _default values_ for a chart. These values may be overridden by users during `helm install` or `helm upgrade`. The `Chart.yaml` file contains a description of the chart. You can access it from within a template. The `charts/` directory _may_ contain other charts (which we call _subcharts_). Later in this guide we will see how those work when it comes to template rendering. ## A Starter Chart For this guide, we'll create a simple chart called `mychart`, and then we'll create some templates inside of the chart. ```console $ helm create mychart Creating mychart ``` ### A Quick Glimpse of `mychart/templates/` If you take a look at the `mychart/templates/` directory, you'll notice a few files already there. - `NOTES.txt`: The "help text" for your chart. This will be displayed to your users when they run `helm install`. - `deployment.yaml`: A basic manifest for creating a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - `service.yaml`: A basic manifest for creating a [service endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment - `_helpers.tpl`: A place to put template helpers that you can re-use throughout the chart And what we're going to do is... _remove them all!_ That way we can work through our tutorial from scratch. We'll actually create our own `NOTES.txt` and `_helpers.tpl` as we go. ```console $ rm -rf mychart/templates/* ``` When you're writing production grade charts, having basic versions of these charts can be really useful. So in your day-to-day chart authoring, you probably won't want to remove them. ## A First Template The first template we are going to create will be a `ConfigMap`. In Kubernetes, a ConfigMap is simply an object for storing configuration data. Other things, like pods, can access the data in a ConfigMap. Because ConfigMaps are basic resources, they make a great starting point for us. Let's begin by creating a file called `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** Template names do not follow a rigid naming pattern. However, we recommend using the extension `.yaml` for YAML files and `.tpl` for helpers. The YAML file above is a bare-bones ConfigMap, having the minimal necessary fields. By virtue of the fact that this file is in the `mychart/templates/` directory, it will be sent through the template engine. It is just fine to put a plain YAML file like this in the `mychart/templates/` directory. When Helm reads this template, it will simply send it to Kubernetes as-is. With this simple template, we now have an installable chart. And we can install it like this: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Using Helm, we can retrieve the release and see the actual template that was loaded. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` The `helm get manifest` command takes a release name (`full-coral`) and prints out all of the Kubernetes resources that were uploaded to the server. Each file begins with `---` to indicate the start of a YAML document, and then is followed by an automatically generated comment line that tells us what template file generated this YAML document. From there on, we can see that the YAML data is exactly what we put in our `configmap.yaml` file. Now we can uninstall our release: `helm uninstall full-coral`. ### Adding a Simple Template Call Hard-coding the `name:` into a resource is usually considered to be bad practice. Names should be unique to a release. So we might want to generate a name field by inserting the release name. **TIP:** The `name:` field is limited to 63 characters because of limitations to the DNS system. For that reason, release names are limited to 53 characters. Kubernetes 1.3 and earlier limited to only 24 characters (thus 14 character names). Let's alter `configmap.yaml` accordingly. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` The big change comes in the value of the `name:` field, which is now `{{ .Release.Name }}-configmap`. > A template directive is enclosed in `{{` and `}}` blocks. The template directive `{{ .Release.Name }}` injects the release name into the template. The values that are passed into a template can be thought of as _namespaced objects_, where a dot (`.`) separates each namespaced element. The leading dot before `Release` indicates that we start with the top-most namespace for this scope (we'll talk about scope in a bit). So we could read `.Release.Name` as "start at the top namespace, find the `Release` object, then look inside of it for an object called `Name`". The `Release` object is one of the built-in objects for Helm, and we'll cover it in more depth later. But for now, it is sufficient to say that this will display the release name that the library assigns to our release. Now when we install our resource, we'll immediately see the result of using this template directive: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` You can run `helm get manifest clunky-serval` to see the entire generated YAML. Note that the ConfigMap inside Kubernetes name is `clunky-serval-configmap` instead of `mychart-configmap` previously. At this point, we've seen templates at their most basic: YAML files that have template directives embedded in `{{` and `}}`. In the next part, we'll take a deeper look into templates. But before moving on, there's one quick trick that can make building templates faster: When you want to test the template rendering, but not actually install anything, you can use `helm install --debug --dry-run goodly-guppy ./mychart`. This will render the templates. But instead of installing the chart, it will return the rendered template to you so you can see the output: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Using `--dry-run` will make it easier to test your code, but it won't ensure that Kubernetes itself will accept the templates you generate. It's best not to assume that your chart will install just because `--dry-run` works. In the [Chart Template Guide](/chart_template_guide/index.mdx), we take the basic chart we defined here and explore the Helm template language in detail. And we'll get started with built-in objects. ================================================ FILE: docs/chart_template_guide/helm_ignore_file.md ================================================ --- title: The .helmignore file description: The `.helmignore` file is used to specify files you don't want to include in your helm chart. sidebar_position: 12 --- The `.helmignore` file is used to specify files you don't want to include in your helm chart. If this file exists, the `helm package` command will ignore all the files that match the pattern specified in the `.helmignore` file while packaging your application. This can help in avoiding unnecessary or sensitive files or directories from being added in your helm chart. The `.helmignore` file supports Unix shell glob matching, relative path matching, and negation (prefixed with !). Only one pattern per line is considered. Here is an example `.helmignore` file: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Some notable differences from .gitignore: - The '**' syntax is not supported. - The globbing library is Go's 'filepath.Match', not fnmatch(3) - Trailing spaces are always ignored (there is no supported escape sequence) - There is no support for '\!' as a special leading sequence. - It does not exclude itself by default, you have to add an explicit entry for `.helmignore` **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm-www/issues) or send us a pull request. ================================================ FILE: docs/chart_template_guide/index.mdx ================================================ --- title: Chart Template Guide sidebar_position: 5 --- # The Chart Template Developer's Guide This guide provides an introduction to Helm's chart templates, with emphasis on the template language. Templates generate manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. We'll look at how templates are structured, how they can be used, how to write Go templates, and how to debug your work. This guide focuses on the following concepts: - The Helm template language - Using values - Techniques for working with templates This guide is oriented toward learning the ins and outs of the Helm template language. Other guides provide introductory material, examples, and best practices. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/chart_template_guide/named_templates.md ================================================ --- title: Named Templates description: How to define named templates. sidebar_position: 9 --- It is time to move beyond one template, and begin to create others. In this section, we will see how to define _named templates_ in one file, and then use them elsewhere. A _named template_ (sometimes called a _partial_ or a _subtemplate_) is simply a template defined inside of a file, and given a name. We'll see two ways to create them, and a few different ways to use them. In the [Flow Control](/chart_template_guide/control_structures.md) section we introduced three actions for declaring and managing templates: `define`, `template`, and `block`. In this section, we'll cover those three actions, and also introduce a special-purpose `include` function that works similarly to the `template` action. An important detail to keep in mind when naming templates: **template names are global**. If you declare two templates with the same name, whichever one is loaded last will be the one used. Because templates in subcharts are compiled together with top-level templates, you should be careful to name your templates with _chart-specific names_. One popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. By using the specific chart name as a prefix we can avoid any conflicts that may arise due to two different charts that implement templates of the same name. This behavior also applies to different versions of a chart. If you have `mychart` version `1.0.0` that defines a template one way, and a `mychart` version `2.0.0` that modifies the existing named template, it will use the one that was loaded last. You can work around this issue by also adding a version in the name of the chart: `{{ define "mychart.v1.labels" }}` and `{{ define "mychart.v2.labels" }}`. ## Partials and `_` files So far, we've used one file, and that one file has contained a single template. But Helm's template language allows you to create named embedded templates, that can be accessed by name elsewhere. Before we get to the nuts-and-bolts of writing those templates, there is file naming convention that deserves mention: * Most files in `templates/` are treated as if they contain Kubernetes manifests * The `NOTES.txt` is one exception * But files whose name begins with an underscore (`_`) are assumed to _not_ have a manifest inside. These files are not rendered to Kubernetes object definitions, but are available everywhere within other chart templates for use. These files are used to store partials and helpers. In fact, when we first created `mychart`, we saw a file called `_helpers.tpl`. That file is the default location for template partials. ## Declaring and using templates with `define` and `template` The `define` action allows us to create a named template inside of a template file. Its syntax goes like this: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` For example, we can define a template to encapsulate a Kubernetes block of labels: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Now we can embed this template inside of our existing ConfigMap, and then include it with the `template` action: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` When the template engine reads this file, it will store away the reference to `mychart.labels` until `template "mychart.labels"` is called. Then it will render that template inline. So the result will look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Note: a `define` does not produce output unless it is called with a template, as in this example. Conventionally, Helm charts put these templates inside of a partials file, usually `_helpers.tpl`. Let's move this function there: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` By convention, `define` functions should have a simple documentation block (`{{/* ... */}}`) describing what they do. Even though this definition is in `_helpers.tpl`, it can still be accessed in `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` As mentioned above, **template names are global**. As a result of this, if two templates are declared with the same name the last occurrence will be the one that is used. Since templates in subcharts are compiled together with top-level templates, it is best to name your templates with _chart specific names_. A popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. ## Setting the scope of a template In the template we defined above, we did not use any objects. We just used functions. Let's modify our defined template to include the chart name and chart version: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` If we render this, we will get an error like this: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` To see what rendered, re-run with `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. The result will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` What happened to the name and version? They weren't in the scope for our defined template. When a named template (created with `define`) is rendered, it will receive the scope passed in by the `template` call. In our example, we included the template like this: ```yaml {{- template "mychart.labels" }} ``` No scope was passed in, so within the template we cannot access anything in `.`. This is easy enough to fix, though. We simply pass a scope to the template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Note that we pass `.` at the end of the `template` call. We could just as easily pass `.Values` or `.Values.favorite` or whatever scope we want. But what we want is the top-level scope. In the context of the named template, `$` will refer to the scope you passed in and not some global scope. Now when we execute this template with `helm install --dry-run --debug plinking-anaco ./mychart`, we get this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Now `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}` resolves to `0.1.0`. ## The `include` function Say we've defined a simple template that looks like this: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Now say I want to insert this both into the `labels:` section of my template, and also the `data:` section: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` If we render this, we will get an error like this: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` To see what rendered, re-run with `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. The output will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Note that the indentation on `app_version` is wrong in both places. Why? Because the template that is substituted in has the text aligned to the left. Because `template` is an action, and not a function, there is no way to pass the output of a `template` call to other functions; the data is simply inserted inline. To work around this case, Helm provides an alternative to `template` that will import the contents of a template into the present pipeline where it can be passed along to other functions in the pipeline. Here's the example above, corrected to use `indent` to indent the `mychart.app` template correctly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Now the produced YAML is correctly indented for each section: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > It is considered preferable to use `include` over `template` in Helm templates > simply so that the output formatting can be handled better for YAML documents. Sometimes we want to import content, but not as templates. That is, we want to import files verbatim. We can achieve this by accessing files through the `.Files` object described in the next section. ================================================ FILE: docs/chart_template_guide/notes_files.md ================================================ --- title: Creating a NOTES.txt File description: How to provide instructions to your Chart users. sidebar_position: 10 --- In this section we are going to look at Helm's tool for providing instructions to your chart users. At the end of a `helm install` or `helm upgrade`, Helm can print out a block of helpful information for users. This information is highly customizable using templates. To add installation notes to your chart, simply create a `templates/NOTES.txt` file. This file is plain text, but it is processed like a template, and has all the normal template functions and objects available. Let's create a simple `NOTES.txt` file: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Now if we run `helm install rude-cardinal ./mychart` we will see this message at the bottom: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Using `NOTES.txt` this way is a great way to give your users detailed information about how to use their newly installed chart. Creating a `NOTES.txt` file is strongly recommended, though it is not required. ================================================ FILE: docs/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts and Global Values description: Interacting with a subchart's and global values. sidebar_position: 11 --- To this point we have been working only with one chart. But charts can have dependencies, called _subcharts_, that also have their own values and templates. In this section we will create a subchart and see the different ways we can access values from within templates. Before we dive into the code, there are a few important details to learn about application subcharts. 1. A subchart is considered "stand-alone", which means a subchart can never explicitly depend on its parent chart. 2. For that reason, a subchart cannot access the values of its parent. 3. A parent chart can override values for subcharts. 4. Helm has a concept of _global values_ that can be accessed by all charts. > These limitations do not all necessarily apply to [library charts](/topics/library_charts.md), which are designed to provide standardized helper functionality. As we walk through the examples in this section, many of these concepts will become clearer. ## Creating a Subchart For these exercises, we'll start with the `mychart/` chart we created at the beginning of this guide, and we'll add a new chart inside of it. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Notice that just as before, we deleted all of the base templates so that we can start from scratch. In this guide, we are focused on how templates work, not on managing dependencies. But the [Charts Guide](/topics/charts.mdx) has more information on how subcharts work. ## Adding Values and a Template to the Subchart Next, let's create a simple template and values file for our `mysubchart` chart. There should already be a `values.yaml` in `mychart/charts/mysubchart`. We'll set it up like this: ```yaml dessert: cake ``` Next, we'll create a new ConfigMap template in `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Because every subchart is a _stand-alone chart_, we can test `mysubchart` on its own: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Overriding Values from a Parent Chart Our original chart, `mychart` is now the _parent_ chart of `mysubchart`. This relationship is based entirely on the fact that `mysubchart` is within `mychart/charts`. Because `mychart` is a parent, we can specify configuration in `mychart` and have that configuration pushed into `mysubchart`. For example, we can modify `mychart/values.yaml` like this: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Note the last two lines. Any directives inside of the `mysubchart` section will be sent to the `mysubchart` chart. So if we run `helm install --generate-name --dry-run --debug mychart`, one of the things we will see is the `mysubchart` ConfigMap: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` The value at the top level has now overridden the value of the subchart. There's an important detail to notice here. We didn't change the template of `mychart/charts/mysubchart/templates/configmap.yaml` to point to `.Values.mysubchart.dessert`. From that template's perspective, the value is still located at `.Values.dessert`. As the template engine passes values along, it sets the scope. So for the `mysubchart` templates, only values specifically for `mysubchart` will be available in `.Values`. Sometimes, though, you do want certain values to be available to all of the templates. This is accomplished using global chart values. ## Global Chart Values Global values are values that can be accessed from any chart or subchart by exactly the same name. Globals require explicit declaration. You can't use an existing non-global as if it were a global. The Values data type has a reserved section called `Values.global` where global values can be set. Let's set one in our `mychart/values.yaml` file. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Because of the way globals work, both `mychart/templates/configmap.yaml` and `mysubchart/templates/configmap.yaml` should be able to access that value as `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Now if we run a dry run install, we'll see the same value in both outputs: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Globals are useful for passing information like this, though it does take some planning to make sure the right templates are configured to use globals. ## Sharing Templates with Subcharts Parent charts and subcharts can share templates. Any defined block in any chart is available to other charts. For example, we can define a simple template like this: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Recall how the labels on templates are _globally shared_. Thus, the `labels` chart can be included from any other chart. While chart developers have a choice between `include` and `template`, one advantage of using `include` is that `include` can dynamically reference templates: ```yaml {{ include $mytemplate }} ``` The above will dereference `$mytemplate`. The `template` function, in contrast, will only accept a string literal. ## Avoid Using Blocks The Go template language provides a `block` keyword that allows developers to provide a default implementation which is overridden later. In Helm charts, blocks are not the best tool for overriding because if multiple implementations of the same block are provided, the one selected is unpredictable. The suggestion is to instead use `include`. ================================================ FILE: docs/chart_template_guide/values_files.mdx ================================================ --- title: Values Files description: Instructions on how to use the --values flag. sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" In the previous section we looked at the built-in objects that Helm templates offer. One of the built-in objects is `Values`. This object provides access to values passed into the chart. Its contents come from multiple sources: - The `values.yaml` file in the chart - If this is a subchart, the `values.yaml` file of a parent chart - A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`) - Individual parameters are passed with `--set` (such as `helm install --set foo=bar ./mychart`) The list above is in order of specificity: `values.yaml` is the default, which can be overridden by a parent chart's `values.yaml`, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by `--set` parameters. Values files are plain YAML files. Let's edit `mychart/values.yaml` and then edit our ConfigMap template. Removing the defaults in `values.yaml`, we'll set just one parameter: ```yaml favoriteDrink: coffee ``` Now we can use this inside of a template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Notice on the last line we access `favoriteDrink` as an attribute of `Values`: `{{ .Values.favoriteDrink }}`. Let's see how this renders. ```console $ helm install geared-marsupi ./mychart --dry-run=client --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Because `favoriteDrink` is set in the default `values.yaml` file to `coffee`, that's the value displayed in the template. We can easily override that by adding a `--set` flag in our call to `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run=client --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Since `--set` has a higher precedence than the default `values.yaml` file, our template generates `drink: slurm`. Values files can contain more structured content, too. For example, we could create a `favorite` section in our `values.yaml` file, and then add several keys there: ```yaml favorite: drink: coffee food: pizza ``` Now we would have to modify the template slightly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` While structuring data this way is possible, the recommendation is that you keep your values trees shallow, favoring flatness. When we look at assigning values to subcharts, we'll see how values are named using a tree structure. ## Deleting a default key If you need to delete a key from the default values, you may override the value of the key to be `null`, in which case Helm will remove the key from the overridden values merge. For example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` If you try to override the livenessProbe handler to `exec` instead of `httpGet` using `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will coalesce the default and overridden keys together, resulting in the following YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` However, Kubernetes would then fail because you can not declare more than one livenessProbe handler. To overcome this, you may instruct Helm to delete the `livenessProbe.httpGet` by setting it to null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` At this point, we've seen several built-in objects, and used them to inject information into a template. Now we will take a look at another aspect of the template engine: functions and pipelines. ================================================ FILE: docs/chart_template_guide/variables.md ================================================ --- title: Variables description: Using variables in templates. sidebar_position: 8 --- With functions, pipelines, objects, and control structures under our belts, we can turn to one of the more basic ideas in many programming languages: variables. In templates, they are less frequently used. But we will see how to use them to simplify code, and to make better use of `with` and `range`. In an earlier example, we saw that this code will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` is not inside of the scope that's restricted in the `with` block. One way to work around scoping issues is to assign objects to variables that can be accessed without respect to the present scope. In Helm templates, a variable is a named reference to another object. It follows the form `$name`. Variables are assigned with a special assignment operator: `:=`. We can rewrite the above to use a variable for `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Notice that before we start the `with` block, we assign `$relname := .Release.Name`. Now inside of the `with` block, the `$relname` variable still points to the release name. Running that will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Variables are particularly useful in `range` loops. They can be used on list-like objects to capture both the index and the value: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Note that `range` comes first, then the variables, then the assignment operator, then the list. This will assign the integer index (starting from zero) to `$index` and the value to `$topping`. Running it will produce: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` For data structures that have both a key and a value, we can use `range` to get both. For example, we can loop through `.Values.favorite` like this: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Now on the first iteration, `$key` will be `drink` and `$val` will be `coffee`, and on the second, `$key` will be `food` and `$val` will be `pizza`. Running the above will generate this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Variables are normally not "global". They are scoped to the block in which they are declared. Earlier, we assigned `$relname` in the top level of the template. That variable will be in scope for the entire template. But in our last example, `$key` and `$val` will only be in scope inside of the `{{ range... }}{{ end }}` block. However, there is one variable that will always point to the root context: - `$` -. This can be very useful when you are looping in a range and you need to know the chart's release name. An example illustrating this: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` So far we have looked at just one template declared in just one file. But one of the powerful features of the Helm template language is its ability to declare multiple templates and use them together. We'll turn to that in the next section. ================================================ FILE: docs/chart_template_guide/wrapping_up.md ================================================ --- title: Next Steps description: Wrapping up - some useful pointers to other documentation that will help you. sidebar_position: 14 --- This guide is intended to give you, the chart developer, a strong understanding of how to use Helm's template language. The guide focuses on the technical aspects of template development. But there are many things this guide has not covered when it comes to the practical day-to-day development of charts. Here are some useful pointers to other documentation that will help you as you create new charts: - The CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) is an indispensable source of charts. - The Kubernetes [Documentation](https://kubernetes.io/docs/home/) provides detailed examples of the various resource kinds that you can use, from ConfigMaps and Secrets to DaemonSets and Deployments. - The Helm [Charts Guide](/topics/charts.mdx) explains the workflow of using charts. - The Helm [Chart Hooks Guide](/topics/charts_hooks.md) explains how to create lifecycle hooks. - The Helm [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) article provides some useful tips for writing charts. - The [Sprig documentation](https://github.com/Masterminds/sprig) documents more than sixty of the template functions. - The [Go template docs](https://godoc.org/text/template) explain the template syntax in detail. - The [Schelm tool](https://github.com/databus23/schelm) is a nice helper utility for debugging charts. Sometimes it's easier to ask a few questions and get answers from experienced developers. The best place to do this is in the [Kubernetes Slack](https://kubernetes.slack.com) Helm channels: - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Finally, if you find errors or omissions in this document, want to suggest some new content, or would like to contribute, visit [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: docs/chart_template_guide/yaml_techniques.md ================================================ --- title: "Appendix: YAML Techniques" description: A closer look at the YAML specification and how it applies to Helm. sidebar_position: 15 --- Most of this guide has been focused on writing the template language. Here, we'll look at the YAML format. YAML has some useful features that we, as template authors, can use to make our templates less error prone and easier to read. ## Scalars and Collections According to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two types of collections, and many scalar types. The two types of collections are maps and sequences: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Scalar values are individual values (as opposed to collections) ### Scalar Types in YAML In Helm's dialect of YAML, the scalar data type of a value is determined by a complex set of rules, including the Kubernetes schema for resource definitions. But when inferring types, the following rules tend to hold true. If an integer or float is an unquoted bare word, it is typically treated as a numeric type: ```yaml count: 1 size: 2.34 ``` But if they are quoted, they are treated as strings: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` The same is true of booleans: ```yaml isGood: true # bool answer: "true" # string ``` The word for an empty value is `null` (not `nil`). Note that `port: "80"` is valid YAML, and will pass through both the template engine and the YAML parser, but will fail if Kubernetes expects `port` to be an integer. In some cases, you can force a particular type inference using YAML node tags: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` In the above, `!!str` tells the parser that `age` is a string, even if it looks like an int. And `port` is treated as an int, even though it is quoted. ## Strings in YAML Much of the data that we place in YAML documents are strings. YAML has more than one way to represent a string. This section explains the ways and demonstrates how to use some of them. There are three "inline" ways of declaring a string: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` All inline styles must be on one line. - Bare words are unquoted, and are not escaped. For this reason, you have to be careful what characters you use. - Double-quoted strings can have specific characters escaped with `\`. For example `"\"Hello\", she said"`. You can escape line breaks with `\n`. - Single-quoted strings are "literal" strings, and do not use the `\` to escape characters. The only escape sequence is `''`, which is decoded as a single `'`. In addition to the one-line strings, you can declare multi-line strings: ```yaml coffee: | Latte Cappuccino Espresso ``` The above will treat the value of `coffee` as a single string equivalent to `Latte\nCappuccino\nEspresso\n`. Note that the first line after the `|` must be correctly indented. So we could break the example above by doing this: ```yaml coffee: | Latte Cappuccino Espresso ``` Because `Latte` is incorrectly indented, we'd get an error like this: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` In templates, it is sometimes safer to put a fake "first line" of content in a multi-line document just for protection from the above error: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Note that whatever that first line is, it will be preserved in the output of the string. So if you are, for example, using this technique to inject a file's contents into a ConfigMap, the comment should be of the type expected by whatever is reading that entry. ### Controlling Spaces in Multi-line Strings In the example above, we used `|` to indicate a multi-line string. But notice that the content of our string was followed with a trailing `\n`. If we want the YAML processor to strip off the trailing newline, we can add a `-` after the `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Now the `coffee` value will be: `Latte\nCappuccino\nEspresso` (with no trailing `\n`). Other times, we might want all trailing whitespace to be preserved. We can do this with the `|+` notation: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Now the value of `coffee` will be `Latte\nCappuccino\nEspresso\n\n\n`. Indentation inside of a text block is preserved, and results in the preservation of line breaks, too: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` In the above case, `coffee` will be `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indenting and Templates When writing templates, you may find yourself wanting to inject the contents of a file into the template. As we saw in previous chapters, there are two ways of doing this: - Use `{{ .Files.Get "FILENAME" }}` to get the contents of a file in the chart. - Use `{{ include "TEMPLATE" . }}` to render a template and then place its contents into the chart. When inserting files into YAML, it's good to understand the multi-line rules above. Often times, the easiest way to insert a static file is to do something like this: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Note how we do the indentation above: `indent 2` tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that template line. That's because if we did, the file content of the first line would be indented twice. ### Folded Multi-line Strings Sometimes you want to represent a string in your YAML with multiple lines, but want it to be treated as one long line when it is interpreted. This is called "folding". To declare a folded block, use `>` instead of `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` The value of `coffee` above will be `Latte Cappuccino Espresso\n`. Note that all but the last line feed will be converted to spaces. You can combine the whitespace controls with the folded text marker, so `>-` will replace or trim all newlines. Note that in the folded syntax, indenting text will cause lines to be preserved. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` The above will produce `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Note that both the spacing and the newlines are still there. ## Embedding Multiple Documents in One File It is possible to place more than one YAML document into a single file. This is done by prefixing a new document with `---` and ending the document with `...` ```yaml --- document: 1 ... --- document: 2 ... ``` In many cases, either the `---` or the `...` may be omitted. Some files in Helm cannot contain more than one doc. If, for example, more than one document is provided inside of a `values.yaml` file, only the first will be used. Template files, however, may have more than one document. When this happens, the file (and all of its documents) is treated as one object during template rendering. But then the resulting YAML is split into multiple documents before it is fed to Kubernetes. We recommend only using multiple documents per file when it is absolutely necessary. Having multiple documents in a file can be difficult to debug. ## YAML is a Superset of JSON Because YAML is a superset of JSON, any valid JSON document _should_ be valid YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` The above is another way of representing this: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` And the two can be mixed (with care): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` All three of these should parse into the same internal representation. While this means that files such as `values.yaml` may contain JSON data, Helm does not treat the file extension `.json` as a valid suffix. ## YAML Anchors The YAML spec provides a way to store a reference to a value, and later refer to that value by reference. YAML refers to this as "anchoring": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` In the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that reference is used as `*favoriteCoffee`. So `coffees` becomes `Latte, Cappuccino, Espresso`. While there are a few cases where anchors are useful, there is one aspect of them that can cause subtle bugs: The first time the YAML is consumed, the reference is expanded and then discarded. So if we were to decode and then re-encode the example above, the resulting YAML would be: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Because Helm and Kubernetes often read, modify, and then rewrite YAML files, the anchors will be lost. ================================================ FILE: docs/glossary/index.mdx ================================================ --- title: Glossary description: Terms used to describe components of Helm's architecture. sidebar_position: 10 --- # Glossary import Helm4 from "/docs/_v4-in-progress.mdx" ## Chart A Helm package that contains information sufficient for installing a set of Kubernetes resources into a Kubernetes cluster. Charts contain a `Chart.yaml` file as well as templates, default values (`values.yaml`), and dependencies. Charts are developed in a well-defined directory structure, and then packaged into an archive format called a _chart archive_. ## Chart Archive A _chart archive_ is a tarred and gzipped (and optionally signed) chart. ## Chart Dependency (Subcharts) Charts may depend upon other charts. There are two ways a dependency may occur: - Soft dependency: A chart may simply not function without another chart being installed in a cluster. Helm does not provide tooling for this case. In this case, dependencies may be managed separately. - Hard dependency: A chart may contain (inside of its `charts/` directory) another chart upon which it depends. In this case, installing the chart will install all of its dependencies. In this case, a chart and its dependencies are managed as a collection. When a chart is packaged (via `helm package`) all of its hard dependencies are bundled with it. ## Chart Version Charts are versioned according to the [SemVer 2 spec](https://semver.org). A version number is required on every chart. ## Chart.yaml Information about a chart is stored in a special file called `Chart.yaml`. Every chart must have this file. ## Helm (and helm) Helm is the package manager for Kubernetes. As an operating system package manager makes it easy to install tools on an OS, Helm makes it easy to install applications and resources into Kubernetes clusters. While _Helm_ is the name of the project, the command line client is also named `helm`. By convention, when speaking of the project, _Helm_ is capitalized. When speaking of the client, _helm_ is in lowercase. ## Helm Configuration Files (XDG) Helm stores its configuration files in XDG directories. These directories are created the first time `helm` is run. ## Kube Config (KUBECONFIG) The Helm client learns about Kubernetes clusters by using files in the _Kube config_ file format. By default, Helm attempts to find this file in the place where `kubectl` creates it (`$HOME/.kube/config`). ## Lint (Linting) To _lint_ a chart is to validate that it follows the conventions and requirements of the Helm chart standard. Helm provides tools to do this, notably the `helm lint` command. ## Provenance (Provenance file) Helm charts may be accompanied by a _provenance file_ which provides information about where the chart came from and what it contains. Provenance files are one part of the Helm security story. A provenance contains a cryptographic hash of the chart archive file, the Chart.yaml data, and a signature block (an OpenPGP "clearsign" block). When coupled with a keychain, this provides chart users with the ability to: - Validate that a chart was signed by a trusted party - Validate that the chart file has not been tampered with - Validate the contents of a chart metadata (`Chart.yaml`) - Quickly match a chart to its provenance data Provenance files have the `.prov` extension, and can be served from a chart repository server or any other HTTP server. ## Release When a chart is installed, the Helm library creates a _release_ to track that installation. A single chart may be installed many times into the same cluster, and create many different releases. For example, one can install three PostgreSQL databases by running `helm install` three times with a different release name. ## Release Number (Release Version) A single release can be updated multiple times. A sequential counter is used to track releases as they change. After a first `helm install`, a release will have _release number_ 1. Each time a release is upgraded or rolled back, the release number will be incremented. ## Rollback A release can be upgraded to a newer chart or configuration. But since release history is stored, a release can also be _rolled back_ to a previous release number. This is done with the `helm rollback` command. Importantly, a rolled back release will receive a new release number. | Operation | Release Number | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (but running the same config as release 1) | The above table illustrates how release numbers increment across install, upgrade, and rollback. ## Helm Library (or SDK) The Helm Library (or SDK) refers to the Go code that interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It can be imported into a project to use Helm as a client library instead of a CLI. ## Repository (Repo, Chart Repository) Helm charts may be stored on dedicated HTTP servers called _chart repositories_ (_repositories_, or just _repos_). A chart repository server is a simple HTTP server that can serve an `index.yaml` file that describes a batch of charts, and provides information on where each chart can be downloaded from. (Many chart repositories serve the charts as well as the `index.yaml` file.) A Helm client can point to zero or more chart repositories. By default, Helm clients are not configured with any chart repositories. Chart repositories can be added at any time using the `helm repo add` command. ## Chart Registry (OCI-based Registry) A Helm Chart Registry is an [OCI-based](https://opencontainers.org/about/overview/) storage and distribution system that is used to host and share Helm chart packages. For more information, see the [Helm documentation on registries](https://helm.sh/docs/topics/registries/). ## Values (Values Files, values.yaml) Values provide a way to override template defaults with your own information. Helm Charts are "parameterized", which means the chart developer may expose configuration that can be overridden at installation time. For example, a chart may expose a `username` field that allows setting a user name for a service. These exposed variables are called _values_ in Helm parlance. Values can be set during `helm install` and `helm upgrade` operations, either by passing them in directly, or by using a `values.yaml` file. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: docs/helm/helm.md ================================================ --- title: helm slug: helm --- The Helm package manager for Kubernetes. ### Synopsis The Kubernetes package manager Common actions for Helm: - helm search: search for charts - helm pull: download a chart to your local directory to view - helm install: upload the chart to Kubernetes - helm list: list releases of charts Environment variables: | Name | Description | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | set an alternative location for storing cached files. | | $HELM_CONFIG_HOME | set an alternative location for storing Helm configuration. | | $HELM_DATA_HOME | set an alternative location for storing Helm data. | | $HELM_DEBUG | indicate whether or not Helm is running in Debug mode | | $HELM_DRIVER | set the backend storage driver. Values are: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | set the connection string the SQL storage driver should use. | | $HELM_MAX_HISTORY | set the maximum number of helm release history. | | $HELM_NAMESPACE | set the namespace used for the helm operations. | | $HELM_NO_PLUGINS | disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins. | | $HELM_PLUGINS | set the path to the plugins directory | | $HELM_REGISTRY_CONFIG | set the path to the registry config file. | | $HELM_REPOSITORY_CACHE | set the path to the repository cache directory | | $HELM_REPOSITORY_CONFIG | set the path to the repositories file. | | $KUBECONFIG | set an alternative Kubernetes configuration file (default "~/.kube/config") | | $HELM_KUBEAPISERVER | set the Kubernetes API Server Endpoint for authentication | | $HELM_KUBECAFILE | set the Kubernetes certificate authority file. | | $HELM_KUBEASGROUPS | set the Groups to use for impersonation using a comma-separated list. | | $HELM_KUBEASUSER | set the Username to impersonate for the operation. | | $HELM_KUBECONTEXT | set the name of the kubeconfig context. | | $HELM_KUBETOKEN | set the Bearer KubeToken used for authentication. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indicate if the Kubernetes API server's certificate validation should be skipped (insecure) | | $HELM_KUBETLS_SERVER_NAME | set the server name used to validate the Kubernetes API server certificate | | $HELM_BURST_LIMIT | set the default burst limit in the case the server contains many CRDs (default 100, -1 to disable) | | $HELM_QPS | set the Queries Per Second in cases where a high number of calls exceed the option for higher burst values | | $HELM_COLOR | set color output mode. Allowed values: never, always, auto (default: never) | | $NO_COLOR | set to any non-empty value to disable all colored output (overrides $HELM_COLOR) | Helm stores cache, configuration, and data based on the following configuration order: - If a HELM_*_HOME environment variable is set, it will be used - Otherwise, on systems supporting the XDG base directory specification, the XDG variables will be used - When no other location is set a default location will be used based on the operating system By default, the default directories depend on the Operating System. The defaults are listed below: | Operating System | Cache Path | Configuration Path | Data Path | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Options ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell * [helm create](/helm/helm_create.md) - create a new chart with the given name * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies * [helm env](/helm/helm_env.md) - helm client environment information * [helm get](/helm/helm_get.md) - download extended information of a named release * [helm history](/helm/helm_history.md) - fetch release history * [helm install](/helm/helm_install.md) - install a chart * [helm lint](/helm/helm_lint.md) - examine a chart for possible issues * [helm list](/helm/helm_list.md) - list releases * [helm package](/helm/helm_package.md) - package a chart directory into a chart archive * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins * [helm pull](/helm/helm_pull.md) - download a chart from a repository and (optionally) unpack it in local directory * [helm push](/helm/helm_push.md) - push a chart to remote * [helm registry](/helm/helm_registry.md) - login to or logout from a registry * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories * [helm rollback](/helm/helm_rollback.md) - roll back a release to a previous revision * [helm search](/helm/helm_search.md) - search for a keyword in charts * [helm show](/helm/helm_show.md) - show information of a chart * [helm status](/helm/helm_status.md) - display the status of the named release * [helm template](/helm/helm_template.md) - locally render templates * [helm test](/helm/helm_test.md) - run tests for a release * [helm uninstall](/helm/helm_uninstall.md) - uninstall a release * [helm upgrade](/helm/helm_upgrade.md) - upgrade a release * [helm verify](/helm/helm_verify.md) - verify that a chart at the given path has been signed and is valid * [helm version](/helm/helm_version.md) - print the helm version information ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_completion.md ================================================ --- title: helm completion --- generate autocompletion scripts for the specified shell ### Synopsis Generate autocompletion scripts for Helm for the specified shell. ### Options ``` -h, --help help for completion ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) - generate autocompletion script for bash * [helm completion fish](/helm/helm_completion_fish.md) - generate autocompletion script for fish * [helm completion powershell](/helm/helm_completion_powershell.md) - generate autocompletion script for powershell * [helm completion zsh](/helm/helm_completion_zsh.md) - generate autocompletion script for zsh ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- generate autocompletion script for bash ### Synopsis Generate the autocompletion script for Helm for the bash shell. To load completions in your current shell session: source <(helm completion bash) To load completions for every new session, execute once: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Options ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- generate autocompletion script for fish ### Synopsis Generate the autocompletion script for Helm for the fish shell. To load completions in your current shell session: helm completion fish | source To load completions for every new session, execute once: helm completion fish > ~/.config/fish/completions/helm.fish You will need to start a new shell for this setup to take effect. ``` helm completion fish [flags] ``` ### Options ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- generate autocompletion script for powershell ### Synopsis Generate the autocompletion script for powershell. To load completions in your current shell session: PS C:\> helm completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` helm completion powershell [flags] ``` ### Options ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- generate autocompletion script for zsh ### Synopsis Generate the autocompletion script for Helm for the zsh shell. To load completions in your current shell session: source <(helm completion zsh) To load completions for every new session, execute once: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Options ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_create.md ================================================ --- title: helm create --- create a new chart with the given name ### Synopsis This command creates a chart directory along with the common files and directories used in a chart. For example, 'helm create foo' will create a directory structure that looks something like this: foo/ ├── .helmignore # Contains patterns to ignore when packaging Helm charts. ├── Chart.yaml # Information about your chart ├── values.yaml # The default values for your templates ├── charts/ # Charts that this chart depends on └── templates/ # The template files └── tests/ # The test files 'helm create' takes a path for an argument. If directories in the given path do not exist, Helm will attempt to create them as it goes. If the given destination exists and there are files in that directory, conflicting files will be overwritten, but other files will be left alone. ``` helm create NAME [flags] ``` ### Options ``` -h, --help help for create -p, --starter string the name or absolute path to Helm starter scaffold ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_dependency.md ================================================ --- title: helm dependency --- manage a chart's dependencies ### Synopsis Manage the dependencies of a chart. Helm charts store their dependencies in 'charts/'. For chart developers, it is often easier to manage dependencies in 'Chart.yaml' which declares all dependencies. The dependency commands operate on that file, making it easy to synchronize between the desired dependencies and the actual dependencies stored in the 'charts/' directory. For example, this Chart.yaml declares two dependencies: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" The 'name' should be the name of a chart, where that name must match the name in that chart's 'Chart.yaml' file. The 'version' field should contain a semantic version or version range. The 'repository' URL should point to a Chart Repository. Helm expects that by appending '/index.yaml' to the URL, it should be able to retrieve the chart repository's index. Note: 'repository' can be an alias. The alias must start with 'alias:' or '@'. Starting from 2.2.0, repository can be defined as the path to the directory of the dependency charts stored locally. The path should start with a prefix of "file://". For example, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" If the dependency chart is retrieved locally, it is not required to have the repository added to helm by "helm add repo". Version matching is also supported for this case. ### Options ``` -h, --help help for dependency ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - rebuild the charts/ directory based on the Chart.lock file * [helm dependency list](/helm/helm_dependency_list.md) - list the dependencies for the given chart * [helm dependency update](/helm/helm_dependency_update.md) - update charts/ based on the contents of Chart.yaml ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- rebuild the charts/ directory based on the Chart.lock file ### Synopsis Build out the charts/ directory from the Chart.lock file. Build is used to reconstruct a chart's dependencies to the state specified in the lock file. This will not re-negotiate dependencies, as 'helm dependency update' does. If no lock file is found, 'helm dependency build' will mirror the behavior of 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- list the dependencies for the given chart ### Synopsis List all of the dependencies declared in a chart. This can take chart archives and chart directories as input. It will not alter the contents of a chart. This will produce an error if the chart cannot be loaded. ``` helm dependency list CHART [flags] ``` ### Options ``` -h, --help help for list --max-col-width uint maximum column width for output table (default 80) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- update charts/ based on the contents of Chart.yaml ### Synopsis Update the on-disk dependencies to mirror Chart.yaml. This command verifies that the required charts, as expressed in 'Chart.yaml', are present in 'charts/' and are at an acceptable version. It will pull down the latest charts that satisfy the dependencies, and clean up old dependencies. On successful update, this will generate a lock file that can be used to rebuild the dependencies to an exact version. Dependencies are not required to be represented in 'Chart.yaml'. For that reason, an update command will not remove charts unless they are (a) present in the Chart.yaml file, but (b) at the wrong version. ``` helm dependency update CHART [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_env.md ================================================ --- title: helm env --- helm client environment information ### Synopsis Env prints out all the environment information in use by Helm. ``` helm env [flags] ``` ### Options ``` -h, --help help for env ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get.md ================================================ --- title: helm get --- download extended information of a named release ### Synopsis This command consists of multiple subcommands which can be used to get extended information about the release, including: - The values used to generate the release - The generated manifest file - The notes provided by the chart of the release - The hooks associated with the release - The metadata of the release ### Options ``` -h, --help help for get ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm get all](/helm/helm_get_all.md) - download all information for a named release * [helm get hooks](/helm/helm_get_hooks.md) - download all hooks for a named release * [helm get manifest](/helm/helm_get_manifest.md) - download the manifest for a named release * [helm get metadata](/helm/helm_get_metadata.md) - This command fetches metadata for a given release * [helm get notes](/helm/helm_get_notes.md) - download the notes for a named release * [helm get values](/helm/helm_get_values.md) - download the values file for a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_all.md ================================================ --- title: helm get all --- download all information for a named release ### Synopsis This command prints a human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. ``` helm get all RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- download all hooks for a named release ### Synopsis This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. ``` helm get hooks RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for hooks --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- download the manifest for a named release ### Synopsis This command fetches the generated manifest for a given release. A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. ``` helm get manifest RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for manifest --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- This command fetches metadata for a given release ``` helm get metadata RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_notes.md ================================================ --- title: helm get notes --- download the notes for a named release ### Synopsis This command shows notes provided by the chart of a named release. ``` helm get notes RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for notes --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_get_values.md ================================================ --- title: helm get values --- download the values file for a named release ### Synopsis This command downloads a values file for a given release. ``` helm get values RELEASE_NAME [flags] ``` ### Options ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_history.md ================================================ --- title: helm history --- fetch release history ### Synopsis History prints historical revisions for a given release. A default maximum of 256 revisions will be returned. Setting '--max' configures the maximum length of the revision list returned. The historical release set is printed as a formatted table, e.g: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for history --max int maximum number of revision to include in history (default 256) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_install.md ================================================ --- title: helm install --- install a chart ### Synopsis This command installs a chart archive. The install argument must be a chart reference, a path to a packaged chart, a path to an unpacked chart directory or a URL. To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line, to force a string value use '--set-string'. You can use '--set-file' to set individual values from a file when the value itself is too long for the command line or is dynamically generated. You can also use '--set-json' to set json values (scalars/objects/arrays) from the command line. Additionally, you can use '--set-json' and passing json object as a string. $ helm install -f myvalues.yaml myredis ./redis or $ helm install --set name=prod myredis ./redis or $ helm install --set-string long_int=1234567890 myredis ./redis or $ helm install --set-file my_script=dothings.sh myredis ./redis or $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis or $ helm install --set-json '{"master":{"sidecars":[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]}}' myredis ./redis You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis You can specify the '--set' flag multiple times. The priority will be given to the last (right-most) set specified. For example, if both 'bar' and 'newbar' values are set for a key called 'foo', the 'newbar' value would take precedence: $ helm install --set foo=bar --set foo=newbar myredis ./redis Similarly, in the following example 'foo' is set to '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis And in the following example, 'foo' is set to '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis To check the generated manifests of a release without installing the chart, the --debug and --dry-run flags can be combined. The --dry-run flag will output all generated chart manifests, including Secrets which can contain sensitive values. To hide Kubernetes Secrets use the --hide-secret flag. Please carefully consider how and when these flags are used. If --verify is set, the chart MUST have a provenance file, and the provenance file MUST pass all verification steps. There are six different ways you can express the chart you want to install: 1. By chart reference: helm install mymaria example/mariadb 2. By path to a packaged chart: helm install mynginx ./nginx-1.2.3.tgz 3. By path to an unpacked chart directory: helm install mynginx ./nginx 4. By absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. By chart reference and repo url: helm install --repo https://example.com/charts/ mynginx nginx 6. By OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx CHART REFERENCES A chart reference is a convenient way of referencing a chart in a chart repository. When you use a chart reference with a repo prefix ('example/mariadb'), Helm will look in the local configuration for a chart repository named 'example', and will then look for a chart in that repository whose name is 'mariadb'. It will install the latest stable version of that chart until you specify '--devel' flag to also include development version (alpha, beta, and release candidate releases), or supply a version number with the '--version' flag. To see the list of chart repositories, use 'helm repo list'. To search for charts in a repository, use 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="unset"] simulates the operation without persisting changes. Must be one of: "none" (default), "client", or "server". '--dry-run=none' executes the operation normally and persists changes (no simulation). '--dry-run=client' simulates the operation client-side only and avoids cluster connections. '--dry-run=server' simulates the operation on the server, requiring cluster connectivity. (default "none") --enable-dns enable DNS lookups when rendering templates --force-conflicts if set server-side apply will force changes against conflicts --force-replace force resource updates by replacement -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace reuse the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --rollback-on-failure if set, Helm will rollback (uninstall) the installation upon failure. The --wait flag will be default to "watcher" if --rollback-on-failure is set --server-side object updates run in the server instead of the client (default true) --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2 or using json format: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait WaitStrategy[=watcher] if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly) --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_lint.md ================================================ --- title: helm lint --- examine a chart for possible issues ### Synopsis This command takes a path to a chart and runs a series of tests to verify that the chart is well-formed. If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages. ``` helm lint PATH [flags] ``` ### Options ``` -h, --help help for lint --kube-version string Kubernetes version used for capabilities and deprecation checks --quiet print only warnings and errors --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2 or using json format: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-schema-validation if set, disables JSON schema validation --strict fail on lint warnings -f, --values strings specify values in a YAML file or a URL (can specify multiple) --with-subcharts lint dependent charts ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_list.md ================================================ --- title: helm list --- list releases ### Synopsis This command lists all of the releases for a specified namespace (uses current namespace context if namespace not specified). By default, it lists all releases in any status. Individual status filters like '--deployed', '--failed', '--pending', '--uninstalled', '--superseded', and '--uninstalling' can be used to show only releases in specific states. Such flags can be combined: '--deployed --failed'. By default, items are sorted alphabetically. Use the '-d' flag to sort by release date. If the --filter flag is provided, it will be treated as a filter. Filters are regular expressions (Perl compatible) that are applied to the list of releases. Only items that match the filter will be returned. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 If no results are found, 'helm list' will exit 0, but with no output (or in the case of no '-q' flag, only headers). By default, up to 256 items may be returned. To limit this, use the '--max' flag. Setting '--max' to 0 will not return all results. Rather, it will return the server's default, which may be much higher than 256. Pairing the '--max' flag with the '--offset' flag allows you to page through results. ``` helm list [flags] ``` ### Options ``` -A, --all-namespaces list releases across all namespaces -d, --date sort by release date --deployed show deployed releases --failed show failed releases -f, --filter string a regular expression (Perl compatible). Any releases that match the expression will be included in the results -h, --help help for list -m, --max int maximum number of releases to fetch (default 256) --no-headers don't print headers when using the default output format --offset int next release index in the list, used to offset from start value -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pending show pending releases -r, --reverse reverse the sort order -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Works only for secret(default) and configmap storage backends. -q, --short output short (quiet) listing format --superseded show superseded releases --time-format string format time using golang time formatter. Example: --time-format "2006-01-02 15:04:05Z0700" --uninstalled show uninstalled releases (if 'helm uninstall --keep-history' was used) --uninstalling show releases that are currently being uninstalled ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_package.md ================================================ --- title: helm package --- package a chart directory into a chart archive ### Synopsis This command packages a chart into a versioned chart archive file. If a path is given, this will look at that path for a chart (which must contain a Chart.yaml file) and then package that directory. Versioned chart archives are used by Helm package repositories. To sign a chart, use the '--sign' flag. In most cases, you should also provide '--keyring path/to/secret/keys' and '--key keyname'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg If '--keyring' is not specified, Helm usually defaults to the public keyring unless your environment is otherwise configured. ``` helm package [CHART_PATH] [...] [flags] ``` ### Options ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin.md ================================================ --- title: helm plugin --- install, list, or uninstall Helm plugins ### Synopsis Manage client-side Helm plugins. ### Options ``` -h, --help help for plugin ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) - install a Helm plugin * [helm plugin list](/helm/helm_plugin_list.md) - list installed Helm plugins * [helm plugin package](/helm/helm_plugin_package.md) - package a plugin directory into a plugin archive * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - uninstall one or more Helm plugins * [helm plugin update](/helm/helm_plugin_update.md) - update one or more Helm plugins * [helm plugin verify](/helm/helm_plugin_verify.md) - verify that a plugin at the given path has been signed and is valid ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- install a Helm plugin ### Synopsis This command allows you to install a plugin from a url to a VCS repo or a local path. By default, plugin signatures are verified before installation when installing from tarballs (.tgz or .tar.gz). This requires a corresponding .prov file to be available alongside the tarball. For local development, plugins installed from local directories are automatically treated as "local dev" and do not require signatures. Use --verify=false to skip signature verification for remote plugins. ``` helm plugin install [options] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for install --insecure-skip-tls-verify skip tls certificate checks for the plugin download --key-file string identify registry client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --password string registry password --plain-http use insecure HTTP connections for the plugin download --username string registry username --verify verify the plugin signature before installing (default true) --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- list installed Helm plugins ``` helm plugin list [flags] ``` ### Options ``` -h, --help help for list --type string Plugin type ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_package.md ================================================ --- title: helm plugin package --- package a plugin directory into a plugin archive ### Synopsis This command packages a Helm plugin directory into a tarball. By default, the command will generate a provenance file signed with a PGP key. This ensures the plugin can be verified after installation. Use --sign=false to skip signing (not recommended for distribution). ``` helm plugin package [PATH] [flags] ``` ### Options ``` -d, --destination string location to write the plugin tarball. (default ".") -h, --help help for package --key string name of the key to use when signing. Used if --sign is true --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" to read from stdin. --sign use a PGP private key to sign this plugin (default true) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- uninstall one or more Helm plugins ``` helm plugin uninstall ... [flags] ``` ### Options ``` -h, --help help for uninstall ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- update one or more Helm plugins ``` helm plugin update ... [flags] ``` ### Options ``` -h, --help help for update ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_plugin_verify.md ================================================ --- title: helm plugin verify --- verify that a plugin at the given path has been signed and is valid ### Synopsis This command verifies that a Helm plugin has a valid provenance file, and that the provenance file is signed by a trusted PGP key. It supports both: - Plugin tarballs (.tgz or .tar.gz files) - Installed plugin directories For installed plugins, use the path shown by 'helm env HELM_PLUGINS' followed by the plugin name. For example: helm plugin verify ~/.local/share/helm/plugins/example-cli To generate a signed plugin, use the 'helm plugin package --sign' command. ``` helm plugin verify [PATH] [flags] ``` ### Options ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_pull.md ================================================ --- title: helm pull --- download a chart from a repository and (optionally) unpack it in local directory ### Synopsis Retrieve a package from a package repository, and download it locally. This is useful for fetching packages to inspect, modify, or repackage. It can also be used to perform cryptographic verification of a chart without installing the chart. There are options for unpacking the chart after download. This will create a directory for the chart and uncompress into that directory. If the --verify flag is specified, the requested chart MUST have a provenance file, and MUST pass the verification process. Failure in any part of this will result in an error, and the chart will not be saved locally. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_push.md ================================================ --- title: helm push --- push a chart to remote ### Synopsis Upload a chart to a registry. If the chart has an associated provenance file, it will also be uploaded. ``` helm push [chart] [remote] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_registry.md ================================================ --- title: helm registry --- login to or logout from a registry ### Synopsis This command consists of multiple subcommands to interact with registries. ### Options ``` -h, --help help for registry ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm registry login](/helm/helm_registry_login.md) - login to a registry * [helm registry logout](/helm/helm_registry_logout.md) - logout from a registry ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_registry_login.md ================================================ --- title: helm registry login --- login to a registry ### Synopsis Authenticate to a remote registry. For example for Github Container Registry: echo "$GITHUB_TOKEN" | helm registry login ghcr.io -u $GITHUB_USER --password-stdin ``` helm registry login [host] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm registry](/helm/helm_registry.md) - login to or logout from a registry ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- logout from a registry ### Synopsis Remove credentials stored for a remote registry. ``` helm registry logout [host] [flags] ``` ### Options ``` -h, --help help for logout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm registry](/helm/helm_registry.md) - login to or logout from a registry ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo.md ================================================ --- title: helm repo --- add, list, remove, update, and index chart repositories ### Synopsis This command consists of multiple subcommands to interact with chart repositories. It can be used to add, remove, list, and index chart repositories. ### Options ``` -h, --help help for repo ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm repo add](/helm/helm_repo_add.md) - add a chart repository * [helm repo index](/helm/helm_repo_index.md) - generate an index file given a directory containing packaged charts * [helm repo list](/helm/helm_repo_list.md) - list chart repositories * [helm repo remove](/helm/helm_repo_remove.md) - remove one or more chart repositories * [helm repo update](/helm/helm_repo_update.md) - update information of available charts locally from chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo_add.md ================================================ --- title: helm repo add --- add a chart repository ``` helm repo add [NAME] [URL] [flags] ``` ### Options ``` --allow-deprecated-repos by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --force-update replace (overwrite) the repo if it already exists -h, --help help for add --insecure-skip-tls-verify skip tls certificate checks for the repository --key-file string identify HTTPS client using this SSL key file --pass-credentials pass credentials to all domains --password string chart repository password --password-stdin read chart repository password from stdin --timeout duration time to wait for the index file download to complete (default 2m0s) --username string chart repository username ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo_index.md ================================================ --- title: helm repo index --- generate an index file given a directory containing packaged charts ### Synopsis Read the current directory, generate an index file based on the charts found and write the result to 'index.yaml' in the current directory. This tool is used for creating an 'index.yaml' file for a chart repository. To set an absolute URL to the charts, use '--url' flag. To merge the generated index with an existing index file, use the '--merge' flag. In this case, the charts found in the current directory will be merged into the index passed in with --merge, with local charts taking priority over existing charts. ``` helm repo index [DIR] [flags] ``` ### Options ``` -h, --help help for index --json output in JSON format --merge string merge the generated index into the given index --url string url of chart repository ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo_list.md ================================================ --- title: helm repo list --- list chart repositories ``` helm repo list [flags] ``` ### Options ``` -h, --help help for list --no-headers suppress headers in the output -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- remove one or more chart repositories ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` -h, --help help for remove ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_repo_update.md ================================================ --- title: helm repo update --- update information of available charts locally from chart repositories ### Synopsis Update gets the latest information about charts from the respective chart repositories. Information is cached locally, where it is used by commands like 'helm search'. You can optionally specify a list of repositories you want to update. $ helm repo update ... To update all the repositories, use 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` -h, --help help for update --timeout duration time to wait for the index file download to complete (default 2m0s) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_rollback.md ================================================ --- title: helm rollback --- roll back a release to a previous revision ### Synopsis This command rolls back a release to a previous revision. The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release. To see revision numbers, run 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Options ``` --cleanup-on-fail allow deletion of new resources created in this rollback when rollback fails --dry-run string[="unset"] simulates the operation without persisting changes. Must be one of: "none" (default), "client", or "server". '--dry-run=none' executes the operation normally and persists changes (no simulation). '--dry-run=client' simulates the operation client-side only and avoids cluster connections. '--dry-run=server' simulates the operation on the server, requiring cluster connectivity. (default "none") --force-conflicts if set server-side apply will force changes against conflicts --force-replace force resource updates by replacement -h, --help help for rollback --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --no-hooks prevent hooks from running during rollback --server-side string must be "true", "false" or "auto". Object updates run in the server instead of the client ("auto" defaults the value from the previous chart release's method) (default "auto") --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait WaitStrategy[=watcher] if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly) --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_search.md ================================================ --- title: helm search --- search for a keyword in charts ### Synopsis Search provides the ability to search for Helm charts in the various places they can be stored including the Artifact Hub and repositories you have added. Use search subcommands to search different locations for charts. ### Options ``` -h, --help help for search ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm search hub](/helm/helm_search_hub.md) - search for charts in the Artifact Hub or your own hub instance * [helm search repo](/helm/helm_search_repo.md) - search repositories for a keyword in charts ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_search_hub.md ================================================ --- title: helm search hub --- search for charts in the Artifact Hub or your own hub instance ### Synopsis Search for Helm charts in the Artifact Hub or your own hub instance. Artifact Hub is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects, including publicly available distributed charts Helm charts. It is a Cloud Native Computing Foundation sandbox project. You can browse the hub at https://artifacthub.io/ The [KEYWORD] argument accepts either a keyword string, or quoted string of rich query options. For rich query options documentation, see https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Previous versions of Helm used an instance of Monocular as the default 'endpoint', so for backwards compatibility Artifact Hub is compatible with the Monocular search API. Similarly, when setting the 'endpoint' flag, the specified endpoint must also be implement a Monocular compatible search API endpoint. Note that when specifying a Monocular instance as the 'endpoint', rich queries are not supported. For API details, see https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Options ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm search](/helm/helm_search.md) - search for a keyword in charts ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_search_repo.md ================================================ --- title: helm search repo --- search repositories for a keyword in charts ### Synopsis Search reads through all of the repositories configured on the system, and looks for matches. Search of these repositories uses the metadata stored on the system. It will display the latest stable versions of the charts found. If you specify the --devel flag, the output will include pre-release versions. If you want to search using a version constraint, use --version. Examples: # Search for stable release versions matching the keyword "nginx" $ helm search repo nginx # Search for release versions matching the keyword "nginx", including pre-release versions $ helm search repo nginx --devel # Search for the latest stable release for nginx-ingress with a major version of 1 $ helm search repo nginx-ingress --version ^1.0.0 Repositories are managed with 'helm repo' commands. ``` helm search repo [keyword] [flags] ``` ### Options ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm search](/helm/helm_search.md) - search for a keyword in charts ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show.md ================================================ --- title: helm show --- show information of a chart ### Synopsis This command consists of multiple subcommands to display information about a chart ### Options ``` -h, --help help for show ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm show all](/helm/helm_show_all.md) - show all information of the chart * [helm show chart](/helm/helm_show_chart.md) - show the chart's definition * [helm show crds](/helm/helm_show_crds.md) - show the chart's CRDs * [helm show readme](/helm/helm_show_readme.md) - show the chart's README * [helm show values](/helm/helm_show_values.md) - show the chart's values ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show_all.md ================================================ --- title: helm show all --- show all information of the chart ### Synopsis This command inspects a chart (directory, file, or URL) and displays all its content (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show_chart.md ================================================ --- title: helm show chart --- show the chart's definition ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the Chart.yaml file ``` helm show chart [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show_crds.md ================================================ --- title: helm show crds --- show the chart's CRDs ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the CustomResourceDefinition files ``` helm show crds [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show_readme.md ================================================ --- title: helm show readme --- show the chart's README ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the README file ``` helm show readme [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_show_values.md ================================================ --- title: helm show values --- show the chart's values ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the values.yaml file ``` helm show values [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_status.md ================================================ --- title: helm status --- display the status of the named release ### Synopsis This command shows the status of a named release. The status consists of: - last deployment time - k8s namespace in which the release lives - state of the release (can be: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback) - revision of the release - description of the release (can be completion message or error message) - list of resources that this release consists of - details on last test suite run, if applicable - additional notes provided by the chart ``` helm status RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_template.md ================================================ --- title: helm template --- locally render templates ### Synopsis Render chart templates locally and display the output. Any values that would normally be looked up or retrieved in-cluster will be faked locally. Additionally, none of the server-side testing of chart validity (e.g. whether an API is supported) is done. To specify the Kubernetes API versions used for Capabilities.APIVersions, use the '--api-versions' flag. This flag can be specified multiple times or as a comma-separated list: $ helm template --api-versions networking.k8s.io/v1 --api-versions cert-manager.io/v1 mychart ./mychart or $ helm template --api-versions networking.k8s.io/v1,cert-manager.io/v1 mychart ./mychart ``` helm template [NAME] [CHART] [flags] ``` ### Options ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions (multiple can be specified) --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="unset"] simulates the operation either client-side or server-side. Must be either: "client", or "server". '--dry-run=client simulates the operation client-side only and avoids cluster connections. '--dry-run=server' simulates/validates the operation on the server, requiring cluster connectivity. (default "client") --enable-dns enable DNS lookups when rendering templates --force-conflicts if set server-side apply will force changes against conflicts --force-replace force resource updates by replacement -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace reuse the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --rollback-on-failure if set, Helm will rollback (uninstall) the installation upon failure. The --wait flag will be default to "watcher" if --rollback-on-failure is set --server-side object updates run in the server instead of the client (default true) --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2 or using json format: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait WaitStrategy[=watcher] if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly) --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_test.md ================================================ --- title: helm test --- run tests for a release ### Synopsis The test command runs the tests for a release. The argument this command takes is the name of a deployed release. The tests to be run are defined in the chart that was installed. ``` helm test [RELEASE] [flags] ``` ### Options ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- uninstall a release ### Synopsis This command takes a release name and uninstalls the release. It removes all of the resources associated with the last release of the chart as well as the release history, freeing it up for future use. Use the '--dry-run' flag to see which releases will be uninstalled without actually uninstalling them. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Options ``` --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run simulate a uninstall -h, --help help for uninstall --ignore-not-found Treat "release not found" as a successful uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --no-hooks prevent hooks from running during uninstallation --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait WaitStrategy[=watcher] if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- upgrade a release ### Synopsis This command upgrades a release to a new version of a chart. The upgrade arguments must be a release and chart. The chart argument can be either: a chart reference('example/mariadb'), a path to a chart directory, a packaged chart, or a fully qualified URL. For chart references, the latest version will be specified unless the '--version' flag is set. To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line, to force string values, use '--set-string'. You can use '--set-file' to set individual values from a file when the value itself is too long for the command line or is dynamically generated. You can also use '--set-json' to set json values (scalars/objects/arrays) from the command line. Additionally, you can use '--set-json' and passing json object as a string. You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis You can specify the '--set' flag multiple times. The priority will be given to the last (right-most) set specified. For example, if both 'bar' and 'newbar' values are set for a key called 'foo', the 'newbar' value would take precedence: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis You can update the values for an existing release with this command as well via the '--reuse-values' flag. The 'RELEASE' and 'CHART' arguments should be set to the original parameters, and existing values will be merged with any values set via '--values'/'-f' or '--set' flags. Priority is given to new values. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis The --dry-run flag will output all generated chart manifests, including Secrets which can contain sensitive values. To hide Kubernetes Secrets use the --hide-secret flag. Please carefully consider how and when these flags are used. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="unset"] simulates the operation without persisting changes. Must be one of: "none" (default), "client", or "server". '--dry-run=none' executes the operation normally and persists changes (no simulation). '--dry-run=client' simulates the operation client-side only and avoids cluster connections. '--dry-run=server' simulates the operation on the server, requiring cluster connectivity. (default "none") --enable-dns enable DNS lookups when rendering templates --force-conflicts if set server-side apply will force changes against conflicts --force-replace force resource updates by replacement -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the name of a postrenderer type plugin to be used for post rendering. If it exists, the plugin will be used --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --rollback-on-failure if set, Helm will rollback the upgrade to previous success release upon failure. The --wait flag will be defaulted to "watcher" if --rollback-on-failure is set --server-side string must be "true", "false" or "auto". Object updates run in the server instead of the client ("auto" defaults the value from the previous chart release's method) (default "auto") --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2 or using json format: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait WaitStrategy[=watcher] if specified, wait until resources are ready (up to --timeout). Values: 'watcher', 'hookOnly', and 'legacy'. (default hookOnly) --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_verify.md ================================================ --- title: helm verify --- verify that a chart at the given path has been signed and is valid ### Synopsis Verify that the given chart has a valid provenance file. Provenance files provide cryptographic verification that a chart has not been tampered with, and was packaged by a trusted provider. This command can be used to verify a local chart. Several other commands provide '--verify' flags that run the same validation. To generate a signed package, use the 'helm package --sign' command. ``` helm verify PATH [flags] ``` ### Options ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/helm_version.md ================================================ --- title: helm version --- print the helm version information ### Synopsis Show the version for Helm. This will print a representation the version of Helm. The output will look something like this: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version is the semantic version of the release. - GitCommit is the SHA for the commit that this version was built from. - GitTreeState is "clean" if there are no local code changes when this binary was built, and "dirty" if the binary was built from locally modified code. - GoVersion is the version of Go that was used to compile Helm. When using the --template flag the following properties are available to use in the template: - .Version contains the semantic version of Helm - .GitCommit is the git commit - .GitTreeState is the state of the git tree when Helm was built - .GoVersion contains the version of Go that Helm was compiled with For example, --template='Version: {{.Version}}' outputs 'Version: v3.2.1'. ``` helm version [flags] ``` ### Options ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --color string use colored output (never, auto, always) (default "auto") --colour string use colored output (never, auto, always) (default "auto") --content-cache string path to the directory containing cached content (e.g. charts) (default "~/.cache/helm/content") --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 9-Feb-2026 ================================================ FILE: docs/helm/index.mdx ================================================ --- title: Helm Commands description: Documentation for the full list of helm CLI commands. sidebar_position: 6 id: helm-category --- # Helm Commands Here you'll find the list of CLI commands for Helm, with help info on their usage. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action to Automate GitHub Page Charts description: Describe how to use Chart Releaser Action to automate releasing charts through GitHub pages. sidebar_position: 3 --- This guide describes how to use [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) to automate releasing charts through GitHub pages. Chart Releaser Action is a GitHub Action workflow to turn a GitHub project into a self-hosted Helm chart repo, using [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool. ## Repository Changes Create a Git repository under your GitHub organization. You could give the name of the repository as `helm-charts`, though other names are also acceptable. The sources of all the charts can be placed under the `main` branch. The charts should be placed under `/charts` directory at the top-level of the directory tree. There should be another branch named `gh-pages` to publish the charts. The changes to that branch will be automatically created by the Chart Releaser Action described here. However, you can create that `gh-branch` and add `README.md` file, which is going to be visible to the users visiting the page. You can add instruction in the `README.md` for charts installation like this (replace ``, ``, and ``): ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` The charts will be published to a website with URL like this: https://.github.io/helm-charts ## GitHub Actions Workflow Create GitHub Actions workflow file in the `main` branch at `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` The above configuration uses [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) to turn your GitHub project into a self-hosted Helm chart repo. It does this - during every push to main - by checking each chart in your project, and whenever there's a new chart version, creates a corresponding GitHub release named for the chart version, adds Helm chart artifacts to the release, and creates or updates an `index.yaml` file with metadata about those releases, which is then hosted on GitHub pages. The Chart Releaser Action version number used in the above example is `v1.6.0`. You can change it to the [latest available version](https://github.com/helm/chart-releaser-action/releases). Note: The Chart Releaser Action is almost always used in tandem with the [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) and [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: docs/howto/chart_repository_sync_example.md ================================================ --- title: Syncing Your Chart Repository description: Describes how to synchronize your local and remote chart repositories. sidebar_position: 2 --- *Note: This example is specifically for a Google Cloud Storage (GCS) bucket which serves a chart repository.* ## Prerequisites * Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We rely heavily on the gsutil rsync functionality* * Be sure to have access to the Helm binary * _Optional: We recommend you set [object versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) on your GCS bucket in case you accidentally delete something._ ## Set up a local chart repository directory Create a local directory like we did in [the chart repository guide](/topics/chart_repository.md), and place your packaged charts in that directory. For example: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Generate an updated index.yaml Use Helm to generate an updated index.yaml file by passing in the directory path and the url of the remote repository to the `helm repo index` command like this: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` This will generate an updated index.yaml file and place it in the `fantastic-charts/` directory. ## Sync your local and remote chart repositories Upload the contents of the directory to your GCS bucket by running `scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket name. For example: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Updating your chart repository You'll want to keep a local copy of the contents of your chart repository or use `gsutil rsync` to copy the contents of your remote chart repository to a local directory. For example: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Helpful Links: * Documentation on [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [The Chart Repository Guide](/topics/chart_repository.md) * Documentation on [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage ================================================ FILE: docs/howto/charts_tips_and_tricks.md ================================================ --- title: Chart Development Tips and Tricks description: Covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. sidebar_position: 1 --- This guide covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. ## Know Your Template Functions Helm uses [Go templates](https://godoc.org/text/template) for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added all of the functions in the [Sprig library](https://masterminds.github.io/sprig/), except `env` and `expandenv`, for security reasons. We also added two special template functions: `include` and `required`. The `include` function allows you to bring in another template, and then pass the results to other template functions. The `required` function allows you to declare a particular values entry as required for template rendering. If the value is empty, the template rendering will fail with a user submitted error message. ### Using the 'include' Function Go provides a way of including one template in another using a built-in `template` directive. However, the built-in function cannot be used in Go template pipelines. To make it possible to include a template, and then perform an operation on that template's output, Helm has a special `include` function: ``` {{ include "toYaml" $value | indent 2 }} ``` The above includes a template called `toYaml`, passes it `$value`, and then passes the output of that template to the `indent` function. Because YAML ascribes significance to indentation levels and whitespace, this is one great way to include snippets of code, but handle indentation in a relevant context. This template snippet includes a template called `mytpl`, then lowercases the result, then wraps that in double quotes. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` ### Using the 'required' function Go provides a `missingkey` template option to control behavior when a map is indexed with a key that's not present in the map. There may be situations where a chart developer wants to enforce this behavior for select values in the `values.yaml` file. The `required` function gives developers the ability to declare a value entry as required for template rendering. If the entry is empty in `values.yaml`, the template will not render and will return an error message supplied by the developer. For example: ``` {{ required "A valid foo is required!" .Values.foo }} ``` The above will render the template when `.Values.foo` is defined, but will fail to render and exit when `.Values.foo` is undefined. The following example of the `required` function declares an entry for `.Values.who` is required, and will print an error message when that entry is missing: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Quote Strings, Don't Quote Integers When you are working with string data, you are always safer quoting the strings than leaving them as bare words: ```yaml name: {{ .Values.MyName | quote }} ``` But when working with integers _do not quote the values._ That can, in many cases, cause parsing errors inside of Kubernetes. ```yaml port: {{ .Values.Port }} ``` This remark does not apply to env variables values which are expected to be string, even if they represent integers: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Using the 'tpl' Function The `tpl` function allows developers to evaluate strings as templates inside a template. This is useful to pass a template string as a value to a chart or render external configuration files. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}` Examples: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Rendering an external configuration file: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Creating Image Pull Secrets Image pull secrets are essentially a combination of _registry_, _username_, and _password_. You may need them in an application you are deploying, but to create them requires running `base64` a couple of times. We can write a helper template to compose the Docker configuration file for use as the Secret's payload. Here is an example: First, assume that the credentials are defined in the `values.yaml` file like so: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` We then define our helper template as follows: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Finally, we use the helper template in a larger template to create the Secret manifest: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Automatically Roll Deployments Often times ConfigMaps or Secrets are injected as configuration files in containers or there are other external dependency changes that require rolling pods. Depending on the application a restart may be required should those be updated with a subsequent `helm upgrade`, but if the deployment spec itself didn't change the application keeps running with the old configuration resulting in an inconsistent deployment. The `sha256sum` function can be used to ensure a deployment's annotation section is updated if another file changes: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTE: If you're adding this to a library chart you won't be able to access your file in `$.Template.BasePath`. Instead you can reference your definition with `{{ include ("mylibchart.configmap") . | sha256sum }}`. In the event you always want to roll your deployment, you can use a similar annotation step as above, instead replacing with a random string so it always changes and causes the deployment to roll: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Each invocation of the template function will generate a unique random string. This means that if it's necessary to sync the random strings used by multiple resources, all relevant resources will need to be in the same template file. Both of these methods allow your Deployment to leverage the built in update strategy logic to avoid taking downtime. NOTE: In the past we recommended using the `--recreate-pods` flag as another option. This flag has been marked as deprecated in Helm 3 in favor of the more declarative method above. ## Tell Helm Not To Uninstall a Resource Sometimes there are resources that should not be uninstalled when Helm runs a `helm uninstall`. Chart developers can add an annotation to a resource to prevent it from being uninstalled. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` The annotation `helm.sh/resource-policy: keep` instructs Helm to skip deleting this resource when a helm operation (such as `helm uninstall`, `helm upgrade` or `helm rollback`) would result in its deletion. _However_, this resource becomes orphaned. Helm will no longer manage it in any way. This can lead to problems if using `helm install --replace` on a release that has already been uninstalled, but has kept resources. ## Using "Partials" and Template Includes Sometimes you want to create some reusable parts in your chart, whether they're blocks or template partials. And often, it's cleaner to keep these in their own files. In the `templates/` directory, any file that begins with an underscore(`_`) is not expected to output a Kubernetes manifest file. So by convention, helper templates and partials are placed in a `_helpers.tpl` file. ## Complex Charts with Many Dependencies Many of the charts in the CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) are "building blocks" for creating more advanced applications. But charts may be used to create instances of large-scale applications. In such cases, a single umbrella chart may have multiple subcharts, each of which functions as a piece of the whole. The current best practice for composing a complex application from discrete parts is to create a top-level umbrella chart that exposes the global configurations, and then use the `charts/` subdirectory to embed each of the components. ## YAML is a Superset of JSON According to the YAML specification, YAML is a superset of JSON. That means that any valid JSON structure ought to be valid in YAML. This has an advantage: Sometimes template developers may find it easier to express a datastructure with a JSON-like syntax rather than deal with YAML's whitespace sensitivity. As a best practice, templates should follow a YAML-like syntax _unless_ the JSON syntax substantially reduces the risk of a formatting issue. ## Be Careful with Generating Random Values There are functions in Helm that allow you to generate random data, cryptographic keys, and so on. These are fine to use. But be aware that during upgrades, templates are re-executed. When a template run generates data that differs from the last run, that will trigger an update of that resource. ## Install or Upgrade a Release with One Command Helm provides a way to perform an install-or-upgrade as a single command. Use `helm upgrade` with the `--install` command. This will cause Helm to see if the release is already installed. If not, it will run an install. If it is, then the existing release will be upgraded. ```console $ helm upgrade --install --values ``` ================================================ FILE: docs/howto/index.mdx ================================================ --- title: How-to sidebar_position: 3 --- # How-to Guides Here you’ll find short answers to “How do I….?” types of questions. These how-to guides don’t cover topics in depth – you’ll find that material in the [Topic Guides](/topics/index.mdx). However, these guides will help you quickly accomplish common tasks. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/index.mdx ================================================ --- title: Docs Home description: Everything you need to know about how the documentation is organized. sidebar_position: 1 --- # Welcome Welcome to the [Helm](https://helm.sh/) documentation. Helm is the package manager for Kubernetes, and you can read detailed background information in the [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). import DocCardList from "@theme/DocCardList"; ================================================ FILE: docs/intro/CheatSheet.mdx ================================================ --- title: Cheat Sheet description: Helm cheatsheet sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm cheatsheet featuring all the necessary commands required to manage an application through Helm. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Basic interpretations/context Chart: - It is the name of your chart in case it has been pulled and untarred. - It is `/` in case the repository has been added but chart not pulled. - It is the URL/Absolute path to the chart. Name: - It is the name you want to give to your current helm chart installation. Release: - Is the name you assigned to an installation instance. Revision: - Is the value from the Helm history command Repo-name: - The name of a repository. DIR: - Directory name/path ------------------------------------------------------------------------------------------------------------------------------------------------ ### Chart Management ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart’s dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Install and Uninstall Apps ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Perform App Upgrade and Rollback ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### List, Add, Remove, and Update Repositories ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm Release monitoring ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Download Release Information ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Plugin Management ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: docs/intro/index.mdx ================================================ --- title: Introduction sidebar_position: 2 --- # Introduction to Helm Are you new to Helm? This is the place to start! import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/intro/install.mdx ================================================ --- title: Installing Helm description: Learn how to install and get running with Helm. sidebar_position: 2 --- This guide shows how to install the Helm CLI. Helm can be installed either from source, or from pre-built binary releases. ## From The Helm Project The Helm project provides two ways to fetch and install Helm. These are the official methods to get Helm releases. In addition to that, the Helm community provides methods to install Helm through different package managers. Installation through those methods can be found below the official methods. ### From the Binary Releases Every [release](https://github.com/helm/helm/releases) of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed. 1. Download your [desired version](https://github.com/helm/helm/releases) 1. Verify the binary. See [Verifying Helm Binaries](#verifying-helm-binaries) on this page. 1. Unpack it (`tar -zxvf helm-v4.0.0-linux-amd64.tar.gz`) 1. Find the `helm` binary in the unpacked directory, and move it to its desired destination (`mv linux-amd64/helm /usr/local/bin/helm`) From there, you should be able to run the client and [add the stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Note:** Helm automated tests are performed for Linux AMD64 only during GitHub Actions builds and releases. Testing of other OSes are the responsibility of the community requesting Helm for the OS in question. ### From Script Helm now has an installer script that will automatically grab the latest version of Helm and [install it locally](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4). You can fetch that script, and then execute it locally. It's well documented so that you can read through it and understand what it is doing before you run it. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 chmod 700 get_helm.sh ./get_helm.sh ``` Yes, you can `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash` if you want to live on the edge. ## Through Package Managers The Helm community provides the ability to install Helm through operating system package managers. These are not supported by the Helm project and are not considered trusted 3rd parties. ### From Homebrew (macOS) Members of the Helm community have contributed a Helm formula build to Homebrew. This formula is generally up to date. ```console brew install helm ``` (Note: There is also a formula for emacs-helm, which is a different project.) ### From Chocolatey (Windows) Members of the Helm community have contributed a [Helm package](https://chocolatey.org/packages/kubernetes-helm) build to [Chocolatey](https://chocolatey.org/). This package is generally up to date. ```console choco install kubernetes-helm ``` ### From Scoop (Windows) Members of the Helm community have contributed a [Helm package](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) build to [Scoop](https://scoop.sh). This package is generally up to date. ```console scoop install helm ``` ### From Winget (Windows) Members of the Helm community have contributed a [Helm package](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) build to [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). This package is generally up to date. ```console winget install Helm.Helm ``` ### From Apt (Debian/Ubuntu) Members of the Helm community have contributed an Apt package for Debian/Ubuntu. This package is generally up to date. Thanks to [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) for hosting the repo. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### From dnf/yum (fedora) Since Fedora 35, Helm is available on the official repository. You can install Helm by invoking: ```console sudo dnf install helm ``` ### From Snap The [Snapcrafters](https://github.com/snapcrafters) community maintains the Snap version of the [Helm package](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### From pkg (FreeBSD) Members of the FreeBSD community have contributed a [Helm package](https://www.freshports.org/sysutils/helm) build to the [FreeBSD Ports Collection](https://man.freebsd.org/ports). This package is generally up to date. ```console pkg install helm ``` ### Development Builds In addition to releases you can download or install development snapshots of Helm. ### From Canary Builds "Canary" builds are versions of the Helm software that are built from the latest `main` branch. They are not official releases, and may not be stable. However, they offer the opportunity to test the cutting edge features. Canary Helm binaries are stored at `get.helm.sh`. Here are links to the common builds: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### From Source (Linux, macOS) Building Helm from source is slightly more work, but is the best way to go if you want to test the latest Helm version. You must have a working Go environment. ```console git clone https://github.com/helm/helm.git cd helm make ``` If required, it will fetch the dependencies and cache them, and validate configuration. It will then compile `helm` and place it in `bin/helm`. ## Verifying Helm Binaries Each Helm release includes cryptographic signatures that confirm the binary was built and signed by Helm maintainers. To help protect against supply chain attacks, you should always verify the authenticity of Helm binaries before installing. Published release assets on `get.helm.sh` (served through a CDN) generally cannot be altered after a GitHub release is published. However, the supply chain involves multiple components (CDN, hosting infrastructure, and so on), so signature verification is important even for older or pinned versions. ### Requirements To verify a Helm binary, you need the following: * The binary archive (for example, `helm-v4.0.0-linux-amd64.tar.gz`) * The corresponding signature file (for example, `helm-v4.0.0-linux-amd64.tar.gz.asc`) * The Helm maintainers' public PGP keys ### Verification Steps To verify a Helm binary: 1. Verify the SHA256 checksum to confirm the download wasn't corrupted. For example: ```console $ sha256sum -c helm-v4.0.0-linux-amd64.tar.gz.sha256sum helm-v4.0.0-linux-amd64.tar.gz: OK ``` 1. Import the Helm maintainers' public keys: ```console $ curl https://raw.githubusercontent.com/helm/helm/main/KEYS | gpg --import ``` :::note Avoid fetching keys from the Helm repository each time you verify a Helm binary. Instead, import the keys one time and then store them in a secure location you control. This protects you if the repository is ever compromised and keys are swapped; your local copy lets you detect the tampering. You can also cross-check maintainer keys on [Keybase](https://keybase.io), where Helm maintainers have profiles linking their identities to their PGP keys. ::: 1. Verify the binary's signature. For example: ```console $ gpg --verify helm-v4.0.0-linux-amd64.tar.gz.asc helm-v4.0.0-linux-amd64.tar.gz gpg: Signature made [date] using RSA key ID [key-id] gpg: Good signature from "Helm Maintainer " ``` A "Good signature" message confirms the binary is authentic and hasn't been tampered with. :::note Signature files are safe to pull from upstream as long as you have trusted copies of the public keys. An attacker cannot forge a valid signature without the private key, which only the legitimate maintainer has. ::: ## FAQ ### Why aren't there native packages of Helm for Fedora and other Linux distros? The Helm project does not maintain packages for operating systems and environments. The Helm community may provide native packages and if the Helm project is made aware of them they will be listed. This is how the Homebrew formula was started and listed. If you're interested in maintaining a package, we'd love it. ### Why do you provide a `curl ...|bash` script? There is a script in our repository (`scripts/get-helm-4`) that can be executed as a `curl ..|bash` script. The transfers are all protected by HTTPS, and the script does some auditing of the packages it fetches. However, the script has all the usual dangers of any shell script. We provide it because it is useful, but we suggest that users carefully read the script first. What we'd really like, though, are better packaged releases of Helm. ### How do I put the Helm client files somewhere other than their defaults? Helm uses the XDG structure for storing files. There are environment variables you can use to override these locations: - `$XDG_CACHE_HOME`: set an alternative location for storing cached files. - `$XDG_CONFIG_HOME`: set an alternative location for storing Helm configuration. - `$XDG_DATA_HOME`: set an alternative location for storing Helm data. Note that if you have existing repositories, you will need to re-add them with `helm repo add...`. ### I want to delete my local Helm. Where are all its files? Along with the `helm` binary, Helm stores some files in the following locations: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME The following table gives the default folder for each of these, by OS: | Operating System | Cache Path | Configuration Path | Data Path | |------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ## Conclusion In most cases, installation is as simple as getting a pre-built `helm` binary. This document covers additional cases for those who want to do more sophisticated things with Helm. Once you have the Helm Client successfully installed, you can move on to using Helm to manage charts and [add the stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: docs/intro/quickstart.md ================================================ --- title: Quickstart Guide description: How to install and get started with Helm including instructions for distros, FAQs, and plugins. sidebar_position: 1 --- This guide covers how you can quickly get started using Helm. ## Prerequisites The following prerequisites are required for a successful and properly secured use of Helm. 1. A Kubernetes cluster 2. Deciding what security configurations to apply to your installation, if any 3. Installing and configuring Helm. ### Install Kubernetes or have access to a cluster - You must have Kubernetes installed. For the latest release of Helm, we recommend the latest stable release of Kubernetes, which in most cases is the second-latest minor release. - You should also have a local configured copy of `kubectl`. See the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) for the maximum version skew supported between Helm and Kubernetes. ## Install Helm Download a binary release of the Helm client. You can use tools like `homebrew`, or look at [the official releases page](https://github.com/helm/helm/releases). For more details, or for other options, see [the installation guide](/intro/install.mdx). ## Initialize a Helm Chart Repository Once you have Helm ready, you can add a chart repository. Check [Artifact Hub](https://artifacthub.io/packages/search?kind=0) for available Helm chart repositories. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Once this is installed, you will be able to list the charts you can install: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Install an Example Chart To install a chart, you can run the `helm install` command. Helm has several ways to find and install a chart, but the easiest is to use the `bitnami` charts. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` In the example above, the `bitnami/mysql` chart was released, and the name of our new release is `mysql-1612624192`. You get a simple idea of the features of this MySQL chart by running `helm show chart bitnami/mysql`. Or you could run `helm show all bitnami/mysql` to get all information about the chart. Whenever you install a chart, a new release is created. So one chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded. The `helm install` command is a very powerful command with many capabilities. To learn more about it, check out the [Using Helm Guide](/intro/using_helm.mdx) ## Learn About Releases It's easy to see what has been released using Helm: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` The `helm list` (or `helm ls`) function will show you a list of all deployed releases. ## Uninstall a Release To uninstall a release, use the `helm uninstall` command: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` This will uninstall `mysql-1612624192` from Kubernetes, which will remove all resources associated with the release as well as the release history. If the flag `--keep-history` is provided, release history will be kept. You will be able to request information about that release: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Because Helm tracks your releases even after you've uninstalled them, you can audit a cluster's history, and even undelete a release (with `helm rollback`). ## Reading the Help Text To learn more about the available Helm commands, use `helm help` or type a command followed by the `-h` flag: ```console $ helm get -h ``` ================================================ FILE: docs/intro/using_helm.mdx ================================================ --- title: Using Helm description: Explains the basics of Helm. sidebar_position: 3 --- import Helm4 from "/docs/_v4-in-progress.mdx" This guide explains the basics of using Helm to manage packages on your Kubernetes cluster. It assumes that you have already [installed](/intro/install.mdx) the Helm client. If you are simply interested in running a few quick commands, you may wish to begin with the [Quickstart Guide](/intro/quickstart.md). This chapter covers the particulars of Helm commands, and explains how to use Helm. ## Three Big Concepts A *Chart* is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file. A *Repository* is the place where charts can be collected and shared. It's like Perl's [CPAN archive](https://www.cpan.org) or the [Fedora Package Database](https://src.fedoraproject.org/), but for Kubernetes packages. A *Release* is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new _release_ is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own _release_, which will in turn have its own _release name_. With these concepts in mind, we can now explain Helm like this: Helm installs _charts_ into Kubernetes, creating a new _release_ for each installation. And to find new charts, you can search Helm chart _repositories_. ## 'helm search': Finding Charts Helm comes with a powerful search command. It can be used to search two different types of source: - `helm search hub` searches [the Artifact Hub](https://artifacthub.io), which lists helm charts from dozens of different repositories. - `helm search repo` searches the repositories that you have added to your local helm client (with `helm repo add`). This search is done over local data, and no public network connection is needed. You can find publicly available charts by running `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` The above searches for all `wordpress` charts on Artifact Hub. With no filter, `helm search hub` shows you all of the available charts. `helm search hub` exposes the URL to the location on [artifacthub.io](https://artifacthub.io/) but not the actual Helm repo. `helm search hub --list-repo-url` exposes the actual Helm repo URL which comes in handy when you are looking to add a new repo: `helm repo add [NAME] [URL]`. Using `helm search repo`, you can find the names of the charts in repositories you have already added: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search uses a fuzzy string matching algorithm, so you can type parts of words or phrases: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Search is a good way to find available packages. Once you have found a package you want to install, you can use `helm install` to install it. ## 'helm install': Installing a Package To install a new package, use the `helm install` command. At its simplest, it takes two arguments: A release name that you pick, and the name of the chart you want to install. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Now the `wordpress` chart is installed. Note that installing a chart creates a new _release_ object. The release above is named `happy-panda`. (If you want Helm to generate a name for you, leave off the release name and use `--generate-name`.) During installation, the `helm` client will print useful information about which resources were created, what the state of the release is, and also whether there are additional configuration steps you can or should take. Helm installs resources in the following order: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm does not wait until all of the resources are running before it exits. Many charts require Docker images that are over 600MB in size, and may take a long time to install into the cluster. To keep track of a release's state, or to re-read configuration information, you can use `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` The above shows the current state of your release. ### Customizing the Chart Before Installing Installing the way we have here will only use the default configuration options for this chart. Many times, you will want to customize the chart to use your preferred configuration. To see what options are configurable on a chart, use `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` You can then override any of these settings in a YAML formatted file, and then pass that file during installation. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` The above will create a default MariaDB user with the name `user0`, and grant this user access to a newly created `user0db` database, but will accept all the rest of the defaults for that chart. There are two ways to pass configuration data during install: - `--values` (or `-f`): Specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence - `--set`: Specify overrides on the command line. If both are used, `--set` values are merged into `--values` with higher precedence. Overrides specified with `--set` are persisted in a Secret. Values that have been `--set` can be viewed for a given release with `helm get values `. Values that have been `--set` can be cleared by running `helm upgrade` with `--reset-values` specified. #### The Format and Limitations of `--set` The `--set` option takes zero or more name/value pairs. At its simplest, it is used like this: `--set name=value`. The YAML equivalent of that is: ```yaml name: value ``` Multiple values are separated by `,` characters. So `--set a=b,c=d` becomes: ```yaml a: b c: d ``` More complex expressions are supported. For example, `--set outer.inner=value` is translated into this: ```yaml outer: inner: value ``` Lists can be expressed by enclosing values in `{` and `}`. For example, `--set name={a, b, c}` translates to: ```yaml name: - a - b - c ``` Certain name/key can be set to be `null` or to be an empty array `[]`. For example, `--set name=[],a=null` translates ```yaml name: - a - b - c a: b ``` to ```yaml name: [] a: null ``` As of Helm 2.5.0, it is possible to access list items using an array index syntax. For example, `--set servers[0].port=80` becomes: ```yaml servers: - port: 80 ``` Multiple values can be set this way. The line `--set servers[0].port=80,servers[0].host=example` becomes: ```yaml servers: - port: 80 host: example ``` Sometimes you need to use special characters in your `--set` lines. You can use a backslash to escape the characters; `--set name=value1\,value2` will become: ```yaml name: "value1,value2" ``` Similarly, you can escape dot sequences as well, which may come in handy when charts use the `toYaml` function to parse annotations, labels and node selectors. The syntax for `--set nodeSelector."kubernetes\.io/role"=master` becomes: ```yaml nodeSelector: kubernetes.io/role: master ``` Deeply nested data structures can be difficult to express using `--set`. Chart designers are encouraged to consider the `--set` usage when designing the format of a `values.yaml` file (read more about [Values Files](/chart_template_guide/values_files.mdx)). ### More Installation Methods The `helm install` command can install from several sources: - A chart repository (as we've seen above) - A local chart archive (`helm install foo foo-0.1.1.tgz`) - An unpacked chart directory (`helm install foo path/to/foo`) - A full URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure When a new version of a chart is released, or when you want to change the configuration of your release, you can use the `helm upgrade` command. An upgrade takes an existing release and upgrades it according to the information you provide. Because Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade. It will only update things that have changed since the last release. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` In the above case, the `happy-panda` release is upgraded with the same chart, but with a new YAML file: ```yaml mariadb.auth.username: user1 ``` We can use `helm get values` to see whether that new setting took effect. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` The `helm get` command is a useful tool for looking at a release in the cluster. And as we can see above, it shows that our new values from `panda.yaml` were deployed to the cluster. Now, if something does not go as planned during a release, it is easy to roll back to a previous release using `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` The above rolls back our happy-panda to its very first release version. A release version is an incremental revision. Every time an install, upgrade, or rollback happens, the revision number is incremented by 1. The first revision number is always 1. And we can use `helm history [RELEASE]` to see revision numbers for a certain release. ## Helpful Options for Install/Upgrade/Rollback There are several other helpful options you can specify for customizing the behavior of Helm during an install/upgrade/rollback. Please note that this is not a full list of cli flags. To see a description of all flags, just run `helm --help`. - `--timeout`: A [Go duration](https://golang.org/pkg/time/#ParseDuration) value to wait for Kubernetes commands to complete. This defaults to `5m0s`. - `--wait`: Waits until all Pods are in a ready state, PVCs are bound, Deployments have minimum (`Desired` minus `maxUnavailable`) Pods in ready state and Services have an IP address (and Ingress if a `LoadBalancer`) before marking the release as successful. It will wait for as long as the `--timeout` value. If timeout is reached, the release will be marked as `FAILED`. Note: In scenarios where Deployment has `replicas` set to 1 and `maxUnavailable` is not set to 0 as part of rolling update strategy, `--wait` will return as ready as it has satisfied the minimum Pod in ready condition. - `--no-hooks`: This skips running hooks for the command - `--recreate-pods` (only available for `upgrade` and `rollback`): This flag will cause all pods to be recreated (with the exception of pods belonging to deployments). (DEPRECATED in Helm 3) ## 'helm uninstall': Uninstalling a Release When it is time to uninstall a release from the cluster, use the `helm uninstall` command: ```console $ helm uninstall happy-panda ``` This will remove the release from the cluster. You can see all of your currently deployed releases with the `helm list` command: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` From the output above, we can see that the `happy-panda` release was uninstalled. In previous versions of Helm, when a release was deleted, a record of its deletion would remain. In Helm 3, deletion removes the release record as well. If you wish to keep a deletion release record, use `helm uninstall --keep-history`. Using `helm list --uninstalled` will only show releases that were uninstalled with the `--keep-history` flag. The `helm list --all` flag will show you all release records that Helm has retained, including records for failed or deleted items (if `--keep-history` was specified): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Note that because releases are now deleted by default, it is no longer possible to rollback an uninstalled resource. ## 'helm repo': Working with Repositories Helm 3 no longer ships with a default chart repository. The `helm repo` command group provides commands to add, list, and remove repositories. You can see which repositories are configured using `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` And new repositories can be added with `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Because chart repositories change frequently, at any point you can make sure your Helm client is up to date by running `helm repo update`. Repositories can be removed with `helm repo remove`. ## Creating Your Own Charts The [Chart Development Guide](/topics/charts.mdx) explains how to develop your own charts. But you can get started quickly by using the `helm create` command: ```console $ helm create deis-workflow Creating deis-workflow ``` Now there is a chart in `./deis-workflow`. You can edit it and create your own templates. As you edit your chart, you can validate that it is well-formed by running `helm lint`. When it's time to package the chart up for distribution, you can run the `helm package` command: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` And that chart can now easily be installed by `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Charts that are packaged can be loaded into chart repositories. See the documentation for [Helm chart repositories](/topics/chart_repository.md) for more details. ## Conclusion This chapter has covered the basic usage patterns of the `helm` client, including searching, installation, upgrading, and uninstalling. It has also covered useful utility commands like `helm status`, `helm get`, and `helm repo`. For more information on these commands, take a look at Helm's built-in help: `helm help`. In the [next chapter](/howto/charts_tips_and_tricks.md), we look at the process of developing charts. ================================================ FILE: docs/overview.md ================================================ --- sidebar_position: 1 sidebar_label: Helm 4 Overview --- # Helm 4 Overview Helm v4 represents a significant evolution from v3, introducing breaking changes, new architectural patterns, and enhanced functionality while maintaining backwards compatibility for charts. For more information about the planned Helm 4 release phases, see [Path to Helm v4](https://helm.sh/blog/path-to-helm-v4/). ## What's New This section provides an overview of what's new in Helm 4, including breaking changes, major new features, and other improvements. For complete technical details, see the [Full Changelog](./changelog.md). ### Summary - **New features**: Wasm-based plugins, kstatus watcher, OCI digest support, multi-doc values, JSON arguments - **Architecture changes**: Plugin system completely redesigned, package restructuring, CLI flag renaming, move to versioned packages, chart v3 support, content-based caching - **Modernization**: slog migration, Go 1.24 update, dependency cleanup - **Security**: Enhanced OCI/registry support, TLS improvements ### Breaking Changes #### Post-renderers implemented as plugins Post-renderers are implemented as plugins. With this change, it is no longer possible to pass an executable directly to `helm render --post-renderer`, but a plugin name must be passed. This might require updates to any existing post-renderer workflows. #### Registry login does not accept full URLs The `helm registry login` command must be done with the domain name only in v4. This is so login can be scoped at different levels on a registry in the future. ### New Features #### Plugin System Overhaul Helm 4 introduces an optional WebAssembly-based runtime for enhanced security and expanded capabilities. Existing plugins continue to work, but the new runtime opens up more of Helm's core behavior for plugin customization. Helm 4 launches with three plugin types: CLI plugins, getter plugins, and post-renderer plugins, plus a system that enables new plugin types for customizing additional core functionality. See [HIP-0026 plugin system](https://github.com/helm/community/blob/main/hips/hip-0026.md) and [Helm 4 example plugins](https://github.com/scottrigby/h4-example-plugins). :::tip Existing plugins work as before. The new WebAssembly runtime is optional but recommended for enhanced security. ::: #### Better resource monitoring New kstatus integration shows detailed status of your deployments. Test with complex applications to see if it catches issues better. #### Enhanced OCI Support Install charts by digest for better supply chain security. For example, `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`. Charts with non-matching digests are not installed. #### Multi-Document Values Split complex values across multiple YAML files. Perfect for testing different environment configs. #### Server-Side Apply Better conflict resolution when multiple tools manage the same resources. Test in environments with operators or other controllers. Helm 4 will default to server-side apply when installing a new Chart release. When upgrading (or rolling back), Helm will by default follow the previous apply method of the release. This latching behavior is done to ensure continuity of operation for existing releases that used client-side apply. The behavior can be overridden by setting the `--server-side` flag explicitly. As such, all releases created by Helm 3 will default to using client-side apply after upgrading to Helm 4. #### Custom Template Functions Extend Helm's templating with your own functions through plugins. Great for organization-specific templating needs. #### Post-Renderers as Plugins Post-renderers are implemented as plugins, providing better integration and more capabilities. #### Stable SDK API API breaking changes are now complete. Test it, break it, give us feedback! The API also enables additional chart versions, opening possibilities for new features in the upcoming Charts v3. #### Charts v3 Coming soon. v2 charts continue to work unchanged. ### Improvements #### Performance Faster dependency resolution and new content-based chart caching. #### Error Messages Clearer, more helpful error output. #### Registry Authentication Better OAuth and token support for private registries. #### CLI Flags renamed Some common CLI flags are renamed to better clarify their operation. The existing flags remain, but emit a deprecated warning: - `--atomic` → `--rollback-on-failure` - `--force` → `--force-replace` Update any automation that uses these renamed CLI flags. #### CLI Flags deprecated The following flags for `helm template` are deprecated and will be removed in Helm 5: - `--hide-notes` - `--render-subchart-notes` These flags have no effect because template output never includes notes. They remain in Helm 4 for backwards compatibility but are hidden from help output. ## Upgrading to Helm 4 While we work hard to make Helm 4 rock-solid for everyone, Helm 4 is brand new. To that end, before upgrading, we've added some tips below for specific things to look out for when testing Helm 4 with your existing workflows. As always, we welcome all feedback about what works, what breaks, and what could be better. ### High Priority * Test your existing charts and releases to verify that they still work with v4. * Test all 3 plugin types (CLI, getter, post-renderer). * Try building WebAssembly plugins with the new runtime (see [example plugins](https://github.com/scottrigby/h4-example-plugins)) * SDK users: test the now-stable API. Try to break it and share your feedback. * Test your CI/CD pipelines and fix any script errors from the renamed CLI flags. * Test your post-renderer integrations. * Test registry authentication and chart installation in your OCI workflows. ### Other * Test other new features, including multi-document values, digest-based installs, and custom template functions. * Test the performance of Helm 4 with large, complex charts to see if it is noticeably faster for your workloads. * Try breaking things intentionally to see if the updated error messages are helpful. ### Feedback * What other plugin types would you like to see added to customize Helm core functionality? * With the API supporting additional chart versions, what new features would you want in Charts v3? ## How to Give Feedback Find issues? Have suggestions? We want to hear from you before the November release: ### GitHub Issues Review the [list of open issues and feature requests](https://github.com/helm/helm/issues) in the Helm repo. Add comments on the existing items, or [create new](https://github.com/helm/helm/issues/new/choose) issues and requests. ### Community Slack Join [Kubernetes Slack](https://slack.kubernetes.io/) channels: - `#helm-dev` for development discussions - `#helm-users` for user support and testing feedback ### Weekly Dev Meetings Join live discussion with maintainers every Thursday 9:30am PT on [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09). For more options, see the Helm community [communication details](https://github.com/helm/community/blob/main/communication.md). ================================================ FILE: docs/plugins/developer/index.mdx ================================================ --- title: Plugins Developer Guide sidebar_label: Developing Plugins sidebar_position: 3 --- import DocCardList from "@theme/DocCardList"; For an overview of Helm Plugin concepts, and how to structure and configure plugins, read the [Plugins Overview](/plugins/overview.md). This section focuses on developing Helm Plugins – it is intended to include [Tutorials](#tutorials), how-to guides, reference guides, and additional developer-focused information for writing Helm Plugins. :::info For an intro to the Plugin System codebase, there will be a Plugins page in the [Go SDK](/sdk/index.mdx) section of the docs, coming soon! ::: ## Tutorials ================================================ FILE: docs/plugins/developer/tutorial-cli-plugin.mdx ================================================ --- title: "Tutorial: Build a CLI Plugin" sidebar_label: Build a CLI Plugin --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; Build a `helm system-info` command that displays system information. ## Subprocess Runtime Let's start by building a CLI Plugin with the Subprocess runtime. ### Prerequisites 1. Install the latest Helm 4 release: **** 2. In your terminal session, alias `helm` to the release you downloaded. `helm version --short` should now show the correct Helm version in this terminal session. ### 1. Create Plugin Directory You can create this anywhere on your filesystem. For example: ```bash mkdir -p $HOME/code/helm/plugins/system-info cd $HOME/code/helm/plugins/system-info ``` ### 2. Create plugin manifest ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: cli/v1 name: "system-info" version: "0.1.0" runtime: subprocess config: usage: system-info shortHelp: Display system and Helm information longHelp: Shows OS info, Helm version, and environment details runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/system-info.sh ``` ### 3. Create Script ```bash title="system-info.sh" showLineNumbers #!/bin/bash echo "=== System Information ===" echo "OS: $(uname -s)" echo "Architecture: $(uname -m)" echo "" echo "=== Helm Information ===" echo "Plugin Dir: $HELM_PLUGIN_DIR" echo "Arguments: $*" echo "" echo "System info complete!" ``` Make it executable: ```bash chmod +x system-info.sh ``` ### 4. Install in Dev Mode and Test Installing a plugin from your filesystem installs in local dev mode. This bypasses checking or verifying provenance: ```bash % helm plugin install $HOME/code/helm/plugins/system-info Installing plugin from local directory (development mode) Installed plugin: system-info ``` Local dev mode installation creates a symlink from your source directory to the plugins directory, so you can continue to develop in your preferred location. You can see the symlink by listing the directory location using the internal HELM_PLUGINS env variable: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 3 r6by staff 96B Nov 10 02:18 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` You can see your plugin details in the `helm plugin list` of installed plugins: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE system-info 0.1.0 cli/v1 v1 local dev unknown ``` You can also now see your plugin in the list of available commands with `helm help`, and see it's own generated help message you defined in your `plugin.yaml`: ```bash % helm help | grep system-info system-info Display system and Helm information % helm help system-info Shows OS info, Helm version, and environment details Usage: helm system-info [flags] ``` Let's try running the CLI subcommand: ```bash % helm system-info === System Information === OS: Darwin Architecture: arm64 === Helm Information === Plugin Dir: /Users/r6by/Library/helm/plugins/system-info Arguments: System info complete! ``` What you built: A CLI plugin using the Subprocess runtime! Now let's do it again, this time using Wasm runtime… ## Wasm Runtime ### Prerequisites - Prerequisites from [Subprocess Runtime](#subprocess-runtime) - Go 1.25 installed :::warning To-do: add this section ::: ================================================ FILE: docs/plugins/developer/tutorial-getter-plugin.mdx ================================================ --- title: "Tutorial: Build a Getter Plugin" sidebar_label: Build a Getter Plugin --- import GetVersion from "@site/src/components/GetVersion"; Build a `helm system-info` command that displays system information. ## Subprocess Runtime Let's build a Getter Plugin using the Subprocess runtime. ### Prerequisites 1. Install the latest Helm 4 release: **** 2. In your terminal session, alias `helm` to the release you downloaded. `helm version --short` should now show the correct Helm version in this terminal session. ### 1. Create Plugin Directory You can create this anywhere on your filesystem. For example: ```bash mkdir -p $HOME/code/helm/plugins/demo-getter cd $HOME/code/helm/plugins/demo-getter ``` ### 2. Create plugin manifest ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: subprocess config: protocols: ["demo"] runtimeConfig: protocolCommands: - protocols: - demo platformCommand: - command: get-demo.sh ``` ### 3. Create Script Getter plugins are responsible for getting/downloading a packaged artifact – in this case a Chart – and returning the path to the downloaded package. For demo purposes, let's use your system's utility to make a temp directory (it will auto-garbage collect in time on it's own), and use the `helm create` and `helm package` commands to just make a demo chart package in the temp dir, and return the package path: ```bash title="get-demo.sh" showLineNumbers #!/usr/bin/env sh set -e URI=$@ TMPDIR="$(mktemp -d)" # make a fake chart for testing with the passed URL basename FILENAME=$(basename -- $URI) helm create $TMPDIR/$FILENAME 1>/dev/null helm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null # cat $FILENAME-0.1.0.tgz # just to not need to know the chart version rm -r $TMPDIR/$FILENAME 1>/dev/null cat $TMPDIR/$FILENAME-* ``` Make it executable: ```bash chmod +x get-demo.sh ``` ### 4. Install in Dev Mode and Test Installing a plugin from your filesystem installs in local dev mode, which does not check the provenance: ```bash % helm plugin install $HOME/code/helm/plugins/demo-getter Installing plugin from local directory (development mode) Installed plugin: demo-getter ``` As we saw in the [CLI Plugin tutorial](/plugins/developer/tutorial-cli-plugin.mdx), local dev mode installation creates a symlink from your plugin source directory to the plugins directory. You now have two plugins installed: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 4 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` Unlike the CLI plugin tutorial, you will not see this plugin in the list of available commands with `helm help`. Only CLI Plugin types appear in the `helm` CLI subcommands list. But like all plugin types, you can see your installed Postrenderer plugin details with `helm plugin list`: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` Let's try it out. It should return templated YAML for a chart named "example": ```bash % helm template example demo://does-not-matter/example LOTS OF YAML, INCLUDING: --- # Source: example/templates/tests/test-connection.yaml ``` What you built: A demo Getter plugin using the Subprocess runtime! Next let's build a version in Wasm runtime… ## Wasm Runtime ### Prerequisites - Prerequisites from [Subprocess Runtime](#subprocess-runtime) - Go 1.25 installed Build a custom protocol getter that converts `demo://` URLs to `https://`. ### 1. Set up repository Scaffold a new repository from the template (or just clone): https://github.com/gjenkins8/helm-extism-plugin-template ### 2. Update plugin manifest Similar to the same step for the Subprocess Getter, except you will do this in your own cloned Git repository. Note the `runtime` and `runtimeConfig` field values will change for Wasm: ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: extism/v1 config: protocols: ["demo"] runtimeConfig: memory: maxPages: 16 timeout: 30000 ``` ### 3. Update `main.go` Specify the plugins input/output messages: ```go title="main.go" showLineNumbers package main ... type InputMessage struct { URL string `json:"url"` Protocol string `json:"protocol"` } type OutputMessage struct { Data []byte `json:"data"` } ``` Replace the `replaceMeImplementationGoesHere` function with actual logic: ```go ... // Delete the `replaceMeImplementationGoesHere` function func demoDownloader(input InputMessage) (*OutputMessage, error) { // Convert demo:// to https:// downloadURL := strings.Replace(input.URL, "demo://", "https://", 1) pdk.Log(pdk.LogLevelInfo, fmt.Sprintf("Converted %s to %s", input.URL, downloadURL)) // Download content resp, err := http.Get(downloadURL) if err != nil { return nil, fmt.Errorf("failed to download: %w", err) } defer resp.Body.Close() // Read and output content data, _ := io.ReadAll(resp.Body) output := OutputMessage{Data: data} return &output, nil } ``` Update the runPlugin function to call `demoDownloader` instead: ```go func runPlugin() error { ... // Remove: output, err := replaceMeImplementationGoesHere(input) output, err := demoDownloader(input) ``` ### 4. Build WebAssembly ```bash $ make build $ ls -la plugin.wasm ``` ### 5. Install in Dev Mode and Test Same as the Subprocess CLI Plugin step. What you built: A WebAssembly plugin with sandboxed execution and structured communication via Extism PDK! ================================================ FILE: docs/plugins/developer/tutorial-postrenderer-plugin.mdx ================================================ --- title: "Tutorial: Build a Postrenderer Plugin" sidebar_label: Build a Postrenderer Plugin --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; Build a plugin that adds custom labels to all Kubernetes resources. ## Subprocess Runtime Let's start by building a Postrenderer Plugin with the Subprocess runtime. ### Prerequisites 1. Install the latest Helm 4 release: **** 2. In your terminal session, alias `helm` to the release you downloaded. `helm version --short` should now show the correct Helm version in this terminal session. 3. Install `mikefarah/yq`: https://github.com/mikefarah/yq/#install ### 1. Create Plugin Directory You can create this anywhere on your filesystem. For example: ```bash mkdir -p $HOME/code/helm/plugins/label-injector cd $HOME/code/helm/plugins/label-injector ``` ### 2. Create plugin manifest ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: postrenderer/v1 name: label-injector version: 0.1.0 runtime: subprocess runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/inject-labels.sh ``` ### 3. Create Script ```bash title="inject-labels.sh" showLineNumbers #!/usr/bin/env sh # set -e cat <&0 | yq '.metadata.labels.postrendered-by = "helm-label-injector-plugin"' ``` Make it executable: ```bash chmod +x inject-labels.sh ``` ### 4. Install in Dev Mode and Test Installing a plugin from your filesystem installs in local dev mode, which does not check the provenance: ```bash % helm plugin install $HOME/code/helm/plugins/label-injector Installing plugin from local directory (development mode) Installed plugin: label-injector ``` As we saw in the [CLI Plugin](/plugins/developer/tutorial-cli-plugin.mdx) and [Getter Plugin](/plugins/developer/tutorial-getter-plugin.mdx) tutorials, local dev mode installation creates a symlink from your plugin source directory to the plugins directory. You now have three plugins installed: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 5 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` You can now see your installed Postrenderer plugin details along with the installed CLI and Getter plugins, using `helm plugin list`: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown label-injector 0.1.0 postrenderer/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` Let's try it out: ```bash % helm create ../mychart % helm template ../mychart --post-renderer label-injector ``` You should see labels like this in the output: ```yaml metadata: labels: postrendered-by: helm-label-injector-plugin ``` What you built: A Postrenderer plugin using the Subprocess runtime! Let's do this one in Wasm runtime now too… ## Wasm Runtime ### Prerequisites - Prerequisites from [Subprocess Runtime](#subprocess-runtime) - Go 1.25 installed :::warning To-do: add this section ::: ================================================ FILE: docs/plugins/index.mdx ================================================ --- title: Plugins Guide sidebar_label: Plugins sidebar_position: 5.5 --- This guide explains what Helm plugins are, how to use them, and how to build them. import DocCardList from "@theme/DocCardList"; ================================================ FILE: docs/plugins/overview.md ================================================ --- title: Plugins Overview sidebar_label: Overview sidebar_position: 1 --- Helm Plugins allow users to extend the core feature set of Helm, without requiring every new feature to be written in Go and added to Helm core. They can be written in any programming language, and can be added and removed from a Helm installation without breaking Helm core functionality. ## Plugin Types Helm currently has 3 types of Plugins: - [CLI plugins](#cli-plugins): allow users to add additional `helm` CLI sub-commands - [Getter plugins](#getter-plugins): allow users to use Charts and even other Plugins in locations Helm core doesn't have built-in support for - [Postrenderer plugins](#postrenderer-plugins): allow users to modify Chart rendered manifests before being sent to the Kubernetes API Starting with Helm 4, the plugin system is set up to more easily allow adding additional plugin types, which would allow users to modify other areas of Helm functionality. ### CLI plugins What is the advantage of using a plugin to create `helm` CLI subcommands as opposed to using separate scripts, or tools with their own standalone commands? The main reason is plugins that add `helm` CLI sub-commands can leverage Helm-specific configuration, context, and functionality that standalone scripts and tools would otherwise need to develop themselves. They can allow a more seamless extension of `helm` CLI user workflows. ### Getter Plugins Helm has built-in support for working with [Charts](/glossary/index.mdx#chart) and Plugins on your local filesystem or stored as artifacts in [OCI Registries](/topics/registries.mdx). Charts can additionally be stored in [HTTP repositories](/topics/chart_repository.md), and plugins can additionally be stored in VCS repositories like Git. Helm Getter plugins allow you to extend this storage and download behavior to support other storage locations. There are community Getter plugins for storing Charts and Plugins in [s3 buckets](/community/related#helm-plugins), and elsewhere. You will want to use getter plugins if you need additional storage options for your Helm workflows. ### PostRenderer plugins Helm allows users to configure charts by supplying custom values. These user-provided values are what Charts use to render the manifests that allow Helm to manage your applications in Kubernetes. If you write your own charts, you can update the templates whenever you need additional configurability for your rendered manifests. However, if you are using community charts that you don't own, post-rendering allows you to modify the manifests after the charts have rendered them but before Helm uses them to manage your Kubernetes resources. Starting with Helm 4, postrenderer plugins are the way to do this. ## Plugin API Versions Starting with Helm 4, the `plugin.yaml` file included with every plugin now has an `apiVersion` field, currently at `v1`. Legacy plugins (prior to API versioning) will still be supported throughout the life of Helm 4, so your existing plugins from Helm 3 will still work until Helm 5. However, you should ask authors of your favorite plugins to update their plugins to the new versioning system. If you are a plugin developer, read more about this in the [Plugins Developer Guide](/plugins/developer/index.mdx). ## Plugin Runtimes Helm currently supports 2 plugin runtimes: - Subprocess runtime - Wasm runtime See the relevant information about each runtime in either the [Plugins User Guide](/plugins/user/index.md) or [Plugins Developer Guide](/plugins/developer/index.mdx). ## File structure All of the files for a plugin live within a single directory, which is used for developing, packaging, and installing. Inside the plugin's directory, Helm expects this structure: ``` example-plugin ├── plugin.yaml # REQUIRED ├── plugin.sh # OPTIONAL for Subprocess runtime └── plugin.wasm # REQUIRED for Wasm runtime ``` - The only required file is [plugin.yaml](#pluginyaml). - [Subprocess runtime](#plugin-runtimes) can optionally contain one or more custom executable files containing your plugin code (can be Node, Python, Go, etc). For this runtime, you can alternatively call any executable already available in the user's PATH, directly from the `plugin.yaml` [runtime configuration](#runtime-configuration) `platformCommand` field. - For [Wasm runtime](#plugin-runtimes), you will need to include a `.wasm` file. This is your plugin code (can be Node, Python, Go, etc) compiled to Wasm. ## Plugin.yaml The `plugin.yaml` file is required for a plugin. It is a YAML file containing metadata and configuration for the plugin. ### Metadata Information ```yaml apiVersion: REQUIRED - The Plugin API version. Must be "v1" type: REQUIRED - The versioned Plugin Type. Can be "cli/v1", "getter/v1", or "postrenderer/v1" name: REQUIRED - The name of the plugin version: REQUIRED - The version of the plugin runtime: REQUIRED - The runtime for the plugin. Can be "subprocess" or "extism/v1" (Wasm) sourceURL: OPTIONAL - A URL pointing to the source code for your plugin config: DEPENDS ON PLUGIN TYPE runtimeConfig: DEPENDS ON RUNTIME ``` - The `config` field is for [Plugin Type Configuration](#plugin-type-configuration), with a structure that differs per [Plugin Type](#plugin-types) as defined by the `type` field. - The `runtimeConfig` field is for [Runtime Configuration](#runtime-configuration), with a structure that differs per [Runtime](#plugin-runtimes) as defined by the `runtime` field. - 💡 While the `sourceURL` field is optional, plugin authors are strongly encouraged to point to the plugin source code because it helps plugin users understand what the code does, and contribute to the plugin if it accepts open source contributions. ### Plugin Type Configuration The `config` field of [plugin.yaml](#pluginyaml) has different options per [Plugin Type](#plugin-types). A plugin's type is defined by the `type` field. #### CLI Plugin Configuration If `type` field is `cli/v1`, it is a [CLI Plugin type](#cli-plugins), and the following plugin type configurations are allowed: ```yaml usage: OPTIONAL - The single-line usage text shown in help shortHelp: The short description shown in the 'helm help' output longHelp: The long message shown in the 'helm help ' output ignoreFlags: Ignores any flags passed in from Helm ``` - `usage` is optional. Defaults to "helm PLUGIN_NAME [flags]" if not overridden with a custom usage string. For recommended syntax, see [spf13/cobra.command.Command] Use field comment: https://pkg.go.dev/github.com/spf13/cobra#Command - `ignoreFlags` switch tells Helm to not pass flags to the plugin. So if a plugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then `--foo` is silently discarded. #### Getter Plugin Configuration If `type` field is `getter/v1`, it is a [Getter Plugin type](#getter-plugins), and the following plugin type configurations are allowed: ```yaml protocols: The list of schemes from the charts URL that this plugin supports. ``` #### Postrenderer Plugin Configuration If `type` field is `postrenderer/v1`, it is a [Postrenderer Plugin type](#cli-plugins), and does not have any configuration options. ### Runtime Configuration The `runtimeConfig` field of [plugin.yaml](#pluginyaml) has different options per [Plugin Runtime](#plugin-runtimes). A plugin's runtime is defined by the `runtime` field. #### Subprocess Runtime Configuration If the `runtime` field is `subprocess`, it is a [Subprocess Runtime](#plugin-runtimes) plugin and the following runtime configurations are allowed: ```yaml runtimeconfig: platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match any OS arch: Architecture match, can be empty or omitted to match any architecture command: Plugin command to execute args: Plugin command arguments platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match any OS arch: Architecture match, can be empty or omitted to match any architecture command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match any OS arch: Architecture match, can be empty or omitted to match any architecture command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match any OS arch: Architecture match, can be empty or omitted to match any architecture command: Plugin delete command to execute args: Plugin delete command arguments protocolCommands: # Obsolete/deprecated - protocols: [] # Protocols are the list of schemes from the charts URL. platformCommand: [] # Same structure as "platformCommand" above ``` - ⚠️ `protocolCommands` is marked `obsolete/deprecated`, and will be removed in future versions of the plugin system after `apiVersion: v1`. It only applies to the "getter/v1" plugin type. This is a compatibility hangover from the old plugin downloader mechanism, which was extended to support multiple protocols in a given plugin. The command supplied in PlatformCommand should implement protocol specific logic by inspecting the download URL. #### Wasm Runtime Configuration If the `runtime` field is `extism/v1`, it is a [Wasm Runtime](#plugin-runtimes) plugin and the following runtime configurations are allowed: ```yaml runtimeconfig: memory: # Describes the limits on the memory the plugin may be allocated maxPages: The max amount of pages the plugin can allocate. One page is 64Kib. e.g. 16 pages would require 1MiB. Default is 4 pages (256KiB). maxHttpResponseBytes: The max size of an Extism HTTP response in bytes. Default is 4096 bytes (4KiB). maxVarBytes: The max size of all Extism vars in bytes. Default is 4096 bytes (4KiB). config: {} # A free-form map that can be passed to the plugin. allowedHosts: [] # An optional set of hosts this plugin can communicate with. Defaults to no hosts allowed. fileSystem: createTempDir: Whether to create a temporary directory on the filesystem. Can be "true" or "false". timeout: The timeout in milliseconds for the plugin to execute hostFunctions: HostFunction names exposed in Helm the plugin may access. See https://extism.org/docs/concepts/host-functions/ entryFuncName: The name of entry function name to call in the plugin. Defaults to "helm_plugin_main". ``` - `allowedHosts` only has an effect if the plugin makes HTTP requests. If not specified, then no hosts are allowed. ================================================ FILE: docs/plugins/user/index.md ================================================ --- title: Plugins User Guide sidebar_label: Using Plugins sidebar_position: 2 --- For an overview of Helm Plugin concepts, how to read their structure, and how to understand what their configurations mean for you as a user, read the [Plugins Overview](/plugins/overview.md). This section focuses on using Helm Plugins as an end-user. ## Finding Plugins You can already find [Helm Plugins on ArtifactHub](https://artifacthub.io/packages/search?kind=6). The Helm 4 Plugin system is brand new. In the near future, you should be able to search plugins by type and runtime on ArtifactHub. Stay tuned for updates on this! ## Plugin Security Depending on the plugin runtime, you should inspect any plugin from third parties before running on your system. - Subprocess runtime has as much access to your system as the user running the commands. Be sure to carefully inspect the plugin code before installing a plugin, uninstalling a plugin, or running any helm commands that could also run these plugins. - Wasm runtime, by contrast, runs in a secure sandbox with only the access to your system that you explicitly approve. This plugin runtime has much stronger controls and an inherently higher level of built-in safety. You should still inspect `plugin.yaml` to know what permissions the plugin is requesting. In both cases, it is highly recommended to verify the provenance of even a Wasm runtime plugin before installing it, so that you can trust where it is downloaded from and who created it. This not only protects you from accidentally installing plugins from spoofed URL attacks, but also network hijacking attacks. Plugin verification allows you to cryptographically ensure a chart has not been compromised before you install it. See the `--verify` flag in `helm plugin install --help`. You may also verify the provenance of already installed plugins with `helm plugin verify --help`, in case verification was bypassed during installation (for development purposes), as well as to help provide you with security compliance information at any time. The `helm plugin list` command also includes high-level provenance information at a glance. ## Installing Plugins Helm has a built-in command to install plugins that defaults to secure installation. However, be sure to read [Plugin Security](#plugin-security) to understand what to check before installing. See `helm plugin install --help` for more information. ## Listing Installed Plugins The command to list plugins includes the plugin's name, version, type, API version, provenance, and source. See `helm plugin list --help` for more information. ## Uninstalling Plugins Uninstalling plugins is intended to be straightforward and easy. However, be sure to read [Plugin Security](#plugin-security) to understand the risks of uninstalling as well. See `helm plugin uninstall --help`. ================================================ FILE: docs/sdk/examples.mdx ================================================ --- title: Examples description: Examples of various features of the Helm SDK sidebar_position: 2 --- import CodeBlock from '@theme/CodeBlock'; import MainExampleGo from '!!raw-loader!/sdkexamples/main.go'; import InstallExampleGo from '!!raw-loader!/sdkexamples/install.go'; import ListExampleGo from '!!raw-loader!/sdkexamples/list.go'; import PullExampleGo from '!!raw-loader!/sdkexamples/pull.go'; import UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go'; import UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go'; This document runs though a series of examples of using the Helm SDK. Intended to document various SDK functionalities. The final example shows `main.go` driver ([link](#driver)). That runs the below actions and includes necessary helper functions. The code for the examples lives in the [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) directory. And is intended to be fully functional. ## Actions ### Install Action This example installs the given chart/release, for the given version and values: {InstallExampleGo} ### Upgrade Action This example upgrades the given release, with the given chart, version and values: {UpgradeExampleGo} ### Uninstall Action This example uninstalls the given release: {UninstallExampleGo} ### List Action This example lists all released charts (in the currently configured namespace): {ListExampleGo} ### Pull Action This example pulls a chart from an OCI repository: {PullExampleGo} ## Driver The driver here shows the necessary auxiliary functions needed for the Helm SDK actions to function. And shows the above examples in action, to pull, install, update, and uninstall the 'podinfo' chart from an OCI repository: {MainExampleGo} ================================================ FILE: docs/sdk/gosdk.mdx ================================================ --- title: Introduction description: Introduces the Helm Go SDK sidebar_position: 1 --- Helm's Go SDK enables custom software to leverage Helm charts and Helm's functionality for managing Kubernetes software deployment (In fact, the Helm CLI is effectively just one such tool!). Currently, the SDK has been functionally separated from the Helm CLI. And the SDK can (and is) used by standalone tooling. The Helm project has committed to API stability for the SDK. As a warning, the SDK has some rough edges remaining from the initial work to separate the CLI and the SDK, which the Helm project aims to improve over time. Full API documentation can be found at [https://pkg.go.dev/helm.sh/helm/v4](https://pkg.go.dev/helm.sh/helm/v4). A brief overview of some of the main types of packages and a simple example follows below. See the [Examples](/sdk/examples.mdx) section for more examples and a more full featured 'driver'. ## Main package overview - [pkg/action](https://pkg.go.dev/helm.sh/helm/v4/pkg/action): Contains the main “client” for performing Helm actions. This is the same package that the CLI is using underneath the hood. If you just need to perform basic Helm commands from another Go program, this package is for you. - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v4/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v4/pkg/chart/v2/util): Methods and helpers used for loading and manipulating charts. - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v4/pkg/cli) and its subpackages: Contains all the handlers for the standard Helm environment variables and its subpackages contain output and values file handling. - [pkg/release](https://pkg.go.dev/helm.sh/helm/v4/pkg/release): Defines the `Release` object and statuses. There are many more packages besides these, so go check out the documentation for more information! ### Simple example This is a simple example of doing a `helm list` using the Go SDK. See the [Examples](/sdk/examples.mdx) section for more full featured examples. ```go package main import ( "log" "os" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Compatibility The Helm SDK explicitly follows the Helm backwards compatibility guarantees: https://github.com/helm/community/blob/main/hips/hip-0004.md That is, breaking changes will only be made with a major version release or to remediate a security issue. ================================================ FILE: docs/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/topics/advanced.mdx ================================================ --- title: Advanced Helm Techniques description: Explains various advanced features for Helm power users sidebar_position: 9 --- import Helm4 from "/docs/_v4-in-progress.mdx" This section explains various advanced features and techniques for using Helm. The information in this section is intended for "power users" of Helm that wish to do advanced customization and manipulation of their charts and releases. Each of these advanced features comes with their own tradeoffs and caveats, so each one must be used carefully and with deep knowledge of Helm. Or in other words, remember the [Peter Parker principle](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility) ## Post Rendering Post rendering gives chart installers the ability to manually manipulate, configure, and/or validate rendered manifests before they are installed by Helm. This allows users with advanced configuration needs to be able to use tools like [`kustomize`](https://kustomize.io) to apply configuration changes without the need to fork a public chart or requiring chart maintainers to specify every last configuration option for a piece of software. There are also use cases for injecting common tools and side cars in enterprise environments or analysis of the manifests before deployment. ### Prerequisites - Helm 3.1+ ### Usage A post-renderer can be any executable that accepts rendered Kubernetes manifests on STDIN and returns valid Kubernetes manifests on STDOUT. It should return an non-0 exit code in the event of a failure. This is the only "API" between the two components. It allows for great flexibility in what you can do with your post-render process. A post-renderer can be used with `install`, `upgrade`, and `template`. To use a post-renderer, use the `--post-renderer` flag with a path to the renderer executable you wish to use: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` If the path does not contain any separators, it will search in $PATH, otherwise it will resolve any relative paths to a fully qualified path If you wish to use multiple post-renderers, call all of them in a script or together in whatever binary tool you have built. In bash, this would be as simple as `renderer1 | renderer2 | renderer3`. You can see an example of using `kustomize` as a post-renderer [here](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). #### Filenames Each manifest passed to the post-renderer includes a temporary annotation: ```yaml metadata: annotations: postrenderer.helm.sh/postrender-filename: ``` Helm uses this annotation when reading back the post-renderer’s output to determine which filename to associate with each manifest for further processing. If the annotation is missing, Helm auto-generates a filename in the format `generated-by-postrender-.yaml`. Finally, Helm removes the annotation before sending the manifests to Kubernetes. #### Hooks and Post-Render Strategy In Helm 4, [chart hooks](/topics/charts_hooks.md) are processed by post-renderers along with regular templates. By default, hooks and templates are sent together in a single stream (the `combined` strategy). This is a change from Helm 3, which never sent hooks to post-renderers. You can control this behavior via the Go SDK using the `PostRenderStrategy` option: | Strategy | Behavior | |----------|----------| | `combined` | Sends hooks and templates together as one stream. This is the default in Helm 4. | | `separate` | Sends hooks and templates as independent invocations to the post-renderer. Useful when the same resource (like a ServiceAccount) appears in both a hook and a template. | | `nohooks` | Sends only templates to the post-renderer; hooks are left untouched. Matches Helm 3 behavior. | **For Kustomize users**: If your Kustomize configuration includes patches that target resources only present in templates (not hooks), use `nohooks`. The `separate` strategy invokes the post-renderer twice—once for hooks and once for templates—and Kustomize patches targeting template-only resources will fail when run against the hook stream. Flux helm-controller defaults to `nohooks` for this reason. ### Caveats When using post renderers, there are several important things to keep in mind. The most important of these is that when using a post-renderer, all people modifying that release **MUST** use the same renderer in order to have repeatable builds. This feature is purposefully built to allow any user to switch out which renderer they are using or to stop using a renderer, but this should be done deliberately to avoid accidental modification or data loss. One other important note is around security. If you are using a post-renderer, you should ensure it is coming from a reliable source (as is the case for any other arbitrary executable). Using non-trusted or non-verified renderers is NOT recommended as they have full access to rendered templates, which often contain secret data. ### Custom Post Renderers The post render step offers even more flexibility when used in the Go SDK. Any post renderer only needs to implement the following Go interface: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` For more information on using the Go SDK, See the [Go SDK section](#go-sdk) ## Go SDK Helm 3 debuted a completely restructured Go SDK for a better experience when building software and tools that leverage Helm. Full documentation can be found in the [Go SDK Section](/sdk/gosdk.mdx). ## Storage backends By default, release information is stored in Secrets in the namespace of the release. The subsections which follow show how to configure different backends. This configuration is based on the `HELM_DRIVER` environment variable. It can be set to one of the values: `[configmap, secret, sql]`. ### ConfigMap storage backend To enable the ConfigMap backend, you'll need to set the environmental variable `HELM_DRIVER` to `configmap`. You can set it in a shell as follows: ```shell export HELM_DRIVER=configmap ``` If you want to switch from the default backend to the ConfigMap backend, you'll have to do the migration for this on your own. You can retrieve release information with the following command: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **PRODUCTION NOTES**: The release information includes the contents of charts and values files, and therefore might contain sensitive data (like passwords, private keys, and other credentials) that needs to be protected from unauthorized access. When managing Kubernetes authorization, for instance with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), it is possible to grant broader access to ConfigMap resources, while restricting access to Secret resources. For instance, the default [user-facing role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" grants access to most resources, but not to Secrets. Furthermore, secrets data can be configured for [encrypted storage](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Please keep that in mind if you decide to switch to the ConfigMap backend, as it could expose your application's sensitive data. ### SQL storage backend There is a ***beta*** SQL storage backend that stores release information in an SQL database. Using such a storage backend is particularly useful if your release information weighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets because of internal limits in Kubernetes' underlying etcd key-value store). To enable the SQL backend, you'll need to deploy a SQL database and set the environmental variable `HELM_DRIVER` to `sql`. The DB details are set with the environmental variable `HELM_DRIVER_SQL_CONNECTION_STRING`. You can set it in a shell as follows: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Note: Only PostgreSQL is supported at this moment. **PRODUCTION NOTES**: It is recommended to: - Make your database production ready. For PostgreSQL, refer to the [Server Administration](https://www.postgresql.org/docs/12/admin.html) docs for more details - Enable [permission management](/topics/permissions_sql_storage_backend.md) to mirror Kubernetes RBAC for release information If you want to switch from the default backend to the SQL backend, you'll have to do the migration for this on your own. You can retrieve release information with the following command: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: docs/topics/architecture.md ================================================ --- title: Helm Architecture description: Describes the Helm architecture at a high level. sidebar_position: 8 --- # Helm Architecture This document describes the Helm architecture at a high level. ## The Purpose of Helm Helm is a tool for managing Kubernetes packages called _charts_. Helm can do the following: - Create new charts from scratch - Package charts into chart archive (tgz) files - Interact with chart repositories where charts are stored - Install and uninstall charts into an existing Kubernetes cluster - Manage the release cycle of charts that have been installed with Helm For Helm, there are three important concepts: 1. The _chart_ is a bundle of information necessary to create an instance of a Kubernetes application. 2. The _config_ contains configuration information that can be merged into a packaged chart to create a releasable object. 3. A _release_ is a running instance of a _chart_, combined with a specific _config_. ## Components Helm is an executable which is implemented into two distinct parts: **The Helm Client** is a command-line client for end users. The client is responsible for the following: - Local chart development - Managing repositories - Managing releases - Interfacing with the Helm library - Sending charts to be installed - Requesting upgrading or uninstalling of existing releases **The Helm Library** provides the logic for executing all Helm operations. It interfaces with the Kubernetes API server and provides the following capability: - Combining a chart and configuration to build a release - Installing charts into Kubernetes, and providing the subsequent release object - Upgrading and uninstalling charts by interacting with Kubernetes The standalone Helm library encapsulates the Helm logic so that it can be leveraged by different clients. ## Implementation The Helm client and library is written in the Go programming language. The library uses the Kubernetes client library to communicate with Kubernetes. Currently, that library uses REST+JSON. It stores information in Secrets located inside of Kubernetes. It does not need its own database. Configuration files are, when possible, written in YAML. ================================================ FILE: docs/topics/chart_repository.md ================================================ --- title: The Chart Repository Guide description: How to create and work with Helm chart repositories. sidebar_position: 6 --- This section explains how to create and work with Helm chart repositories. At a high level, a chart repository is a location where packaged charts can be stored and shared. The distributed community Helm chart repository is located at [Artifact Hub](https://artifacthub.io/packages/search?kind=0) and welcomes participation. But Helm also makes it possible to create and run your own chart repository. This guide explains how to do so. If you are considering creating a chart repository, you may want to consider using an [OCI registry](/topics/registries.mdx) instead. ## Prerequisites * Go through the [Quickstart](/intro/quickstart.md) Guide * Read through the [Charts](/topics/charts.mdx) document ## Create a chart repository A _chart repository_ is an HTTP server that houses an `index.yaml` file and optionally some packaged charts. When you're ready to share your charts, the preferred way to do so is by uploading them to a chart repository. As of Helm 2.2.0, client-side SSL auth to a repository is supported. Other authentication protocols may be available as plugins. Because a chart repository can be any HTTP server that can serve YAML and tar files and can answer GET requests, you have a plethora of options when it comes down to hosting your own chart repository. For example, you can use a Google Cloud Storage (GCS) bucket, Amazon S3 bucket, GitHub Pages, or even create your own web server. ### The chart repository structure A chart repository consists of packaged charts and a special file called `index.yaml` which contains an index of all of the charts in the repository. Frequently, the charts that `index.yaml` describes are also hosted on the same server, as are the [provenance files](/topics/provenance.mdx). For example, the layout of the repository `https://example.com/charts` might look like this: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` In this case, the index file would contain information about one chart, the Alpine chart, and provide the download URL `https://example.com/charts/alpine-0.1.2.tgz` for that chart. It is not required that a chart package be located on the same server as the `index.yaml` file. However, doing so is often the easiest. ### The index file The index file is a yaml file called `index.yaml`. It contains some metadata about the package, including the contents of a chart's `Chart.yaml` file. A valid chart repository must have an index file. The index file contains information about each chart in the chart repository. The `helm repo index` command will generate an index file based on a given local directory that contains packaged charts. This is an example of an index file: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Hosting Chart Repositories This part shows several ways to serve a chart repository. ### Google Cloud Storage The first step is to **create your GCS bucket**. We'll call ours `fantastic-charts`. ![Create a GCS Bucket](/img/helm2/create-a-bucket.png) Next, make your bucket public by **editing the bucket permissions**. ![Edit Permissions](/img/helm2/edit-permissions.png) Insert this line item to **make your bucket public**: ![Make Bucket Public](/img/helm2/make-bucket-public.png) Congratulations, now you have an empty GCS bucket ready to serve charts! You may upload your chart repository using the Google Cloud Storage command line tool, or using the GCS web UI. A public GCS bucket can be accessed via simple HTTPS at this address: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith You can also set up chart repositories using Cloudsmith. Read more about chart repositories with Cloudsmith [here](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory Similarly, you can also set up chart repositories using JFrog Artifactory. Read more about chart repositories with JFrog Artifactory [here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### GitHub Pages example In a similar way you can create charts repository using GitHub Pages. GitHub allows you to serve static web pages in two different ways: - By configuring a project to serve the contents of its `docs/` directory - By configuring a project to serve a particular branch We'll take the second approach, though the first is just as easy. The first step will be to **create your gh-pages branch**. You can do that locally as. ```console $ git checkout -b gh-pages ``` Or via web browser using **Branch** button on your GitHub repository: ![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png) Next, you'll want to make sure your **gh-pages branch** is set as GitHub Pages, click on your repo **Settings** and scroll down to **GitHub pages** section and set as per below: ![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png) By default **Source** usually gets set to **gh-pages branch**. If this is not set by default, then select it. You can use a **custom domain** there if you wish so. And check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when charts are served. In such setup you can use your default branch to store your charts code, and **gh-pages branch** as charts repository, e.g.: `https://USERNAME.github.io/REPONAME`. The demonstration [TS Charts](https://github.com/technosophos/tscharts) repository is accessible at `https://technosophos.github.io/tscharts/`. If you have decided to use GitHub pages to host the chart repository, check out [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action is a GitHub Action workflow to turn a GitHub project into a self-hosted Helm chart repo, using [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool. ### Ordinary web servers To configure an ordinary web server to serve Helm charts, you merely need to do the following: - Put your index and charts in a directory that the server can serve - Make sure the `index.yaml` file can be accessed with no authentication requirement - Make sure `yaml` files are served with the correct content type (`text/yaml` or `text/x-yaml`) For example, if you want to serve your charts out of `$WEBROOT/charts`, make sure there is a `charts/` directory in your web root, and put the index file and charts inside of that folder. ### ChartMuseum Repository Server ChartMuseum is an open-source Helm Chart Repository server written in Go (Golang), with support for cloud storage backends, including [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), and [etcd](https://etcd.io/). You can also use the [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) server to host a chart repository from a local file system. ### GitLab Package Registry With GitLab you can publish Helm charts in your project’s Package Registry. Read more about setting up a helm package repository with GitLab [here](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Managing Chart Repositories Now that you have a chart repository, the last part of this guide explains how to maintain charts in that repository. ### Store charts in your chart repository Now that you have a chart repository, let's upload a chart and an index file to the repository. Charts in a chart repository must be packaged (`helm package chart-name/`) and versioned correctly (following [SemVer 2](https://semver.org/) guidelines). These next steps compose an example workflow, but you are welcome to use whatever workflow you fancy for storing and updating charts in your chart repository. Once you have a packaged chart ready, create a new directory, and move your packaged chart to that directory. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` The last command takes the path of the local directory that you just created and the URL of your remote chart repository and composes an `index.yaml` file inside the given directory path. Now you can upload the chart and the index file to your chart repository using a sync tool or manually. If you're using Google Cloud Storage, check out this [example workflow](/howto/chart_repository_sync_example.md) using the gsutil client. For GitHub, you can simply put the charts in the appropriate destination branch. ### Add new charts to an existing repository Each time you want to add a new chart to your repository, you must regenerate the index. The `helm repo index` command will completely rebuild the `index.yaml` file from scratch, including only the charts that it finds locally. However, you can use the `--merge` flag to incrementally add new charts to an existing `index.yaml` file (a great option when working with a remote repository like GCS). Run `helm repo index --help` to learn more, Make sure that you upload both the revised `index.yaml` file and the chart. And if you generated a provenance file, upload that too. ### Share your charts with others When you're ready to share your charts, simply let someone know what the URL of your repository is. From there, they will add the repository to their helm client via the `helm repo add [NAME] [URL]` command with any name they would like to use to reference the repository. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` If the charts are backed by HTTP basic authentication, you can also supply the username and password here: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Note:** A repository will not be added if it does not contain a valid `index.yaml`. **Note:** If your helm repository is e.g. using a self signed certificate, you can use `helm repo add --insecure-skip-tls-verify ...` in order to skip the CA verification. After that, your users will be able to search through your charts. After you've updated the repository, they can use the `helm repo update` command to get the latest chart information. *Under the hood, the `helm repo add` and `helm repo update` commands are fetching the index.yaml file and storing them in the `$XDG_CACHE_HOME/helm/repository/cache/` directory. This is where the `helm search` function finds information about charts.* ================================================ FILE: docs/topics/chart_tests.md ================================================ --- title: Chart Tests description: Describes how to run and test your charts. sidebar_position: 3 --- A chart contains a number of Kubernetes resources and components that work together. As a chart author, you may want to write some tests that validate that your chart works as expected when it is installed. These tests also help the chart consumer understand what your chart is supposed to do. A **test** in a helm chart lives under the `templates/` directory and is a job definition that specifies a container with a given command to run. The container should exit successfully (exit 0) for a test to be considered a success. The job definition must contain the helm test hook annotation: `helm.sh/hook: test`. Note that until Helm v3, the job definition needed to contain one of these helm test hook annotations: `helm.sh/hook: test-success` or `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` is still accepted as a backwards-compatible alternative to `helm.sh/hook: test`. Example tests: - Validate that your configuration from the values.yaml file was properly injected. - Make sure your username and password work correctly - Make sure an incorrect username and password does not work - Assert that your services are up and correctly load balancing - etc. You can run the pre-defined tests in Helm on a release using the command `helm test `. For a chart consumer, this is a great way to check that their release of a chart (or application) works as expected. ## Example Test The [helm create](/helm/helm_create.md) command will automatically create a number of folders and files. To try the helm test functionality, first create a demo helm chart. ```console $ helm create demo ``` You will now be able to see the following structure in your demo helm chart. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` In `demo/templates/tests/test-connection.yaml` you'll see a test you can try. You can see the helm test pod definition here: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Steps to Run a Test Suite on a Release First, install the chart on your cluster to create a release. You may have to wait for all pods to become active; if you test immediately after this install, it is likely to show a transitive failure, and you will want to re-test. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Notes - You can define as many tests as you would like in a single yaml file or spread across several yaml files in the `templates/` directory. - You are welcome to nest your test suite under a `tests/` directory like `/templates/tests/` for more isolation. - A test is a [Helm hook](/topics/charts_hooks.md), so annotations like `helm.sh/hook-weight` and `helm.sh/hook-delete-policy` may be used with test resources. ================================================ FILE: docs/topics/charts.mdx ================================================ --- title: Charts description: Explains the chart format, and provides basic guidance for building charts with Helm. sidebar_position: 1 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm uses a packaging format called _charts_. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on. Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed. If you want to download and look at the files for a published chart, without installing it, you can do so with `helm pull chartrepo/chartname`. This document explains the chart format, and provides basic guidance for building charts with Helm. ## The Chart File Structure A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing WordPress would be stored in a `wordpress/` directory. Inside of this directory, Helm will expect a structure that matches this: ```text wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file values.yaml # The default configuration values for this chart values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file charts/ # A directory containing any charts upon which this chart depends. crds/ # Custom Resource Definitions templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Helm reserves use of the `charts/`, `crds/`, and `templates/` directories, and of the listed file names. Other files will be left as they are. ## The Chart.yaml File The `Chart.yaml` file is required for a chart. It contains the following fields: ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` As of [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), additional fields are not allowed. The recommended approach is to add custom metadata in `annotations`. ### Charts and Versioning Every chart must have a version number. A version should follow the [SemVer 2](https://semver.org/spec/v2.0.0.html) standard but it is not strictly enforced. Unlike Helm Classic, Helm v2 and later uses version numbers as release markers. Packages in repositories are identified by name plus version. For example, an `nginx` chart whose version field is set to `version: 1.2.3` will be named: ```text nginx-1.2.3.tgz ``` More complex SemVer 2 names are also supported, such as `version: 1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly disallowed by the system. Subject to exception are versions in format `x` or `x.y`. For example, if there is a leading v or a version listed without all 3 parts (e.g. v1.2) it will attempt to coerce it into a valid semantic version (e.g., v1.2.0). **NOTE:** Whereas Helm Classic and Deployment Manager were both very GitHub oriented when it came to charts, Helm v2 and later does not rely upon or require GitHub or even Git. Consequently, it does not use Git SHAs for versioning at all. The `version` field inside of the `Chart.yaml` is used by many of the Helm tools, including the CLI. When generating a package, the `helm package` command will use the version that it finds in the `Chart.yaml` as a token in the package name. The system assumes that the version number in the chart package name matches the version number in the `Chart.yaml`. Failure to meet this assumption will cause an error. ### The `apiVersion` Field The `apiVersion` field should be `v2` for Helm charts that require at least Helm 3. Charts supporting previous Helm versions have an `apiVersion` set to `v1` and are still installable by Helm 3. Changes from `v1` to `v2`: - A `dependencies` field defining chart dependencies, which were located in a separate `requirements.yaml` file for `v1` charts (see [Chart Dependencies](#chart-dependencies)). - The `type` field, discriminating application and library charts (see [Chart Types](#chart-types)). ### The `appVersion` Field Note that the `appVersion` field is not related to the `version` field. It is a way of specifying the version of the application. For example, the `drupal` chart may have an `appVersion: "8.2.1"`, indicating that the version of Drupal included in the chart (by default) is `8.2.1`. This field is informational, and has no impact on chart version calculations. Wrapping the version in quotes is highly recommended. It forces the YAML parser to treat the version number as a string. Leaving it unquoted can lead to parsing issues in some cases. For example, YAML interprets `1.0` as a floating point value, and a git commit SHA like `1234e10` as scientific notation. As of Helm v3.5.0, `helm create` wraps the default `appVersion` field in quotes. ### The `kubeVersion` Field The optional `kubeVersion` field can define semver constraints on supported Kubernetes versions. Helm will validate the version constraints when installing the chart and fail if the cluster runs an unsupported Kubernetes version. Version constraints may comprise space separated AND comparisons such as ``` >= 1.13.0 < 1.15.0 ``` which themselves can be combined with the OR `||` operator like in the following example ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` In this example the version `1.14.0` is excluded, which can make sense if a bug in certain versions is known to prevent the chart from running properly. Apart from version constrains employing operators `=` `!=` `>` `<` `>=` `<=` the following shorthand notations are supported * hyphen ranges for closed intervals, where `1.1 - 2.3.4` is equivalent to `>= 1.1 <= 2.3.4`. * wildcards `x`, `X` and `*`, where `1.2.x` is equivalent to `>= 1.2.0 < 1.3.0`. * tilde ranges (patch version changes allowed), where `~1.2.3` is equivalent to `>= 1.2.3 < 1.3.0`. * caret ranges (minor version changes allowed), where `^1.2.3` is equivalent to `>= 1.2.3 < 2.0.0`. For a detailed explanation of supported semver constraints see [Masterminds/semver](https://github.com/Masterminds/semver). ### Deprecating Charts When managing charts in a Chart Repository, it is sometimes necessary to deprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used to mark a chart as deprecated. If the **latest** version of a chart in the repository is marked as deprecated, then the chart as a whole is considered to be deprecated. The chart name can be later reused by publishing a newer version that is not marked as deprecated. The workflow for deprecating charts is: 1. Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the version 2. Release the new chart version in the Chart Repository 3. Remove the chart from the source repository (e.g. git) ### Chart Types The `type` field defines the type of chart. There are two types: `application` and `library`. Application is the default type and it is the standard chart which can be operated on fully. The [library chart](/topics/library_charts.md) provides utilities or functions for the chart builder. A library chart differs from an application chart because it is not installable and usually doesn't contain any resource objects. **Note:** An application chart can be used as a library chart. This is enabled by setting the type to `library`. The chart will then be rendered as a library chart where all utilities and functions can be leveraged. All resource objects of the chart will not be rendered. ## Chart LICENSE, README and NOTES Charts can also contain files that describe the installation, configuration, usage and license of a chart. A LICENSE is a plain text file containing the [license](https://en.wikipedia.org/wiki/Software_license) for the chart. The chart can contain a license as it may have programming logic in the templates and would therefore not be configuration only. There can also be separate license(s) for the application installed by the chart, if required. A README for a chart should be formatted in Markdown (README.md), and should generally contain: - A description of the application or service the chart provides - Any prerequisites or requirements to run the chart - Descriptions of options in `values.yaml` and default values - Any other information that may be relevant to the installation or configuration of the chart When hubs and other user interfaces display details about a chart that detail is pulled from the content in the `README.md` file. The chart can also contain a short plain text `templates/NOTES.txt` file that will be printed out after installation, and when viewing the status of a release. This file is evaluated as a [template](#templates-and-values), and can be used to display usage notes, next steps, or any other information relevant to a release of the chart. For example, instructions could be provided for connecting to a database, or accessing a web UI. Since this file is printed to STDOUT when running `helm install` or `helm status`, it is recommended to keep the content brief and point to the README for greater detail. ## Chart Dependencies In Helm, one chart may depend on any number of other charts. These dependencies can be dynamically linked using the `dependencies` field in `Chart.yaml` or brought in to the `charts/` directory and managed manually. ### Managing Dependencies with the `dependencies` field The charts required by the current chart are defined as a list in the `dependencies` field. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - The `name` field is the name of the chart you want. - The `version` field is the version of the chart you want. - The `repository` field is the full URL to the chart repository. Note that you must also use `helm repo add` to add that repo locally. - You might use the name of the repo instead of URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Once you have defined dependencies, you can run `helm dependency update` and it will use your dependency file to download all the specified charts into your `charts/` directory for you. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` When `helm dependency update` retrieves charts, it will store them as chart archives in the `charts/` directory. So for the example above, one would expect to see the following files in the charts directory: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Alias field in dependencies In addition to the other fields above, each requirements entry may contain the optional field `alias`. Adding an alias for a dependency chart would put a chart in dependencies using alias as name of new dependency. One can use `alias` in cases where they need to access a chart with other name(s). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` In the above example we will get 3 dependencies in all for `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` The manual way of achieving this is by copy/pasting the same chart in the `charts/` directory multiple times with different names. #### Tags and Condition fields in dependencies In addition to the other fields above, each requirements entry may contain the optional fields `tags` and `condition`. All charts are loaded by default. If `tags` or `condition` fields are present, they will be evaluated and used to control loading for the chart(s) they are applied to. Condition - The condition field holds one or more YAML paths (delimited by commas). If this path exists in the top parent's values and resolves to a boolean value, the chart will be enabled or disabled based on that boolean value. Only the first valid path found in the list is evaluated and if no paths exist then the condition has no effect. Tags - The tags field is a YAML list of labels to associate with this chart. In the top parent's values, all charts with tags can be enabled or disabled by specifying the tag and a boolean value. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` In the above example all charts with the tag `front-end` would be disabled but since the `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the `front-end` tag and `subchart1` will be enabled. Since `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be enabled. Also note that although `subchart2` has a condition specified, there is no corresponding path and value in the parent's values so that condition has no effect. ##### Using the CLI with Tags and Conditions The `--set` parameter can be used as usual to alter tag and condition values. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Tags and Condition Resolution - **Conditions (when set in values) always override tags.** The first condition path that exists wins and subsequent ones for that chart are ignored. - Tags are evaluated as 'if any of the chart's tags are true then enable the chart'. - Tags and conditions values must be set in the top parent's values. - The `tags:` key in values must be a top level key. Globals and nested `tags:` tables are not currently supported. #### Importing Child Values via dependencies In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be shared as common defaults. An additional benefit of using the `exports` format is that it will enable future tooling to introspect user-settable values. The keys containing the values to be imported can be specified in the parent chart's `dependencies` in the field `import-values` using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field. To import values not contained in the `exports` key, use the [child-parent](#using-the-child-parent-format) format. Examples of both formats are described below. ##### Using the exports format If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported directly into the parent's values by specifying the keys to import as in the example below: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Since we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child chart for `data` key and imports its contents. The final parent values would contain our exported field: ```yaml # parent's values myint: 99 ``` Please note the parent key `data` is not contained in the parent's final values. If you need to specify the parent key, use the 'child-parent' format. ##### Using the child-parent format To access values that are not contained in the `exports` key of the child chart's values, you will need to specify the source key of the values to be imported (`child`) and the destination path in the parent chart's values (`parent`). The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them to the parent's values at the path specified in `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` In the above example, values found at `default.data` in the subchart1's values will be imported to the `myimports` key in the parent chart's values as detailed below: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` The parent chart's resulting values would be: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` The parent's final values now contains the `myint` and `mybool` fields imported from subchart1. ### Managing Dependencies manually via the `charts/` directory If more control over dependencies is desired, these dependencies can be expressed explicitly by copying the dependency charts into the `charts/` directory. A dependency should be an unpacked chart directory but its name cannot start with `_` or `.`. Such files are ignored by the chart loader. For example, if the WordPress chart depends on the Apache chart, the Apache chart (of the correct version) is supplied in the WordPress chart's `charts/` directory: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` The example above shows how the WordPress chart expresses its dependency on Apache and MySQL by including those charts inside of its `charts/` directory. **TIP:** _To drop a dependency into your `charts/` directory, use the `helm pull` command_ ### Operational aspects of using dependencies The above sections explain how to specify chart dependencies, but how does this affect chart installation using `helm install` and `helm upgrade`? Suppose that a chart named "A" creates the following Kubernetes objects - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Furthermore, A is dependent on chart B that creates objects - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" After installation/upgrade of chart A a single Helm release is created/modified. The release will create/update all of the above Kubernetes objects in the following order: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet This is because when Helm installs/upgrades charts, the Kubernetes objects from the charts and all its dependencies are - aggregated into a single set; then - sorted by type followed by name; and then - created/updated in that order. Hence a single release is created with all the objects for the chart and its dependencies. The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go (see [the Helm source file](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates and Values Helm Chart templates are written in the [Go template language](https://golang.org/pkg/text/template/), with the addition of 50 or so add-on template functions [from the Sprig library](https://github.com/Masterminds/sprig) and a few other [specialized functions](/howto/charts_tips_and_tricks.md). All template files are stored in a chart's `templates/` folder. When Helm renders the charts, it will pass every file in that directory through the template engine. Values for the templates are supplied two ways: - Chart developers may supply a file called `values.yaml` inside of a chart. This file can contain default values. - Chart users may supply a YAML file that contains values. This can be provided on the command line with `helm install`. When a user supplies custom values, these values will override the values in the chart's `values.yaml` file. ### Template Files Template files follow the standard conventions for writing Go templates (see [the text/template Go package documentation](https://golang.org/pkg/text/template/) for details). An example template file might look something like this: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` The above example, based loosely on [https://github.com/deis/charts](https://github.com/deis/charts), is a template for a Kubernetes replication controller. It can use the following four template values (usually defined in a `values.yaml` file): - `imageRegistry`: The source registry for the Docker image. - `dockerTag`: The tag for the docker image. - `pullPolicy`: The Kubernetes pull policy. - `storage`: The storage backend, whose default is set to `"minio"` All of these values are defined by the template author. Helm does not require or dictate parameters. To see many working charts, check out the CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Predefined Values Values that are supplied via a `values.yaml` file (or via the `--set` flag) are accessible from the `.Values` object in a template. But there are other pre-defined pieces of data you can access in your templates. The following values are pre-defined, are available to every template, and cannot be overridden. As with all values, the names are _case sensitive_. - `Release.Name`: The name of the release (not the chart) - `Release.Namespace`: The namespace the chart was released to. - `Release.Service`: The service that conducted the release. - `Release.IsUpgrade`: This is set to true if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to true if the current operation is an install. - `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is obtainable as `Chart.Version` and the maintainers are in `Chart.Maintainers`. - `Files`: A map-like object containing all non-special files in the chart. This will not give you access to templates, but will give you access to additional files that are present (unless they are excluded using `.helmignore`). Files can be accessed using `{{ index .Files "file.name" }}` or using the `{{.Files.Get name }}` function. You can also access the contents of the file as `[]byte` using `{{ .Files.GetBytes }}` - `Capabilities`: A map-like object that contains information about the versions of Kubernetes (`{{ .Capabilities.KubeVersion }}`) and the supported Kubernetes API versions (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **NOTE:** Any unknown `Chart.yaml` fields will be dropped. They will not be accessible inside of the `Chart` object. Thus, `Chart.yaml` cannot be used to pass arbitrarily structured data into the template. The values file can be used for that, though. ### Values files Considering the template in the previous section, a `values.yaml` file that supplies the necessary values would look like this: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` A values file is formatted in YAML. A chart may include a default `values.yaml` file. The Helm install command allows a user to override values by supplying additional YAML values: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` When values are passed in this way, they will be merged into the default values file. For example, consider a `myvals.yaml` file that looks like this: ```yaml storage: "gcs" ``` When this is merged with the `values.yaml` in the chart, the resulting generated content will be: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Note that only the last field was overridden. **NOTE:** The default values file included inside of a chart _must_ be named `values.yaml`. But files specified on the command line can be named anything. **NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those values are simply converted to YAML on the client side. **NOTE:** If any required entries in the values file exist, they can be declared as required in the chart template by using the ['required' function](/howto/charts_tips_and_tricks.md) Any of these values are then accessible inside of templates using the `.Values` object: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Scope, Dependencies, and Values Values files can declare values for the top-level chart, as well as for any of the charts that are included in that chart's `charts/` directory. Or, to phrase it differently, a values file can supply values to the chart as well as to any of its dependencies. For example, the demonstration WordPress chart above has both `mysql` and `apache` as dependencies. The values file could supply values to all of these components: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Charts at a higher level have access to all of the variables defined beneath. So the WordPress chart can access the MySQL password as `.Values.mysql.password`. But lower level charts cannot access things in parent charts, so MySQL will not be able to access the `title` property. Nor, for that matter, can it access `apache.port`. Values are namespaced, but namespaces are pruned. So for the WordPress chart, it can access the MySQL password field as `.Values.mysql.password`. But for the MySQL chart, the scope of the values has been reduced and the namespace prefix removed, so it will see the password field simply as `.Values.password`. #### Global Values As of 2.0.0-Alpha.2, Helm supports special "global" value. Consider this modified version of the previous example: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` The above adds a `global` section with the value `app: MyWordPress`. This value is available to _all_ charts as `.Values.global.app`. For example, the `mysql` templates may access `app` as `{{ .Values.global.app}}`, and so can the `apache` chart. Effectively, the values file above is regenerated like this: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` This provides a way of sharing one top-level variable with all subcharts, which is useful for things like setting `metadata` properties like labels. If a subchart declares a global variable, that global will be passed _downward_ (to the subchart's subcharts), but not _upward_ to the parent chart. There is no way for a subchart to influence the values of the parent chart. Also, global variables of parent charts take precedence over the global variables from subcharts. ### Schema Files Sometimes, a chart maintainer might want to define a structure on their values. This can be done by defining a schema in the `values.schema.json` file. A schema is represented as a [JSON Schema](https://json-schema.org/). It might look something like this: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` This schema will be applied to the values to validate it. Validation occurs when any of the following commands are invoked: - `helm install` - `helm upgrade` - `helm lint` - `helm template` An example of a `values.yaml` file that meets the requirements of this schema might look something like this: ```yaml name: frontend protocol: https port: 443 ``` Note that the schema is applied to the final `.Values` object, and not just to the `values.yaml` file. This means that the following `yaml` file is valid, given that the chart is installed with the appropriate `--set` option shown below. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Furthermore, the final `.Values` object is checked against *all* subchart schemas. This means that restrictions on a subchart can't be circumvented by a parent chart. This also works backwards - if a subchart has a requirement that is not met in the subchart's `values.yaml` file, the parent chart *must* satisfy those restrictions in order to be valid. Schema validation can be disabled by setting the option shown below. This is particularly useful in air-gapped environments when a chart's JSON Schema file contains remote references. ```console helm install --skip-schema-validation ``` ### References When it comes to writing templates, values, and schema files, there are several standard references that will help you out. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) Kubernetes provides a mechanism for declaring new types of Kubernetes objects. Using CustomResourceDefinitions (CRDs), Kubernetes developers can declare custom resource types. In Helm 3, CRDs are treated as a special kind of object. They are installed before the rest of the chart, and are subject to some limitations. CRD YAML files should be placed in the `crds/` directory inside of a chart. Multiple CRDs (separated by YAML start and end markers) may be placed in the same file. Helm will attempt to load _all_ of the files in the CRD directory into Kubernetes. CRD files _cannot be templated_. They must be plain YAML documents. When Helm installs a new chart, it will upload the CRDs, pause until the CRDs are made available by the API server, and then start the template engine, render the rest of the chart, and upload it to Kubernetes. Because of this ordering, CRD information is available in the `.Capabilities` object in Helm templates, and Helm templates may create new instances of objects that were declared in CRDs. For example, if your chart had a CRD for `CronTab` in the `crds/` directory, you may create instances of the `CronTab` kind in the `templates/` directory: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` The `crontab.yaml` file must contain the CRD with no template directives: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Then the template `mycrontab.yaml` may create a new `CronTab` (using templates as usual): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm will make sure that the `CronTab` kind has been installed and is available from the Kubernetes API server before it proceeds installing the things in `templates/`. ### Limitations on CRDs Unlike most objects in Kubernetes, CRDs are installed globally. For that reason, Helm takes a very cautious approach in managing CRDs. CRDs are subject to the following limitations: - CRDs are never reinstalled. If Helm determines that the CRDs in the `crds/` directory are already present (regardless of version), Helm will not attempt to install or upgrade. - CRDs are never installed on upgrade or rollback. Helm will only create CRDs on installation operations. - CRDs are never deleted. Deleting a CRD automatically deletes all of the CRD's contents across all namespaces in the cluster. Consequently, Helm will not delete CRDs. Operators who want to upgrade or delete CRDs are encouraged to do this manually and with great care. ## Using Helm to Manage Charts The `helm` tool has several commands for working with charts. It can create a new chart for you: ```console $ helm create mychart Created mychart/ ``` Once you have edited a chart, `helm` can package it into a chart archive for you: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` You can also use `helm` to help you find issues with your chart's formatting or information: ```console $ helm lint mychart No issues found ``` ## Chart Repositories A _chart repository_ is an HTTP server that houses one or more packaged charts. While `helm` can be used to manage local chart directories, when it comes to sharing charts, the preferred mechanism is a chart repository. Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server. The Helm team has tested some servers, including Google Cloud Storage with website mode enabled, and S3 with website mode enabled. A repository is characterized primarily by the presence of a special file called `index.yaml` that has a list of all of the packages supplied by the repository, together with metadata that allows retrieving and verifying those packages. On the client side, repositories are managed with the `helm repo` commands. However, Helm does not provide tools for uploading charts to remote repository servers. This is because doing so would add substantial requirements to an implementing server, and thus raise the barrier for setting up a repository. ## Chart Starter Packs The `helm create` command takes an optional `--starter` option that lets you specify a "starter chart". Also, the starter option has a short alias `-p`. Examples of usage: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Starters are just regular charts, but are located in `$XDG_DATA_HOME/helm/starters`. As a chart developer, you may author charts that are specifically designed to be used as starters. Such charts should be designed with the following considerations in mind: - The `Chart.yaml` will be overwritten by the generator. - Users will expect to modify such a chart's contents, so documentation should indicate how users can do so. - All occurrences of `` will be replaced with the specified chart name so that starter charts can be used as templates, except for some variable files. For example, if you use custom files in the `vars` directory or certain `README.md` files, `` will NOT override inside them. Additionally, the chart description is not inherited. Currently the only way to add a chart to `$XDG_DATA_HOME/helm/starters` is to manually copy it there. In your chart's documentation, you may want to explain that process. ================================================ FILE: docs/topics/charts_hooks.md ================================================ --- title: Chart Hooks description: Describes how to work with chart hooks. sidebar_position: 2 --- Helm provides a _hook_ mechanism to allow chart developers to intervene at certain points in a release's life cycle. For example, you can use hooks to: - Load a ConfigMap or Secret during install before any other charts are loaded. - Execute a Job to back up a database before installing a new chart, and then execute a second job after the upgrade in order to restore data. - Run a Job before deleting a release to gracefully take a service out of rotation before removing it. Hooks work like regular templates, but they have special annotations that cause Helm to utilize them differently. In this section, we cover the basic usage pattern for hooks. ## The Available Hooks The following hooks are defined: | Annotation Value | Description | | ---------------- | ----------------------------------------------------------------------------------------------------- | | `pre-install` | Executes after templates are rendered, but before any resources are created in Kubernetes | | `post-install` | Executes after all resources are loaded into Kubernetes | | `pre-delete` | Executes on a deletion request before any resources are deleted from Kubernetes | | `post-delete` | Executes on a deletion request after all of the release's resources have been deleted | | `pre-upgrade` | Executes on an upgrade request after templates are rendered, but before any resources are updated | | `post-upgrade` | Executes on an upgrade request after all resources have been upgraded | | `pre-rollback` | Executes on a rollback request after templates are rendered, but before any resources are rolled back | | `post-rollback` | Executes on a rollback request after all resources have been modified | | `test` | Executes when the Helm test subcommand is invoked ([view test docs](/topics/chart_tests.md)) | _Note that the `crd-install` hook has been removed in favor of the `crds/` directory in Helm 3._ ## Hooks and the Release Lifecycle Hooks allow you, the chart developer, an opportunity to perform operations at strategic points in a release lifecycle. For example, consider the lifecycle for a `helm install`. By default, the lifecycle looks like this: 1. User runs `helm install foo` 2. The Helm library install API is called 3. After some verification, the library renders the `foo` templates 4. The library loads the resulting resources into Kubernetes 5. The library returns the release object (and other data) to the client 6. The client exits Helm defines two hooks for the `install` lifecycle: `pre-install` and `post-install`. If the developer of the `foo` chart implements both hooks, the lifecycle is altered like this: 1. User runs `helm install foo` 2. The Helm library install API is called 3. CRDs in the `crds/` directory are installed 4. After some verification, the library renders the `foo` templates 5. The library prepares to execute the `pre-install` hooks (loading hook resources into Kubernetes) 6. The library sorts hooks by weight (assigning a weight of 0 by default), by resource kind and finally by name in ascending order. 7. The library then loads the hook with the lowest weight first (negative to positive) 8. The library waits until the hook is "Ready" (except for CRDs) 9. The library loads the resulting resources into Kubernetes. Note that if the `--wait` flag is set, the library will wait until all resources are in a ready state and will not run the `post-install` hook until they are ready. 10. The library executes the `post-install` hook (loading hook resources) 11. The library waits until the hook is "Ready" 12. The library returns the release object (and other data) to the client 13. The client exits What does it mean to wait until a hook is ready? This depends on the resource declared in the hook. If the resource is a `Job` or `Pod` kind, Helm will wait until it successfully runs to completion. And if the hook fails, the release will fail. This is a _blocking operation_, so the Helm client will pause while the Job is run. For all other kinds, as soon as Kubernetes marks the resource as loaded (added or updated), the resource is considered "Ready". When many resources are declared in a hook, the resources are executed serially. If they have hook weights (see below), they are executed in weighted order. Starting from Helm 3.2.0 hook resources with same weight are installed in the same order as normal non-hook resources. Otherwise, ordering is not guaranteed. (In Helm 2.3.0 and after, they are sorted alphabetically. That behavior, though, is not considered binding and could change in the future.) It is considered good practice to add a hook weight, and set it to `0` if weight is not important. ### Hook resources are not managed with corresponding releases The resources that a hook creates are currently not tracked or managed as part of the release. Once Helm verifies that the hook has reached its ready state, it will leave the hook resource alone. Garbage collection of hook resources when the corresponding release is deleted may be added to Helm 3 in the future, so any hook resources that must never be deleted should be annotated with `helm.sh/resource-policy: keep`. Practically speaking, this means that if you create resources in a hook, you cannot rely upon `helm uninstall` to remove the resources. To destroy such resources, you need to either [add a custom `helm.sh/hook-delete-policy` annotation](#hook-deletion-policies) to the hook template file, or [set the time to live (TTL) field of a Job resource](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Writing a Hook Hooks are just Kubernetes manifest files with special annotations in the `metadata` section. Because they are template files, you can use all of the normal template features, including reading `.Values`, `.Release`, and `.Template`. For example, this template, stored in `templates/post-install-job.yaml`, declares a job to be run on `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` What makes this template a hook is the annotation: ```yaml annotations: "helm.sh/hook": post-install ``` One resource can implement multiple hooks: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Similarly, there is no limit to the number of different resources that may implement a given hook. For example, one could declare both a secret and a config map as a pre-install hook. When subcharts declare hooks, those are also evaluated. There is no way for a top-level chart to disable the hooks declared by subcharts. It is possible to define a weight for a hook which will help build a deterministic executing order. Weights are defined using the following annotation: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Hook weights can be positive or negative numbers but must be represented as strings. When Helm starts the execution cycle of hooks of a particular Kind it will sort those hooks in ascending order. ### Hook deletion policies It is possible to define policies that determine when to delete corresponding hook resources. Hook deletion policies are defined using the following annotation: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` You can choose one or more defined annotation values: | Annotation Value | Description | | ---------------------- | -------------------------------------------------------------------- | | `before-hook-creation` | Delete the previous resource before a new hook is launched (default) | | `hook-succeeded` | Delete the resource after the hook is successfully executed | | `hook-failed` | Delete the resource if the hook failed during execution | If no hook deletion policy annotation is specified, the `before-hook-creation` behavior applies by default. ================================================ FILE: docs/topics/index.mdx ================================================ --- title: Topics sidebar_position: 3 --- # Topic Guides Here you’ll find introductions to all the key parts of Helm you’ll need or want to know. import DocCardList from '@theme/DocCardList'; ================================================ FILE: docs/topics/kubernetes_apis.md ================================================ --- title: Deprecated Kubernetes APIs description: Explains deprecated Kubernetes APIs in Helm --- Kubernetes is an API-driven system and the API evolves over time to reflect the evolving understanding of the problem space. This is common practice across systems and their APIs. An important part of evolving APIs is a good deprecation policy and process to inform users of how changes to APIs are implemented. In other words, consumers of your API need to know in advance and in what release an API will be removed or changed. This removes the element of surprise and breaking changes to consumers. The [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documents how Kubernetes handles the changes to its API versions. The policy for deprecation states the timeframe that API versions will be supported following a deprecation announcement. It is therefore important to be aware of deprecation announcements and know when API versions will be removed, to help minimize the effect. This is an example of an announcement [for the removal of deprecated API versions in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) and was advertised a few months prior to the release. These API versions would have been announced for deprecation prior to this again. This shows that there is a good policy in place which informs consumers of API version support. Helm templates specify a [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) when defining a Kubernetes object, similar to a Kubernetes manifest file. It is specified in the `apiVersion` field of the template and it identifies the API version of the Kubernetes object. This means that Helm users and chart maintainers need to be aware when Kubernetes API versions have been deprecated and in what Kubernetes version they will be removed. ## Chart Maintainers You should audit your charts checking for Kubernetes API versions that are deprecated or are removed in a Kubernetes version. The API versions found as due to be or that are now out of support, should be updated to the supported version and a new version of the chart released. The API version is defined by the `kind` and `apiVersion` fields. For example, here is a removed `Deployment` object API version in Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm Users You should audit the charts that you use (similar to [chart maintainers](#chart-maintainers)) and identify any charts where API versions are deprecated or removed in a Kubernetes version. For the charts identified, you need to check for the latest version of the chart (which has supported API versions) or update the chart yourself. Additionally, you also need to audit any charts deployed (i.e. Helm releases) checking again for any deprecated or removed API versions. This can be done by getting details of a release using the `helm get manifest` command. The means for updating a Helm release to supported APIs depends on your findings as follows: 1. If you find deprecated API versions only then: - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version 2. If you find any API version(s) that is/are removed in a Kubernetes version then: - If you are running a Kubernetes version where the API version(s) are still available (for example, you are on Kubernetes 1.15 and found you use APIs that will be removed in Kubernetes 1.16): - Follow the step 1 procedure - Otherwise (for example, you are already running a Kubernetes version where some API versions reported by `helm get manifest` are no longer available): - You need to edit the release manifest that is stored in the cluster to update the API versions to supported APIs. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details > Note: In all cases of updating a Helm release with supported APIs, you should never rollback the release to a version prior to the release version with the supported APIs. > Recommendation: The best practice is to upgrade releases using deprecated API versions to supported API versions, prior to upgrading to a kubernetes cluster that removes those API versions. If you don't update a release as suggested previously, you will have an error similar to the following when trying to upgrade a release in a Kubernetes version where its API version(s) is/are removed: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm fails in this scenario because it attempts to create a diff patch between the current deployed release (which contains the Kubernetes APIs that are removed in this Kubernetes version) against the chart you are passing with the updated/supported API versions. The underlying reason for failure is that when Kubernetes removes an API version, the Kubernetes Go client library can no longer parse the deprecated objects and Helm therefore fails when calling the library. Helm unfortunately is unable to recover from this situation and is no longer able to manage such a release. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details on how to recover from this scenario. ## Updating API Versions of a Release Manifest The manifest is a property of the Helm release object which is stored in the data field of a Secret (default) or ConfigMap in the cluster. The data field contains a gzipped object which is base 64 encoded (there is an additional base 64 encoding for a Secret). There is a Secret/ConfigMap per release version/revision in the namespace of the release. You can use the Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) plugin to perform the update of a release to supported APIs. Check out the readme for more details. Alternatively, you can follow these manual steps to perform an update of the API versions of a release manifest. Depending on your configuration you will follow the steps for the Secret or ConfigMap backend. - Get the name of the Secret or Configmap associated with the latest deployed release: - Secrets backend: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap backend: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Get latest deployed release details: - Secrets backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap backend: `kubectl get configmap -n -o yaml > release.yaml` - Backup the release in case you need to restore if something goes wrong: - `cp release.yaml release.bak` - In case of emergency, restore: `kubectl apply -f release.bak -n ` - Decode the release object: - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Change API versions of the manifests. Can use any tool (e.g. editor) to make the changes. This is in the `manifest` field of your decoded release object (`release.data.decoded`) - Encode the release object: - Secrets backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap backend: `cat release.data.decoded | gzip | base64` - Replace `data.release` property value in the deployed release file (`release.yaml`) with the new encoded release object - Apply file to namespace: `kubectl apply -f release.yaml -n ` - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version ================================================ FILE: docs/topics/kubernetes_distros.md ================================================ --- title: Kubernetes Distribution Guide description: Captures information about using Helm in specific Kubernetes environments. sidebar_position: 10 --- Helm should work with any [conformant version of Kubernetes](https://github.com/cncf/k8s-conformance) (whether [certified](https://www.cncf.io/certification/software-conformance/) or not). This document captures information about using Helm in specific Kubernetes environments. Please contribute more details about any distros (sorted alphabetically) if desired. ## AKS Helm works with [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes platform, and requires no additional configuration. ## EKS Helm works with Amazon Elastic Kubernetes Service (Amazon EKS): [Using Helm with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Google's GKE hosted Kubernetes platform is known to work with Helm, and requires no additional configuration. ## `scripts/local-cluster` and Hyperkube Hyperkube configured via `scripts/local-cluster.sh` is known to work. For raw Hyperkube you may need to do some manual configuration. ## IKS Helm works with [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm is regularly tested on [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm works in clusters that are set up by KubeOne without caveats. ## Kubermatic Helm works in user clusters that are created by Kubermatic without caveats. Since seed cluster can be set up in different ways Helm support depends on their configuration. ## MicroK8s Helm can be enabled in [MicroK8s](https://microk8s.io) using the command: `microk8s.enable helm3` ## Minikube Helm is tested and known to work with [Minikube](https://github.com/kubernetes/minikube). It requires no additional configuration. ## Openshift Helm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To learn more read [this blog](https://blog.openshift.com/getting-started-helm-openshift/) post. ## Platform9 Helm is pre-installed with [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 provides access to all official Helm charts through the App Catalog UI and native Kubernetes CLI. Additional repositories can be manually added. Further details are available in this [Platform9 App Catalog article](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu with `kubeadm` Kubernetes bootstrapped with `kubeadm` is known to work on the following Linux distributions: - Ubuntu 16.04 - Fedora release 25 Some versions of Helm (v2.0.0-beta2) require you to `export KUBECONFIG=/etc/kubernetes/admin.conf` or create a `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm runs on VMware Tanzu Kubernetes Grid, TKG, without needing configuration changes. The Tanzu CLI can manage installing packages for [helm-controller](https://fluxcd.io/flux/components/helm/) allowing for declaratively managing Helm chart releases. Further details are available in the [Tanzu Kubernetes Grid documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-kubernetes-grid/2-5/tkg/index.html). ================================================ FILE: docs/topics/library_charts.md ================================================ --- title: Library Charts description: Explains library charts and examples of usage sidebar_position: 4 --- A library chart is a type of [Helm chart](/topics/charts.mdx) that defines chart primitives or definitions which can be shared by Helm templates in other charts. This allows users to share snippets of code that can be re-used across charts, avoiding repetition and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). The library chart was introduced in Helm 3 to formally recognize common or helper charts that have been used by chart maintainers since Helm 2. By including it as a chart type, it provides: - A means to explicitly distinguish between common and application charts - Logic to prevent installation of a common chart - No rendering of templates in a common chart which may contain release artifacts - Allow for dependent charts to use the importer's context A chart maintainer can define a common chart as a library chart and now be confident that Helm will handle the chart in a standard consistent fashion. It also means that definitions in an application chart can be shared by changing the chart type. ## Create a Simple Library Chart As mentioned previously, a library chart is a type of [Helm chart](/topics/charts.mdx). This means that you can start off by creating a scaffold chart: ```console $ helm create mylibchart Creating mylibchart ``` You will first remove all the files in `templates` directory as we will create our own templates definitions in this example. ```console $ rm -rf mylibchart/templates/* ``` The values file will not be required either. ```console $ rm -f mylibchart/values.yaml ``` Before we jump into creating common code, lets do a quick review of some relevant Helm concepts. A [named template](/chart_template_guide/named_templates.md) (sometimes called a partial or a subtemplate) is simply a template defined inside of a file, and given a name. In the `templates/` directory, any file that begins with an underscore(_) is not expected to output a Kubernetes manifest file. So by convention, helper templates and partials are placed in a `_*.tpl` or `_*.yaml` files. In this example, we will code a common ConfigMap which creates an empty ConfigMap resource. We will define the common ConfigMap in file `mylibchart/templates/_configmap.yaml` as follows: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` The ConfigMap construct is defined in named template `mylibchart.configmap.tpl`. It is a simple ConfigMap with an empty resource, `data`. Within this file there is another named template called `mylibchart.configmap`. This named template includes another named template `mylibchart.util.merge` which will take 2 named templates as arguments, the template calling `mylibchart.configmap` and `mylibchart.configmap.tpl`. The helper function `mylibchart.util.merge` is a named template in `mylibchart/templates/_util.yaml`. It is a handy util from [The Common Helm Helper Chart](#the-common-helm-helper-chart) because it merges the 2 templates and overrides any common parts in both: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` This is important when a chart wants to use common code that it needs to customize with its configuration. Finally, lets change the chart type to `library`. This requires editing `mylibchart/Chart.yaml` as follows: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` The library chart is now ready to be shared and its ConfigMap definition to be re-used. Before moving on, it is worth checking if Helm recognizes the chart as a library chart: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Use the Simple Library Chart It is time to use the library chart. This means creating a scaffold chart again: ```console $ helm create mychart Creating mychart ``` Lets clean out the template files again as we want to create a ConfigMap only: ```console $ rm -rf mychart/templates/* ``` When we want to create a simple ConfigMap in a Helm template, it could look similar to the following: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` We are however going to re-use the common code already created in `mylibchart`. The ConfigMap can be created in the file `mychart/templates/configmap.yaml` as follows: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` You can see that it simplifies the work we have to do by inheriting the common ConfigMap definition which adds standard properties for ConfigMap. In our template we add the configuration, in this case the data key `myvalue` and its value. The configuration override the empty resource of the common ConfigMap. This is feasible because of the helper function `mylibchart.util.merge` we mentioned in the previous section. To be able to use the common code, we need to add `mylibchart` as a dependency. Add the following to the end of the file `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` This includes the library chart as a dynamic dependency from the filesystem which is at the same parent path as our application chart. As we are including the library chart as a dynamic dependency, we need to run `helm dependency update`. It will copy the library chart into your `charts/` directory. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` We are now ready to deploy our chart. Before installing, it is worth checking the rendered template first. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` This looks like the ConfigMap we want with data override of `myvalue: Hello World`. Lets install it: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` We can retrieve the release and see that the actual template was loaded. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Library Chart Benefits Because of their inability to act as standalone charts, library charts can leverage the following functionality: - The `.Files` object references the file paths on the parent chart, rather than the path local to the library chart - The `.Values` object is the same as the parent chart, in contrast to application [subcharts](/chart_template_guide/subcharts_and_globals.md) which receive the section of values configured under their header in the parent. ## The Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` This [chart](https://github.com/helm/charts/tree/master/incubator/common) was the original pattern for common charts. It provides utilities that reflect best practices of Kubernetes chart development. Best of all it can be used off the bat by you when developing your charts to give you handy shared code. Here is a quick way to use it. For more details, have a look at the [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Create a scaffold chart again: ```console $ helm create demo Creating demo ``` Lets use the common code from the helper chart. First, edit deployment `demo/templates/deployment.yaml` as follows: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` And now the service file, `demo/templates/service.yaml` as follows: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` These templates show how inheriting the common code from the helper chart simplifies your coding down to your configuration or customization of the resources. To be able to use the common code, we need to add `common` as a dependency. Add the following to the end of the file `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Note: You will need to add the `incubator` repo to the Helm repository list (`helm repo add`). As we are including the chart as a dynamic dependency, we need to run `helm dependency update`. It will copy the helper chart into your `charts/` directory. As helper chart is using some Helm 2 constructs, you will need to add the following to `demo/values.yaml` to enable the `nginx` image to be loaded as this was updated in Helm 3 scaffold chart: ```yaml image: tag: 1.16.0 ``` You can test that the chart templates are correct prior to deploying using the `helm lint` and `helm template` commands. If it's good to go, deploy away using `helm install`! ================================================ FILE: docs/topics/permissions_sql_storage_backend.md ================================================ --- title: Permissions management for SQL storage backend description: Get to know how to setup permissions when using SQL storage backend. --- This document aims to provide guidance to users for setting up and managing permissions when using the SQL storage backend. ## Introduction To handle permissions, Helm leverages the RBAC feature of Kubernetes. When using the SQL storage backend, Kubernetes' roles can't be used to determine whether or not an user can access a given resource. This document shows how to create and manage these permissions. ## Initialization The first time the Helm CLI will make connect to your database, the client will make sure that it was previously initialized. If it is not, it will take care of the necessary setup automatically. This initialization requires admin privileges on the public schema, or at least to be able to: * create a table * grant privileges on the public schema After the migration was run against your database, all the other roles can use the client. ## Grant privileges to a non admin user in PostgreSQL To manage permissions, the SQL backend driver leverages the [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(Row Security Level) feature of PostgreSQL. RLS allows all users to be able to read/write from/to the same table, without being able to manipulate the same rows if they are not explicitly allowed to. By default, any role that has not been explicitly granted with the right privileges will always return an empty list when running `helm list` and will not be able to retrieve or modify any resource in the cluster. Let's see how to grant a given role access to specific namespaces: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` This command will grant the permissions to read and write all resources that meet the `namespace = 'default'` condition to the role `role`. After creating this policy, the user being connected to the database on the behalf of the role `role` will therefore be able to see all the releases living in the `default` namespace when running `helm list`, and to modify and delete them. Privileges can be managed granularly with RLS, and one might be interested in restraining access given the different columns of the table: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: docs/topics/plugins.mdx ================================================ --- title: The Helm Plugins Guide description: Introduces how to use and create plugins to extend Helm's functionality. sidebar_position: 12 --- import Helm4 from "/docs/_v4-in-progress.mdx" A Helm plugin is a tool that can be accessed through the `helm` CLI, but which is not part of the built-in Helm codebase. Existing plugins can be found on [related](/community/related#helm-plugins) section or by searching [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). This guide explains how to use and create plugins. ## An Overview Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool. Helm plugins have the following features: - They can be added and removed from a Helm installation without impacting the core Helm tool. - They can be written in any programming language. - They integrate with Helm, and will show up in `helm help` and other places. Helm plugins live in `$HELM_PLUGINS`. You can find the current value of this, including the default value when not set in the environment, using the `helm env` command. The Helm plugin model is partially based on Git's plugin model. To that end, you may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins being the _plumbing_. This is a shorthand way of suggesting that Helm provides the user experience and top level processing logic, while the plugins do the "detail work" of performing a desired action. ## Installing a Plugin Plugins are installed using the `$ helm plugin install ` command. You can pass in a path to a plugin on your local file system or a url of a remote VCS repo. The `helm plugin install` command clones or copies the plugin at the path/url given into `$HELM_PLUGINS`. If you are installing from a VCS you can specify the version with the `--version` argument. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` If you have a plugin tar distribution, simply untar the plugin into the `$HELM_PLUGINS` directory. You can also install tarball plugins directly from url by issuing `helm plugin install https://domain/path/to/plugin.tar.gz` ## The Plugin File Structure In many ways, a plugin is similar to a chart. Each plugin has a top-level directory containing a `plugin.yaml` file. Additional files may be present but only the `plugin.yaml` file is required. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## The plugin.yaml File The plugin.yaml file is required for a plugin. It contains the following fields: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### The `name` Field The `name` is the name of the plugin. When Helm executes this plugin, this is the name it will use (e.g. `helm NAME` will invoke this plugin). _`name` should match the directory name._ In our example above, that means the plugin with `name: last` should be contained in a directory named `last`. Restrictions on `name`: - `name` cannot duplicate one of the existing `helm` top-level commands. - `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`. ### The `version` Field The `version` is the SemVer 2 version of the plugin. `usage` and `description` are both used to generate the help text of a command. ### The `ignoreFlags` Field The `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a plugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then `--foo` is silently discarded. ### The `platformCommand` Field The `platformCommand` configures the command that the plugin will execute when it is called. You can't set both `platformCommand` & `command` as this will result in an error. The following rules will apply in deciding which command to use: - If `platformCommand` is present, it will be used. - If both `os` and `arch` match the current platform, search will stop and the command will be used. - If `os` matches and `arch` is empty, the command will be used. - If `os` and `arch` are both empty, the command will be used. - If there is no match, Helm will exit with an error. - If `platformCommand` is not present and the deprecated `command` is present it will be used. - If the command is empty, Helm will exit with an error. ### The `platformHooks` Field The `platformHooks` configures the commands that the plugin will execute for lifecycle events. You can't set both `platformHooks` & `hooks` as this will result in an error. The following rules will apply in deciding which hook command to use: - If `platformHooks` is present, it will be used and the commands for the lifecycle event will be processed. - If both `os` and `arch` match the current platform, search will stop and the command will be used. - If `os` matches and `arch` is empty, the command will be used. - If `os` and `arch` are both empty, the command will be used. - If there is no match, Helm will skip the event. - If `platformHooks` is not present and the deprecated `hooks` is present the command for the lifecycle event will be used. - If the command is empty, Helm will skip the event. ## Building a Plugin Here is the plugin YAML for a simple plugin that helps get the last release name: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Plugins may require additional scripts and executables. Scripts can be included in the plugin directory and executables can be downloaded via a hook. The following is an example plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Environment variables are interpolated before the plugin is executed. The pattern above illustrates the preferred way to indicate where the plugin program lives. ### Plugin Commands There are some strategies for working with plugin commands: - If a plugin includes an executable, the executable for a `platformCommand:` or should be packaged in the plugin directory or installed via a hook. - The `platformCommand:` or `command:` line will have any environment variables expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin directory. - The command itself is not executed in a shell. So you can't oneline a shell script. - Helm injects lots of configuration into environment variables. Take a look at the environment to see what information is available. - Helm makes no assumptions about the language of the plugin. You can write it in whatever you prefer. - Commands are responsible for implementing specific help text for `-h` and `--help`. Helm will use `usage` and `description` for `helm help` and `helm help myplugin`, but will not handle `helm myplugin --help`. ### Testing a Local Plugin First you need to find your `HELM_PLUGINS` path to do it run the following command: ``` bash helm env ``` Change your current directory to the director that `HELM_PLUGINS` is set to. Now you can add a symbolic link to your build output of your plugin in this example we did it for `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Downloader Plugins By default, Helm is able to pull Charts using HTTP/S. As of Helm 2.4.0, plugins can have a special capability to download Charts from arbitrary sources. Plugins shall declare this special capability in the `plugin.yaml` file (top level): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` If such plugin is installed, Helm can interact with the repository using the specified protocol scheme by invoking the `command`. The special repository shall be added similarly to the regular ones: `helm repo add favorite myprotocol://example.com/` The rules for the special repos are the same to the regular ones: Helm must be able to download the `index.yaml` file in order to discover and cache the list of available Charts. The defined command will be invoked with the following scheme: `command certFile keyFile caFile full-URL`. The SSL credentials are coming from the repo definition, stored in `$HELM_REPOSITORY_CONFIG` (i.e., `$HELM_CONFIG_HOME/repositories.yaml`). A Downloader plugin is expected to dump the raw content to stdout and report errors on stderr. The downloader command also supports sub-commands or arguments, allowing you to specify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This is useful if you want to use the same executable for the main plugin command and the downloader command, but with a different sub-command for each. ## Environment Variables When Helm executes a plugin, it passes the outer environment to the plugin, and also injects some additional environment variables. Variables like `KUBECONFIG` are set for the plugin if they are set in the outer environment. The following variables are guaranteed to be set: - `HELM_PLUGINS`: The path to the plugins directory. - `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm myplug` will have the short name `myplug`. - `HELM_PLUGIN_DIR`: The directory that contains the plugin. - `HELM_BIN`: The path to the `helm` command (as executed by the user). - `HELM_DEBUG`: Indicates if the debug flag was set by helm. - `HELM_REGISTRY_CONFIG`: The location for the registry configuration (if using). Note that the use of Helm with registries is an experimental feature. - `HELM_REPOSITORY_CACHE`: The path to the repository cache files. - `HELM_REPOSITORY_CONFIG`: The path to the repository configuration file. - `HELM_NAMESPACE`: The namespace given to the `helm` command (generally using the `-n` flag). - `HELM_KUBECONTEXT`: The name of the Kubernetes config context given to the `helm` command. Additionally, if a Kubernetes configuration file was explicitly specified, it will be set as the `KUBECONFIG` variable ## A Note on Flag Parsing When executing a plugin, Helm will parse global flags for its own use. None of these flags are passed on to the plugin. - `--burst-limit`: This is converted to `$HELM_BURST_LIMIT` - `--debug`: If this is specified, `$HELM_DEBUG` is set to `1` - `--kube-apiserver`: This is converted to `$HELM_KUBEAPISERVER` - `--kube-as-group`: These are converted to `$HELM_KUBEASGROUPS` - `--kube-as-user`: This is converted to `$HELM_KUBEASUSER` - `--kube-ca-file`: This is converted to `$HELM_KUBECAFILE` - `--kube-context`: This is converted to `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: This is converted to `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: This is converted to `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: This is converted to `$HELM_KUBETOKEN` - `--kubeconfig`: This is converted to `$KUBECONFIG` - `--namespace` and `-n`: This is converted to `$HELM_NAMESPACE` - `--qps`: This is converted to `$HELM_QPS` - `--registry-config`: This is converted to `$HELM_REGISTRY_CONFIG` - `--repository-cache`: This is converted to `$HELM_REPOSITORY_CACHE` - `--repository-config`: This is converted to `$HELM_REPOSITORY_CONFIG` Plugins _should_ display help text and then exit for `-h` and `--help`. In all other cases, plugins may use flags as appropriate. ## Providing shell auto-completion As of Helm 3.2, a plugin can optionally provide support for shell auto-completion as part of Helm's existing auto-completion mechanism. ### Static auto-completion If a plugin provides its own flags and/or sub-commands, it can inform Helm of them by having a `completion.yaml` file located in the plugin's root directory. The `completion.yaml` file has the form: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Notes: 1. All sections are optional but should be provided if applicable. 1. Flags should not include the `-` or `--` prefix. 1. Both short and long flags can and should be specified. A short flag need not be associated with its corresponding long form, but both forms should be listed. 1. Flags need not be ordered in any way, but need to be listed at the correct point in the sub-command hierarchy of the file. 1. Helm's existing global flags are already handled by Helm's auto-completion mechanism, therefore plugins need not specify the following flags `--debug`, `--namespace` or `-n`, `--kube-context`, and `--kubeconfig`, or any other global flag. 1. The `validArgs` list provides a static list of possible completions for the first parameter following a sub-command. It is not always possible to provide such a list in advance (see the [Dynamic Completion](#dynamic-completion) section below), in which case the `validArgs` section can be omitted. The `completion.yaml` file is entirely optional. If it is not provided, Helm will simply not provide shell auto-completion for the plugin (unless [Dynamic Completion](#dynamic-completion) is supported by the plugin). Also, adding a `completion.yaml` file is backwards-compatible and will not impact the behavior of the plugin when using older helm versions. As an example, for the [`fullstatus plugin`](https://github.com/marckhouzam/helm-fullstatus) which has no sub-commands but accepts the same flags as the `helm status` command, the `completion.yaml` file is: ```yaml name: fullstatus flags: - o - output - revision ``` ### Dynamic completion Also starting with Helm 3.2, plugins can provide their own dynamic shell auto-completion. Dynamic shell auto-completion is the completion of parameter values or flag values that cannot be defined in advance. For example, completion of the names of helm releases currently available on the cluster. For the plugin to support dynamic auto-completion, it must provide an **executable** file called `plugin.complete` in its root directory. When the Helm completion script requires dynamic completions for the plugin, it will execute the `plugin.complete` file, passing it the command-line that needs to be completed. The `plugin.complete` executable will need to have the logic to determine what the proper completion choices are and output them to standard output to be consumed by the Helm completion script. The `plugin.complete` file is entirely optional. If it is not provided, Helm will simply not provide dynamic auto-completion for the plugin. Also, adding a `plugin.complete` file is backwards-compatible and will not impact the behavior of the plugin when using older helm versions. The output of the `plugin.complete` script should be a new-line separated list such as: ```console rel1 rel2 rel3 ``` When `plugin.complete` is called, the plugin environment is set just like when the plugin's main script is called. Therefore, the variables `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT`, and all other plugin variables will already be set, and their corresponding global flags will be removed. The `plugin.complete` file can be in any executable form; it can be a shell script, a Go program, or any other type of program that Helm can execute. The `plugin.complete` file ***must*** have executable permissions for the user. The `plugin.complete` file ***must*** exit with a success code (value 0). In some cases, dynamic completion will require to obtain information from the Kubernetes cluster. For example, the `helm fullstatus` plugin requires a release name as input. In the `fullstatus` plugin, for its `plugin.complete` script to provide completion for current release names, it can simply run `helm list -q` and output the result. If it is desired to use the same executable for plugin execution and for plugin completion, the `plugin.complete` script can be made to call the main plugin executable with some special parameter or flag; when the main plugin executable detects the special parameter or flag, it will know to run the completion. In our example, `plugin.complete` could be implemented like this: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` The `fullstatus` plugin's real script (`status.sh`) must then look for the `--complete` flag and if found, printout the proper completions. ### Tips and tricks 1. The shell will automatically filter out completion choices that don't match user input. A plugin can therefore return all relevant completions without removing the ones that don't match the user input. For example, if the command-line is `helm fullstatus ngin`, the `plugin.complete` script can print *all* release names (of the `default` namespace), not just the ones starting with `ngin`; the shell will only retain the ones starting with `ngin`. 1. To simplify dynamic completion support, especially if you have a complex plugin, you can have your `plugin.complete` script call your main plugin script and request completion choices. See the [Dynamic Completion](#dynamic-completion) section above for an example. 1. To debug dynamic completion and the `plugin.complete` file, one can run the following to see the completion results : - `helm __complete `. For example: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: docs/topics/provenance.mdx ================================================ --- title: Helm Provenance and Integrity description: Describes how to verify the integrity and origin of a Chart. sidebar_position: 5 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm has provenance tools which help chart users verify the integrity and origin of a package. Using industry-standard tools based on PKI, GnuPG, and well-respected package managers, Helm can generate and verify signature files. ## Overview Integrity is established by comparing a chart to a provenance record. Provenance records are stored in _provenance files_, which are stored alongside a packaged chart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file will be `myapp-1.2.3.tgz.prov`. Provenance files are generated at packaging time (`helm package --sign ...`), and can be checked by multiple commands, notably `helm install --verify`. ## The Workflow This section describes a potential workflow for using provenance data effectively. Prerequisites: - A valid PGP keypair in a binary (not ASCII-armored) format - The `helm` command line tool - GnuPG command line tools (optional) - Keybase command line tools (optional) **NOTE:** If your PGP private key has a passphrase, you will be prompted to enter that passphrase for any commands that support the `--sign` option. Creating a new chart is the same as before: ```console $ helm create mychart Creating mychart ``` Once ready to package, add the `--sign` flag to `helm package`. Also, specify the name under which the signing key is known and the keyring containing the corresponding private key: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Note:** The value of the `--key` argument must be a substring of the desired key's `uid` (in the output of `gpg --list-keys`), for example the name or email. **The fingerprint _cannot_ be used.** **TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.gpg`. You can use `gpg --list-secret-keys` to list the keys you have. **Warning:** the GnuPG v2 store your secret keyring using a new format `kbx` on the default location `~/.gnupg/pubring.kbx`. Please use the following command to convert your keyring to the legacy gpg format: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` At this point, you should see both `mychart-0.1.0.tgz` and `mychart-0.1.0.tgz.prov`. Both files should eventually be uploaded to your desired chart repository. You can verify a chart using `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` A failed verification looks like this: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` To verify during an install, use the `--verify` flag. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` If the keyring containing the public key associated with the signed chart is not in the default location, you may need to point to the keyring with `--keyring PATH` as in the `helm package` example. If verification fails, the install will be aborted before the chart is even rendered. ### Using Keybase.io credentials The [Keybase.io](https://keybase.io) service makes it easy to establish a chain of trust for a cryptographic identity. Keybase credentials can be used to sign charts. Prerequisites: - A configured Keybase.io account - GnuPG installed locally - The `keybase` CLI installed locally #### Signing packages The first step is to import your keybase keys into your local GnuPG keyring: ```console $ keybase pgp export -s | gpg --import ``` This will convert your Keybase key into the OpenPGP format, and then import it locally into your `~/.gnupg/secring.gpg` file. You can double check by running `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Note that your secret key will have an identifier string: ``` technosophos (keybase.io/technosophos) ``` That is the full name of your key. Next, you can package and sign a chart with `helm package`. Make sure you use at least part of that name string in `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` As a result, the `package` command should produce both a `.tgz` file and a `.tgz.prov` file. #### Verifying packages You can also use a similar technique to verify a chart signed by someone else's Keybase key. Say you want to verify a package signed by `keybase.io/technosophos`. To do this, use the `keybase` tool: ```console $ keybase follow technosophos $ keybase pgp pull ``` The first command above tracks the user `technosophos`. Next `keybase pgp pull` downloads the OpenPGP keys of all of the accounts you follow, placing them in your GnuPG keyring (`~/.gnupg/pubring.gpg`). At this point, you can now use `helm verify` or any of the commands with a `--verify` flag: ```console $ helm verify somechart-1.2.3.tgz ``` ### Reasons a chart may not verify These are common reasons for failure. - The `.prov` file is missing or corrupt. This indicates that something is misconfigured or that the original maintainer did not create a provenance file. - The key used to sign the file is not in your keyring. This indicate that the entity who signed the chart is not someone you've already signaled that you trust. - The verification of the `.prov` file failed. This indicates that something is wrong with either the chart or the provenance data. - The file hashes in the provenance file do not match the hash of the archive file. This indicates that the archive has been tampered with. If a verification fails, there is reason to distrust the package. ## The Provenance File The provenance file contains a chart’s YAML file plus several pieces of verification information. Provenance files are designed to be automatically generated. The following pieces of provenance data are added: * The chart file (`Chart.yaml`) is included to give both humans and tools an easy view into the contents of the chart. * The signature (SHA256, just like Docker) of the chart package (the `.tgz` file) is included, and may be used to verify the integrity of the chart package. * The entire body is signed using the algorithm used by OpenPGP (see [Keybase.io](https://keybase.io) for an emerging way of making crypto signing and verification easy). The combination of this gives users the following assurances: * The package itself has not been tampered with (checksum package `.tgz`). * The entity who released this package is known (via the GnuPG/PGP signature). The format of the file looks something like this: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Note that the YAML section contains two documents (separated by `...\n`). The first file is the content of `Chart.yaml`. The second is the checksums, a map of filenames to SHA-256 digests of that file's content at packaging time. The signature block is a standard PGP signature, which provides [tamper resistance](https://www.rossde.com/PGP/pgp_signatures.html). ## Chart Repositories Chart repositories serve as a centralized collection of Helm charts. Chart repositories must make it possible to serve provenance files over HTTP via a specific request, and must make them available at the same URI path as the chart. For example, if the base URL for a package is `https://example.com/charts/mychart-1.2.3.tgz`, the provenance file, if it exists, MUST be accessible at `https://example.com/charts/mychart-1.2.3.tgz.prov`. From the end user's perspective, `helm install --verify myrepo/mychart-1.2.3` should result in the download of both the chart and the provenance file with no additional user configuration or action. ### Signatures in OCI-based registries When publishing charts to an [OCI-based registry](/topics/registries.mdx), the [`helm-sigstore` plugin](https://github.com/sigstore/helm-sigstore/) can be used to publish provenance to [sigstore](https://sigstore.dev/). [As described in the documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), the process of creating provenance and signing with a GPG key are common, but the `helm sigstore upload` command can be used to publish the provenance to an immutable transparency log. ## Establishing Authority and Authenticity When dealing with chain-of-trust systems, it is important to be able to establish the authority of a signer. Or, to put this plainly, the system above hinges on the fact that you trust the person who signed the chart. That, in turn, means you need to trust the public key of the signer. One of the design decisions with Helm has been that the Helm project would not insert itself into the chain of trust as a necessary party. We don't want to be "the certificate authority" for all chart signers. Instead, we strongly favor a decentralized model, which is part of the reason we chose OpenPGP as our foundational technology. So when it comes to establishing authority, we have left this step more-or-less undefined in Helm 2 (a decision carried forward in Helm 3). However, we have some pointers and recommendations for those interested in using the provenance system: - The [Keybase](https://keybase.io) platform provides a public centralized repository for trust information. - You can use Keybase to store your keys or to get the public keys of others. - Keybase also has fabulous documentation available - While we haven't tested it, Keybase's "secure website" feature could be used to serve Helm charts. - The basic idea is that an official "chart reviewer" signs charts with her or his key, and the resulting provenance file is then uploaded to the chart repository. - There has been some work on the idea that a list of valid signing keys may be included in the `index.yaml` file of a repository. ================================================ FILE: docs/topics/rbac.md ================================================ --- title: Role-based Access Control description: Explains how Helm interacts with Kubernetes' Role-Based Access Control. sidebar_position: 11 --- In Kubernetes, granting roles to a user or an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified. Read more about service account permissions [in the official Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). From Kubernetes 1.6 onwards, Role-based Access Control is enabled by default. RBAC allows you to specify which types of actions are permitted depending on the user and their role in your organization. With RBAC, you can - grant privileged operations (creating cluster-wide resources, like new roles) to administrators - limit a user's ability to create resources (pods, persistent volumes, deployments) to specific namespaces, or in cluster-wide scopes (resource quotas, roles, custom resource definitions) - limit a user's ability to view resources either in specific namespaces or at a cluster-wide scope. This guide is for administrators who want to restrict the scope of a user's interaction with the Kubernetes API. ## Managing user accounts All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. Normal users are assumed to be managed by an outside, independent service. An administrator distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords. In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call. In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as Secrets, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API. API requests are tied to either a normal user or a service account, or are treated as anonymous requests. This means every process inside or outside the cluster, from a human user typing `kubectl` on a workstation, to kubelets on nodes, to members of the control plane, must authenticate when making requests to the API server, or be treated as an anonymous user. ## Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings In Kubernetes, user accounts and service accounts can only view and edit resources they have been granted access to. This access is granted through the use of Roles and RoleBindings. Roles and RoleBindings are bound to a particular namespace, which grant users the ability to view and/or edit resources within that namespace the Role provides them access to. At a cluster scope, these are called ClusterRoles and ClusterRoleBindings. Granting a user a ClusterRole grants them access to view and/or edit resources across the entire cluster. It is also required to view and/or edit resources at the cluster scope (namespaces, resource quotas, nodes). ClusterRoles can be bound to a particular namespace through reference in a RoleBinding. The `admin`, `edit` and `view` default ClusterRoles are commonly used in this manner. These are a few ClusterRoles available by default in Kubernetes. They are intended to be user-facing roles. They include super-user roles (`cluster-admin`), and roles with more granular access (`admin`, `edit`, `view`). | Default ClusterRole | Default ClusterRoleBinding | Description |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` group | Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself. | `admin` | None | Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and rolebindings within the namespace. It does not allow write access to resource quota or to the namespace itself. | `edit` | None | Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings. | `view` | None | Allows read-only access to see most objects in a namespace. It does not allow viewing roles or rolebindings. It does not allow viewing secrets, since those are escalating. ## Restricting a user account's access using RBAC Now that we understand the basics of Role-based Access Control, let's discuss how an administrator can restrict a user's scope of access. ### Example: Grant a user read/write access to a particular namespace To restrict a user's access to a particular namespace, we can use either the `edit` or the `admin` role. If your charts create or interact with Roles and Rolebindings, you'll want to use the `admin` ClusterRole. Additionally, you may also create a RoleBinding with `cluster-admin` access. Granting a user `cluster-admin` access at the namespace scope provides full control over every resource in the namespace, including the namespace itself. For this example, we will create a user with the `edit` Role. First, create the namespace: ```console $ kubectl create namespace foo ``` Now, create a RoleBinding in that namespace, granting the user the `edit` role. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Example: Grant a user read/write access at the cluster scope If a user wishes to install a chart that installs cluster-scope resources (namespaces, roles, custom resource definitions, etc.), they will require cluster-scope write access. To do that, grant the user either `admin` or `cluster-admin` access. Granting a user `cluster-admin` access grants them access to absolutely every resource available in Kubernetes, including node access with `kubectl drain` and other administrative tasks. It is highly recommended to consider providing the user `admin` access instead, or to create a custom ClusterRole tailored to their needs. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Example: Grant a user read-only access to a particular namespace You might've noticed that there is no ClusterRole available for viewing secrets. The `view` ClusterRole does not grant a user read access to Secrets due to escalation concerns. Helm stores release metadata as Secrets by default. In order for a user to run `helm list`, they need to be able to read these secrets. For that, we will create a special `secret-reader` ClusterRole. Create the file `cluster-role-secret-reader.yaml` and write the following content into the file: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Then, create the ClusterRole using ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Once that's done, we can grant a user read access to most resources, and then grant them read access to secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Example: Grant a user read-only access at the cluster scope In certain scenarios, it may be beneficial to grant a user cluster-scope access. For example, if a user wants to run the command `helm list --all-namespaces`, the API requires the user has cluster-scope read access. To do that, grant the user both `view` and `secret-reader` access as described above, but with a ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Additional Thoughts The examples shown above utilize the default ClusterRoles provided with Kubernetes. For more fine-grained control over what resources users are granted access to, have a look at [the Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) on creating your own custom Roles and ClusterRoles. ================================================ FILE: docs/topics/registries.mdx ================================================ --- title: Use OCI-based registries description: Describes how to use OCI for Chart distribution. sidebar_position: 7 --- import Helm4 from "/docs/_v4-in-progress.mdx" It is recommended to use container registries with [OCI](https://www.opencontainers.org/) support to store and share chart packages. ## Using an OCI-based registry ### Helm repositories in OCI-based registries A [Helm repository](/topics/chart_repository.md) is a way to house and distribute packaged Helm charts. An OCI-based registry can contain zero or more Helm repositories and each of those repositories can contain zero or more packaged Helm charts. ### Use hosted registries There are several hosted container registries with OCI support that you can use for your Helm charts. For example: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Follow the hosted container registry provider's documentation to create and configure a registry with OCI support. **Note:** You can run [Docker Registry](https://docs.docker.com/registry/deploying/) or [`zot`](https://github.com/project-zot/zot), which are OCI-based registries, on your development computer. Running an OCI-based registry on your development computer should only be used for testing purposes. ### Using sigstore to sign OCI-based charts The [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) plugin allows using [Sigstore](https://sigstore.dev/) to sign Helm charts with the same tools used to sign container images. This provides an alternative to the [GPG-based provenance](/topics/provenance.mdx) supported by classic [chart repositories](/topics/chart_repository.md). For more details on using the `helm sigstore` plugin, see [that project's documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Commands for working with registries ### The `registry` subcommand #### `login` login to a registry (with manual password entry) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` The host must be only the registry hostname, optionally with a port. Do not include a URL scheme or path: | Example | Valid | |---------|-------| | `ghcr.io` | Yes | | `localhost:5000` | Yes | | `https://ghcr.io` | No - scheme not allowed | | `ghcr.io/myrepo` | No - path not allowed | #### `logout` logout from a registry ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### The `push` subcommand Upload a chart to an OCI-based registry: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` The `push` subcommand can only be used against `.tgz` files created ahead of time using `helm package`. When using `helm push` to upload a chart an OCI registry, the reference must be prefixed with `oci://` and must not contain the basename or tag. The registry reference basename is inferred from the chart's name, and the tag is inferred from the chart's semantic version. This is currently a strict requirement. Certain registries require the repository and/or namespace (if specified) to be created beforehand. Otherwise, an error will be produced during the `helm push` operation. If you have created a [provenance file](/topics/provenance.mdx) (`.prov`), and it is present next to the chart `.tgz` file, it will automatically be uploaded to the registry upon `push`. This results in an extra layer on [the Helm chart manifest](#helm-chart-manifest). Users of the [helm-push plugin](https://github.com/chartmuseum/helm-push) (for uploading charts to [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) may experience issues, since the plugin conflicts with the new, built-in `push`. As of version v0.10.0, the plugin has been renamed to `cm-push`. ### Other subcommands Support for the `oci://` protocol is also available in various other subcommands. Here is a complete list: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` The basename (chart name) of the registry reference *is* included for any type of action involving chart download (vs. `helm push` where it is omitted). Here are a few examples of using the subcommands listed above against OCI-based charts: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Installing charts with digest Installing a chart with a digest is more secure than a tag because digests are immutable. The digest is specified in the chart URI: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Specifying dependencies Dependencies of a chart can be pulled from a registry using the `dependency update` subcommand. The `repository` for a given entry in `Chart.yaml` is specified as the registry reference without the basename: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` This will fetch `oci://localhost:5000/myrepo/mychart:2.7.0` when `dependency update` is executed. ## Helm chart manifest Example Helm chart manifest as represented in a registry (note the `mediaType` fields): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` The following example contains a [provenance file](/topics/provenance.mdx) (note the extra layer): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migrating from chart repos Migrating from classic [chart repositories](/topics/chart_repository.md) (index.yaml-based repos) is as simple using `helm pull`, then using `helm push` to upload the resulting `.tgz` files to a registry. ================================================ FILE: docs/topics/version_skew.mdx ================================================ --- title: "Helm Version Support Policy" description: "Describes Helm's patch release policy as well as the maximum version skew supported between Helm and Kubernetes." --- This document describes the maximum version skew supported between Helm 4 and Kubernetes. ## Supported Versions Helm versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, following [Semantic Versioning](https://semver.org/spec/v2.0.0.html) terminology. The Helm project maintains a release branch for the most recent minor release. Applicable fixes, including security fixes, are cherry-picked into the release branch, depending on severity and feasibility. More details can be found in [Helm's release policy](/community/release_policy). ## Supported Version Skew When a new version of Helm is released, it is compiled against a particular minor version of Kubernetes. For example, Helm v4.0.0 interacts with Kubernetes using the Kubernetes 1.34.1 client, so it is compatible with Kubernetes 1.34. As of Helm 4, Helm is assumed to be compatible with `n-3` versions of Kubernetes it was compiled against. For example, if you are using a version of Helm 4 that was compiled against the Kubernetes v1.35 client APIs, then it should be safe to use with Kubernetes v1.35, v1.34, v1.33, and v1.32. It is not recommended to use Helm with a version of Kubernetes that is newer than the version it was compiled against, as Helm does not make any forward compatibility guarantees. If you choose to use Helm with a version of Kubernetes that it does not support, you are using it at your own risk. Please refer to the table below to determine what version of Helm is compatible with your cluster. | Helm Version | Supported Kubernetes Versions | |--------------|-------------------------------| | 4.1.x | 1.35.x - 1.32.x | | 4.0.x | 1.34.x - 1.31.x | ================================================ FILE: docusaurus.config.js ================================================ // @ts-check // `@type` JSDoc annotations allow editor autocompletion and type checking // (when paired with `@ts-check`). // There are various equivalent ways to declare your Docusaurus config. // See: https://docusaurus.io/docs/api/docusaurus-config import { themes as prismThemes } from "prism-react-renderer"; // This runs in Node.js - Don't use client-side code here (browser APIs, JSX...) const siteURL = process.env.SITE_URL || "http://localhost:3000"; const rawBaseUrl = process.env.BASE_URL; const normalizedBaseUrl = rawBaseUrl === undefined ? "/" : rawBaseUrl.endsWith("/") ? rawBaseUrl : rawBaseUrl + "/"; // Community documentation configuration const communityConfig = require("./remote-content_community"); const { processConfig, createEditUrlFunction, } = require("./src/utils/communityDocsHelpers"); const { transformImportedContent, } = require("./src/utils/communityDocsTransforms"); // Process the community docs configuration const { documents: remoteDocPaths, metaByPath, slugByPath, linkExceptions, } = processConfig(communityConfig); /** @type {import('@docusaurus/types').Config} */ const config = { title: "Helm", tagline: "The package manager for Kubernetes", favicon: "img/favicon.ico", // Future flags, see https://docusaurus.io/docs/api/docusaurus-config#future future: { v4: true, // Improve compatibility with the upcoming Docusaurus v4 }, // Opt-in to less strict, standard CommonMark support with options // Automatically detects .md and .mdx extensions // See https://docusaurus.io/docs/markdown-features/react#markdown-and-jsx-interoperability // See https://github.com/prettier/prettier/issues/17089 markdown: { format: "detect", }, // Set the production url of your site here url: siteURL, // Set the // pathname under which your site is served // For GitHub pages deployment, it is often '//' baseUrl: normalizedBaseUrl, // GitHub pages deployment config. // If you aren't using GitHub pages, you don't need these. organizationName: "helm", // Usually your GitHub org/user name. projectName: "helm-www", // Usually your repo name. onBrokenLinks: "throw", i18n: { defaultLocale: "en", locales: ["en", "de", "el", "es", "fr", "it", "ja", "ko", "pt", "ru", "uk", "zh"], localeConfigs: { en: { htmlLang: "en-us", label: "English", }, de: { label: "Deutsch (German)", }, es: { label: "Español (Spanish)", }, fr: { label: "Français (French)", }, it: { label: "Italiano (Italian)", }, el: { label: "Ελληνικά (Greek)", }, ja: { label: "日本語 (Japanese)", }, ko: { label: "한국어 (Korean)", }, pt: { label: "Português (Portuguese)", }, ru: { label: "Русский (Russian)", }, uk: { label: "Українська (Ukrainian)", }, zh: { label: "中文 (Chinese)", }, }, }, presets: [ [ "classic", /** @type {import('@docusaurus/preset-classic').Options} */ ({ docs: { sidebarPath: "./sidebars.js", // Please change this to your repo. // Remove this to remove the "edit this page" links. editUrl: "https://github.com/helm/helm-www/blob/main/", // Links "edit this page" on translated pages to i18n/[LOCALE]/... instead of English source file editLocalizedFiles: true, // "lastVersion" means the latest release lastVersion: "current", versions: { // v4 is "current" // v3 is in /versioned_docs/version-3 // v2 is in /versioned_docs/version-2 // TODO when we start work on Helm v5, we will copy /docs to /versioned_docs/version-4 // and v5 will then live in /docs // Be sure to update each locale's docusaurus-plugin-content-docs/current.json to match the current label // To-do: add this snippet to automation for bumping the version for each new release: // `for f in i18n/*/docusaurus-plugin-content-docs/current.json; do jq '."version.label".message = "4.0.0"' "$f" > "$f.tmp" && mv "$f.tmp" "$f"; done` current: { label: "4.1.1" }, 3: { label: "3.20.0", path: "v3" }, 2: { label: "2.17.0", path: "v2" }, }, }, blog: { showReadingTime: true, blogSidebarTitle: "All posts", blogSidebarCount: "ALL", feedOptions: { type: ["rss", "atom"], xslt: true, }, // Please change this to your repo. // Remove this to remove the "edit this page" links. editUrl: "https://github.com/helm/helm-www/blob/main/", // Useful options to enforce blogging best practices onInlineTags: "warn", onInlineAuthors: "warn", onUntruncatedBlogPosts: "throw", }, theme: { customCss: "./src/css/custom.css", }, }), ], ], // Note @docusaurus/preset-classic already includes a docs plugin instance for us under "presets" // See https://docusaurus.io/docs/docs-multi-instance#versioned-and-unversioned-doc plugins: [ [ "@docusaurus/plugin-content-docs", { id: "community", path: "community", routeBasePath: "community", sidebarPath: "./sidebars_community.js", editLocalizedFiles: true, editUrl: createEditUrlFunction(communityConfig.sourceRepo), numberPrefixParser: false, }, ], [ "docusaurus-plugin-remote-content", { name: "community", sourceBaseUrl: communityConfig.sourceBaseUrl, outDir: "community", documents: remoteDocPaths, // Set to true since we commit files to Git and performCleanup: false prevents deletion noRuntimeDownloads: true, // Must be false to prevent files being deleted between i18n locale builds // See: https://github.com/rdilweb/docusaurus-plugin-remote-content/issues/98 performCleanup: false, /** * @param {string} filename - The filename being processed * @param {string} content - The file content * @returns {{content: string, filename?: string}} Transformed content */ modifyContent(filename, content) { const transformed = transformImportedContent( filename, content, metaByPath, slugByPath, linkExceptions ); // transformImportedContent now returns an object with content and optionally filename return transformed; }, }, ], [ "docusaurus-plugin-remote-content", { name: "community-images", sourceBaseUrl: communityConfig.sourceBaseUrl, outDir: "community", documents: [ "art/images/Backgrounds-Pattern-Dark.png", "art/images/Backgrounds-Pattern.png", "art/images/Example-Icon-Illustrations.png", "art/images/Helm-3-Color-Palettes-Dark.png", "art/images/Helm-3-Color-Palettes-Light.png", "art/images/Helm-Summit.png", "art/images/Logo-Tweak-Dark.png", "art/images/Logo-Tweak-Light.png", "art/images/Typography.png", "art/images/Website-Exmple.png", "art/images/Website-Sample.png", "art/images/helm-3.png", "art/images/type-notes.png", ], requestConfig: { responseType: "arraybuffer" }, noRuntimeDownloads: true, performCleanup: false, }, ], ], themeConfig: /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ ({ algolia: { appId: "AYED2EXU9K", apiKey: "ab452074863b15ae08d14d22d393f1e0", indexName: "production", }, announcementBar: { backgroundColor: "#0f1689", textColor: "#ffffff", // Note that closed state is stored in browser // Change id to show again for users who have already closed it id: "helm4_ga", content: '🎉 Helm v4.0.0 is out! See the Helm 4 Overview for details!', isCloseable: true, }, // Replace with your project's social card image: "img/helm-social-card.png", colorMode: { defaultMode: "light", disableSwitch: true, }, docs: { sidebar: { hideable: true, autoCollapseCategories: true, }, }, navbar: { title: "Helm", logo: { alt: "Helm Logo", src: "img/helm.svg", }, items: [ { to: "docs", label: "Docs", position: "left" }, { to: "community", label: "Community", position: "left" }, { to: "blog", label: "Blog", position: "left" }, { href: "https://artifacthub.io/", label: "Charts", position: "left", }, { type: "docsVersionDropdown", position: "right", }, { type: "localeDropdown", position: "right", }, ], }, footer: { style: "dark", links: [ { title: "Helm Project", items: [ { label: "Source code", href: "https://github.com/helm/helm", }, { label: "Blog", to: "blog", }, { label: "Events", href: "https://www.cncf.io/community/kubecon-cloudnativecon-events/", }, { label: "Code of Conduct", href: "https://github.com/cncf/foundation/blob/master/code-of-conduct.md", }, ], }, { title: "Charts", items: [ { label: "Introduction", to: "docs/intro", }, { label: "Chart tips & tricks", to: "docs/howto/charts_tips_and_tricks", }, { label: "Developing Charts", to: "docs/topics/charts", }, { label: "Search 800+ Charts", href: "https://artifacthub.io/", }, ], }, { title: "Development", items: [ { label: "Slack (#helm-dev)", href: "https://kubernetes.slack.com/messages/C51E88VDG", }, { label: "Contribution Guide", href: "https://github.com/helm/helm/blob/main/CONTRIBUTING.md", }, { label: "Maintainers", href: "https://github.com/helm/helm/blob/main/OWNERS", }, { label: "Weekly Meetings", href: "https://github.com/helm/community/blob/main/communication.md#meetings", }, ], }, { title: "Community", items: [ { label: "GitHub Community", href: "https://github.com/helm/community", }, { label: "Slack (#helm-users)", href: "https://kubernetes.slack.com/", }, { label: "Stack Overflow", href: "https://stackoverflow.com/questions/tagged/kubernetes-helm", }, { label: "X", href: "https://x.com/helmpack", }, ], }, ], logo: { alt: "CNCF Logo", src: "/img/cncf-white.png", }, copyright: `

We are a Cloud Native Computing Foundation graduated project.

© Helm Authors ${new Date().getFullYear()}. Documentation distributed under CC-BY-4.0.

© ${new Date().getFullYear()} The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

`, }, prism: { theme: prismThemes.github, darkTheme: prismThemes.dracula, additionalLanguages: ["bash"], }, }), clientModules: [ require.resolve("./src/client-modules/heroHeightCalculator.js"), ], }; export default config; ================================================ FILE: i18n/de/code.json ================================================ { "home.about.whatIsHelm": { "message": "Helm hilft Ihnen, Kubernetes-Anwendungen zu verwalten — Helm Charts helfen Ihnen, selbst die komplexesten Kubernetes-Anwendungen zu definieren, zu installieren und zu aktualisieren.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Charts sind einfach zu erstellen, zu versionieren, zu teilen und zu publizieren — also fangen Sie an, Helm zu verwenden und hören Sie auf zu kopieren und einzufügen.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm ist ein promoviertes Projekt in der {cncfLink} und wird von der {helmCommunityLink} gepflegt.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "Helm Gemeinschaft", "description": "Helm community link" }, "home.about.learnMore": { "message": "Mehr lernen:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Helm-Architektur", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Schnellstartanleitung", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Video: Eine Einführung in Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Was ist Helm?", "description": "What is Helm? title" }, "home.community.nextFeatureRelease": { "message": "Nächste Version", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Version:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Datum:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Veröffentlichungskalender", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Kommende Veranstaltungen", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Kommende Veranstaltungen", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Vergangene Veranstaltungen", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "{meetLink}, um Tools und Projekte zu demonstrieren und zu diskutieren. Community-Treffen werden aufgezeichnet und {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "Sie treffen sich jede Woche", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "auf YouTube geteilt", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Entwickler-Standups" }, "home.community.developerStandups.time": { "message": "Donnerstags 9:30-10 Uhr (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Diese Treffen sind für alle offen. Schauen Sie im {communityRepoLink} für Notizen und Details nach.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "Community-Repository", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Diskussion über die Verwendung von Helm, die Arbeit mit Charts und das Lösen häufiger Fehler.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Themen zur Helm-Entwicklung, laufende PRs, Releases usw.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Diskussion für Benutzer und Mitwirkende von Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink}, um dem Kubernetes Slack-Team beizutreten.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Hier Zugang anfordern", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Beitragen", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm begrüßt immer neue Beiträge zum Projekt!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "Wo anfangen?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm ist ein großes Projekt mit vielen Benutzern und Mitwirkenden. Es kann viel zu verarbeiten sein!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Wir haben eine Liste von {goodFirstIssuesLink}, wenn Sie helfen möchten, aber nicht wissen, wo Sie anfangen sollen.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "guten ersten Issues", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Was soll ich tun?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Bevor Sie Code beisteuern, lesen Sie bitte unseren {contributionGuideLink}. Er behandelt die Prozesse rund um das Erstellen und Überprüfen von Pull Requests.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Beitragsleitfaden", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Nachdem Sie Code geschrieben haben, {signYourCommitsLink} bitte, um sicherzustellen, dass Helm die von der {cncfLink} verwendete {dcoLink}-Vereinbarung einhält.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "signieren Sie Ihre Commits", "description": "Sign your commits link" }, "home.community.title": { "message": "Der Gemeinschaft beitreten", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Weitere Informationen über das Helm-Projekt und wie Sie beitragen können.", "description": "Join the Community subtitle" }, "home.gettingStarted.title": { "message": "Erste Schritte", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Helm bekommen", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Installieren Sie Helm mit einem Paketmanager oder {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "laden Sie eine Binärdatei herunter", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Nach der Installation entpacken Sie die Helm-Binärdatei und fügen Sie sie zu Ihrem PATH hinzu und schon kann es losgehen! Schauen Sie in die {docsLink} für weitere {installationLink} und {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "Dokumentation", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "Installationsanweisungen", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "Nutzungsanweisungen", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Charts beziehen", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Besuchen Sie {artifactHubLink}, um {helmChartsLink} aus zahlreichen öffentlichen Repositories zu erkunden.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm Charts", "description": "Helm charts link" }, "home.header.tagline": { "message": "Der Paket Manager für Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm ist der beste Weg, um Software zu finden, zu teilen und zu verwenden, die für", "description": "Home page header subtitle" }, "home.features.manageComplexity": { "message": "Komplexität verwalten", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Charts beschreiben selbst die komplexesten Apps, ermöglichen wiederholbare Anwendungsinstallationen und dienen als zentrale Autorität.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Einfache Aktualisierungen", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Nehmen Sie den Schmerz aus Updates mit direkten Upgrades und benutzerdefinierten Hooks.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Einfaches Teilen", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Charts sind einfach zu versionieren, zu teilen und auf öffentlichen oder privaten Servern zu hosten.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Zurückrollen", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Verwenden Sie {helmRollback}, um einfach zu einer älteren Version eines Release zurückzukehren.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Funktionen", "description": "Features section title" }, "theme.ErrorPageContent.title": { "message": "Die Seite ist abgestürzt.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Zurück nach oben scrollen", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Archiv", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Archiv", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Navigation der Blog-Listenseite", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Neuere Einträge", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Ältere Einträge", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Blog Post Seiten Navigation", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Neuer Post", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Älterer Post", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Alle Tags anzeigen", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "Systemmodus", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "heller Modus", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "dunkler Modus", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Umschalten zwischen dunkler und heller Ansicht (momentan {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Breadcrumbs", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 Eintrag|{count} Einträge", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Dokumentation Seiten", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Zurück", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Weiter", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Ein doc getaggt|{count} docs getaggt", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} mit \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Das ist die unveröffentlichte Dokumentation für {siteTitle} {versionLabel}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Das ist die Dokumentation für {siteTitle} {versionLabel} und wird nicht weiter gewartet.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Für die aktuellste Dokumentation bitte auf {latestVersionLink} ({versionLabel}) gehen.", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "letzte Version", "description": "The label used for the latest version suggestion link label" }, "theme.docs.versionBadge.label": { "message": "Version: {versionLabel}" }, "theme.common.editThisPage": { "message": "Diese Seite bearbeiten", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "Direkter Link zur {heading}", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " am {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " von {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Letztes Update{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versionen", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.NotFound.title": { "message": "Seite nicht gefunden", "description": "The title of the 404 page" }, "theme.tags.tagsListLabel": { "message": "Tags:", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Schließen", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "vorsicht", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "gefahr", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "info", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "hinweis", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "tipp", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "warnung", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.blog.sidebar.navAriaLabel": { "message": "Navigation der letzten Beiträge im Blog", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Seitenleisten-Kategorie '{label}' erweitern", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Seitenleisten-Kategorie '{label}' einklappen", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(öffnet in neuem Tab)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Haupt", "description": "The ARIA label for the main navigation" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Sprachen", "description": "The label for the mobile language switcher dropdown" }, "theme.NotFound.p1": { "message": "Wir konnten nicht finden, wonach Sie gesucht haben.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Bitte kontaktieren Sie den Besitzer der Seite, die Sie mit der ursprünglichen URL verlinkt hat, und teilen Sie ihm mit, dass der Link nicht mehr funktioniert.", "description": "The 2nd paragraph of the 404 page" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Auf dieser Seite", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "Mehr lesen", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Mehr lesen über {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "Eine Minute Lesezeit|{readingTime} Minuten Lesezeit", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "Kopieren", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Kopiert", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "In die Zwischenablage kopieren", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "Zeilenumbruch umschalten", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "Startseite", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Seitenleiste einklappen", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Seitenleiste einklappen", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.navAriaLabel": { "message": "Dokumentationsseitenleiste", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Navigationsleiste schließen", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Zurück zum Hauptmenü", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Navigationsleiste umschalten", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Dropdown erweitern", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Dropdown einklappen", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Seitenleiste ausklappen", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Seitenleiste ausklappen", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "Ein Post|{count} Posts", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} getaggt mit \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Autoren", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Alle Autoren anzeigen", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Dieser Autor hat noch keine Beiträge geschrieben.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Nicht gelistete Seite", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Diese Seite ist nicht gelistet. Suchmaschinen werden sie nicht indexieren, und nur Benutzer mit einem direkten Link können darauf zugreifen.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Entwurfsseite", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Diese Seite ist ein Entwurf. Sie ist nur in der Entwicklung sichtbar und wird vom Produktions-Build ausgeschlossen.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Nochmal versuchen", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Zum Hauptinhalt springen", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Tags", "description": "The title of the tag list page" } } ================================================ FILE: i18n/de/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Blog", "description": "The title for the blog used in SEO" }, "description": { "message": "Blog", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Alle Beiträge", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Helm verwenden", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm-Befehle", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Templates entwickeln", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Bewährte Praktiken", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Allgemeine Konventionen description: Allgemeine Konventionen für Charts. sidebar_position: 1 --- Dieser Teil des Best-Practices-Leitfadens erklärt allgemeine Konventionen. ## Chart-Namen Chart-Namen müssen aus Kleinbuchstaben und Zahlen bestehen. Wörter _können_ durch Bindestriche (-) getrennt werden: Beispiele: ``` drupal nginx-lego aws-cluster-autoscaler ``` Weder Großbuchstaben noch Unterstriche können in Chart-Namen verwendet werden. Punkte sollten in Chart-Namen nicht verwendet werden. ## Versionsnummern Wo immer möglich, verwendet Helm [SemVer 2](https://semver.org), um Versionsnummern darzustellen. (Beachten Sie, dass Docker-Image-Tags nicht unbedingt SemVer folgen und daher als unglückliche Ausnahme von dieser Regel gelten.) Wenn SemVer-Versionen in Kubernetes-Labels gespeichert werden, ersetzen wir üblicherweise das `+`-Zeichen durch ein `_`-Zeichen, da Labels das `+`-Zeichen als Wert nicht zulassen. ## YAML-Formatierung YAML-Dateien sollten mit _zwei Leerzeichen_ eingerückt werden (und niemals mit Tabs). ## Verwendung der Wörter Helm und Chart Es gibt einige Konventionen für die Verwendung der Wörter _Helm_ und _helm_. - _Helm_ bezieht sich auf das Projekt als Ganzes - `helm` bezieht sich auf den clientseitigen Befehl - Der Begriff `chart` muss nicht großgeschrieben werden, da es sich nicht um einen Eigennamen handelt - Allerdings muss `Chart.yaml` großgeschrieben werden, da der Dateiname Groß- und Kleinschreibung unterscheidet Im Zweifelsfall verwenden Sie _Helm_ (mit einem großen 'H'). ## Chart-Templates und Namespaces Vermeiden Sie es, die Eigenschaft `namespace` im Abschnitt `metadata` Ihrer Chart-Templates zu definieren. Der Namespace, auf den gerenderte Templates angewendet werden sollen, sollte beim Aufruf eines Kubernetes-Clients über ein Flag wie `--namespace` angegeben werden. Helm rendert Ihre Templates unverändert und sendet sie an den Kubernetes-Client, sei es Helm selbst oder ein anderes Programm (kubectl, Flux, Spinnaker, etc.). ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Erstellen und Verwenden von CRDs. sidebar_position: 7 --- Dieser Teil des Best-Practices-Leitfadens behandelt die Erstellung und Verwendung von Custom-Resource-Definition-Objekten. Bei der Arbeit mit Custom Resource Definitions (CRDs) ist es wichtig, zwei Dinge zu unterscheiden: - Es gibt eine Deklaration einer CRD. Dies ist die YAML-Datei mit `kind: CustomResourceDefinition` - Dann gibt es Ressourcen, die die CRD _verwenden_. Angenommen, eine CRD definiert `foo.example.com/v1`. Jede Ressource mit `apiVersion: example.com/v1` und `kind: Foo` ist eine Ressource, die die CRD verwendet. ## CRD-Deklaration vor Ressourcenverwendung installieren Helm ist darauf optimiert, so viele Ressourcen wie möglich so schnell wie möglich in Kubernetes zu laden. Kubernetes kann standardmäßig einen gesamten Satz von Manifesten entgegennehmen und alle gleichzeitig online bringen (dies wird als Abgleichsschleife bzw. Reconciliation Loop bezeichnet). Bei CRDs gibt es jedoch einen Unterschied. Bei einer CRD muss die Deklaration registriert werden, bevor Ressourcen dieser CRD-Art(en) verwendet werden können. Der Registrierungsprozess dauert manchmal einige Sekunden. ### Methode 1: Helm die Arbeit überlassen Mit der Einführung von Helm 3 haben wir die alten `crd-install`-Hooks für eine einfachere Methode entfernt. Es gibt jetzt ein spezielles Verzeichnis namens `crds`, das Sie in Ihrem Chart erstellen können, um Ihre CRDs zu speichern. Diese CRDs werden nicht als Templates verarbeitet, aber standardmäßig installiert, wenn Sie `helm install` für das Chart ausführen. Wenn die CRD bereits existiert, wird sie mit einer Warnung übersprungen. Wenn Sie den CRD-Installationsschritt überspringen möchten, können Sie das Flag `--skip-crds` verwenden. #### Einige Vorbehalte (und Erklärungen) Derzeit gibt es keine Unterstützung für das Aktualisieren oder Löschen von CRDs mit Helm. Dies war eine bewusste Entscheidung nach ausführlicher Community-Diskussion aufgrund der Gefahr eines unbeabsichtigten Datenverlusts. Außerdem gibt es derzeit keinen Community-Konsens darüber, wie CRDs und ihr Lebenszyklus gehandhabt werden sollen. Sobald sich dies weiterentwickelt, wird Helm Unterstützung für diese Anwendungsfälle hinzufügen. Das `--dry-run`-Flag von `helm install` und `helm upgrade` wird derzeit für CRDs nicht unterstützt. Der Zweck von „Dry Run" ist zu validieren, dass die Ausgabe des Charts tatsächlich funktioniert, wenn sie an den Server gesendet wird. Aber CRDs ändern das Serververhalten. Helm kann die CRD bei einem Dry Run nicht installieren, daher kennt der Discovery-Client diese Custom Resource (CR) nicht, und die Validierung schlägt fehl. Sie können alternativ die CRDs in ein eigenes Chart verschieben oder stattdessen `helm template` verwenden. Ein weiterer wichtiger Punkt in der Diskussion um CRD-Unterstützung ist, wie das Rendern von Templates gehandhabt wird. Einer der deutlichen Nachteile der `crd-install`-Methode in Helm 2 war die Unfähigkeit, Charts aufgrund sich ändernder API-Verfügbarkeit ordnungsgemäß zu validieren (eine CRD fügt Ihrem Kubernetes-Cluster tatsächlich eine weitere verfügbare API hinzu). Wenn ein Chart eine CRD installierte, hatte `helm` keinen gültigen Satz von API-Versionen mehr, gegen den es arbeiten konnte. Dies ist auch der Grund für die Entfernung der Template-Unterstützung von CRDs. Mit der neuen `crds`-Methode der CRD-Installation stellen wir nun sicher, dass `helm` vollständig gültige Informationen über den aktuellen Zustand des Clusters hat. ### Methode 2: Separate Charts Eine andere Möglichkeit ist, die CRD-Definition in ein Chart zu packen und dann alle Ressourcen, die diese CRD verwenden, in ein _anderes_ Chart zu packen. Bei dieser Methode muss jedes Chart separat installiert werden. Dieser Workflow kann jedoch für Cluster-Operatoren nützlicher sein, die Administratorzugriff auf einen Cluster haben. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Abhängigkeiten description: Behandelt Best Practices für Chart-Abhängigkeiten. sidebar_position: 4 --- Dieser Teil des Best-Practices-Leitfadens behandelt die in `Chart.yaml` deklarierten `dependencies`. ## Versionen Verwenden Sie nach Möglichkeit Versionsbereiche anstelle einer exakten Version. Der empfohlene Standard ist ein Patch-Level-Versionsabgleich: ```yaml version: ~1.2.3 ``` Dies entspricht Version `1.2.3` und allen Patches zu diesem Release. Mit anderen Worten: `~1.2.3` ist äquivalent zu `>= 1.2.3, < 1.3.0` Die vollständige Syntax für den Versionsabgleich finden Sie in der [semver-Dokumentation](https://github.com/Masterminds/semver#checking-version-constraints). ### Prerelease-Versionen Die oben genannten Versionsbeschränkungen gelten nicht für Prerelease-Versionen. Zum Beispiel stimmt `version: ~1.2.3` mit `version: ~1.2.4` überein, aber nicht mit `version: ~1.2.3-1`. Folgendes ermöglicht sowohl Prerelease- als auch Patch-Level-Abgleich: ```yaml version: ~1.2.3-0 ``` ### Repository-URLs Verwenden Sie nach Möglichkeit `https://`-Repository-URLs, gefolgt von `http://`-URLs. Wenn das Repository zur Repository-Indexdatei hinzugefügt wurde, kann der Repository-Name als Alias für die URL verwendet werden. Verwenden Sie `alias:` oder `@` gefolgt vom Repository-Namen. Datei-URLs (`file://...`) gelten als „Sonderfall" für Charts, die durch eine feste Deployment-Pipeline zusammengestellt werden. Bei der Verwendung von [Downloader-Plugins](../topics/plugins.md#downloader-plugins) ist das URL-Schema spezifisch für das Plugin. Beachten Sie, dass ein Benutzer des Charts ein Plugin installiert haben muss, das das Schema unterstützt, um die Abhängigkeit zu aktualisieren oder zu erstellen. Helm kann keine Abhängigkeitsverwaltungsoperationen für die Abhängigkeit durchführen, wenn das `repository`-Feld leer gelassen wird. In diesem Fall geht Helm davon aus, dass sich die Abhängigkeit in einem Unterverzeichnis des `charts`-Ordners befindet, wobei der Name mit der `name`-Eigenschaft der Abhängigkeit übereinstimmt. ## Conditions und Tags Conditions oder Tags sollten zu allen Abhängigkeiten hinzugefügt werden, die _optional_ sind. Beachten Sie, dass eine `condition` standardmäßig den Wert `true` hat. Die bevorzugte Form einer Condition ist: ```yaml condition: somechart.enabled ``` Wobei `somechart` der Chart-Name der Abhängigkeit ist. Wenn mehrere Subcharts (Abhängigkeiten) zusammen eine optionale oder austauschbare Funktion bereitstellen, sollten diese Charts dieselben Tags teilen. Wenn zum Beispiel sowohl `nginx` als auch `memcached` zusammen Leistungsoptimierungen für die Hauptanwendung im Chart bieten und beide vorhanden sein müssen, wenn diese Funktion aktiviert ist, dann sollten beide einen Tags-Abschnitt wie diesen haben: ```yaml tags: - webaccelerator ``` Dies ermöglicht es einem Benutzer, diese Funktion mit einem Tag ein- und auszuschalten. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Labels und Annotationen description: Behandelt Best Practices für die Verwendung von Labels und Annotationen in Ihrem Chart. sidebar_position: 5 --- Dieser Teil des Best-Practices-Leitfadens behandelt Best Practices für die Verwendung von Labels und Annotationen in Ihrem Chart. ## Ist es ein Label oder eine Annotation? Ein Metadateneintrag sollte unter folgenden Bedingungen ein Label sein: - Es wird von Kubernetes verwendet, um diese Ressource zu identifizieren - Es ist nützlich für Administratoren, um das System abzufragen. Zum Beispiel empfehlen wir, `helm.sh/chart: NAME-VERSION` als Label zu verwenden, damit Administratoren bequem alle Instanzen eines bestimmten Charts finden können. Wenn ein Metadateneintrag nicht für Abfragen verwendet wird, sollte er stattdessen als Annotation gesetzt werden. Helm Hooks sind immer Annotationen. ## Standard-Labels Die folgende Tabelle definiert gängige Labels, die Helm Charts verwenden. Helm selbst erfordert niemals, dass ein bestimmtes Label vorhanden ist. Labels, die mit REC gekennzeichnet sind, werden empfohlen und _sollten_ auf einem Chart für globale Konsistenz gesetzt werden. Die mit OPT gekennzeichneten sind optional. Diese sind üblich oder häufig verwendet, werden aber nicht oft für den Betrieb benötigt. | Name | Status | Beschreibung | |------|--------|--------------| | `app.kubernetes.io/name` | REC | Der App-Name, der die gesamte App widerspiegelt. Üblicherweise wird `{{ template "name" . }}` dafür verwendet. Wird von vielen Kubernetes-Manifesten verwendet und ist nicht Helm-spezifisch. | | `helm.sh/chart` | REC | Der Chart-Name und die Version: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | | `app.kubernetes.io/managed-by` | REC | Sollte immer auf `{{ .Release.Service }}` gesetzt werden. Dient dazu, alle von Helm verwalteten Ressourcen zu finden. | | `app.kubernetes.io/instance` | REC | Sollte `{{ .Release.Name }}` sein. Hilft bei der Unterscheidung zwischen verschiedenen Instanzen derselben Anwendung. | | `app.kubernetes.io/version` | OPT | Die Version der App, kann auf `{{ .Chart.AppVersion }}` gesetzt werden. | | `app.kubernetes.io/component` | OPT | Ein gängiges Label zur Kennzeichnung der verschiedenen Rollen, die Komponenten in einer Anwendung spielen können. Zum Beispiel `app.kubernetes.io/component: frontend`. | | `app.kubernetes.io/part-of` | OPT | Für den Fall, dass mehrere Charts oder Software-Komponenten zusammen eine Anwendung bilden. Zum Beispiel Anwendungssoftware und eine Datenbank für eine Website. Kann auf die übergeordnete Anwendung gesetzt werden. | Weitere Informationen zu den Kubernetes-Labels mit dem Präfix `app.kubernetes.io` finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods und PodTemplates description: Behandelt die Formatierung von Pod- und PodTemplate-Bereichen in Chart-Manifesten. sidebar_position: 6 --- Dieser Teil des Best-Practices-Leitfadens behandelt die Formatierung von Pod- und PodTemplate-Bereichen in Chart-Manifesten. Die folgende (nicht vollständige) Liste von Ressourcen verwendet PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images Ein Container-Image sollte einen festen Tag oder den SHA des Images verwenden. Es sollte nicht die Tags `latest`, `head`, `canary` oder andere „Floating Tags" verwenden, die auf wechselnde Versionen verweisen. Images _können_ in der `values.yaml`-Datei definiert werden, um Images einfach auszutauschen. ```yaml image: {{ .Values.redisImage | quote }} ``` Ein Image und ein Tag _können_ in `values.yaml` als zwei separate Felder definiert werden: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` setzt die `imagePullPolicy` standardmäßig auf `IfNotPresent` durch folgenden Eintrag in Ihrer `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` Und in `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Ebenso setzt Kubernetes die `imagePullPolicy` standardmäßig auf `IfNotPresent`, wenn sie überhaupt nicht definiert ist. Wenn Sie einen anderen Wert als `IfNotPresent` wünschen, aktualisieren Sie einfach den Wert in `values.yaml` auf den gewünschten Wert. ## PodTemplates sollten Selektoren deklarieren Alle PodTemplate-Bereiche sollten einen Selektor angeben. Zum Beispiel: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Dies ist eine gute Praxis, da sie die Beziehung zwischen Set und Pod deutlich macht. Bei Sets wie Deployment ist dies besonders wichtig. Ohne Selektor werden _alle_ Labels verwendet, um passende Pods zu finden. Das führt zu Problemen, wenn Sie Labels verwenden, die sich ändern, wie Version oder Release-Datum. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Rollenbasierte Zugriffskontrolle description: Behandelt die Erstellung und Formatierung von RBAC-Ressourcen in Chart-Manifesten. sidebar_position: 8 --- Dieser Teil des Best-Practices-Leitfadens behandelt die Erstellung und Formatierung von RBAC-Ressourcen in Chart-Manifesten. RBAC-Ressourcen sind: - ServiceAccount (Namespace-gebunden) - Role (Namespace-gebunden) - ClusterRole - RoleBinding (Namespace-gebunden) - ClusterRoleBinding ## YAML-Konfiguration RBAC- und ServiceAccount-Konfiguration sollte unter separaten Schlüsseln erfolgen. Es handelt sich um unterschiedliche Konzepte. Die Trennung in der YAML-Datei verdeutlicht den Unterschied und macht die Konfiguration klarer. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` Diese Struktur kann für komplexere Charts erweitert werden, die mehrere ServiceAccounts benötigen. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC-Ressourcen sollten standardmäßig erstellt werden `rbac.create` sollte ein boolescher Wert sein, der steuert, ob RBAC-Ressourcen erstellt werden. Der Standardwert sollte `true` sein. Benutzer, die ihre RBAC-Zugriffskontrollen selbst verwalten möchten, können diesen Wert auf `false` setzen (siehe hierzu den Abschnitt unten). ## Verwendung von RBAC-Ressourcen `serviceAccount.name` sollte auf den Namen des ServiceAccounts gesetzt werden, der von den zugriffskontrollierten Ressourcen des Charts verwendet wird. - Wenn `serviceAccount.create` auf `true` gesetzt ist, wird ein ServiceAccount mit diesem Namen erstellt. Wenn kein Name angegeben ist, wird ein Name anhand des `fullname`-Templates generiert. - Wenn `serviceAccount.create` auf `false` gesetzt ist, wird der ServiceAccount nicht erstellt. Er sollte jedoch denselben Ressourcen zugeordnet werden, damit manuell erstellte RBAC-Ressourcen, die später darauf verweisen, korrekt funktionieren. - Wenn `serviceAccount.create` auf `false` gesetzt ist und kein Name angegeben wurde, wird der Standard-ServiceAccount verwendet. Verwenden Sie das folgende Helper-Template für den ServiceAccount: ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Templates description: Ein genauerer Blick auf Best Practices rund um Templates. sidebar_position: 3 --- Dieser Teil des Best-Practices-Leitfadens konzentriert sich auf Templates. ## Struktur von `templates/` Das `templates/`-Verzeichnis sollte wie folgt strukturiert sein: - Template-Dateien sollten die Erweiterung `.yaml` haben, wenn sie YAML-Ausgabe erzeugen. Die Erweiterung `.tpl` kann für Template-Dateien verwendet werden, die keinen formatierten Inhalt erzeugen. - Template-Dateinamen sollten die Bindestrich-Schreibweise verwenden (`my-example-configmap.yaml`), nicht camelCase. - Jede Ressourcendefinition sollte in einer eigenen Template-Datei sein. - Template-Dateinamen sollten die Ressourcen-Art im Namen widerspiegeln, z.B. `foo-pod.yaml`, `bar-svc.yaml` ## Namen von definierten Templates Definierte Templates (Templates, die innerhalb einer `{{ define }}`-Direktive erstellt werden) sind global zugänglich. Das bedeutet, dass ein Chart und alle seine Subcharts Zugriff auf alle mit `{{ define }}` erstellten Templates haben. Aus diesem Grund sollten _alle Namen definierter Templates einen Namespace haben._ Richtig: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Falsch: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Es wird dringend empfohlen, neue Charts mit dem Befehl `helm create` zu erstellen, da die Template-Namen automatisch gemäß dieser Best Practice definiert werden. ## Formatierung von Templates Templates sollten mit _zwei Leerzeichen_ eingerückt werden (niemals Tabs). Template-Direktiven sollten Leerzeichen nach den öffnenden geschweiften Klammern und vor den schließenden geschweiften Klammern haben: Richtig: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Falsch: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Templates sollten Whitespace nach Möglichkeit trimmen: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Blöcke (wie Kontrollstrukturen) können eingerückt werden, um den Fluss des Template-Codes anzuzeigen. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Da YAML jedoch eine Whitespace-orientierte Sprache ist, ist es oft nicht möglich, dass die Code-Einrückung dieser Konvention folgt. ## Whitespace in generierten Templates Die Menge an Whitespace in generierten Templates sollte minimal gehalten werden. Insbesondere sollten nicht mehrere leere Zeilen nebeneinander erscheinen. Gelegentliche leere Zeilen (besonders zwischen logischen Abschnitten) sind jedoch in Ordnung. Das ist am besten: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Das ist akzeptabel: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Aber das sollte vermieden werden: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Kommentare (YAML-Kommentare vs. Template-Kommentare) Sowohl YAML als auch Helm Templates haben Kommentarzeichen. YAML-Kommentare: ```yaml # This is a comment type: sprocket ``` Template-Kommentare: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` Template-Kommentare sollten verwendet werden, wenn Funktionen eines Templates dokumentiert werden, zum Beispiel um ein definiertes Template zu erklären: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Innerhalb von Templates können YAML-Kommentare verwendet werden, wenn es für Helm-Benutzer nützlich ist, die Kommentare (möglicherweise) beim Debugging zu sehen. ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` Der obige Kommentar ist sichtbar, wenn der Benutzer `helm install --debug` ausführt, während Kommentare in `{{- /* */}}`-Abschnitten nicht angezeigt werden. Seien Sie vorsichtig beim Hinzufügen von `#` YAML-Kommentaren in Template-Abschnitten, die Helm-Werte enthalten, die von bestimmten Template-Funktionen benötigt werden könnten. Wenn zum Beispiel die Funktion `required` im obigen Beispiel verwendet wird und `maxMem` nicht gesetzt ist, führt ein `#` YAML-Kommentar zu einem Rendering-Fehler. Richtig: `helm template` rendert diesen Block nicht ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Falsch: `helm template` gibt zurück `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Lesen Sie [Templates debuggen](../chart_template_guide/debugging.md) für ein weiteres Beispiel dieses Verhaltens, wie YAML-Kommentare intakt bleiben. ## Verwendung von JSON in Templates und Template-Ausgabe YAML ist eine Obermenge von JSON. In manchen Fällen kann die Verwendung einer JSON-Syntax lesbarer sein als andere YAML-Darstellungen. Zum Beispiel ist dieses YAML näher an der normalen YAML-Methode, Listen auszudrücken: ```yaml arguments: - "--dirname" - "/foo" ``` Aber es ist einfacher zu lesen, wenn es im JSON-Listen-Stil zusammengefasst wird: ```yaml arguments: ["--dirname", "/foo"] ``` Die Verwendung von JSON für bessere Lesbarkeit ist gut. JSON-Syntax sollte jedoch nicht verwendet werden, um komplexere Strukturen darzustellen. Bei reinem JSON, das in YAML eingebettet ist (wie bei der Init-Container-Konfiguration), ist es natürlich angemessen, das JSON-Format zu verwenden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Beschreibt, wie Sie Ihre Values strukturieren und verwenden sollten. sidebar_position: 2 --- Dieser Teil des Best-Practices-Leitfadens behandelt die Verwendung von Values. Hier geben wir Empfehlungen, wie Sie Ihre Values strukturieren und verwenden sollten, mit Fokus auf die Gestaltung der `values.yaml`-Datei eines Charts. ## Namenskonventionen Variablennamen sollten mit einem Kleinbuchstaben beginnen, und Wörter sollten in camelCase getrennt werden: Richtig: ```yaml chicken: true chickenNoodleSoup: true ``` Falsch: ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` Alle integrierten Helm-Variablen beginnen mit einem Großbuchstaben, um sie leicht von benutzerdefinierten Values zu unterscheiden: `.Release.Name`, `.Capabilities.KubeVersion`. ## Flache oder verschachtelte Values YAML ist ein flexibles Format, und Values können tief verschachtelt oder flach strukturiert sein. Verschachtelt: ```yaml server: name: nginx port: 80 ``` Flach: ```yaml serverName: nginx serverPort: 80 ``` In den meisten Fällen ist eine flache Struktur vorzuziehen. Der Grund: Sie ist für Template-Entwickler und Benutzer einfacher. Für optimale Sicherheit muss ein verschachtelter Wert auf jeder Ebene überprüft werden: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Für jede Verschachtelungsebene muss eine Existenzprüfung durchgeführt werden. Bei einer flachen Konfiguration können solche Prüfungen entfallen, was das Template lesbarer und einfacher zu verwenden macht. ``` {{ default "none" .Values.serverName }} ``` Wenn es eine große Anzahl verwandter Variablen gibt und mindestens eine davon erforderlich ist, können verschachtelte Values zur Verbesserung der Lesbarkeit verwendet werden. ## Typen explizit angeben Die Typumwandlungsregeln von YAML sind manchmal nicht intuitiv. Zum Beispiel ist `foo: false` nicht dasselbe wie `foo: "false"`. Große Ganzzahlen wie `foo: 12345678` werden in manchen Fällen in wissenschaftliche Notation umgewandelt. Der einfachste Weg, Typkonvertierungsfehler zu vermeiden, ist, Strings explizit zu kennzeichnen und bei allem anderen implizit zu bleiben. Kurz gesagt: _Alle Strings in Anführungszeichen setzen_. Oft ist es vorteilhaft, Ganzzahlen ebenfalls als Strings zu speichern und im Template `{{ int $value }}` zu verwenden, um sie wieder in eine Ganzzahl umzuwandeln. In den meisten Fällen werden explizite Typ-Tags korrekt interpretiert, sodass `foo: !!string 1234` den Wert `1234` als String behandelt. _Allerdings_ verarbeitet der YAML-Parser Tags intern, sodass die Typinformation nach einem Parse-Vorgang verloren geht. ## Bedenken Sie die Nutzung durch Anwender Es gibt drei potenzielle Quellen für Values: - Die `values.yaml`-Datei eines Charts - Eine Values-Datei, die mit `helm install -f` oder `helm upgrade -f` übergeben wird - Die Werte, die über die Flags `--set` oder `--set-string` bei `helm install` oder `helm upgrade` übergeben werden Bedenken Sie beim Entwurf der Struktur Ihrer Values, dass Benutzer diese möglicherweise über das `-f`-Flag oder mit der `--set`-Option überschreiben möchten. Da `--set` weniger flexibel ist, lautet die erste Richtlinie für das Schreiben Ihrer `values.yaml`-Datei: _Machen Sie das Überschreiben über `--set` einfach_. Aus diesem Grund ist es oft besser, Ihre Values-Datei mit Maps zu strukturieren. Schwierig mit `--set` zu verwenden: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Das Obige lässt sich mit `--set` in Helm `<=2.4` nicht ausdrücken. In Helm 2.5 erfolgt der Zugriff auf den Port von foo mit `--set servers[0].port=80`. Das ist nicht nur schwieriger für den Benutzer herauszufinden, sondern auch fehleranfällig, falls die Reihenfolge der `servers` zu einem späteren Zeitpunkt geändert wird. Einfach zu verwenden: ```yaml servers: foo: port: 80 bar: port: 81 ``` Der Zugriff auf den Port von foo ist viel offensichtlicher: `--set servers.foo.port=80`. ## Dokumentieren Sie `values.yaml` Jede definierte Eigenschaft in `values.yaml` sollte dokumentiert werden. Der Dokumentationsstring sollte mit dem Namen der beschriebenen Eigenschaft beginnen und dann mindestens eine Satzbeschreibung enthalten. Falsch: ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` Richtig: ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` Jeden Kommentar mit dem Namen des Parameters zu beginnen, erleichtert das Durchsuchen der Dokumentation und ermöglicht es Dokumentationswerkzeugen, Dokumentationsstrings zuverlässig mit den beschriebenen Parametern zu verknüpfen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Zugriff auf Dateien innerhalb von Templates description: Wie Sie auf Dateien innerhalb eines Templates zugreifen können. sidebar_position: 10 --- Im vorherigen Abschnitt haben wir mehrere Möglichkeiten kennengelernt, benannte Templates zu erstellen und darauf zuzugreifen. Dies erleichtert das Importieren eines Templates aus einem anderen Template. Manchmal ist es jedoch wünschenswert, eine _Datei zu importieren, die kein Template ist_ und deren Inhalt einzufügen, ohne ihn durch die Template-Rendering-Engine zu senden. Helm bietet Zugriff auf Dateien über das `.Files`-Objekt. Bevor wir mit den Template-Beispielen beginnen, gibt es einige wichtige Hinweise zur Funktionsweise: - Sie können zusätzliche Dateien zu Ihrem Helm Chart hinzufügen. Diese Dateien werden mitgebündelt. Seien Sie jedoch vorsichtig: Charts müssen aufgrund der Speicherbeschränkungen von Kubernetes-Objekten kleiner als 1 MB sein. - Einige Dateien können aus Sicherheitsgründen nicht über das `.Files`-Objekt aufgerufen werden: - Dateien in `templates/` sind nicht zugänglich. - Dateien, die über `.helmignore` ausgeschlossen werden, sind nicht zugänglich. - Dateien außerhalb eines Helm-Anwendungs-[Subcharts](./subcharts_and_globals.md), einschließlich derjenigen des übergeordneten Charts, sind nicht zugänglich. - Charts behalten keine UNIX-Modus-Informationen bei, sodass Datei-Berechtigungen keinen Einfluss auf die Verfügbarkeit einer Datei über das `.Files`-Objekt haben. - [Einfaches Beispiel](#einfaches-beispiel) - [Pfad-Hilfsfunktionen](#pfad-hilfsfunktionen) - [Glob-Muster](#glob-muster) - [ConfigMap- und Secrets-Hilfsfunktionen](#configmap--und-secrets-hilfsfunktionen) - [Kodierung](#kodierung) - [Zeilen](#zeilen) ## Einfaches Beispiel Mit diesen Hinweisen im Hinterkopf schreiben wir nun ein Template, das drei Dateien in unsere ConfigMap einliest. Zunächst fügen wir drei Dateien zum Chart hinzu und platzieren sie direkt im Verzeichnis `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Jede dieser Dateien ist eine einfache TOML-Datei (ähnlich den klassischen Windows-INI-Dateien). Da wir die Namen dieser Dateien kennen, können wir eine `range`-Funktion verwenden, um sie zu durchlaufen und ihren Inhalt in unsere ConfigMap einzufügen. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Diese ConfigMap verwendet mehrere Techniken, die in den vorherigen Abschnitten besprochen wurden. Zum Beispiel erstellen wir eine Variable `$files`, um eine Referenz auf das `.Files`-Objekt zu speichern. Wir verwenden auch die `tuple`-Funktion, um eine Liste von Dateien zu erstellen, die wir durchlaufen. Dann geben wir jeden Dateinamen aus (`{{ . }}: |-`), gefolgt vom Inhalt der Datei `{{ $files.Get . }}`. Das Ausführen dieses Templates erzeugt eine einzelne ConfigMap mit dem Inhalt aller drei Dateien: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Pfad-Hilfsfunktionen Bei der Arbeit mit Dateien kann es sehr nützlich sein, einige Standardoperationen auf den Dateipfaden selbst auszuführen. Um dabei zu helfen, importiert Helm viele Funktionen aus dem Go-Paket [path](https://golang.org/pkg/path/) für Ihre Nutzung. Sie sind alle mit denselben Namen wie im Go-Paket zugänglich, jedoch mit einem Kleinbuchstaben am Anfang. Zum Beispiel wird `Base` zu `base`, usw. Die importierten Funktionen sind: - Base - Dir - Ext - IsAbs - Clean ## Glob-Muster Wenn Ihr Chart wächst, werden Sie möglicherweise feststellen, dass Sie Ihre Dateien besser organisieren müssen. Deshalb bieten wir eine Methode `Files.Glob(pattern string)` an, die beim Extrahieren bestimmter Dateien mit der vollen Flexibilität von [Glob-Mustern](https://godoc.org/github.com/gobwas/glob) hilft. `.Glob` gibt einen `Files`-Typ zurück, sodass Sie alle `Files`-Methoden auf dem zurückgegebenen Objekt aufrufen können. Stellen Sie sich zum Beispiel folgende Verzeichnisstruktur vor: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Sie haben mehrere Optionen mit Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Oder ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap- und Secrets-Hilfsfunktionen (Verfügbar ab Helm 2.0.2 und später) Es ist sehr üblich, Dateiinhalte sowohl in ConfigMaps als auch in Secrets zu platzieren, um sie zur Laufzeit in Ihre Pods einzubinden. Um dabei zu helfen, bieten wir einige Hilfsmethoden auf dem `Files`-Typ an. Für eine bessere Organisation ist es besonders nützlich, diese Methoden in Verbindung mit der `Glob`-Methode zu verwenden. Mit der Verzeichnisstruktur aus dem [Glob](#glob-muster)-Beispiel oben: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Kodierung Sie können eine Datei importieren und das Template sie base64-kodieren lassen, um eine erfolgreiche Übertragung sicherzustellen: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Das obige Beispiel nimmt dieselbe `config1.toml`-Datei, die wir zuvor verwendet haben, und kodiert sie: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Zeilen Manchmal ist es wünschenswert, auf jede Zeile einer Datei in Ihrem Template zuzugreifen. Wir bieten dafür eine praktische `Lines`-Methode. Sie können `Lines` mit einer `range`-Funktion durchlaufen: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Es gibt keine Möglichkeit, Dateien von außerhalb des Charts während `helm install` zu übergeben. Wenn Sie möchten, dass Benutzer Daten bereitstellen, müssen diese über `helm install -f` oder `helm install --set` geladen werden. Damit schließen wir unseren Einblick in die Werkzeuge und Techniken zum Schreiben von Helm-Templates ab. Im nächsten Abschnitt werden wir sehen, wie Sie eine spezielle Datei, `templates/NOTES.txt`, verwenden können, um den Benutzern Ihres Charts Anweisungen nach der Installation zu senden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Integrierte Objekte description: Integrierte Objekte, die in Templates verfügbar sind. sidebar_position: 3 --- Objekte werden von der Template-Engine an ein Template übergeben. Ihr Code kann Objekte weitergeben (wir werden Beispiele sehen, wenn wir uns die `with`- und `range`-Anweisungen ansehen). Es gibt sogar einige Möglichkeiten, neue Objekte innerhalb Ihrer Templates zu erstellen, wie z.B. mit der `tuple`-Funktion, die wir später sehen werden. Objekte können einfach sein und nur einen Wert haben. Oder sie können andere Objekte oder Funktionen enthalten. Zum Beispiel enthält das `Release`-Objekt mehrere Objekte (wie `Release.Name`) und das `Files`-Objekt verfügt über einige Funktionen. Im vorherigen Abschnitt haben wir `{{ .Release.Name }}` verwendet, um den Namen eines Release in ein Template einzufügen. `Release` ist eines der Top-Level- Objekte, auf die Sie in Ihren Templates zugreifen können. - `Release`: Dieses Objekt beschreibt das Release selbst. Es enthält mehrere Objekte: - `Release.Name`: Der Release-Name - `Release.Namespace`: Der Namespace, in den bereitgestellt wird (sofern das Manifest dies nicht überschreibt) - `Release.IsUpgrade`: Wird auf `true` gesetzt, wenn die aktuelle Operation ein Upgrade oder Rollback ist. - `Release.IsInstall`: Wird auf `true` gesetzt, wenn die aktuelle Operation eine Installation ist. - `Release.Revision`: Die Revisionsnummer für dieses Release. Bei der Installation ist dies 1, und sie wird mit jedem Upgrade und Rollback erhöht. - `Release.Service`: Der Dienst, der das aktuelle Template rendert. In Helm ist dies immer `Helm`. - `Values`: Werte, die aus der `values.yaml`-Datei und aus vom Benutzer bereitgestellten Dateien an das Template übergeben werden. Standardmäßig ist `Values` leer. - `Chart`: Der Inhalt der `Chart.yaml`-Datei. Alle Daten in `Chart.yaml` sind hier zugänglich. Zum Beispiel gibt `{{ .Chart.Name }}-{{ .Chart.Version }}` `mychart-0.1.0` aus. - Die verfügbaren Felder sind in der [Charts-Anleitung](/topics/charts.md#the-chartyaml-file) aufgelistet - `Subcharts`: Dies ermöglicht den Zugriff auf den Scope (.Values, .Charts, .Releases usw.) von Subcharts für das übergeordnete Chart. Zum Beispiel greift `.Subcharts.mySubChart.myValue` auf den `myValue` im `mySubChart`-Chart zu. - `Files`: Dies ermöglicht den Zugriff auf alle nicht-speziellen Dateien in einem Chart. Sie können damit zwar nicht auf Templates zugreifen, aber auf andere Dateien im Chart. Weitere Informationen finden Sie im Abschnitt [Zugriff auf Dateien](/chart_template_guide/accessing_files.md). - `Files.Get` ist eine Funktion zum Abrufen einer Datei nach Namen (`.Files.Get config.ini`) - `Files.GetBytes` ist eine Funktion zum Abrufen des Inhalts einer Datei als Byte-Array anstatt als String. Dies ist nützlich für Dinge wie Bilder. - `Files.Glob` ist eine Funktion, die eine Liste von Dateien zurückgibt, deren Namen dem angegebenen Shell-Glob-Muster entsprechen. - `Files.Lines` ist eine Funktion, die eine Datei Zeile für Zeile liest. Dies ist nützlich für die Iteration über jede Zeile in einer Datei. - `Files.AsSecrets` ist eine Funktion, die die Dateiinhalte als Base64- codierte Strings zurückgibt. - `Files.AsConfig` ist eine Funktion, die Dateiinhalte als YAML-Map zurückgibt. - `Capabilities`: Dies liefert Informationen darüber, welche Fähigkeiten der Kubernetes-Cluster unterstützt. - `Capabilities.APIVersions` ist eine Sammlung von Versionen. - `Capabilities.APIVersions.Has $version` gibt an, ob eine Version (z.B. `batch/v1`) oder Ressource (z.B. `apps/v1/Deployment`) im Cluster verfügbar ist. - `Capabilities.KubeVersion` und `Capabilities.KubeVersion.Version` ist die Kubernetes-Version. - `Capabilities.KubeVersion.Major` ist die Kubernetes-Hauptversion. - `Capabilities.KubeVersion.Minor` ist die Kubernetes-Nebenversion. - `Capabilities.HelmVersion` ist das Objekt, das die Helm-Versionsdetails enthält; es entspricht der Ausgabe von `helm version`. - `Capabilities.HelmVersion.Version` ist die aktuelle Helm-Version im SemVer-Format. - `Capabilities.HelmVersion.GitCommit` ist der Helm-Git-SHA1. - `Capabilities.HelmVersion.GitTreeState` ist der Zustand des Helm-Git-Trees. - `Capabilities.HelmVersion.GoVersion` ist die Version des verwendeten Go-Compilers. - `Template`: Enthält Informationen über das aktuelle Template, das ausgeführt wird - `Template.Name`: Ein namespace-qualifizierter Dateipfad zum aktuellen Template (z.B. `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: Der namespace-qualifizierte Pfad zum Templates- Verzeichnis des aktuellen Charts (z.B. `mychart/templates`). Die integrierten Werte beginnen immer mit einem Großbuchstaben. Dies entspricht der Go-Namenskonvention. Wenn Sie Ihre eigenen Namen erstellen, können Sie eine Konvention verwenden, die zu Ihrem Team passt. Einige Teams, wie viele, deren Charts Sie auf [Artifact Hub](https://artifacthub.io/packages/search?kind=0) finden können, verwenden nur Kleinbuchstaben am Anfang, um lokale Namen von den integrierten zu unterscheiden. In dieser Anleitung folgen wir dieser Konvention. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Ablaufsteuerung description: Ein kurzer Überblick über die Ablaufstrukturen in Templates. sidebar_position: 7 --- Kontrollstrukturen (in der Template-Terminologie "Aktionen" genannt) bieten Ihnen als Template-Autor die Möglichkeit, den Ablauf der Template-Generierung zu steuern. Die Template-Sprache von Helm bietet die folgenden Kontrollstrukturen: - `if`/`else` zum Erstellen von bedingten Blöcken - `with` zum Festlegen eines Geltungsbereichs - `range`, das eine "für jedes"-Schleife bereitstellt Zusätzlich zu diesen bietet sie einige Aktionen zum Deklarieren und Verwenden von benannten Template-Segmenten: - `define` deklariert ein neues benanntes Template innerhalb Ihres Templates - `template` importiert ein benanntes Template - `block` deklariert einen speziellen, ausfüllbaren Template-Bereich In diesem Abschnitt behandeln wir `if`, `with` und `range`. Die anderen werden im Abschnitt "Benannte Templates" später in dieser Anleitung behandelt. ## If/Else Die erste Kontrollstruktur, die wir uns ansehen werden, dient zum bedingten Einbinden von Textblöcken in einem Template. Dies ist der `if`/`else`-Block. Die grundlegende Struktur für eine Bedingung sieht so aus: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Beachten Sie: Hier geht es um _Pipelines_, nicht nur um einzelne Werte. Der Grund dafür ist, klarzumachen, dass Kontrollstrukturen eine ganze Pipeline ausführen können – nicht nur einen Wert auswerten. Eine Pipeline wird als _false_ ausgewertet, wenn der Wert: - ein boolesches false ist - eine numerische Null ist - ein leerer String ist - `nil` (leer oder null) ist - eine leere Sammlung (`map`, `slice`, `tuple`, `dict`, `array`) ist Unter allen anderen Bedingungen ist die Bedingung wahr. Fügen wir eine einfache Bedingung zu unserer ConfigMap hinzu. Wir fügen eine weitere Einstellung hinzu, wenn das Getränk auf Kaffee gesetzt ist: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Da wir `drink: coffee` in unserem letzten Beispiel auskommentiert haben, sollte die Ausgabe kein `mug: "true"` Flag enthalten. Aber wenn wir diese Zeile in unsere `values.yaml`-Datei zurücksetzen, sollte die Ausgabe so aussehen: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Steuerung von Leerzeichen Während wir uns mit Bedingungen beschäftigen, sollten wir einen kurzen Blick darauf werfen, wie Leerzeichen in Templates gesteuert werden. Nehmen wir das vorherige Beispiel und formatieren es etwas leserlicher: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Zunächst sieht das gut aus. Aber wenn wir es durch die Template-Engine laufen lassen, erhalten wir ein unglückliches Ergebnis: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Was ist passiert? Wir haben wegen der obigen Leerzeichen ungültiges YAML generiert. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` ist falsch eingerückt. Lassen Sie uns einfach diese eine Zeile nach links verschieben und erneut ausführen: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Wenn wir das ausführen, erhalten wir YAML, das gültig ist, aber immer noch etwas seltsam aussieht: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Beachten Sie, dass wir einige Leerzeilen in unserem YAML erhalten haben. Warum? Wenn die Template-Engine läuft, _entfernt_ sie den Inhalt innerhalb von `{{` und `}}`, lässt aber die verbleibenden Leerzeichen genau so, wie sie sind. YAML misst Leerzeichen eine Bedeutung bei, daher wird die Verwaltung von Leerzeichen ziemlich wichtig. Glücklicherweise haben Helm-Templates einige Werkzeuge, um dabei zu helfen. Erstens kann die geschweifte Klammer-Syntax von Template-Deklarationen mit speziellen Zeichen modifiziert werden, um der Template-Engine mitzuteilen, dass sie Leerzeichen entfernen soll. `{{- ` (mit dem Bindestrich und Leerzeichen) zeigt an, dass Leerzeichen links entfernt werden sollen, während ` -}}` bedeutet, dass Leerzeichen rechts entfernt werden sollen. _Vorsicht! Zeilenumbrüche sind auch Leerzeichen!_ > Stellen Sie sicher, dass zwischen dem `-` und dem Rest Ihrer Direktive ein > Leerzeichen steht. `{{- 3 }}` bedeutet "entferne Leerzeichen links und gib 3 aus", > während `{{-3 }}` "gib -3 aus" bedeutet. Mit dieser Syntax können wir unser Template ändern, um diese Leerzeilen loszuwerden: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Zur Verdeutlichung passen wir das Obige an und ersetzen ein `*` für jedes Leerzeichen, das nach dieser Regel gelöscht wird. Ein `*` am Ende der Zeile zeigt ein Zeilenumbruchzeichen an, das entfernt würde: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Mit diesem Wissen können wir unser Template durch Helm ausführen und das Ergebnis sehen: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Vorsicht bei den Entfernungsmodifikatoren. Es ist leicht, versehentlich so etwas zu tun: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Das erzeugt `food: "PIZZA"mug: "true"`, weil es die Zeilenumbrüche auf beiden Seiten entfernt hat. > Für Details zur Leerzeichen-Steuerung in Templates siehe die [offizielle Go > Template-Dokumentation](https://godoc.org/text/template) Schließlich ist es manchmal einfacher, dem Template-System zu sagen, wie es für Sie einrücken soll, anstatt zu versuchen, die Abstände der Template-Direktiven zu meistern. Aus diesem Grund kann es manchmal nützlich sein, die `indent`- Funktion zu verwenden (`{{ indent 2 "mug:true" }}`). ## Geltungsbereich ändern mit `with` Die nächste Kontrollstruktur, die wir uns ansehen werden, ist die `with`-Aktion. Diese steuert den Geltungsbereich von Variablen. Zur Erinnerung: `.` ist eine Referenz auf _den aktuellen Geltungsbereich_. So sagt `.Values` dem Template, dass es das `Values`-Objekt im aktuellen Geltungsbereich finden soll. Die Syntax für `with` ähnelt einer einfachen `if`-Anweisung: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Geltungsbereiche können geändert werden. `with` kann es Ihnen ermöglichen, den aktuellen Geltungsbereich (`.`) auf ein bestimmtes Objekt zu setzen. Zum Beispiel haben wir mit `.Values.favorite` gearbeitet. Lassen Sie uns unsere ConfigMap umschreiben, um den `.`-Geltungsbereich so zu ändern, dass er auf `.Values.favorite` zeigt: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Beachten Sie, dass wir die `if`-Bedingung aus der vorherigen Übung entfernt haben, weil sie jetzt nicht mehr notwendig ist – der Block nach `with` wird nur ausgeführt, wenn der Wert der `PIPELINE` nicht leer ist. Beachten Sie, dass wir jetzt `.drink` und `.food` ohne Qualifizierung referenzieren können. Das liegt daran, dass die `with`-Anweisung `.` so setzt, dass es auf `.Values.favorite` zeigt. Der `.` wird nach `{{ end }}` auf seinen vorherigen Geltungsbereich zurückgesetzt. Aber Vorsicht! Innerhalb des eingeschränkten Geltungsbereichs können Sie nicht mit `.` auf die anderen Objekte aus dem übergeordneten Geltungsbereich zugreifen. Das folgende Beispiel wird fehlschlagen: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Es wird einen Fehler erzeugen, weil `Release.Name` nicht innerhalb des eingeschränkten Geltungsbereichs für `.` liegt. Wenn wir jedoch die letzten beiden Zeilen vertauschen, funktioniert alles wie erwartet, weil der Geltungsbereich nach `{{ end }}` zurückgesetzt wird. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Oder wir können `$` verwenden, um auf das Objekt `Release.Name` aus dem übergeordneten Geltungsbereich zuzugreifen. `$` wird bei Beginn der Template-Ausführung auf den Root-Geltungsbereich gemappt und ändert sich während der Template-Ausführung nicht. Das Folgende würde ebenfalls funktionieren: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Nachdem wir uns `range` angesehen haben, werden wir einen Blick auf Template-Variablen werfen, die eine Lösung für das obige Geltungsbereichsproblem bieten. ## Schleifen mit der `range`-Aktion Viele Programmiersprachen unterstützen Schleifen mit `for`-Schleifen, `foreach`- Schleifen oder ähnlichen funktionalen Mechanismen. In der Template-Sprache von Helm ist die Methode zum Iterieren durch eine Sammlung der `range`-Operator. Zunächst fügen wir eine Liste von Pizza-Belägen zu unserer `values.yaml`-Datei hinzu: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Jetzt haben wir eine Liste (in Templates `slice` genannt) von `pizzaToppings`. Wir können unser Template ändern, um diese Liste in unsere ConfigMap auszugeben: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Wir können `$` verwenden, um auf die Liste `Values.pizzaToppings` aus dem übergeordneten Geltungsbereich zuzugreifen. `$` wird bei Beginn der Template- Ausführung auf den Root-Geltungsbereich gemappt und ändert sich während der Template-Ausführung nicht. Das Folgende würde ebenfalls funktionieren: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Schauen wir uns die `toppings:`-Liste genauer an. Die `range`-Funktion wird durch die `pizzaToppings`-Liste "rangieren" (iterieren). Aber jetzt passiert etwas Interessantes. Genau wie `with` den Geltungsbereich von `.` setzt, tut dies auch ein `range`-Operator. Bei jedem Durchlauf durch die Schleife wird `.` auf den aktuellen Pizza-Belag gesetzt. Das heißt, beim ersten Mal wird `.` auf `mushrooms` gesetzt. In der zweiten Iteration wird es auf `cheese` gesetzt, und so weiter. Wir können den Wert von `.` direkt durch eine Pipeline senden, sodass wenn wir `{{ . | title | quote }}` ausführen, es `.` an `title` (Großschreibungsfunktion) und dann an `quote` sendet. Wenn wir dieses Template ausführen, ist die Ausgabe: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` In diesem Beispiel haben wir etwas Trickreiches gemacht. Die Zeile `toppings: |-` deklariert einen mehrzeiligen String. Unsere Belagsliste ist also eigentlich keine YAML-Liste. Sie ist ein großer String. Warum sollten wir das tun? Weil die Daten in ConfigMaps aus Schlüssel/Wert-Paaren bestehen, bei denen sowohl der Schlüssel als auch der Wert einfache Strings sind. Um zu verstehen, warum das so ist, schauen Sie sich die [Kubernetes ConfigMap- Dokumentation](https://kubernetes.io/docs/concepts/configuration/configmap/) an. Für uns spielt dieses Detail jedoch keine große Rolle. > Die `|-`-Markierung in YAML nimmt einen mehrzeiligen String. Dies kann eine > nützliche Technik sein, um große Datenblöcke in Ihre Manifeste einzubetten, > wie hier gezeigt. Manchmal ist es nützlich, schnell eine Liste innerhalb Ihres Templates zu erstellen und dann über diese Liste zu iterieren. Helm-Templates haben eine Funktion, die das einfach macht: `tuple`. In der Informatik ist ein Tupel eine listenartige Sammlung fester Größe, aber mit beliebigen Datentypen. Dies vermittelt ungefähr, wie ein `tuple` verwendet wird. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Das Obige erzeugt: ```yaml sizes: |- - small - medium - large ``` Zusätzlich zu Listen und Tupeln kann `range` verwendet werden, um über Sammlungen zu iterieren, die einen Schlüssel und einen Wert haben (wie eine `map` oder `dict`). Wir werden sehen, wie das geht, im nächsten Abschnitt, wenn wir Template-Variablen einführen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Anhang: Go-Datentypen und Templates" description: Ein kurzer Überblick über Variablen in Templates. sidebar_position: 16 --- Die Helm-Template-Sprache ist in der stark typisierten Programmiersprache Go implementiert. Aus diesem Grund sind Variablen in Templates _typisiert_. In den meisten Fällen werden Variablen als einer der folgenden Typen bereitgestellt: - string: Eine Textzeichenkette - bool: Ein `true` oder `false` - int: Ein Integer-Wert (es gibt auch 8-, 16-, 32- und 64-Bit-Varianten, jeweils mit und ohne Vorzeichen) - float64: Ein 64-Bit-Gleitkommawert (es gibt auch 8-, 16- und 32-Bit-Varianten davon) - Ein Byte-Slice (`[]byte`), das häufig für (potenziell) binäre Daten verwendet wird - struct: Ein Objekt mit Eigenschaften und Methoden - Ein Slice (indizierte Liste) eines der vorherigen Typen - Eine Map mit String-Schlüsseln (`map[string]interface{}`), wobei der Wert einer der vorherigen Typen ist Es gibt viele andere Typen in Go, und manchmal müssen Sie in Ihren Templates zwischen ihnen konvertieren. Am einfachsten ermitteln Sie den Typ eines Objekts, indem Sie es in einem Template an `printf "%T"` übergeben – dies gibt den Typ aus. Siehe hierfür auch die Funktionen `typeOf` und `kindOf`. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Templates debuggen description: Fehlerbehebung bei Charts, die nicht bereitgestellt werden können. sidebar_position: 13 --- Das Debuggen von Templates kann schwierig sein, da die gerenderten Templates an den Kubernetes-API-Server gesendet werden, der die YAML-Dateien aus anderen Gründen als der Formatierung ablehnen kann. Es gibt einige Befehle, die Ihnen beim Debuggen helfen können. - `helm lint` ist Ihr bevorzugtes Werkzeug, um zu überprüfen, ob Ihr Chart den Best Practices entspricht - `helm template --debug` testet das Rendern von Chart-Templates lokal. - `helm install --dry-run --debug` rendert Ihr Chart ebenfalls lokal ohne es zu installieren, prüft aber auch, ob bereits konfliktbehaftete Ressourcen auf dem Cluster laufen. Mit `--dry-run=server` werden zusätzlich alle `lookup`-Aufrufe in Ihrem Chart gegen den Server ausgeführt. - `helm get manifest`: Dies ist eine gute Möglichkeit zu sehen, welche Templates auf dem Server installiert sind. Wenn Ihr YAML nicht geparst werden kann, Sie aber sehen möchten, was generiert wird, ist eine einfache Möglichkeit, das YAML abzurufen, den problematischen Abschnitt im Template auszukommentieren und dann `helm install --dry-run --debug` erneut auszuführen: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` Der obige Code wird gerendert und mit den Kommentaren intakt zurückgegeben: ```yaml apiVersion: v2 # some: problem section # "bar" ``` Dies bietet eine schnelle Möglichkeit, den generierten Inhalt anzuzeigen, ohne von YAML-Parse-Fehlern aufgehalten zu werden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Liste der Template-Funktionen description: Eine Liste der in Helm verfügbaren Template-Funktionen sidebar_position: 6 --- Helm enthält viele Template-Funktionen, die Sie in Templates nutzen können. Sie sind hier aufgelistet und in folgende Kategorien unterteilt: * [Kryptografie und Sicherheit](#kryptografie--und-sicherheitsfunktionen) * [Datum](#datumsfunktionen) * [Dictionaries](#dictionaries-und-dict-funktionen) * [Encoding](#encoding-funktionen) * [Dateipfade](#dateipfad-funktionen) * [Kubernetes und Chart](#kubernetes--und-chart-funktionen) * [Logik und Ablaufsteuerung](#logik--und-ablaufsteuerungsfunktionen) * [Listen](#listen-und-list-funktionen) * [Mathematik](#mathematische-funktionen) * [Float-Mathematik](#float-mathematik-funktionen) * [Netzwerk](#netzwerk-funktionen) * [Reflection](#reflection-funktionen) * [Reguläre Ausdrücke](#reguläre-ausdrücke) * [Semantische Versionen](#semantische-versionsfunktionen) * [Strings](#string-funktionen) * [Typkonvertierung](#typkonvertierungsfunktionen) * [URL](#url-funktionen) * [UUID](#uuid-funktionen) ## Logik- und Ablaufsteuerungsfunktionen Helm enthält zahlreiche Logik- und Ablaufsteuerungsfunktionen, darunter [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) und [required](#required). ### and Gibt das boolesche AND von zwei oder mehr Argumenten zurück (das erste leere Argument oder das letzte Argument). ``` and .Arg1 .Arg2 ``` ### or Gibt das boolesche OR von zwei oder mehr Argumenten zurück (das erste nicht-leere Argument oder das letzte Argument). ``` or .Arg1 .Arg2 ``` ### not Gibt die boolesche Negation des Arguments zurück. ``` not .Arg ``` ### eq Gibt die boolesche Gleichheit der Argumente zurück (z.B. Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Gibt die boolesche Ungleichheit der Argumente zurück (z.B. Arg1 != Arg2). ``` ne .Arg1 .Arg2 ``` ### lt Gibt `true` zurück, wenn das erste Argument kleiner als das zweite ist. Andernfalls wird `false` zurückgegeben (z.B. Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Gibt `true` zurück, wenn das erste Argument kleiner oder gleich dem zweiten ist. Andernfalls wird `false` zurückgegeben (z.B. Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Gibt `true` zurück, wenn das erste Argument größer als das zweite ist. Andernfalls wird `false` zurückgegeben (z.B. Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Gibt `true` zurück, wenn das erste Argument größer oder gleich dem zweiten ist. Andernfalls wird `false` zurückgegeben (z.B. Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default Um einen einfachen Standardwert zu setzen, verwenden Sie `default`: ``` default "foo" .Bar ``` Wenn `.Bar` einen nicht-leeren Wert ergibt, wird dieser verwendet. Ist er jedoch leer, wird stattdessen `foo` zurückgegeben. Die Definition von "leer" hängt vom Typ ab: - Numerisch: 0 - String: "" - Listen: `[]` - Dicts: `{}` - Boolean: `false` - Und immer `nil` (auch bekannt als null) Für Structs gibt es keine Definition von leer, daher gibt ein Struct niemals den Standardwert zurück. ### required Geben Sie Werte an, die mit `required` gesetzt werden müssen: ``` required "A valid foo is required!" .Bar ``` Wenn `.Bar` leer oder nicht definiert ist (siehe [default](#default) für die Auswertung), wird das Template nicht gerendert und stattdessen die angegebene Fehlermeldung zurückgegeben. ### empty Die Funktion `empty` gibt `true` zurück, wenn der angegebene Wert als leer gilt, andernfalls `false`. Die leeren Werte sind im Abschnitt `default` aufgelistet. ``` empty .Foo ``` Beachten Sie, dass in Go-Template-Bedingungen die Leerheit automatisch berechnet wird. Daher benötigen Sie selten `if not empty .Foo`. Verwenden Sie stattdessen einfach `if .Foo`. ### fail Gibt bedingungslos einen leeren `string` und einen `error` mit dem angegebenen Text zurück. Dies ist nützlich in Szenarien, in denen andere Bedingungen festgestellt haben, dass das Template-Rendering fehlschlagen sollte. ``` fail "Please accept the end user license agreement" ``` ### coalesce Die Funktion `coalesce` nimmt eine Liste von Werten und gibt den ersten nicht-leeren zurück. ``` coalesce 0 1 2 ``` Das obige gibt `1` zurück. Diese Funktion ist nützlich, um mehrere Variablen oder Werte zu durchsuchen: ``` coalesce .name .parent.name "Matt" ``` Das obige prüft zunächst, ob `.name` leer ist. Falls nicht, wird dieser Wert zurückgegeben. Falls er _leer ist_, wertet `coalesce` `.parent.name` auf Leerheit aus. Wenn schließlich sowohl `.name` als auch `.parent.name` leer sind, wird `Matt` zurückgegeben. ### ternary Die Funktion `ternary` nimmt zwei Werte und einen Testwert. Wenn der Testwert `true` ist, wird der erste Wert zurückgegeben. Wenn der Testwert leer ist, wird der zweite Wert zurückgegeben. Dies ähnelt dem ternären Operator in C und anderen Programmiersprachen. #### true-Testwert ``` ternary "foo" "bar" true ``` oder ``` true | ternary "foo" "bar" ``` Das obige gibt `"foo"` zurück. #### false-Testwert ``` ternary "foo" "bar" false ``` oder ``` false | ternary "foo" "bar" ``` Das obige gibt `"bar"` zurück. ## String-Funktionen Helm enthält die folgenden String-Funktionen: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-und-hassuffix), [hasSuffix](#hasprefix-und-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-und-squote), [randAlpha](#randalphanum-randalpha-randnumeric-und-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-und-randascii), [randAscii](#randalphanum-randalpha-randnumeric-und-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-und-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-und-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap) und [wrapWith](#wrapwith). ### print Gibt einen String aus der Kombination seiner Teile zurück. ``` print "Matt has " .Dogs " dogs" ``` Typen, die keine Strings sind, werden nach Möglichkeit in Strings konvertiert. Beachten Sie, dass zwischen zwei nebeneinanderstehenden Argumenten, die keine Strings sind, ein Leerzeichen eingefügt wird. ### println Funktioniert wie [print](#print), fügt aber am Ende eine neue Zeile hinzu. ### printf Gibt einen String basierend auf einem Formatierungsstring und den übergebenen Argumenten zurück. ``` printf "%s has %d dogs." .Name .NumberDogs ``` Der zu verwendende Platzhalter hängt vom Typ des übergebenen Arguments ab. Dies umfasst: Allgemein: * `%v` der Wert im Standardformat * beim Drucken von Dicts fügt das Plus-Flag (%+v) Feldnamen hinzu * `%%` ein literales Prozentzeichen; verbraucht keinen Wert Boolean: * `%t` das Wort true oder false Integer: * `%b` Basis 2 * `%c` das Zeichen, das durch den entsprechenden Unicode-Codepunkt dargestellt wird * `%d` Basis 10 * `%o` Basis 8 * `%O` Basis 8 mit 0o-Präfix * `%q` ein einzeln zitiertes Zeichenliteral, sicher escaped * `%x` Basis 16, mit Kleinbuchstaben für a-f * `%X` Basis 16, mit Großbuchstaben für A-F * `%U` Unicode-Format: U+1234; entspricht "U+%04X" Fließkomma- und komplexe Bestandteile: * `%b` dezimale wissenschaftliche Notation mit Exponent als Zweierpotenz, z.B. -123456p-78 * `%e` wissenschaftliche Notation, z.B. -1.234456e+78 * `%E` wissenschaftliche Notation, z.B. -1.234456E+78 * `%f` Dezimalpunkt ohne Exponent, z.B. 123.456 * `%F` Synonym für %f * `%g` %e für große Exponenten, sonst %f * `%G` %E für große Exponenten, sonst %F * `%x` hexadezimale Notation (mit dezimaler Zweierpotenz als Exponent), z.B. -0x1.23abcp+20 * `%X` hexadezimale Notation in Großbuchstaben, z.B. -0X1.23ABCP+20 String und Byte-Slice (werden gleichwertig behandelt mit diesen Verben): * `%s` die nicht interpretierten Bytes des Strings oder Slice * `%q` ein doppelt zitierter String, sicher escaped * `%x` Basis 16, Kleinbuchstaben, zwei Zeichen pro Byte * `%X` Basis 16, Großbuchstaben, zwei Zeichen pro Byte Slice: * `%p` Adresse des 0. Elements in Basis-16-Notation mit führendem 0x ### trim Die Funktion `trim` entfernt Leerzeichen von beiden Seiten eines Strings: ``` trim " hello " ``` Das obige erzeugt `hello` ### trimAll Entfernt die angegebenen Zeichen vorne und hinten aus einem String: ``` trimAll "$" "$5.00" ``` Das obige gibt `5.00` zurück (als String). ### trimPrefix Entfernt nur das Präfix aus einem String: ``` trimPrefix "-" "-hello" ``` Das obige gibt `hello` zurück ### trimSuffix Entfernt nur das Suffix aus einem String: ``` trimSuffix "-" "hello-" ``` Das obige gibt `hello` zurück ### lower Konvertiert den gesamten String in Kleinbuchstaben: ``` lower "HELLO" ``` Das obige gibt `hello` zurück ### upper Konvertiert den gesamten String in Großbuchstaben: ``` upper "hello" ``` Das obige gibt `HELLO` zurück ### title Konvertiert in Titel-Schreibweise: ``` title "hello world" ``` Das obige gibt `Hello World` zurück ### untitle Entfernt die Titel-Schreibweise. `untitle "Hello World"` erzeugt `hello world`. ### repeat Wiederholt einen String mehrfach: ``` repeat 3 "hello" ``` Das obige gibt `hellohellohello` zurück ### substr Holt einen Teilstring aus einem String. Es werden drei Parameter benötigt: - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` Das obige gibt `hello` zurück ### nospace Entfernt alle Leerzeichen aus einem String. ``` nospace "hello w o r l d" ``` Das obige gibt `helloworld` zurück ### trunc Kürzt einen String ``` trunc 5 "hello world" ``` Das obige erzeugt `hello`. ``` trunc -5 "hello world" ``` Das obige erzeugt `world`. ### abbrev Kürzt einen String mit Auslassungspunkten (`...`) Parameter: - maximale Länge - der String ``` abbrev 5 "hello world" ``` Das obige gibt `he...` zurück, da die Breite der Auslassungspunkte gegen die maximale Länge gerechnet wird. ### abbrevboth Kürzt auf beiden Seiten: ``` abbrevboth 5 10 "1234 5678 9123" ``` Das obige erzeugt `...5678...` Es werden benötigt: - linker Offset - maximale Länge - der String ### initials Nimmt bei mehreren Wörtern den ersten Buchstaben jedes Wortes und kombiniert sie. ``` initials "First Try" ``` Das obige gibt `FT` zurück ### randAlphaNum, randAlpha, randNumeric und randAscii Diese vier Funktionen generieren kryptografisch sichere (verwendet ```crypto/rand```) zufällige Strings, aber mit unterschiedlichen Basis-Zeichensätzen: - `randAlphaNum` verwendet `0-9a-zA-Z` - `randAlpha` verwendet `a-zA-Z` - `randNumeric` verwendet `0-9` - `randAscii` verwendet alle druckbaren ASCII-Zeichen Jede nimmt einen Parameter: die ganzzahlige Länge des Strings. ``` randNumeric 3 ``` Das obige erzeugt einen zufälligen String mit drei Ziffern. ### wrap Umbricht Text bei einer angegebenen Spaltenanzahl: ``` wrap 80 $someText ``` Das obige umbricht den String in `$someText` bei 80 Spalten. ### wrapWith `wrapWith` funktioniert wie `wrap`, aber erlaubt die Angabe des Umbruch-Strings. (`wrap` verwendet `\n`) ``` wrapWith 5 "\t" "Hello World" ``` Das obige erzeugt `Hello World` (wobei das Leerzeichen ein ASCII-Tabulatorzeichen ist) ### contains Prüft, ob ein String in einem anderen enthalten ist: ``` contains "cat" "catch" ``` Das obige gibt `true` zurück, weil `catch` das Wort `cat` enthält. ### hasPrefix und hasSuffix Die Funktionen `hasPrefix` und `hasSuffix` prüfen, ob ein String ein bestimmtes Präfix oder Suffix hat: ``` hasPrefix "cat" "catch" ``` Das obige gibt `true` zurück, weil `catch` das Präfix `cat` hat. ### quote und squote Diese Funktionen umschließen einen String mit doppelten Anführungszeichen (`quote`) oder einfachen Anführungszeichen (`squote`). ### cat Die Funktion `cat` verkettet mehrere Strings zu einem und trennt sie durch Leerzeichen: ``` cat "hello" "beautiful" "world" ``` Das obige erzeugt `hello beautiful world` ### indent Die Funktion `indent` rückt jede Zeile in einem gegebenen String um die angegebene Einrückungsbreite ein. Dies ist nützlich beim Ausrichten von mehrzeiligen Strings: ``` indent 4 $lots_of_text ``` Das obige rückt jede Textzeile um 4 Leerzeichen ein. ### nindent Die Funktion `nindent` ist identisch mit der Funktion indent, stellt aber eine neue Zeile an den Anfang des Strings. ``` nindent 4 $lots_of_text ``` Das obige rückt jede Textzeile um 4 Leerzeichen ein und fügt am Anfang eine neue Zeile hinzu. ### replace Führt eine einfache String-Ersetzung durch. Es werden drei Argumente benötigt: - zu ersetzender String - Ersetzungs-String - Quell-String ``` "I Am Henry VIII" | replace " " "-" ``` Das obige erzeugt `I-Am-Henry-VIII` ### plural Pluralisiert einen String. ``` len $fish | plural "one anchovy" "many anchovies" ``` Wenn die Länge des Strings 1 ist, wird das erste Argument ausgegeben (`one anchovy`). Andernfalls wird das zweite Argument ausgegeben (`many anchovies`). Die Argumente sind: - Singular-String - Plural-String - Länge als Integer HINWEIS: Helm unterstützt derzeit keine Sprachen mit komplexeren Pluralbildungsregeln. Und `0` wird als Plural betrachtet, weil die englische Sprache es so behandelt (`zero anchovies`). ### snakecase Konvertiert einen String von camelCase in snake_case. ``` snakecase "FirstName" ``` Das obige erzeugt `first_name`. ### camelcase Konvertiert einen String von snake_case in CamelCase. ``` camelcase "http_server" ``` Das obige erzeugt `HttpServer`. ### kebabcase Konvertiert einen String von camelCase in kebab-case. ``` kebabcase "FirstName" ``` Das obige erzeugt `first-name`. ### swapcase Tauscht die Groß-/Kleinschreibung eines Strings mit einem wortbasierten Algorithmus. Konvertierungsalgorithmus: - Großbuchstabe wird zu Kleinbuchstabe - Titelbuchstabe wird zu Kleinbuchstabe - Kleinbuchstabe nach Leerzeichen oder am Anfang wird zu Titelbuchstabe - Andere Kleinbuchstaben werden zu Großbuchstaben - Leerzeichen wird durch unicode.IsSpace(char) definiert ``` swapcase "This Is A.Test" ``` Das obige erzeugt `tHIS iS a.tEST`. ### shuffle Mischt einen String. ``` shuffle "hello" ``` Das obige randomisiert die Buchstaben in `hello` und erzeugt möglicherweise `oelhl`. ## Typkonvertierungsfunktionen Die folgenden Typkonvertierungsfunktionen werden von Helm bereitgestellt: - `atoi`: Konvertiert einen String in einen Integer. - `float64`: Konvertiert in einen `float64`. - `int`: Konvertiert in einen `int` mit der Systembreite. - `int64`: Konvertiert in einen `int64`. - `toDecimal`: Konvertiert eine Unix-Oktalzahl in einen `int64`. - `toString`: Konvertiert in einen String. - `toStrings`: Konvertiert eine Liste, Slice oder Array in eine Liste von Strings. - `toJson` (`mustToJson`): Konvertiert Liste, Slice, Array, Dict oder Objekt in JSON. - `toPrettyJson` (`mustToPrettyJson`): Konvertiert Liste, Slice, Array, Dict oder Objekt in eingerücktes JSON. - `toRawJson` (`mustToRawJson`): Konvertiert Liste, Slice, Array, Dict oder Objekt in JSON mit nicht-escaped HTML-Zeichen. - `fromYaml`: Konvertiert einen YAML-String in ein Objekt. - `fromJson`: Konvertiert einen JSON-String in ein Objekt. - `fromJsonArray`: Konvertiert ein JSON-Array in eine Liste. - `toYaml`: Konvertiert Liste, Slice, Array, Dict oder Objekt in eingerücktes YAML. Diese Funktion entspricht der GoLang yaml.Marshal-Funktion, siehe Dokumentation: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Konvertiert Liste, Slice, Array, Dict oder Objekt in eingerücktes YAML. Entspricht `toYaml`, rückt aber Listen zusätzlich um 2 Leerzeichen ein. - `toToml`: Konvertiert Liste, Slice, Array, Dict oder Objekt in TOML. - `fromYamlArray`: Konvertiert ein YAML-Array in eine Liste. Nur `atoi` erfordert, dass die Eingabe einen bestimmten Typ hat. Die anderen versuchen, von jedem Typ in den Zieltyp zu konvertieren. Zum Beispiel kann `int64` Floats in Ints und auch Strings in Ints konvertieren. ### toStrings Erzeugt bei einer listenähnlichen Sammlung eine Liste von Strings. ``` list 1 2 3 | toStrings ``` Das obige konvertiert `1` in `"1"`, `2` in `"2"` usw. und gibt sie dann als Liste zurück. ### toDecimal Erzeugt aus einer Unix-Oktal-Berechtigung eine Dezimalzahl. ``` "0777" | toDecimal ``` Das obige konvertiert `0777` in `511` und gibt den Wert als int64 zurück. ### toJson, mustToJson Die Funktion `toJson` kodiert ein Element in einen JSON-String. Wenn das Element nicht in JSON konvertiert werden kann, gibt die Funktion einen leeren String zurück. `mustToJson` gibt einen Fehler zurück, falls das Element nicht in JSON kodiert werden kann. ``` toJson .Item ``` Das obige gibt die JSON-String-Darstellung von `.Item` zurück. ### toPrettyJson, mustToPrettyJson Die Funktion `toPrettyJson` kodiert ein Element in einen formatierten (eingerückten) JSON-String. ``` toPrettyJson .Item ``` Das obige gibt die eingerückte JSON-String-Darstellung von `.Item` zurück. ### toRawJson, mustToRawJson Die Funktion `toRawJson` kodiert ein Element in einen JSON-String mit nicht-escaped HTML-Zeichen. ``` toRawJson .Item ``` Das obige gibt die nicht-escaped JSON-String-Darstellung von `.Item` zurück. ### fromYaml Die Funktion `fromYaml` nimmt einen YAML-String und gibt ein Objekt zurück, das in Templates verwendet werden kann. `Datei unter: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson Die Funktion `fromJson` nimmt einen JSON-String und gibt ein Objekt zurück, das in Templates verwendet werden kann. `Datei unter: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray Die Funktion `fromJsonArray` nimmt ein JSON-Array und gibt eine Liste zurück, die in Templates verwendet werden kann. `Datei unter: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty Die Funktionen `toYaml` und `toYamlPretty` kodieren ein Objekt (Liste, Slice, Array, Dict oder Objekt) in einen eingerückten YAML-String. > Beachten Sie, dass `toYamlPretty` funktional äquivalent ist, aber YAML mit > zusätzlicher Einrückung für Listenelemente ausgibt ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray Die Funktion `fromYamlArray` nimmt ein YAML-Array und gibt eine Liste zurück, die in Templates verwendet werden kann. `Datei unter: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Reguläre Ausdrücke Helm enthält die folgenden Funktionen für reguläre Ausdrücke: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Gibt `true` zurück, wenn der Eingabe-String eine Übereinstimmung mit dem regulären Ausdruck enthält. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` Das obige erzeugt `true` `regexMatch` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexMatch` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### regexFindAll, mustRegexFindAll Gibt eine Liste aller Übereinstimmungen des regulären Ausdrucks im Eingabe-String zurück. Der letzte Parameter n bestimmt die Anzahl der zurückzugebenden Teilstrings, wobei -1 bedeutet, dass alle Übereinstimmungen zurückgegeben werden. ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` Das obige erzeugt `[2 4 6 8]` `regexFindAll` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexFindAll` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### regexFind, mustRegexFind Gibt die erste (am weitesten links stehende) Übereinstimmung des regulären Ausdrucks im Eingabe-String zurück. ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` Das obige erzeugt `d1` `regexFind` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexFind` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### regexReplaceAll, mustRegexReplaceAll Gibt eine Kopie des Eingabe-Strings zurück, wobei Übereinstimmungen des regulären Ausdrucks durch den Ersetzungs-String ersetzt werden. Innerhalb des Ersetzungs-Strings werden $-Zeichen wie bei Expand interpretiert, sodass z.B. $1 den Text der ersten Unterübereinstimmung darstellt. Das erste Argument ist ``, das zweite ist `` und das dritte ist ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` Das obige erzeugt `-W-xxW-` `regexReplaceAll` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexReplaceAll` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Gibt eine Kopie des Eingabe-Strings zurück, wobei Übereinstimmungen des regulären Ausdrucks durch den Ersetzungs-String ersetzt werden. Der Ersetzungs-String wird direkt eingesetzt, ohne Expand zu verwenden. Das erste Argument ist ``, das zweite ist `` und das dritte ist ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` Das obige erzeugt `-${1}-${1}-` `regexReplaceAllLiteral` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexReplaceAllLiteral` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### regexSplit, mustRegexSplit Teilt den Eingabe-String in Teilstrings auf, die durch den Ausdruck getrennt sind, und gibt eine Liste der Teilstrings zwischen diesen Ausdrucksübereinstimmungen zurück. Der letzte Parameter `n` bestimmt die Anzahl der zurückzugebenden Teilstrings, wobei `-1` bedeutet, dass alle Übereinstimmungen zurückgegeben werden. ``` regexSplit "z+" "pizza" -1 ``` Das obige erzeugt `[pi a]` `regexSplit` löst einen Panic aus, wenn ein Problem auftritt, und `mustRegexSplit` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ## Kryptografie- und Sicherheitsfunktionen Helm bietet einige fortgeschrittene kryptografische Funktionen. Diese umfassen [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) und [sha256sum](#sha256sum). ### sha1sum Die Funktion `sha1sum` empfängt einen String und berechnet dessen SHA1-Digest. ``` sha1sum "Hello world!" ``` ### sha256sum Die Funktion `sha256sum` empfängt einen String und berechnet dessen SHA256-Digest. ``` sha256sum "Hello world!" ``` Das obige berechnet die SHA-256-Summe in einem "ASCII-armored"-Format, das sicher gedruckt werden kann. ### adler32sum Die Funktion `adler32sum` empfängt einen String und berechnet dessen Adler-32-Prüfsumme. ``` adler32sum "Hello world!" ``` ### htpasswd Die Funktion `htpasswd` nimmt einen `username` und ein `password` und erzeugt einen `bcrypt`-Hash des Passworts. Das Ergebnis kann für die Basis-Authentifizierung auf einem [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic) verwendet werden. ``` htpasswd "myUser" "myPassword" ``` Beachten Sie, dass es unsicher ist, das Passwort direkt im Template zu speichern. ### randBytes Die Funktion randBytes akzeptiert eine Anzahl N und erzeugt eine kryptografisch sichere (verwendet crypto/rand) zufällige Sequenz von N Bytes. Die Sequenz wird als base64-kodierter String zurückgegeben. ``` randBytes 24 ``` ### derivePassword Die Funktion `derivePassword` kann verwendet werden, um ein bestimmtes Passwort basierend auf einigen gemeinsamen "Master-Passwort"-Beschränkungen abzuleiten. Der Algorithmus dafür ist [gut spezifiziert](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Beachten Sie, dass es als unsicher gilt, die Teile direkt im Template zu speichern. ### genPrivateKey Die Funktion `genPrivateKey` erzeugt einen neuen privaten Schlüssel, der in einen PEM-Block kodiert ist. Sie nimmt einen der folgenden Werte als ersten Parameter: - `ecdsa`: Erzeugt einen elliptischen Kurven-DSA-Schlüssel (P256) - `dsa`: Erzeugt einen DSA-Schlüssel (L2048N256) - `rsa`: Erzeugt einen RSA-4096-Schlüssel ### buildCustomCert Die Funktion `buildCustomCert` ermöglicht die Anpassung des Zertifikats. Sie nimmt die folgenden String-Parameter: - Ein base64-kodiertes Zertifikat im PEM-Format - Ein base64-kodierter privater Schlüssel im PEM-Format Sie gibt ein Zertifikatsobjekt mit den folgenden Attributen zurück: - `Cert`: Ein PEM-kodiertes Zertifikat - `Key`: Ein PEM-kodierter privater Schlüssel Beispiel: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Beachten Sie, dass das zurückgegebene Objekt an die Funktion `genSignedCert` übergeben werden kann, um ein Zertifikat mit dieser CA zu signieren. ### genCA Die Funktion `genCA` erzeugt ein neues, selbstsigniertes x509-Zertifizierungsstellenzertifikat. Sie nimmt die folgenden Parameter: - Common Name (cn) des Subjekts - Gültigkeitsdauer des Zertifikats in Tagen Sie gibt ein Objekt mit den folgenden Attributen zurück: - `Cert`: Ein PEM-kodiertes Zertifikat - `Key`: Ein PEM-kodierter privater Schlüssel Beispiel: ``` $ca := genCA "foo-ca" 365 ``` Beachten Sie, dass das zurückgegebene Objekt an die Funktion `genSignedCert` übergeben werden kann, um ein Zertifikat mit dieser CA zu signieren. ### genSelfSignedCert Die Funktion `genSelfSignedCert` erzeugt ein neues, selbstsigniertes x509-Zertifikat. Sie nimmt die folgenden Parameter: - Common Name (cn) des Subjekts - Optionale Liste von IPs; kann nil sein - Optionale Liste alternativer DNS-Namen; kann nil sein - Gültigkeitsdauer des Zertifikats in Tagen Sie gibt ein Objekt mit den folgenden Attributen zurück: - `Cert`: Ein PEM-kodiertes Zertifikat - `Key`: Ein PEM-kodierter privater Schlüssel Beispiel: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert Die Funktion `genSignedCert` erzeugt ein neues x509-Zertifikat, das von der angegebenen CA signiert ist. Sie nimmt die folgenden Parameter: - Common Name (cn) des Subjekts - Optionale Liste von IPs; kann nil sein - Optionale Liste alternativer DNS-Namen; kann nil sein - Gültigkeitsdauer des Zertifikats in Tagen - CA (siehe `genCA`) Beispiel: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES Die Funktion `encryptAES` verschlüsselt Text mit AES-256 CBC und gibt einen base64-kodierten String zurück. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES Die Funktion `decryptAES` empfängt einen base64-String, der mit dem AES-256-CBC-Algorithmus kodiert wurde, und gibt den entschlüsselten Text zurück. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Datumsfunktionen Helm enthält die folgenden Datumsfunktionen, die Sie in Templates verwenden können: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) und [unixEpoch](#unixepoch). ### now Das aktuelle Datum/Uhrzeit. Verwenden Sie dies in Verbindung mit anderen Datumsfunktionen. ### ago Die Funktion `ago` gibt die Dauer seit einer Zeit zurück. Jetzt in Sekundenauflösung. ``` ago .CreatedAt ``` gibt im `time.Duration` String()-Format zurück ``` 2h34m7s ``` ### date Die Funktion `date` formatiert ein Datum. Formatiert das Datum als JAHR-MONAT-TAG: ``` now | date "2006-01-02" ``` Die Datumsformatierung in Go ist [etwas anders](https://pauladamsmith.com/blog/2011/05/go_time.html). Kurz gesagt, nehmen Sie dies als Basisdatum: ``` Mon Jan 2 15:04:05 MST 2006 ``` Schreiben Sie es in dem Format, das Sie möchten. Oben ist `2006-01-02` dasselbe Datum, aber in dem gewünschten Format. ### dateInZone Wie `date`, aber mit einer Zeitzone. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formatiert eine gegebene Anzahl von Sekunden als `time.Duration`. Dies gibt 1m35s zurück ``` duration "95" ``` ### durationRound Rundet eine gegebene Dauer auf die signifikanteste Einheit. Strings und `time.Duration` werden als Dauer geparst, während eine `time.Time` als die Dauer seit diesem Zeitpunkt berechnet wird. Dies gibt 2h zurück ``` durationRound "2h10m5s" ``` Dies gibt 3mo zurück ``` durationRound "2400h10m5s" ``` ### unixEpoch Gibt die Sekunden seit der Unix-Epoche für eine `time.Time` zurück. ``` now | unixEpoch ``` ### dateModify, mustDateModify Die Funktion `dateModify` nimmt eine Modifikation und ein Datum und gibt den Zeitstempel zurück. Subtrahiert eine Stunde und dreißig Minuten von der aktuellen Zeit: ``` now | dateModify "-1.5h" ``` Wenn das Modifikationsformat falsch ist, gibt `dateModify` das Datum unverändert zurück. `mustDateModify` gibt andernfalls einen Fehler zurück. ### htmlDate Die Funktion `htmlDate` formatiert ein Datum zum Einfügen in ein HTML-Datumsauswahl-Eingabefeld. ``` now | htmlDate ``` ### htmlDateInZone Wie htmlDate, aber mit einer Zeitzone. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` konvertiert einen String in ein Datum. Das erste Argument ist das Datumslayout und das zweite der Datums-String. Wenn der String nicht konvertiert werden kann, wird der Nullwert zurückgegeben. `mustToDate` gibt einen Fehler zurück, falls der String nicht konvertiert werden kann. Dies ist nützlich, wenn Sie einen Datums-String in ein anderes Format konvertieren möchten (mit Pipe). Das folgende Beispiel konvertiert "2017-12-31" in "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Dictionaries und Dict-Funktionen Helm bietet einen Schlüssel/Wert-Speichertyp namens `dict` (kurz für "Dictionary", wie in Python). Ein `dict` ist ein _ungeordneter_ Typ. Der Schlüssel eines Dictionary **muss ein String sein**. Der Wert kann jedoch jeden Typ haben, einschließlich eines anderen `dict` oder einer `list`. Im Gegensatz zu `list`s sind `dict`s nicht unveränderlich. Die Funktionen `set` und `unset` ändern den Inhalt eines Dictionary. Helm bietet die folgenden Funktionen zur Arbeit mit Dicts: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) und [values](#values). ### dict Das Erstellen von Dictionaries erfolgt durch Aufrufen der Funktion `dict` und Übergeben einer Liste von Paaren. Das Folgende erstellt ein Dictionary mit drei Elementen: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Holt bei gegebenem Map und Schlüssel den Wert aus dem Map. ``` get $myDict "name1" ``` Das obige gibt `"value1"` zurück Beachten Sie, dass diese Operation einfach `""` zurückgibt, wenn der Schlüssel nicht gefunden wird. Es wird kein Fehler erzeugt. ### set Verwenden Sie `set`, um ein neues Schlüssel/Wert-Paar zu einem Dictionary hinzuzufügen. ``` $_ := set $myDict "name4" "value4" ``` Beachten Sie, dass `set` _das Dictionary zurückgibt_ (eine Anforderung von Go-Template-Funktionen), daher müssen Sie den Wert möglicherweise wie oben mit der `$_`-Zuweisung auffangen. ### unset Löscht bei gegebenem Map und Schlüssel den Schlüssel aus dem Map. ``` $_ := unset $myDict "name4" ``` Wie bei `set` gibt dies das Dictionary zurück. Beachten Sie, dass diese Operation einfach zurückkehrt, wenn der Schlüssel nicht gefunden wird. Es wird kein Fehler erzeugt. ### hasKey Die Funktion `hasKey` gibt `true` zurück, wenn das gegebene Dict den gegebenen Schlüssel enthält. ``` hasKey $myDict "name1" ``` Wenn der Schlüssel nicht gefunden wird, gibt dies `false` zurück. ### pluck Die Funktion `pluck` ermöglicht es, einen Schlüssel und mehrere Maps anzugeben und eine Liste aller Übereinstimmungen zu erhalten: ``` pluck "name1" $myDict $myOtherDict ``` Das obige gibt eine `list` zurück, die jeden gefundenen Wert enthält (`[value1 otherValue1]`). Wenn der gegebene Schlüssel _nicht gefunden_ wird in einem Map, hat dieses Map kein Element in der Liste (und die Länge der zurückgegebenen Liste ist kleiner als die Anzahl der Dicts im Aufruf von `pluck`). Wenn der Schlüssel _gefunden_ wird, aber der Wert ein leerer Wert ist, wird dieser Wert eingefügt. Ein gängiges Idiom in Helm-Templates ist die Verwendung von `pluck... | first`, um den ersten passenden Schlüssel aus einer Sammlung von Dictionaries zu erhalten. ### dig Die Funktion `dig` durchläuft eine verschachtelte Menge von Dicts und wählt Schlüssel aus einer Werteliste aus. Sie gibt einen Standardwert zurück, wenn einer der Schlüssel im zugehörigen Dict nicht gefunden wird. ``` dig "user" "role" "humanName" "guest" $dict ``` Bei einem Dict mit folgender Struktur ``` { user: { role: { humanName: "curator" } } } ``` würde das obige `"curator"` zurückgeben. Wenn das Dict nicht einmal ein `user`-Feld hätte, wäre das Ergebnis `"guest"`. Dig kann sehr nützlich sein in Fällen, in denen Sie Schutzklauseln vermeiden möchten, besonders da das `and` des Go-Template-Pakets nicht kurzschließt. Zum Beispiel wird `and a.maybeNil a.maybeNil.iNeedThis` immer `a.maybeNil.iNeedThis` auswerten und einen Panic auslösen, wenn `a` kein `maybeNil`-Feld hat.) `dig` akzeptiert sein Dict-Argument zuletzt, um Pipelining zu unterstützen. Zum Beispiel: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Führt zwei oder mehr Dictionaries zu einem zusammen, wobei das Ziel-Dictionary Vorrang hat: Gegeben: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` ergibt sich: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` Dies ist eine tiefe Merge-Operation, aber keine tiefe Kopier-Operation. Verschachtelte Objekte, die zusammengeführt werden, sind dieselbe Instanz in beiden Dicts. Wenn Sie eine tiefe Kopie zusammen mit dem Merge möchten, verwenden Sie die Funktion `deepCopy` zusammen mit dem Merging. Zum Beispiel: ``` deepCopy $source | merge $dest ``` `mustMerge` gibt einen Fehler zurück, falls das Merge nicht erfolgreich ist. ### mergeOverwrite, mustMergeOverwrite Führt zwei oder mehr Dictionaries zu einem zusammen, wobei der Vorrang von **rechts nach links** gilt, also Werte im Ziel-Dictionary überschrieben werden: Gegeben: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` ergibt sich: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` Dies ist eine tiefe Merge-Operation, aber keine tiefe Kopier-Operation. Verschachtelte Objekte, die zusammengeführt werden, sind dieselbe Instanz in beiden Dicts. Wenn Sie eine tiefe Kopie zusammen mit dem Merge möchten, verwenden Sie die Funktion `deepCopy` zusammen mit dem Merging. Zum Beispiel: ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` gibt einen Fehler zurück, falls das Merge nicht erfolgreich ist. ### keys Die Funktion `keys` gibt eine `list` aller Schlüssel in einem oder mehreren `dict`-Typen zurück. Da ein Dictionary _ungeordnet_ ist, sind die Schlüssel nicht in einer vorhersagbaren Reihenfolge. Sie können mit `sortAlpha` sortiert werden. ``` keys $myDict | sortAlpha ``` Bei der Angabe mehrerer Dictionaries werden die Schlüssel verkettet. Verwenden Sie die Funktion `uniq` zusammen mit `sortAlpha`, um eine eindeutige, sortierte Liste von Schlüsseln zu erhalten. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick Die Funktion `pick` wählt nur die angegebenen Schlüssel aus einem Dictionary aus und erstellt ein neues `dict`. ``` $new := pick $myDict "name1" "name2" ``` Das obige gibt `{name1: value1, name2: value2}` zurück ### omit Die Funktion `omit` ähnelt `pick`, gibt aber ein neues `dict` mit allen Schlüsseln zurück, die _nicht_ mit den angegebenen Schlüsseln übereinstimmen. ``` $new := omit $myDict "name1" "name3" ``` Das obige gibt `{name2: value2}` zurück ### values Die Funktion `values` ähnelt `keys`, gibt aber eine neue `list` mit allen Werten des Quell-`dict` zurück (nur ein Dictionary wird unterstützt). ``` $vals := values $myDict ``` Das obige gibt `list["value1", "value2", "value 3"]` zurück. Beachten Sie, dass die Funktion `values` keine Garantien für die Reihenfolge des Ergebnisses gibt; wenn Ihnen das wichtig ist, verwenden Sie `sortAlpha`. ### deepCopy, mustDeepCopy Die Funktionen `deepCopy` und `mustDeepCopy` nehmen einen Wert und erstellen eine tiefe Kopie des Wertes. Dies umfasst Dicts und andere Strukturen. `deepCopy` löst einen Panic aus, wenn ein Problem auftritt, während `mustDeepCopy` einen Fehler an das Template-System zurückgibt, wenn ein Fehler auftritt. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Eine Anmerkung zu Dict-Interna Ein `dict` ist in Go als `map[string]interface{}` implementiert. Go-Entwickler können `map[string]interface{}`-Werte in den Kontext übergeben, um sie für Templates als `dict`s verfügbar zu machen. ## Encoding-Funktionen Helm hat die folgenden Kodierungs- und Dekodierungsfunktionen: - `b64enc`/`b64dec`: Kodieren oder Dekodieren mit Base64 - `b32enc`/`b32dec`: Kodieren oder Dekodieren mit Base32 ## Listen und List-Funktionen Helm bietet einen einfachen `list`-Typ, der beliebige sequentielle Datenlisten enthalten kann. Dies ähnelt Arrays oder Slices, aber Listen sind so konzipiert, dass sie als unveränderliche Datentypen verwendet werden. Erstellen Sie eine Liste von Integers: ``` $myList := list 1 2 3 4 5 ``` Das obige erstellt eine Liste von `[1 2 3 4 5]`. Helm bietet die folgenden List-Funktionen: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) und [without (mustWithout)](#without-mustwithout). ### first, mustFirst Um das erste Element einer Liste zu erhalten, verwenden Sie `first`. `first $myList` gibt `1` zurück `first` löst einen Panic aus, wenn ein Problem auftritt, während `mustFirst` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### rest, mustRest Um den Rest der Liste zu erhalten (alles außer dem ersten Element), verwenden Sie `rest`. `rest $myList` gibt `[2 3 4 5]` zurück `rest` löst einen Panic aus, wenn ein Problem auftritt, während `mustRest` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### last, mustLast Um das letzte Element einer Liste zu erhalten, verwenden Sie `last`: `last $myList` gibt `5` zurück. Dies entspricht ungefähr dem Umkehren einer Liste und dem anschließenden Aufrufen von `first`. ### initial, mustInitial Dies ergänzt `last`, indem alle Elemente _außer_ dem letzten zurückgegeben werden. `initial $myList` gibt `[1 2 3 4]` zurück. `initial` löst einen Panic aus, wenn ein Problem auftritt, während `mustInitial` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### append, mustAppend Fügt ein neues Element zu einer bestehenden Liste hinzu und erstellt eine neue Liste. ``` $new = append $myList 6 ``` Das obige würde `$new` auf `[1 2 3 4 5 6]` setzen. `$myList` bleibt unverändert. `append` löst einen Panic aus, wenn ein Problem auftritt, während `mustAppend` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### prepend, mustPrepend Fügt ein Element am Anfang einer Liste ein und erstellt eine neue Liste. ``` prepend $myList 0 ``` Das obige würde `[0 1 2 3 4 5]` erzeugen. `$myList` bleibt unverändert. `prepend` löst einen Panic aus, wenn ein Problem auftritt, während `mustPrepend` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### concat Verkettet eine beliebige Anzahl von Listen zu einer. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` Das obige würde `[1 2 3 4 5 6 7 8]` erzeugen. `$myList` bleibt unverändert. ### reverse, mustReverse Erzeugt eine neue Liste mit den umgekehrten Elementen der gegebenen Liste. ``` reverse $myList ``` Das obige würde die Liste `[5 4 3 2 1]` erzeugen. `reverse` löst einen Panic aus, wenn ein Problem auftritt, während `mustReverse` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### uniq, mustUniq Erzeugt eine Liste, aus der alle Duplikate entfernt wurden. ``` list 1 1 1 2 | uniq ``` Das obige würde `[1 2]` erzeugen `uniq` löst einen Panic aus, wenn ein Problem auftritt, während `mustUniq` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### without, mustWithout Die Funktion `without` filtert Elemente aus einer Liste heraus. ``` without $myList 3 ``` Das obige würde `[1 2 4 5]` erzeugen `without` kann mehr als einen Filter haben: ``` without $myList 1 3 5 ``` Das würde `[2 4]` erzeugen `without` löst einen Panic aus, wenn ein Problem auftritt, während `mustWithout` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### has, mustHas Prüft, ob eine Liste ein bestimmtes Element enthält. ``` has 4 $myList ``` Das obige würde `true` zurückgeben, während `has "hello" $myList` `false` zurückgeben würde. `has` löst einen Panic aus, wenn ein Problem auftritt, während `mustHas` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### compact, mustCompact Akzeptiert eine Liste und entfernt Einträge mit leeren Werten. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` gibt eine neue Liste zurück, aus der das leere (d.h. "") Element entfernt wurde. `compact` löst einen Panic aus, wenn ein Problem auftritt, und `mustCompact` gibt einen Fehler an die Template-Engine zurück, wenn ein Problem auftritt. ### index Um das n-te Element einer Liste zu erhalten, verwenden Sie `index list [n]`. Um in mehrdimensionale Listen zu indizieren, verwenden Sie `index list [n] [m] ...` - `index $myList 0` gibt `1` zurück. Es entspricht `myList[0]` - `index $myList 0 1` würde `myList[0][1]` entsprechen ### slice, mustSlice Um Teilelemente einer Liste zu erhalten, verwenden Sie `slice list [n] [m]`. Es entspricht `list[n:m]`. - `slice $myList` gibt `[1 2 3 4 5]` zurück. Es entspricht `myList[:]`. - `slice $myList 3` gibt `[4 5]` zurück. Es entspricht `myList[3:]`. - `slice $myList 1 3` gibt `[2 3]` zurück. Es entspricht `myList[1:3]`. - `slice $myList 0 3` gibt `[1 2 3]` zurück. Es entspricht `myList[:3]`. `slice` löst einen Panic aus, wenn ein Problem auftritt, während `mustSlice` einen Fehler an die Template-Engine zurückgibt, wenn ein Problem auftritt. ### until Die Funktion `until` erstellt einen Bereich von Integers. ``` until 5 ``` Das obige erzeugt die Liste `[0, 1, 2, 3, 4]`. Dies ist nützlich für Schleifen mit `range $i, $e := until 5`. ### untilStep Wie `until` erzeugt `untilStep` eine Liste von Zähl-Integers. Aber es erlaubt die Definition eines Starts, Stopps und Schritts: ``` untilStep 3 6 2 ``` Das obige erzeugt `[3 5]`, indem es bei 3 beginnt und 2 addiert, bis es gleich oder größer als 6 ist. Dies ähnelt Pythons `range`-Funktion. ### seq Funktioniert wie der Bash-Befehl `seq`. * 1 Parameter (end) - erzeugt alle Zähl-Integers zwischen 1 und `end` einschließlich. * 2 Parameter (start, end) - erzeugt alle Zähl-Integers zwischen `start` und `end` einschließlich, inkrementierend oder dekrementierend um 1. * 3 Parameter (start, step, end) - erzeugt alle Zähl-Integers zwischen `start` und `end` einschließlich, inkrementierend oder dekrementierend um `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Um eine Liste in Chunks einer gegebenen Größe zu teilen, verwenden Sie `chunk size list`. Dies ist nützlich für Paginierung. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` Dies erzeugt eine Liste von Listen `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Mathematische Funktionen Alle mathematischen Funktionen arbeiten mit `int64`-Werten, sofern nicht anders angegeben. Die folgenden mathematischen Funktionen sind verfügbar: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) und [sub](#sub). ### add Summiert Zahlen mit `add`. Akzeptiert zwei oder mehr Eingaben. ``` add 1 2 3 ``` ### add1 Um um 1 zu inkrementieren, verwenden Sie `add1`. ### sub Zum Subtrahieren verwenden Sie `sub`. ### div Führt Integer-Division mit `div` durch. ### mod Modulo mit `mod`. ### mul Multipliziert mit `mul`. Akzeptiert zwei oder mehr Eingaben. ``` mul 1 2 3 ``` ### max Gibt den größten aus einer Reihe von Integers zurück. Dies gibt `3` zurück: ``` max 1 2 3 ``` ### min Gibt den kleinsten aus einer Reihe von Integers zurück. `min 1 2 3` gibt `1` zurück. ### len Gibt die Länge des Arguments als Integer zurück. ``` len .Arg ``` ## Float-Mathematik-Funktionen Alle mathematischen Funktionen arbeiten mit `float64`-Werten. ### addf Summiert Zahlen mit `addf` Dies gibt `5.5` zurück: ``` addf 1.5 2 2 ``` ### add1f Um um 1 zu inkrementieren, verwenden Sie `add1f` ### subf Zum Subtrahieren verwenden Sie `subf` Dies entspricht `7.5 - 2 - 3` und gibt `2.5` zurück: ``` subf 7.5 2 3 ``` ### divf Führt Integer-Division mit `divf` durch Dies entspricht `10 / 2 / 4` und gibt `1.25` zurück: ``` divf 10 2 4 ``` ### mulf Multipliziert mit `mulf` Dies gibt `6` zurück: ``` mulf 1.5 2 2 ``` ### maxf Gibt den größten aus einer Reihe von Floats zurück: Dies gibt `3` zurück: ``` maxf 1 2.5 3 ``` ### minf Gibt den kleinsten aus einer Reihe von Floats zurück. Dies gibt `1.5` zurück: ``` minf 1.5 2 3 ``` ### floor Gibt den größten Float-Wert zurück, der kleiner oder gleich dem Eingabewert ist. `floor 123.9999` gibt `123.0` zurück. ### ceil Gibt den größten Float-Wert zurück, der größer oder gleich dem Eingabewert ist. `ceil 123.001` gibt `124.0` zurück. ### round Gibt einen Float-Wert zurück, bei dem der Rest auf die angegebene Anzahl von Nachkommastellen gerundet ist. `round 123.555555 3` gibt `123.556` zurück. ## Netzwerk-Funktionen Helm hat eine einzige Netzwerk-Funktion, `getHostByName`. Die Funktion `getHostByName` empfängt einen Domainnamen und gibt die IP-Adresse zurück. `getHostByName "www.google.com"` würde die entsprechende IP-Adresse von `www.google.com` zurückgeben. Diese Funktion erfordert, dass die Option `--enable-dns` an der Helm-Kommandozeile übergeben wird. ## Dateipfad-Funktionen Obwohl Helm-Template-Funktionen keinen Zugriff auf das Dateisystem gewähren, bieten sie Funktionen für die Arbeit mit Strings, die Dateipfad-Konventionen folgen. Diese umfassen [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) und [isAbs](#isabs). ### base Gibt das letzte Element eines Pfades zurück. ``` base "foo/bar/baz" ``` Das obige gibt "baz" aus. ### dir Gibt das Verzeichnis zurück und entfernt den letzten Teil des Pfades. Also gibt `dir "foo/bar/baz"` `foo/bar` zurück. ### clean Bereinigt einen Pfad. ``` clean "foo/bar/../baz" ``` Das obige löst das `..` auf und gibt `foo/baz` zurück. ### ext Gibt die Dateierweiterung zurück. ``` ext "foo.bar" ``` Das obige gibt `.bar` zurück. ### isAbs Um zu prüfen, ob ein Dateipfad absolut ist, verwenden Sie `isAbs`. ## Reflection-Funktionen Helm bietet grundlegende Reflection-Tools. Diese helfen fortgeschrittenen Template-Entwicklern, die zugrunde liegenden Go-Typinformationen für einen bestimmten Wert zu verstehen. Helm ist in Go geschrieben und streng typisiert. Das Typsystem gilt auch innerhalb von Templates. Go hat mehrere primitive _Arten_, wie `string`, `slice`, `int64` und `bool`. Go hat ein offenes _Typ_-System, das es Entwicklern ermöglicht, eigene Typen zu erstellen. Helm bietet eine Reihe von Funktionen für jede über [Kind-Funktionen](#kind-funktionen) und [Type-Funktionen](#type-funktionen). Eine [deepEqual](#deepequal)-Funktion wird ebenfalls bereitgestellt, um zwei Werte zu vergleichen. ### Kind-Funktionen Es gibt zwei Kind-Funktionen: `kindOf` gibt die Art eines Objekts zurück. ``` kindOf "hello" ``` Das obige würde `string` zurückgeben. Für einfache Tests (wie in `if`-Blöcken) können Sie mit der Funktion `kindIs` prüfen, ob ein Wert eine bestimmte Art hat: ``` kindIs "int" 123 ``` Das obige gibt `true` zurück. ### Type-Funktionen Typen sind etwas schwieriger zu handhaben, daher gibt es drei verschiedene Funktionen: - `typeOf` gibt den zugrunde liegenden Typ eines Wertes zurück: `typeOf $foo` - `typeIs` ist wie `kindIs`, aber für Typen: `typeIs "*io.Buffer" $myVal` - `typeIsLike` funktioniert wie `typeIs`, dereferenziert aber auch Pointer **Hinweis:** Keine dieser Funktionen kann testen, ob etwas ein bestimmtes Interface implementiert, da dies erfordern würde, das Interface vorab zu kompilieren. ### deepEqual `deepEqual` gibt true zurück, wenn zwei Werte ["tief gleich"](https://golang.org/pkg/reflect/#DeepEqual) sind. Funktioniert auch für nicht-primitive Typen (im Gegensatz zum eingebauten `eq`). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` Das obige gibt `true` zurück. ## Semantische Versionsfunktionen Einige Versionsschemata sind leicht parsebar und vergleichbar. Helm bietet Funktionen für die Arbeit mit [SemVer 2](http://semver.org)-Versionen. Diese umfassen [semver](#semver) und [semverCompare](#semvercompare). Im Folgenden finden Sie auch Details zur Verwendung von Bereichen für Vergleiche. ### semver Die Funktion `semver` parst einen String in eine Semantische Version: ``` $version := semver "1.2.3-alpha.1+123" ``` _Wenn der Parser fehlschlägt, wird die Template-Ausführung mit einem Fehler angehalten._ An diesem Punkt ist `$version` ein Pointer auf ein `Version`-Objekt mit den folgenden Eigenschaften: - `$version.Major`: Die Hauptversionsnummer (`1` oben) - `$version.Minor`: Die Nebenversionsnummer (`2` oben) - `$version.Patch`: Die Patch-Nummer (`3` oben) - `$version.Prerelease`: Das Prerelease (`alpha.1` oben) - `$version.Metadata`: Die Build-Metadaten (`123` oben) - `$version.Original`: Die Originalversion als String Zusätzlich können Sie eine `Version` mit einer anderen `Version` mithilfe der `Compare`-Funktion vergleichen: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` Das obige gibt `-1` zurück. Die Rückgabewerte sind: - `-1` wenn die gegebene Semver größer ist als die Semver, deren `Compare`-Methode aufgerufen wurde - `1` wenn die Version, deren `Compare`-Funktion aufgerufen wurde, größer ist. - `0` wenn sie dieselbe Version sind (Beachten Sie, dass in SemVer das `Metadata`-Feld bei Versionsvergleichen nicht verglichen wird.) ### semverCompare Eine robustere Vergleichsfunktion wird als `semverCompare` bereitgestellt. Diese Version unterstützt Versionsbereiche: - `semverCompare "1.2.3" "1.2.3"` prüft auf eine exakte Übereinstimmung - `semverCompare "~1.2.0" "1.2.3"` prüft, ob die Haupt- und Nebenversionen übereinstimmen und ob die Patch-Nummer der zweiten Version _größer oder gleich_ dem ersten Parameter ist. Die SemVer-Funktionen verwenden die [Masterminds semver-Bibliothek](https://github.com/Masterminds/semver) von den Machern von Sprig. ### Einfache Vergleiche Es gibt zwei Elemente bei den Vergleichen. Erstens ist ein Vergleichs-String eine Liste von durch Leerzeichen oder Kommas getrennten AND-Vergleichen. Diese werden dann durch || (OR)-Vergleiche getrennt. Zum Beispiel sucht `">= 1.2 < 3.0.0 || >= 4.2.3"` nach einem Vergleich, der größer oder gleich 1.2 und kleiner als 3.0.0 ist oder größer oder gleich 4.2.3 ist. Die grundlegenden Vergleiche sind: - `=`: gleich (Alias für keinen Operator) - `!=`: ungleich - `>`: größer als - `<`: kleiner als - `>=`: größer oder gleich - `<=`: kleiner oder gleich ### Arbeiten mit Prerelease-Versionen Prereleases sind, für diejenigen, die damit nicht vertraut sind, für Software-Releases vor stabilen oder allgemein verfügbaren Releases gedacht. Beispiele für Prereleases sind Entwicklungs-, Alpha-, Beta- und Release-Candidate-Releases. Ein Prerelease kann eine Version wie `1.2.3-beta.1` sein, während der stabile Release `1.2.3` wäre. In der Rangfolge kommen Prereleases vor ihren zugehörigen Releases. In diesem Beispiel `1.2.3-beta.1 < 1.2.3`. Gemäß der Semantic-Version-Spezifikation sind Prereleases möglicherweise nicht API-kompatibel mit ihrem Release-Gegenstück. Es heißt: > Eine Prerelease-Version zeigt an, dass die Version instabil ist und > möglicherweise nicht die beabsichtigten Kompatibilitätsanforderungen erfüllt, > wie sie durch ihre zugehörige normale Version gekennzeichnet sind. SemVer-Vergleiche mit Constraints ohne Prerelease-Vergleicher überspringen Prerelease-Versionen. Zum Beispiel überspringt `>=1.2.3` Prereleases beim Durchsuchen einer Liste von Releases, während `>=1.2.3-0` Prereleases auswertet und findet. Der Grund für die `0` als Prerelease-Version im Beispielvergleich ist, dass Prereleases nur ASCII-alphanumerische Zeichen und Bindestriche (zusammen mit `.`-Trennzeichen) enthalten können, gemäß Spezifikation. Die Sortierung erfolgt in ASCII-Sortierreihenfolge, ebenfalls gemäß Spezifikation. Das niedrigste Zeichen ist eine `0` in der ASCII-Sortierreihenfolge (siehe eine [ASCII-Tabelle](http://www.asciitable.com/)) Das Verständnis der ASCII-Sortierreihenfolge ist wichtig, da A-Z vor a-z kommt. Das bedeutet, `>=1.2.3-BETA` gibt `1.2.3-alpha` zurück. Was Sie von Groß-/Kleinschreibungsempfindlichkeit erwarten könnten, gilt hier nicht. Dies liegt an der ASCII-Sortierreihenfolge, die die Spezifikation vorgibt. ### Bindestrich-Bereichsvergleiche Es gibt mehrere Methoden zur Handhabung von Bereichen, und die erste sind Bindestrich-Bereiche. Diese sehen so aus: - `1.2 - 1.4.5` was äquivalent ist zu `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` was äquivalent ist zu `>= 2.3.4 <= 4.5` ### Wildcards in Vergleichen Die Zeichen `x`, `X` und `*` können als Wildcard-Zeichen verwendet werden. Dies funktioniert für alle Vergleichsoperatoren. Bei Verwendung mit dem `=`-Operator fällt es auf den Patch-Level-Vergleich zurück (siehe Tilde unten). Zum Beispiel: - `1.2.x` ist äquivalent zu `>= 1.2.0, < 1.3.0` - `>= 1.2.x` ist äquivalent zu `>= 1.2.0` - `<= 2.x` ist äquivalent zu `< 3` - `*` ist äquivalent zu `>= 0.0.0` ### Tilde-Bereichsvergleiche (Patch) Der Tilde (`~`)-Vergleichsoperator ist für Patch-Level-Bereiche, wenn eine Nebenversion angegeben ist, und für Major-Level-Änderungen, wenn die Nebenversionsnummer fehlt. Zum Beispiel: - `~1.2.3` ist äquivalent zu `>= 1.2.3, < 1.3.0` - `~1` ist äquivalent zu `>= 1, < 2` - `~2.3` ist äquivalent zu `>= 2.3, < 2.4` - `~1.2.x` ist äquivalent zu `>= 1.2.0, < 1.3.0` - `~1.x` ist äquivalent zu `>= 1, < 2` ### Caret-Bereichsvergleiche (Major) Der Caret (`^`)-Vergleichsoperator ist für Major-Level-Änderungen, sobald ein stabiles (1.0.0) Release erfolgt ist. Vor einem 1.0.0-Release fungiert die Nebenversion als API-Stabilitätsstufe. Dies ist nützlich bei Vergleichen von API-Versionen, da eine Major-Änderung API-brechend ist. Zum Beispiel: - `^1.2.3` ist äquivalent zu `>= 1.2.3, < 2.0.0` - `^1.2.x` ist äquivalent zu `>= 1.2.0, < 2.0.0` - `^2.3` ist äquivalent zu `>= 2.3, < 3` - `^2.x` ist äquivalent zu `>= 2.0.0, < 3` - `^0.2.3` ist äquivalent zu `>=0.2.3 <0.3.0` - `^0.2` ist äquivalent zu `>=0.2.0 <0.3.0` - `^0.0.3` ist äquivalent zu `>=0.0.3 <0.0.4` - `^0.0` ist äquivalent zu `>=0.0.0 <0.1.0` - `^0` ist äquivalent zu `>=0.0.0 <1.0.0` ## URL-Funktionen Helm enthält die Funktionen [urlParse](#urlparse), [urlJoin](#urljoin) und [urlquery](#urlquery), die Ihnen die Arbeit mit URL-Teilen ermöglichen. ### urlParse Parst einen String als URL und erzeugt ein Dict mit URL-Teilen ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` Das obige gibt ein Dict zurück, das das URL-Objekt enthält: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Dies wird mit den URL-Paketen aus der Go-Standardbibliothek implementiert. Für weitere Informationen siehe https://golang.org/pkg/net/url/#URL ### urlJoin Verbindet ein Map (erzeugt von `urlParse`) zu einem URL-String ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` Das obige gibt den folgenden String zurück: ``` http://host:80/path?query#fragment ``` ### urlquery Gibt die escaped Version des übergebenen Werts zurück, sodass er zum Einbetten in den Query-Teil einer URL geeignet ist. ``` $var := urlquery "string for query" ``` ## UUID-Funktionen Helm kann UUID v4 universell eindeutige Identifikatoren generieren. ``` uuidv4 ``` Das obige gibt eine neue UUID vom Typ v4 (zufällig generiert) zurück. ## Kubernetes- und Chart-Funktionen Helm enthält Funktionen für die Arbeit mit Kubernetes, darunter [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#file-funktionen) und [lookup](#lookup). ### lookup `lookup` wird verwendet, um Ressourcen in einem laufenden Cluster nachzuschlagen. Bei Verwendung mit dem Befehl `helm template` gibt es immer eine leere Antwort zurück. Weitere Details finden Sie in der [Dokumentation zur lookup-Funktion](./functions_and_pipelines.md#verwendung-der-lookup-funktion). ### .Capabilities.APIVersions.Has Gibt zurück, ob eine API-Version oder Ressource in einem Cluster verfügbar ist. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Weitere Informationen finden Sie in der [Dokumentation der eingebauten Objekte](./builtin_objects.md). ### File-Funktionen Es gibt mehrere Funktionen, die Ihnen den Zugriff auf nicht-spezielle Dateien innerhalb eines Charts ermöglichen. Zum Beispiel zum Zugriff auf Anwendungskonfigurationsdateien. Diese sind dokumentiert unter [Zugriff auf Dateien in Templates](./accessing_files.md). _Hinweis: Die Dokumentation für viele dieser Funktionen stammt von [Sprig](https://github.com/Masterminds/sprig). Sprig ist eine Template-Funktionsbibliothek, die für Go-Anwendungen verfügbar ist._ ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Template-Funktionen und Pipelines description: Verwendung von Funktionen in Templates. sidebar_position: 5 --- Bisher haben wir gesehen, wie man Informationen in ein Template einfügt. Aber diese Informationen werden unverändert in das Template eingefügt. Manchmal möchten wir die übergebenen Daten so transformieren, dass sie für uns nützlicher werden. Beginnen wir mit einer Best Practice: Wenn wir Strings aus dem `.Values`-Objekt in das Template einfügen, sollten wir diese Strings in Anführungszeichen setzen. Dazu rufen wir die `quote`-Funktion in der Template-Anweisung auf: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Template-Funktionen folgen der Syntax `funktionsName arg1 arg2...`. Im obigen Beispiel ruft `quote .Values.favorite.drink` die `quote`-Funktion auf und übergibt ihr ein einzelnes Argument. Helm verfügt über mehr als 60 Funktionen. Einige davon sind durch die [Go-Template-Sprache](https://godoc.org/text/template) selbst definiert. Die meisten anderen stammen aus der [Sprig Template-Bibliothek](https://masterminds.github.io/sprig/). Wir werden viele davon kennenlernen, während wir die Beispiele durcharbeiten. > Obwohl wir von der "Helm-Template-Sprache" sprechen, als wäre sie > Helm-spezifisch, ist sie tatsächlich eine Kombination aus der > Go-Template-Sprache, einigen zusätzlichen Funktionen und verschiedenen > Wrappern, um bestimmte Objekte für die Templates verfügbar zu machen. Viele > Ressourcen über Go-Templates können beim Erlernen des Templating hilfreich > sein. ## Pipelines Eine der leistungsstarken Funktionen der Template-Sprache ist ihr Konzept der _Pipelines_. Basierend auf einem Konzept aus UNIX sind Pipelines ein Werkzeug, um eine Reihe von Template-Befehlen zu verketten und so eine Folge von Transformationen kompakt auszudrücken. Mit anderen Worten: Pipelines sind eine effiziente Methode, um mehrere Dinge nacheinander zu erledigen. Schreiben wir das obige Beispiel mit einer Pipeline um. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` In diesem Beispiel haben wir, anstatt `quote ARGUMENT` aufzurufen, die Reihenfolge umgekehrt. Wir haben das Argument mit einer Pipeline (`|`) an die Funktion "gesendet": `.Values.favorite.drink | quote`. Mit Pipelines können wir mehrere Funktionen verketten: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Die Umkehrung der Reihenfolge ist eine gängige Praxis in Templates. Sie werden > `.val | quote` häufiger sehen als `quote .val`. Beide Varianten sind in > Ordnung. Wenn dieses Template ausgewertet wird, ergibt sich folgendes: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Beachten Sie, dass unser ursprüngliches `pizza` jetzt zu `"PIZZA"` transformiert wurde. Wenn Argumente auf diese Weise durch eine Pipeline geleitet werden, wird das Ergebnis der ersten Auswertung (`.Values.favorite.drink`) als _letztes Argument an die Funktion_ übergeben. Wir können das Getränke-Beispiel oben anpassen, um dies mit einer Funktion zu veranschaulichen, die zwei Argumente akzeptiert: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` Die `repeat`-Funktion wiederholt den gegebenen String die angegebene Anzahl von Malen, sodass wir folgende Ausgabe erhalten: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Verwendung der `default`-Funktion Eine häufig in Templates verwendete Funktion ist die `default`-Funktion: `default STANDARDWERT GEGEBENER_WERT`. Mit dieser Funktion können Sie einen Standardwert im Template festlegen, falls der Wert nicht angegeben wird. Verwenden wir sie, um das Getränke-Beispiel anzupassen: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Wenn wir dies normal ausführen, erhalten wir unseren `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Nun entfernen wir die Einstellung für das Lieblingsgetränk aus `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Wenn wir jetzt `helm install --dry-run --debug fair-worm ./mychart` erneut ausführen, wird folgendes YAML erzeugt: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` In einem echten Chart sollten alle statischen Standardwerte in der `values.yaml` definiert sein und nicht mit dem `default`-Befehl wiederholt werden (da sie sonst redundant wären). Der `default`-Befehl ist jedoch ideal für berechnete Werte, die nicht in `values.yaml` deklariert werden können. Zum Beispiel: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` An manchen Stellen ist eine `if`-Bedingung möglicherweise besser geeignet als `default`. Diese werden wir im nächsten Abschnitt kennenlernen. Template-Funktionen und Pipelines sind eine leistungsstarke Möglichkeit, Informationen zu transformieren und dann in Ihr YAML einzufügen. Aber manchmal ist es notwendig, Template-Logik hinzuzufügen, die etwas anspruchsvoller ist als nur das Einfügen eines Strings. Im nächsten Abschnitt betrachten wir die Kontrollstrukturen, die die Template-Sprache bietet. ## Verwendung der `lookup`-Funktion Die `lookup`-Funktion kann verwendet werden, um Ressourcen in einem laufenden Cluster _nachzuschlagen_. Die Syntax der lookup-Funktion ist `lookup apiVersion, kind, namespace, name -> resource or resource list`. | Parameter | Typ | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Sowohl `name` als auch `namespace` sind optional und können als leerer String (`""`) übergeben werden. Bei Namespace-spezifischen Ressourcen müssen jedoch beide Parameter angegeben werden. Folgende Parameterkombinationen sind möglich: | Verhalten | Lookup-Funktion | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Wenn `lookup` ein Objekt zurückgibt, wird es als Dictionary zurückgegeben. Dieses Dictionary kann weiter navigiert werden, um spezifische Werte zu extrahieren. Das folgende Beispiel gibt die Annotationen zurück, die für das `mynamespace`-Objekt vorhanden sind: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Wenn `lookup` eine Liste von Objekten zurückgibt, kann über das Feld `items` auf die Objektliste zugegriffen werden: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` Wenn kein Objekt gefunden wird, wird ein leerer Wert zurückgegeben. Dies kann verwendet werden, um die Existenz eines Objekts zu prüfen. Die `lookup`-Funktion verwendet Helms bestehende Kubernetes-Verbindungs- konfiguration, um Kubernetes abzufragen. Wenn beim Aufruf des API-Servers ein Fehler zurückgegeben wird (z.B. aufgrund fehlender Berechtigungen zum Zugriff auf eine Ressource), schlägt die Template-Verarbeitung von Helm fehl. Beachten Sie, dass Helm den Kubernetes API-Server nicht während einer `helm template|install|upgrade|delete|rollback --dry-run`-Operation kontaktieren soll. Um `lookup` gegen einen laufenden Cluster zu testen, sollte stattdessen `helm template|install|upgrade|delete|rollback --dry-run=server` verwendet werden, um die Cluster-Verbindung zu ermöglichen. ## Operatoren sind Funktionen Für Templates sind die Operatoren (`eq`, `ne`, `lt`, `gt`, `and`, `or` usw.) alle als Funktionen implementiert. In Pipelines können Operationen mit Klammern (`(` und `)`) gruppiert werden. Nun können wir von Funktionen und Pipelines zur Flusskontrolle mit Bedingungen, Schleifen und Scope-Modifikatoren übergehen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Erste Schritte description: Eine Kurzanleitung zu Chart-Templates. sidebar_position: 2 --- In diesem Abschnitt der Anleitung erstellen wir ein Chart und fügen dann ein erstes Template hinzu. Das hier erstellte Chart wird im Rest der Anleitung verwendet. Um loszulegen, werfen wir einen kurzen Blick auf ein Helm Chart. ## Charts Wie in der [Charts-Anleitung](/topics/charts.md) beschrieben, sind Helm Charts folgendermaßen strukturiert: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Das Verzeichnis `templates/` ist für Template-Dateien vorgesehen. Wenn Helm ein Chart auswertet, sendet es alle Dateien im Verzeichnis `templates/` durch die Template-Rendering-Engine. Anschließend sammelt es die Ergebnisse dieser Templates und sendet sie an Kubernetes. Die Datei `values.yaml` ist ebenfalls wichtig für Templates. Diese Datei enthält die _Standardwerte_ für ein Chart. Diese Werte können von Benutzern während `helm install` oder `helm upgrade` überschrieben werden. Die Datei `Chart.yaml` enthält eine Beschreibung des Charts. Sie können aus einem Template heraus darauf zugreifen. Das Verzeichnis `charts/` _kann_ andere Charts enthalten (die wir _Subcharts_ nennen). Später in dieser Anleitung werden wir sehen, wie diese beim Template-Rendering funktionieren. ## Ein Starter-Chart Für diese Anleitung erstellen wir ein einfaches Chart namens `mychart` und dann einige Templates darin. ```console $ helm create mychart Creating mychart ``` ### Ein kurzer Blick auf `mychart/templates/` Wenn Sie sich das Verzeichnis `mychart/templates/` ansehen, werden Sie einige Dateien bemerken, die bereits vorhanden sind. - `NOTES.txt`: Der "Hilfetext" für Ihr Chart. Dieser wird Ihren Benutzern angezeigt, wenn sie `helm install` ausführen. - `deployment.yaml`: Ein einfaches Manifest zum Erstellen eines Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - `service.yaml`: Ein einfaches Manifest zum Erstellen eines [Service- Endpunkts](https://kubernetes.io/docs/concepts/services-networking/service/) für Ihr Deployment - `_helpers.tpl`: Ein Ort für Template-Hilfsfunktionen, die Sie im gesamten Chart wiederverwenden können Und was wir jetzt tun werden, ist... _sie alle löschen!_ Auf diese Weise können wir unser Tutorial von Grund auf durcharbeiten. Wir werden tatsächlich unsere eigene `NOTES.txt` und `_helpers.tpl` erstellen, während wir fortschreiten. ```console $ rm -rf mychart/templates/* ``` Wenn Sie produktionsreife Charts schreiben, kann es sehr nützlich sein, Grundversionen dieser Charts zu haben. In Ihrem täglichen Chart-Authoring werden Sie diese wahrscheinlich nicht entfernen wollen. ## Ein erstes Template Das erste Template, das wir erstellen werden, ist eine `ConfigMap`. In Kubernetes ist eine ConfigMap einfach ein Objekt zum Speichern von Konfigurationsdaten. Andere Dinge, wie Pods, können auf die Daten in einer ConfigMap zugreifen. Da ConfigMaps grundlegende Ressourcen sind, bieten sie uns einen guten Ausgangspunkt. Beginnen wir mit der Erstellung einer Datei namens `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIPP:** Template-Namen folgen keinem strengen Benennungsmuster. Wir empfehlen jedoch, die Erweiterung `.yaml` für YAML-Dateien und `.tpl` für Hilfsfunktionen zu verwenden. Die obige YAML-Datei ist eine einfache ConfigMap mit den minimal erforderlichen Feldern. Aufgrund der Tatsache, dass sich diese Datei im Verzeichnis `mychart/templates/` befindet, wird sie durch die Template-Engine gesendet. Sie können problemlos eine einfache YAML-Datei wie diese im Verzeichnis `mychart/templates/` ablegen. Wenn Helm dieses Template liest, sendet es das Template unverändert an Kubernetes. Mit diesem einfachen Template haben wir jetzt ein installierbares Chart. Wir können es so installieren: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Mit Helm können wir das Release abrufen und das tatsächlich geladene Template sehen. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` Der Befehl `helm get manifest` nimmt einen Release-Namen (`full-coral`) und gibt alle Kubernetes-Ressourcen aus, die auf den Server hochgeladen wurden. Jede Datei beginnt mit `---`, um den Anfang eines YAML-Dokuments anzuzeigen, gefolgt von einer automatisch generierten Kommentarzeile, die uns sagt, welche Template-Datei dieses YAML-Dokument generiert hat. Von dort an können wir sehen, dass die YAML-Daten genau das sind, was wir in unsere `configmap.yaml`-Datei eingefügt haben. Jetzt können wir unser Release deinstallieren: `helm uninstall full-coral`. ### Hinzufügen eines einfachen Template-Aufrufs Das Hardcodieren des `name:`-Felds in eine Ressource wird normalerweise als schlechte Praxis angesehen. Namen sollten für ein Release eindeutig sein. Deshalb möchten wir vielleicht ein Namensfeld generieren, indem wir den Release-Namen einfügen. **TIPP:** Das `name:`-Feld ist aufgrund von Einschränkungen des DNS-Systems auf 63 Zeichen begrenzt. Aus diesem Grund sind Release-Namen auf 53 Zeichen begrenzt. Kubernetes 1.3 und früher war auf nur 24 Zeichen beschränkt (somit 14 Zeichen für Namen). Ändern wir `configmap.yaml` entsprechend. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Die wesentliche Änderung betrifft den Wert des `name:`-Felds, das jetzt `{{ .Release.Name }}-configmap` ist. > Eine Template-Direktive ist in `{{` und `}}` Blöcken eingeschlossen. Die Template-Direktive `{{ .Release.Name }}` fügt den Release-Namen in das Template ein. Die Werte, die in ein Template übergeben werden, können als _Namespace-Objekte_ betrachtet werden, wobei ein Punkt (`.`) jedes Namespace-Element trennt. Der führende Punkt vor `Release` zeigt an, dass wir mit dem obersten Namespace für diesen Geltungsbereich beginnen (wir werden den Geltungsbereich gleich besprechen). Wir könnten `.Release.Name` also lesen als "beginne im obersten Namespace, finde das `Release`-Objekt, dann suche darin nach einem Objekt namens `Name`". Das `Release`-Objekt ist eines der eingebauten Objekte von Helm, und wir werden es später ausführlicher behandeln. Für den Moment reicht es zu sagen, dass dies den Release-Namen anzeigt, den die Bibliothek unserem Release zuweist. Wenn wir jetzt unsere Ressource installieren, sehen wir sofort das Ergebnis der Verwendung dieser Template-Direktive: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Sie können `helm get manifest clunky-serval` ausführen, um das gesamte generierte YAML zu sehen. Beachten Sie, dass die ConfigMap innerhalb von Kubernetes nun `clunky-serval-configmap` heißt statt wie zuvor `mychart-configmap`. An diesem Punkt haben wir Templates in ihrer einfachsten Form gesehen: YAML-Dateien mit Template-Direktiven, die in `{{` und `}}` eingebettet sind. Im nächsten Teil werden wir uns Templates genauer ansehen. Aber bevor wir weitergehen, gibt es einen schnellen Trick, der das Erstellen von Templates beschleunigen kann: Wenn Sie das Template-Rendering testen möchten, ohne tatsächlich etwas zu installieren, können Sie `helm install --debug --dry-run goodly-guppy ./mychart` verwenden. Dies rendert die Templates. Aber anstatt das Chart zu installieren, wird das gerenderte Template an Sie zurückgegeben, damit Sie die Ausgabe sehen können: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Die Verwendung von `--dry-run` erleichtert das Testen Ihres Codes, garantiert aber nicht, dass Kubernetes selbst die von Ihnen generierten Templates akzeptiert. Es ist am besten, nicht davon auszugehen, dass Ihr Chart installiert wird, nur weil `--dry-run` funktioniert. In der [Chart-Template-Anleitung](/chart_template_guide/index.mdx) nehmen wir das hier definierte grundlegende Chart und erkunden die Helm-Template-Sprache im Detail. Und wir werden mit den eingebauten Objekten beginnen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: Die .helmignore-Datei description: Die `.helmignore`-Datei wird verwendet, um Dateien anzugeben, die Sie nicht in Ihr Helm Chart aufnehmen möchten. sidebar_position: 12 --- Die `.helmignore`-Datei wird verwendet, um Dateien anzugeben, die Sie nicht in Ihr Helm Chart aufnehmen möchten. Wenn diese Datei existiert, ignoriert der Befehl `helm package` beim Paketieren Ihrer Anwendung alle Dateien, die den in der `.helmignore`-Datei angegebenen Mustern entsprechen. So können Sie verhindern, dass unnötige oder sensible Dateien und Verzeichnisse in Ihr Helm Chart aufgenommen werden. Die `.helmignore`-Datei unterstützt Unix-Shell-Glob-Matching, relatives Pfad-Matching und Negation (mit ! vorangestellt). Pro Zeile wird nur ein Muster berücksichtigt. Hier ist ein Beispiel für eine `.helmignore`-Datei: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Einige bemerkenswerte Unterschiede zu .gitignore: - Die '**'-Syntax wird nicht unterstützt. - Die verwendete Globbing-Bibliothek ist Go's 'filepath.Match', nicht fnmatch(3) - Nachstehende Leerzeichen werden immer ignoriert (es gibt keine Escape-Sequenz, um sie zu erhalten) - Es gibt keine Unterstützung für '\!' als spezielle führende Sequenz. - Die Datei schließt sich nicht standardmäßig selbst aus – Sie müssen einen expliziten Eintrag für `.helmignore` hinzufügen **Helfen Sie uns**, dieses Dokument zu verbessern. Um Informationen hinzuzufügen, zu korrigieren oder zu entfernen, [erstellen Sie ein Issue](https://github.com/helm/helm-www/issues) oder senden Sie uns einen Pull Request. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Benannte Templates description: Wie man benannte Templates definiert. sidebar_position: 9 --- Nun ist es an der Zeit, über ein einzelnes Template hinauszugehen und weitere zu erstellen. In diesem Abschnitt werden wir sehen, wie man _benannte Templates_ in einer Datei definiert und sie an anderer Stelle verwendet. Ein _benanntes Template_ (manchmal auch _Partial_ oder _Subtemplate_ genannt) ist einfach ein Template, das innerhalb einer Datei definiert und mit einem Namen versehen wird. Wir werden zwei Möglichkeiten kennenlernen, sie zu erstellen, und verschiedene Wege, sie zu verwenden. Im Abschnitt [Kontrollstrukturen](./control_structures.md) haben wir drei Aktionen zur Deklaration und Verwaltung von Templates vorgestellt: `define`, `template` und `block`. In diesem Abschnitt werden wir diese drei Aktionen behandeln und auch eine spezielle `include`-Funktion vorstellen, die ähnlich wie die `template`-Aktion funktioniert. Ein wichtiges Detail beim Benennen von Templates: **Template-Namen sind global**. Wenn Sie zwei Templates mit demselben Namen deklarieren, wird dasjenige verwendet, das zuletzt geladen wurde. Da Templates in Subcharts zusammen mit Top-Level-Templates kompiliert werden, sollten Sie Ihre Templates mit _chart-spezifischen Namen_ versehen. Eine beliebte Namenskonvention besteht darin, jedem definierten Template den Namen des Charts voranzustellen: `{{ define "mychart.labels" }}`. Durch die Verwendung des spezifischen Chart-Namens als Präfix können Konflikte vermieden werden, die entstehen könnten, wenn zwei verschiedene Charts Templates mit demselben Namen implementieren. Dieses Verhalten gilt auch für verschiedene Versionen eines Charts. Wenn Sie `mychart` Version `1.0.0` haben, die ein Template auf eine bestimmte Weise definiert, und eine `mychart` Version `2.0.0`, die das vorhandene benannte Template modifiziert, wird dasjenige verwendet, das zuletzt geladen wurde. Sie können dieses Problem umgehen, indem Sie auch eine Version im Namen des Charts hinzufügen: `{{ define "mychart.v1.labels" }}` und `{{ define "mychart.v2.labels" }}`. ## Partials und `_`-Dateien Bisher haben wir eine Datei verwendet, und diese eine Datei enthielt ein einzelnes Template. Aber die Template-Sprache von Helm ermöglicht es Ihnen, benannte eingebettete Templates zu erstellen, auf die an anderer Stelle per Name zugegriffen werden kann. Bevor wir uns mit den Details des Schreibens dieser Templates befassen, gibt es eine Dateibenennungskonvention, die erwähnt werden sollte: * Die meisten Dateien in `templates/` werden so behandelt, als ob sie Kubernetes-Manifeste enthalten * Die `NOTES.txt` ist eine Ausnahme * Aber Dateien, deren Name mit einem Unterstrich (`_`) beginnt, enthalten annahmegemäß _kein_ Manifest. Diese Dateien werden nicht als Kubernetes-Objektdefinitionen gerendert, sind aber überall in anderen Chart-Templates zur Verwendung verfügbar. Diese Dateien werden verwendet, um Partials und Hilfsfunktionen zu speichern. Tatsächlich haben wir bei der Erstellung von `mychart` eine Datei namens `_helpers.tpl` gesehen. Diese Datei ist der Standardspeicherort für Template-Partials. ## Templates mit `define` und `template` deklarieren und verwenden Die `define`-Aktion ermöglicht es uns, ein benanntes Template innerhalb einer Template-Datei zu erstellen. Die Syntax sieht folgendermaßen aus: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` Zum Beispiel können wir ein Template definieren, um einen Block von Kubernetes-Labels zu kapseln: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Jetzt können wir dieses Template in unsere vorhandene ConfigMap einbetten und es dann mit der `template`-Aktion einbinden: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Wenn die Template-Engine diese Datei liest, speichert sie die Referenz auf `mychart.labels`, bis `template "mychart.labels"` aufgerufen wird. Dann wird dieses Template inline gerendert. Das Ergebnis sieht so aus: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Hinweis: Ein `define` erzeugt keine Ausgabe, es sei denn, es wird mit template aufgerufen, wie in diesem Beispiel. Konventionell legen Helm Charts diese Templates in einer Partials-Datei ab, üblicherweise `_helpers.tpl`. Verschieben wir diese Funktion dorthin: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Konventionsgemäß sollten `define`-Funktionen einen einfachen Dokumentationsblock (`{{/* ... */}}`) haben, der beschreibt, was sie tun. Obwohl diese Definition in `_helpers.tpl` steht, kann sie dennoch in `configmap.yaml` verwendet werden: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Wie oben erwähnt, **sind Template-Namen global**. Wenn daher zwei Templates mit demselben Namen deklariert werden, wird das zuletzt vorkommende verwendet. Da Templates in Subcharts zusammen mit Top-Level-Templates kompiliert werden, ist es am besten, Ihre Templates mit _chart-spezifischen Namen_ zu versehen. Eine beliebte Namenskonvention besteht darin, jedem definierten Template den Namen des Charts voranzustellen: `{{ define "mychart.labels" }}`. ## Den Gültigkeitsbereich eines Templates festlegen In dem oben definierten Template haben wir keine Objekte verwendet, sondern nur Funktionen. Ändern wir unser definiertes Template so, dass es den Chart-Namen und die Chart-Version enthält: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Wenn wir dies rendern, erhalten wir einen Fehler wie diesen: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Um zu sehen, was gerendert wurde, führen Sie den Befehl mit `--disable-openapi-validation` erneut aus: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Das Ergebnis wird nicht dem entsprechen, was wir erwarten: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Was ist mit dem Namen und der Version passiert? Sie waren nicht im Gültigkeitsbereich unseres definierten Templates. Wenn ein benanntes Template (erstellt mit `define`) gerendert wird, erhält es den Gültigkeitsbereich, der vom `template`-Aufruf übergeben wird. In unserem Beispiel haben wir das Template so eingebunden: ```yaml {{- template "mychart.labels" }} ``` Es wurde kein Gültigkeitsbereich übergeben, daher können wir innerhalb des Templates auf nichts in `.` zugreifen. Das lässt sich aber leicht beheben. Wir übergeben einfach einen Gültigkeitsbereich an das Template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Beachten Sie, dass wir `.` am Ende des `template`-Aufrufs übergeben. Wir könnten genauso gut `.Values` oder `.Values.favorite` oder einen beliebigen anderen Gültigkeitsbereich übergeben. Aber wir möchten den Top-Level-Gültigkeitsbereich. Im Kontext des benannten Templates verweist `$` auf den Gültigkeitsbereich, den Sie übergeben haben, und nicht auf einen globalen Gültigkeitsbereich. Wenn wir dieses Template nun mit `helm install --dry-run --debug plinking-anaco ./mychart` ausführen, erhalten wir folgendes: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Jetzt wird `{{ .Chart.Name }}` zu `mychart` aufgelöst und `{{ .Chart.Version }}` zu `0.1.0`. ## Die `include`-Funktion Nehmen wir an, wir haben ein einfaches Template definiert, das so aussieht: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Nehmen wir nun an, ich möchte dies sowohl in den `labels:`-Abschnitt meines Templates als auch in den `data:`-Abschnitt einfügen: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Wenn wir dies rendern, erhalten wir einen Fehler wie diesen: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Um zu sehen, was gerendert wurde, führen Sie den Befehl mit `--disable-openapi-validation` erneut aus: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Die Ausgabe wird nicht dem entsprechen, was wir erwarten: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Beachten Sie, dass die Einrückung bei `app_version` an beiden Stellen falsch ist. Warum? Weil das eingefügte Template den Text linksbündig ausgerichtet hat. Da `template` eine Aktion und keine Funktion ist, gibt es keine Möglichkeit, die Ausgabe eines `template`-Aufrufs an andere Funktionen zu übergeben; die Daten werden einfach inline eingefügt. Um diesen Fall zu umgehen, bietet Helm eine Alternative zu `template`, die den Inhalt eines Templates in die aktuelle Pipeline importiert, wo er an andere Funktionen in der Pipeline weitergegeben werden kann. Hier ist das obige Beispiel, korrigiert mit `indent`, um das `mychart.app`- Template korrekt einzurücken: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Jetzt ist das erzeugte YAML für jeden Abschnitt korrekt eingerückt: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > In Helm Templates wird die Verwendung von `include` gegenüber `template` > bevorzugt, einfach weil die Ausgabeformatierung für YAML-Dokumente besser > gehandhabt werden kann. Manchmal möchten wir Inhalte importieren, aber nicht als Templates. Das heißt, wir möchten Dateien unverändert importieren. Dies können wir erreichen, indem wir über das `.Files`-Objekt auf Dateien zugreifen, das im nächsten Abschnitt beschrieben wird. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Eine NOTES.txt-Datei erstellen description: Wie Sie Ihren Chart-Benutzern Anweisungen bereitstellen. sidebar_position: 10 --- In diesem Abschnitt betrachten wir das Helm-Werkzeug zur Bereitstellung von Anweisungen für Ihre Chart-Benutzer. Am Ende eines `helm install` oder `helm upgrade` kann Helm einen Block mit hilfreichen Informationen für Benutzer ausgeben. Diese Informationen sind mithilfe von Templates flexibel anpassbar. Um Installationshinweise zu Ihrem Chart hinzuzufügen, erstellen Sie einfach eine `templates/NOTES.txt`-Datei. Diese Datei enthält reinen Text, wird aber wie ein Template verarbeitet und hat Zugriff auf alle normalen Template-Funktionen und -Objekte. Erstellen wir eine einfache `NOTES.txt`-Datei: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Wenn wir jetzt `helm install rude-cardinal ./mychart` ausführen, sehen wir diese Nachricht am Ende: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Die Verwendung von `NOTES.txt` auf diese Weise ist eine hervorragende Möglichkeit, Ihren Benutzern detaillierte Informationen zur Nutzung ihres neu installierten Charts zu geben. Wir empfehlen dringend, eine `NOTES.txt`-Datei zu erstellen, auch wenn diese nicht zwingend erforderlich ist. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts und globale Werte description: Arbeiten mit Subchart-Werten und globalen Werten. sidebar_position: 11 --- Bis zu diesem Punkt haben wir nur mit einem einzelnen Chart gearbeitet. Aber Charts können Abhängigkeiten haben, sogenannte _Subcharts_, die ebenfalls eigene Werte und Templates besitzen. In diesem Abschnitt werden wir ein Subchart erstellen und die verschiedenen Möglichkeiten kennenlernen, wie wir innerhalb von Templates auf Werte zugreifen können. Bevor wir uns dem Code widmen, gibt es einige wichtige Details über Subcharts zu beachten: 1. Ein Subchart gilt als "eigenständig", was bedeutet, dass ein Subchart niemals explizit von seinem übergeordneten Chart abhängig sein kann. 2. Aus diesem Grund kann ein Subchart nicht auf die Werte seines übergeordneten Charts zugreifen. 3. Ein übergeordnetes Chart kann Werte für Subcharts überschreiben. 4. Helm kennt das Konzept von _globalen Werten_, auf die alle Charts zugreifen können. > Diese Einschränkungen gelten nicht unbedingt für [Library Charts](/topics/library_charts.md), die darauf ausgelegt sind, standardisierte Hilfsfunktionen bereitzustellen. Beim Durcharbeiten der Beispiele in diesem Abschnitt werden viele dieser Konzepte deutlicher. ## Erstellen eines Subcharts Für diese Übungen beginnen wir mit dem `mychart/`-Chart, das wir am Anfang dieses Leitfadens erstellt haben, und fügen ein neues Chart darin hinzu. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Beachten Sie, dass wir wie zuvor alle Basis-Templates gelöscht haben, damit wir von Grund auf neu beginnen können. In diesem Leitfaden konzentrieren wir uns auf die Funktionsweise von Templates, nicht auf die Verwaltung von Abhängigkeiten. Der [Charts-Leitfaden](/topics/charts.md) enthält weitere Informationen darüber, wie Subcharts funktionieren. ## Hinzufügen von Werten und einem Template zum Subchart Als Nächstes erstellen wir ein einfaches Template und eine Values-Datei für unser `mysubchart`-Chart. Es sollte bereits eine `values.yaml` in `mychart/charts/mysubchart` vorhanden sein. Wir richten sie wie folgt ein: ```yaml dessert: cake ``` Als Nächstes erstellen wir ein neues ConfigMap-Template in `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Da jedes Subchart ein _eigenständiges Chart_ ist, können wir `mysubchart` einzeln testen: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Überschreiben von Werten aus einem übergeordneten Chart Unser ursprüngliches Chart `mychart` ist nun das _übergeordnete Chart_ von `mysubchart`. Diese Beziehung ergibt sich ausschließlich daraus, dass sich `mysubchart` im Verzeichnis `mychart/charts` befindet. Da `mychart` ein übergeordnetes Chart ist, können wir Konfigurationen in `mychart` festlegen und diese an `mysubchart` weitergeben. Zum Beispiel können wir `mychart/values.yaml` wie folgt ändern: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Beachten Sie die letzten beiden Zeilen. Alle Anweisungen innerhalb des `mysubchart`-Abschnitts werden an das `mysubchart`-Chart gesendet. Wenn wir also `helm install --generate-name --dry-run --debug mychart` ausführen, werden wir unter anderem die `mysubchart`-ConfigMap sehen: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` Der Wert auf der obersten Ebene hat nun den Wert des Subcharts überschrieben. Hier gibt es ein wichtiges Detail zu beachten. Wir haben das Template von `mychart/charts/mysubchart/templates/configmap.yaml` nicht geändert, um auf `.Values.mysubchart.dessert` zu verweisen. Aus Sicht dieses Templates befindet sich der Wert weiterhin unter `.Values.dessert`. Da die Template-Engine Werte weiterreicht, legt sie den Gültigkeitsbereich fest. Für die `mysubchart`-Templates sind also nur Werte verfügbar, die speziell für `mysubchart` bestimmt sind. Manchmal möchten Sie jedoch, dass bestimmte Werte für alle Templates verfügbar sind. Dies wird durch globale Chart-Werte erreicht. ## Globale Chart-Werte Globale Werte sind Werte, auf die von jedem Chart oder Subchart unter genau demselben Namen zugegriffen werden kann. Globale Werte erfordern eine explizite Deklaration. Sie können einen vorhandenen nicht-globalen Wert nicht verwenden, als wäre er global. Der Values-Datentyp hat einen reservierten Abschnitt namens `Values.global`, in dem globale Werte gesetzt werden können. Fügen wir einen in unserer `mychart/values.yaml`-Datei hinzu. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Aufgrund der Funktionsweise von globalen Werten sollten sowohl `mychart/templates/configmap.yaml` als auch `mysubchart/templates/configmap.yaml` auf diesen Wert als `{{ .Values.global.salad }}` zugreifen können. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Wenn wir nun eine Testinstallation durchführen, sehen wir denselben Wert in beiden Ausgaben: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Globale Werte sind nützlich, um solche Informationen weiterzugeben, erfordern jedoch eine gewisse Planung, um sicherzustellen, dass die richtigen Templates für die Verwendung globaler Werte konfiguriert sind. ## Templates mit Subcharts teilen Übergeordnete Charts und Subcharts können Templates gemeinsam nutzen. Jeder definierte Block in einem Chart ist auch für andere Charts verfügbar. Zum Beispiel können wir ein einfaches Template wie dieses definieren: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Erinnern Sie sich daran, dass Labels in Templates _global geteilt_ werden. Daher kann das `labels`-Template von jedem anderen Chart eingebunden werden. Obwohl Chart-Entwickler zwischen `include` und `template` wählen können, hat `include` den Vorteil, dass es Templates dynamisch referenzieren kann: ```yaml {{ include $mytemplate }} ``` Das obige Beispiel dereferenziert `$mytemplate`. Die `template`-Funktion hingegen akzeptiert nur ein String-Literal. ## Vermeiden von Blocks Die Go-Template-Sprache bietet ein `block`-Schlüsselwort, mit dem Entwickler eine Standardimplementierung bereitstellen können, die später überschrieben wird. In Helm Charts sind Blocks nicht das beste Werkzeug zum Überschreiben, da bei mehreren Implementierungen desselben Blocks nicht vorhersehbar ist, welche ausgewählt wird. Die Empfehlung ist, stattdessen `include` zu verwenden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Values-Dateien description: Anleitung zur Verwendung des --values-Flags. sidebar_position: 4 --- Im vorherigen Abschnitt haben wir die eingebauten Objekte betrachtet, die Helm Templates bieten. Eines dieser eingebauten Objekte ist `Values`. Dieses Objekt bietet Zugriff auf Werte, die in das Chart übergeben werden. Der Inhalt stammt aus mehreren Quellen: - Die `values.yaml`-Datei im Chart - Falls es sich um ein Subchart handelt, die `values.yaml`-Datei des übergeordneten Charts - Eine Values-Datei, die mit dem `-f`-Flag an `helm install` oder `helm upgrade` übergeben wird (`helm install -f myvals.yaml ./mychart`) - Einzelne Parameter, die mit `--set` übergeben werden (z.B. `helm install --set foo=bar ./mychart`) Die obige Liste ist nach Priorität geordnet: `values.yaml` ist die Standardeinstellung, die von der `values.yaml` eines übergeordneten Charts überschrieben werden kann, welche wiederum von einer benutzerdefinierten Values-Datei überschrieben werden kann, die ihrerseits von `--set`-Parametern überschrieben werden kann. Values-Dateien sind einfache YAML-Dateien. Bearbeiten wir `mychart/values.yaml` und anschließend unser ConfigMap-Template. Nach dem Entfernen der Standardwerte in `values.yaml` setzen wir nur einen Parameter: ```yaml favoriteDrink: coffee ``` Jetzt können wir diesen Wert in einem Template verwenden: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Beachten Sie, dass wir in der letzten Zeile auf `favoriteDrink` als Attribut von `Values` zugreifen: `{{ .Values.favoriteDrink }}`. Sehen wir uns das Ergebnis an: ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Da `favoriteDrink` in der Standard-`values.yaml`-Datei auf `coffee` gesetzt ist, wird dieser Wert im Template angezeigt. Wir können dies einfach überschreiben, indem wir ein `--set`-Flag bei unserem `helm install`-Aufruf hinzufügen: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Da `--set` eine höhere Priorität als die Standard-`values.yaml`-Datei hat, erzeugt unser Template `drink: slurm`. Values-Dateien können auch strukturiertere Inhalte enthalten. Zum Beispiel könnten wir einen `favorite`-Abschnitt in unserer `values.yaml`-Datei erstellen und dort mehrere Schlüssel hinzufügen: ```yaml favorite: drink: coffee food: pizza ``` Nun müssten wir das Template leicht anpassen: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Obwohl diese Art der Datenstrukturierung möglich ist, empfehlen wir, Ihre Values-Bäume flach zu halten. Wenn wir uns mit der Zuweisung von Werten an Subcharts beschäftigen, werden wir sehen, wie Werte mit einer Baumstruktur benannt werden. ## Löschen eines Standardschlüssels Falls Sie einen Schlüssel aus den Standardwerten entfernen müssen, können Sie den Wert des Schlüssels auf `null` setzen. Helm entfernt dann den Schlüssel bei der Zusammenführung der überschriebenen Werte. Beispielsweise erlaubt das Stable Drupal Chart die Konfiguration der Liveness-Probe, falls Sie ein benutzerdefiniertes Image konfigurieren. Hier sind die Standardwerte: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Wenn Sie versuchen, den livenessProbe-Handler mit `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` auf `exec` statt `httpGet` zu überschreiben, führt Helm die Standard- und überschriebenen Schlüssel zusammen, was zu folgendem YAML führt: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Kubernetes würde dann jedoch einen Fehler melden, da Sie nicht mehr als einen livenessProbe-Handler deklarieren können. Um dies zu umgehen, können Sie Helm anweisen, `livenessProbe.httpGet` zu löschen, indem Sie es auf null setzen: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` Bisher haben wir mehrere eingebaute Objekte kennengelernt und verwendet, um Informationen in Templates einzufügen. Als Nächstes betrachten wir einen weiteren Aspekt der Template-Engine: Funktionen und Pipelines. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Variablen description: Verwendung von Variablen in Templates. sidebar_position: 8 --- Nachdem wir nun mit Funktionen, Pipelines, Objekten und Kontrollstrukturen vertraut sind, können wir uns einem der grundlegendsten Konzepte vieler Programmiersprachen zuwenden: Variablen. In Templates werden sie weniger häufig verwendet. Wir werden jedoch sehen, wie man sie nutzt, um Code zu vereinfachen und `with` sowie `range` besser einzusetzen. In einem früheren Beispiel haben wir gesehen, dass dieser Code fehlschlägt: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` befindet sich nicht innerhalb des Gültigkeitsbereichs, der im `with`-Block eingeschränkt ist. Um solche Gültigkeitsbereichsprobleme zu umgehen, können Sie Objekte Variablen zuweisen, auf die unabhängig vom aktuellen Gültigkeitsbereich zugegriffen werden kann. In Helm Templates ist eine Variable eine benannte Referenz auf ein anderes Objekt. Sie folgt der Form `$name`. Variablen werden mit einem speziellen Zuweisungsoperator zugewiesen: `:=`. Wir können das obige Beispiel umschreiben, um eine Variable für `Release.Name` zu verwenden. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Beachten Sie, dass wir vor dem Start des `with`-Blocks `$relname := .Release.Name` zuweisen. Innerhalb des `with`-Blocks verweist die Variable `$relname` weiterhin auf den Release-Namen. Das erzeugt folgende Ausgabe: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Variablen sind besonders nützlich in `range`-Schleifen. Sie können bei listenartigen Objekten verwendet werden, um sowohl den Index als auch den Wert zu erfassen: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Beachten Sie, dass zuerst `range` kommt, dann die Variablen, dann der Zuweisungsoperator und schließlich die Liste. Dies weist den ganzzahligen Index (beginnend bei Null) `$index` zu und den Wert `$topping`. Das erzeugt: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Bei Datenstrukturen, die sowohl einen Schlüssel als auch einen Wert haben, können wir `range` verwenden, um beides zu erhalten. Zum Beispiel können wir `.Values.favorite` so durchlaufen: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Bei der ersten Iteration wird `$key` den Wert `drink` haben und `$val` den Wert `coffee`, und bei der zweiten wird `$key` den Wert `food` haben und `$val` den Wert `pizza`. Das erzeugt: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Variablen sind normalerweise nicht "global". Sie sind auf den Block beschränkt, in dem sie deklariert werden. Früher haben wir `$relname` auf der obersten Ebene des Templates zugewiesen. Diese Variable ist im gesamten Template gültig. Aber in unserem letzten Beispiel sind `$key` und `$val` nur innerhalb des `{{ range... }}{{ end }}`-Blocks gültig. Es gibt jedoch eine Variable, die immer auf den Root-Kontext verweist: `$`. Dies kann sehr nützlich sein, wenn Sie in einer range-Schleife iterieren und den Release-Namen des Charts benötigen. Ein Beispiel zur Veranschaulichung: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` Bisher haben wir nur ein Template betrachtet, das in nur einer Datei deklariert ist. Aber eine der mächtigen Funktionen der Helm Template-Sprache ist die Möglichkeit, mehrere Templates zu deklarieren und sie gemeinsam zu verwenden. Darauf werden wir im nächsten Abschnitt eingehen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Nächste Schritte description: Abschluss - einige nützliche Hinweise auf weitere Dokumentation, die Ihnen helfen wird. sidebar_position: 14 --- Diese Anleitung soll Ihnen als Chart-Entwickler ein fundiertes Verständnis für die Verwendung der Template-Sprache von Helm vermitteln. Die Anleitung konzentriert sich auf die technischen Aspekte der Template-Entwicklung. Es gibt jedoch viele Themen, die diese Anleitung nicht behandelt hat, wenn es um die praktische tägliche Entwicklung von Charts geht. Hier sind einige nützliche Hinweise auf weitere Dokumentation, die Ihnen bei der Erstellung neuer Charts helfen wird: - Der CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) ist eine unverzichtbare Quelle für Charts. - Die Kubernetes [Dokumentation](https://kubernetes.io/docs/home/) bietet detaillierte Beispiele für die verschiedenen Ressourcentypen, die Sie verwenden können, von ConfigMaps und Secrets bis hin zu DaemonSets und Deployments. - Die Helm [Charts-Anleitung](/topics/charts.md) erklärt den Arbeitsablauf bei der Verwendung von Charts. - Die Helm [Chart Hooks-Anleitung](/topics/charts_hooks.md) erklärt, wie Sie Lifecycle Hooks erstellen. - Der Helm Artikel [Tipps und Tricks](/howto/charts_tips_and_tricks.md) bietet nützliche Hinweise für das Schreiben von Charts. - Die [Sprig-Dokumentation](https://github.com/Masterminds/sprig) dokumentiert mehr als sechzig Template-Funktionen. - Die [Go Template-Dokumentation](https://godoc.org/text/template) erklärt die Template-Syntax im Detail. - Das [Schelm-Tool](https://github.com/databus23/schelm) ist ein praktisches Hilfsprogramm zum Debuggen von Charts. Manchmal ist es einfacher, ein paar Fragen zu stellen und Antworten von erfahrenen Entwicklern zu bekommen. Der beste Ort dafür sind die Helm-Kanäle im [Kubernetes Slack](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Wenn Sie Fehler oder Auslassungen in diesem Dokument finden, neue Inhalte vorschlagen oder einen Beitrag leisten möchten, besuchen Sie das [Helm-Projekt](https://github.com/helm/helm-www). ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Anhang: YAML-Techniken" description: Ein genauerer Blick auf die YAML-Spezifikation und wie sie auf Helm angewendet wird. sidebar_position: 15 --- Der Großteil dieser Anleitung hat sich auf das Schreiben der Template-Sprache konzentriert. Hier werden wir uns das YAML-Format ansehen. YAML hat einige nützliche Funktionen, die wir als Template-Autoren nutzen können, um unsere Templates weniger fehleranfällig und leichter lesbar zu machen. ## Skalare und Collections Laut der [YAML-Spezifikation](https://yaml.org/spec/1.2/spec.html) gibt es zwei Arten von Collections und viele skalare Typen. Die zwei Arten von Collections sind Maps und Sequences: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Skalare Werte sind einzelne Werte (im Gegensatz zu Collections). ### Skalare Typen in YAML In Helms YAML-Dialekt wird der skalare Datentyp eines Wertes durch einen komplexen Satz von Regeln bestimmt, einschließlich des Kubernetes-Schemas für Ressourcendefinitionen. Bei der Typinferenz gelten jedoch in der Regel die folgenden Regeln. Wenn eine Ganzzahl oder Fließkommazahl ein nicht in Anführungszeichen gesetztes Wort ist, wird sie typischerweise als numerischer Typ behandelt: ```yaml count: 1 size: 2.34 ``` Wenn sie jedoch in Anführungszeichen gesetzt sind, werden sie als Strings behandelt: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` Dasselbe gilt für Booleans: ```yaml isGood: true # bool answer: "true" # string ``` Das Wort für einen leeren Wert ist `null` (nicht `nil`). Beachten Sie, dass `port: "80"` gültiges YAML ist und sowohl durch die Template-Engine als auch den YAML-Parser läuft, aber fehlschlägt, wenn Kubernetes erwartet, dass `port` eine Ganzzahl ist. In einigen Fällen können Sie eine bestimmte Typinferenz mit YAML-Node-Tags erzwingen: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` Im obigen Beispiel teilt `!!str` dem Parser mit, dass `age` ein String ist, auch wenn es wie ein Integer aussieht. Und `port` wird als Integer behandelt, obwohl es in Anführungszeichen steht. ## Strings in YAML Ein Großteil der Daten, die wir in YAML-Dokumenten platzieren, sind Strings. YAML hat mehr als eine Möglichkeit, einen String darzustellen. Dieser Abschnitt erklärt die verschiedenen Wege und zeigt, wie einige davon verwendet werden. Es gibt drei "inline" Möglichkeiten, einen String zu deklarieren: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Alle Inline-Stile müssen in einer Zeile stehen. - Bare Words (unquotierte Wörter) sind nicht in Anführungszeichen gesetzt und werden nicht escaped. Aus diesem Grund müssen Sie darauf achten, welche Zeichen Sie verwenden. - Strings in doppelten Anführungszeichen können bestimmte Zeichen mit `\` escapen. Zum Beispiel `"\"Hello\", she said"`. Sie können Zeilenumbrüche mit `\n` escapen. - Strings in einfachen Anführungszeichen sind "literale" Strings und verwenden nicht `\` zum Escapen von Zeichen. Die einzige Escape-Sequenz ist `''`, die als einzelnes `'` dekodiert wird. Zusätzlich zu den einzeiligen Strings können Sie mehrzeilige Strings deklarieren: ```yaml coffee: | Latte Cappuccino Espresso ``` Das obige Beispiel behandelt den Wert von `coffee` als einen einzelnen String, der `Latte\nCappuccino\nEspresso\n` entspricht. Beachten Sie, dass die erste Zeile nach dem `|` korrekt eingerückt sein muss. Wir könnten das obige Beispiel also durch Folgendes ungültig machen: ```yaml coffee: | Latte Cappuccino Espresso ``` Da `Latte` falsch eingerückt ist, würden wir einen Fehler wie diesen erhalten: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` In Templates ist es manchmal sicherer, eine "erste Zeile" als Platzhalter in einem mehrzeiligen Dokument zu setzen, um den obigen Fehler zu vermeiden: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Beachten Sie, dass diese erste Zeile in der Ausgabe des Strings erhalten bleibt. Wenn Sie diese Technik beispielsweise verwenden, um den Inhalt einer Datei in eine ConfigMap einzufügen, sollte der Kommentar dem Typ entsprechen, der von dem erwartet wird, was diesen Eintrag liest. ### Kontrolle von Leerzeichen in mehrzeiligen Strings Im obigen Beispiel haben wir `|` verwendet, um einen mehrzeiligen String anzuzeigen. Beachten Sie jedoch, dass dem Inhalt unseres Strings ein abschließendes `\n` folgte. Wenn wir möchten, dass der YAML-Prozessor das abschließende Newline entfernt, können wir ein `-` nach dem `|` hinzufügen: ```yaml coffee: |- Latte Cappuccino Espresso ``` Jetzt wird der `coffee`-Wert sein: `Latte\nCappuccino\nEspresso` (ohne abschließendes `\n`). In anderen Fällen möchten wir vielleicht, dass alle abschließenden Leerzeichen erhalten bleiben. Wir können dies mit der `|+`-Notation tun: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Jetzt wird der Wert von `coffee` sein: `Latte\nCappuccino\nEspresso\n\n\n`. Die Einrückung innerhalb eines Textblocks wird beibehalten und führt auch zur Beibehaltung von Zeilenumbrüchen: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` Im obigen Fall wird `coffee` sein: `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Einrückung und Templates Beim Schreiben von Templates möchten Sie möglicherweise den Inhalt einer Datei in das Template einfügen. Wie wir in vorherigen Kapiteln gesehen haben, gibt es zwei Möglichkeiten, dies zu tun: - Verwenden Sie `{{ .Files.Get "FILENAME" }}`, um den Inhalt einer Datei im Chart zu erhalten. - Verwenden Sie `{{ include "TEMPLATE" . }}`, um ein Template zu rendern und dann dessen Inhalt in das Chart einzufügen. Beim Einfügen von Dateien in YAML ist es gut, die obigen mehrzeiligen Regeln zu verstehen. Oft ist der einfachste Weg, eine statische Datei einzufügen, folgender: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Beachten Sie, wie wir die Einrückung oben durchführen: `indent 2` weist die Template-Engine an, jede Zeile in "myfile.txt" mit zwei Leerzeichen einzurücken. Beachten Sie, dass wir diese Template-Zeile nicht einrücken. Das liegt daran, dass andernfalls der Dateiinhalt der ersten Zeile doppelt eingerückt würde. ### Gefaltete mehrzeilige Strings Manchmal möchten Sie einen String in Ihrem YAML mit mehreren Zeilen darstellen, aber möchten, dass er bei der Interpretation als eine lange Zeile behandelt wird. Dies wird "Folding" (Falten) genannt. Um einen gefalteten Block zu deklarieren, verwenden Sie `>` anstelle von `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` Der Wert von `coffee` oben wird `Latte Cappuccino Espresso\n` sein. Beachten Sie, dass alle außer dem letzten Zeilenvorschub in Leerzeichen umgewandelt werden. Sie können die Leerzeichen-Kontrollen mit dem Folded-Text-Marker kombinieren, sodass `>-` alle Newlines ersetzt oder entfernt. Beachten Sie, dass in der Folded-Syntax das Einrücken von Text dazu führt, dass Zeilen erhalten bleiben. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Das obige Beispiel ergibt `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Beachten Sie, dass sowohl die Leerzeichen als auch die Zeilenumbrüche noch vorhanden sind. ## Einbetten mehrerer Dokumente in einer Datei Es ist möglich, mehr als ein YAML-Dokument in einer einzigen Datei zu platzieren. Dies geschieht, indem ein neues Dokument mit `---` eingeleitet und das Dokument mit `...` beendet wird. ```yaml --- document: 1 ... --- document: 2 ... ``` In vielen Fällen kann entweder `---` oder `...` weggelassen werden. Einige Dateien in Helm können nicht mehr als ein Dokument enthalten. Wenn beispielsweise mehr als ein Dokument in einer `values.yaml`-Datei bereitgestellt wird, wird nur das erste verwendet. Template-Dateien können jedoch mehr als ein Dokument haben. In diesem Fall wird die Datei (und alle ihre Dokumente) beim Template-Rendering als ein Objekt behandelt. Aber dann wird das resultierende YAML in mehrere Dokumente aufgeteilt, bevor es an Kubernetes übergeben wird. Wir empfehlen, mehrere Dokumente pro Datei nur dann zu verwenden, wenn es unbedingt notwendig ist. Das Vorhandensein mehrerer Dokumente in einer Datei kann das Debugging erschweren. ## YAML ist eine Obermenge von JSON Da YAML eine Obermenge von JSON ist, _sollte_ jedes gültige JSON-Dokument auch gültiges YAML sein. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Das obige ist eine andere Art, dies darzustellen: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` Und die beiden können (mit Vorsicht) gemischt werden: ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Alle drei sollten zur gleichen internen Darstellung geparst werden. Obwohl dies bedeutet, dass Dateien wie `values.yaml` JSON-Daten enthalten können, behandelt Helm die Dateiendung `.json` nicht als gültiges Suffix. ## YAML-Anker Die YAML-Spezifikation bietet eine Möglichkeit, eine Referenz auf einen Wert zu speichern und später auf diesen Wert per Referenz zu verweisen. YAML nennt dies "Anchoring": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` Im obigen Beispiel setzt `&favoriteCoffee` eine Referenz auf `Cappuccino`. Später wird diese Referenz als `*favoriteCoffee` verwendet. So wird `coffees` zu `Latte, Cappuccino, Espresso`. Obwohl es einige Fälle gibt, in denen Anker nützlich sind, gibt es einen Aspekt, der subtile Bugs verursachen kann: Wenn das YAML zum ersten Mal eingelesen wird, wird die Referenz aufgelöst und dann verworfen. Wenn wir also das obige Beispiel dekodieren und dann wieder kodieren würden, wäre das resultierende YAML: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Da Helm und Kubernetes oft YAML-Dateien lesen, modifizieren und dann neu schreiben, gehen die Anker verloren. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: "Änderungen seit Helm 2" sidebar_position: 1 --- ## Änderungen seit Helm 2 Hier ist eine Liste an grundlegenden Änderungen in Helm 3. ### Löschung von Tiller Während des Helm 2 Entwicklungszyklus haben wir Tiller vorgestellt. Tiller spielte eine wichtige Rolle für Teams in einem geteilten Cluster - es war für mehrere unterschiedliche Operatoren möglich, mit demselben Set an Versionen zu interagieren. Mit rollenbasierter Zugriffskontrolle (RBAC), standardmäßig aktiviert in Kubernetes 1.6, sperrte Tiller immer mehr in Produktionsumgebungen aus, da die Verwaltung schwieriger wurde. Durch die vielen möglichen Sicherheitsrichtlinien war es unser Fokus, eine permissive Standardkonfiguration zu liefern. Das erlaubte es Neulingen in Helm und Kubernetes, schnell zu starten, ohne sich allzu viel über Sicherheitskontrollen den Kopf zu zerbrechen. Unglücklicherweise konnte diese permissive Konfiguration ein breites Spektrum an Berechtigungen öffnen, ohne dass der Nutzer dies erwartete. DevOps und SREs hatten zusätzliche Betriebsschritte zu lernen, um Tiller in einem Multi-Mandanten-Cluster zu betreiben. Nachdem wir von Gemeinschaftsmitgliedern gehört haben, wie sie Helm benutzen, fanden wir, dass Tillers Versionsverwaltung nicht zum Clusterbetrieb oder als zentraler Platz für Helm Versionsinformationen passte. Stattdessen können wir einfach die Informationen von der Kubernetes-API abrufen, die Charts auf lokaler Seite rendern und einen Eintrag der Installation in Kubernetes speichern. Tillers primäre Ziel konnte ohne Tiller erreicht werden, so war es eine der ersten Entscheidungen, die für Helm 3 getroffen wurden, Tiller komplett zu entfernen. Ohne Tiller hat sich das Sicherheitsmodell von Helm radikal vereinfacht. Helm 3 unterstützt jetzt alle modernen Sicherheits-, Identitäts- und Autorisierungsfunktionen von Kubernetes. Helms Zugriffsrechte werden anhand Ihrer [kubeconfig-Datei](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) ausgewertet. Cluster-Administratoren können Benutzerrechte so granular einschränken, wie sie es für nötig halten. Versionen werden weiter im Cluster gespeichert und die restliche Funktionalität von Helm bleibt erhalten. ### Verbesserte Aktualisierungsstrategie: 3-Wege Vereinigung Helm 2 hat eine 2-Wege Vereinigungsstrategie benutzt. Während der Aktualisierung verglich es das letzte Chart-Manifest gegen das vorgeschlagene Chart-Manifest (welches bei `helm upgrade` übergeben wurde). Es verglich die Unterschiede zwischen den zwei Charts, um herauszufinden, welche Änderungen an den Ressourcen im Kubernetes-Cluster notwendig sind. Wenn Änderungen außerhalb von Helm gemacht wurden (etwa mit `kubectl edit`), wurden diese Änderungen nicht berücksichtigt. Das resultierte in Ressourcen, die nicht zurückgerollt werden konnten: Weil Helm nur das letzte angewandte Chart-Manifest als aktuellen Status betrachtete, blieb der Live-Status unverändert, wenn es keine Änderungen im Chart-Status gab. In Helm 3 benutzen wir jetzt eine 3-Wege Vereinigungsstrategie. Helm beachtet das alte Manifest, den Livestatus und das neue Manifest, um einen Patch zu generieren. #### Beispiele Lassen Sie uns durch ein paar übliche Beispiele gehen, um die Auswirkungen zu sehen. ##### Zurückrollen wo sich der Livestatus geändert hat Ihr Team hat gerade mit Helm ihre Applikation in die Produktion auf Kubernetes gebracht. Das Chart beinhaltet ein Deployment Objekt, in dem die Nummer der Replicas auf drei gesetzt ist: ```console $ helm install myapp ./myapp ``` Ein neuer Entwickler tritt dem Team bei. An seinem ersten Arbeitstag tritt beim Betrachten des Produktions-Clusters ein fürchterlicher Kaffee-auf-Tastatur-Unfall ein und das Deployment wird von drei Replicas auf 0 skaliert. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Ein anderer Entwickler Ihres Teams stellt fest, dass die Produktionsseite aus ist und entscheidet ein Zurückrollen der Version zum vorherigen Status: ```console $ helm rollback myapp ``` Was passiert? In Helm 2 würde ein Patch generiert, der das alte gegen das neue Manifest vergleicht. Weil es ein Zurückrollen ist, ist es dasselbe Manifest. Helm würde feststellen, dass es nichts zu ändern gibt, weil es keinen Unterschied zwischen dem alten und den neuen Manifest gibt. Der Replica Zähler würde weiter auf 0 stehenbleiben. Panik bricht aus. In Helm 3 würde ein Patch generiert, der das alte Manifest, den Livestatus und das neue Manifest vergleicht. Helm stellt fest, dass der alte Status drei, der Livestatus 0 und das neue Manifest den Wunsch der Änderung zurück zu drei hegt, sodass der Patch eine Änderung des Status zu drei generiert. ##### Aktualisierungen wo sich der Livestatus geändert hat Viele Dienstenetze und andere kontroll-basierte Applikationen injizieren Daten in Kubernetes Objekte. Das kann sowas sein wie ein Sidecar, Label oder andere Informationen. Vorher haben Sie ein Manifest von einem Chart so gerendert: ```yaml containers: - name: server image: nginx:2.0.0 ``` Und der Livestatus wurde von einer anderen Applikation geändert zu: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Jetzt möchten Sie den `nginx` Image Tag auf `2.1.0` aktualisieren. Dazu aktualisieren Sie das Chart mit diesem Manifest: ```yaml containers: - name: server image: nginx:2.1.0 ``` Was passiert? In Helm 2 generiert Helm einen Patch für das `containers` Objekt zwischen dem alten und dem neuen Manifest. Der Cluster Livestatus wird bei der Patchgenerierung nicht beachtet. Der Cluster Livestatus wird in folgender Weise geändert: ```yaml containers: - name: server image: nginx:2.1.0 ``` Der Sidecar-Pod ist aus dem Live-Status gelöscht. Mehr Panik bricht aus. In Helm 3 generiert Helm einen Patch des `containers` Objekts zwischen dem alten Manifest, dem Live-Status und dem neuen Manifest. Es bemerkt, dass das neue Manifest den Image Tag auf `2.1.0` ändern möchte, aber der Live-Status einen Sidecar Container beinhaltet. Der Cluster Livestatus wird in folgender Weise geändert: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Versionsnamen sind jetzt im Umfang des Namespace geändert Nach der Löschung von Tiller müssen die Informationen über die Versionen irgendwohin. In Helm 2 wurde das im selben Namespace wie Tiller gespeichert. In der Praxis bedeutete das, dass ein Name von einer Version verwendet wurde, keine andere Version konnte denselben Namen benutzen, auch wenn es in unterschiedlichen Namespace installiert war. In Helm 3 werden die Informationen über eine Version im selben Namespace gespeichert, in dem die Version selbst installiert ist. Das bedeutet, dass Benutzer jetzt `helm install wordpress stable/wordpress` in zwei separaten Namespaces ausführen können und jede Version mit `helm list` im Kontext des jeweiligen Namespace angezeigt wird (z.B. `helm list --namespace foo`). Mit dieser besseren Ausrichtung auf native Cluster-Namespaces listet das Kommando `helm list` nicht mehr standardmäßig alle Versionen auf. Stattdessen listet es es nur die Versionen im derzeitigen Kubernetes Kontext auf (z.B. den Namespace wenn Sie `kubectl config view --minify` eingeben). Das bedeutet also, dass Sie die Option `--all-namespaces` zu `helm list` eingeben müssen, wie bei Helm 2. ### Secrets als der Standardspeichertreiber In Helm 3 werden jetzt Secrets als der [Standardspeichertreiber](/topics/advanced.md#storage-backends) benutzt. Helm 2 benutzte ConfigMaps als Standard, um Versionsinformationen zu speichern. In Helm 2.7.0 wurde ein neues Speicher-Backend implementiert, was jetzt in Helm 3 der Standard ist. Die Änderung zu Secrets in Helm 3 als Standard erlaubt einen Schutz der Charts in derselben Weise wie die Version der Secret Verschlüsselung in Kubernetes. [Verschlüsseung von Secrets mit Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) wurde Standard als Alpha-Funktion in Kubernetes 1.7 und wurde stabil in Kubernetes 1.13. Dies erlaubt Benutzer Versions Metadaten zu verschlüsseln und es ist ein guter Startpunkt, um später sowas wie Vault zu benutzen. ### Go Import Pfadänderungen In Helm 3 schaltete Helm den Go Importpfad von `k8s.io/helm` zu `helm.sh/helm/v3`. Wenn Sie 3 Go client Bibliotheken verwenden, stellen Sie die Änderung des Importpfads sicher. ### Capabilities Die Verfügbarkeit des eingebauten `.Capabilities` Objekts wurde im Stadium des Renderns vereinfacht. [Eingebaute Objekte](/chart_template_guide/builtin_objects.md) ### Validierung der Chart Values mit JSONSchema Ein JSON Schema kann jetzt den Chart Values auferlegt werden. Das stellt sicher, dass die Werte, die der Nutzer eingegeben hat, dem Schemalayout des Charts entsprechen, bessere Fehlermeldungen werden zur Verfügung gestellt, wenn falsche Werte für das Chart eingegeben wurden. Eine Validierung erfolgt bei folgenden Kommandos: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Sehen Sie die Dokumentation zu [Schema Dateien](/topics/charts.md#schema-files) für mehr Informationen. ### Konsolidierung von `requirements.yaml` in `Chart.yaml` Das Chart-Abhängigkeitssystem wechselte von requirements.yaml und requirements.lock zu Chart.yaml und Chart.lock. Wir empfehlen, dass neue Charts für Helm 3 das neue Format verwenden. Helm 3 versteht jedoch weiterhin die Chart API Version 1 (`v1`) und lädt vorhandene `requirements.yaml` Dateien. In Helm 2 sah eine `requirements.yaml` so aus: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` In Helm 3 sehen die Abhängigkeiten genauso aus, stehen aber in `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Charts werden weiterhin in das `charts/` Verzeichnis heruntergeladen, Subcharts geliefert nach `charts/` werden ohne Anpassungen weiter funktionieren. ### Name (oder --generate-name) ist jetzt zur Installation erforderlich Wenn in Helm 2 kein Name angeben wurde, wurde einer autogeneriert. In der Produktion war das eher störend als hilfreich. In Helm 3 gibt es eine Fehlermeldung, wenn bei `helm install` kein Name angegeben wird. Wer weiter einen autogenerierten Namen verwenden will, kann die Option `--generate-name` für sich benutzen. ### Charts in OCI Registries hochladen Dies ist eine experimentelle Funktion in Helm 3. Um sie zu benutzen, setzen Sie die Umgebungsvariable `HELM_EXPERIMENTAL_OCI=1`. Auf einem hohen Level, ein Chart Repository ist ein Ort, an dem Charts gespeichert und geteilt werden können. Ein Helm Programm packt und schickt Helm Charts zu einem Chart Repository. Einfach ausgedrückt ist das ein simpler HTTP Server, der eine index.yaml Datei hat und einige gepackte Charts. Während es für die meisten einfachen Speicheranforderungen nur Vorteile bringt, gibt es aber auch ein paar Nachteile: - Chart Repositories fällt es sehr schwer, die Sicherheitsanforderungen an eine Produktionsumgebung zu erfüllen. Es ist sehr wichtig, eine Authentifizierung und Authorisierung für die Standard API zu haben. - Helm Chart Herkunftswerkzeuge zum Signieren und Verifizieren der Integrität sind optional für den Veröffentlichungsprozess. - In einer Mehrbenutzerumgebung kann dasselbe Chart von unterschiedlichen Nutzern hochgeladen werden, kostet doppelten Speicher für denselben Inhalt, aber das ist nicht Teil der Spezifikation. - Die Benutzung einer einzigen Indexdatei zum Suchen, Metadataeninformationen und Herunterladen der Charts hat es kompliziert gemacht oder ist in einer sicheren Mehrbenutzerumgebung unmöglich. Das Docker Distribution Projekt (auch bekannt als Docker Registry v2) ist der Erfolgsfaktor des Docker Registry Projekts. Viele Cloud Lieferanten bieten ein Produkt des Distribution Projekts an und da dies so viele sind, hat das Distribution Projekt in vielen Jahren Vorteile bezüglich Hardening, empfohlene Vorgehensweisen und Kampftests. Bitte schauen Sie nach `helm help chart` und `helm help registry` für mehr wie ein Chart zu packen und in eine Docker Registry zu laden ist. Für mehr Informationen schauen Sie [diese Seite](/topics/registries.md). ### Löschen von `helm serve` `helm serve` startete eine lokales Chart Repository auf Ihrem Computer für Entwicklerzwecke. Nun, es wurde nicht viel angenommen und hatte zahlreiche Probleme mit seinem Design. Am Ende entschieden wir uns es zu löschen und als Plugin auszulagern. Für ähnliche Erfahrungen zu `helm serve` schauen Sie in die lokale Dateisystemoption im [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) und das [servecm plugin](https://github.com/jdolitsky/helm-servecm). ### Unterstützung für Chart Bibliotheken Helm 3 unterstützt eine Klasse von Charts genannt "Chart Bibliotheken". Das ist ein Chart, was von anderen Charts geteilt wird, aber keine eigenen Versionsartefakte erstellt. Eine Chart Bibliothek Vorlage kann nur `define` Elemente deklarieren. Global nicht-`define` definierter Inhalt wird ignoriert. Das erlaubt Nutzern, Code oder Codeschnippsel quer zwischen vielen Charts wiederzuverwenden und doppelten Code zu vermeiden ([DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)). Chart Bibliotheken sind in der Abhängigkeitsdirektive in der Chart.yaml deklariert und werden installiert und verwaltet wie andere Charts. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Wir sind sehr stolz darauf, um Anwendungsfälle für diese Funktion von Chartentwicklern und auch beste Beispiele der Nutzung zu sehen. ### Chart.yaml apiVersion erhöht Mit der Vorstellung der Chartbibliotheken, der Konsilidierung der requirements.yaml in Chart.yaml würden Programme in Helm 2 Format nicht mehr funktionieren. So erhöhten wir die apiVersion in Chart.yaml von `v1` zu `v2`. `helm create` erstellt Charts jetzt in diesem neuen Format, so wurde die Standard apiVersion ebenfalls erhöht. Programme möchten beide Versionen unterstützen und sollten das Feld `apiVersion` in Chart.yaml untersuchen, um zu verstehen, wie sie das Paketformat parsen sollen. ### XDG Basis Verzeichnissupport [Die Spezifikation zu XDG Basis Verzeichnissupport](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) ist ein portabler Standard, der Konfigurationen, Daten und Zwischenspeicherdateien definiert und wie sie im Dateisystem gespeichert werden sollen. In Helm 2 speicherte Helm all diese Informationen in `~/.helm` (auch bekannt als `helm home`), was mit der Umgebungsvariable `$HELM_HOME` geändert werden konnte oder auch durch die globale Option `--home`. In Helm 3 respektiert Helm jetzt die folgenden Umgebungsvariablen gemäß der XDG-Basisverzeichnis-Spezifikation: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Helm Plugins beachten weiterhin für Abwärtskompatibilität `$HELM_HOME` als Alias für `$XDG_DATA_HOME`. Verschiedene neue Umgebungsvariablen werden ebenfalls als Variablen des Plugins eingeführt: - `$HELM_PATH_CACHE` für den Pfad zum Zwischenspeicher - `$HELM_PATH_CONFIG` für den Pfad zur Konfiguration - `$HELM_PATH_DATA` für den Pfad zu den Daten Helm Plugins, die Helm 3 unterstützen, sollten diese neuen Umgebungsvariablen nutzen. ### Umbenennung von CLI-Kommandos Um sich an die Terminologie anderer Paketmanager anzupassen, wurde `helm delete` in `helm uninstall` umbenannt. `helm delete` funktioniert weiterhin als Alias für `helm uninstall` und kann weiter verwendet werden. In Helm 2 musste die Option `--purge` angegeben werden, um den Release-Verlauf zu bereinigen. Diese Funktion ist jetzt standardmäßig aktiviert. Um das vorherige Verhalten beizubehalten, verwenden Sie `helm uninstall --keep-history`. Zusätzlich wurden verschiedene andere Kommandos in ähnlicher Konvention umbenannt: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Diese Kommandos haben ihre alte Bedeutung als Alias beibehalten, sodass sie die weiter benutzen können. ### Automatisch erstellter Namespace Wenn eine Version in einem Namespace erstellt wird, der nicht existiert, hat Helm2 diesen angelegt. Helm 3 folgt den Konventionen von anderen Kubernetes Werkzeugen und gibt eine Fehlermeldung zurück, wenn der Namespace nicht existiert. Helm 3 wird den Namespace mit der expliziten Option `--create-namespace` anlegen. ### Was ist mit .Chart.ApiVersion passiert? Helm folgt der üblichen Konvention für CamelCasing, bei der Akronyme großgeschrieben werden. Wir haben das bereits an anderen Stellen im Code so umgesetzt, wie z.B. bei `.Capabilities.APIVersions.Has`. In Helm v3 haben wir `.Chart.ApiVersion` korrigiert und in `.Chart.APIVersion` umbenannt, um dieser Konvention zu folgen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: "Fragen und Antworten" sidebar_position: 8 --- # Fragen und Antworten > Was sind die Kernunterschiede zwischen Helm 2 und Helm 3? > Diese Seite bietet Antworten zu oft gestelten Fragen (FAQ) **Wir möchten Ihre Hilfe**, um dieses Dokument besser zu machen. Um Informationen hinzuzufügen, korrigieren oder zu löschen, [füllen Sie ein Issue aus](https://github.com/helm/helm-www/issues) oder senden Sie einne Pull Request. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: "Installieren" sidebar_position: 2 --- ## Installieren ### Warum gibt es keine nativen Pakete von Helm für Fedora oder andere Linuxdistributionen? Das Helm Projekt verwaltet keine Pakete für Betriebssysteme oder Umgebungen. Die Helm Gemeinschaft stellt möglicherweise native Pakete zur Verfügung und wenn es genug Aufmerksamkeit in der Gemeinschaft für ein Paket gibt, wird es vielleicht gelistet. So war es als Homebrew Formular startete und gelistet wurde. Wenn Sie interessiert sind, ein Paket zu verwalten, würden wir das sehr begrüßen. ### Warum stellen Sie ein `curl ...|bash` Script zur Verfügung? Es ist ein Script in unserem Verzeichnis (`scripts/get-helm-3`), was als `curl ..|bash` ausgeführt werden kann. Die Übertragung ist durch HTTPS gesichert und das Script macht einige Überprüfungen beim Abruf. Aber egal, dieses Script hat alle Gefahren eines Shellscripts. Wir stellen es zur Verfügung, weil es nützlich ist, aber empfehlen den Nutzern, es vor der ersten Ausführung gründlich zu lesen. Was wir wirklich möchten, ist eine besser gepackte Version von Helm. ### Wie lege ich die Dateien vom Helm Programm woanders hin? Helm benutzt die XDG Struktur zum Abspeichern von Dateien. Es gibt Umgebungsvariablen, die diese Lokation überschreiben können: - `$XDG_CACHE_HOME`: Setzt eine alternative Lokation für Zwischenspeicherdateien. - `$XDG_CONFIG_HOME`: Setzt eine alternative Lokation für Helm Konfiguration. - `$XDG_DATA_HOME`: Setzt eine alternative Lokation für Helm Daten. Beachten Sie, dass Sie existierende Repositories mit dem Kommando `helm repo add...` neu hinzufügen müssen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: "Fehlersuche" sidebar_position: 4 --- ## Fehlersuche ### Ich bekomme eine Warnung "Unable to get an update from the "stable" chart repository" Führen Sie `helm repo list` aus. Wenn Ihr `stable` Repository auf eine `storage.googleapis.com` URL zeigt, müssen Sie dieses Repository aktualisieren. Am 13.11.2020 wurde das Helm Charts Repository [nicht mehr unterstützt](https://github.com/helm/charts#deprecation-timeline), nachdem es ein Jahr lang als veraltet gekennzeichnet war. Ein Archiv ist verfügbar unter `https://charts.helm.sh/stable`, erhält aber keine Aktualisierungen mehr. Mit folgendem Befehl können Sie Ihr Repository reparieren: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Dasselbe gilt für das `incubator` Repository, dessen Archiv unter https://charts.helm.sh/incubator verfügbar ist. Zur Reparatur können Sie folgenden Befehl verwenden: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Ich bekomme die Warnung 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' Das alte Google Helm Chart Repository wurde durch ein neues Helm Chart Repository ersetzt. Führen Sie folgenden Befehl aus, um das dauerhaft zu beheben: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Wenn Sie einen ähnlichen Fehler für `incubator` bekommen, führen Sie diesen Befehl aus: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Wenn ich ein Helm Repo hinzufüge, bekomme ich den Fehler 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Die Helm Chart Repositories werden nach [einer einjährigen Übergangsphase](https://github.com/helm/charts#deprecation-timeline) nicht mehr unterstützt. Archive für diese Repositories sind unter `https://charts.helm.sh/stable` und `https://charts.helm.sh/incubator` verfügbar, erhalten jedoch keine Aktualisierungen mehr. Der Befehl `helm repo add` erlaubt das Hinzufügen der alten URLs nicht, außer Sie verwenden die Option `--use-deprecated-repos`. ### Auf GKE (Google Container Engine) bekomme ich "No SSH tunnels currently open" ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Eine andere Variante dieser Fehlermeldung ist: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` Das Problem ist, dass Ihre lokale Kubernetes Konfigurationsdatei die richtigen Anmeldeinformationen enthalten muss. Wenn Sie in GKE einen Cluster erstellen, erhalten Sie Anmeldeinformationen, einschließlich SSL-Zertifikate und Zertifizierungsstellen. Diese müssen in einer Kubernetes Konfigurationsdatei (Standard: `~/.kube/config`) gespeichert werden, damit `kubectl` und `helm` darauf zugreifen können. ### Nach der Migration von Helm 2 zeigt `helm list` nur wenige oder gar keine Releases an Wahrscheinlich haben Sie übersehen, dass Helm 3 nun Cluster-Namespaces verwendet, um Releases zu gruppieren. Das bedeutet, dass Sie bei allen Befehlen, die sich auf ein Release beziehen, eine der folgenden Optionen verwenden müssen: * den aktuellen Namespace im aktiven Kubernetes-Kontext verwenden (wie vom Befehl `kubectl config view --minify` beschrieben), * den korrekten Namespace mit der Option `--namespace`/`-n` angeben, oder * beim `helm list` Befehl die Option `--all-namespaces`/`-A` verwenden Dies gilt für `helm ls`, `helm uninstall` und alle anderen `helm` Befehle, die sich auf ein Release beziehen. ### In macOS wird auf die Datei `/etc/.mdns_debug` zugegriffen. Warum? Wir wissen, dass Helm auf macOS versucht, auf eine Datei namens `/etc/.mdns_debug` zuzugreifen. Wenn die Datei existiert, hält Helm ein Dateihandle offen, während es ausgeführt wird. Dies wird durch die macOS MDNS-Bibliothek verursacht. Sie versucht, diese Datei zu laden, um Debug-Einstellungen zu lesen (falls aktiviert). Das Dateihandle sollte eigentlich nicht offen gehalten werden, und dieses Problem wurde an Apple gemeldet. Es ist jedoch macOS und nicht Helm, das dieses Verhalten verursacht. Wenn Sie nicht möchten, dass Helm diese Datei lädt, können Sie Helm möglicherweise selbst als statische Bibliothek kompilieren, die den Host-Netzwerkstack nicht verwendet. Dadurch wird die Binärgröße von Helm zunehmen, aber die Datei wird nicht mehr geöffnet. Dieses Problem wurde ursprünglich als potenzielles Sicherheitsproblem gemeldet. Es wurde jedoch festgestellt, dass dieses Verhalten keine Schwachstelle oder Sicherheitslücke darstellt. ### helm repo add schlägt fehl, obwohl es früher funktioniert hat In Helm 3.3.1 und früher gab der Befehl `helm repo add ` keine Ausgabe, wenn Sie versuchten, ein bereits existierendes Repository hinzuzufügen. Die Option `--no-update` hätte einen Fehler ausgelöst, wenn das Repository bereits registriert war. In Helm 3.3.2 und später führt der Versuch, ein existierendes Repository hinzuzufügen, zu einem Fehler: `Error: repository name (reponame) already exists, please specify a different name` Das Standardverhalten ist nun umgekehrt. `--no-update` wird jetzt ignoriert. Wenn Sie ein existierendes Repository ersetzen (überschreiben) möchten, können Sie die Option `--force-update` verwenden. Dies ist auf einen Breaking Change für ein Sicherheitsupdate zurückzuführen, wie in den [Helm 3.3.2 Release Notes](https://github.com/helm/helm/releases/tag/v3.3.2) erklärt wird. ### Kubernetes-Client-Protokollierung aktivieren Die Ausgabe von Protokollmeldungen zur Fehlersuche im Kubernetes-Client kann mit den [klog](https://pkg.go.dev/k8s.io/klog)-Flags aktiviert werden. Die Verwendung der `-v` Option zum Festlegen der Ausführlichkeit ist für die meisten Fälle ausreichend. Zum Beispiel: ``` helm list -v 6 ``` ### Tiller-Installationen funktionieren nicht mehr und der Zugriff wird verweigert Helm-Releases waren früher unter verfügbar. Wie in ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/) erklärt, wurde der offizielle Speicherort im Juni 2019 geändert. Die [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) stellt alle alten Tiller-Images zur Verfügung. Wenn Sie versuchen, ältere Versionen von Helm aus dem Storage Bucket herunterzuladen, den Sie früher verwendet haben, stellen Sie möglicherweise fest, dass diese fehlen: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` Der [ursprüngliche Tiller-Image-Speicherort](https://gcr.io/kubernetes-helm/tiller) begann im August 2021 mit der Entfernung von Images. Wir haben diese Images in der [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) zur Verfügung gestellt. Um beispielsweise Version v2.17.0 herunterzuladen, ersetzen Sie: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` durch: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Um mit Helm v2.17.0 zu initialisieren: `helm init —upgrade` Oder wenn eine andere Version benötigt wird, verwenden Sie die --tiller-image Option, um den Standardspeicherort zu überschreiben und eine bestimmte Helm v2-Version zu installieren: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Hinweis:** Die Helm-Maintainer empfehlen die Migration zu einer aktuell unterstützten Version von Helm. Helm v2.17.0 war die letzte Version von Helm v2; Helm v2 wird seit November 2020 nicht mehr unterstützt, wie in [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/) beschrieben. Seit dieser Zeit wurden viele CVEs gegen Helm gemeldet, und diese Exploits sind in Helm v3 behoben, werden aber niemals in Helm v2 behoben werden. Sehen Sie sich die [aktuelle Liste der veröffentlichten Helm-Sicherheitshinweise](https://github.com/helm/helm/security/advisories?state=published) an und planen Sie noch heute die [Migration zu Helm v3](/topics/v2_v3_migration.md). ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: "Deinstallieren" sidebar_position: 3 --- ## Deinstallieren ### Ich möchte mein lokales Helm deinstallieren. Wo sind alle Dateien? Neben dem eigentlichen `helm` Programm speichert Helm Dateien an folgenden Orten: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME Die folgende Tabelle gibt die Standardspeicherorte je Betriebssystem an: | Betriebssystem | Zwischenspeicherpfad | Konfigurationspfad | Datenpfad | |------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: "Glossar" description: "Benutzte Ausdrücke zur Beschreibung der Komponenten der Helm Architektur." sidebar_position: 9 --- # Glossar ## Chart Ein Helm Paket was Informationen zum Installieren eines Sets von Kubernetes Resourcen in einem Kubernetes Cluster beinhaltet. Charts enthalten eine `Chart.yaml` Datei als auch Vorlagen, Standardwerte (`values.yaml`) und Abhängigkeiten. Charts werden in einer gut definierten Verzeichnisstruktur entwickelt und dann in ein Archiv gepackt, was sich _Chart Archiv_ nennt. ## Chart Archiv Ein _Chart Archiv_ ist ein mit tar und gzip gepacktes (und optimalerweise signiertes) Chart. ## Chart Abhängigkeit (Subcharts) Charts können voneinander abgängen. Es gibt zwei Wege, diese Abhängigkeit herzustellen: - Weiche Abhängigkeit: Ein Chart funktioniert möglicherweise nicht ohne ein anderes Chart. Helm stellt für diesen Fall kein Werkzeug zur Verfügung. Abhängigkeiten müssen separat verwaltet werden. - Harte Abhängigkeit: Ein Chart enthält (innerhalb des `charts/` Verzeichnis) ein anderes Chart, von dem es abhängt. In diesem Fall wird die Installation des Charts alle Abhängigkeiten mit installieren. Charts und seine Abhängigkeiten werden als Kollektion verwaltet. Wenn ein Chart gepackt wird (mit `helm package`), werden alle harten Abhängigkeiten mit gebündelt. ## Chart Version Charts sind versioniert nach [SemVer 2 Spezifikation](https://semver.org). Eine Versionsnummer ist für jedes Chart erforderlich. ## Chart.yaml Informationen über ein Chart werden in einer speziellen Datei namens `Chart.yaml` gespeichert. Jedes Chart muss diese Datei haben. ## Helm (und helm) Helm ist der Paket Manager für Kubernetes. Wie ein Paket Manager für das Betriebssystem das Installieren einfacher macht, kann man mit Helm einfacher Applikationen und Resourcen in Kubernetes Cluster installieren. Da _Helm_ der Name des Projekts ist, trägt das Kommandozeilenprogramm denselben Namen. Wenn wir vom Projekt sprechen, wird _Helm_ gross geschrieben. Sprechen wir vom Kommandozeilenprogramm, schreiben wie _helm_ klein. ## Helm Konfigurationsdateien (XDG) Helm speichert seine Konfigurationsdateien in XDG Verzeichnissen. Diese Verzeichnisse werden erstellt, wenn helm zum ersten mal läuft. ## Kube Config (KUBECONFIG) Das Helm Programm lernt Kubernetes Clusters durch die Benutzung des _Kube config_ Dateiformats. Standardmässig erwartet Helm, diese Datei an einem Platz zu finden, wo kubectl es erstellt hat (`$HOME/.kube/config`). ## Lint (Linting) Ein Chart mit _lint_ zu validieren, ist die Überprüfung, ob es den Konventionen und Anforderungen des Helm Chart Standards genügt. Helm stellt Werkzeuge zur Verfügung, allen voran das `helm lint` Kommando. ## Provenance (Provenance file) Helm charts können von einem _provenance file_ begleitet sein, welches Informationen bereitstellt, wo das Chart herkommt und was es beinhaltet. Herkunftsdateien (Provenance files) sind ein Teil der Helm Sicherheit. Eine _provenance_ beinhaltet einen kryptographischen Hash der Chart Archiv Datei, der Chart.yaml Datei und eines Signaturblockes (ein OpenPGP "clearsign" Block). Wenn dies an eine Schlüsselkette gekoppelt ist, können Benutzer: - validieren, von welchem vertrauenswürdigen Partner das Chart signiert wurde - validieren, dass die Chart Datei nicht manipuliert wurde - den Inhalt der Chart Metadaten validieren (`Chart.yaml`) - schnell vergleichen, dass das Chart mit seinen Herkunftsdaten übereinstimmt Herkunftsdateien haben die Erweiterungen `.prov` und können von einem Chart Verzeichnis Server oder einem anderen HTTP Server ausgeliefert werden. ## Release (Version) Wenn ein Chart installiert ist, erstellt die Helmbibliothek ein Version (_release_), um nachzuvollziehen, was installiert wurde. Ein einzelnes Chart wird möglicherweise mehrmals in denselben Cluster installiert und erstellt unterschiedliche Versionen. Zum Beispiel, ein Chart kann drei PostgreSQL Datenbanken mit demselben Kommando `helm install` dreimal mit unterschiedlchen Versionsnamen installieren. ## Release Number (Release Version) Eine eintelne Version kann mehrmals aktualisiert werden. Ein sequentieller Zähler wird benutzt, um die Versionen nachzuvollziehen. Nach einem ersten `helm install` hat eine Version die _release number_ 1. Nach jeder Aktualisierung oder jedem Zurückrollen wird die Versionsnummer erhöht. ## Rollback (Zurückrollen) Eine Version kann zu einem neuen Chart oder einer neuen Konfiguration aktualisiert werden. Wenn die Versionshistorie gespeichert ist, kann eine Version zu einer vorherigen auch zurückgerollt werden (_rolles back_). Das passiert mit dem `helm rollback` Kommando. Wichtig zu wissen, dass eine zurückgerollte Version eine neue Versionsnummer generiert. | Operation | Release Number | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (but running the same config as release 1) | Die obige Tabelle zeigt, wie Versionsnummern bei jeder Aktion wie Installieren, Aktualisieren und Zurückrollen erhöht werden. ## Helm Library (Helm Bibltiothek oder SDK) Die Helm Bibliothek (Library oder SDK) referenziert zum Go Code, der direkt mit dem Kubernetes API Server zum Installieren, Aktualisieren, Abfragen und Löschen von Kubernetes Resourcen interagiert. Sie kann zum Import in ein Projekt benutzt werden, um Helm in einer Bibliothek anstatt des Kommandozeilenwerkzeugs zu verwenden. ## Repository (Verzeichnis, Repo, Chart Repository) Helm Charts sind gespeichert in dedizierten HTTP Servern namens _chart repositories_ (_Verzeichnis_, _Repositories_ oder einfach _repos_). Ein Chart Repository Server ist ein einfacher HTTP Server, der eine index.yaml Datei ausliefern kann, die eine Anzahl Charts beschreibt und Informationen bereitstellt, wo das Chart herunterzuladen ist. (Viele Chart Repositories liefern die Charts zusammen mit der `index.yam` Datei aus.) Ein Helm Programm kann zu null oder mehreren Chart Verzeichnissen zeigen. Standardmässig sind keine Verzeichnisse konfiguriert. Chart Verzeichnisse können mit dem Kommando `helm repo add` hinzugefügt werden. ## Values (Values/Werte Dateien, values.yaml) Values (Werte) stellen einen Weg zur Verfügung, um Standards aus den Vorlagen zu überschreiben. Helm Charts sind "parametisiert", was bedeutet, dass die Chart Entwickler Konfigurationen nach aussen führen, die zur Installationszeit überschrieben werden können. Zum Beispiel, ein Chart führt ein `username` Feld nach aussen, was das Setzen eines Benutzernamens für diesen Dienst erlaubt. Diese nach aussen geführten Variablen werden in Helm _values_ genannt. Values können während `helm install` und `helm upgrade` gesetzt werden, entweder direkt beim Aufruf oder in einer `values.yaml` Datei. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Der Helm-Paketmanager für Kubernetes. ### Zusammenfassung Der Kubernetes-Paketmanager Häufige Aktionen für Helm: - helm search: Suche nach Charts - helm pull: Ein Chart in Ihr lokales Verzeichnis herunterladen, um es anzuzeigen - helm install: Das Chart nach Kubernetes hochladen - helm list: Releases von Charts auflisten Umgebungsvariablen: | Name | Beschreibung | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | Alternativen Speicherort für zwischengespeicherte Dateien festlegen. | | $HELM_CONFIG_HOME | Alternativen Speicherort für die Helm-Konfiguration festlegen. | | $HELM_DATA_HOME | Alternativen Speicherort für Helm-Daten festlegen. | | $HELM_DEBUG | Gibt an, ob Helm im Debug-Modus ausgeführt wird. | | $HELM_DRIVER | Backend-Speichertreiber festlegen. Mögliche Werte: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | Verbindungszeichenfolge für den SQL-Speichertreiber festlegen. | | $HELM_MAX_HISTORY | Maximale Anzahl der Helm-Release-Historie festlegen. | | $HELM_NAMESPACE | Namespace für Helm-Operationen festlegen. | | $HELM_NO_PLUGINS | Plugins deaktivieren. Setzen Sie HELM_NO_PLUGINS=1, um Plugins zu deaktivieren. | | $HELM_PLUGINS | Pfad zum Plugins-Verzeichnis festlegen. | | $HELM_REGISTRY_CONFIG | Pfad zur Registry-Konfigurationsdatei festlegen. | | $HELM_REPOSITORY_CACHE | Pfad zum Repository-Cache-Verzeichnis festlegen. | | $HELM_REPOSITORY_CONFIG | Pfad zur Repositories-Datei festlegen. | | $KUBECONFIG | Alternative Kubernetes-Konfigurationsdatei festlegen (Standard: "~/.kube/config") | | $HELM_KUBEAPISERVER | Kubernetes-API-Server-Endpunkt für die Authentifizierung festlegen. | | $HELM_KUBECAFILE | Kubernetes-Zertifizierungsstellen-Datei festlegen. | | $HELM_KUBEASGROUPS | Gruppen für die Identitätsannahme festlegen (kommagetrennte Liste). | | $HELM_KUBEASUSER | Benutzername für die Identitätsannahme bei der Operation festlegen. | | $HELM_KUBECONTEXT | Name des kubeconfig-Kontexts festlegen. | | $HELM_KUBETOKEN | Bearer-KubeToken für die Authentifizierung festlegen. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Gibt an, ob die Zertifikatsvalidierung des Kubernetes-API-Servers übersprungen werden soll (unsicher). | | $HELM_KUBETLS_SERVER_NAME | Servernamen zur Validierung des Kubernetes-API-Server-Zertifikats festlegen. | | $HELM_BURST_LIMIT | Standard-Burst-Limit festlegen, falls der Server viele CRDs enthält (Standard: 100, -1 zum Deaktivieren). | | $HELM_QPS | Abfragen pro Sekunde festlegen, wenn eine hohe Anzahl von Aufrufen höhere Burst-Werte erfordert. | Helm speichert Cache, Konfiguration und Daten in folgender Konfigurationsreihenfolge: - Falls eine HELM_*_HOME-Umgebungsvariable gesetzt ist, wird diese verwendet - Andernfalls werden auf Systemen, die die XDG-Base-Directory-Spezifikation unterstützen, die XDG-Variablen verwendet - Wenn kein anderer Speicherort festgelegt ist, wird ein Standardspeicherort basierend auf dem Betriebssystem verwendet Standardmäßig hängen die Standardverzeichnisse vom Betriebssystem ab. Die Standardwerte sind unten aufgeführt: | Betriebssystem | Cache-Pfad | Konfigurations-Pfad | Daten-Pfad | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Optionen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm completion](/helm/helm_completion.md) - Generiert Autovervollständigungsskripte für die angegebene Shell * [helm create](/helm/helm_create.md) - Erstellt ein neues Chart mit dem angegebenen Namen * [helm dependency](/helm/helm_dependency.md) - Verwaltet die Abhängigkeiten eines Charts * [helm env](/helm/helm_env.md) - Informationen zur Helm-Client-Umgebung * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen für ein benanntes Release herunter * [helm history](/helm/helm_history.md) - Ruft die Release-Historie ab * [helm install](/helm/helm_install.md) - Installiert ein Chart * [helm lint](/helm/helm_lint.md) - Untersucht ein Chart auf mögliche Probleme * [helm list](/helm/helm_list.md) - Listet Releases auf * [helm package](/helm/helm_package.md) - Packt ein Chart-Verzeichnis in ein Chart-Archiv * [helm plugin](/helm/helm_plugin.md) - Installiert, listet oder deinstalliert Helm-Plugins * [helm pull](/helm/helm_pull.md) - Lädt ein Chart aus einem Repository herunter und entpackt es optional im lokalen Verzeichnis * [helm push](/helm/helm_push.md) - Pusht ein Chart zu einem Remote-Repository * [helm registry](/helm/helm_registry.md) - An- oder Abmeldung bei einer Registry * [helm repo](/helm/helm_repo.md) - Hinzufügen, Auflisten, Entfernen, Aktualisieren und Indizieren von Chart-Repositories * [helm rollback](/helm/helm_rollback.md) - Setzt ein Release auf eine frühere Revision zurück * [helm search](/helm/helm_search.md) - Durchsucht Charts nach einem Suchbegriff * [helm show](/helm/helm_show.md) - Zeigt Informationen eines Charts an * [helm status](/helm/helm_status.md) - Zeigt den Status des benannten Releases an * [helm template](/helm/helm_template.md) - Rendert Templates lokal * [helm test](/helm/helm_test.md) - Führt Tests für ein Release aus * [helm uninstall](/helm/helm_uninstall.md) - Deinstalliert ein Release * [helm upgrade](/helm/helm_upgrade.md) - Aktualisiert ein Release * [helm verify](/helm/helm_verify.md) - Überprüft, ob ein Chart am angegebenen Pfad signiert und gültig ist * [helm version](/helm/helm_version.md) - Gibt die Client-Versionsinformationen aus ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- Generiert Autovervollständigungsskripte für die angegebene Shell ### Zusammenfassung Generiert Autovervollständigungsskripte für Helm für die angegebene Shell. ### Optionen ``` -h, --help Hilfe für completion ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) - Generiert das Autovervollständigungsskript für bash * [helm completion fish](/helm/helm_completion_fish.md) - Generiert das Autovervollständigungsskript für fish * [helm completion powershell](/helm/helm_completion_powershell.md) - Generiert das Autovervollständigungsskript für powershell * [helm completion zsh](/helm/helm_completion_zsh.md) - Generiert das Autovervollständigungsskript für zsh ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- Generiert das Autovervollständigungsskript für bash ### Zusammenfassung Generiert das Helm-Autovervollständigungsskript für die bash-Shell. Um die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden: source <(helm completion bash) Um die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Optionen ``` -h, --help Hilfe für bash --no-descriptions Vervollständigungsbeschreibungen deaktivieren ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm completion](/helm/helm_completion.md) - Generiert Autovervollständigungsskripte für die angegebene Shell ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- Generiert das Autovervollständigungsskript für fish ### Zusammenfassung Generiert das Helm-Autovervollständigungsskript für die fish-Shell. Um die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden: helm completion fish | source Um die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus: helm completion fish > ~/.config/fish/completions/helm.fish Sie müssen eine neue Shell starten, damit diese Einrichtung wirksam wird. ``` helm completion fish [flags] ``` ### Optionen ``` -h, --help Hilfe für fish --no-descriptions Vervollständigungsbeschreibungen deaktivieren ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm completion](/helm/helm_completion.md) - Generiert Autovervollständigungsskripte für die angegebene Shell ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- Generiert das Autovervollständigungsskript für PowerShell ### Zusammenfassung Generiert das Autovervollständigungsskript für PowerShell. Um die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden: PS C:\> helm completion powershell | Out-String | Invoke-Expression Um die Vervollständigungen für jede neue Sitzung zu laden, fügen Sie die Ausgabe des obigen Befehls zu Ihrem PowerShell-Profil hinzu. ``` helm completion powershell [flags] ``` ### Optionen ``` -h, --help Hilfe für powershell --no-descriptions Vervollständigungsbeschreibungen deaktivieren ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm completion](/helm/helm_completion.md) - Generiert Autovervollständigungsskripte für die angegebene Shell ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- Generiert das Autovervollständigungsskript für zsh ### Zusammenfassung Generiert das Helm-Autovervollständigungsskript für die zsh-Shell. Um die Vervollständigungen in Ihrer aktuellen Shell-Sitzung zu laden: source <(helm completion zsh) Um die Vervollständigungen für jede neue Sitzung zu laden, führen Sie einmalig aus: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Optionen ``` -h, --help Hilfe für zsh --no-descriptions Vervollständigungsbeschreibungen deaktivieren ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm completion](/helm/helm_completion.md) - Generiert Autovervollständigungsskripte für die angegebene Shell ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- Erstellt ein neues Chart mit dem angegebenen Namen ### Zusammenfassung Dieser Befehl erstellt ein Chart-Verzeichnis mit den üblichen Dateien und Verzeichnissen, die in einem Chart verwendet werden. Beispielsweise erstellt 'helm create foo' eine Verzeichnisstruktur, die in etwa so aussieht: foo/ ├── .helmignore # Enthält Muster für Dateien, die beim Packen von Helm-Charts ignoriert werden sollen. ├── Chart.yaml # Informationen über Ihr Chart ├── values.yaml # Die Standardwerte für Ihre Templates ├── charts/ # Charts, von denen dieses Chart abhängt └── templates/ # Die Template-Dateien └── tests/ # Die Testdateien 'helm create' erwartet einen Pfad als Argument. Falls Verzeichnisse im angegebenen Pfad nicht existieren, versucht Helm diese während der Ausführung anzulegen. Wenn das angegebene Zielverzeichnis existiert und Dateien enthält, werden kollidierende Dateien überschrieben, andere Dateien bleiben jedoch unverändert. ``` helm create NAME [flags] ``` ### Optionen ``` -h, --help Hilfe für create -p, --starter string Name oder absoluter Pfad zu einer Helm-Starter-Vorlage ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int Client-seitiges Standard-Throttling-Limit (Standard: 100) --debug Ausführliche Ausgabe aktivieren --kube-apiserver string Adresse und Port des Kubernetes-API-Servers --kube-as-group stringArray Gruppe, die für die Operation imitiert werden soll. Dieses Flag kann wiederholt werden, um mehrere Gruppen anzugeben. --kube-as-user string Benutzername, der für die Operation imitiert werden soll --kube-ca-file string Zertifizierungsstellen-Datei für die Kubernetes-API-Server-Verbindung --kube-context string Name des kubeconfig-Kontexts, der verwendet werden soll --kube-insecure-skip-tls-verify Falls true, wird das Zertifikat des Kubernetes-API-Servers nicht auf Gültigkeit geprüft. Dadurch werden Ihre HTTPS-Verbindungen unsicher. --kube-tls-server-name string Servername für die Zertifikatsvalidierung des Kubernetes-API-Servers. Falls nicht angegeben, wird der Hostname verwendet, mit dem der Server kontaktiert wird. --kube-token string Bearer-Token für die Authentifizierung --kubeconfig string Pfad zur kubeconfig-Datei -n, --namespace string Namespace-Geltungsbereich für diese Anfrage --qps float32 Abfragen pro Sekunde bei der Kommunikation mit der Kubernetes-API (ohne Bursting) --registry-config string Pfad zur Registry-Konfigurationsdatei (Standard: "~/.config/helm/registry/config.json") --repository-cache string Pfad zum Verzeichnis mit zwischengespeicherten Repository-Indizes (Standard: "~/.cache/helm/repository") --repository-config string Pfad zur Datei mit Repository-Namen und URLs (Standard: "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- Verwaltet die Abhängigkeiten eines Charts ### Zusammenfassung Verwaltet die Abhängigkeiten eines Charts. Helm Charts speichern ihre Abhängigkeiten im Verzeichnis 'charts/'. Für Chart-Entwickler ist es oft einfacher, die Abhängigkeiten in der 'Chart.yaml' zu verwalten, die alle Abhängigkeiten deklariert. Die Dependency-Befehle arbeiten mit dieser Datei und erleichtern die Synchronisation zwischen den gewünschten Abhängigkeiten und den tatsächlich im Verzeichnis 'charts/' gespeicherten Abhängigkeiten. Beispielsweise deklariert diese Chart.yaml zwei Abhängigkeiten: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" Das Feld 'name' sollte den Namen eines Charts enthalten. Dieser muss mit dem Eintrag in der 'Chart.yaml'-Datei des jeweiligen Charts übereinstimmen. Das Feld 'version' sollte eine semantische Version oder einen Versionsbereich enthalten. Die 'repository'-URL sollte auf ein Chart Repository verweisen. Helm erwartet, dass durch Anhängen von '/index.yaml' an die URL der Index des Chart Repositorys abgerufen werden kann. Hinweis: 'repository' kann ein Alias sein. Der Alias muss mit 'alias:' oder '@' beginnen. Ab Version 2.2.0 kann repository auch als Pfad zum Verzeichnis der lokal gespeicherten Abhängigkeits-Charts definiert werden. Der Pfad sollte mit dem Präfix "file://" beginnen. Zum Beispiel: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" Wenn das Abhängigkeits-Chart lokal abgerufen wird, ist es nicht erforderlich, das Repository mit "helm repo add" zu Helm hinzuzufügen. Auch der Versionsabgleich wird in diesem Fall unterstützt. ### Optionen ``` -h, --help help for dependency ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - Erstellt das Verzeichnis charts/ basierend auf der Chart.lock-Datei neu * [helm dependency list](/helm/helm_dependency_list.md) - Listet die Abhängigkeiten für das angegebene Chart auf * [helm dependency update](/helm/helm_dependency_update.md) - Aktualisiert charts/ entsprechend dem Inhalt von Chart.yaml ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- Erstellt das Verzeichnis charts/ basierend auf der Chart.lock-Datei neu ### Zusammenfassung Baut das Verzeichnis charts/ anhand der Chart.lock-Datei auf. Dieser Befehl stellt die Abhängigkeiten eines Charts auf den Stand der Lock-Datei wieder her. Im Gegensatz zu 'helm dependency update' werden die Abhängigkeiten dabei nicht neu ausgehandelt. Falls keine Lock-Datei gefunden wird, verhält sich 'helm dependency build' wie 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm dependency](/helm/helm_dependency.md) - Verwaltet die Abhängigkeiten eines Charts ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- Listet die Abhängigkeiten für das angegebene Chart auf ### Zusammenfassung Listet alle in einem Chart deklarierten Abhängigkeiten auf. Dieser Befehl akzeptiert Chart-Archive und Chart-Verzeichnisse als Eingabe. Er verändert den Inhalt des Charts nicht. Falls das Chart nicht geladen werden kann, wird ein Fehler ausgegeben. ``` helm dependency list CHART [flags] ``` ### Optionen ``` -h, --help help for list --max-col-width uint maximum column width for output table (default 80) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm dependency](/helm/helm_dependency.md) - Verwaltet die Abhängigkeiten eines Charts ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- Aktualisiert charts/ entsprechend dem Inhalt von Chart.yaml ### Zusammenfassung Aktualisiert die lokalen Abhängigkeiten entsprechend der Chart.yaml. Dieser Befehl überprüft, ob die in 'Chart.yaml' angegebenen erforderlichen Charts im Verzeichnis 'charts/' vorhanden sind und eine passende Version haben. Er lädt die neuesten Charts herunter, die die Abhängigkeiten erfüllen, und entfernt veraltete Abhängigkeiten. Bei erfolgreicher Aktualisierung wird eine Lock-Datei erstellt, mit der die Abhängigkeiten auf eine exakte Version wiederhergestellt werden können. Abhängigkeiten müssen nicht zwingend in 'Chart.yaml' aufgeführt sein. Aus diesem Grund entfernt der update-Befehl Charts nur dann, wenn sie (a) in der Chart.yaml-Datei vorhanden sind, aber (b) die falsche Version haben. ``` helm dependency update CHART [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm dependency](/helm/helm_dependency.md) - Verwaltet die Abhängigkeiten eines Charts ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- Informationen zur Helm-Client-Umgebung ### Zusammenfassung Env gibt alle von Helm verwendeten Umgebungsinformationen aus. ``` helm env [flags] ``` ### Optionen ``` -h, --help help for env ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- Lädt erweiterte Informationen für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl besteht aus mehreren Unterbefehlen, um erweiterte Informationen über ein Release abzurufen, darunter: - Die zur Generierung des Releases verwendeten Values - Die generierte Manifest-Datei - Die vom Chart bereitgestellten Notizen zum Release - Die mit dem Release verbundenen Hooks - Die Metadaten des Releases ### Optionen ``` -h, --help help for get ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm get all](/helm/helm_get_all.md) - Lädt alle Informationen für ein benanntes Release herunter * [helm get hooks](/helm/helm_get_hooks.md) - Lädt alle Hooks für ein benanntes Release herunter * [helm get manifest](/helm/helm_get_manifest.md) - Lädt das Manifest für ein benanntes Release herunter * [helm get metadata](/helm/helm_get_metadata.md) - Ruft Metadaten für ein bestimmtes Release ab * [helm get notes](/helm/helm_get_notes.md) - Lädt die Notizen für ein benanntes Release herunter * [helm get values](/helm/helm_get_values.md) - Lädt die Values-Datei für ein benanntes Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- Lädt alle Informationen für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl gibt eine lesbare Sammlung von Informationen über die Notizen, Hooks, übergebene Values und die generierte Manifest-Datei des angegebenen Releases aus. ``` helm get all RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- Lädt alle Hooks für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl lädt die Hooks für ein bestimmtes Release herunter. Die Hooks werden im YAML-Format ausgegeben und durch den YAML-Trenner '---\n' voneinander getrennt. ``` helm get hooks RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for hooks --revision int get the named release with revision ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- Lädt das Manifest für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl ruft das generierte Manifest für ein bestimmtes Release ab. Ein Manifest ist eine YAML-kodierte Darstellung der Kubernetes-Ressourcen, die aus dem Chart (oder den Charts) dieses Releases generiert wurden. Wenn ein Chart von anderen Charts abhängt, werden auch deren Ressourcen im Manifest enthalten sein. ``` helm get manifest RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for manifest --revision int get the named release with revision ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Ruft die Metadaten für ein bestimmtes Release ab ### Zusammenfassung Dieser Befehl ruft die Metadaten für ein bestimmtes Release ab. ``` helm get metadata RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- Lädt die Notizen für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl zeigt die vom Chart bereitgestellten Notizen für ein benanntes Release an. ``` helm get notes RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for notes --revision int get the named release with revision ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- Lädt die Values-Datei für ein benanntes Release herunter ### Zusammenfassung Dieser Befehl lädt die Values-Datei für ein bestimmtes Release herunter. ``` helm get values RELEASE_NAME [flags] ``` ### Optionen ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm get](/helm/helm_get.md) - Lädt erweiterte Informationen zu einem benannten Release herunter ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- Zeigt die Release-Historie an ### Zusammenfassung History gibt die historischen Revisionen für ein bestimmtes Release aus. Standardmäßig werden maximal 256 Revisionen zurückgegeben. Mit '--max' können Sie die maximale Länge der zurückgegebenen Revisionsliste konfigurieren. Die historischen Releases werden als formatierte Tabelle ausgegeben, z.B.: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for history --max int maximum number of revision to include in history (default 256) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- Installiert ein Chart ### Zusammenfassung Dieser Befehl installiert ein Chart-Archiv. Als Argument für die Installation können Sie angeben: eine Chart-Referenz, einen Pfad zu einem gepackten Chart, einen Pfad zu einem entpackten Chart-Verzeichnis oder eine URL. Zum Überschreiben von Werten in einem Chart verwenden Sie das '--values'-Flag mit einer Datei oder das '--set'-Flag für Konfiguration über die Befehlszeile. Um String-Werte zu erzwingen, verwenden Sie '--set-string'. Mit '--set-file' können Sie einzelne Werte aus einer Datei setzen, wenn der Wert zu lang für die Befehlszeile ist oder dynamisch generiert wird. Mit '--set-json' können Sie JSON-Werte (Skalare/Objekte/Arrays) über die Befehlszeile setzen. $ helm install -f myvalues.yaml myredis ./redis oder $ helm install --set name=prod myredis ./redis oder $ helm install --set-string long_int=1234567890 myredis ./redis oder $ helm install --set-file my_script=dothings.sh myredis ./redis oder $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Das '--values'/'-f'-Flag kann mehrfach angegeben werden. Dabei hat die zuletzt angegebene Datei (ganz rechts) Vorrang. Wenn beispielsweise sowohl myvalues.yaml als auch override.yaml einen Schlüssel namens 'Test' enthalten, hat der in override.yaml gesetzte Wert Vorrang: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Das '--set'-Flag kann ebenfalls mehrfach angegeben werden. Dabei hat der zuletzt angegebene Wert (ganz rechts) Vorrang. Wenn beispielsweise sowohl 'bar' als auch 'newbar' als Werte für einen Schlüssel namens 'foo' gesetzt werden, hat der Wert 'newbar' Vorrang: $ helm install --set foo=bar --set foo=newbar myredis ./redis Im folgenden Beispiel wird 'foo' entsprechend auf '["four"]' gesetzt: $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis Und im folgenden Beispiel wird 'foo' auf '{"key1":"value1","key2":"bar"}' gesetzt: $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Um die generierten Manifeste eines Releases zu prüfen, ohne das Chart zu installieren, können die Flags --debug und --dry-run kombiniert werden. Das --dry-run-Flag zeigt alle generierten Chart-Manifeste an – auch Secrets mit möglicherweise sensiblen Werten. Um Kubernetes Secrets auszublenden, verwenden Sie das --hide-secret-Flag. Bitte bedenken Sie sorgfältig, wie und wann diese Flags verwendet werden. Wenn --verify gesetzt ist, MUSS das Chart eine Provenance-Datei haben, und die Provenance-Datei MUSS alle Verifizierungsschritte bestehen. Es gibt sechs verschiedene Möglichkeiten, das zu installierende Chart anzugeben: 1. Per Chart-Referenz: helm install mymaria example/mariadb 2. Per Pfad zu einem gepackten Chart: helm install mynginx ./nginx-1.2.3.tgz 3. Per Pfad zu einem entpackten Chart-Verzeichnis: helm install mynginx ./nginx 4. Per absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. Per Chart-Referenz und Repository-URL: helm install --repo https://example.com/charts/ mynginx nginx 6. Per OCI-Registry: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx CHART-REFERENZEN Eine Chart-Referenz ist eine praktische Methode, um auf ein Chart in einem Chart-Repository zu verweisen. Wenn Sie eine Chart-Referenz mit einem Repository-Präfix verwenden ('beispiel/mariadb'), sucht Helm in der lokalen Konfiguration nach einem Chart-Repository namens 'beispiel' und dann nach einem Chart mit dem Namen 'mariadb' in diesem Repository. Es wird die neueste stabile Version dieses Charts installiert, sofern Sie nicht das '--devel'-Flag setzen, um auch Entwicklungsversionen (Alpha-, Beta- und Release-Candidate-Versionen) einzubeziehen, oder eine Versionsnummer mit dem '--version'-Flag angeben. Um die Liste der Chart-Repositories anzuzeigen, verwenden Sie 'helm repo list'. Um nach Charts in einem Repository zu suchen, verwenden Sie 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Optionen ``` --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- Untersucht ein Chart auf mögliche Probleme ### Zusammenfassung Dieser Befehl erwartet einen Pfad zu einem Chart und führt eine Reihe von Tests durch, um zu überprüfen, ob das Chart korrekt aufgebaut ist. Wenn der Linter Probleme findet, die die Installation des Charts zum Scheitern bringen würden, gibt er [ERROR]-Meldungen aus. Wenn er auf Probleme stößt, die gegen Konventionen oder Empfehlungen verstoßen, gibt er [WARNING]-Meldungen aus. ``` helm lint PATH [flags] ``` ### Optionen ``` -h, --help help for lint --kube-version string Kubernetes version used for capabilities and deprecation checks --quiet print only warnings and errors --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-schema-validation if set, disables JSON schema validation --strict fail on lint warnings -f, --values strings specify values in a YAML file or a URL (can specify multiple) --with-subcharts lint dependent charts ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- Listet Releases auf ### Zusammenfassung Dieser Befehl listet alle Releases für einen angegebenen Namespace auf. Wird kein Namespace angegeben, wird der aktuelle Namespace-Kontext verwendet. Standardmäßig werden nur Releases aufgelistet, die deployed oder fehlgeschlagen sind. Flags wie '--uninstalled' und '--all' ändern dieses Verhalten. Diese Flags lassen sich kombinieren: '--uninstalled --failed'. Standardmäßig werden Elemente alphabetisch sortiert. Verwenden Sie das Flag '-d', um nach Release-Datum zu sortieren. Wenn das Flag --filter angegeben wird, dient es als Filter. Filter sind reguläre Ausdrücke (Perl-kompatibel), die auf die Liste der Releases angewendet werden. Nur Elemente, die dem Filter entsprechen, werden zurückgegeben. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Wenn keine Ergebnisse gefunden werden, beendet sich 'helm list' mit Exit-Code 0, jedoch ohne Ausgabe (bzw. nur mit Kopfzeilen, wenn das Flag '-q' nicht gesetzt ist). Standardmäßig können bis zu 256 Elemente zurückgegeben werden. Verwenden Sie das Flag '--max', um dies zu begrenzen. Das Setzen von '--max' auf 0 gibt nicht alle Ergebnisse zurück, sondern den Standardwert des Servers, der möglicherweise viel höher als 256 ist. In Kombination mit dem Flag '--offset' können Sie durch die Ergebnisse blättern. ``` helm list [flags] ``` ### Optionen ``` -a, --all show all releases without any filter applied -A, --all-namespaces list releases across all namespaces -d, --date sort by release date --deployed show deployed releases. If no other is specified, this will be automatically enabled --failed show failed releases -f, --filter string a regular expression (Perl compatible). Any releases that match the expression will be included in the results -h, --help help for list -m, --max int maximum number of releases to fetch (default 256) --no-headers don't print headers when using the default output format --offset int next release index in the list, used to offset from start value -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pending show pending releases -r, --reverse reverse the sort order -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Works only for secret(default) and configmap storage backends. -q, --short output short (quiet) listing format --superseded show superseded releases --time-format string format time using golang time formatter. Example: --time-format "2006-01-02 15:04:05Z0700" --uninstalled show uninstalled releases (if 'helm uninstall --keep-history' was used) --uninstalling show releases that are currently being uninstalled ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- Ein Chart-Verzeichnis in ein Chart-Archiv paketieren ### Zusammenfassung Dieser Befehl paketiert ein Chart in ein versioniertes Chart-Archiv. Bei Angabe eines Pfads wird dort nach einem Chart gesucht (das eine Chart.yaml-Datei enthalten muss), und dieses Verzeichnis wird dann paketiert. Versionierte Chart-Archive werden von Helm-Repositorys verwendet. Um ein Chart zu signieren, verwenden Sie das Flag '--sign'. In den meisten Fällen sollten Sie auch '--keyring path/to/secret/keys' und '--key keyname' angeben. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg Wenn '--keyring' nicht angegeben wird, verwendet Helm standardmäßig den öffentlichen Schlüsselbund, es sei denn, Ihre Umgebung ist anders konfiguriert. ``` helm package [CHART_PATH] [...] [flags] ``` ### Optionen ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- Helm Plugins installieren, auflisten oder deinstallieren ### Übersicht Verwaltet clientseitige Helm Plugins. ### Optionen ``` -h, --help help for plugin ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) - Installiert ein Helm-Plugin * [helm plugin list](/helm/helm_plugin_list.md) - Listet installierte Helm Plugins auf * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - Deinstalliert ein oder mehrere Helm Plugins * [helm plugin update](/helm/helm_plugin_update.md) - Aktualisiert ein oder mehrere Helm Plugins ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- Installiert ein Helm-Plugin ### Übersicht Mit diesem Befehl können Sie ein Plugin von der URL eines VCS-Repositorys oder von einem lokalen Pfad installieren. ``` helm plugin install [options] [flags] ``` ### Optionen ``` -h, --help help for install --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm plugin](/helm/helm_plugin.md) - Helm-Plugins installieren, auflisten oder deinstallieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- Listet installierte Helm Plugins auf ``` helm plugin list [flags] ``` ### Optionen ``` -h, --help help for list ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm plugin](/helm/helm_plugin.md) - Helm Plugins installieren, auflisten oder deinstallieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- Deinstalliert ein oder mehrere Helm Plugins ``` helm plugin uninstall ... [flags] ``` ### Optionen ``` -h, --help help for uninstall ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm plugin](/helm/helm_plugin.md) - Helm Plugins installieren, auflisten oder deinstallieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- Aktualisiert ein oder mehrere Helm Plugins ``` helm plugin update ... [flags] ``` ### Optionen ``` -h, --help help for update ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm plugin](/helm/helm_plugin.md) - Helm Plugins installieren, auflisten oder deinstallieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- Ein Chart aus einem Repository herunterladen und (optional) lokal entpacken ### Zusammenfassung Lädt ein Paket aus einem Chart-Repository herunter und speichert es lokal. Damit können Sie Pakete inspizieren, anpassen oder neu paketieren. Der Befehl kann auch verwendet werden, um eine kryptografische Verifizierung eines Charts durchzuführen, ohne es zu installieren. Mit entsprechenden Optionen kann das Chart nach dem Herunterladen entpackt werden. Dabei wird ein Verzeichnis für das Chart erstellt und der Inhalt dorthin extrahiert. Bei Verwendung des Flags --verify MUSS das angeforderte Chart über eine Provenance-Datei verfügen und den Verifizierungsprozess bestehen. Ein Fehler in einem dieser Schritte führt zu einem Abbruch und das Chart wird nicht lokal gespeichert. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- Ein Chart in eine Registry hochladen ### Zusammenfassung Lädt ein Chart in eine Registry hoch. Falls das Chart eine zugehörige Provenance-Datei hat, wird diese ebenfalls hochgeladen. ``` helm push [chart] [remote] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- Bei einer Registry an- oder abmelden ### Zusammenfassung Dieser Befehl besteht aus mehreren Unterbefehlen zur Interaktion mit Registries. ### Optionen ``` -h, --help help for registry ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm registry login](/helm/helm_registry_login.md) - Bei einer Registry anmelden * [helm registry logout](/helm/helm_registry_logout.md) - Von einer Registry abmelden ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- Bei einer Registry anmelden ### Zusammenfassung Authentifiziert sich bei einer entfernten Registry. ``` helm registry login [host] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm registry](/helm/helm_registry.md) - Bei einer Registry an- oder abmelden ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- Von einer Registry abmelden ### Zusammenfassung Entfernt die gespeicherten Anmeldeinformationen für eine entfernte Registry. ``` helm registry logout [host] [flags] ``` ### Optionen ``` -h, --help help for logout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm registry](/helm/helm_registry.md) - Bei einer Registry an- oder abmelden ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ### Zusammenfassung Dieser Befehl besteht aus mehreren Unterbefehlen zur Interaktion mit Chart Repositories. Mit diesem Befehl können Sie Chart Repositories hinzufügen, entfernen, auflisten und indizieren. ### Optionen ``` -h, --help help for repo ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm repo add](/helm/helm_repo_add.md) - Fügt ein Chart Repository hinzu * [helm repo index](/helm/helm_repo_index.md) - Erstellt eine Indexdatei für ein Verzeichnis mit gepackten Charts * [helm repo list](/helm/helm_repo_list.md) - Listet Chart Repositories auf * [helm repo remove](/helm/helm_repo_remove.md) - Entfernt ein oder mehrere Chart Repositories * [helm repo update](/helm/helm_repo_update.md) - Aktualisiert lokal die Informationen über verfügbare Charts aus den Chart Repositories ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- Fügt ein Chart Repository hinzu ``` helm repo add [NAME] [URL] [flags] ``` ### Optionen ``` --allow-deprecated-repos by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --force-update replace (overwrite) the repo if it already exists -h, --help help for add --insecure-skip-tls-verify skip tls certificate checks for the repository --key-file string identify HTTPS client using this SSL key file --no-update Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update. --pass-credentials pass credentials to all domains --password string chart repository password --password-stdin read chart repository password from stdin --timeout duration time to wait for the index file download to complete (default 2m0s) --username string chart repository username ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm repo](/helm/helm_repo.md) - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- Erstellt eine Indexdatei aus einem Verzeichnis mit gepackten Charts ### Zusammenfassung Liest das aktuelle Verzeichnis und erstellt basierend auf den gefundenen Charts eine Indexdatei. Das Ergebnis wird in 'index.yaml' im aktuellen Verzeichnis geschrieben. Dieses Werkzeug wird verwendet, um eine 'index.yaml'-Datei für ein Chart Repository zu erstellen. Um eine absolute URL für die Charts festzulegen, verwenden Sie das Flag '--url'. Um den generierten Index mit einer bestehenden Indexdatei zusammenzuführen, verwenden Sie das Flag '--merge'. In diesem Fall werden die Charts aus dem aktuellen Verzeichnis mit dem übergebenen Index zusammengeführt, wobei lokale Charts Vorrang vor bestehenden Charts haben. ``` helm repo index [DIR] [flags] ``` ### Optionen ``` -h, --help help for index --json output in JSON format --merge string merge the generated index into the given index --url string url of chart repository ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm repo](/helm/helm_repo.md) - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- Listet Chart Repositories auf ``` helm repo list [flags] ``` ### Optionen ``` -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm repo](/helm/helm_repo.md) - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- Entfernt ein oder mehrere Chart Repositories ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Optionen ``` -h, --help help for remove ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm repo](/helm/helm_repo.md) - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- Aktualisiert lokal die Informationen über verfügbare Charts aus den Chart Repositories ### Zusammenfassung Dieser Befehl lädt die neuesten Informationen über Charts aus den jeweiligen Chart Repositories herunter. Die Informationen werden lokal zwischengespeichert und von Befehlen wie 'helm search' verwendet. Sie können optional eine Liste von Repositories angeben, die Sie aktualisieren möchten. $ helm repo update ... Um alle Repositories zu aktualisieren, verwenden Sie 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Optionen ``` --fail-on-repo-update-fail update fails if any of the repository updates fail -h, --help help for update --timeout duration time to wait for the index file download to complete (default 2m0s) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm repo](/helm/helm_repo.md) - Chart Repositories hinzufügen, auflisten, entfernen, aktualisieren und indizieren ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- Setzt ein Release auf eine vorherige Revision zurück ### Zusammenfassung Dieser Befehl setzt ein Release auf eine vorherige Revision zurück. Das erste Argument des Rollback-Befehls ist der Name eines Release. Das zweite Argument ist eine Revisionsnummer (Version). Wird dieses Argument weggelassen oder auf 0 gesetzt, erfolgt ein Rollback auf das vorherige Release. Um Revisionsnummern anzuzeigen, führen Sie 'helm history RELEASE' aus. ``` helm rollback [REVISION] [flags] ``` ### Optionen ``` --cleanup-on-fail allow deletion of new resources created in this rollback when rollback fails --dry-run simulate a rollback --force force resource update through delete/recreate if needed -h, --help help for rollback --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --no-hooks prevent hooks from running during rollback --recreate-pods performs pods restart for the resource if applicable --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- Durchsucht Charts nach einem Suchbegriff ### Zusammenfassung Mit der Suchfunktion können Sie Helm Charts an verschiedenen Orten finden – darunter der Artifact Hub sowie von Ihnen hinzugefügte Repositories. Nutzen Sie die Unterbefehle, um an verschiedenen Orten nach Charts zu suchen. ### Optionen ``` -h, --help help for search ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm search hub](/helm/helm_search_hub.md) - Durchsucht den Artifact Hub oder Ihre eigene Hub-Instanz nach Charts * [helm search repo](/helm/helm_search_repo.md) - Durchsucht Repositories nach Charts anhand eines Suchbegriffs ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- Durchsucht den Artifact Hub oder Ihre eigene Hub-Instanz nach Charts ### Zusammenfassung Dieser Befehl sucht nach Helm Charts im Artifact Hub oder in Ihrer eigenen Hub-Instanz. Artifact Hub ist eine webbasierte Anwendung zum Finden, Installieren und Veröffentlichen von Paketen und Konfigurationen für CNCF-Projekte, einschließlich öffentlich verfügbarer Helm Charts. Es handelt sich um ein Sandbox-Projekt der Cloud Native Computing Foundation. Sie können den Hub unter https://artifacthub.io/ durchsuchen. Das [KEYWORD]-Argument akzeptiert entweder einen Suchbegriff oder eine in Anführungszeichen gesetzte erweiterte Suchanfrage (Rich Query). Die Dokumentation zu erweiterten Suchoptionen finden Sie unter https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Frühere Versionen von Helm verwendeten eine Monocular-Instanz als Standard- 'endpoint'. Zur Abwärtskompatibilität ist Artifact Hub mit der Monocular-Such-API kompatibel. Beim Setzen des 'endpoint'-Flags muss der angegebene Endpunkt ebenfalls eine Monocular-kompatible Such-API bereitstellen. Beachten Sie, dass bei Verwendung einer Monocular-Instanz als 'endpoint' erweiterte Suchanfragen nicht unterstützt werden. API-Details finden Sie unter https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Optionen ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm search](/helm/helm_search.md) - Durchsucht Charts nach einem Suchbegriff ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- Durchsucht Repositories nach Charts anhand eines Suchbegriffs ### Zusammenfassung Dieser Befehl durchsucht alle auf dem System konfigurierten Repositories und sucht nach Übereinstimmungen. Die Suche verwendet die auf dem System gespeicherten Metadaten. Standardmäßig werden die neuesten stabilen Versionen der gefundenen Charts angezeigt. Mit dem Flag --devel enthält die Ausgabe auch Vorabversionen. Um mit einer Versionsbeschränkung zu suchen, verwenden Sie --version. Beispiele: # Stabile Versionen mit Suchbegriff "nginx" suchen $ helm search repo nginx # Versionen mit Suchbegriff "nginx" suchen, einschließlich Vorabversionen $ helm search repo nginx --devel # Neuestes stabiles Release für nginx-ingress mit Hauptversion 1 suchen $ helm search repo nginx-ingress --version ^1.0.0 Repositories werden mit 'helm repo'-Befehlen verwaltet. ``` helm search repo [keyword] [flags] ``` ### Optionen ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm search](/helm/helm_search.md) - Durchsucht Charts nach einem Suchbegriff ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- Zeigt Informationen zu einem Chart an ### Zusammenfassung Dieser Befehl besteht aus mehreren Unterbefehlen zur Anzeige von Informationen über ein Chart ### Optionen ``` -h, --help help for show ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. * [helm show all](/helm/helm_show_all.md) - Zeigt alle Informationen eines Charts an * [helm show chart](/helm/helm_show_chart.md) - Zeigt die Definition des Charts an * [helm show crds](/helm/helm_show_crds.md) - Zeigt die CRDs des Charts an * [helm show readme](/helm/helm_show_readme.md) - Zeigt die README des Charts an * [helm show values](/helm/helm_show_values.md) - Zeigt die Values des Charts an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- Zeigt alle Informationen eines Charts an ### Zusammenfassung Dieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt dessen gesamten Inhalt an (values.yaml, Chart.yaml, README). ``` helm show all [CHART] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm show](/helm/helm_show.md) - Zeigt Informationen zu einem Chart an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- Zeigt die Definition des Charts an ### Zusammenfassung Dieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der Chart.yaml-Datei an. ``` helm show chart [CHART] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm show](/helm/helm_show.md) - Zeigt Informationen zu einem Chart an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- Zeigt die CRDs des Charts an ### Zusammenfassung Dieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der CustomResourceDefinition-Dateien an. ``` helm show crds [CHART] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm show](/helm/helm_show.md) - Zeigt Informationen zu einem Chart an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- Zeigt die README-Datei des Charts an ### Zusammenfassung Dieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der README-Datei an. ``` helm show readme [CHART] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm show](/helm/helm_show.md) - Zeigt Informationen zu einem Chart an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- Zeigt die Werte des Charts an ### Zusammenfassung Dieser Befehl untersucht ein Chart (Verzeichnis, Datei oder URL) und zeigt den Inhalt der values.yaml-Datei an. ``` helm show values [CHART] [flags] ``` ### Optionen ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm show](/helm/helm_show.md) - Zeigt Informationen zu einem Chart an ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- Zeigt den Status eines benannten Releases an ### Zusammenfassung Dieser Befehl zeigt den Status eines benannten Releases an. Der Status umfasst: - Zeitpunkt des letzten Deployments - Kubernetes-Namespace, in dem sich das Release befindet - Zustand des Releases (mögliche Werte: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade oder pending-rollback) - Revision des Releases - Beschreibung des Releases (kann eine Abschlussmeldung oder Fehlermeldung sein, erfordert --show-desc) - Liste der Ressourcen, aus denen dieses Release besteht (erfordert --show-resources) - Details zum letzten Testlauf, falls zutreffend - Zusätzliche Hinweise des Charts ``` helm status RELEASE_NAME [flags] ``` ### Optionen ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision --show-desc if set, display the description message of the named release --show-resources if set, display the resources of the named release ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- Rendert Templates lokal ### Zusammenfassung Rendert Chart-Templates lokal und zeigt die Ausgabe an. Alle Werte, die normalerweise im Cluster nachgeschlagen oder abgerufen würden, werden lokal simuliert. Zusätzlich findet keine serverseitige Validierung der Chart-Gültigkeit statt (z. B. ob eine API unterstützt wird). ``` helm template [NAME] [CHART] [flags] ``` ### Optionen ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- Führt Tests für ein Release aus ### Zusammenfassung Der test-Befehl führt die Tests für ein Release aus. Dieser Befehl erwartet den Namen eines installierten Releases als Argument. Die auszuführenden Tests sind im installierten Chart definiert. ``` helm test [RELEASE] [flags] ``` ### Optionen ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --hide-notes if set, do not show notes in test output. Does not affect presence in chart metadata --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- Deinstalliert ein Release ### Zusammenfassung Dieser Befehl nimmt einen Release-Namen entgegen und deinstalliert das Release. Er entfernt alle Ressourcen, die mit der letzten Version des Charts verbunden sind, sowie den Release-Verlauf und gibt ihn damit für zukünftige Verwendung frei. Verwenden Sie das '--dry-run'-Flag, um zu sehen, welche Releases deinstalliert werden, ohne sie tatsächlich zu deinstallieren. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Optionen ``` --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run simulate a uninstall -h, --help help for uninstall --ignore-not-found Treat "release not found" as a successful uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --no-hooks prevent hooks from running during uninstallation --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- Aktualisiert ein Release auf eine neue Version eines Charts ### Zusammenfassung Dieser Befehl aktualisiert ein Release auf eine neue Version eines Charts. Als Argumente für das Upgrade werden ein Release und ein Chart benötigt. Als Chart-Argument können Sie angeben: eine Chart-Referenz ('beispiel/mariadb'), einen Pfad zu einem Chart-Verzeichnis, ein gepacktes Chart oder eine vollqualifizierte URL. Bei Chart-Referenzen wird die neueste Version verwendet, sofern nicht das '--version'-Flag gesetzt ist. Zum Überschreiben von Werten in einem Chart verwenden Sie das '--values'-Flag mit einer Datei oder das '--set'-Flag für Konfiguration über die Befehlszeile. Um String-Werte zu erzwingen, verwenden Sie '--set-string'. Mit '--set-file' können Sie einzelne Werte aus einer Datei setzen, wenn der Wert zu lang für die Befehlszeile ist oder dynamisch generiert wird. Mit '--set-json' können Sie JSON-Werte (Skalare/Objekte/Arrays) über die Befehlszeile setzen. Das '--values'/'-f'-Flag kann mehrfach angegeben werden. Dabei hat die zuletzt angegebene Datei (ganz rechts) Vorrang. Wenn beispielsweise sowohl myvalues.yaml als auch override.yaml einen Schlüssel namens 'Test' enthalten, hat der in override.yaml gesetzte Wert Vorrang: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Das '--set'-Flag kann ebenfalls mehrfach angegeben werden. Dabei hat der zuletzt angegebene Wert (ganz rechts) Vorrang. Wenn beispielsweise sowohl 'bar' als auch 'newbar' als Werte für einen Schlüssel namens 'foo' gesetzt werden, hat der Wert 'newbar' Vorrang: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis Mit dem '--reuse-values'-Flag können Sie auch Werte eines bestehenden Releases aktualisieren. Die Argumente 'RELEASE' und 'CHART' sollten auf die ursprünglichen Parameter gesetzt werden. Bestehende Werte werden dann mit allen über '--values'/'-f' oder '--set'-Flags gesetzten Werten zusammengeführt. Neue Werte haben Vorrang. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis Das --dry-run-Flag zeigt alle generierten Chart-Manifeste an – auch Secrets mit möglicherweise sensiblen Werten. Um Kubernetes Secrets auszublenden, verwenden Sie das --hide-secret-Flag. Bitte bedenken Sie sorgfältig, wie und wann diese Flags verwendet werden. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Optionen ``` --atomic if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- Überprüft, ob ein Chart am angegebenen Pfad signiert wurde und gültig ist ### Zusammenfassung Überprüft, ob das angegebene Chart über eine gültige Provenance-Datei verfügt. Provenance-Dateien ermöglichen die kryptografische Verifizierung, dass ein Chart nicht manipuliert wurde und von einem vertrauenswürdigen Anbieter paketiert wurde. Verwenden Sie diesen Befehl, um ein lokales Chart zu überprüfen. Andere Befehle bieten ebenfalls '--verify'-Flags, die dieselbe Validierung durchführen. Um ein signiertes Paket zu erstellen, verwenden Sie den Befehl 'helm package --sign'. ``` helm verify PATH [flags] ``` ### Optionen ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- Gibt die Client-Versionsinformationen aus ### Zusammenfassung Zeigt die Version von Helm an. Dieser Befehl gibt die Helm-Versionsinformationen aus. Die Ausgabe sieht etwa so aus: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version ist die semantische Version des Releases. - GitCommit ist der SHA des Commits, aus dem diese Version erstellt wurde. - GitTreeState ist "clean", wenn beim Erstellen dieser Binary keine lokalen Code-Änderungen vorhanden waren, und "dirty", wenn die Binary aus lokal modifiziertem Code erstellt wurde. - GoVersion ist die Go-Version, mit der Helm kompiliert wurde. Bei Verwendung des Flags --template stehen folgende Eigenschaften für das Template zur Verfügung: - .Version enthält die semantische Version von Helm - .GitCommit ist der Git-Commit - .GitTreeState ist der Zustand des Git-Baums beim Erstellen von Helm - .GoVersion enthält die Go-Version, mit der Helm kompiliert wurde Beispiel: --template='Version: {{.Version}}' gibt 'Version: v3.2.1' aus. ``` helm version [flags] ``` ### Optionen ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### Optionen von übergeordneten Befehlen ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SIEHE AUCH * [helm](/helm/helm.md) - Der Helm-Paketmanager für Kubernetes. ###### Automatisch generiert von spf13/cobra am 14-Jan-2026 ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action zur Automatisierung von GitHub Pages Charts description: Beschreibt, wie Sie die Chart Releaser Action verwenden, um die Veröffentlichung von Charts über GitHub Pages zu automatisieren. sidebar_position: 3 --- Diese Anleitung beschreibt, wie Sie die [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) verwenden, um die Veröffentlichung von Charts über GitHub Pages zu automatisieren. Die Chart Releaser Action ist ein GitHub Action Workflow, der Ihr GitHub-Projekt in ein selbst-gehostetes Helm Chart Repository verwandelt, unter Verwendung des CLI-Werkzeugs [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Repository-Änderungen Erstellen Sie ein Git-Repository unter Ihrer GitHub-Organisation. Sie können das Repository beispielsweise `helm-charts` nennen, andere Namen sind aber auch möglich. Die Quelldateien aller Charts können im `main` Branch liegen. Die Charts sollten unter dem Verzeichnis `/charts` auf oberster Verzeichnisebene abgelegt werden. Es sollte einen weiteren Branch namens `gh-pages` geben, um die Charts zu veröffentlichen. Die Änderungen an diesem Branch werden automatisch von der hier beschriebenen Chart Releaser Action erstellt. Sie können jedoch den `gh-pages` Branch erstellen und eine `README.md` Datei hinzufügen, die für Besucher der Seite sichtbar sein wird. Sie können in der `README.md` Installationsanweisungen für die Charts hinzufügen, etwa so (ersetzen Sie ``, `` und ``): ``` ## Verwendung [Helm](https://helm.sh) muss installiert sein, um die Charts zu verwenden. Bitte lesen Sie die Helm [Dokumentation](https://helm.sh/docs) für den Einstieg. Sobald Helm eingerichtet ist, fügen Sie das Repository wie folgt hinzu: helm repo add https://.github.io/helm-charts Falls Sie dieses Repository bereits früher hinzugefügt haben, führen Sie `helm repo update` aus, um die neuesten Versionen der Pakete abzurufen. Mit `helm search repo ` können Sie dann die Charts anzeigen. Um das Chart zu installieren: helm install my- / Um das Chart zu deinstallieren: helm uninstall my- ``` Die Charts werden auf einer Website mit einer URL wie dieser veröffentlicht: https://.github.io/helm-charts ## GitHub Actions Workflow Erstellen Sie eine GitHub Actions Workflow-Datei im `main` Branch unter `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` Die obige Konfiguration verwendet [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), um Ihr GitHub-Projekt in ein selbst-gehostetes Helm Chart Repository zu verwandeln. Bei jedem Push auf main prüft die Action jedes Chart in Ihrem Projekt. Wenn eine neue Chart-Version vorliegt, wird ein entsprechendes GitHub Release erstellt, das nach der Chart-Version benannt ist. Die Helm Chart Artefakte werden dem Release hinzugefügt und eine `index.yaml` Datei mit Metadaten über diese Releases wird erstellt oder aktualisiert. Diese wird dann auf GitHub Pages gehostet. Die im obigen Beispiel verwendete Versionsnummer der Chart Releaser Action ist `v1.6.0`. Sie können diese zur [neuesten verfügbaren Version](https://github.com/helm/chart-releaser-action/releases) ändern. Hinweis: Die Chart Releaser Action wird fast immer zusammen mit der [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) und der [Kind Action](https://github.com/marketplace/actions/kind-cluster) verwendet. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: "Synchronisieren Ihres Chart Repository" description: "Beschreibt wie Sie lokale und entfernte Chart Repositories synchronisieren." sidebar_position: 2 --- *Hinweis: Dieses Beispiel richtet sich an einen Google Cloud Storage (GCS) Bucket, welcher ein Chart Repository bereitstellt.* ## Vorbedingungen * Installieren Sie das [gsutil](https://cloud.google.com/storage/docs/gsutil) Werkzeug. *Wir lehnen uns stark an die gsutil rsync Funktionalität* * Stellen Sie sicher, dass Sie Zugriff auf das Helm Programm haben * _Optional: Wir empfehlen, dass Sie die [Objektversionierung](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) in Ihrem GCS Bucket gesetzt haben, falls Sie etwas versehentlich löschen._ ## Ein lokales Chart Repository Verzeichnis aufsetzen Erstellen Sie ein lokales Verzeichnis wie wir es im [Chart Repository Handbuch](/topics/chart_repository.md) gemacht haben und legen Sie Ihr Chart Paket in das Verzeichnis. Zum Beispiel: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Generieren einer aktualisierten index.yaml Benutzen Sie Helm zum Generieren einer aktualisierten index.yaml Datei durch Aufruf des Verzeichnisses und der URL des entfernten Repository durch das `helm repo index` Kommando wie: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Dies wird eine aktualisierte index.yaml Datei erstellen und in das Verzeichnis `fantastic-charts/` legen. ## Synchronisieren Ihrer lokalen und entfernten Chart Repositories Laden Sie den Inhalt des Verzeichnisses in Ihren GCS Bucket, indem Sie das Programm `scripts/sync-repo.sh` aufrufen und im lokalen Verzeichnis den Verzeichnisnamen und den Namen des GCS Bucket angeben. Zum Beispiel: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Aktualisieren Ihres Chart Repository Sie möchten eine lokale Kopie des Inhalts Ihres Chart Repository behalten oder `gsutil rsync` zum Kopieren des Inhalts Ihres entfernten Chart Repository zu Ihrem lokalen Verzeichnis verwenden. Zum Beispiel: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Hilfreiche Links: * Dokumentation von [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Das Chart Repository Handbuch](/topics/chart_repository.md) * Dokumentation von [Objektversionierung und parallele Zugriffe](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: "Chart-Entwicklung: Tipps und Tricks" description: "Beschreibt Tipps und Tricks, die Helm Chart-Entwickler bei der Erstellung von produktionsreifen Charts gelernt haben." sidebar_position: 1 --- Dieses Handbuch beschreibt Tipps und Tricks, die Helm Chart-Entwickler bei der Erstellung von produktionsreifen Charts gelernt haben. ## Kennen Sie Ihre Vorlagenfunktionen Helm verwendet [Go Templates](https://godoc.org/text/template) für die Vorlagen Ihrer Ressourcendateien. Go liefert bereits einige eingebaute Funktionen mit, wir haben jedoch viele weitere hinzugefügt. Zunächst haben wir alle Funktionen aus der [Sprig-Bibliothek](https://masterminds.github.io/sprig/) hinzugefügt, mit Ausnahme von `env` und `expandenv` aus Sicherheitsgründen. Wir haben außerdem zwei spezielle Vorlagenfunktionen hinzugefügt: `include` und `required`. Die `include`-Funktion ermöglicht es Ihnen, eine andere Vorlage einzubinden und das Ergebnis an weitere Vorlagenfunktionen zu übergeben. Das folgende Beispiel bindet eine Vorlage namens `mytpl` ein, wandelt das Ergebnis in Kleinbuchstaben um und setzt es in Anführungszeichen. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` Die `required`-Funktion ermöglicht es Ihnen, einen bestimmten Werteeintrag als erforderlich für das Vorlagenrendering zu deklarieren. Wenn der Wert leer ist, schlägt das Rendern fehl und gibt eine vom Entwickler definierte Fehlermeldung aus. Das folgende Beispiel der `required`-Funktion deklariert einen Eintrag für `.Values.who` als erforderlich und gibt eine Fehlermeldung aus, wenn dieser fehlt: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Strings in Anführungszeichen setzen, Integers nicht Wenn Sie mit Stringdaten arbeiten, sind Sie immer auf der sicheren Seite, wenn Sie Strings in Anführungszeichen setzen: ```yaml name: {{ .Values.MyName | quote }} ``` Bei Integers hingegen sollten Sie die Werte _nicht_ in Anführungszeichen setzen. Das kann in vielen Fällen zu Parsing-Fehlern in Kubernetes führen. ```yaml port: {{ .Values.Port }} ``` Dieser Hinweis gilt nicht für Umgebungsvariablen, die immer als String erwartet werden, auch wenn sie Integers repräsentieren: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Verwendung der 'include'-Funktion Go bietet die Möglichkeit, über die eingebaute `template`-Direktive eine Vorlage in eine andere einzubinden. Die eingebaute Funktion kann jedoch nicht in Go Template Pipelines verwendet werden. Um es zu ermöglichen, eine Vorlage einzubinden und dann eine Operation auf der Ausgabe dieser Vorlage durchzuführen, bietet Helm eine spezielle `include`-Funktion: ``` {{ include "toYaml" $value | indent 2 }} ``` Dies bindet eine Vorlage namens `toYaml` ein, übergibt ihr `$value` und leitet dann die Ausgabe dieser Vorlage an die `indent`-Funktion weiter. Da YAML Einrückungen und Leerzeichen große Bedeutung beimisst, ist dies ein hervorragender Weg, Code-Snippets einzubinden und dabei die Einrückung im relevanten Kontext zu handhaben. ## Verwendung der 'required'-Funktion Go bietet die Möglichkeit, Vorlagenoptionen zu setzen, um das Verhalten zu steuern, wenn auf eine Map mit einem nicht vorhandenen Schlüssel zugegriffen wird. Dies wird typischerweise mit `template.Options("missingkey=option")` gesetzt, wobei `option` die Werte `default`, `zero` oder `error` haben kann. Während das Setzen dieser Option auf error die Ausführung mit einem Fehler stoppt, würde dies für jeden fehlenden Schlüssel in der Map gelten. Es gibt jedoch Situationen, in denen Chart-Entwickler dieses Verhalten nur für bestimmte Werte in der `values.yaml`-Datei erzwingen möchten. Die `required`-Funktion gibt Entwicklern die Möglichkeit, einen Werteeintrag als erforderlich für das Vorlagenrendering zu deklarieren. Wenn der Eintrag in `values.yaml` leer ist, wird die Vorlage nicht gerendert und gibt eine vom Entwickler bereitgestellte Fehlermeldung zurück. Zum Beispiel: ``` {{ required "A valid foo is required!" .Values.foo }} ``` Das obige Beispiel rendert die Vorlage, wenn `.Values.foo` definiert ist, schlägt aber fehl, wenn `.Values.foo` nicht definiert ist. ## Verwendung der 'tpl'-Funktion Die `tpl`-Funktion ermöglicht es Entwicklern, Strings innerhalb einer Vorlage als Vorlagen auszuwerten. Dies ist nützlich, um einen Vorlagenstring als Wert an ein Chart zu übergeben oder externe Konfigurationsdateien zu rendern. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}` Beispiele: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Rendern einer externen Konfigurationsdatei: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Erstellen von Image Pull Secrets Image Pull Secrets sind im Wesentlichen eine Kombination aus _Registry_, _Benutzername_ und _Passwort_. Sie benötigen diese möglicherweise in einer Anwendung, die Sie bereitstellen, aber zum Erstellen müssen Sie `base64` mehrfach ausführen. Wir können eine Hilfsvorlage schreiben, um die Docker-Konfigurationsdatei als Payload für das Secret zu erstellen. Hier ist ein Beispiel: Zunächst nehmen wir an, dass die Zugangsdaten in der `values.yaml`-Datei wie folgt definiert sind: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Dann definieren wir unsere Hilfsvorlage wie folgt: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Schließlich verwenden wir die Hilfsvorlage in einer größeren Vorlage, um das Secret-Manifest zu erstellen: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Automatisches Rollout von Deployments Häufig werden ConfigMaps oder Secrets als Konfigurationsdateien in Container injiziert, oder es gibt andere externe Abhängigkeitsänderungen, die ein Rollout der Pods erfordern. Abhängig von der Anwendung kann ein Neustart erforderlich sein, wenn diese bei einem nachfolgenden `helm upgrade` aktualisiert werden. Wenn sich jedoch die Deployment-Spezifikation selbst nicht geändert hat, läuft die Anwendung weiterhin mit der alten Konfiguration, was zu einer inkonsistenten Bereitstellung führt. Die `sha256sum`-Funktion kann verwendet werden, um sicherzustellen, dass der Annotation-Abschnitt eines Deployments aktualisiert wird, wenn sich eine andere Datei ändert: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` HINWEIS: Wenn Sie dies zu einem Library Chart hinzufügen, können Sie nicht auf Ihre Datei über `$.Template.BasePath` zugreifen. Stattdessen können Sie Ihre Definition mit `{{ include ("mylibchart.configmap") . | sha256sum }}` referenzieren. Falls Sie Ihr Deployment immer neu ausrollen möchten, können Sie einen ähnlichen Annotation-Schritt wie oben verwenden, aber stattdessen einen zufälligen String einsetzen, sodass sich dieser immer ändert und ein Rollout des Deployments auslöst: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Jeder Aufruf der Vorlagenfunktion generiert einen eindeutigen zufälligen String. Das bedeutet, wenn es notwendig ist, die von mehreren Ressourcen verwendeten zufälligen Strings zu synchronisieren, müssen sich alle relevanten Ressourcen in derselben Vorlagendatei befinden. Beide Methoden ermöglichen es Ihrem Deployment, die eingebaute Update-Strategie-Logik zu nutzen, um Ausfallzeiten zu vermeiden. HINWEIS: In der Vergangenheit haben wir die Verwendung des `--recreate-pods`-Flags als weitere Option empfohlen. Dieses Flag wurde in Helm 3 als veraltet markiert, zugunsten der oben beschriebenen deklarativen Methode. ## Helm anweisen, eine Ressource nicht zu deinstallieren Manchmal gibt es Ressourcen, die nicht deinstalliert werden sollten, wenn Helm `helm uninstall` ausführt. Chart-Entwickler können einer Ressource eine Annotation hinzufügen, um das Deinstallieren zu verhindern. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` Die Annotation `helm.sh/resource-policy: keep` weist Helm an, das Löschen dieser Ressource zu überspringen, wenn eine Helm-Operation (wie `helm uninstall`, `helm upgrade` oder `helm rollback`) normalerweise zu ihrer Löschung führen würde. _Allerdings_ wird diese Ressource dann verwaist. Helm wird sie in keiner Weise mehr verwalten. Dies kann zu Problemen führen, wenn `helm install --replace` für ein Release verwendet wird, das bereits deinstalliert wurde, aber Ressourcen behalten hat. ## Verwendung von "Partials" und Template-Includes Manchmal möchten Sie wiederverwendbare Teile in Ihrem Chart erstellen, sei es als Blöcke oder Template-Partials. Oft ist es sauberer, diese in eigenen Dateien zu halten. Im `templates/`-Verzeichnis wird von keiner Datei, die mit einem Unterstrich (`_`) beginnt, erwartet, dass sie eine Kubernetes-Manifest-Datei ausgibt. Daher werden Hilfsvorlagen und Partials konventionsgemäß in einer `_helpers.tpl`-Datei platziert. ## Komplexe Charts mit vielen Abhängigkeiten Viele Charts im CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) sind "Bausteine" zur Erstellung fortgeschrittener Anwendungen. Charts können jedoch auch verwendet werden, um Instanzen von großangelegten Anwendungen zu erstellen. In solchen Fällen kann ein einzelnes Umbrella-Chart mehrere Subcharts haben, von denen jedes als Teil des Ganzen fungiert. Die aktuelle Best Practice für das Zusammenstellen einer komplexen Anwendung aus einzelnen Teilen ist die Erstellung eines Top-Level-Umbrella-Charts, das die globalen Konfigurationen exponiert, und dann die Verwendung des `charts/`-Unterverzeichnisses zum Einbetten jeder der Komponenten. ## YAML ist eine Obermenge von JSON Laut der YAML-Spezifikation ist YAML eine Obermenge von JSON. Das bedeutet, dass jede gültige JSON-Struktur auch in YAML gültig sein sollte. Dies hat einen Vorteil: Manchmal finden es Vorlagenentwickler einfacher, eine Datenstruktur mit einer JSON-ähnlichen Syntax auszudrücken, anstatt sich mit YAMLs Empfindlichkeit gegenüber Leerzeichen auseinanderzusetzen. Als Best Practice sollten Vorlagen einer YAML-ähnlichen Syntax folgen, _es sei denn_, die JSON-Syntax reduziert das Risiko eines Formatierungsproblems erheblich. ## Vorsicht beim Generieren zufälliger Werte Es gibt Funktionen in Helm, die es ermöglichen, zufällige Daten, kryptographische Schlüssel usw. zu generieren. Diese können problemlos verwendet werden. Beachten Sie jedoch, dass Vorlagen bei Upgrades erneut ausgeführt werden. Wenn ein Vorlagenlauf Daten generiert, die sich vom letzten Lauf unterscheiden, löst dies ein Update dieser Ressource aus. ## Installieren oder Aktualisieren eines Releases mit einem Befehl Helm bietet die Möglichkeit, eine Installation oder ein Upgrade als einzelnen Befehl auszuführen. Verwenden Sie `helm upgrade` mit der `--install`-Option. Dies veranlasst Helm zu prüfen, ob das Release bereits installiert ist. Falls nicht, führt es eine Installation durch. Falls ja, wird das vorhandene Release aktualisiert. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: "Lernprogramme" sidebar_position: 2 --- # Wie-geht-Anleitungen (How-Tos) Hier finden Sie eine schnelle Antwort auf die Fragen “Wie kann ich…?”. Diese Wie-geht- Anleitungen besprechen die Themen nicht in der Tiefe - dieses Material finden Sie in den [Themenhandbüchern](/topics/index.mdx). Diese Anleitungen helfen Ihnen zum schnellen Erfüllen der üblichen Aufgaben. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Dokumentation" description: "Alles Wissenswerte zur Organisation der Dokumentation." --- # Willkommen Willkommen zur [Helm](https://helm.sh/) Dokumentation. Helm ist der Paket Manager für Kubernetes. Genauere Hintergrundinformationen gibt es im [CNCF Helm Projekt Reisebericht](https://www.cncf.io/cncf-helm-project-journey/). # Wie die Dokumentation aufgebaut ist Helm hat eine Menge Dokumentation. Eine Hauptübersicht ist hilfreich, nach bestimmten Dingen zu suchen: - [Lernprogramme](/intro/index.mdx) sind eine gute Handhabe, um das erste Helm Chart zu erstellen. Starten Sie hier, wenn Sie neu bei Helm sind. - [Themenhandbücher](/topics/index.mdx) diskutieren Hauptthemen und Konzepte auf einem hohen Niveau und stellen nützliche Hintergrundinformationen und Erklärungen zur Verfügung. - [Gemeinschaftshandbücher](/community) diskutieren Themen rund um die Helm Gemeinschaft. Starten Sie hier, wenn Sie mehr über den Entwicklungsprozess von Helm lernen möchten und wie Sie dazu beitragen können. - [Anleitungen](/howto/index.mdx) sind wie Rezepte. Sie werden durch die einzelnen Schritte der Hauptprobleme und Anwendungsfälle geleitet. Anleitungen sind mehr fortgeschritten als Themenhandbücher und setzen Wissen voraus, wie Helm funktioniert. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Spickzettel description: Helm Spickzettel sidebar_position: 4 --- Dieser Helm Spickzettel enthält alle notwendigen Befehle, die Sie zur Verwaltung einer Anwendung mit Helm benötigen. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Grundlegende Begriffe und Kontext Chart: - Der Name Ihres Charts, falls es heruntergeladen und entpackt wurde. - `/`, falls das Repository hinzugefügt, aber das Chart nicht heruntergeladen wurde. - Die URL oder der absolute Pfad zum Chart. Name: - Der Name, den Sie Ihrer aktuellen Helm Chart Installation geben möchten. Release: - Der Name, den Sie einer Installationsinstanz zugewiesen haben. Revision: - Der Wert aus dem `helm history` Befehl. Repo-name: - Der Name eines Repository. DIR: - Verzeichnisname oder Pfad. ------------------------------------------------------------------------------------------------------------------------------------------------ ### Chart Verwaltung ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart's dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Anwendungen installieren und deinstallieren ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Anwendungs-Upgrade und Rollback durchführen ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Repositories auflisten, hinzufügen, entfernen und aktualisieren ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm Release Überwachung ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Release-Informationen herunterladen ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Plugin Verwaltung ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: "Einführung" sidebar_position: 1 --- # Einführung in Helm Neu in Helm? Hier ist der Weg zum Start! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: "Helm installieren" description: "Lernen Sie wie man Helm installiert und zum Laufen kriegt." sidebar_position: 2 --- Diese Anleitung zeigt, wie Helm CLI zu installieren ist. Helm kann sowohl vom Quellcode als auch vorkompilierten Binaries installiert werden. ## Vom Helm Projekt Das Helm Projekt stellt zwei Wege zum Beziehen und Installieren von Helm zur Verfügung. Dies sind die offiziellen Methoden, um Helm Versionen zu bekommen. Zusätzlich zu dem stellt die Helm Gemeinschaft Methoden zur Installation mit verschiedenen Paketmanagern zur Verfügung. Die Installation mit diesen Methoden können am Ende der Anleitung zu den offiziellen Methoden gelesen werden. ### Von Binary Versionen Jede [Version](https://github.com/helm/helm/releases) von Helm stellt Binary Versionen für verschiedene Betriebssysteme zur Verfügung. Diese Binary Versionen kann man herunterladen und installieren. 1. Laden Sie die [gewünschte Version](https://github.com/helm/helm/releases) herunter 2. Entpacken Sie diese (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Finden Sie das Helm Binary im entpackten Verzeichnis und verschieben es zum gewünschten Ziel (`mv linux-amd64/helm /usr/local/bin/helm`) Von dort aus sollten Sie in der Lage sein, das Programm aufzurufen und ein [erstes Repo hinzuzufügen](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Hinweis:** In den automatisierten Tests von Helm wird nur die Version von Linux AMD64 beim Bau durch GitHub Actions berücksichtigt. Das Testen von anderen Betriebssystemen liegt in der Zuständigkeit der Gemeinschaft. ### Von einem Script Helm hat ein Installations-Script, mit der automatisch die neueste Version bezogen und [lokal installiert wird](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Sie können dieses Script aufrufen und lokal ausführen. Es ist gut dokumentiert, so dass Sie es lesen und gut verstehen können, bevor Sie es ausführen. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Ja, Sie können auch `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` aufrufen, wenn Sie am Rande des Abgrunds leben. ## Durch einen Paket Manager Die Helm Gemeinschaft stellt auch die Möglichkeit der Installation durch Paketmanager des Betriebssystems zur Verfügung. Diese werden vom Helm Projekt nicht unterstützt und gelten nicht als vertrauenswürdige Drittanbieter. ### Von Homebrew (macOS) Mitglieder der Helm Gemeinschaft haben eine Form des Baus durch Homebrew zur Verfügung gestellt. Diese Form ist generell immer aktuell. ```console brew install helm ``` (Hinweis: Es gibt noch eine Form von emacs-helm, was ein anderes Projekt ist.) ### Von Chocolatey (Windows) Mitglieder der Helm Gemeinschaft haben ein [Helm Paket](https://chocolatey.org/packages/kubernetes-helm) für [Chocolatey](https://chocolatey.org/) beigetragen. Dieses Paket ist generell aktuell. ```console choco install kubernetes-helm ``` ### Von Scoop (Windows) Mitglieder der Helm Gemeinschaft haben ein [Helm Paket](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) für [Scoop](https://scoop.sh) beigetragen. Dieses Paket ist generell aktuell. ```console scoop install helm ``` ### Von Winget (Windows) Mitglieder der Helm Gemeinschaft haben ein [Helm Paket](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) für [Winget](https://learn.microsoft.com/en-us/windows/package-manager/) beigetragen. Dieses Paket ist generell aktuell. ```console winget install Helm.Helm ``` ### Von Apt (Debian/Ubuntu) Mitglieder der Helm Gemeinschaft haben ein Apt-Paket für Debian/Ubuntu beigetragen. Dieses Paket ist generell aktuell. Vielen Dank an [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) für das Hosten des Repositorys. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Von dnf/yum (Fedora) Seit Fedora 35 ist Helm im offiziellen Repository verfügbar. Sie können Helm mit folgendem Befehl installieren: ```console sudo dnf install helm ``` ### Von Snap Die [Snapcrafters](https://github.com/snapcrafters) Gemeinschaft unterstützt die Snap Version vom [Helm Paket](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### Von pkg (FreeBSD) Mitglieder der FreeBSD-Gemeinschaft haben ein [Helm Paket](https://www.freshports.org/sysutils/helm) für die [FreeBSD Ports Collection](https://man.freebsd.org/ports) beigetragen. Dieses Paket ist generell aktuell. ```console pkg install helm ``` ### Entwickler Builds Zusätzlich zu den Versionen können auch Entwicklerkopien von Helm installiert werden. ### Von Canary Builds "Canary" Builds sind Versionen der Helm Software, die aus dem aktuellen `main`-Branch gebaut werden. Das sind keine offiziellen Versionen und sind möglicherweise nicht stabil. Sie bieten die Möglichkeit, die neuesten Funktionen zu testen. Canary Helm Binaries sind unter `get.helm.sh` verfügbar. Hier sind die Links zu den üblichen Builds: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Vom Quellcode (Linux, macOS) Das Bauen von Helm vom Quellcode ist etwas aufwändiger, aber es ist die beste Möglichkeit, die neueste (noch nicht veröffentlichte) Version von Helm zu testen. Sie brauchen eine Go Arbeitsumgebung. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` Wenn erforderlich, werden die Abhängigkeiten heruntergeladen und zwischengespeichert. Die Konfiguration wird validiert und Helm nach `bin/helm` kompiliert. ## Zusammenfassung In den meisten Fällen ist die Installation einfach durch das Beziehen der vorkompilierten Helm Binaries. Dieses Dokument deckt zusätzliche Fälle ab für Leute, die anspruchsvolle Dinge mit Helm bewerkstelligen wollen. Wenn Sie das Helm Programm erfolgreich installiert haben, können Sie zur Verwaltung von Charts und [Hinzufügen des stabilen Repos](/intro/quickstart.md#initialize-a-helm-chart-repository) wechseln. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: "Schnellstartanleitung" description: "Wie mit Helm anfangen, incl. Anleitungen für Distributionen, FAQs und Plugins." sidebar_position: 1 --- Mit dieser Anleitung können Sie schnell mit Helm starten. ## Vorbedingungen Die folgenden Vorbedingungen sind erforderlich, um Helm erfolgreich und sicher zu nutzen. 1. Ein Kubernetes Cluster 2. Entscheiden, welche Sicherheitskonfigurationen zur Installation verwendet werden 3. Installieren und konfigurieren von Helm. ### Installieren von Kubernetes oder Zugriff auf einen Cluster haben - Sie müssen Kubernetes installiert haben. Für die letzte Version von Helm empfehlen wir die letzte stabile Version von Kubernetes, was in den meisten Fällen die zweitletzte Unterversion ist. - Sie sollten eine lokale Kopie eines konfigurierten kubectl haben. Sehen Sie die [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) für die maximal unterstützte Version zwischen Helm und Kubernetes. ## Installieren von Helm Laden Sie eine Binary Version von Helm herunter. Sie können Werkzeuge verwenden wie homebrew oder schauen Sie auf [die offizielle Versionsseite](https://github.com/helm/helm/releases). Für mehr Details oder weitere Optionen schauen Sie in die [Installationsanleitung](/intro/install.md). ## Initialisieren eines Helm Chart Repository {#initialize-a-helm-chart-repository} Wenn Sie Helm installiert haben, können Sie ein Chart Repository hinzufügen. Schauen Sie nach [Artifact Hub](https://artifacthub.io/packages/search?kind=0) für verfügbare Helm Chart Repositories. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Einmal installiert können Sie die installierbaren Charts auflisten: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Installieren eines Beispiel Chart Um ein Chart zu installieren, können Sie das `helm install` Kommando verwenden. Helm kennt verschieden Wege, um ein Chart zu finden und zu installieren, aber am einfachsten ist die Verwendung des `bitnami` Charts. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` Im Beispiel oben wurde das `bitnami/mysql` Chart versioniert und der Name der neuen Version ist `mysql-1612624192`. Sie kriegen eine grobe Idee über die Funktionen dieses MySQL Charts mit dem Kommando `helm show chart bitnami/mysql`. Oder dem Kommando `helm show all bitnami/mysql`, um alle Informationen über das Chart zu bekommen. Wennimmer Sie ein Chart installieren, wird eine neue Version erstellt. So kann ein Chart beliebig oft im selben Cluster installiert und unabhängig verwaltet und aktualisiert werden. Das `helm install` Kommando ist ein sehr mächtiges Kommando mit vielen Möglichkeiten. Um mehr darüber zu lernen, schauen Sie ins [Helm Benutzerhandbuch](/intro/using_helm.md) ## Mehr über Versionen lernen Es ist einfach zu sehen, was durch Helm versioniert wurde: ```console $ helm ls NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` Die `helm list` (oder `helm ls`) Funktion zeigt Ihnen eine Liste aller installierten Versionen. ## Eine Version deinstallieren Um eine Version zu deinstallieren, benutzen Sie das `helm uninstall` Kommando: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Das wird `mysql-1612624192` von Kubernetes deinstallieren, was wiederum alle Resourcen löscht, die mit dieser Version verbunden sind, genauso wie die Versionshistorie. Wenn die Option `--keep-history` verwendet wird, bleibt die Versionshistorie erhalten. So können Sie Informationen über diese Version erhalten: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Weil Helm Ihre Versionen nachverfolgt, auch nachdem Sie sie deinstalliert haben, können Sie die Historie des Clusters auditieren und eine gelöschte Version wiederherstellen (mit `helm rollback`). ## Die Hilfe lesen Um mehr über die verfügbaren Helm Kommandos zu lesen, benutzen Sie `helm help` oder tippen das Kommando gefolgt von einem `-h` ein: ```console $ helm get -h ``` ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: "Helm benutzen" description: "Erklärt die Grundsätze zu Helm." sidebar_position: 3 --- Diese Anleitung erklärt die Grundlagen zur Benutzung von Helm, um Pakete in Ihrem Kubernetes Cluster zu verwalten. Es wird vorausgesetzt, dass Sie den Helm Client bereits [installiert](/intro/install.md) haben. Wenn Sie nur daran interessiert sind, ein paar einfache Kommandos schnell zu lernen, beginnen Sie mit der [Schnellstartanleitung](/intro/quickstart.md). Dieses Kapitel erklärt die speziellen Helm Kommandos und erklärt, wie Helm zu benutzen ist. ## Drei große Konzepte Ein *Chart* ist ein Helm Paket. Es beinhaltet alle Ressourcendefinitionen, die zur Ausführung einer Applikation, eines Werkzeugs oder Dienstes im Kubernetes Cluster erforderlich sind. Denken Sie an etwas wie ein Homebrew Formular für Kubernetes, ein Apt dpkg oder eine Yum RPM Datei. Ein *Repository* ist ein Platz, wo Charts gesammelt und gespeichert werden können. Es ist wie Perl's [CPAN Archiv](https://www.cpan.org) oder die [Fedora Package Database](https://src.fedoraproject.org/), aber für Kubernetes Pakete. Ein(e) *Release/Version* ist eine Instanz von einem Chart, welches in einem Kubernetes Cluster läuft. Ein Chart kann beliebig oft im selben Cluster installiert werden. Und immer wenn es neu installiert wird, wird ein neues _release_ erstellt. Denken Sie an ein MySQL Chart. Wenn Sie zwei laufende Datenbanken in Ihrem Cluster haben möchten, können Sie dieses Chart zweimal installieren. Jedes bekommt sein eigenes _release_, welches sich über seinen eigenen _release_name_ identifiziert. Mit diesem Konzept im Hinterkopf, können wir das Helm Konzept erklären wie: Helm installiert _charts_ in Kubernetes, erstellt ein neues _release_ für jede Installation. Und zur Suche nach neuen Charts, können Sie Helm Chart _repositories_ durchsuchen. ## 'helm search': Charts finden Helm kommt mit einem mächtigen Suchkommando. Es kann zwei verschiedene Quelltypen suchen: - `helm search hub` sucht [den Artifact Hub](https://artifacthub.io), welches Helm Charts von dutzenden unterschiedlichen Repositories listet. - `helm search repo` sucht die Repositories, die Sie lokal in Ihrem Helm Client hinzugefügt haben (mit `helm repo add`). Diese Suche wird über lokale Daten durchgeführt, ohne dass eine öffentliche Netzwerkverbindung notwendig ist. Sie können öffentlich verfügbare Charts finden mit dem Kommando `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` Die obige Suche nach allen `wordpress` Charts auf Artifact Hub. Ohne Filter zeigt `helm search hub` alle verfügbaren Charts. `helm search hub` zeigt die URL zum Standort auf [artifacthub.io](https://artifacthub.io/), aber nicht das eigentliche Helm Repository. Mit `helm search hub --list-repo-url` können Sie die tatsächliche Helm Repository-URL anzeigen lassen, was praktisch ist, wenn Sie ein neues Repository hinzufügen möchten: `helm repo add [NAME] [URL]`. Wenn Sie `helm search repo` benutzen, können Sie alle Namen von Charts in Repositories finden, die Sie bereits hinzugefügt haben: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Die Helm Suche benutzt ein Fuzzy String Matching Algorithmus, wodurch Sie Teile von Wortphrasen eingeben können: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Die Suche ist ein guter Weg, um verfügbare Pakete zu finden. Sobald Sie ein Paket gefunden haben, können Sie es mit `helm install` installieren. ## 'helm install': Ein Paket installieren Benutzen Sie das `helm install` Kommando, um ein neues Helm Paket zu installieren. Am einfachsten hat das Kommando zwei Argumente: Einen Versionsnamen, den Sie gewählt haben und den Namen des Charts, dass Sie installieren möchten. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Jetzt ist das `wordpress` Chart installiert. Beachten Sie dass das Installieren eines Charts ein neues _release_ Objekt erstellt. Die Version oben hat den Namen `happy-panda`. (Wenn Sie möchten, dass Helm einen Namen für Sie generiert, lassen Sie den Versionsnamen offen und geben den Parameter `--generate-name` an.) Während der Installation gibt das `helm` Programm nützliche Informationen aus wie die erstellten Ressourcen, den Status des Release und falls vorhanden zusätzliche Konfigurationsschritte, die Sie durchführen können. Helm installiert Ressourcen in der folgenden Reihenfolge: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm wartet nicht, bis alle Ressourcen laufen. Viele Charts benötigen Docker Images mit einer Grösse von 600 MB und brauchen länger, um im Cluster installiert zu werden. Um auf dem Laufenden zu bleiben oder um Konfigurationsinformationen nochmal zu lesen, können Sie `helm status` benutzen: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Die Informationen oben zeigen den Status der letzten Version. ### Anpassen des Charts vor der Installation Bisher nutzen wir nur die Standardoptionen der Konfiguration eines Charts. Öfters will man aber das Chart anpassen. Um zu sehen, welche Konfigurationsoptionen ein Chart bietet, nutzen Sie `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Sie können alle Einstellungen in einer YAML formatierten Datei überschreiben und dann bei der Installation angeben. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Das oben wird eine Standard MariaDB mit dem Benutzer `user0` erstellen, ihm Rechte auf der neu erstellten Datenbank `user0db` einrichten, aber alle anderen Werte auf dem Standard des Charts belassen. Es gibt zwei Wege, um Konfigurationsdaten während der Installation anzupassen: - `--values` (or `-f`): Gibt eine YAML Datei mit Werten zum Überschreiben an. Das kann beliebig oft gemacht werden, die am weitesten rechts benutzte Datei wird den Wert bestimmen. - `--set`: Gibt Überschreibungen auf der Kommandozeile an. Wenn beide verwendet werden, `--set` Werte werden in `--values` mit einer höheren Gewichtung verschmolzen. Überschreibungen mit `--set` sind in einer ConfigMap persistiert. Werte die mit `--set` angegeben wurden, können in einer Version mit `helm get values ` ausgegeben werden. Werte, die mit `--set` angegeben wurden, können mit dem Kommando `helm upgrade` mit `--reset-values` gelöscht werden. #### Format und Limitierungen von `--set` Die `--set` Option hat null oder mehrere Name/Wert Paare. Am einfachsten ist es zu benutzen wie: `--set name=value`. Die YAML Syntax ist: ```yaml name: value ``` Mehere Werte werden separiert mit `,` Zeichen. Aus `--set a=b,c=d` wird: ```yaml a: b c: d ``` Mehr komplextere Beschreibungen werden auch unterstützt. Zum Beispiel `--set outer.inner=value` wird übersetzt in: ```yaml outer: inner: value ``` Listen können mit geschweiften Klammern `{` und `}` angegeben werden. Zum Beispiel `--set name={a, b, c}` wird übersetzt in: ```yaml name: - a - b - c ``` Bestimmte Namen/Schlüssel können auf `null` oder ein leeres Array `[]` gesetzt werden. Zum Beispiel übersetzt `--set name=[],a=null` ```yaml name: - a - b - c a: b ``` in ```yaml name: [] a: null ``` Mit Helm 2.5.0 ist es möglich, Listenwerte in einer Arrayindex-Syntax anzugeben, Zum Beispiel `--set servers[0].port=80` wird: ```yaml servers: - port: 80 ``` Mehrere Werte können auf diesem Weg angebenen werden. Die Zeile `--set servers[0].port=80,servers[0].host=example` wird: ```yaml servers: - port: 80 host: example ``` Manchmal brauchen Sie spezielle Zeichen in Ihrer `--set` Zeile. Sie können Backslash zum Verstecken des Zeichens benutzen: `--set name=value1\,value2` wird: ```yaml name: "value1,value2" ``` Genauso können Sie Punktsequenzen maskieren, die möglicherweise beim Parsen von Charts in Annotations, Labels und Node Selectors mit der `toYaml` Funktion problematisch werden könnten. Die Syntax für `--set nodeSelector."kubernetes\.io/role"=master` wird: ```yaml nodeSelector: kubernetes.io/role: master ``` Tief verzweigte Datenstrukturen können schwierig darzustellen sein mit `--set`. Chart Designer sind angewiesen, die Benutzung von `--set` durch die Benutzung des Formats der `values.yaml` Datei zu minimieren. (Lesen Sie mehr dazu in [Values Files](/chart_template_guide/values_files.md)). ### Mehr Installationsmethoden Das `helm install` Kommando kann von verschiedenen Quellen installieren: - Ein Chart Repository (wie wir es oben gesehen haben) - Ein lokales Chart Archiv (`helm install foo foo-0.1.1.tgz`) - Ein ungepacktes Chart Verzeichnis (`helm install foo path/to/foo`) - Eine URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' und 'helm rollback': Eine Version aktualisieren und die Wiederherstellung nach einem Fehler Wenn eine neue Version von einem Chart installiert ist oder wenn Sie Änderungen an der Konfiguration durchführen möchten, können Sie das `helm upgrade` Kommando verwenden. Eine Aktualisierung nimmt eine bestehende Version und aktualisiert sie nach den gegebenen Informationen, die Sie bereitstellen. Da Kubernetes Charts sehr gross und komplex sein können, probiert Helm die wenigst invasive Aktualisierung. Es wird nur Dinge aktualisieren, die sich seit der letzten Version wirklich geändert haben. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` In dem Fall oben wird die `happy-panda` Version mit dem selben Chart aber mit einer neuen YAML Datei aktualisiert: ```yaml mariadb.auth.username: user1 ``` Wir können `helm get values` benutzen, um zu sehen, ob die Änderungen durchgeführt wurden. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` Das `helm get` Kommando ist ein nützliches Werkzeug, um nach der Version in Ihrem Cluster zu schauen. Wie wir oben sehen können, sieht es so aus, als wenn unsere neuen Werte von `panda.yaml` im Cluster installiert wurden sind. Jetzt, wenn etwas ungeplantes in dieser Version passiert ist, ist es einfach zu einer vorherigen Version mit dem Kommando `helm rollback [RELEASE] [REVISION]` zu wechseln. ```console $ helm rollback happy-panda 1 ``` Dies rollt unsere happy-panda Installation zur allerersten Version zurück. Bei jeder Installation, Aktualisierung oder Zurückrollen wird die Revisionsnummer um 1 erhöht. Die erste Revisionsnummer ist immer die 1. Und mit dem Kommando `helm history [RELEASE]` sehen wir die Historie zu jeder Version. ## Hilfreiche Optionen für Installation/Aktualisierung/Zurückrollen Es gibt sehr viele hilfreiche Optionen, um das Verhalten von Helm bei der Installation, der Aktualisierung oder dem Zurückrollen zu ändern. Bitte beachten Sie, dass das keine vollständige Liste der Optionen ist. Zur vollen Beschreibung rufen Sie einfach `helm --help` auf. - `--timeout`: Ein Wert der [Go Wartezeit](https://golang.org/pkg/time/#ParseDuration), um auf den Abschluss eines Kubernetes Kommandos zu warten. Der Standardwert ist `5m0s`. - `--wait`: Wartet bis alle Pods im Status Running sind, PVCs gebunden sind und Deployments eine minimale Verfügbarkeit besitzen (`Desired` minus `maxUnavailable`), Services eine IP-Adresse haben (Ingress wenn es ein `LoadBalancer` ist), bevor die ganze Version als erfolgreich installiert markiert wird. Wenn das Timeout `--timeout` erreicht wird, wird die Version als `FAILED` markiert. Hinweis: In Deployments in denen `replicas` auf 1 und `maxUnavailable` als Teil der Aktualisierungsstrategie gesetzt ist, wird `--wait` den Status fertig melden, wenn es den minimalen Pod als fertig gesehen hat. - `--no-hooks`: Dies übergeht Hooks für dieses Kommando - `--recreate-pods` (nur verfügbar bei `upgrade` und `rollback`): Diese Option wird alle Pods neu erstellen (ausser den Pods in diesem Deployment). (VERALTET in Helm 3) ## 'helm uninstall': Eine Version deinstallieren Benutzen Sie das Kommando `helm uninstall`, wenn es an der Zeit ist, eine Version vom Cluster zu deinstallieren: ```console $ helm uninstall happy-panda ``` Das wird die Version vom Cluster löschen. Sie können die derzeit im Cluster installierte Version mit dem Kommando `helm list` sehen: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` Von der Ausgaben oben sehen wir, dass die Version `happy-panda` deinstalliert wurde. In einer vorherigen Version von Helm wurde sich immer das Löschen einer Version gemerkt. In Helm 3 wird dieser Eintrag auch gelöscht. Wenn Sie diese Löscheinträge behalten wollen, benutzen Sie beim Deinstallieren --keep-history`. Die Benutzung von `helm list --uninstalled` wird nur die Versionen zeigen, die mit der Option `--keep-history` gelöscht wurden. Die Option `helm list --all` zeigt alle Versionseinträge, die Helm aufgehoben hat, inkl. fehlerhafte und gelöschte Einträge (wenn `--keep-history` verwendet wurde): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Beachten Sie, dass es durch die standardmässig gelöschten Versionen es nicht mehr möglich ist, eine nicht installierte Resource zurückzurollen. ## 'helm repo': Arbeiten mit Repositories Helm 3 wird nicht mehr mit einem Standard Chart Verzeichnis ausgeliefert. Das `helm repo` Gruppenkommando stellt Kommandos zum Hinzufügen, Auflisten und Löschen von Verzeichnissen zur Verfügung. Mit dem Kommando `helm repo list` können Sie sehen, welche Verzeichnisse konfiguriert sind: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Und neue Verzeichnisse können hinzugefügt werden mit `helm repo add`: ```console $ helm repo add dev https://example.com/dev-charts ``` Weil Sich Chart Repositories ständig ändern, sollten Sie an dieser Stelle sicherstellen, dass Ihr Helm Programm mit dem Kommando `helm repo update` aktuell ist. Repositories können mit `helm repo remove` gelöscht werden. ## Ihr eigenes Chart erstellen Das [Chart Entwicklungshandbuch](/topics/charts.md) erklärt, wie Sie Ihr eigenes Chart entwickeln können. Aber Sie können auch schnell starten mit dem Kommando `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Nun gibt es ein Chart in `./deis-workflow`. Sie können es editieren und Ihre eigene Vorlage erstellen. Nach dem Editieren können Sie das Format mit dem Kommando `helm lint` validieren. Wenn es Zeit ist, ein Paket von diesem Chart für eine Distribution zu erstellen, können Sie das Kommando `helm package` verwenden: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` Jetzt kann das Chart einfach installiert werden mit `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Chart Pakete können einfach in ein Repository geladen werden. Schauen Sie die Dokumentation für [Helm Chart Repositories](/topics/chart_repository.md) für mehr Details. ## Zusammenfassung Dieses Kapitel behandelte die grundlegende Verwendung des `helm` Clients, inkl. Suchen, Installieren, Aktualisieren und Deinstallieren. Es wurden auch hilfreiche Zusatzkommandos besprochen wie `helm status`, `helm get` und `helm repo`. Für mehr Informationen zu diesen Kommandos, schauen Sie in die eingebaute Hilfe: `helm help`. Im [nächsten Kapitel](/howto/charts_tips_and_tricks.md) werden wir einen Blick in die Entwicklung von Charts. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Einführung description: Stellt das Helm Go SDK vor sidebar_position: 1 --- Das Go SDK von Helm ermöglicht es benutzerdefinierter Software, Helm Charts und die Funktionalität von Helm für die Verwaltung von Kubernetes-Software-Deployments zu nutzen. (Die Helm CLI ist im Grunde selbst nur ein solches Werkzeug!) Derzeit wurde das SDK funktional von der Helm CLI getrennt. Das SDK kann (und wird) von eigenständigen Tools verwendet. Das Helm-Projekt hat sich zur API-Stabilität für das SDK verpflichtet. Als Hinweis: Das SDK hat noch einige Ecken und Kanten aus der anfänglichen Arbeit zur Trennung von CLI und SDK. Das Helm-Projekt beabsichtigt, diese im Laufe der Zeit zu verbessern. Die vollständige API-Dokumentation finden Sie unter [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Im Folgenden finden Sie einen kurzen Überblick über einige der wichtigsten Paketarten und ein einfaches Beispiel. Weitere Beispiele und einen umfangreicheren 'Treiber' finden Sie im Abschnitt [Beispiele](/sdk/examples.mdx). ## Überblick über die wichtigsten Pakete - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Enthält den Haupt-"Client" zur Durchführung von Helm-Aktionen. Dies ist dasselbe Paket, das die CLI im Hintergrund verwendet. Wenn Sie nur grundlegende Helm-Befehle aus einem anderen Go-Programm ausführen möchten, ist dieses Paket genau das Richtige. - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Methoden und Hilfsfunktionen zum Laden und Bearbeiten von Charts - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) und seine Unterpakete: Enthält alle Handler für die Standard-Helm-Umgebungsvariablen. Die Unterpakete enthalten die Verarbeitung von Ausgabe- und Values-Dateien. - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Definiert das `Release`-Objekt und Status Es gibt noch viele weitere Pakete – weitere Informationen finden Sie in der Dokumentation. ### Einfaches Beispiel Dies ist ein einfaches Beispiel für ein `helm list` mit dem Go SDK. Weitere umfangreichere Beispiele finden Sie im Abschnitt [Beispiele](/sdk/examples.mdx). ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Kompatibilität Das Helm SDK folgt ausdrücklich den Rückwärtskompatibilitätsgarantien von Helm: Das bedeutet, dass inkompatible Änderungen nur bei Hauptversionen vorgenommen werden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Fortgeschrittene Helm-Techniken description: Erläutert verschiedene fortgeschrittene Funktionen für erfahrene Helm-Benutzer sidebar_position: 9 --- Dieser Abschnitt erläutert verschiedene fortgeschrittene Funktionen und Techniken für die Verwendung von Helm. Die Informationen in diesem Abschnitt richten sich an „fortgeschrittene Benutzer" von Helm, die erweiterte Anpassungen und Manipulationen ihrer Charts und Releases durchführen möchten. Jede dieser fortgeschrittenen Funktionen bringt eigene Kompromisse und Einschränkungen mit sich, daher muss jede mit Sorgfalt und fundiertem Wissen über Helm eingesetzt werden. Oder anders ausgedrückt: Denken Sie an das [Peter-Parker-Prinzip](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Post Rendering Post Rendering gibt Chart-Installierern die Möglichkeit, gerenderte Manifeste manuell zu manipulieren, zu konfigurieren und/oder zu validieren, bevor sie von Helm installiert werden. Dies ermöglicht es Benutzern mit erweiterten Konfigurationsanforderungen, Tools wie [`kustomize`](https://kustomize.io) zu verwenden, um Konfigurationsänderungen anzuwenden, ohne ein öffentliches Chart forken zu müssen oder von Chart-Maintainern zu verlangen, jede einzelne Konfigurationsoption für eine Software bereitzustellen. Es gibt auch Anwendungsfälle für das Einbinden gemeinsamer Tools und Sidecars in Unternehmensumgebungen oder die Analyse der Manifeste vor der Bereitstellung. ### Voraussetzungen - Helm 3.1+ ### Verwendung Ein Post-Renderer kann jede ausführbare Datei sein, die gerenderte Kubernetes-Manifeste über STDIN akzeptiert und gültige Kubernetes-Manifeste über STDOUT zurückgibt. Bei einem Fehler sollte ein Exit-Code ungleich 0 zurückgegeben werden. Dies ist die einzige „API" zwischen den beiden Komponenten. Sie ermöglicht große Flexibilität bei dem, was Sie mit Ihrem Post-Render-Prozess tun können. Ein Post-Renderer kann mit `install`, `upgrade` und `template` verwendet werden. Um einen Post-Renderer zu verwenden, nutzen Sie das Flag `--post-renderer` mit einem Pfad zur ausführbaren Renderer-Datei: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Wenn der Pfad keine Trennzeichen enthält, wird in $PATH gesucht, andernfalls werden relative Pfade zu einem vollqualifizierten Pfad aufgelöst. Wenn Sie mehrere Post-Renderer verwenden möchten, rufen Sie alle in einem Skript auf oder kombinieren Sie sie in einem beliebigen Binary-Tool, das Sie erstellt haben. In Bash wäre dies so einfach wie `renderer1 | renderer2 | renderer3`. Sie können ein Beispiel für die Verwendung von `kustomize` als Post-Renderer [hier](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render) sehen. ### Einschränkungen Bei der Verwendung von Post-Renderern gibt es mehrere wichtige Punkte zu beachten. Der wichtigste davon ist, dass bei Verwendung eines Post-Renderers alle Personen, die dieses Release modifizieren, **denselben Renderer verwenden müssen**, um reproduzierbare Builds zu gewährleisten. Diese Funktion wurde absichtlich so entwickelt, dass jeder Benutzer den verwendeten Renderer wechseln oder die Verwendung eines Renderers beenden kann, aber dies sollte bewusst geschehen, um versehentliche Änderungen oder Datenverlust zu vermeiden. Ein weiterer wichtiger Hinweis betrifft die Sicherheit. Wenn Sie einen Post-Renderer verwenden, sollten Sie sicherstellen, dass er aus einer zuverlässigen Quelle stammt (wie bei jeder anderen beliebigen ausführbaren Datei). Die Verwendung von nicht vertrauenswürdigen oder nicht verifizierten Renderern wird NICHT empfohlen, da sie vollen Zugriff auf gerenderte Templates haben, die oft sensible Daten enthalten. ### Benutzerdefinierte Post-Renderer Der Post-Render-Schritt bietet noch mehr Flexibilität bei Verwendung des Go SDK. Jeder Post-Renderer muss nur das folgende Go-Interface implementieren: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Weitere Informationen zur Verwendung des Go SDK finden Sie im [Go SDK-Abschnitt](#go-sdk). ## Go SDK Helm 3 führte ein komplett umstrukturiertes Go SDK ein, das eine bessere Erfahrung beim Erstellen von Software und Tools bietet, die Helm nutzen. Die vollständige Dokumentation finden Sie im [Go SDK-Abschnitt](/sdk/gosdk.md). ## Speicher-Backends Helm 3 hat den Standard-Speicherort für Release-Informationen auf Secrets im Namespace des Releases geändert. Helm 2 speicherte Release-Informationen standardmäßig als ConfigMaps im Namespace der Tiller-Instanz. Die folgenden Unterabschnitte zeigen, wie verschiedene Backends konfiguriert werden. Diese Konfiguration basiert auf der Umgebungsvariablen `HELM_DRIVER`. Sie kann auf einen der folgenden Werte gesetzt werden: `[configmap, secret, sql]`. ### ConfigMap-Speicher-Backend Um das ConfigMap-Backend zu aktivieren, müssen Sie die Umgebungsvariable `HELM_DRIVER` auf `configmap` setzen. Sie können sie in einer Shell wie folgt setzen: ```shell export HELM_DRIVER=configmap ``` Wenn Sie vom Standard-Backend zum ConfigMap-Backend wechseln möchten, müssen Sie die Migration selbst durchführen. Sie können Release-Informationen mit folgendem Befehl abrufen: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **PRODUKTIONSHINWEISE**: Die Release-Informationen enthalten den Inhalt von Charts und Values-Dateien und können daher sensible Daten (wie Passwörter, private Schlüssel und andere Anmeldedaten) enthalten, die vor unbefugtem Zugriff geschützt werden müssen. Bei der Verwaltung von Kubernetes-Berechtigungen, beispielsweise mit [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), ist es möglich, breiteren Zugriff auf ConfigMap-Ressourcen zu gewähren, während der Zugriff auf Secret-Ressourcen eingeschränkt bleibt. Zum Beispiel gewährt die standardmäßige [benutzerorientierte Rolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) „view" Zugriff auf die meisten Ressourcen, aber nicht auf Secrets. Darüber hinaus können Secrets-Daten für [verschlüsselte Speicherung](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) konfiguriert werden. Bitte beachten Sie dies, wenn Sie zum ConfigMap-Backend wechseln möchten, da dies die sensiblen Daten Ihrer Anwendung offenlegen könnte. ### SQL-Speicher-Backend Es gibt ein ***Beta***-SQL-Speicher-Backend, das Release-Informationen in einer SQL-Datenbank speichert. Die Verwendung eines solchen Speicher-Backends ist besonders nützlich, wenn Ihre Release-Informationen mehr als 1 MB wiegen (in diesem Fall können sie aufgrund interner Beschränkungen im zugrundeliegenden etcd-Schlüssel-Wert-Speicher von Kubernetes nicht in ConfigMaps/Secrets gespeichert werden). Um das SQL-Backend zu aktivieren, müssen Sie eine SQL-Datenbank bereitstellen und die Umgebungsvariable `HELM_DRIVER` auf `sql` setzen. Die Datenbankdetails werden mit der Umgebungsvariablen `HELM_DRIVER_SQL_CONNECTION_STRING` festgelegt. Sie können sie in einer Shell wie folgt setzen: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Hinweis: Derzeit wird nur PostgreSQL unterstützt. **PRODUKTIONSHINWEISE**: Es wird empfohlen: - Ihre Datenbank produktionsreif zu machen. Für PostgreSQL finden Sie weitere Details in der Dokumentation zur [Serveradministration](https://www.postgresql.org/docs/12/admin.html) - [Berechtigungsverwaltung](/topics/permissions_sql_storage_backend.md) zu aktivieren, um Kubernetes RBAC für Release-Informationen zu spiegeln Wenn Sie vom Standard-Backend zum SQL-Backend wechseln möchten, müssen Sie die Migration selbst durchführen. Sie können Release-Informationen mit folgendem Befehl abrufen: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Helm Architektur description: Beschreibt die Architektur von Helm auf hoher Ebene. sidebar_position: 8 --- # Helm Architektur Dieses Dokument beschreibt die Architektur von Helm auf hoher Ebene. ## Der Zweck von Helm Helm ist ein Werkzeug zur Verwaltung von Kubernetes-Paketen, die _Charts_ genannt werden. Helm kann Folgendes: - Neue Charts von Grund auf erstellen - Charts in Chart-Archive (tgz-Dateien) paketieren - Mit Chart-Repositories interagieren, in denen Charts gespeichert sind - Charts in einem bestehenden Kubernetes-Cluster installieren und deinstallieren - Den Release-Zyklus von Charts verwalten, die mit Helm installiert wurden Für Helm gibt es drei wichtige Konzepte: 1. Das _Chart_ ist ein Bündel von Informationen, die zur Erstellung einer Instanz einer Kubernetes-Anwendung erforderlich sind. 2. Die _Config_ enthält Konfigurationsinformationen, die mit einem paketierten Chart zusammengeführt werden können, um ein installierbares Objekt zu erstellen. 3. Ein _Release_ ist eine laufende Instanz eines _Charts_, kombiniert mit einer bestimmten _Config_. ## Komponenten Helm ist eine ausführbare Anwendung, die aus zwei verschiedenen Teilen besteht: **Der Helm Client** ist ein Kommandozeilen-Client für Endbenutzer. Der Client ist für Folgendes verantwortlich: - Lokale Chart-Entwicklung - Verwaltung von Repositories - Verwaltung von Releases - Schnittstelle zur Helm-Bibliothek - Senden von Charts zur Installation - Anfordern von Upgrades oder Deinstallationen bestehender Releases **Die Helm Bibliothek** stellt die Logik für die Ausführung aller Helm-Operationen bereit. Sie kommuniziert mit dem Kubernetes API-Server und bietet folgende Funktionalität: - Kombination eines Charts und einer Config zu einem Release - Installation von Charts in Kubernetes und Bereitstellung des resultierenden Release-Objekts - Aktualisierung und Deinstallation von Charts durch Interaktion mit Kubernetes Die eigenständige Helm-Bibliothek kapselt die Helm-Logik, sodass sie von verschiedenen Clients genutzt werden kann. ## Implementierung Der Helm Client und die Bibliothek sind in der Programmiersprache Go geschrieben. Die Bibliothek verwendet die Kubernetes-Client-Bibliothek zur Kommunikation mit Kubernetes. Derzeit verwendet diese Bibliothek REST+JSON. Sie speichert Informationen in Secrets innerhalb von Kubernetes. Sie benötigt keine eigene Datenbank. Konfigurationsdateien werden, wenn möglich, in YAML geschrieben. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Leitfaden für Chart Repositories description: So erstellen und arbeiten Sie mit Helm Chart Repositories. sidebar_position: 6 --- Dieser Abschnitt erklärt, wie Sie Chart Repositories erstellen und damit arbeiten. Grundsätzlich ist ein Chart Repository ein Ort, an dem gepackte Charts gespeichert und geteilt werden können. Das verteilte Community-Repository für Helm Charts befindet sich bei [Artifact Hub](https://artifacthub.io/packages/search?kind=0) und begrüßt Teilnahme. Aber Helm ermöglicht es auch, eigene Chart Repositories zu erstellen und zu betreiben. Dieser Leitfaden erklärt, wie das geht. Falls Sie erwägen, ein Chart Repository zu erstellen, sollten Sie stattdessen die Verwendung einer [OCI-Registry](/topics/registries.md) in Betracht ziehen. ## Voraussetzungen * Arbeiten Sie den [Schnellstart](/intro/quickstart.md)-Leitfaden durch * Lesen Sie das [Charts](/topics/charts.md)-Dokument ## Ein Chart Repository erstellen Ein _Chart Repository_ ist ein HTTP-Server, der eine `index.yaml`-Datei und optional einige gepackte Charts hostet. Wenn Sie bereit sind, Ihre Charts zu teilen, ist der bevorzugte Weg, sie in ein Chart Repository hochzuladen. Seit Helm 2.2.0 wird clientseitige SSL-Authentifizierung für Repositories unterstützt. Andere Authentifizierungsprotokolle können als Plugins verfügbar sein. Da ein Chart Repository jeder HTTP-Server sein kann, der YAML- und tar-Dateien bereitstellen und GET-Anfragen beantworten kann, haben Sie zahlreiche Optionen beim Hosten Ihres eigenen Chart Repositories. Zum Beispiel können Sie einen Google Cloud Storage (GCS) Bucket, einen Amazon S3 Bucket, GitHub Pages verwenden oder sogar Ihren eigenen Webserver erstellen. ### Die Struktur eines Chart Repositories Ein Chart Repository besteht aus gepackten Charts und einer speziellen Datei namens `index.yaml`, die einen Index aller Charts im Repository enthält. Häufig werden die Charts, die `index.yaml` beschreibt, auch auf demselben Server gehostet, ebenso wie die [Provenienz-Dateien](/topics/provenance.md). Das Layout des Repositories `https://example.com/charts` könnte beispielsweise so aussehen: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` In diesem Fall würde die Index-Datei Informationen über ein Chart enthalten, das Alpine-Chart, und die Download-URL `https://example.com/charts/alpine-0.1.2.tgz` für dieses Chart bereitstellen. Es ist nicht erforderlich, dass ein Chart-Paket auf demselben Server wie die `index.yaml`-Datei liegt. Allerdings ist dies oft am einfachsten. ### Die Index-Datei Die Index-Datei ist eine YAML-Datei namens `index.yaml`. Sie enthält einige Metadaten über das Paket, einschließlich des Inhalts der `Chart.yaml`-Datei eines Charts. Ein gültiges Chart Repository muss eine Index-Datei haben. Die Index-Datei enthält Informationen über jedes Chart im Chart Repository. Der Befehl `helm repo index` generiert eine Index-Datei basierend auf einem gegebenen lokalen Verzeichnis, das gepackte Charts enthält. Dies ist ein Beispiel einer Index-Datei: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Hosten von Chart Repositories Dieser Teil zeigt verschiedene Möglichkeiten, ein Chart Repository bereitzustellen. ### Google Cloud Storage Der erste Schritt ist das **Erstellen Ihres GCS-Buckets**. Wir nennen unseren `fantastic-charts`. ![Create a GCS Bucket](/img/helm2/create-a-bucket.png) Als Nächstes machen Sie Ihren Bucket öffentlich, indem Sie die **Bucket-Berechtigungen bearbeiten**. ![Edit Permissions](/img/helm2/edit-permissions.png) Fügen Sie diese Zeile hinzu, um **Ihren Bucket öffentlich zu machen**: ![Make Bucket Public](/img/helm2/make-bucket-public.png) Herzlichen Glückwunsch! Jetzt haben Sie einen leeren GCS-Bucket, der bereit ist, Charts bereitzustellen. Sie können Ihr Chart Repository mit dem Google Cloud Storage-Kommandozeilentool oder über die GCS-Weboberfläche hochladen. Ein öffentlicher GCS-Bucket kann über einfaches HTTPS unter dieser Adresse erreicht werden: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith Sie können auch Chart Repositories mit Cloudsmith einrichten. Lesen Sie mehr über Chart Repositories mit Cloudsmith [hier](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory Ebenso können Sie Chart Repositories mit JFrog Artifactory einrichten. Lesen Sie mehr über Chart Repositories mit JFrog Artifactory [hier](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### GitHub Pages-Beispiel Auf ähnliche Weise können Sie ein Chart Repository mit GitHub Pages erstellen. GitHub ermöglicht es Ihnen, statische Webseiten auf zwei verschiedene Arten bereitzustellen: - Indem Sie ein Projekt so konfigurieren, dass es den Inhalt seines `docs/`-Verzeichnisses bereitstellt - Indem Sie ein Projekt so konfigurieren, dass es einen bestimmten Branch bereitstellt Wir nehmen den zweiten Ansatz, obwohl der erste genauso einfach ist. Der erste Schritt ist das **Erstellen Ihres gh-pages-Branches**. Sie können dies lokal wie folgt tun: ```console $ git checkout -b gh-pages ``` Oder über den Webbrowser mit dem **Branch**-Button in Ihrem GitHub-Repository: ![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png) Als Nächstes sollten Sie sicherstellen, dass Ihr **gh-pages-Branch** als GitHub Pages eingestellt ist. Klicken Sie auf die **Settings** Ihres Repositories und scrollen Sie zum Abschnitt **GitHub Pages** und stellen Sie es wie unten gezeigt ein: ![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png) Standardmäßig wird die **Source** normalerweise auf **gh-pages branch** gesetzt. Falls dies nicht standardmäßig eingestellt ist, wählen Sie es aus. Sie können dort bei Bedarf eine **benutzerdefinierte Domain** verwenden. Stellen Sie außerdem sicher, dass **Enforce HTTPS** aktiviert ist, damit **HTTPS** verwendet wird, wenn Charts bereitgestellt werden. Mit dieser Einrichtung können Sie Ihren Standard-Branch zum Speichern Ihres Chart-Codes verwenden und den **gh-pages-Branch** als Chart Repository, z.B.: `https://USERNAME.github.io/REPONAME`. Das Demonstrations-Repository [TS Charts](https://github.com/technosophos/tscharts) ist erreichbar unter `https://technosophos.github.io/tscharts/`. Wenn Sie sich entschieden haben, GitHub Pages zum Hosten des Chart Repositories zu verwenden, schauen Sie sich die [Chart Releaser Action](/howto/chart_releaser_action.md) an. Die Chart Releaser Action ist ein GitHub Action-Workflow, der ein GitHub-Projekt in ein selbst gehostetes Helm Chart Repository verwandelt, unter Verwendung des [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI-Tools. ### Gewöhnliche Webserver Um einen gewöhnlichen Webserver für Helm Charts zu konfigurieren, müssen Sie lediglich Folgendes tun: - Legen Sie Ihren Index und Ihre Charts in ein Verzeichnis, das der Server bereitstellen kann - Stellen Sie sicher, dass die `index.yaml`-Datei ohne Authentifizierungsanforderung zugänglich ist - Stellen Sie sicher, dass `yaml`-Dateien mit dem korrekten Content-Type bereitgestellt werden (`text/yaml` oder `text/x-yaml`) Wenn Sie beispielsweise Ihre Charts aus `$WEBROOT/charts` bereitstellen möchten, stellen Sie sicher, dass ein `charts/`-Verzeichnis in Ihrem Web-Root existiert, und legen Sie die Index-Datei und die Charts in diesen Ordner. ### ChartMuseum Repository-Server ChartMuseum ist ein Open-Source Helm Chart Repository-Server, der in Go (Golang) geschrieben ist, mit Unterstützung für Cloud-Storage-Backends, einschließlich [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) und [etcd](https://etcd.io/). Sie können auch den [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)-Server verwenden, um ein Chart Repository aus einem lokalen Dateisystem zu hosten. ### GitLab Package Registry Mit GitLab können Sie Helm Charts in der Package Registry Ihres Projekts veröffentlichen. Lesen Sie mehr über das Einrichten eines Helm Package Repositories mit GitLab [hier](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Verwalten von Chart Repositories Da Sie nun ein Chart Repository haben, erklärt der letzte Teil dieses Leitfadens, wie Sie Charts in diesem Repository pflegen. ### Charts in Ihrem Chart Repository speichern Laden wir nun ein Chart und eine Index-Datei in das Repository hoch. Charts in einem Chart Repository müssen gepackt (`helm package chart-name/`) und korrekt versioniert sein (gemäß den [SemVer 2](https://semver.org/)-Richtlinien). Die folgenden Schritte bilden einen Beispiel-Workflow, aber Sie können jeden beliebigen Workflow verwenden, den Sie zum Speichern und Aktualisieren von Charts in Ihrem Chart Repository bevorzugen. Sobald Sie ein gepacktes Chart bereit haben, erstellen Sie ein neues Verzeichnis und verschieben Sie Ihr gepacktes Chart in dieses Verzeichnis. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` Der letzte Befehl nimmt den Pfad des lokalen Verzeichnisses, das Sie gerade erstellt haben, und die URL Ihres Remote-Chart-Repositories und erstellt eine `index.yaml`-Datei im angegebenen Verzeichnispfad. Jetzt können Sie das Chart und die Index-Datei mit einem Synchronisierungstool oder manuell in Ihr Chart Repository hochladen. Wenn Sie Google Cloud Storage verwenden, schauen Sie sich diesen [Beispiel-Workflow](/howto/chart_repository_sync_example.md) mit dem gsutil-Client an. Für GitHub können Sie die Charts einfach in den entsprechenden Ziel-Branch legen. ### Neue Charts zu einem bestehenden Repository hinzufügen Jedes Mal, wenn Sie ein neues Chart zu Ihrem Repository hinzufügen möchten, müssen Sie den Index neu generieren. Der Befehl `helm repo index` baut die `index.yaml`-Datei vollständig von Grund auf neu auf und nimmt nur die Charts auf, die er lokal findet. Sie können jedoch das Flag `--merge` verwenden, um neue Charts inkrementell zu einer bestehenden `index.yaml`-Datei hinzuzufügen (eine großartige Option bei der Arbeit mit einem Remote-Repository wie GCS). Führen Sie `helm repo index --help` aus, um mehr zu erfahren. Stellen Sie sicher, dass Sie sowohl die überarbeitete `index.yaml`-Datei als auch das Chart hochladen. Und falls Sie eine Provenienz-Datei generiert haben, laden Sie diese ebenfalls hoch. ### Ihre Charts mit anderen teilen Wenn Sie bereit sind, Ihre Charts zu teilen, teilen Sie einfach jemandem die URL Ihres Repositories mit. Von dort aus können sie das Repository mit dem Befehl `helm repo add [NAME] [URL]` zu ihrem Helm-Client hinzufügen, mit einem beliebigen Namen, den sie für die Referenzierung des Repositories verwenden möchten. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Wenn die Charts durch HTTP-Basic-Authentifizierung geschützt sind, können Sie hier auch Benutzername und Passwort angeben: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Hinweis:** Ein Repository wird nicht hinzugefügt, wenn es keine gültige `index.yaml` enthält. **Hinweis:** Wenn Ihr Helm-Repository z.B. ein selbstsigniertes Zertifikat verwendet, können Sie `helm repo add --insecure-skip-tls-verify ...` verwenden, um die CA-Verifizierung zu überspringen. Danach können Ihre Benutzer Ihre Charts durchsuchen. Nachdem Sie das Repository aktualisiert haben, können sie den Befehl `helm repo update` verwenden, um die neuesten Chart-Informationen zu erhalten. *Unter der Haube rufen die Befehle `helm repo add` und `helm repo update` die index.yaml-Datei ab und speichern sie im Verzeichnis `$XDG_CACHE_HOME/helm/repository/cache/`. Hier findet die Funktion `helm search` Informationen über Charts.* ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Chart Tests description: Beschreibt, wie Sie Ihre Charts ausführen und testen können. sidebar_position: 3 --- Ein Chart enthält eine Reihe von Kubernetes-Ressourcen und Komponenten, die zusammenarbeiten. Als Chart-Autor möchten Sie möglicherweise Tests schreiben, die überprüfen, ob Ihr Chart bei der Installation wie erwartet funktioniert. Diese Tests helfen auch dem Chart-Benutzer zu verstehen, was Ihr Chart tun soll. Ein **Test** in einem Helm Chart befindet sich im Verzeichnis `templates/` und ist eine Job-Definition, die einen Container mit einem auszuführenden Befehl spezifiziert. Der Container sollte erfolgreich beendet werden (Exit-Code 0), damit ein Test als erfolgreich gilt. Die Job-Definition muss die Helm-Test-Hook-Annotation enthalten: `helm.sh/hook: test`. Hinweis: Bis Helm v3 musste die Job-Definition eine der folgenden Helm-Test-Hook-Annotationen enthalten: `helm.sh/hook: test-success` oder `helm.sh/hook: test-failure`. Die Annotation `helm.sh/hook: test-success` wird weiterhin als abwärtskompatible Alternative zu `helm.sh/hook: test` akzeptiert. Beispiele für Tests: - Validieren Sie, dass Ihre Konfiguration aus der values.yaml-Datei korrekt übernommen wurde. - Stellen Sie sicher, dass Ihr Benutzername und Passwort korrekt funktionieren - Stellen Sie sicher, dass ein falscher Benutzername und falsches Passwort nicht funktionieren - Überprüfen Sie, dass Ihre Services aktiv sind und die Lastverteilung korrekt funktioniert - usw. Sie können die vordefinierten Tests in Helm für ein Release mit dem Befehl `helm test ` ausführen. Für einen Chart-Benutzer ist dies eine hervorragende Möglichkeit, zu prüfen, ob das Release eines Charts (oder einer Anwendung) wie erwartet funktioniert. ## Beispieltest Der Befehl [helm create](/helm/helm_create.md) erstellt automatisch eine Reihe von Ordnern und Dateien. Um die Helm-Testfunktionalität auszuprobieren, erstellen Sie zunächst ein Demo-Helm-Chart. ```console $ helm create demo ``` Sie sehen nun die folgende Struktur in Ihrem Demo-Helm-Chart. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` In `demo/templates/tests/test-connection.yaml` finden Sie einen Test, den Sie ausprobieren können. Hier sehen Sie die Pod-Definition für den Helm-Test: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Schritte zum Ausführen einer Testsuite für ein Release Installieren Sie zunächst das Chart in Ihrem Cluster, um ein Release zu erstellen. Möglicherweise müssen Sie warten, bis alle Pods aktiv sind; wenn Sie den Test direkt nach der Installation ausführen, wird wahrscheinlich ein vorübergehender Fehler angezeigt, und Sie sollten den Test erneut durchführen. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Hinweise - Sie können beliebig viele Tests in einer einzelnen YAML-Datei definieren oder auf mehrere YAML-Dateien im Verzeichnis `templates/` verteilen. - Sie können Ihre Testsuite in einem Unterverzeichnis `tests/` wie `/templates/tests/` unterbringen, um eine bessere Übersichtlichkeit zu erreichen. - Ein Test ist ein [Helm Hook](/topics/charts_hooks.md), daher können Annotationen wie `helm.sh/hook-weight` und `helm.sh/hook-delete-policy` mit Test-Ressourcen verwendet werden. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Charts description: Erklärt das Chart-Format und bietet grundlegende Anleitungen zum Erstellen von Charts mit Helm. sidebar_position: 1 --- Helm verwendet ein Paketformat namens _Charts_. Ein Chart ist eine Sammlung von Dateien, die zusammengehörige Kubernetes-Ressourcen beschreiben. Mit einem einzelnen Chart lässt sich etwas Einfaches wie ein Memcached-Pod bereitstellen, aber auch etwas Komplexes wie ein vollständiger Web-App-Stack mit HTTP-Servern, Datenbanken, Caches usw. Charts werden als Dateien in einer bestimmten Verzeichnisstruktur angelegt und können in versionierte Archive verpackt werden. Wenn Sie die Dateien eines veröffentlichten Charts herunterladen und ansehen möchten, ohne es zu installieren, können Sie dies mit `helm pull chartrepo/chartname` tun. Dieses Dokument erklärt das Chart-Format und bietet grundlegende Anleitungen zum Erstellen von Charts mit Helm. ## Die Chart-Dateistruktur Ein Chart ist als Sammlung von Dateien innerhalb eines Verzeichnisses organisiert. Der Verzeichnisname entspricht dem Namen des Charts (ohne Versionsinformationen). Ein Chart, das WordPress beschreibt, würde also in einem `wordpress/`-Verzeichnis gespeichert werden. Innerhalb dieses Verzeichnisses erwartet Helm eine Struktur wie diese: ```text wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file values.yaml # The default configuration values for this chart values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file charts/ # A directory containing any charts upon which this chart depends. crds/ # Custom Resource Definitions templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Helm reserviert die Verwendung der Verzeichnisse `charts/`, `crds/` und `templates/` sowie der aufgelisteten Dateinamen. Andere Dateien bleiben unverändert. ## Die Chart.yaml-Datei Die `Chart.yaml`-Datei ist für ein Chart erforderlich. Sie enthält die folgenden Felder: ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` Ab [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2) sind zusätzliche Felder nicht erlaubt. Der empfohlene Ansatz ist, benutzerdefinierte Metadaten in `annotations` hinzuzufügen. ### Charts und Versionierung Jedes Chart muss eine Versionsnummer haben. Eine Version sollte dem [SemVer 2](https://semver.org/spec/v2.0.0.html)-Standard folgen, wird aber nicht strikt erzwungen. Im Gegensatz zu Helm Classic verwenden Helm v2 und spätere Versionen Versionsnummern als Release-Markierungen. Pakete in Repositories werden durch Name plus Version identifiziert. Beispielsweise wird ein `nginx`-Chart, dessen Versionsfeld auf `version: 1.2.3` gesetzt ist, wie folgt benannt: ```text nginx-1.2.3.tgz ``` Komplexere SemVer-2-Namen werden ebenfalls unterstützt, wie z.B. `version: 1.2.3-alpha.1+ef365`. Nicht-SemVer-Namen sind jedoch vom System explizit nicht erlaubt. Eine Ausnahme bilden Versionen im Format `x` oder `x.y`. Wenn beispielsweise ein führendes v vorhanden ist oder eine Version ohne alle 3 Teile angegeben wird (z.B. v1.2), wird versucht, sie in eine gültige semantische Version umzuwandeln (z.B. v1.2.0). **HINWEIS:** Während Helm Classic und Deployment Manager beide sehr GitHub-orientiert waren, wenn es um Charts ging, verlässt sich Helm v2 und später weder auf GitHub noch erfordert es Git. Folglich verwendet es überhaupt keine Git-SHAs zur Versionierung. Das `version`-Feld in der `Chart.yaml` wird von vielen Helm-Tools verwendet, einschließlich der CLI. Beim Generieren eines Pakets verwendet der `helm package`-Befehl die Version, die er in der `Chart.yaml` findet, als Token im Paketnamen. Das System geht davon aus, dass die Versionsnummer im Chart-Paketnamen mit der Versionsnummer in der `Chart.yaml` übereinstimmt. Eine Nichterfüllung dieser Annahme führt zu einem Fehler. ### Das `apiVersion`-Feld Das `apiVersion`-Feld sollte für Helm-Charts, die mindestens Helm 3 erfordern, `v2` sein. Charts, die frühere Helm-Versionen unterstützen, haben `apiVersion` auf `v1` gesetzt und können weiterhin von Helm 3 installiert werden. Änderungen von `v1` zu `v2`: - Ein `dependencies`-Feld, das Chart-Abhängigkeiten definiert, die sich bei `v1`-Charts in einer separaten `requirements.yaml`-Datei befanden (siehe [Chart-Abhängigkeiten](#chart-abhängigkeiten)). - Das `type`-Feld, das zwischen Application- und Library-Charts unterscheidet (siehe [Chart-Typen](#chart-typen)). ### Das `appVersion`-Feld Beachten Sie, dass das `appVersion`-Feld nicht mit dem `version`-Feld zusammenhängt. Es dient zur Angabe der Version der Anwendung. Beispielsweise könnte das `drupal`-Chart ein `appVersion: "8.2.1"` haben, was angibt, dass die im Chart enthaltene Drupal-Version (standardmäßig) `8.2.1` ist. Dieses Feld ist informativ und hat keinen Einfluss auf Chart-Versionsberechnungen. Es wird dringend empfohlen, die Version in Anführungszeichen zu setzen. Dies zwingt den YAML-Parser, die Versionsnummer als String zu behandeln. Ohne Anführungszeichen kann es in einigen Fällen zu Parsing-Problemen kommen. Beispielsweise interpretiert YAML `1.0` als Gleitkommawert und einen Git-Commit-SHA wie `1234e10` als wissenschaftliche Notation. Ab Helm v3.5.0 setzt `helm create` das standardmäßige `appVersion`-Feld in Anführungszeichen. ### Das `kubeVersion`-Feld Das optionale `kubeVersion`-Feld kann SemVer-Einschränkungen für unterstützte Kubernetes-Versionen definieren. Helm validiert die Versionseinschränkungen bei der Installation des Charts und schlägt fehl, wenn der Cluster eine nicht unterstützte Kubernetes-Version verwendet. Versionseinschränkungen können aus durch Leerzeichen getrennten UND-Vergleichen bestehen, wie z.B.: ``` >= 1.13.0 < 1.15.0 ``` Diese können wiederum mit dem ODER-Operator `||` kombiniert werden, wie im folgenden Beispiel: ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` In diesem Beispiel ist die Version `1.14.0` ausgeschlossen, was sinnvoll sein kann, wenn ein Bug in bestimmten Versionen das ordnungsgemäße Funktionieren des Charts verhindert. Neben Versionseinschränkungen mit den Operatoren `=` `!=` `>` `<` `>=` `<=` werden folgende Kurzschreibweisen unterstützt: * Bindestrich-Bereiche für geschlossene Intervalle, wobei `1.1 - 2.3.4` äquivalent zu `>= 1.1 <= 2.3.4` ist. * Wildcards `x`, `X` und `*`, wobei `1.2.x` äquivalent zu `>= 1.2.0 < 1.3.0` ist. * Tilde-Bereiche (Patch-Versionsänderungen erlaubt), wobei `~1.2.3` äquivalent zu `>= 1.2.3 < 1.3.0` ist. * Caret-Bereiche (Minor-Versionsänderungen erlaubt), wobei `^1.2.3` äquivalent zu `>= 1.2.3 < 2.0.0` ist. Für eine detaillierte Erklärung der unterstützten SemVer-Einschränkungen siehe [Masterminds/semver](https://github.com/Masterminds/semver). ### Charts als veraltet markieren Bei der Verwaltung von Charts in einem Chart Repository ist es manchmal notwendig, ein Chart als veraltet zu markieren. Das optionale `deprecated`-Feld in `Chart.yaml` kann verwendet werden, um ein Chart als veraltet zu kennzeichnen. Wenn die **neueste** Version eines Charts im Repository als veraltet markiert ist, wird das Chart insgesamt als veraltet betrachtet. Der Chart-Name kann später wiederverwendet werden, indem eine neuere Version veröffentlicht wird, die nicht als veraltet markiert ist. Der Workflow für das Veraltmarkieren von Charts ist: 1. Aktualisieren Sie die `Chart.yaml` des Charts, um es als veraltet zu markieren, und erhöhen Sie die Version 2. Veröffentlichen Sie die neue Chart-Version im Chart Repository 3. Entfernen Sie das Chart aus dem Quell-Repository (z.B. git) ### Chart-Typen Das `type`-Feld definiert den Typ des Charts. Es gibt zwei Typen: `application` und `library`. Application ist der Standardtyp und das Standard-Chart, das vollständig betrieben werden kann. Das [Library-Chart](/topics/library_charts.md) stellt Dienstprogramme oder Funktionen für den Chart-Builder bereit. Ein Library-Chart unterscheidet sich von einem Application-Chart dadurch, dass es nicht installierbar ist und normalerweise keine Ressourcenobjekte enthält. **Hinweis:** Ein Application-Chart kann als Library-Chart verwendet werden. Dies wird aktiviert, indem der Typ auf `library` gesetzt wird. Das Chart wird dann als Library-Chart gerendert, wobei alle Dienstprogramme und Funktionen genutzt werden können. Alle Ressourcenobjekte des Charts werden nicht gerendert. ## Chart LICENSE, README und NOTES Charts können auch Dateien enthalten, die die Installation, Konfiguration, Verwendung und Lizenz eines Charts beschreiben. Eine LICENSE ist eine Klartextdatei, die die [Lizenz](https://en.wikipedia.org/wiki/Software_license) für das Chart enthält. Das Chart kann eine Lizenz enthalten, da es möglicherweise Programmierlogik in den Templates hat und daher nicht nur Konfiguration wäre. Es kann auch separate Lizenz(en) für die vom Chart installierte Anwendung geben, falls erforderlich. Eine README für ein Chart sollte in Markdown formatiert sein (README.md) und sollte im Allgemeinen enthalten: - Eine Beschreibung der Anwendung oder des Dienstes, den das Chart bereitstellt - Alle Voraussetzungen oder Anforderungen zum Ausführen des Charts - Beschreibungen der Optionen in `values.yaml` und Standardwerte - Alle anderen Informationen, die für die Installation oder Konfiguration des Charts relevant sein könnten Wenn Hubs und andere Benutzeroberflächen Details über ein Chart anzeigen, werden diese Informationen aus dem Inhalt der `README.md`-Datei gezogen. Das Chart kann auch eine kurze Klartextdatei `templates/NOTES.txt` enthalten, die nach der Installation und beim Anzeigen des Status eines Release ausgegeben wird. Diese Datei wird als [Template](#templates-und-values) ausgewertet und kann verwendet werden, um Nutzungshinweise, nächste Schritte oder andere für ein Release des Charts relevante Informationen anzuzeigen. Beispielsweise könnten Anweisungen zum Verbinden mit einer Datenbank oder zum Zugriff auf eine Web-UI bereitgestellt werden. Da diese Datei beim Ausführen von `helm install` oder `helm status` nach STDOUT ausgegeben wird, wird empfohlen, den Inhalt kurz zu halten und für weitere Details auf die README zu verweisen. ## Chart-Abhängigkeiten In Helm kann ein Chart von einer beliebigen Anzahl anderer Charts abhängen. Diese Abhängigkeiten können dynamisch über das `dependencies`-Feld in `Chart.yaml` verknüpft oder im `charts/`-Verzeichnis abgelegt und manuell verwaltet werden. ### Abhängigkeiten mit dem `dependencies`-Feld verwalten Die vom aktuellen Chart benötigten Charts werden als Liste im `dependencies`-Feld definiert. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Das `name`-Feld ist der Name des gewünschten Charts. - Das `version`-Feld ist die Version des gewünschten Charts. - Das `repository`-Feld ist die vollständige URL zum Chart Repository. Beachten Sie, dass Sie dieses Repository auch lokal mit `helm repo add` hinzufügen müssen. - Sie können auch den Namen des Repos anstelle der URL verwenden ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Sobald Sie Abhängigkeiten definiert haben, können Sie `helm dependency update` ausführen, und es wird Ihre Abhängigkeitsdatei verwenden, um alle angegebenen Charts in Ihr `charts/`-Verzeichnis herunterzuladen. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Wenn `helm dependency update` Charts abruft, speichert es diese als Chart-Archive im `charts/`-Verzeichnis. Im obigen Beispiel würde man also die folgenden Dateien im charts-Verzeichnis erwarten: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Das Alias-Feld in Abhängigkeiten Zusätzlich zu den anderen oben genannten Feldern kann jeder Abhängigkeitseintrag das optionale Feld `alias` enthalten. Das Hinzufügen eines Alias für ein abhängiges Chart fügt ein Chart unter Verwendung des Alias als Namen der neuen Abhängigkeit in die Abhängigkeiten ein. Sie können `alias` in Fällen verwenden, in denen Sie auf ein Chart mit anderen Namen zugreifen müssen. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` Im obigen Beispiel erhalten wir insgesamt 3 Abhängigkeiten für `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` Der manuelle Weg, dies zu erreichen, wäre das Kopieren und Einfügen desselben Charts im `charts/`-Verzeichnis mehrfach mit verschiedenen Namen. #### Tags- und Condition-Felder in Abhängigkeiten Zusätzlich zu den anderen oben genannten Feldern kann jeder Abhängigkeitseintrag die optionalen Felder `tags` und `condition` enthalten. Alle Charts werden standardmäßig geladen. Wenn `tags`- oder `condition`-Felder vorhanden sind, werden sie ausgewertet und verwendet, um das Laden der Charts zu steuern, auf die sie angewendet werden. Condition - Das condition-Feld enthält einen oder mehrere YAML-Pfade (durch Kommas getrennt). Wenn dieser Pfad in den Values des übergeordneten Charts existiert und zu einem booleschen Wert aufgelöst wird, wird das Chart basierend auf diesem booleschen Wert aktiviert oder deaktiviert. Nur der erste gültige gefundene Pfad in der Liste wird ausgewertet, und wenn keine Pfade existieren, hat die Condition keine Auswirkung. Tags - Das tags-Feld ist eine YAML-Liste von Labels, die mit diesem Chart verknüpft werden. In den Values des übergeordneten Charts können alle Charts mit Tags aktiviert oder deaktiviert werden, indem das Tag und ein boolescher Wert angegeben werden. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` Im obigen Beispiel würden alle Charts mit dem Tag `front-end` deaktiviert werden, aber da der `subchart1.enabled`-Pfad in den Values des übergeordneten Charts zu 'true' ausgewertet wird, überschreibt die Condition das `front-end`-Tag und `subchart1` wird aktiviert. Da `subchart2` mit `back-end` getaggt ist und dieses Tag zu `true` ausgewertet wird, wird `subchart2` aktiviert. Beachten Sie auch, dass, obwohl `subchart2` eine Condition angegeben hat, es keinen entsprechenden Pfad und Wert in den Values des übergeordneten Charts gibt, sodass diese Condition keine Auswirkung hat. ##### Verwendung der CLI mit Tags und Conditions Der `--set`-Parameter kann wie gewohnt verwendet werden, um Tag- und Condition-Werte zu ändern. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Auflösung von Tags und Conditions - **Conditions (wenn in Values gesetzt) überschreiben immer Tags.** Der erste existierende Condition-Pfad gewinnt, und nachfolgende für dieses Chart werden ignoriert. - Tags werden als 'wenn eines der Tags des Charts true ist, dann aktiviere das Chart' ausgewertet. - Tag- und Condition-Werte müssen in den Values des obersten übergeordneten Charts gesetzt werden. - Der `tags:`-Schlüssel in Values muss ein Schlüssel auf oberster Ebene sein. Globale und verschachtelte `tags:`-Tabellen werden derzeit nicht unterstützt. #### Importieren von Child-Values über Abhängigkeiten In einigen Fällen ist es wünschenswert, dass die Values eines untergeordneten Charts an das übergeordnete Chart weitergegeben und als gemeinsame Standardwerte geteilt werden. Ein zusätzlicher Vorteil der Verwendung des `exports`-Formats ist, dass es zukünftigen Tools ermöglicht, benutzerdefinierbare Werte zu inspizieren. Die Schlüssel, die die zu importierenden Werte enthalten, können im `dependencies`-Feld des übergeordneten Charts im Feld `import-values` als YAML-Liste angegeben werden. Jedes Element in der Liste ist ein Schlüssel, der aus dem `exports`-Feld des untergeordneten Charts importiert wird. Um Werte zu importieren, die nicht im `exports`-Schlüssel enthalten sind, verwenden Sie das [child-parent](#verwendung-des-child-parent-formats)-Format. Beispiele für beide Formate werden unten beschrieben. ##### Verwendung des exports-Formats Wenn die `values.yaml`-Datei eines untergeordneten Charts ein `exports`-Feld auf Root-Ebene enthält, können dessen Inhalte direkt in die Values des übergeordneten Charts importiert werden, indem die zu importierenden Schlüssel wie im folgenden Beispiel angegeben werden: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Da wir den Schlüssel `data` in unserer Importliste angeben, sucht Helm im `exports`-Feld des untergeordneten Charts nach dem `data`-Schlüssel und importiert dessen Inhalt. Die endgültigen Values des übergeordneten Charts würden unser exportiertes Feld enthalten: ```yaml # parent's values myint: 99 ``` Bitte beachten Sie, dass der übergeordnete Schlüssel `data` nicht in den endgültigen Values des übergeordneten Charts enthalten ist. Wenn Sie den übergeordneten Schlüssel angeben müssen, verwenden Sie das 'child-parent'-Format. ##### Verwendung des child-parent-Formats Um auf Werte zuzugreifen, die nicht im `exports`-Schlüssel der Values des untergeordneten Charts enthalten sind, müssen Sie den Quellschlüssel der zu importierenden Werte (`child`) und den Zielpfad in den Values des übergeordneten Charts (`parent`) angeben. Das `import-values` im folgenden Beispiel weist Helm an, alle Werte, die unter dem `child:`-Pfad gefunden werden, zu nehmen und sie in die Values des übergeordneten Charts unter dem in `parent:` angegebenen Pfad zu kopieren. ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` Im obigen Beispiel werden Werte, die unter `default.data` in den Values von subchart1 gefunden werden, in den `myimports`-Schlüssel in den Values des übergeordneten Charts importiert, wie unten beschrieben: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` Die resultierenden Values des übergeordneten Charts wären: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Die endgültigen Values des übergeordneten Charts enthalten jetzt die aus subchart1 importierten Felder `myint` und `mybool`. ### Abhängigkeiten manuell über das `charts/`-Verzeichnis verwalten Wenn mehr Kontrolle über Abhängigkeiten gewünscht wird, können diese Abhängigkeiten explizit ausgedrückt werden, indem die abhängigen Charts in das `charts/`-Verzeichnis kopiert werden. Eine Abhängigkeit sollte ein entpacktes Chart-Verzeichnis sein, aber sein Name darf nicht mit `_` oder `.` beginnen. Solche Dateien werden vom Chart-Loader ignoriert. Wenn beispielsweise das WordPress-Chart vom Apache-Chart abhängt, wird das Apache-Chart (in der korrekten Version) im `charts/`-Verzeichnis des WordPress-Charts bereitgestellt: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` Das obige Beispiel zeigt, wie das WordPress-Chart seine Abhängigkeit von Apache und MySQL ausdrückt, indem es diese Charts in sein `charts/`-Verzeichnis einschließt. **TIPP:** _Um eine Abhängigkeit in Ihr `charts/`-Verzeichnis zu laden, verwenden Sie den Befehl `helm pull`._ ### Betriebsaspekte bei der Verwendung von Abhängigkeiten Die obigen Abschnitte erklären, wie Chart-Abhängigkeiten angegeben werden, aber wie wirkt sich dies auf die Chart-Installation mit `helm install` und `helm upgrade` aus? Angenommen, ein Chart namens "A" erstellt die folgenden Kubernetes-Objekte: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Darüber hinaus ist A von Chart B abhängig, das folgende Objekte erstellt: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Nach der Installation/dem Upgrade von Chart A wird ein einzelnes Helm-Release erstellt/geändert. Das Release erstellt/aktualisiert alle oben genannten Kubernetes-Objekte in der folgenden Reihenfolge: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Der Grund dafür ist, dass Helm bei der Installation/dem Upgrade von Charts die Kubernetes-Objekte aus den Charts und allen ihren Abhängigkeiten: - in einer einzigen Menge zusammenfasst, - nach Typ und dann nach Name sortiert, - in dieser Reihenfolge erstellt/aktualisiert. Daher wird ein einzelnes Release mit allen Objekten für das Chart und seine Abhängigkeiten erstellt. Die Installationsreihenfolge von Kubernetes-Typen wird durch die Aufzählung InstallOrder in kind_sorter.go gegeben (siehe [die Helm-Quelldatei](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates und Values Helm-Chart-Templates werden in der [Go-Template-Sprache](https://golang.org/pkg/text/template/) geschrieben, mit etwa 50 zusätzlichen Template-Funktionen [aus der Sprig-Bibliothek](https://github.com/Masterminds/sprig) und einigen anderen [spezialisierten Funktionen](/howto/charts_tips_and_tricks.md). Alle Template-Dateien werden im `templates/`-Ordner eines Charts gespeichert. Wenn Helm die Charts rendert, übergibt es jede Datei in diesem Verzeichnis an die Template-Engine. Values für die Templates werden auf zwei Arten bereitgestellt: - Chart-Entwickler können eine Datei namens `values.yaml` innerhalb eines Charts bereitstellen. Diese Datei kann Standardwerte enthalten. - Chart-Benutzer können eine YAML-Datei bereitstellen, die Values enthält. Diese kann bei der Befehlszeile mit `helm install` angegeben werden. Wenn ein Benutzer benutzerdefinierte Values bereitstellt, überschreiben diese Values die Werte in der `values.yaml`-Datei des Charts. ### Template-Dateien Template-Dateien folgen den Standardkonventionen für das Schreiben von Go-Templates (siehe [die text/template Go-Paket-Dokumentation](https://golang.org/pkg/text/template/) für Details). Eine Beispiel-Template-Datei könnte etwa so aussehen: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` Das obige Beispiel, lose basierend auf [https://github.com/deis/charts](https://github.com/deis/charts), ist ein Template für einen Kubernetes Replication Controller. Es kann die folgenden vier Template-Values verwenden (normalerweise in einer `values.yaml`-Datei definiert): - `imageRegistry`: Die Quell-Registry für das Docker-Image. - `dockerTag`: Das Tag für das Docker-Image. - `pullPolicy`: Die Kubernetes-Pull-Policy. - `storage`: Das Storage-Backend, dessen Standard auf `"minio"` gesetzt ist. Alle diese Werte werden vom Template-Autor definiert. Helm schreibt keine Parameter vor oder erfordert sie. Um viele funktionierende Charts zu sehen, schauen Sie sich den CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) an. ### Vordefinierte Values Values, die über eine `values.yaml`-Datei (oder über das `--set`-Flag) bereitgestellt werden, sind über das `.Values`-Objekt in einem Template zugänglich. Es gibt aber auch andere vordefinierte Daten, auf die Sie in Ihren Templates zugreifen können. Die folgenden Values sind vordefiniert, in jedem Template verfügbar und können nicht überschrieben werden. Wie bei allen Values sind die Namen _case-sensitive_. - `Release.Name`: Der Name des Release (nicht des Charts) - `Release.Namespace`: Der Namespace, in dem das Chart released wurde. - `Release.Service`: Der Dienst, der das Release durchgeführt hat. - `Release.IsUpgrade`: Dies ist auf true gesetzt, wenn die aktuelle Operation ein Upgrade oder Rollback ist. - `Release.IsInstall`: Dies ist auf true gesetzt, wenn die aktuelle Operation eine Installation ist. - `Chart`: Der Inhalt der `Chart.yaml`. So ist die Chart-Version als `Chart.Version` und die Maintainer als `Chart.Maintainers` erhältlich. - `Files`: Ein Map-ähnliches Objekt, das alle nicht-speziellen Dateien im Chart enthält. Dies gibt Ihnen keinen Zugriff auf Templates, aber auf zusätzliche Dateien, die vorhanden sind (es sei denn, sie werden mit `.helmignore` ausgeschlossen). Dateien können mit `{{ index .Files "file.name" }}` oder mit der `{{.Files.Get name }}`-Funktion zugegriffen werden. Sie können auch auf den Inhalt der Datei als `[]byte` mit `{{ .Files.GetBytes }}` zugreifen. - `Capabilities`: Ein Map-ähnliches Objekt, das Informationen über die Kubernetes-Versionen (`{{ .Capabilities.KubeVersion }}`) und die unterstützten Kubernetes-API-Versionen (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) enthält. **HINWEIS:** Alle unbekannten `Chart.yaml`-Felder werden verworfen. Sie sind innerhalb des `Chart`-Objekts nicht zugänglich. Daher kann `Chart.yaml` nicht verwendet werden, um beliebig strukturierte Daten an das Template zu übergeben. Die Values-Datei kann jedoch dafür verwendet werden. ### Values-Dateien Unter Berücksichtigung des Templates im vorherigen Abschnitt würde eine `values.yaml`-Datei, die die notwendigen Werte bereitstellt, so aussehen: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Eine Values-Datei ist im YAML-Format. Ein Chart kann eine Standard-`values.yaml`-Datei enthalten. Der Helm-Install-Befehl ermöglicht es einem Benutzer, Werte zu überschreiben, indem zusätzliche YAML-Werte bereitgestellt werden: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Wenn Werte auf diese Weise übergeben werden, werden sie in die Standard-Values-Datei gemergt. Betrachten Sie beispielsweise eine `myvals.yaml`-Datei, die so aussieht: ```yaml storage: "gcs" ``` Wenn dies mit der `values.yaml` im Chart gemergt wird, ist der resultierende generierte Inhalt: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Beachten Sie, dass nur das letzte Feld überschrieben wurde. **HINWEIS:** Die Standard-Values-Datei innerhalb eines Charts _muss_ `values.yaml` heißen. Aber Dateien, die auf der Befehlszeile angegeben werden, können beliebig benannt werden. **HINWEIS:** Wenn das `--set`-Flag bei `helm install` oder `helm upgrade` verwendet wird, werden diese Werte einfach clientseitig in YAML konvertiert. **HINWEIS:** Wenn erforderliche Einträge in der Values-Datei existieren, können sie im Chart-Template mit der ['required'-Funktion](/howto/charts_tips_and_tricks.md) als erforderlich deklariert werden. Alle diese Werte sind dann innerhalb von Templates über das `.Values`-Objekt zugänglich: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Scope, Abhängigkeiten und Values Values-Dateien können Werte für das Top-Level-Chart sowie für alle Charts deklarieren, die im `charts/`-Verzeichnis dieses Charts enthalten sind. Anders ausgedrückt: Eine Values-Datei kann Werte sowohl an das Chart als auch an seine Abhängigkeiten liefern. Das demonstrative WordPress-Chart oben hat beispielsweise sowohl `mysql` als auch `apache` als Abhängigkeiten. Die Values-Datei könnte Werte an all diese Komponenten liefern: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Charts auf einer höheren Ebene haben Zugriff auf alle Variablen, die darunter definiert sind. So kann das WordPress-Chart auf das MySQL-Passwort als `.Values.mysql.password` zugreifen. Charts auf niedrigerer Ebene können jedoch nicht auf Dinge in übergeordneten Charts zugreifen, sodass MySQL nicht auf die `title`-Eigenschaft zugreifen kann. Ebenso wenig kann es auf `apache.port` zugreifen. Values sind mit Namespaces versehen, aber Namespaces werden gekürzt. Für das WordPress-Chart kann es also auf das MySQL-Passwortfeld als `.Values.mysql.password` zugreifen. Für das MySQL-Chart wurde jedoch der Scope der Values reduziert und das Namespace-Präfix entfernt, sodass es das Passwortfeld einfach als `.Values.password` sieht. #### Globale Values Ab Version 2.0.0-Alpha.2 unterstützt Helm spezielle "globale" Values. Betrachten Sie diese modifizierte Version des vorherigen Beispiels: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Das Obige fügt einen `global`-Abschnitt mit dem Wert `app: MyWordPress` hinzu. Dieser Wert ist für _alle_ Charts als `.Values.global.app` verfügbar. Beispielsweise können die `mysql`-Templates auf `app` als `{{ .Values.global.app }}` zugreifen, ebenso das `apache`-Chart. Effektiv wird die Values-Datei oben so regeneriert: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` So lässt sich eine Top-Level-Variable mit allen Subcharts teilen, was für Dinge wie das Setzen von `metadata`-Eigenschaften wie Labels nützlich ist. Wenn ein Subchart eine globale Variable deklariert, wird diese _abwärts_ (an die Subcharts des Subcharts) übergeben, aber nicht _aufwärts_ an das übergeordnete Chart. Ein Subchart kann die Values des übergeordneten Charts nicht beeinflussen. Globale Variablen von übergeordneten Charts haben Vorrang vor den globalen Variablen von Subcharts. ### Schema-Dateien Manchmal möchte ein Chart-Maintainer eine Struktur für seine Values definieren. Dies kann durch die Definition eines Schemas in der `values.schema.json`-Datei erfolgen. Ein Schema wird als [JSON Schema](https://json-schema.org/) dargestellt. Es könnte etwa so aussehen: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Dieses Schema wird auf die Values angewendet, um sie zu validieren. Die Validierung erfolgt, wenn einer der folgenden Befehle aufgerufen wird: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Ein Beispiel für eine `values.yaml`-Datei, die die Anforderungen dieses Schemas erfüllt, könnte so aussehen: ```yaml name: frontend protocol: https port: 443 ``` Beachten Sie, dass das Schema auf das endgültige `.Values`-Objekt angewendet wird, nicht nur auf die `values.yaml`-Datei. Das bedeutet, dass die folgende `yaml`-Datei gültig ist, wenn das Chart mit der entsprechenden `--set`-Option installiert wird, wie unten gezeigt. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Außerdem wird das endgültige `.Values`-Objekt gegen *alle* Subchart-Schemas geprüft. Das bedeutet, dass Einschränkungen in einem Subchart nicht durch ein übergeordnetes Chart umgangen werden können. Dies funktioniert auch umgekehrt - wenn ein Subchart eine Anforderung hat, die in der `values.yaml`-Datei des Subcharts nicht erfüllt ist, *muss* das übergeordnete Chart diese Einschränkungen erfüllen, um gültig zu sein. Die Schema-Validierung kann mit der unten gezeigten Option deaktiviert werden. Dies ist besonders nützlich in Air-Gapped-Umgebungen, wenn die JSON-Schema-Datei eines Charts Remote-Referenzen enthält. ```console helm install --skip-schema-validation ``` ### Referenzen Beim Schreiben von Templates, Values und Schema-Dateien gibt es mehrere Standardreferenzen, die Ihnen helfen werden. - [Go-Templates](https://godoc.org/text/template) - [Zusätzliche Template-Funktionen](https://godoc.org/github.com/Masterminds/sprig) - [Das YAML-Format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) Kubernetes bietet einen Mechanismus zum Deklarieren neuer Arten von Kubernetes-Objekten. Mit CustomResourceDefinitions (CRDs) können Kubernetes-Entwickler benutzerdefinierte Ressourcentypen deklarieren. In Helm 3 werden CRDs als eine spezielle Art von Objekt behandelt. Sie werden vor dem Rest des Charts installiert und unterliegen einigen Einschränkungen. CRD-YAML-Dateien sollten im `crds/`-Verzeichnis innerhalb eines Charts platziert werden. Mehrere CRDs (getrennt durch YAML-Start- und End-Marker) können in derselben Datei platziert werden. Helm versucht, _alle_ Dateien im CRD-Verzeichnis in Kubernetes zu laden. CRD-Dateien _können nicht als Template verwendet werden_. Sie müssen einfache YAML-Dokumente sein. Wenn Helm ein neues Chart installiert, lädt es die CRDs hoch, pausiert, bis die CRDs vom API-Server verfügbar gemacht werden, und startet dann die Template-Engine, rendert den Rest des Charts und lädt ihn in Kubernetes hoch. Aufgrund dieser Reihenfolge sind CRD-Informationen im `.Capabilities`-Objekt in Helm-Templates verfügbar, und Helm-Templates können neue Instanzen von Objekten erstellen, die in CRDs deklariert wurden. Wenn Ihr Chart beispielsweise eine CRD für `CronTab` im `crds/`-Verzeichnis hat, können Sie Instanzen der `CronTab`-Art im `templates/`-Verzeichnis erstellen: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Die `crontab.yaml`-Datei muss die CRD ohne Template-Direktiven enthalten: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Dann kann das Template `mycrontab.yaml` eine neue `CronTab` erstellen (unter Verwendung von Templates wie üblich): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm stellt sicher, dass die `CronTab`-Art installiert wurde und vom Kubernetes-API-Server verfügbar ist, bevor es mit der Installation der Dinge in `templates/` fortfährt. ### Einschränkungen bei CRDs Im Gegensatz zu den meisten Objekten in Kubernetes werden CRDs global installiert. Aus diesem Grund verfolgt Helm einen sehr vorsichtigen Ansatz bei der Verwaltung von CRDs. CRDs unterliegen den folgenden Einschränkungen: - CRDs werden niemals neu installiert. Wenn Helm feststellt, dass die CRDs im `crds/`-Verzeichnis bereits vorhanden sind (unabhängig von der Version), versucht Helm nicht, sie zu installieren oder zu aktualisieren. - CRDs werden bei Upgrades oder Rollbacks niemals installiert. Helm erstellt CRDs nur bei Installationsoperationen. - CRDs werden niemals gelöscht. Das Löschen einer CRD löscht automatisch alle Inhalte der CRD über alle Namespaces im Cluster hinweg. Folglich löscht Helm keine CRDs. Operatoren, die CRDs aktualisieren oder löschen möchten, werden ermutigt, dies manuell und mit großer Vorsicht zu tun. ## Verwendung von Helm zur Verwaltung von Charts Das `helm`-Tool verfügt über mehrere Befehle für die Arbeit mit Charts. Es kann ein neues Chart für Sie erstellen: ```console $ helm create mychart Created mychart/ ``` Sobald Sie ein Chart bearbeitet haben, kann `helm` es für Sie in ein Chart-Archiv verpacken: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Sie können `helm` auch verwenden, um Probleme mit der Formatierung oder den Informationen Ihres Charts zu finden: ```console $ helm lint mychart No issues found ``` ## Chart Repositories Ein _Chart Repository_ ist ein HTTP-Server, der ein oder mehrere verpackte Charts hostet. Während `helm` zur Verwaltung lokaler Chart-Verzeichnisse verwendet werden kann, ist bei der gemeinsamen Nutzung von Charts der bevorzugte Mechanismus ein Chart Repository. Jeder HTTP-Server, der YAML-Dateien und tar-Dateien bereitstellen und GET-Anfragen beantworten kann, kann als Repository-Server verwendet werden. Das Helm-Team hat einige Server getestet, darunter Google Cloud Storage mit aktiviertem Website-Modus und S3 mit aktiviertem Website-Modus. Ein Repository zeichnet sich hauptsächlich durch das Vorhandensein einer speziellen Datei namens `index.yaml` aus, die eine Liste aller vom Repository bereitgestellten Pakete enthält, zusammen mit Metadaten, die das Abrufen und Verifizieren dieser Pakete ermöglichen. Auf der Client-Seite werden Repositories mit den `helm repo`-Befehlen verwaltet. Helm bietet jedoch keine Tools zum Hochladen von Charts auf Remote-Repository-Server. Dies liegt daran, dass dies erhebliche Anforderungen an einen implementierenden Server stellen und somit die Hürde für die Einrichtung eines Repositorys erhöhen würde. ## Chart Starter Packs Der `helm create`-Befehl nimmt eine optionale `--starter`-Option an, mit der Sie ein "Starter-Chart" angeben können. Die Starter-Option hat auch einen kurzen Alias `-p`. Beispiele für die Verwendung: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Starter sind einfach reguläre Charts, befinden sich aber in `$XDG_DATA_HOME/helm/starters`. Als Chart-Entwickler können Sie Charts erstellen, die speziell für die Verwendung als Starter konzipiert sind. Solche Charts sollten mit den folgenden Überlegungen entworfen werden: - Die `Chart.yaml` wird vom Generator überschrieben. - Benutzer werden erwarten, den Inhalt eines solchen Charts zu modifizieren, daher sollte die Dokumentation angeben, wie Benutzer dies tun können. - Alle Vorkommen von `` werden durch den angegebenen Chart-Namen ersetzt, sodass Starter-Charts als Vorlagen verwendet werden können, außer in einigen Variablendateien. Wenn Sie beispielsweise benutzerdefinierte Dateien im `vars`-Verzeichnis oder bestimmte `README.md`-Dateien verwenden, wird `` darin NICHT ersetzt. Zusätzlich wird die Chart-Beschreibung nicht vererbt. Derzeit ist die einzige Möglichkeit, ein Chart zu `$XDG_DATA_HOME/helm/starters` hinzuzufügen, es manuell dorthin zu kopieren. In der Dokumentation Ihres Charts sollten Sie diesen Prozess möglicherweise erklären. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Chart Hooks description: Beschreibt die Arbeit mit Chart Hooks. sidebar_position: 2 --- Helm bietet einen _Hook_-Mechanismus, der es Chart-Entwicklern ermöglicht, an bestimmten Punkten im Lebenszyklus eines Release einzugreifen. Sie können Hooks beispielsweise nutzen, um: - Eine ConfigMap oder ein Secret während der Installation zu laden, bevor andere Charts geladen werden. - Einen Job auszuführen, der vor der Installation eines neuen Charts eine Datenbank sichert, und anschließend einen zweiten Job nach dem Upgrade auszuführen, um die Daten wiederherzustellen. - Einen Job vor dem Löschen eines Release auszuführen, um einen Dienst ordnungsgemäß aus der Rotation zu nehmen, bevor er entfernt wird. Hooks funktionieren wie reguläre Templates, verfügen jedoch über spezielle Annotationen, die Helm veranlassen, sie anders zu behandeln. In diesem Abschnitt behandeln wir das grundlegende Nutzungsmuster für Hooks. ## Die verfügbaren Hooks Folgende Hooks sind definiert: | Annotationswert | Beschreibung | | ---------------- | ------------------------------------------------------------------------------------------------------ | | `pre-install` | Wird ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen in Kubernetes erstellt werden | | `post-install` | Wird ausgeführt, nachdem alle Ressourcen in Kubernetes geladen wurden | | `pre-delete` | Wird bei einer Löschanfrage ausgeführt, bevor Ressourcen aus Kubernetes gelöscht werden | | `post-delete` | Wird bei einer Löschanfrage ausgeführt, nachdem alle Ressourcen des Release gelöscht wurden | | `pre-upgrade` | Wird bei einer Upgrade-Anfrage ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen aktualisiert werden | | `post-upgrade` | Wird bei einer Upgrade-Anfrage ausgeführt, nachdem alle Ressourcen aktualisiert wurden | | `pre-rollback` | Wird bei einer Rollback-Anfrage ausgeführt, nachdem Templates gerendert wurden, aber bevor Ressourcen zurückgerollt werden | | `post-rollback` | Wird bei einer Rollback-Anfrage ausgeführt, nachdem alle Ressourcen geändert wurden | | `test` | Wird ausgeführt, wenn der Helm-Unterbefehl test aufgerufen wird ([siehe Testdokumentation](/topics/chart_tests.md)) | _Hinweis: Der `crd-install` Hook wurde in Helm 3 zugunsten des `crds/`-Verzeichnisses entfernt._ ## Hooks und der Release-Lebenszyklus Hooks bieten Ihnen als Chart-Entwickler die Möglichkeit, Operationen an strategischen Punkten im Lebenszyklus eines Release durchzuführen. Betrachten Sie beispielsweise den Lebenszyklus einer `helm install`-Operation. Standardmäßig sieht der Lebenszyklus so aus: 1. Der Benutzer führt `helm install foo` aus 2. Die Install-API der Helm-Bibliothek wird aufgerufen 3. Nach einigen Validierungen rendert die Bibliothek die `foo`-Templates 4. Die Bibliothek lädt die resultierenden Ressourcen in Kubernetes 5. Die Bibliothek gibt das Release-Objekt (und andere Daten) an den Client zurück 6. Der Client wird beendet Helm definiert zwei Hooks für den `install`-Lebenszyklus: `pre-install` und `post-install`. Wenn der Entwickler des `foo`-Charts beide Hooks implementiert, ändert sich der Lebenszyklus wie folgt: 1. Der Benutzer führt `helm install foo` aus 2. Die Install-API der Helm-Bibliothek wird aufgerufen 3. CRDs im `crds/`-Verzeichnis werden installiert 4. Nach einigen Validierungen rendert die Bibliothek die `foo`-Templates 5. Die Bibliothek bereitet die Ausführung der `pre-install` Hooks vor (lädt Hook-Ressourcen in Kubernetes) 6. Die Bibliothek sortiert Hooks nach Gewichtung (standardmäßig wird eine Gewichtung von 0 zugewiesen), dann nach Ressourcentyp und schließlich nach Name in aufsteigender Reihenfolge. 7. Die Bibliothek lädt dann den Hook mit der niedrigsten Gewichtung zuerst (negativ bis positiv) 8. Die Bibliothek wartet, bis der Hook "Ready" ist (außer bei CRDs) 9. Die Bibliothek lädt die resultierenden Ressourcen in Kubernetes. Wenn das `--wait`-Flag gesetzt ist, wartet die Bibliothek, bis alle Ressourcen bereit sind, und führt den `post-install` Hook erst aus, wenn sie bereit sind. 10. Die Bibliothek führt den `post-install` Hook aus (lädt Hook-Ressourcen) 11. Die Bibliothek wartet, bis der Hook "Ready" ist 12. Die Bibliothek gibt das Release-Objekt (und andere Daten) an den Client zurück 13. Der Client wird beendet Was bedeutet es, zu warten, bis ein Hook bereit ist? Das hängt von der im Hook deklarierten Ressource ab. Bei Ressourcen vom Typ `Job` oder `Pod` wartet Helm, bis diese erfolgreich abgeschlossen sind. Wenn der Hook fehlschlägt, schlägt auch das Release fehl. Dies ist eine _blockierende Operation_, sodass der Helm-Client während der Ausführung des Jobs pausiert. Bei allen anderen Ressourcentypen gilt eine Ressource als "Ready", sobald Kubernetes sie als geladen (hinzugefügt oder aktualisiert) markiert. Wenn mehrere Ressourcen in einem Hook deklariert sind, werden die Ressourcen seriell ausgeführt. Wenn sie Hook-Gewichtungen haben (siehe unten), werden sie in gewichteter Reihenfolge ausgeführt. Ab Helm 3.2.0 werden Hook-Ressourcen mit gleicher Gewichtung in derselben Reihenfolge wie normale Nicht-Hook-Ressourcen installiert. Andernfalls ist die Reihenfolge nicht garantiert. (In Helm 2.3.0 und später wurden sie alphabetisch sortiert. Dieses Verhalten ist jedoch nicht bindend und könnte sich in Zukunft ändern.) Es gilt als gute Praxis, eine Hook-Gewichtung hinzuzufügen und sie auf `0` zu setzen, wenn die Gewichtung nicht wichtig ist. ### Hook-Ressourcen werden nicht mit den zugehörigen Releases verwaltet Die von einem Hook erstellten Ressourcen werden derzeit nicht als Teil des Release verfolgt oder verwaltet. Sobald Helm verifiziert hat, dass der Hook seinen Ready-Status erreicht hat, belässt es die Hook-Ressource unverändert. Die Garbage Collection von Hook-Ressourcen beim Löschen des zugehörigen Release könnte in Zukunft zu Helm 3 hinzugefügt werden, daher sollten Hook-Ressourcen, die niemals gelöscht werden dürfen, mit `helm.sh/resource-policy: keep` annotiert werden. Praktisch bedeutet dies: Wenn Sie Ressourcen in einem Hook erstellen, können Sie sich nicht darauf verlassen, dass `helm uninstall` diese Ressourcen entfernt. Um solche Ressourcen zu zerstören, müssen Sie entweder [eine benutzerdefinierte `helm.sh/hook-delete-policy`-Annotation](#hook-löschrichtlinien) zur Hook-Template-Datei hinzufügen oder [das Time-to-Live (TTL)-Feld einer Job-Ressource setzen](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Einen Hook schreiben Hooks sind einfach Kubernetes-Manifest-Dateien mit speziellen Annotationen im `metadata`-Abschnitt. Da es sich um Template-Dateien handelt, können Sie alle normalen Template-Funktionen nutzen, einschließlich des Lesens von `.Values`, `.Release` und `.Template`. Das folgende Template, gespeichert unter `templates/post-install-job.yaml`, deklariert beispielsweise einen Job, der bei `post-install` ausgeführt wird: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Was dieses Template zu einem Hook macht, ist die Annotation: ```yaml annotations: "helm.sh/hook": post-install ``` Eine Ressource kann mehrere Hooks implementieren: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Ebenso gibt es keine Begrenzung für die Anzahl verschiedener Ressourcen, die einen bestimmten Hook implementieren können. Sie könnten beispielsweise sowohl ein Secret als auch eine ConfigMap als pre-install Hook deklarieren. Wenn Subcharts Hooks deklarieren, werden diese ebenfalls ausgewertet. Es gibt keine Möglichkeit für ein übergeordnetes Chart, die von Subcharts deklarierten Hooks zu deaktivieren. Es ist möglich, eine Gewichtung für einen Hook zu definieren, die bei der Bestimmung einer deterministischen Ausführungsreihenfolge hilft. Gewichtungen werden mit der folgenden Annotation definiert: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Hook-Gewichtungen können positive oder negative Zahlen sein, müssen aber als Strings dargestellt werden. Wenn Helm den Ausführungszyklus von Hooks eines bestimmten Typs startet, sortiert es diese Hooks in aufsteigender Reihenfolge. ### Hook-Löschrichtlinien Es ist möglich, Richtlinien zu definieren, die festlegen, wann die entsprechenden Hook-Ressourcen gelöscht werden sollen. Hook-Löschrichtlinien werden mit der folgenden Annotation definiert: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Sie können einen oder mehrere der definierten Annotationswerte wählen: | Annotationswert | Beschreibung | | ---------------------- | ---------------------------------------------------------------------- | | `before-hook-creation` | Die vorherige Ressource löschen, bevor ein neuer Hook gestartet wird (Standard) | | `hook-succeeded` | Die Ressource löschen, nachdem der Hook erfolgreich ausgeführt wurde | | `hook-failed` | Die Ressource löschen, wenn der Hook während der Ausführung fehlgeschlagen ist | Wenn keine Hook-Löschrichtlinien-Annotation angegeben ist, gilt standardmäßig das `before-hook-creation`-Verhalten. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: Veraltete Kubernetes-APIs description: Erläutert veraltete Kubernetes-APIs im Kontext von Helm --- Kubernetes ist ein API-gesteuertes System. Die API entwickelt sich im Laufe der Zeit weiter, um das wachsende Verständnis des Problembereichs widerzuspiegeln. Dies ist gängige Praxis bei Systemen und ihren APIs. Ein wichtiger Teil der API-Weiterentwicklung ist eine gute Deprecation-Richtlinie und ein entsprechender Prozess, um Benutzer über Änderungen zu informieren. Die Nutzer Ihrer API müssen im Voraus wissen, in welchem Release eine API entfernt oder geändert wird. So werden Überraschungen und unerwartete Änderungen vermieden. Die [Kubernetes-Deprecation-Richtlinie](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) dokumentiert, wie Kubernetes Änderungen an seinen API-Versionen handhabt. Die Richtlinie legt fest, wie lange API-Versionen nach einer Deprecation-Ankündigung unterstützt werden. Achten Sie daher auf Deprecation-Ankündigungen und informieren Sie sich, wann API-Versionen entfernt werden, um die Auswirkungen zu minimieren. Ein Beispiel für eine solche Ankündigung ist [die Entfernung veralteter API-Versionen in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/). Diese wurde einige Monate vor dem Release veröffentlicht. Die betroffenen API-Versionen waren zuvor bereits als veraltet angekündigt worden. Dies zeigt, dass eine gute Richtlinie existiert, die Nutzer über die Unterstützung von API-Versionen informiert. Helm-Templates geben eine [Kubernetes-API-Gruppe](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) an, wenn ein Kubernetes-Objekt definiert wird – ähnlich wie eine Kubernetes-Manifest-Datei. Die API-Gruppe wird im Feld `apiVersion` des Templates angegeben und identifiziert die API-Version des Kubernetes-Objekts. Helm-Benutzer und Chart-Maintainer müssen daher wissen, wann Kubernetes-API-Versionen als veraltet markiert wurden und in welcher Kubernetes-Version sie entfernt werden. ## Chart-Maintainer Überprüfen Sie Ihre Charts auf Kubernetes-API-Versionen, die veraltet sind oder in einer Kubernetes-Version entfernt wurden. Aktualisieren Sie API-Versionen, die veraltet oder nicht mehr unterstützt werden, auf die aktuelle Version und veröffentlichen Sie eine neue Chart-Version. Die API-Version wird durch die Felder `kind` und `apiVersion` definiert. Hier ein Beispiel für eine in Kubernetes 1.16 entfernte `Deployment`-API-Version: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm-Benutzer Überprüfen Sie die von Ihnen verwendeten Charts (ähnlich wie [Chart-Maintainer](#chart-maintainer)) und identifizieren Sie alle Charts mit veralteten oder entfernten API-Versionen. Prüfen Sie für die identifizierten Charts, ob eine neuere Chart-Version mit unterstützten API-Versionen verfügbar ist, oder aktualisieren Sie das Chart selbst. Überprüfen Sie zusätzlich alle bereitgestellten Charts (d. h. Helm-Releases) auf veraltete oder entfernte API-Versionen. Verwenden Sie dazu den Befehl `helm get manifest`, um die Details eines Releases abzurufen. Die Vorgehensweise zur Aktualisierung eines Helm-Releases auf unterstützte APIs hängt von Ihren Ergebnissen ab: 1. Wenn Sie nur veraltete API-Versionen finden: - Führen Sie ein `helm upgrade` mit einer Chart-Version durch, die unterstützte Kubernetes-API-Versionen verwendet - Fügen Sie eine Beschreibung hinzu, die darauf hinweist, kein Rollback auf eine frühere Helm-Version durchzuführen 2. Wenn Sie API-Versionen finden, die in einer Kubernetes-Version entfernt wurden: - Falls Sie eine Kubernetes-Version verwenden, in der die API-Versionen noch verfügbar sind (z. B. Sie nutzen Kubernetes 1.15 und haben APIs gefunden, die in Kubernetes 1.16 entfernt werden): - Befolgen Sie die Schritte aus Punkt 1 - Andernfalls (z. B. Sie nutzen bereits eine Kubernetes-Version, in der einige von `helm get manifest` gemeldete API-Versionen nicht mehr verfügbar sind): - Bearbeiten Sie das im Cluster gespeicherte Release-Manifest, um die API-Versionen zu aktualisieren. Weitere Details finden Sie unter [API-Versionen eines Release-Manifests aktualisieren](#api-versionen-eines-release-manifests-aktualisieren) > Hinweis: Führen Sie in keinem Fall ein Rollback auf eine Version vor der Release-Version mit den unterstützten APIs durch. > Empfehlung: Aktualisieren Sie Releases mit veralteten API-Versionen auf unterstützte API-Versionen, bevor Sie auf einen Kubernetes-Cluster upgraden, der diese API-Versionen entfernt. Wenn Sie ein Release nicht wie empfohlen aktualisieren, erhalten Sie beim Upgrade-Versuch in einer Kubernetes-Version, in der die API-Versionen entfernt wurden, einen Fehler wie diesen: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm schlägt in diesem Szenario fehl, weil es versucht, einen Diff-Patch zwischen dem aktuell bereitgestellten Release (mit den entfernten Kubernetes-APIs) und dem Chart mit den aktualisierten API-Versionen zu erstellen. Der eigentliche Grund: Wenn Kubernetes eine API-Version entfernt, kann die Kubernetes-Go-Client-Bibliothek die veralteten Objekte nicht mehr parsen. Helm schlägt daher beim Aufruf der Bibliothek fehl und kann sich von dieser Situation nicht erholen. Weitere Details zur Behebung finden Sie unter [API-Versionen eines Release-Manifests aktualisieren](#api-versionen-eines-release-manifests-aktualisieren). ## API-Versionen eines Release-Manifests aktualisieren Das Manifest ist eine Eigenschaft des Helm-Release-Objekts und wird im Datenfeld eines Secrets (Standard) oder einer ConfigMap im Cluster gespeichert. Das Datenfeld enthält ein gzipptes Objekt, das Base64-kodiert ist (bei einem Secret gibt es eine zusätzliche Base64-Kodierung). Pro Release-Version/Revision existiert ein Secret bzw. eine ConfigMap im Namespace des Releases. Verwenden Sie das Helm-Plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis), um ein Release auf unterstützte APIs zu aktualisieren. Weitere Details finden Sie in der Readme-Datei. Alternativ können Sie die folgenden manuellen Schritte durchführen, um die API-Versionen eines Release-Manifests zu aktualisieren. Je nach Konfiguration folgen Sie den Schritten für das Secret- oder ConfigMap-Backend. - Namen des Secrets oder der ConfigMap abrufen, das/die mit dem zuletzt bereitgestellten Release verknüpft ist: - Secrets-Backend: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap-Backend: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Details des zuletzt bereitgestellten Releases abrufen: - Secrets-Backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap-Backend: `kubectl get configmap -n -o yaml > release.yaml` - Release sichern: - `cp release.yaml release.bak` - Im Notfall wiederherstellen: `kubectl apply -f release.bak -n ` - Release-Objekt dekodieren: - Secrets-Backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap-Backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - API-Versionen der Manifeste ändern. Verwenden Sie ein beliebiges Werkzeug (z. B. einen Editor) für die Änderungen. Die Manifeste befinden sich im Feld `manifest` Ihres dekodierten Release-Objekts (`release.data.decoded`) - Release-Objekt kodieren: - Secrets-Backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap-Backend: `cat release.data.decoded | gzip | base64` - Den Wert der Eigenschaft `data.release` in der Release-Datei (`release.yaml`) durch das neue kodierte Release-Objekt ersetzen - Datei auf den Namespace anwenden: `kubectl apply -f release.yaml -n ` - Ein `helm upgrade` mit einer Chart-Version durchführen, die unterstützte Kubernetes-API-Versionen verwendet - Eine Beschreibung hinzufügen, die darauf hinweist, kein Rollback auf eine frühere Helm-Version durchzuführen ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Leitfaden für Kubernetes-Distributionen description: Enthält Informationen zur Verwendung von Helm in bestimmten Kubernetes-Umgebungen. sidebar_position: 10 --- Helm sollte mit jeder [konformen Version von Kubernetes](https://github.com/cncf/k8s-conformance) funktionieren (ob [zertifiziert](https://www.cncf.io/certification/software-conformance/) oder nicht). Dieses Dokument enthält Informationen zur Verwendung von Helm in bestimmten Kubernetes-Umgebungen. Bitte tragen Sie weitere Details zu beliebigen Distributionen (alphabetisch sortiert) bei, falls gewünscht. ## AKS Helm funktioniert mit [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm wurde auf der Mesosphere DC/OS 1.11 Kubernetes-Plattform getestet und funktioniert ohne zusätzliche Konfiguration. ## EKS Helm funktioniert mit Amazon Elastic Kubernetes Service (Amazon EKS): [Verwendung von Helm mit Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Googles gehostete Kubernetes-Plattform GKE funktioniert nachweislich mit Helm und erfordert keine zusätzliche Konfiguration. ## `scripts/local-cluster` und Hyperkube Hyperkube, konfiguriert über `scripts/local-cluster.sh`, funktioniert nachweislich. Bei reinem Hyperkube ist möglicherweise eine manuelle Konfiguration erforderlich. ## IKS Helm funktioniert mit [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm wird regelmäßig auf [KIND](https://github.com/kubernetes-sigs/kind) getestet. ## KubeOne Helm funktioniert in Clustern, die mit KubeOne eingerichtet wurden, ohne Einschränkungen. ## Kubermatic Helm funktioniert in Benutzer-Clustern, die von Kubermatic erstellt wurden, ohne Einschränkungen. Da Seed-Cluster auf verschiedene Arten eingerichtet werden können, hängt die Helm-Unterstützung von deren Konfiguration ab. ## MicroK8s Helm kann in [MicroK8s](https://microk8s.io) mit dem folgenden Befehl aktiviert werden: `microk8s.enable helm3` ## Minikube Helm wurde mit [Minikube](https://github.com/kubernetes/minikube) getestet und funktioniert nachweislich. Es ist keine zusätzliche Konfiguration erforderlich. ## Openshift Helm funktioniert problemlos auf OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (Version >= 3.6) oder OpenShift Origin (Version >= 3.6). Weitere Informationen finden Sie in diesem [Blogbeitrag](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm ist bei [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes) vorinstalliert. Platform9 bietet Zugang zu allen offiziellen Helm-Charts über die App-Katalog-Benutzeroberfläche und die native Kubernetes-CLI. Zusätzliche Repositories können manuell hinzugefügt werden. Weitere Details finden Sie in diesem [Platform9 App-Katalog-Artikel](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu mit `kubeadm` Kubernetes, das mittels `kubeadm` eingerichtet wurde, funktioniert nachweislich auf folgenden Linux-Distributionen: - Ubuntu 16.04 - Fedora release 25 Bei einigen Helm-Versionen (v2.0.0-beta2) müssen Sie `export KUBECONFIG=/etc/kubernetes/admin.conf` ausführen oder eine `~/.kube/config` erstellen. ## VMware Tanzu Kubernetes Grid Helm läuft auf VMware Tanzu Kubernetes Grid (TKG) ohne Konfigurationsänderungen. Die Tanzu CLI kann die Installation von Paketen für [helm-controller](https://fluxcd.io/flux/components/helm/) verwalten und ermöglicht so die deklarative Verwaltung von Helm-Chart-Releases. Weitere Details finden Sie in der TKG-Dokumentation für [CLI-verwaltete Pakete](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Library Charts description: Erläutert Library Charts und zeigt Anwendungsbeispiele sidebar_position: 4 --- Ein Library Chart ist ein spezieller Typ von [Helm Chart](/topics/charts.md), der Chart-Primitive oder -Definitionen bereitstellt, die von Helm-Templates in anderen Charts verwendet werden können. So lassen sich Code-Snippets über mehrere Charts hinweg gemeinsam nutzen, wodurch Wiederholungen vermieden und Charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) gehalten werden. Das Library Chart wurde in Helm 3 eingeführt, um offiziell gemeinsam genutzte Charts oder Helper Charts anzuerkennen, die von Chart-Maintainern bereits seit Helm 2 verwendet werden. Durch die Definition als eigener Chart-Typ bietet es: - Eine Möglichkeit zur expliziten Unterscheidung zwischen gemeinsam genutzten Charts und Anwendungs-Charts - Logik zur Verhinderung der Installation eines gemeinsam genutzten Charts - Kein Rendering von Templates in einem gemeinsam genutzten Chart, die Release-Artefakte enthalten könnten - Die Möglichkeit für abhängige Charts, den Kontext des importierenden Charts zu nutzen Ein Chart-Maintainer kann ein gemeinsam genutztes Chart als Library Chart definieren und sicher sein, dass Helm das Chart auf eine standardisierte und konsistente Weise behandelt. Darüber hinaus können Definitionen aus einem Anwendungs-Chart geteilt werden, indem einfach der Chart-Typ geändert wird. ## Ein einfaches Library Chart erstellen Wie bereits erwähnt, ist ein Library Chart ein spezieller Typ von [Helm Chart](/topics/charts.md). Das bedeutet, dass Sie mit der Erstellung eines Grundgerüst-Charts beginnen können: ```console $ helm create mylibchart Creating mylibchart ``` Zunächst entfernen Sie alle Dateien im Verzeichnis `templates`, da wir in diesem Beispiel eigene Template-Definitionen erstellen werden. ```console $ rm -rf mylibchart/templates/* ``` Die Values-Datei wird ebenfalls nicht benötigt. ```console $ rm -f mylibchart/values.yaml ``` Bevor wir mit dem Erstellen von gemeinsam genutztem Code beginnen, gehen wir kurz einige relevante Helm-Konzepte durch. Ein [benanntes Template](/chart_template_guide/named_templates.md) (manchmal auch Partial oder Subtemplate genannt) ist einfach ein Template, das in einer Datei definiert und mit einem Namen versehen wird. Im Verzeichnis `templates/` wird jede Datei, die mit einem Unterstrich (_) beginnt, nicht als Kubernetes-Manifest ausgegeben. Daher werden Hilfs-Templates und Partials üblicherweise in `_*.tpl`- oder `_*.yaml`-Dateien abgelegt. In diesem Beispiel erstellen wir eine gemeinsam nutzbare ConfigMap, die eine leere ConfigMap-Ressource definiert. Wir definieren die gemeinsame ConfigMap in der Datei `mylibchart/templates/_configmap.yaml` wie folgt: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Das ConfigMap-Konstrukt wird im benannten Template `mylibchart.configmap.tpl` definiert. Es handelt sich um eine einfache ConfigMap mit einer leeren Ressource, `data`. In dieser Datei gibt es ein weiteres benanntes Template namens `mylibchart.configmap`. Dieses benannte Template bindet ein anderes benanntes Template `mylibchart.util.merge` ein, das 2 benannte Templates als Argumente entgegennimmt: das Template, das `mylibchart.configmap` aufruft, und `mylibchart.configmap.tpl`. Die Hilfsfunktion `mylibchart.util.merge` ist ein benanntes Template in `mylibchart/templates/_util.yaml`. Es handelt sich um ein praktisches Hilfsmittel aus [The Common Helm Helper Chart](#the-common-helm-helper-chart), da es die 2 Templates zusammenführt und gemeinsame Teile in beiden überschreibt: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Dies ist wichtig, wenn ein Chart gemeinsamen Code verwenden möchte, den es mit seiner eigenen Konfiguration anpassen muss. Zum Schluss ändern wir den Chart-Typ zu `library`. Dazu muss `mylibchart/Chart.yaml` wie folgt bearbeitet werden: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` Das Library Chart ist nun bereit zum Teilen und seine ConfigMap-Definition kann wiederverwendet werden. Bevor Sie fortfahren, lohnt es sich zu überprüfen, ob Helm das Chart als Library Chart erkennt: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Das einfache Library Chart verwenden Es ist nun Zeit, das Library Chart zu verwenden. Das bedeutet, wieder ein Grundgerüst-Chart zu erstellen: ```console $ helm create mychart Creating mychart ``` Entfernen wir wieder die Template-Dateien, da wir nur eine ConfigMap erstellen möchten: ```console $ rm -rf mychart/templates/* ``` Wenn wir eine einfache ConfigMap in einem Helm-Template erstellen möchten, könnte sie etwa so aussehen: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Wir werden jedoch den bereits in `mylibchart` erstellten gemeinsamen Code wiederverwenden. Die ConfigMap kann in der Datei `mychart/templates/configmap.yaml` wie folgt erstellt werden: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Sie sehen, dass sich die Arbeit vereinfacht, indem die gemeinsame ConfigMap-Definition geerbt wird, die Standardeigenschaften für ConfigMaps hinzufügt. In unserem Template fügen wir die Konfiguration hinzu, in diesem Fall den Datenschlüssel `myvalue` und seinen Wert. Die Konfiguration überschreibt die leere Ressource der gemeinsamen ConfigMap. Dies ist möglich dank der Hilfsfunktion `mylibchart.util.merge`, die wir im vorherigen Abschnitt erwähnt haben. Um den gemeinsamen Code verwenden zu können, müssen wir `mylibchart` als Abhängigkeit hinzufügen. Fügen Sie Folgendes am Ende der Datei `mychart/Chart.yaml` hinzu: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Dies bindet das Library Chart als dynamische Abhängigkeit aus dem Dateisystem ein, das sich auf derselben übergeordneten Pfadebene wie unser Anwendungs-Chart befindet. Da wir das Library Chart als dynamische Abhängigkeit einbinden, müssen wir `helm dependency update` ausführen. Dieser Befehl kopiert das Library Chart in Ihr Verzeichnis `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Wir sind nun bereit, unser Chart zu deployen. Vor der Installation lohnt es sich, zunächst das gerenderte Template zu überprüfen. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Das sieht nach der ConfigMap aus, die wir wollen, mit dem überschriebenen Datenwert `myvalue: Hello World`. Lassen Sie uns das Chart installieren: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Wir können das Release abrufen und sehen, dass das eigentliche Template geladen wurde. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Vorteile von Library Charts Da Library Charts nicht als eigenständige Charts fungieren können, bieten sie folgende Funktionalität: - Das `.Files`-Objekt verweist auf die Dateipfade des übergeordneten Charts, nicht auf den lokalen Pfad des Library Charts - Das `.Values`-Objekt ist identisch mit dem des übergeordneten Charts, im Gegensatz zu Anwendungs-[Subcharts](/chart_template_guide/subcharts_and_globals.md), die den Abschnitt der Values erhalten, der unter ihrem Header im übergeordneten Chart konfiguriert ist ## The Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` Dieses [Chart](https://github.com/helm/charts/tree/master/incubator/common) war das ursprüngliche Muster für Library Charts. Es bietet Hilfsmittel, die Best Practices der Kubernetes-Chart-Entwicklung widerspiegeln. Der besondere Vorteil: Sie können es bei der Entwicklung Ihrer Charts sofort verwenden, um praktischen gemeinsamen Code zu nutzen. Hier ist eine schnelle Möglichkeit, es zu verwenden. Weitere Details finden Sie in der [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Erstellen Sie wieder ein Grundgerüst-Chart: ```console $ helm create demo Creating demo ``` Verwenden wir den gemeinsamen Code aus dem Helper Chart. Bearbeiten Sie zunächst das Deployment `demo/templates/deployment.yaml` wie folgt: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` Und nun die Service-Datei `demo/templates/service.yaml` wie folgt: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Diese Templates zeigen, wie das Erben von gemeinsam genutztem Code aus dem Helper Chart Ihre Arbeit auf die Konfiguration oder Anpassung der Ressourcen reduziert. Um den gemeinsamen Code verwenden zu können, müssen wir `common` als Abhängigkeit hinzufügen. Fügen Sie Folgendes am Ende der Datei `demo/Chart.yaml` hinzu: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Hinweis: Sie müssen das `incubator`-Repository zur Helm-Repository-Liste hinzufügen (`helm repo add`). Da wir das Chart als dynamische Abhängigkeit einbinden, müssen wir `helm dependency update` ausführen. Dieser Befehl kopiert das Helper Chart in Ihr Verzeichnis `charts/`. Da das Helper Chart einige Helm 2-Konstrukte verwendet, müssen Sie Folgendes zu `demo/values.yaml` hinzufügen, um das `nginx`-Image zu laden, da dies im Helm 3-Grundgerüst-Chart aktualisiert wurde: ```yaml image: tag: 1.16.0 ``` Sie können mit den Befehlen `helm lint` und `helm template` testen, ob die Chart-Templates korrekt sind, bevor Sie sie deployen. Wenn alles in Ordnung ist, deployen Sie mit `helm install`! ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Berechtigungsverwaltung für das SQL-Speicher-Backend description: Erfahren Sie, wie Sie Berechtigungen bei Verwendung des SQL-Speicher-Backends einrichten. --- Dieses Dokument bietet eine Anleitung zur Einrichtung und Verwaltung von Berechtigungen bei Verwendung des SQL-Speicher-Backends. ## Einführung Helm nutzt für die Berechtigungsverwaltung die RBAC-Funktion von Kubernetes. Bei Verwendung des SQL-Speicher-Backends können Kubernetes-Roles jedoch nicht verwendet werden, um zu bestimmen, ob ein Benutzer auf eine bestimmte Ressource zugreifen darf. Dieses Dokument zeigt, wie Sie diese Berechtigungen erstellen und verwalten. ## Initialisierung Beim ersten Verbindungsaufbau der Helm CLI mit Ihrer Datenbank prüft der Client, ob diese bereits initialisiert wurde. Falls nicht, führt er die notwendige Einrichtung automatisch durch. Diese Initialisierung erfordert Administratorrechte auf dem public-Schema oder mindestens folgende Berechtigungen: * eine Tabelle erstellen * Berechtigungen auf dem public-Schema vergeben Nachdem die Migration auf Ihrer Datenbank ausgeführt wurde, können alle anderen Rollen den Client nutzen. ## Berechtigungen für einen Nicht-Administrator in PostgreSQL vergeben Zur Verwaltung von Berechtigungen nutzt der SQL-Backend-Treiber die [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)-Funktion (Row-Level Security, Sicherheit auf Zeilenebene) von PostgreSQL. RLS ermöglicht es allen Benutzern, aus derselben Tabelle zu lesen und in diese zu schreiben, ohne dabei auf dieselben Zeilen zugreifen zu können, sofern ihnen dies nicht explizit erlaubt wurde. Standardmäßig erhält jede Rolle, der nicht explizit die entsprechenden Rechte gewährt wurden, eine leere Liste bei Ausführung von `helm list` und kann keine Ressourcen im Cluster abrufen oder ändern. So gewähren Sie einer bestimmten Rolle Zugriff auf spezifische Namespaces: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Dieser Befehl gewährt der Rolle `role` die Berechtigung, alle Ressourcen zu lesen und zu schreiben, die die Bedingung `namespace = 'default'` erfüllen. Nach dem Erstellen dieser Policy kann der Benutzer, der im Namen der Rolle `role` mit der Datenbank verbunden ist, alle Releases im Namespace `default` bei Ausführung von `helm list` sehen sowie diese bearbeiten und löschen. Berechtigungen lassen sich mit RLS granular verwalten. So können Sie den Zugriff anhand der verschiedenen Tabellenspalten einschränken: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Der Helm Plugins Leitfaden description: Erklärt, wie Sie Plugins verwenden und erstellen können, um die Funktionalität von Helm zu erweitern. sidebar_position: 12 --- Ein Helm Plugin ist ein Werkzeug, das über die `helm` CLI aufgerufen werden kann, aber nicht Teil des integrierten Helm-Quellcodes ist. Bestehende Plugins finden Sie im Bereich [Verwandte Projekte](/community/related#helm-plugins) oder durch eine Suche auf [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Dieser Leitfaden erklärt, wie Sie Plugins verwenden und erstellen. ## Überblick Helm Plugins sind Erweiterungswerkzeuge, die sich nahtlos in Helm integrieren. Sie bieten eine Möglichkeit, die Kernfunktionalität von Helm zu erweitern, ohne dass jede neue Funktion in Go geschrieben und dem Kern-Tool hinzugefügt werden muss. Helm Plugins haben folgende Eigenschaften: - Sie können einer Helm-Installation hinzugefügt und daraus entfernt werden, ohne das Kern-Tool zu beeinflussen. - Sie können in jeder Programmiersprache geschrieben werden. - Sie integrieren sich in Helm und erscheinen in `helm help` und an anderen Stellen. Helm Plugins befinden sich in `$HELM_PLUGINS`. Den aktuellen Wert dieses Pfads, einschließlich des Standardwerts wenn er nicht in der Umgebung gesetzt ist, können Sie mit dem Befehl `helm env` ermitteln. Das Helm Plugin-Modell basiert teilweise auf dem Plugin-Modell von Git. Daher wird `helm` manchmal als _Porcelain_-Schicht (Benutzeroberfläche) bezeichnet, während Plugins die _Plumbing_-Schicht (Basiswerkzeuge) darstellen. Das bedeutet: Helm stellt die Benutzererfahrung und die übergeordnete Verarbeitungslogik bereit, während die Plugins die "Detailarbeit" zur Ausführung einer gewünschten Aktion übernehmen. ## Ein Plugin installieren Plugins werden mit dem Befehl `$ helm plugin install ` installiert. Sie können einen Pfad zu einem Plugin auf Ihrem lokalen Dateisystem oder eine URL eines entfernten VCS-Repositories angeben. Der Befehl `helm plugin install` klont oder kopiert das Plugin vom angegebenen Pfad/URL nach `$HELM_PLUGINS`. Wenn Sie von einem VCS installieren, können Sie die Version mit dem Argument `--version` angeben. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Wenn Sie eine Plugin-Tar-Distribution haben, entpacken Sie das Plugin einfach in das Verzeichnis `$HELM_PLUGINS`. Sie können Tarball-Plugins auch direkt von einer URL installieren mit `helm plugin install https://domain/path/to/plugin.tar.gz` ## Die Plugin-Dateistruktur Ein Plugin ähnelt in vieler Hinsicht einem Chart. Jedes Plugin hat ein übergeordnetes Verzeichnis mit einer `plugin.yaml`-Datei. Weitere Dateien können vorhanden sein, aber nur die `plugin.yaml`-Datei ist erforderlich. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Die plugin.yaml-Datei Die plugin.yaml-Datei ist für ein Plugin erforderlich. Sie enthält folgende Felder: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### Das Feld `name` Das `name` ist der Name des Plugins. Wenn Helm dieses Plugin ausführt, verwendet es diesen Namen (z. B. wird `helm NAME` dieses Plugin aufrufen). _`name` sollte mit dem Verzeichnisnamen übereinstimmen._ In unserem Beispiel oben bedeutet das, dass das Plugin mit `name: last` in einem Verzeichnis namens `last` enthalten sein sollte. Einschränkungen für `name`: - `name` darf keinen der bestehenden `helm` Top-Level-Befehle duplizieren. - `name` muss auf die ASCII-Zeichen a-z, A-Z, 0-9, `_` und `-` beschränkt sein. ### Das Feld `version` Das `version` ist die SemVer 2-Version des Plugins. `usage` und `description` werden beide zur Generierung des Hilfetextes eines Befehls verwendet. ### Das Feld `ignoreFlags` Der Schalter `ignoreFlags` weist Helm an, _keine_ Flags an das Plugin zu übergeben. Wenn also ein Plugin mit `helm myplugin --foo` aufgerufen wird und `ignoreFlags: true` gesetzt ist, wird `--foo` stillschweigend verworfen. ### Das Feld `platformCommand` Das `platformCommand` konfiguriert den Befehl, den das Plugin bei Aufruf ausführt. Sie können nicht sowohl `platformCommand` als auch `command` setzen, da dies zu einem Fehler führt. Die folgenden Regeln gelten für die Auswahl des auszuführenden Befehls: - Wenn `platformCommand` vorhanden ist, wird es verwendet. - Wenn sowohl `os` als auch `arch` mit der aktuellen Plattform übereinstimmen, wird die Suche beendet und der Befehl verwendet. - Wenn `os` übereinstimmt und `arch` leer ist, wird der Befehl verwendet. - Wenn sowohl `os` als auch `arch` leer sind, wird der Befehl verwendet. - Wenn keine Übereinstimmung vorliegt, beendet sich Helm mit einem Fehler. - Wenn `platformCommand` nicht vorhanden ist und das veraltete `command` vorhanden ist, wird es verwendet. - Wenn der Befehl leer ist, beendet sich Helm mit einem Fehler. ### Das Feld `platformHooks` Das `platformHooks` konfiguriert die Befehle, die das Plugin für Lifecycle-Events ausführt. Sie können nicht sowohl `platformHooks` als auch `hooks` setzen, da dies zu einem Fehler führt. Die folgenden Regeln gelten für die Auswahl des Hook-Befehls: - Wenn `platformHooks` vorhanden ist, wird es verwendet und die Befehle für das Lifecycle-Event werden verarbeitet. - Wenn sowohl `os` als auch `arch` mit der aktuellen Plattform übereinstimmen, wird die Suche beendet und der Befehl verwendet. - Wenn `os` übereinstimmt und `arch` leer ist, wird der Befehl verwendet. - Wenn sowohl `os` als auch `arch` leer sind, wird der Befehl verwendet. - Wenn keine Übereinstimmung vorliegt, überspringt Helm das Event. - Wenn `platformHooks` nicht vorhanden ist und das veraltete `hooks` vorhanden ist, wird der Befehl für das Lifecycle-Event verwendet. - Wenn der Befehl leer ist, überspringt Helm das Event. ## Ein Plugin erstellen Hier ist das Plugin-YAML für ein einfaches Plugin, das den letzten Release-Namen abruft: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Plugins können zusätzliche Skripte und ausführbare Dateien benötigen. Skripte können im Plugin-Verzeichnis enthalten sein und ausführbare Dateien können über einen Hook heruntergeladen werden. Das folgende Beispiel zeigt ein Plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Umgebungsvariablen werden interpoliert, bevor das Plugin ausgeführt wird. Das obige Muster zeigt die bevorzugte Methode, um anzugeben, wo sich das Plugin-Programm befindet. ### Plugin-Befehle Es gibt einige Strategien für die Arbeit mit Plugin-Befehlen: - Wenn ein Plugin eine ausführbare Datei enthält, sollte die ausführbare Datei für einen `platformCommand:` im Plugin-Verzeichnis verpackt oder über einen Hook installiert werden. - Die Zeile `platformCommand:` oder `command:` wird vor der Ausführung alle Umgebungsvariablen expandieren. `$HELM_PLUGIN_DIR` zeigt auf das Plugin-Verzeichnis. - Der Befehl selbst wird nicht in einer Shell ausgeführt. Sie können also kein Shell-Skript in einer Zeile schreiben. - Helm injiziert viele Konfigurationen in Umgebungsvariablen. Schauen Sie in die Umgebung, um zu sehen, welche Informationen verfügbar sind. - Helm macht keine Annahmen über die Sprache des Plugins. Sie können es in der Sprache Ihrer Wahl schreiben. - Befehle sind dafür verantwortlich, spezifische Hilfetexte für `-h` und `--help` zu implementieren. Helm verwendet `usage` und `description` für `helm help` und `helm help myplugin`, behandelt aber nicht `helm myplugin --help`. ### Ein lokales Plugin testen Zuerst müssen Sie Ihren `HELM_PLUGINS`-Pfad finden. Führen Sie dazu den folgenden Befehl aus: ``` bash helm env ``` Wechseln Sie in das Verzeichnis, auf das `HELM_PLUGINS` gesetzt ist. Jetzt können Sie einen symbolischen Link zu Ihrer Build-Ausgabe Ihres Plugins hinzufügen – in diesem Beispiel haben wir es für `mapkubeapis` gemacht. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Downloader Plugins Standardmäßig kann Helm Charts über HTTP/S herunterladen. Seit Helm 2.4.0 können Plugins eine spezielle Fähigkeit haben, Charts aus beliebigen Quellen herunterzuladen. Plugins deklarieren diese spezielle Fähigkeit in der `plugin.yaml`-Datei (auf oberster Ebene): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Wenn ein solches Plugin installiert ist, kann Helm mit dem Repository über das angegebene Protokollschema interagieren, indem es den `command` aufruft. Das spezielle Repository wird ähnlich wie reguläre Repositories hinzugefügt: `helm repo add favorite myprotocol://example.com/` Die Regeln für spezielle Repositories sind die gleichen wie für reguläre: Helm muss in der Lage sein, die `index.yaml`-Datei herunterzuladen, um die Liste der verfügbaren Charts zu ermitteln und zwischenzuspeichern. Der definierte Befehl wird mit folgendem Schema aufgerufen: `command certFile keyFile caFile full-URL`. Die SSL-Anmeldeinformationen stammen aus der Repository-Definition, die in `$HELM_REPOSITORY_CONFIG` gespeichert ist (d. h. `$HELM_CONFIG_HOME/repositories.yaml`). Ein Downloader-Plugin soll den Rohinhalt auf stdout ausgeben und Fehler auf stderr melden. Der Downloader-Befehl unterstützt auch Unterbefehle oder Argumente, sodass Sie beispielsweise `bin/mydownloader subcommand -d` in der `plugin.yaml` angeben können. Dies ist nützlich, wenn Sie dieselbe ausführbare Datei für den Haupt-Plugin-Befehl und den Downloader-Befehl verwenden möchten, aber mit einem unterschiedlichen Unterbefehl für jeden. ## Umgebungsvariablen Wenn Helm ein Plugin ausführt, übergibt es die äußere Umgebung an das Plugin und injiziert auch einige zusätzliche Umgebungsvariablen. Variablen wie `KUBECONFIG` werden für das Plugin gesetzt, wenn sie in der äußeren Umgebung gesetzt sind. Die folgenden Variablen sind garantiert gesetzt: - `HELM_PLUGINS`: Der Pfad zum Plugins-Verzeichnis. - `HELM_PLUGIN_NAME`: Der Name des Plugins, wie von `helm` aufgerufen. So hat `helm myplug` den Kurznamen `myplug`. - `HELM_PLUGIN_DIR`: Das Verzeichnis, das das Plugin enthält. - `HELM_BIN`: Der Pfad zum `helm`-Befehl (wie vom Benutzer ausgeführt). - `HELM_DEBUG`: Zeigt an, ob das Debug-Flag von Helm gesetzt wurde. - `HELM_REGISTRY_CONFIG`: Der Speicherort für die Registry-Konfiguration (falls verwendet). Beachten Sie, dass die Verwendung von Helm mit Registries eine experimentelle Funktion ist. - `HELM_REPOSITORY_CACHE`: Der Pfad zu den Repository-Cache-Dateien. - `HELM_REPOSITORY_CONFIG`: Der Pfad zur Repository-Konfigurationsdatei. - `HELM_NAMESPACE`: Der Namespace, der dem `helm`-Befehl übergeben wurde (üblicherweise mit dem Flag `-n`). - `HELM_KUBECONTEXT`: Der Name des Kubernetes-Konfigurationskontexts, der dem `helm`-Befehl übergeben wurde. Zusätzlich wird, wenn eine Kubernetes-Konfigurationsdatei explizit angegeben wurde, diese als Variable `KUBECONFIG` gesetzt. ## Hinweis zur Flag-Verarbeitung Bei der Ausführung eines Plugins analysiert Helm globale Flags für den eigenen Gebrauch. Keines dieser Flags wird an das Plugin weitergegeben. - `--burst-limit`: Dies wird zu `$HELM_BURST_LIMIT` konvertiert - `--debug`: Wenn dies angegeben ist, wird `$HELM_DEBUG` auf `1` gesetzt - `--kube-apiserver`: Dies wird zu `$HELM_KUBEAPISERVER` konvertiert - `--kube-as-group`: Diese werden zu `$HELM_KUBEASGROUPS` konvertiert - `--kube-as-user`: Dies wird zu `$HELM_KUBEASUSER` konvertiert - `--kube-ca-file`: Dies wird zu `$HELM_KUBECAFILE` konvertiert - `--kube-context`: Dies wird zu `$HELM_KUBECONTEXT` konvertiert - `--kube-insecure-skip-tls-verify`: Dies wird zu `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` konvertiert - `--kube-tls-server-name`: Dies wird zu `$HELM_KUBETLS_SERVER_NAME` konvertiert - `--kube-token`: Dies wird zu `$HELM_KUBETOKEN` konvertiert - `--kubeconfig`: Dies wird zu `$KUBECONFIG` konvertiert - `--namespace` und `-n`: Dies wird zu `$HELM_NAMESPACE` konvertiert - `--qps`: Dies wird zu `$HELM_QPS` konvertiert - `--registry-config`: Dies wird zu `$HELM_REGISTRY_CONFIG` konvertiert - `--repository-cache`: Dies wird zu `$HELM_REPOSITORY_CACHE` konvertiert - `--repository-config`: Dies wird zu `$HELM_REPOSITORY_CONFIG` konvertiert Plugins _sollten_ Hilfetext anzeigen und dann beenden für `-h` und `--help`. In allen anderen Fällen können Plugins Flags nach Bedarf verwenden. ## Shell-Autovervollständigung bereitstellen Seit Helm 3.2 kann ein Plugin optional Unterstützung für die Shell-Autovervollständigung als Teil des bestehenden Autovervollständigungsmechanismus von Helm bereitstellen. ### Statische Autovervollständigung Wenn ein Plugin eigene Flags und/oder Unterbefehle bereitstellt, kann es Helm darüber informieren, indem eine `completion.yaml`-Datei im Stammverzeichnis des Plugins vorhanden ist. Die `completion.yaml`-Datei hat folgende Form: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Hinweise: 1. Alle Abschnitte sind optional, sollten aber angegeben werden, wenn zutreffend. 1. Flags sollten nicht das Präfix `-` oder `--` enthalten. 1. Sowohl kurze als auch lange Flags können und sollten angegeben werden. Ein kurzes Flag muss nicht mit seiner entsprechenden Langform verknüpft sein, aber beide Formen sollten aufgelistet werden. 1. Flags müssen nicht in einer bestimmten Reihenfolge sein, müssen aber an der richtigen Stelle in der Unterbefehl-Hierarchie der Datei aufgelistet werden. 1. Die bestehenden globalen Flags von Helm werden bereits vom Autovervollständigungsmechanismus von Helm behandelt, daher müssen Plugins die folgenden Flags nicht angeben: `--debug`, `--namespace` oder `-n`, `--kube-context` und `--kubeconfig`, oder andere globale Flags. 1. Die `validArgs`-Liste bietet eine statische Liste möglicher Vervollständigungen für den ersten Parameter nach einem Unterbefehl. Es ist nicht immer möglich, eine solche Liste im Voraus bereitzustellen (siehe Abschnitt [Dynamische Vervollständigung](#dynamische-vervollständigung) unten), in diesem Fall kann der `validArgs`-Abschnitt weggelassen werden. Die `completion.yaml`-Datei ist vollständig optional. Wenn sie nicht bereitgestellt wird, bietet Helm einfach keine Shell-Autovervollständigung für das Plugin (es sei denn, das Plugin unterstützt [Dynamische Vervollständigung](#dynamische-vervollständigung)). Das Hinzufügen einer `completion.yaml`-Datei ist abwärtskompatibel und beeinflusst das Verhalten des Plugins bei Verwendung älterer Helm-Versionen nicht. Als Beispiel hat das [`fullstatus Plugin`](https://github.com/marckhouzam/helm-fullstatus), das keine Unterbefehle hat, aber dieselben Flags wie der Befehl `helm status` akzeptiert, folgende `completion.yaml`-Datei: ```yaml name: fullstatus flags: - o - output - revision ``` Ein komplexeres Beispiel für das [`2to3 Plugin`](https://github.com/helm/helm-2to3) hat folgende `completion.yaml`-Datei: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Dynamische Vervollständigung Ebenfalls seit Helm 3.2 können Plugins ihre eigene dynamische Shell-Autovervollständigung bereitstellen. Dynamische Shell-Autovervollständigung ist die Vervollständigung von Parameter- oder Flag-Werten, die nicht im Voraus definiert werden können. Zum Beispiel die Vervollständigung der Namen von Helm Releases, die derzeit im Cluster verfügbar sind. Damit das Plugin dynamische Autovervollständigung unterstützt, muss es eine **ausführbare** Datei namens `plugin.complete` in seinem Stammverzeichnis bereitstellen. Wenn das Helm-Vervollständigungsskript dynamische Vervollständigungen für das Plugin benötigt, führt es die Datei `plugin.complete` aus und übergibt ihr die Befehlszeile, die vervollständigt werden muss. Die ausführbare Datei `plugin.complete` muss die Logik enthalten, um zu bestimmen, welche die korrekten Vervollständigungsoptionen sind, und diese auf die Standardausgabe ausgeben, damit sie vom Helm-Vervollständigungsskript verwendet werden können. Die Datei `plugin.complete` ist vollständig optional. Wenn sie nicht bereitgestellt wird, bietet Helm einfach keine dynamische Autovervollständigung für das Plugin. Das Hinzufügen einer `plugin.complete`-Datei ist abwärtskompatibel und beeinflusst das Verhalten des Plugins bei Verwendung älterer Helm-Versionen nicht. Die Ausgabe des `plugin.complete`-Skripts sollte eine durch Zeilenumbrüche getrennte Liste sein, wie: ```console rel1 rel2 rel3 ``` Wenn `plugin.complete` aufgerufen wird, wird die Plugin-Umgebung genauso gesetzt wie beim Aufruf des Haupt-Skripts des Plugins. Daher sind die Variablen `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` und alle anderen Plugin-Variablen bereits gesetzt, und ihre entsprechenden globalen Flags wurden entfernt. Die Datei `plugin.complete` kann in jeder ausführbaren Form vorliegen; es kann ein Shell-Skript, ein Go-Programm oder jede andere Art von Programm sein, das Helm ausführen kann. Die Datei `plugin.complete` ***muss*** ausführbare Berechtigungen für den Benutzer haben. Die Datei `plugin.complete` ***muss*** mit einem Erfolgscode (Wert 0) beenden. In einigen Fällen erfordert die dynamische Vervollständigung das Abrufen von Informationen aus dem Kubernetes-Cluster. Zum Beispiel erfordert das Plugin `helm fullstatus` einen Release-Namen als Eingabe. Im `fullstatus`-Plugin kann sein `plugin.complete`-Skript, um Vervollständigungen für aktuelle Release-Namen bereitzustellen, einfach `helm list -q` ausführen und das Ergebnis ausgeben. Wenn es gewünscht ist, dieselbe ausführbare Datei für die Plugin-Ausführung und für die Plugin-Vervollständigung zu verwenden, kann das `plugin.complete`-Skript so gestaltet werden, dass es die ausführbare Hauptdatei des Plugins mit einem speziellen Parameter oder Flag aufruft. Wenn die ausführbare Hauptdatei des Plugins den speziellen Parameter oder das Flag erkennt, weiß sie, dass sie die Vervollständigung ausführen soll. In unserem Beispiel könnte `plugin.complete` wie folgt implementiert werden: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Das eigentliche Skript des `fullstatus`-Plugins (`status.sh`) muss dann nach dem Flag `--complete` suchen und, wenn gefunden, die entsprechenden Vervollständigungen ausgeben. ### Tipps und Tricks 1. Die Shell filtert automatisch Vervollständigungsoptionen heraus, die nicht mit der Benutzereingabe übereinstimmen. Ein Plugin kann daher alle relevanten Vervollständigungen zurückgeben, ohne diejenigen zu entfernen, die nicht mit der Benutzereingabe übereinstimmen. Wenn die Befehlszeile beispielsweise `helm fullstatus ngin` ist, kann das `plugin.complete`-Skript *alle* Release-Namen (des `default`-Namespace) ausgeben, nicht nur die, die mit `ngin` beginnen; die Shell behält nur diejenigen, die mit `ngin` beginnen. 1. Um die Unterstützung für dynamische Vervollständigung zu vereinfachen, insbesondere bei einem komplexen Plugin, können Sie Ihr `plugin.complete`-Skript Ihr Haupt-Plugin-Skript aufrufen lassen und Vervollständigungsoptionen anfordern. Siehe den Abschnitt [Dynamische Vervollständigung](#dynamische-vervollständigung) oben für ein Beispiel. 1. Um die dynamische Vervollständigung und die `plugin.complete`-Datei zu debuggen, können Sie Folgendes ausführen, um die Vervollständigungsergebnisse zu sehen: - `helm __complete `. Zum Beispiel: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Helm-Provenienz und -Integrität description: Beschreibt, wie Sie die Integrität und Herkunft eines Charts überprüfen können. sidebar_position: 5 --- Helm verfügt über Provenienz-Werkzeuge, die Chart-Benutzern helfen, die Integrität und Herkunft eines Pakets zu überprüfen. Mithilfe von branchenüblichen Werkzeugen, die auf PKI, GnuPG und anerkannten Paketmanagern basieren, kann Helm Signaturdateien erstellen und verifizieren. ## Überblick Die Integrität wird durch den Vergleich eines Charts mit einem Provenienz-Datensatz festgestellt. Provenienz-Datensätze werden in _Provenienz-Dateien_ gespeichert, die zusammen mit einem gepackten Chart abgelegt werden. Wenn beispielsweise ein Chart `myapp-1.2.3.tgz` heißt, lautet seine Provenienz-Datei `myapp-1.2.3.tgz.prov`. Provenienz-Dateien werden beim Paketieren erstellt (`helm package --sign ...`) und können von mehreren Befehlen geprüft werden, insbesondere `helm install --verify`. ## Der Workflow Dieser Abschnitt beschreibt einen möglichen Workflow für die effektive Nutzung von Provenienz-Daten. Voraussetzungen: - Ein gültiges PGP-Schlüsselpaar im Binärformat (nicht ASCII-armored) - Das Kommandozeilenwerkzeug `helm` - GnuPG-Kommandozeilenwerkzeuge (optional) - Keybase-Kommandozeilenwerkzeuge (optional) **Hinweis:** Falls Ihr privater PGP-Schlüssel ein Passwort hat, werden Sie bei allen Befehlen, die die Option `--sign` unterstützen, zur Eingabe dieses Passworts aufgefordert. Das Erstellen eines neuen Charts funktioniert wie gewohnt: ```console $ helm create mychart Creating mychart ``` Wenn Sie bereit zum Paketieren sind, fügen Sie das Flag `--sign` zu `helm package` hinzu. Geben Sie außerdem den Namen an, unter dem der Signaturschlüssel bekannt ist, sowie den Schlüsselring, der den entsprechenden privaten Schlüssel enthält: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Hinweis:** Der Wert des Arguments `--key` muss ein Teilstring der `uid` des gewünschten Schlüssels sein (in der Ausgabe von `gpg --list-keys`), zum Beispiel der Name oder die E-Mail-Adresse. **Der Fingerprint _kann nicht_ verwendet werden.** **Tipp:** Für GnuPG-Benutzer befindet sich der geheime Schlüsselring in `~/.gnupg/secring.gpg`. Mit `gpg --list-secret-keys` können Sie Ihre verfügbaren Schlüssel auflisten. **Warnung:** GnuPG v2 speichert Ihren geheimen Schlüsselring in einem neuen Format `kbx` am Standardspeicherort `~/.gnupg/pubring.kbx`. Verwenden Sie bitte den folgenden Befehl, um Ihren Schlüsselring in das alte gpg-Format zu konvertieren: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` An diesem Punkt sollten Sie sowohl `mychart-0.1.0.tgz` als auch `mychart-0.1.0.tgz.prov` sehen. Beide Dateien sollten letztendlich in Ihr gewünschtes Chart Repository hochgeladen werden. Sie können ein Chart mit `helm verify` verifizieren: ```console $ helm verify mychart-0.1.0.tgz ``` Eine fehlgeschlagene Verifizierung sieht so aus: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Um während der Installation zu verifizieren, verwenden Sie das Flag `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Falls sich der Schlüsselring mit dem öffentlichen Schlüssel, der zum signierten Chart gehört, nicht am Standardspeicherort befindet, müssen Sie möglicherweise mit `--keyring PATH` auf den Schlüsselring verweisen, wie im Beispiel `helm package`. Wenn die Verifizierung fehlschlägt, wird die Installation abgebrochen, bevor das Chart überhaupt gerendert wird. ### Keybase.io-Anmeldedaten verwenden Der Dienst [Keybase.io](https://keybase.io) erleichtert das Aufbauen einer Vertrauenskette für eine kryptografische Identität. Keybase-Anmeldedaten können zum Signieren von Charts verwendet werden. Voraussetzungen: - Ein konfiguriertes Keybase.io-Konto - GnuPG lokal installiert - Die `keybase`-CLI lokal installiert #### Pakete signieren Der erste Schritt besteht darin, Ihre Keybase-Schlüssel in Ihren lokalen GnuPG-Schlüsselring zu importieren: ```console $ keybase pgp export -s | gpg --import ``` Dies konvertiert Ihren Keybase-Schlüssel in das OpenPGP-Format und importiert ihn dann lokal in Ihre `~/.gnupg/secring.gpg`-Datei. Sie können dies mit `gpg --list-secret-keys` überprüfen. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Beachten Sie, dass Ihr geheimer Schlüssel eine Identifikationszeichenkette hat: ``` technosophos (keybase.io/technosophos) ``` Dies ist der vollständige Name Ihres Schlüssels. Als Nächstes können Sie ein Chart mit `helm package` paketieren und signieren. Stellen Sie sicher, dass Sie mindestens einen Teil dieser Namenszeichenkette in `--key` verwenden. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Als Ergebnis sollte der `package`-Befehl sowohl eine `.tgz`-Datei als auch eine `.tgz.prov`-Datei erzeugen. #### Pakete verifizieren Sie können eine ähnliche Technik verwenden, um ein Chart zu verifizieren, das mit dem Keybase-Schlüssel einer anderen Person signiert wurde. Angenommen, Sie möchten ein Paket verifizieren, das von `keybase.io/technosophos` signiert wurde. Verwenden Sie dazu das `keybase`-Werkzeug: ```console $ keybase follow technosophos $ keybase pgp pull ``` Der erste Befehl oben folgt dem Benutzer `technosophos`. Dann lädt `keybase pgp pull` die OpenPGP-Schlüssel aller Konten herunter, denen Sie folgen, und platziert sie in Ihrem GnuPG-Schlüsselring (`~/.gnupg/pubring.gpg`). An diesem Punkt können Sie nun `helm verify` oder jeden Befehl mit dem Flag `--verify` verwenden: ```console $ helm verify somechart-1.2.3.tgz ``` ### Gründe, warum ein Chart nicht verifiziert werden kann Dies sind häufige Gründe für ein Fehlschlagen. - Die `.prov`-Datei fehlt oder ist beschädigt. Dies deutet darauf hin, dass etwas falsch konfiguriert ist oder dass der ursprüngliche Maintainer keine Provenienz-Datei erstellt hat. - Der Schlüssel, der zum Signieren der Datei verwendet wurde, befindet sich nicht in Ihrem Schlüsselring. Dies deutet darauf hin, dass die Entität, die das Chart signiert hat, keine Person ist, der Sie bereits Ihr Vertrauen signalisiert haben. - Die Verifizierung der `.prov`-Datei ist fehlgeschlagen. Dies deutet darauf hin, dass entweder mit dem Chart oder den Provenienz-Daten etwas nicht stimmt. - Die Datei-Hashes in der Provenienz-Datei stimmen nicht mit dem Hash der Archivdatei überein. Dies deutet darauf hin, dass das Archiv manipuliert wurde. Wenn eine Verifizierung fehlschlägt, gibt es Grund, dem Paket zu misstrauen. ## Die Provenienz-Datei Die Provenienz-Datei enthält die YAML-Datei eines Charts sowie mehrere Verifizierungsinformationen. Provenienz-Dateien sind so konzipiert, dass sie automatisch generiert werden. Die folgenden Provenienz-Daten werden hinzugefügt: * Die Chart-Datei (`Chart.yaml`) wird einbezogen, um sowohl Menschen als auch Werkzeugen einen einfachen Einblick in den Inhalt des Charts zu geben. * Die Signatur (SHA256, wie bei Docker) des Chart-Pakets (die `.tgz`-Datei) wird einbezogen und kann zur Überprüfung der Integrität des Chart-Pakets verwendet werden. * Der gesamte Inhalt wird mit dem von OpenPGP verwendeten Algorithmus signiert (siehe [Keybase.io](https://keybase.io) für einen aufkommenden Weg, kryptografisches Signieren und Verifizieren zu vereinfachen). Diese Kombination gibt Benutzern die folgenden Zusicherungen: * Das Paket selbst wurde nicht manipuliert (Prüfsumme des `.tgz`-Pakets). * Die Entität, die dieses Paket veröffentlicht hat, ist bekannt (durch die GnuPG/PGP-Signatur). Das Format der Datei sieht ungefähr so aus: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Beachten Sie, dass der YAML-Abschnitt zwei Dokumente enthält (getrennt durch `...\n`). Die erste Datei ist der Inhalt von `Chart.yaml`. Die zweite enthält die Prüfsummen, eine Zuordnung von Dateinamen zu SHA-256-Digests des Dateiinhalts zum Zeitpunkt des Paketierens. Der Signaturblock ist eine standardmäßige PGP-Signatur, die [Manipulationsschutz](https://www.rossde.com/PGP/pgp_signatures.html) bietet. ## Chart Repositories Chart Repositories dienen als zentrale Sammlung von Helm-Charts. Chart Repositories müssen es ermöglichen, Provenienz-Dateien über HTTP über eine bestimmte Anfrage bereitzustellen, und müssen sie unter demselben URI-Pfad wie das Chart verfügbar machen. Wenn beispielsweise die Basis-URL für ein Paket `https://example.com/charts/mychart-1.2.3.tgz` ist, MUSS die Provenienz-Datei, falls vorhanden, unter `https://example.com/charts/mychart-1.2.3.tgz.prov` erreichbar sein. Aus Sicht des Endbenutzers sollte `helm install --verify myrepo/mychart-1.2.3` zum Download sowohl des Charts als auch der Provenienz-Datei führen, ohne zusätzliche Benutzerkonfiguration oder -aktion. ### Signaturen in OCI-basierten Registries Beim Veröffentlichen von Charts in einer [OCI-basierten Registry](/topics/registries.md) kann das [`helm-sigstore`-Plugin](https://github.com/sigstore/helm-sigstore/) verwendet werden, um Provenienz in [sigstore](https://sigstore.dev/) zu veröffentlichen. [Wie in der Dokumentation beschrieben](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), sind das Erstellen von Provenienz und das Signieren mit einem GPG-Schlüssel üblich, aber der Befehl `helm sigstore upload` kann verwendet werden, um die Provenienz in einem unveränderlichen Transparenz-Log zu veröffentlichen. ## Autorität und Authentizität etablieren Beim Umgang mit Vertrauensketten-Systemen ist es wichtig, die Autorität eines Signierenden feststellen zu können. Anders ausgedrückt: Das oben beschriebene System basiert darauf, dass Sie der Person vertrauen, die das Chart signiert hat. Das wiederum bedeutet, dass Sie dem öffentlichen Schlüssel des Signierenden vertrauen müssen. Eine der Design-Entscheidungen bei Helm war, dass sich das Helm-Projekt nicht als notwendige Partei in die Vertrauenskette einschalten würde. Wir wollen nicht die "Zertifizierungsstelle" für alle Chart-Signierer sein. Stattdessen bevorzugen wir stark ein dezentrales Modell, weshalb wir OpenPGP als unsere grundlegende Technologie gewählt haben. Wenn es also darum geht, Autorität zu etablieren, haben wir diesen Schritt in Helm 2 mehr oder weniger undefiniert gelassen (eine Entscheidung, die in Helm 3 beibehalten wurde). Dennoch haben wir einige Hinweise und Empfehlungen für diejenigen, die das Provenienz-System nutzen möchten: - Die [Keybase](https://keybase.io)-Plattform bietet ein öffentliches, zentralisiertes Repository für Vertrauensinformationen. - Sie können Keybase verwenden, um Ihre Schlüssel zu speichern oder die öffentlichen Schlüssel anderer zu erhalten. - Keybase bietet auch hervorragende Dokumentation. - Obwohl wir es nicht getestet haben, könnte die "sichere Website"-Funktion von Keybase verwendet werden, um Helm-Charts bereitzustellen. - Die Grundidee ist, dass ein offizieller "Chart-Reviewer" Charts mit seinem Schlüssel signiert und die resultierende Provenienz-Datei dann in das Chart Repository hochgeladen wird. - Es wurde an der Idee gearbeitet, dass eine Liste gültiger Signaturschlüssel in der `index.yaml`-Datei eines Repositorys enthalten sein könnte. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Rollenbasierte Zugriffskontrolle description: Erläutert, wie Helm mit der rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes interagiert. sidebar_position: 11 --- In Kubernetes ist es eine Best Practice, Benutzern oder anwendungsspezifischen ServiceAccounts Rollen zuzuweisen, um sicherzustellen, dass Ihre Anwendung nur innerhalb des vorgesehenen Geltungsbereichs agiert. Weitere Informationen zu ServiceAccount-Berechtigungen finden Sie in der [offiziellen Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). Seit Kubernetes 1.6 ist die rollenbasierte Zugriffskontrolle (RBAC) standardmäßig aktiviert. Mit RBAC können Sie festlegen, welche Aktionstypen je nach Benutzer und dessen Rolle in Ihrer Organisation erlaubt sind. Mit RBAC können Sie: - Administratoren privilegierte Operationen gewähren (z. B. das Erstellen clusterweiter Ressourcen wie neue Roles) - die Fähigkeit eines Benutzers einschränken, Ressourcen (Pods, Persistent Volumes, Deployments) entweder in bestimmten Namespaces oder clusterweit zu erstellen (Resource Quotas, Roles, Custom Resource Definitions) - die Fähigkeit eines Benutzers einschränken, Ressourcen entweder in bestimmten Namespaces oder clusterweit einzusehen. Dieser Leitfaden richtet sich an Administratoren, die den Zugriff eines Benutzers auf die Kubernetes-API einschränken möchten. ## Benutzerkonten verwalten Alle Kubernetes-Cluster haben zwei Kategorien von Benutzern: von Kubernetes verwaltete ServiceAccounts und normale Benutzer. Normale Benutzer werden von einem externen, unabhängigen Dienst verwaltet. Ein Administrator kann private Schlüssel verteilen, einen Benutzerspeicher wie Keystone oder Google Accounts verwenden, oder sogar eine Datei mit Benutzernamen und Passwörtern nutzen. Kubernetes verfügt nicht über Objekte, die normale Benutzerkonten repräsentieren. Normale Benutzer können nicht über einen API-Aufruf zum Cluster hinzugefügt werden. Im Gegensatz dazu werden ServiceAccounts von der Kubernetes-API verwaltet. Sie sind an bestimmte Namespaces gebunden und werden entweder automatisch vom API-Server oder manuell durch API-Aufrufe erstellt. ServiceAccounts sind mit Anmeldeinformationen verknüpft, die als Secrets gespeichert und in Pods gemountet werden. Dadurch können Prozesse innerhalb des Clusters mit der Kubernetes-API kommunizieren. API-Anfragen werden entweder einem normalen Benutzer oder einem ServiceAccount zugeordnet, oder sie werden als anonyme Anfragen behandelt. Das bedeutet, dass jeder Prozess innerhalb oder außerhalb des Clusters – ob ein Benutzer, der `kubectl` auf einer Workstation eingibt, Kubelets auf Nodes oder Mitglieder der Control Plane – sich beim API-Server authentifizieren muss oder als anonymer Benutzer behandelt wird. ## Roles, ClusterRoles, RoleBindings und ClusterRoleBindings In Kubernetes können Benutzerkonten und ServiceAccounts nur Ressourcen einsehen und bearbeiten, für die ihnen Zugriff gewährt wurde. Dieser Zugriff wird durch Roles und RoleBindings gewährt. Roles und RoleBindings sind an einen bestimmten Namespace gebunden und gewähren Benutzern die Fähigkeit, Ressourcen innerhalb dieses Namespace einzusehen und/oder zu bearbeiten. Auf Clusterebene heißen diese ClusterRoles und ClusterRoleBindings. Wenn Sie einem Benutzer eine ClusterRole zuweisen, gewähren Sie ihm Zugriff auf das Einsehen und/oder Bearbeiten von Ressourcen im gesamten Cluster. Dies ist auch erforderlich, um Ressourcen auf Clusterebene (Namespaces, Resource Quotas, Nodes) einzusehen und/oder zu bearbeiten. ClusterRoles können über eine Referenz in einem RoleBinding an einen bestimmten Namespace gebunden werden. Die Standard-ClusterRoles `admin`, `edit` und `view` werden häufig auf diese Weise verwendet. Es gibt einige ClusterRoles, die standardmäßig in Kubernetes verfügbar sind. Sie sind für Endbenutzer gedacht und umfassen Super-User-Rollen (`cluster-admin`) sowie Rollen mit granularerem Zugriff (`admin`, `edit`, `view`). | Standard-ClusterRole | Standard-ClusterRoleBinding | Beschreibung |----------------------|-----------------------------|-------------- | `cluster-admin` | `system:masters`-Gruppe | Erlaubt Super-User-Zugriff für alle Aktionen auf allen Ressourcen. Bei Verwendung in einem ClusterRoleBinding gewährt sie volle Kontrolle über jede Ressource im Cluster und in allen Namespaces. Bei Verwendung in einem RoleBinding gewährt sie volle Kontrolle über jede Ressource im Namespace des RoleBindings, einschließlich des Namespace selbst. | `admin` | Keine | Erlaubt Admin-Zugriff, vorgesehen für die Zuweisung innerhalb eines Namespace über ein RoleBinding. Bei Verwendung in einem RoleBinding erlaubt sie Lese-/Schreibzugriff auf die meisten Ressourcen in einem Namespace, einschließlich der Fähigkeit, Roles und RoleBindings innerhalb des Namespace zu erstellen. Sie erlaubt keinen Schreibzugriff auf Resource Quotas oder den Namespace selbst. | `edit` | Keine | Erlaubt Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace. Sie erlaubt nicht das Einsehen oder Bearbeiten von Roles oder RoleBindings. | `view` | Keine | Erlaubt schreibgeschützten Zugriff auf die meisten Objekte in einem Namespace. Sie erlaubt nicht das Einsehen von Roles oder RoleBindings. Sie erlaubt nicht das Einsehen von Secrets, da dies eine Rechteausweitung ermöglichen würde. ## Den Zugriff eines Benutzerkontos mit RBAC einschränken Nachdem wir die Grundlagen der rollenbasierten Zugriffskontrolle verstanden haben, besprechen wir nun, wie ein Administrator den Zugriffsbereich eines Benutzers einschränken kann. ### Beispiel: Einem Benutzer Lese-/Schreibzugriff auf einen bestimmten Namespace gewähren Um den Zugriff eines Benutzers auf einen bestimmten Namespace einzuschränken, können Sie entweder die Role `edit` oder `admin` verwenden. Wenn Ihre Charts Roles und RoleBindings erstellen oder damit interagieren, sollten Sie die ClusterRole `admin` verwenden. Zusätzlich können Sie auch ein RoleBinding mit `cluster-admin`-Zugriff erstellen. Die Gewährung von `cluster-admin`-Zugriff auf Namespace-Ebene gibt dem Benutzer volle Kontrolle über jede Ressource im Namespace, einschließlich des Namespace selbst. Für dieses Beispiel erstellen wir einen Benutzer mit der Role `edit`. Erstellen Sie zunächst den Namespace: ```console $ kubectl create namespace foo ``` Erstellen Sie nun ein RoleBinding in diesem Namespace, das dem Benutzer die Role `edit` zuweist. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Beispiel: Einem Benutzer Lese-/Schreibzugriff auf Clusterebene gewähren Wenn ein Benutzer ein Chart installieren möchte, das clusterweite Ressourcen installiert (Namespaces, Roles, Custom Resource Definitions usw.), benötigt er clusterweiten Schreibzugriff. Gewähren Sie dem Benutzer dafür entweder `admin`- oder `cluster-admin`-Zugriff. Die Gewährung von `cluster-admin`-Zugriff gibt dem Benutzer Zugriff auf absolut jede in Kubernetes verfügbare Ressource, einschließlich Node-Zugriff mit `kubectl drain` und anderen administrativen Aufgaben. Es wird dringend empfohlen, dem Benutzer stattdessen `admin`-Zugriff zu gewähren oder eine benutzerdefinierte ClusterRole zu erstellen, die auf seine Bedürfnisse zugeschnitten ist. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Beispiel: Einem Benutzer schreibgeschützten Zugriff auf einen bestimmten Namespace gewähren Sie haben vielleicht bemerkt, dass es keine ClusterRole zum Einsehen von Secrets gibt. Die ClusterRole `view` gewährt Benutzern aufgrund von Bedenken bezüglich Rechteausweitung keinen Lesezugriff auf Secrets. Helm speichert Release-Metadaten standardmäßig als Secrets. Damit ein Benutzer `helm list` ausführen kann, muss er diese Secrets lesen können. Dafür erstellen wir eine spezielle ClusterRole `secret-reader`. Erstellen Sie die Datei `cluster-role-secret-reader.yaml` mit folgendem Inhalt: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Erstellen Sie dann die ClusterRole mit: ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Sobald dies erledigt ist, können wir einem Benutzer Lesezugriff auf die meisten Ressourcen gewähren und ihm dann Lesezugriff auf Secrets geben: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Beispiel: Einem Benutzer schreibgeschützten Zugriff auf Clusterebene gewähren In bestimmten Szenarien kann es vorteilhaft sein, einem Benutzer clusterweiten Zugriff zu gewähren. Beispielsweise erfordert die API, dass der Benutzer clusterweiten Lesezugriff hat, wenn er den Befehl `helm list --all-namespaces` ausführen möchte. Gewähren Sie dem Benutzer dafür sowohl `view`- als auch `secret-reader`-Zugriff wie oben beschrieben, aber mit einem ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Weitere Überlegungen Die oben gezeigten Beispiele verwenden die Standard-ClusterRoles, die mit Kubernetes bereitgestellt werden. Für eine feinere Kontrolle darüber, auf welche Ressourcen Benutzer Zugriff erhalten, lesen Sie die [Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) zum Erstellen eigener benutzerdefinierter Roles und ClusterRoles. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: OCI-basierte Registries verwenden description: Beschreibt die Verwendung von OCI für die Chart-Verteilung. sidebar_position: 7 --- Seit Helm 3 können Sie Container-Registries mit [OCI](https://www.opencontainers.org/)-Unterstützung verwenden, um Chart-Pakete zu speichern und zu teilen. Ab Helm v3.8.0 ist die OCI-Unterstützung standardmäßig aktiviert. ## OCI-Unterstützung vor v3.8.0 Die OCI-Unterstützung wurde mit Helm v3.8.0 von experimentell auf allgemein verfügbar umgestellt. In früheren Versionen von Helm verhielt sich die OCI-Unterstützung anders. Wenn Sie die OCI-Unterstützung vor Helm v3.8.0 verwendet haben, ist es wichtig zu verstehen, was sich mit den verschiedenen Helm-Versionen geändert hat. ### Aktivierung der OCI-Unterstützung vor v3.8.0 Vor Helm v3.8.0 ist die OCI-Unterstützung *experimentell* und muss aktiviert werden. Um die experimentelle OCI-Unterstützung für Helm-Versionen vor v3.8.0 zu aktivieren, setzen Sie `HELM_EXPERIMENTAL_OCI` in Ihrer Umgebung. Zum Beispiel: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Veraltete OCI-Funktionen und Verhaltensänderungen mit v3.8.0 Mit der Veröffentlichung von [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) unterscheiden sich folgende Funktionen und Verhaltensweisen von früheren Helm-Versionen: - Wenn ein Chart in den Abhängigkeiten als OCI gesetzt wird, kann die Version wie bei anderen Abhängigkeiten als Bereich angegeben werden. - SemVer-Tags, die Build-Informationen enthalten, können gepusht und verwendet werden. OCI-Registries unterstützen das Zeichen `+` nicht in Tags. Helm übersetzt das `+` bei der Speicherung als Tag in `_`. - Der Befehl `helm registry login` folgt nun derselben Struktur wie die Docker-CLI zum Speichern von Anmeldedaten. Derselbe Speicherort für die Registry-Konfiguration kann sowohl an Helm als auch an die Docker-CLI übergeben werden. ### Veraltete OCI-Funktionen und Verhaltensänderungen mit v3.7.0 Mit der Veröffentlichung von [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) wurde [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) für die OCI-Unterstützung implementiert. Dadurch unterscheiden sich folgende Funktionen und Verhaltensweisen von früheren Helm-Versionen: - Der Unterbefehl `helm chart` wurde entfernt. - Der Chart-Cache wurde entfernt (kein `helm chart list` usw.). - OCI-Registry-Referenzen werden jetzt immer mit `oci://` präfixiert. - Der Basisname der Registry-Referenz muss *immer* mit dem Namen des Charts übereinstimmen. - Das Tag der Registry-Referenz muss *immer* mit der semantischen Version des Charts übereinstimmen (d.h. keine `latest`-Tags). - Der Medientyp der Chart-Schicht wurde von `application/tar+gzip` auf `application/vnd.cncf.helm.chart.content.v1.tar+gzip` geändert. ## Verwendung einer OCI-basierten Registry ### Helm-Repositories in OCI-basierten Registries Ein [Helm-Repository](/topics/chart_repository.md) ist eine Möglichkeit, gepackte Helm-Charts zu speichern und zu verteilen. Eine OCI-basierte Registry kann null oder mehr Helm-Repositories enthalten, und jedes dieser Repositories kann null oder mehr gepackte Helm-Charts enthalten. ### Gehostete Registries verwenden Es stehen Ihnen mehrere gehostete Container-Registries mit OCI-Unterstützung zur Verfügung, die Sie für Ihre Helm-Charts nutzen können. Zum Beispiel: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Folgen Sie der Dokumentation Ihres Container-Registry-Anbieters, um eine Registry mit OCI-Unterstützung zu erstellen und zu konfigurieren. **Hinweis:** Sie können [Docker Registry](https://docs.docker.com/registry/deploying/) oder [`zot`](https://github.com/project-zot/zot) ausführen, die OCI-basierte Registries sind, auf Ihrem Entwicklungsrechner. Das Ausführen einer OCI-basierten Registry auf Ihrem Entwicklungsrechner sollte nur zu Testzwecken verwendet werden. ### Sigstore zum Signieren von OCI-basierten Charts verwenden Das [`helm-sigstore`](https://github.com/sigstore/helm-sigstore)-Plugin ermöglicht die Verwendung von [Sigstore](https://sigstore.dev/) zum Signieren von Helm-Charts mit denselben Werkzeugen, die zum Signieren von Container-Images verwendet werden. Dies bietet eine Alternative zur [GPG-basierten Provenienz](/topics/provenance.md), die von klassischen [Chart-Repositories](/topics/chart_repository.md) unterstützt wird. Weitere Informationen zur Verwendung des `helm sigstore`-Plugins finden Sie in der [Dokumentation dieses Projekts](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Befehle für die Arbeit mit Registries ### Der Unterbefehl `registry` #### `login` Bei einer Registry anmelden (mit manueller Passworteingabe) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` Von einer Registry abmelden ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Der Unterbefehl `push` Ein Chart in eine OCI-basierte Registry hochladen: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Der Unterbefehl `push` kann nur für `.tgz`-Dateien verwendet werden, die zuvor mit `helm package` erstellt wurden. Wenn Sie `helm push` verwenden, um ein Chart in eine OCI-Registry hochzuladen, muss die Referenz mit `oci://` präfixiert sein und darf weder den Basisnamen noch das Tag enthalten. Der Basisname der Registry-Referenz wird aus dem Namen des Charts abgeleitet, und das Tag wird aus der semantischen Version des Charts abgeleitet. Dies ist derzeit eine strenge Anforderung. Bestimmte Registries erfordern, dass das Repository und/oder der Namespace (falls angegeben) vorab erstellt werden. Andernfalls wird während des `helm push`-Vorgangs ein Fehler erzeugt. Wenn Sie eine [Provenance-Datei](/topics/provenance.md) (`.prov`) erstellt haben und diese sich neben der Chart-`.tgz`-Datei befindet, wird sie beim `push` automatisch in die Registry hochgeladen. Dies führt zu einer zusätzlichen Schicht im [Helm-Chart-Manifest](#helm-chart-manifest). Benutzer des [helm-push-Plugins](https://github.com/chartmuseum/helm-push) (zum Hochladen von Charts nach [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) könnten Probleme haben, da das Plugin mit dem neuen, integrierten `push` in Konflikt steht. Ab Version v0.10.0 wurde das Plugin in `cm-push` umbenannt. ### Weitere Unterbefehle Die Unterstützung für das `oci://`-Protokoll ist auch in verschiedenen anderen Unterbefehlen verfügbar. Hier ist eine vollständige Liste: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Der Basisname (Chart-Name) der Registry-Referenz *wird* bei jeder Art von Aktion einbezogen, die einen Chart-Download beinhaltet (im Gegensatz zu `helm push`, wo er weggelassen wird). Hier sind einige Beispiele für die Verwendung der oben aufgeführten Unterbefehle mit OCI-basierten Charts: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Charts mit Digest installieren Das Installieren eines Charts mit einem Digest ist sicherer als mit einem Tag, da Digests unveränderlich sind. Der Digest wird in der Chart-URI angegeben: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Abhängigkeiten angeben Abhängigkeiten eines Charts können mit dem Unterbefehl `dependency update` aus einer Registry geholt werden. Das `repository` für einen Eintrag in `Chart.yaml` wird als Registry-Referenz ohne den Basisnamen angegeben: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Dies ruft `oci://localhost:5000/myrepo/mychart:2.7.0` ab, wenn `dependency update` ausgeführt wird. ## Helm-Chart-Manifest Beispiel eines Helm-Chart-Manifests, wie es in einer Registry dargestellt wird (beachten Sie die `mediaType`-Felder): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Das folgende Beispiel enthält eine [Provenance-Datei](/topics/provenance.md) (beachten Sie die zusätzliche Schicht): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migration von Chart-Repos Die Migration von klassischen [Chart-Repositories](/topics/chart_repository.md) (index.yaml-basierte Repos) ist unkompliziert: Verwenden Sie `helm pull`, um Charts herunterzuladen, und anschließend `helm push`, um die resultierenden `.tgz`-Dateien in eine Registry hochzuladen. ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Migration von Helm v2 auf v3 description: Erfahren Sie, wie Sie Helm v2 auf v3 migrieren. sidebar_position: 13 --- Diese Anleitung zeigt, wie Sie Helm v2 auf v3 migrieren. Helm v2 muss installiert sein und Releases in einem oder mehreren Clustern verwalten. ## Übersicht der Änderungen in Helm 3 Die vollständige Liste der Änderungen von Helm 2 auf 3 ist im Abschnitt [FAQ](/faq/changes_since_helm2.md) dokumentiert. Im Folgenden finden Sie eine Zusammenfassung einiger Änderungen, die ein Benutzer vor und während der Migration beachten sollte: 1. Entfernung von Tiller: - Die Client/Server-Architektur wird durch eine Client/Library-Architektur ersetzt (nur noch das `helm`-Binary) - Sicherheit basiert nun auf Benutzerbasis (delegiert an die Kubernetes- Cluster-Sicherheit) - Releases werden jetzt als In-Cluster-Secrets gespeichert und die Metadaten des Release-Objekts haben sich geändert - Releases werden pro Release-Namespace persistiert und nicht mehr im Tiller-Namespace 2. Aktualisiertes Chart-Repository: - `helm search` unterstützt jetzt sowohl lokale Repository-Suchen als auch Suchanfragen an Artifact Hub 3. Chart apiVersion auf "v2" angehoben für folgende Spezifikationsänderungen: - Dynamisch verknüpfte Chart-Abhängigkeiten wurden nach `Chart.yaml` verschoben (`requirements.yaml` entfernt und requirements --> dependencies) - Library-Charts (Hilfs-/Common-Charts) können jetzt als dynamisch verknüpfte Chart-Abhängigkeiten hinzugefügt werden - Charts haben ein `type`-Metadatenfeld, das definiert, ob das Chart ein `application`- oder `library`-Chart ist. Standardmäßig ist es application, was bedeutet, dass es renderbar und installierbar ist - Helm 2-Charts (apiVersion=v1) sind weiterhin installierbar 4. XDG-Verzeichnisspezifikation hinzugefügt: - Helm home wurde entfernt und durch die XDG-Verzeichnisspezifikation zum Speichern von Konfigurationsdateien ersetzt - Helm muss nicht mehr initialisiert werden - `helm init` und `helm home` wurden entfernt 5. Weitere Änderungen: - Die Installation/Einrichtung von Helm wurde vereinfacht: - Nur noch Helm-Client (helm-Binary) (kein Tiller) - Sofort einsatzbereit - `local`- oder `stable`-Repositories werden standardmäßig nicht eingerichtet - Der `crd-install`-Hook wurde entfernt und durch das `crds`-Verzeichnis im Chart ersetzt, in dem alle CRDs definiert werden, die vor dem Rendern des Charts installiert werden - Der Hook-Annotationswert `test-failure` wurde entfernt, und `test-success` ist veraltet. Verwenden Sie stattdessen `test` - Entfernte/ersetzte/hinzugefügte Befehle: - delete --> uninstall: Entfernt standardmäßig die gesamte Release-Historie (früher war `--purge` erforderlich) - fetch --> pull - home (entfernt) - init (entfernt) - install: Erfordert einen Release-Namen oder das Argument `--generate-name` - inspect --> show - reset (entfernt) - serve (entfernt) - template: Das Argument `-x`/`--execute` wurde in `-s`/`--show-only` umbenannt - upgrade: Das Argument `--history-max` wurde hinzugefügt, das die maximale Anzahl der gespeicherten Revisionen pro Release begrenzt (0 für kein Limit) - Die Helm 3-Go-Bibliothek hat viele Änderungen durchlaufen und ist nicht mit der Helm 2-Bibliothek kompatibel - Release-Binaries werden jetzt auf `get.helm.sh` gehostet ## Anwendungsfälle für die Migration Es gibt folgende Anwendungsfälle: 1. Helm v2 und v3 verwalten denselben Cluster: - Dieser Anwendungsfall wird nur empfohlen, wenn Sie beabsichtigen, Helm v2 schrittweise auslaufen zu lassen und v3 keine von v2 bereitgestellten Releases verwalten soll. Alle neuen Releases sollten von v3 bereitgestellt werden, und bestehende, von v2 bereitgestellte Releases sollten nur von v2 aktualisiert/ entfernt werden - Helm v2 und v3 können problemlos denselben Cluster verwalten. Die Helm-Versionen können auf demselben oder auf separaten Systemen installiert werden - Wenn Sie Helm v3 auf demselben System installieren, müssen Sie einen zusätzlichen Schritt durchführen, um sicherzustellen, dass beide Client-Versionen koexistieren können, bis Sie bereit sind, den Helm v2-Client zu entfernen. Benennen Sie das Helm v3-Binary um oder legen Sie es in einem anderen Ordner ab, um Konflikte zu vermeiden - Andernfalls gibt es keine Konflikte zwischen beiden Versionen aufgrund der folgenden Unterschiede: - Die Release-(Historie-)Speicherung von v2 und v3 ist voneinander unabhängig. Die Änderungen umfassen die Kubernetes-Ressource für die Speicherung und die Release-Objekt-Metadaten in der Ressource. Releases werden auch pro Benutzer-Namespace gespeichert und nicht mehr im Tiller-Namespace (z.B. war der Standard-Tiller-Namespace in v2 kube-system). v2 verwendet "ConfigMaps" oder "Secrets" im Tiller-Namespace mit `TILLER`-Ownership. v3 verwendet "Secrets" im Benutzer-Namespace mit `helm`-Ownership. Releases sind sowohl in v2 als auch in v3 inkrementell - Das einzige Problem könnte auftreten, wenn clusterweite Kubernetes-Ressourcen (z.B. `clusterroles.rbac`) in einem Chart definiert sind. Das v3-Deployment würde dann fehlschlagen, selbst wenn es im Namespace eindeutig ist, da die Ressourcen kollidieren würden - Die v3-Konfiguration verwendet nicht mehr `$HELM_HOME` und nutzt stattdessen die XDG-Verzeichnisspezifikation. Sie wird auch bei Bedarf automatisch erstellt. Sie ist daher unabhängig von der v2-Konfiguration. Dies gilt nur, wenn beide Versionen auf demselben System installiert sind 2. Migration von Helm v2 auf Helm v3: - Dieser Anwendungsfall gilt, wenn Sie möchten, dass Helm v3 bestehende Helm v2- Releases verwaltet - Beachten Sie, dass ein Helm v2-Client: - 1 bis viele Kubernetes-Cluster verwalten kann - sich mit 1 bis vielen Tiller-Instanzen pro Cluster verbinden kann - Das bedeutet, dass Sie dies bei der Migration berücksichtigen müssen, da Releases von Tiller und dessen Namespace in Cluster bereitgestellt werden. Sie müssen daher die Migration für jeden Cluster und jede Tiller-Instanz berücksichtigen, die von der Helm v2-Client-Instanz verwaltet wird - Der empfohlene Migrationspfad für Daten ist wie folgt: 1. v2-Daten sichern 2. Helm v2-Konfiguration migrieren 3. Helm v2-Releases migrieren 4. Wenn Sie sicher sind, dass Helm v3 alle Helm v2-Daten (für alle Cluster und Tiller-Instanzen der Helm v2-Client-Instanz) wie erwartet verwaltet, können Sie die Helm v2-Daten bereinigen - Der Migrationsprozess wird durch das Helm v3-Plugin [2to3](https://github.com/helm/helm-2to3) automatisiert ## Referenzen - Helm v3 [2to3](https://github.com/helm/helm-2to3) Plugin - [Blogbeitrag](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/), der die Verwendung des `2to3`-Plugins mit Beispielen erklärt ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Helm Versionsunterstützung" description: "Beschreibt die Patch-Release-Richtlinie von Helm sowie die maximal unterstützte Versionsabweichung zwischen Helm und Kubernetes." --- Dieses Dokument beschreibt die maximal unterstützte Versionsabweichung zwischen Helm und Kubernetes. ## Unterstützte Versionen Helm-Versionen werden als `x.y.z` ausgedrückt, wobei `x` die Hauptversion, `y` die Nebenversion und `z` die Patch-Version ist. Dies entspricht der [Semantischen Versionierung](https://semver.org/spec/v2.0.0.html). Das Helm-Projekt pflegt einen Release-Branch für die jeweils aktuellste Nebenversion. Relevante Korrekturen, einschließlich Sicherheitskorrekturen, werden je nach Schweregrad und Machbarkeit in den Release-Branch übernommen. Weitere Details finden Sie in [Helms Release-Richtlinie](/community/release_policy). ## Unterstützte Versionsabweichung Jede neue Helm-Version wird gegen eine bestimmte Nebenversion von Kubernetes kompiliert. Helm 3.0.0 verwendet beispielsweise den Kubernetes 1.16.2 Client und ist daher mit Kubernetes 1.16 kompatibel. Ab Helm 3 gilt die Kompatibilität mit `n-3` Versionen von Kubernetes, gegen die Helm kompiliert wurde. Bei Helm 2 ist die Unterstützungsrichtlinie aufgrund der Änderungen zwischen Kubernetes-Nebenversionen strenger: hier gilt die Kompatibilität mit `n-1` Versionen. Wenn Sie beispielsweise eine Version von Helm 3 verwenden, die gegen die Kubernetes 1.17 Client-APIs kompiliert wurde, können Sie diese sicher mit Kubernetes 1.17, 1.16, 1.15 und 1.14 verwenden. Bei einer Version von Helm 2, die gegen die Kubernetes 1.16 Client-APIs kompiliert wurde, ist die Verwendung mit Kubernetes 1.16 und 1.15 sicher. Es wird nicht empfohlen, Helm mit einer neueren Kubernetes-Version zu verwenden als der, gegen die es kompiliert wurde. Helm gibt keine Vorwärtskompatibilitätsgarantien. Wenn Sie Helm mit einer nicht unterstützten Kubernetes-Version verwenden, tun Sie dies auf eigenes Risiko. In der folgenden Tabelle sehen Sie, welche Helm-Version mit Ihrem Cluster kompatibel ist. | Helm-Version | Unterstützte Kubernetes-Versionen | |--------------|-----------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/de/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Einführung", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Anleitungen", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Themen", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Bewährte Praktiken", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Chart Template Guide", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm-Befehle", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Gemeinschaft", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Häufig gestellte Fragen", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/de/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Release-Zeitplan-Richtlinie" description: "Beschreibt Helms Release-Zeitplan-Richtlinie." --- Helm gibt Veröffentlichungstermine im Voraus bekannt, damit Anwender besser planen können. Dieses Dokument beschreibt die Richtlinie für Helms Release-Zeitplan. ## Release-Kalender Ein öffentlicher Kalender mit den anstehenden Helm-Releases ist [hier](https://helm.sh/calendar/release) verfügbar. ## Semantische Versionierung Helm-Versionen werden als `x.y.z` ausgedrückt, wobei `x` die Hauptversion, `y` die Nebenversion und `z` die Patch-Version ist. Dies entspricht der Terminologie der [Semantischen Versionierung](https://semver.org/spec/v2.0.0.html). ## Patch-Releases Patch-Releases bieten Benutzern Fehlerbehebungen und Sicherheitskorrekturen. Sie enthalten keine neuen Funktionen. Ein neues Patch-Release für die aktuelle Neben-/Hauptversion wird normalerweise einmal im Monat am zweiten Mittwoch jedes Monats veröffentlicht. Ein Patch-Release zur Behebung einer kritischen Regression oder eines Sicherheitsproblems kann jederzeit bei Bedarf erfolgen. Ein Patch-Release wird aus einem der folgenden Gründe abgesagt: - wenn seit dem letzten Release kein neuer Inhalt hinzugekommen ist - wenn das Patch-Release-Datum innerhalb einer Woche vor dem ersten Release Candidate (RC1) einer anstehenden Nebenversion liegt - wenn das Patch-Release-Datum innerhalb von vier Wochen nach einer Nebenversion liegt ## Nebenversionen Nebenversionen enthalten Sicherheits- und Fehlerbehebungen sowie neue Funktionen. Sie sind rückwärtskompatibel in Bezug auf die API und die CLI-Nutzung. Um sich mit Kubernetes-Releases abzustimmen, wird eine Helm-Nebenversion alle 4 Monate veröffentlicht (3 Releases pro Jahr). Zusätzliche Nebenversionen können bei Bedarf veröffentlicht werden, beeinflussen aber nicht den Zeitplan eines angekündigten zukünftigen Releases, es sei denn, das angekündigte Release liegt weniger als 7 Tage entfernt. Gleichzeitig mit der Veröffentlichung eines Releases wird das Datum der nächsten Nebenversion angekündigt und auf Helms Hauptwebseite veröffentlicht. ## Hauptversionen Hauptversionen enthalten Breaking Changes. Solche Releases sind selten, aber manchmal notwendig, damit sich Helm in wichtigen neuen Richtungen weiterentwickeln kann. Hauptversionen können schwierig zu planen sein. Daher wird ein finales Veröffentlichungsdatum erst gewählt und angekündigt, wenn die erste Beta-Version eines solchen Releases verfügbar ist. ================================================ FILE: i18n/de/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Helm-Projekt", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Entwicklung", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Gemeinschaft", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Quellcode", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Blog", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Veranstaltungen", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Verhaltenskodex", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Einführung", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Chart-Tipps und -Tricks", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Charts entwickeln", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "800+ Charts durchsuchen", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Beitragsleitfaden", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Betreuer", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Wöchentliche Treffen", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "GitHub-Gemeinschaft", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Wir sind ein promoviertes Projekt der Cloud Native Computing Foundation.
© Helm-Autoren 2025. Dokumentation verteilt unter CC-BY-4.0.
© 2025 The Linux Foundation. Alle Rechte vorbehalten. The Linux Foundation besitzt eingetragene Marken und verwendet Marken. Eine Liste der Marken der Linux Foundation finden Sie auf unserer Seite zur Markennutzung.", "description": "The footer copyright" }, "logo.alt": { "message": "CNCF-Logo", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/de/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Helm-Logo", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Dokumentation", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Blog", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Gemeinschaft", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/el/code.json ================================================ { "home.community.nextFeatureRelease": { "message": "Επόμενο Feature Release", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Έκδοση:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Ημερομηνία:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Ημερολόγιο Εκδόσεων", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Επερχόμενα Events", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Επερχόμενα Events", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Παλιά Events", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "{meetLink} για επίδειξη και συζήτηση εργαλείων και έργων. Οι συναντήσεις της κοινότητας καταγράφονται και {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "Συναντιούνται κάθε εβδομάδα", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "κοινοποιούνται στο YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Συναντήσεις Προγραμματιστών" }, "home.community.developerStandups.time": { "message": "Πέμπτες 9:30-10πμ (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Αυτές οι συναντήσεις είναι ανοιχτές σε όλους. Ελέγξτε το {communityRepoLink} για σημειώσεις και λεπτομέρειες.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "αποθετήριο της κοινότητας", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Συζήτηση σχετικά με τη χρήση του Helm, την εργασία με charts και την επίλυση συνηθισμένων σφαλμάτων.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Θέματα σχετικά με την ανάπτυξη του Helm, τρέχοντα PRs, εκδόσεις κ.λπ.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Συζήτηση για χρήστες και συνεισφέροντες στα Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink} για να συμμετάσχετε στην ομάδα Slack του Kubernetes.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Ζητήστε πρόσβαση εδώ", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Συνεισφορά", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Το Helm καλωσορίζει πάντα νέες συνεισφορές στο έργο!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "Από πού να ξεκινήσω;", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Το Helm είναι ένα μεγάλο project με πολλούς χρήστες και contributors. Έχεις πολλά να μάθεις!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Έχουμε μια λίστα με {goodFirstIssuesLink} αν θέλετε να βοηθήσετε αλλά δεν ξέρετε από πού να ξεκινήσετε.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "καλά πρώτα ζητήματα", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Τι πρέπει να κάνω;", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Πριν συνεισφέρετε κώδικα, παρακαλούμε διαβάστε τον {contributionGuideLink}. Περιγράφει τις διαδικασίες γύρω από τη δημιουργία και την αναθεώρηση pull requests.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Οδηγό Συνεισφοράς", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Αφού γράψετε κώδικα, παρακαλούμε {signYourCommitsLink} για να διασφαλίσετε ότι το Helm συμμορφώνεται με τη συμφωνία {dcoLink} που χρησιμοποιείται από το {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "υπογράψτε τα commits σας", "description": "Sign your commits link" }, "home.community.title": { "message": "Μπες στην κοινότητα", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Περισσότερες πληροφορίες για το Helm project, και πως να συνεισφέρεις.", "description": "Join the Community subtitle" }, "home.about.whatIsHelm": { "message": "Το Helm σας βοηθά να διαχειρίζεστε εφαρμογές Kubernetes — Τα Helm Charts σας βοηθούν να ορίζετε, να εγκαθιστάτε και να αναβαθμίζετε ακόμα και τις πιο σύνθετες εφαρμογές Kubernetes.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Τα Charts είναι εύκολο να δημιουργηθούν, να εκδοθούν σε νέες εκδόσεις, να μοιραστούν και να δημοσιευτούν — ξεκινήστε λοιπόν να χρησιμοποιείτε το Helm και σταματήστε το αντιγραφή-επικόλληση.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Το Helm είναι ένα graduated project στο {cncfLink} και διατηρείται από την {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "κοινότητα Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Μάθε περισσότερα:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Αρχιτεκτονική Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Οδηγός Γρήγορης Εκκίνησης", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Βίντεο: Μια Εισαγωγή στο Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Τι είναι το Helm;", "description": "What is Helm? title" }, "home.features.manageComplexity": { "message": "Διαχείριση Πολυπλοκότητας", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Τα Charts περιγράφουν ακόμα και τις πιο σύνθετες εφαρμογές, παρέχουν επαναλήψιμη εγκατάσταση εφαρμογών και λειτουργούν ως ενιαίο σημείο αναφοράς.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Εύκολες Ενημερώσεις", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Αφαιρέστε τον πόνο από τις ενημερώσεις με αναβαθμίσεις επί τόπου και προσαρμοσμένα hooks.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Απλή Κοινοποίηση", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Τα Charts είναι εύκολο να εκδοθούν σε νέες εκδόσεις, να μοιραστούν και να φιλοξενηθούν σε δημόσιους ή ιδιωτικούς διακομιστές.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Επαναφορές", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Χρησιμοποιήστε το {helmRollback} για να επαναφέρετε εύκολα σε παλαιότερη έκδοση μιας κυκλοφορίας.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Χαρακτηριστικά", "description": "Features section title" }, "home.gettingStarted.title": { "message": "Ξεκίνα", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Κατέβασε το Helm!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Εγκαταστήστε το Helm με έναν διαχειριστή πακέτων ή {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "κατεβάστε ένα δυαδικό αρχείο", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Μόλις εγκατασταθεί, αποσυμπιέστε το δυαδικό αρχείο helm και προσθέστε το στο PATH σας και είστε έτοιμοι! Ελέγξτε τα {docsLink} για περαιτέρω {installationLink} και {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "έγγραφα", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "οδηγίες εγκατάστασης", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "οδηγίες χρήσης", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Κατέβασε Charts", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Επισκεφτείτε το {artifactHubLink} για να εξερευνήσετε {helmChartsLink} από πολλά δημόσια αποθετήρια.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "home.header.tagline": { "message": "Ο διαχειριστής πακέτων για το Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Το Helm είναι ο καλύτερος τρόπος για να βρείτε, να μοιραστείτε και να χρησιμοποιήσετε λογισμικό που έχει κατασκευαστεί για", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "This page crashed.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Scroll back to top", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Archive", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Archive", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Blog list page navigation", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Newer entries", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Older entries", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Blog post page navigation", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Newer post", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Older post", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "View all tags", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "λειτουργία συστήματος", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "φωτεινή λειτουργία", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "σκοτεινή λειτουργία", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Switch between dark and light mode (currently {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Breadcrumbs", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 item|{count} items", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Docs pages", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Previous", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Next", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "One doc tagged|{count} docs tagged", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} with \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "This is unreleased documentation for {siteTitle} {versionLabel} version.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "This is documentation for {siteTitle} {versionLabel}, which is no longer actively maintained.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "For up-to-date documentation, see the {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "latest version", "description": "The label used for the latest version suggestion link label" }, "theme.docs.versionBadge.label": { "message": "Version: {versionLabel}" }, "theme.common.editThisPage": { "message": "Edit this page", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "Direct link to {heading}", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " on {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " by {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Last updated{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.NotFound.title": { "message": "Page Not Found", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versions", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Tags:", "description": "The label alongside a tag list" }, "theme.admonition.caution": { "message": "caution", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "danger", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "info", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "note", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "tip", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "warning", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Close", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { "message": "Blog recent posts navigation", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Expand sidebar category '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Collapse sidebar category '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(ανοίγει σε νέα καρτέλα)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Main", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "We could not find what you were looking for.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Please contact the owner of the site that linked you to the original URL and let them know their link is broken.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Languages", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "On this page", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readingTime.plurals": { "message": "One min read|{readingTime} min read", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.post.readMore": { "message": "Read more", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Read more about {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.CodeBlock.copy": { "message": "Copy", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Copied", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Copy code to clipboard", "description": "The ARIA label for copy code blocks button" }, "theme.docs.breadcrumbs.home": { "message": "Home page", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.CodeBlock.wordWrapToggle": { "message": "Toggle word wrap", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.sidebar.navAriaLabel": { "message": "Docs sidebar", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Collapse sidebar", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Collapse sidebar", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Close navigation bar", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Back to main menu", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Toggle navigation bar", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Ανάπτυξη του αναπτυσσόμενου μενού", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Σύμπτυξη του αναπτυσσόμενου μενού", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Expand sidebar", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Expand sidebar", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "One post|{count} posts", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} tagged with \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Συγγραφείς", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "View all authors", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "This author has not written any posts yet.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Unlisted page", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "This page is unlisted. Search engines will not index it, and only users having a direct link can access it.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Draft page", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "This page is a draft. It will only be visible in dev and be excluded from the production build.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Try again", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Skip to main content", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Tags", "description": "The title of the tag list page" }, "theme.blog.list.pageTitle": { "message": "Ιστολόγιο", "description": "The word 'Blog' in breadcrumbs" } } ================================================ FILE: i18n/el/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Ιστολόγιο", "description": "The title for the blog used in SEO" }, "description": { "message": "Ιστολόγιο", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Όλες οι δημοσιεύσεις", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Χρήση του Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Εντολές Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Ανάπτυξη Προτύπων", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Καλές Πρακτικές", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Γενικές Συμβάσεις description: Γενικές Συμβάσεις για τα charts. sidebar_position: 1 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών εξηγεί τις γενικές συμβάσεις. ## Ονόματα των Charts {#chart-names} Τα ονόματα των charts πρέπει να είναι γραμμένα με μικρά λατινικά γράμματα και αριθμούς. Οι λέξεις _μπορούν_ να διαχωρίζονται με παύλες (-): Παραδείγματα: ``` drupal nginx-lego aws-cluster-autoscaler ``` Ούτε κεφαλαία γράμματα ούτε κάτω παύλες μπορούν να χρησιμοποιούνται στα ονόματα των charts. Οι τελείες δεν θα πρέπει να χρησιμοποιούνται στα ονόματα των charts. ## Αριθμοί Εκδόσεων {#version-numbers} Όπου είναι δυνατό, το Helm χρησιμοποιεί το [SemVer 2](https://semver.org) για να αναπαραστήσει τους αριθμούς των εκδόσεων. (Σημειώστε ότι τα tags ενός Docker image δεν ακολουθούν απαραίτητα το SemVer, και ως εκ τούτου θεωρούνται μια ατυχής εξαίρεση στον κανόνα.) Όταν οι εκδόσεις τύπου SemVer αποθηκεύονται στα labels του Kubernetes, ως σύμβαση αλλάζουμε τον χαρακτήρα `+` σε `_`, καθώς τα labels δεν επιτρέπουν το σήμα `+` ως τιμή. ## Μορφοποίηση του YAML {#formatting-yaml} Τα αρχεία YAML θα πρέπει να στοιχίζονται χρησιμοποιώντας _δύο κενά_ (και ποτέ tabs). ## Χρήση των λέξεων Helm και Chart {#usage-of-the-words-helm-and-chart} Υπάρχουν μερικές συμβάσεις για τη χρήση των λέξεων _Helm_ και _helm_. - Το _Helm_ αναφέρεται σε ολόκληρο το project - Το `helm` αναφέρεται στην εντολή που εκτελείται από τον χρήστη - Ο όρος `chart` δεν χρειάζεται να γραφτεί με κεφαλαίο, αφού δεν αποτελεί κύριο όνομα - Παρ' ολ' αυτά, το `Chart.yaml` χρειάζεται να γραφτεί με κεφαλαίο γιατί τα ονόματα αρχείων κάνουν διάκριση πεζών-κεφαλαίων (case sensitive). Όταν δεν είστε σίγουροι, χρησιμοποιήστε το _Helm_ (με κεφαλαίο 'H'). ## Chart templates και namespaces {#chart-templates-and-namespaces} Αποφύγετε τον ορισμό της ιδιότητας `namespace` στην ενότητα `metadata` των templates του chart σας. Το namespace στο οποίο θα εφαρμοστούν τα rendered templates πρέπει να καθορίζεται κατά την κλήση του Kubernetes client μέσω flag όπως `--namespace`. Το Helm κάνει render τα templates σας ως έχουν και τα στέλνει στον Kubernetes client, είτε αυτός είναι το ίδιο το Helm είτε κάποιο άλλο πρόγραμμα (kubectl, flux, spinnaker, κ.λπ.). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Πώς να χειρίζεστε τη δημιουργία και χρήση των CRDs. sidebar_position: 7 --- Αυτός ο τομέας του οδηγού καλύπτει τη δημιουργία και χρήση αντικειμένων Custom Resource Definition. Όταν εργάζεστε με Custom Resource Definitions (CRDs), είναι σημαντικό να διακρίνετε δύο διαφορετικά στοιχεία: - Υπάρχει η δήλωση ενός CRD. Αυτό είναι το αρχείο YAML που έχει kind `CustomResourceDefinition` - Στη συνέχεια υπάρχουν πόροι που _χρησιμοποιούν_ το CRD. Ας πούμε ότι ένα CRD ορίζει `foo.example.com/v1`. Οποιοσδήποτε πόρος έχει `apiVersion: example.com/v1` και kind `Foo` είναι ένας πόρος που χρησιμοποιεί το CRD. ## Εγκαταστήστε μια Δήλωση CRD Πριν Χρησιμοποιήσετε τον Πόρο {#install-a-crd-declaration-before-using-the-resource} Το Helm είναι βελτιστοποιημένο για να φορτώνει όσο το δυνατόν περισσότερους πόρους στο Kubernetes το συντομότερο δυνατό. Από σχεδιασμό, το Kubernetes μπορεί να λάβει ένα ολόκληρο σύνολο manifests και να τα φέρει όλα online (αυτό ονομάζεται reconciliation loop). Αλλά υπάρχει μια διαφορά με τα CRDs. Για ένα CRD, η δήλωση πρέπει να καταχωρηθεί πριν μπορέσουν να χρησιμοποιηθούν οποιοιδήποτε πόροι του τύπου (ή των τύπων) αυτού του CRD. Και η διαδικασία καταχώρησης μερικές φορές διαρκεί μερικά δευτερόλεπτα. ### Μέθοδος 1: Αφήστε το `helm` να το Κάνει {#method-1-let-helm-do-it-for-you} Με την άφιξη του Helm 3, αφαιρέσαμε τα παλιά `crd-install` hooks για μια πιο απλή μεθοδολογία. Υπάρχει τώρα ένας ειδικός φάκελος με το όνομα `crds` που μπορείτε να δημιουργήσετε στο chart σας για να περιέχει τα CRDs σας. Αυτά τα CRDs δεν υποστηρίζουν templating, αλλά θα εγκατασταθούν από προεπιλογή όταν εκτελείτε `helm install` για το chart. Αν το CRD υπάρχει ήδη, θα παραλειφθεί με μια προειδοποίηση. Αν θέλετε να παραλείψετε το βήμα εγκατάστασης CRD, μπορείτε να περάσετε τη σημαία `--skip-crds`. #### Μερικές επιφυλάξεις (και εξηγήσεις) {#some-caveats-and-explanations} Δεν υπάρχει υποστήριξη αυτή τη στιγμή για αναβάθμιση ή διαγραφή CRDs χρησιμοποιώντας το Helm. Αυτή ήταν μια ρητή απόφαση μετά από πολλή συζήτηση στην κοινότητα λόγω του κινδύνου για ακούσια απώλεια δεδομένων. Επιπλέον, αυτή τη στιγμή δεν υπάρχει συναίνεση στην κοινότητα σχετικά με τον τρόπο χειρισμού των CRDs και του κύκλου ζωής τους. Καθώς αυτό εξελίσσεται, το Helm θα προσθέσει υποστήριξη για αυτές τις περιπτώσεις χρήσης. Η σημαία `--dry-run` των `helm install` και `helm upgrade` δεν υποστηρίζεται αυτή τη στιγμή για CRDs. Ο σκοπός του "Dry Run" είναι να επικυρώσει ότι η έξοδος του chart θα λειτουργήσει πραγματικά αν σταλεί στον server. Αλλά τα CRDs αποτελούν τροποποίηση της συμπεριφοράς του server. Το Helm δεν μπορεί να εγκαταστήσει το CRD σε dry run, επομένως ο discovery client δεν θα γνωρίζει για αυτό το Custom Resource (CR), και η επικύρωση θα αποτύχει. Εναλλακτικά μπορείτε να μεταφέρετε τα CRDs στο δικό τους chart ή να χρησιμοποιήσετε το `helm template` αντί αυτού. Ένα άλλο σημαντικό σημείο που πρέπει να ληφθεί υπόψη στη συζήτηση γύρω από την υποστήριξη CRD είναι ο τρόπος με τον οποίο γίνεται το rendering των templates. Ένα από τα ξεχωριστά μειονεκτήματα της μεθόδου `crd-install` που χρησιμοποιούνταν στο Helm 2 ήταν η αδυναμία σωστής επικύρωσης charts λόγω της μεταβαλλόμενης διαθεσιμότητας API (ένα CRD στην πραγματικότητα προσθέτει ένα ακόμη διαθέσιμο API στο Kubernetes cluster σας). Αν ένα chart εγκαθιστούσε ένα CRD, το `helm` δεν είχε πλέον ένα έγκυρο σύνολο εκδόσεων API με το οποίο να εργαστεί. Αυτός είναι επίσης ο λόγος πίσω από την αφαίρεση της υποστήριξης templating από τα CRDs. Με τη νέα μέθοδο `crds` για την εγκατάσταση CRD, διασφαλίζουμε τώρα ότι το `helm` έχει πλήρως έγκυρες πληροφορίες για την τρέχουσα κατάσταση του cluster. ### Μέθοδος 2: Ξεχωριστά Charts {#method-2-separate-charts} Ένας άλλος τρόπος για να το κάνετε αυτό είναι να βάλετε τον ορισμό του CRD σε ένα chart, και στη συνέχεια να βάλετε οποιουσδήποτε πόρους που χρησιμοποιούν αυτό το CRD σε _ένα άλλο_ chart. Με αυτή τη μέθοδο, κάθε chart πρέπει να εγκατασταθεί ξεχωριστά. Ωστόσο, αυτή η ροή εργασίας μπορεί να είναι πιο χρήσιμη για διαχειριστές cluster που διαθέτουν δικαιώματα διαχειριστή σε ένα cluster. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Εξαρτήσεις description: Καλύπτει τις βέλτιστες πρακτικές για τις εξαρτήσεις ενός Chart. sidebar_position: 4 --- Αυτός ο τομέας του οδηγού καλύπτει τις βέλτιστες πρακτικές για τις `dependencies` που δηλώνονται στο `Chart.yaml`. ## Εκδόσεις {#versions} Όπου είναι δυνατό, χρησιμοποιήστε ένα εύρος εκδόσεων αντί να καρφώνετε σε κάποια συγκεκριμένη έκδοση. Η συνιστώμενη προεπιλογή είναι να χρησιμοποιείτε ταίριασμα σε επίπεδο patch: ```yaml version: ~1.2.3 ``` Αυτό θα ταιριάξει με την έκδοση `1.2.3` και όλα τα patches αυτής της έκδοσης. Με άλλα λόγια, το `~1.2.3` είναι ισοδύναμο με `>= 1.2.3, < 1.3.0` Για την πλήρη σύνταξη του ταιριάσματος εκδόσεων, παρακαλούμε δείτε την [τεκμηρίωση του semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Prerelease εκδόσεις {#prerelease-versions} Οι παραπάνω περιορισμοί έκδοσης δεν θα ταιριάξουν με prerelease εκδόσεις. Για παράδειγμα, το `version: ~1.2.3` θα ταιριάξει με το `version: ~1.2.4` αλλά όχι με το `version: ~1.2.3-1`. Το παρακάτω παρέχει ταίριασμα τόσο για prerelease όσο και σε επίπεδο patch: ```yaml version: ~1.2.3-0 ``` ### URLs των Repositories {#repository-urls} Όπου είναι δυνατό, χρησιμοποιήστε `https://` URLs για τα repositories, και στη συνέχεια `http://` URLs. Αν το repository έχει προστεθεί στο αρχείο index του repository, το όνομα του repository μπορεί να χρησιμοποιηθεί ως alias του URL. Χρησιμοποιήστε `alias:` ή `@` ακολουθούμενο από το όνομα του repository. Τα file URLs (`file://...`) θεωρούνται ως «ειδική περίπτωση» για charts τα οποία συναρμολογούνται από ένα σταθερό deployment pipeline. Όταν χρησιμοποιείτε [downloader plugins](/topics/plugins.md#plugins-λήψης), το URL scheme θα είναι συγκεκριμένο για το plugin. Σημειώστε ότι ένας χρήστης του chart θα πρέπει να έχει εγκατεστημένο ένα plugin που υποστηρίζει το scheme για να ενημερώσει ή να δημιουργήσει την εξάρτηση. Το Helm δεν μπορεί να εκτελέσει λειτουργίες διαχείρισης εξαρτήσεων στην εξάρτηση όταν το πεδίο `repository` παραμένει κενό. Σε αυτήν την περίπτωση, το Helm θα υποθέσει ότι η εξάρτηση βρίσκεται σε έναν υποφάκελο του φακέλου `charts` με το ίδιο όνομα με την ιδιότητα `name` της εξάρτησης. ## Συνθήκες και Tags {#conditions-and-tags} Οι συνθήκες ή τα tags θα πρέπει να προστίθενται σε εξαρτήσεις που είναι _προαιρετικές_. Σημειώστε ότι από προεπιλογή ένα `condition` είναι `true`. Η προτιμώμενη μορφή μίας συνθήκης (condition) είναι η ακόλουθη: ```yaml condition: somechart.enabled ``` Όπου το `somechart` είναι το όνομα του chart της εξάρτησης. Όταν πολλαπλά subcharts (εξαρτήσεις) παρέχουν μαζί ένα προαιρετικό ή ανταλλάξιμο feature, αυτά τα charts θα πρέπει να μοιράζονται τα ίδια tags. Για παράδειγμα, αν τόσο το `nginx` όσο και το `memcached` παρέχουν βελτιστοποιήσεις απόδοσης για την κύρια εφαρμογή του chart, και απαιτούνται και τα δύο όταν αυτό το feature είναι ενεργοποιημένο, τότε θα πρέπει να έχουν και τα δύο έναν τομέα με tags κάπως έτσι: ```yaml tags: - webaccelerator ``` Αυτό επιτρέπει στον χρήστη να ενεργοποιεί και να απενεργοποιεί αυτό το feature με ένα tag. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: Βέλτιστες Πρακτικές sidebar: true sidebar_position: 4 --- # Ο Οδηγός Βέλτιστων Πρακτικών για τα Charts Αυτός ο οδηγός καλύπτει αυτά που η Ομάδα του Helm θεωρεί ως βέλτιστες πρακτικές για την δημιουργία charts. Επικεντρώνεται στο πως θα έπρεπε να δομούνται τα charts. Κυρίως επικεντρωνόμαστε στις βέλτιστες πρακτικές για τα charts τα οποία θα μπορούσαν να γίνουν deploy από ευρύτερο κοινό. Ξέρουμε ότι πολλά charts προορίζονται μόνο για εσωτερική χρήση, και οι συγγραφείς τέτοιων charts ότι τα εσωτερικά συμφέροντα παρακάμπτουν τις προτάσεις μας εδώ. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Ετικέτες και Annotations description: Καλύπτει τις βέλτιστες πρακτικές για τη χρήση ετικετών και annotations στο chart σας. sidebar_position: 5 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τις βέλτιστες πρακτικές για τη χρήση ετικετών και annotations στο chart σας. ## Είναι Ετικέτα ή Annotation; {#is-it-a-label-or-an-annotation} Ένα στοιχείο μεταδεδομένων θα πρέπει να είναι ετικέτα υπό τις ακόλουθες συνθήκες: - Χρησιμοποιείται από το Kubernetes για την αναγνώριση αυτού του πόρου - Είναι χρήσιμο να εκτίθεται στους διαχειριστές για σκοπούς αναζήτησης στο σύστημα. Για παράδειγμα, προτείνουμε τη χρήση του `helm.sh/chart: NAME-VERSION` ως ετικέτα, ώστε οι διαχειριστές να μπορούν να βρίσκουν εύκολα όλες τις εκδοχές ενός συγκεκριμένου chart. Αν ένα στοιχείο μεταδεδομένων δεν χρησιμοποιείται για αναζήτηση, θα πρέπει να οριστεί ως annotation. Τα Helm hooks είναι πάντα annotations. ## Τυπικές Ετικέτες {#standard-labels} Ο παρακάτω πίνακας ορίζει τις συνήθεις ετικέτες που χρησιμοποιούν τα Helm charts. Το ίδιο το Helm δεν απαιτεί ποτέ την παρουσία μιας συγκεκριμένης ετικέτας. Οι ετικέτες που σημειώνονται με REC συνιστώνται και **θα πρέπει** να τοποθετούνται σε ένα chart για γενική συνέπεια. Αυτές που σημειώνονται με OPT είναι προαιρετικές. Είναι συνηθισμένες στην πράξη, αλλά δεν είναι απαραίτητες για λειτουργικούς σκοπούς. | Όνομα | Κατάσταση | Περιγραφή | |-------|-----------|-----------| | `app.kubernetes.io/name` | REC | Θα πρέπει να είναι το όνομα της εφαρμογής, που αντιπροσωπεύει ολόκληρη την εφαρμογή. Συνήθως χρησιμοποιείται το `{{ template "name" . }}`. Χρησιμοποιείται από πολλά Kubernetes manifests και δεν είναι συγκεκριμένο για το Helm. | | `helm.sh/chart` | REC | Θα πρέπει να είναι το όνομα και η έκδοση του chart: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | | `app.kubernetes.io/managed-by` | REC | Θα πρέπει να είναι πάντα `{{ .Release.Service }}`. Χρησιμοποιείται για την εύρεση όλων των πόρων που διαχειρίζεται το Helm. | | `app.kubernetes.io/instance` | REC | Θα πρέπει να είναι το `{{ .Release.Name }}`. Βοηθά στη διάκριση μεταξύ διαφορετικών εκδοχών της ίδιας εφαρμογής. | | `app.kubernetes.io/version` | OPT | Η έκδοση της εφαρμογής και μπορεί να οριστεί ως `{{ .Chart.AppVersion }}`. | | `app.kubernetes.io/component` | OPT | Μια συνήθης ετικέτα για τη σήμανση των διαφορετικών ρόλων που μπορεί να έχουν τα διάφορα στοιχεία μιας εφαρμογής. Για παράδειγμα, `app.kubernetes.io/component: frontend`. | | `app.kubernetes.io/part-of` | OPT | Όταν χρησιμοποιούνται πολλαπλά charts ή στοιχεία λογισμικού μαζί για τη δημιουργία μιας εφαρμογής. Για παράδειγμα, λογισμικό εφαρμογής και μια βάση δεδομένων για την παραγωγή ενός ιστότοπου. Μπορεί να οριστεί στην εφαρμογή ανώτερου επιπέδου που υποστηρίζεται. | Μπορείτε να βρείτε περισσότερες πληροφορίες για τις ετικέτες του Kubernetes, με πρόθεμα `app.kubernetes.io`, στην [τεκμηρίωση του Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pod και PodTemplate description: Συζητά τη μορφοποίηση των τμημάτων Pod και PodTemplate στα manifests των chart. sidebar_position: 6 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τη μορφοποίηση των τμημάτων Pod και PodTemplate στα manifests των chart. Η παρακάτω (μη εξαντλητική) λίστα πόρων χρησιμοποιεί PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images {#images} Ένα container image θα πρέπει να χρησιμοποιεί ένα σταθερό tag ή το SHA του image. Δεν θα πρέπει να χρησιμοποιεί τα tags `latest`, `head`, `canary`, ή άλλα tags που είναι σχεδιασμένα να είναι "floating" (μεταβαλλόμενα). Τα images _μπορούν_ να οριστούν στο αρχείο `values.yaml` για να διευκολύνεται η αλλαγή τους. ```yaml image: {{ .Values.redisImage | quote }} ``` Ένα image και ένα tag _μπορούν_ να οριστούν στο `values.yaml` ως δύο ξεχωριστά πεδία: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy {#imagepullpolicy} Η εντολή `helm create` ορίζει το `imagePullPolicy` σε `IfNotPresent` από προεπιλογή με τις ακόλουθες ρυθμίσεις στο `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` Και στο `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Ομοίως, το Kubernetes ορίζει το `imagePullPolicy` σε `IfNotPresent` από προεπιλογή, αν δεν έχει οριστεί καθόλου. Αν θέλετε μια διαφορετική τιμή από το `IfNotPresent`, απλά ενημερώστε την τιμή στο `values.yaml` με την επιθυμητή τιμή. ## Τα PodTemplates Θα Πρέπει να Δηλώνουν Selectors {#podtemplates-should-declare-selectors} Όλα τα τμήματα PodTemplate θα πρέπει να καθορίζουν έναν selector. Για παράδειγμα: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Αυτή είναι μια καλή πρακτική επειδή καθιστά σαφή τη σχέση μεταξύ του set και του Pod. Αυτό είναι ακόμα πιο σημαντικό για πόρους όπως το Deployment. Χωρίς selector, χρησιμοποιείται _ολόκληρο_ το σύνολο των labels για την επιλογή των αντίστοιχων Pods, πράγμα που θα προκαλέσει προβλήματα αν χρησιμοποιείτε labels που αλλάζουν, όπως η έκδοση ή η ημερομηνία release. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους (RBAC) description: Συζητά τη δημιουργία και τη μορφοποίηση πόρων RBAC στα manifests των Charts. sidebar_position: 8 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών ασχολείται με τη δημιουργία και τη μορφοποίηση πόρων RBAC στα manifests των charts. Οι πόροι RBAC είναι: - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## Διαμόρφωση YAML {#yaml-configuration} Η διαμόρφωση RBAC και ServiceAccount θα πρέπει να γίνεται σε ξεχωριστά κλειδιά. Είναι διαφορετικά πράγματα. Ο διαχωρισμός τους στο YAML αποσαφηνίζει τις έννοιες και τις κάνει πιο κατανοητές. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` Αυτή η δομή μπορεί να επεκταθεί για πιο σύνθετα charts που απαιτούν πολλαπλά ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Οι Πόροι RBAC Θα Πρέπει να Δημιουργούνται από Προεπιλογή {#rbac-resources-should-be-created-by-default} Το `rbac.create` θα πρέπει να είναι μια boolean τιμή που ελέγχει αν θα δημιουργηθούν πόροι RBAC. Η προεπιλεγμένη τιμή θα πρέπει να είναι `true`. Οι χρήστες που επιθυμούν να διαχειριστούν οι ίδιοι τους ελέγχους πρόσβασης RBAC μπορούν να ορίσουν αυτή την τιμή σε `false` (δείτε παρακάτω). ## Χρήση Πόρων RBAC {#using-rbac-resources} Το `serviceAccount.name` θα πρέπει να οριστεί στο όνομα του ServiceAccount που θα χρησιμοποιηθεί από τους πόρους με έλεγχο πρόσβασης που δημιουργεί το chart. Αν το `serviceAccount.create` είναι true, τότε θα πρέπει να δημιουργηθεί ένα ServiceAccount με αυτό το όνομα. Αν το όνομα δεν έχει οριστεί, τότε δημιουργείται ένα όνομα χρησιμοποιώντας το template `fullname`. Αν το `serviceAccount.create` είναι false, τότε δεν θα πρέπει να δημιουργηθεί, αλλά θα πρέπει να συσχετίζεται με τους ίδιους πόρους ώστε οι πόροι RBAC που δημιουργούνται χειροκίνητα αργότερα και αναφέρονται σε αυτό να λειτουργούν σωστά. Αν το `serviceAccount.create` είναι false και το όνομα δεν έχει καθοριστεί, τότε χρησιμοποιείται το προεπιλεγμένο ServiceAccount. Χρησιμοποιήστε το παρακάτω βοηθητικό template για το ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Templates description: Μια πιο προσεκτική ματιά στις βέλτιστες πρακτικές που αφορούν τα templates. sidebar_position: 3 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών εστιάζει στα templates. ## Δομή του `templates/` {#structure-of-templates} Ο φάκελος `templates/` θα πρέπει να είναι δομημένος ως εξής: - Τα αρχεία template θα πρέπει να έχουν την επέκταση `.yaml` αν παράγουν έξοδο YAML. Η επέκταση `.tpl` μπορεί να χρησιμοποιηθεί για αρχεία template που δεν παράγουν μορφοποιημένο περιεχόμενο. - Τα ονόματα των αρχείων template θα πρέπει να χρησιμοποιούν παύλες (`my-example-configmap.yaml`), όχι camelcase. - Κάθε ορισμός πόρου θα πρέπει να βρίσκεται στο δικό του αρχείο template. - Τα ονόματα των αρχείων template θα πρέπει να αντικατοπτρίζουν τον τύπο του πόρου, π.χ. `foo-pod.yaml`, `bar-svc.yaml` ## Ονόματα Καθορισμένων Templates {#names-of-defined-templates} Τα καθορισμένα templates (templates που δημιουργούνται μέσα σε μια οδηγία `{{ define }}`) είναι προσβάσιμα από οπουδήποτε. Αυτό σημαίνει ότι ένα chart και όλα τα subcharts του θα έχουν πρόσβαση σε όλα τα templates που δημιουργήθηκαν με `{{ define }}`. Για αυτόν τον λόγο, _όλα τα ονόματα καθορισμένων templates θα πρέπει να έχουν namespace._ Σωστό: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Λάθος: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Συνιστάται ιδιαίτερα να δημιουργούνται νέα charts μέσω της εντολής `helm create`, καθώς τα ονόματα των templates ορίζονται αυτόματα σύμφωνα με αυτή τη βέλτιστη πρακτική. ## Μορφοποίηση Templates {#formatting-templates} Τα templates θα πρέπει να έχουν εσοχή με _δύο κενά_ (ποτέ tabs). Οι οδηγίες template θα πρέπει να έχουν κενό μετά τα αρχικά άγκιστρα και πριν τα τελικά άγκιστρα: Σωστό: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Λάθος: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Τα templates θα πρέπει να περικόπτουν τα κενά όπου είναι δυνατόν: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Τα blocks (όπως οι δομές ελέγχου) μπορούν να έχουν εσοχή για να υποδεικνύουν τη ροή του κώδικα του template. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Ωστόσο, δεδομένου ότι το YAML είναι μια γλώσσα που βασίζεται στα κενά, συχνά δεν είναι δυνατό η εσοχή του κώδικα να ακολουθεί αυτή τη σύμβαση. ## Κενά στα Παραγόμενα Templates {#whitespace-in-generated-templates} Είναι προτιμότερο να κρατάτε τον αριθμό των κενών στα παραγόμενα templates στο ελάχιστο. Ειδικότερα, δεν θα πρέπει να εμφανίζονται πολλές κενές γραμμές διαδοχικά. Αλλά περιστασιακά κενές γραμμές (ιδιαίτερα μεταξύ λογικών ενοτήτων) είναι αποδεκτές. Αυτό είναι το καλύτερο: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Αυτό είναι αποδεκτό: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Αλλά αυτό θα πρέπει να αποφεύγεται: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Σχόλια (Σχόλια YAML έναντι Σχολίων Template) {#comments-yaml-comments-vs-template-comments} Τόσο το YAML όσο και τα Helm Templates έχουν δείκτες σχολίων. Σχόλια YAML: ```yaml # This is a comment {#this-is-a-comment} type: sprocket ``` Σχόλια Template: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` Τα σχόλια template θα πρέπει να χρησιμοποιούνται όταν τεκμηριώνετε χαρακτηριστικά ενός template, όπως για να εξηγήσετε ένα καθορισμένο template: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Μέσα στα templates, τα σχόλια YAML μπορούν να χρησιμοποιηθούν όταν είναι χρήσιμο για τους χρήστες του Helm να (πιθανώς) δουν τα σχόλια κατά την αποσφαλμάτωση. ```yaml # This may cause problems if the value is more than 100Gi {#this-may-cause-problems-if-the-value-is-more-than-100gi} {#this-may-cause-problems-if-the-value-is-more-than-100gi} {#this-may-cause-problems-if-the-value-is-more-than-100gi} {#this-may-cause-problems-if-the-value-is-more-than-100gi} {#this-may-cause-problems-if-the-value-is-more-than-100gi} memory: {{ .Values.maxMem | quote }} ``` Το παραπάνω σχόλιο είναι ορατό όταν ο χρήστης εκτελεί `helm install --debug`, ενώ τα σχόλια που καθορίζονται σε ενότητες `{{- /* */}}` δεν είναι. Να είστε προσεκτικοί όταν προσθέτετε σχόλια YAML με `#` σε ενότητες template που περιέχουν τιμές Helm που μπορεί να απαιτούνται από ορισμένες συναρτήσεις template. Για παράδειγμα, αν η συνάρτηση `required` χρησιμοποιηθεί στο παραπάνω παράδειγμα και το `maxMem` δεν έχει οριστεί, τότε ένα σχόλιο YAML με `#` θα προκαλέσει σφάλμα rendering. Σωστό: το `helm template` δεν κάνει render αυτό το block ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Λάθος: το `helm template` επιστρέφει `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} {#memory-required-valuesmaxmem-maxmem-must-be-set-quote} ``` Δείτε το [Αποσφαλμάτωση Templates](../chart_template_guide/debugging.md) για ένα ακόμη παράδειγμα αυτής της συμπεριφοράς όπου τα σχόλια YAML παραμένουν άθικτα. ## Χρήση JSON σε Templates και Έξοδο Template {#use-of-json-in-templates-and-template-output} Το YAML είναι ένα υπερσύνολο του JSON. Σε ορισμένες περιπτώσεις, η χρήση σύνταξης JSON μπορεί να είναι πιο ευανάγνωστη από άλλες αναπαραστάσεις YAML. Για παράδειγμα, αυτό το YAML είναι πιο κοντά στον κανονικό τρόπο YAML για την έκφραση λιστών: ```yaml arguments: - "--dirname" - "/foo" ``` Αλλά είναι ευκολότερο να διαβαστεί όταν συμπτύσσεται σε στυλ λίστας JSON: ```yaml arguments: ["--dirname", "/foo"] ``` Η χρήση JSON για βελτιωμένη αναγνωσιμότητα είναι καλή. Ωστόσο, η σύνταξη JSON δεν θα πρέπει να χρησιμοποιείται για την αναπαράσταση πιο σύνθετων δομών. Όταν αντιμετωπίζετε καθαρό JSON ενσωματωμένο μέσα σε YAML (όπως διαμόρφωση init container), είναι φυσικά κατάλληλο να χρησιμοποιείτε τη μορφή JSON. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Εστιάζει στον τρόπο με τον οποίο πρέπει να δομείτε και να χρησιμοποιείτε τα values. sidebar_position: 2 --- Αυτό το μέρος του Οδηγού Βέλτιστων Πρακτικών καλύπτει τη χρήση των values. Σε αυτόν τον τομέα του οδηγού, παρέχουμε συστάσεις σχετικά με τον τρόπο που θα πρέπει να δομείτε και να χρησιμοποιείτε τα values, με έμφαση στο σχεδιασμό του αρχείου `values.yaml` ενός chart. ## Συμβάσεις Ονομασίας {#naming-conventions} Τα ονόματα των μεταβλητών θα πρέπει να ξεκινούν με πεζό γράμμα, και οι λέξεις θα πρέπει να διαχωρίζονται με camelcase: Σωστό: ```yaml chicken: true chickenNoodleSoup: true ``` Λάθος: ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` Σημειώστε ότι όλες οι ενσωματωμένες μεταβλητές του Helm ξεκινούν με κεφαλαίο γράμμα για να διακρίνονται εύκολα από τα values που ορίζει ο χρήστης: `.Release.Name`, `.Capabilities.KubeVersion`. ## Επίπεδα ή Ένθετα Values {#flat-or-nested-values} Το YAML είναι μια ευέλικτη μορφή, και τα values μπορούν να είναι βαθιά ένθετα ή επίπεδα. Ένθετα: ```yaml server: name: nginx port: 80 ``` Επίπεδα: ```yaml serverName: nginx serverPort: 80 ``` Στις περισσότερες περιπτώσεις, τα επίπεδα values είναι προτιμότερα από τα ένθετα. Ο λόγος είναι ότι είναι απλούστερα τόσο για τους developers των templates όσο και για τους χρήστες. Για βέλτιστη ασφάλεια, ένα ένθετο value πρέπει να ελέγχεται σε κάθε επίπεδο: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Για κάθε επίπεδο ένθεσης, πρέπει να γίνεται έλεγχος ύπαρξης. Αλλά για επίπεδη διαμόρφωση, τέτοιοι έλεγχοι μπορούν να παραλειφθούν, καθιστώντας το template ευκολότερο στην ανάγνωση και τη χρήση. ``` {{ default "none" .Values.serverName }} ``` Όταν υπάρχει μεγάλος αριθμός σχετικών μεταβλητών, και τουλάχιστον μία από αυτές είναι υποχρεωτική, μπορούν να χρησιμοποιηθούν ένθετα values για βελτίωση της αναγνωσιμότητας. ## Διευκρινίστε τους Τύπους {#make-types-clear} Οι κανόνες μετατροπής τύπων του YAML είναι μερικές φορές απροσδόκητοι. Για παράδειγμα, το `foo: false` δεν είναι το ίδιο με το `foo: "false"`. Μεγάλοι ακέραιοι αριθμοί όπως το `foo: 12345678` μπορεί να μετατραπούν σε επιστημονική σημειογραφία σε ορισμένες περιπτώσεις. Ο ευκολότερος τρόπος να αποφύγετε σφάλματα μετατροπής τύπων είναι να είστε σαφείς με τα strings και να αφήνετε τα υπόλοιπα ως έχουν. Ή, με λίγα λόγια, _βάζετε όλα τα strings σε εισαγωγικά_. Συχνά, για να αποφευχθούν προβλήματα με τη μετατροπή ακεραίων, είναι προτιμότερο να αποθηκεύετε τους ακέραιους ως strings, και να χρησιμοποιείτε το `{{ int $value }}` στο template για μετατροπή από string σε ακέραιο. Στις περισσότερες περιπτώσεις, οι ρητές ετικέτες τύπων αναγνωρίζονται σωστά, οπότε το `foo: !!string 1234` θα αντιμετωπίσει το `1234` ως string. _Ωστόσο_, ο YAML parser καταναλώνει τις ετικέτες, οπότε οι πληροφορίες τύπου χάνονται μετά από μία ανάλυση. ## Σκεφτείτε πώς θα Χρησιμοποιήσουν οι Χρήστες τα Values {#consider-how-users-will-use-your-values} Υπάρχουν τρεις πιθανές πηγές για τα values: - Το αρχείο `values.yaml` του chart - Ένα αρχείο values που παρέχεται με τις εντολές `helm install -f` ή `helm upgrade -f` - Τα values που περνούν μέσω του flag `--set` ή `--set-string` στις εντολές `helm install` ή `helm upgrade` Κατά το σχεδιασμό της δομής των values σας, έχετε υπόψη ότι οι χρήστες του chart μπορεί να θέλουν να τα παρακάμψουν είτε μέσω του flag `-f` είτε με την επιλογή `--set`. Δεδομένου ότι το `--set` έχει περιορισμένη εκφραστικότητα, η πρώτη κατευθυντήρια γραμμή για τη συγγραφή του αρχείου `values.yaml` είναι _να το κάνετε εύκολο να παρακαμφθεί από το `--set`_. Για αυτόν τον λόγο, είναι συχνά καλύτερο να δομείτε το αρχείο values χρησιμοποιώντας maps. Δύσκολο στη χρήση με `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Το παραπάνω δεν μπορεί να εκφραστεί με `--set` στο Helm `<=2.4`. Στο Helm 2.5, η πρόσβαση στο port του foo είναι `--set servers[0].port=80`. Όχι μόνο είναι δυσκολότερο για τον χρήστη να το βρει, αλλά είναι επιρρεπές σε σφάλματα αν αργότερα αλλάξει η σειρά των `servers`. Εύκολο στη χρήση: ```yaml servers: foo: port: 80 bar: port: 81 ``` Η πρόσβαση στο port του foo είναι πολύ πιο προφανής: `--set servers.foo.port=80`. ## Τεκμηρίωση του `values.yaml` {#document-valuesyaml} Κάθε ορισμένη ιδιότητα στο `values.yaml` θα πρέπει να τεκμηριώνεται. Το σχόλιο τεκμηρίωσης θα πρέπει να ξεκινά με το όνομα της ιδιότητας που περιγράφει και στη συνέχεια να δίνει τουλάχιστον μια πρόταση περιγραφής. Λάθος: ```yaml # the host name for the webserver {#the-host-name-for-the-webserver} serverHost: example serverPort: 9191 ``` Σωστό: ```yaml # serverHost is the host name for the webserver {#serverhost-is-the-host-name-for-the-webserver} serverHost: example # serverPort is the HTTP listener port for the webserver {#serverport-is-the-http-listener-port-for-the-webserver} serverPort: 9191 ``` Το να ξεκινάτε κάθε σχόλιο με το όνομα της παραμέτρου που τεκμηριώνει διευκολύνει την εξαγωγή τεκμηρίωσης μέσω grep, και θα επιτρέψει στα εργαλεία τεκμηρίωσης να συσχετίζουν αξιόπιστα τα σχόλια με τις παραμέτρους που περιγράφουν. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Πρόσβαση σε Αρχεία μέσα σε Templates description: Πώς να προσπελάσετε αρχεία μέσα από ένα template. sidebar_position: 10 --- Στην προηγούμενη ενότητα εξετάσαμε διάφορους τρόπους δημιουργίας και πρόσβασης σε ονομασμένα templates. Αυτό διευκολύνει την εισαγωγή ενός template μέσα από ένα άλλο template. Ωστόσο, μερικές φορές είναι επιθυμητό να εισάγετε ένα _αρχείο που δεν είναι template_ και να ενσωματώσετε τα περιεχόμενά του χωρίς να τα περάσετε μέσα από τον template renderer. Το Helm παρέχει πρόσβαση σε αρχεία μέσω του αντικειμένου `.Files`. Πριν προχωρήσουμε με τα παραδείγματα template, υπάρχουν μερικά πράγματα που πρέπει να σημειώσουμε σχετικά με το πώς λειτουργεί αυτό: - Είναι δυνατό να προσθέσετε επιπλέον αρχεία στο Helm chart σας. Αυτά τα αρχεία θα συμπεριληφθούν στο πακέτο. Να είστε όμως προσεκτικοί. Τα charts πρέπει να είναι μικρότερα από 1M λόγω των περιορισμών αποθήκευσης των αντικειμένων Kubernetes. - Ορισμένα αρχεία δεν είναι προσπελάσιμα μέσω του αντικειμένου `.Files`, συνήθως για λόγους ασφαλείας. - Τα αρχεία στο `templates/` δεν είναι προσπελάσιμα. - Τα αρχεία που εξαιρούνται μέσω του `.helmignore` δεν είναι προσπελάσιμα. - Τα αρχεία εκτός του [subchart](./subcharts_and_globals.md) μιας εφαρμογής Helm, συμπεριλαμβανομένων αυτών του γονικού chart, δεν είναι προσπελάσιμα - Τα charts δεν διατηρούν πληροφορίες λειτουργίας UNIX mode, επομένως τα δικαιώματα σε επίπεδο αρχείου δεν επηρεάζουν τη διαθεσιμότητα ενός αρχείου όσον αφορά το αντικείμενο `.Files`. - [Βασικό παράδειγμα](#basic-example) - [Βοηθητικές συναρτήσεις διαδρομής](#path-helpers) - [Μοτίβα glob](#glob-patterns) - [Βοηθητικές συναρτήσεις ConfigMap και Secrets](#configmap-and-secrets-utility-functions) - [Κωδικοποίηση](#encoding) - [Γραμμές](#lines) ## Βασικό παράδειγμα {#basic-example} Με αυτά υπόψη, ας γράψουμε ένα template που διαβάζει τρία αρχεία στο ConfigMap μας. Για να ξεκινήσουμε, θα προσθέσουμε τρία αρχεία στο chart, τοποθετώντας και τα τρία απευθείας μέσα στον κατάλογο `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Καθένα από αυτά είναι ένα απλό αρχείο TOML (σκεφτείτε τα παλιά αρχεία Windows INI). Γνωρίζουμε τα ονόματα αυτών των αρχείων, οπότε μπορούμε να χρησιμοποιήσουμε μια συνάρτηση `range` για να επαναλάβουμε σε αυτά και να εισάγουμε τα περιεχόμενά τους στο ConfigMap μας. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Αυτό το ConfigMap χρησιμοποιεί αρκετές από τις τεχνικές που συζητήθηκαν σε προηγούμενες ενότητες. Για παράδειγμα, δημιουργούμε μια μεταβλητή `$files` για να κρατήσουμε μια αναφορά στο αντικείμενο `.Files`. Χρησιμοποιούμε επίσης τη συνάρτηση `tuple` για να δημιουργήσουμε μια λίστα αρχείων που επαναλαμβάνουμε. Στη συνέχεια εκτυπώνουμε κάθε όνομα αρχείου (`{{ . }}: |-`) ακολουθούμενο από τα περιεχόμενα του αρχείου `{{ $files.Get . }}`. Η εκτέλεση αυτού του template θα παράγει ένα μόνο ConfigMap με τα περιεχόμενα και των τριών αρχείων: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Βοηθητικές συναρτήσεις διαδρομής {#path-helpers} Όταν εργάζεστε με αρχεία, μπορεί να είναι πολύ χρήσιμο να εκτελείτε ορισμένες τυπικές λειτουργίες στις ίδιες τις διαδρομές των αρχείων. Για να βοηθήσει σε αυτό, το Helm εισάγει πολλές από τις συναρτήσεις του πακέτου [path](https://golang.org/pkg/path/) της Go για χρήση. Είναι όλες προσβάσιμες με τα ίδια ονόματα όπως στο πακέτο της Go, αλλά με πεζό πρώτο γράμμα. Για παράδειγμα, η `Base` γίνεται `base`, κ.λπ. Οι εισαγόμενες συναρτήσεις είναι: - Base - Dir - Ext - IsAbs - Clean ## Μοτίβα glob {#glob-patterns} Καθώς το chart σας μεγαλώνει, μπορεί να διαπιστώσετε ότι χρειάζεστε καλύτερη οργάνωση των αρχείων σας, και γι' αυτό παρέχουμε μια μέθοδο `Files.Glob(pattern string)` για να βοηθήσουμε στην εξαγωγή συγκεκριμένων αρχείων με όλη την ευελιξία των [μοτίβων glob](https://godoc.org/github.com/gobwas/glob). Η `.Glob` επιστρέφει έναν τύπο `Files`, οπότε μπορείτε να καλέσετε οποιαδήποτε από τις μεθόδους `Files` στο επιστρεφόμενο αντικείμενο. Για παράδειγμα, φανταστείτε τη δομή καταλόγου: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Έχετε πολλές επιλογές με τα Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Ή ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Βοηθητικές συναρτήσεις ConfigMap και Secrets {#configmap-and-secrets-utility-functions} (Διαθέσιμο από Helm 2.0.2 και μετά) Είναι πολύ συνηθισμένο να θέλετε να τοποθετήσετε περιεχόμενα αρχείων τόσο σε ConfigMaps όσο και σε Secrets, για προσάρτηση στα pods σας κατά το χρόνο εκτέλεσης. Για να βοηθήσουμε σε αυτό, παρέχουμε μερικές βοηθητικές μεθόδους στον τύπο `Files`. Για καλύτερη οργάνωση, είναι ιδιαίτερα χρήσιμο να χρησιμοποιείτε αυτές τις μεθόδους σε συνδυασμό με τη μέθοδο `Glob`. Δεδομένης της δομής καταλόγου από το παράδειγμα [Glob](#glob-patterns) παραπάνω: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Κωδικοποίηση {#encoding} Μπορείτε να εισάγετε ένα αρχείο και να το κωδικοποιήσετε σε base-64 από το template για να εξασφαλίσετε τη σωστή μεταφορά: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Το παραπάνω θα πάρει το ίδιο αρχείο `config1.toml` που χρησιμοποιήσαμε πριν και θα το κωδικοποιήσει: ```yaml # Source: mychart/templates/secret.yaml {#source-mycharttemplatessecretyaml} apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Γραμμές {#lines} Μερικές φορές είναι επιθυμητό να προσπελάσετε κάθε γραμμή ενός αρχείου στο template σας. Παρέχουμε μια βολική μέθοδο `Lines` για αυτό. Μπορείτε να επαναλάβετε μέσω του `Lines` χρησιμοποιώντας μια συνάρτηση `range`: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Δεν υπάρχει τρόπος να περάσετε αρχεία εξωτερικά του chart κατά τη διάρκεια του `helm install`. Επομένως, αν ζητάτε από τους χρήστες να παρέχουν δεδομένα, πρέπει να φορτωθούν χρησιμοποιώντας `helm install -f` ή `helm install --set`. Αυτή η συζήτηση ολοκληρώνει την εμβάθυνσή μας στα εργαλεία και τις τεχνικές για τη συγγραφή Helm templates. Στην επόμενη ενότητα θα δούμε πώς μπορείτε να χρησιμοποιήσετε ένα ειδικό αρχείο, το `templates/NOTES.txt`, για να στείλετε οδηγίες μετά την εγκατάσταση στους χρήστες του chart σας. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Ενσωματωμένα Αντικείμενα description: Τα ενσωματωμένα αντικείμενα που είναι διαθέσιμα στα templates. sidebar_position: 3 --- Τα αντικείμενα μεταβιβάζονται σε ένα template από τη μηχανή template. Ο κώδικάς σας μπορεί να μεταβιβάζει αντικείμενα (θα δούμε παραδείγματα όταν εξετάσουμε τις δηλώσεις `with` και `range`). Υπάρχουν ακόμη και μερικοί τρόποι για να δημιουργήσετε νέα αντικείμενα μέσα στα templates σας, όπως με τη συνάρτηση `tuple` που θα δούμε αργότερα. Τα αντικείμενα μπορεί να είναι απλά, με μία μόνο τιμή. Ή μπορεί να περιέχουν άλλα αντικείμενα ή συναρτήσεις. Για παράδειγμα, το αντικείμενο `Release` περιέχει πολλά αντικείμενα (όπως το `Release.Name`) και το αντικείμενο `Files` έχει μερικές συναρτήσεις. Στην προηγούμενη ενότητα, χρησιμοποιήσαμε το `{{ .Release.Name }}` για να εισάγουμε το όνομα ενός release σε ένα template. Το `Release` είναι ένα από τα αντικείμενα ανώτατου επιπέδου στα οποία μπορείτε να έχετε πρόσβαση στα templates σας. - `Release`: Αυτό το αντικείμενο περιγράφει το ίδιο το release. Περιέχει πολλά αντικείμενα: - `Release.Name`: Το όνομα του release - `Release.Namespace`: Το namespace στο οποίο θα γίνει η εγκατάσταση (αν το manifest δεν το παρακάμπτει) - `Release.IsUpgrade`: Ορίζεται σε `true` αν η τρέχουσα λειτουργία είναι upgrade ή rollback. - `Release.IsInstall`: Ορίζεται σε `true` αν η τρέχουσα λειτουργία είναι εγκατάσταση. - `Release.Revision`: Ο αριθμός αναθεώρησης για αυτό το release. Κατά την εγκατάσταση είναι 1 και αυξάνεται με κάθε upgrade και rollback. - `Release.Service`: Η υπηρεσία που αποδίδει το τρέχον template. Στο Helm, αυτό είναι πάντα `Helm`. - `Values`: Οι τιμές που μεταβιβάζονται στο template από το αρχείο `values.yaml` και από αρχεία που παρέχει ο χρήστης. Από προεπιλογή, το `Values` είναι κενό. - `Chart`: Τα περιεχόμενα του αρχείου `Chart.yaml`. Οποιαδήποτε δεδομένα στο `Chart.yaml` είναι προσβάσιμα εδώ. Για παράδειγμα, το `{{ .Chart.Name }}-{{ .Chart.Version }}` θα εκτυπώσει `mychart-0.1.0`. - Τα διαθέσιμα πεδία παρατίθενται στον [Οδηγό Charts](/topics/charts.md#the-chartyaml-file) - `Subcharts`: Παρέχει πρόσβαση στο εύρος (.Values, .Charts, .Releases κλπ.) των subcharts από το γονικό chart. Για παράδειγμα, το `.Subcharts.mySubChart.myValue` για πρόσβαση στο `myValue` του chart `mySubChart`. - `Files`: Παρέχει πρόσβαση σε όλα τα μη ειδικά αρχεία σε ένα chart. Δεν μπορείτε να το χρησιμοποιήσετε για πρόσβαση σε templates, αλλά μπορείτε να το χρησιμοποιήσετε για πρόσβαση σε άλλα αρχεία του chart. Δείτε την ενότητα [Πρόσβαση σε Αρχεία](/chart_template_guide/accessing_files.md) για περισσότερα. - `Files.Get` είναι μια συνάρτηση για λήψη ενός αρχείου με βάση το όνομά του (`.Files.Get config.ini`) - `Files.GetBytes` είναι μια συνάρτηση για λήψη των περιεχομένων ενός αρχείου ως πίνακα bytes αντί για string. Αυτό είναι χρήσιμο για πράγματα όπως εικόνες. - `Files.Glob` είναι μια συνάρτηση που επιστρέφει μια λίστα αρχείων των οποίων τα ονόματα ταιριάζουν με το δοσμένο μοτίβο shell glob. - `Files.Lines` είναι μια συνάρτηση που διαβάζει ένα αρχείο γραμμή προς γραμμή. Αυτό είναι χρήσιμο για επανάληψη σε κάθε γραμμή ενός αρχείου. - `Files.AsSecrets` είναι μια συνάρτηση που επιστρέφει τα περιεχόμενα των αρχείων ως strings κωδικοποιημένα σε Base 64. - `Files.AsConfig` είναι μια συνάρτηση που επιστρέφει τα περιεχόμενα των αρχείων ως YAML map. - `Capabilities`: Παρέχει πληροφορίες σχετικά με τις δυνατότητες που υποστηρίζει το Kubernetes cluster. - `Capabilities.APIVersions` είναι ένα σύνολο εκδόσεων. - `Capabilities.APIVersions.Has $version` υποδεικνύει αν μια έκδοση (π.χ. `batch/v1`) ή ένας πόρος (π.χ. `apps/v1/Deployment`) είναι διαθέσιμος στο cluster. - `Capabilities.KubeVersion` και `Capabilities.KubeVersion.Version` είναι η έκδοση του Kubernetes. - `Capabilities.KubeVersion.Major` είναι η κύρια έκδοση του Kubernetes. - `Capabilities.KubeVersion.Minor` είναι η δευτερεύουσα έκδοση του Kubernetes. - `Capabilities.HelmVersion` είναι το αντικείμενο που περιέχει τις λεπτομέρειες της έκδοσης Helm, ίδια έξοδος με την εντολή `helm version`. - `Capabilities.HelmVersion.Version` είναι η τρέχουσα έκδοση Helm σε μορφή semver. - `Capabilities.HelmVersion.GitCommit` είναι το Helm git sha1. - `Capabilities.HelmVersion.GitTreeState` είναι η κατάσταση του git tree του Helm. - `Capabilities.HelmVersion.GoVersion` είναι η έκδοση του μεταγλωττιστή Go που χρησιμοποιήθηκε. - `Template`: Περιέχει πληροφορίες σχετικά με το τρέχον template που εκτελείται - `Template.Name`: Η διαδρομή αρχείου με namespace προς το τρέχον template (π.χ. `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: Η διαδρομή με namespace προς τον κατάλογο templates του τρέχοντος chart (π.χ. `mychart/templates`). Τα ενσωματωμένα αντικείμενα ξεκινούν πάντα με κεφαλαίο γράμμα. Αυτό ακολουθεί τη σύμβαση ονομασίας της Go. Όταν δημιουργείτε τα δικά σας ονόματα, είστε ελεύθεροι να χρησιμοποιήσετε μια σύμβαση που ταιριάζει στην ομάδα σας. Ορισμένες ομάδες, όπως πολλές από αυτές των οποίων τα charts μπορείτε να δείτε στο [Artifact Hub](https://artifacthub.io/packages/search?kind=0), επιλέγουν να χρησιμοποιούν μόνο αρχικά πεζά γράμματα για να διακρίνουν τα τοπικά ονόματα από τα ενσωματωμένα. Σε αυτόν τον οδηγό, ακολουθούμε αυτή τη σύμβαση. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Έλεγχος Ροής description: Μια γρήγορη επισκόπηση της δομής ροής στα templates. sidebar_position: 7 --- Οι δομές ελέγχου (που ονομάζονται «actions» στην ορολογία των templates) σας δίνουν τη δυνατότητα να ελέγχετε τη ροή παραγωγής ενός template. Η γλώσσα template του Helm παρέχει τις ακόλουθες δομές ελέγχου: - `if`/`else` για τη δημιουργία blocks υπό συνθήκη - `with` για τον καθορισμό εύρους (scope) - `range`, που παρέχει έναν βρόχο τύπου «for each» Επιπλέον, παρέχει μερικές ενέργειες για τη δήλωση και χρήση ονομασμένων τμημάτων template: - `define` δηλώνει ένα νέο ονομασμένο template μέσα στο template σας - `template` εισάγει ένα ονομασμένο template - `block` δηλώνει έναν ειδικό τύπο περιοχής template που μπορεί να συμπληρωθεί Σε αυτήν την ενότητα, θα μιλήσουμε για τα `if`, `with` και `range`. Τα υπόλοιπα καλύπτονται στην ενότητα «Ονομασμένα Templates» αργότερα σε αυτόν τον οδηγό. ## If/Else {#ifelse} Η πρώτη δομή ελέγχου που θα εξετάσουμε είναι για τη συμπερίληψη blocks κειμένου υπό συνθήκη σε ένα template. Πρόκειται για το block `if`/`else`. Η βασική δομή για μια συνθήκη έχει την εξής μορφή: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Παρατηρήστε ότι τώρα μιλάμε για _pipelines_ αντί για τιμές. Ο λόγος είναι να γίνει σαφές ότι οι δομές ελέγχου μπορούν να εκτελέσουν ένα ολόκληρο pipeline, όχι απλά να αξιολογήσουν μια τιμή. Ένα pipeline αξιολογείται ως _false_ αν η τιμή είναι: - boolean false - αριθμητικό μηδέν - κενό string - `nil` (κενό ή null) - κενή συλλογή (`map`, `slice`, `tuple`, `dict`, `array`) Σε όλες τις άλλες περιπτώσεις, η συνθήκη είναι true. Ας προσθέσουμε μια απλή συνθήκη στο ConfigMap μας. Θα προσθέσουμε μια ακόμη ρύθμιση αν το drink έχει οριστεί σε coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Επειδή σχολιάσαμε το `drink: coffee` στο προηγούμενο παράδειγμά μας, η έξοδος δεν θα πρέπει να περιλαμβάνει τη σημαία `mug: "true"`. Αλλά αν προσθέσουμε ξανά αυτή τη γραμμή στο αρχείο `values.yaml`, η έξοδος θα πρέπει να μοιάζει με αυτό: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Έλεγχος Κενών Χαρακτήρων {#controlling-whitespace} Ενώ εξετάζουμε τις συνθήκες, ας δούμε γρήγορα πώς ελέγχονται οι κενοί χαρακτήρες (whitespace) στα templates. Ας πάρουμε το προηγούμενο παράδειγμα και ας το μορφοποιήσουμε για να είναι πιο ευανάγνωστο: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Αρχικά, αυτό φαίνεται καλό. Αλλά αν το περάσουμε από τη μηχανή template, θα πάρουμε ένα ατυχές αποτέλεσμα: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Τι συνέβη; Δημιουργήσαμε λανθασμένο YAML λόγω των κενών χαρακτήρων παραπάνω. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Το `mug` έχει λανθασμένη εσοχή. Ας αφαιρέσουμε απλά την εσοχή από αυτή τη γραμμή και ας ξανατρέξουμε: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Όταν το στείλουμε, θα πάρουμε YAML που είναι έγκυρο, αλλά εξακολουθεί να φαίνεται λίγο περίεργο: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Παρατηρήστε ότι πήραμε μερικές κενές γραμμές στο YAML μας. Γιατί; Όταν η μηχανή template εκτελείται, _αφαιρεί_ τα περιεχόμενα μέσα από τα `{{` και `}}`, αλλά αφήνει τους υπόλοιπους κενούς χαρακτήρες ακριβώς όπως είναι. Το YAML αποδίδει νόημα στους κενούς χαρακτήρες, οπότε η διαχείρισή τους γίνεται αρκετά σημαντική. Ευτυχώς, τα Helm templates έχουν μερικά εργαλεία για να βοηθήσουν. Πρώτον, η σύνταξη με άγκιστρα των δηλώσεων template μπορεί να τροποποιηθεί με ειδικούς χαρακτήρες για να ενημερώσει τη μηχανή template να «κόψει» (chomp) τους κενούς χαρακτήρες. Το `{{- ` (με παύλα και κενό) υποδεικνύει ότι οι κενοί χαρακτήρες αριστερά πρέπει να αφαιρεθούν, ενώ το ` -}}` σημαίνει ότι οι κενοί χαρακτήρες δεξιά πρέπει να καταναλωθούν. _Προσοχή! Οι αλλαγές γραμμής (newlines) είναι κενοί χαρακτήρες!_ > Βεβαιωθείτε ότι υπάρχει ένα κενό ανάμεσα στην `-` και το υπόλοιπο της > οδηγίας σας. Το `{{- 3 }}` σημαίνει «κόψε τους κενούς χαρακτήρες αριστερά > και τύπωσε 3», ενώ το `{{-3 }}` σημαίνει «τύπωσε -3». Χρησιμοποιώντας αυτή τη σύνταξη, μπορούμε να τροποποιήσουμε το template μας για να απαλλαγούμε από αυτές τις νέες γραμμές: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Για να γίνει αυτό το σημείο ξεκάθαρο, ας προσαρμόσουμε τα παραπάνω και ας αντικαταστήσουμε με ένα `*` κάθε κενό χαρακτήρα που θα διαγραφεί ακολουθώντας αυτόν τον κανόνα. Ένα `*` στο τέλος της γραμμής υποδεικνύει έναν χαρακτήρα αλλαγής γραμμής που θα αφαιρεθεί ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Έχοντας αυτό υπόψη, μπορούμε να περάσουμε το template μας μέσω του Helm και να δούμε το αποτέλεσμα: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Να είστε προσεκτικοί με τους τροποποιητές κοπής (chomping modifiers). Είναι εύκολο να κάνετε κατά λάθος πράγματα όπως αυτό: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Αυτό θα παράγει `food: "PIZZA"mug: "true"` επειδή κατανάλωσε τις αλλαγές γραμμής και στις δύο πλευρές. > Για λεπτομέρειες σχετικά με τον έλεγχο κενών χαρακτήρων στα templates, δείτε > την [Επίσημη τεκμηρίωση των Go templates](https://godoc.org/text/template) Τέλος, μερικές φορές είναι ευκολότερο να πείτε στο σύστημα template πώς να κάνει εσοχή για εσάς αντί να προσπαθείτε να κατακτήσετε τη διαστημάτωση των οδηγιών template. Για αυτόν τον λόγο, μπορεί να βρείτε χρήσιμο να χρησιμοποιήσετε τη συνάρτηση `indent` (`{{ indent 2 "mug:true" }}`). ## Τροποποίηση εύρους με το `with` {#modifying-scope-using-with} Η επόμενη δομή ελέγχου που θα εξετάσουμε είναι η ενέργεια `with`. Αυτή ελέγχει το εύρος (scoping) των μεταβλητών. Θυμηθείτε ότι η `.` είναι μια αναφορά στο _τρέχον εύρος_. Έτσι, το `.Values` λέει στο template να βρει το αντικείμενο `Values` στο τρέχον εύρος. Η σύνταξη για το `with` είναι παρόμοια με μια απλή δήλωση `if`: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Τα εύρη μπορούν να αλλάξουν. Το `with` μπορεί να σας επιτρέψει να ορίσετε το τρέχον εύρος (`.`) σε ένα συγκεκριμένο αντικείμενο. Για παράδειγμα, έχουμε δουλέψει με το `.Values.favorite`. Ας ξαναγράψουμε το ConfigMap μας για να αλλάξουμε το εύρος της `.` ώστε να δείχνει στο `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Σημειώστε ότι αφαιρέσαμε τη συνθήκη `if` από την προηγούμενη άσκηση επειδή δεν είναι πλέον απαραίτητη - το block μετά το `with` εκτελείται μόνο αν η τιμή του `PIPELINE` δεν είναι κενή. Παρατηρήστε ότι τώρα μπορούμε να αναφερθούμε στα `.drink` και `.food` χωρίς να τα προσδιορίσουμε πλήρως. Αυτό συμβαίνει επειδή η δήλωση `with` ορίζει τη `.` να δείχνει στο `.Values.favorite`. Η `.` επαναφέρεται στο προηγούμενο εύρος της μετά το `{{ end }}`. Αλλά εδώ υπάρχει μια προειδοποίηση! Μέσα στο περιορισμένο εύρος, δεν θα μπορείτε να έχετε πρόσβαση στα άλλα αντικείμενα από το γονικό εύρος χρησιμοποιώντας τη `.`. Αυτό, για παράδειγμα, θα αποτύχει: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Θα παράγει σφάλμα επειδή το `Release.Name` δεν βρίσκεται μέσα στο περιορισμένο εύρος της `.`. Ωστόσο, αν εναλλάξουμε τις δύο τελευταίες γραμμές, όλα θα λειτουργήσουν όπως αναμένεται επειδή το εύρος επαναφέρεται μετά το `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Ή, μπορούμε να χρησιμοποιήσουμε το `$` για πρόσβαση στο αντικείμενο `Release.Name` από το γονικό εύρος. Το `$` αντιστοιχίζεται στο αρχικό (root) εύρος όταν ξεκινά η εκτέλεση του template και δεν αλλάζει κατά την εκτέλεση. Το παρακάτω θα λειτουργούσε επίσης: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Αφού δούμε το `range`, θα ρίξουμε μια ματιά στις μεταβλητές template, που προσφέρουν μια λύση στο πρόβλημα εύρους παραπάνω. ## Βρόχοι με την ενέργεια `range` {#looping-with-the-range-action} Πολλές γλώσσες προγραμματισμού υποστηρίζουν βρόχους με `for` loops, `foreach` loops ή παρόμοιους μηχανισμούς. Στη γλώσσα template του Helm, ο τρόπος για να επαναλάβετε μια συλλογή είναι να χρησιμοποιήσετε τον τελεστή `range`. Για να ξεκινήσουμε, ας προσθέσουμε μια λίστα με υλικά πίτσας στο αρχείο `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Τώρα έχουμε μια λίστα (που ονομάζεται `slice` στα templates) με `pizzaToppings`. Μπορούμε να τροποποιήσουμε το template μας για να εκτυπώσει αυτή τη λίστα στο ConfigMap μας: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Μπορούμε να χρησιμοποιήσουμε το `$` για πρόσβαση στη λίστα `Values.pizzaToppings` από το γονικό εύρος. Το `$` αντιστοιχίζεται στο αρχικό (root) εύρος όταν ξεκινά η εκτέλεση του template και δεν αλλάζει κατά την εκτέλεση. Το παρακάτω θα λειτουργούσε επίσης: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Ας δούμε πιο προσεκτικά τη λίστα `toppings:`. Η συνάρτηση `range` θα «διατρέξει» (επαναλάβει) τη λίστα `pizzaToppings`. Αλλά τώρα συμβαίνει κάτι ενδιαφέρον. Όπως ακριβώς το `with` ορίζει το εύρος της `.`, έτσι και ο τελεστής `range`. Κάθε φορά που περνάμε τον βρόχο, η `.` ορίζεται στο τρέχον υλικό πίτσας. Δηλαδή, την πρώτη φορά, η `.` ορίζεται σε `mushrooms`. Στη δεύτερη επανάληψη ορίζεται σε `cheese`, και ούτω καθεξής. Μπορούμε να στείλουμε την τιμή της `.` απευθείας σε ένα pipeline, οπότε όταν κάνουμε `{{ . | title | quote }}`, στέλνει τη `.` στην `title` (συνάρτηση κεφαλαιοποίησης τίτλου) και στη συνέχεια στην `quote`. Αν εκτελέσουμε αυτό το template, η έξοδος θα είναι: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Σε αυτό το παράδειγμα κάναμε κάτι δύσκολο. Η γραμμή `toppings: |-` δηλώνει ένα string πολλαπλών γραμμών. Επομένως, η λίστα υλικών μας δεν είναι στην πραγματικότητα μια λίστα YAML. Είναι ένα μεγάλο string. Γιατί να το κάνουμε αυτό; Επειδή τα δεδομένα στο `data` των ConfigMaps αποτελούνται από ζεύγη κλειδιού/τιμής, όπου τόσο το κλειδί όσο και η τιμή είναι απλά strings. Για να καταλάβετε γιατί συμβαίνει αυτό, δείτε την [τεκμηρίωση Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Για εμάς, όμως, αυτή η λεπτομέρεια δεν έχει μεγάλη σημασία. > Ο δείκτης `|-` στο YAML λαμβάνει ένα string πολλαπλών γραμμών. Αυτό μπορεί > να είναι μια χρήσιμη τεχνική για την ενσωμάτωση μεγάλων blocks δεδομένων > μέσα στα manifests σας, όπως φαίνεται εδώ. Μερικές φορές είναι χρήσιμο να μπορείτε να δημιουργήσετε γρήγορα μια λίστα μέσα στο template σας, και στη συνέχεια να επαναλάβετε αυτή τη λίστα. Τα Helm templates έχουν μια συνάρτηση για να το κάνουν εύκολο: την `tuple`. Στην επιστήμη των υπολογιστών, μια tuple είναι μια συλλογή τύπου λίστας με σταθερό μέγεθος, αλλά με αυθαίρετους τύπους δεδομένων. Αυτό αποδίδει κατά προσέγγιση τον τρόπο χρήσης της `tuple`. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Το παραπάνω θα παράγει: ```yaml sizes: |- - small - medium - large ``` Εκτός από λίστες και tuples, το `range` μπορεί να χρησιμοποιηθεί για επανάληψη πάνω σε συλλογές που έχουν κλειδί και τιμή (όπως ένα `map` ή `dict`). Θα δούμε πώς να το κάνουμε αυτό στην επόμενη ενότητα όταν εισαγάγουμε τις μεταβλητές template. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Παράρτημα: Τύποι Δεδομένων της Go και Templates" description: Μια σύντομη επισκόπηση των μεταβλητών στα templates. sidebar_position: 16 --- Η γλώσσα template του Helm υλοποιείται στην αυστηρά τυποποιημένη γλώσσα προγραμματισμού Go. Για αυτόν τον λόγο, οι μεταβλητές στα templates είναι _τυποποιημένες_. Συνήθως, οι μεταβλητές θα εκτίθενται ως ένας από τους παρακάτω τύπους: - string: Συμβολοσειρά κειμένου - bool: Τιμή `true` ή `false` - int: Ακέραια τιμή (υπάρχουν επίσης παραλλαγές 8, 16, 32 και 64 bit, προσημασμένες και μη) - float64: Τιμή κινητής υποδιαστολής 64 bit (υπάρχουν επίσης παραλλαγές 8, 16 και 32 bit) - byte slice (`[]byte`): Χρησιμοποιείται συχνά για (ενδεχομένως) δυαδικά δεδομένα - struct: Αντικείμενο με ιδιότητες και μεθόδους - slice (ευρετηριασμένη λίστα) ενός από τους προηγούμενους τύπους - map με κλειδιά τύπου string (`map[string]interface{}`) όπου η τιμή είναι ένας από τους προηγούμενους τύπους Υπάρχουν πολλοί άλλοι τύποι στη Go, και μερικές φορές θα χρειαστεί να τους μετατρέπετε στα templates σας. Ο ευκολότερος τρόπος για να κάνετε debug τον τύπο ενός αντικειμένου είναι να το περάσετε μέσω του `printf "%T"` σε ένα template, το οποίο θα εκτυπώσει τον τύπο. Δείτε επίσης τις συναρτήσεις `typeOf` και `kindOf`. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Αποσφαλμάτωση Templates description: Αντιμετώπιση προβλημάτων σε charts που αποτυγχάνουν να εγκατασταθούν. sidebar_position: 13 --- Η αποσφαλμάτωση των templates μπορεί να αποδειχθεί δύσκολη, καθώς τα αποδομημένα templates αποστέλλονται στον Kubernetes API server, ο οποίος μπορεί να απορρίψει τα αρχεία YAML για λόγους που δεν σχετίζονται με τη μορφοποίηση. Υπάρχουν μερικές εντολές που μπορούν να σας βοηθήσουν στην αποσφαλμάτωση. - Η `helm lint` είναι το κύριο εργαλείο σας για να επαληθεύσετε ότι το chart σας ακολουθεί βέλτιστες πρακτικές - Η `helm template --debug` θα δοκιμάσει την απόδοση των chart templates τοπικά. - Η `helm install --dry-run --debug` θα αποδώσει επίσης το chart σας τοπικά χωρίς να το εγκαταστήσει, αλλά θα ελέγξει επίσης αν υπάρχουν συγκρουόμενοι πόροι ήδη εκτελούμενοι στο cluster. Με τη ρύθμιση `--dry-run=server` θα εκτελεστεί επιπλέον οποιοδήποτε `lookup` στο chart σας προς τον server. - `helm get manifest`: Αυτός είναι ένας καλός τρόπος για να δείτε ποια templates είναι εγκατεστημένα στον server. Όταν το YAML σας αποτυγχάνει να αναλυθεί (parse), αλλά θέλετε να δείτε τι παράγεται, ένας εύκολος τρόπος να ανακτήσετε το YAML είναι να σχολιάσετε την προβληματική ενότητα στο template και στη συνέχεια να εκτελέσετε ξανά την `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section {#some-problem-section} {#some-problem-section} {#some-problem-section} # {{ .Values.foo | quote }} {#valuesfoo-quote} ``` Το παραπάνω θα αποδοθεί και θα επιστραφεί με τα σχόλια ανέπαφα: ```yaml apiVersion: v2 # some: problem section # "bar" {#bar} ``` Αυτό παρέχει έναν γρήγορο τρόπο προβολής του παραγόμενου περιεχομένου, χωρίς τα σφάλματα ανάλυσης YAML να εμποδίζουν τη διαδικασία. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Συναρτήσεις Template και Pipelines description: Χρήση συναρτήσεων στα templates. sidebar_position: 5 --- Μέχρι τώρα, έχουμε δει πώς να τοποθετούμε πληροφορίες σε ένα template. Αλλά αυτές οι πληροφορίες τοποθετούνται στο template χωρίς τροποποίηση. Μερικές φορές θέλουμε να μετασχηματίσουμε τα παρεχόμενα δεδομένα με τρόπο που να μας είναι πιο χρήσιμα. Ας ξεκινήσουμε με μια καλή πρακτική: Όταν εισάγουμε strings από το αντικείμενο `.Values` στο template, θα πρέπει να τα περικλείουμε σε εισαγωγικά. Μπορούμε να το κάνουμε αυτό καλώντας τη συνάρτηση `quote` στην οδηγία του template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Οι συναρτήσεις template ακολουθούν τη σύνταξη `functionName arg1 arg2...`. Στο παραπάνω απόσπασμα, η `quote .Values.favorite.drink` καλεί τη συνάρτηση `quote` και της περνάει ένα μόνο όρισμα. Το Helm διαθέτει περισσότερες από 60 συναρτήσεις. Μερικές από αυτές ορίζονται από την ίδια τη [γλώσσα template της Go](https://godoc.org/text/template). Οι περισσότερες από τις υπόλοιπες είναι μέρος της [βιβλιοθήκης Sprig template](https://masterminds.github.io/sprig/). Θα δούμε πολλές από αυτές καθώς προχωράμε στα παραδείγματα. > Ενώ μιλάμε για τη «γλώσσα template του Helm» σαν να είναι συγκεκριμένη για το > Helm, στην πραγματικότητα είναι ένας συνδυασμός της γλώσσας template της Go, > μερικών επιπλέον συναρτήσεων και διάφορων wrappers για την έκθεση > συγκεκριμένων αντικειμένων στα templates. Πολλοί πόροι για τα Go templates > μπορεί να είναι χρήσιμοι καθώς μαθαίνετε για τη δημιουργία templates. ## Pipelines {#pipelines} Ένα από τα ισχυρά χαρακτηριστικά της γλώσσας template είναι η έννοια των _pipelines_. Βασιζόμενοι σε μια ιδέα από το UNIX, τα pipelines είναι ένα εργαλείο για την αλυσίδωση μιας σειράς εντολών template ώστε να εκφράσουμε συνοπτικά μια σειρά μετασχηματισμών. Με άλλα λόγια, τα pipelines είναι ένας αποδοτικός τρόπος για να κάνουμε πολλά πράγματα διαδοχικά. Ας ξαναγράψουμε το παραπάνω παράδειγμα χρησιμοποιώντας ένα pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` Σε αυτό το παράδειγμα, αντί να καλέσουμε `quote ARGUMENT`, αντιστρέψαμε τη σειρά. «Στείλαμε» το όρισμα στη συνάρτηση χρησιμοποιώντας ένα pipeline (`|`): `.Values.favorite.drink | quote`. Χρησιμοποιώντας pipelines, μπορούμε να αλυσιδώσουμε πολλές συναρτήσεις μαζί: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Η αντιστροφή της σειράς είναι μια συνήθης πρακτική στα templates. Θα δείτε > πιο συχνά `.val | quote` παρά `quote .val`. Και οι δύο τρόποι είναι αποδεκτοί. Όταν αξιολογηθεί, αυτό το template θα παράγει: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Παρατηρήστε ότι το αρχικό μας `pizza` έχει μετατραπεί τώρα σε `"PIZZA"`. Όταν περνάμε ορίσματα με pipeline, το αποτέλεσμα της πρώτης αξιολόγησης (`.Values.favorite.drink`) στέλνεται ως _τελευταίο όρισμα στη συνάρτηση_. Μπορούμε να τροποποιήσουμε το παράδειγμα με το ποτό παραπάνω για να δείξουμε μια συνάρτηση που δέχεται δύο ορίσματα: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` Η συνάρτηση `repeat` θα επαναλάβει το δοσμένο string τον καθορισμένο αριθμό φορών, οπότε θα λάβουμε αυτό ως έξοδο: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Χρήση της συνάρτησης `default` {#using-the-default-function} Μια συνάρτηση που χρησιμοποιείται συχνά στα templates είναι η `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Αυτή η συνάρτηση σας επιτρέπει να ορίσετε μια προεπιλεγμένη τιμή μέσα στο template, σε περίπτωση που η τιμή παραλείπεται. Ας τη χρησιμοποιήσουμε για να τροποποιήσουμε το παράδειγμα με το ποτό παραπάνω: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Αν το εκτελέσουμε κανονικά, θα πάρουμε τον `coffee` μας: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Τώρα, θα αφαιρέσουμε τη ρύθμιση για το αγαπημένο ποτό από το `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Τώρα η εκ νέου εκτέλεση της `helm install --dry-run --debug fair-worm ./mychart` θα παράγει αυτό το YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` Σε ένα πραγματικό chart, όλες οι στατικές προεπιλεγμένες τιμές πρέπει να βρίσκονται στο `values.yaml` και δεν πρέπει να επαναλαμβάνονται με την εντολή `default` (διαφορετικά θα ήταν περιττές). Ωστόσο, η εντολή `default` είναι ιδανική για υπολογιζόμενες τιμές, οι οποίες δεν μπορούν να δηλωθούν μέσα στο `values.yaml`. Για παράδειγμα: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` Σε κάποια σημεία, μια συνθήκη `if` μπορεί να είναι πιο κατάλληλη από τη `default`. Θα δούμε αυτές στην επόμενη ενότητα. Οι συναρτήσεις και τα pipelines των templates είναι ένας ισχυρός τρόπος για να μετασχηματίσετε πληροφορίες και στη συνέχεια να τις εισάγετε στο YAML σας. Αλλά μερικές φορές είναι απαραίτητο να προσθέσουμε κάποια λογική template που είναι λίγο πιο εξελιγμένη από την απλή εισαγωγή ενός string. Στην επόμενη ενότητα θα εξετάσουμε τις δομές ελέγχου που παρέχει η γλώσσα template. ## Χρήση της συνάρτησης `lookup` {#using-the-lookup-function} Η συνάρτηση `lookup` μπορεί να χρησιμοποιηθεί για να _αναζητήσει_ resources σε ένα cluster που εκτελείται. Η σύνοψη της συνάρτησης lookup είναι `lookup apiVersion, kind, namespace, name -> resource or resource list`. | παράμετρος | τύπος | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Τόσο το `name` όσο και το `namespace` είναι προαιρετικά και μπορούν να περαστούν ως κενό string (`""`). Ωστόσο, αν εργάζεστε με ένα resource που ανήκει σε namespace, πρέπει να καθοριστούν και τα δύο, το `name` και το `namespace`. Οι ακόλουθοι συνδυασμοί παραμέτρων είναι δυνατοί: | Συμπεριφορά | Συνάρτηση lookup | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Όταν η `lookup` επιστρέφει ένα αντικείμενο, θα επιστρέψει ένα dictionary. Αυτό το dictionary μπορεί να πλοηγηθεί περαιτέρω για να εξαχθούν συγκεκριμένες τιμές. Το ακόλουθο παράδειγμα θα επιστρέψει τα annotations που υπάρχουν για το αντικείμενο `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Όταν η `lookup` επιστρέφει μια λίστα αντικειμένων, είναι δυνατή η πρόσβαση στη λίστα αντικειμένων μέσω του πεδίου `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` Όταν δεν βρεθεί κανένα αντικείμενο, επιστρέφεται μια κενή τιμή. Αυτό μπορεί να χρησιμοποιηθεί για τον έλεγχο ύπαρξης ενός αντικειμένου. Η συνάρτηση `lookup` χρησιμοποιεί την υπάρχουσα ρύθμιση σύνδεσης Kubernetes του Helm για να κάνει ερωτήματα στο Kubernetes. Αν επιστραφεί οποιοδήποτε σφάλμα κατά την αλληλεπίδραση με τον API server (για παράδειγμα λόγω έλλειψης δικαιωμάτων πρόσβασης σε ένα resource), η επεξεργασία template του Helm θα αποτύχει. Να έχετε υπόψη ότι το Helm δεν πρέπει να επικοινωνεί με τον Kubernetes API Server κατά τη διάρκεια μιας λειτουργίας `helm template|install|upgrade|delete|rollback --dry-run`. Για να δοκιμάσετε τη `lookup` σε ένα cluster που εκτελείται, θα πρέπει να χρησιμοποιήσετε `helm template|install|upgrade|delete|rollback --dry-run=server` για να επιτρέψετε τη σύνδεση με το cluster. ## Οι τελεστές είναι συναρτήσεις {#operators-are-functions} Για τα templates, οι τελεστές (`eq`, `ne`, `lt`, `gt`, `and`, `or` κ.λπ.) υλοποιούνται όλοι ως συναρτήσεις. Στα pipelines, οι πράξεις μπορούν να ομαδοποιηθούν με παρενθέσεις (`(` και `)`). Τώρα μπορούμε να προχωρήσουμε από τις συναρτήσεις και τα pipelines στον έλεγχο ροής με συνθήκες, βρόχους και τροποποιητές εύρους. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Ξεκινώντας description: Ένας γρήγορος οδηγός για τα Chart templates. sidebar_position: 2 --- Σε αυτήν την ενότητα του οδηγού, θα δημιουργήσουμε ένα chart και στη συνέχεια θα προσθέσουμε ένα πρώτο template. Το chart που θα δημιουργήσουμε εδώ θα χρησιμοποιηθεί σε όλο τον υπόλοιπο οδηγό. Για να ξεκινήσουμε, ας ρίξουμε μια σύντομη ματιά σε ένα Helm chart. ## Charts {#charts} Όπως περιγράφεται στον [Οδηγό Charts](/topics/charts.md), τα Helm charts έχουν την εξής δομή: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Ο κατάλογος `templates/` προορίζεται για αρχεία template. Όταν το Helm αξιολογεί ένα chart, στέλνει όλα τα αρχεία του καταλόγου `templates/` μέσω της μηχανής απόδοσης template. Στη συνέχεια συλλέγει τα αποτελέσματα αυτών των templates και τα στέλνει στο Kubernetes. Το αρχείο `values.yaml` είναι επίσης σημαντικό για τα templates. Αυτό το αρχείο περιέχει τις _προεπιλεγμένες τιμές_ για ένα chart. Αυτές οι τιμές μπορούν να παρακαμφθούν από τους χρήστες κατά τη διάρκεια του `helm install` ή του `helm upgrade`. Το αρχείο `Chart.yaml` περιέχει μια περιγραφή του chart. Μπορείτε να έχετε πρόσβαση σε αυτό μέσα από ένα template. Ο κατάλογος `charts/` _μπορεί_ να περιέχει άλλα charts (τα οποία ονομάζουμε _subcharts_). Αργότερα σε αυτόν τον οδηγό θα δούμε πώς λειτουργούν αυτά κατά την απόδοση των templates. ## Ένα Αρχικό Chart {#a-starter-chart} Για αυτόν τον οδηγό, θα δημιουργήσουμε ένα απλό chart με το όνομα `mychart`, και στη συνέχεια θα δημιουργήσουμε μερικά templates μέσα σε αυτό. ```console $ helm create mychart Creating mychart ``` ### Μια Γρήγορη Ματιά στο `mychart/templates/` {#a-quick-glimpse-of-mycharttemplates} Αν ρίξετε μια ματιά στον κατάλογο `mychart/templates/`, θα παρατηρήσετε ότι υπάρχουν ήδη μερικά αρχεία. - `NOTES.txt`: Το «κείμενο βοήθειας» για το chart σας. Θα εμφανίζεται στους χρήστες όταν εκτελούν την εντολή `helm install`. - `deployment.yaml`: Ένα βασικό manifest για τη δημιουργία ενός Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - `service.yaml`: Ένα βασικό manifest για τη δημιουργία ενός [service endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) για το deployment σας - `_helpers.tpl`: Ένα μέρος για να τοποθετήσετε template helpers που μπορείτε να επαναχρησιμοποιήσετε σε όλο το chart Και αυτό που θα κάνουμε είναι... _να τα διαγράψουμε όλα!_ Με αυτόν τον τρόπο μπορούμε να δουλέψουμε τον οδηγό από την αρχή. Θα δημιουργήσουμε στην πραγματικότητα τα δικά μας `NOTES.txt` και `_helpers.tpl` καθώς προχωράμε. ```console $ rm -rf mychart/templates/* ``` Όταν γράφετε charts για παραγωγή, η ύπαρξη βασικών εκδόσεων αυτών των αρχείων μπορεί να είναι πραγματικά χρήσιμη. Επομένως, στην καθημερινή δημιουργία charts, πιθανότατα δεν θα θέλετε να τα διαγράψετε. ## Ένα Πρώτο Template {#a-first-template} Το πρώτο template που θα δημιουργήσουμε θα είναι ένα `ConfigMap`. Στο Kubernetes, ένα ConfigMap είναι απλά ένα αντικείμενο για την αποθήκευση δεδομένων ρύθμισης. Άλλα στοιχεία, όπως τα pods, μπορούν να έχουν πρόσβαση στα δεδομένα ενός ConfigMap. Επειδή τα ConfigMaps είναι βασικοί πόροι, αποτελούν ένα εξαιρετικό σημείο εκκίνησης για εμάς. Ας ξεκινήσουμε δημιουργώντας ένα αρχείο με το όνομα `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **ΣΥΜΒΟΥΛΗ:** Τα ονόματα των templates δεν ακολουθούν ένα αυστηρό πρότυπο ονοματολογίας. Ωστόσο, συνιστούμε τη χρήση της επέκτασης `.yaml` για αρχεία YAML και `.tpl` για helpers. Το παραπάνω αρχείο YAML είναι ένα ConfigMap με τα ελάχιστα απαραίτητα πεδία. Λόγω του ότι αυτό το αρχείο βρίσκεται στον κατάλογο `mychart/templates/`, θα περάσει από τη μηχανή template. Είναι απολύτως αποδεκτό να τοποθετήσετε ένα απλό αρχείο YAML όπως αυτό στον κατάλογο `mychart/templates/`. Όταν το Helm διαβάζει αυτό το template, απλά το στέλνει στο Kubernetes ως έχει. Με αυτό το απλό template, έχουμε τώρα ένα chart που μπορεί να εγκατασταθεί. Και μπορούμε να το εγκαταστήσουμε ως εξής: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Χρησιμοποιώντας το Helm, μπορούμε να ανακτήσουμε το release και να δούμε το πραγματικό template που φορτώθηκε. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` Η εντολή `helm get manifest` παίρνει ένα όνομα release (`full-coral`) και εκτυπώνει όλους τους πόρους Kubernetes που ανέβηκαν στον server. Κάθε αρχείο ξεκινά με `---` για να υποδείξει την αρχή ενός εγγράφου YAML, και ακολουθεί μια αυτόματα παραγόμενη γραμμή σχολίου που μας λέει ποιο αρχείο template δημιούργησε αυτό το έγγραφο YAML. Από εκεί και πέρα, μπορούμε να δούμε ότι τα δεδομένα YAML είναι ακριβώς αυτά που βάλαμε στο αρχείο `configmap.yaml`. Τώρα μπορούμε να απεγκαταστήσουμε το release: `helm uninstall full-coral`. ### Προσθήκη μιας Απλής Κλήσης Template {#adding-a-simple-template-call} Η σκληρή κωδικοποίηση του `name:` σε έναν πόρο θεωρείται γενικά κακή πρακτική. Τα ονόματα πρέπει να είναι μοναδικά για κάθε release. Επομένως, μπορεί να θέλουμε να δημιουργήσουμε ένα πεδίο name εισάγοντας το όνομα του release. **ΣΥΜΒΟΥΛΗ:** Το πεδίο `name:` περιορίζεται σε 63 χαρακτήρες λόγω περιορισμών του συστήματος DNS. Για αυτόν τον λόγο, τα ονόματα release περιορίζονται σε 53 χαρακτήρες. Το Kubernetes 1.3 και παλαιότερες εκδόσεις περιορίζονταν σε μόνο 24 χαρακτήρες (άρα 14 χαρακτήρες για τα ονόματα). Ας τροποποιήσουμε το `configmap.yaml` ανάλογα. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Η μεγάλη αλλαγή έρχεται στην τιμή του πεδίου `name:`, η οποία είναι τώρα `{{ .Release.Name }}-configmap`. > Μια οδηγία template περικλείεται σε blocks `{{` και `}}`. Η οδηγία template `{{ .Release.Name }}` εισάγει το όνομα του release στο template. Οι τιμές που περνούν σε ένα template μπορούν να θεωρηθούν ως _αντικείμενα οργανωμένα σε namespaces_, όπου μια τελεία (`.`) διαχωρίζει κάθε namespace. Η αρχική τελεία πριν από το `Release` υποδεικνύει ότι ξεκινάμε από το ανώτατο namespace για αυτό το εύρος (scope) (θα μιλήσουμε για το εύρος αργότερα). Επομένως, μπορούμε να διαβάσουμε το `.Release.Name` ως «ξεκίνα από το ανώτατο namespace, βρες το αντικείμενο `Release`, και μετά ψάξε μέσα του για ένα αντικείμενο με το όνομα `Name`». Το αντικείμενο `Release` είναι ένα από τα ενσωματωμένα αντικείμενα του Helm, και θα το καλύψουμε πιο αναλυτικά αργότερα. Αλλά προς το παρόν, αρκεί να πούμε ότι αυτό θα εμφανίσει το όνομα release που η βιβλιοθήκη αναθέτει στο release μας. Τώρα, όταν εγκαταστήσουμε τον πόρο μας, θα δούμε αμέσως το αποτέλεσμα της χρήσης αυτής της οδηγίας template: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Μπορείτε να εκτελέσετε `helm get manifest clunky-serval` για να δείτε ολόκληρο το παραγόμενο YAML. Παρατηρήστε ότι το ConfigMap μέσα στο Kubernetes έχει όνομα `clunky-serval-configmap` αντί για `mychart-configmap` που είχε προηγουμένως. Σε αυτό το σημείο, έχουμε δει τα templates στην πιο βασική τους μορφή: αρχεία YAML που έχουν οδηγίες template ενσωματωμένες σε `{{` και `}}`. Στο επόμενο μέρος, θα ρίξουμε μια πιο βαθιά ματιά στα templates. Αλλά πριν προχωρήσουμε, υπάρχει ένα γρήγορο κόλπο που μπορεί να κάνει τη δημιουργία templates πιο γρήγορη: Όταν θέλετε να δοκιμάσετε την απόδοση του template, αλλά όχι να εγκαταστήσετε πραγματικά κάτι, μπορείτε να χρησιμοποιήσετε `helm install --debug --dry-run goodly-guppy ./mychart`. Αυτό θα αποδώσει τα templates. Αλλά αντί να εγκαταστήσει το chart, θα επιστρέψει το αποδοθέν template σε εσάς ώστε να δείτε την έξοδο: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Η χρήση του `--dry-run` θα διευκολύνει τον έλεγχο του κώδικά σας, αλλά δεν θα εξασφαλίσει ότι το ίδιο το Kubernetes θα αποδεχτεί τα templates που παράγετε. Είναι καλύτερο να μην υποθέτετε ότι το chart σας θα εγκατασταθεί μόνο και μόνο επειδή το `--dry-run` λειτουργεί. Στον [Οδηγό Chart Template](/chart_template_guide/index.mdx), παίρνουμε το βασικό chart που ορίσαμε εδώ και εξερευνούμε τη γλώσσα template του Helm αναλυτικά. Και θα ξεκινήσουμε με τα ενσωματωμένα αντικείμενα. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: Το αρχείο .helmignore description: Το αρχείο `.helmignore` χρησιμοποιείται για τον καθορισμό αρχείων που δεν θέλετε να συμπεριλάβετε στο helm chart σας. sidebar_position: 12 --- Με το αρχείο `.helmignore` καθορίζετε τα αρχεία που δεν θέλετε να συμπεριλάβετε στο helm chart σας. Εάν υπάρχει αυτό το αρχείο, η εντολή `helm package` θα αγνοήσει όλα τα αρχεία που ταιριάζουν με τα μοτίβα που καθορίζονται στο `.helmignore` κατά τη δημιουργία του πακέτου της εφαρμογής σας. Αυτό βοηθά στην αποφυγή προσθήκης περιττών ή ευαίσθητων αρχείων και καταλόγων στο helm chart σας. Το αρχείο `.helmignore` υποστηρίζει αντιστοίχιση μοτίβων Unix shell glob, αντιστοίχιση σχετικών διαδρομών και άρνηση (με πρόθεμα !). Λαμβάνεται υπόψη μόνο ένα μοτίβο ανά γραμμή. Ακολουθεί ένα παράδειγμα αρχείου `.helmignore`: ``` # comment {#comment} # Match any file or path named .helmignore {#match-any-file-or-path-named-helmignore} .helmignore # Match any file or path named .git {#match-any-file-or-path-named-git} .git # Match any text file {#match-any-text-file} *.txt # Match only directories named mydir {#match-only-directories-named-mydir} mydir/ # Match only text files in the top-level directory {#match-only-text-files-in-the-top-level-directory} /*.txt # Match only the file foo.txt in the top-level directory {#match-only-the-file-footxt-in-the-top-level-directory} /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt {#match-any-file-named-abtxt-actxt-or-adtxt} a[b-d].txt # Match any file under subdir matching temp* {#match-any-file-under-subdir-matching-temp} */temp* */*/temp* temp? ``` Ορισμένες αξιοσημείωτες διαφορές από το .gitignore: - Η σύνταξη '**' δεν υποστηρίζεται. - Η βιβλιοθήκη globbing είναι η `filepath.Match` της Go, όχι η fnmatch(3) - Τα τελικά κενά αγνοούνται πάντα (δεν υπάρχει υποστηριζόμενη ακολουθία διαφυγής) - Δεν υπάρχει υποστήριξη για το '\!' ως ειδική αρχική ακολουθία. - Το αρχείο δεν εξαιρεί τον εαυτό του από προεπιλογή· πρέπει να προσθέσετε ρητά μια καταχώρηση για το `.helmignore` **Θα εκτιμούσαμε τη βοήθειά σας** για τη βελτίωση αυτού του εγγράφου. Για να προσθέσετε, διορθώσετε ή αφαιρέσετε πληροφορίες, [υποβάλετε ένα issue](https://github.com/helm/helm-www/issues) ή στείλτε μας ένα pull request. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: Οδηγός Chart Template sidebar_position: 5 --- # Ο Οδηγός Ανάπτυξης Chart Template {#the-chart-template-developers-guide} Αυτός ο οδηγός παρέχει μια εισαγωγή στα templates των charts του Helm, με έμφαση στη γλώσσα template. Τα templates παράγουν αρχεία manifest, τα οποία είναι περιγραφές πόρων σε μορφή YAML που μπορεί να κατανοήσει το Kubernetes. Θα δούμε πώς είναι δομημένα τα templates, πώς μπορούν να χρησιμοποιηθούν, πώς να γράφετε Go templates και πώς να κάνετε αποσφαλμάτωση της δουλειάς σας. Αυτός ο οδηγός επικεντρώνεται στις ακόλουθες έννοιες: - Η γλώσσα template του Helm - Χρήση values - Τεχνικές για εργασία με templates Αυτός ο οδηγός είναι προσανατολισμένος στην εκμάθηση των λεπτομερειών της γλώσσας template του Helm. Άλλοι οδηγοί παρέχουν εισαγωγικό υλικό, παραδείγματα και βέλτιστες πρακτικές. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Ονομασμένα Templates description: Πώς να ορίζετε ονομασμένα templates. sidebar_position: 9 --- Ήρθε η ώρα να ξεπεράσουμε τη χρήση ενός μόνο template και να αρχίσουμε να δημιουργούμε και άλλα. Σε αυτή την ενότητα θα δούμε πώς να ορίζουμε _ονομασμένα templates_ σε ένα αρχείο και πώς να τα χρησιμοποιούμε αλλού. Ένα _ονομασμένο template_ (μερικές φορές αποκαλείται _partial_ ή _subtemplate_) είναι απλά ένα template που ορίζεται μέσα σε ένα αρχείο και έχει ένα όνομα. Θα δούμε δύο τρόπους δημιουργίας τους και αρκετούς διαφορετικούς τρόπους χρήσης τους. Στην ενότητα [Δομές Ελέγχου Ροής](./control_structures.md) παρουσιάσαμε τρεις ενέργειες για τη δήλωση και διαχείριση templates: `define`, `template` και `block`. Σε αυτή την ενότητα θα καλύψουμε αυτές τις τρεις ενέργειες και επίσης θα παρουσιάσουμε μια ειδική συνάρτηση `include` που λειτουργεί παρόμοια με την ενέργεια `template`. Μια σημαντική λεπτομέρεια που πρέπει να έχετε υπόψη όταν ονομάζετε templates: **τα ονόματα των templates είναι global**. Αν δηλώσετε δύο templates με το ίδιο όνομα, θα χρησιμοποιηθεί αυτό που φορτώθηκε τελευταίο. Επειδή τα templates στα subcharts μεταγλωττίζονται μαζί με τα templates του ανώτερου επιπέδου, θα πρέπει να είστε προσεκτικοί να ονομάζετε τα templates σας με _ονόματα ειδικά για το chart_. Μια δημοφιλής σύμβαση ονομασίας είναι να προσθέτετε ως πρόθεμα σε κάθε ορισμένο template το όνομα του chart: `{{ define "mychart.labels" }}`. Χρησιμοποιώντας το συγκεκριμένο όνομα του chart ως πρόθεμα, μπορούμε να αποφύγουμε τυχόν διενέξεις που μπορεί να προκύψουν από δύο διαφορετικά charts που υλοποιούν templates με το ίδιο όνομα. Αυτή η συμπεριφορά ισχύει επίσης για διαφορετικές εκδόσεις ενός chart. Αν έχετε το `mychart` έκδοση `1.0.0` που ορίζει ένα template με έναν τρόπο, και ένα `mychart` έκδοση `2.0.0` που τροποποιεί το υπάρχον ονομασμένο template, θα χρησιμοποιηθεί αυτό που φορτώθηκε τελευταίο. Μπορείτε να αντιμετωπίσετε αυτό το πρόβλημα προσθέτοντας επίσης μια έκδοση στο όνομα του chart: `{{ define "mychart.v1.labels" }}` και `{{ define "mychart.v2.labels" }}`. ## Partials και αρχεία `_` {#partials-and-_-files} Μέχρι στιγμής έχουμε χρησιμοποιήσει ένα αρχείο, και αυτό το αρχείο περιέχει ένα μόνο template. Όμως η γλώσσα template του Helm σας επιτρέπει να δημιουργείτε ονομασμένα ενσωματωμένα templates, τα οποία μπορούν να προσπελαστούν με το όνομά τους οπουδήποτε αλλού. Πριν ασχοληθούμε με τις λεπτομέρειες της σύνταξης αυτών των templates, υπάρχει μια σύμβαση ονομασίας αρχείων που αξίζει να αναφερθεί: * Τα περισσότερα αρχεία στο `templates/` αντιμετωπίζονται σαν να περιέχουν Kubernetes manifests * Το `NOTES.txt` αποτελεί εξαίρεση * Όμως τα αρχεία των οποίων το όνομα ξεκινά με κάτω παύλα (`_`) θεωρείται ότι _δεν_ περιέχουν manifest. Αυτά τα αρχεία δεν αποδίδονται ως ορισμοί αντικειμένων Kubernetes, αλλά είναι διαθέσιμα παντού μέσα σε άλλα chart templates για χρήση. Αυτά τα αρχεία χρησιμοποιούνται για την αποθήκευση partials και helpers. Στην πραγματικότητα, όταν δημιουργήσαμε για πρώτη φορά το `mychart`, είδαμε ένα αρχείο με το όνομα `_helpers.tpl`. Αυτό το αρχείο είναι η προεπιλεγμένη τοποθεσία για τα template partials. ## Δήλωση και χρήση templates με `define` και `template` {#declaring-and-using-templates-with-define-and-template} Η ενέργεια `define` μας επιτρέπει να δημιουργούμε ένα ονομασμένο template μέσα σε ένα αρχείο template. Η σύνταξή της είναι η εξής: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` Για παράδειγμα, μπορούμε να ορίσουμε ένα template που ενθυλακώνει ένα block labels του Kubernetes: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Τώρα μπορούμε να ενσωματώσουμε αυτό το template μέσα στο υπάρχον ConfigMap και στη συνέχεια να το συμπεριλάβουμε με την ενέργεια `template`: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Όταν ο μηχανισμός template διαβάσει αυτό το αρχείο, θα αποθηκεύσει την αναφορά στο `mychart.labels` μέχρι να κληθεί το `template "mychart.labels"`. Τότε θα αποδώσει αυτό το template στη θέση του. Επομένως το αποτέλεσμα θα είναι: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Σημείωση: ένα `define` δεν παράγει έξοδο εκτός αν κληθεί με ένα template, όπως σε αυτό το παράδειγμα. Συνήθως, τα Helm charts τοποθετούν αυτά τα templates μέσα σε ένα αρχείο partials, συνήθως το `_helpers.tpl`. Ας μεταφέρουμε αυτή τη συνάρτηση εκεί: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Κατά σύμβαση, οι συναρτήσεις `define` θα πρέπει να έχουν ένα απλό block τεκμηρίωσης (`{{/* ... */}}`) που περιγράφει τι κάνουν. Παρόλο που αυτός ο ορισμός βρίσκεται στο `_helpers.tpl`, μπορεί ακόμα να προσπελαστεί από το `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Όπως αναφέρθηκε παραπάνω, **τα ονόματα των templates είναι global**. Ως αποτέλεσμα, αν δύο templates δηλωθούν με το ίδιο όνομα, θα χρησιμοποιηθεί η τελευταία εμφάνιση. Δεδομένου ότι τα templates στα subcharts μεταγλωττίζονται μαζί με τα templates του ανώτερου επιπέδου, είναι καλύτερο να ονομάζετε τα templates σας με _ονόματα ειδικά για το chart_. Μια δημοφιλής σύμβαση ονομασίας είναι να προσθέτετε ως πρόθεμα σε κάθε ορισμένο template το όνομα του chart: `{{ define "mychart.labels" }}`. ## Ορισμός του εύρους (scope) ενός template {#setting-the-scope-of-a-template} Στο template που ορίσαμε παραπάνω, δεν χρησιμοποιήσαμε κανένα αντικείμενο. Χρησιμοποιήσαμε μόνο συναρτήσεις. Ας τροποποιήσουμε το ορισμένο template ώστε να συμπεριλάβει το όνομα και την έκδοση του chart: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Αν αποδώσουμε αυτό, θα λάβουμε ένα σφάλμα όπως αυτό: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Για να δείτε τι αποδόθηκε, εκτελέστε ξανά με `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Το αποτέλεσμα δεν θα είναι αυτό που περιμέναμε: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Τι συνέβη με το όνομα και την έκδοση; Δεν βρίσκονταν μέσα στο εύρος (scope) του ορισμένου template. Όταν ένα ονομασμένο template (που δημιουργήθηκε με `define`) αποδίδεται, θα λάβει το εύρος που μεταβιβάστηκε από την κλήση `template`. Στο παράδειγμά μας, συμπεριλάβαμε το template ως εξής: ```yaml {{- template "mychart.labels" }} ``` Δεν μεταβιβάστηκε κανένα εύρος, οπότε μέσα στο template δεν μπορούμε να έχουμε πρόσβαση σε τίποτα στο `.`. Αυτό διορθώνεται εύκολα. Απλά μεταβιβάζουμε ένα εύρος στο template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Παρατηρήστε ότι μεταβιβάζουμε το `.` στο τέλος της κλήσης `template`. Θα μπορούσαμε εξίσου εύκολα να μεταβιβάσουμε `.Values` ή `.Values.favorite` ή όποιο εύρος θέλουμε. Αλλά αυτό που θέλουμε είναι το εύρος ανώτερου επιπέδου. Στο πλαίσιο του ονομασμένου template, η `$` θα αναφέρεται στο εύρος που μεταβιβάσατε και όχι σε κάποιο global εύρος. Τώρα όταν εκτελέσουμε αυτό το template με `helm install --dry-run --debug plinking-anaco ./mychart`, θα λάβουμε: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Τώρα το `{{ .Chart.Name }}` επιλύεται σε `mychart` και το `{{ .Chart.Version }}` επιλύεται σε `0.1.0`. ## Η συνάρτηση `include` {#the-include-function} Ας πούμε ότι έχουμε ορίσει ένα απλό template που μοιάζει με αυτό: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Τώρα ας πούμε ότι θέλω να εισάγω αυτό τόσο στην ενότητα `labels:` του template μου όσο και στην ενότητα `data:`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Αν αποδώσουμε αυτό, θα λάβουμε ένα σφάλμα όπως αυτό: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Για να δείτε τι αποδόθηκε, εκτελέστε ξανά με `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Η έξοδος δεν θα είναι αυτή που περιμέναμε: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Παρατηρήστε ότι η εσοχή στο `app_version` είναι λάθος και στις δύο θέσεις. Γιατί; Επειδή το template που αντικαθίσταται έχει το κείμενο στοιχισμένο στα αριστερά. Επειδή το `template` είναι μια ενέργεια και όχι μια συνάρτηση, δεν υπάρχει τρόπος να μεταβιβάσουμε την έξοδο μιας κλήσης `template` σε άλλες συναρτήσεις· τα δεδομένα απλά εισάγονται στη θέση τους. Για να αντιμετωπίσουμε αυτή την περίπτωση, το Helm παρέχει μια εναλλακτική στο `template` που θα εισάγει τα περιεχόμενα ενός template στο τρέχον pipeline όπου μπορούν να μεταβιβαστούν σε άλλες συναρτήσεις στο pipeline. Ακολουθεί το παράδειγμα παραπάνω, διορθωμένο ώστε να χρησιμοποιεί το `indent` για να εσοχοποιεί το template `mychart.app` σωστά: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Τώρα το παραγόμενο YAML είναι σωστά εσοχοποιημένο για κάθε ενότητα: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Θεωρείται προτιμότερο να χρησιμοποιείτε το `include` αντί για το `template` > στα Helm templates, απλά επειδή η μορφοποίηση της εξόδου μπορεί να > αντιμετωπιστεί καλύτερα για έγγραφα YAML. Μερικές φορές θέλουμε να εισάγουμε περιεχόμενο, αλλά όχι ως templates. Δηλαδή, θέλουμε να εισάγουμε αρχεία αυτούσια. Μπορούμε να το επιτύχουμε προσπελαύνοντας αρχεία μέσω του αντικειμένου `.Files` που περιγράφεται στην επόμενη ενότητα. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Δημιουργία αρχείου NOTES.txt description: Πώς να παρέχετε οδηγίες στους χρήστες του Chart σας. sidebar_position: 10 --- Σε αυτή την ενότητα θα εξετάσουμε το εργαλείο του Helm για την παροχή οδηγιών στους χρήστες του chart σας. Στο τέλος μιας εντολής `helm install` ή `helm upgrade`, το Helm μπορεί να εμφανίσει ένα μπλοκ χρήσιμων πληροφοριών για τους χρήστες. Αυτές οι πληροφορίες είναι πλήρως προσαρμόσιμες μέσω templates. Για να προσθέσετε σημειώσεις εγκατάστασης στο chart σας, απλά δημιουργήστε ένα αρχείο `templates/NOTES.txt`. Αυτό το αρχείο είναι απλό κείμενο, αλλά επεξεργάζεται σαν template και έχει πρόσβαση σε όλες τις συνήθεις συναρτήσεις και αντικείμενα template. Ας δημιουργήσουμε ένα απλό αρχείο `NOTES.txt`: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Αν εκτελέσουμε τώρα `helm install rude-cardinal ./mychart`, θα δούμε αυτό το μήνυμα στο τέλος: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Η χρήση του `NOTES.txt` με αυτόν τον τρόπο είναι εξαιρετική για να παρέχετε στους χρήστες σας λεπτομερείς πληροφορίες σχετικά με τη χρήση του chart που μόλις εγκατέστησαν. Η δημιουργία ενός αρχείου `NOTES.txt` συνιστάται ιδιαίτερα, αν και δεν είναι υποχρεωτική. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts και Global Values description: Αλληλεπίδραση με τα values ενός subchart και τα global values. sidebar_position: 11 --- Μέχρι τώρα δουλεύαμε μόνο με ένα chart. Όμως τα charts μπορούν να έχουν εξαρτήσεις, που ονομάζονται _subcharts_, τα οποία επίσης έχουν τα δικά τους values και templates. Σε αυτή την ενότητα θα δημιουργήσουμε ένα subchart και θα δούμε τους διαφορετικούς τρόπους πρόσβασης στα values μέσα από τα templates. Πριν εμβαθύνουμε στον κώδικα, υπάρχουν μερικές σημαντικές λεπτομέρειες που πρέπει να γνωρίζετε σχετικά με τα subcharts εφαρμογών. 1. Ένα subchart θεωρείται "αυτόνομο", που σημαίνει ότι ένα subchart δεν μπορεί ποτέ να εξαρτάται ρητά από το γονικό chart. 2. Για αυτόν τον λόγο, ένα subchart δεν μπορεί να έχει πρόσβαση στα values του γονικού chart. 3. Ένα γονικό chart μπορεί να παρακάμψει τα values των subcharts. 4. Το Helm έχει την έννοια των _global values_ που είναι προσβάσιμα από όλα τα charts. > Αυτοί οι περιορισμοί δεν ισχύουν απαραίτητα για τα [library charts](/topics/library_charts.md), τα οποία έχουν σχεδιαστεί για να παρέχουν τυποποιημένη βοηθητική λειτουργικότητα. Καθώς προχωράμε στα παραδείγματα αυτής της ενότητας, πολλές από αυτές τις έννοιες θα γίνουν πιο ξεκάθαρες. ## Δημιουργία Subchart {#creating-a-subchart} Για αυτές τις ασκήσεις, θα ξεκινήσουμε με το chart `mychart/` που δημιουργήσαμε στην αρχή αυτού του οδηγού και θα προσθέσουμε ένα νέο chart μέσα σε αυτό. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Παρατηρήστε ότι όπως και πριν, διαγράψαμε όλα τα βασικά templates ώστε να μπορέσουμε να ξεκινήσουμε από την αρχή. Σε αυτόν τον οδηγό επικεντρωνόμαστε στον τρόπο λειτουργίας των templates, όχι στη διαχείριση εξαρτήσεων. Ο [Οδηγός Charts](/topics/charts.md) περιέχει περισσότερες πληροφορίες σχετικά με τον τρόπο λειτουργίας των subcharts. ## Προσθήκη Values και Template στο Subchart {#adding-values-and-a-template-to-the-subchart} Στη συνέχεια, ας δημιουργήσουμε ένα απλό template και αρχείο values για το chart `mysubchart`. Θα πρέπει να υπάρχει ήδη ένα `values.yaml` στο `mychart/charts/mysubchart`. Θα το ρυθμίσουμε ως εξής: ```yaml dessert: cake ``` Στη συνέχεια, θα δημιουργήσουμε ένα νέο ConfigMap template στο `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Επειδή κάθε subchart είναι ένα _αυτόνομο chart_, μπορούμε να δοκιμάσουμε το `mysubchart` μόνο του: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml {#source-mysubcharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Παράκαμψη Values από Γονικό Chart {#overriding-values-from-a-parent-chart} Το αρχικό μας chart, `mychart`, είναι τώρα το _γονικό chart_ του `mysubchart`. Αυτή η σχέση βασίζεται αποκλειστικά στο γεγονός ότι το `mysubchart` βρίσκεται μέσα στο `mychart/charts`. Επειδή το `mychart` είναι γονικό, μπορούμε να καθορίσουμε ρυθμίσεις στο `mychart` και να τις περάσουμε στο `mysubchart`. Για παράδειγμα, μπορούμε να τροποποιήσουμε το `mychart/values.yaml` ως εξής: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Προσέξτε τις δύο τελευταίες γραμμές. Οποιαδήποτε οδηγία μέσα στην ενότητα `mysubchart` θα σταλεί στο chart `mysubchart`. Έτσι, αν εκτελέσουμε `helm install --generate-name --dry-run --debug mychart`, ένα από τα πράγματα που θα δούμε είναι το ConfigMap του `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml {#source-mychartchartsmysubcharttemplatesconfigmapyaml} {#source-mychartchartsmysubcharttemplatesconfigmapyaml} {#source-mychartchartsmysubcharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` Η τιμή στο ανώτερο επίπεδο έχει τώρα παρακάμψει την τιμή του subchart. Υπάρχει μια σημαντική λεπτομέρεια που πρέπει να παρατηρήσουμε εδώ. Δεν αλλάξαμε το template του `mychart/charts/mysubchart/templates/configmap.yaml` ώστε να δείχνει στο `.Values.mysubchart.dessert`. Από την οπτική γωνία αυτού του template, η τιμή εξακολουθεί να βρίσκεται στο `.Values.dessert`. Καθώς η μηχανή template περνά τα values, ορίζει το εύρος (scope). Έτσι, για τα templates του `mysubchart`, μόνο τα values που προορίζονται συγκεκριμένα για το `mysubchart` θα είναι διαθέσιμα στο `.Values`. Μερικές φορές, όμως, θέλετε ορισμένα values να είναι διαθέσιμα σε όλα τα templates. Αυτό επιτυγχάνεται με τα global chart values. ## Global Chart Values {#global-chart-values} Τα global values είναι τιμές που είναι προσβάσιμες από οποιοδήποτε chart ή subchart με ακριβώς το ίδιο όνομα. Τα globals απαιτούν ρητή δήλωση. Δεν μπορείτε να χρησιμοποιήσετε ένα υπάρχον μη-global value σαν να ήταν global. Ο τύπος δεδομένων Values έχει μια δεσμευμένη ενότητα που ονομάζεται `Values.global` όπου μπορούν να οριστούν global values. Ας ορίσουμε ένα στο αρχείο `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Λόγω του τρόπου λειτουργίας των globals, τόσο το `mychart/templates/configmap.yaml` όσο και το `mysubchart/templates/configmap.yaml` θα πρέπει να μπορούν να έχουν πρόσβαση σε αυτή την τιμή ως `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Τώρα αν εκτελέσουμε μια dry run εγκατάσταση, θα δούμε την ίδια τιμή και στις δύο εξόδους: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Τα globals είναι χρήσιμα για τη μετάδοση τέτοιων πληροφοριών, αν και απαιτείται κάποιος σχεδιασμός για να βεβαιωθείτε ότι τα σωστά templates είναι ρυθμισμένα να χρησιμοποιούν globals. ## Κοινή Χρήση Templates με Subcharts {#sharing-templates-with-subcharts} Τα γονικά charts και τα subcharts μπορούν να μοιράζονται templates. Οποιοδήποτε block ορίζεται σε οποιοδήποτε chart είναι διαθέσιμο σε άλλα charts. Για παράδειγμα, μπορούμε να ορίσουμε ένα απλό template ως εξής: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Θυμηθείτε ότι τα labels στα templates είναι _παγκοσμίως κοινόχρηστα_. Επομένως, το chart `labels` μπορεί να συμπεριληφθεί από οποιοδήποτε άλλο chart. Ενώ οι developers charts έχουν την επιλογή μεταξύ `include` και `template`, ένα πλεονέκτημα της χρήσης του `include` είναι ότι μπορεί να αναφέρεται δυναμικά σε templates: ```yaml {{ include $mytemplate }} ``` Το παραπάνω θα αποαναφέρει (dereference) τη μεταβλητή `$mytemplate`. Η συνάρτηση `template`, αντίθετα, δέχεται μόνο string literal. ## Αποφύγετε τη Χρήση Blocks {#avoid-using-blocks} Η γλώσσα Go template παρέχει τη λέξη-κλειδί `block` που επιτρέπει στους developers να παρέχουν μια προεπιλεγμένη υλοποίηση η οποία μπορεί να παρακαμφθεί αργότερα. Στα Helm charts, τα blocks δεν είναι το καλύτερο εργαλείο για παράκαμψη, επειδή αν παρέχονται πολλαπλές υλοποιήσεις του ίδιου block, η επιλογή είναι απρόβλεπτη. Η σύσταση είναι να χρησιμοποιείτε αντ' αυτού το `include`. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Αρχεία Values description: Οδηγίες για τη χρήση της επιλογής --values. sidebar_position: 4 --- Στην προηγούμενη ενότητα εξετάσαμε τα ενσωματωμένα αντικείμενα που προσφέρουν τα Helm templates. Ένα από αυτά είναι το `Values`. Αυτό το αντικείμενο παρέχει πρόσβαση σε τιμές που μεταβιβάζονται στο chart. Τα περιεχόμενά του προέρχονται από πολλαπλές πηγές: - Το αρχείο `values.yaml` μέσα στο chart - Εάν πρόκειται για subchart, το αρχείο `values.yaml` του γονικού chart - Ένα αρχείο values που μεταβιβάζεται στο `helm install` ή `helm upgrade` με την επιλογή `-f` (`helm install -f myvals.yaml ./mychart`) - Μεμονωμένες παράμετροι που μεταβιβάζονται με το `--set` (όπως `helm install --set foo=bar ./mychart`) Η παραπάνω λίστα είναι σε σειρά προτεραιότητας: το `values.yaml` είναι η προεπιλογή, η οποία μπορεί να παρακαμφθεί από το `values.yaml` ενός γονικού chart. Αυτό μπορεί να παρακαμφθεί από ένα αρχείο values που παρέχει ο χρήστης, το οποίο τέλος μπορεί να παρακαμφθεί από παραμέτρους `--set`. Τα αρχεία values είναι απλά αρχεία YAML. Ας τροποποιήσουμε το `mychart/values.yaml` και στη συνέχεια το template του ConfigMap. Αφαιρώντας τις προεπιλεγμένες τιμές από το `values.yaml`, θα ορίσουμε μόνο μία παράμετρο: ```yaml favoriteDrink: coffee ``` Τώρα μπορούμε να τη χρησιμοποιήσουμε μέσα σε ένα template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Παρατηρήστε ότι στην τελευταία γραμμή έχουμε πρόσβαση στο `favoriteDrink` ως ιδιότητα του `Values`: `{{ .Values.favoriteDrink }}`. Ας δούμε πώς αποδίδεται αυτό. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Επειδή το `favoriteDrink` έχει οριστεί στο προεπιλεγμένο αρχείο `values.yaml` ως `coffee`, αυτή είναι η τιμή που εμφανίζεται στο template. Μπορούμε εύκολα να την παρακάμψουμε προσθέτοντας την επιλογή `--set` στην κλήση του `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Δεδομένου ότι το `--set` έχει μεγαλύτερη προτεραιότητα από το προεπιλεγμένο αρχείο `values.yaml`, το template μας παράγει `drink: slurm`. Τα αρχεία values μπορούν να περιέχουν και πιο δομημένο περιεχόμενο. Για παράδειγμα, θα μπορούσαμε να δημιουργήσουμε μια ενότητα `favorite` στο αρχείο `values.yaml` και να προσθέσουμε εκεί αρκετά κλειδιά: ```yaml favorite: drink: coffee food: pizza ``` Τώρα θα πρέπει να τροποποιήσουμε ελαφρώς το template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Αν και η δόμηση δεδομένων με αυτόν τον τρόπο είναι δυνατή, η σύσταση είναι να διατηρείτε τα δέντρα τιμών σας ρηχά, προτιμώντας την επίπεδη δομή. Όταν εξετάσουμε την ανάθεση τιμών σε subcharts, θα δούμε πώς οι τιμές ονομάζονται χρησιμοποιώντας μια ιεραρχική δομή. ## Διαγραφή ενός προεπιλεγμένου κλειδιού {#deleting-a-default-key} Εάν χρειάζεται να διαγράψετε ένα κλειδί από τις προεπιλεγμένες τιμές, μπορείτε να θέσετε την τιμή του κλειδιού σε `null`, οπότε το Helm θα αφαιρέσει το κλειδί κατά τη συγχώνευση των παρακαμφθεισών τιμών. Για παράδειγμα, το stable Drupal chart επιτρέπει τη ρύθμιση του liveness probe, σε περίπτωση που διαμορφώνετε μια προσαρμοσμένη εικόνα. Οι προεπιλεγμένες τιμές είναι: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Εάν προσπαθήσετε να αλλάξετε τον handler του livenessProbe σε `exec` αντί για `httpGet` χρησιμοποιώντας `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, το Helm θα συγχωνεύσει τα προεπιλεγμένα και τα παρακαμφθέντα κλειδιά, με αποτέλεσμα το ακόλουθο YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Ωστόσο, το Kubernetes θα αποτύχει επειδή δεν μπορείτε να δηλώσετε περισσότερους από έναν handlers για το livenessProbe. Για να το αντιμετωπίσετε, μπορείτε να δώσετε εντολή στο Helm να διαγράψει το `livenessProbe.httpGet` θέτοντάς το σε null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` Σε αυτό το σημείο, έχουμε δει αρκετά ενσωματωμένα αντικείμενα και τα χρησιμοποιήσαμε για να εισάγουμε πληροφορίες σε ένα template. Τώρα θα εξετάσουμε μια άλλη πτυχή της μηχανής template: τις συναρτήσεις και τα pipelines. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Μεταβλητές description: Χρήση μεταβλητών στα templates. sidebar_position: 8 --- Αφού έχουμε δει τις συναρτήσεις, τα pipelines, τα αντικείμενα και τις δομές ελέγχου, μπορούμε να περάσουμε σε μια από τις πιο βασικές έννοιες σε πολλές γλώσσες προγραμματισμού: τις μεταβλητές. Στα templates, χρησιμοποιούνται λιγότερο συχνά. Θα δούμε όμως πώς μπορούν να απλοποιήσουν τον κώδικα και να αξιοποιήσουν καλύτερα τα `with` και `range`. Σε ένα προηγούμενο παράδειγμα, είδαμε ότι αυτός ο κώδικας θα αποτύχει: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Το `Release.Name` δεν βρίσκεται μέσα στο εύρος (scope) που περιορίζεται από το block `with`. Ένας τρόπος για να αντιμετωπίσουμε προβλήματα εύρους είναι να αναθέτουμε αντικείμενα σε μεταβλητές, στις οποίες μπορούμε να έχουμε πρόσβαση ανεξάρτητα από το τρέχον εύρος. Στα Helm templates, μια μεταβλητή είναι μια ονομασμένη αναφορά σε ένα άλλο αντικείμενο. Ακολουθεί τη μορφή `$name`. Οι μεταβλητές αναθέτονται με έναν ειδικό τελεστή ανάθεσης: `:=`. Μπορούμε να ξαναγράψουμε τα παραπάνω χρησιμοποιώντας μια μεταβλητή για το `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Παρατηρήστε ότι πριν ξεκινήσουμε το block `with`, αναθέτουμε `$relname := .Release.Name`. Τώρα μέσα στο block `with`, η μεταβλητή `$relname` εξακολουθεί να δείχνει στο όνομα του release. Η εκτέλεση αυτού θα παράγει: ```yaml # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Οι μεταβλητές είναι ιδιαίτερα χρήσιμες στους βρόχους `range`. Μπορούν να χρησιμοποιηθούν σε λίστες για να πάρουν τόσο τον δείκτη (index) όσο και την τιμή: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Παρατηρήστε ότι το `range` έρχεται πρώτο, μετά οι μεταβλητές, στη συνέχεια ο τελεστής ανάθεσης και τέλος η λίστα. Αυτό θα αναθέσει τον ακέραιο δείκτη (ξεκινώντας από το μηδέν) στην `$index` και την τιμή στην `$topping`. Η εκτέλεση θα παράγει: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Για δομές δεδομένων που έχουν τόσο κλειδί όσο και τιμή, μπορούμε να χρησιμοποιήσουμε το `range` για να λάβουμε και τα δύο. Για παράδειγμα, μπορούμε να κάνουμε βρόχο στο `.Values.favorite` ως εξής: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Στην πρώτη επανάληψη, το `$key` θα είναι `drink` και το `$val` θα είναι `coffee`, και στη δεύτερη, το `$key` θα είναι `food` και το `$val` θα είναι `pizza`. Η εκτέλεση των παραπάνω θα δημιουργήσει: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Οι μεταβλητές κανονικά δεν είναι "καθολικές" (global). Έχουν εύρος μόνο στο block στο οποίο δηλώνονται. Προηγουμένως, αναθέσαμε την `$relname` στο ανώτατο επίπεδο του template. Αυτή η μεταβλητή θα είναι διαθέσιμη σε όλο το template. Όμως στο τελευταίο παράδειγμα, οι `$key` και `$val` θα είναι διαθέσιμες μόνο μέσα στο block `{{ range... }}{{ end }}`. Ωστόσο, υπάρχει μια μεταβλητή που δείχνει πάντα στο αρχικό context: `$`. Αυτό μπορεί να είναι πολύ χρήσιμο όταν κάνουμε βρόχο με `range` και χρειαζόμαστε το όνομα του release του chart. Ένα παράδειγμα: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` Μέχρι τώρα έχουμε δει μόνο ένα template που δηλώνεται σε ένα μόνο αρχείο. Αλλά μια από τις ισχυρές δυνατότητες της γλώσσας template του Helm είναι η ικανότητά της να δηλώνει πολλαπλά templates και να τα χρησιμοποιεί μαζί. Θα περάσουμε σε αυτό στην επόμενη ενότητα. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Επόμενα Βήματα description: Ολοκλήρωση - κάποιες χρήσιμες αναφορές σε άλλη τεκμηρίωση που θα σας βοηθήσουν. sidebar_position: 14 --- Αυτός ο οδηγός σκοπεύει να σας δώσει, ως προγραμματιστή chart, μια ισχυρή κατανόηση του πώς να χρησιμοποιείτε τη γλώσσα template του Helm. Ο οδηγός επικεντρώνεται στις τεχνικές πτυχές της ανάπτυξης templates. Ωστόσο, υπάρχουν πολλά πράγματα που αυτός ο οδηγός δεν κάλυψε όσον αφορά την πρακτική καθημερινή ανάπτυξη charts. Ακολουθούν κάποιες χρήσιμες αναφορές σε άλλη τεκμηρίωση που θα σας βοηθήσουν καθώς δημιουργείτε νέα charts: - Το [Artifact Hub](https://artifacthub.io/packages/search?kind=0) του CNCF είναι μια ανεκτίμητη πηγή charts. - Η [τεκμηρίωση](https://kubernetes.io/docs/home/) του Kubernetes παρέχει λεπτομερή παραδείγματα για τα διάφορα είδη πόρων που μπορείτε να χρησιμοποιήσετε, από ConfigMaps και Secrets έως DaemonSets και Deployments. - Ο [Οδηγός Charts](/topics/charts.md) του Helm εξηγεί τη ροή εργασίας της χρήσης charts. - Ο [Οδηγός Chart Hooks](/topics/charts_hooks.md) του Helm εξηγεί πώς να δημιουργείτε lifecycle hooks. - Το άρθρο [Συμβουλές και Κόλπα για Charts](/howto/charts_tips_and_tricks.md) του Helm παρέχει χρήσιμες συμβουλές για τη συγγραφή charts. - Η [τεκμηρίωση του Sprig](https://github.com/Masterminds/sprig) περιγράφει περισσότερες από εξήντα συναρτήσεις template. - Η [τεκμηρίωση των Go templates](https://godoc.org/text/template) εξηγεί λεπτομερώς τη σύνταξη template. - Το [εργαλείο Schelm](https://github.com/databus23/schelm) είναι ένα εύχρηστο βοηθητικό εργαλείο για τον εντοπισμό σφαλμάτων σε charts. Μερικές φορές είναι πιο εύκολο να κάνετε μερικές ερωτήσεις και να λάβετε απαντήσεις από έμπειρους προγραμματιστές. Το καλύτερο μέρος για αυτό είναι τα κανάλια Helm στο [Kubernetes Slack](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Τέλος, αν βρείτε λάθη ή παραλείψεις σε αυτό το έγγραφο, θέλετε να προτείνετε νέο περιεχόμενο ή θα θέλατε να συνεισφέρετε, επισκεφτείτε το [Helm Project](https://github.com/helm/helm-www). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Παράρτημα: Τεχνικές YAML" description: Μια πιο προσεκτική ματιά στην προδιαγραφή YAML και πώς εφαρμόζεται στο Helm. sidebar_position: 15 --- Το μεγαλύτερο μέρος αυτού του οδηγού επικεντρώθηκε στη συγγραφή της γλώσσας template. Εδώ, θα εξετάσουμε τη μορφή YAML. Η YAML έχει κάποια χρήσιμα χαρακτηριστικά που εμείς, ως συγγραφείς template, μπορούμε να χρησιμοποιήσουμε για να κάνουμε τα templates μας λιγότερο επιρρεπή σε σφάλματα και ευκολότερα στην ανάγνωση. ## Βαθμωτά και Συλλογές {#scalars-and-collections} Σύμφωνα με την [προδιαγραφή YAML](https://yaml.org/spec/1.2/spec.html), υπάρχουν δύο τύποι συλλογών και πολλοί βαθμωτοί τύποι. Οι δύο τύποι συλλογών είναι maps και sequences: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Οι βαθμωτές τιμές είναι μεμονωμένες τιμές (σε αντίθεση με τις συλλογές) ### Βαθμωτοί Τύποι στην YAML {#scalar-types-in-yaml} Στη διάλεκτο YAML του Helm, ο βαθμωτός τύπος δεδομένων μιας τιμής καθορίζεται από ένα πολύπλοκο σύνολο κανόνων, συμπεριλαμβανομένου του Kubernetes schema για ορισμούς πόρων. Αλλά κατά τη συναγωγή τύπων, οι παρακάτω κανόνες τείνουν να ισχύουν. Εάν ένας ακέραιος ή αριθμός κινητής υποδιαστολής είναι bare word (χωρίς εισαγωγικά), τυπικά αντιμετωπίζεται ως αριθμητικός τύπος: ```yaml count: 1 size: 2.34 ``` Αλλά αν βρίσκονται σε εισαγωγικά, αντιμετωπίζονται ως strings: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` Το ίδιο ισχύει για τα booleans: ```yaml isGood: true # bool answer: "true" # string ``` Η λέξη για μια κενή τιμή είναι `null` (όχι `nil`). Σημειώστε ότι το `port: "80"` είναι έγκυρη YAML, και θα περάσει τόσο από τη μηχανή template όσο και από τον parser της YAML, αλλά θα αποτύχει αν το Kubernetes αναμένει το `port` να είναι ακέραιος. Σε ορισμένες περιπτώσεις, μπορείτε να επιβάλετε μια συγκεκριμένη συναγωγή τύπου χρησιμοποιώντας YAML node tags: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` Στο παραπάνω, το `!!str` λέει στον parser ότι το `age` είναι string, ακόμα κι αν μοιάζει με int. Και το `port` αντιμετωπίζεται ως int, παρόλο που βρίσκεται σε εισαγωγικά. ## Strings στην YAML {#strings-in-yaml} Πολλά από τα δεδομένα που τοποθετούμε σε έγγραφα YAML είναι strings. Η YAML έχει περισσότερους από έναν τρόπους για να αναπαραστήσει ένα string. Αυτή η ενότητα εξηγεί τους τρόπους και επιδεικνύει πώς να χρησιμοποιήσετε κάποιους από αυτούς. Υπάρχουν τρεις "inline" τρόποι για να δηλώσετε ένα string: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Όλα τα inline styles πρέπει να είναι σε μία γραμμή. - Τα bare words είναι χωρίς εισαγωγικά και δεν γίνεται escape. Για αυτόν τον λόγο, πρέπει να προσέχετε ποιους χαρακτήρες χρησιμοποιείτε. - Τα double-quoted strings μπορούν να έχουν συγκεκριμένους χαρακτήρες με escape χρησιμοποιώντας `\`. Για παράδειγμα `"\"Hello\", she said"`. Μπορείτε να κάνετε escape τις αλλαγές γραμμής με `\n`. - Τα single-quoted strings είναι "literal" strings, και δεν χρησιμοποιούν το `\` για escape χαρακτήρων. Η μόνη escape sequence είναι `''`, που αποκωδικοποιείται ως ένα μόνο `'`. Εκτός από τα strings μιας γραμμής, μπορείτε να δηλώσετε strings πολλών γραμμών: ```yaml coffee: | Latte Cappuccino Espresso ``` Το παραπάνω θα αντιμετωπίσει την τιμή του `coffee` ως ένα μόνο string ισοδύναμο με `Latte\nCappuccino\nEspresso\n`. Σημειώστε ότι η πρώτη γραμμή μετά το `|` πρέπει να έχει σωστή εσοχή. Έτσι μπορούμε να σπάσουμε το παραπάνω παράδειγμα κάνοντας αυτό: ```yaml coffee: | Latte Cappuccino Espresso ``` Επειδή το `Latte` έχει λανθασμένη εσοχή, θα λάβουμε ένα σφάλμα όπως αυτό: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` Στα templates, είναι μερικές φορές πιο ασφαλές να βάλετε μια ψεύτικη "πρώτη γραμμή" περιεχομένου σε ένα έγγραφο πολλών γραμμών για προστασία από το παραπάνω σφάλμα: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Σημειώστε ότι οτιδήποτε είναι αυτή η πρώτη γραμμή, θα διατηρηθεί στην έξοδο του string. Έτσι αν, για παράδειγμα, χρησιμοποιείτε αυτή την τεχνική για να εισάγετε τα περιεχόμενα ενός αρχείου σε ένα ConfigMap, το σχόλιο πρέπει να είναι του τύπου που αναμένεται από ό,τι διαβάζει αυτή την καταχώρηση. ### Έλεγχος Κενών σε Strings Πολλών Γραμμών {#controlling-spaces-in-multi-line-strings} Στο παραπάνω παράδειγμα, χρησιμοποιήσαμε το `|` για να υποδείξουμε ένα string πολλών γραμμών. Αλλά παρατηρήστε ότι το περιεχόμενο του string μας ακολουθούνταν από ένα τελικό `\n`. Αν θέλουμε ο επεξεργαστής YAML να αφαιρέσει αυτή την τελική αλλαγή γραμμής, μπορούμε να προσθέσουμε ένα `-` μετά το `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Τώρα η τιμή του `coffee` θα είναι: `Latte\nCappuccino\nEspresso` (χωρίς τελικό `\n`). Άλλες φορές, μπορεί να θέλουμε να διατηρηθούν όλα τα κενά στο τέλος. Μπορούμε να το κάνουμε αυτό με τη σημειογραφία `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Τώρα η τιμή του `coffee` θα είναι `Latte\nCappuccino\nEspresso\n\n\n`. Η εσοχή μέσα σε ένα text block διατηρείται, και έχει ως αποτέλεσμα τη διατήρηση των αλλαγών γραμμής επίσης: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` Στην παραπάνω περίπτωση, το `coffee` θα είναι `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Εσοχή και Templates {#indenting-and-templates} Όταν γράφετε templates, μπορεί να θέλετε να εισάγετε τα περιεχόμενα ενός αρχείου στο template. Όπως είδαμε σε προηγούμενα κεφάλαια, υπάρχουν δύο τρόποι για να το κάνετε αυτό: - Χρησιμοποιήστε `{{ .Files.Get "FILENAME" }}` για να λάβετε τα περιεχόμενα ενός αρχείου στο chart. - Χρησιμοποιήστε `{{ include "TEMPLATE" . }}` για να κάνετε render ένα template και στη συνέχεια να τοποθετήσετε τα περιεχόμενά του στο chart. Όταν εισάγετε αρχεία στην YAML, είναι καλό να κατανοήσετε τους κανόνες πολλών γραμμών παραπάνω. Συχνά, ο ευκολότερος τρόπος για να εισάγετε ένα στατικό αρχείο είναι να κάνετε κάτι σαν αυτό: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Σημειώστε πώς κάνουμε την εσοχή παραπάνω: το `indent 2` λέει στη μηχανή template να προσθέσει εσοχή δύο κενών σε κάθε γραμμή του "myfile.txt". Σημειώστε ότι δεν βάζουμε εσοχή σε εκείνη τη γραμμή του template. Αυτό γιατί αν το κάναμε, το περιεχόμενο του αρχείου της πρώτης γραμμής θα είχε διπλή εσοχή. ### Αναδιπλούμενα Strings Πολλών Γραμμών {#folded-multi-line-strings} Μερικές φορές θέλετε να αναπαραστήσετε ένα string στην YAML σας με πολλές γραμμές, αλλά θέλετε να αντιμετωπιστεί ως μία μακριά γραμμή όταν ερμηνεύεται. Αυτό ονομάζεται "folding". Για να δηλώσετε ένα folded block, χρησιμοποιήστε `>` αντί για `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` Η τιμή του `coffee` παραπάνω θα είναι `Latte Cappuccino Espresso\n`. Σημειώστε ότι όλες εκτός από την τελευταία αλλαγή γραμμής θα μετατραπούν σε κενά. Μπορείτε να συνδυάσετε τους ελέγχους whitespace με τον δείκτη folded text, οπότε το `>-` θα αντικαταστήσει ή θα αφαιρέσει όλες τις αλλαγές γραμμής. Σημειώστε ότι στη σύνταξη folding, η εσοχή κειμένου θα προκαλέσει τη διατήρηση των γραμμών. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Το παραπάνω θα παράγει `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Σημειώστε ότι τόσο τα κενά όσο και οι αλλαγές γραμμής εξακολουθούν να υπάρχουν. ## Ενσωμάτωση Πολλαπλών Εγγράφων σε Ένα Αρχείο {#embedding-multiple-documents-in-one-file} Είναι δυνατό να τοποθετήσετε περισσότερα από ένα έγγραφα YAML σε ένα μόνο αρχείο. Αυτό γίνεται προτάσσοντας ένα νέο έγγραφο με `---` και τερματίζοντας το έγγραφο με `...` ```yaml --- document: 1 ... --- document: 2 ... ``` Σε πολλές περιπτώσεις, είτε το `---` είτε το `...` μπορεί να παραλειφθεί. Ορισμένα αρχεία στο Helm δεν μπορούν να περιέχουν περισσότερα από ένα έγγραφα. Αν, για παράδειγμα, παρέχεται περισσότερο από ένα έγγραφο μέσα σε ένα αρχείο `values.yaml`, μόνο το πρώτο θα χρησιμοποιηθεί. Τα αρχεία template, ωστόσο, μπορεί να έχουν περισσότερα από ένα έγγραφα. Όταν συμβαίνει αυτό, το αρχείο (και όλα τα έγγραφά του) αντιμετωπίζεται ως ένα αντικείμενο κατά το rendering του template. Αλλά στη συνέχεια η προκύπτουσα YAML διαχωρίζεται σε πολλαπλά έγγραφα πριν τροφοδοτηθεί στο Kubernetes. Συνιστούμε να χρησιμοποιείτε πολλαπλά έγγραφα ανά αρχείο μόνο όταν είναι απολύτως απαραίτητο. Η ύπαρξη πολλαπλών εγγράφων σε ένα αρχείο μπορεί να είναι δύσκολη στην αποσφαλμάτωση. ## Η YAML είναι Υπερσύνολο της JSON {#yaml-is-a-superset-of-json} Επειδή η YAML είναι υπερσύνολο της JSON, κάθε έγκυρο έγγραφο JSON _θα πρέπει_ να είναι έγκυρη YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Το παραπάνω είναι ένας άλλος τρόπος αναπαράστασης αυτού: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` Και τα δύο μπορούν να αναμειχθούν (με προσοχή): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Και τα τρία πρέπει να αναλυθούν στην ίδια εσωτερική αναπαράσταση. Ενώ αυτό σημαίνει ότι αρχεία όπως το `values.yaml` μπορούν να περιέχουν δεδομένα JSON, το Helm δεν αντιμετωπίζει την επέκταση αρχείου `.json` ως έγκυρο επίθημα. ## YAML Anchors {#yaml-anchors} Η προδιαγραφή YAML παρέχει έναν τρόπο για να αποθηκεύσετε μια αναφορά σε μια τιμή, και αργότερα να αναφερθείτε σε αυτή την τιμή μέσω αναφοράς. Η YAML αναφέρεται σε αυτό ως "anchoring": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` Στο παραπάνω, το `&favoriteCoffee` ορίζει μια αναφορά στο `Cappuccino`. Αργότερα, αυτή η αναφορά χρησιμοποιείται ως `*favoriteCoffee`. Έτσι το `coffees` γίνεται `Latte, Cappuccino, Espresso`. Ενώ υπάρχουν μερικές περιπτώσεις όπου τα anchors είναι χρήσιμα, υπάρχει μια πτυχή τους που μπορεί να προκαλέσει ανεπαίσθητα σφάλματα: Την πρώτη φορά που η YAML καταναλώνεται, η αναφορά επεκτείνεται και στη συνέχεια απορρίπτεται. Έτσι αν αποκωδικοποιούσαμε και στη συνέχεια επανακωδικοποιούσαμε το παραπάνω παράδειγμα, η προκύπτουσα YAML θα ήταν: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Επειδή το Helm και το Kubernetes συχνά διαβάζουν, τροποποιούν και στη συνέχεια ξαναγράφουν αρχεία YAML, τα anchors θα χαθούν. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Αλλαγές από το Helm 2 sidebar_position: 1 --- ## Αλλαγές από το Helm 2 {#changes-since-helm-2} Ακολουθεί μια ολοκληρωμένη λίστα με όλες τις σημαντικές αλλαγές που εισήχθησαν στο Helm 3. ### Κατάργηση του Tiller {#removal-of-tiller} Κατά τη διάρκεια του κύκλου ανάπτυξης του Helm 2, εισαγάγαμε τον Tiller. Ο Tiller διαδραμάτισε σημαντικό ρόλο για ομάδες που εργάζονται σε ένα κοινόχρηστο cluster — releases. Με τον έλεγχο πρόσβασης βάσει ρόλων (RBAC) ενεργοποιημένο από προεπιλογή στο Kubernetes 1.6, η ασφάλιση του Tiller για χρήση σε παραγωγικό περιβάλλον έγινε πιο δύσκολη στη διαχείριση. Λόγω του μεγάλου αριθμού πιθανών πολιτικών ασφαλείας, η προσέγγισή μας ήταν να παρέχουμε μια επιτρεπτική προεπιλεγμένη ρύθμιση. Αυτό επέτρεπε στους νέους χρήστες να ξεκινήσουν να πειραματίζονται με το Helm και το Kubernetes χωρίς να χρειάζεται να εμβαθύνουν αμέσως στους ελέγχους ασφαλείας. Δυστυχώς, αυτή η επιτρεπτική ρύθμιση μπορούσε να δώσει σε έναν χρήστη ένα ευρύ φάσμα δικαιωμάτων που δεν προοριζόταν να έχει. Οι DevOps και SREs έπρεπε να μάθουν επιπλέον διαδικασίες κατά την εγκατάσταση του Tiller σε ένα multi-tenant cluster. Αφού ακούσαμε πώς τα μέλη της κοινότητας χρησιμοποιούσαν το Helm σε διάφορα σενάρια, διαπιστώσαμε ότι το σύστημα διαχείρισης releases του Tiller δεν χρειαζόταν να βασίζεται σε έναν in-cluster operator για να διατηρεί την κατάσταση ή να λειτουργεί ως κεντρικός κόμβος για τις πληροφορίες release του Helm. Αντ' αυτού, μπορούσαμε απλά να ανακτούμε πληροφορίες από τον Kubernetes API server, να κάνουμε render τα Charts στην πλευρά του client και να αποθηκεύουμε μια εγγραφή της εγκατάστασης στο Kubernetes. Ο πρωταρχικός στόχος του Tiller μπορούσε να επιτευχθεί χωρίς τον Tiller, οπότε μία από τις πρώτες αποφάσεις που πήραμε για το Helm 3 ήταν η πλήρης κατάργησή του. Με την κατάργηση του Tiller, το μοντέλο ασφαλείας του Helm απλοποιείται ριζικά. Το Helm 3 υποστηρίζει πλέον όλες τις σύγχρονες δυνατότητες ασφάλειας, ταυτότητας και εξουσιοδότησης του σύγχρονου Kubernetes. Τα δικαιώματα του Helm αξιολογούνται χρησιμοποιώντας το [αρχείο kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) σας. Οι διαχειριστές του cluster μπορούν να περιορίσουν τα δικαιώματα των χρηστών με όποια λεπτομέρεια επιθυμούν. Τα releases εξακολουθούν να καταγράφονται εντός του cluster και η υπόλοιπη λειτουργικότητα του Helm παραμένει αμετάβλητη. ### Βελτιωμένη Στρατηγική Αναβάθμισης: 3-way Strategic Merge Patches {#improved-upgrade-strategy-3-way-strategic-merge-patches} Το Helm 2 χρησιμοποιούσε ένα two-way strategic merge patch. Κατά τη διάρκεια μιας αναβάθμισης, συνέκρινε το manifest του πιο πρόσφατου chart με το προτεινόμενο manifest του chart (αυτό που παρέχεται κατά το `helm upgrade`). Συνέκρινε τις διαφορές μεταξύ αυτών των δύο charts για να προσδιορίσει ποιες αλλαγές έπρεπε να εφαρμοστούν στους πόρους του Kubernetes. Αν εφαρμόζονταν αλλαγές στο cluster εκτός του Helm (όπως κατά τη διάρκεια ενός `kubectl edit`), αυτές οι αλλαγές δεν λαμβάνονταν υπόψη. Αυτό είχε ως αποτέλεσμα οι πόροι να μην μπορούν να επαναφερθούν στην προηγούμενη κατάστασή τους: επειδή το Helm θεωρούσε μόνο το τελευταίο εφαρμοσμένο manifest του chart ως την τρέχουσα κατάσταση, αν δεν υπήρχαν αλλαγές στην κατάσταση του chart, η live κατάσταση παρέμενε αμετάβλητη. Στο Helm 3, χρησιμοποιούμε πλέον ένα three-way strategic merge patch. Το Helm λαμβάνει υπόψη το παλιό manifest, τη live κατάστασή του και το νέο manifest κατά τη δημιουργία ενός patch. #### Παραδείγματα {#examples} Ας δούμε μερικά συνηθισμένα παραδείγματα για το πώς επηρεάζει αυτή η αλλαγή. ##### Επαναφορά όταν η live κατάσταση έχει αλλάξει {#rolling-back-where-live-state-has-changed} Η ομάδα σας μόλις έκανε deploy την εφαρμογή της στο production στο Kubernetes χρησιμοποιώντας το Helm. Το chart περιέχει ένα αντικείμενο Deployment όπου ο αριθμός των replicas έχει οριστεί σε τρία: ```console $ helm install myapp ./myapp ``` Ένας νέος developer εντάσσεται στην ομάδα. Την πρώτη του ημέρα, ενώ παρατηρεί το production cluster, συμβαίνει ένα φρικτό ατύχημα με καφέ που χύνεται στο πληκτρολόγιο και κάνει `kubectl scale` το production deployment από τρία replicas σε μηδέν. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Ένας άλλος developer της ομάδας σας παρατηρεί ότι το production site είναι εκτός λειτουργίας και αποφασίζει να κάνει rollback το release στην προηγούμενη κατάστασή του: ```console $ helm rollback myapp ``` Τι συμβαίνει; Στο Helm 2, θα δημιουργούσε ένα patch συγκρίνοντας το παλιό manifest με το νέο manifest. Επειδή πρόκειται για rollback, είναι το ίδιο manifest. Το Helm θα καθόριζε ότι δεν υπάρχει τίποτα να αλλάξει επειδή δεν υπάρχει διαφορά μεταξύ του παλιού και του νέου manifest. Ο αριθμός των replicas συνεχίζει να παραμένει στο μηδέν. Ακολουθεί πανικός. Στο Helm 3, το patch δημιουργείται χρησιμοποιώντας το παλιό manifest, τη live κατάσταση και το νέο manifest. Το Helm αναγνωρίζει ότι η παλιά κατάσταση ήταν τρία, η live κατάσταση είναι μηδέν και το νέο manifest επιθυμεί να το αλλάξει πίσω σε τρία, οπότε δημιουργεί ένα patch για να επαναφέρει την κατάσταση σε τρία. ##### Αναβαθμίσεις όταν η live κατάσταση έχει αλλάξει {#upgrades-where-live-state-has-changed} Πολλά service meshes και άλλες εφαρμογές που βασίζονται σε controllers εισάγουν δεδομένα σε αντικείμενα Kubernetes. Αυτό μπορεί να είναι κάτι σαν sidecar, labels ή άλλες πληροφορίες. Προηγουμένως, αν είχατε το παρακάτω manifest που προέκυψε από ένα Chart: ```yaml containers: - name: server image: nginx:2.0.0 ``` Και η live κατάσταση τροποποιήθηκε από μια άλλη εφαρμογή σε: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Τώρα, θέλετε να αναβαθμίσετε το image tag του `nginx` σε `2.1.0`. Οπότε, αναβαθμίζετε σε ένα chart με το παρακάτω manifest: ```yaml containers: - name: server image: nginx:2.1.0 ``` Τι συμβαίνει; Στο Helm 2, το Helm δημιουργεί ένα patch του αντικειμένου `containers` μεταξύ του παλιού manifest και του νέου manifest. Η live κατάσταση του cluster δεν λαμβάνεται υπόψη κατά τη δημιουργία του patch. Η live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής: ```yaml containers: - name: server image: nginx:2.1.0 ``` Το sidecar pod αφαιρείται από τη live κατάσταση. Ακολουθεί περισσότερος πανικός. Στο Helm 3, το Helm δημιουργεί ένα patch του αντικειμένου `containers` μεταξύ του παλιού manifest, της live κατάστασης και του νέου manifest. Παρατηρεί ότι το νέο manifest αλλάζει το image tag σε `2.1.0`, αλλά η live κατάσταση περιέχει ένα sidecar container. Η live κατάσταση του cluster τροποποιείται ώστε να μοιάζει με το εξής: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Τα ονόματα Release περιορίζονται πλέον στο Namespace {#release-names-are-now-scoped-to-the-namespace} Με την κατάργηση του Tiller, οι πληροφορίες για κάθε release έπρεπε να αποθηκευτούν κάπου. Στο Helm 2, αυτές αποθηκεύονταν στο ίδιο namespace με τον Tiller. Στην πράξη, αυτό σήμαινε ότι μόλις χρησιμοποιούνταν ένα όνομα από ένα release, κανένα άλλο release δεν μπορούσε να χρησιμοποιήσει το ίδιο όνομα, ακόμα κι αν γινόταν deploy σε διαφορετικό namespace. Στο Helm 3, οι πληροφορίες για ένα συγκεκριμένο release αποθηκεύονται πλέον στο ίδιο namespace με το release. Αυτό σημαίνει ότι οι χρήστες μπορούν πλέον να εκτελέσουν `helm install wordpress stable/wordpress` σε δύο ξεχωριστά namespaces και σε καθένα μπορεί να γίνει αναφορά με `helm list` αλλάζοντας το τρέχον context του namespace (π.χ. `helm list --namespace foo`). Με αυτή τη μεγαλύτερη ευθυγράμμιση με τα native cluster namespaces, η εντολή `helm list` δεν εμφανίζει πλέον όλα τα releases από προεπιλογή. Αντ' αυτού, θα εμφανίσει μόνο τα releases στο namespace του τρέχοντος kubernetes context σας (δηλαδή το namespace που εμφανίζεται όταν εκτελείτε `kubectl config view --minify`). Αυτό σημαίνει επίσης ότι πρέπει να παρέχετε τη σημαία `--all-namespaces` στην εντολή `helm list` για να έχετε συμπεριφορά παρόμοια με το Helm 2. ### Τα Secrets ως προεπιλεγμένος storage driver {#secrets-as-the-default-storage-driver} Στο Helm 3, τα Secrets χρησιμοποιούνται πλέον ως [προεπιλεγμένος storage driver](/topics/advanced.md#storage-backends). Το Helm 2 χρησιμοποιούσε ConfigMaps από προεπιλογή για την αποθήκευση πληροφοριών release. Στο Helm 2.7.0, υλοποιήθηκε ένα νέο storage backend που χρησιμοποιεί Secrets για την αποθήκευση πληροφοριών release, και είναι πλέον η προεπιλογή από το Helm 3. Η αλλαγή σε Secrets ως προεπιλογή του Helm 3 επιτρέπει πρόσθετη ασφάλεια στην προστασία των charts σε συνδυασμό με την κυκλοφορία της κρυπτογράφησης Secret στο Kubernetes. Η [Κρυπτογράφηση secrets σε κατάσταση ηρεμίας](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) έγινε διαθέσιμη ως alpha δυνατότητα στο Kubernetes 1.7 και σταθεροποιήθηκε στο Kubernetes 1.13. Αυτό επιτρέπει στους χρήστες να κρυπτογραφούν τα μεταδεδομένα release του Helm σε κατάσταση ηρεμίας, και αποτελεί ένα καλό σημείο εκκίνησης που μπορεί να επεκταθεί αργότερα για χρήση κάποιου εργαλείου όπως το Vault. ### Αλλαγές στο Go import path {#go-import-path-changes} Στο Helm 3, το Helm άλλαξε το Go import path από `k8s.io/helm` σε `helm.sh/helm/v3`. Αν σκοπεύετε να αναβαθμίσετε στις Go client libraries του Helm 3, φροντίστε να αλλάξετε τα import paths σας. ### Capabilities {#capabilities} Το ενσωματωμένο αντικείμενο `.Capabilities` που είναι διαθέσιμο κατά τη φάση του rendering έχει απλοποιηθεί. [Ενσωματωμένα Αντικείμενα](/chart_template_guide/builtin_objects.md) ### Επικύρωση Chart Values με JSONSchema {#validating-chart-values-with-jsonschema} Ένα JSON Schema μπορεί πλέον να επιβληθεί στα values ενός chart. Αυτό διασφαλίζει ότι τα values που παρέχει ο χρήστης ακολουθούν το schema που έχει ορίσει ο συντηρητής του chart, παρέχοντας καλύτερη αναφορά σφαλμάτων όταν ο χρήστης παρέχει λανθασμένα values για ένα chart. Η επικύρωση πραγματοποιείται όταν εκτελείται οποιαδήποτε από τις παρακάτω εντολές: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Δείτε την τεκμηρίωση για τα [Schema files](/topics/charts.md#schema-files) για περισσότερες πληροφορίες. ### Ενοποίηση του `requirements.yaml` στο `Chart.yaml` {#consolidation-of-requirementsyaml-into-chartyaml} Το σύστημα διαχείρισης εξαρτήσεων Chart μεταφέρθηκε από τα requirements.yaml και requirements.lock στα Chart.yaml και Chart.lock. Συνιστούμε τα νέα charts που προορίζονται για το Helm 3 να χρησιμοποιούν τη νέα μορφή. Ωστόσο, το Helm 3 εξακολουθεί να κατανοεί την έκδοση Chart API 1 (`v1`) και θα φορτώνει υπάρχοντα αρχεία `requirements.yaml`. Στο Helm 2, έτσι έμοιαζε ένα `requirements.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Στο Helm 3, η εξάρτηση εκφράζεται με τον ίδιο τρόπο, αλλά πλέον μέσα στο `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Τα charts εξακολουθούν να κατεβαίνουν και να τοποθετούνται στον κατάλογο `charts/`, οπότε τα subcharts που έχουν ενσωματωθεί στον κατάλογο `charts/` θα συνεχίσουν να λειτουργούν χωρίς τροποποίηση. ### Το Name (ή --generate-name) απαιτείται πλέον κατά την εγκατάσταση {#name-or-generate-name-is-now-required-on-install} Στο Helm 2, αν δεν παρεχόταν όνομα, θα δινόταν ένα αυτόματα παραγόμενο όνομα. Στην παραγωγή, αυτό αποδείχτηκε περισσότερο ενόχληση παρά χρήσιμη δυνατότητα. Στο Helm 3, το Helm θα εμφανίσει σφάλμα αν δεν παρέχεται όνομα με το `helm install`. Για όσους εξακολουθούν να θέλουν να δημιουργείται αυτόματα ένα όνομα, μπορείτε να χρησιμοποιήσετε τη σημαία `--generate-name` για να δημιουργηθεί ένα. ### Αποστολή Charts σε OCI Registries {#pushing-charts-to-oci-registries} Αυτή είναι μια πειραματική δυνατότητα που εισήχθη στο Helm 3. Για να τη χρησιμοποιήσετε, ορίστε τη μεταβλητή περιβάλλοντος `HELM_EXPERIMENTAL_OCI=1`. Σε υψηλό επίπεδο, ένα Chart Repository είναι μια τοποθεσία όπου μπορούν να αποθηκευτούν και να διαμοιραστούν Charts. Ο Helm client συσκευάζει και αποστέλλει Helm Charts σε ένα Chart Repository. Με απλά λόγια, ένα Chart Repository είναι ένας βασικός HTTP server που φιλοξενεί ένα αρχείο index.yaml και μερικά συσκευασμένα charts. Ενώ υπάρχουν αρκετά οφέλη στο ότι το Chart Repository API καλύπτει τις πιο βασικές απαιτήσεις αποθήκευσης, έχουν αρχίσει να εμφανίζονται μερικά μειονεκτήματα: - Τα Chart Repositories δυσκολεύονται πολύ να αφαιρέσουν τις περισσότερες από τις υλοποιήσεις ασφαλείας που απαιτούνται σε ένα παραγωγικό περιβάλλον. Η ύπαρξη ενός τυπικού API για authentication και authorization είναι πολύ σημαντική σε παραγωγικά σενάρια. - Τα εργαλεία provenance του Helm που χρησιμοποιούνται για την υπογραφή και επαλήθευση της ακεραιότητας και προέλευσης ενός chart αποτελούν προαιρετικό μέρος της διαδικασίας δημοσίευσης Chart. - Σε σενάρια multi-tenant, το ίδιο Chart μπορεί να ανεβεί από έναν άλλο tenant, κοστίζοντας διπλάσιο χώρο αποθήκευσης για το ίδιο περιεχόμενο. Έχουν σχεδιαστεί πιο έξυπνα chart repositories για να το αντιμετωπίσουν αυτό, αλλά δεν αποτελεί μέρος της επίσημης προδιαγραφής. - Η χρήση ενός μόνο αρχείου index για αναζήτηση, πληροφορίες μεταδεδομένων και ανάκτηση Charts έχει κάνει δύσκολο ή αδέξιο τον σχεδιασμό σε ασφαλείς υλοποιήσεις multi-tenant. Το project Distribution του Docker (γνωστό και ως Docker Registry v2) είναι ο διάδοχος του project Docker Registry. Πολλοί μεγάλοι cloud vendors προσφέρουν προϊόν βασισμένο στο project Distribution, και με τόσους vendors να προσφέρουν το ίδιο προϊόν, το project Distribution έχει επωφεληθεί από πολλά χρόνια σκληραγώγησης, βέλτιστων πρακτικών ασφαλείας και δοκιμών στην πράξη. Παρακαλούμε δείτε τα `helm help chart` και `helm help registry` για περισσότερες πληροφορίες σχετικά με το πώς να συσκευάσετε ένα chart και να το αποστείλετε σε ένα Docker registry. Για περισσότερες πληροφορίες, δείτε [αυτή τη σελίδα](/topics/registries.md). ### Κατάργηση του `helm serve` {#removal-of-helm-serve} Η εντολή `helm serve` εκτελούσε ένα τοπικό Chart Repository στον υπολογιστή σας για σκοπούς ανάπτυξης. Ωστόσο, δεν είχε μεγάλη υιοθέτηση ως εργαλείο ανάπτυξης και είχε πολλά προβλήματα με τον σχεδιασμό της. Τελικά, αποφασίσαμε να την αφαιρέσουμε και να τη διαχωρίσουμε ως plugin. Για μια παρόμοια εμπειρία με το `helm serve`, δείτε την επιλογή αποθήκευσης σε τοπικό filesystem στο [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) και το [plugin servecm](https://github.com/jdolitsky/helm-servecm). ### Υποστήριξη library chart {#library-chart-support} Το Helm 3 υποστηρίζει μια κατηγορία chart που ονομάζεται "library chart". Αυτό είναι ένα chart που διαμοιράζεται από άλλα charts, αλλά δεν δημιουργεί δικά του release artifacts. Τα templates ενός library chart μπορούν να δηλώνουν μόνο στοιχεία `define`. Περιεχόμενο με global scope που δεν είναι `define` απλά αγνοείται. Αυτό επιτρέπει στους χρήστες να επαναχρησιμοποιούν και να μοιράζονται αποσπάσματα κώδικα που μπορούν να χρησιμοποιηθούν σε πολλά charts, αποφεύγοντας την επανάληψη και διατηρώντας τα charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Τα library charts δηλώνονται στην οδηγία dependencies στο Chart.yaml, και εγκαθίστανται και διαχειρίζονται όπως οποιοδήποτε άλλο chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Είμαστε πολύ ενθουσιασμένοι να δούμε τις περιπτώσεις χρήσης που αυτή η δυνατότητα ανοίγει για τους developers chart, καθώς και τις βέλτιστες πρακτικές που προκύπτουν από τη χρήση library charts. ### Αναβάθμιση του apiVersion στο Chart.yaml {#chartyaml-apiversion-bump} Με την εισαγωγή της υποστήριξης library chart και την ενοποίηση του requirements.yaml στο Chart.yaml, τα clients που κατανοούσαν τη μορφή πακέτου του Helm 2 δεν θα κατανοούν αυτές τις νέες δυνατότητες. Έτσι, αυξήσαμε το apiVersion στο Chart.yaml από `v1` σε `v2`. Η εντολή `helm create` δημιουργεί πλέον charts χρησιμοποιώντας αυτή τη νέα μορφή, οπότε το προεπιλεγμένο apiVersion αυξήθηκε και εκεί. Τα clients που επιθυμούν να υποστηρίζουν και τις δύο εκδόσεις Helm charts θα πρέπει να ελέγχουν το πεδίο `apiVersion` στο Chart.yaml για να κατανοήσουν πώς να αναλύσουν τη μορφή του πακέτου. ### Υποστήριξη XDG Base Directory {#xdg-base-directory-support} Η [Προδιαγραφή XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) είναι ένα φορητό πρότυπο που ορίζει πού θα πρέπει να αποθηκεύονται τα αρχεία ρύθμισης, δεδομένων και cache στο filesystem. Στο Helm 2, το Helm αποθήκευε όλες αυτές τις πληροφορίες στο `~/.helm` (στοργικά γνωστό ως `helm home`), το οποίο μπορούσε να αλλάξει ορίζοντας τη μεταβλητή περιβάλλοντος `$HELM_HOME` ή χρησιμοποιώντας τη global σημαία `--home`. Στο Helm 3, το Helm σέβεται πλέον τις ακόλουθες μεταβλητές περιβάλλοντος σύμφωνα με την Προδιαγραφή XDG Base Directory: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Στα Helm plugins εξακολουθεί να περνιέται το `$HELM_HOME` ως alias για το `$XDG_DATA_HOME` για συμβατότητα προς τα πίσω με plugins που αναζητούν το `$HELM_HOME` ως scratchpad περιβάλλον. Αρκετές νέες μεταβλητές περιβάλλοντος περνιούνται επίσης στο περιβάλλον του plugin για να υποστηρίξουν αυτή την αλλαγή: - `$HELM_PATH_CACHE` για τη διαδρομή cache - `$HELM_PATH_CONFIG` για τη διαδρομή config - `$HELM_PATH_DATA` για τη διαδρομή data Τα Helm plugins που επιθυμούν να υποστηρίξουν το Helm 3 θα πρέπει να εξετάσουν τη χρήση αυτών των νέων μεταβλητών περιβάλλοντος αντί αυτών. ### Μετονομασίες εντολών CLI {#cli-command-renames} Για καλύτερη ευθυγράμμιση της ορολογίας με άλλους package managers, η εντολή `helm delete` μετονομάστηκε σε `helm uninstall`. Η `helm delete` διατηρείται ακόμα ως alias για την `helm uninstall`, οπότε μπορεί να χρησιμοποιηθεί οποιαδήποτε από τις δύο μορφές. Στο Helm 2, για να διαγραφεί το ledger του release, έπρεπε να παρέχεται η σημαία `--purge`. Αυτή η λειτουργικότητα είναι πλέον ενεργοποιημένη από προεπιλογή. Για να διατηρήσετε την προηγούμενη συμπεριφορά, χρησιμοποιήστε `helm uninstall --keep-history`. Επιπλέον, αρκετές άλλες εντολές μετονομάστηκαν για να συμβαδίζουν με τις ίδιες συμβάσεις: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Αυτές οι εντολές έχουν επίσης διατηρήσει τα παλαιότερα ρήματα ως aliases, οπότε μπορείτε να συνεχίσετε να τις χρησιμοποιείτε σε οποιαδήποτε μορφή. ### Αυτόματη δημιουργία namespaces {#automatically-creating-namespaces} Κατά τη δημιουργία ενός release σε ένα namespace που δεν υπάρχει, το Helm 2 δημιουργούσε το namespace. Το Helm 3 ακολουθεί τη συμπεριφορά άλλων εργαλείων Kubernetes και επιστρέφει σφάλμα αν το namespace δεν υπάρχει. Το Helm 3 θα δημιουργήσει το namespace αν ορίσετε ρητά τη σημαία `--create-namespace`. ### Τι συνέβη με το .Chart.ApiVersion; {#what-happened-to-chartapiversion} Το Helm ακολουθεί τη συνηθισμένη σύμβαση CamelCasing που είναι να γράφονται τα αρκτικόλεξα με κεφαλαία. Το έχουμε κάνει αυτό αλλού στον κώδικα, όπως με το `.Capabilities.APIVersions.Has`. Στο Helm v3, διορθώσαμε το `.Chart.ApiVersion` ώστε να ακολουθεί αυτό το μοτίβο, μετονομάζοντάς το σε `.Chart.APIVersion`. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Εγκατάσταση sidebar_position: 2 --- ## Εγκατάσταση {#installing} ### Γιατί δεν υπάρχουν native packages του Helm για Fedora και άλλες διανομές Linux; {#why-arent-there-native-packages-of-helm-for-fedora-and-other-linux-distros} Το project Helm δεν διατηρεί packages για λειτουργικά συστήματα και περιβάλλοντα. Η κοινότητα του Helm μπορεί να παρέχει native packages και αν το project Helm ενημερωθεί γι' αυτά, θα καταχωρηθούν. Με αυτόν τον τρόπο ξεκίνησε και προστέθηκε το Homebrew formula. Αν ενδιαφέρεστε να διατηρήσετε ένα package, θα χαρούμε πολύ. ### Γιατί παρέχετε ένα script `curl ...|bash`; {#why-do-you-provide-a-curl-bash-script} Υπάρχει ένα script στο αποθετήριό μας (`scripts/get-helm-3`) που μπορεί να εκτελεστεί ως script `curl ..|bash`. Όλες οι μεταφορές προστατεύονται μέσω HTTPS και το script πραγματοποιεί κάποιους ελέγχους στα packages που κατεβάζει. Ωστόσο, το script έχει όλους τους συνήθεις κινδύνους οποιουδήποτε shell script. Το παρέχουμε επειδή είναι χρήσιμο, αλλά προτείνουμε στους χρήστες να διαβάσουν προσεκτικά το script πρώτα. Αυτό που πραγματικά θα θέλαμε, ωστόσο, είναι πιο ολοκληρωμένες εκδόσεις του Helm. ### Πώς μπορώ να τοποθετήσω τα αρχεία του Helm client σε διαφορετική θέση από τις προεπιλογές; {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults} Το Helm χρησιμοποιεί τη δομή XDG για την αποθήκευση αρχείων. Υπάρχουν μεταβλητές περιβάλλοντος που μπορείτε να χρησιμοποιήσετε για να παρακάμψετε αυτές τις τοποθεσίες: - `$XDG_CACHE_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση αρχείων cache. - `$XDG_CONFIG_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση της διαμόρφωσης του Helm. - `$XDG_DATA_HOME`: ορίστε μια εναλλακτική τοποθεσία για την αποθήκευση δεδομένων του Helm. Σημειώστε ότι αν έχετε υπάρχοντα αποθετήρια, θα πρέπει να τα προσθέσετε ξανά με την εντολή `helm repo add...`. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Αντιμετώπιση Προβλημάτων sidebar_position: 4 --- ## Αντιμετώπιση Προβλημάτων {#troubleshooting} ### Λαμβάνω μια προειδοποίηση σχετικά με "Unable to get an update from the "stable" chart repository" {#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository} Εκτελέστε `helm repo list`. Αν το αποθετήριο `stable` χρησιμοποιεί URL από το `storage.googleapis.com`, θα πρέπει να το ενημερώσετε. Στις 13 Νοεμβρίου 2020, το αποθετήριο Helm Charts [έπαψε να υποστηρίζεται](https://github.com/helm/charts#deprecation-timeline) μετά από μια περίοδο κατάργησης ενός έτους. Ένα αρχείο είναι διαθέσιμο στο `https://charts.helm.sh/stable` αλλά δεν θα λαμβάνει πλέον ενημερώσεις. Μπορείτε να εκτελέσετε την ακόλουθη εντολή για να διορθώσετε το αποθετήριο σας: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Το ίδιο ισχύει για το αποθετήριο `incubator`, το οποίο έχει ένα αρχείο διαθέσιμο στο https://charts.helm.sh/incubator. Μπορείτε να εκτελέσετε την ακόλουθη εντολή για να το επιδιορθώσετε: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Λαμβάνω την προειδοποίηση 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' {#i-am-getting-the-warning-warning-kubernetes-chartsstoragegoogleapiscom-is-deprecated-for-stable-and-will-be-deleted-nov-13-2020} Το παλιό αποθετήριο chart της Google έχει αντικατασταθεί από ένα νέο αποθετήριο Helm chart. Εκτελέστε την ακόλουθη εντολή για να διορθώσετε αυτό μόνιμα: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Αν λάβετε παρόμοιο σφάλμα για το `incubator`, εκτελέστε αυτή την εντολή: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Όταν προσθέτω ένα Helm repo, λαμβάνω το σφάλμα 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' {#when-i-add-a-helm-repo-i-get-the-error-error-repo-httpskubernetes-chartsstoragegoogleapiscom-is-no-longer-available} Τα αποθετήρια Helm Chart δεν υποστηρίζονται πλέον μετά από [μια περίοδο κατάργησης ενός έτους](https://github.com/helm/charts#deprecation-timeline). Τα αρχεία για αυτά τα αποθετήρια είναι διαθέσιμα στο `https://charts.helm.sh/stable` και `https://charts.helm.sh/incubator`, ωστόσο δεν θα λαμβάνουν πλέον ενημερώσεις. Η εντολή `helm repo add` δεν θα σας επιτρέψει να προσθέσετε τα παλιά URLs εκτός αν καθορίσετε `--use-deprecated-repos`. ### Στο GKE (Google Container Engine) λαμβάνω "No SSH tunnels currently open" {#on-gke-google-container-engine-i-get-no-ssh-tunnels-currently-open} ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Μια άλλη παραλλαγή του μηνύματος σφάλματος είναι: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` Το πρόβλημα είναι ότι το τοπικό σας αρχείο ρυθμίσεων Kubernetes πρέπει να έχει τα σωστά credentials. Όταν δημιουργείτε ένα cluster στο GKE, θα λάβετε credentials, συμπεριλαμβανομένων πιστοποιητικών SSL και αρχών πιστοποίησης. Αυτά πρέπει να αποθηκευτούν σε ένα αρχείο ρυθμίσεων Kubernetes (Προεπιλογή: `~/.kube/config`) ώστε οι `kubectl` και `helm` να έχουν πρόσβαση σε αυτά. ### Μετά τη μετάβαση από το Helm 2, το `helm list` εμφανίζει μόνο μερικά (ή κανένα) από τα releases μου {#after-migration-from-helm-2-helm-list-shows-only-some-or-none-of-my-releases} Πιθανώς δεν έχετε λάβει υπόψη ότι το Helm 3 χρησιμοποιεί πλέον τα namespaces του cluster για τον περιορισμό των releases. Αυτό σημαίνει ότι για όλες τις εντολές που αναφέρονται σε ένα release πρέπει είτε: * να βασίζεστε στο τρέχον namespace στο ενεργό kubernetes context (όπως περιγράφεται από την εντολή `kubectl config view --minify`), * να καθορίσετε το σωστό namespace χρησιμοποιώντας το flag `--namespace`/`-n`, ή * για την εντολή `helm list`, να καθορίσετε το flag `--all-namespaces`/`-A` Αυτό ισχύει για τα `helm ls`, `helm uninstall`, και όλες τις άλλες εντολές `helm` που αναφέρονται σε ένα release. ### Σε macOS, γίνεται πρόσβαση στο αρχείο `/etc/.mdns_debug`. Γιατί; {#on-macos-the-file-etcmdns_debug-is-accessed-why} Γνωρίζουμε μια περίπτωση σε macOS όπου το Helm προσπαθεί να αποκτήσει πρόσβαση σε ένα αρχείο με όνομα `/etc/.mdns_debug`. Αν το αρχείο υπάρχει, το Helm κρατά το file handle ανοιχτό κατά την εκτέλεση. Αυτό προκαλείται από τη βιβλιοθήκη MDNS του macOS. Προσπαθεί να φορτώσει αυτό το αρχείο για να διαβάσει ρυθμίσεις debugging (αν είναι ενεργοποιημένες). Το file handle πιθανώς δεν θα έπρεπε να παραμένει ανοιχτό, και αυτό το ζήτημα έχει αναφερθεί στην Apple. Ωστόσο, είναι το macOS, όχι το Helm, που προκαλεί αυτή τη συμπεριφορά. Αν δεν θέλετε το Helm να φορτώνει αυτό το αρχείο, μπορείτε ίσως να μεταγλωττίσετε το Helm ως static library που δεν χρησιμοποιεί τη στοίβα δικτύου του host. Αυτό θα αυξήσει το μέγεθος του binary του Helm, αλλά θα αποτρέψει το άνοιγμα του αρχείου. Αυτό το ζήτημα αρχικά επισημάνθηκε ως πιθανό πρόβλημα ασφάλειας. Ωστόσο, έχει διαπιστωθεί ότι δεν υπάρχει κανένα ελάττωμα ή ευπάθεια που προκαλείται από αυτή τη συμπεριφορά. ### Το helm repo add αποτυγχάνει ενώ λειτουργούσε παλιότερα {#helm-repo-add-fails-when-it-used-to-work} Στο helm 3.3.1 και παλαιότερα, η εντολή `helm repo add ` δεν έδινε καμία έξοδο αν προσπαθούσατε να προσθέσετε ένα αποθετήριο που υπήρχε ήδη. Το flag `--no-update` θα προκαλούσε σφάλμα αν το αποθετήριο ήταν ήδη καταχωρημένο. Στο helm 3.3.2 και μεταγενέστερα, μια προσπάθεια προσθήκης υπάρχοντος αποθετηρίου θα προκαλέσει σφάλμα: `Error: repository name (reponame) already exists, please specify a different name` Η προεπιλεγμένη συμπεριφορά έχει πλέον αντιστραφεί. Το `--no-update` αγνοείται πλέον, ενώ αν θέλετε να αντικαταστήσετε ένα υπάρχον αποθετήριο, μπορείτε να χρησιμοποιήσετε το `--force-update`. Αυτό οφείλεται σε μια breaking change για διόρθωση ασφαλείας, όπως εξηγείται στις [σημειώσεις έκδοσης του Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Ενεργοποίηση της καταγραφής του Kubernetes client {#enabling-kubernetes-client-logging} Η εκτύπωση μηνυμάτων καταγραφής για τον εντοπισμό σφαλμάτων του Kubernetes client μπορεί να ενεργοποιηθεί χρησιμοποιώντας τα flags του [klog](https://pkg.go.dev/k8s.io/klog). Η χρήση του flag `-v` για να ορίσετε το επίπεδο λεπτομέρειας θα είναι αρκετή για τις περισσότερες περιπτώσεις. Για παράδειγμα: ``` helm list -v 6 ``` ### Οι εγκαταστάσεις Tiller σταμάτησαν να λειτουργούν και η πρόσβαση απορρίπτεται {#tiller-installations-stopped-working-and-access-is-denied} Τα releases του Helm ήταν διαθέσιμα από το . Όπως εξηγείται στο ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/), η επίσημη τοποθεσία άλλαξε τον Ιούνιο του 2019. Το [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) διαθέτει όλα τα παλιά Tiller images. Αν προσπαθείτε να κατεβάσετε παλαιότερες εκδόσεις του Helm από το storage bucket που χρησιμοποιούσατε στο παρελθόν, μπορεί να διαπιστώσετε ότι λείπουν: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` Η [παλιά τοποθεσία Tiller image](https://gcr.io/kubernetes-helm/tiller) ξεκίνησε την αφαίρεση images τον Αύγουστο του 2021. Έχουμε διαθέσει αυτά τα images στην τοποθεσία [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Για παράδειγμα, για να κατεβάσετε την έκδοση v2.17.0, αντικαταστήστε: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` με: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Για να αρχικοποιήσετε με το Helm v2.17.0: `helm init —upgrade` Ή αν χρειάζεται διαφορετική έκδοση, χρησιμοποιήστε το flag --tiller-image για να αντικαταστήσετε την προεπιλεγμένη τοποθεσία και να εγκαταστήσετε μια συγκεκριμένη έκδοση Helm v2: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Σημείωση:** Οι συντηρητές του Helm συνιστούν τη μετάβαση σε μια τρέχουσα υποστηριζόμενη έκδοση του Helm. Το Helm v2.17.0 ήταν η τελική έκδοση του Helm v2· το Helm v2 δεν υποστηρίζεται από τον Νοέμβριο του 2020, όπως αναφέρεται στο [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). Πολλά CVE έχουν αναφερθεί για το Helm από τότε, και αυτές οι ευπάθειες έχουν διορθωθεί στο Helm v3 αλλά δεν θα διορθωθούν ποτέ στο Helm v2. Δείτε την [τρέχουσα λίστα δημοσιευμένων Helm advisories](https://github.com/helm/helm/security/advisories?state=published) και σχεδιάστε τη [μετάβαση στο Helm v3](/topics/v2_v3_migration.md) σήμερα. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Απεγκατάσταση sidebar_position: 3 --- ## Απεγκατάσταση {#uninstalling} ### Θέλω να διαγράψω το τοπικό μου Helm. Πού βρίσκονται όλα τα αρχεία του; {#i-want-to-delete-my-local-helm-where-are-all-its-files} Πέρα από το binary `helm`, το Helm αποθηκεύει ορισμένα αρχεία στις ακόλουθες τοποθεσίες: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME Ο παρακάτω πίνακας δείχνει τον προεπιλεγμένο φάκελο για καθεμία από αυτές, ανά λειτουργικό σύστημα: | Λειτουργικό Σύστημα | Διαδρομή Cache | Διαδρομή Ρυθμίσεων | Διαδρομή Δεδομένων | |---------------------|-----------------------------|----------------------------------|-----------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Ο διαχειριστής πακέτων Helm για το Kubernetes. ### Σύνοψη {#synopsis} Ο διαχειριστής πακέτων του Kubernetes Συνήθεις ενέργειες για το Helm: - helm search: αναζήτηση για charts - helm pull: λήψη ενός chart στον τοπικό σας κατάλογο για προβολή - helm install: μεταφόρτωση του chart στο Kubernetes - helm list: λίστα με τα releases των charts Μεταβλητές περιβάλλοντος: | Όνομα | Περιγραφή | |------------------------------------|-------------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση cached αρχείων. | | $HELM_CONFIG_HOME | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση της διαμόρφωσης του Helm. | | $HELM_DATA_HOME | ορίζει μια εναλλακτική τοποθεσία για την αποθήκευση δεδομένων του Helm. | | $HELM_DEBUG | υποδεικνύει αν το Helm εκτελείται σε λειτουργία Debug | | $HELM_DRIVER | ορίζει το backend storage driver. Τιμές: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | ορίζει το connection string που θα χρησιμοποιήσει το SQL storage driver. | | $HELM_MAX_HISTORY | ορίζει τον μέγιστο αριθμό του ιστορικού εκδόσεων του helm. | | $HELM_NAMESPACE | ορίζει το namespace που χρησιμοποιείται για τις λειτουργίες του helm. | | $HELM_NO_PLUGINS | απενεργοποιεί τα plugins. Ορίστε HELM_NO_PLUGINS=1 για απενεργοποίηση. | | $HELM_PLUGINS | ορίζει τη διαδρομή προς τον κατάλογο των plugins | | $HELM_REGISTRY_CONFIG | ορίζει τη διαδρομή προς το αρχείο διαμόρφωσης του registry. | | $HELM_REPOSITORY_CACHE | ορίζει τη διαδρομή προς τον κατάλογο cache του repository | | $HELM_REPOSITORY_CONFIG | ορίζει τη διαδρομή προς το αρχείο repositories. | | $KUBECONFIG | ορίζει ένα εναλλακτικό αρχείο διαμόρφωσης Kubernetes (προεπιλογή "~/.kube/config") | | $HELM_KUBEAPISERVER | ορίζει το Kubernetes API Server Endpoint για πιστοποίηση | | $HELM_KUBECAFILE | ορίζει το αρχείο certificate authority του Kubernetes. | | $HELM_KUBEASGROUPS | ορίζει τα Groups για προσωποποίηση χρησιμοποιώντας μια λίστα διαχωρισμένη με κόμμα. | | $HELM_KUBEASUSER | ορίζει το Username για προσωποποίηση για τη λειτουργία. | | $HELM_KUBECONTEXT | ορίζει το όνομα του kubeconfig context. | | $HELM_KUBETOKEN | ορίζει το Bearer KubeToken που χρησιμοποιείται για πιστοποίηση. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | υποδεικνύει αν η επαλήθευση του πιστοποιητικού του Kubernetes API server θα πρέπει να παραλειφθεί (μη ασφαλές) | | $HELM_KUBETLS_SERVER_NAME | ορίζει το όνομα διακομιστή που χρησιμοποιείται για την επαλήθευση του πιστοποιητικού του Kubernetes API server | | $HELM_BURST_LIMIT | ορίζει το προεπιλεγμένο όριο burst σε περίπτωση που ο server περιέχει πολλά CRDs (προεπιλογή 100, -1 για απενεργοποίηση) | | $HELM_QPS | ορίζει τα Queries Per Second σε περιπτώσεις όπου ένας υψηλός αριθμός κλήσεων υπερβαίνει την επιλογή για υψηλότερες τιμές burst | Το Helm αποθηκεύει cache, διαμόρφωση και δεδομένα με βάση την ακόλουθη σειρά διαμόρφωσης: - Αν έχει οριστεί μια μεταβλητή περιβάλλοντος HELM_*_HOME, θα χρησιμοποιηθεί αυτή - Διαφορετικά, σε συστήματα που υποστηρίζουν την προδιαγραφή XDG base directory, θα χρησιμοποιηθούν οι μεταβλητές XDG - Όταν δεν έχει οριστεί άλλη τοποθεσία, θα χρησιμοποιηθεί μια προεπιλεγμένη τοποθεσία με βάση το λειτουργικό σύστημα Από προεπιλογή, οι προεπιλεγμένοι κατάλογοι εξαρτώνται από το λειτουργικό σύστημα. Οι προεπιλογές παρατίθενται παρακάτω: | Λειτουργικό Σύστημα | Διαδρομή Cache | Διαδρομή Διαμόρφωσης | Διαδρομή Δεδομένων | |---------------------|---------------------------|--------------------------------|---------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Επιλογές {#options} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm completion](./helm_completion.md) - δημιουργία scripts αυτόματης συμπλήρωσης για το καθορισμένο shell * [helm create](./helm_create.md) - δημιουργία νέου chart με το δοσμένο όνομα * [helm dependency](./helm_dependency.md) - διαχείριση των εξαρτήσεων ενός chart * [helm env](./helm_env.md) - πληροφορίες περιβάλλοντος του Helm client * [helm get](./helm_get.md) - λήψη εκτεταμένων πληροφοριών για ένα συγκεκριμένο release * [helm history](./helm_history.md) - ανάκτηση ιστορικού release * [helm install](./helm_install.md) - εγκατάσταση ενός chart * [helm lint](./helm_lint.md) - εξέταση ενός chart για πιθανά προβλήματα * [helm list](./helm_list.md) - λίστα releases * [helm package](./helm_package.md) - πακετάρισμα ενός καταλόγου chart σε αρχείο chart * [helm plugin](./helm_plugin.md) - εγκατάσταση, λίστα ή απεγκατάσταση Helm plugins * [helm pull](./helm_pull.md) - λήψη ενός chart από ένα repository και (προαιρετικά) αποσυμπίεσή του σε τοπικό κατάλογο * [helm push](./helm_push.md) - αποστολή ενός chart σε απομακρυσμένο server * [helm registry](./helm_registry.md) - σύνδεση ή αποσύνδεση από ένα registry * [helm repo](./helm_repo.md) - προσθήκη, λίστα, αφαίρεση, ενημέρωση και ευρετηρίαση chart repositories * [helm rollback](./helm_rollback.md) - επαναφορά ενός release σε προηγούμενη αναθεώρηση * [helm search](./helm_search.md) - αναζήτηση λέξης-κλειδιού σε charts * [helm show](./helm_show.md) - εμφάνιση πληροφοριών ενός chart * [helm status](./helm_status.md) - εμφάνιση της κατάστασης του συγκεκριμένου release * [helm template](./helm_template.md) - τοπική απόδοση templates * [helm test](./helm_test.md) - εκτέλεση δοκιμών για ένα release * [helm uninstall](./helm_uninstall.md) - απεγκατάσταση ενός release * [helm upgrade](./helm_upgrade.md) - αναβάθμιση ενός release * [helm verify](./helm_verify.md) - επαλήθευση ότι ένα chart στη δοσμένη διαδρομή έχει υπογραφεί και είναι έγκυρο * [helm version](./helm_version.md) - εκτύπωση πληροφοριών έκδοσης του client ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος ### Σύνοψη {#synopsis} Δημιουργεί σενάρια αυτόματης συμπλήρωσης για το Helm για το καθορισμένο κέλυφος. ### Επιλογές {#options} ``` -h, --help help for completion ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. * [helm completion bash](./helm_completion_bash.md) - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το bash * [helm completion fish](./helm_completion_fish.md) - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το fish * [helm completion powershell](./helm_completion_powershell.md) - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το powershell * [helm completion zsh](./helm_completion_zsh.md) - δημιουργεί σενάριο αυτόματης συμπλήρωσης για το zsh ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- δημιουργεί σενάριο αυτόματης συμπλήρωσης για το bash ### Σύνοψη {#synopsis} Δημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος bash. Για να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας: source <(helm completion bash) Για να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Επιλογές {#options} ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm completion](./helm_completion.md) - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- δημιουργεί σενάριο αυτόματης συμπλήρωσης για το fish ### Σύνοψη {#synopsis} Δημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος fish. Για να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας: helm completion fish | source Για να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά: helm completion fish > ~/.config/fish/completions/helm.fish Θα χρειαστεί να ξεκινήσετε ένα νέο κέλυφος για να τεθεί σε ισχύ αυτή η ρύθμιση. ``` helm completion fish [flags] ``` ### Επιλογές {#options} ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm completion](./helm_completion.md) - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- δημιουργεί σενάριο αυτόματης συμπλήρωσης για το powershell ### Σύνοψη {#synopsis} Δημιουργεί το σενάριο αυτόματης συμπλήρωσης για το powershell. Για να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας: PS C:\> helm completion powershell | Out-String | Invoke-Expression Για να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, προσθέστε την έξοδο της παραπάνω εντολής στο powershell profile σας. ``` helm completion powershell [flags] ``` ### Επιλογές {#options} ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm completion](./helm_completion.md) - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- δημιουργεί σενάριο αυτόματης συμπλήρωσης για το zsh ### Σύνοψη {#synopsis} Δημιουργεί το σενάριο αυτόματης συμπλήρωσης για το Helm για το κέλυφος zsh. Για να φορτώσετε την αυτόματη συμπλήρωση στην τρέχουσα συνεδρία του κελύφους σας: source <(helm completion zsh) Για να φορτώσετε την αυτόματη συμπλήρωση για κάθε νέα συνεδρία, εκτελέστε μία φορά: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Επιλογές {#options} ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm completion](./helm_completion.md) - δημιουργεί σενάρια αυτόματης συμπλήρωσης για το καθορισμένο κέλυφος ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- δημιουργεί ένα νέο chart με το δοθέν όνομα ### Σύνοψη {#synopsis} Αυτή η εντολή δημιουργεί έναν κατάλογο chart μαζί με τα κοινά αρχεία και τους καταλόγους που χρησιμοποιούνται σε ένα chart. Για παράδειγμα, η εντολή 'helm create foo' θα δημιουργήσει μια δομή καταλόγου που μοιάζει κάπως έτσι: foo/ ├── .helmignore # Περιέχει μοτίβα που αγνοούνται κατά το πακετάρισμα των Helm charts. ├── Chart.yaml # Πληροφορίες σχετικά με το chart σας ├── values.yaml # Οι προεπιλεγμένες τιμές για τα templates σας ├── charts/ # Charts από τα οποία εξαρτάται αυτό το chart └── templates/ # Τα αρχεία templates └── tests/ # Τα αρχεία δοκιμών Η εντολή 'helm create' δέχεται μια διαδρομή ως όρισμα. Αν οι κατάλογοι στη δοθείσα διαδρομή δεν υπάρχουν, το Helm θα προσπαθήσει να τους δημιουργήσει καθώς προχωρά. Αν ο δοθείς προορισμός υπάρχει και υπάρχουν αρχεία σε αυτόν τον κατάλογο, τα αρχεία που έρχονται σε σύγκρουση θα αντικατασταθούν, αλλά τα υπόλοιπα αρχεία θα παραμείνουν ανέπαφα. ``` helm create NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for create -p, --starter string the name or absolute path to Helm starter scaffold ``` ### Επιλογές που κληρονομούνται από τις γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- διαχείριση εξαρτήσεων ενός chart ### Σύνοψη {#synopsis} Διαχείριση των εξαρτήσεων ενός chart. Τα Helm charts αποθηκεύουν τις εξαρτήσεις τους στον κατάλογο 'charts/'. Για τους προγραμματιστές charts, είναι συχνά πιο εύκολο να διαχειρίζονται τις εξαρτήσεις μέσω του 'Chart.yaml', το οποίο δηλώνει όλες τις εξαρτήσεις. Οι εντολές dependency λειτουργούν με αυτό το αρχείο, διευκολύνοντας τον συγχρονισμό μεταξύ των επιθυμητών εξαρτήσεων και των πραγματικών εξαρτήσεων που αποθηκεύονται στον κατάλογο 'charts/'. Για παράδειγμα, το παρακάτω Chart.yaml δηλώνει δύο εξαρτήσεις: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" Το πεδίο 'name' πρέπει να είναι το όνομα ενός chart, και αυτό το όνομα πρέπει να ταιριάζει με αυτό στο αρχείο 'Chart.yaml' του εν λόγω chart. Το πεδίο 'version' πρέπει να περιέχει μια σημασιολογική έκδοση (SemVer) ή εύρος εκδόσεων. Το URL του 'repository' πρέπει να δείχνει σε ένα Chart Repository. Το Helm αναμένει ότι προσθέτοντας '/index.yaml' στο URL, θα μπορεί να ανακτήσει το ευρετήριο του αποθετηρίου. Σημείωση: το 'repository' μπορεί να είναι ψευδώνυμο. Το ψευδώνυμο πρέπει να ξεκινά με 'alias:' ή '@'. Από την έκδοση 2.2.0 και μετά, το repository μπορεί να οριστεί ως διαδρομή προς τον κατάλογο των εξαρτημένων charts που είναι αποθηκευμένα τοπικά. Η διαδρομή πρέπει να ξεκινά με το πρόθεμα "file://". Για παράδειγμα, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" Αν το εξαρτημένο chart ανακτάται τοπικά, δεν απαιτείται να έχει προστεθεί το αποθετήριο στο Helm μέσω της εντολής "helm repo add". Η αντιστοίχιση εκδόσεων υποστηρίζεται και σε αυτήν την περίπτωση. ### Επιλογές {#options} ``` -h, --help help for dependency ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. * [helm dependency build](./helm_dependency_build.md) - ανακατασκευή του καταλόγου charts/ με βάση το αρχείο Chart.lock * [helm dependency list](./helm_dependency_list.md) - εμφάνιση των εξαρτήσεων για ένα συγκεκριμένο chart * [helm dependency update](./helm_dependency_update.md) - ενημέρωση του καταλόγου charts/ με βάση τα περιεχόμενα του Chart.yaml ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- ανακατασκευή του καταλόγου charts/ με βάση το αρχείο Chart.lock ### Σύνοψη {#synopsis} Κατασκευάζει τον κατάλογο charts/ από το αρχείο Chart.lock. Η εντολή build χρησιμοποιείται για την ανακατασκευή των εξαρτήσεων ενός chart στην κατάσταση που καθορίζεται στο αρχείο lock. Δεν θα επαναδιαπραγματευτεί τις εξαρτήσεις, όπως κάνει η εντολή 'helm dependency update'. Αν δεν βρεθεί αρχείο lock, η 'helm dependency build' θα συμπεριφερθεί όπως η 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm dependency](./helm_dependency.md) - διαχείριση εξαρτήσεων ενός chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- εμφάνιση των εξαρτήσεων για ένα δεδομένο chart ### Σύνοψη {#synopsis} Εμφανίζει όλες τις εξαρτήσεις που έχουν δηλωθεί σε ένα chart. Μπορεί να δεχθεί αρχεία chart και καταλόγους chart ως είσοδο. Δεν θα τροποποιήσει τα περιεχόμενα ενός chart. Θα εμφανίσει σφάλμα αν το chart δεν μπορεί να φορτωθεί. ``` helm dependency list CHART [flags] ``` ### Επιλογές {#options} ``` -h, --help help for list --max-col-width uint maximum column width for output table (default 80) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm dependency](./helm_dependency.md) - διαχείριση εξαρτήσεων ενός chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- ενημέρωση του καταλόγου charts/ με βάση τα περιεχόμενα του Chart.yaml ### Σύνοψη {#synopsis} Ενημερώνει τις εξαρτήσεις στον τοπικό δίσκο σύμφωνα με το Chart.yaml. Αυτή η εντολή επαληθεύει ότι τα απαιτούμενα charts, όπως ορίζονται στο 'Chart.yaml', υπάρχουν στον κατάλογο 'charts/' και είναι σε αποδεκτή έκδοση. Θα κατεβάσει τα πιο πρόσφατα charts που ικανοποιούν τις εξαρτήσεις και θα καθαρίσει τις παλιές εξαρτήσεις. Μετά από επιτυχή ενημέρωση, θα δημιουργηθεί ένα αρχείο lock που μπορεί να χρησιμοποιηθεί για την ανακατασκευή των εξαρτήσεων σε μια ακριβή έκδοση. Οι εξαρτήσεις δεν απαιτείται να αναπαρίστανται στο 'Chart.yaml'. Για αυτόν τον λόγο, μια εντολή ενημέρωσης δεν θα αφαιρέσει charts εκτός αν αυτά (α) υπάρχουν στο αρχείο Chart.yaml, αλλά (β) είναι σε λάθος έκδοση. ``` helm dependency update CHART [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm dependency](/helm/helm_dependency.md) - διαχείριση εξαρτήσεων ενός chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- εμφανίζει τις πληροφορίες περιβάλλοντος του Helm client ### Σύνοψη {#synopsis} Εκτυπώνει όλες τις πληροφορίες περιβάλλοντος που χρησιμοποιεί το Helm. ``` helm env [flags] ``` ### Επιλογές {#options} ``` -h, --help help for env ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή αποτελείται από πολλαπλές υποεντολές που μπορούν να χρησιμοποιηθούν για την ανάκτηση εκτεταμένων πληροφοριών σχετικά με ένα release, όπως: - Οι τιμές που χρησιμοποιήθηκαν για τη δημιουργία του release - Το παραγόμενο αρχείο manifest - Τα notes που παρέχονται από το chart του release - Τα hooks που σχετίζονται με το release - Τα μεταδεδομένα του release ### Επιλογές {#options} ``` -h, --help help for get ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. * [helm get all](./helm_get_all.md) - κατεβάζει όλες τις πληροφορίες για ένα δεδομένο release * [helm get hooks](./helm_get_hooks.md) - κατεβάζει όλα τα hooks για ένα δεδομένο release * [helm get manifest](./helm_get_manifest.md) - κατεβάζει το manifest για ένα δεδομένο release * [helm get metadata](./helm_get_metadata.md) - ανακτά τα μεταδεδομένα για ένα δεδομένο release * [helm get notes](./helm_get_notes.md) - κατεβάζει τα notes για ένα δεδομένο release * [helm get values](./helm_get_values.md) - κατεβάζει το αρχείο values για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- κατεβάζει όλες τις πληροφορίες για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή εκτυπώνει μια αναγνώσιμη συλλογή πληροφοριών σχετικά με τα notes, τα hooks, τις παρεχόμενες τιμές (values) και το παραγόμενο αρχείο manifest του δεδομένου release. ``` helm get all RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- κατεβάζει όλα τα hooks για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή κατεβάζει hooks για ένα δεδομένο release. Τα hooks παρέχονται σε μορφή YAML και διαχωρίζονται με το διαχωριστικό YAML '---\n'. ``` helm get hooks RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for hooks --revision int get the named release with revision ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- κατεβάζει το manifest για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή ανακτά το παραγόμενο manifest για ένα δεδομένο release. Ένα manifest είναι μια αναπαράσταση σε μορφή YAML των πόρων Kubernetes που δημιουργήθηκαν από το chart (ή τα charts) αυτού του release. Αν ένα chart εξαρτάται από άλλα charts, αυτοί οι πόροι θα συμπεριληφθούν επίσης στο manifest. ``` helm get manifest RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for manifest --revision int get the named release with revision ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Αυτή η εντολή ανακτά τα metadata για ένα δεδομένο release ``` helm get metadata RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- κατεβάζει τις σημειώσεις για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή εμφανίζει τις σημειώσεις που παρέχονται από το chart ενός δεδομένου release. ``` helm get notes RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for notes --revision int get the named release with revision ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- κατεβάζει το αρχείο values για ένα δεδομένο release ### Σύνοψη {#synopsis} Αυτή η εντολή κατεβάζει το αρχείο values για ένα δεδομένο release. ``` helm get values RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm get](./helm_get.md) - ανακτά εκτεταμένες πληροφορίες για ένα δεδομένο release ###### Auto generated by spf13/cobra on 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- ανακτά το ιστορικό ενός release ### Σύνοψη {#synopsis} Η εντολή history εμφανίζει τις ιστορικές αναθεωρήσεις για ένα δεδομένο release. Από προεπιλογή, επιστρέφονται έως 256 αναθεωρήσεις. Χρησιμοποιήστε το flag '--max' για να ορίσετε το μέγιστο μήκος της λίστας αναθεωρήσεων που επιστρέφεται. Το σύνολο των ιστορικών releases εμφανίζεται ως μορφοποιημένος πίνακας, π.χ.: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for history --max int maximum number of revision to include in history (default 256) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- εγκαθιστά ένα chart ### Σύνοψη {#synopsis} Αυτή η εντολή εγκαθιστά ένα αρχείο chart. Το όρισμα εγκατάστασης πρέπει να είναι μια αναφορά chart, μια διαδρομή προς ένα πακεταρισμένο chart, μια διαδρομή προς έναν αποσυμπιεσμένο κατάλογο chart ή ένα URL. Για να παρακάμψετε τιμές σε ένα chart, χρησιμοποιήστε είτε το flag '--values' και περάστε ένα αρχείο, είτε το flag '--set' και περάστε ρυθμίσεις από τη γραμμή εντολών. Για να ορίσετε μια τιμή ως string χρησιμοποιήστε '--set-string'. Μπορείτε να χρησιμοποιήσετε '--set-file' για να ορίσετε μεμονωμένες τιμές από αρχείο όταν η τιμή είναι πολύ μεγάλη για τη γραμμή εντολών ή δημιουργείται δυναμικά. Μπορείτε επίσης να χρησιμοποιήσετε '--set-json' για να ορίσετε τιμές JSON (scalars/objects/arrays) από τη γραμμή εντολών. $ helm install -f myvalues.yaml myredis ./redis ή $ helm install --set name=prod myredis ./redis ή $ helm install --set-string long_int=1234567890 myredis ./redis ή $ helm install --set-file my_script=dothings.sh myredis ./redis ή $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Μπορείτε να καθορίσετε το flag '--values'/'-f' πολλές φορές. Προτεραιότητα θα δοθεί στο τελευταίο (δεξιότερο) αρχείο που καθορίζεται. Για παράδειγμα, αν και τα δύο αρχεία myvalues.yaml και override.yaml περιέχουν ένα κλειδί με όνομα 'Test', η τιμή που ορίζεται στο override.yaml θα υπερισχύσει: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Μπορείτε να καθορίσετε το flag '--set' πολλές φορές. Προτεραιότητα θα δοθεί στην τελευταία (δεξιότερη) τιμή. Για παράδειγμα, αν και οι δύο τιμές 'bar' και 'newbar' οριστούν για ένα κλειδί με όνομα 'foo', η τιμή 'newbar' θα υπερισχύσει: $ helm install --set foo=bar --set foo=newbar myredis ./redis Παρόμοια, στο παρακάτω παράδειγμα το 'foo' ορίζεται ως '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis Και στο παρακάτω παράδειγμα, το 'foo' ορίζεται ως '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Για να ελέγξετε τα δημιουργημένα manifests ενός release χωρίς να εγκαταστήσετε το chart, μπορείτε να συνδυάσετε τα flags --debug και --dry-run. Το flag --dry-run θα εξάγει όλα τα δημιουργημένα manifests του chart, συμπεριλαμβανομένων των Secrets που μπορεί να περιέχουν ευαίσθητες τιμές. Για να αποκρύψετε τα Kubernetes Secrets χρησιμοποιήστε το flag --hide-secret. Παρακαλούμε σκεφτείτε προσεκτικά πώς και πότε χρησιμοποιούνται αυτά τα flags. Αν οριστεί το --verify, το chart ΠΡΕΠΕΙ να έχει αρχείο provenance, και το αρχείο provenance ΠΡΕΠΕΙ να περάσει όλα τα βήματα επαλήθευσης. Υπάρχουν έξι διαφορετικοί τρόποι να καθορίσετε το chart που θέλετε να εγκαταστήσετε: 1. Μέσω αναφοράς chart: helm install mymaria example/mariadb 2. Μέσω διαδρομής προς πακεταρισμένο chart: helm install mynginx ./nginx-1.2.3.tgz 3. Μέσω διαδρομής προς αποσυμπιεσμένο κατάλογο chart: helm install mynginx ./nginx 4. Μέσω απόλυτου URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. Μέσω αναφοράς chart και URL αποθετηρίου: helm install --repo https://example.com/charts/ mynginx nginx 6. Μέσω OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx ΑΝΑΦΟΡΕΣ CHART Μια αναφορά chart είναι ένας βολικός τρόπος να αναφερθείτε σε ένα chart μέσα σε ένα αποθετήριο chart. Όταν χρησιμοποιείτε μια αναφορά chart με πρόθεμα αποθετηρίου ('example/mariadb'), το Helm θα αναζητήσει στην τοπική ρύθμιση για ένα αποθετήριο chart με όνομα 'example', και στη συνέχεια θα αναζητήσει ένα chart σε αυτό το αποθετήριο με όνομα 'mariadb'. Θα εγκαταστήσει την τελευταία σταθερή έκδοση αυτού του chart εκτός αν καθορίσετε το flag '--devel' για να συμπεριλάβετε και εκδόσεις ανάπτυξης (alpha, beta και release candidate), ή προσδιορίσετε έναν αριθμό έκδοσης με το flag '--version'. Για να δείτε τη λίστα των αποθετηρίων chart, χρησιμοποιήστε 'helm repo list'. Για να αναζητήσετε charts σε ένα αποθετήριο, χρησιμοποιήστε 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Επιλογές {#options} ``` --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](./helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- εξέταση ενός chart για πιθανά προβλήματα ### Σύνοψη {#synopsis} Αυτή η εντολή δέχεται μια διαδρομή προς ένα chart και εκτελεί μια σειρά δοκιμών για να επαληθεύσει ότι το chart είναι σωστά διαμορφωμένο. Αν ο linter συναντήσει πράγματα που θα προκαλέσουν αποτυχία της εγκατάστασης του chart, θα εμφανίσει μηνύματα [ERROR]. Αν συναντήσει ζητήματα που αποκλίνουν από τις συμβάσεις ή τις συστάσεις, θα εμφανίσει μηνύματα [WARNING]. ``` helm lint PATH [flags] ``` ### Επιλογές {#options} ``` -h, --help help for lint --kube-version string Kubernetes version used for capabilities and deprecation checks --quiet print only warnings and errors --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-schema-validation if set, disables JSON schema validation --strict fail on lint warnings -f, --values strings specify values in a YAML file or a URL (can specify multiple) --with-subcharts lint dependent charts ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- λίστα release ### Σύνοψη {#synopsis} Αυτή η εντολή εμφανίζει όλα τα release για ένα συγκεκριμένο namespace (χρησιμοποιεί το τρέχον namespace context αν δεν καθοριστεί namespace). Από προεπιλογή, εμφανίζει μόνο release με κατάσταση deployed ή failed. Σημαίες όπως '--uninstalled' και '--all' θα αλλάξουν αυτή τη συμπεριφορά. Αυτές οι σημαίες μπορούν να συνδυαστούν: '--uninstalled --failed'. Από προεπιλογή, τα στοιχεία ταξινομούνται αλφαβητικά. Χρησιμοποιήστε τη σημαία '-d' για ταξινόμηση κατά ημερομηνία release. Αν δοθεί η σημαία --filter, θα χρησιμοποιηθεί ως φίλτρο. Τα φίλτρα είναι κανονικές εκφράσεις (συμβατές με Perl) που εφαρμόζονται στη λίστα των release. Μόνο τα στοιχεία που ταιριάζουν με το φίλτρο θα επιστραφούν. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Αν δεν βρεθούν αποτελέσματα, το 'helm list' θα επιστρέψει κωδικό 0, αλλά χωρίς έξοδο (ή στην περίπτωση χωρίς σημαία '-q', μόνο επικεφαλίδες). Από προεπιλογή, μπορούν να επιστραφούν έως 256 στοιχεία. Για να περιορίσετε αυτό, χρησιμοποιήστε τη σημαία '--max'. Η ρύθμιση '--max' σε 0 δεν θα επιστρέψει όλα τα αποτελέσματα. Αντίθετα, θα επιστρέψει την προεπιλεγμένη τιμή του server, η οποία μπορεί να είναι πολύ μεγαλύτερη από 256. Ο συνδυασμός της σημαίας '--max' με τη σημαία '--offset' σας επιτρέπει να περιηγηθείτε στα αποτελέσματα ανά σελίδα. ``` helm list [flags] ``` ### Επιλογές {#options} ``` -a, --all show all releases without any filter applied -A, --all-namespaces list releases across all namespaces -d, --date sort by release date --deployed show deployed releases. If no other is specified, this will be automatically enabled --failed show failed releases -f, --filter string a regular expression (Perl compatible). Any releases that match the expression will be included in the results -h, --help help for list -m, --max int maximum number of releases to fetch (default 256) --no-headers don't print headers when using the default output format --offset int next release index in the list, used to offset from start value -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pending show pending releases -r, --reverse reverse the sort order -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Works only for secret(default) and configmap storage backends. -q, --short output short (quiet) listing format --superseded show superseded releases --time-format string format time using golang time formatter. Example: --time-format "2006-01-02 15:04:05Z0700" --uninstalled show uninstalled releases (if 'helm uninstall --keep-history' was used) --uninstalling show releases that are currently being uninstalled ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- πακετάρισμα καταλόγου chart σε αρχείο chart ### Σύνοψη {#synopsis} Αυτή η εντολή πακετάρει ένα chart σε αρχείο chart με έκδοση. Αν δοθεί μια διαδρομή, θα αναζητηθεί σε αυτή τη διαδρομή ένα chart (το οποίο πρέπει να περιέχει αρχείο Chart.yaml) και στη συνέχεια θα πακεταριστεί αυτός ο κατάλογος. Τα αρχεία chart με έκδοση χρησιμοποιούνται από τα αποθετήρια πακέτων Helm. Για να υπογράψετε ένα chart, χρησιμοποιήστε την επιλογή '--sign'. Στις περισσότερες περιπτώσεις, θα πρέπει επίσης να δώσετε '--keyring path/to/secret/keys' και '--key keyname'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg Αν δεν καθοριστεί η επιλογή '--keyring', το Helm συνήθως χρησιμοποιεί το δημόσιο keyring εκτός αν το περιβάλλον σας έχει ρυθμιστεί διαφορετικά. ``` helm package [CHART_PATH] [...] [flags] ``` ### Επιλογές {#options} ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins ### Σύνοψη {#synopsis} Διαχειρίζεται τα client-side Helm plugins. ### Επιλογές {#options} ``` -h, --help help for plugin ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) - εγκαθιστά ένα Helm plugin * [helm plugin list](/helm/helm_plugin_list.md) - εμφανίζει τα εγκατεστημένα Helm plugins * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - απεγκαθιστά ένα ή περισσότερα Helm plugins * [helm plugin update](/helm/helm_plugin_update.md) - ενημερώνει ένα ή περισσότερα Helm plugins ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- εγκαθιστά ένα Helm plugin ### Σύνοψη {#synopsis} Με αυτή την εντολή μπορείτε να εγκαταστήσετε ένα plugin από ένα URL προς αποθετήριο VCS ή από τοπική διαδρομή. ``` helm plugin install [options] [flags] ``` ### Επιλογές {#options} ``` -h, --help help for install --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm plugin](/helm/helm_plugin.md) - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- εμφανίζει τα εγκατεστημένα Helm plugins ``` helm plugin list [flags] ``` ### Επιλογές {#options} ``` -h, --help help for list ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm plugin](/helm/helm_plugin.md) - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- απεγκαθιστά ένα ή περισσότερα Helm plugins ``` helm plugin uninstall ... [flags] ``` ### Επιλογές {#options} ``` -h, --help help for uninstall ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm plugin](/helm/helm_plugin.md) - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- ενημερώνει ένα ή περισσότερα Helm plugins ``` helm plugin update ... [flags] ``` ### Επιλογές {#options} ``` -h, --help help for update ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm plugin](/helm/helm_plugin.md) - εγκαθιστά, εμφανίζει ή απεγκαθιστά Helm plugins ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- λήψη chart από αποθετήριο με προαιρετική τοπική αποσυμπίεση ### Σύνοψη {#synopsis} Ανακτά ένα πακέτο από αποθετήριο πακέτων και το κατεβάζει τοπικά. Αυτό είναι χρήσιμο για λήψη πακέτων ώστε να τα επιθεωρήσετε, τροποποιήσετε ή επανασυσκευάσετε. Μπορεί επίσης να χρησιμοποιηθεί για κρυπτογραφική επαλήθευση ενός chart χωρίς να το εγκαταστήσετε. Υπάρχουν επιλογές για αποσυμπίεση του chart μετά τη λήψη. Αυτό θα δημιουργήσει έναν κατάλογο για το chart και θα αποσυμπιέσει τα περιεχόμενα σε αυτόν. Αν καθοριστεί η επιλογή --verify, το ζητούμενο chart ΠΡΕΠΕΙ να έχει αρχείο provenance και ΠΡΕΠΕΙ να περάσει τη διαδικασία επαλήθευσης. Σε περίπτωση αποτυχίας, το chart δεν θα αποθηκευτεί τοπικά. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- αποστολή chart σε απομακρυσμένο registry ### Σύνοψη {#synopsis} Ανεβάζει ένα chart σε registry. Αν υπάρχει συσχετισμένο αρχείο provenance, θα ανεβεί επίσης. ``` helm push [chart] [remote] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- σύνδεση ή αποσύνδεση από ένα registry ### Σύνοψη {#synopsis} Αυτή η εντολή αποτελείται από πολλές υποεντολές για αλληλεπίδραση με registries. ### Επιλογές {#options} ``` -h, --help help for registry ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. * [helm registry login](/helm/helm_registry_login.md) - σύνδεση σε ένα registry * [helm registry logout](/helm/helm_registry_logout.md) - αποσύνδεση από ένα registry ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- σύνδεση σε ένα registry ### Σύνοψη {#synopsis} Πραγματοποιεί πιστοποίηση σε ένα απομακρυσμένο registry. ``` helm registry login [host] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm registry](/helm/helm_registry.md) - σύνδεση ή αποσύνδεση από ένα registry ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- αποσύνδεση από ένα registry ### Σύνοψη {#synopsis} Αφαιρεί τα διαπιστευτήρια που είναι αποθηκευμένα για ένα απομακρυσμένο registry. ``` helm registry logout [host] [flags] ``` ### Επιλογές {#options} ``` -h, --help help for logout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm registry](/helm/helm_registry.md) - σύνδεση ή αποσύνδεση από ένα registry ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ### Σύνοψη {#synopsis} Η εντολή αποτελείται από πολλές υποεντολές για διαχείριση αποθετηρίων chart. Χρησιμοποιήστε την για να προσθέσετε, αφαιρέσετε, εμφανίσετε και δημιουργήσετε ευρετήριο αποθετηρίων chart. ### Επιλογές {#options} ``` -h, --help help for repo ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. * [helm repo add](/helm/helm_repo_add.md) - προσθέτει ένα αποθετήριο chart * [helm repo index](/helm/helm_repo_index.md) - δημιουργεί ένα αρχείο ευρετηρίου για έναν κατάλογο που περιέχει πακεταρισμένα charts * [helm repo list](/helm/helm_repo_list.md) - εμφανίζει τα αποθετήρια chart * [helm repo remove](/helm/helm_repo_remove.md) - αφαιρεί ένα ή περισσότερα αποθετήρια chart * [helm repo update](/helm/helm_repo_update.md) - ενημερώνει τοπικά τις πληροφορίες για διαθέσιμα charts από τα αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- προσθέτει ένα αποθετήριο chart ``` helm repo add [NAME] [URL] [flags] ``` ### Επιλογές {#options} ``` --allow-deprecated-repos by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --force-update replace (overwrite) the repo if it already exists -h, --help help for add --insecure-skip-tls-verify skip tls certificate checks for the repository --key-file string identify HTTPS client using this SSL key file --no-update Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update. --pass-credentials pass credentials to all domains --password string chart repository password --password-stdin read chart repository password from stdin --timeout duration time to wait for the index file download to complete (default 2m0s) --username string chart repository username ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm repo](/helm/helm_repo.md) - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- δημιουργεί ένα αρχείο ευρετηρίου για έναν κατάλογο που περιέχει πακεταρισμένα charts ### Σύνοψη {#synopsis} Διαβάζει τον τρέχοντα κατάλογο, δημιουργεί ένα αρχείο ευρετηρίου βασισμένο στα charts που βρέθηκαν και γράφει το αποτέλεσμα στο 'index.yaml' στον τρέχοντα κατάλογο. Αυτό το εργαλείο χρησιμοποιείται για τη δημιουργία ενός αρχείου 'index.yaml' για ένα αποθετήριο chart. Για να ορίσετε απόλυτο URL για τα charts, χρησιμοποιήστε τη σημαία '--url'. Για να συγχωνεύσετε το παραγόμενο ευρετήριο με ένα υπάρχον αρχείο ευρετηρίου, χρησιμοποιήστε τη σημαία '--merge'. Σε αυτή την περίπτωση, τα charts που βρέθηκαν στον τρέχοντα κατάλογο θα συγχωνευθούν με το ευρετήριο που δόθηκε μέσω της --merge, δίνοντας προτεραιότητα στα τοπικά charts. ``` helm repo index [DIR] [flags] ``` ### Επιλογές {#options} ``` -h, --help help for index --json output in JSON format --merge string merge the generated index into the given index --url string url of chart repository ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm repo](/helm/helm_repo.md) - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- εμφανίζει τα αποθετήρια chart ``` helm repo list [flags] ``` ### Επιλογές {#options} ``` -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm repo](/helm/helm_repo.md) - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- αφαιρεί ένα ή περισσότερα αποθετήρια chart ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Επιλογές {#options} ``` -h, --help help for remove ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm repo](/helm/helm_repo.md) - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- ενημερώνει τοπικά τις πληροφορίες για διαθέσιμα charts από τα αποθετήρια chart ### Σύνοψη {#synopsis} Η εντολή update ανακτά τις πιο πρόσφατες πληροφορίες για charts από τα αντίστοιχα αποθετήρια chart. Οι πληροφορίες αποθηκεύονται τοπικά στην προσωρινή μνήμη (cache), όπου χρησιμοποιούνται από εντολές όπως η 'helm search'. Μπορείτε προαιρετικά να καθορίσετε μια λίστα αποθετηρίων που θέλετε να ενημερώσετε. $ helm repo update ... Για να ενημερώσετε όλα τα αποθετήρια, χρησιμοποιήστε 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Επιλογές {#options} ``` --fail-on-repo-update-fail update fails if any of the repository updates fail -h, --help help for update --timeout duration time to wait for the index file download to complete (default 2m0s) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm repo](/helm/helm_repo.md) - προσθέτει, εμφανίζει, αφαιρεί, ενημερώνει και δημιουργεί ευρετήριο για αποθετήρια chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- επαναφέρει ένα release σε προηγούμενη αναθεώρηση ### Σύνοψη {#synopsis} Αυτή η εντολή επαναφέρει ένα release σε μια προηγούμενη αναθεώρηση. Το πρώτο όρισμα της εντολής rollback είναι το όνομα ενός release, και το δεύτερο είναι ένας αριθμός αναθεώρησης (έκδοσης). Αν αυτό το όρισμα παραλειφθεί ή οριστεί σε 0, θα γίνει επαναφορά στο προηγούμενο release. Για να δείτε τους αριθμούς αναθεωρήσεων, εκτελέστε 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Επιλογές {#options} ``` --cleanup-on-fail allow deletion of new resources created in this rollback when rollback fails --dry-run simulate a rollback --force force resource update through delete/recreate if needed -h, --help help for rollback --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --no-hooks prevent hooks from running during rollback --recreate-pods performs pods restart for the resource if applicable --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- αναζητά μια λέξη-κλειδί σε charts ### Σύνοψη {#synopsis} Η εντολή search παρέχει τη δυνατότητα αναζήτησης Helm charts στα διάφορα μέρη όπου μπορούν να αποθηκευτούν, συμπεριλαμβανομένου του Artifact Hub και των αποθετηρίων που έχετε προσθέσει. Χρησιμοποιήστε τις υποεντολές search για αναζήτηση σε διαφορετικές τοποθεσίες. ### Επιλογές {#options} ``` -h, --help help for search ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. * [helm search hub](/helm/helm_search_hub.md) - αναζητά charts στο Artifact Hub ή στη δική σας hub instance * [helm search repo](/helm/helm_search_repo.md) - αναζητά charts στα αποθετήρια με βάση μια λέξη-κλειδί ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- αναζητά charts στο Artifact Hub ή στη δική σας hub instance ### Σύνοψη {#synopsis} Αναζητά Helm charts στο Artifact Hub ή στη δική σας hub instance. Το Artifact Hub είναι μια διαδικτυακή εφαρμογή που επιτρέπει την εύρεση, εγκατάσταση και δημοσίευση πακέτων και ρυθμίσεων για έργα του CNCF, συμπεριλαμβανομένων δημόσια διαθέσιμων Helm charts. Είναι ένα sandbox project του Cloud Native Computing Foundation. Μπορείτε να περιηγηθείτε στο hub στη διεύθυνση https://artifacthub.io/ Το όρισμα [KEYWORD] δέχεται είτε μια λέξη-κλειδί, είτε ένα string σε εισαγωγικά με επιλογές προηγμένης αναζήτησης. Για τεκμηρίωση των επιλογών προηγμένης αναζήτησης, δείτε https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Προηγούμενες εκδόσεις του Helm χρησιμοποιούσαν μια instance του Monocular ως προεπιλεγμένο 'endpoint', οπότε για συμβατότητα προς τα πίσω το Artifact Hub είναι συμβατό με το Monocular search API. Ομοίως, όταν ορίζετε τη σημαία 'endpoint', το καθορισμένο endpoint πρέπει επίσης να υλοποιεί ένα συμβατό Monocular search API endpoint. Όταν καθορίζετε μια Monocular instance ως 'endpoint', η προηγμένη αναζήτηση δεν υποστηρίζεται. Για λεπτομέρειες του API, δείτε https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Επιλογές {#options} ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm search](/helm/helm_search.md) - αναζητά μια λέξη-κλειδί σε charts ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- αναζητά charts στα αποθετήρια με βάση μια λέξη-κλειδί ### Σύνοψη {#synopsis} Η εντολή search διαβάζει όλα τα αποθετήρια που έχουν ρυθμιστεί στο σύστημα και αναζητά αντιστοιχίες. Η αναζήτηση σε αυτά τα αποθετήρια χρησιμοποιεί τα μεταδεδομένα που είναι αποθηκευμένα στο σύστημα. Εμφανίζει τις τελευταίες σταθερές εκδόσεις των charts που βρέθηκαν. Με τη σημαία --devel, τα αποτελέσματα περιλαμβάνουν και εκδόσεις προ-κυκλοφορίας. Για αναζήτηση με περιορισμό έκδοσης, χρησιμοποιήστε --version. Παραδείγματα: # Αναζήτηση σταθερών εκδόσεων με λέξη-κλειδί "nginx" $ helm search repo nginx # Αναζήτηση εκδόσεων με λέξη-κλειδί "nginx", συμπεριλαμβανομένων εκδόσεων προ-κυκλοφορίας $ helm search repo nginx --devel # Αναζήτηση της τελευταίας σταθερής έκδοσης nginx-ingress με κύρια έκδοση 1 $ helm search repo nginx-ingress --version ^1.0.0 Η διαχείριση αποθετηρίων γίνεται με τις εντολές 'helm repo'. ``` helm search repo [keyword] [flags] ``` ### Επιλογές {#options} ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm search](/helm/helm_search.md) - αναζητά μια λέξη-κλειδί σε charts ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- εμφανίζει πληροφορίες για ένα chart ### Σύνοψη {#synopsis} Αυτή η εντολή αποτελείται από πολλαπλές υποεντολές για την εμφάνιση πληροφοριών σχετικά με ένα chart ### Επιλογές {#options} ``` -h, --help help for show ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για το Kubernetes. * [helm show all](/helm/helm_show_all.md) - εμφανίζει όλες τις πληροφορίες του chart * [helm show chart](/helm/helm_show_chart.md) - εμφανίζει τον ορισμό του chart * [helm show crds](/helm/helm_show_crds.md) - εμφανίζει τα CRDs του chart * [helm show readme](/helm/helm_show_readme.md) - εμφανίζει το README του chart * [helm show values](/helm/helm_show_values.md) - εμφανίζει τα values του chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- εμφανίζει όλες τις πληροφορίες του chart ### Σύνοψη {#synopsis} Αυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει όλα τα περιεχόμενά του (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm show](/helm/helm_show.md) - εμφανίζει πληροφορίες για ένα chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- εμφανίζει τον ορισμό του chart ### Σύνοψη {#synopsis} Αυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα του αρχείου Chart.yaml ``` helm show chart [CHART] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm show](/helm/helm_show.md) - εμφανίζει πληροφορίες για ένα chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- εμφανίζει τα CRDs του chart ### Σύνοψη {#synopsis} Αυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα των αρχείων CustomResourceDefinition ``` helm show crds [CHART] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm show](/helm/helm_show.md) - εμφανίζει πληροφορίες για ένα chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- εμφανίζει το README του chart ### Σύνοψη {#synopsis} Αυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα του αρχείου README ``` helm show readme [CHART] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm show](/helm/helm_show.md) - εμφανίζει πληροφορίες για ένα chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- εμφανίζει τις τιμές (values) του chart ### Σύνοψη {#synopsis} Αυτή η εντολή επιθεωρεί ένα chart (κατάλογο, αρχείο ή URL) και εμφανίζει τα περιεχόμενα του αρχείου values.yaml ``` helm show values [CHART] [flags] ``` ### Επιλογές {#options} ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm show](/helm/helm_show.md) - εμφανίζει πληροφορίες για ένα chart ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- εμφανίζει την κατάσταση ενός συγκεκριμένου release ### Σύνοψη {#synopsis} Αυτή η εντολή εμφανίζει πληροφορίες κατάστασης για ένα release με βάση το όνομά του. Η κατάσταση περιλαμβάνει: - τον χρόνο της τελευταίας εγκατάστασης - το namespace του Kubernetes όπου βρίσκεται το release - την τρέχουσα κατάσταση του release (δυνατές τιμές: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade ή pending-rollback) - την αναθεώρηση (revision) του release - την περιγραφή του release (μήνυμα ολοκλήρωσης ή σφάλματος, με το --show-desc) - τη λίστα πόρων που αποτελούν το release (με το --show-resources) - λεπτομέρειες για την τελευταία εκτέλεση test suite, αν υπάρχει - πρόσθετες σημειώσεις από το chart ``` helm status RELEASE_NAME [flags] ``` ### Επιλογές {#options} ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision --show-desc if set, display the description message of the named release --show-resources if set, display the resources of the named release ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- τοπική απόδοση templates ### Σύνοψη {#synopsis} Αποδίδει τα templates ενός chart τοπικά και εμφανίζει το αποτέλεσμα. Οι τιμές που κανονικά θα αναζητούνταν ή θα ανακτούνταν από το cluster προσομοιώνονται τοπικά. Επιπλέον, δεν εκτελείται επικύρωση από την πλευρά του server για την εγκυρότητα του chart (π.χ. αν υποστηρίζεται κάποιο API). ``` helm template [NAME] [CHART] [flags] ``` ### Επιλογές {#options} ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- εκτελεί τα tests για ένα release ### Σύνοψη {#synopsis} Η εντολή test εκτελεί τα tests για ένα release. Το όρισμα που δέχεται αυτή η εντολή είναι το όνομα ενός εγκατεστημένου release. Τα tests που θα εκτελεστούν ορίζονται στο chart που εγκαταστάθηκε. ``` helm test [RELEASE] [flags] ``` ### Επιλογές {#options} ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --hide-notes if set, do not show notes in test output. Does not affect presence in chart metadata --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- απεγκαθιστά ένα release ### Σύνοψη {#synopsis} Αυτή η εντολή δέχεται το όνομα ενός release και το απεγκαθιστά. Αφαιρεί όλους τους πόρους που σχετίζονται με την τελευταία έκδοση του chart, καθώς και το ιστορικό του release, ελευθερώνοντάς το για μελλοντική χρήση. Χρησιμοποιήστε το flag '--dry-run' για να δείτε ποια releases θα απεγκατασταθούν χωρίς να τα απεγκαταστήσετε πραγματικά. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Επιλογές {#options} ``` --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run simulate a uninstall -h, --help help for uninstall --ignore-not-found Treat "release not found" as a successful uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --no-hooks prevent hooks from running during uninstallation --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- αναβαθμίζει ένα release ### Σύνοψη {#synopsis} Αυτή η εντολή αναβαθμίζει ένα release σε μια νέα έκδοση ενός chart. Τα ορίσματα της αναβάθμισης πρέπει να είναι ένα release και ένα chart. Το όρισμα chart μπορεί να είναι είτε: μια αναφορά chart ('example/mariadb'), μια διαδρομή προς έναν κατάλογο chart, ένα πακεταρισμένο chart, ή ένα πλήρως προσδιορισμένο URL. Για αναφορές chart, θα χρησιμοποιηθεί η τελευταία έκδοση εκτός αν οριστεί το flag '--version'. Για να παρακάμψετε τιμές σε ένα chart, χρησιμοποιήστε είτε το flag '--values' και περάστε ένα αρχείο, είτε το flag '--set' και περάστε ρυθμίσεις από τη γραμμή εντολών. Για να αναγκάσετε τιμές string, χρησιμοποιήστε '--set-string'. Μπορείτε να χρησιμοποιήσετε '--set-file' για να ορίσετε μεμονωμένες τιμές από αρχείο όταν η τιμή είναι πολύ μεγάλη για τη γραμμή εντολών ή δημιουργείται δυναμικά. Μπορείτε επίσης να χρησιμοποιήσετε '--set-json' για να ορίσετε τιμές JSON (scalars/objects/arrays) από τη γραμμή εντολών. Μπορείτε να καθορίσετε το flag '--values'/'-f' πολλές φορές. Προτεραιότητα θα δοθεί στο τελευταίο (δεξιότερο) αρχείο που καθορίζεται. Για παράδειγμα, αν και τα δύο αρχεία myvalues.yaml και override.yaml περιέχουν ένα κλειδί με όνομα 'Test', η τιμή που ορίζεται στο override.yaml θα υπερισχύσει: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Μπορείτε να καθορίσετε το flag '--set' πολλές φορές. Προτεραιότητα θα δοθεί στην τελευταία (δεξιότερη) τιμή. Για παράδειγμα, αν και οι δύο τιμές 'bar' και 'newbar' οριστούν για ένα κλειδί με όνομα 'foo', η τιμή 'newbar' θα υπερισχύσει: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis Μπορείτε επίσης να ενημερώσετε τις τιμές για ένα υπάρχον release με αυτή την εντολή μέσω του flag '--reuse-values'. Τα ορίσματα 'RELEASE' και 'CHART' πρέπει να οριστούν στις αρχικές παραμέτρους, και οι υπάρχουσες τιμές θα συγχωνευτούν με όποιες τιμές οριστούν μέσω των flags '--values'/'-f' ή '--set'. Προτεραιότητα δίνεται στις νέες τιμές. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis Το flag --dry-run θα εξάγει όλα τα δημιουργημένα manifests του chart, συμπεριλαμβανομένων των Secrets που μπορεί να περιέχουν ευαίσθητες τιμές. Για να αποκρύψετε τα Kubernetes Secrets χρησιμοποιήστε το flag --hide-secret. Παρακαλούμε σκεφτείτε προσεκτικά πώς και πότε χρησιμοποιούνται αυτά τα flags. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Επιλογές {#options} ``` --atomic if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- επαληθεύει ότι ένα chart στη δεδομένη διαδρομή έχει υπογραφεί και είναι έγκυρο ### Σύνοψη {#synopsis} Επαληθεύει ότι το δεδομένο chart έχει έγκυρο αρχείο provenance. Τα αρχεία provenance παρέχουν κρυπτογραφική επαλήθευση ότι ένα chart δεν έχει παραποιηθεί και δημιουργήθηκε από έναν αξιόπιστο πάροχο. Αυτή η εντολή μπορεί να χρησιμοποιηθεί για την επαλήθευση ενός τοπικού chart. Πολλές άλλες εντολές παρέχουν flags '--verify' που εκτελούν την ίδια επικύρωση. Για να δημιουργήσετε ένα υπογεγραμμένο πακέτο, χρησιμοποιήστε την εντολή 'helm package --sign'. ``` helm verify PATH [flags] ``` ### Επιλογές {#options} ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- εμφανίζει την έκδοση του client ### Σύνοψη {#synopsis} Εμφανίζει την έκδοση του Helm. Αυτή η εντολή εκτυπώνει μια αναπαράσταση της έκδοσης του Helm. Η έξοδος θα μοιάζει κάπως έτσι: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version είναι η semantic version του release. - GitCommit είναι το SHA για το commit από το οποίο δημιουργήθηκε αυτή η έκδοση. - GitTreeState είναι "clean" αν δεν υπάρχουν τοπικές αλλαγές κώδικα κατά τη δημιουργία αυτού του binary, και "dirty" αν το binary δημιουργήθηκε από τοπικά τροποποιημένο κώδικα. - GoVersion είναι η έκδοση της Go που χρησιμοποιήθηκε για τη μεταγλώττιση του Helm. Όταν χρησιμοποιείτε την επιλογή --template, οι παρακάτω ιδιότητες είναι διαθέσιμες για χρήση στο template: - .Version περιέχει τη semantic version του Helm - .GitCommit είναι το git commit - .GitTreeState είναι η κατάσταση του git tree κατά τη δημιουργία του Helm - .GoVersion περιέχει την έκδοση της Go με την οποία μεταγλωττίστηκε το Helm Για παράδειγμα, η επιλογή --template='Version: {{.Version}}' εμφανίζει 'Version: v3.2.1'. ``` helm version [flags] ``` ### Επιλογές {#options} ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### Επιλογές που κληρονομούνται από γονικές εντολές {#options-inherited-from-parent-commands} ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### ΔΕΙΤΕ ΕΠΙΣΗΣ {#see-also} * [helm](/helm/helm.md) - Ο διαχειριστής πακέτων Helm για Kubernetes. ###### Δημιουργήθηκε αυτόματα από spf13/cobra στις 14-Jan-2026 {#auto-generated-by-spf13cobra-on-14-jan-2026} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action για Αυτοματοποίηση Charts σε GitHub Pages description: Περιγράφει πώς να χρησιμοποιήσετε το Chart Releaser Action για την αυτοματοποίηση δημοσίευσης charts μέσω GitHub pages. sidebar_position: 3 --- Αυτός ο οδηγός περιγράφει πώς να χρησιμοποιήσετε το [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) για την αυτοματοποίηση δημοσίευσης charts μέσω GitHub pages. Το Chart Releaser Action είναι ένα GitHub Action workflow που μετατρέπει ένα project στο GitHub σε αυτοφιλοξενούμενο αποθετήριο Helm chart, χρησιμοποιώντας το εργαλείο CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Αλλαγές στο Αποθετήριο {#repository-changes} Δημιουργήστε ένα Git αποθετήριο στον οργανισμό σας στο GitHub. Μπορείτε να ονομάσετε το αποθετήριο `helm-charts`, αν και άλλα ονόματα είναι επίσης αποδεκτά. Ο πηγαίος κώδικας όλων των charts μπορεί να τοποθετηθεί στον κλάδο `main`. Τα charts θα πρέπει να τοποθετηθούν στον κατάλογο `/charts` στο ανώτατο επίπεδο της δομής καταλόγων. Θα πρέπει να υπάρχει ένας άλλος κλάδος με όνομα `gh-pages` για τη δημοσίευση των charts. Οι αλλαγές σε αυτόν τον κλάδο θα δημιουργούνται αυτόματα από το Chart Releaser Action που περιγράφεται εδώ. Ωστόσο, μπορείτε να δημιουργήσετε τον κλάδο `gh-pages` και να προσθέσετε ένα αρχείο `README.md`, το οποίο θα είναι ορατό στους χρήστες που επισκέπτονται τη σελίδα. Μπορείτε να προσθέσετε οδηγίες στο `README.md` για την εγκατάσταση charts ως εξής (αντικαταστήστε τα ``, `` και ``): ``` ## Usage {#usage} [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` Τα charts θα δημοσιεύονται σε μια ιστοσελίδα με URL όπως αυτό: https://.github.io/helm-charts ## GitHub Actions Workflow {#github-actions-workflow} Δημιουργήστε ένα αρχείο GitHub Actions workflow στον κλάδο `main` στη διαδρομή `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` Η παραπάνω διαμόρφωση χρησιμοποιεί το [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) για να μετατρέψει το project σας στο GitHub σε αυτοφιλοξενούμενο αποθετήριο Helm chart. Σε κάθε push στο main, το action ελέγχει κάθε chart στο project σας. Όταν εντοπίσει νέα έκδοση chart, δημιουργεί μια αντίστοιχη release στο GitHub με όνομα που αντιστοιχεί στην έκδοση του chart, προσθέτει τα αρχεία Helm chart στη release, και δημιουργεί ή ενημερώνει ένα αρχείο `index.yaml` με μεταδεδομένα για αυτές τις releases. Το αρχείο αυτό φιλοξενείται στη συνέχεια στο GitHub pages. Ο αριθμός έκδοσης του Chart Releaser Action που χρησιμοποιείται στο παραπάνω παράδειγμα είναι `v1.6.0`. Μπορείτε να τον αλλάξετε στην [τελευταία διαθέσιμη έκδοση](https://github.com/helm/chart-releaser-action/releases). Σημείωση: Το Chart Releaser Action χρησιμοποιείται σχεδόν πάντα σε συνδυασμό με το [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) και το [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Συγχρονισμός Αποθετηρίου Chart description: Περιγράφει πώς να συγχρονίσετε τα τοπικά και απομακρυσμένα αποθετήρια chart. sidebar_position: 2 --- *Σημείωση: Αυτό το παράδειγμα αφορά συγκεκριμένα ένα bucket Google Cloud Storage (GCS) που εξυπηρετεί ένα αποθετήριο chart.* ## Προαπαιτούμενα {#prerequisites} * Εγκαταστήστε το εργαλείο [gsutil](https://cloud.google.com/storage/docs/gsutil). *Βασιζόμαστε σε μεγάλο βαθμό στη λειτουργικότητα rsync του gsutil* * Βεβαιωθείτε ότι έχετε πρόσβαση στο εκτελέσιμο του Helm * _Προαιρετικό: Συνιστούμε να ενεργοποιήσετε την [εκδοσιοποίηση αντικειμένων](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) στο GCS bucket σας, σε περίπτωση που διαγράψετε κατά λάθος κάτι._ ## Δημιουργία τοπικού καταλόγου αποθετηρίου chart {#set-up-a-local-chart-repository-directory} Δημιουργήστε έναν τοπικό κατάλογο όπως κάναμε στον [οδηγό αποθετηρίου chart](/topics/chart_repository.md), και τοποθετήστε τα πακεταρισμένα charts σας σε αυτόν τον κατάλογο. Για παράδειγμα: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Δημιουργία ενημερωμένου index.yaml {#generate-an-updated-indexyaml} Χρησιμοποιήστε το Helm για να δημιουργήσετε ένα ενημερωμένο αρχείο index.yaml, περνώντας τη διαδρομή του καταλόγου και το URL του απομακρυσμένου αποθετηρίου στην εντολή `helm repo index`, ως εξής: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Αυτό θα δημιουργήσει ένα ενημερωμένο αρχείο index.yaml και θα το τοποθετήσει στον κατάλογο `fantastic-charts/`. ## Συγχρονισμός τοπικού και απομακρυσμένου αποθετηρίου chart {#sync-your-local-and-remote-chart-repositories} Ανεβάστε τα περιεχόμενα του καταλόγου στο GCS bucket σας εκτελώντας `scripts/sync-repo.sh` και περνώντας το όνομα του τοπικού καταλόγου και το όνομα του GCS bucket. Για παράδειγμα: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Ενημέρωση του αποθετηρίου chart {#updating-your-chart-repository} Καλό είναι να διατηρείτε ένα τοπικό αντίγραφο των περιεχομένων του αποθετηρίου chart σας ή να χρησιμοποιείτε το `gsutil rsync` για να αντιγράψετε τα περιεχόμενα του απομακρυσμένου αποθετηρίου chart σε έναν τοπικό κατάλογο. Για παράδειγμα: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Χρήσιμοι σύνδεσμοι: * Τεκμηρίωση για το [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Ο οδηγός αποθετηρίου chart](/topics/chart_repository.md) * Τεκμηρίωση για την [εκδοσιοποίηση αντικειμένων και τον έλεγχο ταυτοχρονισμού](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) στο Google Cloud Storage ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Συμβουλές και Κόλπα για την Ανάπτυξη Charts description: Καλύπτει μερικές από τις συμβουλές και τα κόλπα που έχουν μάθει οι προγραμματιστές charts του Helm κατά τη δημιουργία charts παραγωγής. sidebar_position: 1 --- Αυτός ο οδηγός καλύπτει μερικές από τις συμβουλές και τα κόλπα που έχουν μάθει οι προγραμματιστές charts του Helm κατά τη δημιουργία charts για παραγωγικά περιβάλλοντα. ## Γνωρίστε τις Συναρτήσεις Template {#know-your-template-functions} Το Helm χρησιμοποιεί [Go templates](https://godoc.org/text/template) για τη δημιουργία templates στα αρχεία πόρων σας. Αν και η Go παρέχει αρκετές ενσωματωμένες συναρτήσεις, έχουμε προσθέσει πολλές επιπλέον. Πρώτον, προσθέσαμε όλες τις συναρτήσεις της [βιβλιοθήκης Sprig](https://masterminds.github.io/sprig/), εκτός από τις `env` και `expandenv`, για λόγους ασφαλείας. Προσθέσαμε επίσης δύο ειδικές συναρτήσεις template: `include` και `required`. Η συνάρτηση `include` σας επιτρέπει να συμπεριλάβετε ένα άλλο template και στη συνέχεια να περάσετε τα αποτελέσματα σε άλλες συναρτήσεις template. Για παράδειγμα, αυτό το απόσπασμα template συμπεριλαμβάνει ένα template με όνομα `mytpl`, στη συνέχεια μετατρέπει το αποτέλεσμα σε πεζά και το περικλείει σε διπλά εισαγωγικά. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` Η συνάρτηση `required` σας επιτρέπει να δηλώσετε μια συγκεκριμένη καταχώρηση values ως υποχρεωτική για την απόδοση του template. Αν η τιμή είναι κενή, η απόδοση του template θα αποτύχει με ένα μήνυμα σφάλματος που ορίζει ο χρήστης. Το ακόλουθο παράδειγμα της συνάρτησης `required` δηλώνει ότι η καταχώρηση `.Values.who` είναι υποχρεωτική και θα εκτυπώσει ένα μήνυμα σφάλματος όταν αυτή η καταχώρηση λείπει: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Χρησιμοποιήστε Εισαγωγικά για Strings, Όχι για Ακέραιους {#quote-strings-dont-quote-integers} Όταν εργάζεστε με δεδομένα τύπου string, είναι πάντα ασφαλέστερο να χρησιμοποιείτε εισαγωγικά αντί να τα αφήνετε χωρίς: ```yaml name: {{ .Values.MyName | quote }} ``` Αλλά όταν εργάζεστε με ακέραιους αριθμούς, _μην χρησιμοποιείτε εισαγωγικά_. Αυτό μπορεί, σε πολλές περιπτώσεις, να προκαλέσει σφάλματα ανάλυσης μέσα στο Kubernetes. ```yaml port: {{ .Values.Port }} ``` Αυτή η παρατήρηση δεν ισχύει για τιμές μεταβλητών περιβάλλοντος που αναμένονται ως string, ακόμα κι αν αντιπροσωπεύουν ακέραιους: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Χρήση της Συνάρτησης 'include' {#using-the-include-function} Η Go παρέχει έναν τρόπο να συμπεριλάβετε ένα template μέσα σε ένα άλλο χρησιμοποιώντας την ενσωματωμένη οδηγία `template`. Ωστόσο, η ενσωματωμένη συνάρτηση δεν μπορεί να χρησιμοποιηθεί σε pipelines του Go template. Για να είναι δυνατή η συμπερίληψη ενός template και στη συνέχεια η εκτέλεση μιας λειτουργίας στην έξοδο αυτού του template, το Helm έχει μια ειδική συνάρτηση `include`: ``` {{ include "toYaml" $value | indent 2 }} ``` Το παραπάνω συμπεριλαμβάνει ένα template με όνομα `toYaml`, του περνάει το `$value` και στη συνέχεια περνάει την έξοδο αυτού του template στη συνάρτηση `indent`. Επειδή το YAML δίνει σημασία στα επίπεδα εσοχής και στα κενά, αυτός είναι ένας εξαιρετικός τρόπος για να συμπεριλαμβάνετε αποσπάσματα κώδικα, χειριζόμενοι την εσοχή στο κατάλληλο πλαίσιο. ## Χρήση της Συνάρτησης 'required' {#using-the-required-function} Η Go παρέχει έναν τρόπο για να ορίσετε επιλογές template που ελέγχουν τη συμπεριφορά όταν γίνεται αναζήτηση σε ένα map με κλειδί που δεν υπάρχει. Αυτό συνήθως ορίζεται με `template.Options("missingkey=option")`, όπου η `option` μπορεί να είναι `default`, `zero` ή `error`. Αν και η ρύθμιση αυτής της επιλογής σε error θα σταματήσει την εκτέλεση με σφάλμα, αυτό θα ισχύει για κάθε κλειδί που λείπει στο map. Μπορεί να υπάρχουν περιπτώσεις όπου ο προγραμματιστής του chart θέλει να επιβάλει αυτή τη συμπεριφορά για επιλεγμένες τιμές στο αρχείο `values.yaml`. Η συνάρτηση `required` δίνει στους προγραμματιστές τη δυνατότητα να δηλώσουν μια καταχώρηση τιμής ως υποχρεωτική για την απόδοση του template. Αν η καταχώρηση είναι κενή στο `values.yaml`, το template δεν θα αποδοθεί και θα επιστρέψει ένα μήνυμα σφάλματος που παρέχει ο προγραμματιστής. Για παράδειγμα: ``` {{ required "A valid foo is required!" .Values.foo }} ``` Το παραπάνω θα αποδώσει το template όταν το `.Values.foo` είναι ορισμένο, αλλά θα αποτύχει να το αποδώσει και θα τερματίσει όταν το `.Values.foo` δεν είναι ορισμένο. ## Χρήση της Συνάρτησης 'tpl' {#using-the-tpl-function} Η συνάρτηση `tpl` επιτρέπει στους προγραμματιστές να αξιολογούν strings ως templates μέσα σε ένα template. Αυτό είναι χρήσιμο για τη μετάδοση ενός template string ως τιμή σε ένα chart ή για την απόδοση εξωτερικών αρχείων ρυθμίσεων. Σύνταξη: `{{ tpl TEMPLATE_STRING VALUES }}` Παραδείγματα: ```yaml # values {#values} {#values} template: "{{ .Values.name }}" name: "Tom" # template {#template} {#template} {{ tpl .Values.template . }} # output {#output} {#output} Tom ``` Απόδοση εξωτερικού αρχείου ρυθμίσεων: ```yaml # external configuration file conf/app.conf {#external-configuration-file-confappconf} firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Δημιουργία Image Pull Secrets {#creating-image-pull-secrets} Τα image pull secrets είναι ουσιαστικά ένας συνδυασμός _registry_, _username_ και _password_. Μπορεί να τα χρειαστείτε σε μια εφαρμογή που αναπτύσσετε, αλλά για να τα δημιουργήσετε απαιτείται η εκτέλεση του `base64` μερικές φορές. Μπορούμε να γράψουμε ένα βοηθητικό template για τη σύνθεση του αρχείου ρυθμίσεων Docker προς χρήση ως payload του Secret. Ακολουθεί ένα παράδειγμα: Πρώτα, υποθέστε ότι τα credentials ορίζονται στο αρχείο `values.yaml` ως εξής: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Στη συνέχεια ορίζουμε το βοηθητικό template ως εξής: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Τέλος, χρησιμοποιούμε το βοηθητικό template σε ένα μεγαλύτερο template για να δημιουργήσουμε το manifest του Secret: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Αυτόματη Επανεκκίνηση Deployments {#automatically-roll-deployments} Συχνά τα ConfigMaps ή τα Secrets εισάγονται ως αρχεία ρυθμίσεων σε containers ή υπάρχουν άλλες αλλαγές εξωτερικών εξαρτήσεων που απαιτούν επανεκκίνηση των pods. Ανάλογα με την εφαρμογή, μπορεί να απαιτείται επανεκκίνηση αν αυτά ενημερωθούν με ένα επόμενο `helm upgrade`, αλλά αν το ίδιο το deployment spec δεν άλλαξε, η εφαρμογή συνεχίζει να εκτελείται με την παλιά ρύθμιση, με αποτέλεσμα ένα ασυνεπές deployment. Η συνάρτηση `sha256sum` μπορεί να χρησιμοποιηθεί για να διασφαλίσει ότι η ενότητα annotations ενός deployment ενημερώνεται αν αλλάξει ένα άλλο αρχείο: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` ΣΗΜΕΙΩΣΗ: Αν προσθέτετε αυτό σε ένα library chart, δεν θα μπορέσετε να αποκτήσετε πρόσβαση στο αρχείο σας μέσω του `$.Template.BasePath`. Αντίθετα, μπορείτε να αναφερθείτε στον ορισμό σας με `{{ include ("mylibchart.configmap") . | sha256sum }}`. Στην περίπτωση που θέλετε πάντα να κάνετε επανεκκίνηση το deployment σας, μπορείτε να χρησιμοποιήσετε ένα παρόμοιο βήμα annotation όπως παραπάνω, αλλά αντικαθιστώντας με ένα τυχαίο string ώστε να αλλάζει πάντα και να προκαλεί επανεκκίνηση του deployment: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Κάθε κλήση της συνάρτησης template θα δημιουργήσει ένα μοναδικό τυχαίο string. Αυτό σημαίνει ότι αν είναι απαραίτητο να συγχρονιστούν τα τυχαία strings που χρησιμοποιούνται από πολλαπλούς πόρους, όλοι οι σχετικοί πόροι θα πρέπει να βρίσκονται στο ίδιο αρχείο template. Και οι δύο αυτές μέθοδοι επιτρέπουν στο Deployment σας να αξιοποιήσει την ενσωματωμένη λογική στρατηγικής ενημέρωσης για να αποφύγει το downtime. ΣΗΜΕΙΩΣΗ: Στο παρελθόν προτείναμε τη χρήση της επιλογής `--recreate-pods` ως εναλλακτική. Αυτή η επιλογή έχει επισημανθεί ως deprecated στο Helm 3 υπέρ της πιο δηλωτικής μεθόδου που περιγράφεται παραπάνω. ## Αποτροπή Απεγκατάστασης Πόρου από το Helm {#tell-helm-not-to-uninstall-a-resource} Μερικές φορές υπάρχουν πόροι που δεν πρέπει να απεγκατασταθούν όταν το Helm εκτελεί `helm uninstall`. Οι προγραμματιστές charts μπορούν να προσθέσουν ένα annotation σε έναν πόρο για να αποτρέψουν την απεγκατάστασή του. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` Το annotation `helm.sh/resource-policy: keep` δίνει εντολή στο Helm να παραλείψει τη διαγραφή αυτού του πόρου όταν μια λειτουργία helm (όπως `helm uninstall`, `helm upgrade` ή `helm rollback`) θα είχε ως αποτέλεσμα τη διαγραφή του. _Ωστόσο_, αυτός ο πόρος γίνεται ορφανός. Το Helm δεν θα τον διαχειρίζεται πλέον με κανέναν τρόπο. Αυτό μπορεί να οδηγήσει σε προβλήματα αν χρησιμοποιείτε `helm install --replace` σε ένα release που έχει ήδη απεγκατασταθεί, αλλά έχει διατηρήσει πόρους. ## Χρήση "Partials" και Συμπερίληψη Templates {#using-partials-and-template-includes} Μερικές φορές θέλετε να δημιουργήσετε ορισμένα επαναχρησιμοποιήσιμα μέρη στο chart σας, είτε είναι blocks είτε template partials. Και συχνά, είναι πιο καθαρό να τα κρατάτε στα δικά τους αρχεία. Στον κατάλογο `templates/`, οποιοδήποτε αρχείο ξεκινά με underscore (`_`) δεν αναμένεται να παράγει ένα αρχείο manifest Kubernetes. Έτσι, κατά σύμβαση, τα βοηθητικά templates και τα partials τοποθετούνται σε ένα αρχείο `_helpers.tpl`. ## Σύνθετα Charts με Πολλές Εξαρτήσεις {#complex-charts-with-many-dependencies} Πολλά από τα charts στο CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) είναι "δομικά στοιχεία" για τη δημιουργία πιο προηγμένων εφαρμογών. Αλλά τα charts μπορούν επίσης να χρησιμοποιηθούν για τη δημιουργία instances μεγάλης κλίμακας εφαρμογών. Σε τέτοιες περιπτώσεις, ένα κεντρικό umbrella chart μπορεί να έχει πολλαπλά subcharts, καθένα από τα οποία λειτουργεί ως μέρος του συνόλου. Η τρέχουσα βέλτιστη πρακτική για τη σύνθεση μιας σύνθετης εφαρμογής από διακριτά μέρη είναι να δημιουργήσετε ένα κορυφαίο umbrella chart που εκθέτει τις καθολικές ρυθμίσεις και στη συνέχεια να χρησιμοποιήσετε τον υποκατάλογο `charts/` για να ενσωματώσετε κάθε ένα από τα components. ## Το YAML είναι Υπερσύνολο του JSON {#yaml-is-a-superset-of-json} Σύμφωνα με την προδιαγραφή YAML, το YAML είναι υπερσύνολο του JSON. Αυτό σημαίνει ότι οποιαδήποτε έγκυρη δομή JSON θα πρέπει να είναι έγκυρη και σε YAML. Αυτό έχει ένα πλεονέκτημα: Μερικές φορές οι προγραμματιστές templates μπορεί να βρουν πιο εύκολο να εκφράσουν μια δομή δεδομένων με σύνταξη παρόμοια με JSON αντί να ασχοληθούν με την ευαισθησία του YAML στα κενά. Ως βέλτιστη πρακτική, τα templates θα πρέπει να ακολουθούν σύνταξη τύπου YAML _εκτός αν_ η σύνταξη JSON μειώνει σημαντικά τον κίνδυνο προβλήματος μορφοποίησης. ## Προσοχή κατά τη Δημιουργία Τυχαίων Τιμών {#be-careful-with-generating-random-values} Υπάρχουν συναρτήσεις στο Helm που σας επιτρέπουν να δημιουργείτε τυχαία δεδομένα, κρυπτογραφικά κλειδιά και ούτω καθεξής. Αυτές είναι καλές για χρήση. Αλλά να έχετε υπόψη ότι κατά τις αναβαθμίσεις, τα templates εκτελούνται ξανά. Όταν μια εκτέλεση template δημιουργεί δεδομένα που διαφέρουν από την τελευταία εκτέλεση, αυτό θα ενεργοποιήσει μια ενημέρωση αυτού του πόρου. ## Εγκατάσταση ή Αναβάθμιση Release με Μία Εντολή {#install-or-upgrade-a-release-with-one-command} Το Helm παρέχει έναν τρόπο να εκτελέσετε εγκατάσταση ή αναβάθμιση ως μία εντολή. Χρησιμοποιήστε `helm upgrade` με την επιλογή `--install`. Αυτό θα κάνει το Helm να ελέγξει αν το release είναι ήδη εγκατεστημένο. Αν όχι, θα εκτελέσει εγκατάσταση. Αν είναι, τότε το υπάρχον release θα αναβαθμιστεί. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Αρχική Εγγράφων" description: "Όλα όσα χρειάζεσαι να μάθεις για το πως είναι οργανωμένη η τεκμηρίωση." --- # Καλωσήρθες Καλωσήρθες στην τεκμηρίωση του [Helm](https://helm.sh/). Το Helm είναι ο package manager του Kubernetes, και μπορείς να διαβάσεις τις λεπτομερείς πληροφορίες για το πλαίσιο στο [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). # Πως οργανώνεται η τεκμηρίωση Το Helm έχει πολύ καλή τεκμηρίωση. Μια γενική ματιά στο πως είναι οργανωμένη θα σε βοηθήσει να ξέρεις που να ψάξεις για συγκεκριμένα πράγματα: - Τα Tutorials σε παίρνουν από το χέρι και σε καθοδηγούν σε μια σειρά από βήματα ώστε να δημιουργήσεις το πρώτο σου Helm chart. Ξεκίνα από εδώ αν είσαι νέος/νέα στο Helm. - Οι Θεματικοί Οδηγοί συζητούν για θέματα κλειδιά και έννοιες σε ένα αρκετά γενικό επίπεδο και παρέχουν χρήσιμες πληροφορίες για το πλαίσιο και επεξηγήσεις. - Οι Οδηγοί της Κοινότητας συζητούν για θέματα που έχουν κέντρο την κοινότητα του Helm. Ξεκίνα από εδώ αν θες να μάθεις περισσότερα για την διαδικασία ανάπτυξης του ίδιου του Helm και πως μπορείς να συνεισφέρεις. - Οι Οδηγοί How-to είναι συνταγές. Σε καθοδηγούν μέσα από τα βήματα που απαιτούνται ώστε να διευθετήσεις προβλήματα κλειδιά και περιπτώσεις χρήσης. Είναι πιο προχωρημένοι από τα tutorials και έχουν ως προϋπόθεση βασικές γνώσεις για το Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Φύλλο Αναφοράς description: Φύλλο γρήγορης αναφοράς για εντολές Helm sidebar_position: 4 --- Φύλλο αναφοράς Helm με όλες τις απαραίτητες εντολές για τη διαχείριση μιας εφαρμογής μέσω του Helm. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Βασικές έννοιες {#basic-interpretationscontext} Chart: - Είναι το όνομα του chart σας σε περίπτωση που έχει γίνει pull και αποσυμπίεση. - Είναι / σε περίπτωση που το repository έχει προστεθεί αλλά το chart δεν έχει γίνει pull. - Είναι το URL ή η απόλυτη διαδρομή προς το chart. Name: - Είναι το όνομα που θέλετε να δώσετε στην τρέχουσα εγκατάσταση του Helm chart. Release: - Είναι το όνομα που δώσατε σε μια συγκεκριμένη εγκατάσταση. Revision: - Είναι η τιμή που επιστρέφει η εντολή `helm history`. Repo-name: - Το όνομα ενός repository. DIR: - Όνομα ή διαδρομή φακέλου. ------------------------------------------------------------------------------------------------------------------------------------------------ ### Διαχείριση Chart {#chart-management} ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart's dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Εγκατάσταση και Απεγκατάσταση Εφαρμογών {#install-and-uninstall-apps} ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Αναβάθμιση και Επαναφορά Εφαρμογών {#perform-app-upgrade-and-rollback} ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Λίστα, Προσθήκη, Αφαίρεση και Ενημέρωση Repositories {#list-add-remove-and-update-repositories} ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Παρακολούθηση Helm Release {#helm-release-monitoring} ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Λήψη Πληροφοριών Release {#download-release-information} ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Διαχείριση Plugin {#plugin-management} ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Εγκατάσταση του Helm description: Μάθετε πώς να εγκαταστήσετε και να ξεκινήσετε με το Helm. sidebar_position: 2 --- Αυτός ο οδηγός δείχνει πώς να εγκαταστήσετε το Helm CLI. Το Helm μπορεί να εγκατασταθεί είτε από τον πηγαίο κώδικα είτε από έτοιμα binary releases. ## Από το Helm Project {#from-the-helm-project} Το Helm project παρέχει δύο τρόπους για λήψη και εγκατάσταση του Helm. Αυτές είναι οι επίσημες μέθοδοι για απόκτηση εκδόσεων του Helm. Επιπλέον, η κοινότητα του Helm παρέχει μεθόδους εγκατάστασης μέσω διαφορετικών διαχειριστών πακέτων. Η εγκατάσταση μέσω αυτών των μεθόδων περιγράφεται παρακάτω, μετά τις επίσημες μεθόδους. ### Από τα Binary Releases {#from-the-binary-releases} Κάθε [release](https://github.com/helm/helm/releases) του Helm παρέχει binary releases για διάφορα λειτουργικά συστήματα. Αυτές οι binary εκδόσεις μπορούν να ληφθούν και να εγκατασταθούν χειροκίνητα. 1. Κατεβάστε την [επιθυμητή έκδοση](https://github.com/helm/helm/releases) 2. Αποσυμπιέστε την (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Βρείτε το `helm` binary στον αποσυμπιεσμένο φάκελο και μετακινήστε το στην επιθυμητή τοποθεσία (`mv linux-amd64/helm /usr/local/bin/helm`) Από εκεί, θα πρέπει να μπορείτε να εκτελέσετε τον client και να [προσθέσετε το stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Σημείωση:** Τα αυτοματοποιημένα tests του Helm εκτελούνται μόνο για Linux AMD64 κατά τη διάρκεια των builds και releases στο GitHub Actions. Η δοκιμή άλλων λειτουργικών συστημάτων είναι ευθύνη της κοινότητας που ζητά το Helm για το συγκεκριμένο λειτουργικό σύστημα. ### Από Script {#from-script} Το Helm έχει πλέον ένα script εγκατάστασης που κατεβάζει αυτόματα την τελευταία έκδοση του Helm και την [εγκαθιστά τοπικά](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Μπορείτε να κατεβάσετε αυτό το script και μετά να το εκτελέσετε τοπικά. Είναι καλά τεκμηριωμένο ώστε να μπορείτε να το διαβάσετε και να καταλάβετε τι κάνει πριν το εκτελέσετε. ```console $ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 $ chmod 700 get_helm.sh $ ./get_helm.sh ``` Ναι, μπορείτε να εκτελέσετε `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` αν θέλετε να χρησιμοποιήσετε την πιο πρόσφατη (ενδεχομένως ασταθή) έκδοση. ## Μέσω Διαχειριστών Πακέτων {#through-package-managers} Η κοινότητα του Helm παρέχει τη δυνατότητα εγκατάστασης του Helm μέσω διαχειριστών πακέτων λειτουργικών συστημάτων. Αυτές οι μέθοδοι δεν υποστηρίζονται από το Helm project και δεν θεωρούνται αξιόπιστα τρίτα μέρη. ### Από το Homebrew (macOS) {#from-homebrew-macos} Μέλη της κοινότητας του Helm έχουν συνεισφέρει ένα Helm formula στο Homebrew. Αυτό το formula είναι γενικά ενημερωμένο. ```console brew install helm ``` (Σημείωση: Υπάρχει επίσης ένα formula για το emacs-helm, που είναι διαφορετικό project.) ### Από το Chocolatey (Windows) {#from-chocolatey-windows} Μέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm package](https://chocolatey.org/packages/kubernetes-helm) στο [Chocolatey](https://chocolatey.org/). Αυτό το package είναι γενικά ενημερωμένο. ```console choco install kubernetes-helm ``` ### Από το Scoop (Windows) {#from-scoop-windows} Μέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm package](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) στο [Scoop](https://scoop.sh). Αυτό το package είναι γενικά ενημερωμένο. ```console scoop install helm ``` ### Από το Winget (Windows) {#from-winget-windows} Μέλη της κοινότητας του Helm έχουν συνεισφέρει ένα [Helm package](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) στο [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Αυτό το package είναι γενικά ενημερωμένο. ```console winget install Helm.Helm ``` ### Από το Apt (Debian/Ubuntu) {#from-apt-debianubuntu} Μέλη της κοινότητας του Helm έχουν συνεισφέρει ένα Apt package για Debian/Ubuntu. Αυτό το package είναι γενικά ενημερωμένο. Ευχαριστούμε το [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) για τη φιλοξενία του repository. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Από το dnf/yum (Fedora) {#from-dnfyum-fedora} Από το Fedora 35, το Helm είναι διαθέσιμο στο επίσημο repository. Μπορείτε να εγκαταστήσετε το Helm εκτελώντας: ```console sudo dnf install helm ``` ### Από το Snap {#from-snap} Η κοινότητα [Snapcrafters](https://github.com/snapcrafters) συντηρεί την Snap έκδοση του [Helm package](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### Από το pkg (FreeBSD) {#from-pkg-freebsd} Μέλη της κοινότητας FreeBSD έχουν συνεισφέρει ένα [Helm package](https://www.freshports.org/sysutils/helm) στη [FreeBSD Ports Collection](https://man.freebsd.org/ports). Αυτό το package είναι γενικά ενημερωμένο. ```console pkg install helm ``` ### Development Builds {#development-builds} Εκτός από τα releases, μπορείτε να κατεβάσετε ή να εγκαταστήσετε development snapshots του Helm. ### Από Canary Builds {#from-canary-builds} Τα "Canary" builds είναι εκδόσεις του λογισμικού Helm που δημιουργούνται από τον τελευταίο `main` branch. Δεν είναι επίσημα releases και μπορεί να μην είναι σταθερά. Ωστόσο, προσφέρουν τη δυνατότητα να δοκιμάσετε τα πιο πρόσφατα χαρακτηριστικά. Τα Canary Helm binaries αποθηκεύονται στο `get.helm.sh`. Ακολουθούν σύνδεσμοι για τα συνηθισμένα builds: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Από τον Πηγαίο Κώδικα (Linux, macOS) {#from-source-linux-macos} Η μεταγλώττιση του Helm από τον πηγαίο κώδικα απαιτεί λίγο περισσότερη δουλειά, αλλά είναι ο καλύτερος τρόπος αν θέλετε να δοκιμάσετε την τελευταία (pre-release) έκδοση του Helm. Πρέπει να έχετε ένα λειτουργικό περιβάλλον Go. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` Αν απαιτείται, θα κατεβάσει τις εξαρτήσεις, θα τις αποθηκεύσει στην cache και θα επικυρώσει τη ρύθμιση. Στη συνέχεια θα μεταγλωττίσει το `helm` και θα το τοποθετήσει στο `bin/helm`. ## Συμπέρασμα {#conclusion} Στις περισσότερες περιπτώσεις, η εγκατάσταση είναι τόσο απλή όσο η λήψη ενός έτοιμου `helm` binary. Αυτό το έγγραφο καλύπτει πρόσθετες περιπτώσεις για όσους θέλουν να κάνουν πιο εξελιγμένα πράγματα με το Helm. Μόλις εγκαταστήσετε επιτυχώς τον Helm Client, μπορείτε να προχωρήσετε στη χρήση του Helm για τη διαχείριση charts και να [προσθέσετε το stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Οδηγός Γρήγορης Εκκίνησης description: Πώς να εγκαταστήσετε και να ξεκινήσετε με το Helm, συμπεριλαμβανομένων οδηγιών για διανομές, συχνές ερωτήσεις και plugins. sidebar_position: 1 --- Αυτός ο οδηγός καλύπτει πώς μπορείτε να ξεκινήσετε γρήγορα με το Helm. ## Προαπαιτούμενα {#prerequisites} Τα ακόλουθα προαπαιτούμενα είναι απαραίτητα για μια επιτυχημένη και ασφαλή χρήση του Helm: 1. Ένα Kubernetes cluster 2. Επιλογή ρυθμίσεων ασφαλείας για την εγκατάσταση, αν απαιτούνται 3. Εγκατάσταση και ρύθμιση του Helm ### Εγκαταστήστε το Kubernetes ή αποκτήστε πρόσβαση σε cluster {#install-kubernetes-or-have-access-to-a-cluster} - Πρέπει να έχετε εγκατεστημένο το Kubernetes. Για την τελευταία έκδοση του Helm, προτείνουμε την πιο πρόσφατη σταθερή έκδοση του Kubernetes, η οποία στις περισσότερες περιπτώσεις είναι η προτελευταία minor έκδοση. - Θα πρέπει επίσης να έχετε ένα τοπικά ρυθμισμένο αντίγραφο του `kubectl`. Δείτε την [Πολιτική Υποστήριξης Εκδόσεων του Helm](https://helm.sh/docs/topics/version_skew/) για τη μέγιστη υποστηριζόμενη απόκλιση εκδόσεων μεταξύ Helm και Kubernetes. ## Εγκατάσταση του Helm {#install-helm} Κατεβάστε μια binary έκδοση του Helm client. Μπορείτε να χρησιμοποιήσετε εργαλεία όπως το `homebrew`, ή να δείτε [την επίσημη σελίδα εκδόσεων](https://github.com/helm/helm/releases). Για περισσότερες λεπτομέρειες, ή για άλλες επιλογές, δείτε [τον οδηγό εγκατάστασης](/intro/install.md). ## Αρχικοποίηση ενός Helm Chart Repository {#initialize-a-helm-chart-repository} Μόλις έχετε έτοιμο το Helm, μπορείτε να προσθέσετε ένα chart repository. Ελέγξτε το [Artifact Hub](https://artifacthub.io/packages/search?kind=0) για διαθέσιμα Helm chart repositories. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Μόλις προστεθεί, θα μπορείτε να δείτε τη λίστα με τα charts που μπορείτε να εγκαταστήσετε: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... και πολλά άλλα {#and-many-more} ``` ## Εγκατάσταση ενός Παραδείγματος Chart {#install-an-example-chart} Για να εγκαταστήσετε ένα chart, μπορείτε να εκτελέσετε την εντολή `helm install`. Το Helm προσφέρει διάφορους τρόπους για να βρείτε και να εγκαταστήσετε ένα chart, αλλά ο ευκολότερος είναι να χρησιμοποιήσετε τα `bitnami` charts. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` Στο παραπάνω παράδειγμα, εγκαταστάθηκε το chart `bitnami/mysql` και το όνομα του νέου release είναι `mysql-1612624192`. Μπορείτε να δείτε μια απλή περιγραφή των χαρακτηριστικών αυτού του MySQL chart εκτελώντας `helm show chart bitnami/mysql`. Ή μπορείτε να εκτελέσετε `helm show all bitnami/mysql` για να δείτε όλες τις πληροφορίες για το chart. Κάθε φορά που εγκαθιστάτε ένα chart, δημιουργείται ένα νέο release. Έτσι, ένα chart μπορεί να εγκατασταθεί πολλές φορές στο ίδιο cluster. Και κάθε release μπορεί να διαχειρίζεται και να αναβαθμίζεται ανεξάρτητα. Η εντολή `helm install` είναι μια πολύ ισχυρή εντολή με πολλές δυνατότητες. Για να μάθετε περισσότερα, δείτε τον [Οδηγό Χρήσης του Helm](/intro/using_helm.md). ## Μάθετε για τα Releases {#learn-about-releases} Είναι εύκολο να δείτε τι έχει εγκατασταθεί με το Helm: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` Η εντολή `helm list` (ή `helm ls`) θα σας δείξει τη λίστα με όλα τα deployed releases. ## Απεγκατάσταση ενός Release {#uninstall-a-release} Για να απεγκαταστήσετε ένα release, χρησιμοποιήστε την εντολή `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Αυτό θα απεγκαταστήσει το `mysql-1612624192` από το Kubernetes, αφαιρώντας όλους τους πόρους που σχετίζονται με το release καθώς και το ιστορικό του release. Αν χρησιμοποιηθεί η flag `--keep-history`, το ιστορικό του release θα διατηρηθεί. Θα μπορείτε να ζητήσετε πληροφορίες για αυτό το release: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Επειδή το Helm παρακολουθεί τα releases σας ακόμα και μετά την απεγκατάστασή τους, μπορείτε να ελέγξετε το ιστορικό ενός cluster και ακόμα να επαναφέρετε ένα release (με την εντολή `helm rollback`). ## Ανάγνωση του Κειμένου Βοήθειας {#reading-the-help-text} Για να μάθετε περισσότερα για τις διαθέσιμες εντολές του Helm, χρησιμοποιήστε `helm help` ή πληκτρολογήστε μια εντολή ακολουθούμενη από τη flag `-h`: ```console $ helm get -h ``` ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Χρήση του Helm description: Εξηγεί τα βασικά του Helm. sidebar_position: 3 --- Αυτός ο οδηγός εξηγεί τα βασικά της χρήσης του Helm για τη διαχείριση πακέτων στο Kubernetes cluster σας. Προϋποθέτει ότι έχετε ήδη [εγκαταστήσει](/intro/install.md) τον Helm client. Αν απλά θέλετε να εκτελέσετε μερικές γρήγορες εντολές, μπορείτε να ξεκινήσετε με τον [Οδηγό Γρήγορης Εκκίνησης](/intro/quickstart.md). Αυτό το κεφάλαιο καλύπτει τις λεπτομέρειες των εντολών του Helm και εξηγεί πώς να το χρησιμοποιείτε. ## Τρεις Βασικές Έννοιες {#three-big-concepts} Ένα *Chart* είναι ένα πακέτο Helm. Περιέχει όλους τους ορισμούς πόρων που απαιτούνται για την εκτέλεση μιας εφαρμογής, εργαλείου ή υπηρεσίας μέσα σε ένα Kubernetes cluster. Σκεφτείτε το σαν το αντίστοιχο του Kubernetes για ένα Homebrew formula, ένα Apt dpkg ή ένα Yum RPM αρχείο. Ένα *Repository* είναι ο χώρος όπου τα charts μπορούν να συγκεντρωθούν και να μοιραστούν. Είναι σαν το [αρχείο CPAN](https://www.cpan.org) της Perl ή τη [Βάση Δεδομένων Πακέτων Fedora](https://src.fedoraproject.org/), αλλά για πακέτα Kubernetes. Ένα *Release* είναι μια υπόσταση ενός chart που εκτελείται σε ένα Kubernetes cluster. Ένα chart μπορεί συχνά να εγκατασταθεί πολλές φορές στο ίδιο cluster. Και κάθε φορά που εγκαθίσταται, δημιουργείται ένα νέο _release_. Σκεφτείτε ένα MySQL chart. Αν θέλετε δύο βάσεις δεδομένων στο cluster σας, μπορείτε να εγκαταστήσετε αυτό το chart δύο φορές. Κάθε μία θα έχει το δικό της _release_, το οποίο με τη σειρά του θα έχει το δικό του _release name_. Με αυτά υπόψη, μπορούμε τώρα να εξηγήσουμε το Helm ως εξής: Το Helm εγκαθιστά _charts_ στο Kubernetes, δημιουργώντας ένα νέο _release_ για κάθε εγκατάσταση. Και για να βρείτε νέα charts, μπορείτε να αναζητήσετε σε _repositories_ charts του Helm. ## 'helm search': Εύρεση Charts {#helm-search-finding-charts} Το Helm διαθέτει μια ισχυρή εντολή αναζήτησης. Μπορεί να χρησιμοποιηθεί για αναζήτηση σε δύο διαφορετικούς τύπους πηγών: - Η `helm search hub` αναζητά στο [Artifact Hub](https://artifacthub.io), το οποίο παραθέτει helm charts από δεκάδες διαφορετικά repositories. - Η `helm search repo` αναζητά στα repositories που έχετε προσθέσει στον τοπικό σας helm client (με την εντολή `helm repo add`). Αυτή η αναζήτηση γίνεται σε τοπικά δεδομένα και δεν απαιτείται σύνδεση δημόσιου δικτύου. Μπορείτε να βρείτε δημόσια διαθέσιμα charts εκτελώντας `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` Η παραπάνω εντολή αναζητά όλα τα charts `wordpress` στο Artifact Hub. Χωρίς φίλτρο, η `helm search hub` σας δείχνει όλα τα διαθέσιμα charts. Η `helm search hub` εμφανίζει τη διεύθυνση URL στη θέση στο [artifacthub.io](https://artifacthub.io/) αλλά όχι το πραγματικό Helm repo. Η `helm search hub --list-repo-url` εμφανίζει την πραγματική διεύθυνση URL του Helm repo, κάτι που είναι χρήσιμο όταν θέλετε να προσθέσετε ένα νέο repo: `helm repo add [NAME] [URL]`. Χρησιμοποιώντας την `helm search repo`, μπορείτε να βρείτε τα ονόματα των charts στα repositories που έχετε ήδη προσθέσει: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Η αναζήτηση Helm χρησιμοποιεί έναν αλγόριθμο ασαφούς αντιστοίχισης συμβολοσειρών, οπότε μπορείτε να πληκτρολογήσετε μέρη λέξεων ή φράσεων: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Η αναζήτηση είναι ένας καλός τρόπος για να βρείτε διαθέσιμα πακέτα. Μόλις βρείτε ένα πακέτο που θέλετε να εγκαταστήσετε, μπορείτε να χρησιμοποιήσετε την `helm install` για να το εγκαταστήσετε. ## 'helm install': Εγκατάσταση Πακέτου {#helm-install-installing-a-package} Για να εγκαταστήσετε ένα νέο πακέτο, χρησιμοποιήστε την εντολή `helm install`. Στην απλούστερη μορφή της, δέχεται δύο ορίσματα: Ένα release name της επιλογής σας και το όνομα του chart που θέλετε να εγκαταστήσετε. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Τώρα το chart `wordpress` έχει εγκατασταθεί. Σημειώστε ότι η εγκατάσταση ενός chart δημιουργεί ένα νέο αντικείμενο _release_. Το παραπάνω release ονομάζεται `happy-panda`. (Αν θέλετε το Helm να δημιουργήσει ένα όνομα για εσάς, παραλείψτε το release name και χρησιμοποιήστε `--generate-name`.) Κατά την εγκατάσταση, ο `helm` client θα εκτυπώσει χρήσιμες πληροφορίες σχετικά με τους πόρους που δημιουργήθηκαν, την κατάσταση του release, καθώς και αν υπάρχουν επιπλέον βήματα ρύθμισης παραμέτρων που μπορείτε ή πρέπει να κάνετε. Το Helm εγκαθιστά πόρους με την ακόλουθη σειρά: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Το Helm δεν περιμένει μέχρι να εκτελούνται όλοι οι πόροι πριν τερματίσει. Πολλά charts απαιτούν Docker images που είναι πάνω από 600MB σε μέγεθος και μπορεί να χρειαστεί πολύς χρόνος για να εγκατασταθούν στο cluster. Για να παρακολουθήσετε την κατάσταση ενός release ή για να ξαναδιαβάσετε πληροφορίες ρύθμισης παραμέτρων, μπορείτε να χρησιμοποιήσετε την `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Τα παραπάνω δείχνουν την τρέχουσα κατάσταση του release σας. ### Προσαρμογή του Chart Πριν την Εγκατάσταση {#customizing-the-chart-before-installing} Η εγκατάσταση με τον τρόπο που δείξαμε θα χρησιμοποιήσει μόνο τις προεπιλεγμένες επιλογές ρύθμισης παραμέτρων για αυτό το chart. Πολλές φορές θα θέλετε να προσαρμόσετε το chart ώστε να χρησιμοποιεί τη ρύθμιση παραμέτρων της προτίμησής σας. Για να δείτε ποιες επιλογές είναι παραμετροποιήσιμες σε ένα chart, χρησιμοποιήστε την `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters {#global-docker-image-parameters} ## Please, note that this will override the image parameters, including dependencies, configured to use the global value {#please-note-that-this-will-override-the-image-parameters-including-dependencies-configured-to-use-the-global-value} ## Current available global Docker image parameters: imageRegistry and imagePullSecrets {#current-available-global-docker-image-parameters-imageregistry-and-imagepullsecrets} ## # global: {#global} # imageRegistry: myRegistryName {#imageregistry-myregistryname} # imagePullSecrets: {#imagepullsecrets} # - myRegistryKeySecretName {#myregistrykeysecretname} # storageClass: myStorageClass {#storageclass-mystorageclass} ## Bitnami WordPress image version {#bitnami-wordpress-image-version} ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ {#ref-httpshubdockercomrbitnamiwordpresstags} ## image: {#image} registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Στη συνέχεια μπορείτε να παρακάμψετε οποιαδήποτε από αυτές τις ρυθμίσεις σε ένα αρχείο μορφής YAML και να περάσετε αυτό το αρχείο κατά την εγκατάσταση. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Τα παραπάνω θα δημιουργήσουν έναν προεπιλεγμένο χρήστη MariaDB με το όνομα `user0`, και θα παραχωρήσουν σε αυτόν τον χρήστη πρόσβαση σε μια νέα βάση δεδομένων `user0db`, αλλά θα αποδεχτεί όλες τις υπόλοιπες προεπιλογές για αυτό το chart. Υπάρχουν δύο τρόποι για να περάσετε δεδομένα ρύθμισης παραμέτρων κατά την εγκατάσταση: - `--values` (ή `-f`): Καθορίστε ένα αρχείο YAML με παρακάμψεις. Αυτό μπορεί να καθοριστεί πολλές φορές και το δεξιότερο αρχείο θα έχει προτεραιότητα - `--set`: Καθορίστε παρακάμψεις στη γραμμή εντολών. Αν χρησιμοποιηθούν και τα δύο, οι τιμές `--set` συγχωνεύονται στις τιμές `--values` με υψηλότερη προτεραιότητα. Οι παρακάμψεις που καθορίζονται με `--set` αποθηκεύονται σε ένα Secret. Οι τιμές που έχουν οριστεί με `--set` μπορούν να προβληθούν για ένα συγκεκριμένο release με την `helm get values `. Οι τιμές που έχουν οριστεί με `--set` μπορούν να διαγραφούν εκτελώντας `helm upgrade` με την επιλογή `--reset-values`. #### Η Μορφή και οι Περιορισμοί του `--set` {#the-format-and-limitations-of-set} Η επιλογή `--set` δέχεται μηδέν ή περισσότερα ζεύγη ονόματος/τιμής. Στην απλούστερη μορφή της, χρησιμοποιείται ως εξής: `--set name=value`. Το αντίστοιχο σε YAML είναι: ```yaml name: value ``` Πολλαπλές τιμές διαχωρίζονται με χαρακτήρες `,`. Έτσι το `--set a=b,c=d` γίνεται: ```yaml a: b c: d ``` Υποστηρίζονται πιο σύνθετες εκφράσεις. Για παράδειγμα, το `--set outer.inner=value` μεταφράζεται σε αυτό: ```yaml outer: inner: value ``` Οι λίστες μπορούν να εκφραστούν περικλείοντας τιμές με `{` και `}`. Για παράδειγμα, το `--set name={a, b, c}` μεταφράζεται σε: ```yaml name: - a - b - c ``` Ορισμένα ονόματα/κλειδιά μπορούν να οριστούν σε `null` ή σε κενό πίνακα `[]`. Για παράδειγμα, το `--set name=[],a=null` μεταφράζει ```yaml name: - a - b - c a: b ``` σε ```yaml name: [] a: null ``` Από το Helm 2.5.0, είναι δυνατή η πρόσβαση σε στοιχεία λίστας χρησιμοποιώντας σύνταξη δείκτη πίνακα. Για παράδειγμα, το `--set servers[0].port=80` γίνεται: ```yaml servers: - port: 80 ``` Πολλαπλές τιμές μπορούν να οριστούν με αυτόν τον τρόπο. Η γραμμή `--set servers[0].port=80,servers[0].host=example` γίνεται: ```yaml servers: - port: 80 host: example ``` Μερικές φορές χρειάζεται να χρησιμοποιήσετε ειδικούς χαρακτήρες στις γραμμές `--set`. Μπορείτε να χρησιμοποιήσετε backslash για να διαφύγετε τους χαρακτήρες· το `--set name=value1\,value2` θα γίνει: ```yaml name: "value1,value2" ``` Ομοίως, μπορείτε να διαφύγετε ακολουθίες τελειών, κάτι που μπορεί να είναι χρήσιμο όταν τα charts χρησιμοποιούν τη συνάρτηση `toYaml` για ανάλυση annotations, labels και node selectors. Η σύνταξη για το `--set nodeSelector."kubernetes\.io/role"=master` γίνεται: ```yaml nodeSelector: kubernetes.io/role: master ``` Βαθιά ένθετες δομές δεδομένων μπορεί να είναι δύσκολο να εκφραστούν με το `--set`. Οι σχεδιαστές charts ενθαρρύνονται να λαμβάνουν υπόψη τη χρήση του `--set` κατά τον σχεδιασμό της μορφής ενός αρχείου `values.yaml` (διαβάστε περισσότερα για τα [Αρχεία Values](/chart_template_guide/values_files.md)). ### Περισσότεροι Τρόποι Εγκατάστασης {#more-installation-methods} Η εντολή `helm install` μπορεί να εγκαταστήσει από διάφορες πηγές: - Ένα chart repository (όπως είδαμε παραπάνω) - Ένα τοπικό αρχείο chart (`helm install foo foo-0.1.1.tgz`) - Έναν αποσυμπιεσμένο φάκελο chart (`helm install foo path/to/foo`) - Μια πλήρη διεύθυνση URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' και 'helm rollback': Αναβάθμιση Release και Ανάκτηση από Αποτυχία {#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure} Όταν κυκλοφορεί μια νέα έκδοση ενός chart, ή όταν θέλετε να αλλάξετε τη ρύθμιση παραμέτρων του release σας, μπορείτε να χρησιμοποιήσετε την εντολή `helm upgrade`. Μια αναβάθμιση παίρνει ένα υπάρχον release και το αναβαθμίζει σύμφωνα με τις πληροφορίες που παρέχετε. Επειδή τα Kubernetes charts μπορεί να είναι μεγάλα και σύνθετα, το Helm προσπαθεί να εκτελέσει την ελάχιστα παρεμβατική αναβάθμιση. Θα ενημερώσει μόνο πράγματα που έχουν αλλάξει από το τελευταίο release. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` Στην παραπάνω περίπτωση, το release `happy-panda` αναβαθμίζεται με το ίδιο chart, αλλά με ένα νέο αρχείο YAML: ```yaml mariadb.auth.username: user1 ``` Μπορούμε να χρησιμοποιήσουμε την `helm get values` για να δούμε αν αυτή η νέα ρύθμιση εφαρμόστηκε. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` Η εντολή `helm get` είναι ένα χρήσιμο εργαλείο για την εξέταση ενός release στο cluster. Και όπως βλέπουμε παραπάνω, δείχνει ότι οι νέες τιμές μας από το `panda.yaml` εγκαταστάθηκαν στο cluster. Τώρα, αν κάτι δεν πάει σύμφωνα με το σχέδιο κατά τη διάρκεια ενός release, είναι εύκολο να επιστρέψετε σε ένα προηγούμενο release χρησιμοποιώντας `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` Τα παραπάνω επαναφέρουν το happy-panda στην πρώτη του έκδοση release. Μια έκδοση release είναι μια αυξητική αναθεώρηση. Κάθε φορά που γίνεται εγκατάσταση, αναβάθμιση ή rollback, ο αριθμός αναθεώρησης αυξάνεται κατά 1. Ο πρώτος αριθμός αναθεώρησης είναι πάντα 1. Και μπορούμε να χρησιμοποιήσουμε την `helm history [RELEASE]` για να δούμε τους αριθμούς αναθεώρησης για ένα συγκεκριμένο release. ## Χρήσιμες Επιλογές για Install/Upgrade/Rollback {#helpful-options-for-installupgraderollback} Υπάρχουν αρκετές άλλες χρήσιμες επιλογές που μπορείτε να καθορίσετε για την προσαρμογή της συμπεριφοράς του Helm κατά τη διάρκεια μιας εγκατάστασης/αναβάθμισης/rollback. Παρακαλούμε σημειώστε ότι αυτή δεν είναι μια πλήρης λίστα flags του cli. Για να δείτε μια περιγραφή όλων των flags, απλά εκτελέστε `helm --help`. - `--timeout`: Μια τιμή [Go duration](https://golang.org/pkg/time/#ParseDuration) για να περιμένετε την ολοκλήρωση των εντολών Kubernetes. Η προεπιλογή είναι `5m0s`. - `--wait`: Περιμένει μέχρι όλα τα Pods να είναι σε κατάσταση ready, τα PVCs να είναι bound, τα Deployments να έχουν τον ελάχιστο αριθμό (`Desired` μείον `maxUnavailable`) Pods σε κατάσταση ready και τα Services να έχουν μια διεύθυνση IP (και Ingress αν είναι `LoadBalancer`) πριν σημειώσει το release ως επιτυχημένο. Θα περιμένει για όσο χρόνο ορίζει η τιμή `--timeout`. Αν φτάσει το timeout, το release θα σημειωθεί ως `FAILED`. Σημείωση: Σε σενάρια όπου το Deployment έχει `replicas` ορισμένο σε 1 και το `maxUnavailable` δεν είναι ορισμένο σε 0 ως μέρος της στρατηγικής rolling update, το `--wait` θα επιστρέψει ως ready καθώς έχει ικανοποιηθεί η ελάχιστη συνθήκη Pod σε ready. - `--no-hooks`: Παρακάμπτει την εκτέλεση hooks για την εντολή - `--recreate-pods` (διαθέσιμο μόνο για `upgrade` και `rollback`): Αυτό το flag θα προκαλέσει την αναδημιουργία όλων των pods (με εξαίρεση τα pods που ανήκουν σε deployments). (ΚΑΤΑΡΓΗΜΕΝΟ στο Helm 3) ## 'helm uninstall': Απεγκατάσταση ενός Release {#helm-uninstall-uninstalling-a-release} Όταν έρθει η ώρα να απεγκαταστήσετε ένα release από το cluster, χρησιμοποιήστε την εντολή `helm uninstall`: ```console $ helm uninstall happy-panda ``` Αυτό θα αφαιρέσει το release από το cluster. Μπορείτε να δείτε όλα τα τρέχοντα εγκατεστημένα releases σας με την εντολή `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` Από την παραπάνω έξοδο, μπορούμε να δούμε ότι το release `happy-panda` απεγκαταστάθηκε. Σε προηγούμενες εκδόσεις του Helm, όταν διαγραφόταν ένα release, παρέμενε μια εγγραφή της διαγραφής του. Στο Helm 3, η διαγραφή αφαιρεί και την εγγραφή του release. Αν θέλετε να διατηρήσετε μια εγγραφή διαγραφής του release, χρησιμοποιήστε `helm uninstall --keep-history`. Η χρήση της `helm list --uninstalled` θα εμφανίσει μόνο releases που απεγκαταστάθηκαν με το flag `--keep-history`. Το flag `helm list --all` θα σας δείξει όλες τις εγγραφές release που έχει διατηρήσει το Helm, συμπεριλαμβανομένων εγγραφών για αποτυχημένα ή διαγραμμένα στοιχεία (αν είχε καθοριστεί το `--keep-history`): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Σημειώστε ότι επειδή τα releases πλέον διαγράφονται από προεπιλογή, δεν είναι πλέον δυνατό να κάνετε rollback σε έναν απεγκατεστημένο πόρο. ## 'helm repo': Εργασία με Repositories {#helm-repo-working-with-repositories} Το Helm 3 δεν αποστέλλεται πλέον με ένα προεπιλεγμένο chart repository. Η ομάδα εντολών `helm repo` παρέχει εντολές για προσθήκη, εμφάνιση λίστας και αφαίρεση repositories. Μπορείτε να δείτε ποια repositories είναι ρυθμισμένα χρησιμοποιώντας `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Και νέα repositories μπορούν να προστεθούν με `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Επειδή τα chart repositories αλλάζουν συχνά, ανά πάσα στιγμή μπορείτε να βεβαιωθείτε ότι ο Helm client σας είναι ενημερωμένος εκτελώντας `helm repo update`. Τα repositories μπορούν να αφαιρεθούν με την `helm repo remove`. ## Δημιουργία των Δικών σας Charts {#creating-your-own-charts} Ο [Οδηγός Ανάπτυξης Chart](/topics/charts.md) εξηγεί πώς να αναπτύξετε τα δικά σας charts. Αλλά μπορείτε να ξεκινήσετε γρήγορα χρησιμοποιώντας την εντολή `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Τώρα υπάρχει ένα chart στο `./deis-workflow`. Μπορείτε να το επεξεργαστείτε και να δημιουργήσετε τα δικά σας templates. Καθώς επεξεργάζεστε το chart σας, μπορείτε να επικυρώσετε ότι είναι σωστά διαμορφωμένο εκτελώντας `helm lint`. Όταν έρθει η ώρα να πακετάρετε το chart για διανομή, μπορείτε να εκτελέσετε την εντολή `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` Και αυτό το chart μπορεί πλέον εύκολα να εγκατασταθεί με `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Τα πακεταρισμένα charts μπορούν να φορτωθούν σε chart repositories. Δείτε την τεκμηρίωση για τα [chart repositories του Helm](/topics/chart_repository.md) για περισσότερες λεπτομέρειες. ## Συμπέρασμα {#conclusion} Αυτό το κεφάλαιο κάλυψε τα βασικά μοτίβα χρήσης του `helm` client, συμπεριλαμβανομένης της αναζήτησης, εγκατάστασης, αναβάθμισης και απεγκατάστασης. Κάλυψε επίσης χρήσιμες βοηθητικές εντολές όπως `helm status`, `helm get` και `helm repo`. Για περισσότερες πληροφορίες σχετικά με αυτές τις εντολές, ρίξτε μια ματιά στη ενσωματωμένη βοήθεια του Helm: `helm help`. Στο [επόμενο κεφάλαιο](/howto/charts_tips_and_tricks.md), εξετάζουμε τη διαδικασία ανάπτυξης charts. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx ================================================ --- title: Παραδείγματα description: Παραδείγματα διαφόρων λειτουργιών του Helm SDK sidebar_position: 2 --- import CodeBlock from '@theme/CodeBlock'; import MainExampleGo from '!!raw-loader!/sdkexamples/main.go'; import InstallExampleGo from '!!raw-loader!/sdkexamples/install.go'; import ListExampleGo from '!!raw-loader!/sdkexamples/list.go'; import PullExampleGo from '!!raw-loader!/sdkexamples/pull.go'; import UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go'; import UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go'; Αυτό το έγγραφο παρουσιάζει μια σειρά παραδειγμάτων χρήσης του Helm SDK. Σκοπός του είναι να τεκμηριώσει διάφορες λειτουργίες του SDK. Το τελικό παράδειγμα δείχνει τον `main.go` driver ([σύνδεσμος](#driver)). Αυτός εκτελεί τις παρακάτω ενέργειες και περιλαμβάνει τις απαραίτητες βοηθητικές συναρτήσεις. Ο κώδικας για τα παραδείγματα βρίσκεται στον κατάλογο [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples). Και είναι σχεδιασμένος να είναι πλήρως λειτουργικός. ## Ενέργειες {#actions} ### Ενέργεια Install {#install-action} Αυτό το παράδειγμα εγκαθιστά το δοσμένο chart/release, για τη δοσμένη έκδοση και values: {InstallExampleGo} ### Ενέργεια Upgrade {#upgrade-action} Αυτό το παράδειγμα αναβαθμίζει το δοσμένο release, με το δοσμένο chart, έκδοση και values: {UpgradeExampleGo} ### Ενέργεια Uninstall {#uninstall-action} Αυτό το παράδειγμα απεγκαθιστά το δοσμένο release: {UninstallExampleGo} ### Ενέργεια List {#list-action} Αυτό το παράδειγμα παραθέτει όλα τα εγκατεστημένα charts (στο τρέχον διαμορφωμένο namespace): {ListExampleGo} ### Ενέργεια Pull {#pull-action} Αυτό το παράδειγμα κατεβάζει ένα chart από ένα OCI repository: {PullExampleGo} ## Driver {#driver} Ο driver εδώ δείχνει τις απαραίτητες βοηθητικές συναρτήσεις που χρειάζονται για να λειτουργήσουν οι ενέργειες του Helm SDK. Και δείχνει τα παραπάνω παραδείγματα σε δράση, για να κατεβάσει, εγκαταστήσει, αναβαθμίσει και απεγκαταστήσει το 'podinfo' chart από ένα OCI repository: {MainExampleGo} ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Εισαγωγή description: Εισαγωγή στο Helm Go SDK sidebar_position: 1 --- Το Go SDK του Helm επιτρέπει σε προσαρμοσμένο λογισμικό να αξιοποιεί τα Helm charts και τη λειτουργικότητα του Helm για τη διαχείριση εγκατάστασης λογισμικού στο Kubernetes (το Helm CLI είναι στην πραγματικότητα ένα τέτοιο εργαλείο!). Επί του παρόντος, το SDK έχει διαχωριστεί λειτουργικά από το Helm CLI. Το SDK μπορεί να χρησιμοποιηθεί (και χρησιμοποιείται) από αυτόνομα εργαλεία. Το Helm project έχει δεσμευτεί για τη σταθερότητα του API του SDK. Ως προειδοποίηση, το SDK διατηρεί ακόμη κάποιες ατέλειες από την αρχική εργασία διαχωρισμού CLI και SDK, τις οποίες το Helm project στοχεύει να βελτιώσει σταδιακά. Πλήρης τεκμηρίωση του API μπορεί να βρεθεί στη διεύθυνση [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Μια σύντομη επισκόπηση ορισμένων από τους κύριους τύπους πακέτων και ένα απλό παράδειγμα ακολουθούν παρακάτω. Δείτε την ενότητα [Παραδείγματα](/sdk/examples.mdx) για περισσότερα παραδείγματα και έναν πιο ολοκληρωμένο 'driver'. ## Επισκόπηση των κύριων πακέτων {#main-package-overview} - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Περιέχει τον κύριο "client" για την εκτέλεση ενεργειών Helm. Αυτό είναι το ίδιο πακέτο που χρησιμοποιεί το CLI εσωτερικά. Αν χρειάζεστε απλώς να εκτελέσετε βασικές εντολές Helm από άλλο πρόγραμμα Go, αυτό είναι το πακέτο για εσάς - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Μέθοδοι και βοηθητικά εργαλεία για τη φόρτωση και χειρισμό charts - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) και τα υποπακέτα του: Περιέχει όλους τους handlers για τις τυπικές μεταβλητές περιβάλλοντος του Helm. Τα υποπακέτα περιέχουν χειρισμό εξόδου και αρχείων values - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Ορίζει το αντικείμενο `Release` και τις καταστάσεις του Υπάρχουν πολλά περισσότερα πακέτα εκτός από αυτά, οπότε δείτε την τεκμηρίωση για περισσότερες πληροφορίες! ### Απλό παράδειγμα {#simple-example} Αυτό είναι ένα απλό παράδειγμα εκτέλεσης `helm list` χρησιμοποιώντας το Go SDK. Δείτε την ενότητα [Παραδείγματα](/sdk/examples.mdx) για πιο ολοκληρωμένα παραδείγματα. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Συμβατότητα {#compatibility} Το Helm SDK ακολουθεί ρητά τις εγγυήσεις συμβατότητας προς τα πίσω του Helm: Αυτό σημαίνει ότι αλλαγές που διακόπτουν τη συμβατότητα θα γίνονται μόνο μεταξύ major versions. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Προηγμένες Τεχνικές Helm description: Εξηγεί διάφορες προηγμένες δυνατότητες για προχωρημένους χρήστες του Helm sidebar_position: 9 --- Αυτή η ενότητα εξηγεί διάφορες προηγμένες δυνατότητες και τεχνικές για τη χρήση του Helm. Οι πληροφορίες σε αυτή την ενότητα προορίζονται για "προχωρημένους χρήστες" του Helm που επιθυμούν να κάνουν προηγμένη προσαρμογή και χειρισμό των charts και releases τους. Κάθε μία από αυτές τις προηγμένες δυνατότητες έρχεται με τους δικούς της συμβιβασμούς και προειδοποιήσεις, επομένως καθεμία πρέπει να χρησιμοποιείται προσεκτικά και με βαθιά γνώση του Helm. Ή με άλλα λόγια, να θυμάστε την [αρχή του Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility) ## Post Rendering {#post-rendering} Το Post rendering δίνει στους χρήστες που εγκαθιστούν charts τη δυνατότητα να χειριστούν χειροκίνητα, να ρυθμίσουν ή/και να επαληθεύσουν τα παραγόμενα manifests πριν εγκατασταθούν από το Helm. Έτσι, χρήστες με προηγμένες ανάγκες ρύθμισης μπορούν να χρησιμοποιήσουν εργαλεία όπως το [`kustomize`](https://kustomize.io) για να εφαρμόσουν αλλαγές διαμόρφωσης χωρίς να χρειάζεται να κάνουν fork ένα δημόσιο chart ή να απαιτούν από τους συντηρητές του chart να καθορίσουν κάθε δυνατή επιλογή διαμόρφωσης. Υπάρχουν επίσης περιπτώσεις χρήσης για την ένεση κοινών εργαλείων και sidecars σε εταιρικά περιβάλλοντα ή για την ανάλυση των manifests πριν από το deployment. ### Προαπαιτούμενα {#prerequisites} - Helm 3.1+ ### Χρήση {#usage} Ένας post-renderer μπορεί να είναι οποιοδήποτε εκτελέσιμο αρχείο που δέχεται παραγόμενα Kubernetes manifests στο STDIN και επιστρέφει έγκυρα Kubernetes manifests στο STDOUT. Θα πρέπει να επιστρέφει έναν μη-μηδενικό κωδικό εξόδου σε περίπτωση αποτυχίας. Αυτό είναι το μόνο "API" μεταξύ των δύο στοιχείων. Επιτρέπει μεγάλη ευελιξία σε αυτό που μπορείτε να κάνετε με τη διαδικασία post-render. Ένας post-renderer μπορεί να χρησιμοποιηθεί με τις εντολές `install`, `upgrade` και `template`. Για να χρησιμοποιήσετε έναν post-renderer, χρησιμοποιήστε την επιλογή `--post-renderer` με μια διαδρομή προς το εκτελέσιμο renderer που επιθυμείτε να χρησιμοποιήσετε: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Αν η διαδρομή δεν περιέχει διαχωριστικά, θα αναζητήσει στο $PATH, διαφορετικά θα επιλύσει τυχόν σχετικές διαδρομές σε πλήρως προσδιορισμένες διαδρομές. Αν επιθυμείτε να χρησιμοποιήσετε πολλαπλούς post-renderers, καλέστε τους όλους σε ένα script ή μαζί σε οποιοδήποτε binary εργαλείο έχετε δημιουργήσει. Στο bash, αυτό θα ήταν τόσο απλό όσο `renderer1 | renderer2 | renderer3`. Μπορείτε να δείτε ένα παράδειγμα χρήσης του `kustomize` ως post renderer [εδώ](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Προειδοποιήσεις {#caveats} Όταν χρησιμοποιείτε post renderers, υπάρχουν αρκετά σημαντικά πράγματα που πρέπει να έχετε υπόψη σας. Το πιο σημαντικό από αυτά είναι ότι όταν χρησιμοποιείτε έναν post-renderer, όλα τα άτομα που τροποποιούν αυτό το release **ΠΡΕΠΕΙ** να χρησιμοποιούν τον ίδιο renderer για να έχουν επαναλήψιμες κατασκευές. Αυτή η δυνατότητα είναι σκόπιμα σχεδιασμένη ώστε να επιτρέπει σε οποιονδήποτε χρήστη να αλλάξει τον renderer που χρησιμοποιεί ή να σταματήσει να χρησιμοποιεί renderer, αλλά αυτό θα πρέπει να γίνεται σκόπιμα για να αποφευχθεί τυχαία τροποποίηση ή απώλεια δεδομένων. Μια άλλη σημαντική σημείωση αφορά την ασφάλεια. Αν χρησιμοποιείτε έναν post-renderer, θα πρέπει να διασφαλίσετε ότι προέρχεται από αξιόπιστη πηγή (όπως ισχύει για οποιοδήποτε άλλο αυθαίρετο εκτελέσιμο). Η χρήση μη αξιόπιστων ή μη επαληθευμένων renderers ΔΕΝ συνιστάται καθώς έχουν πλήρη πρόσβαση στα παραγόμενα templates, τα οποία συχνά περιέχουν ευαίσθητα δεδομένα. ### Προσαρμοσμένοι Post Renderers {#custom-post-renderers} Το βήμα post render προσφέρει ακόμη περισσότερη ευελιξία όταν χρησιμοποιείται με το Go SDK. Οποιοσδήποτε post renderer χρειάζεται μόνο να υλοποιήσει το ακόλουθο Go interface: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Για περισσότερες πληροφορίες σχετικά με τη χρήση του Go SDK, δείτε την [ενότητα Go SDK](#go-sdk) ## Go SDK {#go-sdk} Το Helm 3 παρουσίασε ένα πλήρως αναδιαρθρωμένο Go SDK για καλύτερη εμπειρία κατά τη δημιουργία λογισμικού και εργαλείων που αξιοποιούν το Helm. Η πλήρης τεκμηρίωση βρίσκεται στην [Ενότητα Go SDK](/sdk/gosdk.md). ## Backends αποθήκευσης {#storage-backends} Το Helm 3 άλλαξε την προεπιλεγμένη αποθήκευση πληροφοριών release σε Secrets μέσα στο namespace του release. Το Helm 2 εξ ορισμού αποθηκεύει πληροφορίες release ως ConfigMaps στο namespace της instance του Tiller. Οι ακόλουθες υποενότητες δείχνουν πώς να ρυθμίσετε διαφορετικά backends. Αυτή η ρύθμιση βασίζεται στη μεταβλητή περιβάλλοντος `HELM_DRIVER`. Μπορεί να οριστεί σε μία από τις τιμές: `[configmap, secret, sql]`. ### Backend αποθήκευσης ConfigMap {#configmap-storage-backend} Για να ενεργοποιήσετε το ConfigMap backend, θα πρέπει να ορίσετε τη μεταβλητή περιβάλλοντος `HELM_DRIVER` σε `configmap`. Μπορείτε να το ορίσετε σε ένα shell ως εξής: ```shell export HELM_DRIVER=configmap ``` Αν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο ConfigMap backend, θα πρέπει να κάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες release με την ακόλουθη εντολή: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ**: Οι πληροφορίες release περιλαμβάνουν τα περιεχόμενα των charts και των αρχείων values, και επομένως μπορεί να περιέχουν ευαίσθητα δεδομένα (όπως κωδικούς πρόσβασης, ιδιωτικά κλειδιά και άλλα διαπιστευτήρια) που πρέπει να προστατευθούν από μη εξουσιοδοτημένη πρόσβαση. Κατά τη διαχείριση της εξουσιοδότησης Kubernetes, για παράδειγμα με το [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), είναι δυνατόν να παραχωρηθεί ευρύτερη πρόσβαση σε πόρους ConfigMap, ενώ περιορίζεται η πρόσβαση σε πόρους Secret. Για παράδειγμα, ο προεπιλεγμένος [ρόλος χρήστη](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" παρέχει πρόσβαση στους περισσότερους πόρους, αλλά όχι στα Secrets. Επιπλέον, τα δεδομένα secrets μπορούν να ρυθμιστούν για [κρυπτογραφημένη αποθήκευση](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Παρακαλούμε να το έχετε αυτό υπόψη σας αν αποφασίσετε να αλλάξετε στο ConfigMap backend, καθώς θα μπορούσε να εκθέσει τα ευαίσθητα δεδομένα της εφαρμογής σας. ### Backend αποθήκευσης SQL {#sql-storage-backend} Υπάρχει ένα ***beta*** SQL backend αποθήκευσης που αποθηκεύει πληροφορίες release σε μια βάση δεδομένων SQL. Η χρήση ενός τέτοιου backend αποθήκευσης είναι ιδιαίτερα χρήσιμη αν οι πληροφορίες release σας ζυγίζουν περισσότερο από 1MB (σε αυτή την περίπτωση, δεν μπορούν να αποθηκευτούν σε ConfigMaps/Secrets λόγω εσωτερικών ορίων στο υποκείμενο etcd key-value store του Kubernetes). Για να ενεργοποιήσετε το SQL backend, θα πρέπει να αναπτύξετε μια βάση δεδομένων SQL και να ορίσετε τη μεταβλητή περιβάλλοντος `HELM_DRIVER` σε `sql`. Οι λεπτομέρειες της βάσης δεδομένων ορίζονται με τη μεταβλητή περιβάλλοντος `HELM_DRIVER_SQL_CONNECTION_STRING`. Μπορείτε να τα ορίσετε σε ένα shell ως εξής: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Σημείωση: Αυτή τη στιγμή υποστηρίζεται μόνο η PostgreSQL. **ΣΗΜΕΙΩΣΕΙΣ ΠΑΡΑΓΩΓΗΣ**: Συνιστάται να: - Κάνετε τη βάση δεδομένων σας έτοιμη για παραγωγή. Για PostgreSQL, ανατρέξτε στην τεκμηρίωση [Server Administration](https://www.postgresql.org/docs/12/admin.html) για περισσότερες λεπτομέρειες - Ενεργοποιήσετε τη [διαχείριση δικαιωμάτων](/topics/permissions_sql_storage_backend.md) για να αντικατοπτρίζει το Kubernetes RBAC για τις πληροφορίες release Αν θέλετε να αλλάξετε από το προεπιλεγμένο backend στο SQL backend, θα πρέπει να κάνετε τη μετάβαση μόνοι σας. Μπορείτε να ανακτήσετε τις πληροφορίες release με την ακόλουθη εντολή: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Αρχιτεκτονική του Helm description: Περιγράφει την αρχιτεκτονική του Helm σε υψηλό επίπεδο. sidebar_position: 8 --- # Αρχιτεκτονική του Helm {#helm-architecture} Αυτό το έγγραφο περιγράφει την αρχιτεκτονική του Helm σε υψηλό επίπεδο. ## Ο Σκοπός του Helm {#the-purpose-of-helm} Το Helm είναι ένα εργαλείο για τη διαχείριση πακέτων Kubernetes που ονομάζονται _charts_. Το Helm μπορεί να κάνει τα εξής: - Δημιουργία νέων charts από την αρχή - Πακετάρισμα charts σε αρχεία αρχειοθέτησης chart (tgz) - Αλληλεπίδραση με αποθετήρια charts όπου αποθηκεύονται τα charts - Εγκατάσταση και απεγκατάσταση charts σε ένα υπάρχον cluster Kubernetes - Διαχείριση του κύκλου release των charts που έχουν εγκατασταθεί με το Helm Στο Helm, υπάρχουν τρεις σημαντικές έννοιες: 1. Το _chart_ είναι ένα σύνολο πληροφοριών που απαιτούνται για τη δημιουργία μιας instance μιας εφαρμογής Kubernetes. 2. Το _config_ περιέχει πληροφορίες ρύθμισης παραμέτρων που μπορούν να συγχωνευθούν με ένα πακεταρισμένο chart για τη δημιουργία ενός αντικειμένου έτοιμου προς κυκλοφορία. 3. Ένα _release_ είναι μια εκτελούμενη instance ενός _chart_, συνδυασμένη με συγκεκριμένη _config_. ## Στοιχεία {#components} Το Helm είναι ένα εκτελέσιμο αρχείο που αποτελείται από δύο διακριτά μέρη: **Ο Helm Client** είναι ένας client γραμμής εντολών για τους τελικούς χρήστες. Ο client είναι υπεύθυνος για τα εξής: - Τοπική ανάπτυξη charts - Διαχείριση αποθετηρίων - Διαχείριση releases - Διασύνδεση με τη βιβλιοθήκη Helm - Αποστολή charts για εγκατάσταση - Αίτηση αναβάθμισης ή απεγκατάστασης υπαρχόντων releases **Η Βιβλιοθήκη Helm** παρέχει τη λογική για την εκτέλεση όλων των λειτουργιών του Helm. Διασυνδέεται με τον Kubernetes API server και παρέχει τις ακόλουθες δυνατότητες: - Συνδυασμός ενός chart και μιας ρύθμισης παραμέτρων για τη δημιουργία ενός release - Εγκατάσταση charts στο Kubernetes και παροχή του αντίστοιχου αντικειμένου release - Αναβάθμιση και απεγκατάσταση charts μέσω αλληλεπίδρασης με το Kubernetes Η αυτόνομη βιβλιοθήκη Helm ενθυλακώνει τη λογική του Helm ώστε να μπορεί να αξιοποιηθεί από διαφορετικούς clients. ## Υλοποίηση {#implementation} Ο Helm client και η βιβλιοθήκη είναι γραμμένοι στη γλώσσα προγραμματισμού Go. Η βιβλιοθήκη χρησιμοποιεί τη client library του Kubernetes για την επικοινωνία με το Kubernetes. Επί του παρόντος, αυτή η βιβλιοθήκη χρησιμοποιεί REST+JSON. Αποθηκεύει πληροφορίες σε Secrets μέσα στο Kubernetes. Δεν χρειάζεται τη δική της βάση δεδομένων. Τα αρχεία ρύθμισης παραμέτρων, όπου είναι δυνατόν, γράφονται σε YAML. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Οδηγός Αποθετηρίου Chart description: Πώς να δημιουργήσετε και να εργαστείτε με αποθετήρια Helm chart. sidebar_position: 6 --- Αυτή η ενότητα εξηγεί πώς να δημιουργήσετε και να εργαστείτε με αποθετήρια Helm chart. Ουσιαστικά, ένα αποθετήριο chart είναι μια τοποθεσία όπου μπορούν να αποθηκεύονται και να διαμοιράζονται πακεταρισμένα charts. Το κατανεμημένο κοινοτικό αποθετήριο Helm chart βρίσκεται στο [Artifact Hub](https://artifacthub.io/packages/search?kind=0) και δέχεται συνεισφορές. Ωστόσο, το Helm επιτρέπει επίσης τη δημιουργία και λειτουργία του δικού σας αποθετηρίου chart. Αυτός ο οδηγός εξηγεί πώς να το κάνετε. Αν σκέφτεστε να δημιουργήσετε ένα αποθετήριο chart, ίσως θέλετε να εξετάσετε τη χρήση ενός [μητρώου OCI](/topics/registries.md) ως εναλλακτική. ## Προαπαιτούμενα {#prerequisites} * Ολοκληρώστε τον οδηγό [Γρήγορης Εκκίνησης](/intro/quickstart.md) * Διαβάστε το έγγραφο [Charts](/topics/charts.md) ## Δημιουργία αποθετηρίου chart {#create-a-chart-repository} Ένα _αποθετήριο chart_ είναι ένας διακομιστής HTTP που φιλοξενεί ένα αρχείο `index.yaml` και προαιρετικά κάποια πακεταρισμένα charts. Όταν είστε έτοιμοι να διαμοιραστείτε τα charts σας, ο προτιμώμενος τρόπος είναι να τα ανεβάσετε σε ένα αποθετήριο chart. Από το Helm 2.2.0, υποστηρίζεται η αυθεντικοποίηση SSL πελάτη προς ένα αποθετήριο. Άλλα πρωτόκολλα αυθεντικοποίησης μπορεί να είναι διαθέσιμα ως plugins. Επειδή ένα αποθετήριο chart μπορεί να είναι οποιοσδήποτε διακομιστής HTTP που μπορεί να εξυπηρετεί αρχεία YAML και tar και να απαντά σε αιτήματα GET, έχετε πολλές επιλογές όταν πρόκειται να φιλοξενήσετε το δικό σας αποθετήριο chart. Για παράδειγμα, μπορείτε να χρησιμοποιήσετε ένα Google Cloud Storage (GCS) bucket, Amazon S3 bucket, GitHub Pages, ή ακόμα να δημιουργήσετε τον δικό σας διακομιστή ιστού. ### Η δομή του αποθετηρίου chart {#the-chart-repository-structure} Ένα αποθετήριο chart αποτελείται από πακεταρισμένα charts και ένα ειδικό αρχείο που ονομάζεται `index.yaml`, το οποίο περιέχει ένα ευρετήριο όλων των charts στο αποθετήριο. Συχνά, τα charts που περιγράφει το `index.yaml` φιλοξενούνται επίσης στον ίδιο διακομιστή, όπως και τα [αρχεία προέλευσης](/topics/provenance.md). Για παράδειγμα, η διάρθρωση του αποθετηρίου `https://example.com/charts` μπορεί να μοιάζει ως εξής: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` Σε αυτή την περίπτωση, το αρχείο ευρετηρίου θα περιέχει πληροφορίες για ένα chart, το Alpine chart, και θα παρέχει τη διεύθυνση λήψης `https://example.com/charts/alpine-0.1.2.tgz` για αυτό το chart. Δεν είναι απαραίτητο το πακέτο chart να βρίσκεται στον ίδιο διακομιστή με το αρχείο `index.yaml`. Ωστόσο, αυτό είναι συνήθως η ευκολότερη λύση. ### Το αρχείο ευρετηρίου {#the-index-file} Το αρχείο ευρετηρίου είναι ένα αρχείο yaml που ονομάζεται `index.yaml`. Περιέχει κάποια μεταδεδομένα για το πακέτο, συμπεριλαμβανομένων των περιεχομένων του αρχείου `Chart.yaml` ενός chart. Ένα έγκυρο αποθετήριο chart πρέπει να έχει ένα αρχείο ευρετηρίου. Το αρχείο ευρετηρίου περιέχει πληροφορίες για κάθε chart στο αποθετήριο chart. Η εντολή `helm repo index` θα δημιουργήσει ένα αρχείο ευρετηρίου βασισμένο σε έναν τοπικό κατάλογο που περιέχει πακεταρισμένα charts. Αυτό είναι ένα παράδειγμα αρχείου ευρετηρίου: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Φιλοξενία Αποθετηρίων Chart {#hosting-chart-repositories} Αυτό το μέρος παρουσιάζει διάφορους τρόπους εξυπηρέτησης ενός αποθετηρίου chart. ### Google Cloud Storage {#google-cloud-storage} Το πρώτο βήμα είναι να **δημιουργήσετε το GCS bucket σας**. Θα ονομάσουμε το δικό μας `fantastic-charts`. ![Δημιουργία GCS Bucket](/img/helm2/create-a-bucket.png) Στη συνέχεια, κάντε το bucket σας δημόσιο **επεξεργαζόμενοι τα δικαιώματα του bucket**. ![Επεξεργασία Δικαιωμάτων](/img/helm2/edit-permissions.png) Εισάγετε αυτή τη γραμμή για να **κάνετε το bucket σας δημόσιο**: ![Κάντε το Bucket Δημόσιο](/img/helm2/make-bucket-public.png) Συγχαρητήρια, τώρα έχετε ένα κενό GCS bucket έτοιμο να εξυπηρετήσει charts! Μπορείτε να ανεβάσετε το αποθετήριο chart σας χρησιμοποιώντας το εργαλείο γραμμής εντολών Google Cloud Storage ή τη διεπαφή ιστού GCS. Ένα δημόσιο GCS bucket μπορεί να προσπελαστεί μέσω απλού HTTPS στη διεύθυνση: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith {#cloudsmith} Μπορείτε επίσης να δημιουργήσετε αποθετήρια chart χρησιμοποιώντας το Cloudsmith. Διαβάστε περισσότερα για τα αποθετήρια chart με Cloudsmith [εδώ](https://help.cloudsmith.io/docs/helm-chart-repository). ### JFrog Artifactory {#jfrog-artifactory} Παρομοίως, μπορείτε να δημιουργήσετε αποθετήρια chart χρησιμοποιώντας το JFrog Artifactory. Διαβάστε περισσότερα για τα αποθετήρια chart με JFrog Artifactory [εδώ](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). ### Παράδειγμα με GitHub Pages {#github-pages-example} Με παρόμοιο τρόπο μπορείτε να δημιουργήσετε αποθετήριο charts χρησιμοποιώντας GitHub Pages. Το GitHub σάς επιτρέπει να εξυπηρετείτε στατικές ιστοσελίδες με δύο διαφορετικούς τρόπους: - Διαμορφώνοντας ένα έργο να εξυπηρετεί τα περιεχόμενα του καταλόγου `docs/` - Διαμορφώνοντας ένα έργο να εξυπηρετεί ένα συγκεκριμένο branch Θα ακολουθήσουμε τη δεύτερη προσέγγιση, αν και η πρώτη είναι εξίσου εύκολη. Το πρώτο βήμα θα είναι να **δημιουργήσετε το gh-pages branch σας**. Μπορείτε να το κάνετε τοπικά ως εξής: ```console $ git checkout -b gh-pages ``` Ή μέσω browser χρησιμοποιώντας το κουμπί **Branch** στο GitHub repository σας: ![Δημιουργία GitHub Pages branch](/img/helm2/create-a-gh-page-button.png) Στη συνέχεια, θέλετε να βεβαιωθείτε ότι το **gh-pages branch** σας έχει οριστεί ως GitHub Pages. Κάντε κλικ στις **Settings** του repository σας και μετακινηθείτε στην ενότητα **GitHub pages** και ρυθμίστε ως εξής: ![Δημιουργία GitHub Pages branch](/img/helm2/set-a-gh-page.png) Από προεπιλογή, το **Source** συνήθως ορίζεται στο **gh-pages branch**. Αν αυτό δεν είναι ρυθμισμένο από προεπιλογή, τότε επιλέξτε το. Μπορείτε να χρησιμοποιήσετε ένα **custom domain** αν θέλετε. Και βεβαιωθείτε ότι το **Enforce HTTPS** είναι επιλεγμένο, έτσι ώστε το **HTTPS** να χρησιμοποιείται κατά την εξυπηρέτηση των charts. Με αυτή τη ρύθμιση μπορείτε να χρησιμοποιήσετε το default branch σας για να αποθηκεύσετε τον κώδικα των charts σας, και το **gh-pages branch** ως αποθετήριο charts, π.χ.: `https://USERNAME.github.io/REPONAME`. Το επιδεικτικό αποθετήριο [TS Charts](https://github.com/technosophos/tscharts) είναι προσβάσιμο στη διεύθυνση `https://technosophos.github.io/tscharts/`. Αν έχετε αποφασίσει να χρησιμοποιήσετε GitHub pages για να φιλοξενήσετε το αποθετήριο chart, δείτε το [Chart Releaser Action](/howto/chart_releaser_action.md). Το Chart Releaser Action είναι μια ροή εργασίας GitHub Action για τη μετατροπή ενός GitHub project σε αυτο-φιλοξενούμενο αποθετήριο Helm chart, χρησιμοποιώντας το εργαλείο CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Απλοί διακομιστές ιστού {#ordinary-web-servers} Για να διαμορφώσετε έναν απλό διακομιστή ιστού να εξυπηρετεί Helm charts, χρειάζεται απλώς να κάνετε τα εξής: - Τοποθετήστε το ευρετήριο και τα charts σας σε έναν κατάλογο που μπορεί να εξυπηρετήσει ο διακομιστής - Βεβαιωθείτε ότι το αρχείο `index.yaml` είναι προσβάσιμο χωρίς απαίτηση αυθεντικοποίησης - Βεβαιωθείτε ότι τα αρχεία `yaml` εξυπηρετούνται με τον σωστό τύπο περιεχομένου (`text/yaml` ή `text/x-yaml`) Για παράδειγμα, αν θέλετε να εξυπηρετήσετε τα charts σας από το `$WEBROOT/charts`, βεβαιωθείτε ότι υπάρχει ένας κατάλογος `charts/` στο web root σας, και τοποθετήστε το αρχείο ευρετηρίου και τα charts μέσα σε αυτόν τον φάκελο. ### Διακομιστής Αποθετηρίου ChartMuseum {#chartmuseum-repository-server} Το ChartMuseum είναι ένας ανοιχτού κώδικα διακομιστής αποθετηρίου Helm Chart γραμμένος σε Go (Golang), με υποστήριξη για backends αποθήκευσης cloud, συμπεριλαμβανομένων [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), και [etcd](https://etcd.io/). Μπορείτε επίσης να χρησιμοποιήσετε τον διακομιστή [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) για να φιλοξενήσετε ένα αποθετήριο chart από ένα τοπικό σύστημα αρχείων. ### Μητρώο Πακέτων GitLab {#gitlab-package-registry} Με το GitLab μπορείτε να δημοσιεύσετε Helm charts στο Package Registry του project σας. Διαβάστε περισσότερα για τη ρύθμιση ενός αποθετηρίου Helm πακέτων με GitLab [εδώ](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Διαχείριση Αποθετηρίων Chart {#managing-chart-repositories} Τώρα που έχετε ένα αποθετήριο chart, το τελευταίο μέρος αυτού του οδηγού εξηγεί πώς να διατηρείτε τα charts σε αυτό το αποθετήριο. ### Αποθήκευση charts στο αποθετήριο chart σας {#store-charts-in-your-chart-repository} Τώρα που έχετε ένα αποθετήριο chart, ας ανεβάσουμε ένα chart και ένα αρχείο ευρετηρίου στο αποθετήριο. Τα charts σε ένα αποθετήριο chart πρέπει να είναι πακεταρισμένα (`helm package chart-name/`) και σωστά εκδοθέντα (ακολουθώντας τις οδηγίες [SemVer 2](https://semver.org/)). Τα επόμενα βήματα αποτελούν ένα παράδειγμα ροής εργασίας, αλλά μπορείτε να χρησιμοποιήσετε όποια ροή εργασίας προτιμάτε για την αποθήκευση και ενημέρωση charts στο αποθετήριο chart σας. Αφού έχετε ένα πακεταρισμένο chart έτοιμο, δημιουργήστε έναν νέο κατάλογο και μετακινήστε το πακεταρισμένο chart σας σε αυτόν τον κατάλογο. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` Η τελευταία εντολή παίρνει τη διαδρομή του τοπικού καταλόγου που μόλις δημιουργήσατε και τη διεύθυνση URL του απομακρυσμένου αποθετηρίου chart σας και συνθέτει ένα αρχείο `index.yaml` μέσα στη δεδομένη διαδρομή καταλόγου. Τώρα μπορείτε να ανεβάσετε το chart και το αρχείο ευρετηρίου στο αποθετήριο chart σας χρησιμοποιώντας ένα εργαλείο συγχρονισμού ή χειροκίνητα. Αν χρησιμοποιείτε Google Cloud Storage, δείτε αυτό το [παράδειγμα ροής εργασίας](/howto/chart_repository_sync_example.md) χρησιμοποιώντας τον gsutil client. Για GitHub, μπορείτε απλά να τοποθετήσετε τα charts στο κατάλληλο branch προορισμού. ### Προσθήκη νέων charts σε υπάρχον αποθετήριο {#add-new-charts-to-an-existing-repository} Κάθε φορά που θέλετε να προσθέσετε ένα νέο chart στο αποθετήριό σας, πρέπει να αναδημιουργήσετε το ευρετήριο. Η εντολή `helm repo index` θα ξαναχτίσει πλήρως το αρχείο `index.yaml` από την αρχή, συμπεριλαμβάνοντας μόνο τα charts που βρίσκει τοπικά. Ωστόσο, μπορείτε να χρησιμοποιήσετε τη σημαία `--merge` για να προσθέσετε σταδιακά νέα charts σε ένα υπάρχον αρχείο `index.yaml` (μια εξαιρετική επιλογή όταν εργάζεστε με απομακρυσμένο αποθετήριο όπως το GCS). Εκτελέστε `helm repo index --help` για να μάθετε περισσότερα. Βεβαιωθείτε ότι ανεβάζετε τόσο το αναθεωρημένο αρχείο `index.yaml` όσο και το chart. Και αν δημιουργήσατε αρχείο προέλευσης, ανεβάστε και αυτό. ### Διαμοιρασμός των charts σας με άλλους {#share-your-charts-with-others} Όταν είστε έτοιμοι να διαμοιραστείτε τα charts σας, απλά ενημερώστε κάποιον ποια είναι η διεύθυνση URL του αποθετηρίου σας. Από εκεί, θα προσθέσουν το αποθετήριο στον Helm client τους μέσω της εντολής `helm repo add [ΟΝΟΜΑ] [URL]` με οποιοδήποτε όνομα θέλουν να χρησιμοποιήσουν για να αναφέρονται στο αποθετήριο. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Αν τα charts υποστηρίζονται από βασική αυθεντικοποίηση HTTP, μπορείτε επίσης να παρέχετε το όνομα χρήστη και τον κωδικό πρόσβασης εδώ: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Σημείωση:** Ένα αποθετήριο δεν θα προστεθεί αν δεν περιέχει ένα έγκυρο `index.yaml`. **Σημείωση:** Αν το αποθετήριο Helm σας χρησιμοποιεί π.χ. αυτο-υπογεγραμμένο πιστοποιητικό, μπορείτε να χρησιμοποιήσετε `helm repo add --insecure-skip-tls-verify ...` για να παραλείψετε την επαλήθευση CA. Μετά από αυτό, οι χρήστες σας θα μπορούν να αναζητούν στα charts σας. Αφού ενημερώσετε το αποθετήριο, μπορούν να χρησιμοποιήσουν την εντολή `helm repo update` για να λάβουν τις τελευταίες πληροφορίες charts. *Εσωτερικά, οι εντολές `helm repo add` και `helm repo update` ανακτούν το αρχείο index.yaml και το αποθηκεύουν στον κατάλογο `$XDG_CACHE_HOME/helm/repository/cache/`. Εκεί βρίσκει η συνάρτηση `helm search` πληροφορίες για τα charts.* ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Δοκιμές Charts description: Περιγράφει τον τρόπο εκτέλεσης και δοκιμής των charts σας. sidebar_position: 3 --- Ένα chart περιέχει πολλούς πόρους Kubernetes και components που λειτουργούν μαζί. Ως δημιουργός chart, μπορεί να θέλετε να γράψετε κάποιες δοκιμές που επαληθεύουν ότι το chart σας λειτουργεί όπως αναμένεται κατά την εγκατάσταση. Αυτές οι δοκιμές βοηθούν επίσης τους χρήστες του chart να κατανοήσουν τι υποτίθεται ότι κάνει το chart σας. Μια **δοκιμή** σε ένα Helm chart βρίσκεται στον φάκελο `templates/` και είναι ένας ορισμός Job που καθορίζει ένα container με μια συγκεκριμένη εντολή προς εκτέλεση. Το container πρέπει να τερματίσει επιτυχώς (exit 0) για να θεωρηθεί η δοκιμή επιτυχής. Ο ορισμός του Job πρέπει να περιέχει το annotation hook δοκιμής του Helm: `helm.sh/hook: test`. Σημειώστε ότι μέχρι το Helm v3, ο ορισμός του Job έπρεπε να περιέχει ένα από τα παρακάτω annotations hook δοκιμής του Helm: `helm.sh/hook: test-success` ή `helm.sh/hook: test-failure`. Το `helm.sh/hook: test-success` εξακολουθεί να γίνεται αποδεκτό ως εναλλακτική επιλογή συμβατή προς τα πίσω αντί του `helm.sh/hook: test`. Παραδείγματα δοκιμών: - Επαλήθευση ότι η ρύθμιση παραμέτρων από το αρχείο values.yaml εισήχθη σωστά. - Βεβαιωθείτε ότι το όνομα χρήστη και ο κωδικός πρόσβασης λειτουργούν σωστά - Βεβαιωθείτε ότι ένα εσφαλμένο όνομα χρήστη και κωδικός πρόσβασης δεν λειτουργεί - Επιβεβαίωση ότι οι υπηρεσίες σας είναι ενεργές και κατανέμουν σωστά το φορτίο - κ.λπ. Μπορείτε να εκτελέσετε τις προκαθορισμένες δοκιμές του Helm σε ένα release χρησιμοποιώντας την εντολή `helm test `. Για τους χρήστες ενός chart, αυτός είναι ένας εξαιρετικός τρόπος να ελέγξουν ότι το release του chart (ή της εφαρμογής) λειτουργεί όπως αναμένεται. ## Παράδειγμα Δοκιμής {#example-test} Η εντολή [helm create](/helm/helm_create.md) δημιουργεί αυτόματα έναν αριθμό φακέλων και αρχείων. Για να δοκιμάσετε τη λειτουργικότητα του helm test, δημιουργήστε πρώτα ένα demo Helm chart. ```console $ helm create demo ``` Θα μπορείτε πλέον να δείτε την ακόλουθη δομή στο demo Helm chart σας. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` Στο `demo/templates/tests/test-connection.yaml` θα βρείτε μια δοκιμή που μπορείτε να δοκιμάσετε. Παρακάτω μπορείτε να δείτε τον ορισμό του pod δοκιμής του Helm: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Βήματα για την Εκτέλεση μιας Σουίτας Δοκιμών σε ένα Release {#steps-to-run-a-test-suite-on-a-release} Πρώτα, εγκαταστήστε το chart στο cluster σας για να δημιουργήσετε ένα release. Μπορεί να χρειαστεί να περιμένετε μέχρι όλα τα pods να γίνουν ενεργά· αν εκτελέσετε τη δοκιμή αμέσως μετά την εγκατάσταση, μπορεί να εμφανιστεί παροδικό σφάλμα και θα θέλετε να επαναλάβετε τη δοκιμή. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Σημειώσεις {#notes} - Μπορείτε να ορίσετε όσες δοκιμές θέλετε σε ένα μόνο αρχείο yaml ή να τις κατανείμετε σε πολλά αρχεία yaml στον φάκελο `templates/`. - Μπορείτε να τοποθετήσετε τη σουίτα δοκιμών σας σε έναν υποφάκελο `tests/` όπως `/templates/tests/` για καλύτερη απομόνωση. - Μια δοκιμή είναι ένα [Helm hook](/topics/charts_hooks.md), επομένως annotations όπως `helm.sh/hook-weight` και `helm.sh/hook-delete-policy` μπορούν να χρησιμοποιηθούν με τους πόρους δοκιμών. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Charts description: Εξηγεί τη μορφή των charts και παρέχει βασικές οδηγίες για τη δημιουργία charts με το Helm. sidebar_position: 1 --- Το Helm χρησιμοποιεί μια μορφή πακεταρίσματος που ονομάζεται _charts_. Ένα chart είναι μια συλλογή αρχείων που περιγράφουν ένα σύνολο σχετικών πόρων του Kubernetes. Ένα chart μπορεί να χρησιμοποιηθεί για να αναπτύξει κάτι απλό, όπως ένα memcached pod, ή κάτι πολύπλοκο, όπως μια πλήρη στοίβα web εφαρμογής με HTTP servers, βάσεις δεδομένων, caches κ.λπ. Τα charts δημιουργούνται ως αρχεία διατεταγμένα σε μια συγκεκριμένη δομή καταλόγων. Μπορούν να πακεταριστούν σε versioned αρχεία για ανάπτυξη. Αν θέλετε να κατεβάσετε και να δείτε τα αρχεία ενός δημοσιευμένου chart, χωρίς να το εγκαταστήσετε, μπορείτε να το κάνετε με την εντολή `helm pull chartrepo/chartname`. Αυτό το έγγραφο εξηγεί τη μορφή των charts και παρέχει βασικές οδηγίες για τη δημιουργία charts με το Helm. ## Η Δομή Αρχείων του Chart {#the-chart-file-structure} Ένα chart είναι οργανωμένο ως μια συλλογή αρχείων μέσα σε έναν κατάλογο. Το όνομα του καταλόγου είναι το όνομα του chart (χωρίς πληροφορίες έκδοσης). Έτσι, ένα chart που περιγράφει το WordPress θα αποθηκευόταν σε έναν κατάλογο `wordpress/`. Μέσα σε αυτόν τον κατάλογο, το Helm αναμένει μια δομή που ταιριάζει με αυτή: ```text wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file values.yaml # The default configuration values for this chart values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file charts/ # A directory containing any charts upon which this chart depends. crds/ # Custom Resource Definitions templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Το Helm δεσμεύει τη χρήση των καταλόγων `charts/`, `crds/` και `templates/`, καθώς και των αρχείων με τα παραπάνω ονόματα. Τα υπόλοιπα αρχεία θα παραμείνουν ως έχουν. ## Το Αρχείο Chart.yaml {#the-chartyaml-file} Το αρχείο `Chart.yaml` είναι απαραίτητο για ένα chart. Περιέχει τα εξής πεδία: ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` Από την έκδοση [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), δεν επιτρέπονται επιπλέον πεδία. Η προτεινόμενη προσέγγιση είναι να προσθέσετε προσαρμοσμένα metadata στο πεδίο `annotations`. ### Charts και Εκδοσιοποίηση {#charts-and-versioning} Κάθε chart πρέπει να έχει έναν αριθμό έκδοσης. Μια έκδοση πρέπει να ακολουθεί το πρότυπο [SemVer 2](https://semver.org/spec/v2.0.0.html), αλλά δεν επιβάλλεται αυστηρά. Σε αντίθεση με το Helm Classic, το Helm v2 και μεταγενέστερα χρησιμοποιεί τους αριθμούς έκδοσης ως δείκτες release. Τα πακέτα στα repositories αναγνωρίζονται από το όνομα συν την έκδοση. Για παράδειγμα, ένα `nginx` chart του οποίου το πεδίο version έχει οριστεί σε `version: 1.2.3` θα ονομάζεται: ```text nginx-1.2.3.tgz ``` Υποστηρίζονται επίσης πιο σύνθετα ονόματα SemVer 2, όπως `version: 1.2.3-alpha.1+ef365`. Ωστόσο, τα μη-SemVer ονόματα απορρίπτονται ρητά από το σύστημα. Εξαίρεση αποτελούν εκδόσεις στη μορφή `x` ή `x.y`. Για παράδειγμα, αν υπάρχει ένα πρόθεμα v ή μια έκδοση χωρίς και τα 3 μέρη (π.χ. v1.2), το σύστημα θα προσπαθήσει να τη μετατρέψει σε έγκυρη σημασιολογική έκδοση (π.χ. v1.2.0). **ΣΗΜΕΙΩΣΗ:** Ενώ το Helm Classic και το Deployment Manager ήταν πολύ προσανατολισμένα στο GitHub όσον αφορά τα charts, το Helm v2 και μεταγενέστερα δεν βασίζεται ούτε απαιτεί GitHub ή ακόμα και Git. Κατά συνέπεια, δεν χρησιμοποιεί καθόλου Git SHAs για εκδοσιοποίηση. Το πεδίο `version` μέσα στο `Chart.yaml` χρησιμοποιείται από πολλά εργαλεία του Helm, συμπεριλαμβανομένου του CLI. Κατά τη δημιουργία πακέτου, η εντολή `helm package` χρησιμοποιεί την έκδοση που βρίσκει στο `Chart.yaml` ως τμήμα του ονόματος του πακέτου. Το σύστημα υποθέτει ότι ο αριθμός έκδοσης στο όνομα του πακέτου chart ταιριάζει με τον αριθμό έκδοσης στο `Chart.yaml`. Η αποτυχία ικανοποίησης αυτής της υπόθεσης θα προκαλέσει σφάλμα. ### Το Πεδίο `apiVersion` {#the-apiversion-field} Το πεδίο `apiVersion` πρέπει να είναι `v2` για Helm charts που απαιτούν τουλάχιστον Helm 3. Τα charts που υποστηρίζουν προηγούμενες εκδόσεις του Helm έχουν `apiVersion` ορισμένο σε `v1` και εξακολουθούν να είναι εγκαταστάσιμα από το Helm 3. Αλλαγές από `v1` σε `v2`: - Ένα πεδίο `dependencies` που ορίζει τις εξαρτήσεις του chart, οι οποίες βρίσκονταν σε ξεχωριστό αρχείο `requirements.yaml` για τα `v1` charts (δείτε [Εξαρτήσεις Chart](#chart-dependencies)). - Το πεδίο `type`, που διακρίνει τα application και library charts (δείτε [Τύποι Chart](#chart-types)). ### Το Πεδίο `appVersion` {#the-appversion-field} Σημειώστε ότι το πεδίο `appVersion` δεν σχετίζεται με το πεδίο `version`. Είναι ένας τρόπος να προσδιορίσετε την έκδοση της εφαρμογής. Για παράδειγμα, το chart `drupal` μπορεί να έχει `appVersion: "8.2.1"`, υποδεικνύοντας ότι η έκδοση του Drupal που περιλαμβάνεται στο chart (από προεπιλογή) είναι `8.2.1`. Αυτό το πεδίο είναι πληροφοριακό και δεν επηρεάζει τους υπολογισμούς έκδοσης του chart. Συνιστάται ιδιαίτερα να περικλείετε την έκδοση σε εισαγωγικά. Αναγκάζει τον YAML parser να αντιμετωπίσει τον αριθμό έκδοσης ως string. Αν το αφήσετε χωρίς εισαγωγικά, μπορεί να προκληθούν προβλήματα parsing σε ορισμένες περιπτώσεις. Για παράδειγμα, το YAML ερμηνεύει το `1.0` ως floating point τιμή, και ένα git commit SHA όπως `1234e10` ως επιστημονική σημειογραφία. Από το Helm v3.5.0, η εντολή `helm create` περικλείει το προεπιλεγμένο πεδίο `appVersion` σε εισαγωγικά. ### Το Πεδίο `kubeVersion` {#the-kubeversion-field} Το προαιρετικό πεδίο `kubeVersion` μπορεί να ορίσει semver περιορισμούς για τις υποστηριζόμενες εκδόσεις Kubernetes. Το Helm θα επικυρώσει τους περιορισμούς έκδοσης κατά την εγκατάσταση του chart και θα αποτύχει αν το cluster τρέχει μη υποστηριζόμενη έκδοση Kubernetes. Οι περιορισμοί έκδοσης μπορεί να αποτελούνται από AND συγκρίσεις διαχωρισμένες με κενά, όπως ``` >= 1.13.0 < 1.15.0 ``` οι οποίες μπορούν να συνδυαστούν με τον OR τελεστή `||` όπως στο παρακάτω παράδειγμα ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` Σε αυτό το παράδειγμα η έκδοση `1.14.0` εξαιρείται, κάτι που μπορεί να έχει νόημα αν ένα bug σε συγκεκριμένες εκδόσεις είναι γνωστό ότι εμποδίζει τη σωστή λειτουργία του chart. Εκτός από περιορισμούς έκδοσης με τελεστές `=` `!=` `>` `<` `>=` `<=`, υποστηρίζονται και οι εξής συντομεύσεις: * hyphen ranges για κλειστά διαστήματα, όπου `1.1 - 2.3.4` ισοδυναμεί με `>= 1.1 <= 2.3.4`. * wildcards `x`, `X` και `*`, όπου `1.2.x` ισοδυναμεί με `>= 1.2.0 < 1.3.0`. * tilde ranges (επιτρέπονται αλλαγές patch version), όπου `~1.2.3` ισοδυναμεί με `>= 1.2.3 < 1.3.0`. * caret ranges (επιτρέπονται αλλαγές minor version), όπου `^1.2.3` ισοδυναμεί με `>= 1.2.3 < 2.0.0`. Για λεπτομερή εξήγηση των υποστηριζόμενων semver περιορισμών, δείτε το [Masterminds/semver](https://github.com/Masterminds/semver). ### Απόσυρση Charts {#deprecating-charts} Κατά τη διαχείριση charts σε ένα Chart Repository, μερικές φορές είναι απαραίτητο να αποσύρετε ένα chart. Το προαιρετικό πεδίο `deprecated` στο `Chart.yaml` μπορεί να χρησιμοποιηθεί για να επισημάνει ένα chart ως απoσυρμένο. Αν η **τελευταία** έκδοση ενός chart στο repository είναι επισημασμένη ως αποσυρμένη, τότε το chart στο σύνολό του θεωρείται αποσυρμένο. Το όνομα του chart μπορεί να επαναχρησιμοποιηθεί αργότερα δημοσιεύοντας μια νεότερη έκδοση που δεν είναι επισημασμένη ως αποσυρμένη. Η ροή εργασίας για την απόσυρση charts είναι: 1. Ενημερώστε το `Chart.yaml` του chart για να επισημάνετε το chart ως αποσυρμένο, αυξάνοντας την έκδοση 2. Δημοσιεύστε τη νέα έκδοση chart στο Chart Repository 3. Αφαιρέστε το chart από το source repository (π.χ. git) ### Τύποι Chart {#chart-types} Το πεδίο `type` ορίζει τον τύπο του chart. Υπάρχουν δύο τύποι: `application` και `library`. Ο application είναι ο προεπιλεγμένος τύπος και είναι το τυπικό chart που μπορεί να λειτουργήσει πλήρως. Το [library chart](/topics/library_charts.md) παρέχει εργαλεία ή συναρτήσεις για τον κατασκευαστή chart. Ένα library chart διαφέρει από ένα application chart επειδή δεν είναι εγκαταστάσιμο και συνήθως δεν περιέχει αντικείμενα πόρων. **Σημείωση:** Ένα application chart μπορεί να χρησιμοποιηθεί ως library chart. Αυτό ενεργοποιείται ορίζοντας τον τύπο σε `library`. Το chart θα αποδοθεί τότε ως library chart όπου όλα τα εργαλεία και οι συναρτήσεις μπορούν να αξιοποιηθούν. Όλα τα αντικείμενα πόρων του chart δεν θα αποδοθούν. ## Chart LICENSE, README και NOTES {#chart-license-readme-and-notes} Τα charts μπορούν επίσης να περιέχουν αρχεία που περιγράφουν την εγκατάσταση, τη διαμόρφωση, τη χρήση και την άδεια ενός chart. Ένα LICENSE είναι ένα απλό αρχείο κειμένου που περιέχει την [άδεια χρήσης](https://en.wikipedia.org/wiki/Software_license) για το chart. Το chart μπορεί να περιέχει άδεια καθώς μπορεί να έχει προγραμματιστική λογική στα templates και επομένως να μην είναι μόνο διαμόρφωση. Μπορεί επίσης να υπάρχουν ξεχωριστές άδειες για την εφαρμογή που εγκαθίσταται από το chart, αν απαιτείται. Ένα README για ένα chart πρέπει να είναι μορφοποιημένο σε Markdown (README.md) και γενικά να περιέχει: - Μια περιγραφή της εφαρμογής ή υπηρεσίας που παρέχει το chart - Τυχόν προαπαιτούμενα ή απαιτήσεις για την εκτέλεση του chart - Περιγραφές των επιλογών στο `values.yaml` και τις προεπιλεγμένες τιμές - Οποιαδήποτε άλλη πληροφορία που μπορεί να είναι σχετική με την εγκατάσταση ή τη διαμόρφωση του chart Όταν τα hubs και άλλα περιβάλλοντα χρήστη εμφανίζουν λεπτομέρειες για ένα chart, αυτές οι λεπτομέρειες λαμβάνονται από το περιεχόμενο του αρχείου `README.md`. Το chart μπορεί επίσης να περιέχει ένα σύντομο αρχείο κειμένου `templates/NOTES.txt` που θα εκτυπώνεται μετά την εγκατάσταση και κατά την προβολή της κατάστασης ενός release. Αυτό το αρχείο αξιολογείται ως [template](#templates-and-values) και μπορεί να χρησιμοποιηθεί για να εμφανίσει σημειώσεις χρήσης, επόμενα βήματα, ή οποιαδήποτε άλλη πληροφορία σχετική με ένα release του chart. Για παράδειγμα, θα μπορούσαν να παρασχεθούν οδηγίες για σύνδεση σε μια βάση δεδομένων ή πρόσβαση σε ένα web UI. Δεδομένου ότι αυτό το αρχείο εκτυπώνεται στο STDOUT κατά την εκτέλεση `helm install` ή `helm status`, συνιστάται να διατηρείτε το περιεχόμενο σύντομο και να παραπέμπετε στο README για περισσότερες λεπτομέρειες. ## Εξαρτήσεις Chart {#chart-dependencies} Στο Helm, ένα chart μπορεί να εξαρτάται από οποιονδήποτε αριθμό άλλων charts. Αυτές οι εξαρτήσεις μπορούν να συνδεθούν δυναμικά χρησιμοποιώντας το πεδίο `dependencies` στο `Chart.yaml` ή να εισαχθούν στον κατάλογο `charts/` και να διαχειριστούν χειροκίνητα. ### Διαχείριση Εξαρτήσεων με το Πεδίο `dependencies` {#managing-dependencies-with-the-dependencies-field} Τα charts που απαιτούνται από το τρέχον chart ορίζονται ως λίστα στο πεδίο `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Το πεδίο `name` είναι το όνομα του chart που θέλετε. - Το πεδίο `version` είναι η έκδοση του chart που θέλετε. - Το πεδίο `repository` είναι το πλήρες URL του chart repository. Σημειώστε ότι πρέπει επίσης να χρησιμοποιήσετε `helm repo add` για να προσθέσετε αυτό το repo τοπικά. - Μπορείτε να χρησιμοποιήσετε το όνομα του repo αντί για URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Αφού ορίσετε τις εξαρτήσεις, μπορείτε να εκτελέσετε `helm dependency update` και θα χρησιμοποιήσει το αρχείο εξαρτήσεων για να κατεβάσει όλα τα καθορισμένα charts στον κατάλογο `charts/` για εσάς. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Όταν η `helm dependency update` ανακτά charts, θα τα αποθηκεύσει ως chart archives στον κατάλογο `charts/`. Για το παραπάνω παράδειγμα, θα περιμένατε να δείτε τα εξής αρχεία στον κατάλογο charts: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Πεδίο Alias στις Εξαρτήσεις {#alias-field-in-dependencies} Επιπλέον των άλλων πεδίων παραπάνω, κάθε εγγραφή εξαρτήσεων μπορεί να περιέχει το προαιρετικό πεδίο `alias`. Η προσθήκη ενός alias για ένα chart εξάρτησης θα τοποθετήσει ένα chart στις εξαρτήσεις χρησιμοποιώντας το alias ως όνομα της νέας εξάρτησης. Μπορείτε να χρησιμοποιήσετε το `alias` σε περιπτώσεις όπου χρειάζεται να προσπελάσετε ένα chart με άλλο όνομα(τα). ```yaml # parentchart/Chart.yaml {#parentchartchartyaml} {#parentchartchartyaml} dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` Στο παραπάνω παράδειγμα θα πάρουμε συνολικά 3 εξαρτήσεις για το `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` Ο χειροκίνητος τρόπος για να επιτευχθεί αυτό είναι με copy/paste του ίδιου chart στον κατάλογο `charts/` πολλές φορές με διαφορετικά ονόματα. #### Πεδία Tags και Condition στις Εξαρτήσεις {#tags-and-condition-fields-in-dependencies} Επιπλέον των άλλων πεδίων παραπάνω, κάθε εγγραφή εξαρτήσεων μπορεί να περιέχει τα προαιρετικά πεδία `tags` και `condition`. Όλα τα charts φορτώνονται από προεπιλογή. Αν υπάρχουν πεδία `tags` ή `condition`, θα αξιολογηθούν και θα χρησιμοποιηθούν για τον έλεγχο φόρτωσης του/των chart(s) στα οποία εφαρμόζονται. Condition - Το πεδίο condition περιέχει μία ή περισσότερες διαδρομές YAML (διαχωρισμένες με κόμμα). Αν αυτή η διαδρομή υπάρχει στα values του ανώτερου γονικού και επιλύεται σε boolean τιμή, το chart θα ενεργοποιηθεί ή απενεργοποιηθεί βάσει αυτής της boolean τιμής. Μόνο η πρώτη έγκυρη διαδρομή που βρέθηκε στη λίστα αξιολογείται και αν δεν υπάρχουν διαδρομές, τότε η condition δεν έχει αποτέλεσμα. Tags - Το πεδίο tags είναι μια YAML λίστα ετικετών που σχετίζονται με αυτό το chart. Στα values του ανώτερου γονικού, όλα τα charts με tags μπορούν να ενεργοποιηθούν ή να απενεργοποιηθούν καθορίζοντας το tag και μια boolean τιμή. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml {#parentchartvaluesyaml} subchart1: enabled: true tags: front-end: false back-end: true ``` Στο παραπάνω παράδειγμα, όλα τα charts με το tag `front-end` θα απενεργοποιηθούν, αλλά επειδή η διαδρομή `subchart1.enabled` αξιολογείται ως 'true' στα values του γονικού, η condition θα υπερισχύσει του tag `front-end` και το `subchart1` θα ενεργοποιηθεί. Δεδομένου ότι το `subchart2` έχει tag `back-end` και αυτό το tag αξιολογείται σε `true`, το `subchart2` θα ενεργοποιηθεί. Επίσης σημειώστε ότι παρόλο που το `subchart2` έχει καθορισμένη condition, δεν υπάρχει αντίστοιχη διαδρομή και τιμή στα values του γονικού, οπότε αυτή η condition δεν έχει αποτέλεσμα. ##### Χρήση του CLI με Tags και Conditions {#using-the-cli-with-tags-and-conditions} Η παράμετρος `--set` μπορεί να χρησιμοποιηθεί όπως συνήθως για να αλλάξει τις τιμές tag και condition. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Επίλυση Tags και Conditions {#tags-and-condition-resolution} - **Οι conditions (όταν ορίζονται στα values) υπερισχύουν πάντα των tags.** Η πρώτη διαδρομή condition που υπάρχει κερδίζει και οι επόμενες για αυτό το chart αγνοούνται. - Τα tags αξιολογούνται ως 'αν οποιοδήποτε από τα tags του chart είναι true, τότε ενεργοποίησε το chart'. - Οι τιμές tags και conditions πρέπει να οριστούν στα values του ανώτερου γονικού. - Το κλειδί `tags:` στα values πρέπει να είναι κλειδί ανώτατου επιπέδου. Τα globals και εμφωλευμένοι πίνακες `tags:` δεν υποστηρίζονται προς το παρόν. #### Εισαγωγή Τιμών Θυγατρικών μέσω Εξαρτήσεων {#importing-child-values-via-dependencies} Σε ορισμένες περιπτώσεις είναι επιθυμητό να επιτρέπεται στις τιμές ενός θυγατρικού chart να διαδοθούν στο γονικό chart και να μοιραστούν ως κοινές προεπιλογές. Ένα επιπλέον πλεονέκτημα της χρήσης της μορφής `exports` είναι ότι θα επιτρέψει σε μελλοντικά εργαλεία να εξετάζουν τις ρυθμιζόμενες τιμές χρήστη. Τα κλειδιά που περιέχουν τις τιμές προς εισαγωγή μπορούν να καθοριστούν στο `dependencies` του γονικού chart στο πεδίο `import-values` χρησιμοποιώντας μια λίστα YAML. Κάθε στοιχείο στη λίστα είναι ένα κλειδί που εισάγεται από το πεδίο `exports` του θυγατρικού chart. Για να εισάγετε τιμές που δεν περιέχονται στο κλειδί `exports`, χρησιμοποιήστε τη μορφή [child-parent](#using-the-child-parent-format). Παραδείγματα και των δύο μορφών περιγράφονται παρακάτω. ##### Χρήση της Μορφής Exports {#using-the-exports-format} Αν το αρχείο `values.yaml` ενός θυγατρικού chart περιέχει ένα πεδίο `exports` στη ρίζα, τα περιεχόμενά του μπορούν να εισαχθούν απευθείας στα values του γονικού καθορίζοντας τα κλειδιά προς εισαγωγή όπως στο παρακάτω παράδειγμα: ```yaml # parent's Chart.yaml file {#parents-chartyaml-file} {#parents-chartyaml-file} dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file {#childs-valuesyaml-file} exports: data: myint: 99 ``` Δεδομένου ότι καθορίζουμε το κλειδί `data` στη λίστα εισαγωγών, το Helm ψάχνει στο πεδίο `exports` του θυγατρικού chart για το κλειδί `data` και εισάγει τα περιεχόμενά του. Τα τελικά values του γονικού θα περιέχουν το εξαγόμενο πεδίο: ```yaml # parent's values {#parents-values} myint: 99 ``` Σημειώστε ότι το γονικό κλειδί `data` δεν περιέχεται στα τελικά values του γονικού. Αν χρειάζεστε να καθορίσετε το γονικό κλειδί, χρησιμοποιήστε τη μορφή 'child-parent'. ##### Χρήση της Μορφής Child-Parent {#using-the-child-parent-format} Για να προσπελάσετε τιμές που δεν περιέχονται στο κλειδί `exports` των values του θυγατρικού chart, θα πρέπει να καθορίσετε το κλειδί πηγή των τιμών προς εισαγωγή (`child`) και τη διαδρομή προορισμού στα values του γονικού chart (`parent`). Το `import-values` στο παρακάτω παράδειγμα δίνει εντολή στο Helm να πάρει οποιεσδήποτε τιμές βρεθούν στη διαδρομή `child:` και να τις αντιγράψει στα values του γονικού στη διαδρομή που καθορίζεται στο `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` Στο παραπάνω παράδειγμα, οι τιμές που βρίσκονται στο `default.data` στα values του subchart1 θα εισαχθούν στο κλειδί `myimports` στα values του γονικού chart όπως περιγράφεται παρακάτω: ```yaml # parent's values.yaml file {#parents-valuesyaml-file} myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file {#subchart1s-valuesyaml-file} default: data: myint: 999 mybool: true ``` Τα τελικά values του γονικού chart θα είναι: ```yaml # parent's final values {#parents-final-values} myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Τα τελικά values του γονικού περιέχουν τώρα τα πεδία `myint` και `mybool` που εισήχθησαν από το subchart1. ### Χειροκίνητη Διαχείριση Εξαρτήσεων μέσω του Καταλόγου `charts/` {#managing-dependencies-manually-via-the-charts-directory} Αν επιθυμείται περισσότερος έλεγχος στις εξαρτήσεις, αυτές οι εξαρτήσεις μπορούν να εκφραστούν ρητά αντιγράφοντας τα charts εξαρτήσεων στον κατάλογο `charts/`. Μια εξάρτηση πρέπει να είναι ένας μη συμπιεσμένος κατάλογος chart, αλλά το όνομά του δεν μπορεί να ξεκινά με `_` ή `.`. Τέτοια αρχεία αγνοούνται από τον φορτωτή chart. Για παράδειγμα, αν το WordPress chart εξαρτάται από το Apache chart, το Apache chart (της σωστής έκδοσης) παρέχεται στον κατάλογο `charts/` του WordPress chart: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` Το παραπάνω παράδειγμα δείχνει πώς το WordPress chart εκφράζει την εξάρτησή του από το Apache και το MySQL συμπεριλαμβάνοντας αυτά τα charts μέσα στον κατάλογο `charts/` του. **ΣΥΜΒΟΥΛΗ:** _Για να τοποθετήσετε μια εξάρτηση στον κατάλογο `charts/`, χρησιμοποιήστε την εντολή `helm pull`_ ### Λειτουργικές Πτυχές της Χρήσης Εξαρτήσεων {#operational-aspects-of-using-dependencies} Οι παραπάνω ενότητες εξηγούν πώς να καθορίσετε εξαρτήσεις chart, αλλά πώς επηρεάζει αυτό την εγκατάσταση chart χρησιμοποιώντας `helm install` και `helm upgrade`; Υποθέστε ότι ένα chart με όνομα "A" δημιουργεί τα εξής αντικείμενα Kubernetes: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Επιπλέον, το A εξαρτάται από το chart B που δημιουργεί αντικείμενα: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Μετά την εγκατάσταση/αναβάθμιση του chart A, δημιουργείται/τροποποιείται ένα μόνο Helm release. Το release θα δημιουργήσει/ενημερώσει όλα τα παραπάνω αντικείμενα Kubernetes με την εξής σειρά: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Αυτό συμβαίνει επειδή όταν το Helm εγκαθιστά/αναβαθμίζει charts, τα αντικείμενα Kubernetes από τα charts και όλες τις εξαρτήσεις τους: - συγκεντρώνονται σε ένα ενιαίο σύνολο· στη συνέχεια - ταξινομούνται κατά τύπο και έπειτα κατά όνομα· και τέλος - δημιουργούνται/ενημερώνονται με αυτή τη σειρά. Επομένως, δημιουργείται ένα μόνο release με όλα τα αντικείμενα για το chart και τις εξαρτήσεις του. Η σειρά εγκατάστασης των τύπων Kubernetes δίνεται από την απαρίθμηση InstallOrder στο kind_sorter.go (δείτε [τον πηγαίο κώδικα του Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates και Values {#templates-and-values} Τα Helm Chart templates γράφονται στη [γλώσσα template της Go](https://golang.org/pkg/text/template/), με την προσθήκη 50 και πλέον συναρτήσεων template [από τη βιβλιοθήκη Sprig](https://github.com/Masterminds/sprig) και μερικές άλλες [εξειδικευμένες συναρτήσεις](/howto/charts_tips_and_tricks.md). Όλα τα αρχεία template αποθηκεύονται στον φάκελο `templates/` ενός chart. Όταν το Helm αποδίδει τα charts, θα περάσει κάθε αρχείο σε αυτόν τον κατάλογο μέσω της μηχανής template. Οι τιμές για τα templates παρέχονται με δύο τρόπους: - Οι προγραμματιστές chart μπορούν να παρέχουν ένα αρχείο με όνομα `values.yaml` μέσα σε ένα chart. Αυτό το αρχείο μπορεί να περιέχει προεπιλεγμένες τιμές. - Οι χρήστες chart μπορούν να παρέχουν ένα αρχείο YAML που περιέχει τιμές. Αυτό μπορεί να παρασχεθεί στη γραμμή εντολών με `helm install`. Όταν ένας χρήστης παρέχει προσαρμοσμένες τιμές, αυτές οι τιμές θα υπερισχύσουν των τιμών στο αρχείο `values.yaml` του chart. ### Αρχεία Template {#template-files} Τα αρχεία template ακολουθούν τις τυπικές συμβάσεις για τη σύνταξη Go templates (δείτε την [τεκμηρίωση του πακέτου text/template της Go](https://golang.org/pkg/text/template/) για λεπτομέρειες). Ένα παράδειγμα αρχείου template μπορεί να μοιάζει κάπως έτσι: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` Το παραπάνω παράδειγμα, βασισμένο χαλαρά στο [https://github.com/deis/charts](https://github.com/deis/charts), είναι ένα template για έναν Kubernetes replication controller. Μπορεί να χρησιμοποιήσει τις εξής τέσσερις τιμές template (συνήθως ορίζονται σε ένα αρχείο `values.yaml`): - `imageRegistry`: Το source registry για το Docker image. - `dockerTag`: Το tag για το docker image. - `pullPolicy`: Η Kubernetes pull policy. - `storage`: Το storage backend, του οποίου η προεπιλογή ορίζεται σε `"minio"` Όλες αυτές οι τιμές ορίζονται από τον συγγραφέα template. Το Helm δεν απαιτεί ούτε επιβάλλει παραμέτρους. Για να δείτε πολλά λειτουργικά charts, δείτε το [Artifact Hub](https://artifacthub.io/packages/search?kind=0) του CNCF. ### Προκαθορισμένες Τιμές {#predefined-values} Οι τιμές που παρέχονται μέσω ενός αρχείου `values.yaml` (ή μέσω της σημαίας `--set`) είναι προσβάσιμες από το αντικείμενο `.Values` σε ένα template. Αλλά υπάρχουν και άλλα προκαθορισμένα δεδομένα που μπορείτε να προσπελάσετε στα templates σας. Οι ακόλουθες τιμές είναι προκαθορισμένες, είναι διαθέσιμες σε κάθε template και δεν μπορούν να παρακαμφθούν. Όπως με όλες τις τιμές, τα ονόματα είναι _case sensitive_. - `Release.Name`: Το όνομα του release (όχι του chart) - `Release.Namespace`: Το namespace στο οποίο εκδόθηκε το chart. - `Release.Service`: Η υπηρεσία που διεξήγαγε το release. - `Release.IsUpgrade`: Ορίζεται σε true αν η τρέχουσα λειτουργία είναι αναβάθμιση ή rollback. - `Release.IsInstall`: Ορίζεται σε true αν η τρέχουσα λειτουργία είναι εγκατάσταση. - `Chart`: Τα περιεχόμενα του `Chart.yaml`. Έτσι, η έκδοση chart είναι διαθέσιμη ως `Chart.Version` και οι maintainers στο `Chart.Maintainers`. - `Files`: Ένα map-like αντικείμενο που περιέχει όλα τα μη ειδικά αρχεία στο chart. Αυτό δεν θα σας δώσει πρόσβαση στα templates, αλλά θα σας δώσει πρόσβαση σε επιπλέον αρχεία που υπάρχουν (εκτός αν εξαιρούνται χρησιμοποιώντας `.helmignore`). Τα αρχεία μπορούν να προσπελαστούν χρησιμοποιώντας `{{ index .Files "file.name" }}` ή χρησιμοποιώντας τη συνάρτηση `{{.Files.Get name }}`. Μπορείτε επίσης να προσπελάσετε τα περιεχόμενα του αρχείου ως `[]byte` χρησιμοποιώντας `{{ .Files.GetBytes }}` - `Capabilities`: Ένα map-like αντικείμενο που περιέχει πληροφορίες για τις εκδόσεις του Kubernetes (`{{ .Capabilities.KubeVersion }}`) και τις υποστηριζόμενες εκδόσεις Kubernetes API (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **ΣΗΜΕΙΩΣΗ:** Οποιαδήποτε άγνωστα πεδία του `Chart.yaml` θα απορριφθούν. Δεν θα είναι προσβάσιμα μέσα στο αντικείμενο `Chart`. Επομένως, το `Chart.yaml` δεν μπορεί να χρησιμοποιηθεί για να περάσετε αυθαίρετα δομημένα δεδομένα στο template. Το αρχείο values όμως μπορεί να χρησιμοποιηθεί για αυτό. ### Αρχεία Values {#values-files} Λαμβάνοντας υπόψη το template στην προηγούμενη ενότητα, ένα αρχείο `values.yaml` που παρέχει τις απαραίτητες τιμές θα έμοιαζε έτσι: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Ένα αρχείο values είναι μορφοποιημένο σε YAML. Ένα chart μπορεί να περιλαμβάνει ένα προεπιλεγμένο αρχείο `values.yaml`. Η εντολή helm install επιτρέπει στον χρήστη να παρακάμψει τιμές παρέχοντας επιπλέον τιμές YAML: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Όταν οι τιμές περνιούνται με αυτόν τον τρόπο, θα συγχωνευτούν με το προεπιλεγμένο αρχείο values. Για παράδειγμα, θεωρήστε ένα αρχείο `myvals.yaml` που μοιάζει έτσι: ```yaml storage: "gcs" ``` Όταν αυτό συγχωνευτεί με το `values.yaml` στο chart, το τελικό περιεχόμενο θα είναι: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Σημειώστε ότι μόνο το τελευταίο πεδίο παρακάμφθηκε. **ΣΗΜΕΙΩΣΗ:** Το προεπιλεγμένο αρχείο values που περιλαμβάνεται μέσα σε ένα chart _πρέπει_ να ονομάζεται `values.yaml`. Αλλά τα αρχεία που καθορίζονται στη γραμμή εντολών μπορούν να έχουν οποιοδήποτε όνομα. **ΣΗΜΕΙΩΣΗ:** Αν χρησιμοποιηθεί η σημαία `--set` στο `helm install` ή `helm upgrade`, αυτές οι τιμές απλά μετατρέπονται σε YAML στην πλευρά του client. **ΣΗΜΕΙΩΣΗ:** Αν υπάρχουν απαιτούμενες εγγραφές στο αρχείο values, μπορούν να δηλωθούν ως υποχρεωτικές στο template του chart χρησιμοποιώντας τη [συνάρτηση 'required'](/howto/charts_tips_and_tricks.md) Οποιαδήποτε από αυτές τις τιμές είναι στη συνέχεια προσβάσιμες μέσα σε templates χρησιμοποιώντας το αντικείμενο `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Εμβέλεια, Εξαρτήσεις και Values {#scope-dependencies-and-values} Τα αρχεία values μπορούν να δηλώσουν τιμές για το chart ανώτατου επιπέδου, καθώς και για οποιοδήποτε από τα charts που περιλαμβάνονται στον κατάλογο `charts/` αυτού του chart. Ή, για να το θέσουμε διαφορετικά, ένα αρχείο values μπορεί να παρέχει τιμές στο chart καθώς και σε οποιαδήποτε από τις εξαρτήσεις του. Για παράδειγμα, το επιδεικτικό WordPress chart παραπάνω έχει τόσο `mysql` όσο και `apache` ως εξαρτήσεις. Το αρχείο values θα μπορούσε να παρέχει τιμές σε όλα αυτά τα στοιχεία: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Τα charts σε ανώτερο επίπεδο έχουν πρόσβαση σε όλες τις μεταβλητές που ορίζονται από κάτω. Έτσι το WordPress chart μπορεί να προσπελάσει τον κωδικό MySQL ως `.Values.mysql.password`. Αλλά τα charts χαμηλότερου επιπέδου δεν μπορούν να προσπελάσουν πράγματα στα γονικά charts, οπότε το MySQL δεν θα μπορεί να προσπελάσει την ιδιότητα `title`. Ούτε, εξάλλου, μπορεί να προσπελάσει το `apache.port`. Οι τιμές έχουν namespaces, αλλά τα namespaces περικόπτονται. Έτσι για το WordPress chart, μπορεί να προσπελάσει το πεδίο κωδικού MySQL ως `.Values.mysql.password`. Αλλά για το MySQL chart, η εμβέλεια των τιμών έχει μειωθεί και το πρόθεμα namespace έχει αφαιρεθεί, οπότε θα δει το πεδίο κωδικού απλά ως `.Values.password`. #### Global Values {#global-values} Από την έκδοση 2.0.0-Alpha.2, το Helm υποστηρίζει ειδικές "global" τιμές. Θεωρήστε αυτή την τροποποιημένη έκδοση του προηγούμενου παραδείγματος: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Τα παραπάνω προσθέτουν μια ενότητα `global` με την τιμή `app: MyWordPress`. Αυτή η τιμή είναι διαθέσιμη σε _όλα_ τα charts ως `.Values.global.app`. Για παράδειγμα, τα templates του `mysql` μπορούν να προσπελάσουν το `app` ως `{{ .Values.global.app}}`, και το ίδιο μπορεί να κάνει και το chart `apache`. Ουσιαστικά, το αρχείο values παραπάνω αναπαράγεται έτσι: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` Αυτό παρέχει έναν τρόπο κοινής χρήσης μιας μεταβλητής ανώτατου επιπέδου με όλα τα subcharts, κάτι που είναι χρήσιμο για ρύθμιση ιδιοτήτων `metadata` όπως labels. Αν ένα subchart δηλώνει μια global μεταβλητή, αυτή η global θα περάσει _προς τα κάτω_ (στα subcharts του subchart), αλλά όχι _προς τα πάνω_ στο γονικό chart. Δεν υπάρχει τρόπος για ένα subchart να επηρεάσει τις τιμές του γονικού chart. Επίσης, οι global μεταβλητές των γονικών charts υπερισχύουν των global μεταβλητών από τα subcharts. ### Αρχεία Schema {#schema-files} Μερικές φορές, ένας συντηρητής chart μπορεί να θέλει να ορίσει μια δομή για τα values του. Αυτό μπορεί να γίνει ορίζοντας ένα schema στο αρχείο `values.schema.json`. Ένα schema αναπαρίσταται ως [JSON Schema](https://json-schema.org/). Μπορεί να μοιάζει κάπως έτσι: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Αυτό το schema θα εφαρμοστεί στα values για να τα επικυρώσει. Η επικύρωση πραγματοποιείται όταν καλούνται οποιεσδήποτε από τις εξής εντολές: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Ένα παράδειγμα αρχείου `values.yaml` που πληροί τις απαιτήσεις αυτού του schema μπορεί να μοιάζει κάπως έτσι: ```yaml name: frontend protocol: https port: 443 ``` Σημειώστε ότι το schema εφαρμόζεται στο τελικό αντικείμενο `.Values` και όχι μόνο στο αρχείο `values.yaml`. Αυτό σημαίνει ότι το ακόλουθο αρχείο yaml είναι έγκυρο, δεδομένου ότι το chart εγκαθίσταται με την κατάλληλη επιλογή `--set` που φαίνεται παρακάτω. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Επιπλέον, το τελικό αντικείμενο `.Values` ελέγχεται έναντι *όλων* των schemas των subcharts. Αυτό σημαίνει ότι οι περιορισμοί σε ένα subchart δεν μπορούν να παρακαμφθούν από ένα γονικό chart. Αυτό λειτουργεί και αντίστροφα - αν ένα subchart έχει μια απαίτηση που δεν ικανοποιείται στο αρχείο `values.yaml` του subchart, το γονικό chart *πρέπει* να ικανοποιήσει αυτούς τους περιορισμούς για να είναι έγκυρο. Η επικύρωση schema μπορεί να απενεργοποιηθεί ορίζοντας την παρακάτω επιλογή. Αυτό είναι ιδιαίτερα χρήσιμο σε περιβάλλοντα air-gapped όταν το αρχείο JSON Schema ενός chart περιέχει απομακρυσμένες αναφορές. ```console helm install --skip-schema-validation ``` ### Αναφορές {#references} Όσον αφορά τη σύνταξη templates, values και αρχείων schema, υπάρχουν αρκετές τυπικές αναφορές που θα σας βοηθήσουν. - [Go templates](https://godoc.org/text/template) - [Επιπλέον συναρτήσεις template](https://godoc.org/github.com/Masterminds/sprig) - [Η μορφή YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) {#custom-resource-definitions-crds} Το Kubernetes παρέχει έναν μηχανισμό για τη δήλωση νέων τύπων αντικειμένων Kubernetes. Χρησιμοποιώντας CustomResourceDefinitions (CRDs), οι προγραμματιστές Kubernetes μπορούν να δηλώσουν προσαρμοσμένους τύπους πόρων. Στο Helm 3, τα CRDs αντιμετωπίζονται ως ειδικός τύπος αντικειμένου. Εγκαθίστανται πριν από το υπόλοιπο chart και υπόκεινται σε ορισμένους περιορισμούς. Τα αρχεία YAML CRD πρέπει να τοποθετούνται στον κατάλογο `crds/` μέσα σε ένα chart. Πολλά CRDs (διαχωρισμένα με δείκτες αρχής και τέλους YAML) μπορούν να τοποθετηθούν στο ίδιο αρχείο. Το Helm θα προσπαθήσει να φορτώσει _όλα_ τα αρχεία στον κατάλογο CRD στο Kubernetes. Τα αρχεία CRD _δεν μπορούν να είναι templated_. Πρέπει να είναι απλά έγγραφα YAML. Όταν το Helm εγκαθιστά ένα νέο chart, θα ανεβάσει τα CRDs, θα περιμένει μέχρι τα CRDs να γίνουν διαθέσιμα από τον API server, και μετά θα ξεκινήσει τη μηχανή template, θα αποδώσει το υπόλοιπο chart και θα το ανεβάσει στο Kubernetes. Λόγω αυτής της σειράς, οι πληροφορίες CRD είναι διαθέσιμες στο αντικείμενο `.Capabilities` στα Helm templates, και τα Helm templates μπορούν να δημιουργήσουν νέα instances αντικειμένων που δηλώθηκαν σε CRDs. Για παράδειγμα, αν το chart σας είχε ένα CRD για `CronTab` στον κατάλογο `crds/`, μπορείτε να δημιουργήσετε instances του είδους `CronTab` στον κατάλογο `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Το αρχείο `crontab.yaml` πρέπει να περιέχει το CRD χωρίς οδηγίες template: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Στη συνέχεια, το template `mycrontab.yaml` μπορεί να δημιουργήσει ένα νέο `CronTab` (χρησιμοποιώντας templates ως συνήθως): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Το Helm θα διασφαλίσει ότι το είδος `CronTab` έχει εγκατασταθεί και είναι διαθέσιμο από τον Kubernetes API server πριν προχωρήσει στην εγκατάσταση των πραγμάτων στο `templates/`. ### Περιορισμοί στα CRDs {#limitations-on-crds} Σε αντίθεση με τα περισσότερα αντικείμενα στο Kubernetes, τα CRDs εγκαθίστανται globally. Για αυτό τον λόγο, το Helm ακολουθεί μια πολύ προσεκτική προσέγγιση στη διαχείριση CRDs. Τα CRDs υπόκεινται στους εξής περιορισμούς: - Τα CRDs δεν επανεγκαθίστανται ποτέ. Αν το Helm διαπιστώσει ότι τα CRDs στον κατάλογο `crds/` υπάρχουν ήδη (ανεξαρτήτως έκδοσης), το Helm δεν θα προσπαθήσει να τα εγκαταστήσει ή να τα αναβαθμίσει. - Τα CRDs δεν εγκαθίστανται ποτέ κατά την αναβάθμιση ή το rollback. Το Helm θα δημιουργήσει CRDs μόνο κατά τις λειτουργίες εγκατάστασης. - Τα CRDs δεν διαγράφονται ποτέ. Η διαγραφή ενός CRD διαγράφει αυτόματα όλα τα περιεχόμενα του CRD σε όλα τα namespaces στο cluster. Κατά συνέπεια, το Helm δεν θα διαγράψει CRDs. Οι διαχειριστές που θέλουν να αναβαθμίσουν ή να διαγράψουν CRDs ενθαρρύνονται να το κάνουν χειροκίνητα και με μεγάλη προσοχή. ## Χρήση του Helm για Διαχείριση Charts {#using-helm-to-manage-charts} Το εργαλείο `helm` έχει αρκετές εντολές για εργασία με charts. Μπορεί να δημιουργήσει ένα νέο chart για εσάς: ```console $ helm create mychart Created mychart/ ``` Αφού επεξεργαστείτε ένα chart, το `helm` μπορεί να το πακετάρει σε ένα chart archive για εσάς: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Μπορείτε επίσης να χρησιμοποιήσετε το `helm` για να σας βοηθήσει να βρείτε προβλήματα με τη μορφοποίηση ή τις πληροφορίες του chart σας: ```console $ helm lint mychart No issues found ``` ## Chart Repositories {#chart-repositories} Ένα _chart repository_ είναι ένας HTTP server που φιλοξενεί ένα ή περισσότερα πακεταρισμένα charts. Ενώ το `helm` μπορεί να χρησιμοποιηθεί για τη διαχείριση τοπικών καταλόγων chart, όταν πρόκειται για κοινή χρήση charts, ο προτιμώμενος μηχανισμός είναι ένα chart repository. Οποιοσδήποτε HTTP server που μπορεί να εξυπηρετεί αρχεία YAML και tar και μπορεί να απαντά σε αιτήματα GET μπορεί να χρησιμοποιηθεί ως server repository. Η ομάδα του Helm έχει δοκιμάσει ορισμένους servers, συμπεριλαμβανομένου του Google Cloud Storage με ενεργοποιημένη τη λειτουργία website και του S3 με ενεργοποιημένη τη λειτουργία website. Ένα repository χαρακτηρίζεται κυρίως από την παρουσία ενός ειδικού αρχείου που ονομάζεται `index.yaml` που έχει μια λίστα με όλα τα πακέτα που παρέχονται από το repository, μαζί με metadata που επιτρέπουν την ανάκτηση και επαλήθευση αυτών των πακέτων. Στην πλευρά του client, τα repositories διαχειρίζονται με τις εντολές `helm repo`. Ωστόσο, το Helm δεν παρέχει εργαλεία για την αποστολή charts σε απομακρυσμένους servers repository. Αυτό συμβαίνει επειδή κάτι τέτοιο θα πρόσθετε σημαντικές απαιτήσεις σε έναν server υλοποίησης, και επομένως θα αύξανε το εμπόδιο για τη δημιουργία ενός repository. ## Chart Starter Packs {#chart-starter-packs} Η εντολή `helm create` δέχεται μια προαιρετική επιλογή `--starter` που σας επιτρέπει να καθορίσετε ένα "starter chart". Επίσης, η επιλογή starter έχει ένα σύντομο alias `-p`. Παραδείγματα χρήσης: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Τα starters είναι απλά κανονικά charts, αλλά βρίσκονται στο `$XDG_DATA_HOME/helm/starters`. Ως προγραμματιστής chart, μπορείτε να δημιουργήσετε charts που είναι ειδικά σχεδιασμένα για χρήση ως starters. Τέτοια charts πρέπει να σχεδιάζονται με τις εξής σκέψεις στο μυαλό: - Το `Chart.yaml` θα αντικατασταθεί από τον generator. - Οι χρήστες θα αναμένουν να τροποποιήσουν τα περιεχόμενα ενός τέτοιου chart, οπότε η τεκμηρίωση πρέπει να υποδεικνύει πώς μπορούν οι χρήστες να το κάνουν. - Όλες οι εμφανίσεις του `` θα αντικατασταθούν με το καθορισμένο όνομα chart, ώστε τα starter charts να μπορούν να χρησιμοποιηθούν ως templates, εκτός από ορισμένα αρχεία μεταβλητών. Για παράδειγμα, αν χρησιμοποιείτε προσαρμοσμένα αρχεία στον κατάλογο `vars` ή ορισμένα αρχεία `README.md`, το `` ΔΕΝ θα αντικατασταθεί μέσα σε αυτά. Επιπλέον, η περιγραφή chart δεν κληρονομείται. Προς το παρόν, ο μόνος τρόπος να προσθέσετε ένα chart στο `$XDG_DATA_HOME/helm/starters` είναι να το αντιγράψετε χειροκίνητα εκεί. Στην τεκμηρίωση του chart σας, μπορεί να θέλετε να εξηγήσετε αυτή τη διαδικασία. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Hooks σε Charts description: Περιγράφει τον τρόπο εργασίας με hooks σε charts. sidebar_position: 2 --- Το Helm παρέχει έναν μηχανισμό _hook_ που επιτρέπει στους δημιουργούς charts να παρεμβαίνουν σε συγκεκριμένα σημεία του κύκλου ζωής ενός release. Για παράδειγμα, μπορείτε να χρησιμοποιήσετε hooks για να: - Φορτώσετε ένα ConfigMap ή Secret κατά την εγκατάσταση πριν φορτωθούν τυχόν άλλα charts. - Εκτελέσετε ένα Job για δημιουργία αντιγράφου ασφαλείας μιας βάσης δεδομένων πριν από την εγκατάσταση ενός νέου chart, και στη συνέχεια εκτελέσετε ένα δεύτερο job μετά την αναβάθμιση για να επαναφέρετε τα δεδομένα. - Εκτελέσετε ένα Job πριν από τη διαγραφή ενός release για να αφαιρέσετε ομαλά μια υπηρεσία από την εναλλαγή πριν την αφαιρέσετε. Τα hooks λειτουργούν όπως τα κανονικά templates, αλλά έχουν ειδικά annotations που αναγκάζουν το Helm να τα χειρίζεται διαφορετικά. Σε αυτήν την ενότητα καλύπτουμε το βασικό μοτίβο χρήσης για τα hooks. ## Τα Διαθέσιμα Hooks {#the-available-hooks} Ορίζονται τα ακόλουθα hooks: | Τιμή Annotation | Περιγραφή | | ------------------ | --------------------------------------------------------------------------------------------------------------- | | `pre-install` | Εκτελείται μετά την απόδοση των templates, αλλά πριν τη δημιουργία οποιουδήποτε πόρου στο Kubernetes | | `post-install` | Εκτελείται μετά τη φόρτωση όλων των πόρων στο Kubernetes | | `pre-delete` | Εκτελείται σε αίτημα διαγραφής πριν τη διαγραφή οποιουδήποτε πόρου από το Kubernetes | | `post-delete` | Εκτελείται σε αίτημα διαγραφής αφού διαγραφούν όλοι οι πόροι του release | | `pre-upgrade` | Εκτελείται σε αίτημα αναβάθμισης μετά την απόδοση των templates, αλλά πριν ενημερωθεί οποιοσδήποτε πόρος | | `post-upgrade` | Εκτελείται σε αίτημα αναβάθμισης μετά την αναβάθμιση όλων των πόρων | | `pre-rollback` | Εκτελείται σε αίτημα rollback μετά την απόδοση των templates, αλλά πριν γίνει rollback οποιουδήποτε πόρου | | `post-rollback` | Εκτελείται σε αίτημα rollback αφού τροποποιηθούν όλοι οι πόροι | | `test` | Εκτελείται όταν καλείται η υποεντολή test του Helm ([δείτε την τεκμηρίωση test](/topics/chart_tests.md)) | _Σημείωση: το hook `crd-install` έχει καταργηθεί υπέρ του φακέλου `crds/` στο Helm 3._ ## Hooks και ο Κύκλος Ζωής του Release {#hooks-and-the-release-lifecycle} Τα hooks σας επιτρέπουν, ως δημιουργό chart, να εκτελείτε λειτουργίες σε στρατηγικά σημεία του κύκλου ζωής ενός release. Για παράδειγμα, σκεφτείτε τον κύκλο ζωής για ένα `helm install`. Από προεπιλογή, ο κύκλος ζωής είναι ο εξής: 1. Ο χρήστης εκτελεί `helm install foo` 2. Καλείται το API εγκατάστασης της βιβλιοθήκης Helm 3. Μετά από ορισμένες επαληθεύσεις, η βιβλιοθήκη αποδίδει τα templates του `foo` 4. Η βιβλιοθήκη φορτώνει τους προκύπτοντες πόρους στο Kubernetes 5. Η βιβλιοθήκη επιστρέφει το αντικείμενο release (και άλλα δεδομένα) στον client 6. Ο client τερματίζει Το Helm ορίζει δύο hooks για τον κύκλο ζωής `install`: `pre-install` και `post-install`. Αν ο δημιουργός του chart `foo` υλοποιήσει και τα δύο hooks, ο κύκλος ζωής τροποποιείται ως εξής: 1. Ο χρήστης εκτελεί `helm install foo` 2. Καλείται το API εγκατάστασης της βιβλιοθήκης Helm 3. Εγκαθίστανται τα CRDs στον φάκελο `crds/` 4. Μετά από ορισμένες επαληθεύσεις, η βιβλιοθήκη αποδίδει τα templates του `foo` 5. Η βιβλιοθήκη προετοιμάζεται να εκτελέσει τα hooks `pre-install` (φορτώνοντας τους πόρους hook στο Kubernetes) 6. Η βιβλιοθήκη ταξινομεί τα hooks κατά βάρος (αναθέτοντας βάρος 0 από προεπιλογή), κατά τύπο πόρου και τέλος κατά όνομα σε αύξουσα σειρά. 7. Η βιβλιοθήκη φορτώνει πρώτα το hook με το μικρότερο βάρος (αρνητικό προς θετικό) 8. Η βιβλιοθήκη περιμένει μέχρι το hook να είναι "Ready" (εκτός από τα CRDs) 9. Η βιβλιοθήκη φορτώνει τους προκύπτοντες πόρους στο Kubernetes. Σημειώστε ότι αν έχει οριστεί η σημαία `--wait`, η βιβλιοθήκη θα περιμένει μέχρι όλοι οι πόροι να βρίσκονται σε κατάσταση ready και δεν θα εκτελέσει το hook `post-install` μέχρι να είναι έτοιμοι. 10. Η βιβλιοθήκη εκτελεί το hook `post-install` (φορτώνοντας τους πόρους hook) 11. Η βιβλιοθήκη περιμένει μέχρι το hook να είναι "Ready" 12. Η βιβλιοθήκη επιστρέφει το αντικείμενο release (και άλλα δεδομένα) στον client 13. Ο client τερματίζει Τι σημαίνει να περιμένουμε μέχρι ένα hook να είναι ready; Αυτό εξαρτάται από τον πόρο που δηλώνεται στο hook. Αν ο πόρος είναι τύπου `Job` ή `Pod`, το Helm θα περιμένει μέχρι να ολοκληρωθεί επιτυχώς. Και αν το hook αποτύχει, το release θα αποτύχει. Αυτή είναι μια _blocking λειτουργία_, επομένως ο client του Helm θα παραμείνει σε αναμονή κατά την εκτέλεση του Job. Για όλους τους άλλους τύπους, μόλις το Kubernetes σημειώσει τον πόρο ως φορτωμένο (προστέθηκε ή ενημερώθηκε), ο πόρος θεωρείται "Ready". Όταν πολλοί πόροι δηλώνονται σε ένα hook, οι πόροι εκτελούνται διαδοχικά. Αν έχουν βάρη hook (δείτε παρακάτω), εκτελούνται με σειρά βάρους. Από το Helm 3.2.0, οι πόροι hook με το ίδιο βάρος εγκαθίστανται με την ίδια σειρά όπως οι κανονικοί πόροι που δεν είναι hook. Διαφορετικά, η σειρά δεν είναι εγγυημένη. (Στο Helm 2.3.0 και μετά, ταξινομούνται αλφαβητικά. Αυτή η συμπεριφορά, ωστόσο, δεν θεωρείται δεσμευτική και μπορεί να αλλάξει στο μέλλον.) Θεωρείται καλή πρακτική να προσθέτετε ένα βάρος hook και να το ορίζετε σε `0` αν το βάρος δεν είναι σημαντικό. ### Οι πόροι hook δεν διαχειρίζονται μαζί με τα αντίστοιχα releases {#hook-resources-are-not-managed-with-corresponding-releases} Οι πόροι που δημιουργεί ένα hook δεν παρακολουθούνται ούτε διαχειρίζονται ως μέρος του release προς το παρόν. Μόλις το Helm επαληθεύσει ότι το hook έχει φτάσει στην κατάσταση ready, θα αφήσει τον πόρο hook ως έχει. Η συλλογή απορριμμάτων των πόρων hook όταν διαγράφεται το αντίστοιχο release μπορεί να προστεθεί στο Helm 3 στο μέλλον, επομένως οποιοιδήποτε πόροι hook που δεν πρέπει ποτέ να διαγραφούν θα πρέπει να φέρουν το annotation `helm.sh/resource-policy: keep`. Πρακτικά, αυτό σημαίνει ότι αν δημιουργήσετε πόρους σε ένα hook, δεν μπορείτε να βασιστείτε στο `helm uninstall` για να αφαιρέσει τους πόρους. Για να καταστρέψετε τέτοιους πόρους, πρέπει είτε να [προσθέσετε ένα προσαρμοσμένο annotation `helm.sh/hook-delete-policy`](#hook-deletion-policies) στο αρχείο template του hook, είτε να [ορίσετε το πεδίο time to live (TTL - χρόνος ζωής) Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Συγγραφή ενός Hook {#writing-a-hook} Τα hooks είναι απλά αρχεία manifest του Kubernetes με ειδικά annotations στην ενότητα `metadata`. Επειδή είναι αρχεία template, μπορείτε να χρησιμοποιήσετε όλες τις κανονικές δυνατότητες template, συμπεριλαμβανομένης της ανάγνωσης `.Values`, `.Release` και `.Template`. Για παράδειγμα, αυτό το template, αποθηκευμένο στο `templates/post-install-job.yaml`, δηλώνει ένα job που θα εκτελεστεί στο `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Αυτό που κάνει αυτό το template να είναι hook είναι το annotation: ```yaml annotations: "helm.sh/hook": post-install ``` Ένας πόρος μπορεί να υλοποιήσει πολλαπλά hooks: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Ομοίως, δεν υπάρχει όριο στον αριθμό των διαφορετικών πόρων που μπορούν να υλοποιήσουν ένα συγκεκριμένο hook. Για παράδειγμα, μπορείτε να δηλώσετε τόσο ένα secret όσο και ένα config map ως hook `pre-install`. Όταν τα subcharts δηλώνουν hooks, αυτά αξιολογούνται επίσης. Δεν υπάρχει τρόπος για ένα chart ανώτερου επιπέδου να απενεργοποιήσει τα hooks που δηλώνονται από τα subcharts. Είναι δυνατός ο ορισμός ενός βάρους για ένα hook που θα βοηθήσει στη δημιουργία μιας καθορισμένης σειράς εκτέλεσης. Τα βάρη ορίζονται χρησιμοποιώντας το ακόλουθο annotation: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Τα βάρη hook μπορούν να είναι θετικοί ή αρνητικοί αριθμοί αλλά πρέπει να αναπαρίστανται ως strings. Όταν το Helm ξεκινά τον κύκλο εκτέλεσης των hooks ενός συγκεκριμένου τύπου, θα ταξινομήσει αυτά τα hooks σε αύξουσα σειρά. ### Πολιτικές διαγραφής hook {#hook-deletion-policies} Είναι δυνατός ο ορισμός πολιτικών που καθορίζουν πότε θα διαγραφούν οι αντίστοιχοι πόροι hook. Οι πολιτικές διαγραφής hook ορίζονται χρησιμοποιώντας το ακόλουθο annotation: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Μπορείτε να επιλέξετε μία ή περισσότερες καθορισμένες τιμές annotation: | Τιμή Annotation | Περιγραφή | | ------------------------ | ---------------------------------------------------------------------------- | | `before-hook-creation` | Διαγράφει τον προηγούμενο πόρο πριν εκκινηθεί ένα νέο hook (προεπιλογή) | | `hook-succeeded` | Διαγράφει τον πόρο μετά την επιτυχή εκτέλεση του hook | | `hook-failed` | Διαγράφει τον πόρο αν το hook απέτυχε κατά την εκτέλεση | Αν δεν καθοριστεί annotation πολιτικής διαγραφής hook, εφαρμόζεται η συμπεριφορά `before-hook-creation` από προεπιλογή. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: Αποσυρμένα API του Kubernetes description: Επεξηγεί τα αποσυρμένα API του Kubernetes στο Helm --- Το Kubernetes είναι ένα σύστημα βασισμένο σε API και το API εξελίσσεται με την πάροδο του χρόνου, αντικατοπτρίζοντας την εξελισσόμενη κατανόηση του πεδίου προβλημάτων. Αυτό είναι κοινή πρακτική σε συστήματα και τα API τους. Ένα σημαντικό μέρος της εξέλιξης των API είναι μια καλή πολιτική απόσυρσης και διαδικασία για να ενημερώνονται οι χρήστες για τις αλλαγές στα API. Δηλαδή, οι καταναλωτές του API σας πρέπει να γνωρίζουν εκ των προτέρων σε ποια έκδοση θα έκδοση θα αφαιρεθεί ή θα αλλάξει ένα API. Αυτό αποτρέπει το στοιχείο της έκπληξης και τις breaking changes για τους καταναλωτές. Η [πολιτική απόσυρσης του Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) τεκμηριώνει τον τρόπο με τον οποίο το Kubernetes χειρίζεται τις αλλαγές στις εκδόσεις του API. Η πολιτική απόσυρσης καθορίζει το χρονικό πλαίσιο υποστήριξης των εκδόσεων API μετά από μια ανακοίνωση απόσυρσης. Επομένως, είναι σημαντικό να παρακολουθείτε τις ανακοινώσεις απόσυρσης και να γνωρίζετε πότε θα αφαιρεθούν οι εκδόσεις API, ώστε να ελαχιστοποιήσετε τις επιπτώσεις. Αυτό είναι ένα παράδειγμα ανακοίνωσης [για την αφαίρεση αποσυρμένων εκδόσεων API στο Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) που δημοσιεύτηκε μερικούς μήνες πριν την κυκλοφορία. Αυτές οι εκδόσεις API θα είχαν ανακοινωθεί ως αποσυρμένες ακόμα νωρίτερα. Αυτό δείχνει ότι υπάρχει μια καλή πολιτική που ενημερώνει τους καταναλωτές για την υποστήριξη εκδόσεων API. Τα templates του Helm καθορίζουν ένα [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) κατά τον ορισμό ενός αντικειμένου Kubernetes, παρόμοια με ένα αρχείο manifest του Kubernetes. Καθορίζεται στο πεδίο `apiVersion` του template και προσδιορίζει την έκδοση API του αντικειμένου Kubernetes. Αυτό σημαίνει ότι οι χρήστες του Helm και οι συντηρητές chart πρέπει να γνωρίζουν πότε οι εκδόσεις API του Kubernetes έχουν αποσυρθεί και σε ποια έκδοση Kubernetes θα αφαιρεθούν. ## Συντηρητές Chart {#chart-maintainers} Θα πρέπει να ελέγξετε τα chart σας για εκδόσεις API του Kubernetes που έχουν αποσυρθεί ή αφαιρεθεί σε κάποια έκδοση Kubernetes. Οι εκδόσεις API που προβλέπεται να αποσυρθούν ή δεν υποστηρίζονται πλέον, θα πρέπει να ενημερωθούν στην υποστηριζόμενη έκδοση και να κυκλοφορήσει μια νέα έκδοση του chart. Η έκδοση API ορίζεται από τα πεδία `kind` και `apiVersion`. Για παράδειγμα, εδώ είναι μια αφαιρεμένη έκδοση API αντικειμένου `Deployment` στο Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Χρήστες του Helm {#helm-users} Θα πρέπει να ελέγξετε τα chart που χρησιμοποιείτε (παρόμοια με τους [συντηρητές chart](#chart-maintainers)) και να εντοπίσετε τυχόν chart με εκδόσεις API που έχουν αποσυρθεί ή αφαιρεθεί σε κάποια έκδοση Kubernetes. Για τα chart που εντοπίζετε, πρέπει να ελέγξετε για την τελευταία έκδοση του chart (που έχει υποστηριζόμενες εκδόσεις API) ή να ενημερώσετε το chart μόνοι σας. Επιπλέον, πρέπει επίσης να ελέγξετε τα chart που έχετε εγκαταστήσει (δηλαδή τα Helm releases) για τυχόν αποσυρμένες ή αφαιρεμένες εκδόσεις API. Αυτό μπορεί να γίνει με τη λήψη λεπτομερειών ενός release χρησιμοποιώντας την εντολή `helm get manifest`. Ο τρόπος ενημέρωσης ενός Helm release σε υποστηριζόμενα API εξαρτάται από τα ευρήματά σας ως εξής: 1. Αν βρείτε μόνο αποσυρμένες εκδόσεις API τότε: - Εκτελέστε `helm upgrade` με μια έκδοση του chart που έχει υποστηριζόμενες εκδόσεις API του Kubernetes - Προσθέστε μια περιγραφή στην αναβάθμιση, που να αναφέρει να μην γίνει rollback σε έκδοση Helm πριν από αυτή την τρέχουσα έκδοση 2. Αν βρείτε κάποια έκδοση(εις) API που έχει(ουν) αφαιρεθεί σε κάποια έκδοση Kubernetes τότε: - Αν εκτελείτε μια έκδοση Kubernetes όπου η(οι) έκδοση(εις) API είναι ακόμα διαθέσιμη(ες) (για παράδειγμα, είστε στο Kubernetes 1.15 και βρήκατε ότι χρησιμοποιείτε API που θα αφαιρεθούν στο Kubernetes 1.16): - Ακολουθήστε τη διαδικασία του βήματος 1 - Διαφορετικά (για παράδειγμα, εκτελείτε ήδη μια έκδοση Kubernetes όπου κάποιες εκδόσεις API που αναφέρονται από το `helm get manifest` δεν είναι πλέον διαθέσιμες): - Πρέπει να επεξεργαστείτε το manifest του release που είναι αποθηκευμένο στο cluster για να ενημερώσετε τις εκδόσεις API σε υποστηριζόμενα API. Δείτε [Ενημέρωση Εκδόσεων API ενός Release Manifest](#updating-api-versions-of-a-release-manifest) για περισσότερες λεπτομέρειες > Σημείωση: Σε όλες τις περιπτώσεις ενημέρωσης ενός Helm release με υποστηριζόμενα API, δεν πρέπει ποτέ να κάνετε rollback του release σε έκδοση πριν από την έκδοση release με τα υποστηριζόμενα API. > Σύσταση: Η βέλτιστη πρακτική είναι να αναβαθμίζετε τα releases που χρησιμοποιούν αποσυρμένες εκδόσεις API σε υποστηριζόμενες εκδόσεις API, πριν αναβαθμίσετε σε ένα Kubernetes cluster που αφαιρεί αυτές τις εκδόσεις API. Αν δεν ενημερώσετε ένα release όπως προτείνεται παραπάνω, θα λάβετε ένα σφάλμα παρόμοιο με το ακόλουθο όταν προσπαθήσετε να αναβαθμίσετε ένα release σε μια έκδοση Kubernetes όπου η(οι) έκδοση(εις) API του έχει(ουν) αφαιρεθεί: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Το Helm αποτυγχάνει σε αυτό το σενάριο επειδή προσπαθεί να δημιουργήσει ένα diff patch μεταξύ του τρέχοντος εγκατεστημένου release (που περιέχει τα API του Kubernetes που έχουν αφαιρεθεί σε αυτή την έκδοση Kubernetes) και του chart που περνάτε με τις ενημερωμένες/υποστηριζόμενες εκδόσεις API. Ο υποκείμενος λόγος της αποτυχίας είναι ότι όταν το Kubernetes αφαιρεί μια έκδοση API, η βιβλιοθήκη Go client του Kubernetes δεν μπορεί πλέον να αναλύσει τα αποσυρμένα αντικείμενα και επομένως το Helm αποτυγχάνει κατά την κλήση της βιβλιοθήκης. Δυστυχώς, το Helm δεν μπορεί να ανακτήσει από αυτή την κατάσταση και δεν είναι πλέον σε θέση να διαχειριστεί ένα τέτοιο release. Δείτε [Ενημέρωση Εκδόσεων API ενός Release Manifest](#updating-api-versions-of-a-release-manifest) για περισσότερες λεπτομέρειες σχετικά με τον τρόπο ανάκτησης από αυτό το σενάριο. ## Ενημέρωση Εκδόσεων API ενός Release Manifest {#updating-api-versions-of-a-release-manifest} Το manifest είναι μια ιδιότητα του αντικειμένου Helm release που αποθηκεύεται στο πεδίο data ενός Secret (προεπιλογή) ή ConfigMap στο cluster. Το πεδίο data περιέχει ένα συμπιεσμένο (gzip) αντικείμενο που είναι κωδικοποιημένο σε base 64 (υπάρχει μια επιπλέον κωδικοποίηση base 64 για τα Secret). Υπάρχει ένα Secret/ConfigMap ανά έκδοση/αναθεώρηση release στο namespace του release. Μπορείτε να χρησιμοποιήσετε το plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis) του Helm για να εκτελέσετε την ενημέρωση ενός release σε υποστηριζόμενα API. Ελέγξτε το readme για περισσότερες λεπτομέρειες. Εναλλακτικά, μπορείτε να ακολουθήσετε αυτά τα χειροκίνητα βήματα για να εκτελέσετε μια ενημέρωση των εκδόσεων API ενός release manifest. Ανάλογα με τις ρυθμίσεις σας, θα ακολουθήσετε τα βήματα για το Secret ή το ConfigMap backend. - Λήψη του ονόματος του Secret ή ConfigMap που σχετίζεται με το τελευταίο εγκατεστημένο release: - Secret backend: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap backend: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Λήψη λεπτομερειών του τελευταίου εγκατεστημένου release: - Secret backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap backend: `kubectl get configmap -n -o yaml > release.yaml` - Δημιουργία αντιγράφου ασφαλείας του release σε περίπτωση που χρειαστεί επαναφορά αν κάτι πάει στραβά: - `cp release.yaml release.bak` - Σε περίπτωση έκτακτης ανάγκης, επαναφορά: `kubectl apply -f release.bak -n ` - Αποκωδικοποίηση του αντικειμένου release: - Secret backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Αλλαγή των εκδόσεων API των manifests. Μπορείτε να χρησιμοποιήσετε οποιοδήποτε εργαλείο (π.χ. editor) για να κάνετε τις αλλαγές. Αυτό βρίσκεται στο πεδίο `manifest` του αποκωδικοποιημένου αντικειμένου release σας (`release.data.decoded`) - Κωδικοποίηση του αντικειμένου release: - Secret backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap backend: `cat release.data.decoded | gzip | base64` - Αντικατάσταση της τιμής της ιδιότητας `data.release` στο αρχείο του εγκατεστημένου release (`release.yaml`) με το νέο κωδικοποιημένο αντικείμενο release - Εφαρμογή του αρχείου στο namespace: `kubectl apply -f release.yaml -n ` - Εκτέλεση `helm upgrade` με μια έκδοση του chart που έχει υποστηριζόμενες εκδόσεις API του Kubernetes - Προσθήκη μιας περιγραφής στην αναβάθμιση, που να αναφέρει να μην γίνει rollback σε έκδοση Helm πριν από αυτή την τρέχουσα έκδοση ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Οδηγός Διανομών Kubernetes description: Πληροφορίες σχετικά με τη χρήση του Helm σε συγκεκριμένα περιβάλλοντα Kubernetes. sidebar_position: 10 --- Το Helm λειτουργεί με οποιαδήποτε [συμβατή έκδοση του Kubernetes](https://github.com/cncf/k8s-conformance) (είτε είναι [πιστοποιημένη](https://www.cncf.io/certification/software-conformance/) είτε όχι). Αυτό το έγγραφο περιέχει πληροφορίες σχετικά με τη χρήση του Helm σε συγκεκριμένα περιβάλλοντα Kubernetes. Μπορείτε να συνεισφέρετε περισσότερες λεπτομέρειες για οποιαδήποτε διανομή (ταξινομημένες αλφαβητικά) αν θέλετε. ## AKS {#aks} Το Helm λειτουργεί με το [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS {#dcos} Το Helm έχει δοκιμαστεί και λειτουργεί στην πλατφόρμα Kubernetes του Mesosphere DC/OS 1.11, και δεν απαιτεί πρόσθετη διαμόρφωση. ## EKS {#eks} Το Helm λειτουργεί με το Amazon Elastic Kubernetes Service (Amazon EKS): [Χρήση του Helm με το Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE {#gke} Η πλατφόρμα GKE της Google λειτουργεί με το Helm και δεν απαιτεί πρόσθετη διαμόρφωση. ## `scripts/local-cluster` και Hyperkube {#scriptslocal-cluster-and-hyperkube} Το Hyperkube ρυθμισμένο μέσω του `scripts/local-cluster.sh` λειτουργεί κανονικά. Για το Hyperkube χωρίς script μπορεί να χρειαστεί χειροκίνητη διαμόρφωση. ## IKS {#iks} Το Helm λειτουργεί με το [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) {#kind-kubernetes-in-docker} Το Helm δοκιμάζεται τακτικά στο [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne {#kubeone} Το Helm λειτουργεί σε cluster που δημιουργούνται με το KubeOne χωρίς ιδιαίτερες προϋποθέσεις. ## Kubermatic {#kubermatic} Το Helm λειτουργεί σε user cluster που δημιουργούνται από το Kubermatic χωρίς ιδιαίτερες προϋποθέσεις. Καθώς τα seed cluster μπορούν να ρυθμιστούν με διαφορετικούς τρόπους, η υποστήριξη του Helm εξαρτάται από τη διαμόρφωσή τους. ## MicroK8s {#microk8s} Το Helm μπορεί να ενεργοποιηθεί στο [MicroK8s](https://microk8s.io) με την εντολή: `microk8s.enable helm3` ## Minikube {#minikube} Το Helm έχει δοκιμαστεί και λειτουργεί με το [Minikube](https://github.com/kubernetes/minikube). Δεν απαιτεί πρόσθετη διαμόρφωση. ## Openshift {#openshift} Το Helm λειτουργεί απευθείας στο OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (έκδοση >= 3.6) ή OpenShift Origin (έκδοση >= 3.6). Για περισσότερες πληροφορίες διαβάστε [αυτό το άρθρο](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 {#platform9} Το Helm είναι προεγκατεστημένο στο [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Η Platform9 παρέχει πρόσβαση σε όλα τα επίσημα Helm chart μέσω του App Catalog UI και του native Kubernetes CLI. Μπορείτε επίσης να προσθέσετε χειροκίνητα πρόσθετα repository. Περισσότερες λεπτομέρειες είναι διαθέσιμες σε αυτό το [άρθρο για το Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu με `kubeadm` {#ubuntu-with-kubeadm} Το Kubernetes που έχει ρυθμιστεί με το `kubeadm` λειτουργεί στις ακόλουθες διανομές Linux: - Ubuntu 16.04 - Fedora release 25 Ορισμένες εκδόσεις του Helm (v2.0.0-beta2) απαιτούν να εκτελέσετε `export KUBECONFIG=/etc/kubernetes/admin.conf` ή να δημιουργήσετε ένα `~/.kube/config`. ## VMware Tanzu Kubernetes Grid {#vmware-tanzu-kubernetes-grid} Το Helm λειτουργεί στο VMware Tanzu Kubernetes Grid, TKG, χωρίς να χρειάζονται αλλαγές στη διαμόρφωση. Το Tanzu CLI μπορεί να διαχειριστεί την εγκατάσταση πακέτων για το [helm-controller](https://fluxcd.io/flux/components/helm/), επιτρέποντας τη δηλωτική διαχείριση των Helm chart release. Περισσότερες λεπτομέρειες είναι διαθέσιμες στην τεκμηρίωση του TKG για τα [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Library Charts description: Εξηγεί τα library charts και παραδείγματα χρήσης τους sidebar_position: 4 --- Τα library charts είναι ένας τύπος [Helm chart](/topics/charts.md) που ορίζει βασικά στοιχεία ή ορισμούς chart, τα οποία μπορούν να χρησιμοποιηθούν από Helm templates σε άλλα charts. Αυτό επιτρέπει τον διαμοιρασμό αποσπασμάτων κώδικα που επαναχρησιμοποιούνται σε διαφορετικά charts, αποφεύγοντας την επανάληψη και διατηρώντας τα charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Το library chart εισήχθη στο Helm 3 για να αναγνωρίσει επίσημα τα κοινά ή βοηθητικά charts που χρησιμοποιούνταν από συντηρητές charts από το Helm 2. Ως τύπος chart, παρέχει: - Σαφή διάκριση μεταξύ κοινών και application charts - Λογική που αποτρέπει την εγκατάσταση ενός κοινού chart - Καμία απόδοση templates σε ένα κοινό chart που μπορεί να περιέχει release artifacts - Δυνατότητα στα εξαρτώμενα charts να χρησιμοποιούν το context του chart που τα εισάγει Ένας συντηρητής chart μπορεί να ορίσει ένα κοινό chart ως library chart και να είναι βέβαιος ότι το Helm θα το χειριστεί με τυπικό και συνεπή τρόπο. Επιπλέον, οι ορισμοί σε ένα application chart μπορούν να διαμοιραστούν αλλάζοντας τον τύπο του chart. ## Δημιουργία Απλού Library Chart {#create-a-simple-library-chart} Όπως αναφέρθηκε προηγουμένως, ένα library chart είναι ένας τύπος [Helm chart](/topics/charts.md). Μπορείτε λοιπόν να ξεκινήσετε δημιουργώντας ένα αρχικό chart: ```console $ helm create mylibchart Creating mylibchart ``` Αφαιρέστε πρώτα όλα τα αρχεία στον κατάλογο `templates`, καθώς θα δημιουργήσουμε τους δικούς μας ορισμούς templates σε αυτό το παράδειγμα. ```console $ rm -rf mylibchart/templates/* ``` Το αρχείο values δεν θα χρειαστεί επίσης. ```console $ rm -f mylibchart/values.yaml ``` Πριν δημιουργήσουμε κοινό κώδικα, ας κάνουμε μια γρήγορη ανασκόπηση ορισμένων σχετικών εννοιών του Helm. Ένα [named template](/chart_template_guide/named_templates.md) (μερικές φορές ονομάζεται partial ή subtemplate) είναι απλά ένα template που ορίζεται μέσα σε ένα αρχείο με συγκεκριμένο όνομα. Στον κατάλογο `templates/`, οποιοδήποτε αρχείο ξεκινά με κάτω παύλα (_) δεν αναμένεται να παράγει αρχείο manifest του Kubernetes. Κατά σύμβαση λοιπόν, τα βοηθητικά templates και τα partials τοποθετούνται σε αρχεία `_*.tpl` ή `_*.yaml`. Σε αυτό το παράδειγμα, θα δημιουργήσουμε ένα κοινό ConfigMap με κενό πόρο ConfigMap. Ο ορισμός του κοινού ConfigMap γίνεται στο αρχείο `mylibchart/templates/_configmap.yaml` ως εξής: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Η δομή του ConfigMap ορίζεται στο named template `mylibchart.configmap.tpl`. Πρόκειται για ένα απλό ConfigMap με κενό πόρο `data`. Στο ίδιο αρχείο υπάρχει ένα άλλο named template με όνομα `mylibchart.configmap`. Αυτό το named template περιλαμβάνει το `mylibchart.util.merge` που δέχεται 2 named templates ως ορίσματα: το template που καλεί το `mylibchart.configmap` και το `mylibchart.configmap.tpl`. Η βοηθητική συνάρτηση `mylibchart.util.merge` είναι ένα named template στο `mylibchart/templates/_util.yaml`. Πρόκειται για ένα χρήσιμο εργαλείο από το [The Common Helm Helper Chart](#the-common-helm-helper-chart), καθώς συγχωνεύει τα 2 templates και παρακάμπτει τα κοινά μέρη τους: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Αυτό είναι σημαντικό όταν ένα chart χρειάζεται να χρησιμοποιήσει κοινό κώδικα και να τον προσαρμόσει στη δική του διαμόρφωση. Τέλος, αλλάξτε τον τύπο του chart σε `library`. Αυτό απαιτεί επεξεργασία του `mylibchart/Chart.yaml` ως εξής: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. {#a-chart-can-be-either-an-application-or-a-library-chart} # # Application charts are a collection of templates that can be packaged into versioned archives {#application-charts-are-a-collection-of-templates-that-can-be-packaged-into-versioned-archives} # to be deployed. {#to-be-deployed} # # Library charts provide useful utilities or functions for the chart developer. They're included as {#library-charts-provide-useful-utilities-or-functions-for-the-chart-developer-theyre-included-as} # a dependency of application charts to inject those utilities and functions into the rendering {#a-dependency-of-application-charts-to-inject-those-utilities-and-functions-into-the-rendering} # pipeline. Library charts do not define any templates and therefore cannot be deployed. {#pipeline-library-charts-do-not-define-any-templates-and-therefore-cannot-be-deployed} # type: application {#type-application} type: library # This is the chart version. This version number should be incremented each time you make changes {#this-is-the-chart-version-this-version-number-should-be-incremented-each-time-you-make-changes} # to the chart and its templates, including the app version. {#to-the-chart-and-its-templates-including-the-app-version} version: 0.1.0 # This is the version number of the application being deployed. This version number should be {#this-is-the-version-number-of-the-application-being-deployed-this-version-number-should-be} # incremented each time you make changes to the application and it is recommended to use it with quotes. {#incremented-each-time-you-make-changes-to-the-application-and-it-is-recommended-to-use-it-with-quotes} appVersion: "1.16.0" ``` Το library chart είναι τώρα έτοιμο για διαμοιρασμό και ο ορισμός του ConfigMap μπορεί να επαναχρησιμοποιηθεί. Πριν προχωρήσετε, ελέγξτε αν το Helm αναγνωρίζει το chart ως library chart: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Χρήση του Απλού Library Chart {#use-the-simple-library-chart} Τώρα μπορούμε να χρησιμοποιήσουμε το library chart. Δημιουργήστε ξανά ένα αρχικό chart: ```console $ helm create mychart Creating mychart ``` Καθαρίστε τα αρχεία template ξανά, καθώς θέλουμε να δημιουργήσουμε μόνο ένα ConfigMap: ```console $ rm -rf mychart/templates/* ``` Αν θέλαμε να δημιουργήσουμε ένα απλό ConfigMap σε ένα Helm template, θα μπορούσε να μοιάζει με το ακόλουθο: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Ωστόσο, θα επαναχρησιμοποιήσουμε τον κοινό κώδικα που έχει ήδη δημιουργηθεί στο `mylibchart`. Το ConfigMap μπορεί να δημιουργηθεί στο αρχείο `mychart/templates/configmap.yaml` ως εξής: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Με αυτόν τον τρόπο απλοποιείται η δουλειά, κληρονομώντας τον κοινό ορισμό ConfigMap που προσθέτει τυπικές ιδιότητες για το ConfigMap. Στο template προσθέτουμε τη διαμόρφωση, σε αυτή την περίπτωση το κλειδί δεδομένων `myvalue` και την τιμή του. Η διαμόρφωση παρακάμπτει τον κενό πόρο του κοινού ConfigMap. Αυτό είναι εφικτό χάρη στη βοηθητική συνάρτηση `mylibchart.util.merge` που αναφέραμε στην προηγούμενη ενότητα. Για να χρησιμοποιήσουμε τον κοινό κώδικα, πρέπει να προσθέσουμε το `mylibchart` ως εξάρτηση. Προσθέστε τα ακόλουθα στο τέλος του αρχείου `mychart/Chart.yaml`: ```yaml # My common code in my library chart {#my-common-code-in-my-library-chart} dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Με αυτόν τον τρόπο το library chart συμπεριλαμβάνεται ως δυναμική εξάρτηση από το σύστημα αρχείων, στην ίδια γονική διαδρομή με το application chart. Επειδή συμπεριλαμβάνουμε το library chart ως δυναμική εξάρτηση, πρέπει να εκτελέσουμε `helm dependency update`. Αυτό θα αντιγράψει το library chart στον κατάλογο `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Είμαστε τώρα έτοιμοι να κάνουμε deploy το chart. Πριν την εγκατάσταση, ελέγξτε πρώτα το rendered template. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml {#source-mycharttemplatesconfigmapyaml} {#source-mycharttemplatesconfigmapyaml} apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Αυτό μοιάζει με το ConfigMap που θέλουμε, με παράκαμψη δεδομένων `myvalue: Hello World`. Εγκαταστήστε το: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Μπορούμε να ανακτήσουμε το release και να δούμε ότι το πραγματικό template φορτώθηκε. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Πλεονεκτήματα Library Chart {#library-chart-benefits} Επειδή τα library charts δεν μπορούν να λειτουργήσουν ως αυτόνομα charts, μπορούν να αξιοποιήσουν την ακόλουθη λειτουργικότητα: - Το αντικείμενο `.Files` αναφέρεται στις διαδρομές αρχείων του γονικού chart, αντί της τοπικής διαδρομής του library chart - Το αντικείμενο `.Values` είναι το ίδιο με αυτό του γονικού chart, σε αντίθεση με τα application [subcharts](/chart_template_guide/subcharts_and_globals.md) που λαμβάνουν την ενότητα values που έχει διαμορφωθεί κάτω από την επικεφαλίδα τους στο γονικό ## The Common Helm Helper Chart {#the-common-helm-helper-chart} ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` Αυτό το [chart](https://github.com/helm/charts/tree/master/incubator/common) ήταν το αρχικό μοτίβο για τα common charts. Παρέχει εργαλεία που αντικατοπτρίζουν τις βέλτιστες πρακτικές ανάπτυξης Kubernetes chart. Το καλύτερο απ' όλα είναι ότι μπορείτε να το χρησιμοποιήσετε αμέσως κατά την ανάπτυξη των δικών σας charts, αποκτώντας έτοιμο κοινόχρηστο κώδικα. Ακολουθεί ένας γρήγορος τρόπος χρήσης. Για περισσότερες λεπτομέρειες, δείτε το [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Δημιουργήστε ένα αρχικό chart ξανά: ```console $ helm create demo Creating demo ``` Ας χρησιμοποιήσουμε τον κοινό κώδικα από το helper chart. Πρώτα, επεξεργαστείτε το deployment `demo/templates/deployment.yaml` ως εξής: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. {#define-overrides-for-your-deployment-resource-here-eg} apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` Στη συνέχεια το αρχείο service, `demo/templates/service.yaml` ως εξής: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. {#define-overrides-for-your-service-resource-here-eg} # metadata: {#metadata} # labels: {#labels} # custom: label {#custom-label} # spec: {#spec} # ports: {#ports} # - port: 8080 {#port-8080} {{- end -}} ``` Αυτά τα templates δείχνουν πώς η κληρονομικότητα του κοινού κώδικα από το helper chart απλοποιεί τον κώδικα στη διαμόρφωση ή την προσαρμογή των πόρων. Για να χρησιμοποιήσουμε τον κοινό κώδικα, πρέπει να προσθέσουμε το `common` ως εξάρτηση. Προσθέστε τα ακόλουθα στο τέλος του αρχείου `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Σημείωση: Θα πρέπει να προσθέσετε το `incubator` repo στη λίστα αποθετηρίων Helm (`helm repo add`). Επειδή συμπεριλαμβάνουμε το chart ως δυναμική εξάρτηση, πρέπει να εκτελέσουμε `helm dependency update`. Αυτό θα αντιγράψει το helper chart στον κατάλογο `charts/`. Επειδή το helper chart χρησιμοποιεί ορισμένες δομές του Helm 2, θα πρέπει να προσθέσετε τα ακόλουθα στο `demo/values.yaml` για να ενεργοποιηθεί η φόρτωση του `nginx` image, καθώς αυτό ενημερώθηκε στο αρχικό chart του Helm 3: ```yaml image: tag: 1.16.0 ``` Μπορείτε να ελέγξετε ότι τα chart templates είναι σωστά πριν το deploy χρησιμοποιώντας τις εντολές `helm lint` και `helm template`. Αν όλα είναι εντάξει, προχωρήστε στο deploy με `helm install`! ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Διαχείριση Δικαιωμάτων για SQL Storage Backend description: Μάθετε πώς να ρυθμίζετε δικαιώματα όταν χρησιμοποιείτε SQL storage backend. --- Αυτός ο οδηγός παρέχει καθοδήγηση για τη ρύθμιση και διαχείριση δικαιωμάτων όταν χρησιμοποιείτε το SQL storage backend. ## Εισαγωγή {#introduction} Για τη διαχείριση δικαιωμάτων, το Helm αξιοποιεί τη λειτουργία RBAC του Kubernetes. Όταν χρησιμοποιείτε το SQL storage backend, οι ρόλοι του Kubernetes δεν μπορούν να καθορίσουν αν ένας χρήστης έχει πρόσβαση σε έναν συγκεκριμένο πόρο. Αυτός ο οδηγός εξηγεί πώς να δημιουργήσετε και να διαχειριστείτε αυτά τα δικαιώματα. ## Αρχικοποίηση {#initialization} Την πρώτη φορά που το Helm CLI θα συνδεθεί στη βάση δεδομένων σας, ο client θα ελέγξει αν έχει γίνει προηγούμενη αρχικοποίηση. Αν όχι, θα πραγματοποιήσει αυτόματα τις απαραίτητες ρυθμίσεις. Αυτή η αρχικοποίηση απαιτεί δικαιώματα διαχειριστή στο public schema, ή τουλάχιστον τη δυνατότητα να: * δημιουργήσετε έναν πίνακα * εκχωρήσετε δικαιώματα στο public schema Μετά την εκτέλεση της μετάβασης στη βάση δεδομένων σας, όλοι οι άλλοι ρόλοι μπορούν να χρησιμοποιήσουν τον client. ## Εκχώρηση δικαιωμάτων σε μη διαχειριστή στην PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql} Για τη διαχείριση δικαιωμάτων, ο driver του SQL backend αξιοποιεί τη λειτουργία [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Level) της PostgreSQL. Το RLS επιτρέπει σε όλους τους χρήστες να διαβάζουν και να γράφουν στον ίδιο πίνακα, χωρίς να μπορούν να τροποποιούν τις ίδιες γραμμές εάν δεν τους έχει δοθεί ρητά η άδεια. Από προεπιλογή, κάθε ρόλος στον οποίο δεν έχουν εκχωρηθεί ρητά τα κατάλληλα δικαιώματα θα λαμβάνει πάντα κενή λίστα όταν εκτελεί `helm list` και δεν θα μπορεί να ανακτήσει ή να τροποποιήσει κανέναν πόρο στο cluster. Ας δούμε πώς να εκχωρήσετε πρόσβαση σε έναν ρόλο για συγκεκριμένα namespaces: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Αυτή η εντολή εκχωρεί δικαιώματα ανάγνωσης και εγγραφής όλων των πόρων που πληρούν τη συνθήκη `namespace = 'default'` στον ρόλο `role`. Μετά τη δημιουργία αυτής της πολιτικής, ο χρήστης που συνδέεται στη βάση δεδομένων για τον ρόλο `role` θα μπορεί να βλέπει όλα τα releases στο namespace `default` όταν εκτελεί `helm list`, καθώς και να τα τροποποιεί και να τα διαγράφει. Τα δικαιώματα μπορούν να διαχειριστούν με λεπτομέρεια χρησιμοποιώντας το RLS. Μπορεί να σας ενδιαφέρει να περιορίσετε την πρόσβαση βάσει των διαφορετικών στηλών του πίνακα: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Ο Οδηγός Plugins του Helm description: Εισάγει τον τρόπο χρήσης και δημιουργίας plugins για την επέκταση της λειτουργικότητας του Helm. sidebar_position: 12 --- Ένα plugin του Helm είναι ένα εργαλείο που είναι προσβάσιμο μέσω του CLI του `helm`, αλλά δεν αποτελεί μέρος του ενσωματωμένου κώδικα του Helm. Υπάρχοντα plugins μπορείτε να βρείτε στην ενότητα [σχετικά](/community/related#helm-plugins) ή αναζητώντας στο [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Αυτός ο οδηγός εξηγεί πώς να χρησιμοποιήσετε και να δημιουργήσετε plugins. ## Επισκόπηση {#an-overview} Τα plugins του Helm είναι πρόσθετα εργαλεία που ενσωματώνονται απρόσκοπτα με το Helm. Παρέχουν έναν τρόπο επέκτασης του βασικού συνόλου λειτουργιών του Helm, χωρίς να απαιτείται κάθε νέα λειτουργία να είναι γραμμένη σε Go και να προστεθεί στο βασικό εργαλείο. Τα plugins του Helm έχουν τα ακόλουθα χαρακτηριστικά: - Μπορούν να προστεθούν και να αφαιρεθούν από μια εγκατάσταση Helm χωρίς να επηρεάζεται το βασικό εργαλείο Helm. - Μπορούν να γραφτούν σε οποιαδήποτε γλώσσα προγραμματισμού. - Ενσωματώνονται με το Helm και εμφανίζονται στο `helm help` και σε άλλα σημεία. Τα plugins του Helm βρίσκονται στο `$HELM_PLUGINS`. Μπορείτε να βρείτε την τρέχουσα τιμή αυτού, συμπεριλαμβανομένης της προεπιλεγμένης τιμής όταν δεν έχει οριστεί στο περιβάλλον, χρησιμοποιώντας την εντολή `helm env`. Το μοντέλο plugins του Helm βασίζεται εν μέρει στο μοντέλο plugins του Git. Για αυτό τον λόγο, μπορεί μερικές φορές να ακούσετε το `helm` να αναφέρεται ως το επίπεδο _porcelain_, με τα plugins να είναι το _plumbing_. Αυτός είναι ένας συντομευμένος τρόπος για να υποδηλωθεί ότι το Helm παρέχει την εμπειρία χρήστη και τη λογική επεξεργασίας υψηλού επιπέδου, ενώ τα plugins εκτελούν τη "λεπτομερή εργασία" για την πραγματοποίηση μιας επιθυμητής ενέργειας. ## Εγκατάσταση ενός Plugin {#installing-a-plugin} Τα plugins εγκαθίστανται χρησιμοποιώντας την εντολή `$ helm plugin install `. Μπορείτε να περάσετε μια διαδρομή προς ένα plugin στο τοπικό σας σύστημα αρχείων ή ένα url ενός απομακρυσμένου VCS αποθετηρίου. Η εντολή `helm plugin install` κλωνοποιεί ή αντιγράφει το plugin από τη διαδρομή/url που δίνεται στο `$HELM_PLUGINS`. Αν εγκαθιστάτε από VCS, μπορείτε να καθορίσετε την έκδοση με το όρισμα `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Αν έχετε μια διανομή plugin σε μορφή tar, απλώς αποσυμπιέστε το plugin στον κατάλογο `$HELM_PLUGINS`. Μπορείτε επίσης να εγκαταστήσετε plugins σε μορφή tarball απευθείας από url εκτελώντας `helm plugin install https://domain/path/to/plugin.tar.gz` ## Η Δομή Αρχείων του Plugin {#the-plugin-file-structure} Από πολλές απόψεις, ένα plugin είναι παρόμοιο με ένα chart. Κάθε plugin έχει έναν κατάλογο ανώτατου επιπέδου που περιέχει ένα αρχείο `plugin.yaml`. Μπορεί να υπάρχουν πρόσθετα αρχεία, αλλά μόνο το αρχείο `plugin.yaml` είναι απαραίτητο. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Το Αρχείο plugin.yaml {#the-pluginyaml-file} Το αρχείο plugin.yaml είναι απαραίτητο για ένα plugin. Περιέχει τα ακόλουθα πεδία: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### Το Πεδίο `name` {#the-name-field} Το `name` είναι το όνομα του plugin. Όταν το Helm εκτελεί αυτό το plugin, αυτό είναι το όνομα που θα χρησιμοποιήσει (π.χ. η εντολή `helm NAME` θα καλέσει αυτό το plugin). _Το `name` πρέπει να ταιριάζει με το όνομα του καταλόγου._ Στο παράδειγμά μας παραπάνω, αυτό σημαίνει ότι το plugin με `name: last` πρέπει να περιέχεται σε έναν κατάλογο με όνομα `last`. Περιορισμοί στο `name`: - Το `name` δεν μπορεί να αντιγράφει μία από τις υπάρχουσες εντολές ανώτατου επιπέδου του `helm`. - Το `name` πρέπει να περιορίζεται στους χαρακτήρες ASCII a-z, A-Z, 0-9, `_` και `-`. ### Το Πεδίο `version` {#the-version-field} Το `version` είναι η έκδοση SemVer 2 του plugin. Τα πεδία `usage` και `description` χρησιμοποιούνται και τα δύο για τη δημιουργία του κειμένου βοήθειας μιας εντολής. ### Το Πεδίο `ignoreFlags` {#the-ignoreflags-field} Ο διακόπτης `ignoreFlags` λέει στο Helm να _μην_ περάσει τις σημαίες στο plugin. Επομένως, αν ένα plugin κληθεί με `helm myplugin --foo` και `ignoreFlags: true`, τότε η σημαία `--foo` απορρίπτεται σιωπηλά. ### Το Πεδίο `platformCommand` {#the-platformcommand-field} Το `platformCommand` ρυθμίζει την εντολή που θα εκτελέσει το plugin όταν κληθεί. Δεν μπορείτε να ορίσετε ταυτόχρονα και `platformCommand` και `command` καθώς αυτό θα οδηγήσει σε σφάλμα. Οι ακόλουθοι κανόνες ισχύουν για τον καθορισμό της εντολής που θα χρησιμοποιηθεί: - Αν υπάρχει το `platformCommand`, θα χρησιμοποιηθεί. - Αν τόσο το `os` όσο και το `arch` ταιριάζουν με την τρέχουσα πλατφόρμα, η αναζήτηση θα σταματήσει και η εντολή θα χρησιμοποιηθεί. - Αν το `os` ταιριάζει και το `arch` είναι κενό, η εντολή θα χρησιμοποιηθεί. - Αν και το `os` και το `arch` είναι κενά, η εντολή θα χρησιμοποιηθεί. - Αν δεν υπάρχει αντιστοιχία, το Helm θα τερματίσει με σφάλμα. - Αν το `platformCommand` δεν υπάρχει και υπάρχει η καταργημένη εντολή `command`, θα χρησιμοποιηθεί αυτή. - Αν η εντολή είναι κενή, το Helm θα τερματίσει με σφάλμα. ### Το Πεδίο `platformHooks` {#the-platformhooks-field} Το `platformHooks` ρυθμίζει τις εντολές που θα εκτελέσει το plugin για συμβάντα κύκλου ζωής. Δεν μπορείτε να ορίσετε ταυτόχρονα και `platformHooks` και `hooks` καθώς αυτό θα οδηγήσει σε σφάλμα. Οι ακόλουθοι κανόνες ισχύουν για τον καθορισμό της εντολής hook που θα χρησιμοποιηθεί: - Αν υπάρχει το `platformHooks`, θα χρησιμοποιηθεί και οι εντολές για το συμβάν κύκλου ζωής θα επεξεργαστούν. - Αν τόσο το `os` όσο και το `arch` ταιριάζουν με την τρέχουσα πλατφόρμα, η αναζήτηση θα σταματήσει και η εντολή θα χρησιμοποιηθεί. - Αν το `os` ταιριάζει και το `arch` είναι κενό, η εντολή θα χρησιμοποιηθεί. - Αν και το `os` και το `arch` είναι κενά, η εντολή θα χρησιμοποιηθεί. - Αν δεν υπάρχει αντιστοιχία, το Helm θα παραλείψει το συμβάν. - Αν το `platformHooks` δεν υπάρχει και υπάρχει το καταργημένο `hooks`, θα χρησιμοποιηθεί η εντολή για το συμβάν κύκλου ζωής. - Αν η εντολή είναι κενή, το Helm θα παραλείψει το συμβάν. ## Δημιουργία Plugin {#building-a-plugin} Ακολουθεί το αρχείο YAML του plugin για ένα απλό plugin που βοηθά να ληφθεί το όνομα της τελευταίας έκδοσης: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Τα plugins μπορεί να απαιτούν πρόσθετα scripts και εκτελέσιμα. Τα scripts μπορούν να συμπεριληφθούν στον κατάλογο του plugin και τα εκτελέσιμα μπορούν να ληφθούν μέσω ενός hook. Ακολουθεί ένα παράδειγμα plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Οι μεταβλητές περιβάλλοντος αντικαθίστανται πριν από την εκτέλεση του plugin. Το παραπάνω μοτίβο δείχνει τον προτιμώμενο τρόπο για να υποδειχθεί πού βρίσκεται το πρόγραμμα του plugin. ### Εντολές Plugin {#plugin-commands} Υπάρχουν ορισμένες στρατηγικές για την εργασία με εντολές plugin: - Αν ένα plugin περιλαμβάνει ένα εκτελέσιμο, το εκτελέσιμο για το `platformCommand:` πρέπει να είναι πακεταρισμένο στον κατάλογο του plugin ή να εγκαθίσταται μέσω ενός hook. - Η γραμμή `platformCommand:` ή `command:` θα έχει όλες τις μεταβλητές περιβάλλοντος επεκταμένες πριν από την εκτέλεση. Η μεταβλητή `$HELM_PLUGIN_DIR` θα δείχνει στον κατάλογο του plugin. - Η ίδια η εντολή δεν εκτελείται σε shell. Επομένως, δεν μπορείτε να γράψετε ένα shell script σε μία γραμμή. - Το Helm εισάγει πολλές ρυθμίσεις σε μεταβλητές περιβάλλοντος. Εξετάστε το περιβάλλον για να δείτε ποιες πληροφορίες είναι διαθέσιμες. - Το Helm δεν κάνει υποθέσεις για τη γλώσσα του plugin. Μπορείτε να το γράψετε σε ό,τι προτιμάτε. - Οι εντολές είναι υπεύθυνες για την υλοποίηση συγκεκριμένου κειμένου βοήθειας για τις σημαίες `-h` και `--help`. Το Helm θα χρησιμοποιήσει τα πεδία `usage` και `description` για τις εντολές `helm help` και `helm help myplugin`, αλλά δεν θα χειριστεί την εντολή `helm myplugin --help`. ### Δοκιμή ενός Τοπικού Plugin {#testing-a-local-plugin} Αρχικά πρέπει να βρείτε τη διαδρομή `HELM_PLUGINS`. Για να το κάνετε αυτό, εκτελέστε την ακόλουθη εντολή: ``` bash helm env ``` Αλλάξτε τον τρέχοντα κατάλογο στον κατάλογο που έχει οριστεί στο `HELM_PLUGINS`. Τώρα μπορείτε να προσθέσετε έναν συμβολικό σύνδεσμο προς την έξοδο build του plugin σας. Σε αυτό το παράδειγμα το κάνουμε για το `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Plugins Λήψης {#downloader-plugins} Από προεπιλογή, το Helm μπορεί να κατεβάσει Charts χρησιμοποιώντας HTTP/S. Από το Helm 2.4.0, τα plugins μπορούν να έχουν μια ειδική δυνατότητα λήψης Charts από αυθαίρετες πηγές. Τα plugins πρέπει να δηλώσουν αυτή την ειδική δυνατότητα στο αρχείο `plugin.yaml` (στο ανώτατο επίπεδο): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Αν ένα τέτοιο plugin είναι εγκατεστημένο, το Helm μπορεί να αλληλεπιδράσει με το αποθετήριο χρησιμοποιώντας το καθορισμένο σχήμα πρωτοκόλλου καλώντας την εντολή `command`. Το ειδικό αποθετήριο πρέπει να προστεθεί παρόμοια με τα κανονικά: `helm repo add favorite myprotocol://example.com/` Οι κανόνες για τα ειδικά αποθετήρια είναι ίδιοι με τα κανονικά: Το Helm πρέπει να μπορεί να κατεβάσει το αρχείο `index.yaml` για να ανακαλύψει και να αποθηκεύσει προσωρινά τη λίστα των διαθέσιμων Charts. Η καθορισμένη εντολή θα κληθεί με το ακόλουθο σχήμα: `command certFile keyFile caFile full-URL`. Τα διαπιστευτήρια SSL προέρχονται από τον ορισμό του αποθετηρίου, που αποθηκεύεται στο `$HELM_REPOSITORY_CONFIG` (δηλαδή `$HELM_CONFIG_HOME/repositories.yaml`). Ένα plugin λήψης αναμένεται να εκτυπώσει το ακατέργαστο περιεχόμενο στο stdout και να αναφέρει σφάλματα στο stderr. Η εντολή λήψης υποστηρίζει επίσης υποεντολές ή ορίσματα, επιτρέποντάς σας να καθορίσετε για παράδειγμα `bin/mydownloader subcommand -d` στο `plugin.yaml`. Αυτό είναι χρήσιμο αν θέλετε να χρησιμοποιήσετε το ίδιο εκτελέσιμο τόσο για την κύρια εντολή του plugin όσο και για την εντολή λήψης, αλλά με διαφορετική υποεντολή για κάθε μία. ## Μεταβλητές Περιβάλλοντος {#environment-variables} Όταν το Helm εκτελεί ένα plugin, περνάει το εξωτερικό περιβάλλον στο plugin, και επίσης εισάγει ορισμένες πρόσθετες μεταβλητές περιβάλλοντος. Μεταβλητές όπως η `KUBECONFIG` ορίζονται για το plugin αν έχουν οριστεί στο εξωτερικό περιβάλλον. Οι ακόλουθες μεταβλητές είναι εγγυημένο ότι θα οριστούν: - `HELM_PLUGINS`: Η διαδρομή προς τον κατάλογο plugins. - `HELM_PLUGIN_NAME`: Το όνομα του plugin, όπως κλήθηκε από το `helm`. Έτσι η εντολή `helm myplug` θα έχει το σύντομο όνομα `myplug`. - `HELM_PLUGIN_DIR`: Ο κατάλογος που περιέχει το plugin. - `HELM_BIN`: Η διαδρομή προς την εντολή `helm` (όπως εκτελέστηκε από τον χρήστη). - `HELM_DEBUG`: Υποδεικνύει αν η σημαία debug ήταν ενεργοποιημένη από το helm. - `HELM_REGISTRY_CONFIG`: Η τοποθεσία για τη ρύθμιση του registry (αν χρησιμοποιείται). Σημειώστε ότι η χρήση του Helm με registries είναι μια πειραματική λειτουργία. - `HELM_REPOSITORY_CACHE`: Η διαδρομή προς τα αρχεία προσωρινής μνήμης του αποθετηρίου. - `HELM_REPOSITORY_CONFIG`: Η διαδρομή προς το αρχείο ρύθμισης του αποθετηρίου. - `HELM_NAMESPACE`: Το namespace που δόθηκε στην εντολή `helm` (συνήθως χρησιμοποιώντας τη σημαία `-n`). - `HELM_KUBECONTEXT`: Το όνομα του Kubernetes config context που δόθηκε στην εντολή `helm`. Επιπλέον, αν ένα αρχείο ρύθμισης Kubernetes καθορίστηκε ρητά, θα οριστεί ως μεταβλητή `KUBECONFIG`. ## Σημείωση για την Ανάλυση Σημαιών {#a-note-on-flag-parsing} Όταν εκτελείται ένα plugin, το Helm αναλύει τις καθολικές σημαίες για δική του χρήση. Καμία από αυτές τις σημαίες δεν περνάει στο plugin. - `--burst-limit`: Μετατρέπεται σε `$HELM_BURST_LIMIT` - `--debug`: Αν καθοριστεί, η `$HELM_DEBUG` ορίζεται σε `1` - `--kube-apiserver`: Μετατρέπεται σε `$HELM_KUBEAPISERVER` - `--kube-as-group`: Μετατρέπονται σε `$HELM_KUBEASGROUPS` - `--kube-as-user`: Μετατρέπεται σε `$HELM_KUBEASUSER` - `--kube-ca-file`: Μετατρέπεται σε `$HELM_KUBECAFILE` - `--kube-context`: Μετατρέπεται σε `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: Μετατρέπεται σε `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: Μετατρέπεται σε `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: Μετατρέπεται σε `$HELM_KUBETOKEN` - `--kubeconfig`: Μετατρέπεται σε `$KUBECONFIG` - `--namespace` και `-n`: Μετατρέπεται σε `$HELM_NAMESPACE` - `--qps`: Μετατρέπεται σε `$HELM_QPS` - `--registry-config`: Μετατρέπεται σε `$HELM_REGISTRY_CONFIG` - `--repository-cache`: Μετατρέπεται σε `$HELM_REPOSITORY_CACHE` - `--repository-config`: Μετατρέπεται σε `$HELM_REPOSITORY_CONFIG` Τα plugins _πρέπει_ να εμφανίζουν κείμενο βοήθειας και στη συνέχεια να τερματίζουν για τις σημαίες `-h` και `--help`. Σε όλες τις άλλες περιπτώσεις, τα plugins μπορούν να χρησιμοποιούν σημαίες όπως κρίνουν κατάλληλο. ## Παροχή Αυτόματης Συμπλήρωσης Shell {#providing-shell-auto-completion} Από το Helm 3.2, ένα plugin μπορεί προαιρετικά να παρέχει υποστήριξη για αυτόματη συμπλήρωση shell ως μέρος του υπάρχοντος μηχανισμού αυτόματης συμπλήρωσης του Helm. ### Στατική Αυτόματη Συμπλήρωση {#static-auto-completion} Αν ένα plugin παρέχει τις δικές του σημαίες ή/και υποεντολές, μπορεί να ενημερώσει το Helm γι' αυτές έχοντας ένα αρχείο `completion.yaml` στον ριζικό κατάλογο του plugin. Το αρχείο `completion.yaml` έχει την ακόλουθη μορφή: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Σημειώσεις: 1. Όλες οι ενότητες είναι προαιρετικές αλλά πρέπει να παρέχονται αν ισχύουν. 1. Οι σημαίες δεν πρέπει να περιλαμβάνουν το πρόθεμα `-` ή `--`. 1. Τόσο οι σύντομες όσο και οι μακριές σημαίες μπορούν και πρέπει να καθοριστούν. Μια σύντομη σημαία δεν χρειάζεται να συσχετιστεί με την αντίστοιχη μακριά μορφή της, αλλά και οι δύο μορφές πρέπει να αναφέρονται. 1. Οι σημαίες δεν χρειάζεται να είναι ταξινομημένες με συγκεκριμένο τρόπο, αλλά πρέπει να αναφέρονται στο σωστό σημείο στην ιεραρχία υποεντολών του αρχείου. 1. Οι υπάρχουσες καθολικές σημαίες του Helm διαχειρίζονται ήδη από τον μηχανισμό αυτόματης συμπλήρωσης του Helm, επομένως τα plugins δεν χρειάζεται να καθορίσουν τις ακόλουθες σημαίες: `--debug`, `--namespace` ή `-n`, `--kube-context` και `--kubeconfig`, ή οποιαδήποτε άλλη καθολική σημαία. 1. Η λίστα `validArgs` παρέχει μια στατική λίστα πιθανών συμπληρώσεων για την πρώτη παράμετρο μετά από μια υποεντολή. Δεν είναι πάντα δυνατό να παρασχεθεί μια τέτοια λίστα εκ των προτέρων (δείτε την ενότητα [Δυναμική Συμπλήρωση](#dynamic-completion) παρακάτω), οπότε η ενότητα `validArgs` μπορεί να παραλειφθεί. Το αρχείο `completion.yaml` είναι εντελώς προαιρετικό. Αν δεν παρέχεται, το Helm απλώς δεν θα παρέχει αυτόματη συμπλήρωση shell για το plugin (εκτός αν υποστηρίζεται [Δυναμική Συμπλήρωση](#dynamic-completion) από το plugin). Επίσης, η προσθήκη ενός αρχείου `completion.yaml` είναι συμβατή προς τα πίσω και δεν θα επηρεάσει τη συμπεριφορά του plugin σε παλαιότερες εκδόσεις του Helm. Ως παράδειγμα, για το [`fullstatus plugin`](https://github.com/marckhouzam/helm-fullstatus) που δεν έχει υποεντολές αλλά δέχεται τις ίδιες σημαίες με την εντολή `helm status`, το αρχείο `completion.yaml` είναι: ```yaml name: fullstatus flags: - o - output - revision ``` Ένα πιο περίπλοκο παράδειγμα για το [`2to3 plugin`](https://github.com/helm/helm-2to3), έχει ένα αρχείο `completion.yaml`: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Δυναμική Συμπλήρωση {#dynamic-completion} Επίσης από το Helm 3.2, τα plugins μπορούν να παρέχουν τη δική τους δυναμική αυτόματη συμπλήρωση shell. Η δυναμική αυτόματη συμπλήρωση shell είναι η συμπλήρωση τιμών παραμέτρων ή σημαιών που δεν μπορούν να οριστούν εκ των προτέρων. Για παράδειγμα, η συμπλήρωση ονομάτων helm releases που είναι διαθέσιμα αυτή τη στιγμή στο cluster. Για να υποστηρίξει το plugin τη δυναμική αυτόματη συμπλήρωση, πρέπει να παρέχει ένα **εκτελέσιμο** αρχείο με όνομα `plugin.complete` στον ριζικό του κατάλογο. Όταν το script συμπλήρωσης του Helm απαιτεί δυναμικές συμπληρώσεις για το plugin, θα εκτελέσει το αρχείο `plugin.complete`, περνώντας του τη γραμμή εντολών που χρειάζεται συμπλήρωση. Το εκτελέσιμο `plugin.complete` θα πρέπει να έχει τη λογική για να καθορίσει ποιες είναι οι κατάλληλες επιλογές συμπλήρωσης και να τις εξάγει στην τυπική έξοδο για να καταναλωθούν από το script συμπλήρωσης του Helm. Το αρχείο `plugin.complete` είναι εντελώς προαιρετικό. Αν δεν παρέχεται, το Helm απλώς δεν θα παρέχει δυναμική αυτόματη συμπλήρωση για το plugin. Επίσης, η προσθήκη ενός αρχείου `plugin.complete` είναι συμβατή προς τα πίσω και δεν θα επηρεάσει τη συμπεριφορά του plugin σε παλαιότερες εκδόσεις του Helm. Η έξοδος του script `plugin.complete` πρέπει να είναι μια λίστα διαχωρισμένη με νέες γραμμές, όπως: ```console rel1 rel2 rel3 ``` Όταν καλείται το `plugin.complete`, το περιβάλλον του plugin ορίζεται όπως όταν καλείται το κύριο script του plugin. Επομένως, οι μεταβλητές `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` και όλες οι άλλες μεταβλητές plugin θα έχουν ήδη οριστεί, και οι αντίστοιχες καθολικές σημαίες τους θα έχουν αφαιρεθεί. Το αρχείο `plugin.complete` μπορεί να είναι σε οποιαδήποτε εκτελέσιμη μορφή· μπορεί να είναι ένα shell script, ένα πρόγραμμα Go ή οποιοδήποτε άλλο είδος προγράμματος που μπορεί να εκτελέσει το Helm. Το αρχείο `plugin.complete` ***πρέπει*** να έχει δικαιώματα εκτέλεσης για τον χρήστη. Το αρχείο `plugin.complete` ***πρέπει*** να τερματίζει με κωδικό επιτυχίας (τιμή 0). Σε ορισμένες περιπτώσεις, η δυναμική συμπλήρωση θα απαιτεί τη λήψη πληροφοριών από το Kubernetes cluster. Για παράδειγμα, το plugin `helm fullstatus` απαιτεί ένα όνομα release ως είσοδο. Στο plugin `fullstatus`, για να παρέχει το script `plugin.complete` συμπληρώσεις για τρέχοντα ονόματα release, μπορεί απλώς να εκτελέσει `helm list -q` και να εξάγει το αποτέλεσμα. Αν επιθυμείτε να χρησιμοποιήσετε το ίδιο εκτελέσιμο τόσο για την εκτέλεση του plugin όσο και για τη συμπλήρωση του plugin, το script `plugin.complete` μπορεί να κάνει κλήση στο κύριο εκτελέσιμο του plugin με κάποια ειδική παράμετρο ή σημαία· όταν το κύριο εκτελέσιμο του plugin ανιχνεύσει την ειδική παράμετρο ή σημαία, θα γνωρίζει ότι πρέπει να εκτελέσει τη συμπλήρωση. Στο παράδειγμά μας, το `plugin.complete` θα μπορούσε να υλοποιηθεί ως εξής: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. {#is-the-entire-command-line-that-requires-completion} # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. {#it-is-important-to-double-quote-the-variable-to-preserve-a-possibly-empty-last-parameter} $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Το πραγματικό script του plugin `fullstatus` (`status.sh`) πρέπει τότε να αναζητήσει τη σημαία `--complete` και αν βρεθεί, να εκτυπώσει τις κατάλληλες συμπληρώσεις. ### Συμβουλές και Κόλπα {#tips-and-tricks} 1. Το shell θα φιλτράρει αυτόματα τις επιλογές συμπλήρωσης που δεν ταιριάζουν με την είσοδο του χρήστη. Ένα plugin μπορεί επομένως να επιστρέφει όλες τις σχετικές συμπληρώσεις χωρίς να αφαιρεί αυτές που δεν ταιριάζουν με την είσοδο του χρήστη. Για παράδειγμα, αν η γραμμή εντολών είναι `helm fullstatus ngin`, το script `plugin.complete` μπορεί να εκτυπώσει *όλα* τα ονόματα release (του namespace `default`), όχι μόνο αυτά που αρχίζουν με `ngin`· το shell θα διατηρήσει μόνο αυτά που αρχίζουν με `ngin`. 1. Για να απλοποιήσετε την υποστήριξη δυναμικής συμπλήρωσης, ειδικά αν έχετε ένα πολύπλοκο plugin, μπορείτε να κάνετε το script `plugin.complete` να καλέσει το κύριο script του plugin σας και να ζητήσει επιλογές συμπλήρωσης. Δείτε την ενότητα [Δυναμική Συμπλήρωση](#dynamic-completion) παραπάνω για ένα παράδειγμα. 1. Για να αποσφαλματώσετε τη δυναμική συμπλήρωση και το αρχείο `plugin.complete`, μπορείτε να εκτελέσετε τα ακόλουθα για να δείτε τα αποτελέσματα συμπλήρωσης: - `helm __complete `. Για παράδειγμα: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Προέλευση και Ακεραιότητα Helm description: Περιγράφει πώς να επαληθεύσετε την ακεραιότητα και την προέλευση ενός Chart. sidebar_position: 5 --- Το Helm διαθέτει εργαλεία προέλευσης που βοηθούν τους χρήστες chart να επαληθεύσουν την ακεραιότητα και την προέλευση ενός πακέτου. Χρησιμοποιώντας εργαλεία βασισμένα σε βιομηχανικά πρότυπα, σε PKI, GnuPG και σεβαστούς διαχειριστές πακέτων, το Helm μπορεί να δημιουργήσει και να επαληθεύσει αρχεία υπογραφής. ## Επισκόπηση {#overview} Η ακεραιότητα καθορίζεται συγκρίνοντας ένα chart με μια εγγραφή προέλευσης. Οι εγγραφές προέλευσης αποθηκεύονται σε _αρχεία προέλευσης_, τα οποία αποθηκεύονται μαζί με το πακεταρισμένο chart. Για παράδειγμα, αν ένα chart ονομάζεται `myapp-1.2.3.tgz`, το αρχείο προέλευσής του θα είναι `myapp-1.2.3.tgz.prov`. Τα αρχεία προέλευσης δημιουργούνται κατά τη διαδικασία πακεταρίσματος (`helm package --sign ...`) και μπορούν να ελεγχθούν από πολλές εντολές, κυρίως την `helm install --verify`. ## Η Ροή Εργασίας {#the-workflow} Αυτή η ενότητα περιγράφει μια πιθανή ροή εργασίας για την αποτελεσματική χρήση δεδομένων προέλευσης. Προαπαιτούμενα: - Ένα έγκυρο ζεύγος κλειδιών PGP σε δυαδική μορφή (όχι ASCII-armored) - Το εργαλείο γραμμής εντολών `helm` - Εργαλεία γραμμής εντολών GnuPG (προαιρετικά) - Εργαλεία γραμμής εντολών Keybase (προαιρετικά) **ΣΗΜΕΙΩΣΗ:** Αν το ιδιωτικό κλειδί PGP σας έχει κωδικό πρόσβασης, θα σας ζητηθεί να τον εισάγετε για οποιαδήποτε εντολή υποστηρίζει την επιλογή `--sign`. Η δημιουργία ενός νέου chart είναι ίδια με πριν: ```console $ helm create mychart Creating mychart ``` Όταν είστε έτοιμοι για πακετάρισμα, προσθέστε τη σημαία `--sign` στην εντολή `helm package`. Επίσης, καθορίστε το όνομα με το οποίο είναι γνωστό το κλειδί υπογραφής και το keyring που περιέχει το αντίστοιχο ιδιωτικό κλειδί: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Σημείωση:** Η τιμή του ορίσματος `--key` πρέπει να είναι ένα υποσύνολο του `uid` του επιθυμητού κλειδιού (στην έξοδο της `gpg --list-keys`), για παράδειγμα το όνομα ή το email. **Το αποτύπωμα _δεν_ μπορεί να χρησιμοποιηθεί.** **ΣΥΜΒΟΥΛΗ:** Για χρήστες GnuPG, το μυστικό keyring σας βρίσκεται στο `~/.gnupg/secring.gpg`. Μπορείτε να χρησιμοποιήσετε την εντολή `gpg --list-secret-keys` για να δείτε τα κλειδιά που διαθέτετε. **Προειδοποίηση:** Το GnuPG v2 αποθηκεύει το μυστικό keyring σας χρησιμοποιώντας τη νέα μορφή `kbx` στην προεπιλεγμένη τοποθεσία `~/.gnupg/pubring.kbx`. Χρησιμοποιήστε την ακόλουθη εντολή για να μετατρέψετε το keyring σας στην παλαιότερη μορφή gpg: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` Τώρα θα πρέπει να βλέπετε και τα δύο αρχεία `mychart-0.1.0.tgz` και `mychart-0.1.0.tgz.prov`. Και τα δύο αρχεία θα πρέπει τελικά να μεταφορτωθούν στο επιθυμητό αποθετήριο chart. Μπορείτε να επαληθεύσετε ένα chart χρησιμοποιώντας `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Μια αποτυχημένη επαλήθευση έχει την εξής μορφή: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Για να επαληθεύσετε κατά την εγκατάσταση, χρησιμοποιήστε τη σημαία `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Αν το keyring που περιέχει το δημόσιο κλειδί σχετιζόμενο με το υπογεγραμμένο chart δεν βρίσκεται στην προεπιλεγμένη τοποθεσία, ίσως χρειαστεί να υποδείξετε το keyring με `--keyring PATH` όπως στο παράδειγμα της `helm package`. Αν η επαλήθευση αποτύχει, η εγκατάσταση θα ακυρωθεί πριν καν αποδοθεί το chart. ### Χρήση διαπιστευτηρίων Keybase.io {#using-keybaseio-credentials} Η υπηρεσία [Keybase.io](https://keybase.io) διευκολύνει τη δημιουργία μιας αλυσίδας εμπιστοσύνης για μια κρυπτογραφική ταυτότητα. Τα διαπιστευτήρια Keybase μπορούν να χρησιμοποιηθούν για την υπογραφή charts. Προαπαιτούμενα: - Ένας διαμορφωμένος λογαριασμός Keybase.io - Εγκατεστημένο τοπικά το GnuPG - Εγκατεστημένο τοπικά το `keybase` CLI #### Υπογραφή πακέτων {#signing-packages} Το πρώτο βήμα είναι να εισάγετε τα κλειδιά Keybase στο τοπικό σας GnuPG keyring: ```console $ keybase pgp export -s | gpg --import ``` Αυτό θα μετατρέψει το κλειδί Keybase σας σε μορφή OpenPGP και στη συνέχεια θα το εισάγει τοπικά στο αρχείο `~/.gnupg/secring.gpg`. Μπορείτε να επαληθεύσετε εκτελώντας `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Σημειώστε ότι το μυστικό κλειδί σας θα έχει μια συμβολοσειρά αναγνώρισης: ``` technosophos (keybase.io/technosophos) ``` Αυτό είναι το πλήρες όνομα του κλειδιού σας. Στη συνέχεια, μπορείτε να πακετάρετε και να υπογράψετε ένα chart με `helm package`. Βεβαιωθείτε ότι χρησιμοποιείτε τουλάχιστον μέρος αυτής της συμβολοσειράς ονόματος στο `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Ως αποτέλεσμα, η εντολή `package` θα παράγει και ένα αρχείο `.tgz` και ένα αρχείο `.tgz.prov`. #### Επαλήθευση πακέτων {#verifying-packages} Μπορείτε επίσης να χρησιμοποιήσετε παρόμοια τεχνική για να επαληθεύσετε ένα chart που έχει υπογραφεί από το κλειδί Keybase κάποιου άλλου. Ας πούμε ότι θέλετε να επαληθεύσετε ένα πακέτο υπογεγραμμένο από τον `keybase.io/technosophos`. Για να το κάνετε αυτό, χρησιμοποιήστε το εργαλείο `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` Η πρώτη εντολή παραπάνω ακολουθεί τον χρήστη `technosophos`. Στη συνέχεια, η `keybase pgp pull` κατεβάζει τα κλειδιά OpenPGP όλων των λογαριασμών που ακολουθείτε, τοποθετώντας τα στο GnuPG keyring σας (`~/.gnupg/pubring.gpg`). Τώρα μπορείτε να χρησιμοποιήσετε `helm verify` ή οποιαδήποτε εντολή με τη σημαία `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Λόγοι που ένα chart μπορεί να μην επαληθευτεί {#reasons-a-chart-may-not-verify} Αυτοί είναι συνήθεις λόγοι αποτυχίας. - Το αρχείο `.prov` λείπει ή είναι κατεστραμμένο. Αυτό υποδηλώνει ότι κάτι έχει ρυθμιστεί λανθασμένα ή ότι ο αρχικός συντηρητής δεν δημιούργησε αρχείο προέλευσης. - Το κλειδί που χρησιμοποιήθηκε για την υπογραφή του αρχείου δεν βρίσκεται στο keyring σας. Αυτό υποδηλώνει ότι η οντότητα που υπέγραψε το chart δεν είναι κάποιος που έχετε ήδη υποδείξει ότι εμπιστεύεστε. - Η επαλήθευση του αρχείου `.prov` απέτυχε. Αυτό υποδηλώνει ότι κάτι δεν πάει καλά είτε με το chart είτε με τα δεδομένα προέλευσης. - Τα hash αρχείων στο αρχείο προέλευσης δεν ταιριάζουν με το hash του αρχείου αρχειοθήκης. Αυτό υποδηλώνει ότι η αρχειοθήκη έχει παραποιηθεί. Αν μια επαλήθευση αποτύχει, υπάρχει λόγος να μην εμπιστεύεστε το πακέτο. ## Το Αρχείο Προέλευσης {#the-provenance-file} Το αρχείο προέλευσης περιέχει το αρχείο YAML του chart μαζί με αρκετές πληροφορίες επαλήθευσης. Τα αρχεία προέλευσης είναι σχεδιασμένα να δημιουργούνται αυτόματα. Προστίθενται τα ακόλουθα δεδομένα προέλευσης: * Το αρχείο chart (`Chart.yaml`) περιλαμβάνεται για να δώσει τόσο στους ανθρώπους όσο και στα εργαλεία μια εύκολη προβολή στα περιεχόμενα του chart. * Η υπογραφή (SHA256, όπως στο Docker) του πακέτου chart (το αρχείο `.tgz`) περιλαμβάνεται και μπορεί να χρησιμοποιηθεί για την επαλήθευση της ακεραιότητας του πακέτου chart. * Ολόκληρο το σώμα υπογράφεται χρησιμοποιώντας τον αλγόριθμο που χρησιμοποιεί το OpenPGP (δείτε το [Keybase.io](https://keybase.io) για έναν αναδυόμενο τρόπο που κάνει την κρυπτογραφική υπογραφή και επαλήθευση εύκολη). Ο συνδυασμός αυτών δίνει στους χρήστες τις ακόλουθες εγγυήσεις: * Το ίδιο το πακέτο δεν έχει παραποιηθεί (checksum πακέτου `.tgz`). * Η οντότητα που κυκλοφόρησε αυτό το πακέτο είναι γνωστή (μέσω της υπογραφής GnuPG/PGP). Η μορφή του αρχείου είναι η ακόλουθη: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Σημειώστε ότι η ενότητα YAML περιέχει δύο έγγραφα (χωρισμένα με `...\n`). Το πρώτο αρχείο είναι το περιεχόμενο του `Chart.yaml`. Το δεύτερο είναι τα checksums, μια αντιστοίχιση ονομάτων αρχείων σε SHA-256 digests του περιεχομένου κάθε αρχείου κατά τη στιγμή του πακεταρίσματος. Το μπλοκ υπογραφής είναι μια τυπική υπογραφή PGP, η οποία παρέχει [αντίσταση σε παραποίηση](https://www.rossde.com/PGP/pgp_signatures.html). ## Αποθετήρια Chart {#chart-repositories} Τα αποθετήρια chart λειτουργούν ως κεντρική συλλογή Helm charts. Τα αποθετήρια chart πρέπει να μπορούν να εξυπηρετούν αρχεία προέλευσης μέσω HTTP με συγκεκριμένο αίτημα, και πρέπει να τα καθιστούν διαθέσιμα στην ίδια διαδρομή URI με το chart. Για παράδειγμα, αν η βασική διεύθυνση URL για ένα πακέτο είναι `https://example.com/charts/mychart-1.2.3.tgz`, το αρχείο προέλευσης, αν υπάρχει, ΠΡΕΠΕΙ να είναι προσβάσιμο στη διεύθυνση `https://example.com/charts/mychart-1.2.3.tgz.prov`. Από την πλευρά του τελικού χρήστη, η εντολή `helm install --verify myrepo/mychart-1.2.3` θα πρέπει να κατεβάζει τόσο το chart όσο και το αρχείο προέλευσης χωρίς επιπλέον διαμόρφωση ή ενέργεια από τον χρήστη. ### Υπογραφές σε αποθετήρια βασισμένα σε OCI {#signatures-in-oci-based-registries} Κατά τη δημοσίευση charts σε ένα [αποθετήριο βασισμένο σε OCI](/topics/registries.md), το plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore/) μπορεί να χρησιμοποιηθεί για τη δημοσίευση προέλευσης στο [sigstore](https://sigstore.dev/). [Όπως περιγράφεται στην τεκμηρίωση](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), η διαδικασία δημιουργίας προέλευσης και υπογραφής με κλειδί GPG είναι κοινές, αλλά η εντολή `helm sigstore upload` μπορεί να χρησιμοποιηθεί για τη δημοσίευση της προέλευσης σε ένα αμετάβλητο αρχείο καταγραφής διαφάνειας. ## Καθιέρωση Αρχής και Αυθεντικότητας {#establishing-authority-and-authenticity} Όταν ασχολούμαστε με συστήματα αλυσίδας εμπιστοσύνης, είναι σημαντικό να μπορούμε να καθιερώσουμε την αρχή ενός υπογράφοντα. Ή, για να το θέσουμε απλά, το παραπάνω σύστημα βασίζεται στο γεγονός ότι εμπιστεύεστε το άτομο που υπέγραψε το chart. Αυτό, με τη σειρά του, σημαίνει ότι πρέπει να εμπιστεύεστε το δημόσιο κλειδί του υπογράφοντα. Μία από τις σχεδιαστικές αποφάσεις του Helm ήταν να μην εισαχθεί το ίδιο το Helm project στην αλυσίδα εμπιστοσύνης ως απαραίτητο μέρος. Δεν θέλουμε να είμαστε "η αρχή πιστοποίησης" για όλους τους υπογράφοντες chart. Αντίθετα, προτιμούμε έντονα ένα αποκεντρωμένο μοντέλο, που είναι μέρος του λόγου που επιλέξαμε το OpenPGP ως θεμελιώδη τεχνολογία μας. Έτσι, όσον αφορά την καθιέρωση αρχής, αφήσαμε αυτό το βήμα ως ανοικτό ζήτημα στο Helm 2 (μια απόφαση που συνεχίστηκε στο Helm 3). Ωστόσο, έχουμε μερικές υποδείξεις και συστάσεις για όσους ενδιαφέρονται να χρησιμοποιήσουν το σύστημα προέλευσης: - Η πλατφόρμα [Keybase](https://keybase.io) παρέχει ένα δημόσιο κεντρικό αποθετήριο για πληροφορίες εμπιστοσύνης. - Μπορείτε να χρησιμοποιήσετε το Keybase για να αποθηκεύσετε τα κλειδιά σας ή να λάβετε τα δημόσια κλειδιά άλλων. - Το Keybase διαθέτει επίσης εξαιρετική τεκμηρίωση - Αν και δεν το έχουμε δοκιμάσει, η λειτουργία "secure website" του Keybase θα μπορούσε να χρησιμοποιηθεί για την εξυπηρέτηση Helm charts. - Η βασική ιδέα είναι ότι ένας επίσημος "αξιολογητής chart" υπογράφει charts με το κλειδί του/της, και το αρχείο προέλευσης που προκύπτει μεταφορτώνεται στη συνέχεια στο αποθετήριο chart. - Έχει γίνει κάποια δουλειά στην ιδέα ότι μια λίστα έγκυρων κλειδιών υπογραφής μπορεί να συμπεριληφθεί στο αρχείο `index.yaml` ενός αποθετηρίου. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους description: Εξηγεί πώς το Helm αλληλεπιδρά με τον Έλεγχο Πρόσβασης Βασισμένο σε Ρόλους (RBAC) του Kubernetes. sidebar_position: 11 --- Στο Kubernetes, η εκχώρηση ρόλων σε έναν χρήστη ή σε ένα service account της εφαρμογής σας αποτελεί βέλτιστη πρακτική για να διασφαλίσετε ότι η εφαρμογή σας λειτουργεί εντός του πεδίου που έχετε ορίσει. Διαβάστε περισσότερα σχετικά με τα δικαιώματα service account [στην επίσημη τεκμηρίωση του Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). Από το Kubernetes 1.6 και μετά, ο Έλεγχος Πρόσβασης Βασισμένος σε Ρόλους είναι ενεργοποιημένος από προεπιλογή. Το RBAC σας επιτρέπει να καθορίσετε ποιοι τύποι ενεργειών επιτρέπονται ανάλογα με τον χρήστη και τον ρόλο του στον οργανισμό σας. Με το RBAC, μπορείτε να: - εκχωρήσετε προνομιούχες λειτουργίες (δημιουργία πόρων σε επίπεδο cluster, όπως νέοι ρόλοι) σε διαχειριστές - περιορίσετε τη δυνατότητα ενός χρήστη να δημιουργεί πόρους (pods, persistent volumes, deployments) σε συγκεκριμένα namespaces ή σε επίπεδο cluster (resource quotas, roles, custom resource definitions) - περιορίσετε τη δυνατότητα ενός χρήστη να βλέπει πόρους είτε σε συγκεκριμένα namespaces είτε σε επίπεδο cluster. Αυτός ο οδηγός είναι για διαχειριστές που θέλουν να περιορίσουν το πεδίο αλληλεπίδρασης ενός χρήστη με το Kubernetes API. ## Διαχείριση λογαριασμών χρηστών {#managing-user-accounts} Όλα τα clusters του Kubernetes έχουν δύο κατηγορίες χρηστών: service accounts που διαχειρίζεται το Kubernetes και κανονικούς χρήστες. Οι κανονικοί χρήστες θεωρείται ότι διαχειρίζονται από μια εξωτερική, ανεξάρτητη υπηρεσία. Μπορεί να είναι ένας διαχειριστής που διανέμει ιδιωτικά κλειδιά, ένα σύστημα αποθήκευσης χρηστών όπως το Keystone ή τα Google Accounts, ακόμα και ένα αρχείο με λίστα ονομάτων χρηστών και κωδικών πρόσβασης. Σε αυτό το πλαίσιο, το Kubernetes δεν διαθέτει αντικείμενα που αντιπροσωπεύουν λογαριασμούς κανονικών χρηστών. Οι κανονικοί χρήστες δεν μπορούν να προστεθούν σε ένα cluster μέσω κλήσης API. Αντίθετα, τα service accounts είναι χρήστες που διαχειρίζεται το Kubernetes API. Είναι δεσμευμένα σε συγκεκριμένα namespaces και δημιουργούνται αυτόματα από τον API server ή χειροκίνητα μέσω κλήσεων API. Τα service accounts συνδέονται με ένα σύνολο διαπιστευτηρίων που αποθηκεύονται ως Secrets, τα οποία προσαρτώνται σε pods επιτρέποντας στις διεργασίες εντός του cluster να επικοινωνούν με το Kubernetes API. Τα αιτήματα API συνδέονται είτε με έναν κανονικό χρήστη είτε με ένα service account, ή αντιμετωπίζονται ως ανώνυμα αιτήματα. Αυτό σημαίνει ότι κάθε διεργασία εντός ή εκτός του cluster, από έναν χρήστη που πληκτρολογεί `kubectl` σε έναν σταθμό εργασίας, μέχρι τα kubelets στους κόμβους, μέχρι τα μέλη του control plane, πρέπει να πιστοποιηθεί όταν κάνει αιτήματα στον API server, ή θα αντιμετωπιστεί ως ανώνυμος χρήστης. ## Roles, ClusterRoles, RoleBindings και ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings} Στο Kubernetes, οι λογαριασμοί χρηστών και τα service accounts μπορούν να βλέπουν και να επεξεργάζονται μόνο πόρους στους οποίους τους έχει εκχωρηθεί πρόσβαση. Αυτή η πρόσβαση εκχωρείται μέσω της χρήσης Roles και RoleBindings. Τα Roles και τα RoleBindings είναι δεσμευμένα σε ένα συγκεκριμένο namespace, το οποίο παρέχει στους χρήστες τη δυνατότητα να βλέπουν ή/και να επεξεργάζονται πόρους εντός αυτού του namespace στο οποίο το Role τους παρέχει πρόσβαση. Σε επίπεδο cluster, αυτά ονομάζονται ClusterRoles και ClusterRoleBindings. Η εκχώρηση ενός ClusterRole σε έναν χρήστη του παρέχει πρόσβαση για προβολή ή/και επεξεργασία πόρων σε ολόκληρο το cluster. Απαιτείται επίσης για την προβολή ή/και επεξεργασία πόρων σε επίπεδο cluster (namespaces, resource quotas, nodes). Τα ClusterRoles μπορούν να δεσμευτούν σε ένα συγκεκριμένο namespace μέσω αναφοράς σε ένα RoleBinding. Τα προεπιλεγμένα ClusterRoles `admin`, `edit` και `view` χρησιμοποιούνται συχνά με αυτόν τον τρόπο. Υπάρχουν μερικά ClusterRoles διαθέσιμα από προεπιλογή στο Kubernetes. Προορίζονται ως ρόλοι για τους χρήστες. Περιλαμβάνουν ρόλους υπερχρήστη (`cluster-admin`) και ρόλους με πιο λεπτομερή πρόσβαση (`admin`, `edit`, `view`). | Προεπιλεγμένο ClusterRole | Προεπιλεγμένο ClusterRoleBinding | Περιγραφή |---------------------------|----------------------------------|------------ | `cluster-admin` | ομάδα `system:masters` | Επιτρέπει πρόσβαση υπερχρήστη για εκτέλεση οποιασδήποτε ενέργειας σε οποιονδήποτε πόρο. Όταν χρησιμοποιείται σε ένα ClusterRoleBinding, παρέχει πλήρη έλεγχο σε κάθε πόρο του cluster και σε όλα τα namespaces. Όταν χρησιμοποιείται σε ένα RoleBinding, παρέχει πλήρη έλεγχο σε κάθε πόρο του namespace του rolebinding, συμπεριλαμβανομένου του ίδιου του namespace. | `admin` | Κανένα | Επιτρέπει πρόσβαση διαχειριστή, προορίζεται να εκχωρηθεί εντός ενός namespace χρησιμοποιώντας ένα RoleBinding. Αν χρησιμοποιηθεί σε ένα RoleBinding, επιτρέπει πρόσβαση ανάγνωσης/εγγραφής στους περισσότερους πόρους ενός namespace, συμπεριλαμβανομένης της δυνατότητας δημιουργίας roles και rolebindings εντός του namespace. Δεν επιτρέπει πρόσβαση εγγραφής στα resource quotas ή στο ίδιο το namespace. | `edit` | Κανένα | Επιτρέπει πρόσβαση ανάγνωσης/εγγραφής στους περισσότερους πόρους ενός namespace. Δεν επιτρέπει την προβολή ή τροποποίηση roles ή rolebindings. | `view` | Κανένα | Επιτρέπει πρόσβαση μόνο για ανάγνωση στους περισσότερους πόρους ενός namespace. Δεν επιτρέπει την προβολή roles ή rolebindings. Δεν επιτρέπει την προβολή secrets, καθώς αυτό θα αποτελούσε κλιμάκωση δικαιωμάτων. ## Περιορισμός πρόσβασης λογαριασμού χρήστη με χρήση RBAC {#restricting-a-user-accounts-access-using-rbac} Τώρα που κατανοούμε τα βασικά του Ελέγχου Πρόσβασης Βασισμένου σε Ρόλους, ας δούμε πώς ένας διαχειριστής μπορεί να περιορίσει το πεδίο πρόσβασης ενός χρήστη. ### Παράδειγμα: Εκχώρηση πρόσβασης ανάγνωσης/εγγραφής σε ένα συγκεκριμένο namespace {#example-grant-a-user-readwrite-access-to-a-particular-namespace} Για να περιορίσετε την πρόσβαση ενός χρήστη σε ένα συγκεκριμένο namespace, μπορείτε να χρησιμοποιήσετε είτε τον ρόλο `edit` είτε τον ρόλο `admin`. Αν τα charts σας δημιουργούν ή αλληλεπιδρούν με Roles και Rolebindings, θα θέλετε να χρησιμοποιήσετε το ClusterRole `admin`. Επιπλέον, μπορείτε επίσης να δημιουργήσετε ένα RoleBinding με πρόσβαση `cluster-admin`. Η εκχώρηση πρόσβασης `cluster-admin` σε έναν χρήστη σε επίπεδο namespace παρέχει πλήρη έλεγχο σε κάθε πόρο του namespace, συμπεριλαμβανομένου του ίδιου του namespace. Για αυτό το παράδειγμα, θα δημιουργήσουμε έναν χρήστη με τον ρόλο `edit`. Πρώτα, δημιουργήστε το namespace: ```console $ kubectl create namespace foo ``` Τώρα, δημιουργήστε ένα RoleBinding σε αυτό το namespace, εκχωρώντας στον χρήστη τον ρόλο `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Παράδειγμα: Εκχώρηση πρόσβασης ανάγνωσης/εγγραφής σε επίπεδο cluster {#example-grant-a-user-readwrite-access-at-the-cluster-scope} Αν ένας χρήστης επιθυμεί να εγκαταστήσει ένα chart που εγκαθιστά πόρους σε επίπεδο cluster (namespaces, roles, custom resource definitions, κ.λπ.), θα χρειαστεί πρόσβαση εγγραφής σε επίπεδο cluster. Για να το κάνετε αυτό, εκχωρήστε στον χρήστη πρόσβαση `admin` ή `cluster-admin`. Η εκχώρηση πρόσβασης `cluster-admin` σε έναν χρήστη του παρέχει πρόσβαση σε απολύτως κάθε διαθέσιμο πόρο στο Kubernetes, συμπεριλαμβανομένης της πρόσβασης σε κόμβους με `kubectl drain` και άλλες διαχειριστικές εργασίες. Συνιστάται ιδιαίτερα να εξετάσετε το ενδεχόμενο να παρέχετε στον χρήστη πρόσβαση `admin` αντί αυτού, ή να δημιουργήσετε ένα προσαρμοσμένο ClusterRole προσαρμοσμένο στις ανάγκες του. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Παράδειγμα: Εκχώρηση πρόσβασης μόνο για ανάγνωση σε ένα συγκεκριμένο namespace {#example-grant-a-user-read-only-access-to-a-particular-namespace} Μπορεί να έχετε παρατηρήσει ότι δεν υπάρχει διαθέσιμο ClusterRole για την προβολή secrets. Το ClusterRole `view` δεν παρέχει στον χρήστη πρόσβαση ανάγνωσης στα Secrets λόγω ανησυχιών για κλιμάκωση δικαιωμάτων. Το Helm αποθηκεύει τα μεταδεδομένα των releases ως Secrets από προεπιλογή. Για να μπορέσει ένας χρήστης να εκτελέσει `helm list`, πρέπει να μπορεί να διαβάσει αυτά τα secrets. Για αυτό, θα δημιουργήσουμε ένα ειδικό ClusterRole `secret-reader`. Δημιουργήστε το αρχείο `cluster-role-secret-reader.yaml` και γράψτε το ακόλουθο περιεχόμενο σε αυτό: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Στη συνέχεια, δημιουργήστε το ClusterRole χρησιμοποιώντας: ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Μόλις ολοκληρωθεί αυτό, μπορούμε να εκχωρήσουμε σε έναν χρήστη πρόσβαση ανάγνωσης στους περισσότερους πόρους, και στη συνέχεια να του εκχωρήσουμε πρόσβαση ανάγνωσης στα secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Παράδειγμα: Εκχώρηση πρόσβασης μόνο για ανάγνωση σε επίπεδο cluster {#example-grant-a-user-read-only-access-at-the-cluster-scope} Σε ορισμένα σενάρια, μπορεί να είναι ωφέλιμο να εκχωρηθεί σε έναν χρήστη πρόσβαση σε επίπεδο cluster. Για παράδειγμα, αν ένας χρήστης θέλει να εκτελέσει την εντολή `helm list --all-namespaces`, το API απαιτεί ο χρήστης να έχει πρόσβαση ανάγνωσης σε επίπεδο cluster. Για να το κάνετε αυτό, εκχωρήστε στον χρήστη πρόσβαση τόσο `view` όσο και `secret-reader` όπως περιγράφηκε παραπάνω, αλλά με ένα ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Επιπλέον Σκέψεις {#additional-thoughts} Τα παραπάνω παραδείγματα χρησιμοποιούν τα προεπιλεγμένα ClusterRoles που παρέχει το Kubernetes. Για πιο λεπτομερή έλεγχο των πόρων στους οποίους οι χρήστες έχουν πρόσβαση, ανατρέξτε στην [τεκμηρίωση του Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) για τη δημιουργία προσαρμοσμένων Roles και ClusterRoles. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Χρήση Μητρώων OCI description: Περιγράφει τη χρήση του OCI για τη διανομή Charts. sidebar_position: 7 --- Από το Helm 3, μπορείτε να χρησιμοποιείτε container registries με υποστήριξη [OCI](https://www.opencontainers.org/) για την αποθήκευση και διαμοιρασμό πακέτων chart. Από το Helm v3.8.0, η υποστήριξη OCI είναι ενεργοποιημένη από προεπιλογή. ## Υποστήριξη OCI πριν από την v3.8.0 {#oci-support-prior-to-v380} Η υποστήριξη OCI πέρασε από πειραματικό σε γενικά διαθέσιμο στάδιο με το Helm v3.8.0. Σε προηγούμενες εκδόσεις του Helm, η υποστήριξη OCI λειτουργούσε διαφορετικά. Αν χρησιμοποιούσατε υποστήριξη OCI πριν από το Helm v3.8.0, είναι σημαντικό να κατανοήσετε τι έχει αλλάξει στις διάφορες εκδόσεις του Helm. ### Ενεργοποίηση υποστήριξης OCI πριν από την v3.8.0 {#enabling-oci-support-prior-to-v380} Πριν από το Helm v3.8.0, η υποστήριξη OCI είναι *πειραματική* και πρέπει να ενεργοποιηθεί χειροκίνητα. Για να ενεργοποιήσετε την πειραματική υποστήριξη OCI σε εκδόσεις Helm πριν από την v3.8.0, ορίστε τη μεταβλητή `HELM_EXPERIMENTAL_OCI` στο περιβάλλον σας. Για παράδειγμα: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Απόσυρση λειτουργιών και αλλαγές συμπεριφοράς στην v3.8.0 {#oci-feature-deprecation-and-behavior-changes-with-v380} Με την κυκλοφορία του [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), οι ακόλουθες λειτουργίες και συμπεριφορές διαφέρουν από προηγούμενες εκδόσεις του Helm: - Όταν ορίζετε ένα chart στις εξαρτήσεις ως OCI, η έκδοση μπορεί να οριστεί ως εύρος, όπως και στις υπόλοιπες εξαρτήσεις. - Μπορείτε πλέον να αποστέλλετε και να χρησιμοποιείτε SemVer tags που περιλαμβάνουν πληροφορίες build. Τα OCI registries δεν υποστηρίζουν τον χαρακτήρα `+` στα tags. Το Helm μετατρέπει το `+` σε `_` κατά την αποθήκευση ως tag. - Η εντολή `helm registry login` ακολουθεί πλέον την ίδια δομή με το Docker CLI για την αποθήκευση διαπιστευτηρίων. Μπορείτε να χρησιμοποιήσετε την ίδια τοποθεσία διαμόρφωσης registry τόσο για το Helm όσο και για το Docker CLI. ### Απόσυρση λειτουργιών και αλλαγές συμπεριφοράς στην v3.7.0 {#oci-feature-deprecation-and-behavior-changes-with-v370} Με την κυκλοφορία του [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) υλοποιήθηκε το [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) για την υποστήριξη OCI. Ως αποτέλεσμα, οι ακόλουθες λειτουργίες και συμπεριφορές διαφέρουν από προηγούμενες εκδόσεις του Helm: - Η υποεντολή `helm chart` αφαιρέθηκε. - Η προσωρινή μνήμη (cache) των charts αφαιρέθηκε (δεν υπάρχει πλέον `helm chart list` κτλ.). - Οι αναφορές σε OCI registry ξεκινούν πλέον πάντα με το πρόθεμα `oci://`. - Το basename της αναφοράς στο registry πρέπει *πάντα* να ταιριάζει με το όνομα του chart. - Το tag της αναφοράς στο registry πρέπει *πάντα* να ταιριάζει με τη σημασιολογική έκδοση του chart (δηλαδή δεν επιτρέπονται `latest` tags). - Ο media type του επιπέδου chart άλλαξε από `application/tar+gzip` σε `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Χρήση Μητρώου OCI {#using-an-oci-based-registry} ### Αποθετήρια Helm σε Μητρώα OCI {#helm-repositories-in-oci-based-registries} Ένα [αποθετήριο Helm](/topics/chart_repository.md) είναι ένας τρόπος φιλοξενίας και διανομής πακέτων Helm charts. Ένα μητρώο OCI μπορεί να περιέχει μηδέν ή περισσότερα αποθετήρια Helm, και κάθε αποθετήριο μπορεί να περιέχει μηδέν ή περισσότερα πακέτα Helm charts. ### Χρήση Φιλοξενούμενων Μητρώων {#use-hosted-registries} Υπάρχουν αρκετά φιλοξενούμενα container registries με υποστήριξη OCI που μπορείτε να χρησιμοποιήσετε για τα Helm charts σας. Για παράδειγμα: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Ακολουθήστε την τεκμηρίωση του παρόχου για να δημιουργήσετε και να διαμορφώσετε ένα registry με υποστήριξη OCI. **Σημείωση:** Μπορείτε να εκτελέσετε τοπικά το [Docker Registry](https://docs.docker.com/registry/deploying/) ή το [`zot`](https://github.com/project-zot/zot), που είναι μητρώα OCI, στον υπολογιστή ανάπτυξής σας. Η τοπική εκτέλεση μητρώου OCI πρέπει να χρησιμοποιείται μόνο για δοκιμές. ### Χρήση sigstore για Υπογραφή Charts OCI {#using-sigstore-to-sign-oci-based-charts} Το plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) επιτρέπει τη χρήση του [Sigstore](https://sigstore.dev/) για την υπογραφή Helm charts με τα ίδια εργαλεία που χρησιμοποιούνται για την υπογραφή container images. Αυτό αποτελεί εναλλακτική στην [προέλευση βασισμένη σε GPG](/topics/provenance.md) που υποστηρίζουν τα κλασικά [αποθετήρια chart](/topics/chart_repository.md). Για περισσότερες λεπτομέρειες σχετικά με τη χρήση του plugin `helm sigstore`, ανατρέξτε στην [τεκμηρίωση του έργου](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Εντολές για Εργασία με Μητρώα {#commands-for-working-with-registries} ### Η Υποεντολή `registry` {#the-registry-subcommand} #### `login` {#login} Σύνδεση σε registry (με χειροκίνητη εισαγωγή κωδικού): ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` {#logout} Αποσύνδεση από registry: ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Η Υποεντολή `push` {#the-push-subcommand} Αποστολή chart σε μητρώο OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Η υποεντολή `push` μπορεί να χρησιμοποιηθεί μόνο με αρχεία `.tgz` που έχουν δημιουργηθεί προηγουμένως με το `helm package`. Κατά τη χρήση του `helm push` για αποστολή chart σε OCI registry, η αναφορά πρέπει να ξεκινά με `oci://` και δεν πρέπει να περιέχει το basename ή το tag. Το basename της αναφοράς στο registry εξάγεται από το όνομα του chart, και το tag εξάγεται από τη σημασιολογική έκδοση του chart. Αυτή είναι προς το παρόν αυστηρή απαίτηση. Ορισμένα registries απαιτούν το repository ή/και το namespace (αν υπάρχει) να δημιουργηθεί εκ των προτέρων. Διαφορετικά, θα εμφανιστεί σφάλμα κατά την εκτέλεση του `helm push`. Αν έχετε δημιουργήσει [αρχείο προέλευσης](/topics/provenance.md) (`.prov`) και βρίσκεται δίπλα στο αρχείο `.tgz` του chart, θα αποσταλεί αυτόματα στο registry κατά το `push`. Αυτό προσθέτει ένα επιπλέον επίπεδο στο [manifest του Helm chart](#helm-chart-manifest). Οι χρήστες του [plugin helm-push](https://github.com/chartmuseum/helm-push) (για αποστολή charts στο [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) μπορεί να αντιμετωπίσουν προβλήματα, καθώς το plugin συγκρούεται με τη νέα ενσωματωμένη εντολή `push`. Από την έκδοση v0.10.0, το plugin μετονομάστηκε σε `cm-push`. ### Άλλες Υποεντολές {#other-subcommands} Η υποστήριξη για το πρωτόκολλο `oci://` είναι διαθέσιμη και σε άλλες υποεντολές. Ακολουθεί η πλήρης λίστα: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Το basename (όνομα chart) της αναφοράς στο registry *συμπεριλαμβάνεται* σε κάθε ενέργεια που περιλαμβάνει λήψη chart (σε αντίθεση με το `helm push` όπου παραλείπεται). Ακολουθούν μερικά παραδείγματα χρήσης των παραπάνω υποεντολών με charts OCI: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml {#source-mycharttemplatesserviceaccountyaml} apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Εγκατάσταση Charts με Digest {#installing-charts-with-digest} Η εγκατάσταση chart με digest είναι πιο ασφαλής από τη χρήση tag, επειδή τα digests είναι αμετάβλητα. Το digest καθορίζεται στο URI του chart: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Καθορισμός Εξαρτήσεων {#specifying-dependencies} Μπορείτε να λάβετε εξαρτήσεις ενός chart από registry χρησιμοποιώντας την υποεντολή `dependency update`. Το `repository` για μια καταχώρηση στο `Chart.yaml` καθορίζεται ως η αναφορά στο registry χωρίς το basename: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Αυτό θα ανακτήσει το `oci://localhost:5000/myrepo/mychart:2.7.0` κατά την εκτέλεση του `dependency update`. ## Manifest Helm Chart {#helm-chart-manifest} Παράδειγμα manifest Helm chart όπως αναπαρίσταται σε registry (σημειώστε τα πεδία `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Το ακόλουθο παράδειγμα περιέχει [αρχείο προέλευσης](/topics/provenance.md) (σημειώστε το επιπλέον επίπεδο): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Μετάβαση από Αποθετήρια Chart {#migrating-from-chart-repos} Η μετάβαση από κλασικά [αποθετήρια chart](/topics/chart_repository.md) (αποθετήρια με index.yaml) είναι απλή: χρησιμοποιήστε το `helm pull` για λήψη και στη συνέχεια το `helm push` για αποστολή των αρχείων `.tgz` σε ένα registry. ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Μετάβαση από Helm v2 σε v3 description: Μάθετε πώς να μεταβείτε από το Helm v2 στο v3. sidebar_position: 13 --- Αυτός ο οδηγός δείχνει πώς να μεταβείτε από το Helm v2 στο v3. Το Helm v2 πρέπει να είναι εγκατεστημένο και να διαχειρίζεται releases σε ένα ή περισσότερα clusters. ## Επισκόπηση Αλλαγών στο Helm 3 {#overview-of-helm-3-changes} Η πλήρης λίστα αλλαγών από το Helm 2 στο 3 είναι τεκμηριωμένη στην ενότητα [FAQ](/faq/changes_since_helm2.md). Ακολουθεί μια σύνοψη κάποιων από αυτές τις αλλαγές που ο χρήστης πρέπει να γνωρίζει πριν και κατά τη μετάβαση: 1. Κατάργηση του Tiller: - Αντικατάσταση της αρχιτεκτονικής client/server με αρχιτεκτονική client/library (μόνο το `helm` binary) - Η ασφάλεια βασίζεται πλέον σε κάθε χρήστη ξεχωριστά (ανατίθεται στην ασφάλεια του Kubernetes cluster ανά χρήστη) - Τα releases αποθηκεύονται πλέον ως secrets εντός του cluster και τα μεταδεδομένα του release object έχουν αλλάξει - Τα releases παραμένουν με βάση το namespace του release και όχι πλέον στο namespace του Tiller 2. Ενημέρωση του chart repository: - Η εντολή `helm search` υποστηρίζει πλέον αναζητήσεις τόσο σε τοπικά repositories όσο και ερωτήματα αναζήτησης στο Artifact Hub 3. Αναβάθμιση του chart apiVersion σε "v2" για τις ακόλουθες αλλαγές προδιαγραφών: - Οι δυναμικά συνδεδεμένες εξαρτήσεις chart μεταφέρθηκαν στο `Chart.yaml` (το `requirements.yaml` καταργήθηκε και requirements --> dependencies) - Τα library charts (helper/common charts) μπορούν πλέον να προστεθούν ως δυναμικά συνδεδεμένες εξαρτήσεις chart - Τα charts έχουν ένα πεδίο μεταδεδομένων `type` για να ορίσουν αν το chart είναι τύπου `application` ή `library`. Η προεπιλογή είναι application, που σημαίνει ότι είναι δυνατή η απεικόνιση (render) και η εγκατάστασή του - Τα Helm 2 charts (apiVersion=v1) εξακολουθούν να είναι εγκαταστάσιμα 4. Προσθήκη προδιαγραφής καταλόγων XDG: - Το Helm home καταργήθηκε και αντικαταστάθηκε με την προδιαγραφή καταλόγων XDG για την αποθήκευση αρχείων ρυθμίσεων - Δεν χρειάζεται πλέον αρχικοποίηση του Helm - Οι εντολές `helm init` και `helm home` καταργήθηκαν 5. Επιπλέον αλλαγές: - Η εγκατάσταση/ρύθμιση του Helm απλοποιήθηκε: - Μόνο το Helm client (helm binary) (χωρίς Tiller) - Λειτουργεί αυτόνομα χωρίς ρύθμιση - Τα `local` ή `stable` repositories δεν ρυθμίζονται πλέον από προεπιλογή - Το hook `crd-install` καταργήθηκε και αντικαταστάθηκε με τον κατάλογο `crds` στο chart, όπου όλα τα CRDs που ορίζονται σε αυτόν θα εγκαθίστανται πριν από οποιαδήποτε απεικόνιση του chart - Η τιμή annotation `test-failure` του hook καταργήθηκε, και η `test-success` έχει καταργηθεί. Χρησιμοποιήστε το `test` αντί αυτού - Εντολές που καταργήθηκαν/αντικαταστάθηκαν/προστέθηκαν: - delete --> uninstall : αφαιρεί όλο το ιστορικό release από προεπιλογή (προηγουμένως απαιτούσε `--purge`) - fetch --> pull - home (καταργήθηκε) - init (καταργήθηκε) - install: απαιτεί όνομα release ή το όρισμα `--generate-name` - inspect --> show - reset (καταργήθηκε) - serve (καταργήθηκε) - template: το όρισμα `-x`/`--execute` μετονομάστηκε σε `-s`/`--show-only` - upgrade: Προστέθηκε το όρισμα `--history-max` που περιορίζει τον μέγιστο αριθμό αναθεωρήσεων που αποθηκεύονται ανά release (0 για χωρίς όριο) - Η βιβλιοθήκη Go του Helm 3 έχει υποστεί πολλές αλλαγές και είναι ασύμβατη με τη βιβλιοθήκη του Helm 2 - Τα release binaries φιλοξενούνται πλέον στο `get.helm.sh` ## Περιπτώσεις Χρήσης Μετάβασης {#migration-use-cases} Οι περιπτώσεις χρήσης για τη μετάβαση είναι οι εξής: 1. Το Helm v2 και v3 διαχειρίζονται το ίδιο cluster: - Αυτή η περίπτωση χρήσης συνιστάται μόνο αν σκοπεύετε να αποσύρετε σταδιακά το Helm v2 και δεν απαιτείτε το v3 να διαχειρίζεται releases που έχουν εγκατασταθεί με το v2. Όλα τα νέα releases πρέπει να εγκαθίστανται με το v3 και τα υπάρχοντα releases που εγκαταστάθηκαν με το v2 πρέπει να ενημερώνονται/αφαιρούνται μόνο με το v2 - Το Helm v2 και v3 μπορούν να διαχειριστούν το ίδιο cluster χωρίς προβλήματα. Οι εκδόσεις του Helm μπορούν να εγκατασταθούν στο ίδιο ή σε διαφορετικά συστήματα - Αν εγκαθιστάτε το Helm v3 στο ίδιο σύστημα, πρέπει να εκτελέσετε ένα επιπλέον βήμα για να διασφαλίσετε ότι και οι δύο εκδόσεις client μπορούν να συνυπάρχουν μέχρι να είστε έτοιμοι να αφαιρέσετε τον Helm v2 client. Μετονομάστε ή τοποθετήστε το Helm v3 binary σε διαφορετικό φάκελο για να αποφύγετε συγκρούσεις - Κατά τα άλλα δεν υπάρχουν συγκρούσεις μεταξύ των δύο εκδόσεων λόγω των ακόλουθων διακρίσεων: - Η αποθήκευση των release (ιστορικού) για τα v2 και v3 είναι ανεξάρτητη. Οι αλλαγές περιλαμβάνουν τον πόρο Kubernetes για την αποθήκευση και τα μεταδεδομένα του release object που περιέχονται στον πόρο. Τα releases θα βρίσκονται επίσης σε namespace ανά χρήστη αντί να χρησιμοποιούν το namespace του Tiller (για παράδειγμα, το προεπιλεγμένο namespace του Tiller στο v2 είναι το kube-system). Το v2 χρησιμοποιεί "ConfigMaps" ή "Secrets" στο namespace του Tiller και ιδιοκτησία `TILLER`. Το v3 χρησιμοποιεί "Secrets" στο namespace του χρήστη και ιδιοκτησία `helm`. Τα releases είναι αυξητικά (incremental) τόσο στο v2 όσο και στο v3 - Το μόνο πιθανό πρόβλημα θα ήταν αν ορίζονται πόροι Kubernetes εμβέλειας cluster (π.χ. `clusterroles.rbac`) σε ένα chart. Η εγκατάσταση με το v3 θα αποτύγχανε ακόμα κι αν είναι μοναδικό στο namespace, καθώς οι πόροι θα συγκρούονταν - Η ρύθμιση του v3 δεν χρησιμοποιεί πλέον το `$HELM_HOME` και χρησιμοποιεί αντ' αυτού την προδιαγραφή καταλόγων XDG. Δημιουργείται επίσης δυναμικά όταν χρειάζεται. Επομένως είναι ανεξάρτητη από τη ρύθμιση του v2. Αυτό ισχύει μόνο όταν και οι δύο εκδόσεις είναι εγκατεστημένες στο ίδιο σύστημα 2. Μετάβαση από Helm v2 σε Helm v3: - Αυτή η περίπτωση χρήσης ισχύει όταν θέλετε το Helm v3 να διαχειρίζεται υπάρχοντα releases του Helm v2 - Πρέπει να σημειωθεί ότι ένας Helm v2 client: - μπορεί να διαχειριστεί 1 έως πολλά Kubernetes clusters - μπορεί να συνδεθεί σε 1 έως πολλές instances του Tiller για ένα cluster - Αυτό σημαίνει ότι πρέπει να το λάβετε υπόψη κατά τη μετάβαση, καθώς τα releases εγκαθίστανται σε clusters από τον Tiller και το namespace του. Επομένως πρέπει να γνωρίζετε ότι η μετάβαση γίνεται για κάθε cluster και κάθε instance του Tiller που διαχειρίζεται η instance του Helm v2 client - Η συνιστώμενη διαδρομή μετάβασης δεδομένων είναι η ακόλουθη: 1. Δημιουργία αντιγράφου ασφαλείας των δεδομένων v2 2. Μετάβαση της ρύθμισης του Helm v2 3. Μετάβαση των releases του Helm v2 4. Όταν είστε βέβαιοι ότι το Helm v3 διαχειρίζεται όλα τα δεδομένα του Helm v2 (για όλα τα clusters και τις instances του Tiller της instance του Helm v2 client) όπως αναμένεται, τότε καθαρίστε τα δεδομένα του Helm v2 - Η διαδικασία μετάβασης είναι αυτοματοποιημένη από το plugin [2to3](https://github.com/helm/helm-2to3) του Helm v3 ## Αναφορές {#reference} - Plugin [2to3](https://github.com/helm/helm-2to3) του Helm v3 - [Άρθρο](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) στο blog που εξηγεί τη χρήση του plugin `2to3` με παραδείγματα ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Πολιτική Υποστήριξης Εκδόσεων Helm" description: "Περιγράφει την πολιτική για τις εκδόσεις patch του Helm καθώς και τη μέγιστη διαφορά εκδόσεων που υποστηρίζεται μεταξύ Helm και Kubernetes." --- Αυτό το έγγραφο περιγράφει τη μέγιστη διαφορά εκδόσεων που υποστηρίζεται μεταξύ Helm και Kubernetes. ## Υποστηριζόμενες Εκδόσεις {#supported-versions} Οι εκδόσεις του Helm εκφράζονται ως `x.y.z`, όπου `x` είναι η κύρια έκδοση (major), `y` είναι η δευτερεύουσα έκδοση (minor) και `z` είναι η έκδοση patch, ακολουθώντας την ορολογία του [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Η ομάδα του Helm διατηρεί ένα release branch για την πιο πρόσφατη δευτερεύουσα έκδοση. Οι σχετικές διορθώσεις, συμπεριλαμβανομένων των διορθώσεων ασφαλείας, μεταφέρονται (cherry-pick) στο release branch, ανάλογα με τη σοβαρότητα και την εφικτότητα. Περισσότερες λεπτομέρειες μπορείτε να βρείτε στην [πολιτική εκδόσεων του Helm](/community/release_policy). ## Υποστηριζόμενη Διαφορά Εκδόσεων {#supported-version-skew} Όταν κυκλοφορεί μια νέα έκδοση του Helm, μεταγλωττίζεται με μια συγκεκριμένη δευτερεύουσα έκδοση του Kubernetes. Για παράδειγμα, το Helm 3.0.0 αλληλεπιδρά με το Kubernetes χρησιμοποιώντας τον client του Kubernetes 1.16.2, επομένως είναι συμβατό με το Kubernetes 1.16. Από το Helm 3 και μετά, θεωρείται ότι το Helm είναι συμβατό με εκδόσεις `n-3` του Kubernetes έναντι του οποίου μεταγλωττίστηκε. Λόγω των αλλαγών του Kubernetes μεταξύ δευτερευουσών εκδόσεων, η πολιτική υποστήριξης του Helm 2 είναι ελαφρώς αυστηρότερη, υποθέτοντας συμβατότητα με εκδόσεις `n-1` του Kubernetes. Για παράδειγμα, αν χρησιμοποιείτε μια έκδοση του Helm 3 που μεταγλωττίστηκε έναντι των client APIs του Kubernetes 1.17, τότε θα πρέπει να είναι ασφαλής η χρήση με Kubernetes 1.17, 1.16, 1.15 και 1.14. Αν χρησιμοποιείτε μια έκδοση του Helm 2 που μεταγλωττίστηκε έναντι των client APIs του Kubernetes 1.16, τότε θα πρέπει να είναι ασφαλής η χρήση με Kubernetes 1.16 και 1.15. Δεν συνιστάται η χρήση του Helm με έκδοση Kubernetes νεότερη από αυτήν έναντι της οποίας μεταγλωττίστηκε, καθώς το Helm δεν παρέχει εγγυήσεις συμβατότητας προς τα εμπρός. Αν επιλέξετε να χρησιμοποιήσετε το Helm με μια έκδοση Kubernetes που το Helm δεν υποστηρίζει, το κάνετε με δική σας ευθύνη. Ανατρέξτε στον παρακάτω πίνακα για να διαπιστώσετε ποια έκδοση του Helm είναι συμβατή με το cluster σας. | Έκδοση Helm | Υποστηριζόμενες Εκδόσεις Kubernetes | |-------------|-------------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/el/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Εισαγωγή", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Πώς να", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Θέματα", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Καλές Πρακτικές", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Οδηγός Προτύπων Chart", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Εντολές Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Κοινότητα", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Συχνές Ερωτήσεις", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/el/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Πολιτική Χρονοδιαγράμματος Εκδόσεων" description: "Περιγράφει την πολιτική χρονοδιαγράμματος εκδόσεων του Helm." --- Προς όφελος των χρηστών, το Helm καθορίζει και ανακοινώνει ημερομηνίες εκδόσεων εκ των προτέρων. Αυτό το έγγραφο περιγράφει την πολιτική που διέπει το χρονοδιάγραμμα εκδόσεων του Helm. ## Ημερολόγιο Εκδόσεων {#release-calendar} Ένα δημόσιο ημερολόγιο που δείχνει τις επερχόμενες εκδόσεις του Helm μπορείτε να βρείτε [εδώ](https://helm.sh/calendar/release). ## Σημασιολογική Αρίθμηση Εκδόσεων {#semantic-versioning} Οι εκδόσεις του Helm εκφράζονται ως `x.y.z`, όπου `x` είναι η κύρια έκδοση (major), `y` είναι η δευτερεύουσα έκδοση (minor) και `z` είναι η έκδοση patch, ακολουθώντας την ορολογία του [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## Εκδόσεις Patch {#patch-releases} Οι εκδόσεις patch παρέχουν στους χρήστες διορθώσεις σφαλμάτων και διορθώσεις ασφαλείας. Δεν περιέχουν νέες λειτουργίες. Μια νέα έκδοση patch για την πιο πρόσφατη δευτερεύουσα/κύρια έκδοση κυκλοφορεί συνήθως μία φορά το μήνα, τη δεύτερη Τετάρτη κάθε μήνα. Μια έκδοση patch για τη διόρθωση ενός κρίσιμου regression ή ζητήματος ασφαλείας μπορεί να κυκλοφορήσει όποτε χρειαστεί. Μια έκδοση patch ακυρώνεται για οποιονδήποτε από τους ακόλουθους λόγους: - δεν υπάρχει νέο περιεχόμενο από την προηγούμενη έκδοση - η ημερομηνία της έκδοσης patch εμπίπτει εντός μίας εβδομάδας πριν από το πρώτο release candidate (RC1) μιας επερχόμενης δευτερεύουσας έκδοσης - η ημερομηνία της έκδοσης patch εμπίπτει εντός τεσσάρων εβδομάδων μετά από μια δευτερεύουσα έκδοση ## Δευτερεύουσες Εκδόσεις {#minor-releases} Οι δευτερεύουσες εκδόσεις περιέχουν διορθώσεις ασφαλείας και σφαλμάτων καθώς και νέες λειτουργίες. Είναι συμβατές προς τα πίσω όσον αφορά το API και τη χρήση CLI. Για ευθυγράμμιση με τις εκδόσεις του Kubernetes, μια δευτερεύουσα έκδοση του Helm κυκλοφορεί κάθε 4 μήνες (3 εκδόσεις ετησίως). Πρόσθετες δευτερεύουσες εκδόσεις μπορούν να κυκλοφορήσουν αν χρειαστεί, αλλά δεν επηρεάζουν το χρονοδιάγραμμα μιας ανακοινωμένης μελλοντικής έκδοσης, εκτός αν η ανακοινωμένη έκδοση απέχει λιγότερο από 7 ημέρες. Ταυτόχρονα με τη δημοσίευση μιας έκδοσης, ανακοινώνεται η ημερομηνία της επόμενης δευτερεύουσας έκδοσης και αναρτάται στην κύρια ιστοσελίδα του Helm. ## Κύριες Εκδόσεις {#major-releases} Οι κύριες εκδόσεις περιέχουν breaking changes. Τέτοιες εκδόσεις είναι σπάνιες, αλλά μερικές φορές απαραίτητες ώστε το Helm να συνεχίσει να εξελίσσεται προς σημαντικές νέες κατευθύνσεις. Οι κύριες εκδόσεις μπορεί να είναι δύσκολο να προγραμματιστούν. Με αυτό υπόψη, μια τελική ημερομηνία έκδοσης επιλέγεται και ανακοινώνεται μόνο αφού γίνει διαθέσιμη η πρώτη beta έκδοση. ================================================ FILE: i18n/el/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Έργο Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Ανάπτυξη", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Κοινότητα", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Πηγαίος κώδικας", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Ιστολόγιο", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Εκδηλώσεις", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Κώδικας Δεοντολογίας", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Εισαγωγή", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Συμβουλές & κόλπα για Charts", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Ανάπτυξη Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Αναζήτηση 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Οδηγός Συνεισφοράς", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Συντηρητές", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Εβδομαδιαίες Συναντήσεις", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Κοινότητα GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Είμαστε ένα graduated project του Cloud Native Computing Foundation.
© Συγγραφείς Helm 2025. Η τεκμηρίωση διανέμεται υπό CC-BY-4.0.
© 2025 The Linux Foundation. Με επιφύλαξη παντός δικαιώματος. Το Linux Foundation διαθέτει εγγεγραμμένα εμπορικά σήματα και χρησιμοποιεί εμπορικά σήματα. Για λίστα των εμπορικών σημάτων του Linux Foundation, παρακαλούμε δείτε τη σελίδα Χρήσης Εμπορικών Σημάτων.", "description": "The footer copyright" }, "logo.alt": { "message": "Λογότυπο CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/el/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Λογότυπο Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Τεκμηρίωση", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Ιστολόγιο", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Κοινότητα", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/es/code.json ================================================ { "home.about.whatIsHelm": { "message": "Helm te ayuda a administrar aplicaciones de Kubernetes — Los Helm Charts te ayudan a definir, instalar y actualizar incluso las aplicaciones de Kubernetes más complejas.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Los Charts son fáciles de crear, versionar, compartir y publicar — así que empieza a usar Helm y deja de copiar y pegar.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm es un proyecto graduado en la {cncfLink} y es mantenido por la {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "comunidad de Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Aprende más:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Arquitectura de Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Guía de Inicio Rápido", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Video: Una Introducción a Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "¿Qué es Helm?", "description": "What is Helm? title" }, "home.community.nextFeatureRelease": { "message": "Próxima Liberación de Características", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Versión:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Fecha:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Calendario de Lanzamientos", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Próximos Eventos", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Próximos Eventos", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Eventos Pasados", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "{meetLink} para demostrar y discutir herramientas y proyectos. Las reuniones de la comunidad son grabadas y {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "Se reúnen cada semana", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "compartidas en YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Standups para desarrolladores" }, "home.community.developerStandups.time": { "message": "Jueves 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Estas reuniones están abiertas a todos. Consulta el {communityRepoLink} para notas y detalles.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "repositorio de la comunidad", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Discusión sobre el uso de Helm, trabajar con charts y resolver errores comunes.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Temas relacionados con el desarrollo de Helm, PRs en curso, lanzamientos, etc.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Discusión para usuarios y colaboradores de Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink} para unirse al equipo de Slack de Kubernetes.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Solicita acceso aquí", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Contribuir", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "¡Helm siempre da la bienvenida a nuevas contribuciones al proyecto!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "¿Por dónde empezar?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm es un gran proyecto con muchos usuarios y colaboradores. ¡Puede ser mucho para asimilar!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Tenemos una lista de {goodFirstIssuesLink} si quieres ayudar pero no sabes por dónde empezar.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "buenos primeros tickets", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "¿Qué debo hacer?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Antes de contribuir con código, por favor lee nuestra {contributionGuideLink}. Cubre los procesos para crear y revisar pull requests.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Guía de Contribución", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Después de escribir código, por favor {signYourCommitsLink} para asegurar que Helm cumpla con el acuerdo {dcoLink} utilizado por la {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "firma tus commits", "description": "Sign your commits link" }, "home.community.title": { "message": "Únete a la Comunidad", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Más información sobre el proyecto Helm y cómo contribuir.", "description": "Join the Community subtitle" }, "home.features.manageComplexity": { "message": "Administra la Complejidad", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Los Charts describen incluso las aplicaciones más complejas, proporcionan instalación de aplicaciones repetible y sirven como un único punto de autoridad.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Actualizaciones Fáciles", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Elimina el dolor de las actualizaciones con upgrades en el lugar y hooks personalizados.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Uso Compartido Simple", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Los Charts son fáciles de versionar, compartir y alojar en servidores públicos o privados.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Retrocesos", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Usa {helmRollback} para revertir a una versión anterior de un lanzamiento con facilidad.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Características", "description": "Features section title" }, "home.gettingStarted.title": { "message": "Comenzar", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Obtener Helm!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Instala Helm con un gestor de paquetes, o {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "descarga un binario", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Una vez instalado, desempaqueta el binario de helm y agrégalo a tu PATH ¡y listo! Consulta la {docsLink} para más información sobre {installationLink} y {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "documentación", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "instalación", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "instrucciones de uso", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Obtener Charts", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Visita {artifactHubLink} para explorar {helmChartsLink} de numerosos repositorios públicos.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "home.header.tagline": { "message": "El gestor de paquetes para Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm es la mejor manera de encontrar, compartir y usar software construido para", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "Esta página ha fallado.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Volver al principio", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Archivo", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Archivo", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Navegación por la página de la lista de blogs ", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Entradas más recientes", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Entradas más antiguas", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Barra de paginación de publicaciones del blog", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Publicación más reciente", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Publicación más antigua", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Ver Todas las Etiquetas", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "modo sistema", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "modo claro", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "modo oscuro", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Cambiar entre modo oscuro y claro (actualmente {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Rastro de navegación", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 artículo|{count} artículos", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Página del documento", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Anterior", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Siguiente", "description": "The label used to navigate to the next doc" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Esta es la documentación sin publicar para {siteTitle}, versión {versionLabel}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Esta es la documentación para {siteTitle} {versionLabel}, que ya no se mantiene activamente.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Para la documentación actualizada, vea {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "última versión", "description": "The label used for the latest version suggestion link label" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Un documento etiquetado|{count} documentos etiquetados", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} con \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "Version: {versionLabel}" }, "theme.common.headingLinkTitle": { "message": "Enlace directo al {heading}", "description": "Title for link to heading" }, "theme.common.editThisPage": { "message": "Editar esta página", "description": "The link label to edit the current page" }, "theme.lastUpdated.atDate": { "message": " en {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " por {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Última actualización{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.NotFound.title": { "message": "Página No Encontrada", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versiones", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Etiquetas:", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Cerrar", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "precaución", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "peligro", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "info", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "nota", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "tip", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "aviso", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.blog.sidebar.navAriaLabel": { "message": "Navegación de publicaciones recientes", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Ampliar la categoría '{label}' de la barra lateral", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Colapsar categoría '{label}' de la barra lateral", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(se abre en una nueva pestaña)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Principal", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "No pudimos encontrar lo que buscaba.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Comuníquese con el dueño del sitio que le proporcionó la URL original y hágale saber que su vínculo está roto.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Idiomas", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "En esta página", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readingTime.plurals": { "message": "Lectura de un minuto|{readingTime} min de lectura", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.post.readMore": { "message": "Leer Más", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Leer más acerca de {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.CodeBlock.copy": { "message": "Copiar", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Copiado", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Copiar código", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "Alternar ajuste de palabras", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "Página de Inicio", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "Barra lateral de Documentos", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Colapsar barra lateral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Colapsar barra lateral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Cerrar barra de lateral", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Volver al menú principal", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Alternar barra lateral", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Expandir el menú desplegable", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Colapsar el menú desplegable", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Expandir barra lateral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Expandir barra lateral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "Una publicación|{count} publicaciones", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} etiquetados con \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Autores", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Ver Todos los Autores", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Este autor aún no ha escrito ninguna publicación.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Página sin clasificar", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Esta página está sin clasificar. Los motores de búsqueda no la indexaran, y solo los usuarios con el enlace directo podrán acceder a esta.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Página borrador", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Esta página es un borrador. Solo será visible en desarrollo y se excluirá de la compilación de producción.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Intente de nuevo", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Saltar al contenido principal", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Etiquetas", "description": "The title of the tag list page" }, "theme.blog.list.pageTitle": { "message": "Blog", "description": "The word 'Blog' in breadcrumbs" } } ================================================ FILE: i18n/es/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Blog", "description": "The title for the blog used in SEO" }, "description": { "message": "Blog", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Todas las publicaciones", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Usando Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandos de Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Desarrollando Plantillas", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Mejores Prácticas", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Convenciones Generales description: Convenciones generales para charts. sidebar_position: 1 --- Esta parte de la Guía de Mejores Prácticas explica las convenciones generales. ## Nombres de Charts Los nombres de los charts deben ser letras minúsculas y números. Las palabras _pueden_ separarse con guiones (-): Ejemplos: ``` drupal nginx-lego aws-cluster-autoscaler ``` No se pueden usar letras mayúsculas ni guiones bajos en los nombres de charts. Los puntos no deben usarse en los nombres de charts. ## Números de Versión Siempre que sea posible, Helm usa [SemVer 2](https://semver.org) para representar números de versión. (Tenga en cuenta que las etiquetas de imágenes de Docker no necesariamente siguen SemVer, y por lo tanto se consideran una desafortunada excepción a la regla.) Cuando las versiones SemVer se almacenan en etiquetas de Kubernetes, convencionalmente se cambia el carácter `+` por un carácter `_`, ya que las etiquetas no permiten el signo `+` como valor. ## Formato de YAML Los archivos YAML deben indentarse usando _dos espacios_ (y nunca tabulaciones). ## Uso de las Palabras Helm y Chart Existen algunas convenciones para el uso de las palabras _Helm_ y _helm_. - _Helm_ se refiere al proyecto en su totalidad - `helm` se refiere al comando del lado del cliente - El término `chart` no necesita ser capitalizado, ya que no es un nombre propio - Sin embargo, `Chart.yaml` sí necesita ser capitalizado porque el nombre del archivo distingue entre mayúsculas y minúsculas Cuando tenga dudas, use _Helm_ (con 'H' mayúscula). ## Plantillas de Chart y Namespace Evite definir la propiedad `namespace` en la sección `metadata` de sus plantillas de chart. El namespace para aplicar las plantillas renderizadas debe especificarse en la llamada a un cliente de Kubernetes mediante un flag como `--namespace`. Helm renderiza sus plantillas tal cual y las envía al cliente de Kubernetes, ya sea Helm mismo u otro programa (kubectl, flux, spinnaker, etc). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Cómo manejar la creación y uso de CRDs. sidebar_position: 7 --- Esta sección de la Guía de Mejores Prácticas trata sobre la creación y uso de objetos Custom Resource Definition. Al trabajar con Custom Resource Definitions (CRDs), es importante distinguir dos partes diferentes: - Existe una declaración de un CRD. Este es el archivo YAML que tiene el kind `CustomResourceDefinition` - Luego existen recursos que _usan_ el CRD. Por ejemplo, un CRD define `foo.example.com/v1`. Cualquier recurso que tenga `apiVersion: example.com/v1` y kind `Foo` es un recurso que usa el CRD. ## Instalar una Declaración de CRD Antes de Usar el Recurso Helm está optimizado para cargar tantos recursos en Kubernetes tan rápido como sea posible. Por diseño, Kubernetes puede tomar un conjunto completo de manifiestos y ponerlos todos en línea (esto se llama el ciclo de reconciliación). Pero hay una diferencia con los CRDs. Para un CRD, la declaración debe registrarse antes de que se puedan usar recursos de ese tipo de CRD. Y el proceso de registro a veces tarda unos segundos. ### Método 1: Deje que `helm` lo Haga por Usted Con la llegada de Helm 3, eliminamos los antiguos hooks `crd-install` por una metodología más simple. Ahora hay un directorio especial llamado `crds` que puede crear en su chart para contener sus CRDs. Estos CRDs no son plantillas, pero se instalarán por defecto al ejecutar `helm install` para el chart. Si el CRD ya existe, se omitirá con una advertencia. Si desea omitir el paso de instalación de CRD, puede pasar el flag `--skip-crds`. #### Algunas advertencias (y explicaciones) Actualmente no hay soporte para actualizar o eliminar CRDs usando Helm. Esta fue una decisión explícita después de mucha discusión en la comunidad debido al peligro de pérdida de datos no intencional. Además, actualmente no hay consenso en la comunidad sobre cómo manejar los CRDs y su ciclo de vida. A medida que esto evolucione, Helm añadirá soporte para esos casos de uso. El flag `--dry-run` de `helm install` y `helm upgrade` actualmente no es compatible con CRDs. El propósito de "Dry Run" es validar que la salida del chart realmente funcionará si se envía al servidor. Pero los CRDs son una modificación del comportamiento del servidor. Helm no puede instalar el CRD en un dry run, por lo que el cliente de descubrimiento no conocerá ese Custom Resource (CR), y la validación fallará. Alternativamente, puede mover los CRDs a su propio chart o usar `helm template` en su lugar. Otro punto importante a considerar en la discusión sobre el soporte de CRDs es cómo se maneja el renderizado de plantillas. Una de las desventajas claras del método `crd-install` usado en Helm 2 era la incapacidad de validar correctamente los charts debido a la disponibilidad cambiante de la API (un CRD en realidad está añadiendo otra API disponible a su clúster de Kubernetes). Si un chart instalaba un CRD, `helm` ya no tenía un conjunto válido de versiones de API con el cual trabajar. Esta es también la razón detrás de eliminar el soporte de plantillas de los CRDs. Con el nuevo método `crds` de instalación de CRDs, ahora aseguramos que `helm` tenga información completamente válida sobre el estado actual del clúster. ### Método 2: Charts Separados Otra forma de hacer esto es poner la definición del CRD en un chart, y luego poner cualquier recurso que use ese CRD en _otro_ chart. En este método, cada chart debe instalarse por separado. Sin embargo, este flujo de trabajo puede ser más útil para operadores de clúster con acceso de administrador. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Dependencias description: Cubre las mejores prácticas para las dependencias de un Chart. sidebar_position: 4 --- Esta sección de la guía cubre las mejores prácticas para las `dependencies` declaradas en `Chart.yaml`. ## Versiones Cuando sea posible, use rangos de versión en lugar de fijar una versión exacta. El valor predeterminado sugerido es usar una coincidencia a nivel de parche: ```yaml version: ~1.2.3 ``` Esto coincidirá con la versión `1.2.3` y cualquier parche de esa release. En otras palabras, `~1.2.3` es equivalente a `>= 1.2.3, < 1.3.0` Para la sintaxis completa de coincidencia de versiones, consulte la [documentación de semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Versiones preliminares (Prerelease) Las restricciones de versión anteriores no coincidirán con versiones preliminares. Por ejemplo, `version: ~1.2.3` coincidirá con `version: ~1.2.4` pero no con `version: ~1.2.3-1`. La siguiente configuración permite coincidir tanto con versiones preliminares como a nivel de parche: ```yaml version: ~1.2.3-0 ``` ### URLs de Repositorio Cuando sea posible, use URLs de repositorio `https://`. Como segunda opción, use `http://`. Si el repositorio se ha añadido al archivo de índice de repositorios, el nombre del repositorio puede usarse como un alias de la URL. Use `alias:` o `@` seguido del nombre del repositorio. Las URLs de archivo (`file://...`) se consideran un "caso especial" para charts que se ensamblan mediante un pipeline de despliegue fijo. Al usar [plugins de descarga](/topics/plugins.md#downloader-plugins), el esquema de URL será específico del plugin. Tenga en cuenta que un usuario del chart necesitará tener instalado un plugin que soporte el esquema para actualizar o construir la dependencia. Helm no puede realizar operaciones de gestión de dependencias cuando el campo `repository` se deja en blanco. En ese caso, Helm asumirá que la dependencia está en un subdirectorio de la carpeta `charts` con el mismo nombre que la propiedad `name` de la dependencia. ## Condiciones y Etiquetas Se deben añadir condiciones o etiquetas a cualquier dependencia que _sea opcional_. Tenga en cuenta que, por defecto, una `condition` es `true`. La forma preferida de una condición es: ```yaml condition: somechart.enabled ``` Donde `somechart` es el nombre del chart de la dependencia. Cuando múltiples subcharts (dependencias) juntos proporcionan una característica opcional o intercambiable, esos charts deben compartir las mismas etiquetas. Por ejemplo, si tanto `nginx` como `memcached` juntos proporcionan optimizaciones de rendimiento para la aplicación principal del chart, y se requiere que ambos estén presentes cuando esa característica está habilitada, entonces ambos deben tener una sección de etiquetas como esta: ```yaml tags: - webaccelerator ``` Esto permite a un usuario activar o desactivar esa característica con una sola etiqueta. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Etiquetas y Anotaciones description: Cubre las mejores prácticas para usar etiquetas y anotaciones en su Chart. sidebar_position: 5 --- Esta parte de la Guía de Mejores Prácticas cubre las mejores prácticas para usar etiquetas y anotaciones en su chart. ## ¿Es una Etiqueta o una Anotación? Un elemento de metadatos debe ser una etiqueta bajo las siguientes condiciones: - Es utilizado por Kubernetes para identificar este recurso - Es útil exponerlo a los operadores con el propósito de consultar el sistema. Por ejemplo, sugerimos usar `helm.sh/chart: NAME-VERSION` como etiqueta para que los operadores puedan encontrar convenientemente todas las instancias de un chart en particular. Si un elemento de metadatos no se usa para consultas, debe establecerse como una anotación en su lugar. Los hooks de Helm siempre son anotaciones. ## Etiquetas Estándar La siguiente tabla define etiquetas comunes que usan los charts de Helm. Helm en sí nunca requiere que una etiqueta particular esté presente. Las etiquetas marcadas como REC son recomendadas, y _deberían_ colocarse en un chart para mantener consistencia global. Las marcadas como OPT son opcionales. Son idiomáticas o de uso común, pero no se depende de ellas frecuentemente para propósitos operacionales. | Nombre | Estado | Descripción | |--------|--------|-------------| | `app.kubernetes.io/name` | REC | Debe ser el nombre de la aplicación, reflejando la aplicación completa. Usualmente se usa `{{ template "name" . }}` para esto. Es usado por muchos manifiestos de Kubernetes y no es específico de Helm. | | `helm.sh/chart` | REC | Debe ser el nombre del chart y la versión: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | | `app.kubernetes.io/managed-by` | REC | Siempre debe establecerse como `{{ .Release.Service }}`. Sirve para encontrar todo lo gestionado por Helm. | | `app.kubernetes.io/instance` | REC | Debe ser `{{ .Release.Name }}`. Ayuda a diferenciar entre diferentes instancias de la misma aplicación. | | `app.kubernetes.io/version` | OPT | La versión de la aplicación, puede establecerse como `{{ .Chart.AppVersion }}`. | | `app.kubernetes.io/component` | OPT | Es una etiqueta común para marcar los diferentes roles que pueden desempeñar los componentes en una aplicación. Por ejemplo, `app.kubernetes.io/component: frontend`. | | `app.kubernetes.io/part-of` | OPT | Cuando se usan múltiples charts o piezas de software juntos para crear una aplicación. Por ejemplo, software de aplicación y una base de datos para producir un sitio web. Puede establecerse con la aplicación de nivel superior que se está soportando. | Puede encontrar más información sobre las etiquetas de Kubernetes, con el prefijo `app.kubernetes.io`, en la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods y PodTemplates description: Discute el formato de las secciones Pod y PodTemplate en los manifiestos de Chart. sidebar_position: 6 --- Esta parte de la Guía de Mejores Prácticas discute el formato de las secciones Pod y PodTemplate en los manifiestos de chart. La siguiente lista (no exhaustiva) de recursos utilizan PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Imágenes Una imagen de contenedor debe usar un tag fijo o el SHA de la imagen. No debe usar los tags `latest`, `head`, `canary`, u otros tags diseñados para ser _flotantes_. Las imágenes _pueden_ definirse en el archivo `values.yaml` para facilitar el cambio de imágenes. ```yaml image: {{ .Values.redisImage | quote }} ``` Una imagen y un tag _pueden_ definirse en `values.yaml` como dos campos separados: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` establece el `imagePullPolicy` en `IfNotPresent` por defecto haciendo lo siguiente en su `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` Y en `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` De manera similar, Kubernetes establece por defecto el `imagePullPolicy` en `IfNotPresent` si no está definido. Si desea un valor diferente a `IfNotPresent`, simplemente actualice el valor en `values.yaml` a su valor deseado. ## Los PodTemplates Deben Declarar Selectores Todas las secciones de PodTemplate deben especificar un selector. Por ejemplo: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Esta es una buena práctica porque establece claramente la relación entre el recurso y el pod. Pero esto es aún más importante para recursos como Deployment. Sin esto, se utiliza el conjunto _completo_ de etiquetas para seleccionar los pods coincidentes, y esto causará problemas si usa etiquetas que cambian, como versión o fecha de lanzamiento. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Control de Acceso Basado en Roles description: Discute la creación y formato de recursos RBAC en manifiestos de Charts. sidebar_position: 8 --- Esta parte de la Guía de Mejores Prácticas cubre la creación y formato de recursos RBAC en manifiestos de charts. Los recursos RBAC son: - ServiceAccount (con namespace) - Role (con namespace) - ClusterRole - RoleBinding (con namespace) - ClusterRoleBinding ## Configuración YAML La configuración de RBAC y ServiceAccount debe realizarse bajo claves separadas. Son conceptos distintos. Separar estos dos conceptos en el YAML los desambigua y lo hace más claro. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` Esta estructura puede extenderse para charts más complejos que requieren múltiples ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Los Recursos RBAC Deben Crearse por Defecto `rbac.create` debe ser un valor booleano que controle si se crean los recursos RBAC. El valor por defecto debe ser `true`. Los usuarios que deseen gestionar los controles de acceso RBAC por sí mismos pueden establecer este valor a `false` (en cuyo caso, consulte la sección siguiente). ## Uso de Recursos RBAC `serviceAccount.name` debe establecerse con el nombre del ServiceAccount que usarán los recursos creados por el chart. - Si `serviceAccount.create` es true, se debe crear un ServiceAccount con este nombre. Si el nombre no está establecido, se genera uno usando la plantilla `fullname`. - Si `serviceAccount.create` es false, no se debe crear el ServiceAccount, pero aún debe asociarse con los mismos recursos para que los recursos RBAC creados manualmente posteriormente funcionen correctamente. - Si `serviceAccount.create` es false y el nombre no está especificado, se usa el ServiceAccount por defecto. La siguiente plantilla auxiliar puede usarse para el ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Plantillas description: Mejores prácticas para trabajar con plantillas. sidebar_position: 3 --- Esta parte de la Guía de Mejores Prácticas se enfoca en plantillas. ## Estructura de `templates/` El directorio `templates/` debe estructurarse de la siguiente manera: - Los archivos de plantilla deben tener la extensión `.yaml` si producen salida YAML. La extensión `.tpl` puede usarse para archivos de plantilla que no producen contenido con formato. - Los nombres de archivos de plantilla deben usar notación con guiones (`my-example-configmap.yaml`), no camelCase. - Cada definición de recurso debe estar en su propio archivo de plantilla. - Los nombres de archivos de plantilla deben reflejar el tipo de recurso en el nombre, por ejemplo: `foo-pod.yaml`, `bar-svc.yaml` ## Nombres de Plantillas Definidas Las plantillas definidas (plantillas creadas dentro de una directiva `{{ define }}`) son accesibles globalmente. Esto significa que un chart y todos sus subcharts tendrán acceso a todas las plantillas creadas con `{{ define }}`. Por esa razón, _todos los nombres de plantillas definidas deben incluir un prefijo de espacio de nombres (namespace)._ Correcto: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorrecto: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Se recomienda encarecidamente que los nuevos charts se creen mediante el comando `helm create`, ya que los nombres de las plantillas se definen automáticamente según esta mejor práctica. ## Formato de Plantillas Las plantillas deben indentarse usando _dos espacios_ (nunca tabulaciones). Las directivas de plantilla deben tener espacio en blanco después de las llaves de apertura y antes de las llaves de cierre: Correcto: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorrecto: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Las plantillas deben recortar espacios en blanco donde sea posible: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Los bloques (como las estructuras de control) pueden indentarse para indicar el flujo del código de la plantilla. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Sin embargo, dado que YAML es un lenguaje orientado a espacios en blanco, a menudo no es posible que la indentación del código siga esa convención. ## Espacios en Blanco en Plantillas Generadas Es preferible mantener la cantidad de espacios en blanco en las plantillas generadas al mínimo. En particular, no deben aparecer numerosas líneas en blanco adyacentes entre sí. Pero líneas vacías ocasionales (particularmente entre secciones lógicas) están bien. Esto es lo mejor: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Esto está bien: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Pero esto debe evitarse: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Comentarios (Comentarios YAML vs. Comentarios de Plantilla) Tanto YAML como las plantillas de Helm tienen marcadores de comentarios. Comentarios YAML: ```yaml # Esto es un comentario type: sprocket ``` Comentarios de Plantilla: ```yaml {{- /* Esto es un comentario. */}} type: frobnitz ``` Los comentarios de plantilla deben usarse para documentar características de una plantilla, como explicar una plantilla definida: ```yaml {{- /* mychart.shortname proporciona una versión truncada de 6 caracteres del nombre del release. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Dentro de las plantillas, los comentarios YAML pueden usarse cuando es útil que los usuarios de Helm (posiblemente) vean los comentarios durante la depuración. ```yaml # Esto puede causar problemas si el valor es mayor que 100Gi memory: {{ .Values.maxMem | quote }} ``` El comentario anterior es visible cuando el usuario ejecuta `helm install --debug`, mientras que los comentarios especificados en secciones `{{- /* */}}` no lo son. Tenga cuidado al agregar comentarios YAML `#` en secciones de plantilla que contengan values de Helm que pueden ser requeridos por ciertas funciones de plantilla. Por ejemplo, si la función `required` se introduce en el ejemplo anterior y `maxMem` no está establecido, entonces un comentario YAML `#` introducirá un error de renderizado. Correcto: `helm template` no renderiza este bloque ```yaml {{- /* # Esto puede causar problemas si el valor es mayor que 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Incorrecto: `helm template` devuelve `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # Esto puede causar problemas si el valor es mayor que 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Revise [Depuración de Plantillas](../chart_template_guide/debugging.md) para otro ejemplo de este comportamiento de cómo los comentarios YAML permanecen intactos. ## Uso de JSON en Plantillas y Salida de Plantillas YAML es un superconjunto de JSON. En algunos casos, usar sintaxis JSON puede ser más legible que otras representaciones YAML. Por ejemplo, este YAML está más cerca del método normal de YAML para expresar listas: ```yaml arguments: - "--dirname" - "/foo" ``` Pero es más fácil de leer cuando se colapsa en un estilo de lista JSON: ```yaml arguments: ["--dirname", "/foo"] ``` Usar JSON para mejorar la legibilidad es bueno. Sin embargo, la sintaxis JSON no debe usarse para representar estructuras más complejas. Al trabajar con JSON puro incrustado dentro de YAML (como la configuración de contenedores init), es apropiado usar el formato JSON. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Valores description: Se enfoca en cómo debe estructurar y usar sus values. sidebar_position: 2 --- Esta parte de la guía de mejores prácticas cubre el uso de values. En esta sección, ofrecemos recomendaciones sobre cómo estructurar y usar sus values, con énfasis en el diseño del archivo `values.yaml` de un chart. ## Convenciones de Nomenclatura Los nombres de variables deben comenzar con una letra minúscula y las palabras deben separarse con camelCase: Correcto: ```yaml chicken: true chickenNoodleSoup: true ``` Incorrecto: ```yaml Chicken: true # las mayúsculas iniciales pueden entrar en conflicto con las variables integradas chicken-noodle-soup: true # no use guiones en el nombre ``` Tenga en cuenta que todas las variables integradas de Helm comienzan con una letra mayúscula para distinguirlas fácilmente de los values definidos por el usuario: `.Release.Name`, `.Capabilities.KubeVersion`. ## Values Planos o Anidados YAML es un formato flexible, y los values pueden estar profundamente anidados o ser planos. Anidado: ```yaml server: name: nginx port: 80 ``` Plano: ```yaml serverName: nginx serverPort: 80 ``` En la mayoría de los casos, se prefiere el formato plano sobre el anidado. Esto se debe a que es más simple para los desarrolladores de plantillas y los usuarios. Para una seguridad óptima, un value anidado debe verificarse en cada nivel: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Por cada nivel de anidamiento, se debe realizar una verificación de existencia. Pero para la configuración plana, estas verificaciones pueden omitirse, haciendo la plantilla más fácil de leer y usar. ``` {{ default "none" .Values.serverName }} ``` Cuando hay una gran cantidad de variables relacionadas, y al menos una de ellas es requerida, los values anidados pueden usarse para mejorar la legibilidad. ## Haga los Tipos Explícitos Las reglas de conversión de tipos de YAML a veces son poco intuitivas. Por ejemplo, `foo: false` no es lo mismo que `foo: "false"`. Los enteros grandes como `foo: 12345678` se convertirán a notación científica en algunos casos. La forma más fácil de evitar errores de conversión de tipos es ser explícito con las cadenas e implícito con todo lo demás. O, en resumen, _entrecomille todas las cadenas_. A menudo, para evitar problemas de conversión de enteros, es ventajoso almacenar sus enteros como cadenas también, y usar `{{ int $value }}` en la plantilla para convertir de cadena a entero. En la mayoría de los casos, las etiquetas de tipo explícitas son respetadas, por lo que `foo: !!string 1234` tratará `1234` como una cadena. _Sin embargo_, el analizador de YAML consume las etiquetas, por lo que la información de tipo se pierde después de un análisis. ## Considere Cómo los Usuarios Usarán sus Values Hay tres fuentes potenciales de values: - El archivo `values.yaml` del chart - Un archivo values proporcionado por `helm install -f` o `helm upgrade -f` - Los values pasados con la opción `--set` o `--set-string` en `helm install` o `helm upgrade` Al diseñar la estructura de sus values, tenga en cuenta que los usuarios de su chart pueden querer sobrescribirlos mediante la opción `-f` o con la opción `--set`. Dado que `--set` es menos expresivo, la primera recomendación para escribir su archivo `values.yaml` es _facilitar la sobrescritura desde `--set`_. Por esta razón, a menudo es mejor estructurar su archivo values usando mapas. Difícil de usar con `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Lo anterior no puede expresarse con `--set` en Helm `<=2.4`. En Helm 2.5, acceder al puerto de foo es `--set servers[0].port=80`. No solo es más difícil para el usuario descubrirlo, sino que es propenso a errores si en algún momento posterior se cambia el orden de `servers`. Fácil de usar: ```yaml servers: foo: port: 80 bar: port: 81 ``` Acceder al puerto de foo es mucho más obvio: `--set servers.foo.port=80`. ## Documente `values.yaml` Cada propiedad definida en `values.yaml` debe documentarse. La cadena de documentación debe comenzar con el nombre de la propiedad que describe y luego proporcionar al menos una descripción de una oración. Incorrecto: ```yaml # el nombre del host para el servidor web serverHost: example serverPort: 9191 ``` Correcto: ```yaml # serverHost es el nombre del host para el servidor web serverHost: example # serverPort es el puerto de escucha HTTP para el servidor web serverPort: 9191 ``` Comenzar cada comentario con el nombre del parámetro que documenta facilita la búsqueda de documentación con grep y permitirá que las herramientas de documentación correlacionen de manera confiable las cadenas de documentación con los parámetros que describen. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Acceso a Archivos en las Plantillas description: Cómo acceder a archivos desde dentro de una plantilla. sidebar_position: 10 --- En la sección anterior vimos varias formas de crear y acceder a plantillas con nombre. Esto facilita importar una plantilla desde dentro de otra plantilla. Pero a veces es deseable importar un _archivo que no es una plantilla_ e inyectar su contenido sin enviarlo a través del renderizador de plantillas. Helm proporciona acceso a archivos a través del objeto `.Files`. Antes de continuar con los ejemplos de plantillas, hay algunas cosas que tener en cuenta sobre cómo funciona esto: - Puede agregar archivos adicionales a su chart de Helm. Estos archivos se empaquetarán junto con el chart. Sin embargo, tenga cuidado: los charts deben ser menores de 1M debido a las limitaciones de almacenamiento de los objetos de Kubernetes. - No se puede acceder a algunos archivos a través del objeto `.Files`, generalmente por razones de seguridad. - No se puede acceder a los archivos en `templates/`. - No se puede acceder a los archivos excluidos usando `.helmignore`. - No se puede acceder a archivos fuera de un [subchart](./subcharts_and_globals.md) de una aplicación Helm, incluyendo los del padre. - Los charts no preservan la información del modo UNIX, por lo que los permisos a nivel de archivo no tendrán impacto en la disponibilidad de un archivo cuando se trata del objeto `.Files`. - [Ejemplo básico](#ejemplo-básico) - [Helpers de ruta](#helpers-de-ruta) - [Patrones glob](#patrones-glob) - [Funciones de utilidad para ConfigMap y Secrets](#funciones-de-utilidad-para-configmap-y-secrets) - [Codificación](#codificación) - [Líneas](#líneas) ## Ejemplo básico Con estas consideraciones en mente, escribamos una plantilla que lea tres archivos en nuestro ConfigMap. Para empezar, agregaremos tres archivos al chart, colocando los tres directamente dentro del directorio `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Cada uno de estos es un archivo TOML simple (piense en los archivos INI de Windows antiguos). Conocemos los nombres de estos archivos, así que podemos usar una función `range` para recorrerlos e inyectar su contenido en nuestro ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Este ConfigMap utiliza varias de las técnicas discutidas en secciones anteriores. Por ejemplo, creamos una variable `$files` para mantener una referencia al objeto `.Files`. También usamos la función `tuple` para crear una lista de archivos que recorremos. Luego imprimimos cada nombre de archivo (`{{ . }}: |-`) seguido del contenido del archivo `{{ $files.Get . }}`. Ejecutar esta plantilla producirá un único ConfigMap con el contenido de los tres archivos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Helpers de ruta Al trabajar con archivos, puede ser muy útil realizar algunas operaciones estándar sobre las rutas de archivos. Para ayudar con esto, Helm importa muchas de las funciones del paquete [path](https://golang.org/pkg/path/) de Go para su uso. Todas son accesibles con los mismos nombres que en el paquete de Go, pero con la primera letra en minúscula. Por ejemplo, `Base` se convierte en `base`, etc. Las funciones importadas son: - Base - Dir - Ext - IsAbs - Clean ## Patrones glob A medida que su chart crece, puede encontrar que tiene una mayor necesidad de organizar sus archivos, por lo que proporcionamos un método `Files.Glob(pattern string)` para ayudar a extraer ciertos archivos con toda la flexibilidad de los [patrones glob](https://godoc.org/github.com/gobwas/glob). `.Glob` devuelve un tipo `Files`, por lo que puede llamar a cualquiera de los métodos de `Files` en el objeto devuelto. Por ejemplo, imagine la siguiente estructura de directorios: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Tiene múltiples opciones con Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` O ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Funciones de utilidad para ConfigMap y Secrets (Disponible en Helm 2.0.2 y posterior) Es muy común querer colocar el contenido de archivos tanto en ConfigMaps como en Secrets, para montarlos en sus pods en tiempo de ejecución. Para ayudar con esto, proporcionamos un par de métodos de utilidad en el tipo `Files`. Para una mayor organización, es especialmente útil usar estos métodos en conjunto con el método `Glob`. Dada la estructura de directorios del ejemplo de [Glob](#patrones-glob) anterior: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Codificación Puede importar un archivo y hacer que la plantilla lo codifique en base-64 para asegurar una transmisión exitosa: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` El ejemplo anterior tomará el mismo archivo `config1.toml` que usamos antes y lo codificará: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Líneas A veces es deseable acceder a cada línea de un archivo en su plantilla. Proporcionamos un método conveniente `Lines` para esto. Puede recorrer `Lines` usando una función `range`: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` No hay forma de pasar archivos externos al chart durante `helm install`. Por lo tanto, si está pidiendo a los usuarios que proporcionen datos, estos deben cargarse usando `helm install -f` o `helm install --set`. Esta discusión concluye nuestra inmersión en las herramientas y técnicas para escribir plantillas de Helm. En la siguiente sección veremos cómo puede usar un archivo especial, `templates/NOTES.txt`, para enviar instrucciones post-instalación a los usuarios de su chart. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Objetos Integrados description: Objetos integrados disponibles para las plantillas. sidebar_position: 3 --- El motor de plantillas pasa los objetos a la plantilla. Su código también puede pasar objetos (veremos ejemplos al usar las sentencias `with` y `range`). Incluso hay algunas formas de crear nuevos objetos dentro de sus plantillas, como con la función `tuple` que veremos más adelante. Los objetos pueden ser simples y contener un único valor. O pueden contener otros objetos o funciones. Por ejemplo, el objeto `Release` contiene varios objetos (como `Release.Name`) y el objeto `Files` tiene algunas funciones. En la sección anterior, usamos `{{ .Release.Name }}` para insertar el nombre de un release en una plantilla. `Release` es uno de los objetos de nivel superior a los que puede acceder en sus plantillas. - `Release`: Este objeto describe el release en sí. Tiene varios objetos dentro: - `Release.Name`: El nombre del release - `Release.Namespace`: El namespace donde se desplegará (si el manifiesto no lo sobrescribe) - `Release.IsUpgrade`: Se establece en `true` si la operación actual es una actualización o rollback. - `Release.IsInstall`: Se establece en `true` si la operación actual es una instalación. - `Release.Revision`: El número de revisión para este release. En la instalación, es 1, y se incrementa con cada actualización y rollback. - `Release.Service`: El servicio que está renderizando la plantilla actual. En Helm, siempre es `Helm`. - `Values`: Valores pasados a la plantilla desde el archivo `values.yaml` y desde archivos proporcionados por el usuario. Por defecto, `Values` está vacío. - `Chart`: El contenido del archivo `Chart.yaml`. Cualquier dato en `Chart.yaml` será accesible aquí. Por ejemplo, `{{ .Chart.Name }}-{{ .Chart.Version }}` imprimirá `mychart-0.1.0`. - Los campos disponibles están listados en la [Guía de Charts](/topics/charts.md#the-chartyaml-file) - `Subcharts`: Proporciona acceso al scope (.Values, .Charts, .Releases, etc.) de los subcharts desde el chart padre. Por ejemplo, `.Subcharts.mySubChart.myValue` para acceder a `myValue` en el chart `mySubChart`. - `Files`: Proporciona acceso a todos los archivos no especiales en un chart. Aunque no puede usarlo para acceder a plantillas, puede usarlo para acceder a otros archivos en el chart. Consulte la sección [Acceso a Archivos](/chart_template_guide/accessing_files.md) para más información. - `Files.Get` es una función para obtener un archivo por nombre (`.Files.Get config.ini`) - `Files.GetBytes` es una función para obtener el contenido de un archivo como un array de bytes en lugar de una cadena. Esto es útil para cosas como imágenes. - `Files.Glob` es una función que devuelve una lista de archivos cuyos nombres coinciden con el patrón glob de shell dado. - `Files.Lines` es una función que lee un archivo línea por línea. Esto es útil para iterar sobre cada línea de un archivo. - `Files.AsSecrets` es una función que devuelve los contenidos de los archivos como cadenas codificadas en Base 64. - `Files.AsConfig` es una función que devuelve los contenidos de los archivos como un mapa YAML. - `Capabilities`: Proporciona información sobre las capacidades que soporta el clúster de Kubernetes. - `Capabilities.APIVersions` es un conjunto de versiones. - `Capabilities.APIVersions.Has $version` indica si una versión (por ejemplo, `batch/v1`) o recurso (por ejemplo, `apps/v1/Deployment`) está disponible en el clúster. - `Capabilities.KubeVersion` y `Capabilities.KubeVersion.Version` es la versión de Kubernetes. - `Capabilities.KubeVersion.Major` es la versión mayor de Kubernetes. - `Capabilities.KubeVersion.Minor` es la versión menor de Kubernetes. - `Capabilities.HelmVersion` es el objeto que contiene los detalles de la versión de Helm, es la misma salida de `helm version`. - `Capabilities.HelmVersion.Version` es la versión actual de Helm en formato semver. - `Capabilities.HelmVersion.GitCommit` es el sha1 de git de Helm. - `Capabilities.HelmVersion.GitTreeState` es el estado del árbol git de Helm. - `Capabilities.HelmVersion.GoVersion` es la versión del compilador Go utilizado. - `Template`: Contiene información sobre la plantilla actual que se está ejecutando - `Template.Name`: Una ruta de archivo con namespace a la plantilla actual (por ejemplo, `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: La ruta con namespace al directorio de plantillas del chart actual (por ejemplo, `mychart/templates`). Los valores integrados siempre comienzan con una letra mayúscula. Esto sigue la convención de nomenclatura de Go. Cuando cree sus propios nombres, puede usar la convención que prefiera su equipo. Algunos equipos, como muchos cuyos charts puede ver en [Artifact Hub](https://artifacthub.io/packages/search?kind=0), eligen usar solo letras minúsculas iniciales para distinguir los nombres locales de los integrados. En esta guía, seguimos esa convención. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Control de Flujo description: Una descripción rápida de la estructura de flujo dentro de las plantillas. sidebar_position: 7 --- Las estructuras de control (llamadas "acciones" en la terminología de plantillas) le permiten, como autor de plantillas, controlar el flujo de generación de una plantilla. El lenguaje de plantillas de Helm proporciona las siguientes estructuras de control: - `if`/`else` para crear bloques condicionales - `with` para especificar un ámbito - `range`, que proporciona un bucle de estilo "for each" Además de estas, proporciona algunas acciones para declarar y usar segmentos de plantilla con nombre: - `define` declara una nueva plantilla con nombre dentro de su plantilla - `template` importa una plantilla con nombre - `block` declara un tipo especial de área de plantilla rellenable En esta sección, hablaremos sobre `if`, `with` y `range`. Los otros se cubren en la sección "Plantillas con Nombre" más adelante en esta guía. ## If/Else La primera estructura de control que veremos es para incluir condicionalmente bloques de texto en una plantilla. Este es el bloque `if`/`else`. La estructura básica de un condicional se ve así: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Observe que ahora estamos hablando de _pipelines_ en lugar de valores. Esto es para aclarar que las estructuras de control pueden ejecutar un pipeline completo, no solo evaluar un valor. Un pipeline se evalúa como _falso_ si el valor es: - un booleano falso - un cero numérico - una cadena vacía - un `nil` (vacío o nulo) - una colección vacía (`map`, `slice`, `tuple`, `dict`, `array`) En todas las demás condiciones, la condición es verdadera. Agreguemos un condicional simple a nuestro ConfigMap. Añadiremos otra configuración si la bebida está establecida como coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Como comentamos `drink: coffee` en nuestro último ejemplo, la salida no debería incluir una bandera `mug: "true"`. Pero si agregamos esa línea de nuevo a nuestro archivo `values.yaml`, la salida debería verse así: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Control de Espacios en Blanco Mientras observamos los condicionales, deberíamos echar un vistazo rápido a cómo se controlan los espacios en blanco en las plantillas. Tomemos el ejemplo anterior y formatémoslo para que sea un poco más fácil de leer: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Inicialmente, esto se ve bien. Pero si lo ejecutamos a través del motor de plantillas, obtendremos un resultado desafortunado: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` ¿Qué pasó? Generamos YAML incorrecto debido a los espacios en blanco anteriores. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` tiene una sangría incorrecta. Simplemente quitemos la sangría de esa línea y volvamos a ejecutar: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Cuando enviemos eso, obtendremos YAML válido, pero que todavía se ve un poco extraño: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Observe que recibimos algunas líneas vacías en nuestro YAML. ¿Por qué? Cuando el motor de plantillas se ejecuta, _elimina_ el contenido dentro de `{{` y `}}`, pero deja el resto de los espacios en blanco exactamente como está. YAML asigna significado a los espacios en blanco, por lo que gestionar los espacios en blanco se vuelve bastante importante. Afortunadamente, las plantillas de Helm tienen algunas herramientas para ayudar. Primero, la sintaxis de llaves de las declaraciones de plantilla se puede modificar con caracteres especiales para indicar al motor de plantillas que recorte los espacios en blanco. `{{- ` (con el guion y el espacio agregados) indica que se deben recortar los espacios en blanco a la izquierda, mientras que ` -}}` significa que se deben consumir los espacios en blanco a la derecha. _¡Tenga cuidado! ¡Los saltos de línea también son espacios en blanco!_ > Asegúrese de que haya un espacio entre el `-` y el resto de su directiva. > `{{- 3 }}` significa "recortar espacios en blanco a la izquierda e imprimir 3" > mientras que `{{-3 }}` significa "imprimir -3". Usando esta sintaxis, podemos modificar nuestra plantilla para eliminar esas nuevas líneas: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Para ilustrar este punto, ajustemos lo anterior y sustituyamos un `*` por cada espacio en blanco que se eliminará siguiendo esta regla. Un `*` al final de la línea indica un carácter de nueva línea que se eliminaría ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Teniendo eso en cuenta, podemos ejecutar nuestra plantilla a través de Helm y ver el resultado: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Tenga cuidado con los modificadores de recorte. Es fácil hacer accidentalmente cosas como esta: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Eso producirá `food: "PIZZA"mug: "true"` porque consume las nuevas líneas en ambos lados. > Para obtener detalles sobre el control de espacios en blanco en plantillas, > consulte la [documentación oficial de plantillas de > Go](https://godoc.org/text/template) Finalmente, a veces es más fácil indicarle al sistema de plantillas cómo debe aplicar la sangría en lugar de intentar dominar el espaciado de las directivas de plantilla. Por esa razón, puede que a veces le resulte útil usar la función `indent` (`{{ indent 2 "mug:true" }}`). ## Modificar el ámbito usando `with` La siguiente estructura de control a analizar es la acción `with`. Esta controla el ámbito de las variables. Recuerde que `.` es una referencia al _ámbito actual_. Por lo tanto, `.Values` le indica a la plantilla que busque el objeto `Values` en el ámbito actual. La sintaxis de `with` es similar a una declaración `if` simple: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Los ámbitos se pueden cambiar. `with` le permite establecer el ámbito actual (`.`) a un objeto particular. Por ejemplo, hemos estado trabajando con `.Values.favorite`. Reescribamos nuestro ConfigMap para alterar el ámbito `.` para que apunte a `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Tenga en cuenta que eliminamos el condicional `if` del ejercicio anterior porque ahora es innecesario - el bloque después de `with` solo se ejecuta si el valor de `PIPELINE` no está vacío. Observe que ahora podemos hacer referencia a `.drink` y `.food` sin calificarlos. Esto se debe a que la declaración `with` establece `.` para que apunte a `.Values.favorite`. El `.` se restablece a su ámbito anterior después de `{{ end }}`. Pero aquí hay una nota de precaución: Dentro del ámbito restringido, no podrá acceder a los otros objetos del ámbito padre usando `.`. Por ejemplo, esto fallará: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Producirá un error porque `Release.Name` no está dentro del ámbito restringido para `.`. Sin embargo, si intercambiamos las dos últimas líneas, todo funcionará como se espera porque el ámbito se restablece después de `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` O bien, podemos usar `$` para acceder al objeto `Release.Name` desde el ámbito padre. `$` se asigna al ámbito raíz cuando comienza la ejecución de la plantilla y no cambia durante la ejecución de la misma. Lo siguiente también funcionaría: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Después de ver `range`, examinaremos las variables de plantilla, que ofrecen una solución al problema de ámbito anterior. ## Iterando con la acción `range` Muchos lenguajes de programación tienen soporte para iterar usando bucles `for`, bucles `foreach` o mecanismos funcionales similares. En el lenguaje de plantillas de Helm, la forma de iterar a través de una colección es usar el operador `range`. Para comenzar, agreguemos una lista de ingredientes de pizza a nuestro archivo `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Ahora tenemos una lista (llamada `slice` en plantillas) de `pizzaToppings`. Podemos modificar nuestra plantilla para imprimir esta lista en nuestro ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Podemos usar `$` para acceder a la lista `Values.pizzaToppings` desde el ámbito padre. `$` se asigna al ámbito raíz cuando comienza la ejecución de la plantilla y no cambia durante la ejecución de la misma. Lo siguiente también funcionaría: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Examinemos más de cerca la lista `toppings:`. La función `range` "recorrerá" (iterará a través de) la lista `pizzaToppings`. Pero ahora sucede algo interesante. Al igual que `with` establece el ámbito de `.`, también lo hace un operador `range`. Cada vez que pasa por el bucle, `.` se establece en el ingrediente de pizza actual. Es decir, la primera vez, `.` se establece en `mushrooms`. En la segunda iteración se establece en `cheese`, y así sucesivamente. Podemos enviar el valor de `.` directamente a través de un pipeline, así que cuando hacemos `{{ . | title | quote }}`, enviamos `.` a `title` (función de capitalización de título) y luego a `quote`. Si ejecutamos esta plantilla, la salida será: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Ahora, en este ejemplo hemos hecho algo ingenioso. La línea `toppings: |-` declara una cadena multilínea. Así que nuestra lista de ingredientes en realidad no es una lista YAML. Es una gran cadena. ¿Por qué haríamos esto? Porque los datos en el campo `data` de ConfigMaps están compuestos por pares clave/valor, donde tanto la clave como el valor son cadenas simples. Para entender por qué este es el caso, consulte la [documentación de ConfigMap de Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/). Sin embargo, para nosotros, este detalle no importa mucho. > El marcador `|-` en YAML toma una cadena multilínea. Esta puede ser una técnica > útil para incrustar grandes bloques de datos dentro de sus manifiestos, como > se ejemplifica aquí. A veces es útil poder crear rápidamente una lista dentro de su plantilla y luego iterar sobre esa lista. Las plantillas de Helm tienen una función para facilitar esto: `tuple`. En ciencias de la computación, una tupla es una colección similar a una lista de tamaño fijo, pero con tipos de datos arbitrarios. Esto transmite aproximadamente la forma en que se usa un `tuple`. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Lo anterior producirá esto: ```yaml sizes: |- - small - medium - large ``` Además de listas y tuplas, `range` se puede usar para iterar sobre colecciones que tienen una clave y un valor (como un `map` o `dict`). Veremos cómo hacer esto en la siguiente sección cuando introduzcamos las variables de plantilla. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Apéndice: Tipos de datos de Go y plantillas" description: Un resumen rápido sobre las variables en las plantillas. sidebar_position: 16 --- El lenguaje de plantillas de Helm está implementado en Go, un lenguaje de programación fuertemente tipado. Por esta razón, las variables en las plantillas tienen _tipos_. En la mayoría de los casos, las variables se expondrán como uno de los siguientes tipos: - string: Una cadena de texto - bool: un valor `true` o `false` - int: Un valor entero (también existen variantes de 8, 16, 32 y 64 bits con y sin signo) - float64: un valor de punto flotante de 64 bits (también existen variantes de 8, 16 y 32 bits) - un slice de bytes (`[]byte`), que se usa frecuentemente para almacenar datos (potencialmente) binarios - struct: un objeto con propiedades y métodos - un slice (lista indexada) de cualquiera de los tipos anteriores - un map con claves de tipo string (`map[string]interface{}`) donde el valor es cualquiera de los tipos anteriores Existen muchos otros tipos en Go, y a veces será necesario convertir entre ellos en las plantillas. La forma más fácil de depurar el tipo de un objeto es pasarlo a través de `printf "%T"` en una plantilla, lo que imprimirá el tipo. También puede consultar las funciones `typeOf` y `kindOf`. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Depuración de Plantillas description: Solución de problemas de charts que no se despliegan correctamente. sidebar_position: 13 --- La depuración de plantillas puede ser complicada porque las plantillas renderizadas se envían al servidor de API de Kubernetes, que puede rechazar los archivos YAML por razones distintas al formato. Hay algunos comandos que pueden ayudarle a depurar. - `helm lint` es su herramienta principal para verificar que su chart sigue las mejores prácticas - `helm template --debug` permite probar el renderizado de las plantillas del chart localmente. - `helm install --dry-run --debug` también renderizará su chart localmente sin instalarlo, pero además verificará si hay recursos en conflicto que ya están ejecutándose en el clúster. Usar `--dry-run=server` también ejecutará cualquier `lookup` en su chart contra el servidor. - `helm get manifest`: Esta es una buena manera de ver qué plantillas están instaladas en el servidor. Cuando su YAML no se puede analizar, pero desea ver qué se genera, una forma fácil de recuperar el YAML es comentar la sección problemática en la plantilla, y luego volver a ejecutar `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` Lo anterior se renderizará y devolverá con los comentarios intactos: ```yaml apiVersion: v2 # some: problem section # "bar" ``` Esto proporciona una forma rápida de ver el contenido generado sin que los errores de análisis de YAML interfieran. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Lista de Funciones de Plantilla description: Una lista de funciones de plantilla disponibles en Helm sidebar_position: 6 --- Helm incluye muchas funciones de plantilla que puede aprovechar en sus plantillas. Se enumeran aquí y se desglosan en las siguientes categorías: * [Criptografía y Seguridad](#funciones-de-criptografía-y-seguridad) * [Fecha](#funciones-de-fecha) * [Diccionarios](#funciones-de-diccionarios-y-dict) * [Codificación](#funciones-de-codificación) * [Rutas de Archivos](#funciones-de-rutas-de-archivos) * [Kubernetes y Chart](#funciones-de-kubernetes-y-chart) * [Lógica y Control de Flujo](#funciones-de-lógica-y-control-de-flujo) * [Listas](#funciones-de-listas-y-list) * [Matemáticas](#funciones-matemáticas) * [Matemáticas de Punto Flotante](#funciones-matemáticas-de-punto-flotante) * [Red](#funciones-de-red) * [Reflexión](#funciones-de-reflexión) * [Expresiones Regulares](#expresiones-regulares) * [Versiones Semánticas](#funciones-de-versiones-semánticas) * [Cadenas](#funciones-de-cadenas) * [Conversión de Tipos](#funciones-de-conversión-de-tipos) * [URL](#funciones-de-url) * [UUID](#funciones-de-uuid) ## Funciones de Lógica y Control de Flujo Helm incluye numerosas funciones de lógica y control de flujo incluyendo [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), y [required](#required). ### and Devuelve el AND booleano de dos o más argumentos (el primer argumento vacío, o el último argumento). ``` and .Arg1 .Arg2 ``` ### or Devuelve el OR booleano de dos o más argumentos (el primer argumento no vacío, o el último argumento). ``` or .Arg1 .Arg2 ``` ### not Devuelve la negación booleana de su argumento. ``` not .Arg ``` ### eq Devuelve la igualdad booleana de los argumentos (ej., Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Devuelve la desigualdad booleana de los argumentos (ej., Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Devuelve un booleano verdadero si el primer argumento es menor que el segundo. De lo contrario devuelve falso (ej., Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Devuelve un booleano verdadero si el primer argumento es menor o igual que el segundo. De lo contrario devuelve falso (ej., Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Devuelve un booleano verdadero si el primer argumento es mayor que el segundo. De lo contrario devuelve falso (ej., Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Devuelve un booleano verdadero si el primer argumento es mayor o igual que el segundo. De lo contrario devuelve falso (ej., Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default Para establecer un valor por defecto simple, use `default`: ``` default "foo" .Bar ``` En el ejemplo anterior, si `.Bar` evalúa a un valor no vacío, se usará ese valor. Pero si está vacío, se devolverá `foo` en su lugar. La definición de "vacío" depende del tipo: - Numérico: 0 - Cadena: "" - Listas: `[]` - Diccionarios: `{}` - Booleano: `false` - Y siempre `nil` (también conocido como null) Para estructuras, no hay definición de vacío, por lo que una estructura nunca devolverá el valor por defecto. ### required Especifique valores que deben establecerse con `required`: ``` required "A valid foo is required!" .Bar ``` Si `.Bar` está vacío o no está definido (consulte [default](#default) para saber cómo se evalúa), la plantilla no se renderizará y devolverá el mensaje de error proporcionado en su lugar. ### empty La función `empty` devuelve `true` si el valor dado se considera vacío, y `false` en caso contrario. Los valores vacíos se enumeran en la sección `default`. ``` empty .Foo ``` Note que en los condicionales de plantillas de Go, el vacío se calcula automáticamente. Por lo tanto, raramente necesitará `if not empty .Foo`. En su lugar, simplemente use `if .Foo`. ### fail Devuelve incondicionalmente un `string` vacío y un `error` con el texto especificado. Esto es útil en escenarios donde otras condiciones han determinado que el renderizado de la plantilla debe fallar. ``` fail "Please accept the end user license agreement" ``` ### coalesce La función `coalesce` toma una lista de valores y devuelve el primer valor no vacío. ``` coalesce 0 1 2 ``` Lo anterior devuelve `1`. Esta función es útil para recorrer múltiples variables o valores: ``` coalesce .name .parent.name "Matt" ``` Lo anterior primero verificará si `.name` está vacío. Si no lo está, devolverá ese valor. Si _está_ vacío, `coalesce` evaluará `.parent.name` para verificar si está vacío. Finalmente, si tanto `.name` como `.parent.name` están vacíos, devolverá `Matt`. ### ternary La función `ternary` toma dos valores y un valor de prueba. Si el valor de prueba es verdadero, se devolverá el primer valor. Si el valor de prueba está vacío, se devolverá el segundo valor. Esto es similar al operador ternario en C y otros lenguajes de programación. #### valor de prueba verdadero ``` ternary "foo" "bar" true ``` o ``` true | ternary "foo" "bar" ``` Lo anterior devuelve `"foo"`. #### valor de prueba falso ``` ternary "foo" "bar" false ``` o ``` false | ternary "foo" "bar" ``` Lo anterior devuelve `"bar"`. ## Funciones de Cadenas Helm incluye las siguientes funciones de cadenas: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-y-hassuffix), [hasSuffix](#hasprefix-y-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-y-squote), [randAlpha](#randalphanum-randalpha-randnumeric-y-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-y-randascii), [randAscii](#randalphanum-randalpha-randnumeric-y-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-y-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-y-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), y [wrapWith](#wrapwith). ### print Devuelve una cadena a partir de la combinación de sus partes. ``` print "Matt has " .Dogs " dogs" ``` Los tipos que no son cadenas se convierten a cadenas cuando es posible. Note que cuando dos argumentos adyacentes no son cadenas, se agrega un espacio entre ellos. ### println Funciona de la misma manera que [print](#print) pero agrega una nueva línea al final. ### printf Devuelve una cadena basada en una cadena de formato y los argumentos a pasar en orden. ``` printf "%s has %d dogs." .Name .NumberDogs ``` El marcador de posición a usar depende del tipo del argumento que se pasa. Esto incluye: Propósito general: * `%v` el valor en formato por defecto * al imprimir diccionarios, el flag plus (%+v) agrega nombres de campo * `%%` un signo de porcentaje literal; no consume ningún valor Booleano: * `%t` la palabra true o false Entero: * `%b` base 2 * `%c` el carácter representado por el punto de código Unicode correspondiente * `%d` base 10 * `%o` base 8 * `%O` base 8 con prefijo 0o * `%q` un literal de carácter entre comillas simples escapado de forma segura * `%x` base 16, con letras minúsculas para a-f * `%X` base 16, con letras mayúsculas para A-F * `%U` formato Unicode: U+1234; igual que "U+%04X" Punto flotante y componentes complejos: * `%b` notación científica decimal con exponente potencia de dos, ej. -123456p-78 * `%e` notación científica, ej. -1.234456e+78 * `%E` notación científica, ej. -1.234456E+78 * `%f` punto decimal pero sin exponente, ej. 123.456 * `%F` sinónimo de %f * `%g` %e para exponentes grandes, %f en caso contrario. * `%G` %E para exponentes grandes, %F en caso contrario * `%x` notación hexadecimal (con exponente potencia de dos decimal), ej. -0x1.23abcp+20 * `%X` notación hexadecimal mayúsculas, ej. -0X1.23ABCP+20 Cadena y slice de bytes (tratados de manera equivalente con estos verbos): * `%s` los bytes sin interpretar de la cadena o slice * `%q` una cadena entre comillas dobles escapada de forma segura * `%x` base 16, minúsculas, dos caracteres por byte * `%X` base 16, mayúsculas, dos caracteres por byte Slice: * `%p` dirección del elemento 0 en notación base 16, con 0x inicial ### trim La función `trim` elimina los espacios en blanco de ambos lados de una cadena: ``` trim " hello " ``` Lo anterior produce `hello` ### trimAll Elimina los caracteres dados del principio y final de una cadena: ``` trimAll "$" "$5.00" ``` Esto devuelve `5.00` (como cadena). ### trimPrefix Elimina solo el prefijo de una cadena: ``` trimPrefix "-" "-hello" ``` Lo anterior devuelve `hello` ### trimSuffix Elimina solo el sufijo de una cadena: ``` trimSuffix "-" "hello-" ``` Lo anterior devuelve `hello` ### lower Convierte toda la cadena a minúsculas: ``` lower "HELLO" ``` Esto devuelve `hello` ### upper Convierte toda la cadena a mayúsculas: ``` upper "hello" ``` Lo anterior devuelve `HELLO` ### title Convierte a formato de título: ``` title "hello world" ``` Lo anterior devuelve `Hello World` ### untitle Elimina el formato de título. `untitle "Hello World"` produce `hello world`. ### repeat Repite una cadena múltiples veces: ``` repeat 3 "hello" ``` Lo anterior devuelve `hellohellohello` ### substr Obtiene una subcadena de una cadena. Toma tres parámetros: - inicio (int) - fin (int) - cadena (string) ``` substr 0 5 "hello world" ``` El resultado es `hello` ### nospace Elimina todos los espacios en blanco de una cadena. ``` nospace "hello w o r l d" ``` El resultado es `helloworld` ### trunc Trunca una cadena ``` trunc 5 "hello world" ``` Lo anterior produce `hello`. ``` trunc -5 "hello world" ``` Lo anterior produce `world`. ### abbrev Trunca una cadena con puntos suspensivos (`...`) Parámetros: - longitud máxima - la cadena ``` abbrev 5 "hello world" ``` Lo anterior devuelve `he...`, ya que cuenta el ancho de los puntos suspensivos contra la longitud máxima. ### abbrevboth Abrevia en ambos lados: ``` abbrevboth 5 10 "1234 5678 9123" ``` Lo anterior produce `...5678...` Toma: - desplazamiento izquierdo - longitud máxima - la cadena ### initials Dadas múltiples palabras, toma la primera letra de cada palabra y las combina. ``` initials "First Try" ``` Esto devuelve `FT` ### randAlphaNum, randAlpha, randNumeric, y randAscii Estas cuatro funciones generan cadenas aleatorias criptográficamente seguras (usan ```crypto/rand```), pero con diferentes conjuntos de caracteres base: - `randAlphaNum` usa `0-9a-zA-Z` - `randAlpha` usa `a-zA-Z` - `randNumeric` usa `0-9` - `randAscii` usa todos los caracteres ASCII imprimibles Cada una toma un parámetro: la longitud entera de la cadena. ``` randNumeric 3 ``` Lo anterior producirá una cadena aleatoria con tres dígitos. ### wrap Ajusta el texto a un número de columnas dado: ``` wrap 80 $someText ``` Lo anterior ajustará la cadena en `$someText` a 80 columnas. ### wrapWith `wrapWith` funciona como `wrap`, pero le permite especificar la cadena con la que ajustar. (`wrap` usa `\n`) ``` wrapWith 5 "\t" "Hello World" ``` Lo anterior produce `Hello World` (donde el espacio en blanco es un carácter de tabulación ASCII) ### contains Prueba si una cadena está contenida dentro de otra: ``` contains "cat" "catch" ``` Esto devuelve `true` porque `catch` contiene `cat`. ### hasPrefix y hasSuffix Las funciones `hasPrefix` y `hasSuffix` prueban si una cadena tiene un prefijo o sufijo dado: ``` hasPrefix "cat" "catch" ``` Lo anterior devuelve `true` porque `catch` tiene el prefijo `cat`. ### quote y squote Estas funciones envuelven una cadena en comillas dobles (`quote`) o comillas simples (`squote`). ### cat La función `cat` concatena múltiples cadenas en una, separándolas con espacios: ``` cat "hello" "beautiful" "world" ``` Lo anterior produce `hello beautiful world` ### indent La función `indent` indenta cada línea en una cadena dada al ancho de indentación especificado. Esto es útil cuando se alinean cadenas multilínea: ``` indent 4 $lots_of_text ``` Lo anterior indentará cada línea de texto con 4 caracteres de espacio. ### nindent La función `nindent` es igual que la función indent, pero antepone una nueva línea al principio de la cadena. ``` nindent 4 $lots_of_text ``` Lo anterior indentará cada línea de texto con 4 caracteres de espacio y agregará una nueva línea al principio. ### replace Realiza un reemplazo simple de cadenas. Toma tres argumentos: - cadena a reemplazar - cadena con la que reemplazar - cadena fuente ``` "I Am Henry VIII" | replace " " "-" ``` Lo anterior producirá `I-Am-Henry-VIII` ### plural Pluraliza una cadena. ``` len $fish | plural "one anchovy" "many anchovies" ``` En el ejemplo anterior, si la longitud de la cadena es 1, se imprimirá el primer argumento (`one anchovy`). De lo contrario, se imprimirá el segundo argumento (`many anchovies`). Los argumentos son: - cadena singular - cadena plural - entero de longitud NOTA: Helm actualmente no soporta idiomas con reglas de pluralización más complejas. Y `0` se considera plural porque el idioma inglés lo trata así (`zero anchovies`). ### snakecase Convierte una cadena de camelCase a snake_case. ``` snakecase "FirstName" ``` Esto producirá `first_name`. ### camelcase Convierte una cadena de snake_case a CamelCase ``` camelcase "http_server" ``` Esto producirá `HttpServer`. ### kebabcase Convierte una cadena de camelCase a kebab-case. ``` kebabcase "FirstName" ``` Lo anterior producirá `first-name`. ### swapcase Intercambia las mayúsculas/minúsculas de una cadena usando un algoritmo basado en palabras. Algoritmo de conversión: - Carácter mayúscula se convierte a minúscula - Carácter de título se convierte a minúscula - Carácter minúscula después de espacio en blanco o al inicio se convierte a título - Otros caracteres minúsculas se convierten a mayúsculas - El espacio en blanco se define por unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` Lo anterior producirá `tHIS iS a.tEST`. ### shuffle Mezcla aleatoriamente una cadena. ``` shuffle "hello" ``` Lo anterior reordenará aleatoriamente las letras en `hello`, produciendo quizás `oelhl`. ## Funciones de Conversión de Tipos Helm proporciona las siguientes funciones de conversión de tipos: - `atoi`: Convierte una cadena a un entero. - `float64`: Convierte a `float64`. - `int`: Convierte a `int` en el ancho del sistema. - `int64`: Convierte a `int64`. - `toDecimal`: Convierte un octal unix a `int64`. - `toString`: Convierte a una cadena. - `toStrings`: Convierte una lista, slice o arreglo a una lista de cadenas. - `toJson` (`mustToJson`): Convierte lista, slice, arreglo, dict u objeto a JSON. - `toPrettyJson` (`mustToPrettyJson`): Convierte lista, slice, arreglo, dict u objeto a JSON indentado. - `toRawJson` (`mustToRawJson`): Convierte lista, slice, arreglo, dict u objeto a JSON con caracteres HTML sin escapar. - `fromYaml`: Convierte una cadena YAML a un objeto. - `fromJson`: Convierte una cadena JSON a un objeto. - `fromJsonArray`: Convierte un arreglo JSON a una lista. - `toYaml`: Convierte lista, slice, arreglo, dict u objeto a yaml indentado, puede usarse para copiar fragmentos de yaml de cualquier fuente. Esta función es equivalente a la función yaml.Marshal de GoLang, consulte la documentación aquí: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Convierte lista, slice, arreglo, dict u objeto a yaml indentado. Equivalente a `toYaml` pero adicionalmente indentará listas por 2 espacios. - `toToml`: Convierte lista, slice, arreglo, dict u objeto a toml, puede usarse para copiar fragmentos de toml de cualquier fuente. - `fromYamlArray`: Convierte un arreglo YAML a una lista. Solo `atoi` requiere que la entrada sea de un tipo específico. Las demás intentarán convertir de cualquier tipo al tipo de destino. Por ejemplo, `int64` puede convertir flotantes a enteros, y también puede convertir cadenas a enteros. ### toStrings Dada una colección tipo lista, produce un slice de cadenas. ``` list 1 2 3 | toStrings ``` Lo anterior convierte `1` a `"1"`, `2` a `"2"`, y así sucesivamente, y luego los devuelve como una lista. ### toDecimal Dado un permiso octal unix, produce un decimal. ``` "0777" | toDecimal ``` Lo anterior convierte `0777` a `511` y devuelve el valor como int64. ### toJson, mustToJson La función `toJson` codifica un elemento en una cadena JSON. Si el elemento no puede ser convertido a JSON, la función devolverá una cadena vacía. `mustToJson` devolverá un error en caso de que el elemento no pueda ser codificado en JSON. ``` toJson .Item ``` Lo anterior devuelve la representación en cadena JSON de `.Item`. ### toPrettyJson, mustToPrettyJson La función `toPrettyJson` codifica un elemento en una cadena JSON formateada (indentada). ``` toPrettyJson .Item ``` Lo anterior devuelve la representación en cadena JSON indentada de `.Item`. ### toRawJson, mustToRawJson La función `toRawJson` codifica un elemento en una cadena JSON con caracteres HTML sin escapar. ``` toRawJson .Item ``` Lo anterior devuelve la representación en cadena JSON sin escapar de `.Item`. ### fromYaml La función `fromYaml` toma una cadena YAML y devuelve un objeto que puede usarse en plantillas. `Archivo en: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson La función `fromJson` toma una cadena JSON y devuelve un objeto que puede usarse en plantillas. `Archivo en: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray La función `fromJsonArray` toma un arreglo JSON y devuelve una lista que puede usarse en plantillas. `Archivo en: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty Las funciones `toYaml` y `toYamlPretty` codifican un objeto (lista, slice, arreglo, dict u objeto) en una cadena YAML indentada. > Note que `toYamlPretty` es funcionalmente equivalente pero mostrará YAML con indentación adicional para elementos de lista ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray La función `fromYamlArray` toma un arreglo YAML y devuelve una lista que puede usarse en plantillas. `Archivo en: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Expresiones Regulares Helm incluye las siguientes funciones de expresiones regulares: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Devuelve true si la cadena de entrada contiene alguna coincidencia de la expresión regular. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` Lo anterior produce `true` `regexMatch` entra en pánico si hay un problema y `mustRegexMatch` devuelve un error al motor de plantillas si hay un problema. ### regexFindAll, mustRegexFindAll Devuelve un slice de todas las coincidencias de la expresión regular en la cadena de entrada. El último parámetro n determina el número de subcadenas a devolver, donde -1 significa devolver todas las coincidencias ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` Lo anterior produce `[2 4 6 8]` `regexFindAll` entra en pánico si hay un problema y `mustRegexFindAll` devuelve un error al motor de plantillas si hay un problema. ### regexFind, mustRegexFind Devuelve la primera coincidencia (la más a la izquierda) de la expresión regular en la cadena de entrada ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` Lo anterior produce `d1` `regexFind` entra en pánico si hay un problema y `mustRegexFind` devuelve un error al motor de plantillas si hay un problema. ### regexReplaceAll, mustRegexReplaceAll Devuelve una copia de la cadena de entrada, reemplazando las coincidencias de la Regexp con la cadena de reemplazo. Dentro de la cadena de reemplazo, los signos $ se interpretan como en Expand, por lo que por ejemplo $1 representa el texto de la primera subcoincidencia. El primer argumento es ``, el segundo es ``, y el tercero es ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` Lo anterior produce `-W-xxW-` `regexReplaceAll` entra en pánico si hay un problema y `mustRegexReplaceAll` devuelve un error al motor de plantillas si hay un problema. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Devuelve una copia de la cadena de entrada, reemplazando las coincidencias de la Regexp con la cadena de reemplazo. La cadena de reemplazo se sustituye directamente, sin usar Expand. El primer argumento es ``, el segundo es ``, y el tercero es ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` Lo anterior produce `-${1}-${1}-` `regexReplaceAllLiteral` entra en pánico si hay un problema y `mustRegexReplaceAllLiteral` devuelve un error al motor de plantillas si hay un problema. ### regexSplit, mustRegexSplit Divide la cadena de entrada en subcadenas separadas por la expresión y devuelve un slice de las subcadenas entre esas coincidencias de expresión. El último parámetro `n` determina el número de subcadenas a devolver, donde `-1` significa devolver todas las coincidencias ``` regexSplit "z+" "pizza" -1 ``` Lo anterior produce `[pi a]` `regexSplit` entra en pánico si hay un problema y `mustRegexSplit` devuelve un error al motor de plantillas si hay un problema. ## Funciones de Criptografía y Seguridad Helm proporciona algunas funciones criptográficas avanzadas. Incluyen [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), y [sha256sum](#sha256sum). ### sha1sum La función `sha1sum` recibe una cadena y calcula su resumen SHA1. ``` sha1sum "Hello world!" ``` ### sha256sum La función `sha256sum` recibe una cadena y calcula su resumen SHA256. ``` sha256sum "Hello world!" ``` Lo anterior calculará la suma SHA 256 en un formato "blindado ASCII" que es seguro para imprimir. ### adler32sum La función `adler32sum` recibe una cadena y calcula su suma de verificación Adler-32. ``` adler32sum "Hello world!" ``` ### htpasswd La función `htpasswd` toma un `username` y `password` y genera un hash `bcrypt` de la contraseña. El resultado puede usarse para autenticación básica en un [Servidor HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Note que es inseguro almacenar la contraseña directamente en la plantilla. ### randBytes La función randBytes acepta un conteo N y genera una secuencia aleatoria criptográficamente segura (usa crypto/rand) de N bytes. La secuencia se devuelve como una cadena codificada en base64. ``` randBytes 24 ``` ### derivePassword La función `derivePassword` puede usarse para derivar una contraseña específica basada en algunas restricciones de "contraseña maestra" compartidas. El algoritmo para esto está [bien especificado](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Note que se considera inseguro almacenar las partes directamente en la plantilla. ### genPrivateKey La función `genPrivateKey` genera una nueva clave privada codificada en un bloque PEM. Toma uno de los valores para su primer parámetro: - `ecdsa`: Genera una clave DSA de curva elíptica (P256) - `dsa`: Genera una clave DSA (L2048N256) - `rsa`: Genera una clave RSA 4096 ### buildCustomCert La función `buildCustomCert` permite personalizar el certificado. Toma los siguientes parámetros de cadena: - Un certificado en formato PEM codificado en base64 - Una clave privada en formato PEM codificada en base64 Devuelve un objeto de certificado con los siguientes atributos: - `Cert`: Un certificado codificado en PEM - `Key`: Una clave privada codificada en PEM Ejemplo: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Note que el objeto devuelto puede pasarse a la función `genSignedCert` para firmar un certificado usando esta CA. ### genCA La función `genCA` genera una nueva autoridad de certificación x509 autofirmada. Toma los siguientes parámetros: - Nombre común del sujeto (cn) - Duración de validez del certificado en días Devuelve un objeto con los siguientes atributos: - `Cert`: Un certificado codificado en PEM - `Key`: Una clave privada codificada en PEM Ejemplo: ``` $ca := genCA "foo-ca" 365 ``` Note que el objeto devuelto puede pasarse a la función `genSignedCert` para firmar un certificado usando esta CA. ### genSelfSignedCert La función `genSelfSignedCert` genera un nuevo certificado x509 autofirmado. Toma los siguientes parámetros: - Nombre común del sujeto (cn) - Lista opcional de IPs; puede ser nil - Lista opcional de nombres DNS alternativos; puede ser nil - Duración de validez del certificado en días Devuelve un objeto con los siguientes atributos: - `Cert`: Un certificado codificado en PEM - `Key`: Una clave privada codificada en PEM Ejemplo: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert La función `genSignedCert` genera un nuevo certificado x509 firmado por la CA especificada. Toma los siguientes parámetros: - Nombre común del sujeto (cn) - Lista opcional de IPs; puede ser nil - Lista opcional de nombres DNS alternativos; puede ser nil - Duración de validez del certificado en días - CA (ver `genCA`) Ejemplo: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES La función `encryptAES` cifra texto con AES-256 CBC y devuelve una cadena codificada en base64. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES La función `decryptAES` recibe una cadena base64 codificada por el algoritmo AES-256 CBC y devuelve el texto descifrado. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Funciones de Fecha Helm incluye las siguientes funciones de fecha que puede usar en plantillas: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate), y [unixEpoch](#unixepoch). ### now La fecha/hora actual. Use esto en conjunto con otras funciones de fecha. ### ago La función `ago` devuelve la duración desde un momento en el tiempo. Ahora en resolución de segundos. ``` ago .CreatedAt ``` devuelve en formato String() de `time.Duration` ``` 2h34m7s ``` ### date La función `date` formatea una fecha. Formatear la fecha a AÑO-MES-DÍA: ``` now | date "2006-01-02" ``` El formateo de fechas en Go es [un poco diferente](https://pauladamsmith.com/blog/2011/05/go_time.html). En resumen, tome esto como la fecha base: ``` Mon Jan 2 15:04:05 MST 2006 ``` Escríbala en el formato que desee. Arriba, `2006-01-02` es la misma fecha, pero en el formato que queremos. ### dateInZone Igual que `date`, pero con una zona horaria. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formatea una cantidad dada de segundos como `time.Duration`. Esto devuelve 1m35s ``` duration "95" ``` ### durationRound Redondea una duración dada a la unidad más significativa. Las cadenas y `time.Duration` se parsean como duración, mientras que un `time.Time` se calcula como la duración desde entonces. Esto devuelve 2h ``` durationRound "2h10m5s" ``` Esto devuelve 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Devuelve los segundos desde el epoch unix para un `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify `dateModify` toma una modificación y una fecha y devuelve la marca de tiempo. Restar una hora y treinta minutos del tiempo actual: ``` now | dateModify "-1.5h" ``` Si el formato de modificación es incorrecto, `dateModify` devolverá la fecha sin modificar. `mustDateModify` devolverá un error en su lugar. ### htmlDate La función `htmlDate` formatea una fecha para insertarla en un campo de entrada de selector de fecha HTML. ``` now | htmlDate ``` ### htmlDateInZone Igual que htmlDate, pero con una zona horaria. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` convierte una cadena a una fecha. El primer argumento es el layout de fecha y el segundo la cadena de fecha. Si la cadena no puede convertirse, devuelve el valor cero. `mustToDate` devolverá un error en caso de que la cadena no pueda convertirse. Esto es útil cuando desea convertir una cadena de fecha a otro formato (usando pipe). El ejemplo siguiente convierte "2017-12-31" a "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Funciones de Diccionarios y Dict Helm proporciona un tipo de almacenamiento clave/valor llamado `dict` (abreviatura de "dictionary", como en Python). Un `dict` es un tipo _no ordenado_. La clave de un diccionario **debe ser una cadena**. Sin embargo, el valor puede ser de cualquier tipo, incluso otro `dict` o `list`. A diferencia de las `list`s, los `dict`s no son inmutables. Las funciones `set` y `unset` modificarán el contenido de un diccionario. Helm proporciona las siguientes funciones para trabajar con dicts: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), y [values](#values). ### dict La creación de diccionarios se hace llamando a la función `dict` y pasándole una lista de pares. Lo siguiente crea un diccionario con tres elementos: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Dado un mapa y una clave, obtiene el valor del mapa. ``` get $myDict "name1" ``` Lo anterior devuelve `"value1"` Note que si la clave no se encuentra, esta operación simplemente devolverá `""`. No se generará ningún error. ### set Use `set` para agregar un nuevo par clave/valor a un diccionario. ``` $_ := set $myDict "name4" "value4" ``` Note que `set` _devuelve el diccionario_ (un requisito de las funciones de plantilla de Go), por lo que puede necesitar capturar el valor como se hizo arriba con la asignación `$_`. ### unset Dado un mapa y una clave, elimina la clave del mapa. ``` $_ := unset $myDict "name4" ``` Al igual que con `set`, esto devuelve el diccionario. Note que si la clave no se encuentra, esta operación simplemente retornará. No se generará ningún error. ### hasKey La función `hasKey` devuelve `true` si el dict dado contiene la clave dada. ``` hasKey $myDict "name1" ``` Si la clave no se encuentra, devuelve `false`. ### pluck La función `pluck` hace posible dar una clave y múltiples mapas, y obtener una lista de todas las coincidencias: ``` pluck "name1" $myDict $myOtherDict ``` Lo anterior devolverá una `list` que contiene cada valor encontrado (`[value1 otherValue1]`). Si la clave dada _no se encuentra_ en un mapa, ese mapa no tendrá un elemento en la lista (y la longitud de la lista devuelta será menor que el número de dicts en la llamada a `pluck`). Si la clave _se encuentra_ pero el valor es un valor vacío, ese valor se insertará. Un patrón común en las plantillas de Helm es usar `pluck... | first` para obtener la primera clave coincidente de una colección de diccionarios. ### dig La función `dig` recorre un conjunto anidado de dicts, seleccionando claves de una lista de valores. Devuelve un valor por defecto si alguna de las claves no se encuentra en el dict asociado. ``` dig "user" "role" "humanName" "guest" $dict ``` Dado un dict estructurado como ``` { user: { role: { humanName: "curator" } } } ``` lo anterior devolvería `"curator"`. Si el dict careciera incluso de un campo `user`, el resultado sería `"guest"`. Dig puede ser muy útil en casos donde le gustaría evitar cláusulas de guardia, especialmente ya que el `and` del paquete de plantillas de Go no hace cortocircuito. Por ejemplo `and a.maybeNil a.maybeNil.iNeedThis` siempre evaluará `a.maybeNil.iNeedThis`, y entrará en pánico si `a` carece de un campo `maybeNil`.) `dig` acepta su argumento dict al final para soportar pipelining. Por ejemplo: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Combina dos o más diccionarios en uno, dando precedencia al diccionario de destino: Dado: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` resultará en: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` Esta es una operación de combinación profunda pero no una operación de copia profunda. Los objetos anidados que se combinan son la misma instancia en ambos dicts. Si desea una copia profunda junto con la combinación, entonces use la función `deepCopy` junto con la combinación. Por ejemplo, ``` deepCopy $source | merge $dest ``` `mustMerge` devolverá un error en caso de una combinación fallida. ### mergeOverwrite, mustMergeOverwrite Combina dos o más diccionarios en uno, dando precedencia de **derecha a izquierda**, sobrescribiendo efectivamente valores en el diccionario de destino: Dado: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` resultará en: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` Esta es una operación de combinación profunda pero no una operación de copia profunda. Los objetos anidados que se combinan son la misma instancia en ambos dicts. Si desea una copia profunda junto con la combinación, entonces use la función `deepCopy` junto con la combinación. Por ejemplo, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` devolverá un error en caso de una combinación fallida. ### keys La función `keys` devolverá una `list` de todas las claves en uno o más tipos `dict`. Dado que un diccionario está _desordenado_, las claves no estarán en un orden predecible. Pueden ordenarse con `sortAlpha`. ``` keys $myDict | sortAlpha ``` Al proporcionar múltiples diccionarios, las claves se concatenarán. Use la función `uniq` junto con `sortAlpha` para obtener una lista única y ordenada de claves. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick La función `pick` selecciona solo las claves dadas de un diccionario, creando un nuevo `dict`. ``` $new := pick $myDict "name1" "name2" ``` Lo anterior devuelve `{name1: value1, name2: value2}` ### omit La función `omit` es similar a `pick`, excepto que devuelve un nuevo `dict` con todas las claves que _no coinciden_ con las claves dadas. ``` $new := omit $myDict "name1" "name3" ``` Lo anterior devuelve `{name2: value2}` ### values La función `values` es similar a `keys`, excepto que devuelve una nueva `list` con todos los valores del `dict` fuente (solo se soporta un diccionario). ``` $vals := values $myDict ``` Lo anterior devuelve `list["value1", "value2", "value 3"]`. Note que la función `values` no da garantías sobre el orden del resultado; si le importa esto, entonces use `sortAlpha`. ### deepCopy, mustDeepCopy Las funciones `deepCopy` y `mustDeepCopy` toman un valor y hacen una copia profunda del valor. Esto incluye dicts y otras estructuras. `deepCopy` entra en pánico cuando hay un problema, mientras que `mustDeepCopy` devuelve un error al sistema de plantillas cuando hay un error. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Una Nota sobre los Internos de Dict Un `dict` se implementa en Go como un `map[string]interface{}`. Los desarrolladores de Go pueden pasar valores `map[string]interface{}` al contexto para hacerlos disponibles a las plantillas como `dict`s. ## Funciones de Codificación Helm tiene las siguientes funciones de codificación y decodificación: - `b64enc`/`b64dec`: Codificar o decodificar con Base64 - `b32enc`/`b32dec`: Codificar o decodificar con Base32 ## Funciones de Listas y List Helm proporciona un tipo `list` simple que puede contener listas secuenciales arbitrarias de datos. Esto es similar a arreglos o slices, pero las listas están diseñadas para ser usadas como tipos de datos inmutables. Crear una lista de enteros: ``` $myList := list 1 2 3 4 5 ``` Lo anterior crea una lista de `[1 2 3 4 5]`. Helm proporciona las siguientes funciones de lista: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), y [without (mustWithout)](#without-mustwithout). ### first, mustFirst Para obtener el primer elemento de una lista, use `first`. `first $myList` devuelve `1` `first` entra en pánico si hay un problema, mientras que `mustFirst` devuelve un error al motor de plantillas si hay un problema. ### rest, mustRest Para obtener la cola de la lista (todo excepto el primer elemento), use `rest`. `rest $myList` devuelve `[2 3 4 5]` `rest` entra en pánico si hay un problema, mientras que `mustRest` devuelve un error al motor de plantillas si hay un problema. ### last, mustLast Para obtener el último elemento de una lista, use `last`: `last $myList` devuelve `5`. Esto es aproximadamente análogo a invertir una lista y luego llamar a `first`. ### initial, mustInitial Esto complementa a `last` devolviendo todo _excepto_ el último elemento. `initial $myList` devuelve `[1 2 3 4]`. `initial` entra en pánico si hay un problema, mientras que `mustInitial` devuelve un error al motor de plantillas si hay un problema. ### append, mustAppend Agrega un nuevo elemento a una lista existente, creando una nueva lista. ``` $new = append $myList 6 ``` Lo anterior establecería `$new` a `[1 2 3 4 5 6]`. `$myList` permanecería sin cambios. `append` entra en pánico si hay un problema, mientras que `mustAppend` devuelve un error al motor de plantillas si hay un problema. ### prepend, mustPrepend Inserta un elemento al principio de una lista, creando una nueva lista. ``` prepend $myList 0 ``` Lo anterior produciría `[0 1 2 3 4 5]`. `$myList` permanecería sin cambios. `prepend` entra en pánico si hay un problema, mientras que `mustPrepend` devuelve un error al motor de plantillas si hay un problema. ### concat Concatena un número arbitrario de listas en una. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` Lo anterior produciría `[1 2 3 4 5 6 7 8]`. `$myList` permanecería sin cambios. ### reverse, mustReverse Produce una nueva lista con los elementos invertidos de la lista dada. ``` reverse $myList ``` Lo anterior generaría la lista `[5 4 3 2 1]`. `reverse` entra en pánico si hay un problema, mientras que `mustReverse` devuelve un error al motor de plantillas si hay un problema. ### uniq, mustUniq Genera una lista con todos los duplicados eliminados. ``` list 1 1 1 2 | uniq ``` Lo anterior produciría `[1 2]` `uniq` entra en pánico si hay un problema, mientras que `mustUniq` devuelve un error al motor de plantillas si hay un problema. ### without, mustWithout La función `without` filtra elementos de una lista. ``` without $myList 3 ``` Lo anterior produciría `[1 2 4 5]` `without` puede tomar más de un filtro: ``` without $myList 1 3 5 ``` Eso produciría `[2 4]` `without` entra en pánico si hay un problema, mientras que `mustWithout` devuelve un error al motor de plantillas si hay un problema. ### has, mustHas Prueba si una lista tiene un elemento particular. ``` has 4 $myList ``` Lo anterior devolvería `true`, mientras que `has "hello" $myList` devolvería false. `has` entra en pánico si hay un problema, mientras que `mustHas` devuelve un error al motor de plantillas si hay un problema. ### compact, mustCompact Acepta una lista y elimina entradas con valores vacíos. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` devolverá una nueva lista con el elemento vacío (es decir, "") eliminado. `compact` entra en pánico si hay un problema y `mustCompact` devuelve un error al motor de plantillas si hay un problema. ### index Para obtener el elemento n-ésimo de una lista, use `index list [n]`. Para indexar en listas multidimensionales, use `index list [n] [m] ...` - `index $myList 0` devuelve `1`. Es lo mismo que `myList[0]` - `index $myList 0 1` sería lo mismo que `myList[0][1]` ### slice, mustSlice Para obtener elementos parciales de una lista, use `slice list [n] [m]`. Es equivalente a `list[n:m]`. - `slice $myList` devuelve `[1 2 3 4 5]`. Es lo mismo que `myList[:]`. - `slice $myList 3` devuelve `[4 5]`. Es lo mismo que `myList[3:]`. - `slice $myList 1 3` devuelve `[2 3]`. Es lo mismo que `myList[1:3]`. - `slice $myList 0 3` devuelve `[1 2 3]`. Es lo mismo que `myList[:3]`. `slice` entra en pánico si hay un problema, mientras que `mustSlice` devuelve un error al motor de plantillas si hay un problema. ### until La función `until` construye un rango de enteros. ``` until 5 ``` Lo anterior genera la lista `[0, 1, 2, 3, 4]`. Esto es útil para iterar con `range $i, $e := until 5`. ### untilStep Como `until`, `untilStep` genera una lista de enteros contando. Pero le permite definir un inicio, fin y paso: ``` untilStep 3 6 2 ``` Lo anterior producirá `[3 5]` comenzando con 3 y sumando 2 hasta que sea igual o mayor que 6. Esto es similar a la función `range` de Python. ### seq Funciona como el comando `seq` de bash. * 1 parámetro (fin) - generará todos los enteros contando entre 1 y `fin` inclusive. * 2 parámetros (inicio, fin) - generará todos los enteros contando entre `inicio` y `fin` inclusive incrementando o decrementando en 1. * 3 parámetros (inicio, paso, fin) - generará todos los enteros contando entre `inicio` y `fin` inclusive incrementando o decrementando en `paso`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Para dividir una lista en fragmentos de un tamaño dado, use `chunk size list`. Esto es útil para paginación. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` Esto produce una lista de listas `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Funciones Matemáticas Todas las funciones matemáticas operan con valores `int64` a menos que se especifique lo contrario. Las siguientes funciones matemáticas están disponibles: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), y [sub](#sub). ### add Suma números con `add`. Acepta dos o más entradas. ``` add 1 2 3 ``` ### add1 Para incrementar en 1, use `add1`. ### sub Para restar, use `sub`. ### div Realiza división entera con `div`. ### mod Módulo con `mod`. ### mul Multiplica con `mul`. Acepta dos o más entradas. ``` mul 1 2 3 ``` ### max Devuelve el mayor de una serie de enteros. Esto devolverá `3`: ``` max 1 2 3 ``` ### min Devuelve el menor de una serie de enteros. `min 1 2 3` devolverá `1`. ### len Devuelve la longitud del argumento como un entero. ``` len .Arg ``` ## Funciones Matemáticas de Punto Flotante Todas las funciones matemáticas operan con valores `float64`. ### addf Suma números con `addf` Esto devolverá `5.5`: ``` addf 1.5 2 2 ``` ### add1f Para incrementar en 1, use `add1f` ### subf Para restar, use `subf` Esto es equivalente a `7.5 - 2 - 3` y devolverá `2.5`: ``` subf 7.5 2 3 ``` ### divf Realiza división con `divf` Esto es equivalente a `10 / 2 / 4` y devolverá `1.25`: ``` divf 10 2 4 ``` ### mulf Multiplica con `mulf` Esto devolverá `6`: ``` mulf 1.5 2 2 ``` ### maxf Devuelve el mayor de una serie de flotantes: Esto devolverá `3`: ``` maxf 1 2.5 3 ``` ### minf Devuelve el menor de una serie de flotantes. Esto devolverá `1.5`: ``` minf 1.5 2 3 ``` ### floor Devuelve el mayor valor flotante menor o igual al valor de entrada. `floor 123.9999` devolverá `123.0`. ### ceil Devuelve el mayor valor flotante mayor o igual al valor de entrada. `ceil 123.001` devolverá `124.0`. ### round Devuelve un valor flotante con el resto redondeado al número dado de dígitos después del punto decimal. `round 123.555555 3` devolverá `123.556`. ## Funciones de Red Helm tiene una única función de red, `getHostByName`. `getHostByName` recibe un nombre de dominio y devuelve la dirección ip. `getHostByName "www.google.com"` devolvería la dirección ip correspondiente de `www.google.com`. Esta función requiere que se pase la opción `--enable-dns` en la línea de comandos de helm. ## Funciones de Rutas de Archivos Aunque las funciones de plantilla de Helm no otorgan acceso al sistema de archivos, sí proporcionan funciones para trabajar con cadenas que siguen convenciones de rutas de archivos. Estas incluyen [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), e [isAbs](#isabs). ### base Devuelve el último elemento de una ruta. ``` base "foo/bar/baz" ``` Lo anterior imprime "baz". ### dir Devuelve el directorio, eliminando la última parte de la ruta. Así que `dir "foo/bar/baz"` devuelve `foo/bar`. ### clean Limpia una ruta. ``` clean "foo/bar/../baz" ``` Lo anterior resuelve el `..` y devuelve `foo/baz`. ### ext Devuelve la extensión del archivo. ``` ext "foo.bar" ``` Lo anterior devuelve `.bar`. ### isAbs Para verificar si una ruta de archivo es absoluta, use `isAbs`. ## Funciones de Reflexión Helm proporciona herramientas de reflexión rudimentarias. Estas ayudan a los desarrolladores avanzados de plantillas a entender la información de tipo de Go subyacente para un valor particular. Helm está escrito en Go y tiene tipado fuerte. El sistema de tipos aplica dentro de las plantillas. Go tiene varios _kinds_ primitivos, como `string`, `slice`, `int64`, y `bool`. Go tiene un sistema de _tipos_ abierto que permite a los desarrolladores crear sus propios tipos. Helm proporciona un conjunto de funciones para cada uno a través de [funciones kind](#funciones-kind) y [funciones type](#funciones-type). También se proporciona una función [deepEqual](#deepequal) para comparar dos valores. ### Funciones Kind Hay dos funciones Kind: `kindOf` devuelve el kind de un objeto. ``` kindOf "hello" ``` Lo anterior devolvería `string`. Para pruebas simples (como en bloques `if`), la función `kindIs` le permitirá verificar que un valor es de un kind particular: ``` kindIs "int" 123 ``` Lo anterior devolverá `true`. ### Funciones Type Los tipos son ligeramente más difíciles de trabajar, por lo que hay tres funciones diferentes: - `typeOf` devuelve el tipo subyacente de un valor: `typeOf $foo` - `typeIs` es como `kindIs`, pero para tipos: `typeIs "*io.Buffer" $myVal` - `typeIsLike` funciona como `typeIs`, excepto que también desreferencia punteros **Nota:** Ninguna de estas puede probar si algo implementa una interfaz dada, ya que hacerlo requeriría compilar la interfaz por adelantado. ### deepEqual `deepEqual` devuelve true si dos valores son ["profundamente iguales"](https://golang.org/pkg/reflect/#DeepEqual) Funciona también para tipos no primitivos (comparado con el `eq` incorporado). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` Lo anterior devolverá `true`. ## Funciones de Versiones Semánticas Algunos esquemas de versiones son fácilmente parseables y comparables. Helm proporciona funciones para trabajar con versiones [SemVer 2](http://semver.org). Estas incluyen [semver](#semver) y [semverCompare](#semvercompare). A continuación también encontrará detalles sobre el uso de rangos para comparaciones. ### semver La función `semver` parsea una cadena en una Versión Semántica: ``` $version := semver "1.2.3-alpha.1+123" ``` _Si el parser falla, causará que la ejecución de la plantilla se detenga con un error._ En este punto, `$version` es un puntero a un objeto `Version` con las siguientes propiedades: - `$version.Major`: El número mayor (`1` arriba) - `$version.Minor`: El número menor (`2` arriba) - `$version.Patch`: El número de parche (`3` arriba) - `$version.Prerelease`: El prerelease (`alpha.1` arriba) - `$version.Metadata`: Los metadatos de compilación (`123` arriba) - `$version.Original`: La versión original como cadena Además, puede comparar una `Version` con otra `version` usando la función `Compare`: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` Lo anterior devolverá `-1`. Los valores de retorno son: - `-1` si la semver dada es mayor que la semver cuyo método `Compare` fue llamado - `1` si la versión cuya función `Compare` fue llamada es mayor. - `0` si son la misma versión (Note que en SemVer, el campo `Metadata` no se compara durante las operaciones de comparación de versiones.) ### semverCompare Se proporciona una función de comparación más robusta como `semverCompare`. Esta versión soporta rangos de versiones: - `semverCompare "1.2.3" "1.2.3"` comprueba una coincidencia exacta - `semverCompare "~1.2.0" "1.2.3"` comprueba que las versiones mayor y menor coincidan, y que el número de parche de la segunda versión sea _mayor o igual al_ primer parámetro. Las funciones SemVer usan la [biblioteca semver de Masterminds](https://github.com/Masterminds/semver), de los creadores de Sprig. ### Comparaciones Básicas Hay dos elementos en las comparaciones. Primero, una cadena de comparación es una lista de comparaciones AND separadas por espacios o comas. Estas luego se separan por || (OR) comparaciones. Por ejemplo, `">= 1.2 < 3.0.0 || >= 4.2.3"` busca una comparación que sea mayor o igual a 1.2 y menor que 3.0.0 o sea mayor o igual a 4.2.3. Las comparaciones básicas son: - `=`: igual (alias de ningún operador) - `!=`: no igual - `>`: mayor que - `<`: menor que - `>=`: mayor o igual que - `<=`: menor o igual que ### Trabajando con Versiones Prerelease Los prereleases, para aquellos no familiarizados con ellos, se usan para lanzamientos de software antes de lanzamientos estables o disponibles de forma general. Ejemplos de prereleases incluyen lanzamientos de desarrollo, alpha, beta y release candidate. Un prerelease puede ser una versión como `1.2.3-beta.1`, mientras que el lanzamiento estable sería `1.2.3`. En el orden de precedencia, los prereleases vienen antes de sus lanzamientos asociados. En este ejemplo `1.2.3-beta.1 < 1.2.3`. Según la especificación de Versiones Semánticas, los prereleases pueden no ser compatibles con la API de su contraparte de lanzamiento. Dice, > Una versión prerelease indica que la versión es inestable y podría no > satisfacer los requisitos de compatibilidad previstos como lo denota su > versión normal asociada. Las comparaciones de SemVer usando restricciones sin un comparador de prerelease omitirán las versiones prerelease. Por ejemplo, `>=1.2.3` omitirá prereleases al buscar en una lista de lanzamientos, mientras que `>=1.2.3-0` evaluará y encontrará prereleases. La razón del `0` como versión prerelease en la comparación de ejemplo es porque los prereleases solo pueden contener alfanuméricos ASCII y guiones (junto con separadores `.`), según la especificación. El ordenamiento ocurre en orden ASCII, nuevamente según la especificación. El carácter más bajo es un `0` en el orden ASCII (vea una [Tabla ASCII](http://www.asciitable.com/)) Entender el ordenamiento ASCII es importante porque A-Z viene antes de a-z. Eso significa que `>=1.2.3-BETA` devolverá `1.2.3-alpha`. Lo que podría esperar de la sensibilidad a mayúsculas no aplica aquí. Esto se debe al ordenamiento ASCII que es lo que la especificación indica. ### Comparaciones de Rango con Guion Hay múltiples métodos para manejar rangos y el primero son los rangos con guion. Estos se ven así: - `1.2 - 1.4.5` que es equivalente a `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` que es equivalente a `>= 2.3.4 <= 4.5` ### Comodines en Comparaciones Los caracteres `x`, `X`, y `*` pueden usarse como comodines. Esto funciona para todos los operadores de comparación. Cuando se usa en el operador `=` se retrocede al nivel de comparación de parche (ver tilde abajo). Por ejemplo, - `1.2.x` es equivalente a `>= 1.2.0, < 1.3.0` - `>= 1.2.x` es equivalente a `>= 1.2.0` - `<= 2.x` es equivalente a `< 3` - `*` es equivalente a `>= 0.0.0` ### Comparaciones de Rango Tilde (Parche) El operador de comparación tilde (`~`) es para rangos a nivel de parche cuando se especifica una versión menor y cambios a nivel mayor cuando falta el número menor. Por ejemplo, - `~1.2.3` es equivalente a `>= 1.2.3, < 1.3.0` - `~1` es equivalente a `>= 1, < 2` - `~2.3` es equivalente a `>= 2.3, < 2.4` - `~1.2.x` es equivalente a `>= 1.2.0, < 1.3.0` - `~1.x` es equivalente a `>= 1, < 2` ### Comparaciones de Rango Circunflejo (Mayor) El operador de comparación circunflejo (`^`) es para cambios a nivel mayor una vez que ha ocurrido un lanzamiento estable (1.0.0). Antes de un lanzamiento 1.0.0, las versiones menores actúan como el nivel de estabilidad de la API. Esto es útil cuando las comparaciones de versiones de API como un cambio mayor es un cambio que rompe la API. Por ejemplo, - `^1.2.3` es equivalente a `>= 1.2.3, < 2.0.0` - `^1.2.x` es equivalente a `>= 1.2.0, < 2.0.0` - `^2.3` es equivalente a `>= 2.3, < 3` - `^2.x` es equivalente a `>= 2.0.0, < 3` - `^0.2.3` es equivalente a `>=0.2.3 <0.3.0` - `^0.2` es equivalente a `>=0.2.0 <0.3.0` - `^0.0.3` es equivalente a `>=0.0.3 <0.0.4` - `^0.0` es equivalente a `>=0.0.0 <0.1.0` - `^0` es equivalente a `>=0.0.0 <1.0.0` ## Funciones de URL Helm incluye las funciones [urlParse](#urlparse), [urlJoin](#urljoin), y [urlquery](#urlquery) que le permiten trabajar con partes de URL. ### urlParse Parsea una cadena para URL y produce un dict con las partes de la URL ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` Lo anterior devuelve un dict, conteniendo un objeto URL: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Esto se implementa usando los paquetes URL de la biblioteca estándar de Go. Para más información, consulte https://golang.org/pkg/net/url/#URL ### urlJoin Une un mapa (producido por `urlParse`) para producir una cadena URL ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` Lo anterior devuelve la siguiente cadena: ``` http://host:80/path?query#fragment ``` ### urlquery Devuelve la versión escapada del valor pasado como argumento para que sea adecuado para incrustar en la parte de query de una URL. ``` $var := urlquery "string for query" ``` ## Funciones de UUID Helm puede generar IDs universalmente únicos UUID v4. ``` uuidv4 ``` Lo anterior devuelve un nuevo UUID del tipo v4 (generado aleatoriamente). ## Funciones de Kubernetes y Chart Helm incluye funciones para trabajar con Kubernetes incluyendo [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#funciones-de-archivos), y [lookup](#lookup). ### lookup `lookup` se usa para buscar recursos en un clúster en ejecución. Cuando se usa con el comando `helm template` siempre devuelve una respuesta vacía. Puede encontrar más detalles en la [documentación sobre la función lookup](./functions_and_pipelines.md#uso-de-la-función-lookup). ### .Capabilities.APIVersions.Has Devuelve si una versión de API o recurso está disponible en un clúster. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Más información está disponible en la [documentación de objetos incorporados](./builtin_objects.md). ### Funciones de Archivos Hay varias funciones que le permiten acceder a archivos no especiales dentro de un chart. Por ejemplo, para acceder a archivos de configuración de aplicaciones. Estas están documentadas en [Acceder a Archivos Dentro de Plantillas](./accessing_files.md). _Nota, la documentación para muchas de estas funciones proviene de [Sprig](https://github.com/Masterminds/sprig). Sprig es una biblioteca de funciones de plantilla disponible para aplicaciones Go._ ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Funciones de Plantilla y Pipelines description: Uso de funciones en plantillas. sidebar_position: 5 --- Hasta ahora, hemos visto cómo colocar información en una plantilla. Pero esa información se coloca en la plantilla sin modificar. A veces queremos transformar los datos suministrados de una manera que nos sea más útil. Comencemos con una mejor práctica: Al inyectar cadenas del objeto `.Values` en la plantilla, debemos ponerlas entre comillas. Podemos hacer esto llamando a la función `quote` en la directiva de plantilla: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Las funciones de plantilla siguen la sintaxis `functionName arg1 arg2...`. En el fragmento anterior, `quote .Values.favorite.drink` llama a la función `quote` y le pasa un solo argumento. Helm tiene más de 60 funciones disponibles. Algunas de ellas están definidas por el propio [lenguaje de plantillas de Go](https://godoc.org/text/template). La mayoría de las demás son parte de la [biblioteca de plantillas Sprig](https://masterminds.github.io/sprig/). Veremos muchas de ellas a medida que avancemos a través de los ejemplos. > Aunque hablamos del "lenguaje de plantillas de Helm" como si fuera específico > de Helm, en realidad es una combinación del lenguaje de plantillas de Go, > algunas funciones adicionales y una variedad de wrappers para exponer ciertos > objetos a las plantillas. Muchos recursos sobre plantillas de Go pueden ser > útiles mientras aprende sobre plantillas. ## Pipelines Una de las características más poderosas del lenguaje de plantillas es su concepto de _pipelines_. Inspirándose en un concepto de UNIX, los pipelines son una herramienta para encadenar una serie de comandos de plantilla y expresar de manera compacta una serie de transformaciones. En otras palabras, los pipelines son una forma eficiente de realizar varias operaciones en secuencia. Reescribamos el ejemplo anterior usando un pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` En este ejemplo, en lugar de llamar a `quote ARGUMENT`, invertimos el orden. "Enviamos" el argumento a la función usando un pipeline (`|`): `.Values.favorite.drink | quote`. Usando pipelines, podemos encadenar varias funciones juntas: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Invertir el orden es una práctica común en plantillas. Verá `.val | quote` más > a menudo que `quote .val`. Cualquiera de las dos prácticas está bien. Cuando se evalúa, esa plantilla producirá esto: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Note que nuestra `pizza` original ahora se ha transformado a `"PIZZA"`. Cuando se encadenan argumentos de esta manera, el resultado de la primera evaluación (`.Values.favorite.drink`) se envía como el _último argumento de la función_. Podemos modificar el ejemplo de bebida anterior para ilustrar con una función que toma dos argumentos: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` La función `repeat` repetirá la cadena dada el número de veces indicado, por lo que obtendremos esta salida: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Uso de la función `default` Una función que se usa con frecuencia en plantillas es la función `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Esta función le permite especificar un valor por defecto dentro de la plantilla, en caso de que el valor sea omitido. Usémosla para modificar el ejemplo de bebida anterior: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Si ejecutamos esto de manera normal, obtendremos nuestro `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Ahora, eliminaremos la configuración de bebida favorita de `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Ahora volver a ejecutar `helm install --dry-run --debug fair-worm ./mychart` producirá este YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` En un chart real, todos los valores por defecto estáticos deben estar en el `values.yaml`, y no deben repetirse usando el comando `default` (de lo contrario serían redundantes). Sin embargo, el comando `default` es perfecto para valores calculados, que no pueden declararse dentro de `values.yaml`. Por ejemplo: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` En algunos lugares, una condición `if` puede ser más adecuada que `default`. Veremos eso en la siguiente sección. Las funciones y pipelines de plantilla son una forma poderosa de transformar información y luego insertarla en su YAML. Pero a veces es necesario agregar algo de lógica de plantilla que sea un poco más sofisticada que simplemente insertar una cadena. En la siguiente sección veremos las estructuras de control proporcionadas por el lenguaje de plantillas. ## Uso de la función `lookup` La función `lookup` se puede usar para _buscar_ recursos en un clúster en ejecución. La sinopsis de la función lookup es `lookup apiVersion, kind, namespace, name -> resource or resource list`. | parámetro | tipo | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Tanto `name` como `namespace` son opcionales y pueden pasarse como una cadena vacía (`""`). Sin embargo, si está trabajando con un recurso con ámbito de namespace, tanto `name` como `namespace` deben especificarse. Las siguientes combinaciones de parámetros son posibles: | Comportamiento | Función lookup | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Cuando `lookup` devuelve un objeto, devolverá un diccionario. Este diccionario se puede navegar posteriormente para extraer valores específicos. El siguiente ejemplo devolverá las anotaciones presentes para el objeto `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Cuando `lookup` devuelve una lista de objetos, es posible acceder a la lista de objetos a través del campo `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` Cuando no se encuentra ningún objeto, se devuelve un valor vacío. Esto se puede usar para verificar la existencia de un objeto. La función `lookup` usa la configuración de conexión de Kubernetes existente de Helm para consultar Kubernetes. Si se devuelve algún error al interactuar con el servidor de API (por ejemplo, debido a falta de permiso para acceder a un recurso), el procesamiento de plantillas de Helm fallará. Tenga en cuenta que Helm no está diseñado para contactar al servidor de API de Kubernetes durante una operación `helm template|install|upgrade|delete|rollback --dry-run`. Para probar `lookup` contra un clúster en ejecución, debe usar `helm template|install|upgrade|delete|rollback --dry-run=server` en su lugar, lo que permite la conexión al clúster. ## Los operadores son funciones Para las plantillas, los operadores (`eq`, `ne`, `lt`, `gt`, `and`, `or` y demás) están todos implementados como funciones. En pipelines, las operaciones se pueden agrupar con paréntesis (`(` y `)`). Ahora podemos pasar de funciones y pipelines al control de flujo con condiciones, bucles y modificadores de alcance. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Primeros Pasos description: Una guía rápida sobre plantillas de Chart. sidebar_position: 2 --- En esta sección de la guía, crearemos un chart y luego agregaremos una primera plantilla. El chart que creamos aquí se usará durante el resto de la guía. Para comenzar, echemos un vistazo rápido a un chart de Helm. ## Charts Como se describe en la [Guía de Charts](/topics/charts.md), los charts de Helm están estructurados así: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` El directorio `templates/` es para archivos de plantilla. Cuando Helm evalúa un chart, envía todos los archivos del directorio `templates/` a través del motor de renderizado de plantillas. Luego recopila los resultados de esas plantillas y los envía a Kubernetes. El archivo `values.yaml` también es importante para las plantillas. Este archivo contiene los _valores por defecto_ de un chart. Estos valores pueden ser sobrescritos por los usuarios durante `helm install` o `helm upgrade`. El archivo `Chart.yaml` contiene una descripción del chart. Puede acceder a él desde dentro de una plantilla. El directorio `charts/` _puede_ contener otros charts (que llamamos _subcharts_). Más adelante en esta guía veremos cómo funcionan cuando se trata de renderizado de plantillas. ## Un Chart Inicial Para esta guía, crearemos un chart simple llamado `mychart`, y luego crearemos algunas plantillas dentro del chart. ```console $ helm create mychart Creating mychart ``` ### Un Vistazo Rápido a `mychart/templates/` Si observa el directorio `mychart/templates/`, notará que ya hay algunos archivos allí. - `NOTES.txt`: El "texto de ayuda" para su chart. Se mostrará a los usuarios cuando ejecuten `helm install`. - `deployment.yaml`: Un manifiesto básico para crear un [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) de Kubernetes - `service.yaml`: Un manifiesto básico para crear un [endpoint de servicio](https://kubernetes.io/docs/concepts/services-networking/service/) para su deployment - `_helpers.tpl`: Un lugar para colocar helpers de plantilla que puede reutilizar en todo el chart Y lo que vamos a hacer es... _¡eliminarlos todos!_ De esta manera podemos trabajar en nuestro tutorial desde cero. En realidad, crearemos nuestros propios `NOTES.txt` y `_helpers.tpl` a medida que avancemos. ```console $ rm -rf mychart/templates/* ``` Cuando esté escribiendo charts de nivel de producción, tener versiones básicas de estos archivos puede ser muy útil. Así que en su trabajo diario de creación de charts, probablemente no querrá eliminarlos. ## Una Primera Plantilla La primera plantilla que vamos a crear será un `ConfigMap`. En Kubernetes, un ConfigMap es simplemente un objeto para almacenar datos de configuración. Otras cosas, como los pods, pueden acceder a los datos en un ConfigMap. Debido a que los ConfigMaps son recursos básicos, son un excelente punto de partida para nosotros. Comencemos creando un archivo llamado `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** Los nombres de plantilla no siguen un patrón de nomenclatura rígido. Sin embargo, recomendamos usar la extensión `.yaml` para archivos YAML y `.tpl` para helpers. El archivo YAML anterior es un ConfigMap básico, con los campos mínimos necesarios. Por el hecho de que este archivo está en el directorio `mychart/templates/`, será enviado a través del motor de plantillas. Está perfectamente bien colocar un archivo YAML simple como este en el directorio `mychart/templates/`. Cuando Helm lea esta plantilla, simplemente la enviará a Kubernetes tal cual. Con esta plantilla simple, ahora tenemos un chart instalable. Y podemos instalarlo así: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Usando Helm, podemos recuperar el release y ver la plantilla real que fue cargada. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` El comando `helm get manifest` toma un nombre de release (`full-coral`) e imprime todos los recursos de Kubernetes que fueron subidos al servidor. Cada archivo comienza con `---` para indicar el inicio de un documento YAML, y luego es seguido por una línea de comentario generada automáticamente que nos dice qué archivo de plantilla generó este documento YAML. A partir de ahí, podemos ver que los datos YAML son exactamente lo que pusimos en nuestro archivo `configmap.yaml`. Ahora podemos desinstalar nuestro release: `helm uninstall full-coral`. ### Agregando una Llamada de Plantilla Simple Codificar el `name:` directamente en un recurso generalmente se considera una mala práctica. Los nombres deben ser únicos para un release. Por lo tanto, podríamos querer generar un campo de nombre insertando el nombre del release. **TIP:** El campo `name:` está limitado a 63 caracteres debido a limitaciones del sistema DNS. Por esa razón, los nombres de release están limitados a 53 caracteres. Kubernetes 1.3 y versiones anteriores estaban limitados a solo 24 caracteres (por lo tanto, nombres de 14 caracteres). Modifiquemos `configmap.yaml` en consecuencia. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` El gran cambio viene en el valor del campo `name:`, que ahora es `{{ .Release.Name }}-configmap`. > Una directiva de plantilla está encerrada en bloques `{{` y `}}`. La directiva de plantilla `{{ .Release.Name }}` inyecta el nombre del release en la plantilla. Los valores que se pasan a una plantilla pueden pensarse como _objetos con namespace_, donde un punto (`.`) separa cada elemento del namespace. El punto inicial antes de `Release` indica que comenzamos con el namespace de nivel superior para este alcance (hablaremos sobre el alcance en un momento). Así que podríamos leer `.Release.Name` como "comenzar en el namespace superior, encontrar el objeto `Release`, luego buscar dentro de él un objeto llamado `Name`". El objeto `Release` es uno de los objetos integrados de Helm, y lo cubriremos con más profundidad más adelante. Pero por ahora, es suficiente decir que esto mostrará el nombre del release que la biblioteca asigna a nuestro release. Ahora cuando instalemos nuestro recurso, veremos inmediatamente el resultado de usar esta directiva de plantilla: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Puede ejecutar `helm get manifest clunky-serval` para ver todo el YAML generado. Note que el nombre del ConfigMap dentro de Kubernetes es `clunky-serval-configmap` en lugar de `mychart-configmap` como antes. En este punto, hemos visto las plantillas en su forma más básica: archivos YAML que tienen directivas de plantilla incrustadas en `{{` y `}}`. En la siguiente parte, veremos más a fondo las plantillas. Pero antes de continuar, hay un truco rápido que puede hacer que la construcción de plantillas sea más rápida: Cuando quiera probar el renderizado de plantillas, pero no instalar nada realmente, puede usar `helm install --debug --dry-run goodly-guppy ./mychart`. Esto renderizará las plantillas. Pero en lugar de instalar el chart, le devolverá la plantilla renderizada para que pueda ver la salida: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Usar `--dry-run` hará más fácil probar su código, pero no garantizará que Kubernetes acepte las plantillas que genere. Es mejor no asumir que su chart se instalará solo porque `--dry-run` funciona. En la [Guía de Plantillas de Chart](/chart_template_guide/index.mdx), tomamos el chart básico que definimos aquí y exploramos el lenguaje de plantillas de Helm en detalle. Y comenzaremos con los objetos integrados. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: El archivo .helmignore description: El archivo `.helmignore` se usa para especificar archivos que no desea incluir en su chart de Helm. sidebar_position: 12 --- El archivo `.helmignore` se usa para especificar archivos que no desea incluir en su chart de Helm. Si este archivo existe, el comando `helm package` ignorará todos los archivos que coincidan con el patrón especificado en el archivo `.helmignore` al empaquetar su chart. Esto puede ayudar a evitar que se agreguen archivos o directorios innecesarios o sensibles en su chart de Helm. El archivo `.helmignore` soporta coincidencia de patrones glob de shell Unix, coincidencia de rutas relativas y negación (con prefijo !). Solo se considera un patrón por línea. Aquí hay un ejemplo de un archivo `.helmignore`: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Algunas diferencias notables con respecto a .gitignore: - La sintaxis '**' no está soportada. - La biblioteca de coincidencia de patrones es 'filepath.Match' de Go, no fnmatch(3) - Los espacios finales siempre se ignoran (no hay secuencia de escape soportada) - No hay soporte para '\!' como secuencia inicial especial. - No se excluye a sí mismo de forma predeterminada, debe agregar una entrada explícita para `.helmignore` **Nos encantaría su ayuda** para mejorar este documento. Para agregar, corregir o eliminar información, [abra un issue](https://github.com/helm/helm-www/issues) o envíenos un pull request. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Plantillas con Nombre description: Cómo definir plantillas con nombre. sidebar_position: 9 --- Ha llegado el momento de ir más allá de una sola plantilla y comenzar a crear otras. En esta sección, veremos cómo definir _plantillas con nombre_ en un archivo y luego usarlas en otros lugares. Una _plantilla con nombre_ (a veces llamada _parcial_ o _subplantilla_) es simplemente una plantilla definida dentro de un archivo a la que se le asigna un nombre. Veremos dos formas de crearlas y varias formas diferentes de usarlas. En la sección de [Estructuras de Control](./control_structures.md) presentamos tres acciones para declarar y gestionar plantillas: `define`, `template` y `block`. En esta sección, cubriremos esas tres acciones y también presentaremos una función especial `include` que funciona de manera similar a la acción `template`. Es importante recordar al nombrar plantillas: **los nombres de las plantillas son globales**. Si declara dos plantillas con el mismo nombre, la que se cargue en último lugar será la que se use. Como las plantillas en subcharts se compilan junto con las plantillas de nivel superior, debe tener cuidado de nombrar sus plantillas con _nombres específicos del chart_. Una convención de nomenclatura popular es prefijar cada plantilla definida con el nombre del chart: `{{ define "mychart.labels" }}`. Al usar el nombre específico del chart como prefijo, podemos evitar cualquier conflicto que pueda surgir debido a dos charts diferentes que implementan plantillas con el mismo nombre. Este comportamiento también se aplica a diferentes versiones de un chart. Si tiene `mychart` versión `1.0.0` que define una plantilla de cierta manera, y `mychart` versión `2.0.0` que modifica la plantilla con nombre existente, se usará la que se cargó en último lugar. Puede solucionar este problema agregando también una versión en el nombre del chart: `{{ define "mychart.v1.labels" }}` y `{{ define "mychart.v2.labels" }}`. ## Parciales y archivos `_` Hasta ahora, hemos usado un solo archivo, y ese archivo contenía una sola plantilla. Pero el lenguaje de plantillas de Helm le permite crear plantillas con nombre incrustadas, a las que se puede acceder por nombre desde cualquier otro lugar. Antes de entrar en los detalles de cómo escribir esas plantillas, hay una convención de nomenclatura de archivos que merece mención: * La mayoría de los archivos en `templates/` se tratan como si contuvieran manifiestos de Kubernetes * `NOTES.txt` es una excepción * Pero los archivos cuyo nombre comienza con un guion bajo (`_`) se asumen como que _no_ contienen un manifiesto. Estos archivos no se renderizan como definiciones de objetos de Kubernetes, pero están disponibles en todas las demás plantillas del chart para su uso. Estos archivos se usan para almacenar parciales y helpers. De hecho, cuando creamos `mychart` por primera vez, vimos un archivo llamado `_helpers.tpl`. Ese archivo es la ubicación predeterminada para parciales de plantillas. ## Declarar y usar plantillas con `define` y `template` La acción `define` nos permite crear una plantilla con nombre dentro de un archivo de plantilla. Su sintaxis es la siguiente: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` Por ejemplo, podemos definir una plantilla para encapsular un bloque de etiquetas de Kubernetes: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Ahora podemos incrustar esta plantilla dentro de nuestro ConfigMap existente, y luego incluirla con la acción `template`: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Cuando el motor de plantillas lee este archivo, almacenará la referencia a `mychart.labels` hasta que se llame a `template "mychart.labels"`. Luego renderizará esa plantilla en línea. Así que el resultado se verá así: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Nota: un `define` no produce salida a menos que se llame con template, como en este ejemplo. Por convención, los charts de Helm colocan estas plantillas dentro de un archivo de parciales, generalmente `_helpers.tpl`. Movamos esta función allí: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Por convención, las funciones `define` deben tener un bloque de documentación simple (`{{/* ... */}}`) que describa lo que hacen. Aunque esta definición está en `_helpers.tpl`, todavía se puede acceder a ella desde `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Como se mencionó anteriormente, **los nombres de las plantillas son globales**. Como resultado, si dos plantillas se declaran con el mismo nombre, la última que aparezca será la que se use. Dado que las plantillas en subcharts se compilan junto con las plantillas de nivel superior, es mejor nombrar sus plantillas con _nombres específicos del chart_. Una convención de nomenclatura popular es prefijar cada plantilla definida con el nombre del chart: `{{ define "mychart.labels" }}`. ## Establecer el ámbito de una plantilla En la plantilla que definimos anteriormente, no usamos ningún objeto. Solo usamos funciones. Modifiquemos nuestra plantilla definida para incluir el nombre del chart y la versión del chart: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Si renderizamos esto, obtendremos un error como este: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Para ver qué se renderizó, vuelva a ejecutar con `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. El resultado no será el que esperamos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` ¿Qué pasó con el nombre y la versión? No estaban en el ámbito de nuestra plantilla definida. Cuando se renderiza una plantilla con nombre (creada con `define`), recibirá el ámbito pasado por la llamada `template`. En nuestro ejemplo, incluimos la plantilla así: ```yaml {{- template "mychart.labels" }} ``` No se pasó ningún ámbito, por lo que dentro de la plantilla no podemos acceder a nada en `.`. Esto es fácil de arreglar. Basta con pasar un ámbito a la plantilla: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Observe que pasamos `.` al final de la llamada `template`. También podríamos pasar `.Values` o `.Values.favorite` o cualquier ámbito que deseemos. Pero lo que queremos es el ámbito de nivel superior. En el contexto de la plantilla con nombre, `$` se referirá al ámbito que pasó y no a algún ámbito global. Ahora, cuando ejecutamos esta plantilla con `helm install --dry-run --debug plinking-anaco ./mychart`, obtenemos esto: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Ahora `{{ .Chart.Name }}` se resuelve a `mychart`, y `{{ .Chart.Version }}` se resuelve a `0.1.0`. ## La función `include` Digamos que hemos definido una plantilla simple que se ve así: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Ahora supongamos que quiero insertar esto tanto en la sección `labels:` de mi plantilla como en la sección `data:`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Si renderizamos esto, obtendremos un error como este: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Para ver qué se renderizó, vuelva a ejecutar con `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. La salida no será la que esperamos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Observe que la indentación de `app_version` es incorrecta en ambos lugares. ¿Por qué? Porque la plantilla que se sustituye tiene el texto alineado a la izquierda. Como `template` es una acción, y no una función, no hay forma de pasar la salida de una llamada `template` a otras funciones; los datos simplemente se insertan en línea. Para solucionar este caso, Helm proporciona una alternativa a `template` que importará el contenido de una plantilla al pipeline actual donde puede pasarse a otras funciones en el pipeline. Aquí está el ejemplo anterior, corregido para usar `indent` para indentar la plantilla `mychart.app` correctamente: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Ahora el YAML producido está correctamente indentado para cada sección: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Es preferible usar `include` en lugar de `template` en las plantillas de Helm > simplemente para que el formato de salida pueda manejarse mejor en documentos > YAML. A veces queremos importar contenido, pero no como plantillas. Es decir, queremos importar archivos literalmente. Podemos lograr esto accediendo a los archivos a través del objeto `.Files` descrito en la siguiente sección. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Creación de un Archivo NOTES.txt description: Cómo proporcionar instrucciones a los usuarios de su Chart. sidebar_position: 10 --- En esta sección vamos a ver la herramienta de Helm para proporcionar instrucciones a los usuarios de su chart. Al finalizar un `helm install` o `helm upgrade`, Helm puede mostrar un bloque de información útil para los usuarios. Esta información es altamente personalizable mediante plantillas. Para agregar notas de instalación a su chart, simplemente cree un archivo `templates/NOTES.txt`. Este archivo es texto plano, pero se procesa como una plantilla, y tiene todas las funciones y objetos de plantilla normales disponibles. Creemos un archivo `NOTES.txt` simple: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Ahora, si ejecutamos `helm install rude-cardinal ./mychart`, veremos este mensaje al final: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Usar `NOTES.txt` de esta manera es una excelente forma de proporcionar a sus usuarios información detallada sobre cómo usar su chart recién instalado. Se recomienda encarecidamente crear un archivo `NOTES.txt`, aunque no es obligatorio. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts y Valores Globales description: Interacción con subcharts y valores globales. sidebar_position: 11 --- Hasta este punto hemos trabajado solo con un chart. Pero los charts pueden tener dependencias, llamadas _subcharts_, que también tienen sus propios values y plantillas. En esta sección crearemos un subchart y veremos las diferentes formas en que podemos acceder a los values desde las plantillas. Antes de profundizar en el código, hay algunos detalles importantes que aprender sobre los subcharts de aplicaciones. 1. Un subchart se considera "independiente", lo que significa que un subchart nunca puede depender explícitamente de su chart padre. 2. Por esa razón, un subchart no puede acceder a los values de su padre. 3. Un chart padre puede sobrescribir values para los subcharts. 4. Helm tiene un concepto de _valores globales_ que pueden ser accedidos por todos los charts. > Estas limitaciones no necesariamente aplican a los [charts de biblioteca](/topics/library_charts.md), que están diseñados para proporcionar funcionalidad auxiliar estandarizada. A medida que recorramos los ejemplos en esta sección, muchos de estos conceptos quedarán más claros. ## Creación de un Subchart Para estos ejercicios, comenzaremos con el chart `mychart/` que creamos al inicio de esta guía, y agregaremos un nuevo chart dentro de él. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Observe que, al igual que antes, eliminamos todas las plantillas base para poder comenzar desde cero. En esta guía, nos enfocamos en cómo funcionan las plantillas, no en gestionar dependencias. Sin embargo, la [Guía de Charts](/topics/charts.md) tiene más información sobre cómo funcionan los subcharts. ## Agregar Values y una Plantilla al Subchart A continuación, crearemos una plantilla simple y un archivo values para nuestro chart `mysubchart`. Ya debería existir un `values.yaml` en `mychart/charts/mysubchart`. Lo configuraremos así: ```yaml dessert: cake ``` Luego, crearemos una nueva plantilla de ConfigMap en `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Como cada subchart es un _chart independiente_, podemos probar `mysubchart` por sí solo: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Sobrescribir Values desde un Chart Padre Nuestro chart original, `mychart`, ahora es el _chart padre_ de `mysubchart`. Esta relación se basa completamente en el hecho de que `mysubchart` está dentro de `mychart/charts`. Como `mychart` es el padre, podemos especificar configuración en `mychart` y hacer que esa configuración se pase a `mysubchart`. Por ejemplo, podemos modificar `mychart/values.yaml` de esta forma: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Observe las últimas dos líneas. Cualquier directiva dentro de la sección `mysubchart` se pasará al chart `mysubchart`. Entonces, si ejecutamos `helm install --generate-name --dry-run --debug mychart`, una de las cosas que veremos es el ConfigMap de `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` El valor en el nivel superior ahora ha sobrescrito el valor del subchart. Hay un detalle importante que notar aquí. No cambiamos la plantilla de `mychart/charts/mysubchart/templates/configmap.yaml` para que apunte a `.Values.mysubchart.dessert`. Desde la perspectiva de esa plantilla, el valor todavía está ubicado en `.Values.dessert`. A medida que el motor de plantillas pasa los values, establece el ámbito. Así que para las plantillas de `mysubchart`, solo los values específicamente para `mysubchart` estarán disponibles en `.Values`. Sin embargo, a veces querrá que ciertos valores estén disponibles para todas las plantillas. Esto se logra usando valores globales de chart. ## Valores Globales de Chart Los valores globales son valores a los que se puede acceder desde cualquier chart o subchart con exactamente el mismo nombre. Los globales requieren declaración explícita. No se puede usar un valor no global existente como si fuera global. El tipo de datos Values tiene una sección reservada llamada `Values.global` donde se pueden establecer valores globales. Establezcamos uno en nuestro archivo `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Debido a cómo funcionan los globales, tanto `mychart/templates/configmap.yaml` como `mysubchart/templates/configmap.yaml` deberían poder acceder a ese valor como `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Ahora, si ejecutamos una instalación en modo dry run, veremos el mismo valor en ambas salidas: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Los globales son útiles para pasar información como esta, aunque requiere cierta planificación para asegurarse de que las plantillas correctas estén configuradas para usar globales. ## Compartir Plantillas con Subcharts Los charts padres y los subcharts pueden compartir plantillas. Cualquier bloque definido en cualquier chart está disponible para otros charts. Por ejemplo, podemos definir una plantilla simple como esta: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Recuerde que las etiquetas en las plantillas se _comparten globalmente_. Por lo tanto, el chart `labels` puede incluirse desde cualquier otro chart. Mientras que los desarrolladores de charts pueden elegir entre `include` y `template`, una ventaja de usar `include` es que puede referenciar plantillas dinámicamente: ```yaml {{ include $mytemplate }} ``` Lo anterior desreferenciará `$mytemplate`. La función `template`, en contraste, solo acepta un literal de cadena. ## Evitar el Uso de Blocks El lenguaje de plantillas de Go proporciona una palabra clave `block` que permite a los desarrolladores proporcionar una implementación por defecto que se sobrescribe después. En los charts de Helm, los blocks no son la mejor herramienta para sobrescribir porque si se proporcionan múltiples implementaciones del mismo block, la seleccionada es impredecible. Se recomienda usar `include` en su lugar. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Archivos Values description: Instrucciones sobre cómo usar la opción --values. sidebar_position: 4 --- En la sección anterior vimos los objetos integrados que ofrecen las plantillas de Helm. Uno de los objetos integrados es `Values`. Este objeto permite acceder a los valores que se pasan al chart. Su contenido proviene de múltiples fuentes: - El archivo `values.yaml` en el chart - Si es un subchart, el archivo `values.yaml` de un chart padre - Un archivo values pasado a `helm install` o `helm upgrade` con la opción `-f` (`helm install -f myvals.yaml ./mychart`) - Parámetros individuales pasados con `--set` (como `helm install --set foo=bar ./mychart`) La lista anterior está en orden de prioridad: `values.yaml` es el valor por defecto, que puede ser sobrescrito por el `values.yaml` de un chart padre, que a su vez puede ser sobrescrito por un archivo values proporcionado por el usuario, que a su vez puede ser sobrescrito por los parámetros `--set`. Los archivos values son archivos YAML simples. Editemos `mychart/values.yaml` y luego editemos nuestra plantilla de ConfigMap. Eliminando los valores por defecto en `values.yaml`, estableceremos solo un parámetro: ```yaml favoriteDrink: coffee ``` Ahora podemos usar esto dentro de una plantilla: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Observe en la última línea que accedemos a `favoriteDrink` como un atributo de `Values`: `{{ .Values.favoriteDrink }}`. Veamos cómo se renderiza. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Dado que `favoriteDrink` está configurado en el archivo `values.yaml` por defecto como `coffee`, ese es el valor que se muestra en la plantilla. Podemos sobrescribirlo fácilmente agregando una opción `--set` en nuestra llamada a `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Dado que `--set` tiene mayor prioridad que el archivo `values.yaml` por defecto, nuestra plantilla genera `drink: slurm`. Los archivos values también pueden contener contenido más estructurado. Por ejemplo, podríamos crear una sección `favorite` en nuestro archivo `values.yaml` y agregar varias claves allí: ```yaml favorite: drink: coffee food: pizza ``` Ahora tendríamos que modificar ligeramente la plantilla: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Aunque es posible estructurar los datos de esta manera, la recomendación es mantener los árboles de values poco profundos, favoreciendo una estructura plana. Cuando veamos cómo asignar valores a subcharts, veremos cómo los values se nombran usando una estructura de árbol. ## Eliminar una clave por defecto Si necesita eliminar una clave de los values por defecto, puede sobrescribir el valor de la clave como `null`, en cuyo caso Helm eliminará la clave de la fusión de valores sobrescritos. Por ejemplo, el chart estable de Drupal permite configurar el liveness probe, en caso de que configure una imagen personalizada. Estos son los valores por defecto: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Si intenta sobrescribir el handler del livenessProbe a `exec` en lugar de `httpGet` usando `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm fusionará las claves por defecto y las sobrescritas, resultando en el siguiente YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Sin embargo, Kubernetes fallaría porque no se puede declarar más de un handler de livenessProbe. Para resolver esto, puede indicar a Helm que elimine `livenessProbe.httpGet` estableciéndolo como null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` En este punto, hemos visto varios objetos integrados y los hemos usado para inyectar información en una plantilla. Ahora veremos otro aspecto del motor de plantillas: funciones y pipelines. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Variables description: Uso de variables en plantillas. sidebar_position: 8 --- Con funciones, pipelines, objetos y estructuras de control ya dominados, podemos abordar una de las ideas más básicas en muchos lenguajes de programación: las variables. En las plantillas, se usan con menos frecuencia. Pero veremos cómo usarlas para simplificar el código y aprovechar mejor `with` y `range`. En un ejemplo anterior, vimos que este código fallará: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` no está dentro del ámbito restringido en el bloque `with`. Una forma de solucionar los problemas de ámbito es asignar objetos a variables a las que se puede acceder independientemente del ámbito actual. En las plantillas de Helm, una variable es una referencia con nombre a otro objeto. Sigue la forma `$nombre`. Las variables se asignan con un operador de asignación especial: `:=`. Podemos reescribir lo anterior para usar una variable para `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Observe que antes de comenzar el bloque `with`, asignamos `$relname := .Release.Name`. Ahora, dentro del bloque `with`, la variable `$relname` todavía apunta al nombre del release. Ejecutar eso producirá lo siguiente: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Las variables son particularmente útiles en los bucles `range`. Se pueden usar en objetos tipo lista para capturar tanto el índice como el valor: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Tenga en cuenta que `range` va primero, luego las variables, luego el operador de asignación y finalmente la lista. Esto asignará el índice entero (comenzando desde cero) a `$index` y el valor a `$topping`. Ejecutarlo producirá: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Para estructuras de datos que tienen tanto una clave como un valor, podemos usar `range` para obtener ambos. Por ejemplo, podemos recorrer `.Values.favorite` de esta manera: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Ahora, en la primera iteración, `$key` será `drink` y `$val` será `coffee`, y en la segunda, `$key` será `food` y `$val` será `pizza`. Ejecutar lo anterior generará esto: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Las variables normalmente no son "globales". Tienen un ámbito limitado al bloque en el que se declaran. Anteriormente, asignamos `$relname` en el nivel superior de la plantilla. Esa variable estará en el ámbito de toda la plantilla. Pero en nuestro último ejemplo, `$key` y `$val` solo estarán en el ámbito dentro del bloque `{{ range... }}{{ end }}`. Sin embargo, hay una variable que siempre apuntará al contexto raíz: `$`. Esto puede ser muy útil cuando está iterando en un range y necesita conocer el nombre del release del chart. Un ejemplo que ilustra esto: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Muchas plantillas de helm usarían `.` a continuación, pero eso no funcionará, # sin embargo `$` funcionará aquí app.kubernetes.io/name: {{ template "fullname" $ }} # No puedo referenciar .Chart.Name, pero puedo hacer $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Valor de appVersion en Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` Hasta ahora hemos visto solo una plantilla declarada en un solo archivo. Pero una de las características más poderosas del lenguaje de plantillas de Helm es su capacidad para declarar múltiples plantillas y usarlas juntas. Lo veremos en la siguiente sección. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Próximos Pasos description: Conclusión - algunos enlaces útiles a otra documentación que le será de ayuda. sidebar_position: 14 --- Esta guía está diseñada para darle a usted, el desarrollador de charts, una comprensión sólida de cómo usar el lenguaje de plantillas de Helm. La guía se centra en los aspectos técnicos del desarrollo de plantillas. Pero hay muchas cosas que esta guía no ha cubierto en lo que respecta al desarrollo práctico de charts en el día a día. Aquí hay algunos enlaces útiles a otra documentación que le ayudará a medida que cree nuevos charts: - El [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de CNCF es una fuente indispensable de charts. - La [Documentación](https://kubernetes.io/docs/home/) de Kubernetes proporciona ejemplos detallados de los diversos tipos de recursos que puede usar, desde ConfigMaps y Secrets hasta DaemonSets y Deployments. - La [Guía de Charts](/topics/charts.md) de Helm explica el flujo de trabajo del uso de charts. - La [Guía de Hooks de Charts](/topics/charts_hooks.md) de Helm explica cómo crear hooks de ciclo de vida. - El artículo [Consejos y Trucos de Charts](/howto/charts_tips_and_tricks.md) de Helm proporciona algunos consejos útiles para escribir charts. - La [documentación de Sprig](https://github.com/Masterminds/sprig) documenta más de sesenta funciones de plantilla. - La [documentación de plantillas de Go](https://godoc.org/text/template) explica la sintaxis de plantillas en detalle. - La [herramienta Schelm](https://github.com/databus23/schelm) es una utilidad auxiliar muy útil para depurar charts. A veces es más fácil hacer algunas preguntas y obtener respuestas de desarrolladores experimentados. El mejor lugar para hacerlo es en los canales de Helm en [Kubernetes Slack](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Finalmente, si encuentra errores u omisiones en este documento, desea sugerir contenido nuevo o le gustaría contribuir, visite [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Apéndice: Técnicas de YAML" description: Una mirada más detallada a la especificación YAML y cómo se aplica a Helm. sidebar_position: 15 --- La mayor parte de esta guía se ha centrado en escribir el lenguaje de plantillas. Aquí veremos el formato YAML. YAML tiene algunas características útiles que nosotros, como autores de plantillas, podemos usar para hacer nuestras plantillas menos propensas a errores y más fáciles de leer. ## Escalares y Colecciones Según la [especificación YAML](https://yaml.org/spec/1.2/spec.html), hay dos tipos de colecciones y muchos tipos escalares. Los dos tipos de colecciones son mapas y secuencias: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Los valores escalares son valores individuales (a diferencia de las colecciones) ### Tipos Escalares en YAML En el dialecto de YAML de Helm, el tipo de dato escalar de un valor se determina por un conjunto complejo de reglas, incluyendo el esquema de Kubernetes para las definiciones de recursos. Pero al inferir tipos, las siguientes reglas tienden a aplicarse. Si un entero o flotante es una palabra sin comillas, normalmente se trata como un tipo numérico: ```yaml count: 1 size: 2.34 ``` Pero si están entre comillas, se tratan como cadenas: ```yaml count: "1" # <-- cadena, no int size: '2.34' # <-- cadena, no float ``` Lo mismo aplica para los booleanos: ```yaml isGood: true # bool answer: "true" # cadena ``` El valor nulo se representa como `null` (no `nil`). Tenga en cuenta que `port: "80"` es YAML válido y pasará tanto por el motor de plantillas como por el analizador YAML, pero fallará si Kubernetes espera que `port` sea un entero. En algunos casos, puede forzar una inferencia de tipo particular usando etiquetas de nodo YAML: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` En el ejemplo anterior, `!!str` le dice al analizador que `age` es una cadena, aunque parezca un int. Y `port` se trata como un int, aunque esté entre comillas. ## Cadenas en YAML Gran parte de los datos que colocamos en documentos YAML son cadenas. YAML tiene más de una forma de representar una cadena. Esta sección explica las formas y demuestra cómo usar algunas de ellas. Hay tres formas "en línea" de declarar una cadena: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Todos los estilos en línea deben estar en una sola línea. - Las palabras sin comillas no están entre comillas y no se escapan. Por esta razón, debe tener cuidado con los caracteres que usa. - Las cadenas entre comillas dobles pueden tener caracteres específicos escapados con `\`. Por ejemplo `"\"Hello\", she said"`. Puede escapar saltos de línea con `\n`. - Las cadenas entre comillas simples son cadenas "literales" y no usan `\` para escapar caracteres. La única secuencia de escape es `''`, que se decodifica como una sola `'`. Además de las cadenas de una línea, puede declarar cadenas multilínea: ```yaml coffee: | Latte Cappuccino Espresso ``` El ejemplo anterior trata el valor de `coffee` como una sola cadena equivalente a `Latte\nCappuccino\nEspresso\n`. Tenga en cuenta que la primera línea después de `|` debe tener la indentación correcta. Podríamos causar un error en el ejemplo anterior haciendo esto: ```yaml coffee: | Latte Cappuccino Espresso ``` Como `Latte` tiene una indentación incorrecta, obtendríamos un error como este: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` En las plantillas, a veces es más seguro poner una "primera línea" falsa de contenido en un documento multilínea solo para protegerse del error anterior: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Tenga en cuenta que cualquiera que sea esa primera línea, se conservará en la salida de la cadena. Entonces, si está usando esta técnica para inyectar el contenido de un archivo en un ConfigMap, el comentario debe ser del tipo esperado por lo que esté leyendo esa entrada. ### Control de Espacios en Cadenas Multilínea En el ejemplo anterior, usamos `|` para indicar una cadena multilínea. Pero observe que el contenido de nuestra cadena fue seguido por un `\n` final. Si queremos que el procesador YAML elimine el salto de línea final, podemos agregar un `-` después del `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Ahora el valor de `coffee` será: `Latte\nCappuccino\nEspresso` (sin `\n` final). Otras veces, podríamos querer que se conserven todos los espacios en blanco finales. Podemos hacer esto con la notación `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Ahora el valor de `coffee` será `Latte\nCappuccino\nEspresso\n\n\n`. La indentación dentro de un bloque de texto se conserva, y también resulta en la conservación de los saltos de línea: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` En el caso anterior, `coffee` será `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indentación y Plantillas Al escribir plantillas, es posible que desee inyectar el contenido de un archivo en la plantilla. Como vimos en capítulos anteriores, hay dos formas de hacer esto: - Use `{{ .Files.Get "FILENAME" }}` para obtener el contenido de un archivo en el chart. - Use `{{ include "TEMPLATE" . }}` para renderizar una plantilla y luego colocar su contenido en el chart. Al insertar archivos en YAML, es bueno entender las reglas de multilínea anteriores. A menudo, la forma más fácil de insertar un archivo estático es hacer algo como esto: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Observe cómo hacemos la indentación anterior: `indent 2` le dice al motor de plantillas que indente cada línea en "myfile.txt" con dos espacios. Tenga en cuenta que no indentamos esa línea de plantilla. Eso es porque si lo hiciéramos, el contenido del archivo de la primera línea estaría indentado dos veces. ### Cadenas Multilínea Plegadas (Folded) A veces quiere representar una cadena en su YAML con múltiples líneas, pero quiere que se trate como una sola línea larga cuando se interprete. A esto se le llama "folding" (plegado). Para declarar un bloque plegado, use `>` en lugar de `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` El valor de `coffee` anterior será `Latte Cappuccino Espresso\n`. Tenga en cuenta que todos los saltos de línea excepto el último se convertirán en espacios. Puede combinar los controles de espacios en blanco con el marcador de texto plegado, así que `>-` reemplazará o recortará todos los saltos de línea. Tenga en cuenta que en la sintaxis plegada, indentar texto hará que las líneas se conserven. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Lo anterior producirá `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Observe que tanto los espacios como los saltos de línea siguen ahí. ## Incrustando Múltiples Documentos en Un Archivo Es posible colocar más de un documento YAML en un solo archivo. Esto se hace prefijando un nuevo documento con `---` y terminando el documento con `...` ```yaml --- document: 1 ... --- document: 2 ... ``` En muchos casos, se puede omitir ya sea `---` o `...`. Algunos archivos en Helm no pueden contener más de un documento. Si, por ejemplo, se proporciona más de un documento dentro de un archivo `values.yaml`, solo se usará el primero. Sin embargo, los archivos de plantilla pueden tener más de un documento. Cuando esto sucede, el archivo (y todos sus documentos) se trata como un objeto durante el renderizado de la plantilla. Pero luego el YAML resultante se divide en múltiples documentos antes de enviarse a Kubernetes. Recomendamos usar múltiples documentos por archivo solo cuando sea absolutamente necesario. Tener múltiples documentos en un archivo puede ser difícil de depurar. ## YAML es un Superconjunto de JSON Debido a que YAML es un superconjunto de JSON, cualquier documento JSON válido _debería_ ser YAML válido. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Lo anterior es otra forma de representar esto: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` Y los dos se pueden mezclar (con cuidado): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Los tres deberían analizarse en la misma representación interna. Si bien esto significa que archivos como `values.yaml` pueden contener datos JSON, Helm no trata la extensión de archivo `.json` como un sufijo válido. ## Anclas YAML La especificación YAML proporciona una forma de almacenar una referencia a un valor y luego referirse a ese valor por referencia. YAML llama a esto "anclaje": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` En lo anterior, `&favoriteCoffee` establece una referencia a `Cappuccino`. Más tarde, esa referencia se usa como `*favoriteCoffee`. Entonces `coffees` se convierte en `Latte, Cappuccino, Espresso`. Si bien hay algunos casos donde las anclas son útiles, hay un aspecto de ellas que puede causar errores sutiles: La primera vez que se consume el YAML, la referencia se expande y luego se descarta. Entonces, si decodificáramos y luego recodificáramos el ejemplo anterior, el YAML resultante sería: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Debido a que Helm y Kubernetes a menudo leen, modifican y luego reescriben archivos YAML, las anclas se perderán. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Cambios desde Helm 2 sidebar_position: 1 --- ## Cambios desde Helm 2 Esta es una lista exhaustiva de todos los cambios principales introducidos en Helm 3. ### Eliminación de Tiller Durante el ciclo de desarrollo de Helm 2, introdujimos Tiller. Tiller desempeñó un papel importante para los equipos que trabajaban en un clúster compartido: permitía que múltiples operadores interactuaran con el mismo conjunto de releases. Con el control de acceso basado en roles (RBAC) habilitado por defecto en Kubernetes 1.6, asegurar Tiller para su uso en un escenario de producción se volvió más difícil de gestionar. Debido a la gran cantidad de posibles políticas de seguridad, nuestra postura fue proporcionar una configuración permisiva por defecto. Esto permitió a los usuarios principiantes comenzar a experimentar con Helm y Kubernetes sin tener que sumergirse de lleno en los controles de seguridad. Desafortunadamente, esta configuración permisiva podía otorgar a un usuario una amplia gama de permisos que no estaba destinado a tener. Los equipos de DevOps y SRE tenían que aprender pasos operativos adicionales al instalar Tiller en un clúster multi-tenant. Después de escuchar cómo los miembros de la comunidad usaban Helm en ciertos escenarios, descubrimos que el sistema de gestión de releases de Tiller no necesitaba depender de un operador dentro del clúster para mantener el estado o actuar como un centro de información de releases de Helm. En su lugar, podíamos simplemente obtener información del servidor API de Kubernetes, renderizar los Charts del lado del cliente y almacenar un registro de la instalación en Kubernetes. El objetivo principal de Tiller podía lograrse sin Tiller, por lo que una de las primeras decisiones que tomamos respecto a Helm 3 fue eliminar Tiller por completo. Sin Tiller, el modelo de seguridad de Helm se simplifica radicalmente. Helm 3 ahora soporta todas las características modernas de seguridad, identidad y autorización de Kubernetes moderno. Los permisos de Helm se evalúan usando su [archivo kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Los administradores del clúster pueden restringir los permisos de los usuarios con la granularidad que consideren apropiada. Los releases aún se registran dentro del clúster, y el resto de la funcionalidad de Helm permanece sin cambios. ### Estrategia de actualización mejorada: parches de fusión estratégica de tres vías Helm 2 utilizaba un parche de fusión estratégica de dos vías. Durante una actualización, comparaba el manifiesto del chart más reciente con el manifiesto del chart propuesto (el proporcionado durante `helm upgrade`). Comparaba las diferencias entre estos dos charts para determinar qué cambios debían aplicarse a los recursos en Kubernetes. Si se aplicaban cambios al clúster fuera de banda (como durante un `kubectl edit`), esos cambios no se consideraban. Esto resultaba en que los recursos no pudieran revertirse a su estado anterior: dado que Helm solo consideraba el manifiesto del último chart aplicado como su estado actual, si no había cambios en el estado del chart, el estado en vivo permanecía sin cambios. En Helm 3, ahora utilizamos un parche de fusión estratégica de tres vías. Helm considera el manifiesto antiguo, su estado en vivo y el nuevo manifiesto al generar un parche. #### Ejemplos Veamos algunos ejemplos comunes de cómo este cambio impacta. ##### Reversión cuando el estado en vivo ha cambiado Su equipo acaba de desplegar su aplicación en producción en Kubernetes usando Helm. El chart contiene un objeto Deployment donde el número de réplicas está configurado en tres: ```console $ helm install myapp ./myapp ``` Un nuevo desarrollador se une al equipo. En su primer día, mientras observa el clúster de producción, ocurre un terrible accidente de café sobre el teclado y ejecutan `kubectl scale` en el deployment de producción, reduciendo de tres réplicas a cero. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Otro desarrollador de su equipo nota que el sitio de producción está caído y decide revertir el release a su estado anterior: ```console $ helm rollback myapp ``` ¿Qué sucede? En Helm 2, generaría un parche comparando el manifiesto antiguo con el nuevo. Como esto es una reversión, es el mismo manifiesto. Helm determinaría que no hay nada que cambiar porque no hay diferencia entre el manifiesto antiguo y el nuevo. El conteo de réplicas continúa en cero. Cunde el pánico. En Helm 3, el parche se genera usando el manifiesto antiguo, el estado en vivo y el nuevo manifiesto. Helm reconoce que el estado antiguo era tres, el estado en vivo es cero y el nuevo manifiesto desea cambiarlo de vuelta a tres, por lo que genera un parche para cambiar el estado de vuelta a tres. ##### Actualizaciones cuando el estado en vivo ha cambiado Muchas service meshes y otras aplicaciones basadas en controladores inyectan datos en los objetos de Kubernetes. Esto puede ser algo como un sidecar, etiquetas u otra información. Anteriormente, si tenía el siguiente manifiesto renderizado desde un Chart: ```yaml containers: - name: server image: nginx:2.0.0 ``` Y el estado en vivo fue modificado por otra aplicación a: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Ahora, desea actualizar la etiqueta de imagen de `nginx` a `2.1.0`. Entonces, actualiza a un chart con el siguiente manifiesto: ```yaml containers: - name: server image: nginx:2.1.0 ``` ¿Qué sucede? En Helm 2, Helm genera un parche del objeto `containers` entre el manifiesto antiguo y el nuevo. El estado en vivo del clúster no se considera durante la generación del parche. El estado en vivo del clúster se modifica para verse así: ```yaml containers: - name: server image: nginx:2.1.0 ``` El pod sidecar se elimina del estado en vivo. Cunde más pánico. En Helm 3, Helm genera un parche del objeto `containers` entre el manifiesto antiguo, el estado en vivo y el nuevo manifiesto. Nota que el nuevo manifiesto cambia la etiqueta de imagen a `2.1.0`, pero el estado en vivo contiene un contenedor sidecar. El estado en vivo del clúster se modifica para verse así: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Los nombres de releases ahora tienen alcance de namespace Con la eliminación de Tiller, la información sobre cada release tenía que almacenarse en algún lugar. En Helm 2, esto se almacenaba en el mismo namespace que Tiller. En la práctica, esto significaba que una vez que un nombre era usado por un release, ningún otro release podía usar ese mismo nombre, incluso si se desplegaba en un namespace diferente. En Helm 3, la información sobre un release particular ahora se almacena en el mismo namespace que el propio release. Esto significa que los usuarios ahora pueden ejecutar `helm install wordpress stable/wordpress` en dos namespaces separados, y cada uno puede consultarse con `helm list` cambiando el contexto del namespace actual (por ejemplo, `helm list --namespace foo`). Con esta mayor alineación a los namespaces nativos del clúster, el comando `helm list` ya no lista todos los releases por defecto. En su lugar, listará solo los releases en el namespace de su contexto actual de Kubernetes (es decir, el namespace mostrado cuando ejecuta `kubectl config view --minify`). Esto también significa que debe proporcionar la flag `--all-namespaces` a `helm list` para obtener un comportamiento similar al de Helm 2. ### Secrets como driver de almacenamiento predeterminado En Helm 3, los Secrets ahora se utilizan como [driver de almacenamiento predeterminado](/topics/advanced.md#storage-backends). Helm 2 usaba ConfigMaps por defecto para almacenar información de releases. En Helm 2.7.0, se implementó un nuevo backend de almacenamiento que usa Secrets para almacenar información de releases, y ahora es el predeterminado desde Helm 3. Cambiar a Secrets como predeterminado en Helm 3 permite seguridad adicional para proteger los charts junto con el lanzamiento del cifrado de Secrets en Kubernetes. [El cifrado de secrets en reposo](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) estuvo disponible como característica alfa en Kubernetes 1.7 y se volvió estable en Kubernetes 1.13. Esto permite a los usuarios cifrar los metadatos de releases de Helm en reposo, por lo que es un buen punto de partida que puede expandirse posteriormente usando algo como Vault. ### Cambios en la ruta de importación de Go En Helm 3, Helm cambió la ruta de importación de Go de `k8s.io/helm` a `helm.sh/helm/v3`. Si tiene la intención de actualizar a las bibliotecas cliente de Go de Helm 3, asegúrese de cambiar sus rutas de importación. ### Capabilities El objeto incorporado `.Capabilities` disponible durante la etapa de renderizado ha sido simplificado. [Objetos incorporados](/chart_template_guide/builtin_objects.md) ### Validación de valores de Chart con JSONSchema Ahora se puede imponer un JSON Schema sobre los valores del chart. Esto asegura que los valores proporcionados por el usuario sigan el esquema establecido por el mantenedor del chart, proporcionando mejor reportes de errores cuando el usuario proporciona un conjunto incorrecto de valores para un chart. La validación ocurre cuando se invocan cualquiera de los siguientes comandos: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Consulte la documentación sobre [archivos de esquema](/topics/charts.md#schema-files) para más información. ### Consolidación de `requirements.yaml` en `Chart.yaml` El sistema de gestión de dependencias de Charts se movió de requirements.yaml y requirements.lock a Chart.yaml y Chart.lock. Recomendamos que los nuevos charts destinados a Helm 3 usen el nuevo formato. Sin embargo, Helm 3 aún entiende la versión 1 del API de Chart (`v1`) y cargará archivos `requirements.yaml` existentes. En Helm 2, así se veía un `requirements.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` En Helm 3, la dependencia se expresa de la misma manera, pero ahora desde su `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Los charts aún se descargan y colocan en el directorio `charts/`, por lo que los subcharts incluidos en el directorio `charts/` continuarán funcionando sin modificaciones. ### El nombre (o --generate-name) ahora es requerido en install En Helm 2, si no se proporcionaba un nombre, se generaba uno automáticamente. En producción, esto resultó ser más una molestia que una característica útil. En Helm 3, Helm lanzará un error si no se proporciona un nombre con `helm install`. Para aquellos que aún deseen que se les genere un nombre automáticamente, pueden usar la flag `--generate-name` para crear uno. ### Publicación de Charts en registros OCI Esta es una característica experimental introducida en Helm 3. Para usarla, configure la variable de entorno `HELM_EXPERIMENTAL_OCI=1`. A alto nivel, un repositorio de Charts es una ubicación donde los Charts pueden almacenarse y compartirse. El cliente de Helm empaqueta y envía Charts de Helm a un repositorio de Charts. Simplemente, un repositorio de Charts es un servidor HTTP básico que aloja un archivo index.yaml y algunos charts empaquetados. Aunque hay varios beneficios en que el API del repositorio de Charts cumpla con los requisitos de almacenamiento más básicos, han comenzado a mostrarse algunas desventajas: - Los repositorios de Charts tienen mucha dificultad para abstraer la mayoría de las implementaciones de seguridad requeridas en un entorno de producción. Tener un API estándar para autenticación y autorización es muy importante en escenarios de producción. - Las herramientas de procedencia de Charts de Helm utilizadas para firmar y verificar la integridad y origen de un chart son una parte opcional del proceso de publicación de Charts. - En escenarios multi-tenant, el mismo Chart puede ser subido por otro tenant, costando el doble de almacenamiento para guardar el mismo contenido. Se han diseñado repositorios de charts más inteligentes para manejar esto, pero no es parte de la especificación formal. - Usar un único archivo de índice para búsqueda, información de metadatos y obtención de Charts ha hecho difícil o torpe diseñar alrededor de esto en implementaciones seguras multi-tenant. El proyecto Distribution de Docker (también conocido como Docker Registry v2) es el sucesor del proyecto Docker Registry. Muchos grandes proveedores de nube tienen un producto basado en el proyecto Distribution, y con tantos proveedores ofreciendo el mismo producto, el proyecto Distribution se ha beneficiado de muchos años de endurecimiento, mejores prácticas de seguridad y pruebas de batalla. Por favor, consulte `helm help chart` y `helm help registry` para más información sobre cómo empaquetar un chart y publicarlo en un registro Docker. Para más información, consulte [esta página](/topics/registries.md). ### Eliminación de `helm serve` `helm serve` ejecutaba un repositorio de Charts local en su máquina para propósitos de desarrollo. Sin embargo, no tuvo mucha adopción como herramienta de desarrollo y tenía numerosos problemas con su diseño. Al final, decidimos eliminarlo y separarlo como un plugin. Para una experiencia similar a `helm serve`, consulte la opción de almacenamiento en sistema de archivos local en [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) y el [plugin servecm](https://github.com/jdolitsky/helm-servecm). ### Soporte para charts de biblioteca Helm 3 soporta una clase de chart llamada "chart de biblioteca". Este es un chart que es compartido por otros charts, pero no crea ningún artefacto de release propio. Las plantillas de un chart de biblioteca solo pueden declarar elementos `define`. El contenido de alcance global no-`define` simplemente se ignora. Esto permite a los usuarios reutilizar y compartir fragmentos de código que pueden usarse en muchos charts, evitando redundancia y manteniendo los charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Los charts de biblioteca se declaran en la directiva dependencies en Chart.yaml, y se instalan y gestionan como cualquier otro chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Estamos muy emocionados de ver los casos de uso que esta característica abre para los desarrolladores de charts, así como las mejores prácticas que surjan del consumo de charts de biblioteca. ### Incremento del apiVersion de Chart.yaml Con la introducción del soporte para charts de biblioteca y la consolidación de requirements.yaml en Chart.yaml, los clientes que entendían el formato de paquete de Helm 2 no entenderán estas nuevas características. Por lo tanto, incrementamos el apiVersion en Chart.yaml de `v1` a `v2`. `helm create` ahora crea charts usando este nuevo formato, por lo que el apiVersion predeterminado también se incrementó ahí. Los clientes que deseen soportar ambas versiones de charts de Helm deben inspeccionar el campo `apiVersion` en Chart.yaml para entender cómo analizar el formato del paquete. ### Soporte para XDG Base Directory [La especificación XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) es un estándar portable que define dónde deben almacenarse los archivos de configuración, datos y caché en el sistema de archivos. En Helm 2, Helm almacenaba toda esta información en `~/.helm` (conocido cariñosamente como `helm home`), que podía cambiarse configurando la variable de entorno `$HELM_HOME`, o usando la flag global `--home`. En Helm 3, Helm ahora respeta las siguientes variables de entorno según la especificación XDG Base Directory: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Los plugins de Helm aún reciben `$HELM_HOME` como un alias de `$XDG_DATA_HOME` para compatibilidad hacia atrás con plugins que buscan usar `$HELM_HOME` como un entorno de trabajo temporal. Varias variables de entorno nuevas también se pasan al entorno del plugin para acomodar este cambio: - `$HELM_PATH_CACHE` para la ruta de caché - `$HELM_PATH_CONFIG` para la ruta de configuración - `$HELM_PATH_DATA` para la ruta de datos Los plugins de Helm que busquen soportar Helm 3 deberían considerar usar estas nuevas variables de entorno en su lugar. ### Renombrado de comandos CLI Para alinear mejor la terminología con otros gestores de paquetes, `helm delete` fue renombrado a `helm uninstall`. `helm delete` aún se conserva como un alias de `helm uninstall`, por lo que cualquiera de las dos formas puede usarse. En Helm 2, para purgar el registro de releases, se tenía que proporcionar la flag `--purge`. Esta funcionalidad ahora está habilitada por defecto. Para mantener el comportamiento anterior, use `helm uninstall --keep-history`. Adicionalmente, varios otros comandos fueron renombrados para acomodar las mismas convenciones: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Estos comandos también han conservado sus verbos anteriores como aliases, por lo que puede continuar usándolos en cualquiera de las dos formas. ### Creación automática de namespaces Al crear un release en un namespace que no existe, Helm 2 creaba el namespace. Helm 3 sigue el comportamiento de otras herramientas de Kubernetes y devuelve un error si el namespace no existe. Helm 3 creará el namespace si especifica explícitamente la flag `--create-namespace`. ### ¿Qué pasó con .Chart.ApiVersion? Helm sigue la convención típica de CamelCasing que es capitalizar un acrónimo. Hemos hecho esto en otros lugares del código, como con `.Capabilities.APIVersions.Has`. En Helm v3, corregimos `.Chart.ApiVersion` para seguir este patrón, renombrándolo a `.Chart.APIVersion`. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Instalación sidebar_position: 2 --- ## Instalación ### ¿Por qué no hay paquetes nativos de Helm para Fedora y otras distribuciones de Linux? El proyecto Helm no mantiene paquetes para sistemas operativos y entornos. La comunidad de Helm puede proporcionar paquetes nativos y, si el proyecto Helm tiene conocimiento de ellos, se incluirán en la lista. Así es como se inició y agregó la fórmula de Homebrew. Si está interesado en mantener un paquete, nos encantaría contar con su ayuda. ### ¿Por qué proporcionan un script `curl ...|bash`? Hay un script en nuestro repositorio (`scripts/get-helm-3`) que se puede ejecutar como un script `curl ..|bash`. Todas las transferencias están protegidas por HTTPS, y el script realiza algunas verificaciones de los paquetes que descarga. Sin embargo, el script tiene todos los riesgos habituales de cualquier script de shell. Lo proporcionamos porque es útil, pero sugerimos que los usuarios lean cuidadosamente el script primero. Lo que realmente nos gustaría, sin embargo, son mejores versiones empaquetadas de Helm. ### ¿Cómo puedo colocar los archivos del cliente de Helm en un lugar diferente a sus ubicaciones predeterminadas? Helm utiliza la estructura XDG para almacenar archivos. Hay variables de entorno que puede usar para anular estas ubicaciones: - `$XDG_CACHE_HOME`: establece una ubicación alternativa para almacenar archivos en caché. - `$XDG_CONFIG_HOME`: establece una ubicación alternativa para almacenar la configuración de Helm. - `$XDG_DATA_HOME`: establece una ubicación alternativa para almacenar los datos de Helm. Tenga en cuenta que si tiene repositorios existentes, deberá volver a agregarlos con `helm repo add...`. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Solución de Problemas sidebar_position: 4 --- ## Solución de Problemas ### Recibo una advertencia sobre "Unable to get an update from the "stable" chart repository" Ejecute `helm repo list`. Si muestra que su repositorio `stable` apunta a una URL de `storage.googleapis.com`, necesitará actualizar ese repositorio. El 13 de noviembre de 2020, el repositorio de Helm Charts [dejó de tener soporte](https://github.com/helm/charts#deprecation-timeline) después de un período de deprecación de un año. Se ha puesto a disposición un archivo en `https://charts.helm.sh/stable`, pero ya no recibirá actualizaciones. Puede ejecutar el siguiente comando para corregir su repositorio: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Lo mismo aplica para el repositorio `incubator`, que tiene un archivo disponible en https://charts.helm.sh/incubator. Puede ejecutar el siguiente comando para repararlo: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Recibo la advertencia 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' El antiguo repositorio de charts de Google Helm ha sido reemplazado por un nuevo repositorio de charts de Helm. Ejecute el siguiente comando para solucionar esto de forma permanente: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Si recibe un error similar para `incubator`, ejecute este comando: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Al agregar un repositorio de Helm, recibo el error 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Los repositorios de Helm Charts ya no tienen soporte después de [un período de deprecación de un año](https://github.com/helm/charts#deprecation-timeline). Los archivos de estos repositorios están disponibles en `https://charts.helm.sh/stable` y `https://charts.helm.sh/incubator`, sin embargo ya no recibirán actualizaciones. El comando `helm repo add` no le permitirá agregar las URLs antiguas a menos que especifique `--use-deprecated-repos`. ### En GKE (Google Container Engine) recibo "No SSH tunnels currently open" ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Otra variación del mensaje de error es: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` El problema es que su archivo de configuración local de Kubernetes debe tener las credenciales correctas. Cuando crea un clúster en GKE, este le proporcionará credenciales, incluyendo certificados SSL y autoridades de certificación. Estos deben almacenarse en un archivo de configuración de Kubernetes (por defecto: `~/.kube/config`) para que `kubectl` y `helm` puedan acceder a ellos. ### Después de migrar desde Helm 2, `helm list` muestra solo algunas (o ninguna) de mis releases Es posible que no haya notado que Helm 3 ahora utiliza namespaces del clúster para delimitar las releases. Esto significa que para todos los comandos que hacen referencia a una release debe: * confiar en el namespace actual en el contexto activo de Kubernetes (como lo describe el comando `kubectl config view --minify`), * especificar el namespace correcto usando el flag `--namespace`/`-n`, o * para el comando `helm list`, especificar el flag `--all-namespaces`/`-A` Esto aplica a `helm ls`, `helm uninstall` y todos los demás comandos de `helm` que hacen referencia a una release. ### En macOS, se accede al archivo `/etc/.mdns_debug`. ¿Por qué? Existe un caso conocido en macOS donde Helm intentará acceder a un archivo llamado `/etc/.mdns_debug`. Si el archivo existe, Helm mantiene el handle del archivo abierto mientras se ejecuta. Esto es causado por la biblioteca MDNS de macOS. Esta intenta cargar ese archivo para leer la configuración de depuración (si está habilitada). El handle del archivo probablemente no debería mantenerse abierto, y este problema ha sido reportado a Apple. Sin embargo, es macOS, no Helm, quien causa este comportamiento. Si no desea que Helm cargue este archivo, puede compilar Helm como una biblioteca estática que no use la pila de red del host. Hacer esto aumentará el tamaño del binario de Helm, pero evitará que el archivo se abra. Este problema fue inicialmente señalado como un posible problema de seguridad. Pero desde entonces se ha determinado que no hay ninguna falla o vulnerabilidad causada por este comportamiento. ### helm repo add falla cuando antes funcionaba En Helm 3.3.1 y versiones anteriores, el comando `helm repo add ` no mostraba salida si intentaba agregar un repositorio que ya existía. El flag `--no-update` generaba un error si el repositorio ya estaba registrado. En Helm 3.3.2 y versiones posteriores, intentar agregar un repositorio existente producirá un error: `Error: repository name (reponame) already exists, please specify a different name` El comportamiento predeterminado ahora está invertido. `--no-update` ahora se ignora, mientras que si desea reemplazar (sobrescribir) un repositorio existente, puede usar `--force-update`. Esto es debido a un cambio importante para una corrección de seguridad, como se explica en las [notas de la versión de Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Habilitar el registro del cliente de Kubernetes Puede habilitar los mensajes de registro para depurar el cliente de Kubernetes usando los flags de [klog](https://pkg.go.dev/k8s.io/klog). Usar el flag `-v` para establecer el nivel de verbosidad será suficiente para la mayoría de los casos. Por ejemplo: ``` helm list -v 6 ``` ### Las instalaciones de Tiller dejaron de funcionar y se deniega el acceso Las versiones de Helm solían estar disponibles en . Como se explica en ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/), la ubicación oficial cambió en junio de 2019. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) pone a disposición todas las imágenes antiguas de Tiller. Si está intentando descargar versiones antiguas de Helm del bucket de almacenamiento que usaba en el pasado, puede encontrar que faltan: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` La [ubicación heredada de imágenes de Tiller](https://gcr.io/kubernetes-helm/tiller) comenzó la eliminación de imágenes en agosto de 2021. Hemos puesto estas imágenes disponibles en la ubicación de [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Por ejemplo, para descargar la versión v2.17.0, reemplace: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` con: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Para inicializar con Helm v2.17.0: `helm init —upgrade` O si necesita una versión diferente, use el flag --tiller-image para anular la ubicación predeterminada e instalar una versión específica de Helm v2: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Nota:** Los mantenedores de Helm recomiendan migrar a una versión de Helm actualmente soportada. Helm v2.17.0 fue la versión final de Helm v2; Helm v2 no tiene soporte desde noviembre de 2020, como se detalla en [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). Se han señalado muchos CVE contra Helm desde entonces, y esos exploits están parcheados en Helm v3 pero nunca serán parcheados en Helm v2. Consulte la [lista actual de avisos de seguridad publicados de Helm](https://github.com/helm/helm/security/advisories?state=published) y haga un plan para [migrar a Helm v3](/topics/v2_v3_migration.md) hoy. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Desinstalación sidebar_position: 3 --- ## Desinstalación ### Quiero eliminar mi Helm local. ¿Dónde están todos sus archivos? Además del binario `helm`, Helm almacena algunos archivos en las siguientes ubicaciones: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME La siguiente tabla muestra la carpeta predeterminada para cada una de estas, según el sistema operativo: | Sistema Operativo | Ruta de Caché | Ruta de Configuración | Ruta de Datos | |-------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- El gestor de paquetes Helm para Kubernetes. ### Sinopsis El gestor de paquetes de Kubernetes Acciones comunes de Helm: - helm search: buscar charts - helm pull: descargar un chart a su directorio local para visualizarlo - helm install: subir el chart a Kubernetes - helm list: listar releases de charts Variables de entorno: | Nombre | Descripción | |------------------------------------|-------------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | establece una ubicación alternativa para almacenar archivos en caché. | | $HELM_CONFIG_HOME | establece una ubicación alternativa para almacenar la configuración de Helm. | | $HELM_DATA_HOME | establece una ubicación alternativa para almacenar datos de Helm. | | $HELM_DEBUG | indica si Helm se está ejecutando en modo Debug o no | | $HELM_DRIVER | establece el controlador de almacenamiento del backend. Los valores son: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | establece la cadena de conexión que debe usar el controlador de almacenamiento SQL. | | $HELM_MAX_HISTORY | establece el número máximo de historial de releases de Helm. | | $HELM_NAMESPACE | establece el namespace usado para las operaciones de Helm. | | $HELM_NO_PLUGINS | deshabilita plugins. Establezca HELM_NO_PLUGINS=1 para deshabilitar plugins. | | $HELM_PLUGINS | establece la ruta al directorio de plugins | | $HELM_REGISTRY_CONFIG | establece la ruta al archivo de configuración del registro. | | $HELM_REPOSITORY_CACHE | establece la ruta al directorio de caché del repositorio | | $HELM_REPOSITORY_CONFIG | establece la ruta al archivo de repositorios. | | $KUBECONFIG | establece un archivo de configuración de Kubernetes alternativo (por defecto "~/.kube/config") | | $HELM_KUBEAPISERVER | establece el Endpoint del servidor API de Kubernetes para autenticación | | $HELM_KUBECAFILE | establece el archivo de autoridad certificadora de Kubernetes. | | $HELM_KUBEASGROUPS | establece los grupos a usar para suplantación usando una lista separada por comas. | | $HELM_KUBEASUSER | establece el nombre de usuario a suplantar para la operación. | | $HELM_KUBECONTEXT | establece el nombre del contexto de kubeconfig. | | $HELM_KUBETOKEN | establece el Bearer KubeToken usado para autenticación. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indica si se debe omitir la validación del certificado del servidor API de Kubernetes (inseguro) | | $HELM_KUBETLS_SERVER_NAME | establece el nombre del servidor usado para validar el certificado del servidor API de Kubernetes | | $HELM_BURST_LIMIT | establece el límite de ráfaga por defecto en caso de que el servidor contenga muchos CRDs (por defecto 100, -1 para deshabilitar) | | $HELM_QPS | establece las consultas por segundo en casos donde un alto número de llamadas exceda la opción para valores de ráfaga más altos | Helm almacena caché, configuración y datos basándose en el siguiente orden de configuración: - Si una variable de entorno HELM_*_HOME está establecida, se usará - De lo contrario, en sistemas que soportan la especificación de directorios base XDG, se usarán las variables XDG - Cuando no se establece ninguna otra ubicación, se usará una ubicación por defecto basada en el sistema operativo Por defecto, los directorios predeterminados dependen del sistema operativo. Los valores por defecto se listan a continuación: | Sistema Operativo | Ruta de Caché | Ruta de Configuración | Ruta de Datos | |-------------------|---------------------------|--------------------------------|---------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Opciones ``` --burst-limit int límite de throttling del lado del cliente por defecto (por defecto 100) --debug habilita salida detallada -h, --help ayuda para helm --kube-apiserver string la dirección y el puerto del servidor API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad certificadora para la conexión del servidor API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string bearer token usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito de namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorio en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm completion](/helm/helm_completion.md) - genera scripts de autocompletado para el shell especificado * [helm create](/helm/helm_create.md) - crea un nuevo chart con el nombre dado * [helm dependency](/helm/helm_dependency.md) - gestiona las dependencias de un chart * [helm env](/helm/helm_env.md) - información del entorno del cliente Helm * [helm get](/helm/helm_get.md) - descarga información extendida de un release nombrado * [helm history](/helm/helm_history.md) - obtiene el historial de releases * [helm install](/helm/helm_install.md) - instala un chart * [helm lint](/helm/helm_lint.md) - examina un chart en busca de posibles problemas * [helm list](/helm/helm_list.md) - lista releases * [helm package](/helm/helm_package.md) - empaqueta un directorio de chart en un archivo de chart * [helm plugin](/helm/helm_plugin.md) - instala, lista o desinstala plugins de Helm * [helm pull](/helm/helm_pull.md) - descarga un chart de un repositorio y (opcionalmente) lo desempaqueta en el directorio local * [helm push](/helm/helm_push.md) - sube un chart a un servidor remoto * [helm registry](/helm/helm_registry.md) - inicia o cierra sesión en un registro * [helm repo](/helm/helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts * [helm rollback](/helm/helm_rollback.md) - revierte un release a una revisión anterior * [helm search](/helm/helm_search.md) - busca una palabra clave en charts * [helm show](/helm/helm_show.md) - muestra información de un chart * [helm status](/helm/helm_status.md) - muestra el estado del release nombrado * [helm template](/helm/helm_template.md) - renderiza plantillas localmente * [helm test](/helm/helm_test.md) - ejecuta pruebas para un release * [helm uninstall](/helm/helm_uninstall.md) - desinstala un release * [helm upgrade](/helm/helm_upgrade.md) - actualiza un release * [helm verify](/helm/helm_verify.md) - verifica que un chart en la ruta dada ha sido firmado y es válido * [helm version](/helm/helm_version.md) - imprime la información de versión del cliente ###### Generado automáticamente por spf13/cobra el 14-Ene-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- genera scripts de autocompletado para el shell especificado ### Sinopsis Genera scripts de autocompletado de Helm para el shell especificado. ### Opciones ``` -h, --help ayuda para completion ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) - genera el script de autocompletado para bash * [helm completion fish](/helm/helm_completion_fish.md) - genera el script de autocompletado para fish * [helm completion powershell](/helm/helm_completion_powershell.md) - genera el script de autocompletado para powershell * [helm completion zsh](/helm/helm_completion_zsh.md) - genera el script de autocompletado para zsh ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- genera el script de autocompletado para bash ### Sinopsis Genera el script de autocompletado de Helm para el shell bash. Para cargar los autocompletados en su sesión de shell actual: source <(helm completion bash) Para cargar los autocompletados en cada nueva sesión, ejecute una vez: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Opciones ``` -h, --help ayuda para bash --no-descriptions deshabilitar descripciones de autocompletado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm completion](/helm/helm_completion.md) - genera scripts de autocompletado para el shell especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- genera el script de autocompletado para fish ### Sinopsis Genera el script de autocompletado de Helm para el shell fish. Para cargar los autocompletados en su sesión de shell actual: helm completion fish | source Para cargar los autocompletados en cada nueva sesión, ejecute una vez: helm completion fish > ~/.config/fish/completions/helm.fish Deberá iniciar un nuevo shell para que esta configuración surta efecto. ``` helm completion fish [flags] ``` ### Opciones ``` -h, --help ayuda para fish --no-descriptions deshabilitar descripciones de autocompletado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm completion](/helm/helm_completion.md) - genera scripts de autocompletado para el shell especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- genera el script de autocompletado para powershell ### Sinopsis Genera el script de autocompletado para powershell. Para cargar los autocompletados en su sesión de shell actual: PS C:\> helm completion powershell | Out-String | Invoke-Expression Para cargar los autocompletados en cada nueva sesión, agregue la salida del comando anterior a su perfil de powershell. ``` helm completion powershell [flags] ``` ### Opciones ``` -h, --help ayuda para powershell --no-descriptions deshabilitar descripciones de autocompletado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm completion](/helm/helm_completion.md) - genera scripts de autocompletado para el shell especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- genera el script de autocompletado para zsh ### Sinopsis Genera el script de autocompletado de Helm para el shell zsh. Para cargar los autocompletados en su sesión de shell actual: source <(helm completion zsh) Para cargar los autocompletados en cada nueva sesión, ejecute una vez: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Opciones ``` -h, --help ayuda para zsh --no-descriptions deshabilitar descripciones de autocompletado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm completion](/helm/helm_completion.md) - genera scripts de autocompletado para el shell especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- crea un nuevo chart con el nombre proporcionado ### Sinopsis Este comando crea un directorio de chart junto con los archivos y directorios comunes utilizados en un chart. Por ejemplo, 'helm create foo' creará una estructura de directorios similar a esta: foo/ ├── .helmignore # Contiene patrones a ignorar al empaquetar charts de Helm. ├── Chart.yaml # Información sobre su chart ├── values.yaml # Los valores predeterminados para sus plantillas ├── charts/ # Charts de los que depende este chart └── templates/ # Los archivos de plantillas └── tests/ # Los archivos de pruebas 'helm create' toma una ruta como argumento. Si los directorios en la ruta proporcionada no existen, Helm intentará crearlos a medida que avanza. Si el destino proporcionado existe y hay archivos en ese directorio, los archivos en conflicto serán sobrescritos, pero los demás archivos se dejarán intactos. ``` helm create NAME [flags] ``` ### Opciones ``` -h, --help ayuda para create -p, --starter string el nombre o ruta absoluta al scaffold de inicio de Helm ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de limitación predeterminado del lado del cliente (predeterminado 100) --debug habilitar salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta bandera puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión del servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es verdadero, el certificado del servidor de API de Kubernetes no será verificado. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host usado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (predeterminado "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (predeterminado "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (predeterminado "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- gestiona las dependencias de un chart ### Sinopsis Gestiona las dependencias de un chart. Los charts de Helm almacenan sus dependencias en 'charts/'. Para los desarrolladores de charts, a menudo es más fácil gestionar las dependencias en 'Chart.yaml', que declara todas las dependencias. Los comandos de dependencia operan sobre ese archivo, facilitando la sincronización entre las dependencias deseadas y las dependencias reales almacenadas en el directorio 'charts/'. Por ejemplo, este Chart.yaml declara dos dependencias: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" El 'name' debe ser el nombre de un chart, donde ese nombre debe coincidir con el nombre en el archivo 'Chart.yaml' de ese chart. El campo 'version' debe contener una versión semántica o un rango de versiones. La URL del 'repository' debe apuntar a un repositorio de charts. Helm espera que, al añadir '/index.yaml' a la URL, pueda obtener el índice del repositorio de charts. Nota: 'repository' puede ser un alias. El alias debe comenzar con 'alias:' o '@'. A partir de la versión 2.2.0, el repository puede definirse como la ruta al directorio de los charts de dependencia almacenados localmente. La ruta debe comenzar con el prefijo "file://". Por ejemplo, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" Si el chart de dependencia se obtiene localmente, no es necesario añadir el repositorio a helm mediante "helm add repo". También se admite la coincidencia de versiones en este caso. ### Opciones ``` -h, --help ayuda para dependency ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - reconstruye el directorio charts/ basándose en el archivo Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) - lista las dependencias del chart dado * [helm dependency update](/helm/helm_dependency_update.md) - actualiza charts/ basándose en el contenido de Chart.yaml ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- reconstruye el directorio charts/ basándose en el archivo Chart.lock ### Sinopsis Reconstruye el directorio charts/ a partir del archivo Chart.lock. Este comando se utiliza para reconstruir las dependencias de un chart al estado especificado en el archivo de bloqueo. Esto no volverá a resolver las dependencias, como lo hace 'helm dependency update'. Si no se encuentra ningún archivo de bloqueo, 'helm dependency build' replicará el comportamiento de 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores habilitados para HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL -h, --help ayuda para build --insecure-skip-tls-verify omite las verificaciones de certificado tls para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string llavero que contiene claves públicas (por defecto "~/.gnupg/pubring.gpg") --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --skip-refresh no actualiza la caché local del repositorio --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica los paquetes contra las firmas ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm dependency](/helm/helm_dependency.md) - gestiona las dependencias de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- lista las dependencias del chart dado ### Sinopsis Lista todas las dependencias declaradas en un chart. Este comando puede recibir archivos de chart y directorios de chart como entrada. No alterará el contenido de un chart. Se producirá un error si no se puede cargar el chart. ``` helm dependency list CHART [flags] ``` ### Opciones ``` -h, --help ayuda para list --max-col-width uint ancho máximo de columna para la tabla de salida (por defecto 80) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm dependency](/helm/helm_dependency.md) - gestiona las dependencias de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- actualiza charts/ basándose en el contenido de Chart.yaml ### Sinopsis Actualiza las dependencias en disco para reflejar Chart.yaml. Este comando verifica que los charts requeridos, tal como se expresan en 'Chart.yaml', estén presentes en 'charts/' y tengan una versión aceptable. Descargará los charts más recientes que satisfagan las dependencias y eliminará las dependencias antiguas. Tras una actualización exitosa, se generará un archivo de bloqueo que puede usarse para reconstruir las dependencias con una versión exacta. No es obligatorio que las dependencias estén representadas en 'Chart.yaml'. Por esa razón, un comando de actualización no eliminará charts a menos que estén (a) presentes en el archivo Chart.yaml, pero (b) con una versión incorrecta. ``` helm dependency update CHART [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores habilitados para HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL -h, --help ayuda para update --insecure-skip-tls-verify omite las verificaciones de certificado tls para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string llavero que contiene claves públicas (por defecto "~/.gnupg/pubring.gpg") --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --skip-refresh no actualiza la caché local del repositorio --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica los paquetes contra las firmas ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm dependency](/helm/helm_dependency.md) - gestiona las dependencias de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- información del entorno del cliente Helm ### Sinopsis Env imprime toda la información del entorno en uso por Helm. ``` helm env [flags] ``` ### Opciones ``` -h, --help ayuda para env ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- descarga información extendida de un release especificado ### Sinopsis Este comando consta de múltiples subcomandos que pueden usarse para obtener información extendida sobre el release, incluyendo: - Los valores utilizados para generar el release - El archivo de manifiesto generado - Las notas proporcionadas por el chart del release - Los hooks asociados con el release - Los metadatos del release ### Opciones ``` -h, --help ayuda para get ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. * [helm get all](/helm/helm_get_all.md) - descarga toda la información de un release especificado * [helm get hooks](/helm/helm_get_hooks.md) - descarga todos los hooks de un release especificado * [helm get manifest](/helm/helm_get_manifest.md) - descarga el manifiesto de un release especificado * [helm get metadata](/helm/helm_get_metadata.md) - obtiene los metadatos de un release dado * [helm get notes](/helm/helm_get_notes.md) - descarga las notas de un release especificado * [helm get values](/helm/helm_get_values.md) - descarga el archivo de valores de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- descarga toda la información de un release especificado ### Sinopsis Este comando muestra información legible sobre las notas, hooks, valores suministrados y el archivo de manifiesto generado de un release dado. ``` helm get all RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para all --revision int obtiene el release especificado con la revisión indicada --template string plantilla de Go para formatear la salida, ej: {{.Release.Name}} ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- descarga todos los hooks de un release especificado ### Sinopsis Este comando descarga los hooks de un release dado. Los hooks están en formato YAML y se separan mediante '---\n'. ``` helm get hooks RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para hooks --revision int obtiene el release especificado con la revisión indicada ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- descarga el manifest de un release especificado ### Sinopsis Este comando obtiene el manifest generado para un release dado. Un manifest es una representación en formato YAML de los recursos de Kubernetes que fueron generados a partir del chart (o charts) de este release. Si un chart depende de otros charts, esos recursos también serán incluidos en el manifest. ``` helm get manifest RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para manifest --revision int obtiene el release especificado con la revisión indicada ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Este comando obtiene los metadatos de un release especificado ### Sinopsis Este comando obtiene los metadatos de un release especificado. ``` helm get metadata RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para metadata -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --revision int especifica la revisión del release ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- descarga las notas de un release especificado ### Sinopsis Este comando muestra las notas proporcionadas por el chart de un release especificado. ``` helm get notes RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para notes --revision int obtiene el release especificado con la revisión indicada ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- descarga el archivo de valores de un release especificado ### Sinopsis Este comando descarga un archivo de valores para un release dado. ``` helm get values RELEASE_NAME [flags] ``` ### Opciones ``` -a, --all muestra todos los valores (calculados) -h, --help ayuda para values -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --revision int obtiene el release especificado con la revisión indicada ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm get](/helm/helm_get.md) - descarga información extendida de un release especificado ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- obtiene el historial del release ### Sinopsis History imprime las revisiones de un release especificado. Por defecto se devuelven hasta 256 revisiones. Use '--max' para configurar la longitud máxima de la lista de revisiones devuelta. El historial del release se muestra como una tabla formateada, por ejemplo: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para history --max int número máximo de revisiones a incluir en el historial (por defecto 256) -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- instala un chart ### Sinopsis Este comando instala un archivo de chart. El argumento de instalación debe ser una referencia de chart, una ruta a un chart empaquetado, una ruta a un directorio de chart desempaquetado o una URL. Para sobrescribir valores en un chart, use la opción '--values' y proporcione un archivo, o use la opción '--set' y pase la configuración desde la línea de comandos. Para forzar un valor de tipo string, use '--set-string'. Puede usar '--set-file' para establecer valores individuales desde un archivo cuando el valor es demasiado largo para la línea de comandos o se genera dinámicamente. También puede usar '--set-json' para establecer valores JSON (escalares/objetos/arrays) desde la línea de comandos. $ helm install -f myvalues.yaml myredis ./redis o $ helm install --set name=prod myredis ./redis o $ helm install --set-string long_int=1234567890 myredis ./redis o $ helm install --set-file my_script=dothings.sh myredis ./redis o $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Puede especificar la opción '--values'/'-f' múltiples veces. Se dará prioridad al último archivo especificado (el más a la derecha). Por ejemplo, si tanto myvalues.yaml como override.yaml contienen una clave llamada 'Test', el valor establecido en override.yaml tendrá precedencia: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Puede especificar la opción '--set' múltiples veces. Se dará prioridad al último valor especificado (el más a la derecha). Por ejemplo, si se asignan los valores 'bar' y 'newbar' a una clave llamada 'foo', el valor 'newbar' tendrá precedencia: $ helm install --set foo=bar --set foo=newbar myredis ./redis De manera similar, en el siguiente ejemplo 'foo' se establece como '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis Y en el siguiente ejemplo, 'foo' se establece como '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Para verificar los manifiestos generados de un release sin instalar el chart, se pueden combinar las opciones --debug y --dry-run. La opción --dry-run mostrará todos los manifiestos de chart generados, incluyendo Secrets que pueden contener valores sensibles. Para ocultar los Secrets de Kubernetes use la opción --hide-secret. Por favor considere cuidadosamente cómo y cuándo usar estas opciones. Si --verify está establecido, el chart DEBE tener un archivo de procedencia, y el archivo de procedencia DEBE pasar todos los pasos de verificación. Existen seis formas diferentes de expresar el chart que desea instalar: 1. Por referencia de chart: helm install mymaria example/mariadb 2. Por ruta a un chart empaquetado: helm install mynginx ./nginx-1.2.3.tgz 3. Por ruta a un directorio de chart desempaquetado: helm install mynginx ./nginx 4. Por URL absoluta: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. Por referencia de chart y URL de repositorio: helm install --repo https://example.com/charts/ mynginx nginx 6. Por registros OCI: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx REFERENCIAS DE CHART Una referencia de chart es una forma conveniente de referenciar un chart en un repositorio de charts. Cuando usa una referencia de chart con un prefijo de repositorio ('example/mariadb'), Helm buscará en la configuración local un repositorio de charts llamado 'example', y luego buscará un chart en ese repositorio cuyo nombre sea 'mariadb'. Instalará la última versión estable de ese chart a menos que especifique la opción '--devel' para incluir también versiones de desarrollo (alpha, beta y release candidate), o proporcione un número de versión con la opción '--version'. Para ver la lista de repositorios de charts, use 'helm repo list'. Para buscar charts en un repositorio, use 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Opciones ``` --atomic si se establece, el proceso de instalación elimina la instalación en caso de fallo. La opción --wait se establecerá automáticamente si se usa --atomic --ca-file string verifica certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL --create-namespace crea el namespace del release si no está presente --dependency-update actualiza las dependencias si faltan antes de instalar el chart --description string añade una descripción personalizada --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si --version está establecido, esto se ignora --disable-openapi-validation si se establece, el proceso de instalación no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes --dry-run string[="client"] simula una instalación. Si --dry-run se establece sin especificar opción o como '--dry-run=client', no intentará conexiones al clúster. Establecer '--dry-run=server' permite intentar conexiones al clúster. --enable-dns habilita búsquedas DNS al renderizar plantillas --force fuerza actualizaciones de recursos mediante una estrategia de reemplazo -g, --generate-name genera el nombre (y omite el parámetro NAME) -h, --help ayuda para install --hide-notes si se establece, no muestra las notas en la salida de instalación. No afecta su presencia en los metadatos del chart --hide-secret oculta los Secrets de Kubernetes cuando también se usa la opción --dry-run --insecure-skip-tls-verify omite verificaciones de certificado TLS para la descarga del chart --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") -l, --labels stringToString etiquetas que se añadirán a los metadatos del release. Deben separarse por coma. (por defecto []) --name-template string especifica la plantilla usada para nombrar el release --no-hooks evita que se ejecuten los hooks durante la instalación -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --post-renderer postRendererString la ruta a un ejecutable que se usará para post-renderizado. Si existe en $PATH, se usará el binario, de lo contrario intentará buscar el ejecutable en la ruta proporcionada --post-renderer-args postRendererArgsSlice un argumento para el post-renderer (puede especificar múltiples) (por defecto []) --render-subchart-notes si se establece, renderiza las notas del subchart junto con el padre --replace reutiliza el nombre dado, solo si ese nombre es un release eliminado que permanece en el historial. Esto es inseguro en producción --repo string URL del repositorio de charts donde localizar el chart solicitado --set stringArray establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --set-file stringArray establece valores desde los archivos respectivos especificados mediante la línea de comandos (puede especificar múltiples o separar valores con comas: key1=path1,key2=path2) --set-json stringArray establece valores JSON en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=jsonval1,key2=jsonval2) --set-literal stringArray establece un valor STRING literal en la línea de comandos --set-string stringArray establece valores STRING en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --skip-crds si se establece, no se instalarán CRDs. Por defecto, los CRDs se instalan si no están presentes --skip-schema-validation si se establece, deshabilita la validación de esquema JSON --take-ownership si se establece, la instalación ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado -f, --values strings especifica valores en un archivo YAML o una URL (puede especificar múltiples) --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión --wait si se establece, esperará hasta que todos los Pods, PVCs, Services, y el número mínimo de Pods de un Deployment, StatefulSet o ReplicaSet estén en estado ready antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout --wait-for-jobs si se establece y --wait está habilitado, esperará hasta que todos los Jobs se hayan completado antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo usadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- examina un chart en busca de posibles problemas ### Sinopsis Este comando toma una ruta a un chart y ejecuta una serie de pruebas para verificar que el chart esté bien formado. Si el linter encuentra problemas que harán fallar la instalación del chart, emitirá mensajes [ERROR]. Si encuentra problemas que rompen con la convención o las recomendaciones, emitirá mensajes [WARNING]. ``` helm lint PATH [flags] ``` ### Opciones ``` -h, --help ayuda para lint --kube-version string versión de Kubernetes usada para verificaciones de capacidades y deprecación --quiet imprime solo advertencias y errores --set stringArray establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --set-file stringArray establece valores desde archivos respectivos especificados a través de la línea de comandos (puede especificar múltiples o separar valores con comas: key1=path1,key2=path2) --set-json stringArray establece valores JSON en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=jsonval1,key2=jsonval2) --set-literal stringArray establece un valor STRING literal en la línea de comandos --set-string stringArray establece valores STRING en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --skip-schema-validation si está activado, deshabilita la validación de esquema JSON --strict falla si hay advertencias en el lint -f, --values strings especifica valores en un archivo YAML o una URL (puede especificar múltiples) --with-subcharts analiza también los charts dependientes ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- lista los releases ### Sinopsis Este comando lista todos los releases para un namespace especificado (usa el contexto del namespace actual si no se especifica ninguno). Por defecto, solo lista los releases que están desplegados o fallidos. Opciones como '--uninstalled' y '--all' alterarán este comportamiento. Estas opciones se pueden combinar: '--uninstalled --failed'. Por defecto, los elementos se ordenan alfabéticamente. Use la opción '-d' para ordenar por fecha de release. Si se proporciona la opción --filter, se tratará como un filtro. Los filtros son expresiones regulares (compatibles con Perl) que se aplican a la lista de releases. Solo se devolverán los elementos que coincidan con el filtro. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Si no se encuentran resultados, 'helm list' finalizará con código 0, pero sin salida (o en caso de no usar la opción '-q', solo mostrará los encabezados). Por defecto, se pueden devolver hasta 256 elementos. Para limitar esto, use la opción '--max'. Establecer '--max' en 0 no devolverá todos los resultados. En su lugar, devolverá el valor predeterminado del servidor, que puede ser mucho mayor que 256. Combinar la opción '--max' con la opción '--offset' permite paginar los resultados. ``` helm list [flags] ``` ### Opciones ``` -a, --all muestra todos los releases sin ningún filtro aplicado -A, --all-namespaces lista releases en todos los namespaces -d, --date ordena por fecha de release --deployed muestra releases desplegados. Si no se especifica otro, se habilitará automáticamente --failed muestra releases fallidos -f, --filter string una expresión regular (compatible con Perl). Cualquier release que coincida con la expresión se incluirá en los resultados -h, --help ayuda para list -m, --max int número máximo de releases a obtener (por defecto 256) --no-headers no imprime encabezados cuando se usa el formato de salida predeterminado --offset int siguiente índice de release en la lista, usado para desplazarse desde el valor inicial -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --pending muestra releases pendientes -r, --reverse invierte el orden de clasificación -l, --selector string Selector (consulta de etiquetas) para filtrar, soporta '=', '==', y '!='.(ej. -l key1=value1,key2=value2). Funciona solo para backends de almacenamiento secret (por defecto) y configmap. -q, --short formato de listado corto (silencioso) --superseded muestra releases reemplazados --time-format string formatea la hora usando el formateador de tiempo de golang. Ejemplo: --time-format "2006-01-02 15:04:05Z0700" --uninstalled muestra releases desinstalados (si se usó 'helm uninstall --keep-history') --uninstalling muestra releases que están siendo desinstalados actualmente ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- empaqueta un directorio de chart en un archivo de chart ### Sinopsis Este comando empaqueta un chart en un archivo de chart versionado. Si se proporciona una ruta, buscará un chart en esa ubicación (que debe contener un archivo Chart.yaml) y luego empaquetará ese directorio. Los repositorios de paquetes de Helm utilizan archivos de chart versionados. Para firmar un chart, use la opción '--sign'. En la mayoría de los casos, también debería proporcionar '--keyring ruta/a/claves/secretas' y '--key nombre_clave'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg Si no se especifica '--keyring', Helm normalmente usa el llavero público por defecto, a menos que su entorno esté configurado de otra manera. ``` helm package [CHART_PATH] [...] [flags] ``` ### Opciones ``` --app-version string establece el appVersion en el chart a esta versión --ca-file string verifica certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL -u, --dependency-update actualiza las dependencias desde "Chart.yaml" al directorio "charts/" antes de empaquetar -d, --destination string ubicación donde escribir el chart (por defecto ".") -h, --help ayuda para package --insecure-skip-tls-verify omite las verificaciones del certificado TLS para la descarga del chart --key string nombre de la clave a usar al firmar. Se usa si --sign es true --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --keyring string ubicación del llavero público (por defecto "~/.gnupg/pubring.gpg") --passphrase-file string ubicación del archivo que contiene la frase de contraseña para la clave de firma. Use "-" para leer desde stdin. --password string contraseña del repositorio de charts donde ubicar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --sign usa una clave privada PGP para firmar este paquete --username string nombre de usuario del repositorio de charts donde ubicar el chart solicitado --version string establece la versión del chart a esta versión semver ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- instala, lista o desinstala plugins de Helm ### Sinopsis Administra plugins de Helm del lado del cliente. ### Opciones ``` -h, --help ayuda para plugin ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. * [helm plugin install](./helm_plugin_install.md) - instala un plugin de Helm * [helm plugin list](./helm_plugin_list.md) - lista los plugins de Helm instalados * [helm plugin uninstall](./helm_plugin_uninstall.md) - desinstala uno o más plugins de Helm * [helm plugin update](./helm_plugin_update.md) - actualiza uno o más plugins de Helm ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- instala un plugin de Helm ### Sinopsis Este comando permite instalar un plugin desde una URL de un repositorio VCS o una ruta local. ``` helm plugin install [options] [flags] ``` ### Opciones ``` -h, --help ayuda para install --version string especifica una restricción de versión. Si no se especifica, se instala la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm plugin](./helm_plugin.md) - instala, lista o desinstala plugins de Helm ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- lista los plugins de Helm instalados ``` helm plugin list [flags] ``` ### Opciones ``` -h, --help ayuda para list ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm plugin](./helm_plugin.md) - instala, lista o desinstala plugins de Helm ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- desinstala uno o más plugins de Helm ``` helm plugin uninstall ... [flags] ``` ### Opciones ``` -h, --help ayuda para uninstall ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm plugin](/helm/helm_plugin.md) - instala, lista o desinstala plugins de Helm ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- actualiza uno o más plugins de Helm ``` helm plugin update ... [flags] ``` ### Opciones ``` -h, --help ayuda para update ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm plugin](./helm_plugin.md) - instala, lista o desinstala plugins de Helm ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- descarga un chart de un repositorio y (opcionalmente) lo desempaqueta en un directorio local ### Sinopsis Recupera un paquete de un repositorio de paquetes y lo descarga localmente. Es útil para obtener paquetes e inspeccionarlos, modificarlos o reempaquetarlos. También puede usarse para realizar una verificación criptográfica de un chart sin instalarlo. Hay opciones para desempaquetar el chart después de la descarga. Esto creará un directorio para el chart y lo descomprimirá en ese directorio. Si se especifica la opción --verify, el chart solicitado DEBE tener un archivo de procedencia y DEBE pasar el proceso de verificación. Cualquier fallo en este proceso generará un error y el chart no se guardará localmente. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL -d, --destination string ubicación donde escribir el chart. Si se especifica junto con untardir, untardir se agrega a esta ruta (por defecto ".") --devel incluye versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esta opción se ignora. -h, --help ayuda para pull --insecure-skip-tls-verify omite las verificaciones del certificado TLS para la descarga del chart --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde ubicar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --prov descarga el archivo de procedencia, pero no realiza verificación --repo string URL del repositorio de charts donde ubicar el chart solicitado --untar si se establece a true, desempaquetará el chart después de descargarlo --untardir string si se especifica untar, esta opción indica el nombre del directorio donde se expandirá el chart (por defecto ".") --username string nombre de usuario del repositorio de charts donde ubicar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (p. ej. 1.1.1) o puede referenciar un rango válido (p. ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- sube un chart a un registro remoto ### Sinopsis Sube un chart a un registro. Si el chart tiene un archivo de procedencia asociado, este también será subido. ``` helm push [chart] [remote] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identifica el cliente del registro usando este archivo de certificado SSL -h, --help ayuda para push --insecure-skip-tls-verify omite las verificaciones del certificado TLS para la subida del chart --key-file string identifica el cliente del registro usando este archivo de clave SSL --password string contraseña del repositorio de charts donde ubicar el chart solicitado --plain-http usa conexiones HTTP inseguras para la subida del chart --username string nombre de usuario del repositorio de charts donde ubicar el chart solicitado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- iniciar o cerrar sesión en un registro ### Sinopsis Este comando consiste en múltiples subcomandos para interactuar con registros. ### Opciones ``` -h, --help ayuda para registry ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes de Helm para Kubernetes. * [helm registry login](./helm_registry_login.md) - iniciar sesión en un registro * [helm registry logout](./helm_registry_logout.md) - cerrar sesión de un registro ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- iniciar sesión en un registro ### Sinopsis Autenticarse en un registro remoto. ``` helm registry login [host] [flags] ``` ### Opciones ``` --ca-file string verificar certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identificar al cliente del registro usando este archivo de certificado SSL -h, --help ayuda para login --insecure permitir conexiones a un registro TLS sin certificados --key-file string identificar al cliente del registro usando este archivo de clave SSL -p, --password string contraseña del registro o token de identidad --password-stdin leer contraseña o token de identidad desde stdin --plain-http usar conexiones HTTP inseguras para la carga del chart -u, --username string nombre de usuario del registro ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm registry](./helm_registry.md) - iniciar o cerrar sesión en un registro ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- cerrar sesión de un registro ### Sinopsis Elimina las credenciales almacenadas para un registro remoto. ``` helm registry logout [host] [flags] ``` ### Opciones ``` -h, --help ayuda para logout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm registry](./helm_registry.md) - iniciar o cerrar sesión en un registro ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- añade, lista, elimina, actualiza e indexa repositorios de charts ### Sinopsis Este comando consiste en múltiples subcomandos para interactuar con repositorios de charts. Puede usarse para añadir, eliminar, listar e indexar repositorios de charts. ### Opciones ``` -h, --help ayuda para repo ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes de Helm para Kubernetes. * [helm repo add](./helm_repo_add.md) - añade un repositorio de charts * [helm repo index](./helm_repo_index.md) - genera un archivo de índice dado un directorio que contiene charts empaquetados * [helm repo list](./helm_repo_list.md) - lista repositorios de charts * [helm repo remove](./helm_repo_remove.md) - elimina uno o más repositorios de charts * [helm repo update](./helm_repo_update.md) - actualiza la información de charts disponibles localmente desde repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- añade un repositorio de charts ``` helm repo add [NAME] [URL] [flags] ``` ### Opciones ``` --allow-deprecated-repos por defecto, este comando no permite añadir repositorios oficiales que han sido eliminados permanentemente. Esta opción deshabilita ese comportamiento --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL --force-update reemplaza (sobrescribe) el repositorio si ya existe -h, --help ayuda para add --insecure-skip-tls-verify omite las verificaciones de certificado TLS para el repositorio --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --no-update Ignorado. Anteriormente, deshabilitaba las actualizaciones forzadas. Está obsoleto por force-update. --pass-credentials pasa las credenciales a todos los dominios --password string contraseña del repositorio de charts --password-stdin lee la contraseña del repositorio de charts desde stdin --timeout duration tiempo de espera para que se complete la descarga del archivo de índice (por defecto 2m0s) --username string nombre de usuario del repositorio de charts ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm repo](./helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- genera un archivo de índice a partir de un directorio con charts empaquetados ### Sinopsis Lee el directorio actual, genera un archivo de índice basado en los charts encontrados y escribe el resultado en 'index.yaml' en el directorio actual. Esta herramienta se utiliza para crear un archivo 'index.yaml' para un repositorio de charts. Para establecer una URL absoluta para los charts, use la opción '--url'. Para fusionar el índice generado con un archivo de índice existente, use la opción '--merge'. En este caso, los charts encontrados en el directorio actual se fusionarán con el índice proporcionado en --merge, donde los charts locales tienen prioridad sobre los charts existentes. ``` helm repo index [DIR] [flags] ``` ### Opciones ``` -h, --help ayuda para index --json salida en formato JSON --merge string fusiona el índice generado con el índice proporcionado --url string url del repositorio de charts ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm repo](./helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- lista repositorios de charts ``` helm repo list [flags] ``` ### Opciones ``` -h, --help ayuda para list -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm repo](./helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- elimina uno o más repositorios de charts ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Opciones ``` -h, --help ayuda para remove ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm repo](./helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- actualiza la información local de los charts disponibles en los repositorios ### Sinopsis Este comando obtiene la información más reciente sobre charts desde los repositorios de charts correspondientes. La información se almacena en caché localmente, donde es utilizada por comandos como 'helm search'. Opcionalmente puede especificar una lista de repositorios que desea actualizar. $ helm repo update ... Para actualizar todos los repositorios, use 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Opciones ``` --fail-on-repo-update-fail la actualización falla si alguna de las actualizaciones de repositorio falla -h, --help ayuda para update --timeout duration tiempo de espera para que se complete la descarga del archivo de índice (por defecto 2m0s) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm repo](./helm_repo.md) - añade, lista, elimina, actualiza e indexa repositorios de charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- revierte un release a una revisión anterior ### Sinopsis Este comando revierte un release a una revisión anterior. El primer argumento del comando rollback es el nombre de un release, y el segundo es un número de revisión (versión). Si se omite este argumento o se establece en 0, se revertirá al release anterior. Para ver los números de revisión, ejecute 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Opciones ``` --cleanup-on-fail permite eliminar nuevos recursos creados en este rollback cuando el rollback falla --dry-run simula un rollback --force fuerza la actualización de recursos mediante eliminación/recreación si es necesario -h, --help ayuda para rollback --history-max int limita el número máximo de revisiones guardadas por release. Use 0 para sin límite (por defecto 10) --no-hooks evita que los hooks se ejecuten durante el rollback --recreate-pods realiza el reinicio de pods para el recurso si es aplicable --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) --wait si se establece, esperará hasta que todos los Pods, PVCs, Services, y el número mínimo de Pods de un Deployment, StatefulSet o ReplicaSet estén en estado ready antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout --wait-for-jobs si se establece y --wait está habilitado, esperará hasta que todos los Jobs se hayan completado antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- busca una palabra clave en charts ### Sinopsis Permite buscar charts de Helm en los distintos lugares donde pueden estar almacenados, incluyendo Artifact Hub y los repositorios que haya añadido. Use los subcomandos de search para buscar en diferentes ubicaciones. ### Opciones ``` -h, --help ayuda para search ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes de Helm para Kubernetes. * [helm search hub](./helm_search_hub.md) - busca charts en Artifact Hub o en su propia instancia de hub * [helm search repo](./helm_search_repo.md) - busca charts por palabra clave en los repositorios ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- busca charts en Artifact Hub o en su propia instancia de hub ### Sinopsis Busca charts de Helm en Artifact Hub o en su propia instancia de hub. Artifact Hub es una aplicación web que permite encontrar, instalar y publicar paquetes y configuraciones para proyectos de CNCF, incluyendo charts de Helm disponibles públicamente. Es un proyecto sandbox de la Cloud Native Computing Foundation. Puede explorar el hub en https://artifacthub.io/ El argumento [KEYWORD] acepta una cadena de palabra clave o una cadena entre comillas con opciones de consulta avanzada. Para documentación sobre las opciones de consulta avanzada, consulte https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Las versiones anteriores de Helm utilizaban una instancia de Monocular como 'endpoint' predeterminado, por lo que Artifact Hub es compatible con la API de búsqueda de Monocular para mantener la compatibilidad con versiones anteriores. De manera similar, al establecer la opción 'endpoint', el endpoint especificado también debe implementar un endpoint de API de búsqueda compatible con Monocular. Tenga en cuenta que al especificar una instancia de Monocular como 'endpoint', las consultas avanzadas no son compatibles. Para detalles de la API, consulte https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Opciones ``` --endpoint string instancia de Hub a consultar para charts (por defecto "https://hub.helm.sh") --fail-on-no-result la búsqueda falla si no se encuentran resultados -h, --help ayuda para hub --list-repo-url imprime la URL del repositorio de charts --max-col-width uint ancho máximo de columna para la tabla de salida (por defecto 50) -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm search](./helm_search.md) - busca una palabra clave en charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- busca charts por palabra clave en los repositorios ### Sinopsis Lee todos los repositorios configurados en el sistema y busca coincidencias. La búsqueda en estos repositorios utiliza los metadatos almacenados en el sistema. Mostrará las últimas versiones estables de los charts encontrados. Si especifica la opción --devel, la salida incluirá versiones preliminares. Si desea buscar usando una restricción de versión, use --version. Ejemplos: # Buscar versiones de release estables que coincidan con la palabra clave "nginx" $ helm search repo nginx # Buscar versiones de release que coincidan con la palabra clave "nginx", incluyendo versiones preliminares $ helm search repo nginx --devel # Buscar la última versión estable de nginx-ingress con una versión mayor de 1 $ helm search repo nginx-ingress --version ^1.0.0 Los repositorios se gestionan con los comandos 'helm repo'. ``` helm search repo [keyword] [flags] ``` ### Opciones ``` --devel usar versiones de desarrollo (alpha, beta y release candidate) también. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora --fail-on-no-result la búsqueda falla si no se encuentran resultados -h, --help ayuda para repo --max-col-width uint ancho máximo de columna para la tabla de salida (por defecto 50) -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) -r, --regexp usar expresiones regulares para buscar en los repositorios que ha añadido --version string buscar usando restricciones de versionado semántico en los repositorios que ha añadido -l, --versions mostrar el listado largo, con cada versión de cada chart en su propia línea, para los repositorios que ha añadido ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm search](./helm_search.md) - busca una palabra clave en charts ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- muestra información de un chart ### Sinopsis Este comando consiste en múltiples subcomandos para mostrar información sobre un chart ### Opciones ``` -h, --help ayuda para show ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. * [helm show all](./helm_show_all.md) - muestra toda la información del chart * [helm show chart](./helm_show_chart.md) - muestra la definición del chart * [helm show crds](./helm_show_crds.md) - muestra los CRDs del chart * [helm show readme](./helm_show_readme.md) - muestra el README del chart * [helm show values](./helm_show_values.md) - muestra los values del chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- muestra toda la información del chart ### Sinopsis Este comando inspecciona un chart (directorio, archivo o URL) y muestra todo su contenido (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora -h, --help ayuda para all --insecure-skip-tls-verify omite las verificaciones de certificado TLS para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --repo string URL del repositorio de charts donde localizar el chart solicitado --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm show](./helm_show.md) - muestra información de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- muestra la definición del chart ### Sinopsis Este comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido del archivo Chart.yaml ``` helm show chart [CHART] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora -h, --help ayuda para chart --insecure-skip-tls-verify omite las verificaciones de certificado TLS para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --repo string URL del repositorio de charts donde localizar el chart solicitado --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm show](./helm_show.md) - muestra información de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- muestra los CRDs del chart ### Sinopsis Este comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido de los archivos CustomResourceDefinition ``` helm show crds [CHART] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora -h, --help ayuda para crds --insecure-skip-tls-verify omite las verificaciones de certificado TLS para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --repo string URL del repositorio de charts donde localizar el chart solicitado --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm show](./helm_show.md) - muestra información de un chart ###### Generado automáticamente por spf13/cobra el 14-Ene-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- muestra el README del chart ### Sinopsis Este comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido del archivo README ``` helm show readme [CHART] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora -h, --help ayuda para readme --insecure-skip-tls-verify omite las verificaciones de certificado TLS para la descarga del chart --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --repo string URL del repositorio de charts donde localizar el chart solicitado --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm show](./helm_show.md) - muestra información de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- muestra los valores del chart ### Sinopsis Este comando inspecciona un chart (directorio, archivo o URL) y muestra el contenido del archivo values.yaml ``` helm show values [CHART] [flags] ``` ### Opciones ``` --ca-file string verifica certificados de servidores HTTPS usando este paquete de CA --cert-file string identifica al cliente HTTPS usando este archivo de certificado SSL --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora -h, --help ayuda para values --insecure-skip-tls-verify omite las verificaciones de certificado TLS para la descarga del chart --jsonpath string proporciona una expresión JSONPath para filtrar la salida --key-file string identifica al cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --repo string URL del repositorio de charts donde localizar el chart solicitado --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm show](./helm_show.md) - muestra información de un chart ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- muestra el estado del release especificado ### Sinopsis Este comando muestra el estado de un release especificado. El estado consiste en: - fecha y hora del último despliegue - namespace de Kubernetes en el que reside el release - estado del release (puede ser: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade o pending-rollback) - revisión del release - descripción del release (puede ser un mensaje de finalización o un mensaje de error, requiere habilitar --show-desc) - lista de recursos que componen este release (requiere habilitar --show-resources) - detalles de la última ejecución del conjunto de pruebas, si aplica - notas adicionales proporcionadas por el chart ``` helm status RELEASE_NAME [flags] ``` ### Opciones ``` -h, --help ayuda para status -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --revision int si se establece, muestra el estado del release especificado con esa revisión --show-desc si se establece, muestra el mensaje de descripción del release especificado --show-resources si se establece, muestra los recursos del release especificado ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- renderiza plantillas localmente ### Sinopsis Renderiza las plantillas del chart localmente y muestra la salida. Cualquier valor que normalmente se buscaría o recuperaría en el clúster será simulado localmente. Además, no se realiza ninguna validación del chart del lado del servidor (por ejemplo, si una API es compatible). ``` helm template [NAME] [CHART] [flags] ``` ### Opciones ``` -a, --api-versions strings versiones de la API de Kubernetes utilizadas para Capabilities.APIVersions --atomic si se establece, el proceso de instalación elimina la instalación en caso de fallo. La opción --wait se establece automáticamente si se usa --atomic --ca-file string verifica certificados de servidores con HTTPS habilitado usando este bundle de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL --create-namespace crea el namespace del release si no está presente --dependency-update actualiza las dependencias si faltan antes de instalar el chart --description string añade una descripción personalizada --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si se establece --version, esto se ignora --disable-openapi-validation si se establece, el proceso de instalación no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes --dry-run string[="client"] simula una instalación. Si --dry-run se establece sin especificar una opción o como '--dry-run=client', no intentará conexiones al clúster. Establecer '--dry-run=server' permite intentar conexiones al clúster. --enable-dns habilita búsquedas DNS al renderizar plantillas --force fuerza actualizaciones de recursos a través de una estrategia de reemplazo -g, --generate-name genera el nombre (y omite el parámetro NAME) -h, --help ayuda para template --hide-notes si se establece, no muestra las notas en la salida. No afecta su presencia en los metadatos del chart --include-crds incluye CRDs en la salida renderizada --insecure-skip-tls-verify omite verificaciones de certificado TLS para la descarga del chart --is-upgrade establece .Release.IsUpgrade en lugar de .Release.IsInstall --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") --kube-version string versión de Kubernetes usada para Capabilities.KubeVersion -l, --labels stringToString etiquetas que se añadirían a los metadatos del release. Deben separarse con comas. (por defecto []) --name-template string especifica la plantilla usada para nombrar el release --no-hooks evita que los hooks se ejecuten durante la instalación --output-dir string escribe las plantillas ejecutadas en archivos en output-dir en lugar de stdout --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --post-renderer postRendererString la ruta a un ejecutable para usar en post-renderizado. Si existe en $PATH, se usará el binario, de lo contrario intentará buscar el ejecutable en la ruta especificada --post-renderer-args postRendererArgsSlice un argumento para el post-renderer (puede especificar múltiples) (por defecto []) --release-name usa el nombre del release en la ruta de output-dir. --render-subchart-notes si se establece, renderiza las notas del subchart junto con el padre --replace reutiliza el nombre dado, solo si ese nombre es un release eliminado que permanece en el historial. Esto es inseguro en producción --repo string URL del repositorio de charts donde localizar el chart solicitado --set stringArray establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --set-file stringArray establece valores desde los archivos respectivos especificados en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=path1,key2=path2) --set-json stringArray establece valores JSON en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=jsonval1,key2=jsonval2) --set-literal stringArray establece un valor STRING literal en la línea de comandos --set-string stringArray establece valores STRING en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) -s, --show-only stringArray solo muestra manifiestos renderizados desde las plantillas especificadas --skip-crds si se establece, no se instalarán CRDs. Por defecto, los CRDs se instalan si no están presentes --skip-schema-validation si se establece, deshabilita la validación del esquema JSON --skip-tests omite las pruebas en la salida renderizada --take-ownership si se establece, install ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado --validate valida sus manifiestos contra el clúster de Kubernetes al que está apuntando actualmente. Esta es la misma validación que se realiza en una instalación -f, --values strings especifica valores en un archivo YAML o una URL (puede especificar múltiples) --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede referenciar un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión --wait si se establece, esperará hasta que todos los Pods, PVCs, Services y el número mínimo de Pods de un Deployment, StatefulSet o ReplicaSet estén en estado ready antes de marcar el release como exitoso. Esperará tanto como --timeout --wait-for-jobs si se establece y --wait está habilitado, esperará hasta que todos los Jobs se hayan completado antes de marcar el release como exitoso. Esperará tanto como --timeout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- ejecuta las pruebas de un release ### Sinopsis El comando test ejecuta las pruebas de un release. Este comando recibe como argumento el nombre de un release desplegado. Las pruebas que se ejecutarán están definidas en el chart instalado. ``` helm test [RELEASE] [flags] ``` ### Opciones ``` --filter strings especifica pruebas por atributo (actualmente "name") usando sintaxis atributo=valor o '!atributo=valor' para excluir una prueba (puede especificar múltiples o separar valores con comas: name=test1,name=test2) -h, --help ayuda para test --hide-notes si se establece, no muestra las notas en la salida de test. No afecta su presencia en los metadatos del chart --logs vuelca los logs de los pods de prueba (esto se ejecuta después de que todas las pruebas se completen, pero antes de cualquier limpieza) --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- desinstala un release ### Sinopsis Este comando recibe un nombre de release y lo desinstala. Elimina todos los recursos asociados con la última versión del chart, así como el historial del release, liberándolo para uso futuro. Use la opción '--dry-run' para ver qué releases serán desinstalados sin desinstalarlos realmente. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Opciones ``` --cascade string Debe ser "background", "orphan" o "foreground". Selecciona la estrategia de eliminación en cascada para los dependientes. Por defecto es background. (por defecto "background") --description string añade una descripción personalizada --dry-run simula una desinstalación -h, --help ayuda para uninstall --ignore-not-found Trata "release no encontrado" como una desinstalación exitosa --keep-history elimina todos los recursos asociados y marca el release como eliminado, pero retiene el historial del release --no-hooks evita que los hooks se ejecuten durante la desinstalación --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) --wait si se establece, esperará hasta que todos los recursos sean eliminados antes de finalizar. Esperará tanto tiempo como se especifique en --timeout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a usar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer usado para autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](/helm/helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- actualiza un release a una nueva versión de un chart ### Sinopsis Este comando actualiza un release a una nueva versión de un chart. Los argumentos de upgrade deben ser un release y un chart. El argumento chart puede ser: una referencia de chart ('example/mariadb'), una ruta a un directorio de chart, un chart empaquetado, o una URL completamente cualificada. Para referencias de chart, se especificará la última versión a menos que se establezca la opción '--version'. Para sobrescribir valores en un chart, use la opción '--values' y proporcione un archivo, o use la opción '--set' y pase la configuración desde la línea de comandos. Para forzar valores de tipo string, use '--set-string'. Puede usar '--set-file' para establecer valores individuales desde un archivo cuando el valor es demasiado largo para la línea de comandos o se genera dinámicamente. También puede usar '--set-json' para establecer valores JSON (escalares/objetos/arrays) desde la línea de comandos. Puede especificar la opción '--values'/'-f' múltiples veces. Se dará prioridad al último archivo especificado. Por ejemplo, si tanto myvalues.yaml como override.yaml contienen una clave llamada 'Test', el valor en override.yaml tendrá precedencia: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Puede especificar la opción '--set' múltiples veces. Se dará prioridad al último valor especificado. Por ejemplo, si se asignan los valores 'bar' y 'newbar' a una clave llamada 'foo', el valor 'newbar' tendrá precedencia: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis También puede actualizar los valores de un release existente con este comando mediante la opción '--reuse-values'. Los argumentos 'RELEASE' y 'CHART' deben establecerse a los parámetros originales, y los valores existentes se fusionarán con cualquier valor establecido mediante las opciones '--values'/'-f' o '--set'. La prioridad se da a los nuevos valores. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis La opción --dry-run mostrará todos los manifiestos de chart generados, incluyendo Secrets que pueden contener valores sensibles. Para ocultar los Secrets de Kubernetes use la opción --hide-secret. Por favor considere cuidadosamente cómo y cuándo usar estas opciones. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Opciones ``` --atomic si se establece, el proceso de upgrade revierte los cambios realizados en caso de un upgrade fallido. La opción --wait se establecerá automáticamente si se usa --atomic --ca-file string verifica certificados de servidores habilitados con HTTPS usando este paquete de CA --cert-file string identifica el cliente HTTPS usando este archivo de certificado SSL --cleanup-on-fail permite eliminar nuevos recursos creados en este upgrade cuando el upgrade falla --create-namespace si --install está establecido, crea el namespace del release si no está presente --dependency-update actualiza las dependencias si faltan antes de instalar el chart --description string añade una descripción personalizada --devel usa también versiones de desarrollo. Equivalente a version '>0.0.0-0'. Si --version está establecido, esto se ignora --disable-openapi-validation si se establece, el proceso de upgrade no validará las plantillas renderizadas contra el esquema OpenAPI de Kubernetes --dry-run string[="client"] simula una instalación. Si --dry-run se establece sin especificar opción o como '--dry-run=client', no intentará conexiones al clúster. Establecer '--dry-run=server' permite intentar conexiones al clúster. --enable-dns habilita búsquedas DNS al renderizar plantillas --force fuerza actualizaciones de recursos mediante una estrategia de reemplazo -h, --help ayuda para upgrade --hide-notes si se establece, no muestra las notas en la salida del upgrade. No afecta su presencia en los metadatos del chart --hide-secret oculta los Secrets de Kubernetes cuando también se usa la opción --dry-run --history-max int limita el número máximo de revisiones guardadas por release. Use 0 para sin límite (por defecto 10) --insecure-skip-tls-verify omite verificaciones de certificado TLS para la descarga del chart -i, --install si un release con este nombre no existe, ejecuta una instalación --key-file string identifica el cliente HTTPS usando este archivo de clave SSL --keyring string ubicación de las claves públicas usadas para verificación (por defecto "~/.gnupg/pubring.gpg") -l, --labels stringToString etiquetas que se añadirán a los metadatos del release. Deben separarse por coma. Las etiquetas originales del release se fusionarán con las etiquetas del upgrade. Puede eliminar una etiqueta usando null. (por defecto []) --no-hooks deshabilita los hooks pre/post upgrade -o, --output format imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table) --pass-credentials pasa credenciales a todos los dominios --password string contraseña del repositorio de charts donde localizar el chart solicitado --plain-http usa conexiones HTTP inseguras para la descarga del chart --post-renderer postRendererString la ruta a un ejecutable que se usará para post-renderizado. Si existe en $PATH, se usará el binario, de lo contrario intentará buscar el ejecutable en la ruta proporcionada --post-renderer-args postRendererArgsSlice un argumento para el post-renderer (puede especificar múltiples) (por defecto []) --render-subchart-notes si se establece, renderiza las notas del subchart junto con el padre --repo string URL del repositorio de charts donde localizar el chart solicitado --reset-then-reuse-values al actualizar, restablece los valores a los incorporados en el chart, aplica los valores del último release y fusiona cualquier sobrescritura de la línea de comandos mediante --set y -f. Si se especifica '--reset-values' o '--reuse-values', esto se ignora --reset-values al actualizar, restablece los valores a los incorporados en el chart --reuse-values al actualizar, reutiliza los valores del último release y fusiona cualquier sobrescritura de la línea de comandos mediante --set y -f. Si se especifica '--reset-values', esto se ignora --set stringArray establece valores en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --set-file stringArray establece valores desde los archivos respectivos especificados mediante la línea de comandos (puede especificar múltiples o separar valores con comas: key1=path1,key2=path2) --set-json stringArray establece valores JSON en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=jsonval1,key2=jsonval2) --set-literal stringArray establece un valor STRING literal en la línea de comandos --set-string stringArray establece valores STRING en la línea de comandos (puede especificar múltiples o separar valores con comas: key1=val1,key2=val2) --skip-crds si se establece, no se instalarán CRDs cuando se realice un upgrade con la opción install habilitada. Por defecto, los CRDs se instalan si no están presentes, cuando se realiza un upgrade con la opción install habilitada --skip-schema-validation si se establece, deshabilita la validación de esquema JSON --take-ownership si se establece, el upgrade ignorará la verificación de anotaciones de helm y tomará posesión de los recursos existentes --timeout duration tiempo de espera para cualquier operación individual de Kubernetes (como Jobs para hooks) (por defecto 5m0s) --username string nombre de usuario del repositorio de charts donde localizar el chart solicitado -f, --values strings especifica valores en un archivo YAML o una URL (puede especificar múltiples) --verify verifica el paquete antes de usarlo --version string especifica una restricción de versión para la versión del chart a usar. Esta restricción puede ser una etiqueta específica (ej. 1.1.1) o puede hacer referencia a un rango válido (ej. ^2.0.0). Si no se especifica, se usa la última versión --wait si se establece, esperará hasta que todos los Pods, PVCs, Services, y el número mínimo de Pods de un Deployment, StatefulSet o ReplicaSet estén en estado ready antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout --wait-for-jobs si se establece y --wait está habilitado, esperará hasta que todos los Jobs se hayan completado antes de marcar el release como exitoso. Esperará tanto tiempo como --timeout ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- verifica que un chart en la ruta dada ha sido firmado y es válido ### Sinopsis Verifica que el chart especificado tenga un archivo de procedencia válido. Los archivos de procedencia proporcionan verificación criptográfica de que un chart no ha sido manipulado y fue empaquetado por un proveedor de confianza. Este comando permite verificar un chart local. Otros comandos proporcionan opciones '--verify' que ejecutan la misma validación. Para generar un paquete firmado, use el comando 'helm package --sign'. ``` helm verify PATH [flags] ``` ### Opciones ``` -h, --help ayuda para verify --keyring string llavero que contiene las claves públicas (por defecto "~/.gnupg/pubring.gpg") ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- muestra la información de versión del cliente ### Sinopsis Muestra la versión de Helm. Este comando imprimirá una representación de la versión de Helm. La salida tendrá un aspecto similar a este: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version es la versión semántica de la release. - GitCommit es el SHA del commit a partir del cual se construyó esta versión. - GitTreeState es "clean" si no hay cambios locales en el código cuando se construyó este binario, y "dirty" si el binario fue construido a partir de código modificado localmente. - GoVersion es la versión de Go que se utilizó para compilar Helm. Cuando utilice la opción --template, las siguientes propiedades están disponibles para usar en la plantilla: - .Version contiene la versión semántica de Helm - .GitCommit es el commit de git - .GitTreeState es el estado del árbol de git cuando se construyó Helm - .GoVersion contiene la versión de Go con la que se compiló Helm Por ejemplo, --template='Version: {{.Version}}' produce 'Version: v3.2.1'. ``` helm version [flags] ``` ### Opciones ``` -h, --help ayuda para version --short muestra solo el número de versión --template string plantilla para el formato de la cadena de versión ``` ### Opciones heredadas de comandos padre ``` --burst-limit int límite de throttling del lado del cliente (por defecto 100) --debug habilita la salida detallada --kube-apiserver string la dirección y el puerto del servidor de API de Kubernetes --kube-as-group stringArray grupo a suplantar para la operación, esta opción puede repetirse para especificar múltiples grupos. --kube-as-user string nombre de usuario a suplantar para la operación --kube-ca-file string el archivo de autoridad de certificación para la conexión al servidor de API de Kubernetes --kube-context string nombre del contexto de kubeconfig a utilizar --kube-insecure-skip-tls-verify si es true, no se verificará la validez del certificado del servidor de API de Kubernetes. Esto hará que sus conexiones HTTPS sean inseguras --kube-tls-server-name string nombre del servidor a usar para la validación del certificado del servidor de API de Kubernetes. Si no se proporciona, se usa el nombre de host utilizado para contactar al servidor --kube-token string token bearer utilizado para la autenticación --kubeconfig string ruta al archivo kubeconfig -n, --namespace string ámbito del namespace para esta solicitud --qps float32 consultas por segundo utilizadas al comunicarse con la API de Kubernetes, sin incluir ráfagas --registry-config string ruta al archivo de configuración del registro (por defecto "~/.config/helm/registry/config.json") --repository-cache string ruta al directorio que contiene los índices de repositorios en caché (por defecto "~/.cache/helm/repository") --repository-config string ruta al archivo que contiene los nombres y URLs de los repositorios (por defecto "~/.config/helm/repositories.yaml") ``` ### VEA TAMBIÉN * [helm](./helm.md) - El gestor de paquetes Helm para Kubernetes. ###### Generado automáticamente por spf13/cobra el 14-Jan-2026 ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: "Chart Releaser Action para automatizar la publicación de Charts en GitHub Pages" description: "Describe cómo utilizar Chart Releaser Action para automatizar la publicación de charts a través de GitHub Pages." sidebar_position: 3 --- Esta guía describe cómo utilizar [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) para automatizar la publicación de charts a través de GitHub Pages. Chart Releaser Action es un workflow de GitHub Action para convertir un proyecto de GitHub en un repositorio de Helm charts autoalojado, utilizando la herramienta CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Cambios en el Repositorio Cree un repositorio Git en su organización de GitHub. Puede nombrar el repositorio como `helm-charts`, aunque otros nombres también son aceptables. El código fuente de todos los charts puede colocarse en la rama `main`. Los charts deben ubicarse en el directorio `/charts` en el nivel superior del árbol de directorios. Debe existir otra rama llamada `gh-pages` para publicar los charts. Los cambios en esa rama serán creados automáticamente por Chart Releaser Action como se describe aquí. Sin embargo, puede crear esa rama `gh-pages` y añadir un archivo `README.md`, que será visible para los usuarios que visiten la página. Puede añadir instrucciones en el `README.md` para la instalación de charts de la siguiente manera (reemplace ``, `` y ``): ``` ## Uso [Helm](https://helm.sh) debe estar instalado para usar los charts. Consulte la [documentación](https://helm.sh/docs) de Helm para comenzar. Una vez que Helm esté configurado correctamente, añada el repositorio de la siguiente manera: helm repo add https://.github.io/helm-charts Si ya añadió este repositorio anteriormente, ejecute `helm repo update` para obtener las últimas versiones de los paquetes. Luego puede ejecutar `helm search repo ` para ver los charts. Para instalar el chart : helm install my- / Para desinstalar el chart: helm uninstall my- ``` Los charts se publicarán en un sitio web con una URL como esta: https://.github.io/helm-charts ## GitHub Actions Workflow Cree un archivo de workflow de GitHub Actions en la rama `main` en `.github/workflows/release.yml` ```yaml name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` La configuración anterior utiliza [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) para convertir su proyecto de GitHub en un repositorio de Helm charts autoalojado. Esto funciona de la siguiente manera: durante cada push a main, verifica cada chart en su proyecto y, cuando hay una nueva versión de chart, crea un release de GitHub correspondiente con el nombre de la versión del chart, añade los artefactos del Helm chart al release, y crea o actualiza un archivo `index.yaml` con metadatos sobre esos releases, que luego se alojan en GitHub Pages. La versión de Chart Releaser Action utilizada en el ejemplo anterior es `v1.6.0`. Puede cambiarla por la [última versión disponible](https://github.com/helm/chart-releaser-action/releases). Nota: Chart Releaser Action se utiliza casi siempre junto con [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) y [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: "Sincronizar su Repositorio de Charts" description: "Describe cómo sincronizar sus repositorios de charts locales y remotos." sidebar_position: 2 --- *Nota: Este ejemplo es específico para un bucket de Google Cloud Storage (GCS) que sirve como repositorio de charts.* ## Requisitos Previos * Instalar la herramienta [gsutil](https://cloud.google.com/storage/docs/gsutil). *Dependemos en gran medida de la funcionalidad de gsutil rsync* * Asegúrese de tener acceso al binario de Helm * _Opcional: Le recomendamos que establezca [control de versiones del objeto](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) en su bucket de GCS en caso de que elimine algo accidentalmente._ ## Configurar un directorio de repositorio de charts local Cree un directorio local como lo hicimos en [la guía del repositorio de charts](/topics/chart_repository.md) , y coloque sus charts empaquetados en ese directorio. Por ejemplo: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Genere un index.yaml actualizado Utilice Helm para generar un archivo index.yaml actualizado pasando la ruta del directorio y la URL del repositorio remoto al comando `helm repo index` de esta manera: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Esto generará un archivo index.yaml actualizado y lo colocará en el directorio `fantastic-charts/`. ## Sincronice sus repositorios de charts locales y remotos Suba el contenido del directorio a su bucket de GCS ejecutando `scripts/sync-repo.sh` y pase el nombre del directorio local y el nombre del bucket de GCS. Por ejemplo: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Actualizar su repositorio de charts Querrá mantener una copia local del contenido de su repositorio de charts o usar `gsutil rsync` para copiar el contenido de su repositorio de charts remoto a un directorio local. Por ejemplo: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # la bandera -n hace un ensayo Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # realiza las acciones de copia Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Enlaces Útiles: * Documentación sobre [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [La Guía del Repositorio de Charts](/topics/chart_repository.md) * Documentación sobre [Control de versiones de objetos y control de simultaneidad](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) en Google Cloud Storage ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: "Consejos y Trucos para el Desarrollo de Charts" description: "Cubre algunos de los consejos y trucos que los desarrolladores de charts de Helm han aprendido al crear charts con calidad de producción." sidebar_position: 1 --- Esta guía cubre algunos de los consejos y trucos que los desarrolladores de charts de Helm han aprendido al crear charts con calidad de producción. ## Conozca las Funciones de Plantilla Helm usa [plantillas Go](https://godoc.org/text/template) para crear plantillas para sus archivos de recursos. Si bien Go incluye varias funciones integradas, hemos agregado muchas otras. Primero, agregamos todas las funciones en la [biblioteca Sprig](https://masterminds.github.io/sprig/), excepto `env` y `expandenv`, por razones de seguridad. También agregamos dos funciones de plantilla especiales: `include` y `required`. La función `include` le permite traer otra plantilla y luego pasar los resultados a otras funciones de la plantilla. Por ejemplo, este fragmento de plantilla incluye una plantilla llamada `mytpl`, luego pone el resultado en minúsculas y luego lo envuelve entre comillas dobles. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` La función `required` le permite declarar una entrada de valores particulares según sea necesario para la representación de la plantilla. Si el valor está vacío, la representación de la plantilla fallará con un mensaje de error enviado al usuario. El siguiente ejemplo de la función `required` declara que una entrada para `.Values.who` es obligatoria e imprimirá un mensaje de error cuando falte esa entrada: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Envuelva en Comillas las Cadenas, no los Enteros Cuando trabaja con cadenas de caracteres, siempre es más seguro envolverlas entre comillas dobles que dejarlas como palabras sueltas: ```yaml name: {{ .Values.MyName | quote }} ``` Pero cuando trabaje con números enteros, _no envuelva entre comillas dobles los valores._ Eso puede, en muchos casos, causar errores de análisis dentro de Kubernetes. ```yaml port: {{ .Values.Port }} ``` Esta observación no se aplica a los valores de las variables de entorno que se espera que sean cadenas, incluso si representan números enteros: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Utilizar la Función 'include' Go proporciona una forma de incluir una plantilla en otra utilizando la directiva incorporada `template`. Sin embargo, la directiva incorporada no se puede utilizar en las canalizaciones de plantilla de Go. Para que sea posible incluir una plantilla y luego realizar una operación en la salida de esa plantilla, Helm tiene una función `include` especial: ``` {{ include "toYaml" $value | indent 2 }} ``` Lo anterior incluye una plantilla llamada `toYaml`, le pasa `$value` y luego pasa la salida de esa plantilla a la función `indent`. Debido a que YAML atribuye importancia a los niveles de sangría y los espacios en blanco, esta es una excelente manera de incluir fragmentos de código, pero manejar la sangría en un contexto relevante. ## Utilizar la Función 'required' Go proporciona una forma de configurar opciones de plantilla para controlar el comportamiento cuando un mapa se indexa con una clave que no está presente en el mapa. Por lo general, esto se establece con `template.Options("missingkey=option")`, donde `option` puede ser `default`, `zero` o `error`. Si bien establecer esta opción en error detendrá la ejecución con un error, esto se aplicaría a todas las claves que faltan en el mapa. Puede haber situaciones en las que un desarrollador de charts quiera aplicar este comportamiento para valores seleccionados en el archivo `values.yaml`. La función `required` brinda a los desarrolladores la capacidad de declarar una entrada de valor según sea necesario para la renderización de la plantilla. Si la entrada está vacía en `values.yaml`, la plantilla no se procesará y devolverá un mensaje de error proporcionado por el desarrollador. Por ejemplo: ``` {{ required "A valid foo is required!" .Values.foo }} ``` Lo anterior renderizará la plantilla cuando se defina `.Values.foo`, pero fallará en renderizar y se cerrará cuando `.Values.foo` no esté definido. ## Utilizar la Función 'tpl' La función `tpl` permite a los desarrolladores evaluar cadenas como plantillas dentro de una plantilla. Esto es útil para pasar una cadena de plantilla como valor a un chart o representar archivos de configuración externos. Sintaxis: `{{ tpl TEMPLATE_STRING VALUES }}` Ejemplos: ```yaml # valores template: "{{ .Values.name }}" name: "Tom" # plantilla {{ tpl .Values.template . }} # salida Tom ``` Renderizar un archivo de configuración externo: ```yaml # archivo de configuración externo conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # valores firstName: Peter lastName: Parker # plantilla {{ tpl (.Files.Get "conf/app.conf") . }} # salida firstName=Peter lastName=Parker ``` ## Creando Image Pull Secrets Los Image Pull Secrets son esencialmente una combinación de _registro_, _username_ y _password_. Es posible que los necesite en una aplicación que está implementando, pero para crearlos es necesario ejecutar `base64` un par de veces. Podemos escribir una plantilla auxiliar para componer el archivo de configuración de Docker y usarlo como carga útil del Secret. Aquí hay un ejemplo: Primero, suponga que las credenciales están definidas en el archivo `values.yaml` así: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Luego definimos nuestra plantilla auxiliar de la siguiente manera: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Finalmente, usamos la plantilla auxiliar en una plantilla más grande para crear el manifiesto del Secret: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Despliegue Automático de Deployments A menudo, los ConfigMaps o Secrets se inyectan como archivos de configuración en contenedores o hay otros cambios de dependencia externa que requieren recrear pods. Dependiendo de la aplicación, es posible que sea necesario reiniciar si se actualizan con un `helm upgrade` posterior, pero si el Deployment spec en sí no cambia, la aplicación sigue ejecutándose con la configuración anterior, lo que da como resultado un despliegue inconsistente. La función `sha256sum` se puede utilizar para garantizar que la sección de anotaciones de un Deployment se actualice si cambia otro archivo: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTA: Si está agregando esto a un library chart, no podrá acceder a su archivo en `$.Template.BasePath`. En su lugar, puede hacer referencia a su definición con `{{ include ("mylibchart.configmap") . | sha256sum }}`. En el caso de que siempre desee reiniciar su Deployment, puede usar un paso de anotación similar al anterior, en lugar de reemplazarlo con una cadena aleatoria para que siempre cambie y haga que el Deployment se reinicie: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Cada invocación de la función de plantilla generará una cadena aleatoria única. Esto significa que si es necesario sincronizar las cadenas aleatorias utilizadas por varios recursos, todos los recursos relevantes deberán estar en el mismo archivo de plantilla. Ambos métodos permiten que su Deployment aproveche la lógica de la estrategia de actualización incorporada para evitar tener tiempo de inactividad. NOTA: En el pasado, recomendamos usar la marca `--recreate-pods` como otra opción. Esta marca se ha marcado como obsoleta en Helm 3 a favor del método más declarativo anterior. ## Dígale a Helm que No Desinstale un Recurso A veces hay recursos que no deben desinstalarse cuando Helm ejecuta un `helm uninstall`. Los desarrolladores de charts pueden agregar una anotación a un recurso para evitar que se desinstale. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` La anotación `helm.sh/resource-policy: keep` indica a Helm que omita la eliminación de este recurso cuando una operación de helm (como `helm uninstall`, `helm upgrade` o `helm rollback`) resulte en su eliminación. _Sin embargo_, este recurso queda huérfano. Helm ya no lo administrará de ninguna manera. Esto puede ocasionar problemas si se usa `helm install --replace` en un release que ya se ha desinstalado, pero que ha conservado los recursos. ## Utilizar "Parciales" (Partials) e Incluir Plantillas A veces, desea crear algunas partes reutilizables en sus charts, ya sean bloques o parciales de plantilla. Y, a menudo, es más limpio mantenerlos en sus propios archivos. En el directorio `templates/`, no se espera que ningún archivo que comience con un guión bajo (`_`) genere un archivo de manifiesto de Kubernetes. Entonces, por convención, las plantillas auxiliares y los parciales se colocan en un archivo `_helpers.tpl`. ## Charts Complejos con Muchas Dependencias Muchos de los charts de [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF son "bloques de construcción" para crear aplicaciones más avanzadas. Pero los charts pueden usarse para crear instancias de aplicaciones a gran escala. En tales casos, un solo chart general puede tener múltiples sub-charts, cada uno de los cuales funciona como una parte del todo. La mejor práctica actual para componer una aplicación compleja a partir de partes discretas es crear un chart general de nivel superior que exponga las configuraciones globales, y luego usar el subdirectorio `charts/` para incrustar cada uno de los componentes. ## YAML es un Superconjunto de JSON Según la especificación YAML, YAML es un superconjunto de JSON. Eso significa que cualquier estructura JSON válida debería ser válida en YAML. Esto tiene una ventaja: a veces, a los desarrolladores de plantillas les puede resultar más fácil expresar una estructura de datos con una sintaxis similar a JSON en lugar de lidiar con la sensibilidad de los espacios en blanco de YAML. Como práctica recomendada, las plantillas deben seguir una sintaxis similar a YAML, _a menos que_ la sintaxis JSON reduzca sustancialmente el riesgo de problemas de formato. ## Tenga Cuidado con la Generación de Valores Aleatorios Hay funciones en Helm que le permiten generar datos aleatorios, claves criptográficas, etc. Está bien usarlos. Pero tenga en cuenta que durante las actualizaciones, las plantillas se vuelven a ejecutar. Cuando la ejecución de una plantilla genera datos que difieren de la última ejecución, se activará una actualización de ese recurso. ## Instalar o Actualizar un Release con un Comando Helm proporciona una forma de realizar una instalación o actualización como un solo comando. Utilice `helm upgrade` con el comando `--install`. Esto hará que Helm vea si el release ya está instalado. De lo contrario, ejecutará una instalación. Si es así, se actualizará el release existente. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: "Cómo Hacer" sidebar_position: 2 --- # Guías de Cómo Hacer Aquí encontrará respuestas breves a preguntas del tipo “¿Cómo hago para ...?”. Estas guías prácticas no cubren temas en profundidad; encontrará ese material en las [Guías de Temas](/topics/index.mdx). Sin embargo, estas guías lo ayudarán a realizar rápidamente tareas comunes. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Docs Inicio" description: "Todo lo que necesita saber sobre cómo está organizada la documentación." sidebar_position: 1 hide_table_of_contents: true --- # Bienvenidos Bienvenidos a la documentación de [Helm](https://helm.sh/). Helm es el administrador de paquetes de Kubernetes, y puedes leer información de antecedentes detallados en el [CNCF Informe de Viaje del Proyecto de Helm](https://www.cncf.io/cncf-helm-project-journey/). # Cómo está organizada la documentación Helm tiene mucha documentación. Una descripción general de alto nivel de cómo está organizado lo ayudará a saber dónde buscar ciertas cosas: - [Tutoriales](/intro/index.mdx) te llevan de la mano a través de una serie de pasos para crear tu primer Helm chart. Empieza aquí si eres nuevo en Helm. - [Guías de temas](/topics/index.mdx) discute temas y conceptos clave a un nivel bastante alto y proporcionar información de antecedentes y explicaciones útiles. - [Guías de la comunidad](/community) discute temas centrados en la comunidad de Helm. Comience aquí si desea obtener más información sobre el proceso de desarrollo de Helm y cómo puede contribuir. - [Guías prácticas](/howto/index.mdx) son recetas. Le guían a través de los pasos necesarios para abordar problemas clave y casos de uso. Son más avanzados que los tutoriales y asumen cierto conocimiento de cómo funciona Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Guía Rápida description: Guía rápida de comandos de Helm sidebar_position: 4 --- Guía rápida de Helm con todos los comandos necesarios para gestionar una aplicación a través de Helm. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Interpretaciones básicas/contexto Chart: - Es el nombre de su chart en caso de que haya sido descargada y descomprimida. - Es / en caso de que el repositorio se haya añadido pero la chart no se haya descargado. - Es la URL/ruta absoluta a la chart. Name: - Es el nombre que desea dar a su instalación actual de Helm chart. Release: - Es el nombre que asignó a una instancia de instalación. Revision: - Es el valor del comando Helm history. Repo-name: - El nombre de un repositorio. DIR: - Nombre del directorio/ruta. ------------------------------------------------------------------------------------------------------------------------------------------------ ### Gestión de Charts ```bash helm create # Crea un directorio de chart junto con los archivos y directorios comunes usados en una chart. helm package # Empaqueta una chart en un archivo chart versionado. helm lint # Ejecuta pruebas para examinar una chart e identificar posibles problemas. helm show all # Inspecciona una chart y lista su contenido. helm show values # Muestra el contenido del archivo values.yaml. helm pull # Descarga una chart. helm pull --untar=true # Si se establece en true, descomprime la chart después de descargarla. helm pull --verify # Verifica el paquete antes de usarlo. helm pull --version # Por defecto se usa la última versión; especifica una restricción de versión para la chart. helm dependency list # Muestra una lista de las dependencias de una chart. ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Instalar y desinstalar aplicaciones ```bash helm install # Instala la chart con un nombre. helm install --namespace # Instala la chart en un namespace específico. helm install --set key1=val1,key2=val2 # Establece valores en la línea de comandos (puede especificar varios o separarlos con comas). helm install --values # Instala la chart con los valores especificados. helm install --dry-run --debug # Ejecuta una instalación de prueba para validar la chart (p). helm install --verify # Verifica el paquete antes de usarlo. helm install --dependency-update # Actualiza dependencias si faltan antes de instalar la chart. helm uninstall # Desinstala una release del namespace actual (por defecto). helm uninstall --namespace # Desinstala una release del namespace especificado. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Actualizar y revertir la aplicación (Rollback) ```bash helm upgrade # Actualiza una release. helm upgrade --rollback-on-failure # Si se establece, el proceso de actualización revierte los cambios en caso de fallo. helm upgrade --dependency-update # Actualiza las dependencias si faltan antes de instalar la chart. helm upgrade --version # Especifica una restricción de versión para la chart a usar. helm upgrade --values # Especifica valores en un archivo YAML o una URL (puede especificar múltiples). helm upgrade --set key1=val1,key2=val2 # Establece valores en la línea de comandos (puede especificar múltiples o separados). helm upgrade --force # Fuerza la actualización de recursos mediante una estrategia de reemplazo. helm rollback # Revierte una release a una revisión específica. helm rollback --cleanup-on-fail # Permite eliminar nuevos recursos creados en este rollback si el rollback falla. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Listar, añadir, eliminar y actualizar repositorios ```bash helm repo add # Añade un repositorio desde internet. helm repo list # Lista los repositorios de charts añadidos. helm repo update # Actualiza la información local de charts disponibles desde los repositorios. helm repo remove # Elimina uno o más repositorios de charts. helm repo index # Lee el directorio actual y genera un archivo de índice basado en las charts encontradas. helm repo index --merge # Fusiona el índice generado con un archivo de índice existente. helm search repo # Busca una palabra clave en los charts de los repositorios. helm search hub # Busca charts en Artifact Hub o en su propia instancia de hub. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Monitorización de Helm Release ```bash helm list # Lista todas las releases del namespace especificado; usa el namespace actual si no se especifica. helm list --all # Muestra todas las releases sin aplicar ningún filtro, puede usar -a. helm list --all-namespaces # Lista releases en todos los namespaces, puede usar -A. helm list -l key1=value1,key2=value2 # Selector (label query) para filtrar, soporta '=', '==', y '!='. helm list --date # Ordena por fecha de release. helm list --deployed # Muestra las releases desplegadas. Si no se especifica otra opción, se activa automáticamente. helm list --pending # Muestra las releases pendientes. helm list --failed # Muestra las releases fallidas. helm list --uninstalled # Muestra las releases desinstaladas (si se usó 'helm uninstall --keep-history'). helm list --superseded # Muestra las releases sustituidas. helm list -o yaml # Imprime la salida en el formato especificado. Valores permitidos: table, json, yaml (por defecto table). helm status # Muestra el estado de una release con nombre. helm status --revision # Si se establece, muestra el estado de la release nombrada con la revisión. helm history # Historial de revisiones para una release dada. helm env # Imprime toda la información de entorno usada por Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Descargar información de Release ```bash helm get all # Una colección legible de información sobre las notas, hooks, valores suministrados y archivo de manifiesto generado de la release dada. helm get hooks # Descarga los hooks para una release dada. Los hooks están formateados en YAML y separados por el separador YAML '---\n'. helm get manifest # Un manifiesto es una representación codificada en YAML de los recursos de Kubernetes generados a partir de la(s) chart(s) de esta release. Si una chart depende de otras charts, esos recursos también se incluirán en el manifiesto. helm get notes # Muestra las notas proporcionadas por la chart de una release con nombre. helm get values # Descarga un archivo de valores para una release dada. Use -o para formatear la salida. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Gestión de plugins ```bash helm plugin install # Instala plugins. helm plugin list # Muestra una lista de todos los plugins instalados. helm plugin update # Actualiza plugins. helm plugin uninstall # Desinstala un plugin. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: "Introducción" sidebar_position: 1 --- # Introducción a Helm ¿Eres nuevo en Helm? ¡Este es el lugar para comenzar! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Instalar Helm description: Aprenda a instalar y poner Helm en funcionamiento. sidebar_position: 2 --- Esta guía muestra cómo instalar Helm CLI. Helm se puede instalar desde la fuente o desde versiones binarias preconstruidas. ## Desde el Proyecto Helm El proyecto Helm proporciona dos formas de obtener e instalar Helm. Estos son los métodos oficiales para obtener lanzamientos de Helm. Además de eso, la comunidad de Helm proporciona métodos para instalar Helm a través de diferentes administradores de paquetes. La instalación a través de esos métodos se puede encontrar debajo de los métodos oficiales. ### De los Lanzamientos Binarios Cada [lanzamiento](https://github.com/helm/helm/releases) de Helm proporciona binarios de lanzamiento para una variedad de sistemas operativos. Estas versiones binarias se pueden descargar e instalar manualmente. 1. Descarga tu [versión deseada](https://github.com/helm/helm/releases) 2. Desempaquétala (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Encuentra el binario `helm` en el directorio desempaquetado, y muévelo a su destino deseado (`mv linux-amd64/helm /usr/local/bin/helm`) De ahí, debe poder ejecutar el cliente y [agregar el repositorio de charts estable](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Nota:** Las pruebas automatizadas de Helm se realizan para Linux AMD64 solo durante las compilaciones y lanzamientos de GitHub Actions. Las pruebas de otros sistemas operativos son responsabilidad de la comunidad que solicita Helm para el sistema operativo en cuestión. ### Desde Script Helm ahora tiene un script de instalación que automáticamente tomará la última versión de Helm y [la instalará localmente](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Puede recuperar ese script y luego ejecutarlo localmente. Está bien documentado para que puedas leerlo y comprender lo que está haciendo antes de ejecutarlo. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Sí, puedes `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`si quieres vivir al límite. ## A Través de Administradores de Paquetes La comunidad de Helm ofrece la posibilidad de instalar Helm a través de administradores de paquetes del sistema operativo. Estos no son soportados por el proyecto Helm y no se consideran terceros de confianza. ### Desde Homebrew (macOS) Los miembros de la comunidad de Helm han contribuido con una fórmula de Helm a Homebrew. Esta fórmula generalmente está actualizada. ```console brew install helm ``` (Nota: también hay una fórmula para emacs-helm, que es un proyecto diferente). ### Desde Chocolatey (Windows) Los miembros de la comunidad Helm han contribuido con un [paquete Helm](https://chocolatey.org/packages/kubernetes-helm) construido para [Chocolatey](https://chocolatey.org/). Este paquete generalmente está actualizado. ```console choco install kubernetes-helm ``` ### Desde Scoop (Windows) Los miembros de la comunidad Helm han contribuido con un [paquete Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) construido para [Scoop](https://scoop.sh). Este paquete generalmente está actualizado. ```console scoop install helm ``` ### Desde Winget (Windows) Los miembros de la comunidad Helm han contribuido con un [paquete Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) construido para [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Este paquete generalmente está actualizado. ```console winget install Helm.Helm ``` ### Desde Apt (Debian/Ubuntu) Los miembros de la comunidad Helm han contribuido con un paquete Apt para Debian/Ubuntu. Este paquete generalmente está actualizado. Gracias a [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) por alojar el repositorio. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Desde dnf/yum (fedora) Desde Fedora 35, Helm está disponible en el repositorio oficial. Puede instalar Helm ejecutando: ```console sudo dnf install helm ``` ### Desde Snap La comunidad [Snapcrafters](https://github.com/snapcrafters) mantiene la versión Snap del [paquete Helm](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### Desde pkg (FreeBSD) Los miembros de la comunidad FreeBSD han contribuido con una compilación de [paquete Helm](https://www.freshports.org/sysutils/helm) a la [Colección de Ports de FreeBSD](https://man.freebsd.org/ports). Este paquete generalmente está actualizado. ```console pkg install helm ``` ### Builds de Desarrollo Además de los lanzamientos, puede descargar o instalar versiones de desarrollo de Helm. ### Desde Canary Builds Los "Canary" builds son versiones del software Helm que se crean a partir de lo último de la rama main. No son lanzamientos oficiales y pueden no ser estables. Sin embargo, ofrecen la oportunidad de probar las funciones de vanguardia. Los binarios Canary builds se guardan en [get.helm.sh](https://get.helm.sh). Aquí hay enlaces a las compilaciones comunes: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Windows Experimental AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Desde los Fuentes (Linux, macOS) Construir Helm desde los fuentes es un poco más complicado, pero es la mejor manera de hacerlo si desea probar la última versión (prelanzamiento) de Helm. Debe tener un entorno de trabajo de Go. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` Si es necesario, buscará las dependencias, las almacenará en caché y validará la configuración. Luego compilará `helm` y lo colocará en `bin/helm`. ## Conclusión En la mayoría de los casos, la instalación es tan simple como obtener un binario `helm` preconstruido. Este documento cubre casos adicionales para aquellos que desean hacer cosas más sofisticadas con Helm. Una vez que tenga el cliente de Helm instalado correctamente, puede continuar con el uso de Helm para administrar charts y [agregar el repositorio de charts estable](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Guía de inicio rápido description: Cómo instalar y comenzar con Helm, incluidas instrucciones para distribuciones, preguntas frecuentes y plugins. sidebar_position: 1 --- Esta guía explica cómo empezar a utilizar Helm rápidamente. ## Prerrequisitos Para usar Helm de forma exitosa y segura, necesita lo siguiente: 1. Un clúster de Kubernetes 2. Decidir qué configuraciones de seguridad aplicar a su instalación, si corresponde 3. Instalar y configurar Helm. ### Instalar Kubernetes o tener acceso a un clúster - Debe tener Kubernetes instalado. Para la última versión de Helm, recomendamos la última versión estable de Kubernetes, que en la mayoría de los casos es la segunda versión menor más reciente. - También debe tener una copia de `kubectl` configurada localmente. Consulte la [Política de Soporte de Versiones de Helm](https://helm.sh/docs/topics/version_skew/) para conocer la máxima diferencia de versiones soportada entre Helm y Kubernetes. ## Instalar Helm Descargue una versión binaria del cliente Helm. Puede usar herramientas como `homebrew`, o consultar [la página de releases oficiales](https://github.com/helm/helm/releases). Para más detalles u otras opciones, consulte [la guía de instalación](/intro/install.md). ## Inicializar un Repositorio de Charts de Helm {#initialize-a-helm-chart-repository} Una vez que tenga Helm listo, puede agregar un repositorio de charts. Consulte [Artifact Hub](https://artifacthub.io/packages/search?kind=0) para ver los repositorios de charts de Helm disponibles. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Una vez instalado, podrá listar los charts disponibles para instalar: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... y muchos más ``` ## Instalar un Chart de Ejemplo Para instalar un chart, puede ejecutar el comando `helm install`. Helm tiene varias formas de buscar e instalar un chart, pero la más fácil es utilizar los charts de `bitnami`. ```console $ helm repo update # Asegúrese de obtener la última lista de charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` En el ejemplo anterior, se desplegó el chart `bitnami/mysql` y el nombre de nuestro nuevo release es `mysql-1612624192`. Puede ver las características básicas de este chart de MySQL ejecutando `helm show chart bitnami/mysql`. O puede ejecutar `helm show all bitnami/mysql` para obtener toda la información sobre el chart. Siempre que instale un chart, se crea un nuevo release. Por lo tanto, un chart se puede instalar varias veces en el mismo clúster. Y cada uno se puede administrar y actualizar de forma independiente. El comando `helm install` es muy potente y tiene muchas capacidades. Para más información, consulte la [Guía de Uso de Helm](/intro/using_helm.md). ## Más Información sobre Releases Con Helm puede ver fácilmente lo que se ha desplegado: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` El comando `helm list` (o `helm ls`) le mostrará una lista de todos los releases desplegados. ## Desinstalar un Release Para desinstalar un release, utilice el comando `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Esto desinstalará `mysql-1612624192` de Kubernetes, eliminando todos los recursos asociados con el release, así como el historial del release. Si proporciona la bandera `--keep-history`, se conservará el historial del release. Podrá solicitar información sobre ese release: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Dado que Helm realiza un seguimiento de sus releases incluso después de haberlos desinstalado, puede auditar el historial de un clúster e incluso recuperar un release (con `helm rollback`). ## Leer el Texto de Ayuda Para más información sobre los comandos disponibles de Helm, utilice `helm help` o escriba un comando seguido de la bandera `-h`: ```console $ helm get -h ``` ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Uso de Helm description: Explica los conceptos básicos de Helm. sidebar_position: 3 --- Esta guía explica los conceptos básicos del uso de Helm para administrar paquetes en su clúster de Kubernetes. Asume que ya has [instalado](/intro/install.md) el cliente de Helm. Si simplemente está interesado en ejecutar algunos comandos rápidos, es posible que desee comenzar con la [Guía de inicio rápido](/intro/quickstart.md). Este capítulo cubre los detalles de los comandos de Helm y explica cómo usar Helm. ## Tres Grandes Conceptos Un *Chart* es un paquete de Helm. Contiene todas las definiciones de recursos necesarias para ejecutar una aplicación, herramienta o servicio dentro de un clúster de Kubernetes. Piense en él como el equivalente de Kubernetes de una fórmula Homebrew, un Apt de dpkg o un archivo Yum de RPM. Un *Repositorio* es el lugar donde se pueden recopilar y compartir Charts. Es como el [archivo CPAN](https://www.cpan.org) de Perl o la [Base de Datos de Paquetes de Fedora](https://src.fedoraproject.org/), pero para los paquetes de Kubernetes. Un *Release* es una instancia de un Chart que se ejecuta en un clúster de Kubernetes. A menudo, un Chart se puede instalar muchas veces en el mismo clúster. Y cada vez que se instala, se crea un nuevo _release_. Considere un Chart MySQL. Si desea que se ejecuten dos bases de datos en su clúster, puede instalar ese Chart dos veces. Cada uno tendrá su propio _release_, que a su vez tendrá su propio _nombre de release_. Con estos conceptos en mente, ahora podemos explicar Helm así: Helm instala _charts_ en Kubernetes, creando nuevos _release_ para cada instalacion. Y para encontrar nuevos charts, puedes buscar en los _repositorios_ de charts de Helm. ## 'helm search': Buscando Charts Helm viene con un poderoso comando de búsqueda. Se puede utilizar para buscar dos tipos diferentes de fuentes: - `helm search hub` buscar en [Artifact Hub](https://artifacthub.io), que enumera charts de Helm de docenas de repositorios diferentes. - `helm search repo` busca en los repositorios que ha agregado a su cliente de helm local (con `helm repo add`). Esta búsqueda se realiza a través de datos locales y no se necesita una conexión de red pública. Puede encontrar charts disponibles públicamente ejecutando `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` Lo anterior busca todos los charts de `wordpress` en Artifact Hub. Sin filtro, `helm search hub` muestra todos los charts disponibles. `helm search hub` muestra la URL de la ubicación en [artifacthub.io](https://artifacthub.io/) pero no la URL real del repositorio de Helm. `helm search hub --list-repo-url` muestra la URL real del repositorio de Helm, lo cual es útil cuando desea agregar un nuevo repositorio: `helm repo add [NAME] [URL]`. Usando `helm search repo`, puede encontrar los nombres de los charts en los repositorios que ya has agregado: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search utiliza un algoritmo de coincidencia de cadenas difusas, por lo que puede escribir partes de palabras o frases: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` El comando search es una buena forma de encontrar paquetes disponibles. Una vez que haya encontrado el paquete que desea instalar, puede usar `helm install` para instalarlo. ## 'helm install': Instalando un Package Para instalar un nuevo paquete, use el comando `helm install`. En su forma más simple, se necesitan dos argumentos: un nombre de release que elijas y el nombre del chart que deseas instalar. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Ahora el chart `wordpress` está instalado. Tenga en cuenta que la instalación de un chart crea un nuevo objeto _release_. El release anterior se llama `happy-panda`. (Si desea que Helm genere un nombre por usted, omita el nombre del release y use `--generate-name`). Durante la instalación, el cliente `helm` imprimirá información útil sobre qué recursos se crearon, cuál es el estado del release y también si hay pasos de configuración adicionales que puede o debe tomar. Helm instala los recursos en el siguiente orden: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm no espera hasta que todos los recursos se estén ejecutando antes de salir. Muchos charts requieren imágenes de Docker que tienen un tamaño superior a 600M y pueden tardar mucho en instalarse en el clúster. Para realizar un seguimiento del estado de un release o para volver a leer la información de configuración, puede utilizar `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Lo anterior muestra el estado actual de su release. ### Personalización del Charts antes de la instalación La instalación de la forma que tenemos aquí solo usará las opciones de configuración predeterminadas para este chart. Muchas veces, querrás personalizar el chart para usar tu configuración preferida. Para ver qué opciones se pueden configurar en un chart, use `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Luego, puedes sobreescribir cualquiera de estas configuraciones en un archivo con formato YAML y luego pasar ese archivo durante la instalación. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Lo anterior creará un usuario MariaDB predeterminado con el nombre `user0`, y otorgará a este usuario acceso a una base de datos `user0db` recién creada, pero aceptará el resto de los valores predeterminados para ese chart. Hay dos formas de pasar los datos de configuración durante la instalación: - `--values` (o `-f`): Especifique un archivo YAML con sobreescrituras. Esto se puede especificar varias veces y el archivo más a la derecha tendrá prioridad - `--set`: Especifique sobreescrituras en la línea de comando. Si se utilizan ambos, los valores pasados en `--set` se fusionan con los pasados en `--values` con mayor precedencia. Las sobreescrituras especificadas con `--set` se guardan en un Secret. Los valores que han sido pasados con `--set` se pueden ver para un release determinado con `helm get values `. Los valores que han sido pasados con `--set` se pueden borrar ejecutando `helm upgrade` especificando `--reset-values`. #### El Formato y Limitaciones de `--set` La opción `--set` toma cero o más pares de nombre/valor. En su forma más simple, se usa así: `--set name=value`. El equivalente YAML de eso es: ```yaml name: value ``` Múltiples valores son separados por el caracteres `,`. Entonces, `--set a=b,c=d` se convierte en: ```yaml a: b c: d ``` Expresiones más complejas son soportadas. Por ejemplo, `--set outer.inner=value` es traducida a esto: ```yaml outer: inner: value ``` Las listas se pueden expresar encerrando valores en `{` y `}`. Por ejemplo, `--set name={a, b, c}` se traduce a: ```yaml name: - a - b - c ``` Ciertos nombres/claves se pueden establecer como `null` o como un array vacío `[]`. Por ejemplo, `--set name=[],a=null` traduce ```yaml name: - a - b - c a: b ``` a ```yaml name: [] a: null ``` A partir de Helm 2.5.0, es posible acceder a los elementos de la lista utilizando una sintaxis de índice de arreglo. Por ejemplo, `--set servers[0].port=80` se convierte en: ```yaml servers: - port: 80 ``` De esta forma se pueden configurar varios valores. La línea `--set servers[0].port=80,servers[0].host=example` se vuelve: ```yaml servers: - port: 80 host: example ``` A veces es necesario utilizar caracteres especiales en sus líneas `--set`. Puede usar una barra invertida para escapar de los caracteres; `--set name=value1\,value2` se convertirá en: ```yaml name: "value1,value2" ``` De manera similar, también puede escapar de las secuencias de puntos, lo que puede resultar útil cuando los charts usan la función `toYaml` para analizar anotaciones, etiquetas y selectores de nodos. La sintaxis para `--set nodeSelector."kubernetes\.io/role"=master` se convertirá en: ```yaml nodeSelector: kubernetes.io/role: master ``` Las estructuras de datos profundamente anidadas pueden ser difíciles de expresar usando `--set`. Se alienta a los diseñadores de charts a considerar el uso de `--set` al diseñar el formato de un archivo `values.yaml` (lea más sobre [Archivos Values](/chart_template_guide/values_files.md)). ### Más Métodos de Instalación El comando `helm install` puede instalar desde varias fuentes: - Un repositorio de charts (como hemos visto anteriormente) - Un archivo de chart local (`helm install foo foo-0.1.1.tgz`) - Un directorio de chart descomprimido (`helm install foo path/to/foo`) - Una URL completa (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' y 'helm rollback': Actualizar un Release y Revertir un Fallo Cuando se lanza una nueva versión de un chart, o cuando desea cambiar la configuración de su release, puede usar el comando `helm upgrade`. Una actualización toma un release existente y lo actualiza de acuerdo con la información que proporcione. Dado que los charts de Kubernetes pueden ser grandes y complejos, Helm intenta realizar la actualización menos invasiva. Solo actualizará las cosas que hayan cambiado desde el último release. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` En el caso anterior, la versión `happy-panda` se actualiza con el mismo chart, pero con un nuevo archivo YAML: ```yaml mariadb.auth.username: user1 ``` Podemos usar `helm get values` para ver si esa nueva configuración entró en vigencia. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` El comando `helm get` es una herramienta útil para ver un release en el clúster. Y como podemos ver arriba, muestra que nuestros nuevos valores de `panda.yaml` se desplegaron en el clúster. Ahora, si algo no sale según lo planeado durante un release, es fácil retroceder a un release anterior usando `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` Lo anterior hace retroceder a nuestro release happy-panda a su primera versión de release. La versión de release es una revisión incremental. Cada vez que ocurre una instalación, actualización o reversión, el número de revisión se incrementa en 1. El primer número de revisión es siempre 1. Y podemos usar `helm history [RELEASE]` para ver los números de revisión de un determinado release. ## Opciones Útiles para Instalar/Actualizar/Revertir Hay varias otras opciones útiles que puede especificar para personalizar el comportamiento de Helm durante una instalación/actualización/reversión. Tenga en cuenta que esta no es una lista completa de banderas del cliente. Para ver una descripción de todos las banderas, simplemente ejecute `helm --help`. - `--timeout`: Un valor de [duración de Go](https://golang.org/pkg/time/#ParseDuration) para esperar a que se completen los comandos de Kubernetes. El valor por defecto es `5m0s`. - `--wait`: Espera hasta que todos los pods estén listos, los PVC están vinculados, los Depolyments tengan el mínimo (`Desired` menos `maxUnavailable`) Pods en estado listo y los Services tengan una dirección IP (e Ingress si es un `LoadBalancer`) antes de marcar el release como exitoso. Esperará tanto tiempo como el valor `--timeout`. Si se alcanza el tiempo de espera, el release se marcará como `FAILED` (Fallida). Nota: En escenarios donde el Deployment tiene `replicas` configuradas en 1 y `maxUnavailable` no está configurado en 0 como parte de la estrategia de actualización continua, `--wait` regresará tan pronto como haya satisfecho la condición de mínimo de Pods listos. - `--no-hooks`: Esto omite la ejecución de ganchos para el comando - `--recreate-pods` (sólo disponible para `upgrade` y `rollback`): Esta bandera hará que se vuelvan a crear todos los Pods (con la excepción de los Pods que pertenecen a Deployments). (DEPRECADO en Helm 3) ## 'helm uninstall': Desinstalar un Release Cuando sea el momento de desinstalar un release del clúster, use el comando `helm uninstall`: ```console $ helm uninstall happy-panda ``` Esto eliminará el release del clúster. Puedes ver todas tus releases implementados actualmente con el comando `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` En el resultado anterior, podemos ver que se desinstaló el release `happy-panda`. En versiones anteriores de Helm, cuando se eliminaba un release, quedaba un registro de su eliminación. En Helm 3, la eliminación también elimina el registro del release. Si desea mantener un registro de eliminación del release, use `helm uninstall --keep-history`. El uso de `helm list --uninstalled` solo mostrará los releases que se desinstalaron con la bandera `--keep-history`. La bandera `helm list --all` le mostrará todos los registros de releases que Helm ha retenido, incluidos los registros de elementos fallidos o eliminados (si se especificó `--keep-history`): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Tenga en cuenta que debido a que los releases ahora se eliminan de forma predeterminada, ya no es posible revertir un recurso desinstalado. ## 'helm repo': Trabajar con Repositorios Helm 3 ya no viene con un repositorio de charts predeterminado. El grupo de comandos `helm repo` proporciona comandos para agregar, enumerar y eliminar repositorios. Puede ver qué repositorios están configurados usando `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Y se pueden agregar nuevos repositorios con `helm repo add`: ```console $ helm repo add dev https://example.com/dev-charts ``` Debido a que los repositorios de charts cambian con frecuencia, en cualquier momento puede asegurarse de que su cliente Helm esté actualizado ejecutando `helm repo update`. Los repositorios se pueden eliminar con `helm repo remove`. ## Creación de sus Propios Charts La [Guía de Desarrollo de Chart](/topics/charts.md) explica cómo desarrollar sus propios charts. Pero puede comenzar rápidamente usando el comando `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Ahora hay un chart en `./deis-workflow`. Puede editarlo y crear sus propias plantillas. A medida que editas tu chart, puede validar que está bien formado ejecutando `helm lint`. Cuando llegue el momento de empaquetar el chart para su distribución, puedes ejecutar el comando `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` Y este chart ahora se puede instalar fácilmente con `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Los Charts empaquetados se pueden cargar en repositorios de charts. Consulte la documentación de los [Repositorios de Charts de Helm](/topics/chart_repository.md) para obtener más detalles. ## Conclusión Este capítulo ha cubierto los patrones de uso básicos del cliente `helm`, incluida la búsqueda, instalación, actualización y desinstalación. También ha cubierto comandos útiles de utilidad como `helm status`, `helm get` y `helm repo`. Para obtener más información sobre estos comandos, consulte la ayuda incorporada de Helm: `helm help`. En el [capítulo siguiente](/howto/charts_tips_and_tricks.md), analizamos el proceso de desarrollo de charts. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Introducción description: Presenta el SDK de Go para Helm sidebar_position: 1 --- El SDK de Go de Helm permite que software personalizado aproveche los charts de Helm y la funcionalidad de Helm para gestionar el despliegue de software en Kubernetes. ¡De hecho, la CLI de Helm es efectivamente una herramienta de este tipo! Actualmente, el SDK ha sido funcionalmente separado de la CLI de Helm. Y el SDK puede ser (y es) utilizado por herramientas independientes. El proyecto Helm se ha comprometido con la estabilidad de la API del SDK. Como advertencia, el SDK aún tiene algunas asperezas pendientes del trabajo inicial para separar la CLI y el SDK, que el proyecto Helm tiene como objetivo mejorar con el tiempo. La documentación completa de la API se puede encontrar en [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). A continuación se presenta una breve descripción de algunos de los principales tipos de paquetes y un ejemplo sencillo. Consulte la sección de [Ejemplos](/sdk/examples.mdx) para más ejemplos y un 'driver' (controlador) más completo. ## Descripción general de los paquetes principales - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Contiene el "cliente" principal para realizar acciones de Helm. Este es el mismo paquete que la CLI utiliza internamente. Si solo necesita ejecutar comandos básicos de Helm desde otro programa Go, este es el paquete indicado - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Métodos y helpers utilizados para cargar y manipular charts - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) y sus subpaquetes: Contiene todos los handlers para las variables de entorno estándar de Helm y sus subpaquetes contienen el manejo de salida y archivos de valores - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Define el objeto `Release` y sus estados ¡Hay muchos más paquetes además de estos, así que consulte la documentación para más información! ### Ejemplo sencillo Este es un ejemplo sencillo de cómo hacer un `helm list` usando el SDK de Go. Consulte la sección de [Ejemplos](/sdk/examples.mdx) para ejemplos más completos. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Compatibilidad El SDK de Helm sigue explícitamente las garantías de compatibilidad hacia atrás de Helm: Es decir, los cambios que rompen la compatibilidad solo se realizarán en versiones mayores. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Técnicas avanzadas de Helm description: Explica varias características avanzadas para usuarios avanzados de Helm sidebar_position: 9 --- Esta sección explica varias características avanzadas y técnicas para usar Helm. La información de esta sección está pensada para "usuarios avanzados" de Helm que desean personalización avanzada y manipulación de sus charts y releases. Cada una de estas funciones avanzadas tiene sus propias desventajas y advertencias, por lo que cada una debe usarse con cuidado y con un conocimiento profundo de Helm. O en otras palabras, recuerde el [principio de Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Post Renderizado El post renderizado da a los instaladores de charts la capacidad de manipular manualmente, configurar y/o validar manifiestos renderizados antes de que sean instalados por Helm. Esto permite a los usuarios con necesidades de configuración avanzada usar herramientas como [`kustomize`](https://kustomize.io) para aplicar cambios de configuración sin necesidad de un fork a un chart público o requerir que los mantenedores de charts especifiquen hasta la última opción de configuración de un software. También hay casos de uso para inyectar herramientas comunes y sidecars en entornos empresariales o análisis de los manifiestos antes del despliegue. ### Prerrequisitos - Helm 3.1+ ### Uso Un post-renderizador puede ser cualquier ejecutable que acepte manifiestos Kubernetes renderizados en STDIN y devuelva manifiestos Kubernetes válidos en STDOUT. Debe devolver un código de salida distinto de 0 en caso de fallo. Esta es la única "API" entre los dos componentes. Permite una gran flexibilidad en lo que puede hacer con su proceso de post renderizado. Un post renderizador puede ser usado con `install`, `upgrade`, y `template`. Para utilizar un post renderizador, utilice la flag `--post-renderer` con una ruta al ejecutable del renderizador que desea utilizar: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Si la ruta no contiene ningún separador, buscará en $PATH, de lo contrario resolverá cualquier ruta relativa a una ruta absoluta. Si desea utilizar varios post-renderizadores, llámelos a todos desde un script o juntos en cualquier herramienta binaria que haya creado. En bash, sería tan simple como `renderer1 | renderer2 | renderer3`. Puede ver un ejemplo de uso de `kustomize` como post renderer [aquí](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Advertencias Cuando se usan post renderers, hay varias cosas importantes a tener en cuenta. La más importante de ellas es que cuando se utiliza un post renderizador, todas las personas que modifican esa release **DEBEN** utilizar el mismo renderizador con el fin de tener construcciones repetibles. Esta característica está construida a propósito para permitir a cualquier usuario cambiar el renderizador utilizado o dejar de usarlo, pero esto debe hacerse deliberadamente para evitar la modificación accidental o pérdida de datos. Otra nota importante se refiere a la seguridad. Si está utilizando un post-renderizador, debe asegurarse de que proviene de una fuente fiable. El uso de renderizadores no fiables o no verificados NO es recomendable, ya que tienen acceso completo a las plantillas renderizadas, que a menudo contienen secretos. ### Post-renderizadores personalizados El paso de post renderizado ofrece aún más flexibilidad cuando se utiliza en el Go SDK. Cualquier post renderizador solo necesita implementar la siguiente interfaz Go: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Para más información sobre el uso del Go SDK, consulte la siguiente [sección Go SDK](#go-sdk). ## Go SDK Helm 3 debutó con un Go SDK completamente reestructurado para una mejor experiencia cuando se construye software y herramientas que aprovechan Helm. La documentación completa se puede encontrar en la [sección Go SDK](/sdk/gosdk.md), pero a continuación se ofrece una breve descripción de algunos de los paquetes más comunes y un ejemplo sencillo. ### Resumen de paquetes Esta es una lista de los paquetes más utilizados con una explicación sencilla sobre cada uno de ellos: - `pkg/action`: Contiene el "cliente" principal para realizar acciones de Helm. Este es el mismo paquete que usa el CLI. Si solo necesita ejecutar comandos básicos de Helm desde otro programa Go, este paquete es para usted. - `pkg/{chart,chartutil}`: Métodos y ayudantes usados para cargar y manipular charts. - `pkg/cli` y sus subpaquetes: Contiene todos los manejadores para las variables de entorno estándar de Helm y sus subpaquetes contienen el manejo de ficheros de salida y valores. - `pkg/release`: Define el objeto `Release` y sus estados. Obviamente hay muchos más paquetes además de estos, ¡así que revise la documentación para más información! ### Ejemplo simple Este es un ejemplo simple para hacer un `helm list` usando el Go SDK: ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Backends de almacenamiento {#storage-backends} Helm 3 cambió el almacenamiento por defecto de la información de la release a Secrets en el namespace de la release. Helm 2 por defecto almacena la información de la release como ConfigMaps en el namespace de la instancia de Tiller. Las subsecciones siguientes muestran cómo configurar diferentes backends. Esta configuración se basa en la variable de entorno `HELM_DRIVER`. Se puede establecer a uno de los valores: `[configmap, secret, sql]`. ### Backend de almacenamiento ConfigMap Para habilitar el backend ConfigMap, necesitará establecer la variable de entorno `HELM_DRIVER` a `configmap`. Puede establecerla en un shell de la siguiente manera: ```shell export HELM_DRIVER=configmap ``` Si desea cambiar del backend por defecto al backend ConfigMap, tendrá que hacer la migración por su cuenta. Puede recuperar la información de la release con el siguiente comando: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **NOTAS DE PRODUCCIÓN**: La información de release incluye el contenido de charts y archivos de valores y, por lo tanto, podría contener datos confidenciales (como contraseñas, claves privadas y otras credenciales) que deben protegerse del acceso no autorizado. Al gestionar la autorización de Kubernetes, por ejemplo con [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), es posible conceder un acceso más amplio a los recursos ConfigMap, al tiempo que se restringe el acceso a los recursos Secret. Por ejemplo, el rol predeterminado [user-facing role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" otorga acceso a la mayoría de los recursos, pero no a los Secrets. Además, los secretos pueden configurarse para [almacenamiento cifrado](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Tenga esto en cuenta si decide cambiar al backend ConfigMap, ya que podría exponer los datos sensibles de su aplicación. ### Backend de almacenamiento SQL Existe un backend de almacenamiento SQL ***beta*** que almacena la información de liberación en una base de datos SQL. El uso de este tipo de almacenamiento es especialmente útil si la información de publicación pesa más de 1 MB (en cuyo caso, no puede almacenarse en ConfigMaps/Secrets debido a los límites internos del almacenamiento de valores clave etcd subyacente de Kubernetes). Para habilitar el backend SQL, tendrá que desplegar una base de datos SQL y establecer la variable de entorno `HELM_DRIVER` en `sql`. Los detalles de la base de datos se establecen con la variable de entorno `HELM_DRIVER_SQL_CONNECTION_STRING`. Puede configurarlo en un shell de la siguiente manera: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Nota: En este momento solo se soporta PostgreSQL. **NOTAS DE PRODUCCIÓN**: Se recomienda: - Preparar la base de datos para la producción. Para PostgreSQL, consulte la documentación [Administración del servidor](https://www.postgresql.org/docs/12/admin.html) para más detalles - Habilitar [gestión de permisos](/topics/permissions_sql_storage_backend.md) para reflejar Kubernetes RBAC y obtener información sobre la versión Si desea cambiar del backend por defecto al backend SQL, tendrá que hacer la migración por su cuenta. Puede recuperar la información de lanzamiento con el siguiente comando: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Arquitectura Helm description: Describe la arquitectura de Helm a alto nivel. sidebar_position: 8 --- # Arquitectura de Helm Este documento describe la arquitectura de Helm a alto nivel. ## El propósito de Helm Helm es una herramienta para gestionar paquetes Kubernetes llamados _charts_. Helm puede hacer lo siguiente: - Crear nuevos charts desde cero - Empaquetar charts en archivos de charts (tgz) - Interactuar con repositorios de charts donde se almacenan charts - Instalar y desinstalar charts en un clúster Kubernetes existente - Gestionar el ciclo de lanzamiento de los charts instalados con Helm Para Helm, hay tres conceptos importantes: 1. El _chart_ es un conjunto de información necesaria para crear una instancia de una aplicación de Kubernetes. 2. El _config_ contiene información de configuración que puede fusionarse en un chart empaquetado para crear un objeto desplegable. 3. Un _release_ es una instancia en ejecución de un _chart_, combinado con un _config_ específico. ## Componentes Helm es un ejecutable que se implementa en dos partes distintas: **El cliente Helm** es un cliente de línea de comandos para usuarios finales. El cliente es responsable de lo siguiente: - Desarrollo de charts locales - Gestión de repositorios - Gestión de releases - Interfaz con la biblioteca Helm - Envío de charts para su instalación - Solicitud de actualización o desinstalación de releases existentes **La biblioteca Helm** proporciona la lógica para ejecutar todas las operaciones de Helm. Interactúa con el servidor API de Kubernetes y proporciona la siguiente capacidad: - Combinar un chart y una configuración para construir un release - Instalar charts en Kubernetes y proporcionar el objeto release subsiguiente - Actualizar y desinstalar charts interactuando con Kubernetes La biblioteca standalone de Helm encapsula la lógica de Helm para que pueda ser aprovechada por diferentes clientes. ## Implementación El cliente y la biblioteca Helm están escritos en el lenguaje de programación Go. La biblioteca utiliza la biblioteca cliente de Kubernetes para comunicarse con Kubernetes. Actualmente, esa biblioteca utiliza REST+JSON. Almacena información en Secrets ubicados dentro de Kubernetes. No necesita su propia base de datos. Los archivos de configuración se escriben, cuando es posible, en YAML. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Guía del Repositorio de Charts description: Cómo crear y trabajar con repositorios de charts de Helm. sidebar_position: 6 --- Esta sección explica cómo crear y trabajar con repositorios de charts de Helm. En términos generales, un repositorio de charts es un lugar donde se pueden almacenar y compartir charts empaquetados. El repositorio comunitario distribuido de charts de Helm está ubicado en [Artifact Hub](https://artifacthub.io/packages/search?kind=0) y acepta participación. Pero Helm también permite crear y ejecutar su propio repositorio de charts. Esta guía explica cómo hacerlo. Si está considerando crear un repositorio de charts, puede considerar usar un [registro OCI](/topics/registries.md) en su lugar. ## Prerrequisitos * Completar la guía de [Inicio Rápido](/intro/quickstart.md) * Leer el documento de [Charts](/topics/charts.md) ## Crear un repositorio de charts Un _repositorio de charts_ es un servidor HTTP que aloja un archivo `index.yaml` y opcionalmente algunos charts empaquetados. Cuando esté listo para compartir sus charts, la forma preferida es subirlos a un repositorio de charts. A partir de Helm 2.2.0, se admite la autenticación SSL del lado del cliente para un repositorio. Otros protocolos de autenticación pueden estar disponibles como plugins. Debido a que un repositorio de charts puede ser cualquier servidor HTTP que pueda servir archivos YAML y tar y pueda responder a solicitudes GET, dispone de muchas opciones para alojar su propio repositorio de charts. Por ejemplo, puede usar un bucket de Google Cloud Storage (GCS), un bucket de Amazon S3, GitHub Pages, o incluso crear su propio servidor web. ### La estructura del repositorio de charts Un repositorio de charts consiste en charts empaquetados y un archivo especial llamado `index.yaml` que contiene un índice de todos los charts en el repositorio. Frecuentemente, los charts que `index.yaml` describe también están alojados en el mismo servidor, al igual que los [archivos de procedencia](/topics/provenance.md). Por ejemplo, el diseño del repositorio `https://example.com/charts` podría verse así: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` En este caso, el archivo de índice contendría información sobre un chart, el chart Alpine, y proporcionaría la URL de descarga `https://example.com/charts/alpine-0.1.2.tgz` para ese chart. No es necesario que un paquete de chart esté ubicado en el mismo servidor que el archivo `index.yaml`. Sin embargo, hacerlo suele ser lo más fácil. ### El archivo de índice El archivo de índice es un archivo yaml llamado `index.yaml`. Contiene algunos metadatos sobre el paquete, incluyendo el contenido del archivo `Chart.yaml` de un chart. Un repositorio de charts válido debe tener un archivo de índice. El archivo de índice contiene información sobre cada chart en el repositorio de charts. El comando `helm repo index` generará un archivo de índice basándose en un directorio local dado que contiene charts empaquetados. Este es un ejemplo de un archivo de índice: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Alojamiento de Repositorios de Charts Esta parte muestra varias formas de servir un repositorio de charts. ### Google Cloud Storage El primer paso es **crear su bucket de GCS**. Llamaremos al nuestro `fantastic-charts`. ![Crear un Bucket de GCS](/img/helm2/create-a-bucket.png) A continuación, haga público su bucket **editando los permisos del bucket**. ![Editar Permisos](/img/helm2/edit-permissions.png) Inserte esta línea para **hacer público su bucket**: ![Hacer Público el Bucket](/img/helm2/make-bucket-public.png) ¡Felicitaciones, ahora tiene un bucket de GCS vacío listo para servir charts! Puede subir su repositorio de charts usando la herramienta de línea de comandos de Google Cloud Storage, o usando la interfaz web de GCS. Un bucket público de GCS puede ser accedido vía HTTPS simple en esta dirección: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith También puede configurar repositorios de charts usando Cloudsmith. Lea más sobre repositorios de charts con Cloudsmith [aquí](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory De manera similar, también puede configurar repositorios de charts usando JFrog Artifactory. Lea más sobre repositorios de charts con JFrog Artifactory [aquí](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### Ejemplo de GitHub Pages De manera similar, puede crear un repositorio de charts usando GitHub Pages. GitHub le permite servir páginas web estáticas de dos formas diferentes: - Configurando un proyecto para servir el contenido de su directorio `docs/` - Configurando un proyecto para servir una rama específica Tomaremos el segundo enfoque, aunque el primero es igual de fácil. El primer paso será **crear su rama gh-pages**. Puede hacerlo localmente así: ```console $ git checkout -b gh-pages ``` O vía navegador web usando el botón **Branch** en su repositorio de GitHub: ![Crear rama de GitHub Pages](/img/helm2/create-a-gh-page-button.png) A continuación, querrá asegurarse de que su **rama gh-pages** esté configurada como GitHub Pages, haga clic en **Settings** de su repositorio y desplácese hacia abajo a la sección **GitHub pages** y configure como se muestra a continuación: ![Crear rama de GitHub Pages](/img/helm2/set-a-gh-page.png) Por defecto, **Source** generalmente se configura a **gh-pages branch**. Si esto no está configurado por defecto, selecciónelo. Puede usar un **dominio personalizado** si lo desea. Y verifique que **Enforce HTTPS** esté marcado, para que se use **HTTPS** cuando se sirvan los charts. Con esta configuración puede usar su rama principal para almacenar el código de sus charts, y la **rama gh-pages** como repositorio de charts, por ejemplo: `https://USERNAME.github.io/REPONAME`. El repositorio de demostración [TS Charts](https://github.com/technosophos/tscharts) está accesible en `https://technosophos.github.io/tscharts/`. Si ha decidido usar GitHub Pages para alojar el repositorio de charts, consulte [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action es un flujo de trabajo de GitHub Action para convertir un proyecto de GitHub en un repositorio de charts de Helm autoalojado, usando la herramienta CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Servidores web ordinarios Para configurar un servidor web ordinario para servir charts de Helm, simplemente necesita hacer lo siguiente: - Poner su índice y charts en un directorio que el servidor pueda servir - Asegurarse de que el archivo `index.yaml` sea accesible sin requisitos de autenticación - Asegurarse de que los archivos `yaml` se sirvan con el tipo de contenido correcto (`text/yaml` o `text/x-yaml`) Por ejemplo, si desea servir sus charts desde `$WEBROOT/charts`, asegúrese de que haya un directorio `charts/` en su raíz web, y coloque el archivo de índice y los charts dentro de esa carpeta. ### Servidor de Repositorio ChartMuseum ChartMuseum es un servidor de repositorio de charts de Helm de código abierto escrito en Go (Golang), con soporte para backends de almacenamiento en la nube, incluyendo [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), y [etcd](https://etcd.io/). También puede usar el servidor [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) para alojar un repositorio de charts desde un sistema de archivos local. ### Registro de Paquetes de GitLab Con GitLab puede publicar charts de Helm en el Registro de Paquetes de su proyecto. Lea más sobre cómo configurar un repositorio de paquetes helm con GitLab [aquí](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Gestión de Repositorios de Charts Ahora que tiene un repositorio de charts, la última parte de esta guía explica cómo mantener charts en ese repositorio. ### Almacenar charts en su repositorio de charts Ahora que tiene un repositorio de charts, subamos un chart y un archivo de índice al repositorio. Los charts en un repositorio de charts deben estar empaquetados (`helm package chart-name/`) y versionados correctamente (siguiendo las directrices de [SemVer 2](https://semver.org/)). Estos siguientes pasos componen un flujo de trabajo de ejemplo, pero puede usar cualquier flujo de trabajo que prefiera para almacenar y actualizar charts en su repositorio de charts. Una vez que tenga un chart empaquetado listo, cree un nuevo directorio y mueva su chart empaquetado a ese directorio. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` El último comando toma la ruta del directorio local que acaba de crear y la URL de su repositorio de charts remoto y compone un archivo `index.yaml` dentro de la ruta del directorio dado. Ahora puede subir el chart y el archivo de índice a su repositorio de charts usando una herramienta de sincronización o manualmente. Si está usando Google Cloud Storage, consulte este [flujo de trabajo de ejemplo](/howto/chart_repository_sync_example.md) usando el cliente gsutil. Para GitHub, simplemente puede poner los charts en la rama de destino apropiada. ### Agregar nuevos charts a un repositorio existente Cada vez que desee agregar un nuevo chart a su repositorio, debe regenerar el índice. El comando `helm repo index` reconstruirá completamente el archivo `index.yaml` desde cero, incluyendo solo los charts que encuentre localmente. Sin embargo, puede usar la bandera `--merge` para agregar incrementalmente nuevos charts a un archivo `index.yaml` existente (una gran opción cuando trabaja con un repositorio remoto como GCS). Ejecute `helm repo index --help` para obtener más información. Asegúrese de subir tanto el archivo `index.yaml` revisado como el chart. Y si generó un archivo de procedencia, súbalo también. ### Compartir sus charts con otros Cuando esté listo para compartir sus charts, simplemente comparta la URL de su repositorio. Desde allí, agregarán el repositorio a su cliente helm mediante el comando `helm repo add [NAME] [URL]` con cualquier nombre que deseen usar para referenciar el repositorio. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Si los charts están respaldados por autenticación básica HTTP, también puede proporcionar el nombre de usuario y la contraseña aquí: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Nota:** No se agregará un repositorio si no contiene un `index.yaml` válido. **Nota:** Si su repositorio de helm utiliza, por ejemplo, un certificado autofirmado, puede usar `helm repo add --insecure-skip-tls-verify ...` para omitir la verificación de CA. Después de eso, sus usuarios podrán buscar en sus charts. Después de que haya actualizado el repositorio, pueden usar el comando `helm repo update` para obtener la información más reciente de los charts. *Bajo el capó, los comandos `helm repo add` y `helm repo update` obtienen el archivo index.yaml y lo almacenan en el directorio `$XDG_CACHE_HOME/helm/repository/cache/`. Aquí es donde la función `helm search` encuentra información sobre los charts.* ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Pruebas de Chart description: Describe cómo ejecutar y probar sus charts. sidebar_position: 3 --- Un chart contiene varios recursos y componentes de Kubernetes que funcionan juntos. Como autor de charts, es posible que desee escribir algunas pruebas que validen que su chart funciona como se esperaba cuando se instala. Estas pruebas también ayudan al consumidor de charts a comprender lo que se supone que debe hacer su chart. Una **prueba** en un chart de Helm vive en el directorio `templates/` y es una definición de Job que especifica un contenedor con un comando dado para ejecutar. El contenedor debe salir correctamente (exit 0) para que una prueba se considere exitosa. La definición del Job debe contener la anotación del hook de prueba de Helm: `helm.sh/hook: test`. Tenga en cuenta que hasta Helm v3, la definición de trabajo debía contener una de estas anotaciones de hook de prueba de Helm: `helm.sh/hook: test-success` o `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` todavía se acepta como una alternativa compatible con versiones anteriores de `helm.sh/hook: test`. Ejemplos de pruebas: - Validar que su configuración del archivo values.yaml se haya inyectado correctamente. - Asegurarse de que su nombre de usuario y contraseña funcionen correctamente - Asegurarse de que un nombre de usuario y una contraseña incorrectos no funcionen - Verificar que sus servicios están activos y con el balanceo de carga correcto - etc. Puede ejecutar las pruebas predefinidas en Helm sobre un release usando el comando `helm test `. Para un consumidor de charts, esta es una excelente manera de verificar que su release de un chart (o aplicación) funcione como se esperaba. ## Ejemplo de Prueba El comando [helm create](/helm/helm_create.md) creará automáticamente varias carpetas y archivos. Para probar la funcionalidad de helm test, primero cree un chart de demostración. ```console $ helm create demo ``` Ahora podrá ver la siguiente estructura en su chart de demostración. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` En `demo/templates/tests/test-connection.yaml` encontrará una prueba que puede ejecutar. A continuación se muestra la definición del Pod de prueba de Helm: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Pasos para Ejecutar un Conjunto de Pruebas sobre un Release Primero, instale el chart en su clúster para crear un release. Puede que tenga que esperar a que todos los pods se activen; si prueba inmediatamente después de esta instalación, es probable que muestre una falla transitoria y querrá volver a probar. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Notas - Puede definir tantas pruebas como desee en un solo archivo yaml o distribuirlas en varios archivos yaml en el directorio `templates/`. - Le invitamos a anidar su suite de pruebas en un directorio `tests/` como `/templates/tests/` para mayor aislamiento. - Una prueba es un [hook de Helm](/topics/charts_hooks.md), por lo que anotaciones como `helm.sh/hook-weight` y `helm.sh/hook-delete-policy` pueden usarse con recursos de prueba. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: "Charts" description: "Explica el formato del chart y proporciona una guía básica para crear charts con Helm." sidebar_position: 1 --- Helm usa un formato de empaquetado llamado _charts_. Un chart es una colección de archivos que describen un conjunto relacionado de recursos de Kubernetes. Se puede usar un solo chart para implementar algo simple, como un pod de Memcached, o algo complejo, como una pila de aplicaciones web completa con servidores HTTP, bases de datos, cachés, etc. Los charts se crean como archivos dispuestos en un árbol de directorios en particular. Se pueden empaquetar en archivos versionados para ser desplegados. Si desea descargar y ver los archivos de un chart publicado, sin instalarlo, puede hacerlo con `helm pull chartrepo/chartname`. Este documento explica el formato del chart y proporciona una guía básica para crear charts con Helm. ## La Estructura de Archivos del Chart Un chart se organiza como una colección de archivos dentro de un directorio. El nombre del directorio es el nombre del chart (sin información de versiones). Por lo tanto, un chart que describa WordPress se almacenaría en un directorio `wordpress/`. Dentro de este directorio, Helm esperará una estructura que coincida con esto: ```text wordpress/ Chart.yaml # Un archivo YAML que contiene información sobre el chart. LICENSE # OPCIONAL: Un archivo de texto sin formato que contiene la licencia del chart. README.md # OPCIONAL: Un archivo README legible por humanos values.yaml # Los valores de configuración predeterminados para este chart values.schema.json # OPCIONAL: Un esquema JSON para imponer una estructura en el archivo values.yaml charts/ # Un directorio que contiene los charts de los que depende este chart. crds/ # Custom Resource Definitions templates/ # Un directorio de plantillas que, cuando se combinan con valores, # generarán archivos de manifiesto de Kubernetes válidos. templates/NOTES.txt # OPCIONAL: Un archivo de texto sin formato que contiene breves notas de uso. ``` Helm se reserva el uso de los directorios `charts/`, `crds/` y `templates/`, y de los nombres de archivo listados. Los demás archivos se dejarán como están. ## El Archivo Chart.yaml {#the-chartyaml-file} El archivo `Chart.yaml` es requerido para un chart. Contiene los siguientes campos: ```yaml apiVersion: La versión de la API de chart (requerido) name: El nombre del chart (requerido) version: An versión SemVer 2 (requerido) kubeVersion: Un rango SemVer de versiones compatibles de Kubernetes (opcional) description: Una descripción de una sola frase de este proyecto (opcional) type: El tipo de chart (opcional) keywords: - Una lista de palabras clave sobre este proyecto (opcional) home: La URL de la página de inicio de este proyecto (opcional) sources: - Una lista de URL al código fuente de este proyecto (opcional) dependencies: # Una lista de los requisitos del chart. (opcional) - name: El nombre del chart (nginx) version: La versión del chart ("1.2.3") repository: (opcional) La URL del repositorio ("https://example.com/charts") o el alias ("@repo-name") condition: (opcional) Una ruta yaml que se resuelve en un booleano, que se usa para habilitar/deshabilitar charts (e.g. subchart1.enabled) tags: # (opcional) - Las etiquetas se pueden usar para agrupar charts para habilitar/deshabilitar en for conjunta import-values: # (opcional) - ImportValues contiene la asignación de valores de origen a la clave principal que se va a importar. Cada elemento puede ser una cadena o un par de elementos hijo/padre de la sublista. alias: (opcional) Alias que se utilizará para el chart. Útil cuando tiene que agregar el mismo chart varias veces maintainers: # (opcional) - name: El nombre de los mantenedores (requerido para cada mantenedor) email: El correo electrónico de los mantenedores (opcional para cada mantenedor) url: Una URL para el mantenedor (opcional para cada mantenedor) icon: Una URL a una imagen SVG o PNG que se utilizará como icono (opcional). appVersion: La versión de la aplicación que contiene. (opcional). No es necesario que sea SemVer. Se recomienda encerrar en comillas. deprecated: Si este chart está obsoleto (optional, boolean) annotations: example: Una lista de anotaciones codificadas por nombre (opcional). ``` A partir de [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), no se permiten campos adicionales. El enfoque recomendado es agregar metadatos personalizados en `annotations`. ### Charts y Versionado Cada chart debe tener un número de versión. Una versión debe seguir el estándar [SemVer 2](https://semver.org/spec/v2.0.0.html). A diferencia de Helm Classic, Helm v2 y versiones posteriores utilizan números de versión como marcadores de versión. Los paquetes en repositorios son identificado por el nombre más la versión. Por ejemplo, un chart `nginx` cuyo campo de versión se establece en `versión: 1.2.3` se denominará: ```text nginx-1.2.3.tgz ``` También se admiten nombres SemVer 2 más complejos, como `versión: 1.2.3-alpha.1+ef365`. Pero el sistema rechaza explícitamente los nombres que no son SemVer. Se exceptúan las versiones en formato `x` o `x.y`. Por ejemplo, si hay una v al principio o una versión sin las 3 partes (por ejemplo, v1.2), se intentará convertirla en una versión semántica válida (por ejemplo, v1.2.0). **NOTA:** Mientras que Helm Classic y Deployment Manager estaban muy orientados a GitHub cuando se trataba de charts, Helm v2 y versiones posteriores no dependen ni requieren GitHub o incluso Git. En consecuencia, no utiliza Git SHA para el control de versiones. El campo `version` dentro de `Chart.yaml` es utilizado por muchas de las herramientas de Helm, incluida el CLI. Al generar un paquete, el comando `helm package` usará la versión que encuentre en el archivo `Chart.yaml` como un token en el nombre del paquete. El sistema asume que el número de versión en el nombre del paquete del chart coincide con el número de versión en `Chart.yaml`. El incumplimiento de esta suposición provocará un error. ### El Campo `apiVersion` El campo `apiVersion` debe ser `v2` para los charts de Helm que requieren al menos Helm 3. Los charts que admiten versiones anteriores de Helm tienen el campo `apiVersion` establecido en `v1` y aún se pueden instalar en Helm 3. Cambios de `v1` a `v2`: - Un campo `dependencies` que define las dependencias del chart, que se encontraba en el archivo `requirements.yaml` para los charts `v1` (consulte [Dependencias del chart](#dependencias-del-chart)). - El campo `type`, discriminando charts de aplicaciones y bibliotecas (consulte [Tipos de Charts](#tipos-de-chart)). ### El Campo `appVersion` Tenga en cuenta que el campo `appVersion` no está relacionado con el campo `version`. Es una forma de especificar la versión de la aplicación. Por ejemplo, el chart `drupal` puede tener una `appVersion: "8.2.1"`, lo que indica que la versión de Drupal incluida en el chart (por defecto) es `8.2.1`. Este campo es informativo y no tiene ningún impacto en los cálculos de la versión del chart. Se recomienda encarecidamente envolver la versión entre comillas. Esto obliga al analizador YAML a tratar el número de versión como una cadena. Dejarlo sin comillas puede provocar problemas de análisis en algunos casos. Por ejemplo, YAML interpreta `1.0` como un valor de punto flotante y un SHA de confirmación de git como `1234e10` como notación científica. A partir de Helm v3.5.0, `helm create` envuelve el campo predeterminado `appVersion` entre comillas. ### El Campo `kubeVersion` El campo opcional `kubeVersion` puede definir restricciones de SemVer en las versiones compatibles de Kubernetes. Helm validará las restricciones de versión al instalar el chart y fallará si el clúster ejecuta una versión de Kubernetes no compatible. Las restricciones de versión pueden comprender comparaciones AND separadas por espacios, como ```text >= 1.13.0 < 1.15.0 ``` que pueden combinarse con el operador OR `||` como en el siguiente ejemplo ```text >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` En este ejemplo, se excluye la versión `1.14.0`, lo que puede tener sentido si se sabe que un error en ciertas versiones impide que el chart se ejecute correctamente. Aparte de las restricciones de versión que emplean operadores `=` `! =` `>` `<` `> =` `<=`, se admiten las siguientes notaciones abreviadas * rangos de guiones para intervalos cerrados, donde `1.1 - 2.3.4` es equivalente a `>= 1.1 <= 2.3.4`. * comodines `x`, `X` y `*`, donde `1.2.x` es equivalente a `> = 1.2.0 <1.3.0`. * rangos de tilde (se permiten cambios en la versión del parche), donde `~1.2.3` es equivalente a `>= 1.2.3 < 1.3.0`. * intervalos de intercalación (se permiten cambios menores en la versión), donde `^1.2.3` es equivalente a `>= 1.2.3 < 2.0.0`. Para obtener una explicación detallada de las restricciones semver admitidas, consulte [Masterminds/semver](https://github.com/Masterminds/semver). ### Deprecando Charts Al administrar charts en un repositorio de charts, a veces es necesario deprecar un chart. El campo opcional `deprecated` en `Chart.yaml` se puede utilizar para marcar un chart como deprecado. Si la **última** versión de un chart en el repositorio está marcada como deprecado, entonces el chart en su conjunto se considera deprecado. El nombre del chart se puede reutilizar más tarde publicando una versión más reciente que no esté marcada como deprecado. El flujo de trabajo para charts obsoletos es: 1. Actualizar el archivo `Chart.yaml` del chart para marcar el chart como deprecado, subiendo la versión 2. Publicar la nueva versión del chart en el repositorio de charts. 3. Eliminar el chart del repositorio de origen (p. Ej., git) ### Tipos de Chart El campo `type` define el tipo de chart. Hay dos tipos: `application` (aplicación) y `library` (biblioteca). Aplicación es el tipo predeterminado y es el chart estándar con el que se puede operar completamente. El [chart de biblioteca](/topics/library_charts.md) proporciona utilidades o funciones para el generador de charts. Un chart de biblioteca se diferencia de un chart de aplicación porque no se puede instalar y, por lo general, no contiene ningún objeto de recurso. **Nota:** Se puede utilizar un chart de aplicación como chart de biblioteca. Esto se habilita estableciendo el tipo en `library`. Luego, el chart se renderizará como un chart de biblioteca en el que se pueden aprovechar todas las utilidades y funciones. Todos los objetos de recursos del chart no se renderizarán. ## Archivos LICENSE, README y NOTES del Chart Los Charts también pueden contener archivos que describen la instalación, configuración, uso y licencia de un chart. Un archivo LICENSE es un archivo de texto sin formato que contiene la [licencia](https://en.wikipedia.org/wiki/Software_license) para el chart. El chart puede contener una licencia, ya que puede tener lógica de programación en las plantillas y, por lo tanto, no sería solo configuración. También puede haber licencias separadas para la aplicación instalada por el chart, si es necesario. Un archivo README para un chart debe tener el formato Markdown (README.md) y generalmente debe contener: - Una descripción de la aplicación o servicio que proporciona el chart. - Cualquier requisito previo o requisito para ejecutar el chart. - Descripciones de opciones en `values.yaml` y valores predeterminados - Cualquier otra información que pueda ser relevante para la instalación o configuración del chart Cuando los concentradores y otras interfaces de usuario muestran detalles sobre un chart, ese detalle se extrae del contenido del archivo `README.md`. El chart también puede contener un archivo corto de texto sin formato `templates/NOTES.txt` que se imprimirá después de la instalación y al ver el estado de un release. Este archivo se evalúa como una [plantilla](#plantillas-y-valores) y se puede utilizar para mostrar notas de uso, próximos pasos o cualquier otra información relevante para una publicación del chart. Por ejemplo, se pueden proporcionar instrucciones para conectarse a una base de datos o acceder a una interfaz de usuario web. Dado que este archivo se imprime en STDOUT cuando se ejecuta `helm install` o `helm status`, se recomienda mantener breve el contenido y señalar el archivo README para obtener más detalles. ## Dependencias del Chart En Helm, un chart puede depender de cualquier número de otros charts. Estas dependencias se pueden vincular dinámicamente usando el campo `dependencies` en `Chart.yaml` o se pueden traer al directorio `charts/` y administrar manualmente. ### Administrar Dependencias con el Campo `dependencies` Los chart requeridos por el chart actual se definen como una lista en el campo `dependencias`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - El campo `name` es el nombre del chart que desea. - El campo `version` es la versión del chart que desea. - El campo `repository` es la URL completa del repositorio de charts. Tenga en cuenta que usted también debe usar `helm repo add` para agregar ese repositorio localmente. - Puede usar el nombre del repositorio en lugar de la URL ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Una vez que haya definido las dependencias, puede ejecutar `helm dependency update` y usará su archivo de dependencia para descargar todos los chart especificados en su directorio `charts/` por usted. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Cuando `helm dependency update` recupera charts, los almacenará como archivos de chart en el directorio `charts/`. Entonces, para el ejemplo anterior, uno esperaría ver los siguientes archivos en el directorio de charts: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### El Campo Alias en dependencies Además de los otros campos anteriores, cada entrada de requisitos puede contener el campo opcional `alias`. Agregar un alias para un chart de dependencia colocaría un chart en dependencias usando alias como nombre de la nueva dependencia. Se puede usar un `alias` en los casos en que necesiten acceder a un chart con otro nombre(s). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` En el ejemplo anterior obtendremos 3 dependencias en total para `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` La forma manual de lograr esto es copiando y pegando el mismo chart en el directorio `charts/` varias veces con diferentes nombres. #### Campos de Tags and Condition en dependencies Además de los otros campos anteriores, cada entrada de requisitos puede contener los campos opcionales `tags` y `condition`. Todos los charts se cargan de forma predeterminada. Si los campos `tags` o `condition` están presentes, se evaluarán y usarán para controlar la carga de los charts a los que se aplican. Condition: el campo condition contiene una o más rutas YAML (delimitadas por comas). Si esta ruta existe en los valores del padre superior y se resuelve en un valor booleano, el chart se habilitará o deshabilitará en función de ese valor booleano. Solo se evalúa la primera ruta válida que se encuentra en la lista y, si no existen rutas, la condición no tiene ningún efecto. Tags: el campo tag es una lista YAML de etiquetas para asociar con este chart. En los valores padres superiores, todos los charts con etiquetas se pueden habilitar o deshabilitar especificando la etiqueta y un valor booleano. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled, global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` En el ejemplo anterior, todos los chart con la etiqueta `front-end` estarían deshabilitados, pero dado que la ruta `subchart1.enabled` se evalúa como 'true' en los valores del padre, la condición anulará la etiqueta `front-end` y `subchart1` estará habilitado. Dado que `subchart2` está etiquetado con `back-end` y esa etiqueta se evalúa como `true`, se habilitará `subchart2`. También tenga en cuenta que aunque `subchart2` tiene una condición especificada, no hay una ruta y un valor correspondientes en los valores de los padres, por lo que la condición no tiene ningún efecto. ##### Utilizar el CLI con Etiquetas y Condiciones El parámetro `--set` se puede utilizar como de costumbre para alterar los valores de tags (etiquetas) y conditions (condiciones). ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Resolución de Etiquetas y Condiciones - **Las condiciones (cuando se establecen en values) siempre sobreescriben a las etiquetas.** La primera ruta de condición que existe gana y las siguientes para ese chart se ignoran. - Las etiquetas se evalúan como 'si alguna de las etiquetas del chart es verdadera, habilite el chart'. - Los valores de etiquetas y condiciones deben establecerse en los values del chart padre superior. - The `tags:` key in values must be a top level key. Globals and nested `tags:` tables are not currently supported. - La clave `tags:` en values debe ser una clave de nivel superior. Los `tags:` globales y anidados no son soportados actualmente. #### Importar values hijos via dependencias En algunos casos, es deseable permitir que los valores de un chart secundario se propaguen al chart principal y se compartan como valores predeterminados comunes. Un beneficio adicional de usar el formato de `exports` es que permitirá que las herramientas futuras introspecten los valores configurables por el usuario. Las claves que contienen los valores que se van a importar se pueden especificar en la sección `dependencies` del chart principal en el campo `import-values` mediante una lista YAML. Cada elemento de la lista es una clave que se importa del campo `exports` del chart secundario. Para importar valores que no están contenidos en la clave `exports`, use el formato [hijo-padre](#usando-el-formato-padre-hijo). A continuación se describen ejemplos de ambos formatos. ##### Usando el formato de exportación If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported directly into the parent's values by specifying the keys to import as in the example below: Si el archivo `values.yaml` de un chart secundario contiene un campo de `exports` en la raíz, su contenido se puede importar directamente a los values del padre especificando las claves para importar como en el siguiente ejemplo: ```yaml # archivo Chart.yaml del padre dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # archivo value.yaml del hijo exports: data: myint: 99 ``` Dado que estamos especificando la clave `data` en nuestra lista de importación, Helm busca en el campo `exports` del chart secundario la clave `data` e importa su contenido. El values final del padres contendrían nuestro campo exportado: ```yaml # values del padre myint: 99 ``` Tenga en cuenta que la clave principal `data` no está contenida en el values final del padre. Si necesita especificar la clave principal, utilice el formato 'hijo-padre'. ##### Usando el formato padre-hijo Para acceder a los valores que no están contenidos en la clave `exports` del values del chart hijo, deberá especificar la clave de origen del values que se importarán (`child`) y la ruta de destino en el values del chart padre (`parent`). The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them to the parent's values at the path specified in `parent:` Los `import-values` en el siguiente ejemplo le indican a Helm que tome los valores encontrados en la ruta `child:` y los copie a los valores del padre en la ruta especificada en `parent:` ```yaml # archivo Chart.yaml del padre dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` En el ejemplo anterior, los valores que se encuentran en `default.data` en los valores del subchart1 se importarán a la clave `myimports` en los values del chart padre como se detalla a continuación: ```yaml # archivo values.yaml del padre myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # archivo values.yaml subchart1 default: data: myint: 999 mybool: true ``` El values del chart padre resultantes sería: ```yaml # vales final del padre myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` El values final del padre ahora contienen los campos `myint` y `mybool` importados de subchart1. ### Administrar Dependencias manualmente a través del directorio `charts/` Si se desea más control sobre las dependencias, estas dependencias se pueden expresar explícitamente copiando los charts de dependencias en el directorio `charts/`. Una dependencia debe ser un directorio de chart desempaquetado, pero su nombre no puede comenzar con `_` o `.`. El cargador de charts ignora esos archivos. Por ejemplo, si el chart de WordPress depende del chart de Apache, el chart de Apache (de la versión correcta) se proporciona en el directorio `charts/` del chart de WordPress: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` El ejemplo anterior muestra cómo el chart de WordPress expresa su dependencia de Apache y MySQL al incluir esos charts dentro de su directorio `charts /`. **CONSEJO:** _Para colocar una dependencia en su directorio `charts/`, use el comando `helm pull`_ ### Aspectos operativos del uso de dependencias Las secciones anteriores explican cómo especificar las dependencias del chart, pero ¿cómo afecta esto a la instalación del chart usando `helm install` y `helm upgrade`? Supongamos que un chart llamado "A" crea los siguientes objetos de Kubernetes - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Además, A depende del chart B que crea los objetos - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Después de la instalación/actualización del chart A, se crea/modifica un único release de Helm. El release creará/actualizará todos los objetos de Kubernetes anteriores en el siguiente orden: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Esto se debe a que cuando Helm instala/actualiza charts, los objetos de Kubernetes de los charts y todas sus dependencias son - agregado en un solo conjunto; luego - ordenados por tipo seguido de nombre; y entonces - creado/actualizado en ese orden. Por lo tanto, se crea un único release con todos los objetos del charts y sus dependencias. El orden de instalación de los tipos de Kubernetes viene dado por la enumeración InstallOrder en kind_sorter.go (ver [el archivo fuente de Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Plantillas y Valores Las plantillas de Charts de Helm están escritas en el [lenguaje Go template](https://golang.org/pkg/text/template/), con la adición de unas 50 funciones de plantilla complementarias [de la biblioteca Sprig](https://github.com/Masterminds/sprig) y algunas otras [funciones especializadas](/howto/charts_tips_and_tricks.md). Todos los archivos de plantilla se almacenan en la carpeta `templates/` de un chart. Cuando Helm renderiza los charts, pasará todos los archivos de ese directorio a través del motor de plantillas. Los valores de las plantillas se proporcionan de dos formas: - Los desarrolladores de charts pueden proporcionar un archivo llamado `values.yaml` dentro de un chart. Este archivo puede contener valores predeterminados. - Los usuarios de charts pueden proporcionar un archivo YAML que contenga valores. Esto se puede proporcionar en la línea de comandos con `helm install`. Cuando un usuario proporciona valores personalizados, estos valores sobreescribirán los valores del archivo `values.yaml` del chart. ### Archivos de Plantillas Los archivos de plantilla siguen las convenciones estándar para escribir plantillas de Go (consulte [la documentación del paquete de text/template de Go](https://golang.org/pkg/text/template/) para obtener más detalles). Un archivo de plantilla de ejemplo podría verse así: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` El ejemplo anterior, basado ligeramente en [https://github.com/deis/charts](https://github.com/deis/charts), es una plantilla para un controlador de replicación de Kubernetes. Puede utilizar los siguientes cuatro valores de plantilla (normalmente definidos en un archivo `values.yaml`): - `imageRegistry`: El registro de origen de la imagen de Docker. - `dockerTag`: La etiqueta para image de Docker. - `pullPolicy`: La política de pull de The Kubernetes. - `storage`: El backend de almacenamiento, cuyo valor predeterminado es `"minio"` Todos estos valores los define el autor de la plantilla. Helm no requiere ni dicta parámetros. Para ver muchos charts operativos, consulte [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF. ### Valores Predefinidos Los valores que se proporcionan a través de un archivo `values.yaml` (o mediante la bandera `--set`) son accesibles desde el objeto `.Values` en una plantilla. Pero hay otros datos predefinidos a los que puede acceder en tus plantillas. Los siguientes valores están predefinidos, están disponibles para todas las plantillas y no se pueden sobreescribir. Como ocurre con todos los valores, los nombres son _sensibles a mayúsculas y minúsculas_. - `Release.Name`: El nombre del release (no del chart) - `Release.Namespace`: El namespace donde el chart fue deplegado. - `Release.Service`: El servicio que realizó el lanzamiento. - `Release.IsUpgrade`: Se establece en true (verdadero) si la operación actual es una actualización o una reversión. - `Release.IsInstall`: Se establece en true (verdadero) si la operación actual es una instalación. - `Chart`: El contenido de `Chart.yaml`. Por lo tanto, la versión del chart se puede obtener como `Chart.Version` y los mantenedores están en `Chart.Maintainers`. - `Files`: Un objeto similar a un mapa que contiene todos los archivos no especiales del chart. Esto no le dará acceso a las plantillas, pero le dará acceso a archivos adicionales que están presentes (a menos que estén excluidos usando `.helmignore`). Se puede acceder al archivo usando `{{ index .Files "file.name" }}` o usando la función `{{ .Files.Get name }}`. También puede acceder al contenido del archivo como `[]byte` usando `{{ .Files.GetBytes }}` - `Capabilities`: Un objeto similar a un mapa que contiene información sobre las versiones de Kubernetes (`{{ .Capabilities.KubeVersion }}`) y las versiones compatibles de la API de Kubernetes (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **NOTA:** Se eliminarán todos los campos desconocidos de `Chart.yaml`. No serán accesibles dentro del objeto `Chart`. Por lo tanto, `Chart.yaml` no se puede usar para pasar datos estructurados arbitrariamente a la plantilla. Sin embargo, el archivo de values se puede usar para eso. ### Archivos values Teniendo en cuenta la plantilla de la sección anterior, un archivo `values.yaml` que proporciona los valores necesarios se vería así: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Un archivo values tiene el formato YAML. Un chart puede incluir un archivo `values.yaml` predeterminado. El comando de instalación de Helm permite al usuario sobreescribir valores al proporcionar valores YAML adicionales: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Cuando los valores se pasan de esta manera, se fusionarán en el archivo de values predeterminado. Por ejemplo, considere un archivo `myvals.yaml` que se ve así: ```yaml storage: "gcs" ``` Cuando se fusiona con `values.yaml` del chart, el contenido generado resultante será: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Tenga en cuenta que solo se sobreescribó el último campo. **NOTA:** El archivo de valores predeterminados incluido dentro de un chart _debe_ llamarse `values.yaml`. Pero los archivos especificados en la línea de comandos pueden tener cualquier nombre. **NOTA:** Si la marca `--set` se usa en `helm install` o `helm upgrade`, esos valores simplemente se convierten a YAML en el lado del cliente. **NOTA:** Si existen entradas obligatorias en el archivo values, se pueden declarar según sea necesario en la plantilla del chart mediante la [función 'required'](/howto/charts_tips_and_tricks.md) Cualquiera de estos valores es accesible dentro de las plantillas usando el objeto `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Alcance, Dependencias y Valores Los archivos de valores pueden declarar valores para el chart de nivel superior, así como para cualquiera de los charts que se incluyen en el directorio `charts/` de ese chart. O, para expresarlo de otra manera, un archivo de valores puede proporcionar valores al chart, así como a cualquiera de sus dependencias. Por ejemplo, el chart de demostración de WordPress anterior tiene tanto `mysql` como `apache` como dependencias. El archivo de valores podría proporcionar valores a todos estos componentes: ```yaml title: "My WordPress Site" # Enviado a la plantilla de WordPress mysql: max_connections: 100 # Enviado a MySQL password: "secret" apache: port: 8080 # Enviado a Apache ``` Los charts de un nivel superior tienen acceso a todas las variables definidas a nivel inferior. Entonces, el chart de WordPress puede acceder a la contraseña de MySQL como `.Values.mysql.password`. Pero los charts de nivel inferior no pueden acceder a elementos de los charts padres, por lo que MySQL no podrá acceder a la propiedad `title`. Tampoco, en ese caso, puede acceder a `apache.port`. Los valores son dependientes del espacio de nombres, pero los espacios de nombres se podan. Entonces, para el chart de WordPress, puede acceder al campo de contraseña de MySQL como `.Values.mysql.password`. Pero para el chart MySQL, el alcance de los valores se ha reducido y el prefijo del espacio de nombres eliminado, por lo que verá el campo de contraseña simplemente como `.Values.password`. #### Valores Globales A partir de 2.0.0-Alpha.2, Helm admite un valor "global" especial. Considere esta versión modificada del ejemplo anterior: ```yaml title: "My WordPress Site" # Enviado a la plantilla de WordPress global: app: MyWordPress mysql: max_connections: 100 # Enviado a MySQL password: "secret" apache: port: 8080 # Enviado a Apache ``` Lo anterior agrega una sección `global` con el valor `app: MyWordPress`. Este valor está disponible para _todos_ los charts como `.Values.global.app`. Por ejemplo, las plantillas `mysql` pueden acceder a `app` como `{{ .Values.global.app }}`, y también el chart `apache`. Efectivamente, el archivo de valores anterior se regenera así: ```yaml title: "My WordPress Site" # Enviado a la plantilla de WordPress global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Enviado a MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Enviado a Apache ``` Esto proporciona una forma de compartir una variable de nivel superior con todos los sub-charts, lo cual es útil para cosas como establecer propiedades de `metadatos` como etiquetas. Si un sub-chart declara una variable global, ese global se pasará _hacia abajo_ (a los sub-charts del sub-chart), pero no _hacia arriba_ al chart padre. No hay forma de que un sub-chart influya en los valores del chart padre. Además, las variables globales de los charts padres tienen prioridad sobre las variables globales de los subcharts. ### Archivos de Esquema {#schema-files} A veces, un mantenedor de charts puede querer definir una estructura sobre sus valores. Esto se puede hacer definiendo un esquema en el archivo `values.schema.json`. Un esquema se representa como un [JSON Schema](https://json-schema.org/). Podría verse algo como esto: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Este esquema se aplicará a los valores para validarlo. La validación se produce cuando se invoca cualquiera de los siguientes comandos: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Un ejemplo de un archivo `values.yaml` que cumpla con los requisitos de este esquema podría verse así: ```yaml name: frontend protocol: https port: 443 ``` Tenga en cuenta que el esquema se aplica al objeto final `.Values`, y no solo al archivo `values.yaml`. Esto significa que el siguiente archivo `yaml` es válido, dado que el chart se instala con la opción `--set` apropiada que se muestra a continuación. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Además, el objeto `.Values` final se verifica con *todos* los esquemas de los sub-charts. Esto significa que un chart padre no puede eludir las restricciones de un sub-chart. Esto también funciona al revés: si un subchart tiene un requisito que no se cumple en el archivo `values.yaml` del subchart, el chart padre *debe* satisfacer esas restricciones para ser válido. La validación del esquema se puede deshabilitar con la siguiente opción. Esto es particularmente útil en entornos aislados (air-gapped) cuando el archivo JSON Schema de un chart contiene referencias remotas. ```console helm install --skip-schema-validation ``` ### Referencias Cuando se trata de escribir plantillas, valores y archivos de esquema, existen varias referencias estándar que le ayudarán. - [Plantillas de Go](https://godoc.org/text/template) - [Funciones extras de plantillas](https://godoc.org/github.com/Masterminds/sprig) - [El formato YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) Kubernetes proporciona un mecanismo para declarar nuevos tipos de objetos de Kubernetes. Con CustomResourceDefinitions (CRD), los desarrolladores de Kubernetes pueden declarar tipos de recursos personalizados. En Helm 3, los CRD se tratan como un tipo especial de objeto. Se instalan antes que el resto de la tabla y están sujetos a algunas limitaciones. Los archivos CRD YAML deben colocarse en el directorio `crds/` dentro de un chart. Se pueden colocar varios CRD (separados por marcadores de inicio y finalización YAML) en el mismo archivo. Helm intentará cargar _todos_ los archivos del directorio CRD en Kubernetes. Los archivos CRD _no pueden tener plantilla_. Deben ser documentos YAML simples. Cuando Helm instala un nuevo chart, cargará los CRD, se detendrá hasta que el servidor de API los ponga a disposición, y luego iniciará el motor de plantillas, renderizará el resto del chart y lo cargará en Kubernetes. Debido a este orden, la información de CRD está disponible en el objeto `.Capabilities` en las plantillas de Helm, y las plantillas de Helm pueden crear nuevas instancias de objetos que fueron declarados en los CRD. For example, if your chart had a CRD for `CronTab` in the `crds/` directory, you may create instances of the `CronTab` kind in the `templates/` directory: Por ejemplo, si su chart tenía un CRD para `CronTab` en el directorio `crds/`, puede crear instancias del tipo `CronTab` en el directorio `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` El archivo `crontab.yaml` debe contener el CRD sin directivas de plantilla: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Luego, la plantilla `mycrontab.yaml` puede crear un nuevo `CronTab` (usando plantillas como de costumbre): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm se asegurará de que el tipo `CronTab` se haya instalado y esté disponible en el servidor API de Kubernetes antes de continuar con la instalación de las cosas en `templates/`. ### Limitaciones de los CRDs A diferencia de la mayoría de los objetos de Kubernetes, los CRD se instalan globalmente. Por esa razón, Helm adopta un enfoque muy cauteloso en la gestión de CRD. Los CRD están sujetos a las siguientes limitaciones: - Los CRD nunca se reinstalan. Si Helm determina que los CRD en el directorio `crds/` ya están presentes (independientemente de la versión), Helm no intentará instalarlos ni actualizarlos. - Los CRD nunca se instalan en la actualización o reversión. Helm solo creará CRD en las operaciones de instalación. - Los CRD nunca se eliminan. La eliminación de un CRD elimina automáticamente todo el contenido del CRD en todos los espacios de nombres del clúster. En consecuencia, Helm no eliminará los CRD. Se recomienda a los operadores que deseen actualizar o eliminar CRD que lo hagan manualmente y con mucho cuidado. ## Uso de Helm para Administrar Charts La herramienta `helm` tiene varios comandos para trabajar con charts. Puede crear un nuevo chart para usted: ```console $ helm create mychart Created mychart/ ``` Una vez que haya editado un chart, `helm` puede empaquetarlo en un archivo de charts para usted: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` También puede usar `helm` para ayudarlo a encontrar problemas con el formato o la información de su chart: ```console $ helm lint mychart No issues found ``` ## Repositorios de Chart Un _repositorio de charts_ es un servidor HTTP que alberga uno o más charts empaquetados. Si bien `helm` se puede usar para administrar directorios de charts locales, cuando se trata de compartir charts, el mecanismo preferido es un repositorio de charts. Cualquier servidor HTTP que pueda servir archivos YAML y tar y que pueda responder solicitudes GET se puede utilizar como servidor de repositorio. El equipo de Helm ha probado algunos servidores, incluido Google Cloud Storage con el modo de sitio web habilitado y S3 con el modo de sitio web habilitado. Un repositorio se caracteriza principalmente por la presencia de un archivo especial llamado `index.yaml` que tiene una lista de todos los paquetes proporcionados por el repositorio, junto con metadatos que permiten recuperar y verificar esos paquetes. En el lado del cliente, los repositorios se administran con los comandos `helm repo`. Sin embargo, Helm no proporciona herramientas para cargar charts en servidores de repositorios remotos. Esto se debe a que hacerlo agregaría requisitos sustanciales a un servidor de implementación y, por lo tanto, elevaría la barrera para configurar un repositorio. ## Paquetes de Inicio de Charts El comando `helm create` toma una opción opcional `--starter` que le permite especificar un "chart de inicio". Además, la opción starter tiene un alias corto `-p`. Ejemplos de uso: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Los paquetes de inicio son charts regulares, pero se encuentran en `$XDG_DATA_HOME/helm/starters`. Como desarrollador de charts, puede crear charts que estén diseñados específicamente para usarse como iniciadores. Dichos charts deben diseñarse teniendo en cuenta las siguientes consideraciones: - El generador sobrescribirá el archivo `Chart.yaml`. - Los usuarios esperarán modificar el contenido de dicho chart, por lo que la documentación debe indicar cómo pueden hacerlo los usuarios. - Todas las apariciones de `` serán reemplazadas con el nombre de chart especificado para que los charts de inicio se puedan usar como plantillas, excepto para algunos archivos variables. Por ejemplo, si usa archivos personalizados en el directorio `vars` o ciertos archivos `README.md`, `` NO se reemplazará dentro de ellos. Además, la descripción del chart no se hereda. Actualmente, la única forma de agregar un chart a `$XDG_DATA_HOME/helm/starters` es copiarlo manualmente allí. En la documentación de su chart, es posible que desee explicar ese proceso. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: "Ganchos de Chart" description: "Describe como trabajar con ganchos de chart." sidebar_position: 2 --- Helm proporciona un mecanismo de _gancho_ (hook) que permite a los desarrolladores de charts intervenir en determinados puntos del ciclo de vida de un release. Por ejemplo, puede utilizar ganchos para: - Cargue un ConfigMap o un Secret durante la instalación antes de que se carguen otros charts. - Ejecute un trabajo para hacer una copia de seguridad de una base de datos antes de instalar un nuevo chart y luego ejecute un segundo trabajo después de la actualización para restaurar los datos. - Ejecute un trabajo antes de eliminar un release para retirar un servicio de rotación antes de eliminarlo. Los ganchos funcionan como plantillas normales, pero tienen anotaciones especiales que hacen que Helm los utilice de manera diferente. En esta sección, cubrimos el patrón de uso básico de los ganchos. ## Los Ganchos Disponibles Se definen los siguientes ganchos: | Valor de Anotación | Descripción | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | `pre-install` | Se ejecuta después de que se procesan las plantillas, pero antes de que se creen recursos en Kubernetes | | `post-install` | Se ejecuta después de que todos los recursos se cargan en Kubernetes | | `pre-delete` | Ejecuta en una solicitud de eliminación antes de que se eliminen los recursos de Kubernetes | | `post-delete` | Se ejecuta en una solicitud de eliminación después de que se hayan eliminado todos los recursos del release | | `pre-upgrade` | Se ejecuta en una solicitud de actualización después de que se procesan las plantillas, pero antes de que se actualicen los recursos | | `post-upgrade` | Se ejecuta en una solicitud de actualización después de que se hayan actualizado todos los recursos. | | `pre-rollback` | Se ejecuta en una solicitud de reversión después de renderizar las plantillas, pero antes de revertir los recursos | | `post-rollback` | Se ejecuta en una solicitud de reversión después de que se hayan modificado todos los recursos. | | `test` | Se ejecuta cuando se invoca el subcomando Helm test ([ver documentos de prueba](/topics/chart_tests.md)) | _Note que el gancho `crd-install` se ha eliminado a favor del directorio `crds/` en Helm 3._ ## Ganchos y el Ciclo de Vida del Release Los ganchos le brindan a usted, el desarrollador de charts, la oportunidad de realizar operaciones en puntos estratégicos del ciclo de vida de un release. Por ejemplo, considere el ciclo de vida de un `helm install`. De forma predeterminada, el ciclo de vida se ve así: 1. El usuario ejecuta `helm install foo` 2. La API de instalación de la biblioteca Helm se llama 3. Después de cierta verificación, la biblioteca renderiza las plantillas de `foo` 4. La biblioteca carga los recursos resultantes en Kubernetes. 5. La biblioteca devuelve el objeto de release (y otros datos) al cliente. 6. El cliente sale Helm define dos ganchos para el ciclo de vida de `install`: `pre-install` y `post-install`. Si el desarrollador del chart `foo` implementa ambos ganchos, el ciclo de vida se modifica así: 1. El usuario ejecuta `helm install foo` 2. La API de instalación de la biblioteca Helm se llama 3. Se instalan los CRD del directorio `crds/` 4. Después de cierta verificación, la biblioteca renderiza las plantillas de `foo` 5. La biblioteca se prepara para ejecutar los ganchos de `pre-install` (cargando los recursos del gancho en Kubernetes) 6. La biblioteca ordena los ganchos por peso (asignando un peso de 0 de forma predeterminada), por tipo de recurso y finalmente por nombre en orden ascendente. 7. Luego, la biblioteca carga primero el gancho con el peso más bajo (negativo a positivo) 8. La biblioteca espera hasta que el gancho esté "Listo" (excepto para los CRD). 9. La biblioteca carga los recursos resultantes en Kubernetes. Tenga en cuenta que si la bandera `--wait` está configurada, la biblioteca esperará hasta que todos los recursos estén en un estado "Listo" y no ejecutará el gancho `post-install` hasta que estén listos. 10. La biblioteca ejecuta el gancho `post-install` (cargando recursos del gancho) 11. La biblioteca espera hasta que el gancho esté "Listo". 12. La biblioteca devuelve el objeto de release (y otros datos) al cliente. 13. El cliente sale ¿Qué significa esperar hasta que un gancho esté listo? Esto depende del recurso declarado en el gancho. Si el recurso es del tipo `Job` o `Pod`, Helm esperará hasta que se complete correctamente. Y si el gancho falla, el release fallará. Esta es una _operación de bloqueo_, por lo que el cliente de Helm se detendrá mientras se ejecuta el Job. Para todos los demás tipos, tan pronto como Kubernetes marca el recurso como cargado (agregado o actualizado), el recurso se considera "Listo". Cuando se declaran muchos recursos en un gancho, los recursos se ejecutan en serie. Si tienen pesos de gancho (ver más abajo), se ejecutan en orden ponderado. A partir de Helm 3.2.0, los recursos de ganchos con el mismo peso se instalan en el mismo orden que los recursos normales que no son de gancho. De lo contrario, el ordenamiento no está garantizado. (En Helm 2.3.0 y posteriores, se ordenan alfabéticamente. Sin embargo, ese comportamiento no se considera vinculante y podría cambiar en el futuro). Se considera una buena práctica agregar un peso de gancho y establecerlo en `0` si el peso no es importante. ### Los recursos del gancho no se administran con los releases correspondientes Los recursos que crea un gancho no se rastrean ni administran actualmente como parte del release. Una vez que Helm verifica que el gancho ha alcanzado su estado listo, dejará solo el recurso de gancho. La recolección de basura de los recursos del gancho cuando se elimina el release correspondiente se puede agregar a Helm 3 en el futuro, por lo que cualquier recurso del gancho que nunca deba eliminarse debe anotarse con `helm.sh/resource-policy: keep`. En términos prácticos, esto significa que si crea recursos en un gancho, no puede confiar en `helm uninstall` para eliminar los recursos. Para destruir dichos recursos, debe [agregar una anotación personalizada `helm.sh/hook-delete-policy`](#políticas-de-eliminación-de-ganchos) al archivo de plantilla de gancho, o [establecer el campo de tiempo de vida (TTL) de un recurso Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Escribir un Gancho Los ganchos son solo archivos de manifiesto de Kubernetes con anotaciones especiales en la sección `metadata`. Debido a que son archivos de plantilla, puede utilizar todas las funciones normales de la plantilla, incluida la lectura de `.Values`, `.Release` y `.Template`. Por ejemplo, esta plantilla, almacenada en `templates/post-install-job.yaml`, declara que un Job se ejecutará en `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # Esto es lo que define este recurso como un gancho. Sin esta línea, # el trabajo se considera parte del release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Lo que hace que esta plantilla sea un gancho es la anotación: ```yaml annotations: "helm.sh/hook": post-install ``` Un recurso puede implementar varios ganchos: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` De manera similar, no hay límite para la cantidad de recursos diferentes que pueden implementar un gancho determinado. Por ejemplo, uno podría declarar tanto un ConfigMap y un Secret como un gancho de pre-install. Cuando los sub-charts declaran ganchos, también se evalúan. No hay forma de que un chart de nivel superior deshabilite los ganchos declarados por los sub-charts. Es posible definir un peso para un gancho que ayudará a construir un orden de ejecución determinista. Los pesos se definen mediante la siguiente anotación: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Los pesos de los ganchos pueden ser números positivos o negativos, pero deben representarse como cadenas. Cuando Helm inicia el ciclo de ejecución de ganchos de un tipo particular, los ordenará en orden ascendente. ### Políticas de eliminación de ganchos Es posible definir políticas que determinen cuándo eliminar los recursos de gancho correspondientes. Las políticas de eliminación de ganchos se definen mediante la siguiente anotación: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Puede elegir uno o más valores de anotación definidos: | Valor de Anotación | Descripción | | ---------------------- | ---------------------------------------------------------------------------------- | | `before-hook-creation` | Elimina el recurso anterior antes de que se lance un nuevo gancho (predeterminado) | | `hook-succeeded` | Eliminar el recurso después de que el gancho se ejecute correctamente | | `hook-failed` | Eliminar el recurso si el gancho falló durante la ejecución | Si no se especifica ninguna anotación de política de eliminación de ganchos, el comportamiento `before-hook-creation` se aplica de forma predeterminada. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: "Temas" sidebar_position: 3 --- # Guías de Temas Aquí encontrará una introducción a todas las partes clave de Helm que necesitará o querrá saber. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: APIs de Kubernetes Obsoletas description: Explica las APIs de Kubernetes obsoletas en Helm --- Kubernetes es un sistema basado en APIs y estas evolucionan con el tiempo para adaptarse a una mejor comprensión del problema que resuelven. Esta es una práctica común en sistemas y sus APIs. Una parte importante de esta evolución es tener una buena política y proceso de deprecación para informar a los usuarios sobre cómo se implementan los cambios. En otras palabras, los consumidores de su API necesitan saber con anticipación en qué release se eliminará o cambiará una API. Esto evita sorpresas y cambios incompatibles para los consumidores. La [política de deprecación de Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documenta cómo Kubernetes maneja los cambios en sus versiones de API. La política establece el plazo durante el cual las versiones de API serán soportadas después de un anuncio de deprecación. Por lo tanto, es importante conocer los anuncios de deprecación y saber cuándo se eliminarán las versiones de API para minimizar el impacto. Este es un ejemplo de un anuncio [para la eliminación de versiones de API obsoletas en Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) que fue publicado unos meses antes del release. Estas versiones de API ya habrían sido anunciadas como obsoletas previamente. Esto demuestra que existe una buena política que informa a los consumidores sobre el soporte de versiones de API. Las plantillas de Helm especifican un [grupo de API de Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) al definir un objeto de Kubernetes, similar a un archivo de manifiesto de Kubernetes. Se especifica en el campo `apiVersion` de la plantilla e identifica la versión de API del objeto de Kubernetes. Esto significa que los usuarios de Helm y los mantenedores de charts deben conocer cuándo las versiones de API de Kubernetes han sido declaradas obsoletas y en qué versión de Kubernetes serán eliminadas. ## Mantenedores de Charts Debe auditar sus charts verificando las versiones de API de Kubernetes que están obsoletas o han sido eliminadas en alguna versión de Kubernetes. Las versiones de API que están por dejar de ser soportadas o que ya no lo son deben actualizarse a la versión soportada y publicar una nueva versión del chart. La versión de API se define mediante los campos `kind` y `apiVersion`. Por ejemplo, aquí hay una versión de API de objeto `Deployment` eliminada en Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Usuarios de Helm Debe auditar los charts que utiliza (similar a los [mantenedores de charts](#mantenedores-de-charts)) e identificar cualquier chart donde las versiones de API estén obsoletas o hayan sido eliminadas en alguna versión de Kubernetes. Para los charts identificados, verifique si existe una versión más reciente del chart (con versiones de API soportadas) o actualice el chart usted mismo. Además, debe auditar los charts desplegados (es decir, los releases de Helm) verificando nuevamente si hay versiones de API obsoletas o eliminadas. Puede hacerlo obteniendo los detalles de un release con el comando `helm get manifest`. Los pasos para actualizar un release de Helm a APIs soportadas dependen de lo que encuentre: 1. Si encuentra solo versiones de API obsoletas: - Realice un `helm upgrade` con una versión del chart que tenga versiones de API de Kubernetes soportadas - Agregue una descripción en la actualización indicando que no debe revertirse a una versión de Helm anterior a esta 2. Si encuentra alguna versión de API que haya sido eliminada en una versión de Kubernetes: - Si está ejecutando una versión de Kubernetes donde las versiones de API aún están disponibles (por ejemplo, está en Kubernetes 1.15 y encontró que usa APIs que serán eliminadas en Kubernetes 1.16): - Siga el procedimiento del paso 1 - De lo contrario (por ejemplo, ya está ejecutando una versión de Kubernetes donde algunas versiones de API reportadas por `helm get manifest` ya no están disponibles): - Necesita editar el manifiesto del release almacenado en el clúster para actualizar las versiones de API. Consulte [Actualización de Versiones de API de un Manifiesto de Release](#actualización-de-versiones-de-api-de-un-manifiesto-de-release) para más detalles > Nota: En todos los casos de actualización de un release de Helm con APIs soportadas, nunca debe revertir el release a una versión anterior a la versión con las APIs soportadas. > Recomendación: La mejor práctica es actualizar los releases que usan versiones de API obsoletas a versiones soportadas antes de actualizar a un clúster de Kubernetes que elimine esas versiones de API. Si no actualiza un release como se sugirió anteriormente, obtendrá un error similar al siguiente al intentar actualizar un release en una versión de Kubernetes donde sus versiones de API han sido eliminadas: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm falla en este escenario porque intenta crear un parche diff entre el release desplegado actualmente (que contiene las APIs de Kubernetes eliminadas en esta versión) y el chart que está pasando con las versiones de API actualizadas/soportadas. La razón subyacente es que cuando Kubernetes elimina una versión de API, la biblioteca cliente de Go de Kubernetes ya no puede analizar los objetos obsoletos, por lo que Helm falla al llamar a la biblioteca. Desafortunadamente, Helm no puede recuperarse de esta situación y ya no puede gestionar dicho release. Consulte [Actualización de Versiones de API de un Manifiesto de Release](#actualización-de-versiones-de-api-de-un-manifiesto-de-release) para más detalles sobre cómo recuperarse de este escenario. ## Actualización de Versiones de API de un Manifiesto de Release El manifiesto es una propiedad del objeto release de Helm que se almacena en el campo de datos de un Secret (por defecto) o ConfigMap en el clúster. El campo de datos contiene un objeto comprimido con gzip codificado en base 64 (hay una codificación base 64 adicional para un Secret). Existe un Secret/ConfigMap por cada versión/revisión del release en el namespace del release. Puede usar el plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis) de Helm para actualizar un release a APIs soportadas. Consulte el readme para más detalles. Alternativamente, puede seguir estos pasos manuales para actualizar las versiones de API de un manifiesto de release. Dependiendo de su configuración, seguirá los pasos para el backend de Secret o ConfigMap. - Obtenga el nombre del Secret o ConfigMap asociado con el último release desplegado: - Backend de Secrets: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Backend de ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Obtenga los detalles del último release desplegado: - Backend de Secrets: `kubectl get secret -n -o yaml > release.yaml` - Backend de ConfigMap: `kubectl get configmap -n -o yaml > release.yaml` - Haga una copia de seguridad del release en caso de que necesite restaurarlo si algo sale mal: - `cp release.yaml release.bak` - En caso de emergencia, restaure: `kubectl apply -f release.bak -n ` - Decodifique el objeto release: - Backend de Secrets:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - Backend de ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Cambie las versiones de API de los manifiestos. Puede usar cualquier herramienta (por ejemplo, un editor) para hacer los cambios. Esto está en el campo `manifest` de su objeto release decodificado (`release.data.decoded`) - Codifique el objeto release: - Backend de Secrets: `cat release.data.decoded | gzip | base64 | base64` - Backend de ConfigMap: `cat release.data.decoded | gzip | base64` - Reemplace el valor de la propiedad `data.release` en el archivo del release desplegado (`release.yaml`) con el nuevo objeto release codificado - Aplique el archivo al namespace: `kubectl apply -f release.yaml -n ` - Realice un `helm upgrade` con una versión del chart que tenga versiones de API de Kubernetes soportadas - Agregue una descripción en la actualización indicando que no debe revertirse a una versión de Helm anterior a esta ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: "Guía de distribución de Kubernetes" description: "Captura información sobre el uso de Helm en entornos específicos de Kubernetes" sidebar_position: 10 --- Helm debería funcionar con cualquier [versión conforme de Kubernetes](https://github.com/cncf/k8s-conformance) (ya sea [certificada](https://www.cncf.io/certification/software-conformance/) o no). Este documento recoge información sobre el uso de Helm en entornos Kubernetes específicos. Por favor, contribuya con más detalles sobre cualquier distro (ordenados alfabéticamente). ## AKS Helm funciona con [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm ha sido probado y funciona en la plataforma Mesospheres DC/OS 1.11 Kubernetes, y no requiere ninguna configuración adicional. ## EKS Helm funciona con Amazon Elastic Kubernetes Service (Amazon EKS): [Uso de Helm con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Se sabe que la plataforma Kubernetes alojada en GKE de Google funciona con Helm, y no requiere ninguna configuración adicional. ## `scripts/local-cluster` e Hyperkube Se sabe que Hyperkube configurado a través de `scripts/local-cluster.sh` funciona. Para Hyperkube puro es posible que tenga que hacer alguna configuración manual. ## IKS Helm funciona con [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm se prueba regularmente en [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm funciona en clusters configurados por KubeOne sin advertencias. ## Kubermatic Helm funciona en clusters de usuarios que son creados por Kubermatic sin advertencias. Dado que el cluster de semillas puede ser configurado de diferentes maneras el soporte de Helm depende de su configuración. ## MicroK8s Helm puede ser habilitado en [MicroK8s](https://microk8s.io) usando el comando: `microk8s.enable helm3` ## Minikube Helm está probado y se sabe que funciona con [Minikube](https://github.com/kubernetes/minikube). No requiere configuración adicional. ## Openshift Helm funciona sin problemas en OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) o OpenShift Origin (version >= 3.6). Para obtener más información, lea [este artículo](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm está preinstalado con [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 proporciona acceso a todos los charts oficiales de Helm a través de la App Catalog UI y la CLI nativa de Kubernetes. Se pueden añadir manualmente repositorios adicionales. Encontrará más detalles en este [artículo de Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu con `kubeadm` Se sabe que Kubernetes arrancado con `kubeadm` funciona en las siguientes distribuciones de Linux: - Ubuntu 16.04 - Fedora release 25 Algunas versiones de Helm (v2.0.0-beta2) requieren que el comando `export KUBECONFIG=/etc/kubernetes/admin.conf` o crear el fichero `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm se ejecuta en VMware Tanzu Kubernetes Grid, TKG, sin necesidad de cambios en la configuración. La CLI de Tanzu puede gestionar la instalación de paquetes para [helm-controller](https://fluxcd.io/flux/components/helm/) permitiendo gestionar de forma declarativa las liberaciones de charts de Helm. Más detalles disponibles en la documentación de TKG para [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: "Charts de Biblioteca" description: "Explica los charts de biblioteca y ejemplos de uso." sidebar_position: 4 --- Un chart de biblioteca es un tipo de [chart de Helm](/topics/charts.md) que define las primitivas o definiciones del chart que pueden ser compartidas por las plantillas de Helm en otros charts. Esto permite a los usuarios compartir fragmentos de código que se pueden reutilizar en los charts, evitando la repetición y manteniendo los charts [DRY](https://es.wikipedia.org/wiki/No_te_repitas). El chart de biblioteca se introdujo en Helm 3 para reconocer formalmente los charts comunes o auxiliares que han sido utilizados por los mantenedores de charts desde Helm 2. Al incluirlo como un tipo de chart, proporciona: - Un medio para distinguir explícitamente entre charts comunes y de aplicación - Lógica para evitar la instalación de un chart común - No se renderizan las plantillas en un chart común que puede contener artefactos de un release - Permite que los charts dependientes utilicen el contexto del chart que los importa Un mantenedor de charts puede definir un chart común como un chart de biblioteca y ahora estar seguro de que Helm manejará el chart de una manera estándar y consistente. También significa que las definiciones en un chart de aplicación se pueden compartir cambiando el tipo de chart. ## Crear un Chart de Biblioteca Simple Como se mencionó anteriormente, un chart de biblioteca es un tipo de [chart de Helm](/topics/charts.md). Esto significa que puede comenzar creando un chart base: ```console $ helm create mylibchart Creating mylibchart ``` Primero eliminará todos los archivos en el directorio `templates` ya que crearemos nuestras propias definiciones de plantillas en este ejemplo. ```console $ rm -rf mylibchart/templates/* ``` El archivo values tampoco será necesario. ```console $ rm -f mylibchart/values.yaml ``` Antes de pasar a la creación de código común, hagamos una revisión rápida de algunos conceptos relevantes de Helm. Una [plantilla con nombre](/chart_template_guide/named_templates.md) (a veces llamada parcial o subplantilla) es simplemente una plantilla definida dentro de un archivo, y se le da un nombre. En el directorio `templates/`, no se espera que ningún archivo que comience con un guión bajo (_) genere un archivo de manifiesto de Kubernetes. Entonces, por convención, las plantillas auxiliares y los parciales se colocan en archivos `_*.tpl` o `_*.yaml`. En este ejemplo, codificaremos un ConfigMap común que crea un recurso ConfigMap vacío. Definiremos el ConfigMap común en el archivo `mylibchart/templates/_configmap.yaml` de la siguiente manera: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` La construcción ConfigMap se define en la plantilla denominada `mylibchart.configmap.tpl`. Es un ConfigMap simple con un recurso vacío, `data`. Dentro de este archivo hay otra plantilla con nombre llamada `mylibchart.configmap`. Esta plantilla con nombre incluye otra plantilla con nombre `mylibchart.util.merge` que tomará 2 plantillas con nombre como argumentos, la plantilla que llama a `mylibchart.configmap` y `mylibchart.configmap.tpl`. La función auxiliar `mylibchart.util.merge` es una plantilla con nombre en `mylibchart/templates/_util.yaml`. Es una utilidad útil de [El Chart de Utilidad Común de Helm](#el-chart-de-utilidad-común-de-helm) porque combina las 2 plantillas y sobrescribe cualquier parte común en ambas: ```yaml {{- /* mylibchart.util.merge fusionará dos plantillas YAML y generará el resultado. Esto toma un array de tres valores: - el contexto superior - el nombre de la plantilla de las anulaciones (destino) - el nombre de la plantilla base (fuente) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Esto es importante cuando un chart desea utilizar un código común que necesita personalizar con su configuración. Finalmente, cambiemos el tipo de chart a `library`. Esto requiere editar `mylibchart/Chart.yaml` de la siguiente manera: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` El chart de biblioteca ahora está listo para ser compartido y su definición de ConfigMap para ser reutilizada. Antes de continuar, vale la pena verificar si Helm reconoce el chart como un chart de biblioteca: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Utilice el Chart de Biblioteca Simple Es hora de usar el chart de biblioteca. Esto significa volver a crear un chart base: ```console $ helm create mychart Creating mychart ``` Limpiemos los archivos de plantilla nuevamente, ya que solo queremos crear un ConfigMap: ```console $ rm -rf mychart/templates/* ``` Cuando queremos crear un ConfigMap simple en una plantilla de Helm, podría tener un aspecto similar al siguiente: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Sin embargo, vamos a reutilizar el código común ya creado en `mylibchart`. El ConfigMap se puede crear en el archivo `mychart/templates/configmap.yaml` de la siguiente manera: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Puede ver que simplifica el trabajo que tenemos que hacer al heredar la definición común de ConfigMap que agrega propiedades estándar para ConfigMap. En nuestra plantilla agregamos la configuración, en este caso la clave de datos `myvalue` y su valor. La configuración sobrescribe el recurso vacío del ConfigMap común. Esto es factible debido a la función auxiliar `mylibchart.util.merge` que mencionamos en la sección anterior. Para poder usar el código común, necesitamos agregar `mylibchart` como dependencia. Agregue lo siguiente al final del archivo `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Esto incluye el chart de biblioteca como una dependencia dinámica del sistema de archivos que se encuentra en la misma ruta principal que nuestro chart de aplicación. Como estamos incluyendo el chart de biblioteca como una dependencia dinámica, necesitamos ejecutar `helm dependency update`. Helm copiará el chart de biblioteca en su directorio `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Ahora estamos listos para implementar nuestro chart. Antes de instalar, vale la pena verificar primero la plantilla renderizada. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Esto se parece al ConfigMap que queremos con la sobrescritura de datos de `myvalue: Hello World`. Vamos a instalarlo: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Podemos recuperar el release y ver que se cargó la plantilla real. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Beneficios del Chart de Biblioteca Debido a su incapacidad para actuar como charts independientes, los charts de biblioteca pueden aprovechar la siguiente funcionalidad: - El objeto `.Files` hace referencia a las rutas de archivo del chart padre, en lugar de la ruta local del chart de biblioteca - El objeto `.Values` es el mismo que el del chart padre, a diferencia de los [subcharts](/chart_template_guide/subcharts_and_globals.md) de aplicación que reciben la sección de valores configurada bajo su encabezado en el padre ## El Chart de Utilidad Común de Helm ```markdown Nota: El repositorio del Chart de Utilidad Común de Helm en GitHub ya no se mantiene activamente, y el repositorio ha sido marcado como obsoleto y archivado. ``` Este [chart](https://github.com/helm/charts/tree/master/incubator/common) fue el patrón original para los charts comunes. Proporciona utilidades que reflejan las mejores prácticas del desarrollo de charts de Kubernetes. Lo mejor de todo es que puede usarlo de inmediato cuando desarrolle sus charts para brindarle un código compartido útil. Aquí hay una forma rápida de usarlo. Para más detalles, consulte el [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Vuelva a crear un chart base: ```console $ helm create demo Creating demo ``` Usemos el código común del chart auxiliar. Primero, edite el deployment `demo/templates/deployment.yaml` de la siguiente manera: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Defina anulaciones para su recurso Deployment aquí, por ejemplo apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` Y ahora el archivo de servicio, `demo/templates/service.yaml` como sigue: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Defina anulaciones para su recurso Service aquí, por ejemplo # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Estas plantillas muestran cómo heredar el código común del chart auxiliar simplifica su codificación hasta su configuración o personalización de los recursos. Para poder usar el código común, necesitamos agregar `common` como dependencia. Agregue lo siguiente al final del archivo `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Nota: Deberá agregar el repositorio `incubator` a la lista de repositorios de Helm (`helm repo add`). Como estamos incluyendo el chart como una dependencia dinámica, necesitamos ejecutar `helm dependency update`. Helm copiará el chart auxiliar en su directorio `charts/`. Como el chart auxiliar usa algunas construcciones de Helm 2, deberá agregar lo siguiente a `demo/values.yaml` para permitir que se cargue la imagen `nginx` ya que se actualizó en el chart base de Helm 3: ```yaml image: tag: 1.16.0 ``` Puede verificar que las plantillas del chart son correctas antes de desplegarlo usando los comandos `helm lint` y `helm template`. ¡Si todo está bien, proceda a desplegarlo con `helm install`! ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Gestión de permisos para el backend de almacenamiento SQL description: Aprenda a configurar permisos cuando utilice el backend de almacenamiento SQL. --- Este documento proporciona orientación para configurar y gestionar permisos al utilizar el backend de almacenamiento SQL. ## Introducción Para manejar permisos, Helm aprovecha la funcionalidad RBAC de Kubernetes. Al utilizar el backend de almacenamiento SQL, los roles de Kubernetes no pueden usarse para determinar si un usuario puede acceder a un recurso dado. Este documento muestra cómo crear y gestionar estos permisos. ## Inicialización Cuando el CLI de Helm se conecte por primera vez a su base de datos, el cliente verificará que haya sido inicializada previamente. Si no lo está, realizará la configuración necesaria automáticamente. Esta inicialización requiere privilegios de administrador en el esquema público, o al menos poder: * crear una tabla * otorgar privilegios en el esquema público Una vez ejecutada la migración en su base de datos, todos los demás roles pueden utilizar el cliente. ## Otorgar privilegios a un usuario no administrador en PostgreSQL Para gestionar permisos, el controlador del backend SQL aprovecha la funcionalidad [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Level) de PostgreSQL. RLS permite que todos los usuarios lean y escriban en la misma tabla, pero solo puedan manipular las filas para las que tienen permiso explícito. Por defecto, cualquier rol al que no se le hayan otorgado explícitamente los privilegios correctos siempre devolverá una lista vacía al ejecutar `helm list` y no podrá recuperar ni modificar ningún recurso en el clúster. Veamos cómo otorgar a un rol dado acceso a namespaces específicos: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Este comando otorgará permisos para leer y escribir todos los recursos que cumplan la condición `namespace = 'default'` al rol `role`. Después de crear esta política, el usuario conectado a la base de datos en representación del rol `role` podrá ver todos los releases en el namespace `default` al ejecutar `helm list`, y podrá modificarlos y eliminarlos. Los privilegios pueden gestionarse de manera granular con RLS, y puede resultar útil restringir el acceso según las diferentes columnas de la tabla: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Guía de Plugins de Helm description: Introduce cómo usar y crear plugins para extender la funcionalidad de Helm. sidebar_position: 12 --- Un plugin de Helm es una herramienta a la que se puede acceder a través del CLI de `helm`, pero que no forma parte del código base incorporado de Helm. Los plugins existentes se pueden encontrar en la sección [relacionados](/community/related#helm-plugins) o buscando en [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Esta guía explica cómo usar y crear plugins. ## Descripción General Los plugins de Helm son herramientas complementarias que se integran perfectamente con Helm. Proporcionan una forma de extender el conjunto de características principales de Helm, sin requerir que cada nueva característica sea escrita en Go y añadida a la herramienta principal. Los plugins de Helm tienen las siguientes características: - Se pueden agregar y eliminar de una instalación de Helm sin afectar la herramienta principal de Helm. - Pueden ser escritos en cualquier lenguaje de programación. - Se integran con Helm y aparecerán en `helm help` y otros lugares. Los plugins de Helm residen en `$HELM_PLUGINS`. Puede encontrar el valor actual de esta variable, incluyendo el valor predeterminado cuando no está configurada en el entorno, usando el comando `helm env`. El modelo de plugins de Helm está parcialmente basado en el modelo de plugins de Git. Por esa razón, a veces puede escuchar que `helm` se denomina la capa de _porcelana_, mientras que los plugins son la _fontanería_. Esta es una forma abreviada de sugerir que Helm proporciona la experiencia del usuario y la lógica de procesamiento de alto nivel, mientras que los plugins hacen el "trabajo de detalle" de realizar una acción deseada. ## Instalar un Plugin Los plugins se instalan usando el comando `$ helm plugin install `. Puede pasar una ruta a un plugin en su sistema de archivos local o una URL de un repositorio VCS remoto. El comando `helm plugin install` clona o copia el plugin en la ruta/URL proporcionada en `$HELM_PLUGINS`. Si está instalando desde un VCS, puede especificar la versión con el argumento `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Si tiene una distribución tar de un plugin, simplemente descomprima el plugin en el directorio `$HELM_PLUGINS`. También puede instalar plugins tarball directamente desde una URL usando `helm plugin install https://domain/path/to/plugin.tar.gz` ## Estructura de Archivos del Plugin En muchos aspectos, un plugin es similar a un chart. Cada plugin tiene un directorio de nivel superior que contiene un archivo `plugin.yaml`. Pueden estar presentes archivos adicionales, pero solo el archivo `plugin.yaml` es requerido. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## El Archivo plugin.yaml El archivo plugin.yaml es requerido para un plugin. Contiene los siguientes campos: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### El Campo `name` El `name` es el nombre del plugin. Cuando Helm ejecuta este plugin, este es el nombre que usará (por ejemplo, `helm NAME` invocará este plugin). _`name` debe coincidir con el nombre del directorio._ En nuestro ejemplo anterior, eso significa que el plugin con `name: last` debe estar contenido en un directorio llamado `last`. Restricciones sobre `name`: - `name` no puede duplicar uno de los comandos de nivel superior existentes de `helm`. - `name` debe estar restringido a los caracteres ASCII a-z, A-Z, 0-9, `_` y `-`. ### El Campo `version` El `version` es la versión SemVer 2 del plugin. `usage` y `description` se utilizan para generar el texto de ayuda de un comando. ### El Campo `ignoreFlags` El interruptor `ignoreFlags` le indica a Helm que _no_ pase banderas al plugin. Por lo tanto, si un plugin se llama con `helm myplugin --foo` e `ignoreFlags: true`, entonces `--foo` se descarta silenciosamente. ### El Campo `platformCommand` El campo `platformCommand` configura el comando que el plugin ejecutará cuando sea invocado. No puede establecer tanto `platformCommand` como `command`, ya que esto resultará en un error. Se aplicarán las siguientes reglas para decidir qué comando usar: - Si `platformCommand` está presente, se usará. - Si tanto `os` como `arch` coinciden con la plataforma actual, la búsqueda se detendrá y se usará el comando. - Si `os` coincide y `arch` está vacío, se usará el comando. - Si tanto `os` como `arch` están vacíos, se usará el comando. - Si no hay coincidencia, Helm saldrá con un error. - Si `platformCommand` no está presente y el obsoleto `command` está presente, se usará. - Si el comando está vacío, Helm saldrá con un error. ### El Campo `platformHooks` El campo `platformHooks` configura los comandos que el plugin ejecutará para eventos del ciclo de vida. No puede establecer tanto `platformHooks` como `hooks`, ya que esto resultará en un error. Se aplicarán las siguientes reglas para decidir qué comando de hook usar: - Si `platformHooks` está presente, se usará y se procesarán los comandos para el evento del ciclo de vida. - Si tanto `os` como `arch` coinciden con la plataforma actual, la búsqueda se detendrá y se usará el comando. - Si `os` coincide y `arch` está vacío, se usará el comando. - Si tanto `os` como `arch` están vacíos, se usará el comando. - Si no hay coincidencia, Helm omitirá el evento. - Si `platformHooks` no está presente y el obsoleto `hooks` está presente, se usará el comando para el evento del ciclo de vida. - Si el comando está vacío, Helm omitirá el evento. ## Construir un Plugin Aquí está el YAML del plugin para un plugin simple que ayuda a obtener el nombre del último release: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Los plugins pueden requerir scripts y ejecutables adicionales. Los scripts pueden incluirse en el directorio del plugin y los ejecutables pueden descargarse mediante un hook. El siguiente es un ejemplo de plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Las variables de entorno se interpolan antes de que el plugin se ejecute. El patrón anterior ilustra la forma preferida de indicar dónde reside el programa del plugin. ### Comandos del Plugin Hay algunas estrategias para trabajar con comandos de plugins: - Si un plugin incluye un ejecutable, el ejecutable para un `platformCommand:` o debe estar empaquetado en el directorio del plugin o instalado mediante un hook. - La línea `platformCommand:` o `command:` tendrá todas las variables de entorno expandidas antes de la ejecución. `$HELM_PLUGIN_DIR` apuntará al directorio del plugin. - El comando en sí no se ejecuta en un shell. Por lo tanto, no puede escribir un script de shell en una sola línea. - Helm inyecta mucha configuración en variables de entorno. Examine el entorno para ver qué información está disponible. - Helm no hace suposiciones sobre el lenguaje del plugin. Puede escribirlo en el lenguaje que prefiera. - Los comandos son responsables de implementar texto de ayuda específico para `-h` y `--help`. Helm usará `usage` y `description` para `helm help` y `helm help myplugin`, pero no manejará `helm myplugin --help`. ### Probar un Plugin Local Primero necesita encontrar la ruta de su `HELM_PLUGINS`. Para hacerlo, ejecute el siguiente comando: ``` bash helm env ``` Cambie su directorio actual al directorio donde está configurado `HELM_PLUGINS`. Ahora puede agregar un enlace simbólico a la salida de compilación de su plugin. En este ejemplo lo hicimos para `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Plugins de Descarga Por defecto, Helm puede descargar Charts usando HTTP/S. A partir de Helm 2.4.0, los plugins pueden tener una capacidad especial para descargar Charts desde fuentes arbitrarias. Los plugins deben declarar esta capacidad especial en el archivo `plugin.yaml` (nivel superior): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Si dicho plugin está instalado, Helm puede interactuar con el repositorio usando el esquema de protocolo especificado invocando el `command`. El repositorio especial debe agregarse de manera similar a los regulares: `helm repo add favorite myprotocol://example.com/`. Las reglas para los repositorios especiales son las mismas que para los regulares: Helm debe poder descargar el archivo `index.yaml` para descubrir y almacenar en caché la lista de Charts disponibles. El comando definido se invocará con el siguiente esquema: `command certFile keyFile caFile full-URL`. Las credenciales SSL provienen de la definición del repositorio, almacenada en `$HELM_REPOSITORY_CONFIG` (es decir, `$HELM_CONFIG_HOME/repositories.yaml`). Se espera que un plugin de descarga envíe el contenido sin procesar a stdout e informe errores en stderr. El comando de descarga también admite subcomandos o argumentos, lo que le permite especificar, por ejemplo, `bin/mydownloader subcommand -d` en el `plugin.yaml`. Esto es útil si desea usar el mismo ejecutable para el comando principal del plugin y el comando de descarga, pero con un subcomando diferente para cada uno. ## Variables de Entorno Cuando Helm ejecuta un plugin, pasa el entorno externo al plugin y también inyecta algunas variables de entorno adicionales. Variables como `KUBECONFIG` se configuran para el plugin si están configuradas en el entorno externo. Se garantiza que las siguientes variables estarán configuradas: - `HELM_PLUGINS`: La ruta al directorio de plugins. - `HELM_PLUGIN_NAME`: El nombre del plugin, como fue invocado por `helm`. Así que `helm myplug` tendrá el nombre corto `myplug`. - `HELM_PLUGIN_DIR`: El directorio que contiene el plugin. - `HELM_BIN`: La ruta al comando `helm` (como fue ejecutado por el usuario). - `HELM_DEBUG`: Indica si la bandera de depuración fue establecida por helm. - `HELM_REGISTRY_CONFIG`: La ubicación de la configuración del registro (si se usa). Tenga en cuenta que el uso de Helm con registros es una característica experimental. - `HELM_REPOSITORY_CACHE`: La ruta a los archivos de caché del repositorio. - `HELM_REPOSITORY_CONFIG`: La ruta al archivo de configuración del repositorio. - `HELM_NAMESPACE`: El namespace dado al comando `helm` (generalmente usando la bandera `-n`). - `HELM_KUBECONTEXT`: El nombre del contexto de configuración de Kubernetes dado al comando `helm`. Adicionalmente, si se especificó explícitamente un archivo de configuración de Kubernetes, se establecerá como la variable `KUBECONFIG`. ## Una Nota sobre el Análisis de Banderas Al ejecutar un plugin, Helm analizará las banderas globales para su propio uso. Ninguna de estas banderas se pasa al plugin. - `--burst-limit`: Esto se convierte a `$HELM_BURST_LIMIT` - `--debug`: Si se especifica, `$HELM_DEBUG` se establece en `1` - `--kube-apiserver`: Esto se convierte a `$HELM_KUBEAPISERVER` - `--kube-as-group`: Estas se convierten a `$HELM_KUBEASGROUPS` - `--kube-as-user`: Esto se convierte a `$HELM_KUBEASUSER` - `--kube-ca-file`: Esto se convierte a `$HELM_KUBECAFILE` - `--kube-context`: Esto se convierte a `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: Esto se convierte a `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: Esto se convierte a `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: Esto se convierte a `$HELM_KUBETOKEN` - `--kubeconfig`: Esto se convierte a `$KUBECONFIG` - `--namespace` y `-n`: Esto se convierte a `$HELM_NAMESPACE` - `--qps`: Esto se convierte a `$HELM_QPS` - `--registry-config`: Esto se convierte a `$HELM_REGISTRY_CONFIG` - `--repository-cache`: Esto se convierte a `$HELM_REPOSITORY_CACHE` - `--repository-config`: Esto se convierte a `$HELM_REPOSITORY_CONFIG` Los plugins _deberían_ mostrar texto de ayuda y luego salir para `-h` y `--help`. En todos los demás casos, los plugins pueden usar banderas según sea apropiado. ## Proporcionar Auto-completado de Shell A partir de Helm 3.2, un plugin puede opcionalmente proporcionar soporte para auto-completado de shell como parte del mecanismo de auto-completado existente de Helm. ### Auto-completado Estático Si un plugin proporciona sus propias banderas y/o subcomandos, puede informar a Helm de ellos teniendo un archivo `completion.yaml` ubicado en el directorio raíz del plugin. El archivo `completion.yaml` tiene la siguiente forma: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Notas: 1. Todas las secciones son opcionales pero deben proporcionarse si son aplicables. 1. Las banderas no deben incluir el prefijo `-` o `--`. 1. Se pueden y deben especificar tanto banderas cortas como largas. Una bandera corta no necesita estar asociada con su forma larga correspondiente, pero ambas formas deben listarse. 1. Las banderas no necesitan estar ordenadas de ninguna manera, pero deben listarse en el punto correcto de la jerarquía de subcomandos del archivo. 1. Las banderas globales existentes de Helm ya son manejadas por el mecanismo de auto-completado de Helm, por lo tanto los plugins no necesitan especificar las siguientes banderas `--debug`, `--namespace` o `-n`, `--kube-context`, y `--kubeconfig`, ni ninguna otra bandera global. 1. La lista `validArgs` proporciona una lista estática de posibles completados para el primer parámetro después de un subcomando. No siempre es posible proporcionar dicha lista por adelantado (consulte la sección [Completado Dinámico](#completado-dinámico) a continuación), en cuyo caso la sección `validArgs` puede omitirse. El archivo `completion.yaml` es completamente opcional. Si no se proporciona, Helm simplemente no proporcionará auto-completado de shell para el plugin (a menos que el plugin soporte [Completado Dinámico](#completado-dinámico)). Además, agregar un archivo `completion.yaml` es compatible con versiones anteriores y no afectará el comportamiento del plugin cuando se usen versiones anteriores de helm. Como ejemplo, para el plugin [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus) que no tiene subcomandos pero acepta las mismas banderas que el comando `helm status`, el archivo `completion.yaml` es: ```yaml name: fullstatus flags: - o - output - revision ``` Un ejemplo más complejo para el plugin [`2to3`](https://github.com/helm/helm-2to3), tiene un archivo `completion.yaml` de: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Completado Dinámico También a partir de Helm 3.2, los plugins pueden proporcionar su propio auto-completado dinámico de shell. El auto-completado dinámico de shell es el completado de valores de parámetros o valores de banderas que no pueden definirse por adelantado. Por ejemplo, el completado de los nombres de releases de helm actualmente disponibles en el clúster. Para que el plugin soporte el completado dinámico, debe proporcionar un archivo **ejecutable** llamado `plugin.complete` en su directorio raíz. Cuando el script de completado de Helm requiere completados dinámicos para el plugin, ejecutará el archivo `plugin.complete`, pasándole la línea de comandos que necesita ser completada. El ejecutable `plugin.complete` deberá tener la lógica para determinar cuáles son las opciones de completado apropiadas y enviarlas a la salida estándar para ser consumidas por el script de completado de Helm. El archivo `plugin.complete` es completamente opcional. Si no se proporciona, Helm simplemente no proporcionará auto-completado dinámico para el plugin. Además, agregar un archivo `plugin.complete` es compatible con versiones anteriores y no afectará el comportamiento del plugin cuando se usen versiones anteriores de helm. La salida del script `plugin.complete` debe ser una lista separada por nuevas líneas como: ```console rel1 rel2 rel3 ``` Cuando se llama a `plugin.complete`, el entorno del plugin se configura igual que cuando se llama al script principal del plugin. Por lo tanto, las variables `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` y todas las demás variables del plugin ya estarán configuradas, y sus banderas globales correspondientes habrán sido eliminadas. El archivo `plugin.complete` puede estar en cualquier forma ejecutable; puede ser un script de shell, un programa Go o cualquier otro tipo de programa que Helm pueda ejecutar. El archivo `plugin.complete` ***debe*** tener permisos de ejecución para el usuario. El archivo `plugin.complete` ***debe*** salir con un código de éxito (valor 0). En algunos casos, el completado dinámico requerirá obtener información del clúster de Kubernetes. Por ejemplo, el plugin `helm fullstatus` requiere un nombre de release como entrada. En el plugin `fullstatus`, para que su script `plugin.complete` proporcione completado para los nombres de releases actuales, simplemente puede ejecutar `helm list -q` y mostrar el resultado. Si se desea usar el mismo ejecutable para la ejecución del plugin y para el completado del plugin, el script `plugin.complete` puede configurarse para llamar al ejecutable principal del plugin con algún parámetro o bandera especial; cuando el ejecutable principal del plugin detecte el parámetro o bandera especial, sabrá que debe ejecutar el completado. En nuestro ejemplo, `plugin.complete` podría implementarse así: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` El script real del plugin `fullstatus` (`status.sh`) debe entonces buscar la bandera `--complete` y, si la encuentra, mostrar los completados apropiados. ### Consejos y Trucos 1. El shell filtrará automáticamente las opciones de completado que no coincidan con la entrada del usuario. Por lo tanto, un plugin puede devolver todos los completados relevantes sin eliminar los que no coinciden con la entrada del usuario. Por ejemplo, si la línea de comandos es `helm fullstatus ngin`, el script `plugin.complete` puede mostrar *todos* los nombres de releases (del namespace `default`), no solo los que comienzan con `ngin`; el shell solo mantendrá los que comienzan con `ngin`. 1. Para simplificar el soporte de completado dinámico, especialmente si tiene un plugin complejo, puede hacer que su script `plugin.complete` llame a su script principal del plugin y solicite opciones de completado. Consulte la sección [Completado Dinámico](#completado-dinámico) anterior para ver un ejemplo. 1. Para depurar el completado dinámico y el archivo `plugin.complete`, puede ejecutar lo siguiente para ver los resultados de completado: - `helm __complete `. Por ejemplo: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: "Procedencia e Integridad de Helm" description: "Describe cómo verificar la integridad y el origen de un Chart." sidebar_position: 5 --- Helm tiene herramientas de procedencia que ayudan a los usuarios de charts a verificar la integridad y el origen de un paquete. Utilizando herramientas estándar de la industria basadas en PKI, GnuPG y administradores de paquetes muy respetados, Helm puede generar y verificar archivos de firmas. ## Descripción General La integridad se establece comparando un chart con un registro de procedencia. Los registros de procedencia se almacenan en _archivos de procedencia_, que se almacenan junto con un chart empaquetado. Por ejemplo, si un chart se llama `myapp-1.2.3.tgz`, su archivo de procedencia será `myapp-1.2.3.tgz.prov`. Los archivos de procedencia se generan en el momento del empaquetado (`helm package --sign ...`) y se pueden verificar mediante varios comandos, en particular `helm install --verify`. ## El Flujo de Trabajo Esta sección describe un flujo de trabajo potencial para utilizar los datos de procedencia de manera eficaz. Requisitos previos: - Un par de claves PGP válido en formato binario (no blindado ASCII) - La herramienta de línea de comandos `helm` - Herramientas de línea de comandos de GnuPG (opcional) - Herramientas de línea de comandos de Keybase (opcional) **NOTA:** Si su clave privada PGP tiene una frase de contraseña, se le pedirá que ingrese esa frase de contraseña para cualquier comando que admita la opción `--sign`. Crear un nuevo chart es el mismo que antes: ```console $ helm create mychart Creating mychart ``` Una vez que esté listo para empaquetar, agregue la marca `--sign` a `helm package`. Además, especifique el nombre con el que se conoce la clave de firma y el anillo de claves que contiene la clave privada correspondiente: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Nota:** El valor del argumento `--key` debe ser una subcadena del `uid` de la clave deseada (en la salida de `gpg --list-keys`), por ejemplo, el nombre o el correo electrónico. **La huella _no_ se puede utilizar.** **SUGERENCIA:** para los usuarios de GnuPG, su anillo de claves secreto está en `~/.gnupg/secring.gpg`. Puede usar `gpg --list-secret-keys` para enumerar las claves que tiene. **Advertencia:** GnuPG v2 almacena su llavero secreto usando un nuevo formato `kbx` en la ubicación predeterminada `~/.gnupg/pubring.kbx`. Utilice el siguiente comando para convertir su llavero al formato gpg heredado: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` En este punto, debería ver tanto `mychart-0.1.0.tgz` como `mychart-0.1.0.tgz.prov`. Finalmente, ambos archivos deberían cargarse en el repositorio de charts que desee. Puede verificar un chart usando `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Una verificación fallida se ve así: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Para verificar durante una instalación, use la bandera `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Si el llavero que contiene la clave pública asociada con el chart firmado no se encuentra en la ubicación predeterminada, es posible que deba señalar el llavero con `--keyring PATH` como en el ejemplo de `helm package`. Si la verificación falla, la instalación se cancelará antes de que el chart sea renderizado. ### Usando las credenciales de Keybase.io El servicio [Keybase.io](https://keybase.io) facilita el establecimiento de una cadena de confianza para una identidad criptográfica. Las credenciales de la base de claves se pueden utilizar para firmar charts. Requisitos previos: - Una cuenta Keybase.io configurada - GnuPG instalado localmente - La CLI `keybase` instalada localmente #### Firma de paquetes El primer paso es importar sus claves de Keybase a su anillo de claves GnuPG local: ```console $ keybase pgp export -s | gpg --import ``` Esto convertirá su clave de Keybase al formato OpenPGP, y luego la importará localmente en su archivo `~/.gnupg/secring.gpg`. Puede comprobarlo ejecutando `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Tenga en cuenta que su clave secreta tendrá una cadena de identificación: ``` technosophos (keybase.io/technosophos) ``` Ese es el nombre completo de su clave. A continuación, puede empaquetar y firmar un chart con `helm package`. Asegúrese de utilizar al menos parte de esa cadena de nombre en `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Como resultado, el comando `package` debería producir tanto un archivo `.tgz` como un archivo `.tgz.prov`. #### Verificación de paquetes También puede utilizar una técnica similar para verificar un chart firmado por la clave de Keybase de otra persona. Supongamos que desea verificar un paquete firmado por `keybase.io/technosophos`. Para hacer esto, use la herramienta `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` El primer comando de arriba rastrea al usuario `technosophos`. A continuación, `keybase pgp pull` descarga las claves OpenPGP de todas las cuentas que sigue, colocándolas en su anillo de claves GnuPG (`~/.gnupg/pubring.gpg`). En este punto, ahora puede usar `helm verify` o cualquiera de los comandos con una marca `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Razones por las que un chart no puede verificar Éstas son razones comunes de falla. - Falta el archivo `.prov` o está dañado. Esto indica que algo está mal configurado o que el responsable de mantenimiento original no creó un archivo de procedencia. - La clave utilizada para firmar el archivo no está en su llavero. Esto indica que la entidad que firmó el chart no es alguien a quien ya haya señalado que confía. - Falló la verificación del archivo `.prov`. Esto indica que algo anda mal con el chart o con los datos de procedencia. - Los hash de archivo en el archivo de procedencia no coinciden con el hash del archivo de almacenamiento. Esto indica que el archivo ha sido manipulado. Si una verificación falla, hay motivos para desconfiar del paquete. ## El Archivo de Procedencia El archivo de procedencia contiene un archivo YAML de un chart más varios datos de verificación. Los archivos de procedencia están diseñados para generarse automáticamente. Se agregan los siguientes datos de procedencia: - El archivo de chart (`Chart.yaml`) se incluye para que tanto los humanos como las herramientas puedan ver fácilmente el contenido del chart. - La firma (SHA256, al igual que Docker) del paquete de charts (el archivo `.tgz`) está incluida y puede usarse para verificar la integridad del paquete de charts. - Todo el cuerpo está firmado utilizando el algoritmo utilizado por OpenPGP (consulte [Keybase.io](https://keybase.io) para conocer una forma emergente de facilitar la firma y verificación de cifrado). La combinación de esto brinda a los usuarios las siguientes garantías: - El paquete en sí no ha sido manipulado (suma de comprobación del paquete `.tgz`). - Se conoce la entidad que liberó este paquete (a través de la firma GnuPG/PGP). El formato del archivo se parece a esto: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Tenga en cuenta que la sección YAML contiene dos documentos (separados por `...\n`). El primer archivo es el contenido de `Chart.yaml`. El segundo son las sumas de comprobación, un mapa de nombres de archivo a resúmenes SHA-256 del contenido de ese archivo en el momento del empaquetado. El bloque de firma es una firma PGP estándar, que proporciona [resistencia a la manipulación](https://www.rossde.com/PGP/pgp_signatures.html). ## Repositorios de Charts Los repositorios de charts sirven como una colección centralizada de charts de Helm. Los repositorios de charts deben permitir la entrega de archivos de procedencia a través de HTTP a través de una solicitud específica, y deben hacerlos disponibles en la misma ruta de URI que el chart. Por ejemplo, si la URL base de un paquete es `https://example.com/charts/mychart-1.2.3.tgz`, el archivo de procedencia, si existe, DEBE ser accesible en `https://example.com/charts/mychart-1.2.3.tgz.prov`. Desde la perspectiva del usuario final, `helm install --verify myrepo/mychart-1.2.3` debería resultar en la descarga tanto del chart como del archivo de procedencia sin configuración o acción adicional del usuario. ### Firmas en registros basados en OCI Al publicar charts en un [registro basado en OCI](/topics/registries.md), se puede utilizar el [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) para publicar la procedencia en [sigstore](https://sigstore.dev/). [Como se describe en la documentación](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), el proceso de crear la procedencia y firmar con una clave GPG es común, pero el comando `helm sigstore upload` se puede utilizar para publicar la procedencia en un registro de transparencia inmutable. ## Establecimiento de Autoridad y Autenticidad Cuando se trata de sistemas de cadena de confianza, es importante poder establecer la autoridad de un firmante. O, para decirlo claramente, el sistema anterior depende del hecho de que usted confía en la persona que firmó el chart. Eso, a su vez, significa que debe confiar en la clave pública del firmante. Una de las decisiones de diseño de Helm ha sido que el proyecto Helm no se insertará en la cadena de confianza como parte necesaria. No queremos ser "la autoridad de certificación" para todos los firmantes de charts. En cambio, estamos a favor de un modelo descentralizado, que es parte de la razón por la que elegimos OpenPGP como nuestra tecnología fundamental. Entonces, cuando se trata de establecer la autoridad, hemos dejado este paso más o menos indefinido en Helm 2 (una decisión llevada a cabo en Helm 3). Sin embargo, tenemos algunos consejos y recomendaciones para aquellos interesados en utilizar el sistema de procedencia: - La plataforma [Keybase](https://keybase.io) proporciona un repositorio público centralizado para información de confianza. - Puede utilizar Keybase para almacenar sus claves o para obtener las claves públicas de otros. - Keybase también tiene documentación fabulosa disponible - Si bien no lo hemos probado, la función de "sitio web seguro" de Keybase podría usarse para servir charts de Helm. - La idea básica es que un "revisor de charts" oficial firme los charts con su clave, y el archivo de procedencia resultante se carga en el repositorio de charts. - Se ha trabajado en la idea de que se pueda incluir una lista de claves de firmas válidas en el archivo `index.yaml` de un repositorio. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Control de Acceso Basado en Roles description: Explica cómo Helm interactúa con el Control de Acceso Basado en Roles (RBAC) de Kubernetes. sidebar_position: 11 --- En Kubernetes, otorgar roles a un usuario o a una cuenta de servicio específica de la aplicación es una buena práctica para asegurar que su aplicación esté operando dentro del alcance que usted ha especificado. Lea más sobre los permisos de cuentas de servicio [en la documentación oficial de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). A partir de Kubernetes 1.6, el Control de Acceso Basado en Roles está habilitado por defecto. RBAC le permite especificar qué tipos de acciones están permitidas dependiendo del usuario y su rol en su organización. Con RBAC, puede: - otorgar operaciones privilegiadas (crear recursos a nivel de clúster, como nuevos roles) a administradores - limitar la capacidad de un usuario para crear recursos (pods, volúmenes persistentes, deployments) a namespaces específicos, o a nivel de todo el clúster (cuotas de recursos, roles, definiciones de recursos personalizados) - limitar la capacidad de un usuario para ver recursos ya sea en namespaces específicos o a nivel de todo el clúster. Esta guía es para administradores que desean restringir el alcance de la interacción de un usuario con la API de Kubernetes. ## Administración de cuentas de usuario Todos los clústeres de Kubernetes tienen dos categorías de usuarios: cuentas de servicio administradas por Kubernetes, y usuarios normales. Se asume que los usuarios normales son administrados por un servicio externo e independiente. Un administrador que distribuye claves privadas, un almacén de usuarios como Keystone o Google Accounts, incluso un archivo con una lista de nombres de usuario y contraseñas. En este sentido, Kubernetes no tiene objetos que representen cuentas de usuarios normales. Los usuarios normales no pueden agregarse a un clúster mediante una llamada a la API. En contraste, las cuentas de servicio son usuarios administrados por la API de Kubernetes. Están vinculadas a namespaces específicos y son creadas automáticamente por el servidor de API o manualmente mediante llamadas a la API. Las cuentas de servicio están ligadas a un conjunto de credenciales almacenadas como Secrets, que se montan en los pods permitiendo que los procesos dentro del clúster se comuniquen con la API de Kubernetes. Las solicitudes a la API están vinculadas ya sea a un usuario normal o a una cuenta de servicio, o se tratan como solicitudes anónimas. Esto significa que cada proceso dentro o fuera del clúster, desde un usuario humano escribiendo `kubectl` en una estación de trabajo, hasta kubelets en los nodos, hasta miembros del plano de control, debe autenticarse al hacer solicitudes al servidor de API, o ser tratado como un usuario anónimo. ## Roles, ClusterRoles, RoleBindings y ClusterRoleBindings En Kubernetes, las cuentas de usuario y las cuentas de servicio solo pueden ver y editar los recursos a los que se les ha otorgado acceso. Este acceso se otorga mediante el uso de Roles y RoleBindings. Los Roles y RoleBindings están vinculados a un namespace particular, lo que otorga a los usuarios la capacidad de ver y/o editar recursos dentro de ese namespace al que el Role les proporciona acceso. A nivel de clúster, estos se denominan ClusterRoles y ClusterRoleBindings. Otorgar a un usuario un ClusterRole le da acceso para ver y/o editar recursos en todo el clúster. También es necesario para ver y/o editar recursos a nivel de clúster (namespaces, cuotas de recursos, nodos). Los ClusterRoles pueden vincularse a un namespace particular mediante referencia en un RoleBinding. Los ClusterRoles predeterminados `admin`, `edit` y `view` se utilizan comúnmente de esta manera. Estos son algunos ClusterRoles disponibles por defecto en Kubernetes. Están pensados para ser roles orientados al usuario. Incluyen roles de superusuario (`cluster-admin`) y roles con acceso más granular (`admin`, `edit`, `view`). | ClusterRole predeterminado | ClusterRoleBinding predeterminado | Descripción |----------------------------|-----------------------------------|------------- | `cluster-admin` | grupo `system:masters` | Permite acceso de superusuario para realizar cualquier acción en cualquier recurso. Cuando se usa en un ClusterRoleBinding, otorga control total sobre todos los recursos en el clúster y en todos los namespaces. Cuando se usa en un RoleBinding, otorga control total sobre todos los recursos en el namespace del RoleBinding, incluyendo el namespace en sí. | `admin` | Ninguno | Permite acceso de administrador, destinado a ser otorgado dentro de un namespace usando un RoleBinding. Si se usa en un RoleBinding, permite acceso de lectura/escritura a la mayoría de los recursos en un namespace, incluyendo la capacidad de crear roles y rolebindings dentro del namespace. No permite acceso de escritura a la cuota de recursos ni al namespace en sí. | `edit` | Ninguno | Permite acceso de lectura/escritura a la mayoría de los objetos en un namespace. No permite ver ni modificar roles o rolebindings. | `view` | Ninguno | Permite acceso de solo lectura para ver la mayoría de los objetos en un namespace. No permite ver roles o rolebindings. No permite ver secrets, ya que permiten escalada de privilegios. ## Restringir el acceso de una cuenta de usuario usando RBAC Ahora que entendemos los conceptos básicos del Control de Acceso Basado en Roles, analicemos cómo un administrador puede restringir el alcance del acceso de un usuario. ### Ejemplo: Otorgar a un usuario acceso de lectura/escritura a un namespace particular Para restringir el acceso de un usuario a un namespace particular, podemos usar el role `edit` o el role `admin`. Si sus charts crean o interactúan con Roles y RoleBindings, querrá usar el ClusterRole `admin`. Adicionalmente, también puede crear un RoleBinding con acceso `cluster-admin`. Otorgar a un usuario acceso `cluster-admin` a nivel de namespace proporciona control total sobre todos los recursos en el namespace, incluyendo el namespace en sí. Para este ejemplo, crearemos un usuario con el Role `edit`. Primero, cree el namespace: ```console $ kubectl create namespace foo ``` Ahora, cree un RoleBinding en ese namespace, otorgando al usuario el role `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Ejemplo: Otorgar a un usuario acceso de lectura/escritura a nivel de clúster Si un usuario desea instalar un chart que instala recursos a nivel de clúster (namespaces, roles, definiciones de recursos personalizados, etc.), necesitará acceso de escritura a nivel de clúster. Para hacer esto, otorgue al usuario acceso `admin` o `cluster-admin`. Otorgar a un usuario acceso `cluster-admin` le da acceso a absolutamente todos los recursos disponibles en Kubernetes, incluyendo acceso a nodos con `kubectl drain` y otras tareas administrativas. Es altamente recomendable considerar proporcionar al usuario acceso `admin` en su lugar, o crear un ClusterRole personalizado adaptado a sus necesidades. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Ejemplo: Otorgar a un usuario acceso de solo lectura a un namespace particular Habrá notado que no hay un ClusterRole disponible para ver secrets. El ClusterRole `view` no otorga a un usuario acceso de lectura a Secrets debido a preocupaciones de escalada de privilegios. Helm almacena los metadatos de releases como Secrets por defecto. Para que un usuario pueda ejecutar `helm list`, necesita poder leer estos secrets. Para esto, crearemos un ClusterRole especial `secret-reader`. Cree el archivo `cluster-role-secret-reader.yaml` y escriba el siguiente contenido en el archivo: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Luego, cree el ClusterRole usando ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Una vez hecho esto, podemos otorgar a un usuario acceso de lectura a la mayoría de los recursos, y luego otorgarle acceso de lectura a los secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Ejemplo: Otorgar a un usuario acceso de solo lectura a nivel de clúster En ciertos escenarios, puede ser beneficioso otorgar a un usuario acceso a nivel de clúster. Por ejemplo, si un usuario quiere ejecutar el comando `helm list --all-namespaces`, la API requiere que el usuario tenga acceso de lectura a nivel de clúster. Para hacer esto, otorgue al usuario acceso tanto a `view` como a `secret-reader` como se describió anteriormente, pero con un ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Consideraciones adicionales Los ejemplos mostrados anteriormente utilizan los ClusterRoles predeterminados proporcionados con Kubernetes. Para un control más detallado sobre a qué recursos se les otorga acceso a los usuarios, consulte [la documentación de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sobre cómo crear sus propios Roles y ClusterRoles personalizados. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Uso de registros basados en OCI description: Describe cómo usar OCI para la distribución de Charts. sidebar_position: 7 --- A partir de Helm 3, puede usar registros de contenedores con soporte [OCI](https://www.opencontainers.org/) para almacenar y compartir paquetes de charts. A partir de Helm v3.8.0, el soporte OCI está habilitado por defecto. ## Soporte OCI antes de v3.8.0 El soporte OCI pasó de experimental a disponibilidad general con Helm v3.8.0. En versiones anteriores de Helm, el soporte OCI se comportaba de manera diferente. Si estaba usando el soporte OCI antes de Helm v3.8.0, es importante entender qué ha cambiado con las diferentes versiones de Helm. ### Habilitar el soporte OCI antes de v3.8.0 Antes de Helm v3.8.0, el soporte OCI es *experimental* y debe ser habilitado. Para habilitar el soporte experimental de OCI en versiones de Helm anteriores a v3.8.0, configure `HELM_EXPERIMENTAL_OCI` en su entorno. Por ejemplo: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Deprecación de características y cambios de comportamiento de OCI con v3.8.0 Con el lanzamiento de [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), las siguientes características y comportamientos son diferentes de versiones anteriores de Helm: - Al establecer un chart en las dependencias como OCI, la versión se puede establecer como un rango al igual que otras dependencias. - Las etiquetas SemVer que incluyen información de compilación se pueden enviar y usar. Los registros OCI no admiten `+` como carácter de etiqueta. Helm traduce el `+` a `_` cuando se almacena como etiqueta. - El comando `helm registry login` ahora sigue la misma estructura que la CLI de Docker para almacenar credenciales. La misma ubicación para la configuración del registro se puede pasar tanto a Helm como a la CLI de Docker. ### Deprecación de características y cambios de comportamiento de OCI con v3.7.0 Con el lanzamiento de [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) se incluyó la implementación de [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) para el soporte OCI. Como resultado, las siguientes características y comportamientos son diferentes de versiones anteriores de Helm: - El subcomando `helm chart` ha sido eliminado. - El caché de charts ha sido eliminado (no más `helm chart list`, etc.). - Las referencias a registros OCI ahora siempre llevan el prefijo `oci://`. - El nombre base de la referencia del registro *siempre* debe coincidir con el nombre del chart. - La etiqueta de la referencia del registro *siempre* debe coincidir con la versión semántica del chart (es decir, no hay etiquetas `latest`). - El tipo de medio de la capa del chart cambió de `application/tar+gzip` a `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Uso de un registro basado en OCI ### Repositorios Helm en registros basados en OCI Un [repositorio Helm](/topics/chart_repository.md) es una forma de alojar y distribuir charts de Helm empaquetados. Un registro basado en OCI puede contener cero o más repositorios Helm y cada uno de esos repositorios puede contener cero o más charts de Helm empaquetados. ### Usar registros alojados Existen varios registros de contenedores alojados con soporte OCI que puede usar para sus charts de Helm. Por ejemplo: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Siga la documentación del proveedor de su registro de contenedores alojado para crear y configurar un registro con soporte OCI. **Nota:** Puede ejecutar [Docker Registry](https://docs.docker.com/registry/deploying/) o [`zot`](https://github.com/project-zot/zot), que son registros basados en OCI, en su equipo de desarrollo. Ejecutar un registro basado en OCI en su equipo de desarrollo solo debe usarse con fines de prueba. ### Uso de sigstore para firmar charts basados en OCI El plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permite usar [Sigstore](https://sigstore.dev/) para firmar charts de Helm con las mismas herramientas usadas para firmar imágenes de contenedores. Esto proporciona una alternativa a la [procedencia basada en GPG](/topics/provenance.md) soportada por los [repositorios de charts](/topics/chart_repository.md) clásicos. Para más detalles sobre el uso del plugin `helm sigstore`, consulte [la documentación de ese proyecto](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Comandos para trabajar con registros ### El subcomando `registry` #### `login` Iniciar sesión en un registro (con entrada manual de contraseña) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` Cerrar sesión de un registro ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### El subcomando `push` Subir un chart a un registro basado en OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` El subcomando `push` solo puede usarse con archivos `.tgz` creados previamente usando `helm package`. Al usar `helm push` para subir un chart a un registro OCI, la referencia debe tener el prefijo `oci://` y no debe contener el nombre base ni la etiqueta. El nombre base de la referencia del registro se infiere del nombre del chart, y la etiqueta se infiere de la versión semántica del chart. Actualmente esto es un requisito estricto. Ciertos registros requieren que el repositorio y/o namespace (si se especifica) se cree de antemano. De lo contrario, se producirá un error durante la operación `helm push`. Si ha creado un [archivo de procedencia](/topics/provenance.md) (`.prov`), y está presente junto al archivo `.tgz` del chart, se subirá automáticamente al registro en el `push`. Esto añade una capa adicional en [el manifiesto del chart de Helm](#manifiesto-de-chart-de-helm). Los usuarios del [plugin helm-push](https://github.com/chartmuseum/helm-push) (para subir charts a [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) pueden experimentar problemas, ya que el plugin entra en conflicto con el nuevo `push` integrado. A partir de la versión v0.10.0, el plugin ha sido renombrado a `cm-push`. ### Otros subcomandos El soporte para el protocolo `oci://` también está disponible en varios otros subcomandos. Aquí está la lista completa: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` El nombre base (nombre del chart) de la referencia del registro *sí* se incluye para cualquier tipo de acción que involucre la descarga del chart (a diferencia de `helm push` donde se omite). Aquí hay algunos ejemplos del uso de los subcomandos listados anteriormente con charts basados en OCI: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Instalar charts con digest Instalar un chart con un digest es más seguro que con una etiqueta porque los digests son inmutables. El digest se especifica en el URI del chart: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Especificar dependencias Las dependencias de un chart se pueden descargar de un registro usando el subcomando `dependency update`. El `repository` para una entrada dada en `Chart.yaml` se especifica como la referencia del registro sin el nombre base: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Esto descargará `oci://localhost:5000/myrepo/mychart:2.7.0` cuando se ejecute `dependency update`. ## Manifiesto de chart de Helm Ejemplo de manifiesto de chart de Helm tal como se representa en un registro (note los campos `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` El siguiente ejemplo contiene un [archivo de procedencia](/topics/provenance.md) (note la capa adicional): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migrar desde repositorios de charts Migrar desde [repositorios de charts](/topics/chart_repository.md) clásicos (repositorios basados en index.yaml) es tan simple como usar `helm pull` y luego usar `helm push` para subir los archivos `.tgz` resultantes a un registro. ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Migración de Helm v2 a v3 description: Aprenda cómo migrar de Helm v2 a v3. sidebar_position: 13 --- Esta guía muestra cómo migrar de Helm v2 a v3. Helm v2 debe estar instalado y gestionando releases en uno o más clústeres. ## Resumen de Cambios en Helm 3 La lista completa de cambios de Helm 2 a 3 está documentada en la [sección de preguntas frecuentes](/faq/changes_since_helm2.md). A continuación se presenta un resumen de algunos de esos cambios que el usuario debe conocer antes y durante la migración: 1. Eliminación de Tiller: - Reemplaza la arquitectura cliente/servidor por una arquitectura cliente/biblioteca (solo el binario `helm`) - La seguridad ahora se gestiona por usuario (delegada a la seguridad del clúster de Kubernetes del usuario) - Los releases ahora se almacenan como secrets dentro del clúster y los metadatos del objeto release han cambiado - Los releases se persisten por namespace del release y ya no en el namespace de Tiller 2. Repositorio de charts actualizado: - `helm search` ahora soporta tanto búsquedas en repositorios locales como consultas de búsqueda en Artifact Hub 3. Chart apiVersion actualizado a "v2" para los siguientes cambios de especificación: - Las dependencias de charts enlazadas dinámicamente se movieron a `Chart.yaml` (`requirements.yaml` eliminado y requirements --> dependencies) - Los library charts (charts auxiliares/comunes) ahora pueden añadirse como dependencias de charts enlazadas dinámicamente - Los charts tienen un campo de metadatos `type` para definir si el chart es de tipo `application` o `library`. Por defecto es application, lo que significa que es renderizable e instalable - Los charts de Helm 2 (apiVersion=v1) siguen siendo instalables 4. Especificación de directorios XDG añadida: - El directorio home de Helm eliminado y reemplazado por la especificación de directorios XDG para almacenar archivos de configuración - Ya no es necesario inicializar Helm - `helm init` y `helm home` eliminados 5. Cambios adicionales: - La instalación/configuración de Helm se simplifica: - Solo cliente Helm (binario helm) (sin Tiller) - Se ejecuta tal cual - Los repositorios `local` o `stable` no se configuran por defecto - El hook `crd-install` eliminado y reemplazado por el directorio `crds` en el chart donde todos los CRDs definidos se instalarán antes de cualquier renderizado del chart - El valor de anotación de hook `test-failure` eliminado, y `test-success` obsoleto. Use `test` en su lugar - Comandos eliminados/reemplazados/añadidos: - delete --> uninstall: elimina todo el historial del release por defecto (anteriormente necesitaba `--purge`) - fetch --> pull - home (eliminado) - init (eliminado) - install: requiere nombre del release o argumento `--generate-name` - inspect --> show - reset (eliminado) - serve (eliminado) - template: argumento `-x`/`--execute` renombrado a `-s`/`--show-only` - upgrade: Añadido argumento `--history-max` que limita el número máximo de revisiones guardadas por release (0 para sin límite) - La biblioteca Go de Helm 3 ha sufrido muchos cambios y es incompatible con la biblioteca de Helm 2 - Los binarios de release ahora se alojan en `get.helm.sh` ## Casos de Uso de Migración Los casos de uso de migración son los siguientes: 1. Helm v2 y v3 gestionando el mismo clúster: - Este caso de uso solo se recomienda si tiene la intención de eliminar gradualmente Helm v2 y no necesita que v3 gestione ningún release desplegado por v2. Todos los nuevos releases deben desplegarse con v3 y los releases existentes desplegados con v2 solo deben actualizarse/eliminarse con v2 - Helm v2 y v3 pueden gestionar el mismo clúster sin problemas. Las versiones de Helm pueden instalarse en el mismo sistema o en sistemas separados - Si instala Helm v3 en el mismo sistema, necesita realizar un paso adicional para asegurar que ambas versiones del cliente puedan coexistir hasta que esté listo para eliminar el cliente de Helm v2. Renombre o coloque el binario de Helm v3 en una carpeta diferente para evitar conflictos - De lo contrario, no hay conflictos entre ambas versiones debido a las siguientes distinciones: - El almacenamiento de releases (historial) de v2 y v3 son independientes entre sí. Los cambios incluyen el recurso de Kubernetes para almacenamiento y los metadatos del objeto release contenidos en el recurso. Los releases también estarán en un namespace por usuario en lugar de usar el namespace de Tiller (por ejemplo, el namespace por defecto de Tiller en v2 es kube-system). v2 usa "ConfigMaps" o "Secrets" bajo el namespace de Tiller con propiedad `TILLER`. v3 usa "Secrets" en el namespace del usuario con propiedad `helm`. Los releases son incrementales tanto en v2 como en v3 - El único problema podría ser si se definen recursos de Kubernetes con alcance de clúster (por ejemplo, `clusterroles.rbac`) en un chart. El despliegue de v3 fallaría aunque sea único en el namespace porque los recursos colisionarían - La configuración de v3 ya no usa `$HELM_HOME` y usa la especificación de directorios XDG en su lugar. También se crea sobre la marcha según sea necesario. Por lo tanto, es independiente de la configuración de v2. Esto aplica solo cuando ambas versiones están instaladas en el mismo sistema 2. Migrar Helm v2 a Helm v3: - Este caso de uso aplica cuando desea que Helm v3 gestione los releases existentes de Helm v2 - Debe tenerse en cuenta que un cliente de Helm v2: - puede gestionar de 1 a muchos clústeres de Kubernetes - puede conectarse a de 1 a muchas instancias de Tiller para un clúster - Esto significa que debe tener esto en cuenta al migrar, ya que los releases se despliegan en los clústeres por Tiller y su namespace. Por lo tanto, debe ser consciente de la migración para cada clúster y cada instancia de Tiller que gestiona la instancia del cliente de Helm v2 - La ruta de migración de datos recomendada es la siguiente: 1. Hacer backup de los datos de v2 2. Migrar la configuración de Helm v2 3. Migrar los releases de Helm v2 4. Cuando esté seguro de que Helm v3 está gestionando todos los datos de Helm v2 (para todos los clústeres e instancias de Tiller de la instancia del cliente de Helm v2) según lo esperado, limpie los datos de Helm v2 - El proceso de migración está automatizado por el plugin [2to3](https://github.com/helm/helm-2to3) de Helm v3 ## Referencia - Plugin [2to3](https://github.com/helm/helm-2to3) de Helm v3 - [Artículo de blog](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) que explica el uso del plugin `2to3` con ejemplos ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Política de Soporte de Versiones de Helm" description: "Describe la política de lanzamiento de parches de Helm, así como la diferencia máxima de versiones soportada entre Helm y Kubernetes." --- Este documento describe la diferencia máxima de versiones soportada entre Helm y Kubernetes. ## Versiones Soportadas Las versiones de Helm se expresan como `x.y.z`, donde `x` es la versión mayor, `y` es la versión menor y `z` es la versión de parche, siguiendo la terminología de [Versionado Semántico](https://semver.org/spec/v2.0.0.html). El proyecto Helm mantiene una rama de release para la versión menor más reciente. Las correcciones aplicables, incluyendo correcciones de seguridad, se incorporan a la rama de release, dependiendo de la severidad y la viabilidad. Para más detalles, consulte la [política de releases de Helm](/community/release_policy). ## Diferencia de Versiones Soportada Cuando se lanza una nueva versión de Helm, se compila contra una versión menor particular de Kubernetes. Por ejemplo, Helm 3.0.0 interactúa con Kubernetes utilizando el cliente de Kubernetes 1.16.2, por lo que es compatible con Kubernetes 1.16. A partir de Helm 3, se asume que Helm es compatible con versiones `n-3` de Kubernetes contra las que fue compilado. Debido a los cambios de Kubernetes entre versiones menores, la política de soporte de Helm 2 es ligeramente más estricta, asumiendo compatibilidad con versiones `n-1` de Kubernetes. Por ejemplo, si está utilizando una versión de Helm 3 que fue compilada contra las APIs del cliente de Kubernetes 1.17, entonces debería ser seguro usarla con Kubernetes 1.17, 1.16, 1.15 y 1.14. Si está utilizando una versión de Helm 2 que fue compilada contra las APIs del cliente de Kubernetes 1.16, entonces debería ser seguro usarla con Kubernetes 1.16 y 1.15. No se recomienda usar Helm con una versión de Kubernetes más nueva que la versión contra la que fue compilado, ya que Helm no ofrece garantías de compatibilidad hacia adelante. Si elige usar Helm con una versión de Kubernetes que no soporta, lo hace bajo su propia responsabilidad. Consulte la siguiente tabla para determinar qué versión de Helm es compatible con su clúster. | Versión de Helm | Versiones de Kubernetes Soportadas | |-----------------|------------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/es/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Introducción", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Cómo hacer", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Temas", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Mejores Prácticas", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Guía de Plantillas de Charts", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandos de Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Comunidad", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Preguntas Frecuentes", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/es/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Política de Calendario de Releases" description: "Describe la política de calendario de releases de Helm." --- Para beneficio de sus usuarios, Helm define y anuncia las fechas de release con anticipación. Este documento describe la política que rige el calendario de releases de Helm. ## Calendario de Releases Puede consultar un calendario público con los próximos releases de Helm [aquí](https://helm.sh/calendar/release). ## Versionado Semántico Las versiones de Helm se expresan como `x.y.z`, donde `x` es la versión mayor, `y` es la versión menor y `z` es la versión de parche, siguiendo la terminología de [Versionado Semántico](https://semver.org/spec/v2.0.0.html). ## Releases de Parche Los releases de parche proporcionan a los usuarios correcciones de errores y correcciones de seguridad. No contienen nuevas funcionalidades. Normalmente, se realizará un nuevo release de parche relacionado con el último release menor/mayor una vez al mes, el segundo miércoles de cada mes. Se puede realizar un release de parche para corregir una regresión de alta prioridad o un problema de seguridad en cualquier momento que sea necesario. Un release de parche se cancelará por cualquiera de las siguientes razones: - si no hay contenido nuevo desde el release anterior - si la fecha del release de parche cae dentro de la semana anterior al primer release candidate (RC1) de un próximo release menor - si la fecha del release de parche cae dentro de las cuatro semanas siguientes a un release menor ## Releases Menores Los releases menores contienen correcciones de seguridad y errores, así como nuevas funcionalidades. Son compatibles con versiones anteriores en cuanto a la API y el uso del CLI. Para alinearse con los releases de Kubernetes, se realizará un release menor de Helm cada 4 meses (3 releases al año). Se pueden realizar releases menores adicionales si es necesario, pero esto no afectará el cronograma de un release futuro anunciado, a menos que falten menos de 7 días para el release anunciado. Al mismo tiempo que se publica un release, se anunciará la fecha del próximo release menor y se publicará en la página web principal de Helm. ## Releases Mayores Los releases mayores contienen cambios incompatibles. Estos releases son poco frecuentes, pero a veces son necesarios para permitir que Helm continúe evolucionando en nuevas direcciones importantes. Los releases mayores pueden ser difíciles de planificar. Con esto en mente, solo se elegirá y anunciará una fecha de release final una vez que esté disponible la primera versión beta de dicho release. ================================================ FILE: i18n/es/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Proyecto Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Desarrollo", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Comunidad", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Código fuente", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Blog", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Eventos", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Código de Conducta", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Introducción", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Consejos y trucos de Charts", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Desarrollando Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Buscar 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Guía de Contribución", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Mantenedores", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Reuniones Semanales", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Comunidad de GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Somos un proyecto graduado de Cloud Native Computing Foundation.
© Autores de Helm 2025. Documentación distribuida bajo CC-BY-4.0.
© 2025 The Linux Foundation. Todos los derechos reservados. The Linux Foundation tiene marcas registradas y usa marcas comerciales. Para una lista de marcas comerciales de The Linux Foundation, consulte nuestra página de Uso de Marcas.", "description": "The footer copyright" }, "logo.alt": { "message": "Logo de CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/es/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Logo de Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Documentación", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Blog", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Comunidad", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/fr/code.json ================================================ { "home.about.whatIsHelm": { "message": "Helm vous aide à gérer les applications Kubernetes — Les Helm Charts vous aident à définir, installer et mettre à jour même les applications Kubernetes les plus complexes.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Les Charts sont faciles à créer, versionner, partager et publier — alors commencez à utiliser Helm et arrêtez le copier-coller.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm est un projet diplômé de la {cncfLink} et est maintenu par la {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "communauté Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "En savoir plus :", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Architecture de Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Guide de Démarrage Rapide", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Vidéo : Une Introduction à Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Qu'est-ce que Helm ?", "description": "What is Helm? title" }, "home.community.nextFeatureRelease": { "message": "Prochaine Feature Release", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Version :", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Date :", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Calendrier des Versions", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Événements à Venir", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Événements à Venir", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Événements Passés", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "{meetLink} pour faire des démos et discuter des outils et projets. Les réunions de la communauté sont enregistrées et {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "Ils se réunissent chaque semaine", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "partagées sur YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Rencontres Développeur" }, "home.community.developerStandups.time": { "message": "Jeudis 9:30-10h (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Ces réunions sont ouvertes à tous. Consultez le {communityRepoLink} pour les notes et détails.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "dépôt de la communauté", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Discussion sur l'utilisation de Helm, le travail avec les charts et la résolution des erreurs courantes.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Sujets concernant le développement de Helm, les PRs en cours, les versions, etc.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Discussion pour les utilisateurs et contributeurs de Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink} pour rejoindre l'équipe Kubernetes Slack.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Demander l'accès ici", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Contribuer", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm accueille toujours les contributeurs avec plaisir !", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "Par où commencer ?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm est un grand projet avec beaucoup d'utilisateurs et de contributeurs. Cela peut être beaucoup à assimiler !", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Nous avons une liste de {goodFirstIssuesLink} si vous voulez aider mais ne savez pas par où commencer.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "bonnes premières issues", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Que dois-je faire ?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Avant de contribuer du code, veuillez lire notre {contributionGuideLink}. Il couvre les processus de création et de révision des pull requests.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Guide de Contribution", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Après avoir écrit du code, veuillez {signYourCommitsLink} pour garantir que Helm respecte l'accord {dcoLink} utilisé par la {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "signer vos commits", "description": "Sign your commits link" }, "home.community.title": { "message": "Rejoignez la communauté !", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Plus d'informations sur le projet Helm et comment contribuer.", "description": "Join the Community subtitle" }, "home.header.tagline": { "message": "Le gestionnaire de paquets pour Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm est le meilleur moyen de trouver, partager et utiliser des logiciels conçus pour", "description": "Home page header subtitle" }, "home.gettingStarted.title": { "message": "Commencer", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Télécharger Helm !", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Installez Helm avec un gestionnaire de paquets, ou {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "téléchargez un binaire", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Une fois installé, décompressez le binaire helm et ajoutez-le à votre PATH et c'est parti ! Consultez la {docsLink} pour plus d'informations sur {installationLink} et {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "documentation", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "l'installation", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "les instructions d'utilisation", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Télécharger des Charts", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Visitez {artifactHubLink} pour explorer des {helmChartsLink} de nombreux dépôts publics.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "home.features.manageComplexity": { "message": "Gérer la Complexité", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Les Charts décrivent même les applications les plus complexes, fournissent une installation d'application répétable et servent de point d'autorité unique.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Mises à Jour Faciles", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Éliminez la douleur des mises à jour avec des upgrades sur place et des hooks personnalisés.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Partage Simple", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Les Charts sont faciles à versionner, partager et héberger sur des serveurs publics ou privés.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Retours en Arrière", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Utilisez {helmRollback} pour revenir facilement à une version antérieure d'une version.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Fonctionnalités", "description": "Features section title" }, "theme.ErrorPageContent.title": { "message": "Cette page a planté.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Retour au début de la page", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Archive", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Archive", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Pagination de la liste des articles du blog", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Nouvelles entrées", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Anciennes entrées", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Pagination des articles du blog", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Article plus récent", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Article plus ancien", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Voir tous les tags", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "mode système", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "mode clair", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "mode sombre", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Basculer entre le mode sombre et clair (actuellement {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Fil d'Ariane", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 élément|{count} éléments", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Pages de documentation", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Précédent", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Suivant", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Un document tagué|{count} documents tagués", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} avec \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Pour une documentation à jour, consultez la {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "dernière version", "description": "The label used for the latest version suggestion link label" }, "theme.docs.versionBadge.label": { "message": "Version: {versionLabel}" }, "theme.common.editThisPage": { "message": "Éditer cette page", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "Lien direct vers {heading}", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " le {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " par {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Dernière mise à jour{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.NotFound.title": { "message": "Page introuvable", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versions", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Tags :", "description": "The label alongside a tag list" }, "theme.admonition.caution": { "message": "attention", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "danger", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "info", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "remarque", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "astuce", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "attention", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Fermer", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { "message": "Navigation article de blog récent", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Développer la catégorie '{label}' de la barre latérale", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Réduire la catégorie '{label}' de la barre latérale", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(s'ouvre dans un nouvel onglet)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Principal", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "Nous n'avons pas trouvé ce que vous recherchez.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Langues", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Sur cette page", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "Lire plus", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "En savoir plus sur {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "Une minute de lecture|{readingTime} minutes de lecture", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "Copier", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Copié", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Copier le code", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "Activer/désactiver le retour à la ligne", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "Page d'accueil", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "Barre latérale de documentation", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Réduire le menu latéral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Réduire le menu latéral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Fermer la barre de navigation", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Retour au menu principal", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Ouvrir/fermer la barre de navigation", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Développer le menu déroulant", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Réduire le menu déroulant", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Déplier le menu latéral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Déplier le menu latéral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "Un article|{count} articles", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} tagués avec « {tagName} »", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Auteurs", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Voir Tous les Auteurs", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Cet auteur n'a pas encore écrit d'articles.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Page non répertoriée", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Cette page n'est pas répertoriée. Les moteurs de recherche ne l'indexeront pas, et seuls les utilisateurs ayant un lien direct peuvent y accéder.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Page brouillon", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Cette page est un brouillon. Elle ne sera visible qu'en développement et sera exclue de la version de production.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Réessayer", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Aller au contenu principal", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Tags", "description": "The title of the tag list page" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Blog", "description": "The title for the blog used in SEO" }, "description": { "message": "Blog", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Tous les articles", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Utiliser Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Commandes Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Développer des Templates", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Meilleures Pratiques", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Conventions générales description: Conventions générales pour les charts. sidebar_position: 1 --- Cette partie du guide des bonnes pratiques explique les conventions générales. ## Noms des charts Les noms de charts doivent être composés uniquement de lettres minuscules et de chiffres. Les mots _peuvent_ être séparés par des tirets (-) : Exemples : ``` drupal nginx-lego aws-cluster-autoscaler ``` Les majuscules et les tirets bas (underscores) ne peuvent pas être utilisés dans les noms de charts. Les points ne devraient pas être utilisés dans les noms de charts. ## Numéros de version Dans la mesure du possible, Helm utilise [SemVer 2](https://semver.org) pour représenter les numéros de version. (Notez que les tags d'images Docker ne suivent pas nécessairement SemVer et sont donc considérés comme une exception regrettable à cette règle.) Lorsque les versions SemVer sont stockées dans des labels Kubernetes, nous remplaçons conventionnellement le caractère `+` par un caractère `_`, car les labels n'autorisent pas le signe `+` comme valeur. ## Formatage YAML Les fichiers YAML doivent être indentés avec _deux espaces_ (et jamais des tabulations). ## Utilisation des mots Helm et Chart Il existe quelques conventions pour l'utilisation des mots _Helm_ et _helm_. - _Helm_ fait référence au projet dans son ensemble - `helm` fait référence à la commande côté client - Le terme `chart` n'a pas besoin d'être mis en majuscule, car ce n'est pas un nom propre - Cependant, `Chart.yaml` doit être mis en majuscule car le nom du fichier est sensible à la casse En cas de doute, utilisez _Helm_ (avec un 'H' majuscule). ## Templates de chart et namespaces Évitez de définir la propriété `namespace` dans la section `metadata` de vos templates de chart. Le namespace à appliquer aux templates rendus doit être spécifié lors de l'appel à un client Kubernetes via un flag comme `--namespace`. Helm rend vos templates tels quels et les envoie au client Kubernetes, que ce soit Helm lui-même ou un autre programme (kubectl, flux, spinnaker, etc.). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Définitions de ressources personnalisées description: Comment créer et utiliser des CRDs. sidebar_position: 7 --- Cette partie du guide des bonnes pratiques traite de la création et de l'utilisation des objets Custom Resource Definition. Lorsque vous travaillez avec des Custom Resource Definitions (CRDs), il est important de distinguer deux éléments différents : - Il y a une déclaration de CRD. C'est le fichier YAML qui a le kind `CustomResourceDefinition` - Ensuite, il y a les ressources qui _utilisent_ la CRD. Par exemple, si une CRD définit `foo.example.com/v1`, toute ressource ayant `apiVersion: example.com/v1` et le kind `Foo` est une ressource qui utilise cette CRD. ## Installer une déclaration de CRD avant d'utiliser la ressource Helm est optimisé pour charger autant de ressources que possible dans Kubernetes le plus rapidement possible. Par conception, Kubernetes peut prendre un ensemble complet de manifestes et les mettre tous en ligne (c'est ce qu'on appelle la boucle de réconciliation). Mais il y a une différence avec les CRDs. Pour une CRD, la déclaration doit être enregistrée avant que les ressources de ce type de CRD puissent être utilisées. L'enregistrement peut prendre quelques secondes. ### Méthode 1 : Laissez Helm s'en charger Avec l'arrivée de Helm 3, nous avons supprimé les anciens hooks `crd-install` au profit d'une méthodologie plus simple. Il existe maintenant un répertoire spécial appelé `crds` que vous pouvez créer dans votre chart pour contenir vos CRDs. Ces CRDs ne sont pas traitées comme des templates, mais seront installées par défaut lors de l'exécution de `helm install` pour le chart. Si la CRD existe déjà, elle sera ignorée avec un avertissement. Si vous souhaitez ignorer l'étape d'installation des CRDs, vous pouvez passer le flag `--skip-crds`. #### Quelques mises en garde (et explications) Il n'y a actuellement pas de support pour la mise à niveau ou la suppression des CRDs via Helm. Cette décision a été prise explicitement après de nombreuses discussions avec la communauté en raison du danger de perte accidentelle de données. De plus, il n'existe actuellement pas de consensus communautaire sur la manière de gérer les CRDs et leur cycle de vie. À mesure que cela évoluera, Helm ajoutera un support pour ces cas d'utilisation. Le flag `--dry-run` de `helm install` et `helm upgrade` n'est actuellement pas supporté pour les CRDs. L'objectif du "Dry Run" est de valider que la sortie du chart fonctionnera réellement si elle est envoyée au serveur. Mais les CRDs sont une modification du comportement du serveur. Helm ne peut pas installer la CRD lors d'un dry run, donc le client de découverte ne connaîtra pas cette Custom Resource (CR), et la validation échouera. Vous pouvez alternativement déplacer les CRDs dans leur propre chart ou utiliser `helm template` à la place. Un autre point important à considérer dans la discussion sur le support des CRDs est la façon dont le rendu des templates est géré. L'un des inconvénients distincts de la méthode `crd-install` utilisée dans Helm 2 était l'impossibilité de valider correctement les charts en raison du changement de disponibilité des APIs (une CRD ajoute en fait une autre API disponible à votre cluster Kubernetes). Si un chart installait une CRD, `helm` n'avait plus un ensemble valide de versions d'API contre lesquelles travailler. C'est aussi la raison de la suppression du support du templating pour les CRDs. Avec la nouvelle méthode `crds` d'installation des CRDs, nous nous assurons maintenant que `helm` dispose d'informations complètement valides sur l'état actuel du cluster. ### Méthode 2 : Charts séparés Une autre façon de procéder est de mettre la définition de la CRD dans un chart, puis de mettre toutes les ressources qui utilisent cette CRD dans _un autre_ chart. Avec cette méthode, chaque chart doit être installé séparément. Cependant, ce workflow peut être plus utile pour les opérateurs de cluster qui ont un accès administrateur au cluster. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Dépendances description: Couvre les bonnes pratiques pour les dépendances de chart. sidebar_position: 4 --- Cette partie du guide des bonnes pratiques couvre les `dependencies` déclarées dans `Chart.yaml`. ## Versions Lorsque c'est possible, utilisez des plages de versions plutôt que de figer une version exacte. Par défaut, il est recommandé d'utiliser une correspondance au niveau du patch : ```yaml version: ~1.2.3 ``` Cela correspondra à la version `1.2.3` et à tous les patches de cette release. En d'autres termes, `~1.2.3` équivaut à `>= 1.2.3, < 1.3.0` Pour la syntaxe complète de correspondance des versions, veuillez consulter la [documentation semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Versions préliminaires Les contraintes de version ci-dessus ne correspondent pas aux versions préliminaires (pre-release). Par exemple, `version: ~1.2.3` correspondra à `version: ~1.2.4` mais pas à `version: ~1.2.3-1`. La syntaxe suivante permet une correspondance pour les pre-release ainsi qu'au niveau du patch : ```yaml version: ~1.2.3-0 ``` ### URLs de dépôt Lorsque c'est possible, utilisez des URLs de dépôt en `https://`, puis en `http://` comme alternative. Si le dépôt a été ajouté au fichier d'index des dépôts, le nom du dépôt peut être utilisé comme alias de l'URL. Utilisez `alias:` ou `@` suivi du nom du dépôt. Les URLs de fichiers (`file://...`) sont considérées comme un "cas particulier" pour les charts qui sont assemblés par un pipeline de déploiement fixe. Lors de l'utilisation de [plugins de téléchargement](../topics/plugins.md#downloader-plugins), le schéma d'URL sera spécifique au plugin. Notez qu'un utilisateur du chart devra avoir installé un plugin prenant en charge ce schéma pour mettre à jour ou construire la dépendance. Si le champ `repository` est vide, Helm ne pourra pas effectuer d'opérations de gestion des dépendances. Dans ce cas, Helm supposera que la dépendance se trouve dans un sous-répertoire du dossier `charts` avec un nom identique à la propriété `name` de la dépendance. ## Conditions et Tags Des conditions ou des tags doivent être ajoutés à toutes les dépendances qui **sont optionnelles**. Notez que par défaut, une `condition` est évaluée à `true`. La forme préférée d'une condition est : ```yaml condition: somechart.enabled ``` Où `somechart` est le nom du chart de la dépendance. Lorsque plusieurs sous-charts (dépendances) fournissent ensemble une fonctionnalité optionnelle ou interchangeable, ces charts doivent partager les mêmes tags. Par exemple, si `nginx` et `memcached` fournissent ensemble des optimisations de performance pour l'application principale du chart, et doivent être tous les deux présents lorsque cette fonctionnalité est activée, ils doivent avoir une section tags comme celle-ci : ```yaml tags: - webaccelerator ``` Cela permet à l'utilisateur d'activer ou de désactiver cette fonctionnalité avec un seul tag. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Labels et annotations description: Couvre les bonnes pratiques pour l'utilisation des labels et annotations dans votre chart. sidebar_position: 5 --- Cette partie du guide des bonnes pratiques traite de l'utilisation des labels et annotations dans votre chart. ## Est-ce un label ou une annotation ? Un élément de métadonnées doit être un label dans les conditions suivantes : - Il est utilisé par Kubernetes pour identifier cette ressource - Il est utile de l'exposer aux opérateurs pour permettre l'interrogation du système. Par exemple, nous suggérons d'utiliser `helm.sh/chart: NAME-VERSION` comme label afin que les opérateurs puissent facilement trouver toutes les instances d'un chart particulier. Si un élément de métadonnées n'est pas utilisé pour l'interrogation, il devrait être défini comme une annotation. Les hooks Helm sont toujours des annotations. ## Labels standards Le tableau suivant définit les labels courants utilisés par les charts Helm. Helm lui-même n'exige jamais qu'un label particulier soit présent. Les labels marqués REC sont recommandés et **devraient** être placés sur un chart pour une cohérence globale. Ceux marqués OPT sont optionnels. Ils sont idiomatiques ou couramment utilisés, mais ne sont pas fréquemment utilisés à des fins opérationnelles. Nom|Statut|Description -----|------|---------- `app.kubernetes.io/name` | REC | Doit être le nom de l'application, reflétant l'application entière. Généralement `{{ template "name" . }}` est utilisé pour cela. Utilisé par de nombreux manifestes Kubernetes, non spécifique à Helm. `helm.sh/chart` | REC | Doit être le nom et la version du chart : `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | Doit toujours être défini à `{{ .Release.Service }}`. Permet de trouver tout ce qui est géré par Helm. `app.kubernetes.io/instance` | REC | Doit être `{{ .Release.Name }}`. Aide à différencier les différentes instances de la même application. `app.kubernetes.io/version` | OPT | La version de l'application, peut être défini à `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | Un label courant pour marquer les différents rôles que les composants peuvent jouer dans une application. Par exemple, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | Utilisé lorsque plusieurs charts ou logiciels sont combinés pour former une application. Par exemple, un logiciel applicatif et une base de données pour produire un site web. Peut être défini sur l'application principale prise en charge. Pour plus d'informations sur les labels Kubernetes préfixés par `app.kubernetes.io`, consultez la [documentation Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods et PodTemplates description: Bonnes pratiques pour le formatage des sections Pod et PodTemplate dans les manifestes de chart. sidebar_position: 6 --- Cette partie du guide des bonnes pratiques aborde le formatage des sections Pod et PodTemplate dans les manifestes de chart. La liste suivante (non exhaustive) de ressources utilise des PodTemplates : - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images Une image de conteneur doit utiliser un tag fixe ou le SHA de l'image. Elle ne doit pas utiliser les tags `latest`, `head`, `canary`, ou d'autres tags conçus pour être « flottants ». Les images _peuvent_ être définies dans le fichier `values.yaml` pour faciliter le remplacement des images. ```yaml image: {{ .Values.redisImage | quote }} ``` Une image et un tag _peuvent_ être définis dans `values.yaml` comme deux champs séparés : ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` définit `imagePullPolicy` sur `IfNotPresent` par défaut en ajoutant ce qui suit dans votre `deployment.yaml` : ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` Et dans `values.yaml` : ```yaml image: pullPolicy: IfNotPresent ``` De la même façon, Kubernetes définit par défaut `imagePullPolicy` sur `IfNotPresent` s'il n'est pas défini du tout. Si vous souhaitez une valeur autre que `IfNotPresent`, modifiez simplement la valeur dans `values.yaml` pour la valeur souhaitée. ## Les PodTemplates doivent déclarer des sélecteurs Toutes les sections PodTemplate doivent spécifier un sélecteur. Par exemple : ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` C'est une bonne pratique car elle établit clairement la relation entre l'ensemble et le pod. Mais cela est encore plus important pour les ressources comme Deployment. Sans cela, _l'ensemble complet_ des labels est utilisé pour sélectionner les pods correspondants, ce qui peut poser problème si vous utilisez des labels qui changent, comme la version ou la date de release. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Contrôle d'accès basé sur les rôles description: Traite de la création et du formatage des ressources RBAC dans les manifestes de chart. sidebar_position: 8 --- Cette partie du guide des bonnes pratiques traite de la création et du formatage des ressources RBAC dans les manifestes de chart. Les ressources RBAC sont : - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## Configuration YAML La configuration de RBAC et de ServiceAccount doit se faire sous des clés séparées. Ce sont des concepts distincts. Les séparer dans le YAML permet de les distinguer clairement. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` Cette structure peut être étendue pour des charts plus complexes nécessitant plusieurs ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Les ressources RBAC doivent être créées par défaut `rbac.create` doit être une valeur booléenne contrôlant si les ressources RBAC sont créées. La valeur par défaut doit être `true`. Les utilisateurs qui souhaitent gérer eux-mêmes les contrôles d'accès RBAC peuvent définir cette valeur à `false` (dans ce cas, voir ci-dessous). ## Utilisation des ressources RBAC `serviceAccount.name` doit être défini avec le nom du ServiceAccount à utiliser par les ressources soumises au contrôle d'accès créées par le chart. - Si `serviceAccount.create` est true, un ServiceAccount avec ce nom doit être créé. - Si le nom n'est pas défini, un nom est généré en utilisant le template `fullname`. - Si `serviceAccount.create` est false, le ServiceAccount ne doit pas être créé, mais il doit tout de même être associé aux mêmes ressources afin que les ressources RBAC créées manuellement ultérieurement fonctionnent correctement. - Si `serviceAccount.create` est false et que le nom n'est pas spécifié, le ServiceAccount par défaut est utilisé. Le helper template suivant doit être utilisé pour le ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Templates description: Un examen approfondi des bonnes pratiques concernant les templates. sidebar_position: 3 --- Cette partie du guide des bonnes pratiques se concentre sur les templates. ## Structure de `templates/` Le répertoire `templates/` doit être structuré comme suit : - Les fichiers template doivent avoir l'extension `.yaml` s'ils produisent une sortie YAML. L'extension `.tpl` peut être utilisée pour les fichiers template qui ne produisent pas de contenu formaté. - Les noms de fichiers template doivent utiliser la notation avec tirets (`my-example-configmap.yaml`), et non le camelCase. - Chaque définition de ressource doit être dans son propre fichier template. - Les noms de fichiers template doivent refléter le type de ressource dans le nom. Par exemple : `foo-pod.yaml`, `bar-svc.yaml` ## Noms des templates définis Les templates définis (templates créés à l'intérieur d'une directive `{{ define }}`) sont globalement accessibles. Cela signifie qu'un chart et tous ses sous-charts auront accès à tous les templates créés avec `{{ define }}`. Pour cette raison, _tous les noms de templates définis doivent être préfixés par un espace de noms._ Correct : ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorrect : ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Il est fortement recommandé de créer de nouveaux charts via la commande `helm create` car les noms de templates sont automatiquement définis selon cette bonne pratique. ## Formatage des templates Les templates doivent être indentés avec _deux espaces_ (jamais des tabulations). Les directives de template doivent avoir un espace après les accolades ouvrantes et avant les accolades fermantes : Correct : ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorrect : ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Les templates doivent supprimer les espaces blancs lorsque c'est possible : ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Les blocs (tels que les structures de contrôle) peuvent être indentés pour indiquer le flux du code template. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Cependant, comme YAML est un langage orienté espaces blancs, il n'est souvent pas possible pour l'indentation du code de suivre cette convention. ## Espaces blancs dans les templates générés Il est préférable de limiter la quantité d'espaces blancs dans les templates générés au minimum. En particulier, de nombreuses lignes vides ne doivent pas apparaître les unes à côté des autres. Cependant, des lignes vides occasionnelles (en particulier entre les sections logiques) sont acceptables. Ceci est idéal : ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Ceci est acceptable : ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Mais ceci doit être évité : ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Commentaires (Commentaires YAML vs. Commentaires de template) YAML et les templates Helm disposent tous deux de marqueurs de commentaires. Commentaires YAML : ```yaml # Ceci est un commentaire type: sprocket ``` Commentaires de template : ```yaml {{- /* Ceci est un commentaire. */}} type: frobnitz ``` Les commentaires de template doivent être utilisés pour documenter les fonctionnalités d'un template, comme expliquer un template défini : ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` À l'intérieur des templates, les commentaires YAML peuvent être utilisés lorsqu'il est utile que les utilisateurs Helm puissent (éventuellement) voir les commentaires lors du débogage. ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` Le commentaire ci-dessus est visible lorsque l'utilisateur exécute `helm install --debug`, tandis que les commentaires spécifiés dans les sections `{{- /* */}}` ne le sont pas. Faites attention lors de l'ajout de commentaires YAML `#` sur des sections de template contenant des valeurs Helm qui peuvent être requises par certaines fonctions de template. Par exemple, si la fonction `required` est introduite dans l'exemple ci-dessus, et que `maxMem` n'est pas défini, alors un commentaire YAML `#` provoquera une erreur de rendu. Correct : `helm template` ne rend pas ce bloc ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Incorrect : `helm template` retourne `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Consultez [Débogage des templates](../chart_template_guide/debugging.md) pour un autre exemple de ce comportement où les commentaires YAML sont conservés tels quels. ## Utilisation de JSON dans les templates et la sortie des templates YAML est un sur-ensemble de JSON. Dans certains cas, utiliser une syntaxe JSON peut être plus lisible que d'autres représentations YAML. Par exemple, ce YAML est plus proche de la méthode YAML normale pour exprimer des listes : ```yaml arguments: - "--dirname" - "/foo" ``` Mais il est plus facile à lire lorsqu'il est condensé dans un style de liste JSON : ```yaml arguments: ["--dirname", "/foo"] ``` Utiliser JSON pour améliorer la lisibilité est une bonne pratique. Cependant, la syntaxe JSON ne doit pas être utilisée pour représenter des constructions plus complexes. Lorsque vous travaillez avec du JSON pur intégré dans du YAML (comme la configuration de conteneur init), il est bien sûr approprié d'utiliser le format JSON. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Se concentre sur la façon de structurer et d'utiliser vos values. sidebar_position: 2 --- Cette partie du guide des bonnes pratiques couvre l'utilisation des values. Dans cette section, nous fournissons des recommandations sur la façon de structurer et d'utiliser vos values, en mettant l'accent sur la conception du fichier `values.yaml` d'un chart. ## Conventions de nommage Les noms de variables doivent commencer par une lettre minuscule, et les mots doivent être séparés en camelCase : Correct : ```yaml chicken: true chickenNoodleSoup: true ``` Incorrect : ```yaml Chicken: true # les majuscules initiales peuvent entrer en conflit avec les variables intégrées chicken-noodle-soup: true # n'utilisez pas de tirets dans le nom ``` Notez que toutes les variables intégrées de Helm commencent par une lettre majuscule pour les distinguer facilement des valeurs définies par l'utilisateur : `.Release.Name`, `.Capabilities.KubeVersion`. ## Values plates ou imbriquées YAML est un format flexible, et les values peuvent être profondément imbriquées ou aplaties. Imbriquées : ```yaml server: name: nginx port: 80 ``` Plates : ```yaml serverName: nginx serverPort: 80 ``` Dans la plupart des cas, les values plates sont préférables aux values imbriquées. La raison est que c'est plus simple pour les développeurs de templates et les utilisateurs. Pour une sécurité optimale, une value imbriquée doit être vérifiée à chaque niveau : ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Pour chaque niveau d'imbrication, une vérification d'existence doit être effectuée. Mais pour une configuration plate, ces vérifications peuvent être ignorées, rendant le template plus facile à lire et à utiliser. ``` {{ default "none" .Values.serverName }} ``` Lorsqu'il y a un grand nombre de variables liées, et qu'au moins l'une d'entre elles est obligatoire, les values imbriquées peuvent être utilisées pour améliorer la lisibilité. ## Rendre les types explicites Les règles de conversion de type de YAML sont parfois contre-intuitives. Par exemple, `foo: false` n'est pas la même chose que `foo: "false"`. Les grands entiers comme `foo: 12345678` seront convertis en notation scientifique dans certains cas. La façon la plus simple d'éviter les erreurs de conversion de type est d'être explicite avec les chaînes de caractères, et implicite avec tout le reste. Autrement dit, _mettez toutes les chaînes entre guillemets_. Souvent, pour éviter les problèmes de conversion d'entiers, il est avantageux de stocker vos entiers sous forme de chaînes également, et d'utiliser `{{ int $value }}` dans le template pour convertir une chaîne en entier. Dans la plupart des cas, les balises de type explicites sont respectées, donc `foo: !!string 1234` devrait traiter `1234` comme une chaîne. _Cependant_, le parseur YAML consomme les balises, donc les données de type sont perdues après un premier parsing. ## Considérez comment les utilisateurs utiliseront vos values Il existe trois sources potentielles de values : - Le fichier `values.yaml` d'un chart - Un fichier de values fourni par `helm install -f` ou `helm upgrade -f` - Les values passées via les options `--set` ou `--set-string` de `helm install` ou `helm upgrade` Lors de la conception de la structure de vos values, gardez à l'esprit que les utilisateurs de votre chart peuvent vouloir les remplacer soit via l'option `-f`, soit avec l'option `--set`. Étant donné que `--set` est plus limité en termes d'expressivité, la première règle pour écrire votre fichier `values.yaml` est de _le rendre facile à remplacer avec `--set`_. Pour cette raison, il est souvent préférable de structurer votre fichier de values en utilisant des maps. Difficile à utiliser avec `--set` : ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` L'exemple ci-dessus ne peut pas être exprimé avec `--set` dans Helm `<=2.4`. Dans Helm 2.5, accéder au port de foo se fait avec `--set servers[0].port=80`. Non seulement c'est plus difficile à comprendre pour l'utilisateur, mais cela est aussi sujet aux erreurs si l'ordre des `servers` est modifié ultérieurement. Facile à utiliser : ```yaml servers: foo: port: 80 bar: port: 81 ``` Accéder au port de foo est beaucoup plus évident : `--set servers.foo.port=80`. ## Documenter `values.yaml` Chaque propriété définie dans `values.yaml` devrait être documentée. La chaîne de documentation devrait commencer par le nom de la propriété qu'elle décrit, puis donner au moins une phrase de description. Incorrect : ```yaml # le nom d'hôte du serveur web serverHost: example serverPort: 9191 ``` Correct : ```yaml # serverHost est le nom d'hôte du serveur web serverHost: example # serverPort est le port d'écoute HTTP du serveur web serverPort: 9191 ``` Commencer chaque commentaire par le nom du paramètre qu'il documente facilite l'extraction de la documentation avec grep, et permettra aux outils de documentation de corréler de manière fiable les chaînes de documentation avec les paramètres qu'elles décrivent. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Accéder aux fichiers dans les templates description: Comment accéder aux fichiers depuis un template. sidebar_position: 10 --- Dans la section précédente, nous avons examiné plusieurs façons de créer et d'accéder à des templates nommés. Cela facilite l'importation d'un template depuis un autre template. Mais parfois, il est souhaitable d'importer un _fichier qui n'est pas un template_ et d'injecter son contenu sans le faire passer par le moteur de rendu de templates. Helm permet d'accéder aux fichiers via l'objet `.Files`. Avant de passer aux exemples de templates, voici quelques points importants à noter sur son fonctionnement : - Vous pouvez ajouter des fichiers supplémentaires à votre chart Helm. Ces fichiers seront inclus dans le package. Attention toutefois : les charts doivent faire moins de 1 Mo en raison des limitations de stockage des objets Kubernetes. - Certains fichiers ne sont pas accessibles via l'objet `.Files`, généralement pour des raisons de sécurité. - Les fichiers dans `templates/` ne sont pas accessibles. - Les fichiers exclus via `.helmignore` ne sont pas accessibles. - Les fichiers situés en dehors d'un [sous-chart](/chart_template_guide/subcharts_and_globals.md) de l'application Helm, y compris ceux du chart parent, ne sont pas accessibles. - Les charts ne préservent pas les informations de mode UNIX, donc les permissions au niveau des fichiers n'auront aucun impact sur la disponibilité d'un fichier via l'objet `.Files`. - [Exemple de base](#exemple-de-base) - [Fonctions d'aide pour les chemins](#fonctions-daide-pour-les-chemins) - [Motifs glob](#motifs-glob) - [Fonctions utilitaires pour ConfigMap et Secrets](#fonctions-utilitaires-pour-configmap-et-secrets) - [Encodage](#encodage) - [Lignes](#lignes) ## Exemple de base Ces points clarifiés, écrivons un template qui lit trois fichiers dans notre ConfigMap. Pour commencer, nous allons ajouter trois fichiers au chart, en les plaçant tous directement dans le répertoire `mychart/`. `config1.toml` : ```toml message = "Hello from config 1" ``` `config2.toml` : ```toml message = "This is config 2" ``` `config3.toml` : ```toml message = "Goodbye from config 3" ``` Chacun de ces fichiers est un simple fichier TOML (pensez aux anciens fichiers INI de Windows). Nous connaissons les noms de ces fichiers, nous pouvons donc utiliser une fonction `range` pour les parcourir et injecter leur contenu dans notre ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Ce ConfigMap utilise plusieurs des techniques abordées dans les sections précédentes. Par exemple, nous créons une variable `$files` pour conserver une référence à l'objet `.Files`. Nous utilisons également la fonction `tuple` pour créer une liste de fichiers que nous parcourons. Ensuite, nous affichons le nom de chaque fichier (`{{ . }}: |-`) suivi du contenu du fichier `{{ $files.Get . }}`. L'exécution de ce template produira un seul ConfigMap contenant le contenu des trois fichiers : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Fonctions d'aide pour les chemins Lorsque vous travaillez avec des fichiers, il peut être très utile d'effectuer des opérations standard sur les chemins de fichiers eux-mêmes. Pour vous aider, Helm importe de nombreuses fonctions du package [path](https://golang.org/pkg/path/) de Go. Elles sont toutes accessibles avec les mêmes noms que dans le package Go, mais avec une première lettre en minuscule. Par exemple, `Base` devient `base`, etc. Les fonctions importées sont : - Base - Dir - Ext - IsAbs - Clean ## Motifs glob À mesure que votre chart grandit, vous pourriez avoir besoin d'organiser davantage vos fichiers. Nous fournissons donc une méthode `Files.Glob(pattern string)` pour vous aider à extraire certains fichiers avec toute la flexibilité des [motifs glob](https://godoc.org/github.com/gobwas/glob). `.Glob` retourne un type `Files`, vous pouvez donc appeler n'importe quelle méthode de `Files` sur l'objet retourné. Par exemple, imaginez la structure de répertoires suivante : ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Vous avez plusieurs options avec les Globs : ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Ou ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Fonctions utilitaires pour ConfigMap et Secrets (Disponible depuis Helm 2.0.2) Il est très courant de vouloir placer le contenu de fichiers dans des ConfigMaps et des Secrets, pour les monter dans vos pods au moment de l'exécution. Pour vous aider, nous fournissons quelques méthodes utilitaires sur le type `Files`. Pour une meilleure organisation, il est particulièrement utile d'utiliser ces méthodes en conjonction avec la méthode `Glob`. Avec la structure de répertoires de l'exemple [Glob](#motifs-glob) ci-dessus : ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Encodage Vous pouvez importer un fichier et demander au template de l'encoder en base64 pour garantir une transmission réussie : ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Le code ci-dessus prendra le même fichier `config1.toml` utilisé précédemment et l'encodera : ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Lignes Parfois, il est souhaitable d'accéder à chaque ligne d'un fichier dans votre template. Nous fournissons une méthode `Lines` pratique pour cela. Vous pouvez parcourir `Lines` en utilisant une fonction `range` : ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Il n'est pas possible de passer des fichiers externes au chart lors de `helm install`. Donc, si vous demandez aux utilisateurs de fournir des données, celles-ci doivent être chargées en utilisant `helm install -f` ou `helm install --set`. Cette discussion conclut notre exploration des outils et techniques pour écrire des templates Helm. Dans la prochaine section, nous verrons comment utiliser un fichier spécial, `templates/NOTES.txt`, pour envoyer des instructions post-installation aux utilisateurs de votre chart. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Objets intégrés description: Les objets intégrés disponibles dans les templates. sidebar_position: 3 --- Les objets sont passés dans un template par le moteur de template. Votre code peut également transmettre des objets (nous verrons des exemples lorsque nous examinerons les instructions `with` et `range`). Il existe même plusieurs façons de créer de nouveaux objets dans vos templates, comme avec la fonction `tuple` que nous verrons plus tard. Les objets peuvent être simples et n'avoir qu'une seule valeur. Ou ils peuvent contenir d'autres objets ou fonctions. Par exemple, l'objet `Release` contient plusieurs objets (comme `Release.Name`) et l'objet `Files` possède quelques fonctions. Dans la section précédente, nous avons utilisé `{{ .Release.Name }}` pour insérer le nom d'une release dans un template. `Release` est l'un des objets de premier niveau auxquels vous pouvez accéder dans vos templates. - `Release` : Cet objet décrit la release elle-même. Il contient plusieurs objets : - `Release.Name` : Le nom de la release - `Release.Namespace` : Le namespace dans lequel la release sera déployée (si le manifeste ne le remplace pas) - `Release.IsUpgrade` : Cette valeur est définie à `true` si l'opération en cours est une mise à niveau ou un rollback. - `Release.IsInstall` : Cette valeur est définie à `true` si l'opération en cours est une installation. - `Release.Revision` : Le numéro de révision pour cette release. Lors de l'installation, cette valeur est 1, et elle est incrémentée à chaque mise à niveau et rollback. - `Release.Service` : Le service qui effectue le rendu du template actuel. Dans Helm, c'est toujours `Helm`. - `Values` : Les valeurs passées dans le template depuis le fichier `values.yaml` et depuis les fichiers fournis par l'utilisateur. Par défaut, `Values` est vide. - `Chart` : Le contenu du fichier `Chart.yaml`. Toutes les données de `Chart.yaml` seront accessibles ici. Par exemple, `{{ .Chart.Name }}-{{ .Chart.Version }}` affichera `mychart-0.1.0`. - Les champs disponibles sont listés dans le [Guide des Charts](/topics/charts.md#the-chartyaml-file) - `Subcharts` : Cet objet donne accès à la portée (`.Values`, `.Charts`, `.Releases`, etc.) des sous-charts depuis le chart parent. Par exemple, `.Subcharts.mySubChart.myValue` pour accéder à `myValue` dans le chart `mySubChart`. - `Files` : Cet objet donne accès à tous les fichiers non spéciaux dans un chart. Bien que vous ne puissiez pas l'utiliser pour accéder aux templates, vous pouvez l'utiliser pour accéder aux autres fichiers du chart. Consultez la section [Accès aux fichiers](/chart_template_guide/accessing_files.md) pour plus de détails. - `Files.Get` est une fonction pour obtenir un fichier par son nom (`.Files.Get config.ini`) - `Files.GetBytes` est une fonction pour obtenir le contenu d'un fichier sous forme de tableau d'octets au lieu d'une chaîne de caractères. Ceci est utile pour des éléments comme les images. - `Files.Glob` est une fonction qui retourne une liste de fichiers dont les noms correspondent au motif glob donné. - `Files.Lines` est une fonction qui lit un fichier ligne par ligne. Utile pour itérer sur chaque ligne d'un fichier. - `Files.AsSecrets` est une fonction qui retourne le contenu des fichiers encodé en Base 64. - `Files.AsConfig` est une fonction qui retourne le contenu des fichiers sous forme de map YAML. - `Capabilities` : Cet objet fournit des informations sur les fonctionnalités prises en charge par le cluster Kubernetes. - `Capabilities.APIVersions` est un ensemble de versions. - `Capabilities.APIVersions.Has $version` indique si une version (par exemple, `batch/v1`) ou une ressource (par exemple, `apps/v1/Deployment`) est disponible sur le cluster. - `Capabilities.KubeVersion` et `Capabilities.KubeVersion.Version` représentent la version de Kubernetes. - `Capabilities.KubeVersion.Major` est la version majeure de Kubernetes. - `Capabilities.KubeVersion.Minor` est la version mineure de Kubernetes. - `Capabilities.HelmVersion` est l'objet contenant les détails de la version de Helm, c'est la même sortie que `helm version`. - `Capabilities.HelmVersion.Version` est la version actuelle de Helm au format semver. - `Capabilities.HelmVersion.GitCommit` est le sha1 git de Helm. - `Capabilities.HelmVersion.GitTreeState` est l'état de l'arborescence git de Helm. - `Capabilities.HelmVersion.GoVersion` est la version du compilateur Go utilisé. - `Template` : Contient des informations sur le template en cours d'exécution - `Template.Name` : Le chemin qualifié vers le template actuel (par exemple, `mychart/templates/mytemplate.yaml`) - `Template.BasePath` : Le chemin qualifié vers le répertoire templates du chart actuel (par exemple, `mychart/templates`). Les valeurs intégrées commencent toujours par une majuscule. Ceci est conforme à la convention de nommage de Go. Lorsque vous créez vos propres noms, vous êtes libre d'utiliser la convention qui convient à votre équipe. Certaines équipes, comme celles dont vous pouvez voir les charts sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choisissent d'utiliser uniquement des minuscules en première lettre afin de distinguer les noms locaux de ceux qui sont intégrés. Dans ce guide, nous suivons cette convention. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Structures de contrôle description: Un aperçu rapide des structures de contrôle dans les templates. sidebar_position: 7 --- Les structures de contrôle (appelées « actions » dans le jargon des templates) vous permettent, en tant qu'auteur de template, de contrôler le flux de génération d'un template. Le langage de template de Helm fournit les structures de contrôle suivantes : - `if`/`else` pour créer des blocs conditionnels - `with` pour spécifier une portée - `range`, qui fournit une boucle de type « for each » En plus de celles-ci, il fournit quelques actions pour déclarer et utiliser des segments de templates nommés : - `define` déclare un nouveau template nommé à l'intérieur de votre template - `template` importe un template nommé - `block` déclare un type spécial de zone de template remplissable Dans cette section, nous parlerons de `if`, `with` et `range`. Les autres sont couverts dans la section « Templates nommés » plus loin dans ce guide. ## If/Else La première structure de contrôle que nous allons examiner sert à inclure conditionnellement des blocs de texte dans un template. Il s'agit du bloc `if`/`else`. La structure de base d'une condition ressemble à ceci : ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Remarquez que nous parlons maintenant de _pipelines_ plutôt que de valeurs. Cela permet de clarifier que les structures de contrôle peuvent exécuter un pipeline entier, pas seulement évaluer une valeur. Un pipeline est évalué comme _false_ si la valeur est : - un booléen false - un zéro numérique - une chaîne vide - un `nil` (vide ou null) - une collection vide (`map`, `slice`, `tuple`, `dict`, `array`) Dans toutes les autres conditions, la condition est vraie. Ajoutons une condition simple à notre ConfigMap. Nous ajouterons un autre paramètre si la boisson est définie sur coffee : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Puisque nous avons commenté `drink: coffee` dans notre dernier exemple, la sortie ne devrait pas inclure un indicateur `mug: "true"`. Mais si nous ajoutons cette ligne dans notre fichier `values.yaml`, la sortie devrait ressembler à ceci : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Contrôle des espaces blancs En examinant les conditions, nous devrions jeter un coup d'œil rapide à la façon dont les espaces blancs sont contrôlés dans les templates. Prenons l'exemple précédent et formatons-le pour le rendre plus lisible : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Initialement, cela semble correct. Mais si nous l'exécutons via le moteur de template, nous obtiendrons un résultat malheureux : ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Que s'est-il passé ? Nous avons généré du YAML incorrect à cause des espaces blancs ci-dessus. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` est mal indenté. Réduisons l'indentation de cette ligne et relançons : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Lorsque nous envoyons cela, nous obtiendrons du YAML valide, mais qui a toujours l'air un peu étrange : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Remarquez que nous avons reçu quelques lignes vides dans notre YAML. Pourquoi ? Lorsque le moteur de template s'exécute, il _supprime_ le contenu à l'intérieur de `{{` et `}}`, mais il laisse les espaces blancs restants exactement tels quels. YAML attribue une signification aux espaces blancs, donc la gestion des espaces blancs devient assez importante. Heureusement, les templates Helm ont quelques outils pour aider. Premièrement, la syntaxe des accolades des déclarations de template peut être modifiée avec des caractères spéciaux pour indiquer au moteur de template de supprimer les espaces blancs. `{{- ` (avec le tiret et l'espace ajoutés) indique que les espaces blancs à gauche doivent être supprimés, tandis que ` -}}` signifie que les espaces blancs à droite doivent être consommés. _Attention ! Les retours à la ligne sont des espaces blancs !_ > Assurez-vous qu'il y a un espace entre le `-` et le reste de votre directive. > `{{- 3 }}` signifie « supprimer les espaces blancs à gauche et afficher 3 » tandis que `{{-3 }}` signifie « afficher -3 ». En utilisant cette syntaxe, nous pouvons modifier notre template pour nous débarrasser de ces nouvelles lignes : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Juste pour clarifier ce point, ajustons ce qui précède et substituons un `*` pour chaque espace blanc qui sera supprimé selon cette règle. Un `*` à la fin de la ligne indique un caractère de nouvelle ligne qui serait supprimé ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` En gardant cela à l'esprit, nous pouvons exécuter notre template via Helm et voir le résultat : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Soyez prudent avec les modificateurs de suppression. Il est facile de faire accidentellement des choses comme ceci : ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Cela produira `food: "PIZZA"mug: "true"` car cela a consommé les nouvelles lignes des deux côtés. > Pour les détails sur le contrôle des espaces blancs dans les templates, consultez la [documentation officielle de Go template](https://godoc.org/text/template) Enfin, il est parfois plus facile d'indiquer au système de template comment indenter pour vous au lieu d'essayer de maîtriser l'espacement des directives de template. Pour cette raison, vous pouvez parfois trouver utile d'utiliser la fonction `indent` (`{{ indent 2 "mug:true" }}`). ## Modification de la portée avec `with` La prochaine structure de contrôle à examiner est l'action `with`. Elle contrôle la portée des variables. Rappelez-vous que `.` est une référence à _la portée actuelle_. Ainsi, `.Values` indique au template de trouver l'objet `Values` dans la portée actuelle. La syntaxe de `with` est similaire à une simple instruction `if` : ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Les portées peuvent être modifiées. `with` peut vous permettre de définir la portée actuelle (`.`) sur un objet particulier. Par exemple, nous avons travaillé avec `.Values.favorite`. Réécrivons notre ConfigMap pour modifier la portée de `.` afin qu'elle pointe vers `.Values.favorite` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Notez que nous avons supprimé la condition `if` de l'exercice précédent car elle n'est plus nécessaire - le bloc après `with` ne s'exécute que si la valeur du `PIPELINE` n'est pas vide. Remarquez que nous pouvons maintenant référencer `.drink` et `.food` sans les qualifier. C'est parce que l'instruction `with` définit `.` pour pointer vers `.Values.favorite`. Le `.` est réinitialisé à sa portée précédente après `{{ end }}`. Mais voici une mise en garde ! À l'intérieur de la portée restreinte, vous ne pourrez pas accéder aux autres objets de la portée parente en utilisant `.`. Ceci, par exemple, échouera : ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Cela produira une erreur car `Release.Name` n'est pas à l'intérieur de la portée restreinte pour `.`. Cependant, si nous échangeons les deux dernières lignes, tout fonctionnera comme prévu car la portée est réinitialisée après `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Ou, nous pouvons utiliser `$` pour accéder à l'objet `Release.Name` depuis la portée parente. `$` est mappé à la portée racine lorsque l'exécution du template commence et ne change pas pendant l'exécution du template. Ce qui suit fonctionnerait également : ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Après avoir examiné `range`, nous examinerons les variables de template, qui offrent une solution au problème de portée ci-dessus. ## Boucle avec l'action `range` De nombreux langages de programmation prennent en charge les boucles utilisant des boucles `for`, des boucles `foreach` ou des mécanismes fonctionnels similaires. Dans le langage de template de Helm, la façon d'itérer sur une collection est d'utiliser l'opérateur `range`. Pour commencer, ajoutons une liste de garnitures de pizza à notre fichier `values.yaml` : ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Maintenant, nous avons une liste (appelée `slice` dans les templates) de `pizzaToppings`. Nous pouvons modifier notre template pour imprimer cette liste dans notre ConfigMap : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Nous pouvons utiliser `$` pour accéder à la liste `Values.pizzaToppings` depuis la portée parente. `$` est mappé à la portée racine lorsque l'exécution du template commence et ne change pas pendant l'exécution du template. Ce qui suit fonctionnerait également : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Examinons de plus près la liste `toppings:`. La fonction `range` va « parcourir » (itérer sur) la liste `pizzaToppings`. Mais maintenant, quelque chose d'intéressant se produit. Tout comme `with` définit la portée de `.`, l'opérateur `range` fait de même. À chaque passage dans la boucle, `.` est défini sur la garniture de pizza actuelle. C'est-à-dire, la première fois, `.` est défini sur `mushrooms`. La deuxième itération, il est défini sur `cheese`, et ainsi de suite. Nous pouvons envoyer la valeur de `.` directement dans un pipeline, donc quand nous faisons `{{ . | title | quote }}`, cela envoie `.` à `title` (fonction de mise en majuscule des titres) puis à `quote`. Si nous exécutons ce template, la sortie sera : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Maintenant, dans cet exemple, nous avons fait quelque chose d'astucieux. La ligne `toppings: |-` déclare une chaîne multi-lignes. Donc notre liste de garnitures n'est en fait pas une liste YAML. C'est une grande chaîne. Pourquoi ferions-nous cela ? Parce que les données dans `data` d'un ConfigMap sont composées de paires clé/valeur, où la clé et la valeur sont des chaînes simples. Pour comprendre pourquoi c'est le cas, consultez la [documentation ConfigMap de Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/). Pour nous, cependant, ce détail n'a pas beaucoup d'importance. > Le marqueur `|-` en YAML prend une chaîne multi-lignes. Cela peut être une technique utile pour intégrer de gros blocs de données dans vos manifests, comme illustré ici. Parfois, il est utile de pouvoir créer rapidement une liste à l'intérieur de votre template, puis d'itérer sur cette liste. Les templates Helm ont une fonction pour faciliter cela : `tuple`. En informatique, un tuple est une collection de type liste de taille fixe, mais avec des types de données arbitraires. Cela traduit approximativement la façon dont un `tuple` est utilisé. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Ce qui précède produira ceci : ```yaml sizes: |- - small - medium - large ``` En plus des listes et des tuples, `range` peut être utilisé pour itérer sur des collections qui ont une clé et une valeur (comme un `map` ou `dict`). Nous verrons comment faire cela dans la prochaine section lorsque nous introduirons les variables de template. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Annexe : Types de données Go et Templates" description: Un bref aperçu des variables dans les templates. sidebar_position: 16 --- Le langage de template Helm est implémenté dans le langage de programmation Go, qui est fortement typé. Pour cette raison, les variables dans les templates sont _typées_. Généralement, les variables seront exposées comme l'un des types suivants : - string : une chaîne de texte - bool : un `true` ou `false` - int : une valeur entière (il existe également des variantes signées et non signées sur 8, 16, 32 et 64 bits) - float64 : une valeur à virgule flottante sur 64 bits (il existe également des variantes sur 8, 16 et 32 bits) - un slice d'octets (`[]byte`), souvent utilisé pour stocker des données (potentiellement) binaires - struct : un objet avec des propriétés et des méthodes - un slice (liste indexée) de l'un des types précédents - une map indexée par des chaînes (`map[string]interface{}`) où la valeur est l'un des types précédents Il existe de nombreux autres types en Go, et vous devrez parfois effectuer des conversions entre eux dans vos templates. La façon la plus simple de déboguer le type d'un objet est de le passer à travers `printf "%T"` dans un template, ce qui affichera le type. Consultez également les fonctions `typeOf` et `kindOf`. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Débogage des templates description: Dépannage des charts dont le déploiement échoue. sidebar_position: 13 --- Le débogage des templates peut être délicat, car les templates rendus sont envoyés au serveur d'API Kubernetes, qui peut rejeter les fichiers YAML pour des raisons autres que le formatage. Voici quelques commandes utiles pour le débogage. - `helm lint` est votre outil de référence pour vérifier que votre chart respecte les bonnes pratiques - `helm template --debug` permet de tester le rendu des templates de chart localement. - `helm install --dry-run --debug` effectue également le rendu de votre chart localement sans l'installer, mais vérifie aussi si des ressources en conflit sont déjà en cours d'exécution sur le cluster. L'option `--dry-run=server` permet en plus d'exécuter toute fonction `lookup` de votre chart vers le serveur. - `helm get manifest` : C'est un bon moyen de voir quels templates sont installés sur le serveur. Lorsque votre fichier YAML ne parvient pas à être analysé, mais que vous souhaitez voir ce qui est généré, un moyen simple de récupérer le YAML est de commenter la section problématique dans le template, puis de relancer `helm install --dry-run --debug` : ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` Le code ci-dessus sera rendu et retourné avec les commentaires intacts : ```yaml apiVersion: v2 # some: problem section # "bar" ``` Cela permet de visualiser rapidement le contenu généré sans être bloqué par des erreurs d'analyse YAML. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Liste des fonctions de template description: Une liste des fonctions de template disponibles dans Helm sidebar_position: 6 --- Helm inclut de nombreuses fonctions de template que vous pouvez utiliser dans vos templates. Elles sont répertoriées ici et classées dans les catégories suivantes : * [Fonctions cryptographiques et de sécurité](#fonctions-cryptographiques-et-de-sécurité) * [Date](#fonctions-de-date) * [Dictionnaires](#dictionnaires-et-fonctions-dict) * [Encodage](#fonctions-dencodage) * [Chemins de fichiers](#fonctions-de-chemin-de-fichier) * [Kubernetes et Chart](#fonctions-kubernetes-et-chart) * [Logique et contrôle de flux](#fonctions-de-logique-et-de-contrôle-de-flux) * [Listes](#listes-et-fonctions-de-liste) * [Mathématiques](#fonctions-mathématiques) * [Mathématiques à virgule flottante](#fonctions-mathématiques-à-virgule-flottante) * [Réseau](#fonctions-réseau) * [Réflexion](#fonctions-de-réflexion) * [Expressions régulières](#expressions-régulières) * [Versions sémantiques](#fonctions-de-version-sémantique) * [Chaînes de caractères](#fonctions-de-chaînes-de-caractères) * [Conversion de types](#fonctions-de-conversion-de-types) * [URL](#fonctions-url) * [UUID](#fonctions-uuid) ## Fonctions de logique et de contrôle de flux Helm inclut de nombreuses fonctions de logique et de contrôle de flux, notamment [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), et [required](#required). ### and Retourne le ET logique de deux arguments ou plus (le premier argument vide, ou le dernier argument). ``` and .Arg1 .Arg2 ``` ### or Retourne le OU logique de deux arguments ou plus (le premier argument non vide, ou le dernier argument). ``` or .Arg1 .Arg2 ``` ### not Retourne la négation logique de son argument. ``` not .Arg ``` ### eq Retourne l'égalité booléenne des arguments (par exemple, Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Retourne l'inégalité booléenne des arguments (par exemple, Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Retourne vrai si le premier argument est inférieur au second. Retourne faux sinon (par exemple, Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Retourne vrai si le premier argument est inférieur ou égal au second. Retourne faux sinon (par exemple, Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Retourne vrai si le premier argument est supérieur au second. Retourne faux sinon (par exemple, Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Retourne vrai si le premier argument est supérieur ou égal au second. Retourne faux sinon (par exemple, Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default Pour définir une valeur par défaut simple, utilisez `default` : ``` default "foo" .Bar ``` Dans l'exemple ci-dessus, si `.Bar` s'évalue à une valeur non vide, elle sera utilisée. Sinon, `foo` sera retourné à la place. La définition de « vide » dépend du type : - Numérique : 0 - Chaîne : "" - Listes : `[]` - Dicts : `{}` - Booléen : `false` - Et toujours `nil` (aka null) Pour les structures, il n'y a pas de définition de vide, donc une structure ne retournera jamais la valeur par défaut. ### required Spécifiez les valeurs qui doivent être définies avec `required` : ``` required "A valid foo is required!" .Bar ``` Si `.Bar` est vide ou non défini (voir [default](#default) pour savoir comment cela est évalué), le template ne sera pas rendu et retournera le message d'erreur fourni à la place. ### empty La fonction `empty` retourne `true` si la valeur donnée est considérée comme vide, et `false` sinon. Les valeurs vides sont listées dans la section `default`. ``` empty .Foo ``` Notez que dans les conditionnels des templates Go, le vide est calculé pour vous. Ainsi, vous avez rarement besoin de `if not empty .Foo`. Utilisez simplement `if .Foo`. ### fail Retourne inconditionnellement une chaîne vide (`string`) et une erreur (`error`) avec le texte spécifié. Ceci est utile dans les scénarios où d'autres conditionnels ont déterminé que le rendu du template doit échouer. ``` fail "Please accept the end user license agreement" ``` ### coalesce La fonction `coalesce` prend une liste de valeurs et retourne la première valeur non vide. ``` coalesce 0 1 2 ``` L'exemple ci-dessus retourne `1`. Cette fonction est utile pour parcourir plusieurs variables ou valeurs : ``` coalesce .name .parent.name "Matt" ``` L'exemple ci-dessus vérifiera d'abord si `.name` est vide. Si ce n'est pas le cas, il retournera cette valeur. Si c'est vide, `coalesce` évaluera `.parent.name` pour vérifier s'il est vide. Enfin, si `.name` et `.parent.name` sont tous deux vides, il retournera `Matt`. ### ternary La fonction `ternary` prend deux valeurs et une valeur de test. Si la valeur de test est vraie, la première valeur sera retournée. Si la valeur de test est vide, la seconde valeur sera retournée. Ceci est similaire à l'opérateur ternaire en C et autres langages de programmation. #### Valeur de test vraie ``` ternary "foo" "bar" true ``` ou ``` true | ternary "foo" "bar" ``` L'exemple ci-dessus retourne `"foo"`. #### Valeur de test fausse ``` ternary "foo" "bar" false ``` ou ``` false | ternary "foo" "bar" ``` L'exemple ci-dessus retourne `"bar"`. ## Fonctions de chaînes de caractères Helm inclut les fonctions de chaînes suivantes : [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-et-hassuffix), [hasSuffix](#hasprefix-et-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-et-squote), [randAlpha](#randalphanum-randalpha-randnumeric-et-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-et-randascii), [randAscii](#randalphanum-randalpha-randnumeric-et-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-et-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-et-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), et [wrapWith](#wrapwith). ### print Retourne une chaîne à partir de la combinaison de ses parties. ``` print "Matt has " .Dogs " dogs" ``` Les types qui ne sont pas des chaînes sont convertis en chaînes lorsque c'est possible. Notez que lorsque deux arguments côte à côte ne sont pas des chaînes, un espace est ajouté entre eux. ### println Fonctionne de la même manière que [print](#print) mais ajoute une nouvelle ligne à la fin. ### printf Retourne une chaîne basée sur une chaîne de formatage et les arguments à lui passer dans l'ordre. ``` printf "%s has %d dogs." .Name .NumberDogs ``` Le caractère de substitution à utiliser dépend du type de l'argument passé. Cela inclut : Usage général : * `%v` la valeur dans un format par défaut * lors de l'impression de dicts, le flag plus (%+v) ajoute les noms de champs * `%%` un signe pourcentage littéral ; ne consomme aucune valeur Booléen : * `%t` le mot true ou false Entier : * `%b` base 2 * `%c` le caractère représenté par le point de code Unicode correspondant * `%d` base 10 * `%o` base 8 * `%O` base 8 avec le préfixe 0o * `%q` un caractère littéral entre guillemets simples, échappé de manière sûre * `%x` base 16, avec des lettres minuscules pour a-f * `%X` base 16, avec des lettres majuscules pour A-F * `%U` format Unicode : U+1234 ; identique à "U+%04X" Virgule flottante et constituants complexes : * `%b` notation scientifique décimale avec exposant puissance de deux, par exemple -123456p-78 * `%e` notation scientifique, par exemple -1.234456e+78 * `%E` notation scientifique, par exemple -1.234456E+78 * `%f` virgule décimale sans exposant, par exemple 123.456 * `%F` synonyme de %f * `%g` %e pour les grands exposants, %f sinon. * `%G` %E pour les grands exposants, %F sinon * `%x` notation hexadécimale (avec exposant puissance de deux décimale), par exemple -0x1.23abcp+20 * `%X` notation hexadécimale majuscule, par exemple -0X1.23ABCP+20 Chaîne et slice d'octets (traités de manière équivalente avec ces verbes) : * `%s` les octets non interprétés de la chaîne ou du slice * `%q` une chaîne entre guillemets doubles, échappée de manière sûre * `%x` base 16, minuscules, deux caractères par octet * `%X` base 16, majuscules, deux caractères par octet Slice : * `%p` adresse du 0ème élément en notation base 16, avec 0x en préfixe ### trim La fonction `trim` supprime les espaces blancs des deux côtés d'une chaîne : ``` trim " hello " ``` L'exemple ci-dessus produit `hello` ### trimAll Supprime les caractères donnés de l'avant et de l'arrière d'une chaîne : ``` trimAll "$" "$5.00" ``` L'exemple ci-dessus retourne `5.00` (en tant que chaîne). ### trimPrefix Supprime uniquement le préfixe d'une chaîne : ``` trimPrefix "-" "-hello" ``` L'exemple ci-dessus retourne `hello` ### trimSuffix Supprime uniquement le suffixe d'une chaîne : ``` trimSuffix "-" "hello-" ``` L'exemple ci-dessus retourne `hello` ### lower Convertit toute la chaîne en minuscules : ``` lower "HELLO" ``` L'exemple ci-dessus retourne `hello` ### upper Convertit toute la chaîne en majuscules : ``` upper "hello" ``` L'exemple ci-dessus retourne `HELLO` ### title Convertit en casse titre : ``` title "hello world" ``` L'exemple ci-dessus retourne `Hello World` ### untitle Supprime la casse titre. `untitle "Hello World"` produit `hello world`. ### repeat Répète une chaîne plusieurs fois : ``` repeat 3 "hello" ``` L'exemple ci-dessus retourne `hellohellohello` ### substr Obtient une sous-chaîne d'une chaîne. Cette fonction prend trois paramètres : - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` L'exemple ci-dessus retourne `hello` ### nospace Supprime tous les espaces blancs d'une chaîne. ``` nospace "hello w o r l d" ``` L'exemple ci-dessus retourne `helloworld` ### trunc Tronque une chaîne ``` trunc 5 "hello world" ``` L'exemple ci-dessus produit `hello`. ``` trunc -5 "hello world" ``` L'exemple ci-dessus produit `world`. ### abbrev Tronque une chaîne avec des points de suspension (`...`) Paramètres : - longueur maximale - la chaîne ``` abbrev 5 "hello world" ``` L'exemple ci-dessus retourne `he...`, car la largeur des points de suspension est comptée dans la longueur maximale. ### abbrevboth Abrège des deux côtés : ``` abbrevboth 5 10 "1234 5678 9123" ``` L'exemple ci-dessus produit `...5678...` Cette fonction prend : - décalage gauche - longueur maximale - la chaîne ### initials Étant donné plusieurs mots, prend la première lettre de chaque mot et les combine. ``` initials "First Try" ``` L'exemple ci-dessus retourne `FT` ### randAlphaNum, randAlpha, randNumeric et randAscii Ces quatre fonctions génèrent des chaînes aléatoires cryptographiquement sécurisées (utilisant ```crypto/rand```), mais avec différents jeux de caractères de base : - `randAlphaNum` utilise `0-9a-zA-Z` - `randAlpha` utilise `a-zA-Z` - `randNumeric` utilise `0-9` - `randAscii` utilise tous les caractères ASCII imprimables Chacune d'elles prend un paramètre : la longueur entière de la chaîne. ``` randNumeric 3 ``` L'exemple ci-dessus produira une chaîne aléatoire avec trois chiffres. ### wrap Enveloppe le texte à un nombre de colonnes donné : ``` wrap 80 $someText ``` L'exemple ci-dessus enveloppera la chaîne dans `$someText` à 80 colonnes. ### wrapWith `wrapWith` fonctionne comme `wrap`, mais vous permet de spécifier la chaîne avec laquelle envelopper. (`wrap` utilise `\n`) ``` wrapWith 5 "\t" "Hello World" ``` L'exemple ci-dessus produit `Hello World` (où l'espace blanc est un caractère de tabulation ASCII) ### contains Teste si une chaîne est contenue dans une autre : ``` contains "cat" "catch" ``` L'exemple ci-dessus retourne `true` car `catch` contient `cat`. ### hasPrefix et hasSuffix Les fonctions `hasPrefix` et `hasSuffix` testent si une chaîne a un préfixe ou suffixe donné : ``` hasPrefix "cat" "catch" ``` L'exemple ci-dessus retourne `true` car `catch` a le préfixe `cat`. ### quote et squote Ces fonctions entourent une chaîne de guillemets doubles (`quote`) ou de guillemets simples (`squote`). ### cat La fonction `cat` concatène plusieurs chaînes en une seule, en les séparant par des espaces : ``` cat "hello" "beautiful" "world" ``` L'exemple ci-dessus produit `hello beautiful world` ### indent La fonction `indent` indente chaque ligne d'une chaîne donnée à la largeur d'indentation spécifiée. Ceci est utile lors de l'alignement de chaînes multilignes : ``` indent 4 $lots_of_text ``` L'exemple ci-dessus indentera chaque ligne de texte de 4 caractères d'espace. ### nindent La fonction `nindent` est identique à la fonction indent, mais ajoute une nouvelle ligne au début de la chaîne. ``` nindent 4 $lots_of_text ``` L'exemple ci-dessus indentera chaque ligne de texte de 4 caractères d'espace et ajoutera une nouvelle ligne au début. ### replace Effectue un simple remplacement de chaîne. Cette fonction prend trois arguments : - chaîne à remplacer - chaîne de remplacement - chaîne source ``` "I Am Henry VIII" | replace " " "-" ``` L'exemple ci-dessus produira `I-Am-Henry-VIII` ### plural Pluralise une chaîne. ``` len $fish | plural "one anchovy" "many anchovies" ``` Dans l'exemple ci-dessus, si la longueur de la chaîne est 1, le premier argument sera affiché (`one anchovy`). Sinon, le second argument sera affiché (`many anchovies`). Les arguments sont : - chaîne au singulier - chaîne au pluriel - entier de longueur NOTE : Helm ne prend actuellement pas en charge les langues avec des règles de pluralisation plus complexes. Et `0` est considéré comme un pluriel car la langue anglaise le traite ainsi (`zero anchovies`). ### snakecase Convertit une chaîne de camelCase en snake_case. ``` snakecase "FirstName" ``` L'exemple ci-dessus produira `first_name`. ### camelcase Convertit une chaîne de snake_case en CamelCase ``` camelcase "http_server" ``` L'exemple ci-dessus produira `HttpServer`. ### kebabcase Convertit une chaîne de camelCase en kebab-case. ``` kebabcase "FirstName" ``` L'exemple ci-dessus produira `first-name`. ### swapcase Inverse la casse d'une chaîne en utilisant un algorithme basé sur les mots. Algorithme de conversion : - Les caractères majuscules sont convertis en minuscules - Les caractères en casse titre sont convertis en minuscules - Les caractères minuscules après un espace ou au début sont convertis en casse titre - Les autres caractères minuscules sont convertis en majuscules - Les espaces sont définis par unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` L'exemple ci-dessus produira `tHIS iS a.tEST`. ### shuffle Mélange une chaîne. ``` shuffle "hello" ``` L'exemple ci-dessus mélangera les lettres dans `hello`, produisant peut-être `oelhl`. ## Fonctions de conversion de types Les fonctions de conversion de types suivantes sont fournies par Helm : - `atoi` : Convertit une chaîne en entier. - `float64` : Convertit en `float64`. - `int` : Convertit en `int` à la largeur du système. - `int64` : Convertit en `int64`. - `toDecimal` : Convertit un octal unix en `int64`. - `toString` : Convertit en chaîne. - `toStrings` : Convertit une liste, un slice ou un tableau en une liste de chaînes. - `toJson` (`mustToJson`) : Convertit une liste, un slice, un tableau, un dict ou un objet en JSON. - `toPrettyJson` (`mustToPrettyJson`) : Convertit une liste, un slice, un tableau, un dict ou un objet en JSON indenté. - `toRawJson` (`mustToRawJson`) : Convertit une liste, un slice, un tableau, un dict ou un objet en JSON avec les caractères HTML non échappés. - `fromYaml` : Convertit une chaîne YAML en objet. - `fromJson` : Convertit une chaîne JSON en objet. - `fromJsonArray` : Convertit un tableau JSON en liste. - `toYaml` : Convertit une liste, un slice, un tableau, un dict ou un objet en yaml indenté, peut être utilisé pour copier des morceaux de yaml depuis n'importe quelle source. Cette fonction est équivalente à la fonction GoLang yaml.Marshal, voir la documentation ici : https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty` : Convertit une liste, un slice, un tableau, un dict ou un objet en yaml indenté. Équivalent à `toYaml` mais indentera en plus les listes de 2 espaces. - `toToml` : Convertit une liste, un slice, un tableau, un dict ou un objet en toml, peut être utilisé pour copier des morceaux de toml depuis n'importe quelle source. - `fromYamlArray` : Convertit un tableau YAML en liste. Seule `atoi` nécessite que l'entrée soit d'un type spécifique. Les autres tenteront de convertir depuis n'importe quel type vers le type de destination. Par exemple, `int64` peut convertir des flottants en entiers, et peut également convertir des chaînes en entiers. ### toStrings Étant donné une collection de type liste, produit un slice de chaînes. ``` list 1 2 3 | toStrings ``` L'exemple ci-dessus convertit `1` en `"1"`, `2` en `"2"`, et ainsi de suite, puis les retourne sous forme de liste. ### toDecimal Étant donné une permission octal unix, produit un décimal. ``` "0777" | toDecimal ``` L'exemple ci-dessus convertit `0777` en `511` et retourne la valeur en tant qu'int64. ### toJson, mustToJson La fonction `toJson` encode un élément en chaîne JSON. Si l'élément ne peut pas être converti en JSON, la fonction retournera une chaîne vide. `mustToJson` retournera une erreur si l'élément ne peut pas être encodé en JSON. ``` toJson .Item ``` L'exemple ci-dessus retourne la représentation en chaîne JSON de `.Item`. ### toPrettyJson, mustToPrettyJson La fonction `toPrettyJson` encode un élément en chaîne JSON formatée (indentée). ``` toPrettyJson .Item ``` L'exemple ci-dessus retourne la représentation en chaîne JSON indentée de `.Item`. ### toRawJson, mustToRawJson La fonction `toRawJson` encode un élément en chaîne JSON avec les caractères HTML non échappés. ``` toRawJson .Item ``` L'exemple ci-dessus retourne la représentation en chaîne JSON non échappée de `.Item`. ### fromYaml La fonction `fromYaml` prend une chaîne YAML et retourne un objet qui peut être utilisé dans les templates. `Fichier à : yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson La fonction `fromJson` prend une chaîne JSON et retourne un objet qui peut être utilisé dans les templates. `Fichier à : jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray La fonction `fromJsonArray` prend un tableau JSON et retourne une liste qui peut être utilisée dans les templates. `Fichier à : jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty Les fonctions `toYaml` et `toYamlPretty` encodent un objet (liste, slice, tableau, dict ou objet) en une chaîne YAML indentée. > Notez que `toYamlPretty` est fonctionnellement équivalent mais produira du YAML avec une indentation supplémentaire pour les éléments de liste ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray La fonction `fromYamlArray` prend un tableau YAML et retourne une liste qui peut être utilisée dans les templates. `Fichier à : yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Expressions régulières Helm inclut les fonctions d'expressions régulières suivantes : [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Retourne vrai si la chaîne d'entrée contient une correspondance de l'expression régulière. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` L'exemple ci-dessus produit `true` `regexMatch` provoque un panic en cas de problème et `mustRegexMatch` retourne une erreur au moteur de template en cas de problème. ### regexFindAll, mustRegexFindAll Retourne un slice de toutes les correspondances de l'expression régulière dans la chaîne d'entrée. Le dernier paramètre n détermine le nombre de sous-chaînes à retourner, où -1 signifie retourner toutes les correspondances ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` L'exemple ci-dessus produit `[2 4 6 8]` `regexFindAll` provoque un panic en cas de problème et `mustRegexFindAll` retourne une erreur au moteur de template en cas de problème. ### regexFind, mustRegexFind Retourne la première (la plus à gauche) correspondance de l'expression régulière dans la chaîne d'entrée ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` L'exemple ci-dessus produit `d1` `regexFind` provoque un panic en cas de problème et `mustRegexFind` retourne une erreur au moteur de template en cas de problème. ### regexReplaceAll, mustRegexReplaceAll Retourne une copie de la chaîne d'entrée, en remplaçant les correspondances de l'expression régulière par la chaîne de remplacement. Dans la chaîne de remplacement, les signes $ sont interprétés comme dans Expand, donc par exemple $1 représente le texte de la première sous-correspondance. Le premier argument est ``, le second est ``, et le troisième est ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` L'exemple ci-dessus produit `-W-xxW-` `regexReplaceAll` provoque un panic en cas de problème et `mustRegexReplaceAll` retourne une erreur au moteur de template en cas de problème. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Retourne une copie de la chaîne d'entrée, en remplaçant les correspondances de l'expression régulière par la chaîne de remplacement. La chaîne de remplacement est substituée directement, sans utiliser Expand. Le premier argument est ``, le second est ``, et le troisième est ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` L'exemple ci-dessus produit `-${1}-${1}-` `regexReplaceAllLiteral` provoque un panic en cas de problème et `mustRegexReplaceAllLiteral` retourne une erreur au moteur de template en cas de problème. ### regexSplit, mustRegexSplit Découpe la chaîne d'entrée en sous-chaînes séparées par l'expression et retourne un slice des sous-chaînes entre ces correspondances d'expression. Le dernier paramètre `n` détermine le nombre de sous-chaînes à retourner, où `-1` signifie retourner toutes les correspondances ``` regexSplit "z+" "pizza" -1 ``` L'exemple ci-dessus produit `[pi a]` `regexSplit` provoque un panic en cas de problème et `mustRegexSplit` retourne une erreur au moteur de template en cas de problème. ## Fonctions cryptographiques et de sécurité Helm fournit des fonctions cryptographiques avancées. Elles incluent [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), et [sha256sum](#sha256sum). ### sha1sum La fonction `sha1sum` reçoit une chaîne et calcule son condensé SHA1. ``` sha1sum "Hello world!" ``` ### sha256sum La fonction `sha256sum` reçoit une chaîne et calcule son condensé SHA256. ``` sha256sum "Hello world!" ``` L'exemple ci-dessus calculera la somme SHA 256 dans un format « ASCII armored » qui est sûr à afficher. ### adler32sum La fonction `adler32sum` reçoit une chaîne et calcule sa somme de contrôle Adler-32. ``` adler32sum "Hello world!" ``` ### htpasswd La fonction `htpasswd` prend un `username` et un `password` et génère un hachage `bcrypt` du mot de passe. Le résultat peut être utilisé pour l'authentification de base sur un [serveur HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Notez qu'il n'est pas sécurisé de stocker le mot de passe directement dans le template. ### randBytes La fonction randBytes accepte un compteur N et génère une séquence aléatoire cryptographiquement sécurisée (utilise crypto/rand) de N octets. La séquence est retournée sous forme de chaîne encodée en base64. ``` randBytes 24 ``` ### derivePassword La fonction `derivePassword` peut être utilisée pour dériver un mot de passe spécifique basé sur certaines contraintes d'un « mot de passe maître » partagé. L'algorithme pour cela est [bien spécifié](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Notez qu'il est considéré comme non sécurisé de stocker les parties directement dans le template. ### genPrivateKey La fonction `genPrivateKey` génère une nouvelle clé privée encodée dans un bloc PEM. Elle prend l'une des valeurs suivantes pour son premier paramètre : - `ecdsa` : Génère une clé DSA à courbe elliptique (P256) - `dsa` : Génère une clé DSA (L2048N256) - `rsa` : Génère une clé RSA 4096 ### buildCustomCert La fonction `buildCustomCert` permet de personnaliser le certificat. Elle prend les paramètres de chaîne suivants : - Un certificat au format PEM encodé en base64 - Une clé privée au format PEM encodée en base64 Elle retourne un objet certificat avec les attributs suivants : - `Cert` : Un certificat encodé en PEM - `Key` : Une clé privée encodée en PEM Exemple : ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Notez que l'objet retourné peut être passé à la fonction `genSignedCert` pour signer un certificat en utilisant cette CA. ### genCA La fonction `genCA` génère une nouvelle autorité de certification x509 auto-signée. Elle prend les paramètres suivants : - Nom commun du sujet (cn) - Durée de validité du certificat en jours Elle retourne un objet avec les attributs suivants : - `Cert` : Un certificat encodé en PEM - `Key` : Une clé privée encodée en PEM Exemple : ``` $ca := genCA "foo-ca" 365 ``` Notez que l'objet retourné peut être passé à la fonction `genSignedCert` pour signer un certificat en utilisant cette CA. ### genSelfSignedCert La fonction `genSelfSignedCert` génère un nouveau certificat x509 auto-signé. Elle prend les paramètres suivants : - Nom commun du sujet (cn) - Liste optionnelle d'IPs ; peut être nil - Liste optionnelle de noms DNS alternatifs ; peut être nil - Durée de validité du certificat en jours Elle retourne un objet avec les attributs suivants : - `Cert` : Un certificat encodé en PEM - `Key` : Une clé privée encodée en PEM Exemple : ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert La fonction `genSignedCert` génère un nouveau certificat x509 signé par la CA spécifiée. Elle prend les paramètres suivants : - Nom commun du sujet (cn) - Liste optionnelle d'IPs ; peut être nil - Liste optionnelle de noms DNS alternatifs ; peut être nil - Durée de validité du certificat en jours - CA (voir `genCA`) Exemple : ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES La fonction `encryptAES` chiffre du texte avec AES-256 CBC et retourne une chaîne encodée en base64. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES La fonction `decryptAES` reçoit une chaîne base64 encodée par l'algorithme AES-256 CBC et retourne le texte déchiffré. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Fonctions de date Helm inclut les fonctions de date suivantes que vous pouvez utiliser dans les templates : [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate), et [unixEpoch](#unixepoch). ### now La date/heure actuelle. Utilisez ceci en conjonction avec d'autres fonctions de date. ### ago La fonction `ago` retourne la durée depuis un temps. Résolution en secondes. ``` ago .CreatedAt ``` retourne au format String() de `time.Duration` ``` 2h34m7s ``` ### date La fonction `date` formate une date. Formatez la date en ANNÉE-MOIS-JOUR : ``` now | date "2006-01-02" ``` Le formatage de date en Go est [un peu différent](https://pauladamsmith.com/blog/2011/05/go_time.html). En bref, prenez ceci comme date de référence : ``` Mon Jan 2 15:04:05 MST 2006 ``` Écrivez-la dans le format souhaité. Ci-dessus, `2006-01-02` est la même date, mais dans le format que nous voulons. ### dateInZone Identique à `date`, mais avec un fuseau horaire. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formate un nombre de secondes donné en `time.Duration`. Ceci retourne 1m35s ``` duration "95" ``` ### durationRound Arrondit une durée donnée à l'unité la plus significative. Les chaînes et `time.Duration` sont analysés comme une durée, tandis qu'un `time.Time` est calculé comme la durée depuis. Ceci retourne 2h ``` durationRound "2h10m5s" ``` Ceci retourne 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Retourne les secondes depuis l'époque unix pour un `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify La fonction `dateModify` prend une modification et une date et retourne l'horodatage. Soustraire une heure et trente minutes de l'heure actuelle : ``` now | dateModify "-1.5h" ``` Si le format de modification est incorrect, `dateModify` retournera la date non modifiée. `mustDateModify` retournera une erreur dans ce cas. ### htmlDate La fonction `htmlDate` formate une date pour l'insertion dans un champ de sélection de date HTML. ``` now | htmlDate ``` ### htmlDateInZone Identique à htmlDate, mais avec un fuseau horaire. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` convertit une chaîne en date. Le premier argument est le format de date et le second est la chaîne de date. Si la chaîne ne peut pas être convertie, elle retourne la valeur zéro. `mustToDate` retournera une erreur si la chaîne ne peut pas être convertie. Ceci est utile lorsque vous voulez convertir une date en chaîne vers un autre format (en utilisant un pipe). L'exemple ci-dessous convertit "2017-12-31" en "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Dictionnaires et fonctions Dict Helm fournit un type de stockage clé/valeur appelé `dict` (abréviation de « dictionary », comme en Python). Un `dict` est un type _non ordonné_. La clé d'un dictionnaire **doit être une chaîne**. Cependant, la valeur peut être de n'importe quel type, même un autre `dict` ou une `list`. Contrairement aux `list`s, les `dict`s ne sont pas immuables. Les fonctions `set` et `unset` modifieront le contenu d'un dictionnaire. Helm fournit les fonctions suivantes pour travailler avec les dicts : [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), et [values](#values). ### dict La création de dictionnaires se fait en appelant la fonction `dict` et en lui passant une liste de paires. L'exemple suivant crée un dictionnaire avec trois éléments : ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Étant donné un map et une clé, obtient la valeur du map. ``` get $myDict "name1" ``` L'exemple ci-dessus retourne `"value1"` Notez que si la clé n'est pas trouvée, cette opération retournera simplement `""`. Aucune erreur ne sera générée. ### set Utilisez `set` pour ajouter une nouvelle paire clé/valeur à un dictionnaire. ``` $_ := set $myDict "name4" "value4" ``` Notez que `set` _retourne le dictionnaire_ (une exigence des fonctions de template Go), vous devrez donc peut-être capturer la valeur comme fait ci-dessus avec l'assignation `$_`. ### unset Étant donné un map et une clé, supprime la clé du map. ``` $_ := unset $myDict "name4" ``` Comme avec `set`, ceci retourne le dictionnaire. Notez que si la clé n'est pas trouvée, cette opération retournera simplement. Aucune erreur ne sera générée. ### hasKey La fonction `hasKey` retourne `true` si le dict donné contient la clé donnée. ``` hasKey $myDict "name1" ``` Si la clé n'est pas trouvée, ceci retourne `false`. ### pluck La fonction `pluck` permet de donner une clé et plusieurs maps, et d'obtenir une liste de toutes les correspondances : ``` pluck "name1" $myDict $myOtherDict ``` L'exemple ci-dessus retournera une `list` contenant chaque valeur trouvée (`[value1 otherValue1]`). Si la clé donnée _n'est pas trouvée_ dans un map, ce map n'aura pas d'élément dans la liste (et la longueur de la liste retournée sera inférieure au nombre de dicts dans l'appel à `pluck`). Si la clé _est trouvée_ mais que la valeur est une valeur vide, cette valeur sera insérée. Un idiome courant dans les templates Helm est d'utiliser `pluck... | first` pour obtenir la première clé correspondante d'une collection de dictionnaires. ### dig La fonction `dig` parcourt un ensemble imbriqué de dicts, en sélectionnant les clés d'une liste de valeurs. Elle retourne une valeur par défaut si l'une des clés n'est pas trouvée dans le dict associé. ``` dig "user" "role" "humanName" "guest" $dict ``` Étant donné un dict structuré comme ``` { user: { role: { humanName: "curator" } } } ``` l'exemple ci-dessus retournerait `"curator"`. Si le dict n'avait même pas de champ `user`, le résultat serait `"guest"`. Dig peut être très utile dans les cas où vous souhaitez éviter les clauses de garde, d'autant plus que le `and` du package template de Go ne fait pas de court-circuit. Par exemple `and a.maybeNil a.maybeNil.iNeedThis` évaluera toujours `a.maybeNil.iNeedThis`, et provoquera une panique si `a` n'a pas de champ `maybeNil`.) `dig` accepte son argument dict en dernier afin de prendre en charge le pipelining. Par exemple : ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Fusionne deux dictionnaires ou plus en un seul, en donnant la priorité au dictionnaire de destination : Étant donné : ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` le résultat sera : ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` C'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués qui sont fusionnés sont la même instance dans les deux dicts. Si vous voulez une copie profonde en même temps que la fusion, utilisez la fonction `deepCopy` avec la fusion. Par exemple, ``` deepCopy $source | merge $dest ``` `mustMerge` retournera une erreur en cas de fusion non réussie. ### mergeOverwrite, mustMergeOverwrite Fusionne deux dictionnaires ou plus en un seul, en donnant la priorité **de droite à gauche**, écrasant ainsi les valeurs dans le dictionnaire de destination : Étant donné : ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` le résultat sera : ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` C'est une opération de fusion profonde mais pas une opération de copie profonde. Les objets imbriqués qui sont fusionnés sont la même instance dans les deux dicts. Si vous voulez une copie profonde en même temps que la fusion, utilisez la fonction `deepCopy` avec la fusion. Par exemple, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` retournera une erreur en cas de fusion non réussie. ### keys La fonction `keys` retournera une `list` de toutes les clés dans un ou plusieurs types `dict`. Puisqu'un dictionnaire est _non ordonné_, les clés ne seront pas dans un ordre prévisible. Elles peuvent être triées avec `sortAlpha`. ``` keys $myDict | sortAlpha ``` Lors de la fourniture de plusieurs dictionnaires, les clés seront concaténées. Utilisez la fonction `uniq` avec `sortAlpha` pour obtenir une liste unique et triée de clés. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick La fonction `pick` sélectionne uniquement les clés données d'un dictionnaire, créant un nouveau `dict`. ``` $new := pick $myDict "name1" "name2" ``` L'exemple ci-dessus retourne `{name1: value1, name2: value2}` ### omit La fonction `omit` est similaire à `pick`, sauf qu'elle retourne un nouveau `dict` avec toutes les clés qui _ne correspondent pas_ aux clés données. ``` $new := omit $myDict "name1" "name3" ``` L'exemple ci-dessus retourne `{name2: value2}` ### values La fonction `values` est similaire à `keys`, sauf qu'elle retourne une nouvelle `list` avec toutes les valeurs du `dict` source (un seul dictionnaire est pris en charge). ``` $vals := values $myDict ``` L'exemple ci-dessus retourne `list["value1", "value2", "value 3"]`. Notez que la fonction `values` ne donne aucune garantie sur l'ordre des résultats ; si cela vous importe, utilisez `sortAlpha`. ### deepCopy, mustDeepCopy Les fonctions `deepCopy` et `mustDeepCopy` prennent une valeur et en font une copie profonde. Cela inclut les dicts et autres structures. `deepCopy` provoque un panic lorsqu'il y a un problème, tandis que `mustDeepCopy` retourne une erreur au système de template lorsqu'il y a une erreur. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Note sur les internes des Dict Un `dict` est implémenté en Go comme un `map[string]interface{}`. Les développeurs Go peuvent passer des valeurs `map[string]interface{}` dans le contexte pour les rendre disponibles aux templates en tant que `dict`s. ## Fonctions d'encodage Helm dispose des fonctions d'encodage et de décodage suivantes : - `b64enc`/`b64dec` : Encoder ou décoder avec Base64 - `b32enc`/`b32dec` : Encoder ou décoder avec Base32 ## Listes et fonctions de liste Helm fournit un type `list` simple qui peut contenir des listes séquentielles arbitraires de données. C'est similaire aux tableaux ou aux slices, mais les listes sont conçues pour être utilisées comme types de données immuables. Créer une liste d'entiers : ``` $myList := list 1 2 3 4 5 ``` L'exemple ci-dessus crée une liste de `[1 2 3 4 5]`. Helm fournit les fonctions de liste suivantes : [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), et [without (mustWithout)](#without-mustwithout). ### first, mustFirst Pour obtenir le premier élément d'une liste, utilisez `first`. `first $myList` retourne `1` `first` provoque un panic en cas de problème, tandis que `mustFirst` retourne une erreur au moteur de template en cas de problème. ### rest, mustRest Pour obtenir la queue de la liste (tout sauf le premier élément), utilisez `rest`. `rest $myList` retourne `[2 3 4 5]` `rest` provoque un panic en cas de problème, tandis que `mustRest` retourne une erreur au moteur de template en cas de problème. ### last, mustLast Pour obtenir le dernier élément d'une liste, utilisez `last` : `last $myList` retourne `5`. C'est approximativement équivalent à inverser une liste et ensuite appeler `first`. ### initial, mustInitial Ceci complète `last` en retournant tous les éléments _sauf_ le dernier. `initial $myList` retourne `[1 2 3 4]`. `initial` provoque un panic en cas de problème, tandis que `mustInitial` retourne une erreur au moteur de template en cas de problème. ### append, mustAppend Ajoute un nouvel élément à une liste existante, créant une nouvelle liste. ``` $new = append $myList 6 ``` L'exemple ci-dessus définirait `$new` à `[1 2 3 4 5 6]`. `$myList` resterait inchangé. `append` provoque un panic en cas de problème, tandis que `mustAppend` retourne une erreur au moteur de template en cas de problème. ### prepend, mustPrepend Pousse un élément au début d'une liste, créant une nouvelle liste. ``` prepend $myList 0 ``` L'exemple ci-dessus produirait `[0 1 2 3 4 5]`. `$myList` resterait inchangé. `prepend` provoque un panic en cas de problème, tandis que `mustPrepend` retourne une erreur au moteur de template en cas de problème. ### concat Concatène un nombre arbitraire de listes en une seule. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` L'exemple ci-dessus produirait `[1 2 3 4 5 6 7 8]`. `$myList` resterait inchangé. ### reverse, mustReverse Produit une nouvelle liste avec les éléments inversés de la liste donnée. ``` reverse $myList ``` L'exemple ci-dessus générerait la liste `[5 4 3 2 1]`. `reverse` provoque un panic en cas de problème, tandis que `mustReverse` retourne une erreur au moteur de template en cas de problème. ### uniq, mustUniq Génère une liste avec tous les doublons supprimés. ``` list 1 1 1 2 | uniq ``` L'exemple ci-dessus produirait `[1 2]` `uniq` provoque un panic en cas de problème, tandis que `mustUniq` retourne une erreur au moteur de template en cas de problème. ### without, mustWithout La fonction `without` filtre les éléments d'une liste. ``` without $myList 3 ``` L'exemple ci-dessus produirait `[1 2 4 5]` `without` peut prendre plus d'un filtre : ``` without $myList 1 3 5 ``` Cela produirait `[2 4]` `without` provoque un panic en cas de problème, tandis que `mustWithout` retourne une erreur au moteur de template en cas de problème. ### has, mustHas Teste si une liste contient un élément particulier. ``` has 4 $myList ``` L'exemple ci-dessus retournerait `true`, tandis que `has "hello" $myList` retournerait false. `has` provoque un panic en cas de problème, tandis que `mustHas` retourne une erreur au moteur de template en cas de problème. ### compact, mustCompact Accepte une liste et supprime les entrées avec des valeurs vides. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` retournera une nouvelle liste avec l'élément vide (c'est-à-dire "") supprimé. `compact` provoque un panic en cas de problème et `mustCompact` retourne une erreur au moteur de template en cas de problème. ### index Pour obtenir le nième élément d'une liste, utilisez `index list [n]`. Pour indexer dans des listes multidimensionnelles, utilisez `index list [n] [m] ...` - `index $myList 0` retourne `1`. C'est la même chose que `myList[0]` - `index $myList 0 1` serait la même chose que `myList[0][1]` ### slice, mustSlice Pour obtenir des éléments partiels d'une liste, utilisez `slice list [n] [m]`. C'est équivalent à `list[n:m]`. - `slice $myList` retourne `[1 2 3 4 5]`. C'est la même chose que `myList[:]`. - `slice $myList 3` retourne `[4 5]`. C'est la même chose que `myList[3:]`. - `slice $myList 1 3` retourne `[2 3]`. C'est la même chose que `myList[1:3]`. - `slice $myList 0 3` retourne `[1 2 3]`. C'est la même chose que `myList[:3]`. `slice` provoque un panic en cas de problème, tandis que `mustSlice` retourne une erreur au moteur de template en cas de problème. ### until La fonction `until` construit une plage d'entiers. ``` until 5 ``` L'exemple ci-dessus génère la liste `[0, 1, 2, 3, 4]`. C'est utile pour boucler avec `range $i, $e := until 5`. ### untilStep Comme `until`, `untilStep` génère une liste d'entiers à compter. Mais elle vous permet de définir un début, une fin et un pas : ``` untilStep 3 6 2 ``` L'exemple ci-dessus produira `[3 5]` en commençant par 3, et en ajoutant 2 jusqu'à ce que ce soit égal ou supérieur à 6. C'est similaire à la fonction `range` de Python. ### seq Fonctionne comme la commande bash `seq`. * 1 paramètre (end) - générera tous les entiers entre 1 et `end` inclus. * 2 paramètres (start, end) - générera tous les entiers entre `start` et `end` inclus en incrémentant ou décrémentant de 1. * 3 paramètres (start, step, end) - générera tous les entiers entre `start` et `end` inclus en incrémentant ou décrémentant de `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Pour diviser une liste en morceaux d'une taille donnée, utilisez `chunk size list`. C'est utile pour la pagination. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` Ceci produit une liste de listes `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Fonctions mathématiques Toutes les fonctions mathématiques opèrent sur des valeurs `int64` sauf indication contraire. Les fonctions mathématiques suivantes sont disponibles : [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), et [sub](#sub). ### add Additionne des nombres avec `add`. Accepte deux entrées ou plus. ``` add 1 2 3 ``` ### add1 Pour incrémenter de 1, utilisez `add1`. ### sub Pour soustraire, utilisez `sub`. ### div Effectue une division entière avec `div`. ### mod Modulo avec `mod`. ### mul Multiplie avec `mul`. Accepte deux entrées ou plus. ``` mul 1 2 3 ``` ### max Retourne le plus grand d'une série d'entiers. Ceci retournera `3` : ``` max 1 2 3 ``` ### min Retourne le plus petit d'une série d'entiers. `min 1 2 3` retournera `1`. ### len Retourne la longueur de l'argument en tant qu'entier. ``` len .Arg ``` ## Fonctions mathématiques à virgule flottante Toutes les fonctions mathématiques opèrent sur des valeurs `float64`. ### addf Additionne des nombres avec `addf` Ceci retournera `5.5` : ``` addf 1.5 2 2 ``` ### add1f Pour incrémenter de 1, utilisez `add1f` ### subf Pour soustraire, utilisez `subf` Ceci est équivalent à `7.5 - 2 - 3` et retournera `2.5` : ``` subf 7.5 2 3 ``` ### divf Effectue une division à virgule flottante avec `divf` Ceci est équivalent à `10 / 2 / 4` et retournera `1.25` : ``` divf 10 2 4 ``` ### mulf Multiplie avec `mulf` Ceci retournera `6` : ``` mulf 1.5 2 2 ``` ### maxf Retourne le plus grand d'une série de nombres à virgule flottante : Ceci retournera `3` : ``` maxf 1 2.5 3 ``` ### minf Retourne le plus petit d'une série de nombres à virgule flottante. Ceci retournera `1.5` : ``` minf 1.5 2 3 ``` ### floor Retourne la plus grande valeur flottante inférieure ou égale à la valeur d'entrée. `floor 123.9999` retournera `123.0`. ### ceil Retourne la plus grande valeur flottante supérieure ou égale à la valeur d'entrée. `ceil 123.001` retournera `124.0`. ### round Retourne une valeur flottante avec le reste arrondi au nombre donné de chiffres après la virgule décimale. `round 123.555555 3` retournera `123.556`. ## Fonctions réseau Helm a une seule fonction réseau, `getHostByName`. La fonction `getHostByName` reçoit un nom de domaine et retourne l'adresse IP. `getHostByName "www.google.com"` retournerait l'adresse IP correspondante de `www.google.com`. Cette fonction nécessite l'option `--enable-dns` à passer sur la ligne de commande helm. ## Fonctions de chemin de fichier Bien que les fonctions de template Helm ne donnent pas accès au système de fichiers, elles fournissent des fonctions pour travailler avec des chaînes qui suivent les conventions de chemins de fichiers. Celles-ci incluent [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), et [isAbs](#isabs). ### base Retourne le dernier élément d'un chemin. ``` base "foo/bar/baz" ``` L'exemple ci-dessus affiche "baz". ### dir Retourne le répertoire, en supprimant la dernière partie du chemin. Donc `dir "foo/bar/baz"` retourne `foo/bar`. ### clean Nettoie un chemin. ``` clean "foo/bar/../baz" ``` L'exemple ci-dessus résout le `..` et retourne `foo/baz`. ### ext Retourne l'extension du fichier. ``` ext "foo.bar" ``` L'exemple ci-dessus retourne `.bar`. ### isAbs Pour vérifier si un chemin de fichier est absolu, utilisez `isAbs`. ## Fonctions de réflexion Helm fournit des outils de réflexion rudimentaires. Ceux-ci aident les développeurs de templates avancés à comprendre les informations de type Go sous-jacentes pour une valeur particulière. Helm est écrit en Go et est fortement typé. Le système de types s'applique dans les templates. Go a plusieurs _kinds_ primitifs, comme `string`, `slice`, `int64`, et `bool`. Go a un système de _types_ ouvert qui permet aux développeurs de créer leurs propres types. Helm fournit un ensemble de fonctions pour chacun via les [fonctions kind](#fonctions-kind) et les [fonctions type](#fonctions-type). Une fonction [deepEqual](#deepequal) est également fournie pour comparer deux valeurs. ### Fonctions Kind Il y a deux fonctions Kind : `kindOf` retourne le kind d'un objet. ``` kindOf "hello" ``` L'exemple ci-dessus retournerait `string`. Pour des tests simples (comme dans les blocs `if`), la fonction `kindIs` vous permettra de vérifier qu'une valeur est d'un kind particulier : ``` kindIs "int" 123 ``` L'exemple ci-dessus retournera `true`. ### Fonctions Type Les types sont légèrement plus difficiles à manipuler, il y a donc trois fonctions différentes : - `typeOf` retourne le type sous-jacent d'une valeur : `typeOf $foo` - `typeIs` est comme `kindIs`, mais pour les types : `typeIs "*io.Buffer" $myVal` - `typeIsLike` fonctionne comme `typeIs`, sauf qu'il déréférence également les pointeurs **Note :** Aucune de ces fonctions ne peut tester si quelque chose implémente une interface donnée, car cela nécessiterait de compiler l'interface à l'avance. ### deepEqual `deepEqual` retourne vrai si deux valeurs sont [« profondément égales »](https://golang.org/pkg/reflect/#DeepEqual) Fonctionne également pour les types non primitifs (contrairement au `eq` intégré). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` L'exemple ci-dessus retournera `true`. ## Fonctions de version sémantique Certains schémas de version sont facilement analysables et comparables. Helm fournit des fonctions pour travailler avec les versions [SemVer 2](http://semver.org). Celles-ci incluent [semver](#semver) et [semverCompare](#semvercompare). Vous trouverez ci-dessous également des détails sur l'utilisation des plages pour les comparaisons. ### semver La fonction `semver` analyse une chaîne en une Version Sémantique : ``` $version := semver "1.2.3-alpha.1+123" ``` _Si l'analyseur échoue, il provoquera l'arrêt de l'exécution du template avec une erreur._ À ce stade, `$version` est un pointeur vers un objet `Version` avec les propriétés suivantes : - `$version.Major` : Le numéro majeur (`1` ci-dessus) - `$version.Minor` : Le numéro mineur (`2` ci-dessus) - `$version.Patch` : Le numéro de patch (`3` ci-dessus) - `$version.Prerelease` : La préversion (`alpha.1` ci-dessus) - `$version.Metadata` : Les métadonnées de build (`123` ci-dessus) - `$version.Original` : La version originale sous forme de chaîne De plus, vous pouvez comparer une `Version` à une autre `version` en utilisant la fonction `Compare` : ``` semver "1.4.3" | (semver "1.2.3").Compare ``` L'exemple ci-dessus retournera `-1`. Les valeurs de retour sont : - `-1` si le semver donné est supérieur au semver dont la méthode `Compare` a été appelée - `1` si la version dont la fonction `Compare` a été appelée est supérieure. - `0` s'ils sont de la même version (Notez que dans SemVer, le champ `Metadata` n'est pas comparé lors des opérations de comparaison de version.) ### semverCompare Une fonction de comparaison plus robuste est fournie par `semverCompare`. Cette version prend en charge les plages de versions : - `semverCompare "1.2.3" "1.2.3"` vérifie une correspondance exacte - `semverCompare "~1.2.0" "1.2.3"` vérifie que les versions majeure et mineure correspondent, et que le numéro de patch du second paramètre est _supérieur ou égal au_ premier paramètre. Les fonctions SemVer utilisent la [bibliothèque semver Masterminds](https://github.com/Masterminds/semver), des créateurs de Sprig. ### Comparaisons de base Il y a deux éléments dans les comparaisons. Premièrement, une chaîne de comparaison est une liste de comparaisons ET séparées par des espaces ou des virgules. Celles-ci sont ensuite séparées par || (OU) comparaisons. Par exemple, `">= 1.2 < 3.0.0 || >= 4.2.3"` recherche une comparaison qui est supérieure ou égale à 1.2 et inférieure à 3.0.0 ou est supérieure ou égale à 4.2.3. Les comparaisons de base sont : - `=` : égal (alias vers pas d'opérateur) - `!=` : différent - `>` : supérieur à - `<` : inférieur à - `>=` : supérieur ou égal à - `<=` : inférieur ou égal à ### Travailler avec les versions préliminaires Les préversions, pour ceux qui ne les connaissent pas, sont utilisées pour les versions de logiciels avant les versions stables ou généralement disponibles. Des exemples de préversions incluent les versions de développement, alpha, bêta et release candidate. Une préversion peut être une version comme `1.2.3-beta.1`, tandis que la version stable serait `1.2.3`. Dans l' ordre de préséance, les préversions viennent avant leurs versions associées. Dans cet exemple `1.2.3-beta.1 < 1.2.3`. Selon la spécification de Version Sémantique, les préversions peuvent ne pas être conformes à l'API avec leur version correspondante. Elle dit : > Une version préliminaire indique que la version est instable et pourrait ne pas > satisfaire les exigences de compatibilité prévues comme indiqué par sa > version normale associée. Les comparaisons SemVer utilisant des contraintes sans comparateur de préversion sauteront les versions préliminaires. Par exemple, `>=1.2.3` sautera les préversions lors de la recherche dans une liste de versions, tandis que `>=1.2.3-0` évaluera et trouvera les préversions. La raison du `0` comme version préliminaire dans l'exemple de comparaison est que les préversions ne peuvent contenir que des alphanumériques ASCII et des tirets (avec des séparateurs `.`), selon la spécification. Le tri se fait dans l'ordre de tri ASCII, encore selon la spécification. Le caractère le plus bas est un `0` dans l'ordre de tri ASCII (voir une [Table ASCII](http://www.asciitable.com/)) Comprendre l'ordre de tri ASCII est important car A-Z vient avant a-z. Cela signifie que `>=1.2.3-BETA` retournera `1.2.3-alpha`. Ce à quoi vous pourriez vous attendre de la sensibilité à la casse ne s'applique pas ici. C'est dû à l'ordre de tri ASCII qui est ce que la spécification définit. ### Comparaisons de plage avec tiret Il existe plusieurs méthodes pour gérer les plages et la première est les plages avec tirets. Celles-ci ressemblent à : - `1.2 - 1.4.5` qui est équivalent à `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` qui est équivalent à `>= 2.3.4 <= 4.5` ### Caractères génériques dans les comparaisons Les caractères `x`, `X` et `*` peuvent être utilisés comme caractère générique. Cela fonctionne pour tous les opérateurs de comparaison. Lorsqu'il est utilisé avec l'opérateur `=`, il revient à la comparaison au niveau du patch (voir tilde ci-dessous). Par exemple, - `1.2.x` est équivalent à `>= 1.2.0, < 1.3.0` - `>= 1.2.x` est équivalent à `>= 1.2.0` - `<= 2.x` est équivalent à `< 3` - `*` est équivalent à `>= 0.0.0` ### Comparaisons de plage avec tilde (Patch) L'opérateur de comparaison tilde (`~`) est pour les plages au niveau du patch lorsqu'une version mineure est spécifiée et les changements au niveau majeur lorsque le numéro mineur est manquant. Par exemple, - `~1.2.3` est équivalent à `>= 1.2.3, < 1.3.0` - `~1` est équivalent à `>= 1, < 2` - `~2.3` est équivalent à `>= 2.3, < 2.4` - `~1.2.x` est équivalent à `>= 1.2.0, < 1.3.0` - `~1.x` est équivalent à `>= 1, < 2` ### Comparaisons de plage avec accent circonflexe (Majeur) L'opérateur de comparaison accent circonflexe (`^`) est pour les changements au niveau majeur une fois qu'une version stable (1.0.0) a été publiée. Avant une version 1.0.0, les versions mineures agissent comme le niveau de stabilité de l'API. C'est utile lors des comparaisons de versions d'API car un changement majeur casse l'API. Par exemple, - `^1.2.3` est équivalent à `>= 1.2.3, < 2.0.0` - `^1.2.x` est équivalent à `>= 1.2.0, < 2.0.0` - `^2.3` est équivalent à `>= 2.3, < 3` - `^2.x` est équivalent à `>= 2.0.0, < 3` - `^0.2.3` est équivalent à `>=0.2.3 <0.3.0` - `^0.2` est équivalent à `>=0.2.0 <0.3.0` - `^0.0.3` est équivalent à `>=0.0.3 <0.0.4` - `^0.0` est équivalent à `>=0.0.0 <0.1.0` - `^0` est équivalent à `>=0.0.0 <1.0.0` ## Fonctions URL Helm inclut les fonctions [urlParse](#urlparse), [urlJoin](#urljoin), et [urlquery](#urlquery) vous permettant de travailler avec les parties d'URL. ### urlParse Analyse une chaîne pour une URL et produit un dict avec les parties de l'URL ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` L'exemple ci-dessus retourne un dict, contenant l'objet URL : ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Ceci est implémenté en utilisant les packages URL de la bibliothèque standard Go. Pour plus d'informations, consultez https://golang.org/pkg/net/url/#URL ### urlJoin Joint un map (produit par `urlParse`) pour produire une chaîne URL ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` L'exemple ci-dessus retourne la chaîne suivante : ``` http://host:80/path?query#fragment ``` ### urlquery Retourne la version échappée de la valeur passée en argument de sorte qu'elle soit adaptée à l'intégration dans la partie requête d'une URL. ``` $var := urlquery "string for query" ``` ## Fonctions UUID Helm peut générer des UUID v4 universellement uniques. ``` uuidv4 ``` L'exemple ci-dessus retourne un nouvel UUID de type v4 (généré aléatoirement). ## Fonctions Kubernetes et Chart Helm inclut des fonctions pour travailler avec Kubernetes, notamment [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#fonctions-de-fichier), et [lookup](#lookup). ### lookup `lookup` est utilisé pour rechercher une ressource dans un cluster en cours d'exécution. Lorsqu'il est utilisé avec la commande `helm template`, il retourne toujours une réponse vide. Vous pouvez trouver plus de détails dans la [documentation sur la fonction lookup](./functions_and_pipelines.md#utilisation-de-la-fonction-lookup). ### .Capabilities.APIVersions.Has Retourne si une version d'API ou une ressource est disponible dans un cluster. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Plus d'informations sont disponibles dans la [documentation sur les objets intégrés](./builtin_objects.md). ### Fonctions de fichier Il existe plusieurs fonctions qui vous permettent d'accéder aux fichiers non spéciaux dans un chart. Par exemple, pour accéder aux fichiers de configuration d'application. Celles-ci sont documentées dans [Accéder aux fichiers dans les templates](./accessing_files.md). _Note, la documentation de beaucoup de ces fonctions provient de [Sprig](https://github.com/Masterminds/sprig). Sprig est une bibliothèque de fonctions de template disponible pour les applications Go._ ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Fonctions de template et pipelines description: Utilisation des fonctions dans les templates. sidebar_position: 5 --- Jusqu'à présent, nous avons vu comment insérer des informations dans un template. Mais ces informations sont insérées sans modification. Parfois, nous voulons transformer les données fournies de manière plus exploitable. Commençons par une bonne pratique : lorsque vous injectez des chaînes de caractères provenant de l'objet `.Values` dans le template, vous devriez les mettre entre guillemets. Vous pouvez le faire en appelant la fonction `quote` dans la directive de template : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Les fonctions de template suivent la syntaxe `nomFonction arg1 arg2...`. Dans l'extrait ci-dessus, `quote .Values.favorite.drink` appelle la fonction `quote` et lui passe un unique argument. Helm dispose de plus de 60 fonctions disponibles. Certaines sont définies par le [langage de template Go](https://godoc.org/text/template) lui-même. La plupart des autres font partie de la [bibliothèque de templates Sprig](https://masterminds.github.io/sprig/). Nous en verrons plusieurs au fil des exemples. > Même si nous parlons du « langage de template Helm » comme s'il était spécifique à Helm, il s'agit en réalité d'une combinaison du langage de template Go, de fonctions supplémentaires et de divers wrappers pour exposer certains objets aux templates. De nombreuses ressources sur les templates Go peuvent vous aider dans votre apprentissage. ## Pipelines L'une des fonctionnalités puissantes du langage de template est son concept de _pipelines_. S'inspirant d'un concept d'UNIX, les pipelines sont un outil permettant d'enchaîner une série de commandes de template pour exprimer de manière compacte une série de transformations. Autrement dit, les pipelines sont un moyen efficace d'accomplir plusieurs choses en séquence. Réécrivons l'exemple ci-dessus en utilisant un pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` Dans cet exemple, au lieu d'appeler `quote ARGUMENT`, nous avons inversé l'ordre. Nous avons « envoyé » l'argument à la fonction en utilisant un pipeline (`|`) : `.Values.favorite.drink | quote`. Avec les pipelines, nous pouvons enchaîner plusieurs fonctions : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Inverser l'ordre est une pratique courante dans les templates. Vous verrez `.val | quote` plus souvent que `quote .val`. Les deux pratiques sont valables. Lorsque ce template est évalué, il produira le résultat suivant : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Notez que notre `pizza` d'origine a été transformée en `"PIZZA"`. Lorsque vous utilisez des arguments en pipeline de cette façon, le résultat de la première évaluation (`.Values.favorite.drink`) est envoyé comme _dernier argument de la fonction_. Nous pouvons modifier l'exemple de la boisson ci-dessus pour illustrer cela avec une fonction qui prend deux arguments : `repeat COUNT STRING` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` La fonction `repeat` répétera la chaîne donnée le nombre de fois spécifié, nous obtiendrons donc ce résultat : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Utilisation de la fonction `default` Une fonction fréquemment utilisée dans les templates est la fonction `default` : `default VALEUR_PAR_DEFAUT VALEUR_DONNEE`. Cette fonction vous permet de spécifier une valeur par défaut à l'intérieur du template, au cas où la valeur serait omise. Utilisons-la pour modifier l'exemple de la boisson ci-dessus : ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Si nous exécutons ceci normalement, nous obtiendrons notre `coffee` : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Maintenant, supprimons le paramètre de boisson favorite dans `values.yaml` : ```yaml favorite: #drink: coffee food: pizza ``` En réexécutant `helm install --dry-run --debug fair-worm ./mychart`, nous obtiendrons ce YAML : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` Dans un vrai chart, toutes les valeurs par défaut statiques devraient se trouver dans `values.yaml` et ne devraient pas être répétées avec la commande `default` (sinon elles seraient redondantes). Cependant, la commande `default` est parfaite pour les valeurs calculées, qui ne peuvent pas être déclarées dans `values.yaml`. Par exemple : ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` Dans certains cas, une condition `if` peut être mieux adaptée que `default`. Nous les verrons dans la section suivante. Les fonctions et les pipelines de template sont un moyen puissant de transformer des informations puis de les insérer dans votre YAML. Mais parfois, il est nécessaire d'ajouter une logique de template un peu plus sophistiquée que la simple insertion d'une chaîne. Dans la section suivante, nous examinerons les structures de contrôle fournies par le langage de template. ## Utilisation de la fonction `lookup` La fonction `lookup` peut être utilisée pour _rechercher_ des ressources dans un cluster en cours d'exécution. La syntaxe de la fonction lookup est `lookup apiVersion, kind, namespace, name -> ressource ou liste de ressources`. | paramètre | type | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | `name` et `namespace` sont optionnels et peuvent être passés comme chaîne vide (`""`). Cependant, si vous travaillez avec une ressource à portée de namespace, `name` et `namespace` doivent tous deux être spécifiés. Les combinaisons de paramètres suivantes sont possibles : | Comportement | Fonction lookup | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Lorsque `lookup` retourne un objet, il renvoie un dictionnaire. Ce dictionnaire peut être parcouru pour extraire des valeurs spécifiques. L'exemple suivant renverra les annotations présentes pour l'objet `mynamespace` : ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Lorsque `lookup` retourne une liste d'objets, il est possible d'accéder à la liste d'objets via le champ `items` : ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* faire quelque chose avec chaque service */}} {{ end }} ``` Lorsqu'aucun objet n'est trouvé, une valeur vide est retournée. Cela peut être utilisé pour vérifier l'existence d'un objet. La fonction `lookup` utilise la configuration de connexion Kubernetes existante de Helm pour interroger Kubernetes. Si une erreur est retournée lors de l'interaction avec le serveur API (par exemple en raison d'un manque de permission pour accéder à une ressource), le traitement du template par Helm échouera. Notez que Helm ne doit pas contacter le serveur API Kubernetes lors d'une opération `helm template|install|upgrade|delete|rollback --dry-run`. Pour tester `lookup` contre un cluster en cours d'exécution, utilisez plutôt `helm template|install|upgrade|delete|rollback --dry-run=server` afin de permettre la connexion au cluster. ## Les opérateurs sont des fonctions Pour les templates, les opérateurs (`eq`, `ne`, `lt`, `gt`, `and`, `or`, etc.) sont tous implémentés comme des fonctions. Dans les pipelines, les opérations peuvent être regroupées avec des parenthèses (`(` et `)`). Passons maintenant aux structures de contrôle : conditions, boucles et modificateurs de portée. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Premiers pas description: Un guide rapide sur les templates de chart. sidebar_position: 2 --- Dans cette section du guide, nous allons créer un chart et y ajouter un premier template. Le chart créé ici sera utilisé tout au long du reste du guide. Pour commencer, examinons brièvement la structure d'un chart Helm. ## Charts Comme décrit dans le [Guide des charts](/topics/charts.md), les charts Helm sont structurés de la manière suivante : ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Le répertoire `templates/` contient les fichiers de template. Lorsque Helm évalue un chart, il envoie tous les fichiers du répertoire `templates/` au moteur de rendu de templates. Il collecte ensuite les résultats de ces templates et les envoie à Kubernetes. Le fichier `values.yaml` est également important pour les templates. Ce fichier contient les _valeurs par défaut_ d'un chart. Ces valeurs peuvent être remplacées par les utilisateurs lors de l'exécution de `helm install` ou `helm upgrade`. Le fichier `Chart.yaml` contient une description du chart. Vous pouvez y accéder depuis un template. Le répertoire `charts/` _peut_ contenir d'autres charts (que nous appelons _sous-charts_). Plus loin dans ce guide, nous verrons comment ceux-ci fonctionnent lors du rendu des templates. ## Un premier chart Pour ce guide, nous allons créer un chart simple appelé `mychart`, puis nous créerons quelques templates à l'intérieur de ce chart. ```console $ helm create mychart Creating mychart ``` ### Un aperçu rapide de `mychart/templates/` Si vous examinez le répertoire `mychart/templates/`, vous remarquerez que quelques fichiers sont déjà présents : - `NOTES.txt` : Le « texte d'aide » de votre chart. Il sera affiché aux utilisateurs lorsqu'ils exécuteront `helm install`. - `deployment.yaml` : Un manifeste de base pour créer un [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) Kubernetes - `service.yaml` : Un manifeste de base pour créer un [endpoint de service](https://kubernetes.io/docs/concepts/services-networking/service/) pour votre deployment - `_helpers.tpl` : Un emplacement pour les fonctions de template réutilisables dans tout le chart Et ce que nous allons faire, c'est... _tous les supprimer !_ De cette façon, nous pourrons suivre notre tutoriel depuis le début. Nous créerons en fait nos propres fichiers `NOTES.txt` et `_helpers.tpl` au fur et à mesure. ```console $ rm -rf mychart/templates/* ``` Lorsque vous écrivez des charts de qualité production, avoir des versions de base de ces fichiers peut être très utile. Dans votre travail quotidien de création de charts, vous ne voudrez probablement pas les supprimer. ## Un premier template Le premier template que nous allons créer sera un `ConfigMap`. Dans Kubernetes, un ConfigMap est simplement un objet permettant de stocker des données de configuration. D'autres éléments, comme les pods, peuvent accéder aux données d'un ConfigMap. Comme les ConfigMaps sont des ressources de base, ils constituent un excellent point de départ pour nous. Commençons par créer un fichier appelé `mychart/templates/configmap.yaml` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **ASTUCE :** Les noms de template ne suivent pas de convention de nommage stricte. Cependant, nous recommandons d'utiliser l'extension `.yaml` pour les fichiers YAML et `.tpl` pour les fichiers d'aide. Le fichier YAML ci-dessus est un ConfigMap minimaliste, contenant uniquement les champs minimaux nécessaires. Du fait que ce fichier se trouve dans le répertoire `mychart/templates/`, il sera envoyé au moteur de templates. Il est tout à fait acceptable de placer un fichier YAML simple comme celui-ci dans le répertoire `mychart/templates/`. Lorsque Helm lit ce template, il l'envoie simplement à Kubernetes tel quel. Avec ce template simple, nous avons maintenant un chart installable. Et nous pouvons l'installer de cette façon : ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` En utilisant Helm, nous pouvons récupérer la release et voir le template réellement chargé. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` La commande `helm get manifest` prend un nom de release (`full-coral`) et affiche toutes les ressources Kubernetes qui ont été envoyées au serveur. Chaque fichier commence par `---` pour indiquer le début d'un document YAML, puis est suivi d'une ligne de commentaire générée automatiquement qui nous indique quel fichier de template a généré ce document YAML. À partir de là, nous pouvons voir que les données YAML sont exactement ce que nous avons mis dans notre fichier `configmap.yaml`. Maintenant, nous pouvons désinstaller notre release : `helm uninstall full-coral`. ### Ajouter un appel de template simple Coder en dur le champ `name:` dans une ressource est généralement considéré comme une mauvaise pratique. Les noms doivent être uniques pour chaque release. Nous pourrions donc vouloir générer le champ name en insérant le nom de la release. **ASTUCE :** Le champ `name:` est limité à 63 caractères en raison des limitations du système DNS. Pour cette raison, les noms de release sont limités à 53 caractères. Kubernetes 1.3 et les versions antérieures étaient limitées à seulement 24 caractères (donc des noms de 14 caractères). Modifions `configmap.yaml` en conséquence. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Le changement majeur se trouve dans la valeur du champ `name:`, qui est maintenant `{{ .Release.Name }}-configmap`. > Une directive de template est encadrée par les blocs `{{` et `}}`. La directive de template `{{ .Release.Name }}` injecte le nom de la release dans le template. Les valeurs passées à un template peuvent être considérées comme des _objets à espace de noms_, où un point (`.`) sépare chaque élément. Le point initial avant `Release` indique que nous commençons par l'espace de noms racine pour cette portée (nous parlerons de la portée plus tard). Nous pouvons donc lire `.Release.Name` comme « partir de l'espace de noms racine, trouver l'objet `Release`, puis chercher à l'intérieur un objet appelé `Name` ». L'objet `Release` est l'un des objets intégrés de Helm, et nous l'aborderons plus en détail ultérieurement. Pour l'instant, il suffit de dire qu'il affichera le nom de release que la bibliothèque attribue à notre release. Maintenant, lorsque nous installons notre ressource, nous verrons immédiatement le résultat de l'utilisation de cette directive de template : ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Vous pouvez exécuter `helm get manifest clunky-serval` pour voir l'ensemble du YAML généré. Notez que le nom du ConfigMap dans Kubernetes est `clunky-serval-configmap` au lieu de `mychart-configmap` précédemment. À ce stade, nous avons vu les templates dans leur forme la plus basique : des fichiers YAML avec des directives de template intégrées dans `{{` et `}}`. Dans la partie suivante, nous examinerons les templates plus en profondeur. Mais avant de continuer, voici une astuce qui peut accélérer la création de templates : lorsque vous voulez tester le rendu d'un template sans rien installer réellement, vous pouvez utiliser `helm install --debug --dry-run goodly-guppy ./mychart`. Cela effectuera le rendu des templates. Mais au lieu d'installer le chart, cela vous retournera le template rendu pour que vous puissiez voir le résultat : ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` L'utilisation de `--dry-run` facilite le test de votre code, mais ne garantit pas que Kubernetes acceptera les templates que vous générez. Il vaut mieux ne pas supposer que votre chart s'installera simplement parce que `--dry-run` fonctionne. Dans le [Guide des templates de chart](/chart_template_guide/index.mdx), nous reprenons le chart de base défini ici et explorons le langage de template Helm en détail. Et nous commencerons par les objets intégrés. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: Le fichier .helmignore description: Le fichier `.helmignore` permet de spécifier les fichiers que vous ne souhaitez pas inclure dans votre chart Helm. sidebar_position: 12 --- Le fichier `.helmignore` permet de spécifier les fichiers que vous ne souhaitez pas inclure dans votre chart Helm. Si ce fichier existe, la commande `helm package` ignorera tous les fichiers qui correspondent aux motifs spécifiés dans le fichier `.helmignore` lors de l'empaquetage de votre application. Cela permet d'éviter l'ajout de fichiers ou répertoires inutiles ou sensibles dans votre chart Helm. Le fichier `.helmignore` prend en charge les motifs de type glob Unix, la correspondance de chemins relatifs, et la négation (préfixée par !). Chaque ligne ne doit contenir qu'un seul motif. Voici un exemple de fichier `.helmignore` : ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Quelques différences notables par rapport à .gitignore : - La syntaxe '**' n'est pas prise en charge. - La bibliothèque de correspondance utilisée est 'filepath.Match' de Go, et non fnmatch(3). - Les espaces en fin de ligne sont toujours ignorés (aucune séquence d'échappement n'est prise en charge). - Il n'y a pas de prise en charge de '\!' comme séquence spéciale de début de ligne. - Le fichier ne s'exclut pas lui-même par défaut ; vous devez ajouter une entrée explicite pour `.helmignore`. **Vous pouvez nous aider** à améliorer ce document. Pour ajouter, corriger ou supprimer des informations, [créez un ticket](https://github.com/helm/helm-www/issues) ou envoyez-nous une pull request. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Templates Nommés description: Comment définir des templates nommés. sidebar_position: 9 --- Il est temps d'aller au-delà d'un seul template et de commencer à en créer d'autres. Dans cette section, nous verrons comment définir des _templates nommés_ dans un fichier, puis les utiliser ailleurs. Un _template nommé_ (parfois appelé _partial_ ou _sous-template_) est simplement un template défini à l'intérieur d'un fichier et auquel on donne un nom. Nous verrons deux façons de les créer et plusieurs façons de les utiliser. Dans la section [Structures de contrôle](/chart_template_guide/control_structures.md), nous avons introduit trois actions pour déclarer et gérer les templates : `define`, `template` et `block`. Dans cette section, nous aborderons ces trois actions et présenterons également une fonction spéciale `include` qui fonctionne de manière similaire à l'action `template`. Un détail important à garder à l'esprit lors de la création de templates : **les noms de templates sont globaux**. Si vous déclarez deux templates avec le même nom, celui qui est chargé en dernier sera utilisé. Comme les templates des sous-charts sont compilés avec les templates de niveau supérieur, vous devez veiller à nommer vos templates avec des _noms spécifiques au chart_. Une convention de nommage répandue consiste à préfixer chaque template défini avec le nom du chart : `{{ define "mychart.labels" }}`. En utilisant le nom spécifique du chart comme préfixe, nous pouvons éviter tout conflit qui pourrait survenir si deux charts différents implémentent des templates du même nom. Ce comportement s'applique également aux différentes versions d'un chart. Si vous avez `mychart` version `1.0.0` qui définit un template d'une certaine manière, et `mychart` version `2.0.0` qui modifie ce template nommé existant, c'est celui qui a été chargé en dernier qui sera utilisé. Vous pouvez contourner ce problème en ajoutant également une version dans le nom du chart : `{{ define "mychart.v1.labels" }}` et `{{ define "mychart.v2.labels" }}`. ## Partials et fichiers `_` Jusqu'à présent, nous avons utilisé un seul fichier, et ce fichier contenait un seul template. Mais le langage de template de Helm permet de créer des templates nommés intégrés, qui peuvent être accédés par leur nom ailleurs. Avant d'entrer dans les détails de l'écriture de ces templates, il y a une convention de nommage de fichiers qui mérite d'être mentionnée : * La plupart des fichiers dans `templates/` sont traités comme s'ils contenaient des manifestes Kubernetes * Le fichier `NOTES.txt` est une exception * Mais les fichiers dont le nom commence par un underscore (`_`) sont supposés _ne pas_ contenir de manifeste. Ces fichiers ne sont pas rendus en définitions d'objets Kubernetes, mais sont disponibles partout dans les autres templates du chart pour être utilisés. Ces fichiers sont utilisés pour stocker des partials et des helpers. En fait, lorsque nous avons créé `mychart` pour la première fois, nous avons vu un fichier appelé `_helpers.tpl`. Ce fichier est l'emplacement par défaut pour les partials de template. ## Déclarer et utiliser des templates avec `define` et `template` L'action `define` nous permet de créer un template nommé à l'intérieur d'un fichier template. Sa syntaxe est la suivante : ```yaml {{- define "MY.NAME" }} # corps du template ici {{- end }} ``` Par exemple, nous pouvons définir un template pour encapsuler un bloc de labels Kubernetes : ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Nous pouvons maintenant intégrer ce template dans notre ConfigMap existant, puis l'inclure avec l'action `template` : ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Lorsque le moteur de template lit ce fichier, il stocke la référence à `mychart.labels` jusqu'à ce que `template "mychart.labels"` soit appelé. Il rend alors ce template en ligne. Le résultat ressemblera à ceci : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Remarque : un `define` ne produit pas de sortie à moins d'être appelé avec un template, comme dans cet exemple. Par convention, les charts Helm placent ces templates dans un fichier de partials, généralement `_helpers.tpl`. Déplaçons cette fonction là-bas : ```yaml {{/* Génère les labels de base */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Par convention, les fonctions `define` devraient avoir un simple bloc de documentation (`{{/* ... */}}`) décrivant ce qu'elles font. Même si cette définition est dans `_helpers.tpl`, elle peut toujours être accédée dans `configmap.yaml` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Comme mentionné ci-dessus, **les noms de templates sont globaux**. Par conséquent, si deux templates sont déclarés avec le même nom, la dernière occurrence sera celle utilisée. Comme les templates des sous-charts sont compilés avec les templates de niveau supérieur, il est préférable de nommer vos templates avec des _noms spécifiques au chart_. Une convention de nommage répandue consiste à préfixer chaque template défini avec le nom du chart : `{{ define "mychart.labels" }}`. ## Définir la portée d'un template Dans le template que nous avons défini ci-dessus, nous n'avons utilisé aucun objet. Nous avons juste utilisé des fonctions. Modifions notre template défini pour inclure le nom du chart et la version du chart : ```yaml {{/* Génère les labels de base */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Si nous rendons ceci, nous obtiendrons une erreur comme celle-ci : ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Pour voir ce qui a été rendu, relancez avec `--disable-openapi-validation` : `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Le résultat ne sera pas celui attendu : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Que s'est-il passé avec le nom et la version ? Ils n'étaient pas dans la portée de notre template défini. Lorsqu'un template nommé (créé avec `define`) est rendu, il reçoit la portée passée par l'appel à `template`. Dans notre exemple, nous avons inclus le template comme ceci : ```yaml {{- template "mychart.labels" }} ``` Aucune portée n'a été passée, donc à l'intérieur du template nous ne pouvons accéder à rien dans `.`. La solution est simple : il suffit de passer une portée au template : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Notez que nous passons `.` à la fin de l'appel `template`. Nous pourrions tout aussi bien passer `.Values` ou `.Values.favorite` ou n'importe quelle portée souhaitée. Mais ce que nous voulons, c'est la portée de niveau supérieur. Dans le contexte du template nommé, `$` fera référence à la portée que vous avez passée et non à une portée globale. Maintenant, lorsque nous exécutons ce template avec `helm install --dry-run --debug plinking-anaco ./mychart`, nous obtenons ceci : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Maintenant `{{ .Chart.Name }}` se résout en `mychart`, et `{{ .Chart.Version }}` se résout en `0.1.0`. ## La fonction `include` Supposons que nous ayons défini un template simple qui ressemble à ceci : ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Maintenant, supposons que je veuille insérer ceci à la fois dans la section `labels:` de mon template et aussi dans la section `data:` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Si nous rendons ceci, nous obtiendrons une erreur comme celle-ci : ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Pour voir ce qui a été rendu, relancez avec `--disable-openapi-validation` : `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. La sortie ne sera pas celle attendue : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Notez que l'indentation de `app_version` est incorrecte aux deux endroits. Pourquoi ? Parce que le template substitué a le texte aligné à gauche. Comme `template` est une action et non une fonction, il n'y a aucun moyen de passer la sortie d'un appel `template` à d'autres fonctions ; les données sont simplement insérées en ligne. Pour contourner ce cas, Helm fournit une alternative à `template` qui importera le contenu d'un template dans le pipeline actuel où il peut être passé à d'autres fonctions dans le pipeline. Voici l'exemple ci-dessus, corrigé pour utiliser `indent` afin d'indenter correctement le template `mychart.app` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Maintenant le YAML produit est correctement indenté pour chaque section : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Il est préférable d'utiliser `include` plutôt que `template` dans les templates Helm, simplement pour que le formatage de la sortie puisse être mieux géré pour les documents YAML. Parfois, nous voulons importer du contenu, mais pas en tant que templates. C'est-à-dire que nous voulons importer des fichiers tels quels. Nous pouvons y parvenir en accédant aux fichiers via l'objet `.Files` décrit dans la section suivante. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Créer un fichier NOTES.txt description: Comment fournir des instructions aux utilisateurs de votre Chart. sidebar_position: 10 --- Dans cette section, nous allons examiner l'outil Helm permettant de fournir des instructions aux utilisateurs de votre chart. À la fin d'un `helm install` ou d'un `helm upgrade`, Helm peut afficher un bloc d'informations utiles pour les utilisateurs. Ces informations sont entièrement personnalisables à l'aide des templates. Pour ajouter des notes d'installation à votre chart, créez simplement un fichier `templates/NOTES.txt`. Ce fichier est en texte brut, mais il est traité comme un template et a accès à toutes les fonctions et objets de template habituels. Créons un simple fichier `NOTES.txt` : ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Maintenant, si nous exécutons `helm install rude-cardinal ./mychart`, nous verrons ce message en bas : ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Utiliser `NOTES.txt` de cette manière est un excellent moyen de fournir à vos utilisateurs des informations détaillées sur l'utilisation de leur chart nouvellement installé. La création d'un fichier `NOTES.txt` est fortement recommandée, même si elle n'est pas obligatoire. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Sous-charts et Valeurs Globales description: Interaction avec les valeurs d'un sous-chart et les valeurs globales. sidebar_position: 11 --- Jusqu'à présent, nous avons travaillé uniquement avec un seul chart. Cependant, les charts peuvent avoir des dépendances, appelées _sous-charts_, qui possèdent également leurs propres valeurs et templates. Dans cette section, nous allons créer un sous-chart et découvrir les différentes façons d'accéder aux valeurs depuis les templates. Avant de plonger dans le code, voici quelques détails importants à connaître sur les sous-charts d'application. 1. Un sous-chart est considéré comme « autonome », ce qui signifie qu'il ne peut jamais dépendre explicitement de son chart parent. 2. Pour cette raison, un sous-chart ne peut pas accéder aux valeurs de son chart parent. 3. Un chart parent peut remplacer les valeurs des sous-charts. 4. Helm dispose d'un concept de _valeurs globales_ accessibles par tous les charts. > Ces limitations ne s'appliquent pas nécessairement aux [charts de bibliothèque](/topics/library_charts.md), qui sont conçus pour fournir des fonctionnalités d'aide standardisées. Au fil des exemples de cette section, ces concepts deviendront plus clairs. ## Création d'un Sous-chart Pour ces exercices, nous partirons du chart `mychart/` que nous avons créé au début de ce guide, et nous ajouterons un nouveau chart à l'intérieur. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Remarquez que, comme précédemment, nous avons supprimé tous les templates de base afin de repartir de zéro. Dans ce guide, nous nous concentrons sur le fonctionnement des templates, et non sur la gestion des dépendances. Cependant, le [Guide des Charts](/topics/charts.md) contient plus d'informations sur le fonctionnement des sous-charts. ## Ajout de Valeurs et d'un Template au Sous-chart Ensuite, créons un simple template et un fichier values pour notre chart `mysubchart`. Un fichier `values.yaml` devrait déjà exister dans `mychart/charts/mysubchart`. Configurons-le ainsi : ```yaml dessert: cake ``` Ensuite, nous allons créer un nouveau template ConfigMap dans `mychart/charts/mysubchart/templates/configmap.yaml` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Comme chaque sous-chart est un _chart autonome_, nous pouvons tester `mysubchart` indépendamment : ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Remplacement des Valeurs depuis un Chart Parent Notre chart original, `mychart`, est maintenant le _chart parent_ de `mysubchart`. Cette relation est entièrement basée sur le fait que `mysubchart` se trouve dans `mychart/charts`. Puisque `mychart` est un parent, nous pouvons spécifier une configuration dans `mychart` et la propager dans `mysubchart`. Par exemple, nous pouvons modifier `mychart/values.yaml` ainsi : ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Notez les deux dernières lignes. Toute directive à l'intérieur de la section `mysubchart` sera envoyée au chart `mysubchart`. Donc, si nous exécutons `helm install --generate-name --dry-run --debug mychart`, l'une des choses que nous verrons est le ConfigMap de `mysubchart` : ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` La valeur au niveau supérieur a maintenant remplacé la valeur du sous-chart. Il y a un détail important à noter ici. Nous n'avons pas modifié le template de `mychart/charts/mysubchart/templates/configmap.yaml` pour pointer vers `.Values.mysubchart.dessert`. Du point de vue de ce template, la valeur se trouve toujours à `.Values.dessert`. Lorsque le moteur de templates transmet les valeurs, il définit la portée. Ainsi, pour les templates de `mysubchart`, seules les valeurs spécifiquement destinées à `mysubchart` seront disponibles dans `.Values`. Parfois, cependant, vous souhaitez que certaines valeurs soient disponibles pour tous les templates. Cela s'accomplit en utilisant les valeurs globales de chart. ## Valeurs Globales de Chart Les valeurs globales sont des valeurs accessibles depuis n'importe quel chart ou sous-chart avec exactement le même nom. Les valeurs globales nécessitent une déclaration explicite. Vous ne pouvez pas utiliser une valeur non globale existante comme si elle était globale. Le type de données Values possède une section réservée appelée `Values.global` où les valeurs globales peuvent être définies. Définissons-en une dans notre fichier `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Grâce au fonctionnement des valeurs globales, `mychart/templates/configmap.yaml` et `mysubchart/templates/configmap.yaml` devraient pouvoir accéder à cette valeur via `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml` : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Maintenant, si nous effectuons une installation dry-run, nous verrons la même valeur dans les deux sorties : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Les valeurs globales sont utiles pour transmettre ce type d'information, bien qu'elles nécessitent une certaine planification pour s'assurer que les bons templates sont configurés pour les utiliser. ## Partage de Templates avec les Sous-charts Les charts parents et les sous-charts peuvent partager des templates. Tout bloc défini dans n'importe quel chart est disponible pour les autres charts. Par exemple, nous pouvons définir un simple template comme ceci : ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Rappelez-vous que les labels sur les templates sont _partagés globalement_. Ainsi, le chart `labels` peut être inclus depuis n'importe quel autre chart. Bien que les développeurs de charts aient le choix entre `include` et `template`, un avantage d'utiliser `include` est que `include` peut référencer dynamiquement des templates : ```yaml {{ include $mytemplate }} ``` L'exemple ci-dessus déréférencera `$mytemplate`. La fonction `template`, en revanche, n'accepte qu'une chaîne littérale. ## Éviter l'Utilisation des Blocs Le langage de template Go fournit un mot-clé `block` qui permet aux développeurs de fournir une implémentation par défaut qui sera remplacée ultérieurement. Dans les charts Helm, les blocs ne sont pas le meilleur outil pour le remplacement car si plusieurs implémentations du même bloc sont fournies, celle sélectionnée est imprévisible. Nous recommandons d'utiliser `include` à la place. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Fichiers Values description: Instructions sur l'utilisation du flag --values. sidebar_position: 4 --- Dans la section précédente, nous avons examiné les objets intégrés que les templates Helm proposent. L'un de ces objets intégrés est `Values`. Cet objet donne accès aux valeurs passées dans le chart. Son contenu provient de plusieurs sources : - Le fichier `values.yaml` du chart - Si c'est un sous-chart, le fichier `values.yaml` du chart parent - Un fichier values passé à `helm install` ou `helm upgrade` avec le flag `-f` (`helm install -f myvals.yaml ./mychart`) - Des paramètres individuels passés avec `--set` (par exemple `helm install --set foo=bar ./mychart`) La liste ci-dessus est ordonnée par spécificité : `values.yaml` est la valeur par défaut, qui peut être remplacée par le `values.yaml` d'un chart parent, qui peut à son tour être remplacé par un fichier values fourni par l'utilisateur, qui peut lui-même être remplacé par les paramètres `--set`. Les fichiers values sont de simples fichiers YAML. Modifions `mychart/values.yaml`, puis éditons notre template ConfigMap. En supprimant les valeurs par défaut dans `values.yaml`, nous définirons un seul paramètre : ```yaml favoriteDrink: coffee ``` Nous pouvons maintenant l'utiliser dans un template : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Remarquez qu'à la dernière ligne, nous accédons à `favoriteDrink` comme attribut de `Values` : `{{ .Values.favoriteDrink }}`. Voyons comment cela est rendu. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Puisque `favoriteDrink` est défini dans le fichier `values.yaml` par défaut à `coffee`, c'est la valeur affichée dans le template. Nous pouvons facilement la remplacer en ajoutant un flag `--set` dans notre appel à `helm install` : ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Puisque `--set` a une priorité plus élevée que le fichier `values.yaml` par défaut, notre template génère `drink: slurm`. Les fichiers values peuvent également contenir du contenu plus structuré. Par exemple, nous pourrions créer une section `favorite` dans notre fichier `values.yaml`, puis y ajouter plusieurs clés : ```yaml favorite: drink: coffee food: pizza ``` Il faudrait alors modifier légèrement le template : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Bien que structurer les données de cette façon soit possible, la recommandation est de garder vos arbres de valeurs peu imbriqués, en privilégiant une structure plate. Lorsque nous examinerons l'assignation de valeurs aux sous-charts, nous verrons comment les valeurs sont nommées en utilisant une structure arborescente. ## Supprimer une clé par défaut Si vous avez besoin de supprimer une clé des valeurs par défaut, vous pouvez remplacer la valeur de cette clé par `null`, auquel cas Helm supprimera la clé lors de la fusion des valeurs surchargées. Par exemple, le chart Drupal stable permet de configurer la sonde de vivacité (liveness probe), au cas où vous configureriez une image personnalisée. Voici les valeurs par défaut : ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Si vous essayez de remplacer le handler livenessProbe par `exec` au lieu de `httpGet` en utilisant `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm fusionnera les clés par défaut et celles surchargées, produisant le YAML suivant : ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Cependant, Kubernetes échouera car vous ne pouvez pas déclarer plus d'un handler livenessProbe. Pour contourner ce problème, vous pouvez demander à Helm de supprimer `livenessProbe.httpGet` en le définissant à null : ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` À ce stade, nous avons vu plusieurs objets intégrés et les avons utilisés pour injecter des informations dans un template. Nous allons maintenant examiner un autre aspect du moteur de templates : les fonctions et les pipelines. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Variables description: Utilisation des variables dans les templates. sidebar_position: 8 --- Après avoir abordé les fonctions, les pipelines, les objets et les structures de contrôle, nous pouvons nous tourner vers l'un des concepts les plus fondamentaux de nombreux langages de programmation : les variables. Dans les templates, elles sont moins fréquemment utilisées. Mais nous allons voir comment les utiliser pour simplifier le code et mieux exploiter `with` et `range`. Dans un exemple précédent, nous avons vu que ce code échouera : ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` n'est pas dans la portée restreinte du bloc `with`. Une façon de contourner les problèmes de portée est d'assigner des objets à des variables qui peuvent être accédées indépendamment de la portée actuelle. Dans les templates Helm, une variable est une référence nommée vers un autre objet. Elle suit la forme `$name`. Les variables sont assignées avec un opérateur d'assignation spécial : `:=`. Nous pouvons réécrire l'exemple ci-dessus en utilisant une variable pour `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Notez qu'avant de commencer le bloc `with`, nous assignons `$relname := .Release.Name`. Maintenant, à l'intérieur du bloc `with`, la variable `$relname` pointe toujours vers le nom de la release. L'exécution de ce code produira : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Les variables sont particulièrement utiles dans les boucles `range`. Elles peuvent être utilisées sur des objets de type liste pour capturer à la fois l'index et la valeur : ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Notez que `range` vient en premier, puis les variables, puis l'opérateur d'assignation, et enfin la liste. Cela assignera l'index entier (à partir de zéro) à `$index` et la valeur à `$topping`. L'exécution produira : ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Pour les structures de données qui ont à la fois une clé et une valeur, nous pouvons utiliser `range` pour obtenir les deux. Par exemple, nous pouvons parcourir `.Values.favorite` comme ceci : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Lors de la première itération, `$key` sera `drink` et `$val` sera `coffee`, et lors de la seconde, `$key` sera `food` et `$val` sera `pizza`. L'exécution du code ci-dessus générera : ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Les variables ne sont normalement pas « globales ». Elles sont limitées au bloc dans lequel elles sont déclarées. Plus tôt, nous avons assigné `$relname` au niveau supérieur du template. Cette variable sera dans la portée de l'ensemble du template. Mais dans notre dernier exemple, `$key` et `$val` ne seront dans la portée qu'à l'intérieur du bloc `{{ range... }}{{ end }}`. Cependant, il existe une variable qui pointe toujours vers le contexte racine : `$`. Cela peut être très utile lorsque vous itérez dans une boucle `range` et que vous avez besoin de connaître le nom de la release du chart. Voici un exemple illustrant cela : ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # De nombreux templates Helm utiliseraient `.` ci-dessous, mais cela ne fonctionnera pas, # cependant `$` fonctionnera ici app.kubernetes.io/name: {{ template "fullname" $ }} # Je ne peux pas référencer .Chart.Name, mais je peux faire $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Valeur de appVersion dans Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` Jusqu'ici, nous n'avons examiné qu'un seul template déclaré dans un seul fichier. Mais l'une des fonctionnalités puissantes du langage de template Helm est sa capacité à déclarer plusieurs templates et à les utiliser ensemble. Nous aborderons cela dans la prochaine section. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Prochaines étapes description: Conclusion - quelques liens utiles vers d'autres documentations qui vous aideront. sidebar_position: 14 --- Ce guide est destiné à vous fournir, en tant que développeur de charts, une bonne maîtrise du langage de template de Helm. Il met l'accent sur les aspects techniques du développement de templates. Cependant, de nombreux sujets liés au développement pratique de charts au quotidien n'ont pas été abordés ici. Voici quelques liens utiles vers d'autres documentations qui vous aideront lors de la création de nouveaux charts : - [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF est une source incontournable de charts. - La [documentation](https://kubernetes.io/docs/home/) Kubernetes fournit des exemples détaillés des différents types de ressources que vous pouvez utiliser, des ConfigMaps et Secrets aux DaemonSets et Deployments. - Le [guide des charts](/topics/charts.md) Helm explique le flux de travail pour l'utilisation des charts. - Le [guide des hooks de charts](/topics/charts_hooks.md) Helm explique comment créer des hooks de cycle de vie. - L'article [Astuces et conseils pour les charts](/howto/charts_tips_and_tricks.md) Helm fournit des conseils utiles pour la rédaction de charts. - La [documentation Sprig](https://github.com/Masterminds/sprig) documente plus de soixante fonctions de template. - La [documentation des templates Go](https://godoc.org/text/template) explique la syntaxe des templates en détail. - L'outil [Schelm](https://github.com/databus23/schelm) est un utilitaire pratique pour le débogage des charts. Parfois, il est plus facile de poser quelques questions et d'obtenir des réponses de développeurs expérimentés. Le meilleur endroit pour cela est sur les canaux Helm du [Slack Kubernetes](https://kubernetes.slack.com) : - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Enfin, si vous trouvez des erreurs ou des omissions dans ce document, souhaitez suggérer du nouveau contenu ou aimeriez contribuer, visitez [le projet Helm](https://github.com/helm/helm-www). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Annexe : Techniques YAML" description: Un examen approfondi de la spécification YAML et de son application dans Helm. sidebar_position: 15 --- Ce guide s'est principalement concentré sur l'écriture du langage de template. Ici, nous allons examiner le format YAML. YAML possède des fonctionnalités utiles que nous, en tant qu'auteurs de templates, pouvons utiliser pour rendre nos templates moins sujets aux erreurs et plus faciles à lire. ## Scalaires et collections Selon la [spécification YAML](https://yaml.org/spec/1.2/spec.html), il existe deux types de collections et de nombreux types scalaires. Les deux types de collections sont les maps et les séquences : ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Les valeurs scalaires sont des valeurs individuelles (par opposition aux collections). ### Types scalaires en YAML Dans le dialecte YAML de Helm, le type de données scalaire d'une valeur est déterminé par un ensemble de règles complexes, incluant le schéma Kubernetes pour les définitions de ressources. Mais lors de l'inférence des types, les règles suivantes tendent à s'appliquer. Si un entier ou un flottant est un mot non quoté, il est généralement traité comme un type numérique : ```yaml count: 1 size: 2.34 ``` Mais s'ils sont entre guillemets, ils sont traités comme des chaînes : ```yaml count: "1" # <-- chaîne, pas int size: '2.34' # <-- chaîne, pas float ``` Il en va de même pour les booléens : ```yaml isGood: true # bool answer: "true" # chaîne ``` Le mot pour une valeur vide est `null` (pas `nil`). Notez que `port: "80"` est du YAML valide, et passera à travers le moteur de template et l'analyseur YAML, mais échouera si Kubernetes attend que `port` soit un entier. Dans certains cas, vous pouvez forcer une inférence de type particulière en utilisant les balises de nœud YAML : ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` Dans l'exemple ci-dessus, `!!str` indique à l'analyseur que `age` est une chaîne, même s'il ressemble à un entier. Et `port` est traité comme un entier, même s'il est entre guillemets. ## Les chaînes de caractères en YAML Une grande partie des données que nous plaçons dans les documents YAML sont des chaînes de caractères. YAML propose plus d'une façon de représenter une chaîne. Cette section explique les différentes méthodes et montre comment en utiliser certaines. Il existe trois façons « en ligne » de déclarer une chaîne : ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Tous les styles en ligne doivent tenir sur une seule ligne. - Les mots non quotés (*bare words*) ne sont pas échappés. Pour cette raison, vous devez faire attention aux caractères que vous utilisez. - Les chaînes entre guillemets doubles peuvent avoir des caractères spécifiques échappés avec `\`. Par exemple `"\"Hello\", she said"`. Vous pouvez échapper les sauts de ligne avec `\n`. - Les chaînes entre guillemets simples sont des chaînes « littérales » et n'utilisent pas le `\` pour échapper les caractères. La seule séquence d'échappement est `''`, qui est décodée comme un seul `'`. En plus des chaînes sur une seule ligne, vous pouvez déclarer des chaînes multi-lignes : ```yaml coffee: | Latte Cappuccino Espresso ``` L'exemple ci-dessus traitera la valeur de `coffee` comme une chaîne unique équivalente à `Latte\nCappuccino\nEspresso\n`. Notez que la première ligne après le `|` doit être correctement indentée. Nous pourrions donc casser l'exemple ci-dessus en faisant ceci : ```yaml coffee: | Latte Cappuccino Espresso ``` Comme `Latte` est incorrectement indenté, nous obtiendrions une erreur comme celle-ci : ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` Dans les templates, il est parfois plus sûr de mettre une fausse « première ligne » de contenu dans un document multi-lignes juste pour se protéger de l'erreur ci-dessus : ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Notez que quelle que soit cette première ligne, elle sera conservée dans la sortie de la chaîne. Donc si vous utilisez, par exemple, cette technique pour injecter le contenu d'un fichier dans un ConfigMap, le commentaire doit être du type attendu par ce qui lit cette entrée. ### Contrôler les espaces dans les chaînes multi-lignes Dans l'exemple ci-dessus, nous avons utilisé `|` pour indiquer une chaîne multi-lignes. Mais remarquez que le contenu de notre chaîne était suivi d'un `\n` final. Si nous voulons que le processeur YAML supprime le saut de ligne final, nous pouvons ajouter un `-` après le `|` : ```yaml coffee: |- Latte Cappuccino Espresso ``` Maintenant la valeur de `coffee` sera : `Latte\nCappuccino\nEspresso` (sans `\n` final). D'autres fois, nous pourrions vouloir préserver tous les espaces blancs finaux. Nous pouvons le faire avec la notation `|+` : ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Maintenant la valeur de `coffee` sera `Latte\nCappuccino\nEspresso\n\n\n`. L'indentation à l'intérieur d'un bloc de texte est préservée, et entraîne également la préservation des sauts de ligne : ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` Dans le cas ci-dessus, `coffee` sera `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indentation et templates Lors de l'écriture de templates, vous pourriez vouloir injecter le contenu d'un fichier dans le template. Comme nous l'avons vu dans les chapitres précédents, il existe deux façons de le faire : - Utilisez `{{ .Files.Get "FILENAME" }}` pour obtenir le contenu d'un fichier dans le chart. - Utilisez `{{ include "TEMPLATE" . }}` pour rendre un template et ensuite placer son contenu dans le chart. Lors de l'insertion de fichiers dans du YAML, il est bon de comprendre les règles multi-lignes ci-dessus. Souvent, la façon la plus simple d'insérer un fichier statique est de faire quelque chose comme ceci : ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Notez comment nous faisons l'indentation ci-dessus : `indent 2` indique au moteur de template d'indenter chaque ligne de « myfile.txt » avec deux espaces. Notez que nous n'indentons pas cette ligne de template. C'est parce que si nous le faisions, le contenu du fichier de la première ligne serait indenté deux fois. ### Chaînes multi-lignes repliées Parfois vous voulez représenter une chaîne dans votre YAML avec plusieurs lignes, mais vous voulez qu'elle soit traitée comme une longue ligne lors de l'interprétation. Cela s'appelle le « repliement ». Pour déclarer un bloc replié, utilisez `>` au lieu de `|` : ```yaml coffee: > Latte Cappuccino Espresso ``` La valeur de `coffee` ci-dessus sera `Latte Cappuccino Espresso\n`. Notez que tous les sauts de ligne sauf le dernier seront convertis en espaces. Vous pouvez combiner les contrôles d'espaces blancs avec le marqueur de texte replié, donc `>-` remplacera ou supprimera tous les sauts de ligne. Notez que dans la syntaxe repliée, l'indentation du texte entraînera la préservation des lignes. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` L'exemple ci-dessus produira `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Notez que les espaces et les sauts de ligne sont toujours présents. ## Intégrer plusieurs documents dans un seul fichier Il est possible de placer plus d'un document YAML dans un seul fichier. Cela se fait en préfixant un nouveau document avec `---` et en terminant le document avec `...` ```yaml --- document: 1 ... --- document: 2 ... ``` Dans de nombreux cas, le `---` ou le `...` peuvent être omis. Certains fichiers dans Helm ne peuvent pas contenir plus d'un document. Si, par exemple, plus d'un document est fourni à l'intérieur d'un fichier `values.yaml`, seul le premier sera utilisé. Les fichiers de template, cependant, peuvent avoir plus d'un document. Lorsque c'est le cas, le fichier (et tous ses documents) est traité comme un seul objet pendant le rendu du template. Mais ensuite le YAML résultant est divisé en plusieurs documents avant d'être envoyé à Kubernetes. Nous recommandons de n'utiliser plusieurs documents par fichier que lorsque c'est absolument nécessaire. Avoir plusieurs documents dans un fichier peut être difficile à déboguer. ## YAML est un sur-ensemble de JSON Parce que YAML est un sur-ensemble de JSON, tout document JSON valide _devrait_ être du YAML valide. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` L'exemple ci-dessus est une autre façon de représenter ceci : ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` Et les deux peuvent être mélangés (avec précaution) : ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Ces trois exemples devraient être analysés vers la même représentation interne. Bien que cela signifie que des fichiers comme `values.yaml` peuvent contenir des données JSON, Helm ne traite pas l'extension de fichier `.json` comme un suffixe valide. ## Ancres YAML La spécification YAML fournit un moyen de stocker une référence à une valeur, et plus tard de se référer à cette valeur par référence. YAML appelle cela l'« ancrage » : ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` Dans l'exemple ci-dessus, `&favoriteCoffee` définit une référence à `Cappuccino`. Plus tard, cette référence est utilisée comme `*favoriteCoffee`. Donc `coffees` devient `Latte, Cappuccino, Espresso`. Bien qu'il existe quelques cas où les ancres sont utiles, il y a un aspect qui peut causer des bugs subtils : la première fois que le YAML est consommé, la référence est développée puis supprimée. Donc si nous devions décoder puis ré-encoder l'exemple ci-dessus, le YAML résultant serait : ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Parce que Helm et Kubernetes lisent, modifient et réécrivent souvent les fichiers YAML, les ancres seront perdues. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Changements depuis Helm 2 sidebar_position: 1 --- ## Changements depuis Helm 2 Voici une liste exhaustive de tous les changements majeurs introduits dans Helm 3. ### Suppression de Tiller Durant le cycle de développement de Helm 2, nous avons introduit Tiller. Tiller jouait un rôle important pour les équipes travaillant sur un cluster partagé : il permettait à plusieurs opérateurs différents d'interagir avec le même ensemble de releases. Avec le contrôle d'accès basé sur les rôles (RBAC) activé par défaut dans Kubernetes 1.6, sécuriser Tiller pour une utilisation en production est devenu plus difficile à gérer. En raison du grand nombre de politiques de sécurité possibles, notre position était de fournir une configuration permissive par défaut. Cela permettait aux nouveaux utilisateurs de commencer à expérimenter avec Helm et Kubernetes sans avoir à plonger directement dans les contrôles de sécurité. Malheureusement, cette configuration permissive pouvait accorder à un utilisateur un large éventail de permissions qu'il n'était pas censé avoir. Les équipes DevOps et SRE devaient apprendre des étapes opérationnelles supplémentaires lors de l'installation de Tiller dans un cluster multi-tenant. Après avoir écouté comment les membres de la communauté utilisaient Helm dans certains scénarios, nous avons constaté que le système de gestion des releases de Tiller n'avait pas besoin de s'appuyer sur un opérateur dans le cluster pour maintenir l'état ou servir de hub central pour les informations de release Helm. Au lieu de cela, nous pouvions simplement récupérer les informations depuis le serveur API Kubernetes, effectuer le rendu des Charts côté client, et stocker un enregistrement de l'installation dans Kubernetes. L'objectif principal de Tiller pouvait être atteint sans Tiller, c'est pourquoi l'une des premières décisions que nous avons prises concernant Helm 3 a été de supprimer complètement Tiller. Avec la disparition de Tiller, le modèle de sécurité de Helm est radicalement simplifié. Helm 3 prend désormais en charge toutes les fonctionnalités modernes de sécurité, d'identité et d'autorisation de Kubernetes moderne. Les permissions de Helm sont évaluées en utilisant votre [fichier kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Les administrateurs de cluster peuvent restreindre les permissions des utilisateurs avec la granularité qu'ils jugent appropriée. Les releases sont toujours enregistrées dans le cluster, et le reste des fonctionnalités de Helm reste inchangé. ### Stratégie de mise à niveau améliorée : correctifs de fusion stratégique à 3 voies Helm 2 utilisait un correctif de fusion stratégique à deux voies. Lors d'une mise à niveau, il comparait le manifeste du chart le plus récent avec le manifeste du chart proposé (celui fourni lors de `helm upgrade`). Il comparait les différences entre ces deux charts pour déterminer quels changements devaient être appliqués aux ressources dans Kubernetes. Si des changements étaient appliqués au cluster hors bande (par exemple lors d'un `kubectl edit`), ces changements n'étaient pas pris en compte. Cela empêchait les ressources de revenir à leur état précédent : parce que Helm ne considérait que le manifeste du dernier chart appliqué comme son état actuel, s'il n'y avait pas de changements dans l'état du chart, l'état actif restait inchangé. Dans Helm 3, nous utilisons maintenant un correctif de fusion stratégique à trois voies. Helm prend en compte l'ancien manifeste, son état actif et le nouveau manifeste lors de la génération d'un correctif. #### Exemples Passons en revue quelques exemples courants pour illustrer l'impact de ce changement. ##### Retour en arrière lorsque l'état actif a changé Votre équipe vient de déployer son application en production sur Kubernetes en utilisant Helm. Le chart contient un objet Deployment où le nombre de réplicas est défini à trois : ```console $ helm install myapp ./myapp ``` Un nouveau développeur rejoint l'équipe. Le premier jour, en observant le cluster de production, un terrible accident de café renversé sur le clavier se produit et il exécute `kubectl scale` sur le déploiement de production, passant de trois réplicas à zéro. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Un autre développeur de votre équipe remarque que le site de production est hors service et décide de restaurer la release à son état précédent : ```console $ helm rollback myapp ``` Que se passe-t-il ? Dans Helm 2, un correctif serait généré en comparant l'ancien manifeste avec le nouveau manifeste. Comme il s'agit d'un rollback, c'est le même manifeste. Helm déterminerait qu'il n'y a rien à changer car il n'y a pas de différence entre l'ancien manifeste et le nouveau manifeste. Le nombre de réplicas reste à zéro. C'est la panique. Dans Helm 3, le correctif est généré en utilisant l'ancien manifeste, l'état actif et le nouveau manifeste. Helm reconnaît que l'ancien état était à trois, que l'état actif est à zéro et que le nouveau manifeste souhaite le ramener à trois, il génère donc un correctif pour remettre l'état à trois. ##### Mises à niveau lorsque l'état actif a changé De nombreux service meshes et autres applications basées sur des contrôleurs injectent des données dans les objets Kubernetes. Cela peut être un sidecar, des labels ou d'autres informations. Auparavant, si vous aviez le manifeste suivant rendu depuis un Chart : ```yaml containers: - name: server image: nginx:2.0.0 ``` Et que l'état actif avait été modifié par une autre application pour devenir : ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Maintenant, vous voulez mettre à jour le tag de l'image `nginx` vers `2.1.0`. Vous effectuez donc une mise à niveau vers un chart avec le manifeste suivant : ```yaml containers: - name: server image: nginx:2.1.0 ``` Que se passe-t-il ? Dans Helm 2, Helm génère un correctif de l'objet `containers` entre l'ancien manifeste et le nouveau manifeste. L'état actif du cluster n'est pas pris en compte lors de la génération du correctif. L'état actif du cluster est modifié pour ressembler à ceci : ```yaml containers: - name: server image: nginx:2.1.0 ``` Le pod sidecar est supprimé de l'état actif. Encore plus de panique. Dans Helm 3, Helm génère un correctif de l'objet `containers` entre l'ancien manifeste, l'état actif et le nouveau manifeste. Il remarque que le nouveau manifeste change le tag de l'image vers `2.1.0`, mais que l'état actif contient un conteneur sidecar. L'état actif du cluster est modifié pour ressembler à ceci : ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Les noms de releases sont maintenant limités au namespace Avec la suppression de Tiller, les informations sur chaque release devaient être stockées quelque part. Dans Helm 2, elles étaient stockées dans le même namespace que Tiller. En pratique, cela signifiait qu'une fois qu'un nom était utilisé par une release, aucune autre release ne pouvait utiliser ce même nom, même si elle était déployée dans un namespace différent. Dans Helm 3, les informations sur une release particulière sont maintenant stockées dans le même namespace que la release elle-même. Cela signifie que les utilisateurs peuvent maintenant exécuter `helm install wordpress stable/wordpress` dans deux namespaces séparés, et chacune peut être référencée avec `helm list` en changeant le contexte du namespace actuel (par exemple `helm list --namespace foo`). Avec ce meilleur alignement sur les namespaces natifs du cluster, la commande `helm list` ne liste plus toutes les releases par défaut. Au lieu de cela, elle ne liste que les releases dans le namespace de votre contexte Kubernetes actuel (c'est-à-dire le namespace affiché lorsque vous exécutez `kubectl config view --minify`). Cela signifie également que vous devez fournir le flag `--all-namespaces` à `helm list` pour obtenir un comportement similaire à Helm 2. ### Les Secrets comme backend de stockage par défaut Dans Helm 3, les Secrets sont maintenant utilisés comme [backend de stockage par défaut](/topics/advanced.md#storage-backends). Helm 2 utilisait les ConfigMaps par défaut pour stocker les informations de release. Dans Helm 2.7.0, un nouveau backend de stockage utilisant des Secrets pour stocker les informations de release a été implémenté, et c'est maintenant le backend par défaut à partir de Helm 3. Le passage aux Secrets comme valeur par défaut de Helm 3 permet une sécurité supplémentaire pour protéger les charts en conjonction avec le chiffrement des Secrets dans Kubernetes. [Le chiffrement des secrets au repos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) est devenu disponible en tant que fonctionnalité alpha dans Kubernetes 1.7 et est devenu stable à partir de Kubernetes 1.13. Cela permet aux utilisateurs de chiffrer les métadonnées de release Helm au repos, ce qui constitue un bon point de départ qui peut être étendu ultérieurement à l'utilisation de quelque chose comme Vault. ### Changements du chemin d'import Go Dans Helm 3, Helm a changé le chemin d'import Go de `k8s.io/helm` vers `helm.sh/helm/v3`. Si vous avez l'intention de mettre à niveau vers les bibliothèques clientes Go de Helm 3, assurez-vous de modifier vos chemins d'import. ### Capabilities L'objet intégré `.Capabilities` disponible pendant la phase de rendu a été simplifié. [Objets intégrés](/chart_template_guide/builtin_objects.md) ### Validation des valeurs de chart avec JSONSchema Un schéma JSON peut maintenant être imposé aux valeurs de chart. Cela garantit que les valeurs fournies par l'utilisateur suivent le schéma défini par le mainteneur du chart, fournissant un meilleur rapport d'erreurs lorsque l'utilisateur fournit un ensemble incorrect de valeurs pour un chart. La validation se produit lorsque l'une des commandes suivantes est invoquée : * `helm install` * `helm upgrade` * `helm template` * `helm lint` Consultez la documentation sur les [fichiers de schéma](/topics/charts.md#schema-files) pour plus d'informations. ### Consolidation de `requirements.yaml` dans `Chart.yaml` Le système de gestion des dépendances de chart a été déplacé de requirements.yaml et requirements.lock vers Chart.yaml et Chart.lock. Nous recommandons que les nouveaux charts destinés à Helm 3 utilisent le nouveau format. Cependant, Helm 3 comprend toujours la version 1 de l'API Chart (`v1`) et chargera les fichiers `requirements.yaml` existants. Dans Helm 2, voici à quoi ressemblait un `requirements.yaml` : ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Dans Helm 3, la dépendance est exprimée de la même manière, mais maintenant depuis votre `Chart.yaml` : ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Les charts sont toujours téléchargés et placés dans le répertoire `charts/`, donc les sous-charts intégrés dans le répertoire `charts/` continueront à fonctionner sans modification. ### Le nom (ou --generate-name) est maintenant requis lors de l'installation Dans Helm 2, si aucun nom n'était fourni, un nom auto-généré était attribué. En production, cela s'est avéré être plus une nuisance qu'une fonctionnalité utile. Dans Helm 3, Helm génère une erreur si aucun nom n'est fourni avec `helm install`. Pour ceux qui souhaitent toujours avoir un nom auto-généré, vous pouvez utiliser le flag `--generate-name` pour en créer un. ### Publication de charts vers des registres OCI Il s'agit d'une fonctionnalité expérimentale introduite dans Helm 3. Pour l'utiliser, définissez la variable d'environnement `HELM_EXPERIMENTAL_OCI=1`. À un niveau général, un dépôt de charts est un emplacement où les charts peuvent être stockés et partagés. Le client Helm empaquette et envoie les Helm Charts vers un dépôt de charts. En termes simples, un dépôt de charts est un serveur HTTP basique qui héberge un fichier index.yaml et quelques charts empaquetés. Bien que l'API des dépôts de charts présente plusieurs avantages pour répondre aux exigences de stockage les plus basiques, quelques inconvénients ont commencé à apparaître : - Les dépôts de charts ont beaucoup de mal à abstraire la plupart des implémentations de sécurité requises dans un environnement de production. Avoir une API standard pour l'authentification et l'autorisation est très important dans les scénarios de production. - Les outils de provenance de chart de Helm utilisés pour signer et vérifier l'intégrité et l'origine d'un chart sont une partie optionnelle du processus de publication de chart. - Dans les scénarios multi-tenant, le même chart peut être téléchargé par un autre tenant, coûtant deux fois le coût de stockage pour stocker le même contenu. Des dépôts de charts plus intelligents ont été conçus pour gérer cela, mais ce n'est pas une partie de la spécification formelle. - L'utilisation d'un seul fichier index pour la recherche, les informations de métadonnées et la récupération des charts a rendu difficile ou maladroite la conception dans des implémentations multi-tenant sécurisées. Le projet Distribution de Docker (également connu sous le nom de Docker Registry v2) est le successeur du projet Docker Registry. De nombreux grands fournisseurs cloud proposent une offre produit du projet Distribution, et avec tant de fournisseurs offrant le même produit, le projet Distribution a bénéficié de nombreuses années de durcissement, de meilleures pratiques de sécurité et de tests intensifs. Consultez `helm help chart` et `helm help registry` pour plus d'informations sur comment empaqueter un chart et le publier vers un registre Docker. Pour plus d'informations, consultez [cette page](/topics/registries.md). ### Suppression de `helm serve` `helm serve` exécutait un dépôt de charts local sur votre machine à des fins de développement. Cependant, il n'a pas reçu beaucoup d'adoption en tant qu'outil de développement et avait de nombreux problèmes de conception. Finalement, nous avons décidé de le supprimer et de le séparer en tant que plugin. Pour une expérience similaire à `helm serve`, consultez l'option de stockage sur système de fichiers local dans [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) et le [plugin servecm](https://github.com/jdolitsky/helm-servecm). ### Support des charts de type bibliothèque Helm 3 prend en charge une catégorie de chart appelée "chart de bibliothèque". C'est un chart qui est partagé par d'autres charts, mais qui ne crée pas d'artefacts de release par lui-même. Les templates d'un chart de bibliothèque ne peuvent déclarer que des éléments `define`. Le contenu à portée globale non-`define` est simplement ignoré. Cela permet aux utilisateurs de réutiliser et de partager des extraits de code qui peuvent être réutilisés dans de nombreux charts, évitant ainsi la redondance et gardant les charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Les charts de bibliothèque sont déclarés dans la directive dependencies de Chart.yaml, et sont installés et gérés comme n'importe quel autre chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Nous sommes très enthousiastes de voir les cas d'utilisation que cette fonctionnalité ouvre pour les développeurs de charts, ainsi que les meilleures pratiques qui émergeront de l'utilisation des charts de bibliothèque. ### Mise à jour de l'apiVersion de Chart.yaml Avec l'introduction du support des charts de bibliothèque et la consolidation de requirements.yaml dans Chart.yaml, les clients qui comprenaient le format de package de Helm 2 ne comprendront pas ces nouvelles fonctionnalités. Nous avons donc mis à jour l'apiVersion dans Chart.yaml de `v1` vers `v2`. `helm create` crée maintenant des charts en utilisant ce nouveau format, donc l'apiVersion par défaut a également été mise à jour. Les clients souhaitant prendre en charge les deux versions de charts Helm devraient inspecter le champ `apiVersion` dans Chart.yaml pour comprendre comment analyser le format de package. ### Support de la spécification des répertoires de base XDG [La spécification des répertoires de base XDG](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) est un standard portable définissant où les fichiers de configuration, de données et de cache doivent être stockés sur le système de fichiers. Dans Helm 2, Helm stockait toutes ces informations dans `~/.helm` (affectueusement connu sous le nom de `helm home`), qui pouvait être modifié en définissant la variable d'environnement `$HELM_HOME`, ou en utilisant le flag global `--home`. Dans Helm 3, Helm respecte maintenant les variables d'environnement suivantes conformément à la spécification des répertoires de base XDG : - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Les plugins Helm reçoivent toujours `$HELM_HOME` comme alias vers `$XDG_DATA_HOME` pour la rétrocompatibilité avec les plugins qui utilisent `$HELM_HOME` comme environnement de travail. Plusieurs nouvelles variables d'environnement sont également transmises à l'environnement du plugin pour s'adapter à ce changement : - `$HELM_PATH_CACHE` pour le chemin du cache - `$HELM_PATH_CONFIG` pour le chemin de la configuration - `$HELM_PATH_DATA` pour le chemin des données Les plugins Helm souhaitant prendre en charge Helm 3 devraient envisager d'utiliser ces nouvelles variables d'environnement à la place. ### Renommage des commandes CLI Afin de mieux aligner la terminologie avec d'autres gestionnaires de paquets, `helm delete` a été renommé en `helm uninstall`. `helm delete` est toujours conservé comme alias de `helm uninstall`, donc les deux formes peuvent être utilisées. Dans Helm 2, pour purger le registre des releases, le flag `--purge` devait être fourni. Cette fonctionnalité est maintenant activée par défaut. Pour conserver le comportement précédent, utilisez `helm uninstall --keep-history`. De plus, plusieurs autres commandes ont été renommées pour suivre les mêmes conventions : - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Ces commandes ont également conservé leurs anciens verbes comme alias, vous pouvez donc continuer à les utiliser sous l'une ou l'autre forme. ### Création automatique des namespaces Lors de la création d'une release dans un namespace qui n'existe pas, Helm 2 créait le namespace. Helm 3 suit le comportement des autres outils Kubernetes et renvoie une erreur si le namespace n'existe pas. Helm 3 créera le namespace si vous spécifiez explicitement le flag `--create-namespace`. ### Qu'est-il arrivé à .Chart.ApiVersion ? Helm suit la convention typique de CamelCase qui consiste à mettre une majuscule aux acronymes. Nous avons fait cela ailleurs dans le code, comme avec `.Capabilities.APIVersions.Has`. Dans Helm v3, nous avons corrigé `.Chart.ApiVersion` pour suivre ce modèle, en le renommant `.Chart.APIVersion`. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Installation sidebar_position: 2 --- ## Installation ### Pourquoi n'y a-t-il pas de paquets natifs de Helm pour Fedora et d'autres distributions Linux ? Le projet Helm ne maintient pas de paquets pour les systèmes d'exploitation et les environnements. La communauté Helm peut fournir des paquets natifs et si le projet Helm en est informé, ils seront listés. C'est ainsi que la formule Homebrew a été créée et listée. Si vous êtes intéressé par la maintenance d'un paquet, nous serions ravis de vous accompagner. ### Pourquoi fournissez-vous un script `curl ...|bash` ? Il existe un script dans notre dépôt (`scripts/get-helm-3`) qui peut être exécuté sous la forme d'un script `curl ..|bash`. Les transferts sont tous protégés par HTTPS et le script effectue quelques vérifications sur les paquets qu'il télécharge. Cependant, le script présente tous les dangers habituels de tout script shell. Nous le fournissons parce qu'il est utile, mais nous suggérons aux utilisateurs de lire attentivement le script avant de l'exécuter. Ce que nous souhaiterions vraiment, cependant, ce sont de meilleures versions de Helm sous forme de paquets. ### Comment puis-je placer les fichiers du client Helm ailleurs que dans leurs emplacements par défaut ? Helm utilise la structure XDG pour le stockage des fichiers. Il existe des variables d'environnement que vous pouvez utiliser pour remplacer ces emplacements : - `$XDG_CACHE_HOME` : définit un emplacement alternatif pour le stockage des fichiers mis en cache. - `$XDG_CONFIG_HOME` : définit un emplacement alternatif pour le stockage de la configuration Helm. - `$XDG_DATA_HOME` : définit un emplacement alternatif pour le stockage des données Helm. Notez que si vous avez des dépôts existants, vous devrez les ajouter à nouveau avec `helm repo add...`. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Dépannage sidebar_position: 4 --- ## Dépannage ### J'obtiens un avertissement « Unable to get an update from the "stable" chart repository » Exécutez `helm repo list`. Si votre dépôt `stable` pointe vers une URL `storage.googleapis.com`, vous devrez mettre à jour ce dépôt. Le 13 novembre 2020, le dépôt Helm Charts [n'est plus pris en charge](https://github.com/helm/charts#deprecation-timeline) après une période de dépréciation d'un an. Une archive a été mise à disposition à l'adresse `https://charts.helm.sh/stable` mais ne recevra plus de mises à jour. Vous pouvez exécuter la commande suivante pour corriger votre dépôt : ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Il en va de même pour le dépôt `incubator`, dont une archive est disponible à l'adresse https://charts.helm.sh/incubator. Vous pouvez exécuter la commande suivante pour le réparer : ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### J'obtiens l'avertissement 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' L'ancien dépôt de charts Helm de Google a été remplacé par un nouveau dépôt de charts Helm. Exécutez la commande suivante pour corriger définitivement ce problème : ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Si vous obtenez une erreur similaire pour `incubator`, exécutez cette commande : ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Quand j'ajoute un dépôt Helm, j'obtiens l'erreur 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Les dépôts Helm Charts ne sont plus pris en charge après [une période de dépréciation d'un an](https://github.com/helm/charts#deprecation-timeline). Des archives de ces dépôts sont disponibles à `https://charts.helm.sh/stable` et `https://charts.helm.sh/incubator`, mais elles ne recevront plus de mises à jour. La commande `helm repo add` ne vous permettra pas d'ajouter les anciennes URLs à moins que vous ne spécifiez `--use-deprecated-repos`. ### Sur GKE (Google Container Engine) j'obtiens « No SSH tunnels currently open » ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Une autre variante de ce message d'erreur est : ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` Le problème vient du fait que votre fichier de configuration Kubernetes local doit contenir les identifiants corrects. Lorsque vous créez un cluster sur GKE, celui-ci vous fournit des identifiants, y compris des certificats SSL et des autorités de certification. Ceux-ci doivent être stockés dans un fichier de configuration Kubernetes (par défaut : `~/.kube/config`) afin que `kubectl` et `helm` puissent y accéder. ### Après la migration depuis Helm 2, `helm list` n'affiche qu'une partie (ou aucune) de mes releases Il est probable que vous n'ayez pas remarqué que Helm 3 utilise désormais les namespaces du cluster pour définir la portée des releases. Cela signifie que pour toutes les commandes faisant référence à une release, vous devez soit : * vous fier au namespace actuel dans le contexte kubernetes actif (comme décrit par la commande `kubectl config view --minify`), * spécifier le namespace correct en utilisant le flag `--namespace`/`-n`, ou * pour la commande `helm list`, spécifier le flag `--all-namespaces`/`-A` Cela s'applique à `helm ls`, `helm uninstall` et toutes les autres commandes `helm` faisant référence à une release. ### Sur macOS, le fichier `/etc/.mdns_debug` est accédé. Pourquoi ? Nous avons connaissance d'un cas sur macOS où Helm essaie d'accéder à un fichier nommé `/etc/.mdns_debug`. Si le fichier existe, Helm garde le descripteur de fichier ouvert pendant son exécution. Cela est causé par la bibliothèque MDNS de macOS. Elle tente de charger ce fichier pour lire les paramètres de débogage (si activés). Le descripteur de fichier ne devrait probablement pas rester ouvert, et ce problème a été signalé à Apple. Cependant, c'est macOS, et non Helm, qui cause ce comportement. Si vous ne souhaitez pas que Helm charge ce fichier, vous pouvez compiler Helm en tant que bibliothèque statique qui n'utilise pas la pile réseau de l'hôte. Cela augmentera la taille du binaire de Helm, mais empêchera l'ouverture du fichier. Ce problème a été initialement signalé comme un potentiel problème de sécurité. Mais il a depuis été déterminé qu'il n'y a pas de faille ou de vulnérabilité causée par ce comportement. ### helm repo add échoue alors qu'il fonctionnait auparavant Dans Helm 3.3.1 et versions antérieures, la commande `helm repo add ` ne produisait aucune sortie si vous tentiez d'ajouter un dépôt qui existait déjà. Le flag `--no-update` levait une erreur si le dépôt était déjà enregistré. Dans Helm 3.3.2 et versions ultérieures, une tentative d'ajout d'un dépôt existant produit une erreur : `Error: repository name (reponame) already exists, please specify a different name` Le comportement par défaut est maintenant inversé. `--no-update` est désormais ignoré, tandis que si vous souhaitez remplacer (écraser) un dépôt existant, vous pouvez utiliser `--force-update`. Cela est dû à un changement incompatible pour une correction de sécurité, comme expliqué dans les [notes de version de Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Activer la journalisation du client Kubernetes L'affichage des messages de journal pour le débogage du client Kubernetes peut être activé en utilisant les flags [klog](https://pkg.go.dev/k8s.io/klog). L'utilisation du flag `-v` pour définir le niveau de verbosité sera suffisant dans la plupart des cas. Par exemple : ``` helm list -v 6 ``` ### Les installations de Tiller ne fonctionnent plus et l'accès est refusé Les releases Helm étaient auparavant disponibles sur . Comme expliqué dans [« Announcing get.helm.sh »](https://helm.sh/blog/get-helm-sh/), l'emplacement officiel a changé en juin 2019. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) met à disposition toutes les anciennes images Tiller. Si vous essayez de télécharger des versions plus anciennes de Helm depuis le bucket de stockage que vous utilisiez auparavant, vous pourriez constater qu'elles sont manquantes : ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` L'[ancien emplacement des images Tiller](https://gcr.io/kubernetes-helm/tiller) a commencé la suppression des images en août 2021. Nous avons rendu ces images disponibles sur [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Par exemple, pour télécharger la version v2.17.0, remplacez : `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` par : `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Pour initialiser avec Helm v2.17.0 : `helm init —upgrade` Ou si une version différente est nécessaire, utilisez le flag --tiller-image pour remplacer l'emplacement par défaut et installer une version spécifique de Helm v2 : `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Note :** Les mainteneurs de Helm recommandent la migration vers une version actuellement prise en charge de Helm. Helm v2.17.0 était la dernière release de Helm v2 ; Helm v2 n'est plus pris en charge depuis novembre 2020, comme détaillé dans [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). De nombreuses CVE ont été signalées contre Helm depuis, et ces failles sont corrigées dans Helm v3 mais ne seront jamais corrigées dans Helm v2. Consultez la [liste actuelle des avis de sécurité Helm publiés](https://github.com/helm/helm/security/advisories?state=published) et planifiez votre [migration vers Helm v3](/topics/v2_v3_migration.md) dès aujourd'hui. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Désinstallation sidebar_position: 3 --- ## Désinstallation ### Je veux supprimer Helm de mon ordinateur. Où se trouvent tous ses fichiers ? En plus du binaire `helm`, Helm stocke certains fichiers aux emplacements suivants : - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME Le tableau suivant indique le dossier par défaut pour chacun de ces emplacements, selon le système d'exploitation : | Système d'exploitation | Chemin du cache | Chemin de configuration | Chemin des données | |------------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Helm, Le gestionnaire de paquets pour Kubernetes ### Synopsis Le gestionnaire de paquets pour Kubernetes Actions courantes de Helm : - `helm search` : cherche des charts installées dans Kubernetes - `helm pull` : télécharge l'archive chart dans le répertoire courant - `helm install` : installe le chart dans le namespace du cluster Kubernetes - `helm list` : liste les versions de charts installées dans le namespace du cluster Kubernetes Variables d'environnement : | Nom | Description | |------------------------------------|----------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | définit un répertoire alternatif pour stocker les fichiers du cache. | | $HELM_CONFIG_HOME | définit un répertoire alternatif pour stocker les fichiers de configuration. | | $HELM_DATA_HOME | définit un répertoire alternatif pour stocker les fichiers de données. | | $HELM_DEBUG | indique si Helm tourne en mode Debug | | $HELM_DRIVER | définit le driver du stockage du backend. Il peut être: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | définit la chaîne de caractères que le driver de stockage SQL doit utiliser. | | $HELM_MAX_HISTORY | définit le nombre maximum de versions helm conservées. | | $HELM_NAMESPACE | définit le namespace des operations helm. | | $HELM_NO_PLUGINS | désactive les plugins. Mettre HELM_NO_PLUGINS=1 pour désactiver les plugins. | | $HELM_PLUGINS | définit le chemin du répertoire de plugins. | | $HELM_REGISTRY_CONFIG | définit le chemin de la configuration du registre. | | $HELM_REPOSITORY_CACHE | définit le chemin du repertoire cache. | | $HELM_REPOSITORY_CONFIG | définit le chemin de la configuration du répertoire. | | $KUBECONFIG | définit un chemin alternatif de configuration de kubernetes (par défaut "~/.kube/config") | | $HELM_KUBEAPISERVER | définit le point d'entrée API du serveur Kubernetes pour l'authentification | | $HELM_KUBECAFILE | définit le fichier de l'autorité de certification de Kubernetes. | | $HELM_KUBEASGROUPS | définit le groupe à utiliser pour anonymisation en utilisant une liste csv. | | $HELM_KUBEASUSER | définit le nom à utiliser pour anonymiser l'operation. | | $HELM_KUBECONTEXT | définit le nom du contexte kubeconfig. | | $HELM_KUBETOKEN | définit le canal KubeToken utilisé pour l'authentification. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indique si la vérification du certificat de l'API ne doit pas être faite. (peu sûr) | | $HELM_KUBETLS_SERVER_NAME | définit le nom du serveur utilisé pour valider le certificat de l'API Kubernetes. | | $HELM_BURST_LIMIT | définit la limite burst au cas où le serveur contient plusieurs CRDs (par défaut 100, -1 désactive)| | $HELM_QPS | définit le nombre de requêtes par seconde lorsqu'un grand nombre d'appels dépasse les valeurs de burst | Helm stocke le cache, la configuration, et les données suivant les configurations serveur suivantes : - Si la variable d'environnement `HELM_*_HOME` est positionnée, elle sera utilisée - Sinon, sur les systèmes supportant les spécifications XDG base directory, les variables XDG seront utilisées - Lorsqu'aucun autre chemin n'est positionné, le chemin par défaut sera celui définit par le système d'exploitation OS Par défaut, les répertoires par défaut dépendent du système d'exploitation OS: | OS | Chemin Cache | Chemin Configuration | Chemin Données | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Options ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée -h, --help Aide pour Helm --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, hors burst --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### VOIR AUSSI * [helm completion](./helm_completion.md) - génère des scripts d'autocomplétion pour le shell spécifié * [helm create](./helm_create.md) - crée un nouveau chart avec le nom donné * [helm dependency](./helm_dependency.md) - gère les dépendances d'un chart * [helm env](./helm_env.md) - informations sur l'environnement client Helm * [helm get](./helm_get.md) - télécharge des informations étendues d'une release nommée * [helm history](./helm_history.md) - récupère l'historique d'une release * [helm install](./helm_install.md) - installe un chart * [helm lint](./helm_lint.md) - examine un chart pour détecter d'éventuels problèmes * [helm list](./helm_list.md) - liste les releases * [helm package](./helm_package.md) - empaquète un répertoire chart dans une archive chart * [helm plugin](./helm_plugin.md) - installe, liste ou désinstalle des plugins Helm * [helm pull](./helm_pull.md) - télécharge un chart depuis un dépôt et (optionnellement) le décompresse localement * [helm push](./helm_push.md) - pousse un chart vers un dépôt distant * [helm registry](./helm_registry.md) - connexion ou déconnexion d'un registre * [helm repo](./helm_repo.md) - ajoute, liste, supprime, met à jour et indexe des dépôts de charts * [helm rollback](./helm_rollback.md) - restaure une release à une révision précédente * [helm search](./helm_search.md) - recherche un mot-clé dans les charts * [helm show](./helm_show.md) - affiche les informations d'un chart * [helm status](./helm_status.md) - affiche le statut de la release nommée * [helm template](./helm_template.md) - effectue le rendu local des templates * [helm test](./helm_test.md) - exécute les tests d'une release * [helm uninstall](./helm_uninstall.md) - désinstalle une release * [helm upgrade](./helm_upgrade.md) - met à niveau une release * [helm verify](./helm_verify.md) - vérifie qu'un chart à un chemin donné a été signé et est valide * [helm version](./helm_version.md) - affiche les informations de version du client ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- générer des scripts d'auto-complétion pour le shell spécifié ### Synopsis Générer des scripts d'auto-complétion pour Helm pour le shell spécifié. ### Options ``` -h, --help Aide pour la complétion ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de paquets Helm pour Kubernetes * [helm completion bash](/helm/helm_completion_bash.md) - Générer des scripts d'auto-complétion pour bash * [helm completion fish](/helm/helm_completion_fish.md) - Générer des scripts d'auto-complétion pour fish * [helm completion powershell](/helm/helm_completion_powershell.md) - Générer des scripts d'auto-complétion pour powershell * [helm completion zsh](/helm/helm_completion_zsh.md) - Générer des scripts d'auto-complétion pour zsh ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- générer des scripts d'auto-complétion pour bash ### Synopsis Générer des scripts d'auto-complétion pour Helm pour le shell bash. Pour charger les complétions dans votre session shell courante : source <(helm completion bash) Pour charger les complétions pour chaque nouvelles sessions, exécutez une fois : - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm Vous devez relancer un nouveau shell pour que cette configuration prenne effet. ``` helm completion bash [flags] ``` ### Options ``` -h, --help Aide pour bash --no-descriptions Désactiver les descriptions des complétions ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm completion](./helm_completion.md) - Générer des scripts d'auto-complétion pour le shell spécifié ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- générer des scripts d'auto-complétion pour fish ### Synopsis Générer des scripts d'auto-complétion pour Helm pour le shell fish. Pour charger les complétions dans votre session shell courante : helm completion fish | source Pour charger les complétions pour chaque nouvelle session, exécutez une fois : helm completion fish > ~/.config/fish/completions/helm.fish Vous devez relancer un nouveau shell pour que cette configuration prenne effet. ``` helm completion fish [flags] ``` ### Options ``` -h, --help Aide pour fish --no-descriptions Désactiver les descriptions des complétions ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour le shell spécifié ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- générer des scripts d'auto-complétion pour powershell ### Synopsis Générer des scripts d'auto-complétion Helm pour PowerShell. Pour charger les complétions dans votre session shell actuelle : `PS C:\> helm completion powershell | Out-String | Invoke-Expression` Pour charger les complétions pour chaque nouvelle session, ajoutez la sortie de la commande ci-dessus à votre profil PowerShell. ``` helm completion powershell [flags] ``` ### Options ``` -h, --help Aide pour powershell --no-descriptions Désactiver les descriptions pour les complétions ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour un shell spécifique ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- générer des scripts d'auto-complétion pour Zsh ### Synopsis Générer des scripts d'auto-complétion pour Helm pour Zsh Pour charger les complétions dans votre session courante shell : source <(helm completion zsh) Pour charger les complétions pour chaque nouvelle session shell, exécutez une fois : helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Options ``` -h, --help Aide pour zsh --no-descriptions Désactiver les descriptions des complétions ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm completion](/helm/helm_completion.md) - Générer des scripts d'auto-complétion pour un shell spécifique ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- créer un nouveau chart avec le nom donné ### Synopsis Cette commande crée un dossier chart ainsi que les fichiers et répertoires courants utilisés dans un chart. Par exemple, `helm create foo` va créer une structure de répertoires qui ressemble à ceci : foo/ ├── .helmignore # Contient des modèles à ignorer lors de l’empaquetage des charts Helm ├── Chart.yaml # Informations à propos de votre chart ├── values.yaml # Valeurs par défaut pour vos templates ├── charts/ # Charts dont dépend votre chart └── templates/ # Fichiers de template └── tests/ # Fichiers de test `helm create` prend en argument, un chemin. Si le dossier du chemin n'existe pas, Helm tentera de les créer au fur et à mesure. Si le chemin de destination existe et qu'il y a des fichiers dans le dossier, les fichiers en conflit seront écrasés, mais les autres fichiers seront laissés. ``` helm create NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande create -p, --starter string Le nom ou le chemin absolu vers le dossier de démarrage Helm ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- gestion des dépendances d'un chart ### Synopsis Gère les dépendances d'un chart. Les charts Helm stockent leurs dépendances dans le dossier `charts/`. Pour les développeurs de chart, il est souvent plus facile de gérer les dépendances dans le fichier `Chart.yaml` qui déclare toutes les dépendances. Les commandes de dépendance fonctionnent sur ce fichier, ce qui facilite la synchronisation entre les dépendances souhaitées et les dépendances réelles stockées dans le répertoire `charts/`. Par exemple, ce fichier Chart.yaml déclare deux dépendances : # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" Le champ `name` doit correspondre au nom du chart tel qu'indiqué dans le fichier `Chart.yaml` de ce chart. Le champ `version` doit contenir une version sémantique ou une plage de versions. L'URL du 'repository' doit pointer vers un dépôt de Chart. Helm s'attend à ce qu'en ajoutant `/index.yaml` à l'URL, il puisse récupérer l'index du dépôt de chart. Note : 'repository' peut être un alias. L'alias doit commencer par `alias:` ou `@`. À partir de la version 2.2.0, le dépôt peut être défini comme le chemin d'accès au répertoire des charts dépendants stockés localement. Le chemin doit commencer par le préfixe `file://`. Par exemple : # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" Si le chart dépendant est récupéré localement, il n'est pas nécessaire d'ajouter le dépôt à Helm avec la commande `helm add repo`. La correspondance des versions est également prise en charge pour ce cas. ### Options ``` -h, --help Aide pour la commande dependency ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - Reconstruire le répertoire charts/ en fonction du fichier Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) - Lister les dépendances pour un chart donné * [helm dependency update](/helm/helm_dependency_update.md) - Met à jour le répertoire charts/ basé sur le contenu du fichier Chart.yaml ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- reconstruire le répertoire charts/ à partir du fichier Chart.lock ### Synopsis Reconstruire le répertoire charts/ à partir du fichier Chart.lock. Cette commande sert à reconstruire les dépendances d'un chart selon l'état spécifié dans le fichier lock. Cela ne renégociera pas les dépendances, comme le fait la commande `helm dependency update`. Si aucun fichier lock n'est trouvé, la commande `helm dependency build` aura le même comportement que la commande `helm dependency update`. ``` helm dependency build CHART [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -h, --help Aide pour la commande build --insecure-skip-tls-verify Ignore les vérifications du certificat TLS pour le téléchargement du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Porte-clés contenant des clés publiques (par défaut "~/.gnupg/pubring.gpg") --password string Mot de passe du dépôt de charts où se trouve le chart demandé --plain-http Utilise une connexion HTTP non sécurisée pour le téléchargement du chart --skip-refresh Ne pas actualiser le cache du dépôt local --username string Nom d'utilisateur du dépôt de charts où se trouve le chart demandé --verify Vérifier les paquets par rapport aux signatures ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- liste les dépendances pour un chart donné ### Synopsis Liste toutes les dépendances déclarées dans un chart. Cela prend en entrée les archives de chart et le répertoire des charts. Cela ne modifiera pas le contenu d'un chart. Cela produira une erreur si le chart ne peut pas être chargé. ``` helm dependency list CHART [flags] ``` ### Options ``` -h, --help Aide pour la commande list --max-col-width uint Largeur maximal de colonne pour le tableau de sortie (par defaut 80) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- met à jour le dossier charts/ basé sur le contenu du fichier Chart.yaml ### Synopsis Met à jour les dépendances sur le disque pour correspondre au fichier `Chart.yaml`. Cette commande vérifie que les charts requis, tel qu'exprimés dans le fichier `Chart.yaml`, soient présents dans le dossier `charts/` et sont dans une version acceptable. Elle récupérera les derniers charts qui satisfont les dépendances et nettoiera les anciennes dépendances. En cas de mise à jour réussie, cela générera un fichier lock qui pourra être utilisé pour reconstruire les dépendances vers une version spécifique. Il n'est pas nécessaire que les dépendances soient présentes dans le fichier `Chart.yaml`. Pour cette raison, une commande de mise à jour ne supprimera pas les charts à moins qu'ils ne soient (a) présents dans le fichier `Chart.yaml` mais (b) dans une version incorrecte. ``` helm dependency update CHART [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -h, --help Aide pour la commande update --insecure-skip-tls-verify Ignore les vérifications du certificat TLS pour le téléchargement du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Porte-clés contenant des clés publiques (par défaut "~/.gnupg/pubring.gpg") --password string Mot de passe du dépôt de charts où se trouve le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le téléchargement du chart --skip-refresh Ne pas actualiser le cache du dépôt local --username string Nom d'utilisateur du dépôt de charts où se trouve le chart demandé --verify Vérifier les paquets par rapport aux signatures ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm dependency](/helm/helm_dependency.md) - Gérer les dépendances d'un chart ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- informations sur l'environnement du client Helm ### Synopsis La commande `env`, affiche toutes les informations sur l'environnement utilisé par Helm. ``` helm env [flags] ``` ### Options ``` -h, --help Aide pour la commande env ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire officiel de paquets Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- télécharger les informations détaillées d'une version donnée ### Synopsis Cette commande se compose de plusieurs sous-commandes qui peuvent être utilisées pour obtenir des informations détaillées sur la version, cela inclut : - Les valeurs utilisées pour générer la version - Le fichier manifeste généré - Les notes fournies par le chart d'une version - Les hooks associés avec la version - Les métadonnées de la version ### Options ``` -h, --help Aide pour la commande get ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes * [helm get all](/helm/helm_get_all.md) - Télécharge toutes les informations d'une version donnée * [helm get hooks](/helm/helm_get_hooks.md) - Télécharge tous les hooks pour une version donnée * [helm get manifest](/helm/helm_get_manifest.md) - Télécharge le manifeste d'une version donnée * [helm get metadata](/helm/helm_get_metadata.md) - Cette commande récupère les métadonnées d'une version donnée * [helm get notes](/helm/helm_get_notes.md) - Télécharge les notes d'une version donnée * [helm get values](/helm/helm_get_values.md) - Télécharge le fichier valeurs d'une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- télécharge toutes les informations pour une version donnée ### Synopsis Cette commande affiche de manière compréhensible, une liste d'informations contenant les notes, les hooks, les valeurs utilisées et le fichier manifeste généré pour une version donnée. ``` helm get all RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande get all --revision int Récupère la version donnée avec sa révision --template string Template en Go pour formatter la sortie, ex : {{.Release.Name}} ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- télécharge tous les hooks pour une version donnée ### Synopsis Cette commande télécharge les hooks pour une version donnée. Les hooks sont formatés en YAML et séparés par le séparateur YAML `---\n`. ``` helm get hooks RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande get hooks --revision int Récupère la version donnée avec sa révision ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- télécharge le manifeste pour une version donnée ### Synopsis Cette commande récupère le manifeste généré pour une version donnée. Un manifeste est une représentation encodée en YAML des ressources Kubernetes générées à partir du ou des charts de cette version. Si un chart dépend d'autres charts, ces ressources seront également incluses dans le manifeste. ``` helm get manifest RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande get manifest --revision int Récupère la version donnée avec sa révision ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Cette commande récupère les métadonnées pour une version donnée ``` helm get metadata RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande get metadata -o, --output format Affiche la sortie sous différents formats. Valeurs possibles : table, json, yaml (par défaut table) --revision int Spécifie la révision ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- télécharge les notes pour une version donnée ### Synopsis Cette commande affiche les notes fournies pour une version de chart donnée. ``` helm get notes RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande get notes --revision int Récupère la version donnée avec sa révision ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- télécharge le fichier de valeurs d'une version donnée ### Synopsis Cette commande télécharge un fichier de valeurs d'une version donnée ``` helm get values RELEASE_NAME [flags] ``` ### Options ``` -a, --all Récupère toutes les valeurs (calculées) -h, --help Aide pour la commande get values -o, --output format Affiche la sortie sous différents formats. Valeurs possibles : table, json, yaml (par défaut table) --revision int Récupère la version donnée avec sa révision ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm get](/helm/helm_get.md) - Télécharge les informations détaillées pour une version donnée ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- récupère l'historique des versions ### Synopsis Cette commande affiche l'historique des revisions pour une version donnée. Un maximum par défaut de 256 révisions sera renvoyé. Le paramètre `--max` configure la longueur maximale de la liste de révisions renvoyée. L'historique de la version est affiché sous la forme d'un tableau, ex : $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande history --max int Nombre maximum de révisions à inclure dans l'historique (par défaut 256) -o, --output format Affiche la sortie dans un format spécifique. Valeurs possibles : table, json, yaml (par défaut table) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- installe un chart ### Synopsis Cette commande installe une archive de chart. L'argument d'installation doit être une référence, un chemin d'accès vers un chart compressé, un chemin d'accès vers un chart décompressé ou une URL. Pour remplacer les valeurs dans un chart, utilisez soit l'argument `--values` et passez-y un fichier ou utilisez l'argument `--set` et passez-y la configuration à partir de la ligne de commande, pour forcer l'utilisation d'une valeur en chaine de caractères, utilisez `--set-string`. Vous pouvez utilisez `--set-file` pour fixer individuellement les valeurs à partir d'un fichier lorsque les valeurs sont trop longues pour être en ligne de commande ou parce qu'elles sont généré dynamiquement. Vous pouvez aussi utiliser `--set-json` pour fixer des valeurs au format JSON (scalars/objects/arrays) depuis la ligne de commande. $ helm install -f myvalues.yaml myredis ./redis ou $ helm install --set name=prod myredis ./redis ou $ helm install --set-string long_int=1234567890 myredis ./redis ou $ helm install --set-file my_script=dothings.sh myredis ./redis ou $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Vous pouvez spécifier l'argument `--values` (abrégé en `-f`) plusieurs fois. La priorité sera donnée au dernier fichier spécifié (à l'extreme droite). Par exemple, si `myvalues.yaml` et `override.yaml` contiennent une clé nommée 'Test', la valeurs fixé dans le fichier `override.yaml` aura priorité : $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Vous pouvez spécifier l'argument `--set` plusieurs fois. La priorité sera donnée au dernier spécifié (à l'extreme droite). Par exemple, si les valeurs 'bar' et 'newbar' sont fixées pour la clé nommé 'foo', la valeur 'newbar' sera prioritaire : $ helm install --set foo=bar --set foo=newbar myredis ./redis De même, dans l'exemple suivant, 'foo' est défini sur '["four"]' : $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis Et dans l'exemple suivant, 'foo' est défini sur '{"key1":"value1","key2":"bar"}' : $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Pour vérifier les manifestes générés d'une version sans installer le chart, les arguments `--debug` et `--dry-run` peuvent être combinés. L'argument `--dry-run` affichera tous les manifestes générés du chart, y compris les Secrets qui peuvent contenir des valeurs sensibles. Pour masquer les Secrets Kubernetes, utilisez l'argument `--hide-secret`. Veuillez considérer attentivement comment et quand utiliser ces arguments. Si l'argument `--verify` est fixé, le chart DOIT avoir un fichier de provenance, et le fichier de provenance DOIT passer toutes les étapes de vérification. Il y a six manières différentes d'exprimer le chart que vous souhaitez installer : 1. Par référence du chart : `helm install mymaria example/mariadb` 2. Par le chemin d'accès vers un chart compressé : `helm install mynginx ./nginx-1.2.3.tgz` 3. Par le chemin d'accès vers un chart décompressé : `helm install mynginx ./nginx` 4. Par l'URL absolue : `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz` 5. Par référence du chart et l'URL du dépôt : `helm install --repo https://example.com/charts/ mynginx nginx` 6. Par les registres OCI : `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx` RÉFÉRENCES DES CHARTS Une référence de chart est un moyen pratique de référencer un chart dans un référentiel de charts. Lorsque vous utilisez une référence de chart avec un préfixe de dépôt ('example/mariadb'), Helm va rechercher dans la configuration locale, si un dépôt nommé 'example' et recherchera ensuite si un chart dans ce référentiel dont le nom est 'mariadb'. Il installera la dernière version stable de ce chart jusqu'à ce que vous le spécifiiez avec l'argument `--devel` pour inclure également la version de développement (alpha, beta et les versions candidates), ou fournissez un numéro de version avec l'argument `--version`. Pour voir la liste des dépôts, utilisez la commande `helm repo list`. Pour chercher un chart dans un dépôt, utilisez la commande `helm search`. ``` helm install [NAME] [CHART] [flags] ``` ### Options ``` --rollback-on-failure Si fixé, le processus d'installation supprimera l'installation en cas d'échec. L'argument --wait sera défini automatiquement si --rollback-on-failure est utilisé --ca-file string Vérifie les certificats des serveurs ayant activé HTTPS en utilisant ce fichier de certificat racine (CA bundle) --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --create-namespace Créer le namespace de la version s'il n'est pas présent --dependency-update Met à jour les dépendances si elles sont manquantes avant l'installation du chart --description string Ajoute une description personnalisée --devel Utiliser également les versions de développement. Équivalent à version '>0.0.0-0'. Si --versions est fixé, ceci est ignoré --disable-openapi-validation Si défini, le processus d'installation ne validera pas les modèles générés par rapport au schéma OpenAPI de Kubernetes --dry-run string[="client"] Simule une installation. Si '--dry-run' est fixé sans option ou comme '--dry-run=client', aucune tentative de connexion au cluster ne sera éffectuée. En définissant '--dy-run=server', des tentatives de connexion au cluster seront autorisées --enable-dns Active les recherches DNS lors du rendu des modèles --force Force les mise à jour des ressources en utilisant une stratègie de remplacement -g, --generate-name Génère le nom (et omet le paramètre NAME) -h, --help Aide pour la commande install --hide-notes Si défini, n'affiche pas les notes dans la sortie d'installation. N'affecte pas la présence dans les métadonnées du chart --hide-secret Masque les Secrets Kubernetes lors de l'utilisation de l'argument --dry-run --insecure-skip-tls-verify Ignore les vérifications de certificat TLS lors du téléchargement du chart --key-file string Identifie le client HTTPS en utilisant ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisées pour la vérification (par defaut "~/.gnupg/pubring.gpg") -l, --labels stringToString Étiquettes qui seront ajoutées aux métadonnées de la publication. Doit être séparé par des virgules. (par defaut []) --name-template string Spécifie un modèle à utiliser pour le nom de la publication --no-hooks Empêche les hooks de fonctionner pendant l'installation -o, --output format Affiche la sortie dans un format spécifique. Valeurs possibles : table, json, yaml (par defaut table) --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe du dépôt de chart où est localisé le chart demandé --plain-http Utiliser des connexion HTTP non sécurisées pour le téléchargement du chart --post-renderer postRendererString Chemin vers un éxécutable à utiliser pour le post-rendu. S'il existe dans $PATH, le binaire sera utilisé, sinon il essaiera de rechercher l'exécutable au chemin spécifié. --post-renderer-args postRendererArgsSlice Un argument pour le post-rendu (peut être spécifié plusieurs fois) (par défaut []) --render-subchart-notes Si défini, génère les notes du sous-chart avec le chart parent --replace Réutilise le nom donné, uniquement si ce nom correspond à une publication supprimé qui reste dans l'historique. Ceci n'est pas sûre en production --repo string Url du dépôt de chart où est localisé le chart demandé --set stringArray Défini des valeurs en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --set-file stringArray Défini des valeurs depuis un fichier spécifique en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=path1,key2=path2) --set-json stringArray Défini des valeurs en JSON en ligne de commande (vous pouvez spécifier plusieurs ou séparer les valeurs par des virgules : key1=jsonval1,key2=jsonval2) --set-literal stringArray Défini une valeur littérale de type STRING en ligne de commande --set-string stringArray Défini des valeurs de type STRING en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --skip-crds Si défini, aucun CRD ne sera installé. Par défaut, les CRD sont installés s'ils ne sont pas déjà présents --skip-schema-validation Si défini, désactive la validation du schéma JSON --take-ownership Si défini, l'installation ignorera la vérification des annotations Helm et prendra possession des ressources existantes --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) --username string Nom d'utilisateur du dépôt de chart où est localisé le chart demandé -f, --values strings Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs) --verify Vérifie le paquet avant de l'utiliser --version string Spécifier une contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (par exemple, 1.1.1) ou elle peut faire référence à une plage valide (par exemple, ^2.0.0). Si cela n'est pas spécifié, la dernière version est utilisée --wait Si défini, cela attendra que tous les pods, PVCs, services, et le nombre minimum de pods d'un déploiement, StatefulSet ou ReplicaSet soient dans un état prêt avant de marquer la publication comme réussie. Il attendra aussi longtemps que spécifié par '--timeout' --wait-for-jobs Si défini et que '--wait' est activé, cela attendra que tous les Jobs soient terminés avant de marquer la publication comme réussie. Il attendra aussi longtemps que spécifié par '--timeout' ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- examine un chart pour détecter d'éventuels problèmes ### Synopsis Cette commande prend un chemin vers un chart et lance une série de tests pour vérifier que le chart est correctement formé. Si le linter rencontre des éléments qui entraîneront l'échec de l'installation du chart, il émettra des messages [ERROR]. S'il rencontre des problèmes qui sont en conflit avec les conventions ou des recommandations, il émettra des messages [WARNING]. ``` helm lint PATH [flags] ``` ### Options ``` -h, --help Aide pour la commande lint --kube-version string Version de Kubernetes utilisée pour les vérifications des capacités et des dépréciations --quiet Affiche uniquement les avertissements et les erreurs --set stringArray Défini des valeurs en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --set-file stringArray Défini des valeurs depuis un fichier spécifique en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=path1,key2=path2) --set-json stringArray Défini des valeurs en JSON en ligne de commande (vous pouvez spécifier plusieurs ou séparer les valeurs par des virgules : key1=jsonval1,key2=jsonval2) --set-literal stringArray Défini une valeur littérale de type STRING en ligne de commande --set-string stringArray Défini des valeurs de type STRING en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --skip-schema-validation Si défini, désactive la validation du schéma JSON --strict Échoue en cas d'avertissements -f, --values strings Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs) --with-subcharts Vérifie les sous-charts dépendants ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- liste les publications ### Synopsis Cette commande liste toutes les publications pour un namespace donné (utilise le namespace du contexte si le namespace n'est pas spécifié). Par défaut, cela liste uniquement les publications qui sont déployées ou échouées. Des options telles que '--uninstalled' et '--all' modifieront ce comportement. Ces options peuvent être combinées, par exemple '--uninstalled --failed'. Par défaut, les éléments sont triés par ordre alphabétique. Vous pouvez utiliser l'option '-d' pour trier par date de publication. Si l'option '--filter' est renseignée, elle sera traitée comme un filtre. Les filtres sont des expressions régulières (compatibles avec Perl) qui sont appliquées à la liste des publications. Seuls les éléments qui correspondent au filtre seront renvoyés. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Si aucun résultat n'est trouvé, 'helm list' se terminera avec le code de sortie 0, mais sans affichage (ou dans le cas de l'absence de l'option '-q', seulement les en-têtes). Par défaut, jusqu'à 256 éléments peuvent être renvoyés. Pour limiter cela, utilisez l'option '--max'. Définir '--max' à 0 ne renverra pas tous les résultats. Au lieu de ça, il renverra la valeur par défaut du serveur qui peut être beaucoup plus élevée que 256. L'utilisation de l'option '--max' avec l'option '--offset' vous permet de parcourir les résultats pages par pages. ``` helm list [flags] ``` ### Options ``` -a, --all Affiche toutes les publications sans aucun filtre appliqué -A, --all-namespaces Liste les publications à travers tous les namespaces -d, --date Trie par date de publication --deployed Affiche les publications déployées. Si aucune autre option n'est spécifiée, celle-ci sera automatiquement activée --failed Affiche les publications échouées -f, --filter string Une expression régulière (compatible Perl). Toutes les publications correspondant à l'expression régulières seront incluses dans les résultats -h, --help Aide pour la commande list -m, --max int Nombre maximum de publications à récupérer (par défaut 256) --no-headers Ne pas afficher les en-têtes lors de l'utilisation de sortie par défaut --offset int Index de la prochaine publication dans la liste, utilisé pour décaler à partir de la valeur de départ -o, --output format Affiche la sortie dans un format spécifique. Valeurs possible : table, json, yaml (par défaut table) --pending Affiche les publications en attente -r, --reverse Inverse l'ordre de tri -l, --selector string Sélecteur (requête d'étiquette) à utiliser comme filtre, prend en charge '=', '==', et '!='.(ex : -l key1=value1,key2=value2). Fonctionne uniquement avec les backends de stockage secret (par défaut) et configmap -q, --short Format de la liste de sortie courte (silencieux) --superseded Affiche les publications remplacées --time-format string Format du temps en utilisant le formateur de temps de GoLang. Exemple : --time-format "2006-01-02 15:04:05Z0700" --uninstalled Affiche les publications désinstallées (Si 'helm uninstall --keep-history' a été utilisé) --uninstalling Affiche les publications en cours de désinstallation ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- emballe un dossier de chart dans une archive de chart ### Synopsis Cette commande, emballe un chart dans un fichier archive versionné. Si un chemin est donné, elle regardera si ce chemin est un chemin vers un chart (qui doit contenir un fichier Chart.yaml) puis emballe ce dossier. Les archives de chart versionnés sont utilisées par les dépôts de paquets Helm. Pour signer un chart, utilisez l'argument '--sign'. Dans la plupart des cas, vous devez également fournir '--keyring path/to/secret/keys' et '--key keyname'. `$ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg` Si l'argument '--keyring' n'est pas spécifié, Helm utilisera généralement par défaut le trousseau de clés public, sauf si votre environnement est configuré autrement. ``` helm package [CHART_PATH] [...] [flags] ``` ### Options ``` --app-version string Définit l'appVersion du chart pour cette version --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -u, --dependency-update Met à jour les dépendances depuis le fichier "Chart.yaml" vers le dossier "charts/" avant de l'emballer -d, --destination string Emplacement pour écrire le chart. (par défaut ".") -h, --help Aide pour la commande package --insecure-skip-tls-verify Ignore les vérifications du certificat TLS pour le téléchargement du chart --key string Nom de la clé à utiliser lors de la signature. Utilisé si '--sign' est vrai --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement du trousseau de clés public (par défaut "~/.gnupg/pubring.gpg") --passphrase-file string Emplacement du fichier qui contient la passphrase pour la clé de signature. Utilisez "-" pour lire depuis stdin. --password string Mot de passe du dépôt de charts où se trouve le chart demandé --plain-http Utilise une connexion HTTP non sécurisée pour le téléchargement du chart --sign Utilise une clé privée PGP pour signer ce paquet --username string Nom d'utilisateur du dépôt de charts où se trouve le chart demandé --version string Définit la version de ce chart (version semver) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](./helm.md) - Le gestionnaire de package Helm pour Kubernetes. ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- installer, lister ou désinstaller des plugins Helm. ### Synopsis Gère les plugins Helm côté client. ### Options ``` -h, --help Aide pour la commande plugin ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes * [helm plugin install](/helm/helm_plugin_install.md) - Installe un ou plusieurs plugins Helm * [helm plugin list](/helm/helm_plugin_list.md) - Liste les plugins Helm installés * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - Désinstalle un ou plusieurs plugins Helm * [helm plugin update](/helm/helm_plugin_update.md) - Met à jour un ou plusieurs plugins Helm ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- installe un ou plusieurs plugins Helm ### Synopsis Cette commande vous permet d'installer un plugin depuis une URL vers un dépôt VCS ou un chemin local. ``` helm plugin install [options] ... [flags] ``` ### Options ``` -h, --help Aide pour la commande install --version string Spécifie une contrainte de version. Si cela n'est pas spécifié, la dernière version sera installée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- liste les plugins Helm installés ``` helm plugin list [flags] ``` ### Options ``` -h, --help Aide pour la commande list ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra vos connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- désinstalle un ou plusieurs plugins Helm ``` helm plugin uninstall ... [flags] ``` ### Options ``` -h, --help Aide pour la commande uninstall ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- met à jour un ou plusieurs plugins Helm ``` helm plugin update ... [flags] ``` ### Options ``` -h, --help Aide pour la commande update ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm plugin](/helm/helm_plugin.md) - Installer, lister ou désinstaller des plugins Helm ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- Télécharge un chart depuis un dépôt et (optionnellement) le décompresse dans un répertoire local. ### Synopsis Récupère un package depuis un dépôt de packages et le télécharge localement. Cela est utile pour récupérer des packages pour les inspecter, modifier ou pour les repackager. Cette commande peut également être utilisée pour effectuer une vérification cryptographique d'un chart sans l'installer. Des options permettent de décompresser le chart après le téléchargement. Cela créera un répertoire pour le chart et le décompressera dans ce répertoire. Si l'argument `--verify` est spécifié, le chart demandé DOIT avoir un fichier de provenance et DOIT passer le processus de vérification. Un échec dans n’importe quelle partie entraînera une erreur et le chart ne sera pas enregistré localement. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -d, --destination string Emplacement pour écrire le chart. Si cette option et untardir sont spécifiées, untardir est ajouté à ce chemin (par défaut ".") --devel Utilise les versions de développement également. Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande pull --insecure-skip-tls-verify Ignore les vérifications du certificat TLS pour le téléchargement du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisées pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmettre les informations d'identification à tous les domaines --password string Mot de passe du répertoire de chart --plain-http Utilise une connexion HTTP non-sécurisée pour le téléchargement du chart --prov Récupérer le fichier de provenance, mais n'effectue pas de vérification --repo string URL du répertoire de chart --untar Si fixé à true, décompresse le chart après l'avoir téléchargé --untardir string Si untar est spécifié, cet argument spécifie le nom du dossier dans lequel le chart sera décompressé (par défaut ".") --username string Nom d'utilisateur du répertoire de chart --verify Vérifie le package avant de l'utiliser --version string Spécifie une contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex: 1.1.1) ou elle peut faire référence à une plage valide (ex: ^2.0.0). Si ce n'est pas spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes. ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- Pousse un chart à distance ### Synopsis Transfert un chart vers un registre. Si le chart est associé à un fichier de provenance, il sera également transféré avec. ``` helm push [chart] [remote] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -h, --help Aide pour la commande push --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --password string Mot de passe du dépôt de chart où est localisé le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --username string Nom d'utilisateur du dépôt de chart où est localisé le chart demandé ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](./helm.md) - Le gestionnaire de package Helm pour Kubernetes ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- Se connecter ou se déconnecter d'un registre ### Synopsis Cette commande se compose de plusieurs sous-commandes pour interagir avec des registres. ### Options ``` -h, --help Aide pour la commande registry ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra vos connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes * [helm registry login](/helm/helm_registry_login.md) - Se connecter à un registre * [helm registry logout](/helm/helm_registry_logout.md) - Se déconnecter d'un registre ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- Se connecter à un registre ### Synopsis Authentification sur un registre distant ``` helm registry login [host] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL -h, --help Aide pour la commande login --insecure Autorise la connexion TLS au registre sans certificat --key-file string identifie le client de registre à l'aide de ce fichier de clé SSL -p, --password string Mot de passe du registre ou jeton d'identification --password-stdin Lire le mot de passe ou le token d'identification depuis stdin --plain-http Utilise des connexions HTTP non sécurisées pour le téléversement du chart -u, --username string Nom d'utilisateur du registre ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm registry](/helm/helm_registry.md) - Se connecter et se déconnecter d'un registre ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- Se déconnecter d'un registre ### Synopsis Supprime les informations d'identification stockées pour un registre distant. ``` helm registry logout [host] [flags] ``` ### Options ``` -h, --help Aide pour la commande logout ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm registry](/helm/helm_registry.md) - Se connecter ou se déconnecter d'un registre ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- Ajoute, supprime, liste, met à jour et index les référentiels de charts ### Synopsis Cette commande se compose de plusieurs sous-commandes pour interagir avec des référentiels de charts. Elle peut être utilisée pour ajouter, supprimer, lister et indexer des référentiels de charts. ### Options ``` -h, --help Aide pour la commande repo ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de packages Helm pour Kubernetes * [helm repo add](/helm/helm_repo_add.md) - Ajoute un référentiel de charts * [helm repo index](/helm/helm_repo_index.md) - Génère un fichier d'index à partir d'un référentiel contenant des charts packagés * [helm repo list](/helm/helm_repo_list.md) - Liste les référentiels * [helm repo remove](/helm/helm_repo_remove.md) - Supprime un ou plusieurs référentiels * [helm repo update](/helm/helm_repo_update.md) - Met à jour les informations des charts disponible localement à partir des référentiels ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- Ajouter un répertoire de chart ``` helm repo add [NAME] [URL] [flags] ``` ### Options ``` --allow-deprecated-repos Par défaut, cette commande ne permettra pas d'ajouter des dépôts officiels qui ont été définitivement supprimés. Cela désactive ce comportement --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --force-update Remplace (réécrit) le repo s'il existe déjà -h, --help Aide pour la commande add --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --no-update Ignoré. Auparavant, cela désactivait les mises à jour forcées. Il est obsolète et remplacé par --force-update. --pass-credentials Transmettre les informations d'identification à tous les domaines --password string Mot de passe du répertoire --password-stdin Lis le mot de passe depuis la sortie standard --timeout duration Temps d'attente pour le téléchargement du fichier index (par défaut 2m0s) --username string Nom d'utilisateur du répertoire ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- Génère un fichier index à partir d'un répertoire contenant des charts packagés ### Synopsis Analyse le dossier courant, génère un fichier index basé sur les charts trouvés et écrit le résultat dans `index.yaml` dans le répertoire courant. Cet outil est utilisé pour créer un fichier `index.yaml` pour un dépôt de charts. Pour définir une URL absolue vers les charts, utilisez l'argument `--url`. Pour fusionner l'index généré avec un index existant, utilisez l'argument `--merge`. Dans ce cas, les charts trouvés dans le dossier actuel seront fusionnés dans l'index existant, les charts locaux étant prioritaires sur les charts existants. ``` helm repo index [DIR] [flags] ``` ### Options ``` -h, --help Aide pour la commande index --json Sortie au format JSON --merge string Fusionne l'index généré avec l'index donné --url string URL du répertoire de charts ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- Liste les répertoires de charts ``` helm repo list [flags] ``` ### Options ``` -h, --help Aide pour la commande list -o, --output format Affiche la sortie dans le format spécifié. Valeurs autorisées: table, json, yaml (par défaut table) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- Supprime un ou plusieurs répertoires de charts ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` -h, --help Aide pour la commande remove ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- Met à jour les informations sur les charts disponibles localement à partir des répertoires de charts ### Synopsis La mise à jour obtient les dernières informations sur les charts à partir des répertoires de charts respectifs. Les informations sont mises en cache localement, où elles sont utilisées par des commandes telles que `helm search`. Vous pouvez optionnellement spécifier une liste de répertoires que vous voulez mettre à jour. `$ helm repo update ...` Pour mettre à jour tous les répertoires, utilisez `helm repo update`. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` --fail-on-repo-update-fail La mise à jour échoue si l'une des mise à jour du répertoire échoue -h, --help Aide pour la commande update --timeout duration Temps d'attente pour le téléchargement du fichier d'index (par défaut 2m0s) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm repo](/helm/helm_repo.md) - Ajouter, lister, supprimer, mettre à jour et indexer des répertoires de charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- Restaurer une release vers une révision précédente ### Synopsis Cette commande restaure une release vers une révision précédente. Le premier argument de cette commande est le nom de la release et le second est la révision (numéro de version). Si cet argument est omis ou défini sur 0, la release précédente sera restaurée. Pour voir les numéros de révision, lancez la commande `helm history `. ``` helm rollback [REVISION] [flags] ``` ### Options ``` --cleanup-on-fail Suppression des nouvelles ressources créées lors de cette restauration en cas d'échec de la restauration --dry-run Simule une restauration --force Force la mise à jour des ressources en les supprimant/recréant si nécessaire -h, --help Aide pour la commande rollback --history-max int Limite le nombre maximum de révision sauvegardé par release. Utilisez 0 pour ne pas fixer de limite (par défaut 10) --no-hooks Empêche les hooks de fonctionner pendant la restauration --recreate-pods Effectue le redémarrage des pods pour la ressource, le cas échéant --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) --wait Si fixé, attendra que tous les pods, PVC, services et le nombre minimum de pods d'un déploiement, d'un StatefulSet ou d'un ReplicaSet soient à l'état prêt avant de marquer la release comme réussie. Il attendra aussi longtemps que la valeur de --timeout --wait-for-jobs Si fixé et --wait activé, il attendra que tous les jobs soient terminés avant de marquer la release comme réussie. Il attendra aussi longtemps que la valeur de --timeout ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- Recherche un mot clé dans les charts ### Synopsis La commande search offre la possibilité de rechercher des charts Helm dans différents endroits où ils peuvent être stockés, y compris Artifact Hub et les répertoires que vous avez ajoutés. Utilisez les sous-commandes de search pour rechercher des charts dans différents endroits. ### Options ``` -h, --help Aide pour la commande search ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes * [helm search hub](/helm/helm_search_hub.md) - Rechercher des charts dans Artifact Hub ou dans votre propre instance de hub * [helm search repo](/helm/helm_search_repo.md) - Rechercher dans les répertoires un mot-clé dans les charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- Recherche de charts dans l'Artifact Hub ou dans votre propre instance du hub ### Synopsis Rechercher des charts Helm dans l'Artifact Hub ou dans votre propre instance du hub. L'Artifact Hub est une application web qui permet de trouver, installer et publier des packages et des configurations pour les projets de la CNCF, y compris des charts Helm publiques. C'est un projet sandbox de la Cloud Native Computing Foundation. Vous pouvez parcourir le hub via le site https://artifacthub.io/ L'argument `[KEYWORD]` accepte soit une chaîne de mot-clé, soit une chaîne entre guillemets d'options de requête enrichies. Pour la documentation sur les options des requêtes enrichies, rendez-vous sur https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Les versions précédentes de Helm utilisaient une instance de Monocular comme « point de terminaison » par défaut. Par conséquent, pour une rétro compatibilité, Artifact Hub est compatible avec l'API de recherche Monocular. De même, lors de la définition de l'argument `endpoint`, le point de terminaison spécifié doit également implémenter un point de terminaison d'API de recherche compatible Monocular. Notez que lorsque vous spécifiez une instance Monocular comme « point de terminaison », les requêtes enrichies ne sont pas prises en charge. Pour plus de détails sur l'API, voir https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Options ``` --endpoint string instance du Hub pour rechercher les charts (par défaut "https://hub.helm.sh") --fail-on-no-result La recherche échoue si pas de résultat trouvé -h, --help Aide pour la commande hub --list-repo-url Affiche les URLs des répertoires de charts --max-col-width uint Largeur maximum de colonne pour la table de sortie (par défaut 50) -o, --output format Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm search](/helm/helm_search.md) - Recherche par mot clé dans les charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- Rechercher par mot clé dans les répertoires de charts ### Synopsis La recherche parcourt tous les référentiels configurés sur le système et recherche les correspondances. La recherche dans ces répertoires utilise les métadonnées stockées sur le système. Il affichera les dernières versions stables des charts trouvés. Si vous spécifiez l'argument `--devel`, cela inclura des versions préliminaires. Si vous voulez faire une recherche en utilisant une contrainte de version, utilisez l'argument `--version`. Examples : # Recherchez les versions stables correspondant au mot-clé "nginx" $ helm search repo nginx # Recherchez les versions correspondant au mot-clé "nginx", incluant les versions préliminaires $ helm search repo nginx --devel # Recherchez les dernières versions stables pour nginx-ingress avec une version majeure de 1 $ helm search repo nginx-ingress --version ^1.0.0 Les répertoires sont gérés avec la commande `helm repo`. ``` helm search repo [keyword] [flags] ``` ### Options ``` --devel Utiliser également les versions de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré --fail-on-no-result La recherche échoue si pas de résultat trouvé -h, --help Aide pour la commande repo --max-col-width uint Largeur maximum de colonne pour la table de sortie (par défaut 50) -o, --output format Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table) -r, --regexp Utiliser des expressions régulières pour rechercher dans les répertoires que vous avez ajoutés --version string Utiliser une contrainte de version sémantique sur les répertoires que vous avez ajoutés -l, --versions Affiche la longue liste, avec chaque version de chaque chart sur sa propre ligne, pour les répertoires que vous avez ajoutés ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm search](/helm/helm_search.md) - Recherche par mot clé dans les charts ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- Affiche les informations sur le chart ### Synopsis Cette commande se compose de plusieurs sous-commandes pour afficher des informations sur les charts. ### Options ``` -h, --help Aide pour la commande show ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes * [helm show all](/helm/helm_show_all.md) - Affiche toutes les informations sur le chart * [helm show chart](/helm/helm_show_chart.md) - Affiche la définition du chart * [helm show crds](/helm/helm_show_crds.md) - Affiche les CRDs du chart * [helm show readme](/helm/helm_show_readme.md) - Affiche le README du chart * [helm show values](/helm/helm_show_values.md) - Affiche les Values du chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- Affiche toutes les informations sur un chart ### Synopsis Cette commande inspecte un chart (dossier, fichier ou URL) et affiche tout son contenu (values.yaml, Chart.yaml, README). ``` helm show all [CHART] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --devel Utiliser également les versions de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande all --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le répertoire de chart où est le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --repo string URL du répertoire du chart demandé --username string Nom d'utilisateur pour le répertoire du chart demandé --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou il peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm show](/helm/helm_show.md) - Affiche les informations sur un chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- Affiche la définition du chart ### Synopsis Cette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier Chart.yaml. ``` helm show chart [CHART] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --devel Utiliser également les versions de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande chart --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le répertoire de chart où est le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --repo string URL du répertoire du chart demandé --username string Nom d'utilisateur pour le répertoire du chart demandé --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou il peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm show](/helm/helm_show.md) - Affiche les informations sur un chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- Affiche les CRDs du chart ### Synopsis Cette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu des fichiers des CustomResourceDefinition. ``` helm show crds [CHART] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --devel Utiliser également les version de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande crds --insecure-skip-tls-verify Passe les vérification du certificat TLS pour le transfer du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le répertoire de chart où est le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --repo string URL du répertoire du chart demandé --username string Nom d'utilisateur pour le répertoire du chart demandé --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou il peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm show](/helm/helm_show.md) - Affiche les informations du chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- Affiche le README du chart ### Synopsis Cette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier README. ``` helm show readme [CHART] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --devel Utiliser également les versions de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande readme --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le répertoire de chart où est le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --repo string URL du répertoire du chart demandé --username string Nom d'utilisateur pour le répertoire du chart demandé --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou il peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm show](/helm/helm_show.md) - Affiche les informations du chart ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- Affiche les values du chart ### Synopsis Cette commande inspecte un chart (dossier, fichier ou URL) et affiche le contenu du fichier values.yaml. ``` helm show values [CHART] [flags] ``` ### Options ``` --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --devel Utiliser également les version de développement (alpha, beta, et versions candidates). Équivalent à version '>0.0.0-0'. Si --version est fixé, cela sera ignoré -h, --help Aide pour la commande values --insecure-skip-tls-verify Passe les vérifications du certificat TLS pour le transfert du chart --jsonpath string fournir une expression JSONPath pour filtrer la sortie --key-file string Identifie le client HTTPS à l'aide de ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le répertoire de chart où est le chart demandé --plain-http Utilise une connexion HTTP non-sécurisée pour le transfert du chart --repo string URL du répertoire du chart demandé --username string Nom d'utilisateur pour le répertoire du chart demandé --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou il peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm show](/helm/helm_show.md) - Affiche les informations du chart ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- Affiche le statut de la release nommée ### Synopsis Cette commande affiche l'état d'une release nommée. Le statut est composé de : - heure du dernier déploiement - namespace k8s dans lequel se trouve la release - l'état de la release (peut être : unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback) - révision de la release - description de la release (peut être un message de complément ou un message d'erreur, besoin d'activer `--show-desc`) - liste des ressources dont se compose cette release (besoin d'activer `--show-resources`) - détails sur la dernière exécution de la suite de tests, si disponible - notes supplémentaires fournies par le chart ``` helm status RELEASE_NAME [flags] ``` ### Options ``` -h, --help Aide pour la commande status -o, --output format Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table) --revision int Si fixé, affiche le statut de la release nommée avec la révision --show-desc Si fixé, affiche la description de la release nommée --show-resources Si fixé, affiche les ressources de la release nommée ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- Rendu local de modèles ### Synopsis Rendu local de modèle de chart et affiche le résultat. Toutes les valeurs qui seraient normalement recherchées ou récupérées dans le cluster seront simulées localement. De plus, aucun des tests côté serveur de validité ne sera effectué (par exemple, si une API est prise en charge). ``` helm template [NAME] [CHART] [flags] ``` ### Options ``` -a, --api-versions strings Versions de l'API Kubernetes utilisées pour Capabilities.APIVersions --atomic Si défini, le processus d'installation supprimera l'installation en cas d'échec. L'argument --wait sera défini automatiquement si --atomic est utilisé --ca-file string Vérifie les certificats des serveurs compatibles HTTPS à l'aide de ce bundle CA --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --create-namespace Créer le namespace de release s'il n'est pas présent --dependency-update Met à jour les dépendances si elles sont manquantes avant l'installation du chart --description string Ajoute une description personnalisée --devel Utiliser également les versions de développement. Équivalent à version '>0.0.0-0'. Si --version est défini, ceci est ignoré --disable-openapi-validation Si défini, le processus d'installation ne validera pas les modèles générés par rapport au schéma OpenAPI de Kubernetes --dry-run string[="client"] Simule une installation. Si '--dry-run' est défini sans option ou comme '--dry-run=client', aucune tentative de connexion au cluster ne sera effectuée. En définissant '--dry-run=server', des tentatives de connexion au cluster seront autorisées --enable-dns Active les recherches DNS lors du rendu des modèles --force Force les mises à jour des ressources en utilisant une stratégie de remplacement -g, --generate-name Génère le nom (et omet le paramètre NAME) -h, --help Aide pour la commande template --hide-notes Si défini, ne pas afficher les notes dans la sortie de l'installation. N'affecte pas la présence dans les métadonnées du chart --include-crds Inclure les CRDs dans la sortie du modèle --insecure-skip-tls-verify Ignore les vérifications de certificat TLS lors du téléchargement du chart --is-upgrade Définit .Release.IsUpgrade à la place de .Release.IsInstall --key-file string Identifie le client HTTPS en utilisant ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") --kube-version string Version de Kubernetes utilisée pour Capabilities.KubeVersion -l, --labels stringToString Étiquettes qui seront ajoutées aux métadonnées de la release. Doit être séparé par des virgules. (par défaut []) --name-template string Spécifie un modèle à utiliser pour le nom de la release --no-hooks Empêche les hooks de fonctionner pendant l'installation --output-dir string Écrit les modèles exécutés dans des fichiers dans le dossier de sortie au lieu de la sortie standard (stdout) --pass-credentials Transmet les informations d'identification à tous les domaines --password string Mot de passe pour le dépôt de chart où se trouve le chart demandé --plain-http Utilise une connexion HTTP non sécurisée pour le téléchargement du chart --post-renderer postRendererString Chemin vers un exécutable à utiliser pour le post-rendu. S'il existe dans $PATH, le binaire sera utilisé, sinon il essaiera de rechercher l'exécutable au chemin spécifié --post-renderer-args postRendererArgsSlice Un argument pour le post-rendu (peut être spécifié plusieurs fois) (par défaut []) --release-name Utilise le nom de la release dans le chemin du dossier de sortie --render-subchart-notes Si défini, génère les notes du sous-chart avec le chart parent --replace Réutilise le nom donné, uniquement si ce nom correspond à une release supprimée qui reste dans l'historique. Ceci n'est pas sûr en production --repo string URL du dépôt du chart demandé --set stringArray Définit des valeurs en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --set-file stringArray Définit des valeurs depuis un fichier spécifique en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=path1,key2=path2) --set-json stringArray Définit des valeurs en JSON en ligne de commande (vous pouvez spécifier plusieurs ou séparer les valeurs par des virgules : key1=jsonval1,key2=jsonval2) --set-literal stringArray Définit une valeur littérale de type STRING en ligne de commande --set-string stringArray Définit des valeurs de type STRING en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) -s, --show-only stringArray Affiche uniquement les manifestes rendus à partir des modèles donnés --skip-crds Si défini, aucun CRD ne sera installé. Par défaut, les CRD sont installés s'ils ne sont pas déjà présents --skip-schema-validation Si défini, désactive la validation du schéma JSON --skip-tests Exclut les tests de la sortie du modèle --take-ownership Si défini, l'installation ignorera la vérification des annotations Helm et prendra possession des ressources existantes --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) --username string Nom d'utilisateur pour le dépôt du chart demandé --validate Valide vos manifestes par rapport au cluster Kubernetes sur lequel vous êtes actuellement connecté. Il s'agit de la même validation effectuée lors d'une installation -f, --values strings Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs) --verify Vérifie le package avant de l'utiliser --version string Spécifie la contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (ex : 1.1.1) ou elle peut faire référence à une plage valide (ex : ^2.0.0). Si non spécifié, la dernière version sera utilisée --wait Si défini, attendra que tous les Pods, PVCs, Services, et le nombre minimum de Pods d'un Deployment, StatefulSet ou ReplicaSet soient dans un état prêt avant de marquer la release comme réussie. Attendra aussi longtemps que spécifié par '--timeout' --wait-for-jobs Si défini et que '--wait' est activé, attendra que tous les Jobs soient terminés avant de marquer la release comme réussie. Attendra aussi longtemps que spécifié par '--timeout' ``` ### Options héritées des commandes parentes ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port du serveur API Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion au serveur API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le répertoire contenant les index du dépôt mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](./helm.md) - Le gestionnaire de packages Helm pour Kubernetes. ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- Lance des tests sur une release ### Synopsis La commande test, lance des tests sur une release. Cette commande prend le nom d'une release déployée. Les tests à exécuter sont définis dans le chart qui a été installée. ``` helm test [RELEASE] [flags] ``` ### Options ``` --filter strings Spécifier les tests par attribut (actuellement "name") en utilisant la syntaxe attribut=valeur ou '!attribut=valeur' ​​pour exclure un test (vous pouvez spécifier plusieurs valeurs ou des valeurs distinctes avec des virgules : name=test1, name=test2) -h, --help Aide pour la commande test --hide-notes Si défini, ne pas afficher les notes dans la sortie des tests. N'affecte pas leur présence dans les métadonnées du chart --logs Récupère les logs du pod de test (cela s'exécutera une fois tous les tests terminés, mais avant de tout nettoyer) --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) ``` ### Options héritées des commandes parents ``` --burst-limit int Limite coté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'operation --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utilisé pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- Désinstalle une release ### Synopsis Cette commande prend le nom d'une release et la désinstalle. Cela supprimera toutes les ressources associées à la dernière release d'un chart ainsi que l'historique des versions, le libérant pour une utilisation future. Utilisez l'argument `--dry-run` pour voir quelles releases seront désinstallées sans vraiment les désinstaller. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Options ``` --cascade string Doit être "background", "orphan", ou "foreground". Sélectionne la stratégie de suppression en cascade pour les dépendances. Par défaut : background. (par défaut "background") --description string Ajoute une description personnalisée --dry-run Simule une désinstallation -h, --help Aide pour la commande uninstall --ignore-not-found Considère l'erreur "release not found" comme une désinstallation réussie --keep-history Supprime toutes les ressources associées et marque la release comme supprimée, mais conserve l'historique des versions --no-hooks Empêche les hooks de s'exécuter pendant la désinstallation --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) --wait Si défini, attendra que toutes les ressources soient supprimées avant de retourner. Attendra aussi longtemps que la valeur de --timeout ``` ### Options héritées des commandes parentes ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra vos connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom d'hôte utilisé pour contacter le serveur sera utilisé --kube-token string Jeton bearer utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](./helm.md) - Le gestionnaire de paquets Helm pour Kubernetes ###### Généré automatiquement par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- Met à niveau une release ### Synopsis Cette commande met à niveau une release vers une nouvelle version du chart. Les arguments de mise à niveau doivent être une release et un chart. L'argument chart peut être soit : une référence de chart ('example/mariadb'), un chemin vers un répertoire de chart, un chart packagé, ou une URL complète. Pour les références de chart, la dernière version sera spécifiée à moins que l'argument `--version` soit défini. Pour remplacer les valeurs dans un chart, utilisez soit l'argument `--values` et fournissez un fichier, soit utilisez l'argument `--set` et passez la configuration depuis la ligne de commande. Pour forcer les valeurs en chaîne de caractères, utilisez `--set-string`. Vous pouvez utiliser `--set-file` pour définir des valeurs individuelles depuis un fichier lorsque la valeur elle-même est trop longue pour la ligne de commande ou est générée dynamiquement. Vous pouvez également utiliser `--set-json` pour définir des valeurs JSON (scalaires/objets/tableaux) depuis la ligne de commande. Vous pouvez spécifier l'argument `--values`/`-f` plusieurs fois. La priorité sera donnée au dernier fichier spécifié (le plus à droite). Par exemple, si `myvalues.yaml` et `override.yaml` contiennent tous deux une clé nommée 'Test', la valeur définie dans `override.yaml` sera prioritaire : $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Vous pouvez spécifier l'argument `--set` plusieurs fois. La priorité sera donnée à la dernière valeur spécifiée (la plus à droite). Par exemple, si les valeurs 'bar' et 'newbar' sont définies pour une clé nommée 'foo', la valeur 'newbar' sera prioritaire : $ helm upgrade --set foo=bar --set foo=newbar redis ./redis Vous pouvez mettre à jour les valeurs d'une release existante avec cette commande via l'argument `--reuse-values`. Les arguments 'RELEASE' et 'CHART' doivent être définis avec les paramètres d'origine, et les valeurs existantes seront fusionnées avec toutes les valeurs définies via les arguments `--values`/`-f` ou `--set`. La priorité est donnée aux nouvelles valeurs. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis L'argument --dry-run affichera tous les manifests générés du chart, y compris les Secrets qui peuvent contenir des valeurs sensibles. Pour masquer les Secrets Kubernetes, utilisez l'argument --hide-secret. Veuillez considérer attentivement comment et quand ces arguments sont utilisés. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Options ``` --atomic Si défini, le processus de mise à niveau annule les modifications effectuées en cas d'échec. L'argument --wait sera défini automatiquement si --atomic est utilisé --ca-file string Vérifie les certificats des serveurs HTTPS en utilisant ce fichier de certificat racine (CA bundle) --cert-file string Identifie le client HTTPS à l'aide de ce fichier de certificat SSL --cleanup-on-fail Autorise la suppression des nouvelles ressources créées lors de cette mise à niveau en cas d'échec --create-namespace Si --install est défini, crée le namespace de la release s'il n'est pas présent --dependency-update Met à jour les dépendances si elles sont manquantes avant l'installation du chart --description string Ajoute une description personnalisée --devel Utilise également les versions de développement. Équivalent à version '>0.0.0-0'. Si --version est défini, ceci est ignoré --disable-openapi-validation Si défini, le processus de mise à niveau ne validera pas les templates générés par rapport au schéma OpenAPI de Kubernetes --dry-run string[="client"] Simule une installation. Si '--dry-run' est défini sans option ou comme '--dry-run=client', aucune tentative de connexion au cluster ne sera effectuée. En définissant '--dry-run=server', des tentatives de connexion au cluster seront autorisées --enable-dns Active les recherches DNS lors du rendu des templates --force Force les mises à jour des ressources en utilisant une stratégie de remplacement -h, --help Aide pour upgrade --hide-notes Si défini, n'affiche pas les notes dans la sortie de mise à niveau. N'affecte pas la présence dans les métadonnées du chart --hide-secret Masque les Secrets Kubernetes lors de l'utilisation de l'argument --dry-run --history-max int Limite le nombre maximum de révisions sauvegardées par release. Utilisez 0 pour ne pas avoir de limite (par défaut 10) --insecure-skip-tls-verify Ignore les vérifications de certificat TLS lors du téléchargement du chart -i, --install Si une release avec ce nom n'existe pas, lance une installation --key-file string Identifie le client HTTPS en utilisant ce fichier de clé SSL --keyring string Emplacement des clés publiques utilisées pour la vérification (par défaut "~/.gnupg/pubring.gpg") -l, --labels stringToString étiquettes qui seront ajoutées aux métadonnées de la release. Doivent être séparées par des virgules. Les étiquettes de la release originale seront fusionnées avec les étiquettes de mise à niveau. Vous pouvez supprimer une étiquette en utilisant null. (par défaut []) --no-hooks Désactive les hooks pre/post mise à niveau -o, --output format Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table) --pass-credentials Transmet les identifiants à tous les domaines --password string Mot de passe du dépôt de charts où se trouve le chart demandé --plain-http Utilise des connexions HTTP non sécurisées pour le téléchargement du chart --post-renderer postRendererString Chemin vers un exécutable à utiliser pour le post-rendu. S'il existe dans $PATH, le binaire sera utilisé, sinon il essaiera de rechercher l'exécutable au chemin spécifié --post-renderer-args postRendererArgsSlice Un argument pour le post-renderer (peut être spécifié plusieurs fois) (par défaut []) --render-subchart-notes Si défini, génère les notes des sous-charts avec le chart parent --repo string URL du dépôt de charts où se trouve le chart demandé --reset-then-reuse-values Lors de la mise à niveau, réinitialise les valeurs sur celles intégrées au chart, applique les valeurs de la dernière release et fusionne toutes les valeurs à partir de la ligne de commande via --set et -f. Si '--reset-values' ou '--reuse-values' est spécifié, ceci sera ignoré --reset-values Lors de la mise à niveau, réinitialise les valeurs à celles intégrées au chart --reuse-values Lors de la mise à niveau, réutilise les valeurs de la dernière release et fusionne toutes les valeurs depuis la ligne de commande via '--set' et '-f'. Si '--reset-values' est spécifié, ceci sera ignoré --set stringArray Définit des valeurs en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --set-file stringArray Définit des valeurs depuis un fichier spécifié en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=path1,key2=path2) --set-json stringArray Définit des valeurs JSON en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=jsonval1,key2=jsonval2) --set-literal stringArray Définit une valeur littérale de type STRING en ligne de commande --set-string stringArray Définit des valeurs de type STRING en ligne de commande (vous pouvez en spécifier plusieurs ou séparer les valeurs par des virgules : key1=val1,key2=val2) --skip-crds Si défini, aucun CRD ne sera installé lors d'une mise à niveau avec l'option install activée. Par défaut, les CRD sont installés s'ils ne sont pas déjà présents --skip-schema-validation Si défini, désactive la validation du schéma JSON --take-ownership Si défini, la mise à niveau ignorera la vérification des annotations helm et prendra possession des ressources existantes --timeout duration Temps d'attente pour chaque opération Kubernetes (comme les Jobs pour les hooks) (par défaut 5m0s) --username string Nom d'utilisateur du dépôt de charts où se trouve le chart demandé -f, --values strings Spécifie les valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs) --verify Vérifie le paquet avant de l'utiliser --version string Spécifie une contrainte de version pour la version du chart à utiliser. Cette contrainte peut être un tag spécifique (par exemple 1.1.1) ou elle peut faire référence à une plage valide (par exemple ^2.0.0). Si cela n'est pas spécifié, la dernière version est utilisée --wait Si défini, attend que tous les Pods, PVCs, Services, et le nombre minimum de Pods d'un Deployment, StatefulSet ou ReplicaSet soient dans un état prêt avant de marquer la release comme réussie. Attend aussi longtemps que spécifié par '--timeout' --wait-for-jobs Si défini et que '--wait' est activé, attend que tous les Jobs soient terminés avant de marquer la release comme réussie. Attend aussi longtemps que spécifié par '--timeout' ``` ### Options héritées des commandes parentes ``` --burst-limit int Limite de régulation côté client (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string Adresse et port du serveur API Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Fichier de l'autorité de certification pour la connexion au serveur API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, le certificat du serveur API Kubernetes ne sera pas vérifié. Cela rendra vos connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom d'hôte utilisé pour contacter le serveur sera utilisé --kube-token string Jeton bearer utilisé pour l'authentification --kubeconfig string Chemin vers le fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le répertoire contenant les index de dépôts mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](./helm.md) - Le gestionnaire de paquets Helm pour Kubernetes. ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- Vérifie que le chart à l'emplacement donné a été signé et est valide ### Synopsis Vérifie que le chart donné possède un fichier de provenance valide. Les fichiers de provenance fournissent une vérification cryptographique indiquant qu'un chart n'a pas été falsifié et qu'il a été emballé par un fournisseur de confiance. Cette commande peut être utilisée pour vérifier un chart local. Plusieurs autres commandes fournissent des arguments `--verify` qui exécutent la même validation. Pour générer un package signé, utilisez la commande `helm package --sign`. ``` helm verify PATH [flags] ``` ### Options ``` -h, --help Aide pour la commande verify --keyring string Emplacement des clés publiques utilisé pour la vérification (par défaut "~/.gnupg/pubring.gpg") ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela rendra les connexions HTTPS non sécurisées --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du dépôt mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des dépôts (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- Affiche les informations sur la version du client ### Synopsis Affiche la version de Helm. Cela affiche une représentation de la version de Helm. Le résultat ressemblera à ceci : version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version : est la version sémantique de la release. - GitCommit est le hash SHA pour le commit à partir duquel cette version a été construite. - GitTreeState est à "clean" s'il n'y a pas de changement de code local lorsque ce binaire a été construit, et "dirty" si le binaire a été construit à partir de code modifié localement. - GoVersion est la version de Go qui a été utilisée pour compiler Helm. Lorsque vous utilisez l'indicateur `--template`, les propriétés suivantes peuvent être utilisées dans le modèle : - .Version contient la version sémantique de Helm. - .GitCommit est le commit git. - .GitTreeState est l'état du git tree quand Helm a été construit. - .GoVersion contient la version de Go qui a été utilisée pour compiler Helm. Par exemple : `--template='Version: {{.Version}}'` retournera : 'Version: v3.2.1'. ``` helm version [flags] ``` ### Options ``` -h, --help Aide pour la commande version --short Affiche le numéro de version --template string Modèle pour le format de version ``` ### Options héritées des commandes parents ``` --burst-limit int Limite côté client de la bande passante (par défaut 100) --debug Active la sortie détaillée --kube-apiserver string L'adresse et le port API du serveur Kubernetes --kube-as-group stringArray Groupe à utiliser pour l'opération, cet argument peut être répété pour spécifier plusieurs groupes --kube-as-user string Nom d'utilisateur à utiliser pour l'opération --kube-ca-file string Le fichier de l'autorité de certification pour la connexion à l'API Kubernetes --kube-context string Nom du contexte kubeconfig à utiliser --kube-insecure-skip-tls-verify Si true, la validité du certificat du serveur API Kubernetes ne sera pas vérifiée. Cela fera les connexions HTTPS non sûres --kube-tls-server-name string Nom du serveur utilisé pour la validation du certificat du serveur API Kubernetes. S'il n'est pas fourni, le nom de la machine cliente utilisée pour contacter le serveur sera utilisé --kube-token string Jeton utilisé pour l'authentification --kubeconfig string Chemin du fichier de configuration kubeconfig -n, --namespace string Namespace à utiliser pour la requête --qps float32 Requêtes par seconde utilisées lors de la communication avec l'API Kubernetes, sans compter le bursting --registry-config string Chemin vers le fichier de configuration du registre (par défaut "~/.config/helm/registry/config.json") --repository-cache string Chemin vers le fichier contenant les index du répertoire mis en cache (par défaut "~/.cache/helm/repository") --repository-config string Chemin vers le fichier contenant les noms et URLs des répertoires (par défaut "~/.config/helm/repositories.yaml") ``` ### Voir également * [helm](/helm/helm.md) - Le gestionnaire de package Helm pour Kubernetes ###### Auto généré par spf13/cobra le 14-Jan-2026 ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Commandes Helm description: Documentation de toute la liste des commandes CLI helm. sidebar_position: 6 id: helm-category --- # Commandes Helm Vous trouverez ici la liste des commandes CLI helm, avec l'aide sur leur utilisation import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Action Chart Releaser pour automatiser les charts via GitHub Pages description: Décrit comment utiliser l'action Chart Releaser pour automatiser la publication de charts via GitHub Pages. sidebar_position: 3 --- Ce guide décrit comment utiliser [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) pour automatiser la publication de charts via GitHub Pages. Chart Releaser Action est un workflow GitHub Action qui transforme un projet GitHub en dépôt Helm chart auto-hébergé, en utilisant l'outil CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Configuration du dépôt Créez un dépôt Git sous votre organisation GitHub. Vous pouvez nommer le dépôt `helm-charts`, bien que d'autres noms soient également acceptables. Les sources de tous les charts peuvent être placées dans la branche `main`. Les charts doivent être placés dans le répertoire `/charts` à la racine de l'arborescence. Une autre branche nommée `gh-pages` est nécessaire pour publier les charts. Les modifications apportées à cette branche seront automatiquement créées par l'action Chart Releaser décrite ici. Vous pouvez cependant créer cette branche `gh-pages` et y ajouter un fichier `README.md`, qui sera visible aux utilisateurs qui visitent la page. Vous pouvez ajouter des instructions dans le `README.md` pour l'installation des charts comme ceci (remplacez ``, `` et ``) : ``` ## Utilisation [Helm](https://helm.sh) doit être installé pour utiliser les charts. Veuillez consulter la [documentation](https://helm.sh/docs) de Helm pour commencer. Une fois Helm correctement configuré, ajoutez le dépôt comme suit : helm repo add https://.github.io/helm-charts Si vous avez déjà ajouté ce dépôt précédemment, exécutez `helm repo update` pour récupérer les dernières versions des packages. Vous pouvez ensuite exécuter `helm search repo ` pour voir les charts disponibles. Pour installer le chart : helm install my- / Pour désinstaller le chart : helm uninstall my- ``` Les charts seront publiés sur un site web avec une URL comme celle-ci : https://.github.io/helm-charts ## Workflow GitHub Actions Créez un fichier de workflow GitHub Actions dans la branche `main` à l'emplacement `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` La configuration ci-dessus utilise [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) pour transformer votre projet GitHub en dépôt Helm chart auto-hébergé. À chaque push sur main, l'action vérifie chaque chart de votre projet. Lorsqu'une nouvelle version est détectée, elle crée une release GitHub correspondante nommée d'après la version du chart, y ajoute les artefacts Helm chart, puis crée ou met à jour un fichier `index.yaml` contenant les métadonnées de ces releases. Ce fichier est ensuite hébergé sur GitHub Pages. Le numéro de version de Chart Releaser Action utilisé dans l'exemple ci-dessus est `v1.6.0`. Vous pouvez le remplacer par la [dernière version disponible](https://github.com/helm/chart-releaser-action/releases). Remarque : Chart Releaser Action est presque toujours utilisée conjointement avec [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) et [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Synchroniser votre dépôt de charts description: Explique comment synchroniser vos dépôts de charts locaux et distants. sidebar_position: 2 --- *Remarque : cet exemple est spécifiquement conçu pour un bucket Google Cloud Storage (GCS) qui héberge un dépôt de charts.* ## Prérequis * Installez l'outil [gsutil](https://cloud.google.com/storage/docs/gsutil). *Nous nous appuyons fortement sur la fonctionnalité rsync de gsutil* * Assurez-vous d'avoir accès au binaire Helm * _Optionnel : nous vous recommandons d'activer le [versionnement des objets](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) sur votre bucket GCS en cas de suppression accidentelle._ ## Configurer un répertoire local pour le dépôt de charts Créez un répertoire local comme nous l'avons fait dans [le guide des dépôts de charts](/topics/chart_repository.md), et placez vos charts empaquetés dans ce répertoire. Par exemple : ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Générer un fichier index.yaml mis à jour Utilisez Helm pour générer un fichier index.yaml mis à jour en passant le chemin du répertoire et l'URL du dépôt distant à la commande `helm repo index` comme ceci : ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Cela générera un fichier index.yaml mis à jour et le placera dans le répertoire `fantastic-charts/`. ## Synchroniser vos dépôts de charts local et distant Téléversez le contenu du répertoire vers votre bucket GCS en exécutant `scripts/sync-repo.sh` et en passant le nom du répertoire local et le nom du bucket GCS. Par exemple : ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Mettre à jour votre dépôt de charts Vous devriez conserver une copie locale du contenu de votre dépôt de charts ou utiliser `gsutil rsync` pour copier le contenu de votre dépôt de charts distant vers un répertoire local. Par exemple : ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Liens utiles : * Documentation sur [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Le guide des dépôts de charts](/topics/chart_repository.md) * Documentation sur le [versionnement des objets et le contrôle de concurrence](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) dans Google Cloud Storage ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Trucs et astuces pour le développement de charts description: Présente des trucs et astuces que les développeurs de charts Helm ont appris lors de la création de charts de qualité production. sidebar_position: 1 --- Ce guide présente des trucs et astuces que les développeurs de charts Helm ont appris lors de la création de charts de qualité production. ## Connaître vos fonctions de template Helm utilise les [templates Go](https://godoc.org/text/template) pour créer vos fichiers de ressources. Go est livré avec plusieurs fonctions intégrées, mais nous en avons ajouté beaucoup d'autres. Tout d'abord, nous avons ajouté toutes les fonctions de la [bibliothèque Sprig](https://masterminds.github.io/sprig/), à l'exception de `env` et `expandenv`, pour des raisons de sécurité. Nous avons également ajouté deux fonctions de template spéciales : `include` et `required`. La fonction `include` vous permet d'intégrer un autre template, puis de passer les résultats à d'autres fonctions de template. Par exemple, ce fragment de template inclut un template appelé `mytpl`, puis convertit le résultat en minuscules, puis l'entoure de guillemets doubles. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` La fonction `required` vous permet de déclarer une entrée de values particulière comme obligatoire pour le rendu du template. Si la valeur est vide, le rendu du template échouera avec un message d'erreur soumis par l'utilisateur. L'exemple suivant de la fonction `required` déclare qu'une entrée pour `.Values.who` est requise, et affichera un message d'erreur lorsque cette entrée est manquante : ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Mettre les chaînes entre guillemets, pas les entiers Lorsque vous travaillez avec des données de type chaîne de caractères, il est toujours plus sûr de mettre les chaînes entre guillemets plutôt que de les laisser comme des mots bruts : ```yaml name: {{ .Values.MyName | quote }} ``` Mais lorsque vous travaillez avec des entiers, _ne mettez pas les valeurs entre guillemets._ Cela peut, dans de nombreux cas, provoquer des erreurs d'analyse dans Kubernetes. ```yaml port: {{ .Values.Port }} ``` Cette remarque ne s'applique pas aux valeurs des variables d'environnement qui sont censées être des chaînes, même si elles représentent des entiers : ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Utiliser la fonction 'include' Go fournit un moyen d'inclure un template dans un autre en utilisant une directive `template` intégrée. Cependant, la fonction intégrée ne peut pas être utilisée dans les pipelines de templates Go. Pour permettre d'inclure un template, puis d'effectuer une opération sur la sortie de ce template, Helm dispose d'une fonction spéciale `include` : ``` {{ include "toYaml" $value | indent 2 }} ``` Ce qui précède inclut un template appelé `toYaml`, lui passe `$value`, puis passe la sortie de ce template à la fonction `indent`. Parce que YAML accorde de l'importance aux niveaux d'indentation et aux espaces blancs, c'est un excellent moyen d'inclure des fragments de code, tout en gérant l'indentation dans un contexte approprié. ## Utiliser la fonction 'required' Go fournit un moyen de définir des options de template pour contrôler le comportement lorsqu'une map est indexée avec une clé qui n'est pas présente dans la map. Cela se fait généralement avec `template.Options("missingkey=option")`, où `option` peut être `default`, `zero` ou `error`. Bien que définir cette option sur error arrêtera l'exécution avec une erreur, cela s'appliquera à chaque clé manquante dans la map. Il peut y avoir des situations où un développeur de chart souhaite appliquer ce comportement pour certaines valeurs sélectionnées dans le fichier `values.yaml`. La fonction `required` donne aux développeurs la possibilité de déclarer une entrée de valeur comme obligatoire pour le rendu du template. Si l'entrée est vide dans `values.yaml`, le template ne sera pas rendu et retournera un message d'erreur fourni par le développeur. Par exemple : ``` {{ required "A valid foo is required!" .Values.foo }} ``` Ce qui précède rendra le template lorsque `.Values.foo` est défini, mais échouera au rendu et quittera lorsque `.Values.foo` n'est pas défini. ## Utiliser la fonction 'tpl' La fonction `tpl` permet aux développeurs d'évaluer des chaînes comme des templates à l'intérieur d'un template. C'est utile pour passer une chaîne de template comme valeur à un chart ou rendre des fichiers de configuration externes. Syntaxe : `{{ tpl TEMPLATE_STRING VALUES }}` Exemples : ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Rendu d'un fichier de configuration externe : ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Créer des Image Pull Secrets Les image pull secrets sont essentiellement une combinaison de _registry_, _username_ et _password_. Vous pouvez en avoir besoin dans une application que vous déployez, mais les créer nécessite d'exécuter `base64` plusieurs fois. Nous pouvons écrire un template helper pour composer le fichier de configuration Docker à utiliser comme contenu du Secret. Voici un exemple : Tout d'abord, supposons que les identifiants sont définis dans le fichier `values.yaml` comme suit : ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Nous définissons ensuite notre template helper comme suit : ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Enfin, nous utilisons le template helper dans un template plus large pour créer le manifeste Secret : ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Déclencher automatiquement le redéploiement des Deployments Souvent, les ConfigMaps ou Secrets sont injectés comme fichiers de configuration dans les conteneurs, ou il existe d'autres changements de dépendances externes qui nécessitent le redémarrage des pods. Selon l'application, un redémarrage peut être nécessaire si ceux-ci sont mis à jour avec un `helm upgrade` ultérieur, mais si la spec du deployment elle-même n'a pas changé, l'application continue de fonctionner avec l'ancienne configuration, résultant en un déploiement incohérent. La fonction `sha256sum` peut être utilisée pour s'assurer qu'une section d'annotation d'un deployment est mise à jour si un autre fichier change : ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTE : Si vous ajoutez ceci à un library chart, vous ne pourrez pas accéder à votre fichier dans `$.Template.BasePath`. À la place, vous pouvez référencer votre définition avec `{{ include ("mylibchart.configmap") . | sha256sum }}`. Dans le cas où vous voulez toujours déclencher le redéploiement, vous pouvez utiliser une étape d'annotation similaire à celle ci-dessus, en remplaçant par une chaîne aléatoire afin qu'elle change toujours et provoque le redéploiement : ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Chaque invocation de la fonction de template générera une chaîne aléatoire unique. Cela signifie que s'il est nécessaire de synchroniser les chaînes aléatoires utilisées par plusieurs ressources, toutes les ressources concernées devront être dans le même fichier de template. Ces deux méthodes permettent à votre Deployment d'exploiter la logique de stratégie de mise à jour intégrée pour éviter les temps d'arrêt. NOTE : Par le passé, nous recommandions d'utiliser le flag `--recreate-pods` comme autre option. Ce flag a été marqué comme déprécié dans Helm 3 en faveur de la méthode déclarative ci-dessus. ## Indiquer à Helm de ne pas désinstaller une ressource Parfois, certaines ressources ne doivent pas être désinstallées lorsque Helm exécute un `helm uninstall`. Les développeurs de charts peuvent ajouter une annotation à une ressource pour empêcher sa désinstallation. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` L'annotation `helm.sh/resource-policy: keep` indique à Helm d'ignorer la suppression de cette ressource lorsqu'une opération helm (comme `helm uninstall`, `helm upgrade` ou `helm rollback`) entraînerait sa suppression. _Cependant_, cette ressource devient orpheline. Helm ne la gérera plus d'aucune manière. Cela peut poser des problèmes si vous utilisez `helm install --replace` sur une release qui a déjà été désinstallée, mais qui a conservé des ressources. ## Utiliser les « Partials » et les includes de templates Parfois, vous souhaitez créer des éléments réutilisables dans votre chart, qu'il s'agisse de blocs ou de partials de templates. Et souvent, il est plus propre de les conserver dans leurs propres fichiers. Dans le répertoire `templates/`, tout fichier commençant par un underscore (`_`) n'est pas censé produire un fichier manifeste Kubernetes. Par convention, les templates helpers et les partials sont placés dans un fichier `_helpers.tpl`. ## Charts complexes avec de nombreuses dépendances De nombreux charts sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF sont des « blocs de construction » pour créer des applications plus avancées. Mais les charts peuvent également être utilisés pour créer des instances d'applications à grande échelle. Dans de tels cas, un seul chart parapluie peut avoir plusieurs sous-charts, chacun fonctionnant comme une pièce de l'ensemble. La meilleure pratique actuelle pour composer une application complexe à partir d'éléments discrets est de créer un chart parapluie de niveau supérieur qui expose les configurations globales, puis d'utiliser le sous-répertoire `charts/` pour intégrer chacun des composants. ## YAML est un sur-ensemble de JSON Selon la spécification YAML, YAML est un sur-ensemble de JSON. Cela signifie que toute structure JSON valide devrait être valide en YAML. Cela présente un avantage : parfois, les développeurs de templates peuvent trouver plus facile d'exprimer une structure de données avec une syntaxe de type JSON plutôt que de gérer la sensibilité aux espaces blancs de YAML. En tant que bonne pratique, les templates devraient suivre une syntaxe de type YAML _sauf si_ la syntaxe JSON réduit substantiellement le risque de problème de formatage. ## Attention à la génération de valeurs aléatoires Il existe des fonctions dans Helm qui vous permettent de générer des données aléatoires, des clés cryptographiques, etc. C'est bien de les utiliser. Mais sachez que lors des mises à niveau, les templates sont ré-exécutés. Lorsqu'une exécution de template génère des données qui diffèrent de la dernière exécution, cela déclenchera une mise à jour de cette ressource. ## Installer ou mettre à niveau une release avec une seule commande Helm fournit un moyen d'effectuer une installation ou une mise à niveau en une seule commande. Utilisez `helm upgrade` avec la commande `--install`. Cela amènera Helm à vérifier si la release est déjà installée. Si ce n'est pas le cas, il exécutera une installation. Si elle l'est, alors la release existante sera mise à niveau. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: Comment faire sidebar_position: 2 --- # Comment faire Dans cette section vous trouverez un ensemble de courtes réponses aux questions "**Comment faire ...?**". Ces guides ne vont pas traiter de sujets en profondeur *(La documentation dans les guides par [Thèmes](/topics/index.mdx))*, cependant ils vous aideront à réussir rapidement des tâches simples. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Accueil Documentations" description: "Tout ce que vous devez savoir sur l'organisation de la documentation." --- # Bienvenue Bienvenue dans la documentation de [Helm](https://helm.sh/). Helm est le manageur de paquet pour Kubernetes. Les informations générales détaillées sont disponnibles ici : [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). # Comment la documentation est organisée Helm a beaucoup de documentation. Voici un aperçu de son organisation pour vous aider à chercher: - [Les Tutoriels](/intro/index.mdx) vous guide à travers une série d'étapes pour créer votre premier tableau Helm. Commencez ici si vous êtes nouveau dans Helm. - [Les Guides thématiques](/topics/index.mdx) abordent des sujets et concepts clés à un niveau assez élevé et fournissent des informations de base et des explications utiles. - [Le Guide de la communauté](/community) aborde des sujets centrés sur la communauté de Helm. Rendez-vous dessus si vous souhaitez en savoir plus sur le processus de développement de Helm en lui-même et comment vous pouvez y contribuer. - [Les Guides pratiques](/howto/index.mdx) sont des recettes. Ils vous guident à travers les étapes qui permettent de résoudre les problèmes clés et les cas d’utilisations. Ils sont plus avancés que les tutoriels et nécessitent une certaine connaissance du fonctionnement de Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Cheat Sheet description: Helm cheatsheet sidebar_position: 4 --- La cheatsheet d'Helm contient toutes les commandes nécessaires pour gérer une application avec Helm. --- ### Base Chart: - Il s'agit du nom de votre chart dans le cas où il aurait été téléchargé ou décompressé. - Il s'agit du / dans le cas où le répertoire a été ajouté mais que le chart n'a pas été téléchargé. - Il s'agit de l'URL/chemin absolu vers le chart. Name: - C'est le nom que vous souhaitez donner à votre installation du Chart Helm. Release: - C'est le nom que vous donnez à une instance d'installation. Revision: - C'est le numéro de l'historique de déploiement. Repo-name: - Le nom d'un dépôt. DIR: - Nom/chemin du dossier --- ### Gestion des Chart ```bash helm create # Créer un dossier chart avec les fichiers et dossiers utilisés dans un chart. helm package # Emballe un chart dans une archive compressée et versionnée. helm lint # Lance des tests pour examiner un chart et identifier des problèmes. helm show all # Inspecte et liste le contenu d'un chart. helm show values # Affiche le contenu du fichier values.yaml helm pull # Télécharge/pull un chart helm pull --untar=true # Si spécifié à true, décompresse le chart une fois téléchargé. helm pull --verify # Vérifie le package avant de l'utiliser helm pull --version # Par défaut, c'est la dernière version (latest) qui est utilisée, vous pouvez spécifier une version à utiliser. helm dependency list # Affiche la liste des dépendances du chart. ``` --- ### Installer et Désinstaller des Applications ```bash helm install # Installe le chart avec son nom. helm install --namespace # Installe le chart dans un namespace spécifié. helm install --set key1=val1,key2=val2 # Définir des valeurs en ligne de commande (vous pouvez spécifier plusieurs valeur ou les séparer par des virgules). helm install --values # Installe le chart avec vos valeurs spécifiques. helm install --dry-run --debug # Lance un test d'installation pour valider le chart. helm install --verify # Vérifie le package avant de l'utiliser. helm install --dependency-update # Met à jour les dépendances si elles sont manquantes avant d'installer le chart. helm uninstall # Désinstalle une release du namespace courant (par défaut). helm uninstall --namespace # Désinstalle une release du namespace spécifié. ``` --- ### Mise à jour et Restauration de l'Application ```bash helm upgrade # Met à niveau une version helm upgrade --rollback-on-failure # Si fixé, le processus de mise à niveau restaure en cas d'erreur helm upgrade --dependency-update # Met à jour les dépendances si elles sont manquantes avant d'installer le chart helm upgrade --version # Spécifie une version à installer helm upgrade --values # Spécifier des valeurs dans un fichier YAML ou une URL (vous pouvez en spécifier plusieurs) helm upgrade --set key1=val1,key2=val2 # Définir des valeurs en ligne de commande (vous pouvez spécifier plusieurs valeurs ou les séparer par des virgules) helm upgrade --force # Force la mise à jour des ressources via une stratégie de remplacement helm rollback # Restaure une release vers une révision spécifique helm rollback --cleanup-on-fail # Autorise la suppression des nouvelles ressources créées si le rollback échoue ``` --- ### Lister, Ajouter, Supprimer et Mettre à jour des dépôts ```bash helm repo add # Ajoute un dépôt depuis Internet. helm repo list # Liste les dépôts de charts ajoutés. helm repo update # Met à jour les informations des charts disponibles localement à partir des dépôts. helm repo remove # Supprime un ou plusieurs dépôts. helm repo index # Lit le dossier courant et génère un fichier d'index sur les charts trouvés. helm repo index --merge # Fusionne l'index généré avec un fichier d'index existant. helm search repo # Recherche des dépôts pour un mot clé dans les charts. helm search hub # Recherche des charts sur l'Artifact Hub ou sur votre propre instance hub. ``` --- ### Surveillance des Version Helm ```bash helm list # Liste toutes les versions pour un namespace spécifique, utilise le namespace du contexte courant si le namespace n'est pas spécifié. helm list --all # Liste toutes les versions sans filtre appliqué, vous pouvez utiliser '-a'. helm list --all-namespaces # Liste toutes les versions dans tous les namespaces, vous pouvez utiliser '-A'. helm list -l key1=value1,key2=value2 # Sélecteur (requête sur les étiquettes) sur lequel filtrer, prend en charge '=', '==', et '!='. helm list --date # Tri par date de sortie. helm list --deployed # Liste les releases déployées. Si aucune n'est spécifiée, cela sera automatiquement activé. helm list --pending # Liste les releases en attente. helm list --failed # Liste les releases ayant échoué. helm list --uninstalled # Liste les releases désinstallées (si 'helm uninstall --keep-history' a été utilisé). helm list --superseded # Liste les releases remplacées. helm list -o yaml # Affiche la sortie dans le format spécifié. Valeurs autorisées : table, json, yaml (par défaut table). helm status # Cette commande affiche l'état de la release nommée. helm status --revision # Si fixé, affiche l'état d'une release nommée avec sa révision. helm history # Historique des révisions pour une release donnée. helm env # Affiche toutes les informations sur l'environnement utilisées par Helm. ``` --- ### Télécharger les Informations des Versions ```bash helm get all # Une collection d'informations lisible par l'homme sur les notes, les hooks, les valeurs fournies et le fichier manifeste généré de la release donnée. helm get hooks # Cette commande télécharge les hooks d'une release. Les hooks sont formatés en YAML et séparés par le séparateur YAML '---\n'. helm get manifest # Un manifeste est une représentation encodée en YAML des ressources Kubernetes qui ont été générées par cette release du/des chart(s). Si un chart dépend d'autres charts, ces ressources seront également incluses dans le manifeste. helm get notes # Affiche les notes fournies par le chart d'une release donnée. helm get values # Télécharge un fichier de valeurs pour une release donnée. Utilisez l'argument '-o' pour formater la sortie. ``` --- ### Gestion des Plugins ```bash helm plugin install # Installe des plugins helm plugin list # Affiche la liste des plugins installés helm plugin update # Met à jour des plugins helm plugin uninstall # Désinstalle un plugin ``` --- ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: Introduction sidebar_position: 1 --- # Introduction à Helm Vous êtes nouveau sur Helm ? C'est ici que ça commence ! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Installation de Helm description: Apprenez à installer Helm et à le prendre en main. sidebar_position: 2 --- Ce guide vous explique comment installer la CLI (Interface de Ligne de Commande) Helm. Helm peut être installé soit à partir des sources, soit à partir des releases binaires pré-construites. ## Depuis le projet Helm Le projet Helm propose deux méthodes pour récupérer et installer Helm. Il s'agit des méthodes officielles pour obtenir les releases de l'application. En plus de cela, la communauté Helm fournit des méthodes pour installer Helm via différents gestionnaires de packages. L'installation via ces méthodes peut être trouvée ci-dessous, après les méthodes officielles. ### À partir des releases binaires Chaque [release](https://github.com/helm/helm/releases) de Helm fournit des binaires pour une variété de systèmes d'exploitation. Ces binaires peuvent être téléchargés manuellement et installés. 1. Téléchargez la [version souhaitée](https://github.com/helm/helm/releases) 2. Décompressez l'archive (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Trouvez le binaire `helm` dans le répertoire décompressé, et déplacez-le à l'emplacement souhaité (`mv linux-amd64/helm /usr/local/bin/helm`) À ce stade, vous devriez être capable de lancer le client et [d'ajouter le dépôt stable](/intro/quickstart.md#initialize-a-helm-chart-repository) : `helm help`. **Remarque :** Les tests automatisés de Helm sont effectués pour Linux AMD64 uniquement pendant les builds et releases GitHub Actions. Les tests d'autres systèmes d'exploitation sont sous la responsabilité de la communauté qui demande Helm pour le système d'exploitation en question. ### À partir du script Helm dispose maintenant d'un script d'installation qui récupère automatiquement la dernière version de Helm et [l'installe localement](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Vous pouvez récupérer ce script, puis l'exécuter localement. Il est bien documenté, ce qui vous permet de le lire et comprendre ce qu'il fait avant de l'exécuter. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Oui, vous pouvez également exécuter `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` si vous aimez vivre dangereusement. ## Via les gestionnaires de packages La communauté Helm offre la possibilité d'installer Helm via le gestionnaire de packages de votre système d'exploitation. Ceux-ci ne sont pas pris en charge par le projet Helm et ne sont pas considérés comme des tiers de confiance. ### Depuis Homebrew (macOS) Les membres de la communauté Helm ont contribué à la création d'une formule Helm pour Homebrew. Cette formule est généralement à jour. ```console brew install helm ``` (Note : il existe un projet différent possédant une formule pour emacs-helm.) ### Depuis Chocolatey (Windows) Les membres de la communauté Helm ont contribué à la création d'un [package Helm](https://chocolatey.org/packages/kubernetes-helm) pour [Chocolatey](https://chocolatey.org/). Ce package est généralement à jour. ```console choco install kubernetes-helm ``` ### Depuis Scoop (Windows) Les membres de la communauté Helm ont contribué à la création d'un [package Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) pour [Scoop](https://scoop.sh). Ce package est généralement à jour. ```console scoop install helm ``` ### Depuis Winget (Windows) Les membres de la communauté Helm ont contribué à la création d'un [package Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) pour [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Ce package est généralement à jour. ```console winget install Helm.Helm ``` ### Depuis Apt (Debian/Ubuntu) Les membres de la communauté Helm ont contribué à la création d'un package Apt pour Debian/Ubuntu. Ce package est généralement à jour. Merci à [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) pour l'hébergement du dépôt. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Depuis dnf/yum (Fedora) Depuis Fedora 35, Helm est disponible dans le dépôt officiel. Vous pouvez installer Helm en exécutant : ```console sudo dnf install helm ``` ### Depuis Snap La communauté des [Snapcrafters](https://github.com/snapcrafters) maintient la version Snap du [package Helm](https://snapcraft.io/helm) : ```console sudo snap install helm --classic ``` ### Depuis pkg (FreeBSD) Les membres de la communauté FreeBSD ont contribué à la création d'un [package Helm](https://www.freshports.org/sysutils/helm) pour la [Collection de Ports FreeBSD](https://man.freebsd.org/ports). Ce package est généralement à jour. ```console pkg install helm ``` ### Builds de développement En plus des releases, vous pouvez également télécharger et installer les snapshots de développement de Helm. ### Depuis les builds Canary Les builds "Canary" sont des versions du logiciel Helm construites à partir de la dernière version de la branche `main`. Ce ne sont pas des releases officielles et peuvent ne pas être stables. Cependant, elles permettent de tester les fonctionnalités les plus récentes. Les binaires Canary de Helm sont disponibles sur `get.helm.sh`. Voici les liens vers les builds les plus courants : - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Depuis les sources (Linux, macOS) Construire Helm à partir des sources demande un peu plus de travail, mais c'est le meilleur moyen de tester la dernière version (pré-release) de Helm. Vous devez disposer d'un environnement Go fonctionnel. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` Si nécessaire, les dépendances seront récupérées et mises en cache, puis la configuration sera validée. `helm` sera ensuite compilé et placé dans `bin/helm`. ## Conclusion Dans la plupart des cas, l'installation est aussi simple que de récupérer un binaire `helm` pré-compilé. Ce document couvre des cas supplémentaires pour ceux qui souhaitent utiliser Helm de manière plus avancée. Une fois que le client Helm est installé avec succès, vous pouvez passer à l'utilisation de Helm pour gérer des charts et [ajouter le dépôt stable](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Guide de démarrage rapide description: Comment installer et débuter avec Helm, y compris les instructions pour les distributions, FAQ et plugins. sidebar_position: 1 --- Ce guide explique comment commencer rapidement à utiliser Helm. ## Conditions préalables Les conditions préalables suivantes sont requises pour une utilisation correcte et sécurisée de Helm : 1. Un cluster Kubernetes 2. Décider des configurations de sécurité à appliquer à votre installation, si nécessaire 3. Installation et configuration de Helm ### Installer Kubernetes ou avoir accès à un cluster - Vous devez avoir Kubernetes installé. Pour la dernière release de Helm, nous recommandons la dernière version stable de Kubernetes, qui est dans la plupart des cas la deuxième release mineure la plus récente. - Vous devriez également avoir une copie locale configurée de `kubectl`. Consultez la [Politique de prise en charge des versions de Helm](https://helm.sh/docs/topics/version_skew/) pour connaître le décalage de version maximal pris en charge entre Helm et Kubernetes. ## Installer Helm Téléchargez le binaire de la release de Helm. Vous pouvez utiliser des outils comme `homebrew`, ou consulter [la page des releases officielles](https://github.com/helm/helm/releases). Pour plus de détails ou d'autres options, consultez [le guide d'installation](/intro/install.md). ## Initialiser un dépôt de charts Helm Une fois Helm prêt, vous pouvez ajouter un dépôt de charts. Consultez [Artifact Hub](https://artifacthub.io/packages/search?kind=0) pour voir les dépôts de charts Helm disponibles. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Une fois le dépôt ajouté, vous pourrez lister les charts disponibles : ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Installer un chart d'exemple Pour installer un chart, vous pouvez exécuter la commande `helm install`. Helm dispose de plusieurs moyens pour trouver et installer un chart, mais le plus simple est d'utiliser les charts `bitnami`. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` Dans l'exemple ci-dessus, le chart `bitnami/mysql` a été déployé, et le nom de notre nouvelle release est `mysql-1612624192`. Vous pouvez obtenir un aperçu des fonctionnalités de ce chart MySQL en exécutant `helm show chart bitnami/mysql`. Ou vous pouvez lancer `helm show all bitnami/mysql` pour obtenir toutes les informations sur le chart. Chaque fois que vous installez un chart, une nouvelle release est créée. Un chart peut donc être installé plusieurs fois sur le même cluster. Et chaque release peut être gérée et mise à jour indépendamment. La commande `helm install` est très puissante et possède de nombreuses fonctionnalités. Pour en apprendre davantage, consultez le [Guide d'utilisation de Helm](/intro/using_helm.md). ## Découvrir les releases Pour voir ce qui a été déployé avec Helm : ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` La fonction `helm list` (ou `helm ls`) vous montrera une liste de toutes les releases déployées. ## Désinstaller une release Pour désinstaller une release, utilisez la commande `helm uninstall` : ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Cela désinstallera `mysql-1612624192` de Kubernetes, supprimant toutes les ressources associées à la release ainsi que l'historique de la release. Si l'option `--keep-history` est fournie, l'historique de la release sera conservé. Vous pourrez alors demander des informations sur cette release : ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Étant donné que Helm suit vos releases même après les avoir désinstallées, vous pouvez auditer l'historique d'un cluster, et même restaurer une release (avec `helm rollback`). ## Consulter l'aide Pour en savoir plus sur les commandes Helm disponibles, utilisez `helm help` ou tapez une commande suivie de l'option `-h` : ```console $ helm get -h ``` ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Utilisation de Helm description: Explique la base de Helm. sidebar_position: 3 --- Ce guide explique les bases de l'utilisation de Helm pour gérer les packages sur votre cluster Kubernetes. Nous partons du principe que vous avez déjà [installé](/intro/install.md) le client Helm. Si vous souhaitez simplement exécuter quelques commandes rapides, vous pouvez commencer par le [Guide de démarrage rapide](/intro/quickstart.md). Ce chapitre couvre les différentes commandes Helm et explique comment les utiliser. ## Trois grands concepts Un *Chart* est un package Helm. Il contient toutes les définitions des ressources nécessaires pour exécuter une application, un outil ou un service à l'intérieur d'un cluster Kubernetes. Voyez cela comme l'équivalent Kubernetes d'une formule Homebrew, d'un paquet dpkg Apt, ou d'un fichier RPM Yum. Un *Dépôt* est l'endroit où les charts peuvent être collectés et partagés. C'est comme les [archives CPAN de Perl](https://www.cpan.org) ou la [base de données de paquets Fedora](https://src.fedoraproject.org/), mais pour les packages Kubernetes. Une *Release* est une instance d'un chart s'exécutant dans un cluster Kubernetes. Un chart peut être installé plusieurs fois dans le même cluster. Et à chaque fois qu'il est à nouveau installé, une nouvelle _release_ est créé. Prenons un chart MySQL, si vous voulez deux bases de données s'exécutant dans votre cluster, vous pouvez installer ce chart deux fois. Chacune aura sa propre _release_, qui à son tour aura son propre _release name_. Maintenant que vous maîtrisez ces concepts, nous pouvons aborder Helm de la manière suivante : Helm installe des _charts_ dans Kubernetes, créant une nouvelle _release_ pour chaque installation. Et pour trouver de nouveaux charts, vous pouvez rechercher des _repositories_ (dépôts) de charts Helm. ## 'helm search': La recherche de charts Helm est livré avec une puissante commande de recherche. Elle peut être utilisée pour rechercher deux différents types de ressources : - `helm search hub` recherche sur [Artifact Hub](https://artifacthub.io), qui liste les charts Helm provenant de dizaines de dépôts différents. - `helm search repo` recherche dans les dépôts que vous avez ajoutés à votre configuration locale (via `helm repo add`). Cette recherche s'effectue localement et ne nécessite pas de connexion internet. Vous pouvez trouver des charts publiquement disponibles avec la commande `helm search hub` : ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` La commande ci-dessus recherche toutes les charts `wordpress` sur Artifact Hub. Sans filtre, `helm search hub` affiche tous les charts disponibles. `helm search hub` expose l'URL vers l'emplacement sur [artifacthub.io](https://artifacthub.io/) mais pas l'URL réelle du dépôt Helm. `helm search hub --list-repo-url` expose l'URL réelle du dépôt Helm, ce qui est pratique lorsque vous souhaitez ajouter un nouveau dépôt : `helm repo add [NOM] [URL]`. En utilisant `helm search repo`, vous pouvez trouver les noms des charts dans les dépôts que vous avez ajoutés manuellement : ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` La commande de recherche de Helm utilise un algorithme de correspondance de chaîne de caractères, vous pouvez donc saisir des mots ou des parties de mots : ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` La recherche est un bon moyen de trouver les packages disponibles. Une fois que vous avez trouvé une application que vous souhaitez installer, vous pouvez utiliser `helm install` pour l'installer. ## 'helm install': Installation d'un package Pour installer un nouveau package, utilisez la commande `helm install`. Dans sa forme la plus simple, elle prend deux arguments: le nom de la version voulue et le nom du chart que vous voulez installer. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Le chart `wordpress` est maintenant installé. Notez que l'installation d'un chart crée un nouvel objet _release_. La version ci-dessus est nommée «happy-panda». (Si vous voulez que Helm génère un nom pour vous, oubliez le nom de la version et utilisez `--generate-name`.) Lors de l'installation, le client `helm` affichera des informations utiles sur les ressources qui ont été créées, l'état de la version et si il y a des étapes de configurations supplémentaires que vous pouvez ou devez suivre. Helm installe les ressources dans l'ordre suivant : - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm n'attend pas que toutes les ressources soient en cours d'exécution avant de quitter. De nombreux charts nécessitent des images Docker de plus de 600 Mo et peuvent prendre du temps à s'installer dans le cluster. Pour suivre l'état d'une release ou pour relire les informations de configuration, vous pouvez utiliser `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` La commande ci-dessus montre l'état actuel de votre release. ### Personnalisation d'un chart avant son installation L'installation comme nous l'avons fait ici n'utilisera que les options de configuration par défaut. Il peut arriver que vous souhaitiez personnaliser le chart pour utiliser une configuration personnalisée. Pour voir quelles options sont configurables sur un chart, utilisez `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Vous pouvez ensuite ecraser la configuration par défaut grâce à un fichier YAML que vous passerez en paramètre lors de l'installation. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` La commande ci-dessus créera un utilisateur MariaDB par défaut avec le nom `user0`, et accordera à cet utilisateur l'accès à la base de données `user0db` nouvellement créée, mais prendra le reste des valeurs par défaut pour l'installation du chart. Il existe deux façons de transmettre les données de configuration lors de l'installation: - `--values` (ou `-f`): Spécifie un fichier YAML personnalisé. Vous pouvez spécifier plusieurs fichiers, celui le plus à droite prévaudra. - `--set`: Spécifie une valeur personnalisée en ligne de commande. Si les deux sont utilisés, les valeurs de `--set` sont fusionnées dans `--values` avec une priorité plus élevée. Les remplacements spécifiés avec `--set` sont conservés dans un Secret. Les valeurs définies avec `--set` peuvent être visualisées pour une release donnée avec `helm get values `. Les valeurs définies avec `--set` peuvent être effacées en exécutant `helm upgrade` avec `--reset-values` spécifié. #### Le format et les limites de `--set` L'option `--set` prend zéro ou plusieurs paires de nom/valeur. La manière la plus simple d'utilisation est : `--set name = value`. L'équivalent YAML serait : ```yaml name: value ``` Vous pouvez entrer plusieurs valeurs en les séparant par une virgule `,` . Ainsi `--set a=b,c=d` devient l'équivalent YAML de : ```yaml a: b c: d ``` Des expressions plus complexes sont acceptés. Par exemple l'équivalent de `--set outer.inner=value` en YAML est : ```yaml outer: inner: value ``` Vous pouvez définir des listes grâce à des accolades `{` et `}`. Exemple: `--set name={a, b, c}` devient : ```yaml name: - a - b - c ``` Certaines clés peuvent être définies à `null` ou à un tableau vide `[]`. Par exemple, `--set name=[],a=null` transforme : ```yaml name: - a - b - c a: b ``` en : ```yaml name: [] a: null ``` Depuis Helm 2.5.0, il est possible d'accéder aux éléments d'une liste en utilisant l'index du tableau. Exemple : `--set servers[0].port=80` correspond à : ```yaml servers: - port: 80 ``` Plusieurs valeurs peuvent être définies de cette manière. La ligne suivante `--set servers[0].port=80,servers[0].host=example` devient: ```yaml servers: - port: 80 host: example ``` Il peut arriver que vous ayez besoin d'utiliser un charactère spécial avec `--set`. Pour ce faire vous pouvez utiliser un backslash `\`. Exemple : `--set name=value1\,value2` devient : ```yaml name: "value1,value2" ``` De la même manière, vous pouvez l'utiliser pour une séquence commençant par un point, ce qui peut être utile lorsque les charts utilisent la fonction `toYaml` pour analyser les annotations, les étiquettes et les nœuds sélecteurs. La syntaxe de `--set nodeSelector." Kubernetes \ .io / role "= master` devient: ```yaml nodeSelector: kubernetes.io/role: master ``` Les structures de données profondément imbriquées peuvent être difficiles à exprimer en utilisant `--set`. Les concepteurs de charts sont encouragés à utiliser un fichier de valeurs au format YAML : ` values.yaml` lorsqu'il y a beaucoup de valeurs à configurer (en savoir plus sur [les fichiers de valeurs](/chart_template_guide/values_files.md)). ### Autres méthodes d'installation La commande `helm install` peut installer un package depuis différentes sources: - Un dépôt de charts (comme vu précédemment) - Une archive locale d'un chart (`helm install foo foo-0.1.1.tgz`) - Un dossier contenant un chart décompressé (`helm install foo path/to/foo`) - Une URL pointant vers un chart (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' et 'helm rollback': Mettre à jour une Release, et récupération d'un Echec Lorsqu'une nouvelle release d'un chart est publiée, ou lorsque vous souhaitez modifier la configuration de votre release, vous pouvez utiliser la commande `helm upgrade`. Une mise à niveau prend une release existante et la met à niveau en fonction des informations que vous fournissez. Étant donné que les charts Kubernetes peuvent être volumineuses et complexes, Helm essaie d'effectuer la mise à niveau la moins invasive. Ainsi il essaiera de mettre à jour uniquement les éléments qui ont changé depuis la dernière version. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` Dans le cas ci-dessus la release `happy-panda` est mis à jour depuis la même chart mais avec un fichier de config YAML différent : ```yaml mariadb.auth.username: user1 ``` Vous pouvez utiliser `helm get values` pour voir si votre nouvelle configuration à pris effet ou non : ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` La commande `helm get` est un outil utile pour voir les informations d'une release dans le cluster. Et comme nous venons de le voir ci-dessus, la commande peut également être utilisée pour voir si les nouvelles valeurs de `panda.yaml` sont bien déployées sur le cluster. Maintenant admettons que quelque chose ne se passe pas comme prévu lors d'une release, il est facile de revenir à une version précédente en utilisant `helm rollback [RELEASE_NAME] [VERSION]`. ```console $ helm rollback happy-panda 1 ``` la commande précédente ramène notre happy-panda à sa toute première version. Une version de release est une révision incrémentielle. Chaque fois qu'une installation, qu'une mise à jour ou qu'une restauration est faite, le numéro de révision est incrémenté de 1. La première release est toujours la version numéro 1. Et vous pouvez utiliser `helm history [RELEASE]` pour voir les versions d'une release. ## Options utiles pour l'installation / la mise à jour / la restauration Il existe d'autres options utiles que vous pouvez spécifier pour personnaliser le comportement de Helm lors d'une installation / d'une mise à jour / d'une restauration. Veuillez noter que la liste qui suit n'est pas exhaustive. Pour voir une description de tous les flags, exécutez simplement `helm --help`. - `--timeout`: Une [durée Go](https://golang.org/pkg/time/#ParseDuration) maximale avant de terminer la commande Kubernetes. La valeur par défaut est `5m0s`. - `--wait`: Attend que tous les pods soient dans un état prêt, les PVCs sont liés, les déploiements ont un minimum (`Desired` moins ` maxUnavailable`) de pods prêts et les services ont une adresse IP (et une entrée si il y a un `LoadBalancer`) avant de marquer la release comme réussie. Il attendra au maximum la valeur de `--timeout`. Si le délai d'expiration est atteint, la release sera marquée comme «FAILED». Remarque: dans les scénarios où le déploiement a `réplicas` défini sur 1 et ` maxUnavailable` n'est pas défini à 0 dans le cadre de la stratégie de mise à jour progressive, `--wait` sera marqué comme prêt dès qu'il aura satisfait son nombre minimum de Pods en état prêt. - `--no-hooks`: Permet d'ignorer l'exécution des hooks pour la commande - `--recreate-pods` (seulement disponible pour les `upgrade` et les `rollback`): Ce flag permet de recréer tous les pods (à l'exception des pods de deploiements). (DEPRECIE depuis Helm 3) ## 'helm uninstall': Désinstallation d'une Release Quand sera venu le jour ou vous devrez désinstaller une release de votre cluster, utilisez la commande `helm uninstall` : ```console $ helm uninstall happy-panda ``` Cela supprimera la release du cluster. Vous pouvez voir toutes vos releases actuellement déployées avec la commande `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` À partir du résultat ci-dessus, nous pouvons voir que la version `happy-panda` a bien été désinstallé. Dans les versions précédentes de Helm, lorsqu'une release était supprimée, l'historique entier restait disponible. Depuis Helm 3, la désinstallation supprime également l'historique de la release. Si vous souhaitez tout de même conserver un enregistrement de l'historique, utilisez `helm uninstall --keep-history`. L'utilisation de `helm list --uninstalled` affichera uniquement les release qui ont été désinstallés avec l'indicateur `--keep-history`. L'indicateur `helm list --all` vous montrera tous les historique de release que Helm a conservés, y compris les historiques des éléments ayant échoué ou ayant été supprimé (si `--keep-history` était spécifié): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Notez que les historiques de release étant désormais supprimées par défaut, il n'est plus possible de restaurer une ressource désinstallée. ## 'helm repo': Travailler avec des Dépôts Helm 3 n'est plus livré avec un dépôt de charts par défaut. La commande `helm repo` vous permet entre autre d'ajouter, de répertorier et de supprimer des dépôts. Vous pouvez voir quels dépôts sont configurés en utilisant `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Vous pouvez bien entendu ajouter de nouveaux dépôts avec `helm repo add`: ```console $ helm repo add dev https://example.com/dev-charts ``` Étant donné que les dépôts de charts changent fréquemment, vous pouvez à tout moment vous assurer que votre client Helm est à jour en exécutant `helm repo update`. Les dépôts peuvent être supprimés avec `helm repo remove`. ## Création de vos propres charts Le [Guide de développement de charts](/topics/charts.md) explique comment développer vos propres charts. Mais vous pouvez vous lancer rapidement dans la création de charts avec la commande `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Il y a maintenant un chart dans `./deis-workflow`. Vous pouvez le modifier et créer vos propres templates. Lorsque vous modifiez votre chart, vous pouvez valider sa syntaxe en exécutant `helm lint`. Quand vous aurez besoin de packager le chart pour la distribution, vous pourrez exécuter `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` Le chart est maintenant prêt à l'installation `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Les charts packagés peuvent être uploadés dans des dépôts. Jetez un oeil à la [documentation des dépôts](/topics/chart_repository.md) de charts Helm pour plus de détails. ## Conclusion Ce chapitre a couvert les utilisations de base du client `helm`, y compris la recherche, l'installation, la mise à jour et la désinstallation. Nous avons également vu les commandes utilitaires telles que `helm status`,` helm get` ou encore `helm repo`. Pour plus d'informations sur ces commandes, consultez l'aide intégrée de Helm: `helm help`. Dans le [chapitre suivant](/howto/charts_tips_and_tricks.md), nous verrons le processus de développement des charts. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Introduction description: Présente le SDK Go de Helm sidebar_position: 1 --- Le SDK Go de Helm permet aux logiciels personnalisés d'exploiter les charts Helm et les fonctionnalités de Helm pour gérer le déploiement de logiciels sur Kubernetes. (En fait, la CLI Helm n'est qu'un exemple d'un tel outil !) Actuellement, le SDK a été séparé fonctionnellement de la CLI Helm. Le SDK peut être (et est) utilisé par des outils autonomes. Le projet Helm s'est engagé à assurer la stabilité de l'API du SDK. Attention : le SDK présente encore quelques imperfections héritées du travail initial de séparation entre la CLI et le SDK. Le projet Helm s'efforce de les améliorer progressivement. La documentation complète de l'API est disponible sur [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Un bref aperçu des principaux types de packages ainsi qu'un exemple simple sont présentés ci-dessous. Consultez la section [Exemples](/sdk/examples.mdx) pour plus d'exemples et un exemple plus complet. ## Aperçu des packages principaux - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action) : Contient le "client" principal pour exécuter les actions Helm. C'est le même package que la CLI utilise en interne. Si vous avez simplement besoin d'exécuter des commandes Helm de base depuis un autre programme Go, c'est le package qu'il vous faut. - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil) : Méthodes et utilitaires pour charger et manipuler les charts. - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) et ses sous-packages : Contient tous les handlers pour les variables d'environnement Helm standard. Ses sous-packages gèrent la sortie et le traitement des fichiers values. - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release) : Définit l'objet `Release` et ses statuts. Il existe de nombreux autres packages. Consultez la documentation pour plus d'informations ! ### Exemple simple Voici un exemple simple d'exécution d'un `helm list` avec le SDK Go. Consultez la section [Exemples](/sdk/examples.mdx) pour des exemples plus complets. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Compatibilité Le SDK Helm suit explicitement les garanties de rétrocompatibilité de Helm : Les ruptures de compatibilité ne sont introduites qu'entre versions majeures. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Techniques Helm avancées description: Explique diverses fonctionnalités avancées pour les utilisateurs expérimentés de Helm sidebar_position: 9 --- Cette section présente diverses fonctionnalités et techniques avancées pour utiliser Helm. Ces informations sont destinées aux « utilisateurs expérimentés » de Helm qui souhaitent effectuer des personnalisations et manipulations avancées de leurs charts et releases. Chacune de ces fonctionnalités avancées comporte ses propres compromis et mises en garde. Elles doivent donc être utilisées avec précaution et une connaissance approfondie de Helm. Autrement dit, gardez à l'esprit le [principe de Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Post Rendering Le post rendering permet de manipuler, configurer et/ou valider manuellement les manifestes rendus avant leur installation par Helm. Cette fonctionnalité permet aux utilisateurs ayant des besoins de configuration avancés d'utiliser des outils comme [`kustomize`](https://kustomize.io) pour appliquer des modifications de configuration sans avoir à forker un chart public ou exiger des mainteneurs qu'ils spécifient chaque option de configuration possible pour un logiciel. Il existe également des cas d'utilisation pour l'injection d'outils communs et de sidecars dans les environnements d'entreprise, ou l'analyse des manifestes avant le déploiement. ### Prérequis - Helm 3.1+ ### Utilisation Un post-renderer peut être n'importe quel exécutable qui accepte les manifestes Kubernetes rendus sur STDIN et retourne des manifestes Kubernetes valides sur STDOUT. Il doit retourner un code de sortie non nul en cas d'échec. C'est la seule « API » entre les deux composants. Cela offre une grande flexibilité dans ce que vous pouvez faire avec votre processus de post-render. Un post renderer peut être utilisé avec `install`, `upgrade` et `template`. Pour utiliser un post-renderer, utilisez le flag `--post-renderer` avec le chemin vers l'exécutable du renderer que vous souhaitez utiliser : ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Si le chemin ne contient aucun séparateur, il sera recherché dans $PATH, sinon les chemins relatifs seront résolus en chemins absolus. Si vous souhaitez utiliser plusieurs post-renderers, appelez-les tous dans un script ou ensemble dans l'outil binaire que vous avez construit. En bash, cela serait aussi simple que `renderer1 | renderer2 | renderer3`. Vous pouvez voir un exemple d'utilisation de `kustomize` comme post renderer [ici](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Mises en garde Lors de l'utilisation de post renderers, plusieurs points importants sont à garder à l'esprit. Le plus important : toutes les personnes modifiant une release **DOIVENT** utiliser le même renderer afin d'avoir des builds reproductibles. Cette fonctionnalité permet à tout utilisateur de changer de renderer ou d'arrêter d'en utiliser un, mais cela doit être fait délibérément pour éviter toute modification accidentelle ou perte de données. Point important sur la sécurité : si vous utilisez un post-renderer, assurez-vous qu'il provient d'une source fiable (comme pour tout autre exécutable arbitraire). L'utilisation de renderers non fiables ou non vérifiés N'EST PAS recommandée, car ils ont un accès complet aux templates rendus, qui contiennent souvent des données sensibles. ### Post Renderers personnalisés L'étape de post render offre encore plus de flexibilité lorsqu'elle est utilisée avec le SDK Go. Tout post renderer n'a qu'à implémenter l'interface Go suivante : ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Pour plus d'informations sur l'utilisation du SDK Go, consultez la [section SDK Go](#sdk-go) ## SDK Go Helm 3 a introduit un SDK Go entièrement restructuré pour une meilleure expérience lors de la création de logiciels et d'outils exploitant Helm. La documentation complète se trouve dans la [section SDK Go](/sdk/gosdk.md). ## Backends de stockage Helm 3 a changé le stockage par défaut des informations de release vers les Secrets dans le namespace de la release. Helm 2 stockait par défaut les informations de release sous forme de ConfigMaps dans le namespace de l'instance Tiller. Les sous-sections suivantes expliquent comment configurer différents backends. Cette configuration est basée sur la variable d'environnement `HELM_DRIVER`. Elle peut être définie sur l'une des valeurs suivantes : `[configmap, secret, sql]`. ### Backend de stockage ConfigMap Pour activer le backend ConfigMap, vous devez définir la variable d'environnement `HELM_DRIVER` sur `configmap`. Vous pouvez la définir dans un shell comme suit : ```shell export HELM_DRIVER=configmap ``` Si vous souhaitez passer du backend par défaut au backend ConfigMap, vous devrez effectuer la migration vous-même. Vous pouvez récupérer les informations de release avec la commande suivante : ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **NOTES DE PRODUCTION** : Les informations de release incluent le contenu des charts et des fichiers values, et peuvent donc contenir des données sensibles (comme des mots de passe, des clés privées et d'autres identifiants) qui doivent être protégées contre les accès non autorisés. Lors de la gestion des autorisations Kubernetes, par exemple avec [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), il est possible d'accorder un accès plus large aux ressources ConfigMap, tout en restreignant l'accès aux ressources Secret. Par exemple, le [rôle orienté utilisateur](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) par défaut « view » accorde l'accès à la plupart des ressources, mais pas aux Secrets. De plus, les données des secrets peuvent être configurées pour un [stockage chiffré](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Gardez cela à l'esprit si vous décidez de passer au backend ConfigMap, car cela pourrait exposer les données sensibles de votre application. ### Backend de stockage SQL Il existe un backend de stockage SQL en ***beta*** qui stocke les informations de release dans une base de données SQL. L'utilisation d'un tel backend de stockage est particulièrement utile si vos informations de release pèsent plus de 1 Mo (auquel cas, elles ne peuvent pas être stockées dans ConfigMaps/Secrets en raison des limites internes du magasin clé-valeur etcd sous-jacent de Kubernetes). Pour activer le backend SQL, vous devez déployer une base de données SQL et définir la variable d'environnement `HELM_DRIVER` sur `sql`. Les détails de la base de données sont définis avec la variable d'environnement `HELM_DRIVER_SQL_CONNECTION_STRING`. Vous pouvez les définir dans un shell comme suit : ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Note : Seul PostgreSQL est pris en charge pour le moment. **NOTES DE PRODUCTION** : Il est recommandé de : - Rendre votre base de données prête pour la production. Pour PostgreSQL, consultez la documentation [Server Administration](https://www.postgresql.org/docs/12/admin.html) pour plus de détails - Activer la [gestion des permissions](/topics/permissions_sql_storage_backend.md) pour refléter le RBAC Kubernetes pour les informations de release Si vous souhaitez passer du backend par défaut au backend SQL, vous devrez effectuer la migration vous-même. Vous pouvez récupérer les informations de release avec la commande suivante : ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Architecture de Helm description: Décrit l'architecture de Helm à un niveau général. sidebar_position: 8 --- # Architecture de Helm Ce document décrit l'architecture de Helm à un niveau général. ## L'objectif de Helm Helm est un outil de gestion des paquets Kubernetes appelés _charts_. Helm peut effectuer les opérations suivantes : - Créer de nouveaux charts à partir de zéro - Empaqueter des charts dans des fichiers d'archive (tgz) - Interagir avec des dépôts de charts où les charts sont stockés - Installer et désinstaller des charts dans un cluster Kubernetes existant - Gérer le cycle de release des charts installés avec Helm Pour Helm, il existe trois concepts importants : 1. Le _chart_ est un ensemble d'informations nécessaires à la création d'une instance d'une application Kubernetes. 2. La _config_ contient les informations de configuration qui peuvent être fusionnées avec un chart empaqueté pour créer un objet déployable. 3. Une _release_ est une instance en cours d'exécution d'un _chart_, combinée avec une _config_ spécifique. ## Composants Helm est un exécutable implémenté en deux parties distinctes : **Le client Helm** est un client en ligne de commande destiné aux utilisateurs finaux. Le client est responsable des opérations suivantes : - Développement local de charts - Gestion des dépôts - Gestion des releases - Interface avec la bibliothèque Helm - Envoi de charts à installer - Demande de mise à niveau ou de désinstallation de releases existantes **La bibliothèque Helm** fournit la logique pour exécuter toutes les opérations Helm. Elle communique avec le serveur d'API Kubernetes et permet de : - Combiner un chart et une configuration pour créer une release - Installer des charts dans Kubernetes et fournir l'objet release résultant - Mettre à niveau et désinstaller des charts en interagissant avec Kubernetes La bibliothèque Helm autonome encapsule la logique Helm afin qu'elle puisse être utilisée par différents clients. ## Implémentation Le client et la bibliothèque Helm sont écrits dans le langage de programmation Go. La bibliothèque utilise la bibliothèque client Kubernetes pour communiquer avec Kubernetes. Actuellement, cette bibliothèque utilise REST+JSON. Elle stocke les informations dans des Secrets situés dans Kubernetes. Elle ne nécessite pas sa propre base de données. Les fichiers de configuration sont, dans la mesure du possible, écrits en YAML. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Guide des dépôts de charts description: Comment créer et travailler avec les dépôts de charts Helm. sidebar_position: 6 --- Cette section explique comment créer et travailler avec les dépôts de charts Helm. Un dépôt de charts est un emplacement où les charts empaquetés peuvent être stockés et partagés. Le dépôt communautaire distribué de charts Helm se trouve sur [Artifact Hub](https://artifacthub.io/packages/search?kind=0) et accueille les contributions. Cependant, Helm permet également de créer et d'héberger votre propre dépôt de charts. Ce guide explique comment procéder. Si vous envisagez de créer un dépôt de charts, vous pourriez considérer l'utilisation d'un [registre OCI](./registries.md) à la place. ## Prérequis * Parcourir le guide de [Démarrage rapide](../intro/quickstart.md) * Lire le document sur les [Charts](./charts.md) ## Créer un dépôt de charts Un _dépôt de charts_ est un serveur HTTP qui héberge un fichier `index.yaml` ainsi que des charts empaquetés. Lorsque vous êtes prêt à partager vos charts, la méthode recommandée est de les téléverser vers un dépôt de charts. Depuis Helm 2.2.0, l'authentification SSL côté client est supportée pour les dépôts. D'autres protocoles d'authentification peuvent être disponibles via des plugins. Puisqu'un dépôt de charts peut être n'importe quel serveur HTTP capable de servir des fichiers YAML et tar et de répondre aux requêtes GET, vous avez de nombreuses options pour héberger votre propre dépôt de charts. Par exemple, vous pouvez utiliser un bucket Google Cloud Storage (GCS), un bucket Amazon S3, GitHub Pages, ou même créer votre propre serveur web. ### Structure du dépôt de charts Un dépôt de charts se compose de charts empaquetés et d'un fichier spécial appelé `index.yaml` qui contient un index de tous les charts du dépôt. Souvent, les charts décrits par `index.yaml` sont également hébergés sur le même serveur, tout comme les [fichiers de provenance](./provenance.md). Par exemple, la structure du dépôt `https://example.com/charts` pourrait ressembler à ceci : ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` Dans ce cas, le fichier index contiendrait des informations sur un seul chart, le chart Alpine, et fournirait l'URL de téléchargement `https://example.com/charts/alpine-0.1.2.tgz` pour ce chart. Il n'est pas obligatoire que le package du chart soit situé sur le même serveur que le fichier `index.yaml`. Cependant, c'est souvent la solution la plus simple. ### Le fichier index Le fichier index est un fichier yaml appelé `index.yaml`. Il contient des métadonnées sur le package, y compris le contenu du fichier `Chart.yaml` du chart. Un dépôt de charts valide doit avoir un fichier index. Le fichier index contient des informations sur chaque chart dans le dépôt. La commande `helm repo index` génère un fichier index à partir d'un répertoire local donné contenant des charts empaquetés. Voici un exemple de fichier index : ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Héberger des dépôts de charts Cette partie présente plusieurs façons de servir un dépôt de charts. ### Google Cloud Storage La première étape est de **créer votre bucket GCS**. Nous appellerons le nôtre `fantastic-charts`. ![Créer un bucket GCS](/img/helm2/create-a-bucket.png) Ensuite, rendez votre bucket public en **modifiant les permissions du bucket**. ![Modifier les permissions](/img/helm2/edit-permissions.png) Ajoutez cette ligne pour **rendre votre bucket public** : ![Rendre le bucket public](/img/helm2/make-bucket-public.png) Félicitations, vous avez maintenant un bucket GCS vide prêt à servir des charts ! Vous pouvez téléverser votre dépôt de charts en utilisant l'outil en ligne de commande Google Cloud Storage ou via l'interface web GCS. Un bucket GCS public est accessible via HTTPS simple à cette adresse : `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith Vous pouvez également configurer des dépôts de charts en utilisant Cloudsmith. Pour en savoir plus sur les dépôts de charts avec Cloudsmith, consultez [cette documentation](https://help.cloudsmith.io/docs/helm-chart-repository). ### JFrog Artifactory De même, vous pouvez configurer des dépôts de charts en utilisant JFrog Artifactory. Pour en savoir plus sur les dépôts de charts avec JFrog Artifactory, consultez [cette documentation](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). ### Exemple avec GitHub Pages De manière similaire, vous pouvez créer un dépôt de charts en utilisant GitHub Pages. GitHub vous permet de servir des pages web statiques de deux manières différentes : - En configurant un projet pour servir le contenu de son répertoire `docs/` - En configurant un projet pour servir une branche particulière Nous allons utiliser la seconde approche, bien que la première soit tout aussi simple. La première étape sera de **créer votre branche gh-pages**. Vous pouvez le faire localement ainsi : ```console $ git checkout -b gh-pages ``` Ou via le navigateur web en utilisant le bouton **Branch** dans votre dépôt GitHub : ![Créer une branche GitHub Pages](/img/helm2/create-a-gh-page-button.png) Ensuite, assurez-vous que votre **branche gh-pages** est définie comme source pour GitHub Pages. Cliquez sur **Settings** de votre dépôt et descendez jusqu'à la section **GitHub pages** puis configurez comme suit : ![Configurer GitHub Pages](/img/helm2/set-a-gh-page.png) Par défaut, **Source** est généralement défini sur **gh-pages branch**. Si ce n'est pas le cas par défaut, sélectionnez-le. Vous pouvez utiliser un **domaine personnalisé** si vous le souhaitez. Et vérifiez que **Enforce HTTPS** est coché, afin que **HTTPS** soit utilisé lors du service des charts. Avec cette configuration, vous pouvez utiliser votre branche par défaut pour stocker le code de vos charts et la **branche gh-pages** comme dépôt de charts, par exemple : `https://USERNAME.github.io/REPONAME`. Le dépôt de démonstration [TS Charts](https://github.com/technosophos/tscharts) est accessible à `https://technosophos.github.io/tscharts/`. Si vous avez décidé d'utiliser GitHub Pages pour héberger le dépôt de charts, consultez [Chart Releaser Action](../howto/chart_releaser_action.md). Chart Releaser Action est un workflow GitHub Action pour transformer un projet GitHub en dépôt de charts Helm auto-hébergé, en utilisant l'outil CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Serveurs web ordinaires Pour configurer un serveur web ordinaire pour servir des charts Helm, vous devez simplement faire ce qui suit : - Placer votre fichier index et vos charts dans un répertoire que le serveur peut servir - S'assurer que le fichier `index.yaml` est accessible sans exigence d'authentification - S'assurer que les fichiers `yaml` sont servis avec le bon type de contenu (`text/yaml` ou `text/x-yaml`) Par exemple, si vous voulez servir vos charts depuis `$WEBROOT/charts`, assurez-vous qu'il y a un répertoire `charts/` dans votre racine web, et placez le fichier index et les charts dans ce dossier. ### Serveur de dépôt ChartMuseum ChartMuseum est un serveur de dépôt de charts Helm open-source écrit en Go (Golang), avec support pour les backends de stockage cloud, notamment [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), et [etcd](https://etcd.io/). Vous pouvez également utiliser le serveur [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) pour héberger un dépôt de charts depuis un système de fichiers local. ### GitLab Package Registry Avec GitLab, vous pouvez publier des charts Helm dans le Package Registry de votre projet. Pour en savoir plus sur la configuration d'un dépôt de packages Helm avec GitLab, consultez [cette documentation](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Gérer les dépôts de charts Maintenant que vous avez un dépôt de charts, la dernière partie de ce guide explique comment maintenir les charts dans ce dépôt. ### Stocker des charts dans votre dépôt de charts Maintenant que vous avez un dépôt de charts, téléversons un chart et un fichier index vers le dépôt. Les charts dans un dépôt de charts doivent être empaquetés (`helm package chart-name/`) et versionnés correctement (en suivant les directives [SemVer 2](https://semver.org/)). Les étapes suivantes composent un exemple de workflow, mais vous êtes libre d'utiliser le workflow de votre choix pour stocker et mettre à jour les charts dans votre dépôt. Une fois que vous avez un chart empaqueté prêt, créez un nouveau répertoire et déplacez-y votre chart empaqueté. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` La dernière commande prend le chemin du répertoire local que vous venez de créer et l'URL de votre dépôt de charts distant pour composer un fichier `index.yaml` dans le répertoire donné. Vous pouvez maintenant téléverser le chart et le fichier index vers votre dépôt de charts en utilisant un outil de synchronisation ou manuellement. Si vous utilisez Google Cloud Storage, consultez cet [exemple de workflow](../howto/chart_repository_sync_example.md) utilisant le client gsutil. Pour GitHub, vous pouvez simplement placer les charts dans la branche de destination appropriée. ### Ajouter de nouveaux charts à un dépôt existant Chaque fois que vous souhaitez ajouter un nouveau chart à votre dépôt, vous devez régénérer l'index. La commande `helm repo index` reconstruira complètement le fichier `index.yaml` à partir de zéro, en incluant uniquement les charts qu'elle trouve localement. Cependant, vous pouvez utiliser le flag `--merge` pour ajouter de nouveaux charts de manière incrémentale à un fichier `index.yaml` existant (une excellente option lorsque vous travaillez avec un dépôt distant comme GCS). Exécutez `helm repo index --help` pour en savoir plus. Assurez-vous de téléverser à la fois le fichier `index.yaml` révisé et le chart. Et si vous avez généré un fichier de provenance, téléversez-le également. ### Partager vos charts avec d'autres Lorsque vous êtes prêt à partager vos charts, communiquez simplement l'URL de votre dépôt. À partir de là, ils pourront ajouter le dépôt à leur client Helm via la commande `helm repo add [NOM] [URL]` avec le nom de leur choix pour référencer le dépôt. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Si les charts sont protégés par une authentification HTTP basique, vous pouvez également fournir le nom d'utilisateur et le mot de passe ici : ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Note :** Un dépôt ne sera pas ajouté s'il ne contient pas un fichier `index.yaml` valide. **Note :** Si votre dépôt Helm utilise par exemple un certificat auto-signé, vous pouvez utiliser `helm repo add --insecure-skip-tls-verify ...` pour ignorer la vérification du CA. Après cela, vos utilisateurs pourront rechercher dans vos charts. Après avoir mis à jour le dépôt, ils peuvent utiliser la commande `helm repo update` pour obtenir les dernières informations sur les charts. *En coulisses, les commandes `helm repo add` et `helm repo update` récupèrent le fichier index.yaml et le stockent dans le répertoire `$XDG_CACHE_HOME/helm/repository/cache/`. C'est là que la fonction `helm search` trouve les informations sur les charts.* ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Tests de chart description: Décrit comment exécuter et tester vos charts. sidebar_position: 3 --- Un chart contient de nombreuses ressources et composants Kubernetes qui fonctionnent ensemble. En tant qu'auteur de chart, vous souhaiterez peut-être écrire des tests pour valider que votre chart fonctionne comme prévu lors de son installation. Ces tests aident également les utilisateurs du chart à comprendre ce que celui-ci est censé faire. Un **test** dans un chart Helm se trouve dans le répertoire `templates/` et consiste en une définition de Job spécifiant un conteneur avec une commande donnée à exécuter. Le conteneur doit se terminer avec succès (exit 0) pour que le test soit considéré comme réussi. La définition du Job doit contenir l'annotation de hook de test Helm : `helm.sh/hook: test`. Notez que jusqu'à Helm v3, la définition du Job devait contenir l'une de ces annotations de hook de test Helm : `helm.sh/hook: test-success` ou `helm.sh/hook: test-failure`. L'annotation `helm.sh/hook: test-success` est toujours acceptée comme alternative rétrocompatible à `helm.sh/hook: test`. Exemples de tests : - Valider que votre configuration provenant du fichier values.yaml a été correctement injectée. - Vérifier que votre nom d'utilisateur et votre mot de passe fonctionnent correctement - Vérifier qu'un nom d'utilisateur et un mot de passe incorrects ne fonctionnent pas - Vérifier que vos services sont opérationnels et répartissent correctement la charge - etc. Vous pouvez exécuter les tests prédéfinis dans Helm sur une release à l'aide de la commande `helm test `. C'est un excellent moyen pour les utilisateurs de vérifier que leur release d'un chart (ou application) fonctionne comme prévu. ## Exemple de test La commande [helm create](/helm/helm_create.md) crée automatiquement un certain nombre de dossiers et fichiers. Pour essayer la fonctionnalité de test Helm, créez d'abord un chart de démonstration. ```console $ helm create demo ``` Vous verrez maintenant la structure suivante dans votre chart de démonstration. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` Dans `demo/templates/tests/test-connection.yaml`, vous trouverez un test que vous pouvez essayer. Voici la définition du pod de test Helm : ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Étapes pour exécuter une suite de tests sur une release Tout d'abord, installez le chart sur votre cluster pour créer une release. Vous devrez peut-être attendre que tous les pods deviennent actifs ; si vous lancez le test immédiatement après l'installation, un échec transitoire est probable, et vous voudrez relancer le test. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Notes - Vous pouvez définir autant de tests que vous le souhaitez dans un seul fichier yaml ou les répartir dans plusieurs fichiers yaml dans le répertoire `templates/`. - Vous pouvez placer votre suite de tests dans un sous-répertoire `tests/` comme `/templates/tests/` pour plus d'isolation. - Un test est un [hook Helm](/topics/charts_hooks.md), donc les annotations telles que `helm.sh/hook-weight` et `helm.sh/hook-delete-policy` peuvent être utilisées avec les ressources de test. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Charts description: Explique le format des charts et fournit des conseils de base pour créer des charts avec Helm. sidebar_position: 1 --- Helm utilise un format de packaging appelé _charts_. Un chart est une collection de fichiers décrivant un ensemble cohérent de ressources Kubernetes. Un seul chart peut être utilisé pour déployer quelque chose de simple, comme un pod memcached, ou quelque chose de complexe, comme une pile applicative web complète avec serveurs HTTP, bases de données, caches, etc. Les charts sont créés sous forme de fichiers organisés dans une arborescence de répertoires particulière. Ils peuvent être empaquetés dans des archives versionnées pour être déployés. Si vous souhaitez télécharger et examiner les fichiers d'un chart publié sans l'installer, vous pouvez le faire avec `helm pull chartrepo/chartname`. Ce document explique le format des charts et fournit des conseils de base pour créer des charts avec Helm. ## Structure des fichiers d'un chart Un chart est organisé comme une collection de fichiers dans un répertoire. Le nom du répertoire est le nom du chart (sans information de version). Ainsi, un chart décrivant WordPress serait stocké dans un répertoire `wordpress/`. À l'intérieur de ce répertoire, Helm s'attend à une structure correspondant à ceci : ```text wordpress/ Chart.yaml # Un fichier YAML contenant des informations sur le chart LICENSE # OPTIONNEL : Un fichier texte contenant la licence du chart README.md # OPTIONNEL : Un fichier README lisible par les humains values.yaml # Les valeurs de configuration par défaut pour ce chart values.schema.json # OPTIONNEL : Un JSON Schema pour imposer une structure au fichier values.yaml charts/ # Un répertoire contenant les charts dont ce chart dépend crds/ # Custom Resource Definitions templates/ # Un répertoire de templates qui, combinés aux values, # génèreront des fichiers manifestes Kubernetes valides templates/NOTES.txt # OPTIONNEL : Un fichier texte contenant des notes d'utilisation courtes ``` Helm réserve l'utilisation des répertoires `charts/`, `crds/` et `templates/`, ainsi que des noms de fichiers listés ci-dessus. Les autres fichiers sont laissés tels quels. ## Le fichier Chart.yaml Le fichier `Chart.yaml` est obligatoire pour un chart. Il contient les champs suivants : ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` À partir de [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), les champs supplémentaires ne sont plus autorisés. L'approche recommandée est d'ajouter des métadonnées personnalisées dans `annotations`. ### Charts et versioning Chaque chart doit avoir un numéro de version. Une version doit suivre le standard [SemVer 2](https://semver.org/spec/v2.0.0.html), mais ce n'est pas strictement imposé. Contrairement à Helm Classic, Helm v2 et les versions ultérieures utilisent les numéros de version comme marqueurs de release. Les paquets dans les dépôts sont identifiés par leur nom plus leur version. Par exemple, un chart `nginx` dont le champ version est défini à `version: 1.2.3` sera nommé : ```text nginx-1.2.3.tgz ``` Des noms SemVer 2 plus complexes sont également supportés, comme `version: 1.2.3-alpha.1+ef365`. Cependant, les noms non-SemVer sont explicitement interdits par le système. Sont toutefois acceptés les formats de version `x` ou `x.y`. Par exemple, s'il y a un `v` initial ou une version listée sans les 3 parties (par ex. `v1.2`), Helm tentera de la convertir en une version sémantique valide (par ex. `v1.2.0`). **NOTE :** Alors que Helm Classic et Deployment Manager étaient très orientés GitHub en ce qui concerne les charts, Helm v2 et les versions ultérieures ne dépendent pas de GitHub ni ne requièrent Git. Par conséquent, les SHA Git ne sont pas du tout utilisés pour le versioning. Le champ `version` dans le fichier `Chart.yaml` est utilisé par de nombreux outils Helm, y compris la CLI. Lors de la génération d'un paquet, la commande `helm package` utilisera la version trouvée dans le `Chart.yaml` comme jeton dans le nom du paquet. Le système suppose que le numéro de version dans le nom du paquet de chart correspond au numéro de version dans le `Chart.yaml`. Le non-respect de cette hypothèse provoquera une erreur. ### Le champ `apiVersion` Le champ `apiVersion` doit être `v2` pour les charts Helm nécessitant au moins Helm 3. Les charts supportant les versions précédentes de Helm ont un `apiVersion` défini à `v1` et restent installables par Helm 3. Changements de `v1` à `v2` : - Un champ `dependencies` définissant les dépendances du chart, qui étaient situées dans un fichier séparé `requirements.yaml` pour les charts `v1` (voir [Dépendances des charts](#dependances-des-charts)). - Le champ `type`, distinguant les charts d'application et les charts de type library (voir [Types de charts](#types-de-charts)). ### Le champ `appVersion` Notez que le champ `appVersion` n'est pas lié au champ `version`. C'est un moyen de spécifier la version de l'application. Par exemple, le chart `drupal` peut avoir un `appVersion: "8.2.1"`, indiquant que la version de Drupal incluse dans le chart (par défaut) est `8.2.1`. Ce champ est informatif et n'a aucun impact sur les calculs de version du chart. Il est fortement recommandé d'entourer la version de guillemets. Cela force l'analyseur YAML à traiter le numéro de version comme une chaîne. Ne pas utiliser de guillemets peut entraîner des problèmes d'analyse dans certains cas. Par exemple, YAML interprète `1.0` comme une valeur à virgule flottante, et un SHA de commit git comme `1234e10` comme une notation scientifique. À partir de Helm v3.5.0, `helm create` entoure le champ `appVersion` par défaut de guillemets. ### Le champ `kubeVersion` Le champ optionnel `kubeVersion` peut définir des contraintes semver sur les versions de Kubernetes supportées. Helm validera les contraintes de version lors de l'installation du chart et échouera si le cluster exécute une version de Kubernetes non supportée. Les contraintes de version peuvent comprendre des comparaisons AND séparées par des espaces comme : ``` >= 1.13.0 < 1.15.0 ``` qui peuvent elles-mêmes être combinées avec l'opérateur OR `||` comme dans l'exemple suivant : ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` Dans cet exemple, la version `1.14.0` est exclue, ce qui peut être utile si un bug dans certaines versions est connu pour empêcher le chart de fonctionner correctement. En plus des contraintes de version utilisant les opérateurs `=` `!=` `>` `<` `>=` `<=`, les notations raccourcies suivantes sont supportées : * plages avec tiret pour les intervalles fermés, où `1.1 - 2.3.4` est équivalent à `>= 1.1 <= 2.3.4`. * jokers `x`, `X` et `*`, où `1.2.x` est équivalent à `>= 1.2.0 < 1.3.0`. * plages tilde (changements de version patch autorisés), où `~1.2.3` est équivalent à `>= 1.2.3 < 1.3.0`. * plages caret (changements de version mineure autorisés), où `^1.2.3` est équivalent à `>= 1.2.3 < 2.0.0`. Pour une explication détaillée des contraintes semver supportées, consultez [Masterminds/semver](https://github.com/Masterminds/semver). ### Déprécier des charts Lors de la gestion de charts dans un dépôt de charts, il est parfois nécessaire de déprécier un chart. Le champ optionnel `deprecated` dans `Chart.yaml` peut être utilisé pour marquer un chart comme déprécié. Si la **dernière** version d'un chart dans le dépôt est marquée comme dépréciée, alors le chart dans son ensemble est considéré comme déprécié. Le nom du chart peut être réutilisé ultérieurement en publiant une nouvelle version qui n'est pas marquée comme dépréciée. Le workflow pour déprécier des charts est : 1. Mettre à jour le `Chart.yaml` du chart pour le marquer comme déprécié, en incrémentant la version 2. Publier la nouvelle version du chart dans le dépôt de charts 3. Supprimer le chart du dépôt source (par ex. git) ### Types de charts Le champ `type` définit le type de chart. Il existe deux types : `application` et `library`. Application est le type par défaut et c'est le chart standard sur lequel on peut effectuer toutes les opérations. Le [chart de type library](/topics/library_charts.md) fournit des utilitaires ou des fonctions pour le créateur du chart. Un chart de type library diffère d'un chart d'application car il n'est pas installable et ne contient généralement pas d'objets ressources. **Note :** Un chart d'application peut être utilisé comme chart de type library. Cela s'active en définissant le type à `library`. Le chart sera alors rendu comme un chart de type library où tous les utilitaires et fonctions peuvent être exploités. Tous les objets ressources du chart ne seront pas rendus. ## LICENSE, README et NOTES d'un chart Les charts peuvent également contenir des fichiers décrivant l'installation, la configuration, l'utilisation et la licence d'un chart. Une LICENSE est un fichier texte brut contenant la [licence](https://fr.wikipedia.org/wiki/Licence_de_logiciel) du chart. Le chart peut contenir une licence car il peut avoir une logique de programmation dans les templates et ne serait donc pas uniquement de la configuration. Il peut également y avoir des licences séparées pour l'application installée par le chart, si nécessaire. Un README pour un chart doit être formaté en Markdown (README.md), et devrait généralement contenir : - Une description de l'application ou du service fourni par le chart - Tout prérequis ou exigence pour exécuter le chart - Des descriptions des options dans `values.yaml` et des valeurs par défaut - Toute autre information pertinente pour l'installation ou la configuration du chart Lorsque les hubs et autres interfaces utilisateur affichent les détails d'un chart, ces informations sont extraites du contenu du fichier `README.md`. Le chart peut également contenir un court fichier texte `templates/NOTES.txt` qui sera affiché après l'installation et lors de l'affichage du statut d'une release. Ce fichier est évalué comme un [template](#templates-et-values), et peut être utilisé pour afficher des notes d'utilisation, les prochaines étapes, ou toute autre information pertinente pour une release du chart. Par exemple, des instructions pourraient être fournies pour se connecter à une base de données ou accéder à une interface web. Comme ce fichier est affiché sur STDOUT lors de l'exécution de `helm install` ou `helm status`, il est recommandé de garder le contenu bref et de pointer vers le README pour plus de détails. ## Dépendances des charts Dans Helm, un chart peut dépendre de n'importe quel nombre d'autres charts. Ces dépendances peuvent être liées dynamiquement en utilisant le champ `dependencies` dans `Chart.yaml` ou importées dans le répertoire `charts/` et gérées manuellement. ### Gérer les dépendances avec le champ `dependencies` Les charts requis par le chart actuel sont définis comme une liste dans le champ `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Le champ `name` est le nom du chart souhaité. - Le champ `version` est la version du chart souhaitée. - Le champ `repository` est l'URL complète du dépôt de charts. Notez que vous devez également utiliser `helm repo add` pour ajouter ce dépôt localement. - Vous pouvez utiliser le nom du dépôt au lieu de l'URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Une fois les dépendances définies, vous pouvez exécuter `helm dependency update` qui utilisera votre fichier de dépendances pour télécharger tous les charts spécifiés dans votre répertoire `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Lorsque `helm dependency update` récupère les charts, il les stocke sous forme d'archives de charts dans le répertoire `charts/`. Ainsi, pour l'exemple ci-dessus, on s'attendrait à voir les fichiers suivants dans le répertoire charts : ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Champ alias dans les dépendances En plus des autres champs ci-dessus, chaque entrée de dépendance peut contenir le champ optionnel `alias`. Ajouter un alias pour un chart de dépendance place ce chart dans les dépendances en utilisant l'alias comme nom de la nouvelle dépendance. On peut utiliser `alias` lorsqu'on a besoin d'accéder à un chart avec un ou plusieurs autres noms. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` Dans l'exemple ci-dessus, nous obtiendrons 3 dépendances au total pour `parentchart` : ```text subchart new-subchart-1 new-subchart-2 ``` La méthode manuelle pour accomplir cela serait de copier/coller le même chart dans le répertoire `charts/` plusieurs fois avec des noms différents. #### Champs tags et condition dans les dépendances En plus des autres champs ci-dessus, chaque entrée de dépendance peut contenir les champs optionnels `tags` et `condition`. Tous les charts sont chargés par défaut. Si les champs `tags` ou `condition` sont présents, ils seront évalués et utilisés pour contrôler le chargement des charts auxquels ils s'appliquent. Condition - Le champ condition contient un ou plusieurs chemins YAML (délimités par des virgules). Si ce chemin existe dans les values du parent de niveau supérieur et se résout en une valeur booléenne, le chart sera activé ou désactivé en fonction de cette valeur booléenne. Seul le premier chemin valide trouvé dans la liste est évalué et si aucun chemin n'existe, la condition n'a aucun effet. Tags - Le champ tags est une liste YAML de labels à associer à ce chart. Dans les values du parent de niveau supérieur, tous les charts avec des tags peuvent être activés ou désactivés en spécifiant le tag et une valeur booléenne. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` Dans l'exemple ci-dessus, tous les charts avec le tag `front-end` seraient désactivés, mais comme le chemin `subchart1.enabled` s'évalue à 'true' dans les values du parent, la condition prendra le dessus sur le tag `front-end` et `subchart1` sera activé. Puisque `subchart2` a le tag `back-end` et que ce tag s'évalue à `true`, `subchart2` sera activé. Notez également que bien que `subchart2` ait une condition spécifiée, il n'y a pas de chemin et de valeur correspondants dans les values du parent, donc cette condition n'a aucun effet. ##### Utiliser la CLI avec les tags et conditions Le paramètre `--set` peut être utilisé comme d'habitude pour modifier les valeurs des tags et conditions. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Résolution des tags et conditions - **Les conditions (quand elles sont définies dans les values) prennent toujours le dessus sur les tags.** Le premier chemin de condition qui existe l'emporte et les suivants pour ce chart sont ignorés. - Les tags sont évalués comme "si l'un des tags du chart est vrai, alors activer le chart". - Les valeurs des tags et conditions doivent être définies dans les values du parent de niveau supérieur. - La clé `tags:` dans les values doit être une clé de niveau supérieur. Les globaux et les tables `tags:` imbriquées ne sont actuellement pas supportés. #### Importer les values des charts enfants via les dépendances Dans certains cas, il est souhaitable de permettre aux values d'un chart enfant de se propager au chart parent et d'être partagées comme valeurs par défaut communes. Un avantage supplémentaire de l'utilisation du format `exports` est qu'il permettra aux outils futurs d'introspecter les valeurs configurables par l'utilisateur. Les clés contenant les values à importer peuvent être spécifiées dans les `dependencies` du chart parent dans le champ `import-values` en utilisant une liste YAML. Chaque élément de la liste est une clé qui est importée depuis le champ `exports` du chart enfant. Pour importer des values non contenues dans la clé `exports`, utilisez le format [child-parent](#utiliser-le-format-child-parent). Des exemples des deux formats sont décrits ci-dessous. ##### Utiliser le format exports Si le fichier `values.yaml` d'un chart enfant contient un champ `exports` à la racine, son contenu peut être importé directement dans les values du parent en spécifiant les clés à importer comme dans l'exemple ci-dessous : ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Puisque nous spécifions la clé `data` dans notre liste d'import, Helm cherche dans le champ `exports` du chart enfant la clé `data` et importe son contenu. Les values finales du parent contiendront notre champ exporté : ```yaml # parent's values myint: 99 ``` Veuillez noter que la clé parente `data` n'est pas contenue dans les values finales du parent. Si vous avez besoin de spécifier la clé parente, utilisez le format 'child-parent'. ##### Utiliser le format child-parent Pour accéder aux values qui ne sont pas contenues dans la clé `exports` des values du chart enfant, vous devrez spécifier la clé source des values à importer (`child`) et le chemin de destination dans les values du chart parent (`parent`). Le `import-values` dans l'exemple ci-dessous indique à Helm de prendre toutes les values trouvées au chemin `child:` et de les copier vers les values du parent au chemin spécifié dans `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` Dans l'exemple ci-dessus, les values trouvées à `default.data` dans les values de subchart1 seront importées à la clé `myimports` dans les values du chart parent comme détaillé ci-dessous : ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` Les values résultantes du chart parent seraient : ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Les values finales du parent contiennent maintenant les champs `myint` et `mybool` importés de subchart1. ### Gérer les dépendances manuellement via le répertoire `charts/` Si plus de contrôle sur les dépendances est souhaité, ces dépendances peuvent être exprimées explicitement en copiant les charts de dépendance dans le répertoire `charts/`. Une dépendance doit être un répertoire de chart non compressé mais son nom ne peut pas commencer par `_` ou `.`. De tels fichiers sont ignorés par le chargeur de chart. Par exemple, si le chart WordPress dépend du chart Apache, le chart Apache (de la bonne version) est fourni dans le répertoire `charts/` du chart WordPress : ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` L'exemple ci-dessus montre comment le chart WordPress exprime sa dépendance envers Apache et MySQL en incluant ces charts dans son répertoire `charts/`. **CONSEIL :** _Pour placer une dépendance dans votre répertoire `charts/`, utilisez la commande `helm pull`_ ### Aspects opérationnels de l'utilisation des dépendances Les sections ci-dessus expliquent comment spécifier les dépendances de charts, mais comment cela affecte-t-il l'installation de charts avec `helm install` et `helm upgrade` ? Supposons qu'un chart nommé "A" crée les objets Kubernetes suivants : - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" De plus, A dépend du chart B qui crée les objets : - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Après l'installation/mise à niveau du chart A, une seule release Helm est créée/modifiée. La release créera/mettra à jour tous les objets Kubernetes ci-dessus dans l'ordre suivant : - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet C'est parce que lorsque Helm installe/met à niveau des charts, les objets Kubernetes provenant des charts et de toutes leurs dépendances sont : - agrégés en un seul ensemble ; puis - triés par type suivi du nom ; et ensuite - créés/mis à jour dans cet ordre. Par conséquent, une seule release est créée avec tous les objets du chart et de ses dépendances. L'ordre d'installation des types Kubernetes est donné par l'énumération InstallOrder dans kind_sorter.go (voir [le fichier source Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates et Values Les templates de charts Helm sont écrits dans le [langage de template Go](https://golang.org/pkg/text/template/), avec l'ajout d'une cinquantaine de fonctions de template supplémentaires [de la bibliothèque Sprig](https://github.com/Masterminds/sprig) et quelques autres [fonctions spécialisées](/howto/charts_tips_and_tricks.md). Tous les fichiers de template sont stockés dans le dossier `templates/` d'un chart. Lorsque Helm effectue le rendu des charts, il passe chaque fichier de ce répertoire à travers le moteur de template. Les values pour les templates sont fournies de deux manières : - Les développeurs de charts peuvent fournir un fichier appelé `values.yaml` dans un chart. Ce fichier peut contenir des valeurs par défaut. - Les utilisateurs de charts peuvent fournir un fichier YAML contenant des values. Celui-ci peut être fourni en ligne de commande avec `helm install`. Lorsqu'un utilisateur fournit des values personnalisées, ces values remplaceront les values du fichier `values.yaml` du chart. ### Fichiers de template Les fichiers de template suivent les conventions standard pour écrire des templates Go (voir la [documentation du package Go text/template](https://golang.org/pkg/text/template/) pour les détails). Un exemple de fichier de template pourrait ressembler à ceci : ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` L'exemple ci-dessus, inspiré de [https://github.com/deis/charts](https://github.com/deis/charts), est un template pour un contrôleur de réplication Kubernetes. Il peut utiliser les quatre values de template suivantes (généralement définies dans un fichier `values.yaml`) : - `imageRegistry` : Le registre source pour l'image Docker. - `dockerTag` : Le tag pour l'image Docker. - `pullPolicy` : La politique de pull Kubernetes. - `storage` : Le backend de stockage, dont la valeur par défaut est `"minio"` Toutes ces values sont définies par l'auteur du template. Helm n'exige ni ne dicte de paramètres. Pour voir de nombreux charts fonctionnels, consultez le [Artifact Hub](https://artifacthub.io/packages/search?kind=0) de la CNCF. ### Values prédéfinies Les values fournies via un fichier `values.yaml` (ou via le flag `--set`) sont accessibles depuis l'objet `.Values` dans un template. Mais il existe d'autres éléments de données prédéfinis auxquels vous pouvez accéder dans vos templates. Les values suivantes sont prédéfinies, disponibles pour chaque template, et ne peuvent pas être remplacées. Comme pour toutes les values, les noms sont _sensibles à la casse_. - `Release.Name` : Le nom de la release (pas du chart) - `Release.Namespace` : Le namespace dans lequel le chart a été déployé. - `Release.Service` : Le service qui a effectué la release. - `Release.IsUpgrade` : Défini à true si l'opération actuelle est une mise à niveau ou un rollback. - `Release.IsInstall` : Défini à true si l'opération actuelle est une installation. - `Chart` : Le contenu du `Chart.yaml`. Ainsi, la version du chart est accessible via `Chart.Version` et les mainteneurs sont dans `Chart.Maintainers`. - `Files` : Un objet de type map contenant tous les fichiers non spéciaux du chart. Cela ne vous donne pas accès aux templates, mais vous permet d'accéder aux fichiers additionnels présents (sauf s'ils sont exclus via `.helmignore`). Les fichiers sont accessibles via `{{ index .Files "file.name" }}` ou via la fonction `{{.Files.Get name }}`. Vous pouvez également accéder au contenu du fichier sous forme de `[]byte` avec `{{ .Files.GetBytes }}` - `Capabilities` : Un objet de type map contenant des informations sur les versions de Kubernetes (`{{ .Capabilities.KubeVersion }}`) et les versions d'API Kubernetes supportées (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **NOTE :** Tout champ inconnu du `Chart.yaml` sera supprimé. Il ne sera pas accessible dans l'objet `Chart`. Ainsi, `Chart.yaml` ne peut pas être utilisé pour passer des données structurées arbitraires dans le template. Le fichier values peut être utilisé à cette fin. ### Fichiers values En considérant le template de la section précédente, un fichier `values.yaml` fournissant les values nécessaires ressemblerait à ceci : ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Un fichier values est formaté en YAML. Un chart peut inclure un fichier `values.yaml` par défaut. La commande helm install permet à un utilisateur de remplacer les values en fournissant des values YAML supplémentaires : ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Lorsque les values sont passées de cette manière, elles seront fusionnées avec le fichier values par défaut. Par exemple, considérons un fichier `myvals.yaml` qui ressemble à ceci : ```yaml storage: "gcs" ``` Lorsque ceci est fusionné avec le `values.yaml` du chart, le contenu généré résultant sera : ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Notez que seul le dernier champ a été remplacé. **NOTE :** Le fichier values par défaut inclus dans un chart _doit_ être nommé `values.yaml`. Mais les fichiers spécifiés en ligne de commande peuvent avoir n'importe quel nom. **NOTE :** Si le flag `--set` est utilisé avec `helm install` ou `helm upgrade`, ces values sont simplement converties en YAML côté client. **NOTE :** Si des entrées obligatoires existent dans le fichier values, elles peuvent être déclarées comme requises dans le template du chart en utilisant la [fonction 'required'](/howto/charts_tips_and_tricks.md). Toutes ces values sont ensuite accessibles dans les templates via l'objet `.Values` : ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Portée, dépendances et values Les fichiers values peuvent déclarer des values pour le chart de niveau supérieur, ainsi que pour tous les charts inclus dans le répertoire `charts/` de ce chart. Ou, formulé différemment, un fichier values peut fournir des values au chart ainsi qu'à toutes ses dépendances. Par exemple, le chart WordPress de démonstration ci-dessus a `mysql` et `apache` comme dépendances. Le fichier values pourrait fournir des values à tous ces composants : ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Les charts de niveau supérieur ont accès à toutes les variables définies en dessous. Ainsi, le chart WordPress peut accéder au mot de passe MySQL via `.Values.mysql.password`. Mais les charts de niveau inférieur ne peuvent pas accéder aux éléments des charts parents, donc MySQL ne pourra pas accéder à la propriété `title`. De même, il ne peut pas accéder à `apache.port`. Les values sont séparées par namespace, mais les préfixes de namespace sont supprimés. Ainsi, pour le chart WordPress, il peut accéder au champ du mot de passe MySQL via `.Values.mysql.password`. Mais pour le chart MySQL, la portée des values a été réduite et le préfixe de namespace supprimé, donc il verra le champ password simplement comme `.Values.password`. #### Values globales À partir de la version 2.0.0-Alpha.2, Helm supporte des values "globales" spéciales. Considérons cette version modifiée de l'exemple précédent : ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Ceci ajoute une section `global` avec la valeur `app: MyWordPress`. Cette valeur est disponible pour _tous_ les charts via `.Values.global.app`. Par exemple, les templates `mysql` peuvent accéder à `app` via `{{ .Values.global.app }}`, tout comme le chart `apache`. En fait, le fichier values ci-dessus est régénéré comme ceci : ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` Cela fournit un moyen de partager une variable de niveau supérieur avec tous les sous-charts, ce qui est utile pour des choses comme définir des propriétés `metadata` comme les labels. Si un sous-chart déclare une variable globale, cette globale sera passée _vers le bas_ (aux sous-charts du sous-chart), mais pas _vers le haut_ au chart parent. Il n'y a aucun moyen pour un sous-chart d'influencer les values du chart parent. De plus, les variables globales des charts parents ont la priorité sur les variables globales des sous-charts. ### Fichiers de schéma Parfois, un mainteneur de chart peut vouloir définir une structure pour ses values. Cela peut être fait en définissant un schéma dans le fichier `values.schema.json`. Un schéma est représenté sous forme de [JSON Schema](https://json-schema.org/). Il pourrait ressembler à ceci : ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Ce schéma sera appliqué aux values pour les valider. La validation se produit lorsque l'une des commandes suivantes est invoquée : - `helm install` - `helm upgrade` - `helm lint` - `helm template` Un exemple de fichier `values.yaml` qui répond aux exigences de ce schéma pourrait ressembler à ceci : ```yaml name: frontend protocol: https port: 443 ``` Notez que le schéma est appliqué à l'objet `.Values` final, et pas seulement au fichier `values.yaml`. Cela signifie que le fichier `yaml` suivant est valide, à condition que le chart soit installé avec l'option `--set` appropriée montrée ci-dessous. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` De plus, l'objet `.Values` final est vérifié par rapport aux schémas de *tous* les sous-charts. Cela signifie que les restrictions d'un sous-chart ne peuvent pas être contournées par un chart parent. Cela fonctionne également dans l'autre sens - si un sous-chart a une exigence qui n'est pas satisfaite dans le fichier `values.yaml` du sous-chart, le chart parent *doit* satisfaire ces restrictions pour être valide. La validation de schéma peut être désactivée avec l'option montrée ci-dessous. C'est particulièrement utile dans les environnements isolés lorsque le fichier JSON Schema d'un chart contient des références distantes. ```console helm install --skip-schema-validation ``` ### Références En ce qui concerne l'écriture de templates, values et fichiers de schéma, il existe plusieurs références standard qui vous aideront. - [Templates Go](https://godoc.org/text/template) - [Fonctions de template supplémentaires](https://godoc.org/github.com/Masterminds/sprig) - [Le format YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) Kubernetes fournit un mécanisme pour déclarer de nouveaux types d'objets Kubernetes. En utilisant les CustomResourceDefinitions (CRDs), les développeurs Kubernetes peuvent déclarer des types de ressources personnalisées. Dans Helm 3, les CRDs sont traitées comme un type spécial d'objet. Elles sont installées avant le reste du chart et sont soumises à certaines limitations. Les fichiers YAML CRD doivent être placés dans le répertoire `crds/` à l'intérieur d'un chart. Plusieurs CRDs (séparées par des marqueurs de début et de fin YAML) peuvent être placées dans le même fichier. Helm tentera de charger _tous_ les fichiers du répertoire CRD dans Kubernetes. Les fichiers CRD _ne peuvent pas être templatisés_. Ils doivent être des documents YAML bruts. Lorsque Helm installe un nouveau chart, il télécharge les CRDs, attend jusqu'à ce que les CRDs soient rendues disponibles par le serveur API, puis démarre le moteur de template, effectue le rendu du reste du chart, et le télécharge vers Kubernetes. En raison de cet ordre, les informations CRD sont disponibles dans l'objet `.Capabilities` des templates Helm, et les templates Helm peuvent créer de nouvelles instances d'objets qui ont été déclarés dans les CRDs. Par exemple, si votre chart avait une CRD pour `CronTab` dans le répertoire `crds/`, vous pouvez créer des instances du type `CronTab` dans le répertoire `templates/` : ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Le fichier `crontab.yaml` doit contenir la CRD sans directives de template : ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Ensuite, le template `mycrontab.yaml` peut créer un nouveau `CronTab` (en utilisant les templates comme d'habitude) : ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm s'assurera que le type `CronTab` a été installé et est disponible depuis le serveur API Kubernetes avant de procéder à l'installation des éléments dans `templates/`. ### Limitations des CRDs Contrairement à la plupart des objets dans Kubernetes, les CRDs sont installées globalement. Pour cette raison, Helm adopte une approche très prudente dans la gestion des CRDs. Les CRDs sont soumises aux limitations suivantes : - Les CRDs ne sont jamais réinstallées. Si Helm détermine que les CRDs dans le répertoire `crds/` sont déjà présentes (quelle que soit la version), Helm ne tentera pas de les installer ou de les mettre à niveau. - Les CRDs ne sont jamais installées lors d'une mise à niveau ou d'un rollback. Helm créera uniquement les CRDs lors des opérations d'installation. - Les CRDs ne sont jamais supprimées. La suppression d'une CRD supprime automatiquement tout le contenu de la CRD dans tous les namespaces du cluster. Par conséquent, Helm ne supprimera pas les CRDs. Les opérateurs qui souhaitent mettre à niveau ou supprimer des CRDs sont encouragés à le faire manuellement et avec beaucoup de précaution. ## Utiliser Helm pour gérer les charts L'outil `helm` dispose de plusieurs commandes pour travailler avec les charts. Il peut créer un nouveau chart pour vous : ```console $ helm create mychart Created mychart/ ``` Une fois que vous avez modifié un chart, `helm` peut l'empaqueter dans une archive de chart pour vous : ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Vous pouvez également utiliser `helm` pour vous aider à trouver des problèmes de formatage ou d'information dans votre chart : ```console $ helm lint mychart No issues found ``` ## Dépôts de charts Un _dépôt de charts_ est un serveur HTTP qui héberge un ou plusieurs charts empaquetés. Bien que `helm` puisse être utilisé pour gérer des répertoires de charts locaux, quand il s'agit de partager des charts, le mécanisme préféré est un dépôt de charts. Tout serveur HTTP capable de servir des fichiers YAML et tar et de répondre aux requêtes GET peut être utilisé comme serveur de dépôt. L'équipe Helm a testé certains serveurs, notamment Google Cloud Storage avec le mode site web activé, et S3 avec le mode site web activé. Un dépôt est caractérisé principalement par la présence d'un fichier spécial appelé `index.yaml` qui contient une liste de tous les paquets fournis par le dépôt, ainsi que des métadonnées permettant de récupérer et vérifier ces paquets. Côté client, les dépôts sont gérés avec les commandes `helm repo`. Cependant, Helm ne fournit pas d'outils pour télécharger des charts vers des serveurs de dépôt distants. En effet, cela ajouterait des exigences substantielles à un serveur implémentant cette fonctionnalité, et augmenterait donc la barrière pour mettre en place un dépôt. ## Packs de démarrage de charts La commande `helm create` prend une option optionnelle `--starter` qui vous permet de spécifier un "chart de démarrage". De plus, l'option starter a un alias court `-p`. Exemples d'utilisation : ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Les starters sont simplement des charts ordinaires, mais situés dans `$XDG_DATA_HOME/helm/starters`. En tant que développeur de chart, vous pouvez créer des charts spécifiquement conçus pour être utilisés comme starters. Ces charts doivent être conçus avec les considérations suivantes en tête : - Le `Chart.yaml` sera écrasé par le générateur. - Les utilisateurs s'attendront à modifier le contenu d'un tel chart, donc la documentation devrait indiquer comment les utilisateurs peuvent le faire. - Toutes les occurrences de `` seront remplacées par le nom de chart spécifié afin que les charts de démarrage puissent être utilisés comme templates, sauf pour certains fichiers de variables. Par exemple, si vous utilisez des fichiers personnalisés dans le répertoire `vars` ou certains fichiers `README.md`, `` ne sera PAS remplacé à l'intérieur de ceux-ci. De plus, la description du chart n'est pas héritée. Actuellement, la seule façon d'ajouter un chart à `$XDG_DATA_HOME/helm/starters` est de le copier manuellement. Dans la documentation de votre chart, vous voudrez peut-être expliquer ce processus. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Hooks de chart description: Décrit comment utiliser les hooks de chart. sidebar_position: 2 --- Helm fournit un mécanisme de _hook_ permettant aux développeurs de charts d'intervenir à certains moments du cycle de vie d'une release. Par exemple, vous pouvez utiliser les hooks pour : - Charger un ConfigMap ou un Secret pendant l'installation avant le chargement des autres charts. - Exécuter un Job pour sauvegarder une base de données avant l'installation d'un nouveau chart, puis exécuter un second job après la mise à niveau pour restaurer les données. - Exécuter un Job avant la suppression d'une release pour retirer proprement un service de la rotation avant de le supprimer. Les hooks fonctionnent comme des templates classiques, mais possèdent des annotations spéciales qui amènent Helm à les utiliser différemment. Cette section couvre les principes de base de l'utilisation des hooks. ## Les hooks disponibles Les hooks suivants sont définis : | Valeur de l'annotation | Description | | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | `pre-install` | S'exécute après le rendu des templates, mais avant la création des ressources dans Kubernetes | | `post-install` | S'exécute après le chargement de toutes les ressources dans Kubernetes | | `pre-delete` | S'exécute lors d'une demande de suppression, avant la suppression des ressources de Kubernetes | | `post-delete` | S'exécute lors d'une demande de suppression, après la suppression de toutes les ressources de la release | | `pre-upgrade` | S'exécute lors d'une mise à niveau, après le rendu des templates, mais avant la mise à jour des ressources | | `post-upgrade` | S'exécute lors d'une mise à niveau, après la mise à jour de toutes les ressources | | `pre-rollback` | S'exécute lors d'un rollback, après le rendu des templates, mais avant le rollback des ressources | | `post-rollback` | S'exécute lors d'un rollback, après la modification de toutes les ressources | | `test` | S'exécute lorsque la sous-commande test de Helm est invoquée ([voir la documentation des tests](/topics/chart_tests.md)) | _Note : le hook `crd-install` a été supprimé au profit du répertoire `crds/` dans Helm 3._ ## Les hooks et le cycle de vie d'une release Les hooks vous permettent, en tant que développeur de charts, d'effectuer des opérations à des moments stratégiques du cycle de vie d'une release. Par exemple, considérons le cycle de vie d'un `helm install`. Par défaut, celui-ci se déroule ainsi : 1. L'utilisateur exécute `helm install foo` 2. L'API d'installation de la bibliothèque Helm est appelée 3. Après quelques vérifications, la bibliothèque effectue le rendu des templates de `foo` 4. La bibliothèque charge les ressources résultantes dans Kubernetes 5. La bibliothèque renvoie l'objet release (et d'autres données) au client 6. Le client se termine Helm définit deux hooks pour le cycle de vie de l'installation : `pre-install` et `post-install`. Si le développeur du chart `foo` implémente ces deux hooks, le cycle de vie est modifié ainsi : 1. L'utilisateur exécute `helm install foo` 2. L'API d'installation de la bibliothèque Helm est appelée 3. Les CRDs du répertoire `crds/` sont installés 4. Après quelques vérifications, la bibliothèque effectue le rendu des templates de `foo` 5. La bibliothèque prépare l'exécution des hooks `pre-install` (chargement des ressources du hook dans Kubernetes) 6. La bibliothèque trie les hooks par poids (attribuant un poids de 0 par défaut), puis par type de ressource et enfin par nom dans l'ordre croissant 7. La bibliothèque charge ensuite le hook ayant le poids le plus faible en premier (du négatif vers le positif) 8. La bibliothèque attend que le hook soit « Ready » (sauf pour les CRDs) 9. La bibliothèque charge les ressources résultantes dans Kubernetes. Notez que si le drapeau `--wait` est défini, la bibliothèque attendra que toutes les ressources soient dans un état prêt et n'exécutera pas le hook `post-install` tant qu'elles ne le seront pas. 10. La bibliothèque exécute le hook `post-install` (chargement des ressources du hook) 11. La bibliothèque attend que le hook soit « Ready » 12. La bibliothèque renvoie l'objet release (et d'autres données) au client 13. Le client se termine Que signifie attendre qu'un hook soit prêt ? Cela dépend de la ressource déclarée dans le hook. Si la ressource est de type `Job` ou `Pod`, Helm attendra qu'elle s'exécute avec succès jusqu'à son terme. Et si le hook échoue, la release échouera. Il s'agit d'une _opération bloquante_, le client Helm se mettra donc en pause pendant l'exécution du Job. Pour tous les autres types, dès que Kubernetes marque la ressource comme chargée (ajoutée ou mise à jour), la ressource est considérée comme « Ready ». Lorsque plusieurs ressources sont déclarées dans un hook, elles sont exécutées en série. Si elles possèdent des poids de hook (voir ci-dessous), elles sont exécutées dans l'ordre de leurs poids. À partir de Helm 3.2.0, les ressources de hook ayant le même poids sont installées dans le même ordre que les ressources normales (non-hook). Sinon, l'ordre n'est pas garanti. (Dans Helm 2.3.0 et versions ultérieures, elles étaient triées par ordre alphabétique. Ce comportement n'est toutefois pas considéré comme contraignant et pourrait changer à l'avenir.) Une bonne pratique consiste à ajouter un poids de hook et à le définir à `0` si le poids n'est pas important. ### Les ressources de hook ne sont pas gérées avec les releases correspondantes Les ressources créées par un hook ne sont actuellement pas suivies ni gérées dans le cadre de la release. Une fois que Helm a vérifié que le hook a atteint son état prêt, il ne touche plus à la ressource du hook. Le nettoyage des ressources de hook lors de la suppression de la release correspondante pourrait être ajouté à Helm 3 dans le futur, donc toute ressource de hook qui ne doit jamais être supprimée doit être annotée avec `helm.sh/resource-policy: keep`. En pratique, cela signifie que si vous créez des ressources dans un hook, vous ne pouvez pas compter sur `helm uninstall` pour les supprimer. Pour détruire ces ressources, vous devez soit [ajouter une annotation personnalisée `helm.sh/hook-delete-policy`](#politiques-de-suppression-de-hook) au fichier template du hook, soit [définir le champ TTL (time to live) d'une ressource Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Écrire un hook Les hooks sont simplement des fichiers manifeste Kubernetes avec des annotations spéciales dans la section `metadata`. Comme ce sont des fichiers template, vous pouvez utiliser toutes les fonctionnalités habituelles des templates, y compris la lecture de `.Values`, `.Release` et `.Template`. Par exemple, ce template, stocké dans `templates/post-install-job.yaml`, déclare un job à exécuter lors du `post-install` : ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # C'est ce qui définit cette ressource comme un hook. Sans cette ligne, # le job est considéré comme faisant partie de la release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Ce qui fait de ce template un hook, c'est l'annotation : ```yaml annotations: "helm.sh/hook": post-install ``` Une ressource peut implémenter plusieurs hooks : ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` De même, il n'y a pas de limite au nombre de ressources différentes pouvant implémenter un hook donné. Par exemple, on pourrait déclarer à la fois un secret et un config map comme hook de pre-install. Lorsque des sous-charts déclarent des hooks, ceux-ci sont également évalués. Il n'y a aucun moyen pour un chart parent de désactiver les hooks déclarés par les sous-charts. Il est possible de définir un poids pour un hook afin de construire un ordre d'exécution déterministe. Les poids sont définis à l'aide de l'annotation suivante : ```yaml annotations: "helm.sh/hook-weight": "5" ``` Les poids de hook peuvent être des nombres positifs ou négatifs, mais doivent être représentés sous forme de chaînes de caractères. Lorsque Helm commence le cycle d'exécution des hooks d'un type particulier, il trie ces hooks par ordre croissant. ### Politiques de suppression de hook Il est possible de définir des politiques qui déterminent quand supprimer les ressources de hook correspondantes. Les politiques de suppression de hook sont définies à l'aide de l'annotation suivante : ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Vous pouvez choisir une ou plusieurs valeurs d'annotation parmi celles définies : | Valeur de l'annotation | Description | | ---------------------- | ---------------------------------------------------------------------------- | | `before-hook-creation` | Supprime la ressource précédente avant le lancement d'un nouveau hook (défaut) | | `hook-succeeded` | Supprime la ressource après l'exécution réussie du hook | | `hook-failed` | Supprime la ressource si le hook a échoué pendant l'exécution | Si aucune annotation de politique de suppression de hook n'est spécifiée, le comportement `before-hook-creation` s'applique par défaut. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: Thèmes sidebar_position: 3 --- # Guides par thème Dans cette section vous trouverez une introduction pour chacune des parties clés de Helm dont vous pourrez avoir besoin. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: APIs Kubernetes dépréciées description: Explique les APIs Kubernetes dépréciées dans Helm --- Kubernetes est un système basé sur les APIs, et l'API évolue au fil du temps pour refléter une meilleure compréhension des problématiques. C'est une pratique courante pour les systèmes et leurs APIs. Une partie importante de l'évolution des APIs est d'avoir une bonne politique et un bon processus de dépréciation pour informer les utilisateurs de la manière dont les changements d'API sont implémentés. En d'autres termes, les consommateurs de votre API doivent savoir à l'avance et dans quelle version une API sera supprimée ou modifiée. Cela évite les surprises et les changements incompatibles pour les consommateurs. La [politique de dépréciation de Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documente comment Kubernetes gère les changements de ses versions d'API. Cette politique précise la durée pendant laquelle les versions d'API seront supportées après l'annonce de leur dépréciation. Il est donc important d'être attentif aux annonces de dépréciation et de savoir quand les versions d'API seront supprimées, afin de minimiser l'impact. Voici un exemple d'annonce [concernant la suppression des versions d'API dépréciées dans Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), publiée quelques mois avant la release. Ces versions d'API auraient également été annoncées comme dépréciées auparavant. Cela montre qu'une bonne politique est en place pour informer les consommateurs du support des versions d'API. Les templates Helm spécifient un [groupe d'API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) lors de la définition d'un objet Kubernetes, de manière similaire à un fichier manifeste Kubernetes. Ce groupe est spécifié dans le champ `apiVersion` du template et identifie la version d'API de l'objet Kubernetes. Cela signifie que les utilisateurs de Helm et les mainteneurs de charts doivent être attentifs aux versions d'API Kubernetes qui ont été dépréciées et dans quelle version de Kubernetes elles seront supprimées. ## Mainteneurs de charts Vous devez auditer vos charts pour vérifier les versions d'API Kubernetes qui sont dépréciées ou supprimées dans une version de Kubernetes. Les versions d'API identifiées comme devant être ou étant désormais hors support doivent être mises à jour vers la version supportée et une nouvelle version du chart doit être publiée. La version d'API est définie par les champs `kind` et `apiVersion`. Par exemple, voici une version d'API de l'objet `Deployment` supprimée dans Kubernetes 1.16 : ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Utilisateurs de Helm Vous devez auditer les charts que vous utilisez (de la même manière que les [mainteneurs de charts](#mainteneurs-de-charts)) et identifier ceux dont les versions d'API sont dépréciées ou supprimées dans une version de Kubernetes. Pour les charts identifiés, vous devez vérifier si une version plus récente du chart (avec des versions d'API supportées) existe ou mettre à jour le chart vous-même. De plus, vous devez également auditer les charts déployés (c'est-à-dire les releases Helm) en vérifiant à nouveau les versions d'API dépréciées ou supprimées. Cela peut être fait en obtenant les détails d'une release à l'aide de la commande `helm get manifest`. La méthode pour mettre à jour une release Helm vers des APIs supportées dépend de vos constatations : 1. Si vous ne trouvez que des versions d'API dépréciées : - Effectuez un `helm upgrade` avec une version du chart utilisant des versions d'API Kubernetes supportées - Ajoutez une description lors de la mise à niveau, indiquant de ne pas effectuer de rollback vers une version de Helm antérieure à cette version actuelle 2. Si vous trouvez des version(s) d'API supprimée(s) dans une version de Kubernetes : - Si vous utilisez une version de Kubernetes où la ou les version(s) d'API sont encore disponibles (par exemple, vous êtes sur Kubernetes 1.15 et vous utilisez des APIs qui seront supprimées dans Kubernetes 1.16) : - Suivez la procédure de l'étape 1 - Sinon (par exemple, vous utilisez déjà une version de Kubernetes où certaines versions d'API rapportées par `helm get manifest` ne sont plus disponibles) : - Vous devez modifier le manifeste de release stocké dans le cluster pour mettre à jour les versions d'API vers des APIs supportées. Consultez [Mise à jour des versions d'API d'un manifeste de release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release) pour plus de détails > Remarque : Dans tous les cas de mise à jour d'une release Helm avec des APIs supportées, vous ne devez jamais effectuer de rollback de la release vers une version antérieure à la version de release avec les APIs supportées. > Recommandation : La bonne pratique consiste à mettre à niveau les releases utilisant des versions d'API dépréciées vers des versions d'API supportées, avant de mettre à niveau vers un cluster Kubernetes qui supprime ces versions d'API. Si vous ne mettez pas à jour une release comme suggéré précédemment, vous obtiendrez une erreur similaire à la suivante lors de la tentative de mise à niveau d'une release dans une version de Kubernetes où sa ou ses version(s) d'API est/sont supprimée(s) : ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm échoue dans ce scénario car il tente de créer un patch de différences entre la release actuellement déployée (qui contient les APIs Kubernetes supprimées dans cette version de Kubernetes) et le chart que vous passez avec les versions d'API mises à jour/supportées. La raison sous-jacente de l'échec est que lorsque Kubernetes supprime une version d'API, la bibliothèque client Go de Kubernetes ne peut plus parser les objets dépréciés, et Helm échoue donc lors de l'appel à la bibliothèque. Helm ne peut malheureusement pas récupérer de cette situation et n'est plus en mesure de gérer une telle release. Consultez [Mise à jour des versions d'API d'un manifeste de release](#mise-à-jour-des-versions-dapi-dun-manifeste-de-release) pour savoir comment récupérer de ce scénario. ## Mise à jour des versions d'API d'un manifeste de release Le manifeste est une propriété de l'objet release Helm qui est stockée dans le champ data d'un Secret (par défaut) ou d'un ConfigMap dans le cluster. Le champ data contient un objet compressé en gzip et encodé en base 64 (il y a un encodage base 64 supplémentaire pour un Secret). Il y a un Secret/ConfigMap par version/révision de release dans le namespace de la release. Vous pouvez utiliser le plugin Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) pour effectuer la mise à jour d'une release vers des APIs supportées. Consultez le readme pour plus de détails. Alternativement, vous pouvez suivre ces étapes manuelles pour effectuer une mise à jour des versions d'API d'un manifeste de release. Selon votre configuration, vous suivrez les étapes pour le backend Secret ou ConfigMap. - Obtenez le nom du Secret ou ConfigMap associé à la dernière release déployée : - Backend Secrets : `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Backend ConfigMap : `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Obtenez les détails de la dernière release déployée : - Backend Secrets : `kubectl get secret -n -o yaml > release.yaml` - Backend ConfigMap : `kubectl get configmap -n -o yaml > release.yaml` - Sauvegardez la release au cas où vous auriez besoin de la restaurer si quelque chose tourne mal : - `cp release.yaml release.bak` - En cas d'urgence, restaurez : `kubectl apply -f release.bak -n ` - Décodez l'objet release : - Backend Secrets : `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - Backend ConfigMap : `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Modifiez les versions d'API des manifestes. Vous pouvez utiliser n'importe quel outil (par exemple, un éditeur) pour effectuer les modifications. Cela se trouve dans le champ `manifest` de votre objet release décodé (`release.data.decoded`) - Encodez l'objet release : - Backend Secrets : `cat release.data.decoded | gzip | base64 | base64` - Backend ConfigMap : `cat release.data.decoded | gzip | base64` - Remplacez la valeur de la propriété `data.release` dans le fichier de release déployée (`release.yaml`) par le nouvel objet release encodé - Appliquez le fichier au namespace : `kubectl apply -f release.yaml -n ` - Effectuez un `helm upgrade` avec une version du chart utilisant des versions d'API Kubernetes supportées - Ajoutez une description lors de la mise à niveau, indiquant de ne pas effectuer de rollback vers une version de Helm antérieure à cette version actuelle ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Guide des Distributions Kubernetes description: Fournit des informations sur l'utilisation de Helm dans des environnements Kubernetes spécifiques. sidebar_position: 10 --- Helm devrait fonctionner avec toute [version conforme de Kubernetes](https://github.com/cncf/k8s-conformance) (qu'elle soit [certifiée](https://www.cncf.io/certification/software-conformance/) ou non). Ce document fournit des informations sur l'utilisation de Helm dans des environnements Kubernetes spécifiques. Vous pouvez contribuer des informations supplémentaires sur d'autres distributions (triées par ordre alphabétique) si vous le souhaitez. ## AKS Helm fonctionne avec [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm a été testé et fonctionne sur la plateforme Kubernetes de Mesosphere DC/OS 1.11, sans configuration supplémentaire. ## EKS Helm fonctionne avec Amazon Elastic Kubernetes Service (Amazon EKS) : [Utilisation de Helm avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE La plateforme Kubernetes hébergée de Google, GKE, fonctionne avec Helm et ne nécessite aucune configuration supplémentaire. ## `scripts/local-cluster` et Hyperkube Hyperkube configuré via `scripts/local-cluster.sh` fonctionne correctement. Pour Hyperkube en mode natif, une configuration manuelle peut être nécessaire. ## IKS Helm fonctionne avec [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm est régulièrement testé avec [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm fonctionne dans les clusters configurés par KubeOne sans difficulté. ## Kubermatic Helm fonctionne dans les clusters utilisateurs créés par Kubermatic sans difficulté. Étant donné que les seed clusters peuvent être configurés de différentes manières, la prise en charge de Helm dépend de leur configuration. ## MicroK8s Helm peut être activé dans [MicroK8s](https://microk8s.io) avec la commande : `microk8s.enable helm3` ## Minikube Helm est testé et fonctionne avec [Minikube](https://github.com/kubernetes/minikube). Aucune configuration supplémentaire n'est requise. ## Openshift Helm fonctionne directement sur OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) ou OpenShift Origin (version >= 3.6). Pour en savoir plus, consultez [cet article de blog](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm est préinstallé avec [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 donne accès à tous les charts Helm officiels via l'interface App Catalog et la CLI Kubernetes native. Des dépôts supplémentaires peuvent être ajoutés manuellement. Plus de détails sont disponibles dans cet [article sur Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu avec `kubeadm` Kubernetes déployé avec `kubeadm` fonctionne sur les distributions Linux suivantes : - Ubuntu 16.04 - Fedora release 25 Certaines versions de Helm (v2.0.0-beta2) nécessitent d'exécuter `export KUBECONFIG=/etc/kubernetes/admin.conf` ou de créer un fichier `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm fonctionne sur VMware Tanzu Kubernetes Grid, TKG, sans modification de configuration. La CLI Tanzu permet de gérer l'installation de packages pour [helm-controller](https://fluxcd.io/flux/components/helm/), permettant une gestion déclarative des releases de charts Helm. Plus de détails sont disponibles dans la documentation TKG concernant les [packages gérés via CLI](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Charts de type Library description: Explique les charts de type library et fournit des exemples d'utilisation sidebar_position: 4 --- Un chart de type library est un type de [chart Helm](/topics/charts.md) qui définit des primitives ou des définitions pouvant être partagées par les templates Helm d'autres charts. Cela permet aux utilisateurs de partager des extraits de code réutilisables entre plusieurs charts, évitant ainsi la répétition et respectant le principe [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself). Le chart de type library a été introduit dans Helm 3 pour reconnaître officiellement les charts communs ou utilitaires utilisés par les mainteneurs de charts depuis Helm 2. En l'incluant comme type de chart, il offre : - Un moyen de distinguer explicitement les charts communs des charts d'application - Une logique empêchant l'installation d'un chart commun - Pas de rendu des templates dans un chart commun qui pourraient contenir des artefacts de release - La possibilité pour les charts dépendants d'utiliser le contexte de l'importateur Un mainteneur de chart peut définir un chart commun comme chart de type library et être ainsi certain que Helm gérera le chart de manière standard et cohérente. Cela signifie également que les définitions d'un chart d'application peuvent être partagées simplement en changeant le type de chart. ## Créer un chart de type library simple Comme mentionné précédemment, un chart de type library est un type de [chart Helm](/topics/charts.md). Cela signifie que vous pouvez commencer par créer un chart de base : ```console $ helm create mylibchart Creating mylibchart ``` Vous allez d'abord supprimer tous les fichiers du répertoire `templates` car nous allons créer nos propres définitions de templates dans cet exemple. ```console $ rm -rf mylibchart/templates/* ``` Le fichier values ne sera pas non plus nécessaire. ```console $ rm -f mylibchart/values.yaml ``` Avant de passer à la création du code commun, revenons sur quelques concepts Helm pertinents. Un [template nommé](/chart_template_guide/named_templates.md) (parfois appelé partial ou sous-template) est simplement un template défini dans un fichier et auquel on donne un nom. Dans le répertoire `templates/`, tout fichier commençant par un underscore (_) n'est pas censé générer un fichier manifeste Kubernetes. Par convention, les templates utilitaires et les partials sont donc placés dans des fichiers `_*.tpl` ou `_*.yaml`. Dans cet exemple, nous allons coder un ConfigMap commun qui crée une ressource ConfigMap vide. Nous définirons ce ConfigMap commun dans le fichier `mylibchart/templates/_configmap.yaml` comme suit : ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` La structure ConfigMap est définie dans le template nommé `mylibchart.configmap.tpl`. C'est un simple ConfigMap avec une ressource vide, `data`. Dans ce fichier, il y a un autre template nommé appelé `mylibchart.configmap`. Ce template nommé inclut un autre template nommé `mylibchart.util.merge` qui prend 2 templates nommés comme arguments : le template appelant `mylibchart.configmap` et `mylibchart.configmap.tpl`. La fonction utilitaire `mylibchart.util.merge` est un template nommé dans `mylibchart/templates/_util.yaml`. C'est un utilitaire pratique tiré de [The Common Helm Helper Chart](#the-common-helm-helper-chart) car il fusionne les 2 templates et remplace les parties communes aux deux : ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Ceci est important lorsqu'un chart souhaite utiliser du code commun qu'il doit personnaliser avec sa propre configuration. Enfin, changeons le type de chart en `library`. Cela nécessite de modifier le fichier `mylibchart/Chart.yaml` comme suit : ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` Le chart de type library est maintenant prêt à être partagé et sa définition de ConfigMap peut être réutilisée. Avant de continuer, il est utile de vérifier si Helm reconnaît le chart comme un chart de type library : ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Utiliser le chart de type library simple Il est temps d'utiliser le chart de type library. Cela signifie créer à nouveau un chart de base : ```console $ helm create mychart Creating mychart ``` Supprimons à nouveau les fichiers de templates car nous voulons créer uniquement un ConfigMap : ```console $ rm -rf mychart/templates/* ``` Lorsque nous voulons créer un simple ConfigMap dans un template Helm, cela pourrait ressembler à ceci : ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Cependant, nous allons réutiliser le code commun déjà créé dans `mylibchart`. Le ConfigMap peut être créé dans le fichier `mychart/templates/configmap.yaml` comme suit : ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Vous pouvez voir que cela simplifie le travail en héritant de la définition commune du ConfigMap qui ajoute les propriétés standard. Dans notre template, nous ajoutons la configuration, dans ce cas la clé de données `myvalue` et sa valeur. La configuration remplace la ressource vide du ConfigMap commun. Ceci est possible grâce à la fonction utilitaire `mylibchart.util.merge` mentionnée dans la section précédente. Pour pouvoir utiliser le code commun, nous devons ajouter `mylibchart` comme dépendance. Ajoutez ce qui suit à la fin du fichier `mychart/Chart.yaml` : ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Cela inclut le chart de type library comme dépendance dynamique depuis le système de fichiers, au même niveau que notre chart d'application. Comme nous incluons le chart de type library en tant que dépendance dynamique, nous devons exécuter `helm dependency update`. Cette commande copiera le chart de type library dans votre répertoire `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Nous sommes maintenant prêts à déployer notre chart. Avant l'installation, il est utile de vérifier d'abord le template rendu. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Cela ressemble au ConfigMap que nous voulions avec la surcharge de données `myvalue: Hello World`. Installons-le : ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Nous pouvons récupérer la release et voir que le template réel a été chargé. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Avantages des charts de type library Parce qu'ils ne peuvent pas fonctionner comme des charts autonomes, les charts de type library peuvent tirer parti des fonctionnalités suivantes : - L'objet `.Files` référence les chemins de fichiers du chart parent, plutôt que le chemin local du chart de type library - L'objet `.Values` est le même que celui du chart parent, contrairement aux [sous-charts](/chart_template_guide/subcharts_and_globals.md) d'application qui reçoivent la section de values configurée sous leur en-tête dans le parent. ## The Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` Ce [chart](https://github.com/helm/charts/tree/master/incubator/common) était le modèle original pour les charts communs. Il fournit des utilitaires qui reflètent les meilleures pratiques de développement de charts Kubernetes. Et surtout, il peut être utilisé immédiatement lors du développement de vos charts pour vous fournir du code partagé pratique. Voici une façon rapide de l'utiliser. Pour plus de détails, consultez le [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Créez à nouveau un chart de base : ```console $ helm create demo Creating demo ``` Utilisons le code commun du chart utilitaire. Tout d'abord, modifiez le déploiement `demo/templates/deployment.yaml` comme suit : ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` Et maintenant le fichier service, `demo/templates/service.yaml` comme suit : ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Ces templates montrent comment hériter du code commun du chart utilitaire simplifie votre codage à la seule configuration ou personnalisation des ressources. Pour pouvoir utiliser le code commun, nous devons ajouter `common` comme dépendance. Ajoutez ce qui suit à la fin du fichier `demo/Chart.yaml` : ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Note : Vous devrez ajouter le dépôt `incubator` à la liste des dépôts Helm (`helm repo add`). Comme nous incluons le chart en tant que dépendance dynamique, nous devons exécuter `helm dependency update`. Cette commande copiera le chart utilitaire dans votre répertoire `charts/`. Comme le chart utilitaire utilise certaines constructions de Helm 2, vous devrez ajouter ce qui suit à `demo/values.yaml` pour permettre le chargement de l'image `nginx`, car cela a été mis à jour dans le chart de base de Helm 3 : ```yaml image: tag: 1.16.0 ``` Vous pouvez tester que les templates du chart sont corrects avant de déployer en utilisant les commandes `helm lint` et `helm template`. Si tout est en ordre, déployez avec `helm install` ! ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Gestion des permissions pour le backend de stockage SQL description: Découvrez comment configurer les permissions lors de l'utilisation du backend de stockage SQL. --- Ce document explique comment configurer et gérer les permissions lors de l'utilisation du backend de stockage SQL. ## Introduction Pour gérer les permissions, Helm s'appuie sur la fonctionnalité RBAC de Kubernetes. Lorsque vous utilisez le backend de stockage SQL, les rôles Kubernetes ne peuvent pas être utilisés pour déterminer si un utilisateur peut accéder à une ressource donnée ou non. Ce document explique comment créer et gérer ces permissions. ## Initialisation La première fois que le CLI Helm se connectera à votre base de données, le client s'assurera qu'elle a été préalablement initialisée. Si ce n'est pas le cas, il effectuera automatiquement la configuration nécessaire. Cette initialisation nécessite des privilèges d'administrateur sur le schéma public, ou au minimum la capacité de : * créer une table * accorder des privilèges sur le schéma public Une fois la migration exécutée sur votre base de données, tous les autres rôles peuvent utiliser le client. ## Accorder des privilèges à un utilisateur non administrateur dans PostgreSQL Pour gérer les permissions, le pilote du backend SQL utilise la fonctionnalité [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Level) de PostgreSQL. RLS permet à tous les utilisateurs de lire et écrire dans la même table, sans pouvoir manipuler les mêmes lignes s'ils n'y sont pas explicitement autorisés. Par défaut, tout rôle qui n'a pas reçu explicitement les privilèges appropriés obtiendra toujours une liste vide lors de l'exécution de `helm list` et ne pourra ni récupérer ni modifier aucune ressource dans le cluster. Voyons comment accorder à un rôle donné l'accès à des namespaces spécifiques : ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Cette commande accordera au rôle `role` les permissions de lecture et d'écriture sur toutes les ressources qui respectent la condition `namespace = 'default'`. Après la création de cette politique, l'utilisateur connecté à la base de données pour le compte du rôle `role` pourra voir toutes les releases présentes dans le namespace `default` lors de l'exécution de `helm list`, ainsi que les modifier et les supprimer. Les privilèges peuvent être gérés de manière granulaire avec RLS, et vous pouvez restreindre l'accès en fonction des différentes colonnes de la table : * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Guide des plugins Helm description: Présente comment utiliser et créer des plugins pour étendre les fonctionnalités de Helm. sidebar_position: 12 --- Un plugin Helm est un outil accessible via la CLI `helm`, mais qui ne fait pas partie du code source intégré de Helm. Les plugins existants peuvent être trouvés dans la section [associée](/community/related#helm-plugins) ou en recherchant sur [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Ce guide explique comment utiliser et créer des plugins. ## Vue d'ensemble Les plugins Helm sont des outils complémentaires qui s'intègrent parfaitement à Helm. Ils permettent d'étendre les fonctionnalités de base de Helm, sans nécessiter que chaque nouvelle fonctionnalité soit écrite en Go et ajoutée à l'outil principal. Les plugins Helm possèdent les caractéristiques suivantes : - Ils peuvent être ajoutés et supprimés d'une installation Helm sans impacter l'outil Helm principal. - Ils peuvent être écrits dans n'importe quel langage de programmation. - Ils s'intègrent à Helm et apparaissent dans `helm help` et ailleurs. Les plugins Helm résident dans `$HELM_PLUGINS`. Vous pouvez trouver la valeur actuelle de cette variable, y compris la valeur par défaut lorsqu'elle n'est pas définie dans l'environnement, en utilisant la commande `helm env`. Le modèle de plugin Helm est partiellement basé sur le modèle de plugin de Git. De ce fait, vous pouvez parfois entendre `helm` désigné comme la couche _porcelaine_, et les plugins comme la _plomberie_. C'est une façon abrégée de suggérer que Helm fournit l'expérience utilisateur et la logique de traitement de haut niveau, tandis que les plugins effectuent le « travail de fond » pour réaliser une action souhaitée. ## Installer un plugin Les plugins sont installés à l'aide de la commande `$ helm plugin install `. Vous pouvez passer un chemin vers un plugin sur votre système de fichiers local ou une URL d'un dépôt VCS distant. La commande `helm plugin install` clone ou copie le plugin situé au chemin/URL donné dans `$HELM_PLUGINS`. Si vous installez depuis un VCS, vous pouvez spécifier la version avec l'argument `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Si vous avez une distribution tar d'un plugin, extrayez simplement le plugin dans le répertoire `$HELM_PLUGINS`. Vous pouvez également installer des plugins tarball directement depuis une URL en exécutant `helm plugin install https://domain/path/to/plugin.tar.gz` ## Structure de fichiers d'un plugin À bien des égards, un plugin est similaire à un chart. Chaque plugin possède un répertoire de premier niveau contenant un fichier `plugin.yaml`. D'autres fichiers peuvent être présents, mais seul le fichier `plugin.yaml` est requis. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Le fichier plugin.yaml Le fichier plugin.yaml est requis pour un plugin. Il contient les champs suivants : ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### Le champ `name` Le champ `name` est le nom du plugin. Lorsque Helm exécute ce plugin, c'est le nom qu'il utilisera (par exemple, `helm NAME` invoquera ce plugin). _Le `name` doit correspondre au nom du répertoire._ Dans notre exemple ci-dessus, cela signifie que le plugin avec `name: last` doit être contenu dans un répertoire nommé `last`. Restrictions sur `name` : - `name` ne peut pas dupliquer l'une des commandes de premier niveau existantes de `helm`. - `name` doit être limité aux caractères ASCII a-z, A-Z, 0-9, `_` et `-`. ### Le champ `version` Le champ `version` est la version SemVer 2 du plugin. `usage` et `description` sont tous deux utilisés pour générer le texte d'aide d'une commande. ### Le champ `ignoreFlags` Le paramètre `ignoreFlags` indique à Helm de _ne pas_ transmettre les flags au plugin. Ainsi, si un plugin est appelé avec `helm myplugin --foo` et que `ignoreFlags: true`, alors `--foo` est ignoré silencieusement. ### Le champ `platformCommand` Le champ `platformCommand` configure la commande que le plugin exécutera lorsqu'il sera appelé. Vous ne pouvez pas définir à la fois `platformCommand` et `command`, cela entraînerait une erreur. Les règles suivantes s'appliquent pour déterminer quelle commande utiliser : - Si `platformCommand` est présent, il sera utilisé. - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée. - Si `os` correspond et `arch` est vide, la commande sera utilisée. - Si `os` et `arch` sont tous deux vides, la commande sera utilisée. - S'il n'y a pas de correspondance, Helm se terminera avec une erreur. - Si `platformCommand` n'est pas présent et que la commande dépréciée `command` est présente, elle sera utilisée. - Si la commande est vide, Helm se terminera avec une erreur. ### Le champ `platformHooks` Le champ `platformHooks` configure les commandes que le plugin exécutera pour les événements du cycle de vie. Vous ne pouvez pas définir à la fois `platformHooks` et `hooks`, cela entraînerait une erreur. Les règles suivantes s'appliquent pour déterminer quelle commande de hook utiliser : - Si `platformHooks` est présent, il sera utilisé et les commandes pour l'événement du cycle de vie seront traitées. - Si `os` et `arch` correspondent à la plateforme actuelle, la recherche s'arrête et la commande sera utilisée. - Si `os` correspond et `arch` est vide, la commande sera utilisée. - Si `os` et `arch` sont tous deux vides, la commande sera utilisée. - S'il n'y a pas de correspondance, Helm ignorera l'événement. - Si `platformHooks` n'est pas présent et que le hook déprécié `hooks` est présent, la commande pour l'événement du cycle de vie sera utilisée. - Si la commande est vide, Helm ignorera l'événement. ## Créer un plugin Voici le YAML de plugin pour un plugin simple qui aide à obtenir le nom de la dernière release : ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Les plugins peuvent nécessiter des scripts et exécutables supplémentaires. Les scripts peuvent être inclus dans le répertoire du plugin et les exécutables peuvent être téléchargés via un hook. Voici un exemple de plugin : ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Les variables d'environnement sont interpolées avant l'exécution du plugin. Le modèle ci-dessus illustre la méthode préférée pour indiquer où se trouve le programme du plugin. ### Commandes de plugin Il existe quelques stratégies pour travailler avec les commandes de plugin : - Si un plugin inclut un exécutable, l'exécutable pour un `platformCommand:` doit être packagé dans le répertoire du plugin ou installé via un hook. - La ligne `platformCommand:` ou `command:` aura toutes ses variables d'environnement développées avant l'exécution. `$HELM_PLUGIN_DIR` pointera vers le répertoire du plugin. - La commande elle-même n'est pas exécutée dans un shell. Vous ne pouvez donc pas écrire un script shell sur une seule ligne. - Helm injecte beaucoup de configuration dans les variables d'environnement. Consultez l'environnement pour voir quelles informations sont disponibles. - Helm ne fait aucune supposition sur le langage du plugin. Vous pouvez l'écrire dans le langage de votre choix. - Les commandes sont responsables d'implémenter un texte d'aide spécifique pour `-h` et `--help`. Helm utilisera `usage` et `description` pour `helm help` et `helm help myplugin`, mais ne gérera pas `helm myplugin --help`. ### Tester un plugin local Vous devez d'abord trouver votre chemin `HELM_PLUGINS`. Pour ce faire, exécutez la commande suivante : ``` bash helm env ``` Changez votre répertoire actuel vers le répertoire défini par `HELM_PLUGINS`. Maintenant vous pouvez ajouter un lien symbolique vers la sortie de build de votre plugin. Dans cet exemple, nous l'avons fait pour `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Plugins téléchargeurs Par défaut, Helm est capable de télécharger des charts via HTTP/S. À partir de Helm 2.4.0, les plugins peuvent avoir une capacité spéciale pour télécharger des charts depuis des sources arbitraires. Les plugins doivent déclarer cette capacité spéciale dans le fichier `plugin.yaml` (au niveau supérieur) : ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Si un tel plugin est installé, Helm peut interagir avec le dépôt en utilisant le protocole spécifié en invoquant la `command`. Le dépôt spécial doit être ajouté de manière similaire aux dépôts réguliers : `helm repo add favorite myprotocol://example.com/`. Les règles pour les dépôts spéciaux sont les mêmes que pour les dépôts réguliers : Helm doit être capable de télécharger le fichier `index.yaml` afin de découvrir et mettre en cache la liste des charts disponibles. La commande définie sera invoquée avec le schéma suivant : `command certFile keyFile caFile full-URL`. Les identifiants SSL proviennent de la définition du dépôt, stockée dans `$HELM_REPOSITORY_CONFIG` (c'est-à-dire `$HELM_CONFIG_HOME/repositories.yaml`). Un plugin téléchargeur doit écrire le contenu brut sur stdout et signaler les erreurs sur stderr. La commande de téléchargement supporte également les sous-commandes ou arguments, vous permettant de spécifier par exemple `bin/mydownloader subcommand -d` dans le `plugin.yaml`. Ceci est utile si vous souhaitez utiliser le même exécutable pour la commande principale du plugin et la commande de téléchargement, mais avec une sous-commande différente pour chacune. ## Variables d'environnement Lorsque Helm exécute un plugin, il transmet l'environnement externe au plugin et injecte également quelques variables d'environnement supplémentaires. Les variables comme `KUBECONFIG` sont définies pour le plugin si elles sont définies dans l'environnement externe. Les variables suivantes sont garanties d'être définies : - `HELM_PLUGINS` : Le chemin vers le répertoire des plugins. - `HELM_PLUGIN_NAME` : Le nom du plugin, tel qu'invoqué par `helm`. Ainsi `helm myplug` aura le nom court `myplug`. - `HELM_PLUGIN_DIR` : Le répertoire qui contient le plugin. - `HELM_BIN` : Le chemin vers la commande `helm` (telle qu'exécutée par l'utilisateur). - `HELM_DEBUG` : Indique si le flag debug a été défini par helm. - `HELM_REGISTRY_CONFIG` : L'emplacement de la configuration du registre (si utilisé). Notez que l'utilisation de Helm avec des registres est une fonctionnalité expérimentale. - `HELM_REPOSITORY_CACHE` : Le chemin vers les fichiers de cache du dépôt. - `HELM_REPOSITORY_CONFIG` : Le chemin vers le fichier de configuration du dépôt. - `HELM_NAMESPACE` : Le namespace donné à la commande `helm` (généralement via le flag `-n`). - `HELM_KUBECONTEXT` : Le nom du contexte de configuration Kubernetes donné à la commande `helm`. De plus, si un fichier de configuration Kubernetes a été explicitement spécifié, il sera défini comme variable `KUBECONFIG`. ## Note sur l'analyse des flags Lors de l'exécution d'un plugin, Helm analyse les flags globaux pour son propre usage. Aucun de ces flags n'est transmis au plugin. - `--burst-limit` : Converti en `$HELM_BURST_LIMIT` - `--debug` : Si spécifié, `$HELM_DEBUG` est défini à `1` - `--kube-apiserver` : Converti en `$HELM_KUBEAPISERVER` - `--kube-as-group` : Converti en `$HELM_KUBEASGROUPS` - `--kube-as-user` : Converti en `$HELM_KUBEASUSER` - `--kube-ca-file` : Converti en `$HELM_KUBECAFILE` - `--kube-context` : Converti en `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify` : Converti en `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name` : Converti en `$HELM_KUBETLS_SERVER_NAME` - `--kube-token` : Converti en `$HELM_KUBETOKEN` - `--kubeconfig` : Converti en `$KUBECONFIG` - `--namespace` et `-n` : Converti en `$HELM_NAMESPACE` - `--qps` : Converti en `$HELM_QPS` - `--registry-config` : Converti en `$HELM_REGISTRY_CONFIG` - `--repository-cache` : Converti en `$HELM_REPOSITORY_CACHE` - `--repository-config` : Converti en `$HELM_REPOSITORY_CONFIG` Les plugins _devraient_ afficher un texte d'aide et se terminer pour `-h` et `--help`. Dans tous les autres cas, les plugins peuvent utiliser les flags comme approprié. ## Fournir l'auto-complétion shell À partir de Helm 3.2, un plugin peut optionnellement fournir le support de l'auto-complétion shell dans le cadre du mécanisme d'auto-complétion existant de Helm. ### Auto-complétion statique Si un plugin fournit ses propres flags et/ou sous-commandes, il peut en informer Helm via un fichier `completion.yaml` situé dans le répertoire racine du plugin. Le fichier `completion.yaml` a la forme suivante : ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Notes : 1. Toutes les sections sont optionnelles mais doivent être fournies si applicables. 1. Les flags ne doivent pas inclure le préfixe `-` ou `--`. 1. Les flags courts et longs peuvent et doivent être spécifiés. Un flag court n'a pas besoin d'être associé à sa forme longue correspondante, mais les deux formes doivent être listées. 1. Les flags n'ont pas besoin d'être ordonnés d'une manière particulière, mais doivent être listés au bon endroit dans la hiérarchie des sous-commandes du fichier. 1. Les flags globaux existants de Helm sont déjà gérés par le mécanisme d'auto-complétion de Helm, les plugins n'ont donc pas besoin de spécifier les flags suivants : `--debug`, `--namespace` ou `-n`, `--kube-context`, et `--kubeconfig`, ou tout autre flag global. 1. La liste `validArgs` fournit une liste statique des complétions possibles pour le premier paramètre suivant une sous-commande. Il n'est pas toujours possible de fournir une telle liste à l'avance (voir la section [Complétion dynamique](#complétion-dynamique) ci-dessous), auquel cas la section `validArgs` peut être omise. Le fichier `completion.yaml` est entièrement optionnel. S'il n'est pas fourni, Helm ne fournira simplement pas d'auto-complétion shell pour le plugin (sauf si la [Complétion dynamique](#complétion-dynamique) est supportée par le plugin). De plus, l'ajout d'un fichier `completion.yaml` est rétro-compatible et n'impactera pas le comportement du plugin lors de l'utilisation de versions plus anciennes de Helm. Par exemple, pour le plugin [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus) qui n'a pas de sous-commandes mais accepte les mêmes flags que la commande `helm status`, le fichier `completion.yaml` est : ```yaml name: fullstatus flags: - o - output - revision ``` Un exemple plus élaboré pour le plugin [`2to3`](https://github.com/helm/helm-2to3), a un fichier `completion.yaml` de : ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Complétion dynamique Également à partir de Helm 3.2, les plugins peuvent fournir leur propre auto-complétion shell dynamique. L'auto-complétion shell dynamique est la complétion des valeurs de paramètres ou de flags qui ne peuvent pas être définies à l'avance. Par exemple, la complétion des noms des releases Helm actuellement disponibles sur le cluster. Pour que le plugin supporte la complétion dynamique, il doit fournir un fichier **exécutable** appelé `plugin.complete` dans son répertoire racine. Lorsque le script de complétion de Helm nécessite des complétions dynamiques pour le plugin, il exécutera le fichier `plugin.complete`, en lui passant la ligne de commande qui doit être complétée. L'exécutable `plugin.complete` devra avoir la logique pour déterminer quels sont les choix de complétion appropriés et les afficher sur la sortie standard pour être consommés par le script de complétion de Helm. Le fichier `plugin.complete` est entièrement optionnel. S'il n'est pas fourni, Helm ne fournira simplement pas d'auto-complétion dynamique pour le plugin. De plus, l'ajout d'un fichier `plugin.complete` est rétro-compatible et n'impactera pas le comportement du plugin lors de l'utilisation de versions plus anciennes de Helm. La sortie du script `plugin.complete` doit être une liste séparée par des sauts de ligne telle que : ```console rel1 rel2 rel3 ``` Lorsque `plugin.complete` est appelé, l'environnement du plugin est défini exactement comme lorsque le script principal du plugin est appelé. Par conséquent, les variables `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` et toutes les autres variables de plugin seront déjà définies, et leurs flags globaux correspondants auront été supprimés. Le fichier `plugin.complete` peut être sous n'importe quelle forme exécutable ; ce peut être un script shell, un programme Go, ou tout autre type de programme que Helm peut exécuter. Le fichier `plugin.complete` ***doit*** avoir les permissions d'exécution pour l'utilisateur. Le fichier `plugin.complete` ***doit*** se terminer avec un code de succès (valeur 0). Dans certains cas, la complétion dynamique nécessitera d'obtenir des informations du cluster Kubernetes. Par exemple, le plugin `helm fullstatus` nécessite un nom de release en entrée. Dans le plugin `fullstatus`, pour que son script `plugin.complete` fournisse la complétion pour les noms de release actuels, il peut simplement exécuter `helm list -q` et afficher le résultat. Si vous souhaitez utiliser le même exécutable pour l'exécution du plugin et pour la complétion du plugin, le script `plugin.complete` peut être fait pour appeler l'exécutable principal du plugin avec un paramètre ou flag spécial ; lorsque l'exécutable principal du plugin détecte le paramètre ou flag spécial, il saura qu'il doit exécuter la complétion. Dans notre exemple, `plugin.complete` pourrait être implémenté ainsi : ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Le vrai script du plugin `fullstatus` (`status.sh`) doit alors rechercher le flag `--complete` et si trouvé, afficher les complétions appropriées. ### Astuces et conseils 1. Le shell filtrera automatiquement les choix de complétion qui ne correspondent pas à l'entrée de l'utilisateur. Un plugin peut donc retourner toutes les complétions pertinentes sans supprimer celles qui ne correspondent pas à l'entrée de l'utilisateur. Par exemple, si la ligne de commande est `helm fullstatus ngin`, le script `plugin.complete` peut afficher *tous* les noms de release (du namespace `default`), pas seulement ceux commençant par `ngin` ; le shell ne conservera que ceux commençant par `ngin`. 1. Pour simplifier le support de la complétion dynamique, surtout si vous avez un plugin complexe, vous pouvez faire en sorte que votre script `plugin.complete` appelle votre script principal du plugin et demande les choix de complétion. Voir la section [Complétion dynamique](#complétion-dynamique) ci-dessus pour un exemple. 1. Pour déboguer la complétion dynamique et le fichier `plugin.complete`, vous pouvez exécuter ce qui suit pour voir les résultats de complétion : - `helm __complete `. Par exemple : - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Provenance et intégrité dans Helm description: Décrit comment vérifier l'intégrité et l'origine d'un Chart. sidebar_position: 5 --- Helm dispose d'outils de provenance qui aident les utilisateurs de charts à vérifier l'intégrité et l'origine d'un package. Basé sur des outils standard de l'industrie comme PKI, GnuPG et des gestionnaires de paquets reconnus, Helm peut générer et vérifier des fichiers de signature. ## Vue d'ensemble L'intégrité est établie en comparant un chart à un enregistrement de provenance. Ces enregistrements sont stockés dans des _fichiers de provenance_, conservés aux côtés du chart packageé. Par exemple, si un chart est nommé `myapp-1.2.3.tgz`, son fichier de provenance sera `myapp-1.2.3.tgz.prov`. Les fichiers de provenance sont générés lors du packaging (`helm package --sign ...`) et peuvent être vérifiés par plusieurs commandes, notamment `helm install --verify`. ## Le flux de travail Cette section décrit un flux de travail possible pour utiliser efficacement les données de provenance. Prérequis : - Une paire de clés PGP valide au format binaire (pas au format ASCII-armored) - L'outil en ligne de commande `helm` - Les outils en ligne de commande GnuPG (optionnel) - Les outils en ligne de commande Keybase (optionnel) **NOTE :** Si votre clé privée PGP possède une phrase de passe, vous serez invité à la saisir pour toute commande prenant en charge l'option `--sign`. La création d'un nouveau chart se fait comme d'habitude : ```console $ helm create mychart Creating mychart ``` Lorsque vous êtes prêt à packager, ajoutez le drapeau `--sign` à `helm package`. Spécifiez également le nom sous lequel la clé de signature est connue ainsi que le trousseau de clés contenant la clé privée correspondante : ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Note :** La valeur de l'argument `--key` doit être une sous-chaîne de l'`uid` de la clé souhaitée (tel qu'affiché par `gpg --list-keys`), par exemple le nom ou l'email. **L'empreinte _ne peut pas_ être utilisée.** **ASTUCE :** Pour les utilisateurs de GnuPG, votre trousseau de clés secrètes se trouve dans `~/.gnupg/secring.gpg`. Utilisez `gpg --list-secret-keys` pour lister vos clés disponibles. **Attention :** GnuPG v2 stocke votre trousseau de clés secrètes dans un nouveau format `kbx` à l'emplacement par défaut `~/.gnupg/pubring.kbx`. Utilisez la commande suivante pour convertir votre trousseau au format gpg historique : ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` À ce stade, vous devriez voir à la fois `mychart-0.1.0.tgz` et `mychart-0.1.0.tgz.prov`. Ces deux fichiers doivent ensuite être téléversés vers votre dépôt de charts. Vous pouvez vérifier un chart avec `helm verify` : ```console $ helm verify mychart-0.1.0.tgz ``` Une vérification échouée ressemble à ceci : ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Pour vérifier lors d'une installation, utilisez le drapeau `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Si le trousseau de clés contenant la clé publique associée au chart signé n'est pas à l'emplacement par défaut, vous devrez peut-être indiquer le trousseau avec `--keyring PATH` comme dans l'exemple `helm package`. Si la vérification échoue, l'installation sera annulée avant même que le chart ne soit rendu. ### Utiliser les identifiants Keybase.io Le service [Keybase.io](https://keybase.io) facilite l'établissement d'une chaîne de confiance pour une identité cryptographique. Les identifiants Keybase peuvent être utilisés pour signer des charts. Prérequis : - Un compte Keybase.io configuré - GnuPG installé localement - La CLI `keybase` installée localement #### Signer des packages La première étape consiste à importer vos clés Keybase dans votre trousseau GnuPG local : ```console $ keybase pgp export -s | gpg --import ``` Cela convertira votre clé Keybase au format OpenPGP, puis l'importera localement dans votre fichier `~/.gnupg/secring.gpg`. Vous pouvez vérifier en exécutant `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Notez que votre clé secrète possède une chaîne d'identification : ``` technosophos (keybase.io/technosophos) ``` C'est le nom complet de votre clé. Ensuite, vous pouvez packager et signer un chart avec `helm package`. Assurez-vous d'utiliser au moins une partie de cette chaîne de nom dans `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` En résultat, la commande `package` produira à la fois un fichier `.tgz` et un fichier `.tgz.prov`. #### Vérifier des packages Vous pouvez également utiliser une technique similaire pour vérifier un chart signé avec la clé Keybase d'une autre personne. Supposons que vous souhaitiez vérifier un package signé par `keybase.io/technosophos`. Utilisez l'outil `keybase` : ```console $ keybase follow technosophos $ keybase pgp pull ``` La première commande suit l'utilisateur `technosophos`. Ensuite, `keybase pgp pull` télécharge les clés OpenPGP de tous les comptes que vous suivez et les place dans votre trousseau GnuPG (`~/.gnupg/pubring.gpg`). À ce stade, vous pouvez utiliser `helm verify` ou n'importe quelle commande avec le drapeau `--verify` : ```console $ helm verify somechart-1.2.3.tgz ``` ### Raisons pour lesquelles un chart peut ne pas être vérifié Voici les raisons courantes d'échec. - Le fichier `.prov` est manquant ou corrompu. Cela indique que quelque chose est mal configuré ou que le mainteneur original n'a pas créé de fichier de provenance. - La clé utilisée pour signer le fichier n'est pas dans votre trousseau. Cela indique que l'entité qui a signé le chart n'est pas quelqu'un en qui vous avez déjà indiqué avoir confiance. - La vérification du fichier `.prov` a échoué. Cela indique un problème avec le chart ou les données de provenance. - Les hachages de fichiers dans le fichier de provenance ne correspondent pas au hachage du fichier d'archive. Cela indique que l'archive a été altérée. Si une vérification échoue, il convient de se méfier du package. ## Le fichier de provenance Le fichier de provenance contient le fichier YAML du chart ainsi que plusieurs informations de vérification. Les fichiers de provenance sont conçus pour être générés automatiquement. Les données de provenance suivantes sont ajoutées : * Le fichier du chart (`Chart.yaml`) est inclus pour donner aux humains et aux outils une vue claire du contenu du chart. * La signature (SHA256, comme Docker) du package du chart (le fichier `.tgz`) est incluse et peut être utilisée pour vérifier l'intégrité du package. * L'ensemble du corps est signé avec l'algorithme utilisé par OpenPGP (voir [Keybase.io](https://keybase.io) pour une méthode émergente de signature et de vérification cryptographiques simplifiées). Cette combinaison donne aux utilisateurs les assurances suivantes : * Le package lui-même n'a pas été altéré (somme de contrôle du package `.tgz`). * L'entité qui a publié ce package est connue (via la signature GnuPG/PGP). Le format du fichier ressemble à ceci : ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Notez que la section YAML contient deux documents (séparés par `...\n`). Le premier est le contenu de `Chart.yaml`. Le second contient les sommes de contrôle : une correspondance entre les noms de fichiers et les condensés SHA-256 du contenu de chaque fichier au moment du packaging. Le bloc de signature est une signature PGP standard, qui fournit une [résistance à l'altération](https://www.rossde.com/PGP/pgp_signatures.html). ## Dépôts de charts Les dépôts de charts constituent une collection centralisée de charts Helm. Les dépôts de charts doivent permettre de servir les fichiers de provenance via HTTP par une requête spécifique, et doivent les rendre disponibles au même chemin URI que le chart. Par exemple, si l'URL de base d'un package est `https://example.com/charts/mychart-1.2.3.tgz`, le fichier de provenance, s'il existe, DOIT être accessible à `https://example.com/charts/mychart-1.2.3.tgz.prov`. Du point de vue de l'utilisateur final, `helm install --verify myrepo/mychart-1.2.3` doit entraîner le téléchargement du chart et du fichier de provenance sans configuration ni action supplémentaire de l'utilisateur. ### Signatures dans les registres basés sur OCI Lors de la publication de charts vers un [registre basé sur OCI](/topics/registries.md), le [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) peut être utilisé pour publier la provenance sur [sigstore](https://sigstore.dev/). [Comme décrit dans la documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), le processus de création de provenance et de signature avec une clé GPG est commun, mais la commande `helm sigstore upload` peut être utilisée pour publier la provenance vers un journal de transparence immuable. ## Établir l'autorité et l'authenticité Dans les systèmes basés sur une chaîne de confiance, il est important de pouvoir établir l'autorité d'un signataire. Autrement dit, le système ci-dessus repose sur le fait que vous faites confiance à la personne qui a signé le chart. Ce qui implique que vous devez faire confiance à la clé publique du signataire. L'une des décisions de conception de Helm a été de ne pas s'insérer dans la chaîne de confiance en tant que partie nécessaire. Nous ne voulons pas être « l'autorité de certification » pour tous les signataires de charts. Nous privilégions un modèle décentralisé, ce qui explique notre choix d'OpenPGP comme technologie de base. Concernant l'établissement de l'autorité, nous avons laissé cette étape relativement indéfinie dans Helm 2 (décision reprise dans Helm 3). Cependant, voici quelques conseils et recommandations pour ceux qui souhaitent utiliser le système de provenance : - La plateforme [Keybase](https://keybase.io) fournit un dépôt public centralisé pour les informations de confiance. - Vous pouvez utiliser Keybase pour stocker vos clés ou obtenir les clés publiques d'autres personnes. - Keybase dispose également d'une excellente documentation. - Bien que nous ne l'ayons pas testé, la fonctionnalité « site web sécurisé » de Keybase pourrait être utilisée pour servir des charts Helm. - L'idée de base est qu'un « réviseur de charts » officiel signe les charts avec sa clé, et le fichier de provenance résultant est ensuite téléversé vers le dépôt de charts. - Des travaux ont été menés sur l'idée qu'une liste de clés de signature valides pourrait être incluse dans le fichier `index.yaml` d'un dépôt. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Contrôle d'accès basé sur les rôles description: Explique comment Helm interagit avec le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. sidebar_position: 11 --- Dans Kubernetes, attribuer des rôles à un utilisateur ou à un compte de service spécifique à une application est une bonne pratique pour garantir que votre application fonctionne dans le périmètre que vous avez défini. Pour en savoir plus sur les permissions des comptes de service, consultez [la documentation officielle de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). Depuis Kubernetes 1.6, le contrôle d'accès basé sur les rôles est activé par défaut. RBAC vous permet de spécifier quels types d'actions sont autorisées en fonction de l'utilisateur et de son rôle dans votre organisation. Avec RBAC, vous pouvez : - accorder des opérations privilégiées (création de ressources à l'échelle du cluster, comme de nouveaux rôles) aux administrateurs - limiter la capacité d'un utilisateur à créer des ressources (Pods, volumes persistants, Deployments) à des namespaces spécifiques, ou à l'échelle du cluster (quotas de ressources, rôles, Custom Resource Definitions) - limiter la capacité d'un utilisateur à visualiser des ressources dans des namespaces spécifiques ou à l'échelle du cluster. Ce guide s'adresse aux administrateurs qui souhaitent restreindre le périmètre d'interaction d'un utilisateur avec l'API Kubernetes. ## Gestion des comptes utilisateurs Tous les clusters Kubernetes disposent de deux catégories d'utilisateurs : les comptes de service gérés par Kubernetes, et les utilisateurs normaux. Les utilisateurs normaux sont supposés être gérés par un service externe indépendant. Il peut s'agir d'un administrateur distribuant des clés privées, d'un annuaire d'utilisateurs comme Keystone ou Google Accounts, voire d'un fichier contenant une liste de noms d'utilisateurs et de mots de passe. À cet égard, Kubernetes ne possède pas d'objets représentant les comptes utilisateurs normaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster via un appel API. En revanche, les comptes de service sont des utilisateurs gérés par l'API Kubernetes. Ils sont liés à des namespaces spécifiques et créés automatiquement par le serveur API ou manuellement via des appels API. Les comptes de service sont associés à un ensemble d'identifiants stockés en tant que Secrets, qui sont montés dans les Pods permettant aux processus du cluster de communiquer avec l'API Kubernetes. Les requêtes API sont liées soit à un utilisateur normal, soit à un compte de service, soit traitées comme des requêtes anonymes. Cela signifie que chaque processus à l'intérieur ou à l'extérieur du cluster, qu'il s'agisse d'un utilisateur humain exécutant `kubectl` sur un poste de travail, des kubelets sur les nœuds, ou des membres du plan de contrôle, doit s'authentifier lors des requêtes au serveur API, sinon il sera traité comme un utilisateur anonyme. ## Roles, ClusterRoles, RoleBindings et ClusterRoleBindings Dans Kubernetes, les comptes utilisateurs et les comptes de service ne peuvent visualiser et modifier que les ressources auxquelles ils ont été autorisés à accéder. Cet accès est accordé via l'utilisation de Roles et de RoleBindings. Les Roles et RoleBindings sont liés à un namespace particulier, ce qui permet aux utilisateurs de visualiser et/ou de modifier les ressources au sein de ce namespace auxquelles le Role leur donne accès. À l'échelle du cluster, on parle de ClusterRoles et de ClusterRoleBindings. Accorder un ClusterRole à un utilisateur lui donne accès à la visualisation et/ou à la modification des ressources sur l'ensemble du cluster. C'est également nécessaire pour visualiser et/ou modifier des ressources à l'échelle du cluster (namespaces, quotas de ressources, nœuds). Les ClusterRoles peuvent être liés à un namespace particulier via une référence dans un RoleBinding. Les ClusterRoles par défaut `admin`, `edit` et `view` sont couramment utilisés de cette manière. Voici quelques ClusterRoles disponibles par défaut dans Kubernetes. Ils sont destinés aux utilisateurs finaux. Ils comprennent des rôles de super-utilisateur (`cluster-admin`), et des rôles avec des accès plus granulaires (`admin`, `edit`, `view`). | ClusterRole par défaut | ClusterRoleBinding par défaut | Description |------------------------|-------------------------------|------------- | `cluster-admin` | groupe `system:masters` | Permet un accès super-utilisateur pour effectuer n'importe quelle action sur n'importe quelle ressource. Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource du cluster et de tous les namespaces. Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource du namespace du RoleBinding, y compris le namespace lui-même. | `admin` | Aucun | Permet un accès administrateur, destiné à être accordé au sein d'un namespace via un RoleBinding. S'il est utilisé dans un RoleBinding, il permet un accès en lecture/écriture à la plupart des ressources d'un namespace, y compris la possibilité de créer des Roles et des RoleBindings au sein du namespace. Il ne permet pas l'accès en écriture aux quotas de ressources ou au namespace lui-même. | `edit` | Aucun | Permet un accès en lecture/écriture à la plupart des objets d'un namespace. Il ne permet pas de visualiser ou de modifier les Roles ou les RoleBindings. | `view` | Aucun | Permet un accès en lecture seule pour voir la plupart des objets d'un namespace. Il ne permet pas de visualiser les Roles ou les RoleBindings. Il ne permet pas de visualiser les Secrets, car cela constituerait une élévation de privilèges. ## Restreindre l'accès d'un compte utilisateur avec RBAC Maintenant que nous comprenons les bases du contrôle d'accès basé sur les rôles, voyons comment un administrateur peut restreindre le périmètre d'accès d'un utilisateur. ### Exemple : Accorder à un utilisateur un accès en lecture/écriture à un namespace particulier Pour restreindre l'accès d'un utilisateur à un namespace particulier, nous pouvons utiliser soit le rôle `edit`, soit le rôle `admin`. Si vos charts créent ou interagissent avec des Roles et des RoleBindings, vous devrez utiliser le ClusterRole `admin`. De plus, vous pouvez également créer un RoleBinding avec un accès `cluster-admin`. Accorder à un utilisateur l'accès `cluster-admin` au niveau d'un namespace lui donne un contrôle total sur chaque ressource du namespace, y compris le namespace lui-même. Pour cet exemple, nous allons créer un utilisateur avec le Role `edit`. Tout d'abord, créez le namespace : ```console $ kubectl create namespace foo ``` Ensuite, créez un RoleBinding dans ce namespace, accordant à l'utilisateur le rôle `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Exemple : Accorder à un utilisateur un accès en lecture/écriture à l'échelle du cluster Si un utilisateur souhaite installer un chart qui installe des ressources à l'échelle du cluster (namespaces, rôles, Custom Resource Definitions, etc.), il aura besoin d'un accès en écriture à l'échelle du cluster. Pour cela, accordez à l'utilisateur l'accès `admin` ou `cluster-admin`. Accorder à un utilisateur l'accès `cluster-admin` lui donne accès à absolument toutes les ressources disponibles dans Kubernetes, y compris l'accès aux nœuds avec `kubectl drain` et d'autres tâches administratives. Il est fortement recommandé d'envisager de fournir à l'utilisateur l'accès `admin` à la place, ou de créer un ClusterRole personnalisé adapté à ses besoins. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Exemple : Accorder à un utilisateur un accès en lecture seule à un namespace particulier Vous avez peut-être remarqué qu'il n'existe pas de ClusterRole permettant de visualiser les Secrets. Le ClusterRole `view` n'accorde pas l'accès en lecture aux Secrets car cela permettrait une élévation de privilèges. Helm stocke les métadonnées des releases en tant que Secrets par défaut. Pour qu'un utilisateur puisse exécuter `helm list`, il doit pouvoir lire ces Secrets. Pour cela, nous allons créer un ClusterRole spécial `secret-reader`. Créez le fichier `cluster-role-secret-reader.yaml` et écrivez le contenu suivant dans le fichier : ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Ensuite, créez le ClusterRole avec la commande : ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Une fois cela fait, nous pouvons accorder à un utilisateur un accès en lecture à la plupart des ressources, puis lui accorder un accès en lecture aux Secrets : ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Exemple : Accorder à un utilisateur un accès en lecture seule à l'échelle du cluster Dans certains scénarios, il peut être utile d'accorder à un utilisateur un accès à l'échelle du cluster. Par exemple, si un utilisateur souhaite exécuter la commande `helm list --all-namespaces`, l'API exige que l'utilisateur dispose d'un accès en lecture à l'échelle du cluster. Pour cela, accordez à l'utilisateur les accès `view` et `secret-reader` comme décrit ci-dessus, mais avec un ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Réflexions supplémentaires Les exemples présentés ci-dessus utilisent les ClusterRoles par défaut fournis avec Kubernetes. Pour un contrôle plus fin sur les ressources auxquelles les utilisateurs ont accès, consultez [la documentation Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sur la création de vos propres Roles et ClusterRoles personnalisés. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Utiliser des registres basés sur OCI description: Décrit comment utiliser OCI pour la distribution de charts. sidebar_position: 7 --- À partir de Helm 3, vous pouvez utiliser des registres de conteneurs compatibles [OCI](https://www.opencontainers.org/) pour stocker et partager des packages de charts. À partir de Helm v3.8.0, le support OCI est activé par défaut. ## Support OCI avant la version v3.8.0 Le support OCI est passé du statut expérimental à la disponibilité générale avec Helm v3.8.0. Dans les versions antérieures de Helm, le support OCI fonctionnait différemment. Si vous utilisiez le support OCI avant Helm v3.8.0, il est important de comprendre ce qui a changé selon les versions de Helm. ### Activer le support OCI avant la version v3.8.0 Avant Helm v3.8.0, le support OCI est *expérimental* et doit être activé manuellement. Pour activer le support OCI expérimental pour les versions de Helm antérieures à v3.8.0, définissez `HELM_EXPERIMENTAL_OCI` dans votre environnement. Par exemple : ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Dépréciation de fonctionnalités OCI et changements de comportement avec la v3.8.0 Avec la release de [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), les fonctionnalités et comportements suivants diffèrent des versions précédentes de Helm : - Lors de la définition d'un chart dans les dépendances en tant qu'OCI, la version peut être définie comme une plage, comme pour les autres dépendances. - Les tags SemVer incluant des informations de build peuvent être poussés et utilisés. Les registres OCI ne supportent pas le caractère `+` dans les tags. Helm convertit le `+` en `_` lors du stockage en tant que tag. - La commande `helm registry login` suit désormais la même structure que la CLI Docker pour le stockage des identifiants. Le même emplacement de configuration de registre peut être utilisé à la fois par Helm et par la CLI Docker. ### Dépréciation de fonctionnalités OCI et changements de comportement avec la v3.7.0 Avec la release de [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0), l'implémentation de [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) pour le support OCI a été incluse. En conséquence, les fonctionnalités et comportements suivants diffèrent des versions précédentes de Helm : - La sous-commande `helm chart` a été supprimée. - Le cache de charts a été supprimé (plus de `helm chart list`, etc.). - Les références aux registres OCI sont désormais toujours préfixées par `oci://`. - Le nom de base de la référence au registre doit *toujours* correspondre au nom du chart. - Le tag de la référence au registre doit *toujours* correspondre à la version sémantique du chart (c'est-à-dire pas de tags `latest`). - Le type de média de la couche du chart a été modifié de `application/tar+gzip` à `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Utiliser un registre basé sur OCI ### Dépôts Helm dans des registres basés sur OCI Un [dépôt Helm](/topics/chart_repository.md) est un moyen d'héberger et de distribuer des charts Helm packagés. Un registre basé sur OCI peut contenir zéro ou plusieurs dépôts Helm, et chacun de ces dépôts peut contenir zéro ou plusieurs charts Helm packagés. ### Utiliser des registres hébergés Il existe plusieurs registres de conteneurs hébergés avec support OCI que vous pouvez utiliser pour vos charts Helm. Par exemple : - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Consultez la documentation de votre fournisseur de registre de conteneurs hébergé pour créer et configurer un registre compatible OCI. **Note :** Vous pouvez exécuter [Docker Registry](https://docs.docker.com/registry/deploying/) ou [`zot`](https://github.com/project-zot/zot), qui sont des registres basés sur OCI, sur votre poste de développement. L'exécution d'un registre basé sur OCI sur votre poste de développement ne devrait être utilisée qu'à des fins de test. ### Utiliser Sigstore pour signer des charts basés sur OCI Le plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permet d'utiliser [Sigstore](https://sigstore.dev/) pour signer des charts Helm avec les mêmes outils utilisés pour signer des images de conteneurs. Cela offre une alternative à la [provenance basée sur GPG](/topics/provenance.md) supportée par les [dépôts de charts](/topics/chart_repository.md) classiques. Pour plus de détails sur l'utilisation du plugin `helm sigstore`, consultez [la documentation de ce projet](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Commandes pour travailler avec les registres ### La sous-commande `registry` #### `login` Se connecter à un registre (avec saisie manuelle du mot de passe) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` Se déconnecter d'un registre ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### La sous-commande `push` Téléverser un chart vers un registre basé sur OCI : ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` La sous-commande `push` s'utilise uniquement avec des fichiers `.tgz` créés au préalable avec `helm package`. Lors de l'utilisation de `helm push` pour téléverser un chart vers un registre OCI, la référence doit être préfixée par `oci://` et ne doit pas contenir le nom de base ni le tag. Le nom de base de la référence au registre est déduit du nom du chart, et le tag est déduit de la version sémantique du chart. Il s'agit actuellement d'une exigence stricte. Certains registres nécessitent que le dépôt et/ou le namespace (si spécifié) soient créés au préalable. Sinon, une erreur sera produite lors de l'opération `helm push`. Si vous avez créé un [fichier de provenance](/topics/provenance.md) (`.prov`) et qu'il est présent à côté du fichier `.tgz` du chart, il sera automatiquement téléversé vers le registre lors du `push`. Cela ajoute une couche supplémentaire au [manifeste du chart Helm](#manifeste-du-chart-helm). Les utilisateurs du [plugin helm-push](https://github.com/chartmuseum/helm-push) (pour téléverser des charts vers [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) peuvent rencontrer des problèmes, car le plugin entre en conflit avec la nouvelle commande `push` intégrée. À partir de la version v0.10.0, le plugin a été renommé en `cm-push`. ### Autres sous-commandes Le support du protocole `oci://` est également disponible dans plusieurs autres sous-commandes. Voici la liste complète : - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Le nom de base (nom du chart) de la référence au registre *est* inclus pour tout type d'action impliquant le téléchargement d'un chart (contrairement à `helm push` où il est omis). Voici quelques exemples d'utilisation des sous-commandes listées ci-dessus avec des charts basés sur OCI : ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Installer des charts avec un digest Installer un chart avec un digest est plus sécurisé qu'avec un tag car les digests sont immuables. Le digest est spécifié dans l'URI du chart : ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Spécifier les dépendances Les dépendances d'un chart peuvent être récupérées depuis un registre en utilisant la sous-commande `dependency update`. Le `repository` pour une entrée donnée dans `Chart.yaml` est spécifié comme la référence au registre sans le nom de base : ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Cela récupérera `oci://localhost:5000/myrepo/mychart:2.7.0` lors de l'exécution de `dependency update`. ## Manifeste du chart Helm Exemple de manifeste de chart Helm tel que représenté dans un registre (remarquez les champs `mediaType`) : ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` L'exemple suivant contient un [fichier de provenance](/topics/provenance.md) (notez la couche supplémentaire) : ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migration depuis des dépôts de charts La migration depuis des [dépôts de charts](/topics/chart_repository.md) classiques (dépôts basés sur index.yaml) est aussi simple que d'utiliser `helm pull`, puis `helm push` pour téléverser les fichiers `.tgz` résultants vers un registre. ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Migration de Helm v2 vers v3 description: Apprenez comment migrer Helm v2 vers v3. sidebar_position: 13 --- Ce guide explique comment migrer de Helm v2 vers v3. Helm v2 doit être installé et gérer des releases dans un ou plusieurs clusters. ## Aperçu des changements dans Helm 3 La liste complète des changements entre Helm 2 et 3 est documentée dans la [section FAQ](/faq/changes_since_helm2.md). Voici un résumé des changements qu'un utilisateur devrait connaître avant et pendant la migration : 1. Suppression de Tiller : - Remplacement de l'architecture client/serveur par une architecture client/bibliothèque (binaire `helm` uniquement) - La sécurité est désormais gérée par utilisateur (déléguée à la sécurité du cluster Kubernetes) - Les releases sont maintenant stockées en tant que secrets dans le cluster et les métadonnées de l'objet release ont changé - Les releases sont persistées par namespace et non plus dans le namespace Tiller 2. Mise à jour du dépôt de charts : - `helm search` prend désormais en charge les recherches dans les dépôts locaux ainsi que les requêtes de recherche sur Artifact Hub 3. Passage de l'apiVersion des charts à "v2" pour les changements de spécification suivants : - Les dépendances de charts liées dynamiquement ont été déplacées vers `Chart.yaml` (`requirements.yaml` supprimé et requirements --> dependencies) - Les charts de type bibliothèque (helper/common charts) peuvent maintenant être ajoutés comme dépendances de charts liées dynamiquement - Les charts ont un champ de métadonnées `type` pour définir le chart comme étant de type `application` ou `library`. Par défaut, il est de type application, ce qui signifie qu'il est rendu et installable - Les charts Helm 2 (apiVersion=v1) sont toujours installables 4. Ajout de la spécification des répertoires XDG : - Helm home supprimé et remplacé par la spécification des répertoires XDG pour le stockage des fichiers de configuration - Plus besoin d'initialiser Helm - `helm init` et `helm home` supprimés 5. Changements supplémentaires : - L'installation/configuration de Helm est simplifiée : - Client Helm (binaire helm) uniquement (pas de Tiller) - Fonctionne immédiatement - Les dépôts `local` ou `stable` ne sont plus configurés par défaut - Le hook `crd-install` est supprimé et remplacé par le répertoire `crds` dans le chart où tous les CRDs définis seront installés avant le rendu du chart - La valeur d'annotation de hook `test-failure` est supprimée, et `test-success` est dépréciée. Utilisez `test` à la place - Commandes supprimées/remplacées/ajoutées : - delete --> uninstall : supprime tout l'historique des releases par défaut (auparavant nécessitait `--purge`) - fetch --> pull - home (supprimé) - init (supprimé) - install : nécessite un nom de release ou l'argument `--generate-name` - inspect --> show - reset (supprimé) - serve (supprimé) - template : l'argument `-x`/`--execute` renommé en `-s`/`--show-only` - upgrade : ajout de l'argument `--history-max` qui limite le nombre maximum de révisions sauvegardées par release (0 pour aucune limite) - La bibliothèque Go de Helm 3 a subi de nombreux changements et est incompatible avec la bibliothèque Helm 2 - Les binaires de release sont maintenant hébergés sur `get.helm.sh` ## Cas d'utilisation de la migration Les cas d'utilisation de la migration sont les suivants : 1. Helm v2 et v3 gérant le même cluster : - Ce cas d'utilisation est recommandé uniquement si vous avez l'intention de supprimer progressivement Helm v2 et que vous n'avez pas besoin que v3 gère les releases déployées par v2. Toutes les nouvelles releases doivent être déployées par v3 et les releases existantes déployées par v2 sont mises à jour/supprimées uniquement par v2 - Helm v2 et v3 peuvent parfaitement gérer le même cluster. Les versions de Helm peuvent être installées sur le même système ou sur des systèmes séparés - Si vous installez Helm v3 sur le même système, vous devez effectuer une étape supplémentaire pour vous assurer que les deux versions du client peuvent coexister jusqu'à ce que vous soyez prêt à supprimer le client Helm v2. Renommez ou placez le binaire Helm v3 dans un dossier différent pour éviter tout conflit - Sinon, il n'y a pas de conflits entre les deux versions grâce aux distinctions suivantes : - Le stockage des releases (historique) de v2 et v3 est indépendant. Les changements incluent la ressource Kubernetes pour le stockage et les métadonnées de l'objet release contenues dans la ressource. Les releases seront également sur une base de namespace par utilisateur au lieu d'utiliser le namespace Tiller (par exemple, le namespace Tiller par défaut de v2 est kube-system). v2 utilise "ConfigMaps" ou "Secrets" sous le namespace Tiller et la propriété `TILLER`. v3 utilise "Secrets" dans le namespace utilisateur et la propriété `helm`. Les releases sont incrémentales dans v2 et v3 - Le seul problème pourrait survenir si des ressources Kubernetes à portée de cluster (par exemple `clusterroles.rbac`) sont définies dans un chart. Le déploiement v3 échouerait alors même si le namespace est unique car les ressources entreraient en conflit - La configuration v3 n'utilise plus `$HELM_HOME` et utilise à la place la spécification des répertoires XDG. Elle est également créée à la volée selon les besoins. Elle est donc indépendante de la configuration v2. Ceci s'applique uniquement lorsque les deux versions sont installées sur le même système 2. Migration de Helm v2 vers Helm v3 : - Ce cas d'utilisation s'applique lorsque vous souhaitez que Helm v3 gère les releases Helm v2 existantes - Il faut noter qu'un client Helm v2 : - peut gérer 1 à plusieurs clusters Kubernetes - peut se connecter à 1 à plusieurs instances Tiller pour un cluster - Ceci implique que vous devez en tenir compte lors de la migration car les releases sont déployées dans les clusters par Tiller et son namespace. Vous devez donc prendre en compte la migration pour chaque cluster et chaque instance Tiller gérée par l'instance du client Helm v2 - Le chemin de migration de données recommandé est le suivant : 1. Sauvegarder les données v2 2. Migrer la configuration Helm v2 3. Migrer les releases Helm v2 4. Lorsque vous êtes confiant que Helm v3 gère toutes les données Helm v2 (pour tous les clusters et instances Tiller de l'instance du client Helm v2) comme prévu, procédez au nettoyage des données Helm v2 - Le processus de migration est automatisé par le plugin Helm v3 [2to3](https://github.com/helm/helm-2to3) ## Références - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3) - [Article de blog](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) expliquant l'utilisation du plugin `2to3` avec des exemples ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Politique de Prise en Charge des Versions Helm" description: "Décrit la politique de publication des correctifs de Helm ainsi que le décalage de version maximal pris en charge entre Helm et Kubernetes." --- Ce document décrit le décalage de version maximal pris en charge entre Helm et Kubernetes. ## Versions Prises en Charge Les versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version majeure, `y` est la version mineure et `z` est la version de correctif, suivant la terminologie du [Versionnement Sémantique](https://semver.org/spec/v2.0.0.html). Le projet Helm maintient une branche de release pour la version mineure la plus récente. Les correctifs applicables, y compris les correctifs de sécurité, sont intégrés à la branche de release, en fonction de la gravité et de la faisabilité. Plus de détails sont disponibles dans la [politique de publication de Helm](/community/release_policy). ## Décalage de Version Pris en Charge Lorsqu'une nouvelle version de Helm est publiée, elle est compilée pour une version mineure particulière de Kubernetes. Par exemple, Helm 3.0.0 interagit avec Kubernetes en utilisant le client Kubernetes 1.16.2, et est donc compatible avec Kubernetes 1.16. À partir de Helm 3, Helm est considéré comme compatible avec les versions `n-3` de Kubernetes pour lesquelles il a été compilé. En raison des changements apportés par Kubernetes entre les versions mineures, la politique de prise en charge de Helm 2 est légèrement plus stricte, prenant en charge les versions `n-1` de Kubernetes. Par exemple, si vous utilisez une version de Helm 3 compilée avec les API du client Kubernetes 1.17, vous pouvez l'utiliser en toute sécurité avec Kubernetes 1.17, 1.16, 1.15 et 1.14. Si vous utilisez une version de Helm 2 compilée avec les API du client Kubernetes 1.16, vous pouvez l'utiliser en toute sécurité avec Kubernetes 1.16 et 1.15. Il n'est pas recommandé d'utiliser Helm avec une version de Kubernetes plus récente que celle pour laquelle il a été compilé, car Helm ne garantit pas la compatibilité ascendante. Si vous choisissez d'utiliser Helm avec une version de Kubernetes non prise en charge, vous le faites à vos propres risques. Veuillez consulter le tableau ci-dessous pour déterminer quelle version de Helm est compatible avec votre cluster. | Version Helm | Versions Kubernetes Prises en Charge | |--------------|--------------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Introduction", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Comment faire", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Sujets", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Meilleures Pratiques", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Guide des Templates de Chart", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Commandes Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Communauté", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Questions Fréquemment Posées", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/fr/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Politique de planification des releases" description: "Décrit la politique de planification des releases de Helm." --- Dans l'intérêt de ses utilisateurs, Helm définit et annonce les dates de release à l'avance. Ce document décrit la politique régissant la planification des releases de Helm. ## Calendrier des releases Un calendrier public indiquant les prochaines releases de Helm est disponible [ici](https://helm.sh/calendar/release). ## Versionnement sémantique Les versions de Helm sont exprimées sous la forme `x.y.z`, où `x` est la version majeure, `y` est la version mineure et `z` est la version de correctif, suivant la terminologie du [Versionnement Sémantique](https://semver.org/spec/v2.0.0.html). ## Releases de correctifs Les releases de correctifs fournissent aux utilisateurs des corrections de bugs et des correctifs de sécurité. Elles ne contiennent pas de nouvelles fonctionnalités. Une nouvelle release de correctif relative à la dernière version mineure/majeure est normalement effectuée une fois par mois, le deuxième mercredi de chaque mois. Une release de correctif pour résoudre une régression de haute priorité ou un problème de sécurité peut être effectuée à tout moment si nécessaire. Une release de correctif sera annulée pour l'une des raisons suivantes : - s'il n'y a pas de nouveau contenu depuis la release précédente - si la date de la release de correctif tombe dans la semaine précédant la première release candidate (RC1) d'une prochaine version mineure - si la date de la release de correctif tombe dans les quatre semaines suivant une release mineure ## Releases mineures Les releases mineures contiennent des correctifs de sécurité, des corrections de bugs ainsi que de nouvelles fonctionnalités. Elles sont rétrocompatibles en ce qui concerne l'API et l'utilisation de la CLI. Pour s'aligner sur les releases de Kubernetes, une release mineure de Helm est effectuée tous les 4 mois (3 releases par an). Des releases mineures supplémentaires peuvent être effectuées si nécessaire, mais n'affecteront pas le calendrier d'une release future annoncée, sauf si celle-ci est prévue dans moins de 7 jours. Au moment de la publication d'une release, la date de la prochaine release mineure sera annoncée et publiée sur la page principale du site web de Helm. ## Releases majeures Les releases majeures contiennent des changements non rétrocompatibles. Ces releases sont rares mais parfois nécessaires pour permettre à Helm de continuer à évoluer dans de nouvelles directions importantes. Les releases majeures peuvent être difficiles à planifier. Dans cet esprit, une date de release finale ne sera choisie et annoncée qu'une fois la première version bêta d'une telle release disponible. ================================================ FILE: i18n/fr/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Projet Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Développement", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Communauté", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Code source", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Blog", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Événements", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Code de Conduite", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Introduction", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Conseils et astuces pour Charts", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Développer des Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Rechercher 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Guide de Contribution", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Mainteneurs", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Réunions Hebdomadaires", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Communauté GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Nous sommes un projet diplômé de la Cloud Native Computing Foundation.
© Auteurs de Helm 2025. Documentation distribuée sous CC-BY-4.0.
© 2025 The Linux Foundation. Tous droits réservés. The Linux Foundation possède des marques déposées et utilise des marques commerciales. Pour une liste des marques commerciales de The Linux Foundation, veuillez consulter notre page d'utilisation des marques.", "description": "The footer copyright" }, "logo.alt": { "message": "Logo CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/fr/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Logo Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Documentation", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Blog", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Communauté", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/it/code.json ================================================ { "home.community.nextFeatureRelease": { "message": "Prossima versione", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "v4.0.0", "description": "Next Feature Release version" }, "home.community.nextFeatureRelease.calendar": { "message": "Calendario Rilasci", "description": "Release Calendar link" }, "home.community.events": { "message": "Eventi", "description": "Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Prossimi eventi", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Eventi Passati", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "Ci si {meetLink} per mostrare e discutere strumenti e progetti. Gli incontri della comunità vengono registrati e {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "incontra ogni settimana", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "condivisi su YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Developer Standups" }, "home.community.developerStandups.time": { "message": "Giovedì dalle 9:30 alle 10:00 (ora del Pacifico)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Questi incontri sono aperti a tutti. Controlla {communityRepoLink} per note e dettagli.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "community repo", "description": "Community repo link" }, "home.community.slack.join": { "message": "{slackLink} per entrare nel team Kubernetes Slack.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Richiedi accesso qui", "description": "Request access to slack link" }, "home.community.slack.helmUsers.description": { "message": "Discussione sull'uso di Helm, sul lavoro con i charts e sulla risoluzione degli errori più comuni.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Argomenti relativi allo sviluppo di Helm, PR in corso, rilasci, ecc.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Discussione per utenti e collaboratori di Helm Charts.", "description": "charts slack channel description" }, "home.community.contributing": { "message": "Contribuire", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm accoglie sempre con favore nuovi contributi al progetto!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "Da dove iniziare?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm è un progetto di grandi dimensioni con molti utenti e collaboratori. Può essere difficile da comprendere appieno!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Abbiamo un elenco di {goodFirstIssuesLink} se desideri dare una mano ma non sai da dove iniziare.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "good first issues", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Cosa devo fare?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Prima di contribuire con del codice, leggi la nostra {contributionGuideLink}. Descrive le procedure relative alla creazione e alla revisione delle richieste pull.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Guida al contributo", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Dopo aver scritto del codice, ti preghiamo di {signYourCommitsLink} per garantire che Helm rispetti l'accordo {dcoLink} utilizzato da {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "firmare il tuo commit", "description": "Sign your commits link" }, "home.community.title": { "message": "Entra nella Community", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Maggiori informazioni sul progetto Helm e su come contribuire.", "description": "Join the Community subtitle" }, "home.features.manageComplexity": { "message": "Gestire la complessità", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "I chart descrivono anche le app più complesse, consentono un'installazione ripetibile delle applicazioni e fungono da unico punto di riferimento autorevole.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Aggiornamenti facili", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Elimina il fastidio degli aggiornamenti con aggiornamenti in loco e hook personalizzati.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Condivisione semplice", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "I chart sono facili da versionare, condividere e ospitare su server pubblici o privati.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Rollbacks", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Utilizza {helmRollback} per ripristinare facilmente una versione precedente di una release.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Features", "description": "Features section title" }, "home.gettingStarted.title": { "message": "Per iniziare", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Ottieni Helm", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Installa Helm con un gestore di pacchetti o {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "scarica un binario", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Una volta installato, decomprimi il file binario helm e aggiungilo al tuo PATH e sei pronto per partire! Controlla {docsLink} per ulteriori {installationLink} e {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "docs", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "installazione", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "istruzioni d'utilizzo", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Ottieni Charts", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Visita {artifactHubLink} per esplorare {helmChartsLink} da numerosi repository pubblici.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "home.about.whatIsHelm": { "message": "Helm ti aiuta a gestire le applicazioni Kubernetes: gli Helm Charts ti aiutano a definire, installare e aggiornare anche le applicazioni Kubernetes più complesse.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "I chart sono facili da creare, aggiornare, condividere e pubblicare: inizia a usare Helm e smetti di copiare e incollare.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm è un graduated project del {cncfLink} ed è mantenuto dalla {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "community Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Per saperne di più:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Architettura di Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Guida rapida", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Video: Introduzione a Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Che cos'è Helm?", "description": "What is Helm? title" }, "home.header.tagline": { "message": "Il package manager per Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm è il modo migliore per trovare, condividere e utilizzare software creato per", "description": "Home page header subtitle" }, "home.support.title": { "message": "Supporters", "description": "Community support section title" }, "home.support.subtitle": { "message": "Helm è supportato e sviluppato da una comunità di oltre 400 sviluppatori.", "description": "Community support section subtitle" }, "home.support.maintainers": { "message": "...e {maintainersLink}.", "description": "Link to core maintainers" }, "home.support.maintainersLink": { "message": "molti altri meravigliosi manutentori del core di Helm", "description": "Core maintainers link text" }, "theme.docs.breadcrumbs.home": { "message": "Pagina principale", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.blog.list.pageTitle": { "message": "Blog", "description": "The word \"Blog\" in breadcrumbs" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Breadcrumbs", "description": "The ARIA label for the breadcrumbs" }, "theme.blog.sidebar.navAriaLabel": { "message": "Navigazione dei post recenti del blog", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Su questa pagina", "description": "The label used by the button on the collapsible TOC component" }, "theme.ErrorPageContent.title": { "message": "Questa pagina è andata in crash.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Torna indietro all'inizio", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Archivio", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Archivio", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Navigazione nella pagina dei post del blog ", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Post più recenti", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Post più vecchi", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Navigazione nella pagina dei post del blog ", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Post più recente", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Post più vecchio", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Guarda tutte le etichette", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "system mode", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "Modalità chiara", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "Modalità scura", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Passa dalla modalità scura a quella chiara (currently {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 elemento|{count} elementi", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Pagina del documento", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Precedente", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Successivo", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Un documento etichettato|{count} documenti etichettati", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} con \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "Versione: {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Questa è documentazione inedita per {siteTitle} versione {versionLabel}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Questa è la documentazione per {siteTitle} {versionLabel}, che non è più attivamente mantenuta.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Per la documentazione aggiornata, guarda la {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "ultima versione", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { "message": "Modifica questa pagina", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "Link diretto a {heading}", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " il {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " da {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Ultimo aggiornamento{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versioni", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.NotFound.title": { "message": "Pagina non trovata", "description": "The title of the 404 page" }, "theme.tags.tagsListLabel": { "message": "Etichette:", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Chiudi", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "attenzione", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "pericolo", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "informazioni", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "note", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "suggerimento", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "warning", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Expand sidebar category '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Collapse sidebar category '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(apri in un nuovo tab)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Principale", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "Non siamo riusciti a trovare quello che stavi cercando.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Contatta il proprietario del sito che ti ha collegato all'URL originale e fagli sapere che il loro collegamento è interrotto.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Linguaggio", "description": "The label for the mobile language switcher dropdown" }, "theme.blog.post.readingTime.plurals": { "message": "Lettura di 1 minuto|{readingTime} minuti di lettura", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.post.readMore": { "message": "Leggi di più", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Leggi di più su {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.CodeBlock.wordWrapToggle": { "message": "Attiva/disattiva a capo automatico", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.CodeBlock.copy": { "message": "Copia", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Copiato", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Copia il codice negli appunti", "description": "The ARIA label for copy code blocks button" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Collassa la barra laterale", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Collassa la barra laterale", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.navAriaLabel": { "message": "Barra laterale dei documenti", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Chiudi la barra di navigazione", "description": "The ARIA label for close button of mobile sidebar" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Attiva/disattiva la barra di navigazione", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Indietro al menu principale", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Apri il menù a tendina", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Chiudi il menù a tendina", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Espandi la barra laterale", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Espandi la barra laterale", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "Un post|{count} post", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} etichettati con \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Authori", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Vedi Tutti gli Authori", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Questo autore non ha ancora scritto alcun post.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Pagina non in elenco", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Questa pagina non è in elenco. I motori di ricerca non lo indicheranno e solo gli utenti con collegamento diretto possono accedervi.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Pagina in bozza", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Questa pagina è una bozza. Sarà visibile solo in dev e sarà esclusa dalla build di produzione.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Prova di nuovo", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Passa al contenuto principale", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Etichette", "description": "The title of the tag list page" } } ================================================ FILE: i18n/it/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Blog", "description": "The title for the blog used in SEO" }, "description": { "message": "Blog", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Tutti i post", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" } } ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Usa Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandi Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Sviluppa Templates", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Best Practices", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Inizio della documentazione" description: “Tutto quello che c'è da sapere su come è organizzata questa documentazione.” sidebar_position: 1 --- # Benvenuto Benvenuto nella documentazione di [Helm](https://helm.sh/). Helm è un gestore di pacchetti per Kubernetes. Per ulteriori informazioni sul contesto dettagliato, consulta il [rapporto sul percorso del progetto Helm alla CNCF](https://www.cncf.io/cncf-helm-project-journey/). # Come è organizzata questa documentazione? Helm ha una vasta documentazione. Una panoramica di alto livello su come è organizzata ti aiuterà a capire dove cercare determinate informazioni: - I [tutorial](/intro/index.mdx) ti guidano passo dopo passo nella creazione del tuo primo Chart in Helm. Inizia da qui se sei nuovo in Helm. - [Guide tematiche](/topics/index.mdx) trattano gli argomenti e i concetti principali ad alto livello, oltre a fornire contesto e spiegazioni utili su Helm. - [Guide pratiche](/howto/index.mdx) sono ricette pronte all'uso. Ti guidano attraverso i passaggi necessari per risolvere i principali problemi e casi d'uso. Sono più avanzate dei tutorial e richiedono una conoscenza preliminare del funzionamento di Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: "Tecniche Avanzate di Helm" description: "Spiega varie funzioni avanzate per i power user di Helm" weight: 9 --- Questa sezione illustra varie funzioni e tecniche avanzate di utilizzo di Helm. Le informazioni contenute in questa sezione sono destinate ai "power user" di Helm che desiderano personalizzare e manipolare in modo avanzato i charts e le release. Ognuna di queste funzioni avanzate comporta dei compromessi e degli avvertimenti, per cui ognuna di esse deve essere utilizzata con attenzione e con una conoscenza approfondita di Helm. O in altre parole, ricordate il [principio di Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility) ## Post Rendering Il post rendering offre agli installatori di Charts la possibilità di manipolare manualmente, configurare e/o convalidare i manifesti renderizzati prima che vengano installati da Helm. Questo permette agli utenti con esigenze di configurazione avanzate di poter usare strumenti come [`kustomize`](https://kustomize.io) per applicare le modifiche alla configurazione senza la necessità di dover fare il fork di un chart pubblico o senza richiedere ai manutentori del chart di specificare ogni singola opzione di per un pezzo di software. Esistono anche casi d'uso per iniettare strumenti comuni e macchine secondarie in ambienti aziendali o l'analisi dei manifesi prima della distribuzione. ### Prerequisiti - Helm 3.1+ ### Utilizzo Un post-renderer può essere un qualsiasi eseguibile che accetta manifest Kubernetes renderizzati su STDIN e restituisce manifest Kubernetes validi su STDOUT. Dovrebbe restituire un codice di uscita non-0 in caso di fallimento. Questa è l'unica "API" tra i due componenti. Permette una grande flessibilità in ciò che si può fare con il processo di post-rendering. Un post renderer può essere usato con `install`, `upgrade` e `template`. Per usare un post-renderer, usare il flag `--post-renderer` con il percorso del renderer che si desidera utilizzare: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Se il percorso non contiene separatori, la ricerca verrà effettuata in $PATH, altrimenti risolverà qualsiasi percorso relativo in un percorso completamente qualificato. Se si desidera utilizzare più post-renderizzatori, richiamateli tutti in uno script o insieme in un qualsiasi strumento binario con cui è stato implementato. In bash, questo potrebbe essere semplice come `renderer1 | renderer2 | renderer3`. Si può vedere un esempio di utilizzo di `kustomize` come renderizzatore di post [qui](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Avvertenze Quando si usano i postrenderer, ci sono diverse cose importanti da tenere a mente. La più importante è che quando si usa un post renderer, tutte le persone che modificano quella release **DOVREBBERO** usare lo stesso renderizzatore per poter essere ripetibili. Questa caratteristica è stata costruita appositamente per consentire a qualsiasi utente di cambiare il renderer che sta utilizzando o di smettere di usare un renderer, ma questo dovrebbe essere fatto deliberatamente per evitare modifiche accidentali o perdite di dati. Un'altra nota importante riguarda la sicurezza. Se si usa un post-renderer, bisogna assicurarsi che provenga da una fonte affidabile (come nel caso di qualsiasi altro eseguibile arbitrario ). L'uso di renderizzatori non affidabili o non verificati NON è raccomandato, in quanto hanno pieno accesso ai modelli renderizzati, che spesso contengono dati dati segreti. ### Post renderer personalizzati La fase di post renderer offre una flessibilità ancora maggiore se utilizzata con l'SDK Go. Ogni post renderer deve solo implementare la seguente interfaccia di Go: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Per ulteriori informazioni sull'uso di Go SDK, vedere la sezione [Go SDK](#go-sdk). ## Go SDK Helm 3 ha presentato un SDK per Go completamente ristrutturato per una migliore esperienza nella di creazione di software e strumenti che sfruttano Helm. La documentazione completa è disponibile all'indirizzo [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), ma una breve panoramica di alcuni dei pacchetti più comuni e di un semplice esempio qui di seguito. ## Storage backends Helm 3 ha cambiato il default in cui memorizzare le informazioni sul rilascio in Secrets nel namespace della release. Helm 2 per impostazione predefinita memorizza le informazioni della release in ConfigMaps nel namespace dell'istanza di Tiller. Le sottosezioni che seguono mostrano come configurare i diversi backend. Questa configurazione si basa sulla variabile d'ambiente `HELM_DRIVER`. Può essere impostata su uno dei valori: `[configmap, secret, sql]`. ### Storage backend ConfigMap Per abilitare il backend ConfigMap, è necessario impostare la variabile d'ambiente `HELM_DRIVER` a `configmap`. Si può impostare in una shell come segue: ```shell export HELM_DRIVER=configmap ``` Se si vuole passare dal backend predefinito a quello ConfigMap, si dovrà fare la migrazione autonomamente. È possibile recuperare le informazioni sulla release con il seguente comando: ```shell kubectl get secret --all-namespaces -l “owner=helm” ``` **NOTE DI PRODUZIONE**: Le informazioni sulla release includono il contenuto dei chart e dei values file, e quindi potrebbero contenere dati sensibili (come password, chiavi private e altre credenziali) che devono essere protetti dall'accesso non autorizzato. Quando si gestisce l'autorizzazione di Kubernetes, ad esempio con [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), è possibile concedere un accesso più ampio alle risorse ConfigMap, mentre si limita l'accesso alle risorse Secret. Ad esempio, il ruolo predefinito [user-facing utente](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) “view” garantisce l'accesso alla maggior parte delle risorse, ma non ai Secret. Inoltre, i dati dei Secret possono essere configurati per [archiviazione criptata](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Si tenga presente questo aspetto se si decide di passare al backend ConfigMap, perché potrebbe esporre i dati sensibili dell'applicazione. ### Storage backend SQL Esiste uno storage backend SQL ***beta*** che memorizza le informazioni di rilascio in un database SQL. L'uso di uno storage backend di questo tipo è particolarmente utile se le informazioni sulla release pesano più di 1 MB (nel qual caso non possono essere memorizzate in ConfigMaps/Secrets). a causa dei limiti nello storage key-values di etcd in Kubernetes). Per abilitare il backend SQL, è necessario distribuire un database SQL e impostare la variabile d'ambiente `HELM_DRIVER` a `sql`. I dettagli del DB sono impostati con la variabile d'ambiente `HELM_DRIVER_SQL_CONNECTION_STRING`. È possibile impostarla in una shell come segue: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Nota: al momento è supportato solo PostgreSQL. **NOTE DI PRODUZIONE**: Si raccomanda di: - Preparare il database alla produzione. Per PostgreSQL, consultare i documenti di [Server Administration](https://www.postgresql.org/docs/12/admin.html) per maggiori dettagli. - Abilitare la [gestione dei permessi](/topics/permissions_sql_storage_backend.md) per rispecchiare le RBAC di Kubernetes per le informazioni della release Se si vuole passare dal backend predefinito al backend SQL, si dovrà fare la migrazione in autonomia. È possibile recuperare le informazioni sulla release con il seguente comando: ```shell kubectl get secret --all-namespaces -l “owner=helm” ``` ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: "Architettura di Helm" description: "Descrive l'architettura di Helm ad alto livello." weight: 8 --- # Architettura di Helm Questo documento descrive l'architettura di Helm ad alto livello. ## Lo scopo di Helm Helm è uno strumento per la gestione dei pacchetti Kubernetes chiamati _charts_. Helm può fare quanto segue: - Creare nuovi chart da zero - Pacchettizzare i chart in file archivi (tgz) - Interagire con i repository dei chart, dove questi sono memorizzati - installare e disinstallare chart in un cluster Kubernetes esistente - Gestire il ciclo di rilascio dei chart installati con Helm. Per Helm, ci sono tre concetti importanti: 1. Il _chart_ è un insieme di informazioni necessarie per creare un'istanza di un'applicazione Kubernetes. 2. Il _config_ contiene informazioni di configurazione che possono essere unite in un chart impacchettato per creare un oggetto rilasciabile. 3. Una _release_ è un'istanza in esecuzione di un _chart_, combinato con una specifica _config_. ## Componenti Helm è un eseguibile implementato in due parti distinte: Il **Client Helm** è un client a riga di comando per gli utenti finali. Il client è responsabile di quanto segue: - Sviluppo del chart locale - Gestione dei repository - Gestione dei rilasci - Interfacciamento con la libreria Helm - Invio di chart da installare - Richiedere l'aggiornamento o la disinstallazione di release esistenti. La **Libreria Helm** fornisce la logica per l'esecuzione di tutte le operazioni di Helm. Si si interfaccia con il server API di Kubernetes e fornisce le seguenti funzionalità: - Combinazione di un chart e di una configurazione per costruire un rilascio. - Installazione dei chart in Kubernetes e fornitura del successivo oggetto di rilascio. - Aggiornamento e disinstallazione dei chart interagendo con Kubernetes. La libreria Helm standalone incapsula la logica Helm in modo che possa essere sfruttata da diversi client. ## Implementazione Il client e la libreria Helm sono scritti nel linguaggio di programmazione Go. La libreria utilizza il client Kubernetes per comunicare con Kubernetes. Attualmente, questa libreria utilizza REST+JSON. Memorizza le informazioni in Secrets situati all'interno di Kubernetes. Non ha bisogno di un proprio database. I file di configurazione sono, quando possibile, scritti in YAML. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: "Guida ai Chart Repository" description: "Come creare e lavorare coi repository per Helm chart." weight: 6 --- Questa sezione spiega come creare e lavorare con i repository dei chart Helm. Ad alto livello un repository di chart è una posizione in cui i chart confezionati possono essere archiviati e condivisi. Il repository distribuito della comunità di Helm si trova all'indirizzo [Artifact Hub](https://artifacthub.io/packages/search?kind=0) e accoglie con favore la partecipazione. Ma Helm permette anche di creare e gestire un proprio repository di chart. Questa guida spiega come farlo. ## Prerequisiti * Leggere la guida [Quickstart](/intro/quickstart.md) * Leggere il documento [Charts](/topics/charts.md) ## Creare un chart repository Un _chart repository_ è un server HTTP che ospita un file `index.yaml` e opzionalmente alcuni chart confezionati. Quando si è pronti a condividere i propri chart, il modo modo preferibile è caricarli in un archivio di grafici. A partire da Helm 2.2.0, è supportata l'autenticazione SSL lato client a un repository. Altri protocolli di autenticazione possono essere disponibili come plugin. Poiché un chart repository può essere un qualsiasi server HTTP in grado di servire file YAML e tar e può rispondere a richieste GET, si ha una pletora di opzioni quando si tratta di ospitare il proprio chart repository. Ad esempio, è possibile utilizzare un bucket di Google Cloud Storage (GCS), Amazon S3, GitHub Pages o addirittura creare il proprio server web. ### La struttura del chart repository Un chart repository è composto da chart pacchettizzati e da un file speciale chiamato`index.yaml` che contiene un indice di tutti i chart presenti nel repository. Spesso, i chart che `index.yaml` descrive sono ospitati sullo stesso server, così come i [file di provenienza] ({{< ref "provenance.md" >}}).Per esempio, il layout del repository `https://example.com/charts` potrebbe essere così: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` In questo caso, il file di indice conterrebbe informazioni su un chart, il chart Alpine, e fornirebbe l'URL per il download`https://example.com/charts/alpine-0.1.2.tgz` per quel chart. Non è necessario che un pacchetto di chart si trovi sullo stesso server del file`index.yaml`. Tuttavia, spesso è la soluzione più semplice. ### Il file indice Il file indice è un file yaml chiamato `index.yaml`. Contiene alcuni metadati del pacchetto, compreso il contenuto del file `Chart.yaml` di un chart. A chart repository valido deve avere un file di indice. Il file indice contiene informazioni su ogni chart presente nel repository. Il comando `helm repo index` genera un file di indice basato su una determinata directory locale che contenente i chart pacchettizzati. Questo è un esempio di file di indice: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Ospitare i Chart Repositories Questa parte mostra diversi modi per servire un chart repository.. ### Google Cloud Storage Il primo passo è quello di **creare il proprio bucket GCS**. Chiameremo il nostro `fantastic-charts`. ![Creare un bucket GCS](https://helm.sh/img/create-a-bucket.png) Quindi, rendete il vostro bucket pubblico **modificando i permessi del bucket**. ![Modifica permessi](https://helm.sh/img/edit-permissions.png) Inserire questa voce per **rendere pubblico il bucket**: ![Rendi pubblico il bucket](https://helm.sh/img/make-bucket-public.png) Congratulazioni, ora avete un bucket GCS vuoto pronto per servire i chart! È possibile caricare il chart repository utilizzando lo strumento a riga di comando Google Cloud Storage o utilizzando l'interfaccia web di GCS. È possibile accedere a un bucket GCS pubblico tramite semplice HTTPS a questo indirizzo: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith È anche possibile impostare chart repositories utilizzando Cloudsmith. Per saperne di più chart repositories con Cloudsmith [qui](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory Allo stesso modo, è possibile impostare chart repositories utilizzando JFrog Artifactory. Per saperne di più su chart repositories con JFrog Artifactory [qui](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repository) ### Esempio con GitHub Pages In modo simile è possibile creare charts repository utilizzando GitHub Pages. GitHub consente di servire pagine web statiche in due modi diversi: - Configurando un progetto per servire il contenuto della sua cartella `docs/`. - Configurando un progetto per servire un particolare branch. Noi adotteremo il secondo approccio, anche se il primo è altrettanto semplice. Il primo passo sarà quello di **creare il branch gh-pages**. È possibile farlo localmente come. ```console $ git checkout -b gh-pages ``` Oppure tramite browser web usando il pulsante **Branch** sul repository GitHub: ![Crea branch GitHub Pages](https://helm.sh/img/create-a-gh-page-button.png) Successivamente, ci si deve assicurare che il branch **gh-pages** sia impostato come GitHub Pages, cliccare sulle **Impostazioni** del proprio repository e scorrere fino alla sezione **Pagine GitHub** e e impostare come indicato di seguito: ![Crea branch GitHub Pages](https://helm.sh/img/set-a-gh-page.png) Per impostazione predefinita, **Source** viene solitamente impostato su **gh-pages branch**. Se questo non è impostato per impostazione predefinita, selezionarlo. È possibile utilizzare un **dominio personalizzato** se lo si desidera. Verificare che **Enforce HTTPS** sia spuntato, in modo che **HTTPS** venga utilizzato quando vengono serviti i chart. In questa configurazione si può usare il branch predefinito per memorizzare il codice dei chart e il branch **gh-pages** come repository dei chart. Ad esempio: `https://USERNAME.github.io/REPONAME`. La dimostrazione [TS Charts](https://github.com/technosophos/tscharts) è accessibile all'indirizzo `https://technosophos.github.io/tscharts/`. Se hai deciso di utilizzare le GitHub pages per ospitare il repository dei chart, consulta [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action è un flusso di lavoro GitHub Action che consente di trasformare un progetto GitHub in un repository Helm chart self-hosted, utilizzando lo strumento CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Ordinary web servers To configure an ordinary web server to serve Helm charts, you merely need to do the following: - Put your index and charts in a directory that the server can serve - Make sure the `index.yaml` file can be accessed with no authentication requirement - Make sure `yaml` files are served with the correct content type (`text/yaml` or `text/x-yaml`) Per esempio, se si vogliono servire i chart da `$WEBROOT/charts`, assicurarsi che ci sia una cartella `charts/` nella propria radice web e inserire il file indice e i chart all'interno di quella cartella. ### ChartMuseum Repository Server ChartMuseum è un server di repository Helm Chart open-source scritto in Go (Golang), con supporto per backend di cloud storage, tra cui [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Microsoft Azure](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Oracle Cloud](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Tencent](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) e [etcd](https://etcd.io/). È inoltre possibile utilizzare il servizio [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) per ospitare un archivio di chart da un file system locale. ### Registro dei pacchetti GitLab Con GitLab è possibile pubblicare i chart Helm nel Package Registry del progetto. Per saperne di più sull'impostazione di un helm package repository con GitLab [qui](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Gestione dei repository dei grafici Ora che si dispone di un chart repository, l'ultima parte di questa guida spiega come come gestire i chart in quel repository. ### Memorizzare i chart nel chart repository Ora che si dispone di un chart repository, carichiamo un chart e un file di indice nel repository. I chart in un chart repository devono essere impacchettati (`helm package nome-della-cartella/`) e correttamente versionati (seguendo le linee guida di [SemVer 2](https://semver.org/)). I passi successivi compongono un flusso di lavoro di esempio, ma si può usare qualsiasi flusso di lavoro per memorizzare e aggiornare i chart nel proprio repository. Una volta pronto un chart pacchettizzato, creare una nuova directory e spostare il chart pacchettizzato in quella directory. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` L'ultimo comando prende il percorso della cartella locale appena creata e l'URL del repository grafico remoto. l'URL del chart repository remoto e compone un file `index.yaml` all'interno della cartella indicata. Ora è possibile caricare il chart e il file di indice nel chart repository, utilizzando uno strumento di sincronizzazione o manualmente. Se si utilizza Google Cloud Storage, si può dare un'occhiata a questo [esempio di flusso di lavoro](/howto/chart_repository_sync_example.md) utilizzando il client gsutil. Per GitHub, è sufficiente inserire i chart nel branch di destinazione appropriato. ### Aggiungere nuovi chart a un repository esistente Ogni volta che si desidera aggiungere un nuovo chart al repository, è necessario rigenerare l'indice. Il comando `helm repo index` ricostruisce completamente il file `index.yaml` da zero, includendo solo i chart trovati localmente. Tuttavia, è possibile utilizzare il flag `--merge` per aggiungere in modo incrementale nuovi chart a un file `index.yaml esistente (un'ottima opzione quando si lavora con un repository remoto come GCS). Eseguire `helm repo index --help` per saperne di più, Assicurarsi di caricare sia il file `index.yaml` rivisto che il chart. E se si è generato un file di provenienza, caricare anche quello. ### Condividere i chart con altri Quando si è pronti a condividere i chart, è sufficiente comunicare a qualcuno l'URL del vostro repository. Da lì, aggiungeranno il repository al loro client helm tramite il comando `helm repo add [NAME] [URL]` con il nome che si desidera utilizzare per fare riferimento al repository. ``console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Se i chart sono supportati dall'autenticazione di base HTTP, si possono fornire anche il nome utente e la password: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Nota:** Un repository non verrà aggiunto se non contiene un valido file `index.yaml`. **Nota:** Se il proprio repository helm utilizza ad esempio un certificato autofirmato, si può usare `helm repo add --insecure-skip-tls-verify ...` per saltare la verifica della CA. Dopodiché, i vostri utenti saranno in grado di cercare nei vostri chart. Dopo aver aggiornato il repository, possono usare il comando `helm repo update` per ottenere le ultime informazioni più recenti sui chart. *Sotto il cofano, i comandi `helm repo add` e `helm repo update` recuperano il file index.yaml e lo memorizzano nella cartella `$XDG_CACHE_HOME/helm/repository/cache/`. È qui che la funzione `helm search` trova le informazioni sui chart. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: "Testare i Chart" description: "Descrive come eseguire e testare i chart." weight: 3 --- Un chart contiene una serie di risorse e componenti Kubernetes che lavorano insieme. Come autore di un chart, potresti voler scrivere alcuni test che convalidino che il tuo chart funzioni come previsto quando viene installato. Questi test aiutano anche l'utente del chart a capire cosa dovrebbe fare il chart. Un **test** in un chart helm si trova nella cartella `templates/` ed è una definizione di lavoro che specifica un container con un determinato comando da eseguire. Il container deve terminare con successo (exit 0) perché il test sia considerato superato. La definizione del job deve contenere l'annotazione helm test hook: `helm.sh/hook: test`. Si noti che fino a Helm v3, la definizione del job doveva contenere una di queste annotazioni helm test hook: `helm.sh/hook: test-success` o `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` è ancora accettato come alternativa retro-compatibile a `helm.sh/hook: test`. Test di esempio: - Validare che la configurazione del file values.yaml sia stata iniettata correttamente. - Verificare che il nome utente e la password funzionino correttamente - Assicurarsi che un nome utente e una password non corretti non funzionino. - Verificare che i servizi siano attivi e che il bilanciamento del carico sia corretto - ecc. È possibile eseguire i test predefiniti in Helm su una release utilizzando il comando `helm test `. Per un utente del chart, questo è un ottimo modo per verificare che la propria release di un chart (o di un'applicazione) funzioni come previsto. ## Esempio di test Il comando [helm create](/docs/helm/helm_create) creerà automaticamente una serie di cartelle e file. Per provare la funzionalità di test di helm, creare prima un chart demo. ```console $ helm create demo ``` Ora sarà possibile vedere la seguente struttura nel chart demo. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` In `demo/templates/tests/test-connection.yaml` si trova un test che si può provare. È possibile vedere la definizione del pod di test di helm qui: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Passi per eseguire una suite di test su una release Per prima cosa, installare il chart sul cluster per creare una release. Potrebbe essere necessario attendere che tutti i pod siano attivi; se si esegue il test subito dopo l'installazione, è probabile che si verifichi un errore transitivo e che si debba ripetere il test. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Note - È possibile definire tutti i test che si desidera in un singolo file yaml o distribuirli in diversi file yaml nella cartella `templates/`. - È possibile annidare la propria suite di test sotto una cartella `tests/`, come ad esempio `/templates/tests/` per un maggiore isolamento. - Un test è un [hook] di Helm (/docs/charts_hooks/), quindi annotazioni come `helm.sh/hook-weight` e `helm.sh/hook-delete-policy` possono essere usate con le risorse dei test. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: "Charts" description: "Spiega il formato dei chart e fornisce indicazioni di base per la creazione di chart con Helm." weight: 1 --- Helm utilizza un formato di packaging chiamato _charts_. Un chart è un insieme di file che descrivono un insieme correlato di risorse Kubernetes. Un singolo chart potrebbe essere usato per distribuire qualcosa di semplice, come un pod memcached, o qualcosa di complesso, come uno stack completo di app web con server HTTP, database, cache e così via. I chart vengono creati come file disposti in un particolare albero di directory. Possono essere in archivi versionati per essere distribuiti. Se si desidera scaricare e consultare i file di un chart pubblicato, senza installarlo, è possibile farlo con `helm pull chartrepo/nome del chart`. Questo documento spiega il formato del chart e fornisce una guida di base per costruire chart con Helm. ## La struttura dei file del chart Un chart è organizzato come una raccolta di file all'interno di una directory. Il nome della directory è il nome del chart (senza informazioni sulla versione). Quindi, un chart che descrive WordPress verrebbe memorizzato in una directory `wordpress/`. All'interno di questa directory, Helm si aspetta una struttura che corrisponde a questa: ```text wordpress/ Chart.yaml # Un file YAML contenente informazioni sul chart LICENSE # OPZIONALE: un file di testo semplice contenente la licenza per il chart. README.md # OPZIONALE: un file README human-readable values.yaml # I valori di configurazione predefiniti per questo chart values.schema.json # OPZIONALE: Uno schema JSON per imporre una struttura al file values.yaml charts/ # Una directory contenente i chart da cui dipende questo chart. crds/ # Custom Resource Definitions templates/ # Una directory di template che, se combinati con i values, # genereranno file manifest Kubernetes validi. templates/NOTES.txt # OPZIONALE: un file di testo semplice contenente brevi note d'uso. ``` Helm si riserva l'uso delle directory `charts/`, `crds/` e `templates/` e dei nomi dei file elencati. Gli altri file saranno lasciati così come sono. ## Il file Chart.yaml Il file `Chart.yaml` è necessario per un chart. Contiene i seguenti campi: ```yaml apiVersion: La versione dell'API del chart (obbligatorio) name: il nome del chart (obbligatorio) version: Una versione di SemVer 2 (obbligatorio) kubeVersion: Un intervallo SemVer di versioni Kubernetes compatibili (opzionale) description: Una descrizione di una sola frase di questo progetto (opzionale) type: Il tipo di chart (opzionale) keywords: - Un elenco di parole chiave relative a questo progetto (opzionale) home: L'URL della pagina iniziale di questo progetto (facoltativo) sources: - Un elenco di URL al codice sorgente di questo progetto (facoltativo) dependencies: # Un elenco dei requisiti del chart (opzionale) - name: il nome del chart (nginx) version: La versione del chart ("1.2.3") repository: (opzionale) L'URL del repository ("https://example.com/charts") o l'alias ("@repo-name") condition: (facoltativo) Un percorso yaml che si risolve in un booleano, usato per abilitare/disabilitare i chart (ad esempio, subchart1.enabled). tag: # (opzionale) - I tag possono essere usati per raggruppare i chart da abilitare/disabilitare insieme import-values: # (opzionale) - ImportValues contiene la mappatura dei valori di origine con la chiave padre da importare. Ogni elemento può essere una stringa o una coppia di elementi di sottoelenco padre/figlio. alias: (opzionale) Alias da usare per il chart. Utile quando si deve aggiungere lo stesso chart più volte. maintainer: # (opzionale) - name: il nome del maintainer (obbligatorio per ogni maintainer) email: L'email del maintainer (opzionale per ogni maintainer) url: Un URL per il maintainer ( opzionale per ogni maintainer) icon: Un URL a un'immagine SVG o PNG da usare come icona (opzionale). appVersion: La versione dell'applicazione che contiene (opzionale). Non è necessario che sia SemVer. Si consigliano le citazioni. deprecated: Se questo chart è deprecato (opzionale, booleano). annotations: example: Un elenco di annotazioni con chiave per nome (opzionale). ``` A partire da [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), non sono consentiti campi aggiuntivi. L'approccio consigliato è quello di aggiungere metadati personalizzati in `annotations`. ### Chart e versioni Ogni chart deve avere un numero di versione. Una versione deve seguire lo standard [SemVer 2](https://semver.org/spec/v2.0.0.html). A differenza di Helm Classic, Helm v2 e successivi utilizza i numeri di versione come marcatori di release. I pacchetti nei repository sono identificati dal nome più versione. Per esempio, un chart `nginx` il cui campo versione è impostato a `version: 1.2.3` si chiamerà: ```testo nginx-1.2.3.tgz ``` Sono supportati anche nomi SemVer 2 più complessi, come `version: 1.2.3-alpha.1+ef365`. Ma i nomi non SemVer sono esplicitamente rifiutati dal sistema. **NOTA:** Mentre Helm Classic e Deployment Manager erano entrambi molto orientati a GitHub quando si trattava di chart, Helm v2 e successivi non si basano su GitHub e nemmeno su Git. Di conseguenza, non utilizza gli SHA di Git per il versioning. Il campo `version` all'interno di `Chart.yaml` è usato da molti strumenti di Helm, compresa la CLI. Quando si genera un pacchetto, il comando `helm package` utilizzerà la versione trovata in `Chart.yaml` come token nel nome del pacchetto. Il sistema presume che il numero di versione nel nome del pacchetto del chart corrisponda al numero di versione presente in `Chart.yaml`. Il mancato rispetto di questa ipotesi causerà un errore. ### Il campo `apiVersion` Il campo `apiVersion` dovrebbe essere `v2` per i chart Helm che richiedono almeno Helm 3. I chart che supportano versioni precedenti di Helm hanno una `apiVersion` impostata a `v1` e sono ancora installabili con Helm 3. Cambiamenti dalla `v1` alla `v2`: - Un campo `dependencies` che definisce le dipendenze del chart, che erano situate in un file `requirements.yaml` separato per i chart della `v1` (vedere [Dipendenze dei Chart](#dipendenze-dei-chart)). - Il campo `type`, che discrimina i chart di applicazione da quelli di libreria (vedere [Tipi di chart](#tipi-di-chart)). ### Il campo `appVersion` Si noti che il campo `appVersion` non è correlato al campo `version`. È un modo di specificare la versione dell'applicazione. Per esempio, la tabella `drupal` può avere una `appVersion: "8.2.1"`, che indica che la versione di Drupal inclusa nel chart (per impostazione predefinita) è `8.2.1`. Questo campo è informativo e non ha alcun impatto sul calcolo della versione del chart. Si consiglia di racchiudere la versione tra virgolette. Questo costringe il parser YAML a trattare il numero di versione come una stringa. Lasciarlo senza virgolette può causare problemi di parsing in alcuni casi. Per esempio, YAML interpreta `1.0` come un valore in virgola mobile e un SHA di git commit come `1234e10` come notazione scientifica. A partire da Helm v3.5.0, `helm create` avvolge il campo predefinito `appVersion` tra virgolette. ### Il campo `kubeVersion` Il campo opzionale `kubeVersion` può definire i vincoli di semver sulle versioni supportate di Kubernetes. Helm convaliderà i vincoli di versione al momento dell'installazione del chart e fallirà se il cluster esegue una versione di Kubernetes non supportata. I vincoli di versione possono comprendere confronti AND separati da spazi, come ad esempio ``` >= 1.13.0 < 1.15.0 ``` che possono essere combinati con l'operatore OR `||` come nel seguente esempio ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` In questo esempio la versione `1.14.0` viene esclusa, il che può avere senso se è noto un bug in certe versioni che impediscono il corretto funzionamento del chart. Oltre ai vincoli di versione che impiegano gli operatori `=` `!=` `>` `<` `>=` `<=`, sono supportate le seguenti notazioni stenografiche * intervalli di trattini per intervalli chiusi, dove `1.1 - 2.3.4` è equivalente a `>= 1.1 <= 2.3.4`. * caratteri jolly `x`, `X` e `*`, dove `1.2.x` equivale a `>= 1.2.0 <= 1.3.0`. 1.3.0`. * intervalli di tilde (sono consentite modifiche alla versione della patch), dove `~1.2.3` equivale a `>= 1.2.3 < 1.3.0`. * intervalli di caret (sono ammessi cambiamenti di versione minori), dove `^1.2.3` equivale a `>= 1.2.3 < 2.0.0`. Per una spiegazione dettagliata dei vincoli di semver supportati, vedere [Masterminds/semver](https://github.com/Masterminds/semver). ### Deprecazione dei chart Quando si gestiscono i chart in un Chart Repository, a volte è necessario deprecare un chart. Il campo opzionale `deprecated` in `Chart.yaml` può essere utilizzato per contrassegnare un chart come deprecato. Se la versione **più recente** di un chart nel repository è contrassegnata come deprecata, allora il chart nel suo insieme è considerato deprecato. Il nome del chart può essere riutilizzato in seguito pubblicando una versione più recente che non sia contrassegnata come deprecata. Il flusso di lavoro per la deprecazione dei chart è il seguente: 1. Aggiornare il file `Chart.yaml` del grafico per contrassegnarlo come deprecato, eliminando la versione 2. Rilasciare la nuova versione del chart nel Chart Repository. 3. Rimuovere il chart dal repository dei sorgenti (p.e. git) ### Tipi di chart Il campo `type` definisce il tipo di chart. Esistono due tipi:`application` e `library`. Application è il tipo predefinito e rappresenta il chart standard che può essere utilizzato completamente. Il [Chart di tipo Library]({{< ref "/docs/topics/library_charts.md" >}}) fornisce utilità o funzioni per il costruttore di chart. Un chart library si differenzia da un chart applicativo perché non è installabile e di solito non contiene oggetti risorsa. **Nota:** Un chart di tipo application può essere usato come chart di tipo library. Questo viene abilitato impostando il tipo a `library`. Il chart sarà quindi reso come un chart di libreria dove si possono sfruttare tutte le utilità e le funzioni. Tutti gli oggetti risorsa del chart non saranno renderizzati. ## LICENZA, README e NOTE I chart possono contenere anche file che descrivono l'installazione, la configurazione, e la licenza d'uso di un chart. La LICENZA è un file di testo semplice che contiene il codice di[licenza](https://en.wikipedia.org/wiki/Software_license) per il chart.Il chart può contenere una licenza perché può contenere logica di programmazione nei modelli e quindi non sarebbe solo di configurazione. Ci possono essere anche licenze separate per l'applicazione installata dal chart, se necessario. Un README per un chart dovrebbe essere formattato in Markdown (README.md) e dovrebbe contenere generalmente: - una descrizione dell'applicazione o del servizio che il chart fornisce - Eventuali prerequisiti o requisiti per eseguire il chart - Descrizioni delle opzioni in `values.yaml` e dei valori predefiniti - Qualsiasi altra informazione che possa essere rilevante per l'installazione o la configurazione del chart. Quando gli hub e le altre interfacce utente visualizzano i dettagli di un chart, tali dettagli vengono dal contenuto del file `README.md`. Il chart può anche contenere un breve file di testo semplice `templates/NOTES.txt` che verrà stampato dopo l'installazione e quando si visualizza lo stato di una release. Questo file viene valutato come un [template](#templates-e-values) e può essere usato per visualizzare le note d'uso, i passi successivi o qualsiasi altra informazione relativa a una un rilascio del chart. Ad esempio, si possono fornire istruzioni per connessione a un database o l'accesso a un'interfaccia web. Poiché questo file viene stampato su STDOUT quando si esegue `helm install` o `helm status`, è consigliabile mantenere il contenuto breve e rimandare al README per maggiori dettagli. ## Dipendenze dei chart In Helm, un chart può dipendere da un numero qualsiasi di altri chart. Queste dipendenze possono essere collegate dinamicamente utilizzando il campo `dependencies` in `Chart.yaml` o nella cartella `charts/` e gestite manualmente. ### Gestione delle dipendenze con il campo `dipendenze I chart richiesti dal chart corrente sono definiti come un elenco nel campo `dipendenze`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Il campo `name` è il nome del chart desiderato. - Il campo `version` è la versione del chart desiderata. - Il campo `repository` è l'URL completo del repository del chart. Si noti che deve essere usato anche `helm repo add` per aggiungere quel repo localmente. - Si può usare il nome del repo invece dell'URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Una volta definite le dipendenze, è possibile eseguire `helm dependency update` e il programma utilizzerà il file delle dipendenze per scaricare tutti i chart specificati nel file delle dipendenze per scaricare tutti i chart specificati nella cartella `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Quando `helm dependency update` recupera i chart, li memorizza come archivi di chart nella directory `charts/`. Quindi, per l'esempio precedente, ci si aspetterebbe di vedere i seguenti file nella cartella charts: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Campo Alias nelle dipendenze Oltre agli altri campi sopra citati, ogni voce relativa alle dipendenze può contenere il campo opzionale`alias`. L'aggiunta di un alias per un dependency chart inserisce un chart nelle dipendenze usando alias come nome della nuova dipendenza. Si può usare `alias` nel caso in cui si debba accedere a un chart con altri nomi. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` Nell'esempio precedente, avremo 3 dipendenze in tutto per `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` Il modo manuale per ottenere questo risultato è copiare/incollare lo stesso chart nella directory `charts/` più volte con nomi diversi. #### Tag e Condition fields nelle dipendenze Oltre agli altri campi sopra citati, ogni voce di requisiti può contenere i campi opzionali `tags` e `condition`. Tutti i campi sono caricati per impostazione predefinita. Se i campi `tags` o `condition` sono presenti, vengono valutati e utilizzati per controllare il caricamento dei chart a cui sono applicati. Condition - Il campo condition contiene uno o più percorsi YAML (delimitati da virgole). Se questo percorso esiste nei valori del genitore superiore e si risolve in un valore valore booleano, il grafico verrà attivato o disattivato in base a quel valore booleano. Viene valutato solo il primo percorso valido trovato nell'elenco; se non esistono percorsi, la condizione non ha effetto. Tags - Il campo tags è un elenco YAML di etichette da associare a questo chart. In valori del parent superiore, tutti i chart con tag possono essere attivati o disattivati specificando il tag e un valore booleano. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` Nell'esempio precedente, tutti i chart con il tag `front-end` sarebbero disabilitati ma poiché il percorso `subchart1.enabled` valuta 'true' nei valori del parent, la condizione sovrascrive il tag `front-end` e `subchart1` viene abilitato. Poiché `subchart2` è etichettato con `back-end` e tale tag valuta a `true`, `subchart2` sarà abilitato. Si noti anche che, sebbene `subchart2` abbia una condizione specificata, non c'è alcun percorso e valore corrispondente nei valori del parent, per cui questa condizione non ha alcun effetto. ##### Uso della CLI con tag e condizioni Il parametro `--set' può essere usato come di consueto per modificare i valori dei tag e delle condizioni. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Risoluzione di tag e condizioni - **Le conditions (se impostate in valori) sovrascrivono sempre i tag.** La prima condition path che esiste vince e le successive per quel chart vengono ignorate. - I tag vengono valutati come "se uno qualsiasi dei tag del chart è vero, allora abilita il chart". - I valori dei tag e delle condition devono essere impostati nei value del chart superiore. - La chiave `tags:` nei value deve essere una chiave di livello superiore. I globals e le tabelle `tags:` annidate non sono attualmente supportati. #### Importare i Values dei figli tramite le dipendenze In alcuni casi è auspicabile che i valori di un chart figlio si propaghino al chart padre e siano condivisi come values predefiniti comuni. Un ulteriore vantaggio di utilizzare il formato `exports` è che consentirà ai futuri strumenti di introspezione dei values impostabili dall'utente. Le chiavi che contengono i valori da importare possono essere specificate nel chart padre, nel campo `import-values`, utilizzando un elenco YAML. Ogni elemento dell'elenco è una chiave che viene importata dal campo `exports` del chart figlio. Per importare valori non contenuti nella chiave `exports`, utilizzare il metodo [child-parent](#usare-il-formato-child-parent). Esempi di entrambi i formati sono descritti di seguito. ##### Usare il formato exports Se il file `values.yaml` di un chart figlio contiene un campo `exports` nella root, il suo contenuto può essere importato direttamente nei valori del parent, specificando le chiavi da importare, come nell'esempio seguente: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Dal momento che stiamo specificando la chiave `data` nella nostra lista di importazione, Helm cerca nel campo `exports` del chart figlio la chiave `data` e importa il suo contenuto. I valori finali del parent conterranno il nostro campo esportato: ```yaml # parent's values myint: 99 ``` Si noti che la chiave del parent `data' non è contenuta nei values finali del parent. Se è necessario specificare la chiave del parent, utilizzare il formato 'child-parent'. ##### Usare il formato child-parent Per accedere ai values che non sono contenuti nella chiave `exports` dei values del chart figlio, sarà necessario specificare la chiave di origine dei valori da da importare (`child`) e il percorso di destinazione nei valori del chart padre (`parent`). L'opzione `import-values` nell'esempio seguente indica a Helm di prendere tutti i valori trovati nel percorso `child:` e di copiarli nei valori del parent nel percorso specificato in `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` Nell'esempio precedente, i valori trovati in `default.data` nei valori del subchart1 saranno importati nella chiave `myimports` nei valori del chart padre, come descritto di seguito: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` I valori risultanti del chart padre saranno: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` I valori finali del parent contengono ora i campi `myint` e `mybool` importati da subchart1. ### Gestione manuale delle dipendenze tramite la directory `charts/` Se si desidera un maggiore controllo sulle dipendenze, queste possono essere esplicitate copiando i chart delle dipendenze nella cartella `charts/`. Una dipendenza deve essere una cartella di chart scompattati, ma il suo nome non può iniziare con con `_` o `.`. Tali file vengono ignorati dal caricatore del chart. Per esempio, se il chart di WordPress dipende dal grafico di Apache, il chart di Apache (della versione corretta) viene fornito nella cartella `charts/` del chart WordPress: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` L'esempio precedente mostra come il chart di WordPress esprima la sua dipendenza da Apache e MySQL includendo questi chart all'interno della cartella `charts/`. **TIP:** _Per inserire una dipendenza nella cartella `charts/`, usare il comando `helm pull". ### Aspetti operativi dell'uso delle dipendenze Le sezioni precedenti spiegano come specificare le dipendenze dei chart, ma come influiscono sull'installazione dei chart con `helm install` e `helm upgrade`? Supponiamo che un chart chiamato "A" crei i seguenti oggetti Kubernetes - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Inoltre, A dipende dal chart B, che crea gli oggetti - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Dopo l'installazione/aggiornamento del chart A viene creata/modificata una singola release di Helm. Il rilascio creerà/aggiornerà tutti gli oggetti Kubernetes di cui sopra nel seguente ordine: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Questo perché quando Helm installa/aggiorna i chart, gli oggetti Kubernetes del chart e tutte le sue dipendenze sono - aggregati in un unico insieme; quindi - ordinati per tipo seguito dal nome; e poi - creati/aggiornati in questo ordine. Quindi viene creata una singola release con tutti gli oggetti per il chart e le sue dipendenze. L'ordine di installazione dei tipi di Kubernetes è dato dall'enumerazione InstallOrder in kind_sorter.go (si veda [il file sorgente di Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates e Values I template di Helm Chart sono scritti nel linguaggio [Go template](https://golang.org/pkg/text/template/), con l'aggiunta di una cinquantina di funzioni template [dalla libreria Sprig](https://github.com/Masterminds/sprig) e alcune altre [funzioni specializzate](/howto/charts_tips_and_tricks.md). Tutti i file dei template sono memorizzati nella cartella `templates/` di un chart. Quando Helm esegue il rendering dei chart, passerà ogni file in quella cartella attraverso il motore dei template. I values dei template possono essere forniti in due modi: - Gli sviluppatori dei chart possono fornire un file chiamato `values.yaml` all'interno di di un chart. Questo file può contenere valori predefiniti. - Gli utenti dei chart possono fornire un file YAML contenente i valori. Questo può essere fornito a riga di comando con helm install. Quando un utente fornisce valori personalizzati, questi valori sovrascrivono quelli del file values.yaml del chart. ### File Template I file template seguono le convenzioni standard per la scrittura dei template di Go (vedi [il pacchetto Go text/templatedocumentazione](https://golang.org/pkg/text/template/) per i dettagli). Un esempio dipotrebbe essere simile a questo: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` L'esempio precedente, basato vagamente su [https://github.com/deis/charts](https://github.com/deis/charts), è un template per un replica controller Kubernetes. Può utilizzare i seguenti quattro valori (solitamente definiti in un file `values.yaml`): - `imageRegistry`: Il registry di origine dell'immagine Docker. - `dockerTag`: Il tag per l'immagine Docker. - `pullPolicy`: La politica di pull di Kubernetes. - `storage`: Il backend dello storage, il cui valore predefinito è impostato su `"minio"`. Tutti questi valori sono definiti dall'autore del template. Helm non richiede o deficita di parametri. Per vedere chart funzionanti, consultare il CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Valori predefiniti I valori forniti tramite un file `values.yaml` (o tramite il flag `--set`) sono accessibili dall'oggetto `.Values` di un template. Ma ci sono altri dati predefiniti a cui si può accedere nei template. I seguenti valori sono predefiniti, sono disponibili per ogni template e non possono essere sovrascritti. Come per tutti i valori, i nomi sono _sensibili alle maiuscole_. - `Release.Name`: Il nome della release (non il chart). - `Release.Namespace`: il namespace in cui è stato rilasciato il chart - `Release.Service`: Il servizio che ha effettuato il rilascio. - `Release.IsUpgrade`: Viene impostato a true se l'operazione corrente è un aggiornamento o rollback. - `Release.IsInstall`: È impostato su true se l'operazione corrente è un'installazione. - `Chart`: Il contenuto di `Chart.yaml`. Pertanto, la versione del chart è ottenibile come `Chart.Version` e i manutentori sono in `Chart.Maintainers`. - `Files`: Un oggetto simile a una mappa che contiene tutti i file non speciali del chart. Questo oggetto non darà accesso ai template, ma darà accesso ai file aggiuntivi presenti (a meno che non siano esclusi usando `.helmignore`). Ai file si può accedere utilizzando `{{ index .Files "file.name" }}` o utilizzando il comando `{{.Files.Get name }}` Si può anche accedere al contenuto del file come `[]byte` usando `{{ .Files.GetBytes }}`. - `Capabilities`: Un oggetto simile a una mappa che contiene informazioni sulle versioni di Kubernetes (`{{ .Capabilities.KubeVersion }}`) e le versioni di Kubernetes API supportate (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`). **NOTA:** Qualsiasi campo `Chart.yaml` sconosciuto verrà eliminato.Non saranno accessibili all'interno dell'oggetto `Chart`. Pertanto, `Chart.yaml` non può essere usato per passare dati strutturati in modo arbitrario nel template. Il file values può essere usato per questo, però. ### Values Files Considerando il modello della sezione precedente, un file `values.yaml` che fornisce i valori necessari avrebbe il seguente aspetto: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Un file di valori è formattato in YAML. Un chart può includere un file `values.yaml` predefinito. Il comando di installazione di Helm permette all'utente di sovrascrivere i valori fornendo values YAML aggiuntivi: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Quando i valori vengono passati in questo modo, verranno uniti nel file dei valori di default. Per esempio, si consideri un file `myvals.yaml` che assomiglia a questo: ```yaml storage: "gcs" ``` Quando questo viene unito con il file `values.yaml` nel chart, il contenuto generato risultante sarà: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Si noti che solo l'ultimo campo è stato sovrascritto. **NOTA:** Il file dei valori predefiniti incluso in un chart _deve_ essere chiamato `values.yaml`. Ma i file specificati sulla riga di comando possono avere qualsiasi nome. **NOTA:** Se il flag `--set` è usato in `helm install` o `helm upgrade`, quei valori sono semplicemente convertiti in YAML. **NOTA:** Se esistono voci richieste nel file dei valori, queste possono essere dichiarate come richieste nel template del chart, utilizzando la funzione ['required'](/howto/charts_tips_and_tricks.md) Tutti questi valori sono poi accessibili all'interno dei template utilizzando l'oggetto `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Ambito, dipendenze e valori I file Values possono dichiarare valori per il chart di primo livello e per tutti i chart inclusi nella cartella `charts/` di quel chart. Oppure, per dirla in modo diverso, un file di values può fornire valori al chart così come a qualsiasi delle sue dipendenze. Per esempio, il chart dimostrativo di WordPress qui sopra ha sia `mysql` che `apache` come dipendenze. Il file dei valori potrebbe fornire i valori a tutti questi componenti: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` I chart di livello superiore hanno accesso a tutte le variabili definite sotto. Quindi il chart di WordPress può accedere alla password di MySQL come `.Values.mysql.password`. Ma i chart di livello inferiore non possono accedere alle variabili dei chart padre, quindi MySQL non sarà in grado di accedere alla proprietà `title`. Né, a questo proposito, può accedere a `apache.port`. I valori sono inseriti in namespace, ma i namespace vengono eliminati. Quindi, per il chart di WordPress, può accedere al campo della password di MySQL come `.Values.mysql.password`. Ma per il chart MySQL, l'ambito dei valori è stato ridotto e il prefisso dello spazio dei nomi è stato rimosso, per cui il campo password viene visualizzato semplicemente come `.Values.password`. #### Valori globali A partire dalla versione 2.0.0-Alpha.2, Helm supporta valori speciali "globali". Si consideri questa versione modificata dell'esempio precedente: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Quanto sopra aggiunge una sezione `global` con il valore `app: MyWordPress`. Questo valore è disponibile per _tutti_ i chart come `.Values.global.app`. Per esempio, i template `mysql` possono accedere a `app` come `{{.Values.global.app}}`, così come il chart `apache`. In effetti, il file values di cui sopra viene rigenerato in questo modo: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` Questo permette di condividere una variabile di primo livello con tutti i chart secondari che è utile per impostare proprietà di `metadati` come le etichette. Se un subchart dichiara una variabile globale, questa sarà passata _verso il basso_ (ai subchart del subchart), ma non _verso l'alto_ al chart padre. Non c'è modo che un subchart possa influenzare i valori del chart padre. Inoltre, le variabili globali del chart padre hanno la precedenza sulle variabili globali dei subchart. ### Schema Files A volte, il maintainer di un chart potrebbe voler definire una struttura per i suoi values. Questo può essere fatto definendo uno schema nel file `values.schema.json`. Uno schema è rappresentato come un [JSON Schema] (https://json-schema.org/). Potrebbe assomigliare a qualcosa del genere: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Questo schema verrà applicato ai valori per convalidarli. La convalida avviene quando uno dei seguenti comandi: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Un esempio di file `values.yaml` che soddisfa i requisiti di questo schema potrebbe assomigliare a questo: ```yaml name: frontend protocol: https port: 443 ``` Si noti che lo schema viene applicato all'oggetto finale `.Values` e non solo al file `values.yaml`. Questo significa che il seguente file `yaml` è valido, dato che lo schema è stato installato con l'appropriata opzione `--set` mostrata sotto. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Inoltre, l'oggetto finale `.Values` viene controllato rispetto a *tutti* gli schemi dei subchart.Questo significa che le restrizioni di un subchart non possono essere aggirate da un chart padre. Questo funziona anche al contrario: se un subchart ha un requisito che non è soddisfatto nel file `values.yaml` del subchart, il chart padre *deve* soddisfare tali restrizioni per essere valido. ### Riferimenti Quando si tratta di scrivere template, values e schema, esistono diversi riferimenti standard che vi aiuteranno. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Definizioni di risorse personalizzate (CRD) Kubernetes fornisce un meccanismo per dichiarare nuovi tipi di oggetti Kubernetes. Utilizzando le CustomResourceDefinitions (CRDs), gli sviluppatori Kubernetes possono dichiarare tipi di risorse personalizzate. In Helm 3, i CRD sono trattati come un tipo speciale di oggetto. Vengono installati prima del resto del chart e sono soggetti ad alcune limitazioni. I file YAML dei CRD devono essere collocati nella cartella `crds/` all'interno di un chart. Più CRD (separati da marcatori YAML di inizio e fine) possono essere inseriti nello stesso file. Helm tenterà di caricare _tutti_ i file nella directory CRD in Kubernetes. I file CRD _non possono essere "templetizzati"_. Devono essere semplici documenti YAML. Quando Helm installa un nuovo chart, caricherà i CRD, si fermerà fino a quando i CRD sono resi disponibili dal server API, quindi avvia il motore dei template, esegue il rendering del resto del chart e lo carica su Kubernetes. A causa di questo ordine, le informazioni sui CRD sono disponibili nell'oggetto `.Capabilities` nei template Helm, e i template di Helm possono creare nuove istanze di oggetti che sono stati dichiarati in CRD. Ad esempio, se il chart ha una CRD per `CronTab` nella cartella `crds/`, si possono creare istanze del tipo `CronTab` nella cartella `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Il file `crontab.yaml` deve contenere la CRD senza direttive di template: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Quindi il template `mycrontab.yaml` può creare una nuova `CronTab` (usando i template come di consueto): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm si assicurerà che il tipo `CronTab` sia stato installato e che sia disponibile dal server API di Kubernetes prima di procedere all'installazione degli elementi in `templates/`. ### Limitazioni dei CRD A differenza della maggior parte degli oggetti in Kubernetes, i CRD sono installati globalmente. Per questo motivo, Helm adotta un approccio molto cauto nella gestione dei CRD. I CRD sono soggetti alle seguenti limitazioni: - I CRD non vengono mai reinstallati. Se Helm determina che i CRD presenti nella directory `crds/` sono già presenti (indipendentemente dalla versione), Helm non tenterà di installarli o aggiornarli. - I CRD non vengono mai installati in caso di aggiornamento o rollback. Helm creerà i CRD solo durante le operazioni di installazione. - I CRD non vengono mai eliminati. L'eliminazione di un CRD cancella automaticamente tutti i contenuti del CRD in tutti i namespace del cluster. Di conseguenza, Helm non eliminerà i CRD. Gli operatori che desiderano aggiornare o eliminare i CRD sono invitati a farlo manualmente e con molta attenzione. ## Usare Helm per gestire i chart Lo strumento `helm` ha diversi comandi per lavorare con i chart. Può creare un nuovo chart: ```console $ helm create mychart Created mychart/ ``` Una volta modificato un chart, `helm` può impacchettarlo in un archivio di chart per l'utente: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Si può anche usare `helm` per trovare problemi con la formattazione o le informazioni del chart. ```console $ helm lint mychart No issues found ``` ## Chart Repositories Un _chart repository_ è un server HTTP che ospita uno o più chart confezionati. Mentre `helm` può essere utilizzato per gestire le directory locali di chart, quando si tratta di condividere i chart, il meccanismo preferito è un chart repository. Qualsiasi server HTTP in grado di servire file YAML e file tar e di rispondere alle richieste GET può essere utilizzato come server di repository. Il team di Helm ha testato alcuni server, tra cui Google Cloud Storage con modalità website abilitata e S3 con modalità website abilitata. Un repository è caratterizzato principalmente dalla presenza di un file speciale chiamato `index.yaml` che contiene un elenco di tutti i pacchetti forniti dal repository, insieme ai metadati che permettono di recuperare e verificare tali pacchetti. Sul lato client, i repository sono gestiti con i comandi `helm repo`. Tuttavia, Helm non fornisce strumenti per il caricamento di grafici su server di repository remoti. Questo perché ciò comporterebbe l'aggiunta di requisiti sostanziali per un server server e quindi aumenterebbe la barriera per la creazione di un repository. ## Chart Starter Packs Il comando `helm create` accetta un'opzione `--starter` che permette di specificare un "chart iniziale". Inoltre, l'opzione starter ha un alias breve `-p`. Esempi di utilizzo: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Gli starter sono dei normali chart, ma si trovano in `$XDG_DATA_HOME/helm/starters`. Come sviluppatore di chart, si possono creare chart che sono specificamente progettati per essere usati come starter. Tali chart devono essere progettati con le seguenti considerazioni: - Il file `Chart.yaml` sarà sovrascritto dal generatore. - Gli utenti si aspetteranno di poter modificare i contenuti di un chart di questo tipo, quindi la documentazione dovrebbe indicare come gli utenti possono farlo. - Tutte le occorrenze di `` saranno sostituite con il nome del chart specificato, in modo che i chart di partenza possano essere usati come modelli, tranne che per alcuni file variabili. Ad esempio, se si utilizzano file personalizzati nella cartella `vars` o alcuni file `README.md`, `` NON verrà sovrascritto al loro interno. Inoltre, la descrizione del chart non viene ereditata. Attualmente l'unico modo per aggiungere un chart a `$XDG_DATA_HOME/helm/starters` è copiarlo manualmente. Nella documentazione del chart, si potrebbe spiegare questo processo. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: "Chart Hooks" description: "Descrive come lavorare con i chart hooks." aliases: ["/docs/charts_hooks/"] weight: 2 --- Helm fornisce un meccanismo di _hook_ per consentire agli sviluppatori di chart di intervenire in determinati punti del ciclo di vita di una release. Ad esempio, è possibile utilizzare gli hook per: - Caricare una ConfigMap o un Segreto durante l'installazione prima che vengano caricati altri chart. - Eseguire un Job per eseguire il backup di un database prima dell'installazione di un nuovo chart e poi eseguire un secondo Job dopo l'aggiornamento per ripristinare i dati. - Eseguire un Job prima di eliminare una release per togliere in modo gracefully un service dalla rotation prima di rimuoverlo. Gli hook funzionano come i normali templates, ma hanno annotazioni speciali che fanno sì che Helm li utilizzi in modo diverso. In questa sezione si illustra il modello d'uso di base degli hook. ## Gli Hook disponibili Sono definiti i seguenti hook: | Valore Annotation | Descrizione | | ---------------- | ----------------------------------------------------------------------------------------------------- | | `pre-install` | Viene eseguito dopo il rendering dei modelli, ma prima che vengano create le risorse in Kubernetes | | `post-install` | Viene eseguita dopo che tutte le risorse sono state caricate in Kubernetes | | `pre-delete` | Viene eseguito su una richiesta di cancellazione prima che qualsiasi risorsa venga eliminata da Kubernetes | | `post-delete` | Viene eseguita su una richiesta di cancellazione dopo che tutte le risorse della release sono state cancellate | | `pre-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che i template sono stati renderizzati, ma prima che le risorse siano aggiornate | |`post-upgrade` | Viene eseguita una richiesta di aggiornamento dopo che tutte le risorse sono state aggiornate | | `pre-rollback` | Viene eseguita una richiesta di rollback dopo che i template sono stati renderizzati, ma prima che le risorse siano state rollbackate | | `post-rollback` | Viene eseguita una richiesta di rollback dopo che tutte le risorse sono state modificate | | `test` | Viene eseguita quando viene invocato il sottocomando Helm test ([view test docs](/topics/chart_tests.md)) | Si noti che l'hook `crd-install` è stato rimosso a favore della directory `crds/`. in Helm 3._ ## Hooks e Release Lifecycle Gli hook consentono allo sviluppatore del chart di eseguire operazioni in punti strategici del ciclo di vita della release. Ad esempio, si consideri il ciclo di vita di un'installazione di `helm`. Per impostazione predefinita, il ciclo di vita appare come segue: 1. L'utente esegue `helm install foo` 2. Viene richiamata l'API di installazione della libreria Helm3. 3. Dopo alcune verifiche, la libreria restituisce i manifest `foo`. 4. La libreria carica le risorse risultanti in Kubernetes 5. La libreria restituisce l'oggetto di rilascio (e altri dati) al client. 6. Il client esce Helm definisce due hook per il ciclo di vita di `install`: `pre-install` e `post-install`. Se lo sviluppatore della chart `foo` implementa entrambi gli hook, il ciclo di vita viene modificato in questo modo: 1. L'utente esegue `helm install foo` 2. Viene richiamata l'API di installazione della libreria Helm 3. Vengono installati i CRD nella directory `crds/`. 4. Dopo alcune verifiche, la libreria esegue il rendering dei template `foo`. 5. La libreria si prepara a eseguire gli hook `pre-install` (caricamento delle risorse hook in Kubernetes) 6. La libreria ordina gli hook per peso (assegnando un peso pari a 0 per impostazione predefinita), per tipo di risorsa e infine per nome in ordine crescente. 7. La libreria carica quindi per primo hook con il peso più basso (da negativo a positivo). 8. La libreria attende finché l'hook non è "pronto" (tranne che per i CRD). 9. La libreria carica le risorse risultanti in Kubernetes. Si noti che se il flag `--wait` è impostato, la libreria aspetterà che tutte le risorse siano in uno stato di ready e non eseguirà l'hook `post-install` finché non saranno pronte. 10. La libreria esegue l'hook `post-install` (caricando le risorse dell'hook). 11. La libreria attende finché l'hook non è "pronto". 12. La libreria restituisce l'oggetto release (e altri dati) al client. 13. Il client esce Cosa significa aspettare che un hook sia pronto? Dipende dalla risorsa dichiarata nell'hook. Se la risorsa è del tipo `Job` o `Pod`, Helm attenderà finché non viene eseguita con successo fino al completamento. Se l'hook fallisce, il rilascio fallirà. Si tratta di un'operazione _bloccante_, quindi il client Helm si metterà in pausa durante l'esecuzione del Job. Per tutti gli altri tipi, non appena Kubernetes contrassegna la risorsa come caricata (aggiunta o aggiornata), la risorsa è considerata come caricata. o aggiornata), la risorsa è considerata "pronta". Quando molte risorse sono dichiarate in un hook, le risorse vengono eseguite in serie. Se hanno un peso (vedere sotto), vengono eseguite in ordine ponderato. A partire da Helm 3.2.0 le risorse hook con lo stesso peso vengono installate nello stesso delle normali risorse non hook. Altrimenti, l'ordine non è garantito. (In Helm 2.3.0 e successivi, sono ordinate alfabeticamente. Questo comportamento, tuttavia, non è considerato vincolante e potrebbe cambiare in futuro). È considerata una buona pratica aggiungere un peso all'hook e impostarlo a `0` se il peso non è importante. ### Le risorse degli hook non sono gestite con i rilasci corrispondenti Le risorse create da un hook non sono attualmente tracciate o gestite come parte del rilascio. Una volta che Helm ha verificato che l'hook ha raggiunto lo stato di ready, lascerà la risorsa hook da sola. Il garbage collection delle risorse hook quando il rilascio corrispondente viene cancellato, potrebbe essere aggiunto a Helm 3 in futuro, per cui le risorse hook che non devono mai essere cancellate dovrebbero essere annotate con `helm.sh/resource-policy: keep`. In pratica, ciò significa che se si creano delle risorse in un hook, non si può fare affidamento su `helm uninstall` per rimuovere le risorse. Per distruggere tali risorse, è necessario o [aggiungere un'annotazione personalizzata `helm.sh/hook-delete-policy personalizzata](#politiche-di-cancellazione-degli-hook) al file template dell'hook, oppure [impostare il campo time to live (TTL) di una risorsa Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Scrivere un hook Gli hook sono semplicemente file manifest di Kubernetes con annotazioni speciali nella sezione `metadati`.Essendo file di template, si possono usare tutte le normali funzionalità dei template, tra cui la lettura di `.Values`, `.Release` e `.Template`. Per esempio, questo modello, memorizzato in `templates/post-install-job.yaml`, dichiara un job da eseguire su `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Ciò che rende questo template un hook è l'annotazione: ```yaml annotations: "helm.sh/hook": post-install ``` Una risorsa può implementare più hook: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Allo stesso modo, non c'è limite al numero di risorse diverse che possono implementare un determinato hook. Per esempio, si potrebbero dichiarare sia un segreto che una config map come pre-install hook. Quando sottochart dichiarano degli hook, anche questi vengono valutati. Non c'è modo per un chart di di livello superiore di disabilitare gli hook dichiarati dai sottochart. È possibile definire un peso per un hook, che aiuterà a costruire un ordine di esecuzione deterministico. I pesi si definiscono utilizzando la seguente annotazione: ```yaml annotations: "helm.sh/hook-weight": "5" ``` I pesi degli hook possono essere numeri positivi o negativi, ma devono essere rappresentati come stringhe. Quando Helm avvia il ciclo di esecuzione degli hook di un particolare tipo, li ordina modo crescente. ### Politiche di cancellazione degli hook È possibile definire delle politiche che determinano quando eliminare le risorse degli hook corrispondenti. Le politiche di cancellazione degli hook sono definite usando la seguente annotazione: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` È possibile scegliere uno o più valori di annotazione definiti: | Annotation Value | Description | | ---------------------- | -------------------------------------------------------------------- | | `before-hook-creation` | Elimina la risorsa precedente prima che venga lanciato un nuovo hook (impostazione predefinita) | | `hook-succeeded` | Eliminare la risorsa dopo che l' hook è stato eseguito con successo | | `hook-failed` | Elimina la risorsa se l'hook fallisce durante l'esecuzione | Se non è specificata alcuna annotazione relativa alla politica di cancellazione degli hook, si applica il comportamento `before-hook-creation` per impostazione predefinita. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: Guide tematiche sidebar_position: 3 --- # Guide tematiche Qui troverai un'introduzione a tutti i concetti principali di Helm che dovrai conoscere. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: "API Kubernetes Deprecate" description: "Spiega le API Kubernetes deprecate in Helm" aliases: ["docs/k8s_apis/"] --- Kubernetes è un sistema basato su API e l'API si evolve nel tempo per riflettere l'evoluzione della comprensione dello spazio problematico. Questa è una pratica comune a tutti i sistemi e le loro API. Una parte importante dell'evoluzione delle API è una buona politica e un processo di deprecazione e un processo che informi gli utenti sulle modalità di implementazione delle modifiche alle API. In altre parole, i consumatori della vostra API devono sapere in anticipo e in quale release un'API sarà rimossa o modificata. In questo modo si elimina l'elemento sorpresa e di cambiamenti che possono causare interruzioni per i consumatori. Il [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documenta come Kubernetes gestisce le modifiche alle versioni delle sue API. La politica di deprecazione indica l'arco di tempo in cui le versioni delle API saranno supportate in seguito a un annuncio di deprecazione. È quindi importante essere a conoscenza degli annunci di deprecazione e sapere quando le versioni delle API e verranno rimosse, per ridurre al minimo l'effetto. Questo è un esempio di annuncio [per la rimozione di versioni API deprecate deprecate in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) ed è stato pubblicizzato alcuni mesi prima del rilascio. Queste API sarebbero state annunciate per la deprecazione prima di questo rilascio. Questo dimostra che esiste una buona politica che informa i consumatori sul supporto delle versioni delle API. I template di Helm specificano un [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) quando si definisce un oggetto Kubernetes, simile a un file manifest Kubernetes. Viene specificato nel campo `apiVersion` del template e identifica la versione dell'API dell'oggetto Kubernetes. Questo significa che gli utenti di Helm e i manteiner dei chart Helm devono sapere quando le versioni delle API di Kubernetes sono state deprecate e in quale versione di Kubernetes saranno rimosse. ## Maintainers dei chart È necessario controllare i chart per verificare la presenza di versioni dell'API Kubernetes che siano deprecate o rimosse in una versione di Kubernetes. Le versioni dell'API trovate come deprecate o che non sono più supportate, dovrebbero essere aggiornate alla versione supportata e rilasciata una nuova versione del chart. La versione dell'API è definita dai parametri `kind` e `apiVersion`. Ad esempio, un oggetto `Deployment` rimosso nella versione API di Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Utenti Helm È necessario verificare i chart che si utilizzano (in modo simile a [chart maintainers](#maintainers-dei-chart)) e identificare tutti i chart in cui le versioni delle API sono deprecate o rimosse in una versione di Kubernetes. Per i chart identificati, è necessario verificare l'ultima versione del chart (che ha versioni API supportate) o aggiornare il chart da soli. Inoltre, è necessario verificare tutti i chart distribuiti (ad esempio, i rilasci di Helm). verificando nuovamente la presenza di versioni API deprecate o rimosse. Questo può essere fatto ottenendo i dettagli di una release con il comando `helm get manifest`. I mezzi per aggiornare una release di Helm alle API supportate dipendono dalle vostre scoperte come segue: 1. Se si trovano versioni API deprecate solo allora: - Eseguire un `aggiornamento` con una versione del chart con versioni API di Kubernetes supportate. - Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un rollback a una versione di Helm precedente a quella attuale. 2. Se si trova una o più versioni di API che sono state rimosse in una versione di Kubernetes allora: - Se si sta eseguendo una versione di Kubernetes in cui la versione o le versioni API sono ancora disponibili (ad esempio, si è su Kubernetes 1.15 e si è scoperto di utilizzare API che saranno rimosse in Kubernetes 1.16): - Seguire la procedura del passo 1 - In caso contrario (ad esempio, si sta già utilizzando una versione di Kubernetes dove alcune versioni di API segnalate da `helm get manifest` non sono più disponibili): - È necessario modificare il manifest di rilascio memorizzato nel cluster per aggiornare le versioni delle API a quelle supportate. Vedere [Aggiornamento delle versioni API di un Release Manifest](#aggiornamento-delle-versioni-api-di-un-release-manifest) per maggiori dettagli. > Nota: in tutti i casi di aggiornamento di una release di Helm con API supportate, non si dovrebbe mai eseguire il rollback della release a una versione precedente a quella con le API supportate. > Raccomandazione: La pratica migliore è quella di aggiornare le release che utilizzano API deprecate alle versioni API supportate, prima di eseguire l'aggiornamento a un cluster kubernetes che rimuove tali versioni API. Se non si aggiorna una release come suggerito in precedenza, si verificherà un errore simile al seguente quando si tenta di aggiornare una release in una versione Kubernetes in cui la versione o le versioni API sono state rimosse: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm fallisce in questo scenario perché tenta di creare una patch diff tra la release correntemente distribuita (che contiene le API di Kubernetes che vengono rimosse in questa versione di Kubernetes) rispetto al chart che si sta passando con le versioni aggiornate/supportate delle API. Il motivo del fallimento è che quando Kubernetes rimuove una versione dell'API, la libreria client di Kubernetes Go non è più in grado di analizzare gli oggetti deprecati e quindi Helm fallisce quando chiama la libreria. Helm purtroppo non è in grado di riprendersi da questa situazione e non è più in grado di gestire un simile rilascio. Vedere [Aggiornamento delle versioni API di un Release Manifest](#aggiornamento-delle-versioni-api-di-un-release-manifest) per maggiori dettagli su come recuperare da questo scenario. ## Aggiornamento delle versioni API di un Release Manifest Il manifest è una proprietà dell'oggetto Helm release che viene memorizzata nel campo dati di un Secret (predefinito) o di ConfigMap nel cluster. Il campo dati contiene un oggetto gzipped codificato in base 64 (c'è un'ulteriore codifica in base 64 per un Secret). Esiste un Secret/ConfigMap per release nel namespace della release. È possibile utilizzare il plugin Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) per eseguire l'aggiornamento di una release alle API supportate. Consultare il readme per maggiori dettagli. In alternativa, si possono seguire i seguenti passaggi manuali per eseguire l'aggiornamento delle versioni APIdi un manifest di rilascio. A seconda della configurazione, si seguiranno i passi per il backend Secret o la ConfigMap. - Ottenere il nome del Secret o della Configmap associata all'ultima release distribuita : - backend Secrets: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - backend ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Ottenere i dettagli dell'ultimo rilascio distribuito: - Secrets backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap Backend: `kubectl get configmap -n -o yaml > release.yaml` - Eseguire il backup del rilascio, nel caso sia necessario ripristinarlo se qualcosa va storto: - `cp release.yaml release.bak` - In caso di emergenza, ripristinare: `kubectl apply -f release.bak -n ` - Decodificare l'oggetto release: - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Cambia le versioni API dei manifest. Si può usare qualsiasi strumento (per esempio un editor) per apportare le modifiche. Questo si trova nel campo `manifest` dell'oggetto release decodificato (`release.data.decoded`) - Codifica l'oggetto release: - Secrets backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap backend: `cat release.data.decoded | gzip | base64` - Sostituire il valore della proprietà `data.release` nel file di rilascio distribuito (`release.yaml`) con il nuovo oggetto di rilascio codificato - Applicare il file allo nel namespace: `kubectl apply -f release.yaml -n ` - Eseguire un `helm upgrade` con una versione del chart con le versioni supportate di API Kubernetes - Aggiungere una descrizione nell'aggiornamento, qualcosa del tipo di non eseguire un rollback a una versione di Helm precedente a questa versione attuale ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: "Guida alle distribuzioni di Kubernetes" description: "Raccoglie informazioni sull'utilizzo di Helm in ambienti Kubernetes specifici." aliases: ["/docs/kubernetes_distros/"] weight: 10 --- Helm dovrebbe funzionare con qualsiasi [versione conforme di Kubernetes](https://github.com/cncf/k8s-conformance) (che sia [certificato](https://www.cncf.io/certification/software-conformance/) o meno). Questo documento raccoglie informazioni sull'uso di Helm in specifici ambienti Kubernetes. Si prega di contribuire con ulteriori dettagli su qualsiasi distro (ordinata in ordine alfabetico) se lo si desidera. ## AKS Helm funziona con [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm è stato testato e funziona sulla piattaforma Mesospheres DC/OS 1.11 Kubernetes, e non richiede alcuna configurazione aggiuntiva. ## EKS Helm funziona con Amazon Elastic Kubernetes Service (Amazon EKS): [Utilizzo di Helm con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE La piattaforma Kubernetes in hosting GKE di Google è nota per funzionare con Helm e non richiede nessuna configurazione aggiuntiva. ## `scripts/local-cluster` e Hyperkube È noto che Hyperkube configurato tramite `scripts/local-cluster.sh` funziona. Per Hyperkube raw potrebbe essere necessario eseguire una configurazione manuale. ## IKS Helm funziona con [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm è regolarmente testato su [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm funziona senza problemi nei cluster impostati da KubeOne. ## Kubermatic Helm funziona senza problemi nei cluster utente creati da Kubermatic. Poiché i seed cluster possono essere impostati in modi diversi, il supporto di Helm dipende dalla loro configurazione. ## MicroK8s Helm può essere abilitato in [MicroK8s](https://microk8s.io) usando il comando: `microk8s.enable helm3` ## Minikube Helm è testato e noto per funzionare con [Minikube](https://github.com/kubernetes/minikube). Non richiede alcuna configurazione aggiuntiva. ## Openshift Helm funziona direttamente su OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (versione >= 3.6) o OpenShift Origin (versione >= 3.6). Per saperne di più leggete [questo blog](https://blog.openshift.com/getting-started-helm-openshift/) post. ## Platform9 Helm è preinstallato con [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 fornisce l'accesso a tutti i chart ufficiali di Helm attraverso l'interfaccia utente dell'App Catalog e la CLI nativa di Kubernetes. È possibile aggiungere manualmente altri repository. Ulteriori dettagli sono disponibili in questo [articolo Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu con `kubeadm` Kubernetes avviato con `kubeadm` è noto per funzionare sulle seguenti distribuzioni Linux: - Ubuntu 16.04 - Fedora release 25 Alcune versioni di Helm (v2.0.0-beta2) richiedono di `esportare KUBECONFIG=/etc/kubernetes/admin.conf` o creare un `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm funziona su VMware Tanzu Kubernetes Grid, TKG, senza bisogno di modifiche alla configurazione. La Tanzu CLI può gestire l'installazione di pacchetti per [helm-controller](https://fluxcd.io/flux/components/helm/), consentendo di gestire in modo dichiarativo i rilasci dei chart Helm. Ulteriori dettagli sono disponibili nella documentazione di TKG per [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: "Library Charts" description: "Spiega i library charts e gli esempi di utilizzo" aliases: ["docs/library_charts/"] weight: 4 --- Un library chart è un tipo di [[Helm chart]] ({{< ref "/docs/topics/charts.md" >}}) che definisce primitive o definizioni di chart che possono essere condivise dai template di Helm in altri chart. Questo permette agli utenti di condividere frammenti di codice che possono essere riutilizzabili tra i vari chart, evitando ripetizioni e mantenendo i chart [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Il library chart è stato introdotto in Helm 3 per riconoscere formalmente i chart comuni o di aiuto che sono stati utilizzati dai manutentori dei chart a partire da Helm 2. Includendolo come tipo di chart, fornisce: - un mezzo per distinguere esplicitamente tra chart comuni e chart applicativi - Una logica per impedire l'installazione di un chart comune - Nessun rendering di template in un chart comune, che potrebbe contenere artefatti di rilascio. - Permettere ai chart dipendenti di utilizzare il contesto dell'importatore. Un manutentore di chart può definire un chart comune come un library chart ed essere sicuro che Helm gestirà il chart in modo standard e coerente. Ciò significa anche che che le definizioni in un chart applicativo possono essere condivise cambiando il tipo di chart. ## Creare un Simple Library Chart Come accennato in precedenza, un library chart è un tipo di [Helm chart]({{< ref "/docs/topics/charts.md" >}}). Ciò significa che si può iniziare creando un chart: ```console $ helm create mylibchart Creating mylibchart ``` Si rimuoveranno prima tutti i file nella cartella `templates`, poiché in questo esempio si creeranno le le nostre definizioni di template. ```console $ rm -rf mylibchart/templates/* ``` Anche il file values non sarà necessario. ```console $ rm -f mylibchart/values.yaml ``` Prima di lanciarci nella creazione di codice comune, facciamo un rapido ripasso di alcuni concetti rilevanti di Helm. Un [named template](/chart_template_guide/named_templates.md) (talvolta chiamato partial o un subtemplate) è semplicemente un template definito all'interno di un file e a cui viene dato un nome. Nella cartella `templates/`, qualsiasi file che inizia con un trattino basso(_) non è previsto come output di un file manifest di Kubernetes. Quindi, per convenzione, i template e partials sono inseriti in un file `_*.tpl` o `_*.yaml`. In questo esempio, si codificherà un ConfigMap comune che crea una risorsa ConfigMap vuota. Si definirà il ConfigMap comune nel file `mylibchart/templates/_configmap.yaml` come segue: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Il costrutto ConfigMap è definito nel template `mylibchart.configmap.tpl`. Si tratta di un semplice ConfigMap con una risorsa vuota, `data`.All'interno di questo file c'è un altro modello denominato `mylibchart.configmap`. Questo named template include un altro template chiamato `mylibchart.util.merge` che prenderà come argomenti due named template il template che chiama `mylibchart.configmap` e `mylibchart.configmap.tpl`. La helper function `mylibchart.util.merge` è un named template in `mylibchart/templates/_util.yaml`. Si tratta di un pratico utility di [The Common Helm Helper Chart](#the-common-helm-helper-chart) perché fonde i due template e sovrascrive qualsiasi parte comune in entrambi: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Questo è importante quando un chart vuole utilizzare codice comune che deve essere personalizzato con la sua configurazione. Infine, cambiamo il tipo di chart in `library`. Questo richiede la modifica di `mylibchart/Chart.yaml` come segue: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` Il library chart è ora pronto per essere condiviso e la sua definizione di ConfigMap può essere riutilizzata. Prima di andare avanti, vale la pena di verificare se Helm riconosce il chart come un library chart: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Utilizzare il Simple Library Chart È il momento di utilizzare il library chart. Ciò significa creare nuovamente un chart: ```console $ helm create mychart Creating mychart ``` Ripuliamo di nuovo i file dei template, perché vogliamo creare solo una ConfigMap: ```console $ rm -rf mychart/templates/* ``` Quando si vuole creare una semplice ConfigMap in un template di Helm, si potrebbe avere un aspetto simile al seguente: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Tuttavia, riutilizzeremo il codice comune già creato in `mylibchart`. La ConfigMap può essere creata nel file `mychart/templates/configmap.yaml` come segue: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Si può notare che si semplifica il lavoro da fare, ereditando la definizione comune di ConfigMap, che aggiunge proprietà standard per ConfigMap. Nel nostro modello aggiungiamo la configurazione, in questo caso la chiave dati `myvalue` e il suo valore. valore. La configurazione sovrascrive la risorsa vuota del ConfigMap comune. Questo è possibile grazie alla funzione helper `mylibchart.util.merge` di cui abbiamo parlato nella sezione precedente. Per poter utilizzare il codice comune, è necessario aggiungere `mylibchart` come dipendenza. Aggiungere quanto segue alla fine del file `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Questo include il library chart come dipendenza dinamica dal filesystem che si trova nello stesso percorso padre del nostro chart dell'applicazione. Poiché stiamo includendo il library chart come dipendenza dinamica, è necessario eseguire `helm dependency update`. Questo copierà il library chart nella cartella `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Ora siamo pronti a distribuire il nostro chart. Prima dell'installazione, vale la pena di controllare il template renderizzato. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Questa sembra la ConfigMap che vogliamo, con la sovrascrittura dei dati di `myvalue: Hello World`. Installiamolo: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Possiamo recuperare il rilascio e vedere che il template effettivo è stato caricato. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Vantaggi dei Library Chart A causa della loro incapacità di agire come chart autonomi, i library charts possono sfruttare le seguenti funzionalità: - L'oggetto `.Files` fa riferimento ai percorsi dei file del chart padre, anziché al percorso locale del library charts. - L'oggetto `.Values` è lo stesso del chart padre, a differenza dei [subcharts](/chart_template_guide/subcharts_and_globals.md) dell'applicazione che ricevono la sezione di valori configurata sotto la loro intestazione nel chart padre. ## The Common Helm Helper Chart ```markdown Note: Il repo Common Helm Helper Chart su Github non è più mantenuto attivamente e il repo è stato deprecato e archiviato. ``` Questo [chart] (https://github.com/helm/charts/tree/master/incubator/common) era il pattern originale per i chart comuni. Fornisce utilità che riflettono le best practice di sviluppo dei chart Kubernetes. Soprattutto, può essere utilizzato quando si sviluppano i chart, in modo da avere a disposizione un pratico codice condiviso. Ecco un modo rapido per usarlo. Per maggiori dettagli, consultare il file [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Creare di nuovo un chart: ```console $ helm create demo Creating demo ``` Utilizziamo il codice comune della tabella degli helper. Per prima cosa, modificare il file di deployment `demo/templates/deployment.yaml` come segue: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` E ora il file del service, `demo/templates/service.yaml`, come segue: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Questi template mostrano come l'ereditarietà del codice comune dal helper chart semplifica la codifica fino alla configurazione o alla personalizzazione delle risorse. Per poter utilizzare il codice comune, occorre aggiungere `common` come dipendenza. Aggiungere quanto segue alla fine del file `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Nota: è necessario aggiungere il repo `incubator` all'elenco dei repository Helm (`helm repo add`). Poiché stiamo includendo il chart come dipendenza dinamica, dobbiamo eseguire `helm dependency update`. Questo copierà il chart helper nella cartella `charts/`. Poiché l'helper chart utilizza alcuni costrutti di Helm 2, è necessario aggiungere il file a `demo/values.yaml` per consentire il caricamento dell'immagine `nginx`, che è stata aggiornata nello scaffold chart di Helm 3: ```yaml image: tag: 1.16.0 ``` Si può verificare che i chart template siano corretti prima di distribuirli usando i comandi `helm lint` e `helm template`. Se è tutto a posto, si può procedere al deploy con `helm install`! ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: "Gestione delle autorizzazioni per SQL storage backend" description: "Scoprite come impostare le autorizzazioni quando si utilizza SQL storage backend." --- Questo documento ha lo scopo di fornire agli utenti una guida per l'impostazione e la gestione dei permessi nell'utilizzo del SQL storage backend. ## Introduzione Per gestire i permessi, Helm sfrutta la funzione RBAC di Kubernetes. Quando si utilizza SQL storage backend, i ruoli di Kubernetes non possono essere utilizzati per determinare se un utente può accedere o meno a una determinata risorsa. Questo documento mostra come creare e gestire questi permessi. ## Inizializzazione La prima volta che la CLI di Helm si connetterà al database, il client si accerterà che sia stato precedentemente inizializzato. Se così non fosse, si occuperà automaticamente dell'impostazione necessaria. Questa inizializzazione richiede i privilegi di amministratore sullo schema pubblico, o almeno per essere in grado di: * creare una tabella * concedere i privilegi sullo schema pubblico Dopo l'esecuzione della migrazione sul database, tutti gli altri ruoli possono utilizzare il client. ## Concedere i privilegi a un utente non amministratore in PostgreSQL Per gestire i permessi, il driver del backend SQL sfrutta l'opzione [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Security Level) di PostgreSQL. RLS consente a tutti gli utenti di poter leggere/scrivere dalla/alla stessa tabella, senza poter manipolare le stesse righe se non ne sono esplicitamente autorizzati a farlo. Per impostazione predefinita, qualsiasi ruolo che non sia stato concesso esplicitamente con i giusti privilegi restituirà sempre un elenco vuoto quando si esegue `helm list` e non sarà in grado di recuperare o modificare alcuna risorsa nel cluster. Vediamo come concedere a un determinato ruolo l'accesso a specifici spazi dei nomi: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Questo comando concederà i permessi di lettura e scrittura a tutte le risorse che soddisfano la condizione `namespace = 'default'' al ruolo `role'. Dopo aver creato questa politica, l'utente che si connette al database per conto del ruolo `role` sarà quindi in grado di vedere tutti i rilasci che risiedono nel namespace`default`. quando si esegue `helm list`, e di modificarle e cancellarle. I privilegi possono essere gestiti in modo granulare con RLS, e si potrebbe essere interessati a limitare l'accesso alle diverse colonne della tabella: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: "Guida ai plugin di Helm" description: "Introduce all'uso e alla creazione di plugin per estendere le funzionalità di Helm." weight: 12 --- Un plugin di Helm è uno strumento a cui si può accedere tramite la CLI `helm`, ma che non fa parte della base di codice di Helm. Questa guida spiega come usare e creare i plugin. ## Una panoramica I plugin di Helm sono strumenti aggiuntivi che si integrano perfettamente con Helm. Forniscono un modo per estendere il set di funzionalità principali di Helm, senza però richiedere che ogni nuova funzionalità sia scritta in in Go e di aggiungerle al core dello strumento. I plugin di Helm hanno le seguenti caratteristiche: - Possono essere aggiunti e rimossi da un'installazione di Helm senza impattare lo strumento principale. - Possono essere scritti in qualsiasi linguaggio di programmazione. - Si integrano con Helm e vengono visualizzati in `helm help` e in altri luoghi. I plugin di Helm si trovano in `$HELM_PLUGINS`. È possibile trovarne il valore corrente, compreso il valore predefinito quando non è impostato nell'ambiente, usando il comando `helm env`. Il modello a plugin di Helm è parzialmente basato sul modello a plugin di Git. A tal fine, a volte si sente parlare di `helm` come il _porcelain_ layer, mentre i plugin sono il _plumbing_. Questo è un modo abbreviato per suggerire che Helm fornisce l'esperienza dell'utente e la logica di elaborazione di primo livello, mentre i plugin svolgono il "lavoro di dettaglio" per eseguire un'azione desiderata. ## Installazione di un plugin I plugin vengono installati con il comando `$ helm plugin install `. È possibile inserire il percorso di un plugin sul file system locale o l'url di un repo VCS remoto. Il comando `helm plugin install` clona o copia il plugin nel percorso/url indicato in `$HELM_PLUGINS` ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Se si dispone di una distribuzione tar del plugin, è sufficiente decomprimere il plugin nella cartella `$HELM_PLUGINS`. È anche possibile installare i plugin in formato tar direttamente da url, lanciando `helm plugin install https://domain/path/to/plugin.tar.gz` ## La struttura del file Plugin Per molti versi, un plugin è simile a un chart. Ogni plugin ha una cartella di primo livello e un file `plugin.yaml`. Possono essere presenti altri file, ma è necessario solo il file plugin.yaml. ``` $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Il file plugin.yaml Il file plugin.yaml è necessario per un plugin. Contiene i seguenti campi: ```yaml name: il nome del plugin (OBBLIGATORIO) version: Una versione in formato SemVer 2 (OBBLIGATORIA) usage: Testo d'uso a riga singola mostrato nella guida descrizione: Lunga descrizione mostrata in luoghi come l'help di Helm ignoreFlags: Ignora i flag passati in Helm platformCommand: # Configura il comando da eseguire in base alla piattaforma - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi. arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture command: Comando del plugin da eseguire args: Argomenti del comando del plugin command: (DEPRECATO) Comando del plugin, utilizzare invece platformCommand platformHooks: # Configura gli hook del ciclo di vita del plugin in base alla piattaforma install: # Comando di install - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi. arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture comando: Comando di installazione del plugin da eseguire args: Argomenti del comando di installazione del plugin update: # Comando di update - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi. arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture comando: Comando di aggiornamento del plugin da eseguire args: Argomenti del comando di aggiornamento del plugin delete: # Comando di delete plugin - os: OS match, può essere vuoto o omesso per corrispondere a tutti i sistemi operativi. arch: Architecture match, può essere vuoto o omesso per corrispondere a tutte le architetture comando: Comando di cancellazione del plugin da eseguire args: Argomenti del comando di cancellazione del plugin hooks: # (Deprecato) Hook del plugin, usare invece platformHooks install: Comando per installare il plugin update: Comando per aggiornare il plugin delete: Comando per cancellare il plugin downloader: # Configura la capacità dei downloader - command: Comando da invocare protocolli: - Schema di protocollo supportato ``` ### Il campo `name` Il campo `name` è il nome del plugin. Quando Helm esegue questo plugin, questo è il nome che utilizzerà (ad esempio, `helm NAME` invocherà questo plugin). _`name` deve corrispondere al nome della cartella._ Nell'esempio precedente, ciò significa che il plugin con `name: last` deve essere contenuto in una cartella chiamata `last`. Restrizioni su `name`: - `name` non può duplicare uno dei comandi di primo livello esistenti `helm`. - `name` deve essere limitato ai caratteri ASCII a-z, A-Z, 0-9, `_` e `-`. ### Il campo `version` La `version` è la versione in formato SemVer 2 del plugin. I campi `usage` e `description` sono entrambi utilizzati per generare il testo di aiuto di un comando. ### Il campo `ignoreFlags` L'opzione `ignoreFlags` indica a Helm di non passare i flag al plugin. Quindi, se un plugin è chiamato con `helm myplugin --foo` e `ignoreFlags: true`, allora `--foo` viene silenziosamente scartato. ### Il campo `platformCommand` Il campo `platformCommand` configura il comando che il plugin eseguirà quando viene chiamato. Non è possibile impostare sia `platformCommand` che `command`, in quanto ciò provocherebbe un errore. Per decidere quale comando utilizzare si applicano le seguenti regole: - Se `platformCommand` è presente, verrà utilizzato. - Se sia `os` che `arch` corrispondono alla piattaforma corrente, la ricerca si interrompe e viene utilizzato il comando - Se `os` corrisponde e `arch` è vuoto, verrà utilizzato il comando. - Se `os` e `arch` sono entrambi vuoti, verrà utilizzato il comando. - Se non c'è corrispondenza, Helm uscirà con un errore. - Se `platformCommand` non è presente e il deprecato `command` è presente verrà utilizzato. - Se il comando è vuoto, Helm uscirà con un errore. ### Il campo `platformHooks` Il campo `platformHooks` configura i comandi che il plugin eseguirà per gli eventi del ciclo di vita. Non è possibile impostare sia `platformHooks` che `hooks`, in quanto si otterrebbe un errore. Per decidere quale comando di hook utilizzare, si applicano le seguenti regole: - Se `platformHooks` è presente, verrà utilizzato e i comandi per l'evento del ciclo di vita saranno processati. - Se sia `os` che `arch` corrispondono alla piattaforma corrente, la ricerca si interrompe e il comando sarà utilizzato - Se `os` corrisponde e `arch` è vuoto, il comando verrà utilizzato. - Se `os` e `arch` sono entrambi vuoti, verrà utilizzato il comando. - Se non c'è corrispondenza, Helm salterà l'evento. - Se `platformHooks` non è presente e il deprecato `hooks` è presente il comando per l'evento del ciclo di vita sarà usato. - Se il comando è vuoto, Helm salterà l'evento. ## Building a Plugin Ecco un plugin YAML per un semplice plugin che aiuta a recuperare il nome dell'ultima release: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` I plugin possono richiedere script ed eseguibili aggiuntivi. Gli script possono essere inclusi nella cartella dei plugin e gli eseguibili possono essere scaricati tramite un hook. Il seguente è un esempio di plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Le variabili d'ambiente vengono interpolate prima dell'esecuzione del plugin. Il modello sopra illustra il modo preferito per indicare dove risiede il programma del plugin. ### Comandi dei plugin Esistono alcune strategie per lavorare con i comandi dei plugin: - Se un plugin include un eseguibile, l'eseguibile per un `platformCommand:` dovrebbe essere impacchettato nella cartella del plugin o installato tramite un hook. - La linea `platformCommand:` o `command:` avrà le variabili d'ambiente espanse prima dell'esecuzione. `$HELM_PLUGIN_DIR` punterà alla cartella dei plugin. - Il comando stesso non viene eseguito in una shell. Quindi non è possibile eseguire uno script. - Helm inietta molte configurazioni nelle variabili d'ambiente. Si può dare un'occhiata all'ambiente per vedere quali informazioni sono disponibili. - Helm non fa alcuna ipotesi sulla linguaggio del plugin. È possibile scriverlo in qualsiasi linguaggio si preferisca. - I comandi sono responsabili dell'implementazione di testi di aiuto specifici per `-h` e `--help`. Helm userà `usage` e `description` per `helm help` e `helm help myplugin`, ma non gestirà `helm myplugin --help`. ### Testare un plugin locale Per prima cosa è necessario trovare il percorso `HELM_PLUGINS` e per farlo eseguire il seguente comando: ``` bash helm env ``` Cambiare la propria directory corrente nella directory in cui è impostato `HELM_PLUGINS`. Ora si può aggiungere un collegamento simbolico all'output di compilazione del plugin, in questo esempio lo abbiamo fatto per `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Downloader Plugins Per impostazione predefinita, Helm è in grado di estrarre i chart tramite HTTP/S. A partire da Helm 2.4.0, i plugin possono avere una capacità speciale di scaricare chart da fonti arbitrarie. I plugin devono dichiarare questa capacità speciale nel file `plugin.yaml` (livello superiore): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Se tale plugin è installato, Helm può interagire con il repository usando lo schema di protocollo specificato invocando il `comand`. Il repository speciale deve essere aggiunto in modo simile a quelli normali: `helm repo add favoritemyprotocol://example.com/` Le regole per i repository speciali sono le stesse di quelli regolari: Helm deve essere in grado di scaricare il file `index.yaml` per poter scoprire e memorizzare nella cache l'elenco dei chart disponibili. Il comando definito sarà invocato con il seguente schema: `command certFile keyFile caFile full-URL`. Le credenziali SSL provengono dalla definizione del repo memorizzate in `$HELM_REPOSITORY_CONFIG`. (cioè, `$HELM_CONFIG_HOME/repositories.yaml`). Un downloader plugin dovrebbe scaricare il contenuto grezzo su stdout e segnalare gli errori su stderr. Il comando downloader supporta anche subcommands o argomenti, consentendo di specificare ad esempio il subcommand `bin/mydownloader -d` nel file `plugin.yaml`. Questo è utile se si vuole usare lo stesso eseguibile per il comando principale del plugin e per il comando downloader, ma con un subcommand diverso per ciascuno. ## Variabili d'ambiente Quando Helm esegue un plugin, passa l'environment esterno al plugin e inietta alcune variabili d'ambiente aggiuntive. Variabili come `KUBECONFIG` sono impostate per il plugin se sono impostate nell'ambiente esterno. Viene garantito che le seguenti variabili siano impostate: - `HELM_PLUGINS`:Il percorso della cartella dei plugin. - `HELM_PLUGIN_NAME`: Il nome del plugin, come invocato da `helm`. Quindi `helm myplug` avrà il nome breve `myplug`. - `HELM_PLUGIN_DIR`: La directory che contiene il plugin. - `HELM_BIN`: Il percorso del comando `helm` (come eseguito dall'utente). - `HELM_DEBUG`: Indica se il flag di debug è stato impostato da helm. - `HELM_REGISTRY_CONFIG`: Il percorso della configurazione del registry (se se si usa). Si noti che l'uso di Helm con i registry è una funzione sperimentale. - `HELM_REPOSITORY_CACHE`: Il percorso dei file della cache del repository. - `HELM_REPOSITORY_CONFIG`: Il percorso del file di configurazione del repository. - `HELM_NAMESPACE`: Il namespace dato al comando `helm` (generalmente usando il flag il flag `-n`). - `HELM_KUBECONTEXT`: Il nome del contesto di configurazione di Kubernetes dato al comando `helm`. Inoltre, se è stato specificato esplicitamente un file di configurazione di Kubernetes, esso verrà sarà impostato come variabile `KUBECONFIG`. ## Una nota sul flag parsing Quando si esegue un plugin, Helm analizza i flag globali per il proprio uso. Nessuno di questi flag viene passato al plugin. - `--debug`: Se viene specificato, `$HELM_DEBUG` viene impostato a `1`. - `--registry-config`: Viene convertito in `$HELM_REGISTRY_CONFIG`. - `--repository-cache`: Viene convertito in `$HELM_REPOSITORY_CACHE`. - `--repository-config`: Viene convertito in `$HELM_REPOSITORY_CONFIG`. - `--namespace` e `-n`: Viene convertito in `$HELM_NAMESPACE`. - `--kube-context`: Viene convertito in `$HELM_KUBECONTEXT`. - `--kubeconfig`: Viene convertito in `$KUBECONFIG`. I plugin dovrebbero mostrare un testo di aiuto e poi uscire per `-h` e `--help`. In tutti gli altri casi, i plugin possono usare i flag come meglio credono. ## Supporto per l'autocompletamento della shell A partire da Helm 3.2, un plugin può opzionalmente fornire il supporto per il completamento automatico della shell come parte del meccanismo di autocompletamento di Helm. ### Autocompletamento statico Se un plugin fornisce i propri flag e/o sotto-comandi, può informare Helm di questi, disponendo di un file `completion.yaml` che si trova nella cartella principale del plugin. Il file `completion.yaml` ha la forma: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Note: 1. Tutte le sezioni sono facoltative ma devono essere fornite se applicabili. 2. I flag non devono includere il prefisso `-` o `--`. 3. Possono e devono essere specificati flag sia brevi che lunghi. Un flag breve non deve necessariamente essere associato alla corrispondente forma lunga, ma entrambe le forme devono essere elencate. 4. I flag non devono essere ordinati in alcun modo, ma devono essere elencati nel punto corretto della gerarchia dei sottocomandi del file. 5. I flag globali esistenti di Helm sono già gestiti dal meccanismo di autocompletamento di Helm, quindi i plugin non devono specificare i seguenti flag `--debug`, `--namespace` o `-n`, `--kube-context` e `--kubeconfig`, o qualsiasi altro flag globale. 6. L'elenco `validArgs` fornisce un elenco statico di possibili completamenti del primo parametro di un sottocomando. Non è sempre possibile fornire tale elenco in anticipo (vedere la sezione [Completamento dinamico](#completamento-dinamico)), nel qual caso la sezione `validArgs` può essere omessa. Il file `completion.yaml` è del tutto opzionale. Se non viene fornito, Helm non fornirà semplicemente il completamento automatico della shell per il plugin (a meno che [Completamento dinamico](#completamento-dinamico) sia supportato dal plugin). Inoltre, aggiungendo un file `completion.yaml` è compatibile con le versioni precedenti e non avrà alcun impatto sul comportamento del plugin quando si utilizzano versioni precedenti di helm. A titolo di esempio, per il [`fullstatus ](https://github.com/marckhouzam/helm-fullstatus) che non ha sottocomandi, ma accetta gli stessi flag del comando `helm status`, il file file `completion.yaml` è: ```yaml name: fullstatus flags: - o - output - revision ``` Un esempio più complesso per il [`2to3`](https://github.com/helm/helm-2to3), ha un file `completion.yaml` del tipo: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Completamento dinamico Sempre a partire da Helm 3.2, i plugin possono fornire il proprio completamento automatico della shell. L'autocompletamento dinamico della shell è il completamento dei valori dei parametri o dei flag che non possono essere definiti in anticipo. Ad esempio, il completamento dei nomi delle release di helm attualmente disponibili sul cluster. Affinché il plugin supporti l'autocompletamento dinamico, deve fornire un file **eseguibile** chiamato `plugin.complete` nella sua directory principale. Quando lo script di completamento di Helm richiede un completamento dinamico per il plugin, eseguirà il file `plugin.complete`., passandogli la riga di comando che deve essere completata. L'eseguibile `plugin.complete` dovrà avere la logica per determinare quali siano le scelte corrette per il completamento e inviarle allo standard per essere utilizzato dallo script di completamento di Helm. Il file `plugin.complete` è del tutto opzionale. Se non viene fornito, Helm non fornirà il completamento automatico dinamico per il plugin. Inoltre, l'aggiunta di un file `plugin.complete` è compatibile con le versioni precedenti e non avrà alcun impatto sul comportamento del plugin quando si utilizza con versioni precedenti di Helm. L'output dello script `plugin.complete` dovrebbe essere un elenco separato da new-line char come ad esempio: ``` rel1 rel2 rel3 ``` Quando viene richiamato `plugin.complete`, l'ambiente del plugin viene impostato come quando viene richiamato lo script principale del plugin. Pertanto, le variabili `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` e tutte le altre variabili del plugin saranno già impostate e i corrispondenti flag globali saranno rimossi. Il file `plugin.complete` può essere in qualsiasi forma eseguibile; può essere uno script di shell, un programma Go o qualsiasi altro tipo di programma che Helm può eseguire. Il file `plugin.complete` ***deve*** avere i permessi di esecuzione per l'utente. Il file `plugin.complete` ***deve*** terminare con codice di successo (valore 0). In alcuni casi, il completamento dinamico richiederà di ottenere informazioni dal cluster Kubernetes.Ad esempio, il plugin `helm fullstatus` richiede come input il nome di una release. Nel plugin `fullstatus`, per il suo script `plugin.complete` fornisce il completamento per i nomi dei rilasci correnti, può semplicemente eseguire `helm list -q` e produrre il risultato. Se si vuole usare lo stesso eseguibile per l'esecuzione del plugin e per il suo completamento, lo script `plugin.complete` deve richiamare l'eseguibile del plugin principale con qualche parametro o flag speciale; quando l'eseguibile principale del plugin rileva il parametro o il flag speciale, saprà di dover eseguire il completamento. Nel nostro esempio, `plugin.complete` potrebbe essere implementato in questo modo: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Il vero script del plugin `fullstatus` (`status.sh`) deve quindi cercare il flag `--complete` e, se lo trova, stampare il completamento corretto. ### Suggerimenti e trucchi 1. La shell filtra automaticamente le scelte di completamento che non corrispondono all'input dell'utente. Un plugin può quindi restituire tutti i completamenti rilevanti senza rimuovere quelli che non corrispondono all'input dell'utente. Ad esempio, se la riga di comando è `helm fullstatus ngin`, lo script `plugin.complete` può stampare *tutti* i nomi dei rilasci (dello spazio dei nomi `default`), non solo quelli che iniziano con `ngin`. ; la shell manterrà solo quelli che iniziano con `ngin`. 2. Per semplificare il supporto al completamento dinamico, specialmente se si ha un plugin complesso, si può fare in modo che lo script `plugin.complete` chiami lo script principale del plugin e richieda le scelte di completamento. Si veda la sezione [Completamento dinamico](#completamento-dinamico) per un esempio. 3. Per eseguire il debug del completamento dinamico e del file `plugin.complete`, si può eseguire il comando seguente per vedere i risultati del completamento: - `helm __complete `. Per esempio: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""`. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: "Provenienza e integrità di Helm" description: "Descrive come verificare l'integrità e l'origine di un chart." weight: 5 --- Helm dispone di strumenti di provenienza che aiutano gli utenti dei chart a verificare l'integrità e l'origine di un pacchetto. Utilizzando strumenti standard del settore basati su PKI, GnuPG e gestori di pacchetti ben noti, Helm è in grado di generare e verificare i file di firma. ## Panoramica L'integrità viene stabilita confrontando un chart con un record di provenienza. I record di provenienza sono memorizzati in _file di provenienza_, che vengono memorizzati insieme a un chart impacchettato. Per esempio, se un chart è chiamato `myapp-1.2.3.tgz`, il suo file di provenienza sarà `myapp-1.2.3.tgz.prov`. I file di provenienza sono generati al momento dell'impacchettamento (`helm package --sign ...`), e possono essere controllati da più comandi, in particolare `helm install --verify`. ## Il flusso di lavoro Questa sezione descrive un potenziale flusso di lavoro per utilizzare i dati di provenienza in modo efficace. Prerequisiti: - Una coppia di chiavi PGP valida in un formato binario (non in formato ASCII) - Lo strumento a riga di comando `helm` - Strumenti a riga di comando GnuPG (opzionale) - Strumenti a riga di comando Keybase (opzionale) **NOTA:** Se la vostra chiave privata PGP ha una passphrase, vi sarà richiesto di inserire tale passphrase per tutti i comandi che supportano l'opzione `--sign'. La creazione di un nuovo chart è identica a quella precedente: ```console $ helm create mychart Creating mychart ``` Una volta pronti per l'impacchettamento, aggiungere il flag `-sign' a `helm package'. Inoltre, specificare il nome con cui è conosciuta la chiave di firma e il portachiavi che contiene la corrispondente chiave privata: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Nota:** Il valore dell'argomento `--key` deve essere una sottostringa del `uid` della chiave desiderata (nell'output di `gpg --list-keys`), ad esempio il nome o l'email. **L'impronta digitale non può essere usata.** **TIP:** per gli utenti di GnuPG, il portachiavi segreto si trova in `~/.gnupg/secring.gpg`. È possibile usare `gpg --list-secret-keys` per elencare le chiavi in proprio possesso. **Attenzione:** GnuPG v2 memorizza il portachiavi segreto usando un nuovo formato `kbx`nel percorso predefinito `~/.gnupg/pubring.kbx`. Utilizzare il seguente comando per convertire il portachiavi nel formato gpg tradizionale: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` A questo punto, si dovrebbero vedere sia `mychart-0.1.0.tgz` che `mychart-0.1.0.tgz.prov`. Entrambi i file dovrebbero essere caricati nel repository desiderato. È possibile verificare un chart usando `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Una verifica fallita si presenta così: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Per verificare durante un'installazione, usare il flag `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Se il portachiavi contenente la chiave pubblica associata al grafico firmato non si trova nella posizione predefinita, potrebbe essere necessario indicare il portachiavi con `--keyring PATH` come nell'esempio del pacchetto `helm`. Se la verifica fallisce, l'installazione verrà interrotta prima che il chart venga renderizzato. ### Utilizzo delle credenziali di Keybase.io Il servizio [Keybase.io](https://keybase.io) semplifica la creazione di una catena di fiducia per un'identità crittografica. Le credenziali di Keybase possono essere usate per firmare chart. Prerequisiti: - Un account Keybase.io configurato - GnuPG installato localmente - La CLI `keybase` installata localmente #### Firmare i pacchetti Il primo passo è importare le chiavi del keybase nel portachiavi GnuPG locale: ```console $ keybase pgp export -s | gpg --import ``` Questo convertirà la vostra chiave Keybase nel formato OpenPGP, e poi la importerà localmente nel file `~/.gnupg/secring.gpg`. Si può verificare eseguendo `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Si noti che la chiave segreta avrà una stringa identificativa: ``` technosophos (keybase.io/technosophos) ``` Questo è il nome completo della chiave. Successivamente, si può impacchettare e firmare un chart con `helm package`. Assicuratevi di usare almeno una parte di questi nomi in `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Di conseguenza, il comando `package` dovrebbe produrre sia un file `.tgz` che un file `.tgz.prov`. #### Verifica dei pacchetti È possibile utilizzare una tecnica simile anche per verificare un chart firmato con la chiave Keybase di qualcun altro. Supponiamo di voler verificare un pacchetto firmato da `keybase.io/technosophos`. Per farlo, utilizzate lo strumento `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` Il primo comando qui sopra traccia l'utente `technosophos`. Successivamente `keybase pgp pull` scarica le chiavi OpenPGP di tutti gli account che si seguono, inserendole nel proprio portachiavi GnuPG (`~/.gnupg/pubring.gpg`). A questo punto, è possibile utilizzare `helm verify` o uno qualsiasi dei comandi con il flag `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Motivi per cui un chart non può essere verificato Queste sono le ragioni più comuni del fallimento. - Il file `.prov' è mancante o corrotto. Questo indica che qualcosa è configurato male o che il manteiner originale non ha creato un file di provenienza. - La chiave usata per firmare il file non è presente nel portachiavi. Questo indica che l'entità che ha firmato il chart non è qualcuno di cui avete già segnalato la fiducia. - La verifica del file `.prov` non è riuscita. Questo indica che c'è qualcosa di sbagliato nel chart o nei dati di provenienza. - Gli hash dei file nel file di provenienza non corrispondono all'hash del file dell'archivio. Ciò indica che l'archivio è stato manomesso. Se la verifica fallisce, c'è motivo di diffidare del pacchetto. ## Il file di provenienza Il file di provenienza contiene il file YAML di un chart e diverse informazioni di verifica. I file di provenienza sono progettati per essere generati automaticamente. Vengono aggiunti i seguenti dati di provenienza: * Il file del chart (`Chart.yaml`) è incluso per dare sia all'uomo che agli strumenti una facile visione del contenuto del chart. * La firma (SHA256, proprio come Docker) del pacchetto del chart (il file `.tgz`) è inclusa e può essere usata per verificare l'integrità del pacchetto chart. * L'intero corpo del file è firmato con l'algoritmo usato da OpenPGP (vedi [Keybase.io](https://keybase.io) per un modo emergente di rendere semplice la firma crittografica e la verifica). La combinazione di questi elementi fornisce agli utenti le seguenti garanzie: * Il pacchetto stesso non è stato manomesso (checksum del pacchetto `.tgz`). * L'entità che ha rilasciato il pacchetto è nota (tramite la firma GnuPG/PGP). Il formato del file è simile a questo: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Si noti che la sezione YAML contiene due documenti (separati da `...\n`). Il primo file è il contenuto di `Chart.yaml`.Il secondo è il checksum, una mappa di nomi di file e digest SHA-256 del contenuto di quel file al momento del packaging. Il blocco della firma è una firma PGP standard, che fornisce [resistenza alla manomissione](https://www.rossde.com/PGP/pgp_signatures.html). ## Chart Repositories I chart repository servono come raccolta centralizzata dei chart Helm. I chart repository devono consentire di fornire i file di provenienza via HTTP tramite una una richiesta specifica e devono renderli disponibili nello stesso percorso URI del chart. Ad esempio, se l'URL di base di un pacchetto è`https://example.com/charts/mychart-1.2.3.tgz`, il file di provenienza, se esiste, DEVE essere accessibile all'indirizzo `https://example.com/charts/mychart-1.2.3.tgz.prov`. Dal punto di vista dell'utente finale, `helm install --verify myrepo/mychart-1.2.3` dovrebbe portare al download sia del chart che del file di provenienza, senza alcuna configurazione o azione aggiuntiva da parte dell'utente. ### Firme nei registri basati su OCI Se si pubblicano charts in un [registro basato su OCI]({{< ref "registries.md" >}}), si può usare il [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) per pubblicare la provenienza su [sigstore](https://sigstore.dev/). [Come descritto nella documentazione](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), il processo di creazione della provenienza e di firma con una chiave GPG sono comuni, ma il comando `helm sigstore upload` può essere usato per pubblicare la provenienza in un registro di trasparenza immutabile. ## Stabilire autorità e autenticità Quando si ha a che fare con i sistemi a catena di fiducia, è importante essere in grado di stabilire l'autorità di un firmatario. O, per dirla in parole povere, il sistema di cui sopra si basa sul fatto che ci si fida della persona che ha firmato il chart. Questo, a sua volta significa che bisogna fidarsi della chiave pubblica del firmatario. Una delle decisioni progettuali di Helm è stata quella di non inserirsi nella catena di fiducia come una parte necessaria. Non vogliamo essere "l'autorità di certificazione" per tutti i firmatari di chart. Al contrario, siamo decisamente favorevoli a un modello decentralizzato, e questo è uno dei motivi per cui abbiamo scelto OpenPGP come tecnologia di base. Quindi, quando si tratta di stabilire l'autorità, abbiamo lasciato questo passo più o meno indefinito in Helm 2 (una decisione portata avanti in Helm 3). Tuttavia, abbiamo alcune indicazioni e raccomandazioni per coloro che sono interessati a utilizzare il sistema di provenienza: - La piattaforma [Keybase](https://keybase.io) fornisce un archivio pubblico centralizzato per le informazioni sulla fiducia. - È possibile utilizzare Keybase per memorizzare le proprie chiavi o per ottenere le chiavi pubbliche di altri. - Keybase ha anche una favolosa documentazione disponibile - Anche se non l'abbiamo testata, la funzione "sito web sicuro" di Keybase potrebbe essere usata per fornire i chart di Helm. - L'idea di base è che un "revisore di chart" ufficiale firmi i chart con la sua chiave e il file di provenienza risultante venga caricato nel chart repository. - Si è lavorato sull'idea che un elenco di chiavi di firma valide possa essere incluso nel file `index.yaml` di un repository. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: "Role-based Access Control" description: "Spiega come Helm interagisce con il Role-Based Access Control di Kubernetes." weight: 11 --- In Kubernetes, l'assegnazione di ruoli a un utente o a un account di servizio specifico per un'applicazione è una pratica ottimale per garantire che l'applicazione operi nell'ambito specificato. Per saperne di più sui permessi dei service account leggere la [ documentazione ufficiale di Kubernetes] (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). A partire da Kubernetes 1.6, il Role-based Access Control è abilitato per impostazione predefinita. RBAC consente di specificare quali tipi di azioni sono consentite a seconda dell'utente e del suo ruolo nell'organizzazione. Con RBAC, è possibile - concedere operazioni privilegiate (creazione di risorse a livello di cluster, come nuovi ruoli) agli amministratori - limitare la capacità di un utente di creare risorse (pod, volumi persistenti, deployment) a specifici namespace o in ambiti a livello di cluster (quote di risorse, ruoli, definizioni di risorse personalizzate). - limitare la capacità di un utente di visualizzare le risorse in namespace specifici o a livello di cluster. Questa guida è destinata agli amministratori che desiderano limitare l'ambito di interazione di un utente con l'API Kubernetes. ## Gestione degli account utente Tutti i cluster Kubernetes hanno due categorie di utenti: i service accounts gestiti da Kubernetes e gli utenti normali. Si presume che gli utenti normali siano gestiti da un servizio esterno e indipendente. Un amministratore che distribuisce le chiavi private, uno user store come Keystone o Google Accounts, persino un file con un elenco di nomi utente e password. A questo proposito, Kubernetes non dispone di oggetti che rappresentano i normali account utente. Gli utenti normali non possono essere aggiunti a un cluster tramite una chiamata API. Al contrario, i service account sono utenti gestiti dall'API di Kubernetes. Sono vincolati a specifici namespace e creati automaticamente dal server API o manualmente tramite chiamate API. I service account sono legati a un insieme di credenziali memorizzate come Secrets, che vengono montate nei pod e che consentono ai processi in cluster di interagire con l'API di Kubernetes. Le richieste API sono legate a un utente normale o a un service account, oppure sono trattate come richieste anonime. Questo significa che ogni processo all'interno o all'esterno del cluster, dall'utente umano che digita `kubectl` su una workstation, alle kubelets sui nodi, ai membri del sistema di controllo devono autenticarsi quando effettuano richieste al server API, o essere trattato come un utente anonimo. ## Ruoli, ClusterRoles, RoleBindings e ClusterRoleBindings In Kubernetes, gli account utente e i service account possono visualizzare e modificare solo le risorse a cui è stato concesso l'accesso. Questo accesso viene concesso attraverso l'uso di Ruoli e RoleBindings. I ruoli e i RoleBindings sono vincolati a un particolare namespace, che concedono agli utenti la possibilità di visualizzare e/o modificare le risorse all'interno di quel namespace a cui il ruolo fornisce l'accesso. A livello di cluster, questi sono chiamati ClusterRoles e ClusterRoleBindings. La concessione di un ClusterRole a un utente garantisce l'accesso alla visualizzazione e/o alla modifica di risorse nell'intero cluster. È inoltre necessario per visualizzare e/o modificare le risorse a livello del cluster (namespace, quote di risorse, nodi). I ClusterRole possono essere vincolati a un particolare namespace attraverso un riferimento in un RoleBinding. I ClusterRoles predefiniti `admin`, `edit` e `view` sono comunemente utilizzati in questo modo. Questi sono alcuni ClusterRoles disponibili di default in Kubernetes. Sono intesi come ruoli rivolti all'utente. Includono i ruoli di super-utente (`cluster-admin`) e ruoli con accesso più granulare (`admin`, `edit`, `view`). | Default ClusterRole | Default ClusterRoleBinding | Description |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` group | Consente l'accesso al superutente per eseguire qualsiasi azione su qualsiasi risorsa. Se usato in un ClusterRoleBinding, dà il pieno controllo su ogni risorsa del cluster e su tutti i namespace. Se usato in un RoleBinding, dà il pieno controllo su ogni risorsa nel namespace del rolebinding, compreso namespace stesso. | `admin` | Nessuno | Consente l'accesso come amministratore, da concedere all'interno di un namespace utilizzando un RoleBinding. Se usato in un RoleBinding, consente l'accesso in lettura/scrittura alla maggior parte delle risorse di un namespace, compresa la possibilità di creare ruoli e rolebindings all'interno del namespace. Non consente l'accesso in scrittura alla quota di risorse o al namespace stesso. | `edit` | Nessuno | Consente l'accesso in lettura/scrittura alla maggior parte degli oggetti di un namespace. Non consente di visualizzare o modificare i ruoli o i rolebindings. | `view` | Nessuno | Consente l'accesso in sola lettura alla maggior parte degli oggetti di un namespace. Non consente di visualizzare i ruoli o i rolebindings. Non consente di visualizzare i secret, poiché questi sono a valore elevato. ## Limitare l'accesso di un account utente utilizzando RBAC Ora che abbiamo compreso le basi del controllo degli accessi basato sui ruoli, discutiamo di come un amministratore può limitare l'accesso di un utente. ### Esempio: Concedere a un utente l'accesso in lettura/scrittura a un particolare namespace Per limitare l'accesso di un utente a un particolare namespace, si può usare il ruolo `edit` o il ruolo `admin`. Se i vostri chart creano o interagiscono con i Ruoli e i Rolebindings, si vorrà utilizzare il ClusterRole `admin`. Inoltre, è possibile creare un RoleBinding con accesso `cluster-admin`. Concedere a un utente l'accesso `cluster-admin` all'ambito del namespace fornisce il pieno controllo su tutte le risorse del namespace, compreso il namespace stesso. In questo esempio, creeremo un utente con il ruolo `edit`. Per prima cosa, creare il namespace: ```console $ kubectl create namespace foo ``` Ora, creare un RoleBinding in questo namespace, assegnando all'utente il ruolo `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Esempio: Concedere a un utente l'accesso in lettura/scrittura all'ambito del cluster Se un utente desidera installare un chart che installa risorse di ambito cluster (namespace, ruoli, definizioni di risorse personalizzate, ecc.) necessita di accesso in scrittura all'ambito del cluster. Per farlo, si deve concedere all'utente l'accesso `admin` o `cluster-admin`. Concedere a un utente l'accesso `cluster-admin` garantisce l'accesso a tutte le risorse disponibili in Kubernetes, compreso l'accesso ai nodi con `kubectl drain` e altri compiti amministrativi. Si raccomanda vivamente di considerare di fornire all'utente l'accesso `admin` o di creare un ClusterRole personalizzato per le sue esigenze. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Esempio: Concedere a un utente l'accesso in sola lettura a un particolare spazio dei nomi Si sarà notato che non c'è un ClusterRole disponibile per visualizzare i secret. Il ClusterRole `view` non concede a un utente l'accesso in lettura ai secret, per motivi di escalation. Helm memorizza i metadati di rilascio come secret per impostazione predefinita. Per poter eseguire `helm list`, un utente deve essere in grado di leggere i secret. Per questo, si creerà uno speciale ClusterRole `secret-reader`. Creare il file `cluster-role-secret-reader.yaml` e scrivervi il seguente contenuto nel file: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Quindi, creare il ClusterRole usando ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Una volta fatto questo, possiamo concedere a un utente l'accesso in lettura alla maggior parte delle risorse, e poi l'accesso in lettura ai secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Esempio: Concedere a un utente l'accesso in sola lettura all'ambito del cluster In alcuni scenari, può essere utile concedere a un utente l'accesso all'ambito del cluster. Ad esempio, se un utente vuole eseguire il comando `helm list --all-namespaces`, l'API richiede che l'utente abbia accesso in lettura all'ambito del cluster. Per farlo, si deve concedere all'utente l'accesso `view` e `secret-reader` come descritto sopra, ma con un ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Riflessioni aggiuntive Gli esempi mostrati sopra utilizzano i ClusterRoles predefiniti forniti con Kubernetes. Per un controllo più dettagliato sulle risorse a cui gli utenti hanno accesso, si può consultare [la documentazione di Kubernetes https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sulla creazione di Roles e ClusterRoles personalizzati. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: "Utilizzare registry OCI-based" description: "Descrive come utilizzare OCI per la distribuzione dei chart." weight: 7 --- A partire da Helm 3, è possibile utilizzare i registry dei container con supporto [OCI](https://www.opencontainers.org/) per memorizzare e condividere i pacchetti di chart. A partire da Helm v3.8.0, il supporto OCI è abilitato per impostazione predefinita. ## Supporto OCI prima della v3.8.0 Con Helm v3.8.0 il supporto OCI è passato da sperimentale a disponibile in generale. Nelle versioni precedenti di Helm, il supporto OCI si comportava in modo diverso. Se si utilizzava il supporto OCI prima di Helm v3.8.0, è importante capire cosa è cambiato con le diverse versioni di Helm. ### Abilitazione del supporto OCI prima della v3.8.0 Prima di Helm v3.8.0, il supporto OCI è *sperimentale* e deve essere abilitato. Per abilitare il supporto sperimentale di OCI per le versioni di Helm precedenti alla v3.8.0, impostare la variabile d'ambiente `HELM_EXPERIMENTAL_OCI`. Ad esempio: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Deprecazione di funzioni OCI e cambiamenti di comportamento con la versione 3.8.0 Con il rilascio di [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), le seguenti caratteristiche e comportamenti sono diversi dalle versioni precedenti di Helm: - Quando si imposta un chart nelle dipendenze come OCI, la versione può essere impostata su un intervallo come le altre dipendenze. - I tag SemVer che includono informazioni sulla compilazione possono essere pushed e utilizzati. I registries OCI non supportano il carattere `+` come tag. Helm traduce il `+` in `_` quando viene memorizzato come tag. - Il comando `helm registry login` segue ora la stessa struttura della Docker CLI per la memorizzazione delle credenziali. Lo stesso path per la configurazione del registry può essere passato sia a Helm che alla Docker CLI. ### Deprecazione di funzioni OCI e cambiamenti di comportamento con la v3.7.0 Il rilascio di [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) ha incluso l'implementazione di [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) per il supporto di OCI. Di conseguenza, le seguenti caratteristiche e comportamenti sono diversi dalle versioni precedenti di Helm: - Il sottocomando `helm chart` è stato rimosso. - La cache dei chart è stata rimossa (niente `helm chart list` ecc.). - I riferimenti al registry OCI sono ora sempre preceduti da `oci://`. - Il nome di base del riferimento al registry deve *sempre* corrispondere al nome del chart. - Il tag del riferimento al registry deve *sempre* corrispondere alla versione semantica del chart (quindi nessun tag `latest`). - Il tipo di supporto del chart è stato cambiato da `application/tar+gzip` a `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Utilizzo di un registry OCI-based ### Helm repositories in registry OCI-based Un [repository Helm] ({{< ref "chart_repository.md" >}}) è un modo per ospitare e distribuire i chart Helm pacchettizzati. Un registry basato su OCI può contenere zero o più repository Helm e ognuno di questi repository può contenere zero o più chart Helm pacchettizzati. ### Use hosted registries Esistono diversi registri di container ospitati con supporto OCI che si possono usare per i chart di Helm. Ad esempio: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) Seguire la documentazione del fornitore del container registry ospitati per creare e configurare un registry con supporto OCI. **Nota:** È possibile eseguire [Docker Registry](https://docs.docker.com/registry/deploying/) o [`zot`](https://github.com/project-zot/zot), che sono registries basati su OCI, sul computer di sviluppo. L'esecuzione di un registry basato su OCI sul computer di sviluppo deve essere utilizzata solo a scopo di test. ### Usare sigstore per firmare i chart basati su OCI Il plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permette di usare [Sigstore](https://sigstore.dev/) per firmare i chart Helm con gli stessi strumenti usati per firmare le immagini dei container. Questo fornisce un'alternativa alla [Provenienza basata su GPG]({{< ref "provenance.md" >}}) supportata dai classici [chart repository]({{< ref "chart_repository.md" >}}). Per maggiori dettagli sull'uso del plugin `helm sigstore`, vedere [la documentazione del progetto](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Comandi per lavorare con i registries ### il sottocomando `registry` #### `login` accesso a un registry (con inserimento manuale della password) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` logout da un registry ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Il sottocomando `push` Carica un chart in un registry basato su OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Il sottocomando `push` può essere utilizzato solo per i file `.tgz creati in anticipo con `helm package`. Quando si usa `helm push` per caricare un chart in un registro OCI, il riferimento deve essere preceduto da `oci://` e non deve contenere il nome di base o il tag. Il nome di base del registry viene dedotto dal nome del chart, e il tag viene dedotto dalla versione semantica del chart. Questo è attualmente un requisito rigoroso. Alcuni registry richiedono che il repository e/o lo spazio dei nomi (se specificato). siano stati creati in precedenza. In caso contrario, verrà prodotto un errore durante l'operazione `helm push`. Se è stato creato un [file di provenienza] ({{< ref "provenance.md" >}}) (`.prov`), ed è presente accanto al file `.tgz` del chart, esso sarà automaticamente caricato nel registry al momento del `push`. Questo comporta un livello in più nel [Helm chart manifest] (#helm-chart-manifest). Gli utenti del plugin [helm-push](https://github.com/chartmuseum/helm-push) (per caricare i chart su [ChartMuseum]({{< ref "chart_repository.md" >}}#chartmuseum-repository-server)) potrebbe avere dei problemi, poiché il plugin va in conflitto con il nuovo `push` integrato. A partire dalla versione v0.10.0, il plugin è stato rinominato in `cm-push`. ### Altri sottocomandi Il supporto per il protocollo `oci://` è disponibile anche in vari altri sottocomandi. Ecco un elenco completo: - `helm pull` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Il nome di base (nome del chart) del riferimento al registry *è* incluso in ogni tipo di azione che comporta il download di un chart (rispetto a `helm push` dove viene omesso). Ecco alcuni esempi di utilizzo dei sottocomandi sopra elencati contro grafici basati su OCI: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Specificare le dipendenze Le dipendenze di un chart possono essere recuperate da un registry usando il sottocomando `dependency update`. Il `repository` per una data voce in `Chart.yaml` è specificato come riferimento al registry senza il nome di base: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Questo recupererà `oci://localhost:5000/myrepo/mychart:2.7.0` quando viene eseguito `dependency update`. ## Helm chart manifest Esempio di manifest del chart Helm rappresentato in un registry (notare i campi `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Il seguente esempio contiene un [provenance file]({{< ref "provenance.md" >}}) (notare il layer extra): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migrazione da un chart repo La migrazione dai classici [chart repository]({{< ref "chart_repository.md" >}}) (repository basati su index.yaml) è semplice usando `helm pull`, poi `helm push` per caricare i file `.tgz` in un registry. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/release_policy.md ================================================ --- title: "Politica sui rilasci pianificati" description: "Descrive la politica dei programmi di rilascio di Helm." --- A beneficio dei suoi utenti, Helm definisce e annuncia in anticipo le date di rilascio. Questo documento descrive la politica che regola il programma di rilascio di Helm. ## Calendario dei rilasci Il calendario pubblico dei prossimi rilasci di Helm è disponibile [qui] (https://helm.sh/calendar/release). ## Versioni semantiche Le versioni di Helm sono espresse come `x.y.z`, dove `x` è la versione maggiore, `y` è la versione minore e `z` è la versione della patch, secondo [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## Rilasci di patch Le patch release forniscono agli utenti correzioni di bug e di sicurezza. Non contengono nuove funzionalità. Il rilascio di una nuova patch relativa all'ultima minor/major release avverrà di norma una volta al mese, il secondo mercoledì di ogni mese. Un rilascio di patch per correggere una regressione ad alta priorità o un problema di sicurezza può essere effettuato ogni volta che è necessario. Il rilascio di una patch sarà annullato per uno dei seguenti motivi: - se non ci sono nuovi contenuti dal rilascio precedente - se la data di rilascio della patch cade una settimana prima della release candidate (RC1) di una prossima release minore - se la data di rilascio della patch cade entro le quattro settimane successive a una release minore ## Rilasci minori I rilasci minori contengono correzioni di sicurezza e bug, oltre a nuove funzionalità. Sono retrocompatibili per quanto riguarda l'API e l'uso della CLI. Per allinearsi con i rilasci di Kubernetes, verrà rilasciata una minor release di helm ogni 4 mesi (3 release all'anno). Se necessario, è possibile effettuare ulteriori rilasci minori, che non influenzeranno la tempistica di un rilascio futuro annunciato, a meno che la release annunciata non sia a meno di 7 giorni di distanza. In concomitanza con la pubblicazione di una release, la data della prossima release minore sarà annunciata e pubblicata sulla pagina web principale di Helm. ## Rilasci maggiori Le versioni maggiori contengono cambiamenti radicali. Tali rilasci sono rari, ma a volte sono necessarie per consentire a helm di continuare a evolversi in nuove e importanti direzioni. Le major release possono essere difficili da pianificare. Per questo motivo, la data di rilascio finale definitiva sarà scelta e annunciata solo dopo che sarà disponibile la prima versione beta di tale release. ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: "Migrazione Helm da v2 a v3" description: "Scoprite come migrare Helm da v2 a v3." weight: 13 --- Questa guida mostra come migrare Helm da v2 a v3. Helm v2 deve essere installato e gestire le release in uno o più cluster. ## Panoramica dei cambiamenti di Helm 3 L'elenco completo dei cambiamenti da Helm 2 a 3 è documentato nella sezione [FAQ](https://v3.helm.sh/docs/faq/#changes-since-helm-2). Di seguito è riportato un estratto di alcuni di questi cambiamenti che l'utente dovrebbe conoscere prima e durante la migrazione: 1. Rimozione di Tiller: - Sostituisce l'architettura client/server con quella client/library (solo binary `helm`). - La sicurezza è ora basata sull'utente (delegata al cluster di utenti Kubernetes). - I rilasci sono ora memorizzati come secrets all'interno del cluster e i metadati dell'oggetto release sono cambiati. - I rilasci sono persistiti in base al namespace della release e non più nel Tiller namespace. 2. Aggiornamento del repository dei chart: - `helm search` ora supporta sia la ricerca nel repository locale che l'esecuzione di query di ricerca nell'Hub degli artefatti 3. Chart apiVersion spostato a "v2" per le modifiche alle specifiche: - Dipendenze del chart collegate dinamicamente spostate in `Chart.yaml`. (`requirements.yaml` rimosso e requisiti --> dipendenze) - I library chart (chart helper/comuni) possono ora essere aggiunti come dipendenze di chart collegati dinamicamente - I chart hanno un campo di metadati `type` per definire che il chart è di tipo "applicazione" o "libreria". È un'applicazione per impostazione predefinita, il che significa che è renderizzabile e installabile - I chart di Helm 2 (apiVersion=v1) sono ancora installabili. 4. Aggiunta della specifica di directory XDG: - La home di Helm è stata rimossa e sostituita con una specifica di directory XDG per la memorizzazione dei file di configurazione. - Non è più necessario inizializzare Helm - Rimossi `helm init` e `helm home`. 5. Ulteriori modifiche: - L'installazione/set-up di Helm è semplificata: - Solo client Helm (helm binary) (senza Tiller). - Paradigma Run-as-is - i repository `local` o `stable` non sono impostati di default - L'hook `crd-install` è stato rimosso e sostituito con la directory `crds` in chart dove tutti i CRD in essa definiti saranno installati prima di qualsiasi rendering del chart. - il valore dell'annotazione del hook `test-failure` è stato rimosso e `test-success` è stato deprecato. Usare invece `test` - Comandi rimossi/sostituiti/aggiunti: - delete --> uninstall : rimuove tutta la cronologia dei rilasci per impostazione predefinita (in precedenza era necessario `--purge`) - fetch --> pull - home (rimosso) - init (rimosso) - install: richiede il nome della release o l'argomento `--generate-name`. - inspect --> show - reset (rimosso) - serve (rimosso) - template: l'argomento `-x`/`--execute` è stato rinominato in `-s`/`--show-only`. - upgrade: Aggiunto l'argomento `--history-max` che limita il numero massimo di revisioni salvate per rilascio (0 per nessun limite) - La libreria Go di Helm 3 ha subito molte modifiche ed è incompatibile con la libreria Helm 2 - I binari di rilascio sono ora ospitati su `get.helm.sh`. ## Casi d'uso per migrazione I casi d'uso della migrazione sono i seguenti: 1. Helm v2 e v3 gestiscono lo stesso cluster: - Questo caso d'uso è consigliato solo se si intende eliminare gradualmente Helm v2 e non si richiede a v3 di gestire le release distribuite da v2. Tutte le nuove release in fase di distribuzione dovrebbero essere eseguite dalla v3 e le release esistenti distribuite dalla v2 esistenti sono aggiornate/rimosse solo dalla v2. - Helm v2 e v3 possono tranquillamente gestire lo stesso cluster. Le versioni di Helm possono essere installate sullo stesso sistema o su sistemi separati - Se si installa Helm v3 sullo stesso sistema, è necessario eseguire un passaggio aggiuntivo per garantire che entrambe le versioni del client possano coesistere fino alla rimozione del client Helm v2.Rinominare o collocare il binario di Helm v3 in una cartella diversa per evitare conflitti. - Altrimenti non ci sono conflitti tra le due versioni grazie alle seguenti distinzioni: - I file di archiviazione delle release (cronologia) v2 e v3 sono indipendenti l'uno dall'altro. Le modifiche includono la risorsa Kubernetes per la memorizzazione e i metadati dell'oggetto contenuti nella risorsa. I rilasci saranno anche su un namespace per utente invece di utilizzare namespace di Tiller (ad esempio, v2 namespace predefinito di Tiller kube-system). v2 utilizza "ConfigMaps" o "Secrets" sotto namespace Tiller e la ownership `TILLER`. v3 usa "Secrets" nel namespace utente e ownership `helm`. I rilasci sono incrementali sia in v2 e v3 - L'unico problema potrebbe esserci se le risorse Kubernetes con scope di cluster (ad es. `clusterroles.rbac`) sono definite in un chart. La distribuzione v3 fallirebbe anche se unico nel namespace, perché le risorse si scontrerebbero. - La configurazione della v3 non usa più `$HELM_HOME` e utilizza invece le specifiche delle directory XDG Viene anche creata al volo, se necessario. È quindi indipendente dalla configurazione v2. Questo è applicabile solo quando entrambe le versioni sono installate sullo stesso sistema 2. Migrazione di Helm v2 a Helm v3: - Questo caso d'uso si applica quando si desidera che Helm v3 gestisca le release Helm v2 esistenti. - Va notato che un client Helm v2: - può gestire da 1 a molti cluster Kubernetes - può connettersi a 1 o più istanze di Tiller per un cluster. - Questo significa che bisogna essere consapevoli di questo quando si esegue la migrazione, in quanto le release vengono distribuite nei cluster da Tiller e dal suo namespace. È necessario quindi essere consapevoli della migrazione per ogni cluster e ogni istanza Tiller gestita dall'istanza del client Helm v2. - Il percorso di migrazione dei dati consigliato è il seguente: 1. Backup dei dati v2 2. Migrare la configurazione di Helm v2 3. Migrare le release di Helm v2 4. Quando si è certi che Helm v3 stia gestendo tutti i dati di Helm v2 (per tutti i cluster e le istanze Tiller dell'istanza client di Helm v2) come ci si aspetta, si procede alla pulizia dei dati di Helm v2. - Il processo di migrazione è automatizzato da Helm v3 [2to3](https://github.com/helm/helm-2to3). ## Riferimenti - Plugin Helm v3 [2to3](https://github.com/helm/helm-2to3) - Blog [post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) che spiega l'uso del plugin `2to3` con degli esempi ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Helm Version Support Policy" description: "Descrive la politica di rilascio delle patch di Helm e lo scostamento massimo di versione supportato tra Helm e Kubernetes." --- Questo documento descrive il massimo scarto di versione supportato tra Helm e Kubernetes. ## Versioni supportate Le versioni di Helm sono espresse come `x.y.z`, dove `x` è la versione maggiore, `y` è la versione minore e `z` è la versione della patch, secondo la terminologia di [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Il progetto Helm mantiene un branch di rilascio per la versione minore più recente. Le correzioni applicabili, comprese quelle per la sicurezza, vengono raccolte nel ramo di rilascio, a seconda della gravità e della fattibilità. ## Sfasamento della versione supportata Quando viene rilasciata una nuova versione di Helm, questa viene compilata per una particolare versione minore di Kubernetes. Ad esempio, Helm 3.0.0 interagisce con Kubernetes utilizzando il client Kubernetes 1.16.2, quindi è compatibile con Kubernetes 1.16. A partire da Helm 3, si presume che Helm sia compatibile con `n-3` versioni di Kubernetes con cui è stato compilato. A causa dei cambiamenti di Kubernetes tra le versioni minori, la politica di supporto di Helm 2 è leggermente più restrittiva, in quanto si presume che sia compatibile con `n-1` versioni di Kubernetes. Ad esempio, se si utilizza una versione di Helm 3 compilata con la versione client di API Kubernetes 1.17, allora dovrebbe essere sicuro l'utilizzo con Kubernetes 1.17, 1.16, 1.15 e 1.14. Se si sta utilizzando una versione di Helm 2 compilata con le API client di Kubernetes 1.16, dovrebbe essere sicuro l'uso con Kubernetes 1.16 e 1.15. Non è consigliabile utilizzare Helm con una versione di Kubernetes più recente di quella con cui è stato compilato in quanto Helm non fornisce alcuna garanzia di compatibilità. Se si sceglie di utilizzare Helm con una versione di Kubernetes non supportata, l'utilizzo avviene a proprio rischio e pericolo. Per determinare quale versione di Helm è compatibile con il vostro cluster, consultate la tabella seguente. | Helm Version | Supported Kubernetes Versions | |--------------|-------------------------------| | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/it/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Introduzione", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "How-to", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Topics", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Best Practices", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Guida ai Chart Template", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandi Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Community", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Frequently Asked Questions", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/it/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Helm Project", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Sviluppo", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Community", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Codice sorgente", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Blog", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Eventi", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Codice di condotta", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Introduzione", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Chart tips & tricks", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Sviluppo Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Cerca 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Guida alla contribuzione", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Maintainers", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Riunioni settimanali", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "GitHub Community", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "

Siamo un progetto graduated della Cloud Native Computing Foundation.

© Helm Authors 2025. Documentazione distribuita sotto licenza CC-BY-4.0.

© 2025 The Linux Foundation. Tutti i diritti riservati. The Linux Foundation ha registrato marchi commerciali e utilizza marchi commerciali. Per una lista dei marchi commerciali de The Linux Foundation, per favore visita la nostra pagina Uso Marchi Commerciali.

", "description": "The footer copyright" }, "logo.alt": { "message": "CNCF Logo", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/it/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Helm Logo", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Docs", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Blog", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Community", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/ja/code.json ================================================ { "home.about.whatIsHelm": { "message": "Helmは、Kubernetesアプリケーションの管理を支援します。Helm Chartsは、最も複雑なKubernetesアプリケーションでも定義、インストール、アップグレードができます。", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Chartsは簡単に作成、バージョン管理、共有、公開ができます。Helmを使い始めて、コピー&ペーストをやめましょう。", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helmは{cncfLink}の卒業プロジェクトで、{helmCommunityLink}によって維持されています。", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "Helmコミュニティ", "description": "Helm community link" }, "home.about.learnMore": { "message": "詳細はこちら:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Helmアーキテクチャ", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "クイックスタートガイド", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "ビデオ: Helmの紹介", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Helmとは？", "description": "What is Helm? title" }, "home.features.manageComplexity": { "message": "複雑性の管理", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Chartsは最も複雑なアプリケーションでも記述し、再現可能なアプリケーションのインストールを提供し、単一の権威ポイントとして機能します。", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "簡単なアップデート", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "インプレースアップグレードとカスタムフックで、アップデートの苦痛を取り除きます。", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "シンプルな共有", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Chartsは簡単にバージョン管理、共有でき、パブリックまたはプライベートサーバーでホストできます。", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "ロールバック", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "{helmRollback}を使用して、リリースの古いバージョンに簡単にロールバックできます。", "description": "Rollbacks section description" }, "home.features.title": { "message": "機能", "description": "Features section title" }, "home.community.nextFeatureRelease": { "message": "次回の機能リリース", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "バージョン:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "日付:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "リリースカレンダー", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "今後のイベント", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "今後のイベント", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "過去のイベント", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "彼らは{meetLink}ツールやプロジェクトのデモと議論を行います。コミュニティミーティングは記録され{youtubeLink}。", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "毎週集まって", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "YouTubeで共有されます", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "開発者スタンドアップ" }, "home.community.developerStandups.time": { "message": "木曜日 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "これらのミーティングはすべての人に公開されています。メモや詳細については{communityRepoLink}を確認してください。", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "コミュニティリポジトリ", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Helmの使用、Chartsの作業、一般的なエラーの解決に関するディスカッション。", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Helm開発、進行中のPR、リリースなどに関するトピック。", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Helm Chartsのユーザーとコントリビューターのためのディスカッション。", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "Kubernetes Slackチームに参加するには{slackLink}。", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "こちらからアクセスをリクエスト", "description": "Request access to slack link" }, "home.community.contributing": { "message": "貢献する", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helmはプロジェクトへの新しい貢献をいつでも歓迎します！", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "どこから始めればいいですか？", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helmは多くのユーザーとコントリビューターを持つ大きなプロジェクトです。理解するのは大変かもしれません！", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "助けたいけれどどこから始めればいいかわからない場合は、{goodFirstIssuesLink}のリストがあります。", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "初心者向けのissue", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "何をすればいいですか？", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "コードを貢献する前に、{contributionGuideLink}をお読みください。プルリクエストの作成とレビューのプロセスについて説明しています。", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "貢献ガイド", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "コードを書いた後、Helmが{cncfLink}で使用される{dcoLink}契約に準拠していることを確認するために、{signYourCommitsLink}してください。", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "コミットに署名", "description": "Sign your commits link" }, "home.community.title": { "message": "コミュニティに参加", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Helmプロジェクトと貢献方法に関する詳細情報。", "description": "Join the Community subtitle" }, "home.gettingStarted.title": { "message": "はじめに", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "ヘルムを入手！", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "パッケージマネージャーでHelmをインストールするか、{downloadLink}してください。", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "バイナリをダウンロード", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "インストールしたら、helmバイナリを解凍してPATHに追加すれば準備完了です！詳細な{installationLink}と{usageLink}については{docsLink}を確認してください。", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "ドキュメント", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "インストール手順", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "使用手順", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Chartsを入手", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "{artifactHubLink}にアクセスして、多数のパブリックリポジトリから{helmChartsLink}を探索してください。", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "home.header.tagline": { "message": "Kubernetes用パッケージマネージャー", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helmは、Kubernetes向けに構築されたソフトウェアを検索、共有、使用するための最良の方法です", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "エラーが発生しました", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "先頭へ戻る", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "アーカイブ", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "アーカイブ", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "ブログ記事一覧のナビゲーション", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "新しい記事", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "過去の記事", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "ブログ記事のナビゲーション", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "新しい記事", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "過去の記事", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "全てのタグを見る", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "システムモード", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "ライトモード", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "ダークモード", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "ダークモードを切り替える(現在は{mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "パンくずリストのナビゲーション", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "{count}項目", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "ドキュメントページ", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "前へ", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "次へ", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "{count}記事", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "「{tagName}」タグのついた{nDocsTagged}", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "バージョン: {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "これはリリース前のバージョン{versionLabel}の{siteTitle}のドキュメントです。", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "これはバージョン{versionLabel}の{siteTitle}のドキュメントで現在はメンテナンスされていません", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "最新のドキュメントは{latestVersionLink} ({versionLabel}) を見てください", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "最新バージョン", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { "message": "このページを編集", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "{heading} への直接リンク", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": "{date}に", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": "{user}が", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "{atDate}{byUser}最終更新", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "他のバージョン", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.NotFound.title": { "message": "ページが見つかりません", "description": "The title of the 404 page" }, "theme.tags.tagsListLabel": { "message": "タグ:", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "閉じる", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "注意", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "危険", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "備考", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "注記", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "ヒント", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "警告", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.blog.sidebar.navAriaLabel": { "message": "最近のブログ記事のナビゲーション", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "'{label}'の目次を開く", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "'{label}'の目次を隠す", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(新しいタブで開きます)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "ナビゲーション", "description": "The ARIA label for the main navigation" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "他の言語", "description": "The label for the mobile language switcher dropdown" }, "theme.NotFound.p1": { "message": "お探しのページが見つかりませんでした", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "このページにリンクしているサイトの所有者にリンクが壊れていることを伝えてください", "description": "The 2nd paragraph of the 404 page" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "このページの見出し", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "もっと見る", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "{title}についてもっと見る", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "約{readingTime}分", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "コピー", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "コピーしました", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "クリップボードにコードをコピー", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "折り返し", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "ホームページ", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "ドキュメントのサイドバー", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "サイドバーを隠す", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "サイドバーを隠す", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "ナビゲーションバーを閉じる", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← メインメニューに戻る", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "ナビゲーションバーを開く", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "ドロップダウンを開く", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "ドロップダウンを閉じる", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "サイドバーを開く", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "サイドバーを開く", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "{count}件", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "「{tagName}」タグの記事が{nPosts}件あります", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "著者一覧", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "すべての著者を見る", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "この著者による投稿はまだありません。", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "非公開のページ", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "このページは非公開です。 検索対象外となり、このページのリンクに直接アクセスできるユーザーのみに公開されます。", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "下書きのページ", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "このページは下書きです。開発環境でのみ表示され、本番環境のビルドには含まれません。", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "もう一度試してください", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "メインコンテンツまでスキップ", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "タグ", "description": "The title of the tag list page" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "ブログ", "description": "The title for the blog used in SEO" }, "description": { "message": "ブログ", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "すべての投稿", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Helmの使用", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helmコマンド", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "チャート", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "テンプレートの開発", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "ベストプラクティス", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: 一般的な規約 description: chart の一般的な規約について説明します。 sidebar_position: 1 --- ベストプラクティスガイドのこの部分では、一般的な規約について説明します。 ## chart 名 chart 名は英小文字と数字で構成する必要があります。単語はダッシュ（-）で区切ることが _できます_ 。 例: ``` drupal nginx-lego aws-cluster-autoscaler ``` 英大文字やアンダースコアは chart 名に使用できません。ドットも chart 名には使用しないでください。 ## バージョン番号 Helm は可能な限り [SemVer 2](https://semver.org) を使用してバージョン番号を表現します。（Docker イメージタグは必ずしも SemVer に従わないため、この規則の例外と見なされています。） SemVer バージョンを Kubernetes ラベルに保存する場合、`+` 文字を `_` に置き換える慣習があります。ラベルの値として `+` 記号が許可されていないためです。 ## YAML のフォーマット YAML ファイルは _スペース 2 つ_ でインデントしてください（タブは使用しないでください）。 ## Helm と chart という用語の使い方 _Helm_ および _helm_ という用語の使い方にはいくつかの規約があります。 - _Helm_ はプロジェクト全体を指します - `helm` はクライアントサイドのコマンドを指します - `chart` という用語は固有名詞ではないため、大文字にする必要はありません - ただし、ファイル名は大文字小文字を区別するため、`Chart.yaml` は正確に記述する必要があります 迷った場合は、_Helm_（大文字の「H」）を使用してください。 ## chart テンプレートと namespace chart テンプレートの `metadata` セクションで `namespace` プロパティを定義することは避けてください。レンダリングされたテンプレートを適用する namespace は、`--namespace` などのフラグを通じて Kubernetes クライアントへの呼び出し時に指定してください。Helm はテンプレートをそのままレンダリングして、Kubernetes クライアント（Helm 自身、kubectl、flux、spinnaker など）に送信します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: カスタムリソース定義 description: CRDの作成と使用方法について解説します。 sidebar_position: 7 --- ベストプラクティスガイドのこのセクションでは、カスタムリソース定義オブジェクトの作成と使用方法について説明します。 カスタムリソース定義（CRD）を扱う場合、2つの異なる要素を区別することが重要です。 - CRDの宣言。kind が `CustomResourceDefinition` である YAML ファイルです。 - CRDを _使用する_ リソース。例えば、CRD が `foo.example.com/v1` を定義するとします。`apiVersion: example.com/v1` かつ kind `Foo` を持つリソースは、その CRD を使用するリソースです。 ## リソースを使用する前に CRD 宣言をインストールする Helm は Kubernetes にできるだけ多くのリソースを高速にロードできるよう最適化されています。Kubernetes は設計上、マニフェストのセット全体を受け取り、それらをすべてオンラインにできます（これは reconciliation loop と呼ばれます）。 しかし CRD には違いがあります。 CRD を使用するには、その CRD の kind を持つリソースを使用する前に、まず CRD の宣言を登録する必要があります。この登録処理には数秒かかることがあります。 ### 方法1: `helm` に任せる Helm 3 の登場により、古い `crd-install` フックは削除され、よりシンプルな方法が採用されました。chart 内に `crds` という特別なディレクトリを作成し、CRD を配置できます。これらの CRD はテンプレート化されませんが、`helm install` を実行するとデフォルトでインストールされます。CRD がすでに存在する場合は、警告とともにスキップされます。CRD のインストール手順をスキップしたい場合は、`--skip-crds` フラグを指定してください。 #### 注意事項（および説明） 現時点では、Helm を使用して CRD をアップグレードまたは削除することはサポートされていません。これは、意図しないデータ損失の危険性があるため、コミュニティで多くの議論が行われた結果、明示的に決定されたものです。さらに、CRD とそのライフサイクルの処理方法については、コミュニティ内でコンセンサスが得られていません。この状況が進展すれば、Helm はこれらのユースケースのサポートを追加する予定です。 `helm install` および `helm upgrade` の `--dry-run` フラグは、CRD ではサポートされていません。ドライランの目的は、chart の出力をサーバーに送信した場合に実際に機能するかを検証することです。しかし、CRD はサーバーの動作を変更するものです。Helm はドライランで CRD をインストールできないため、ディスカバリークライアントはそのカスタムリソース（CR）を認識できず、検証は失敗します。代わりに、CRD を別の chart に分離するか、`helm template` を使用してください。 CRD サポートに関する議論で考慮すべきもう1つの重要な点は、テンプレートのレンダリング処理です。Helm 2 で使用されていた `crd-install` メソッドの明確な欠点の1つは、API の利用可能性が変化するため chart を適切に検証できないことでした（CRD は実際に Kubernetes クラスターに新しい API を追加します）。chart が CRD をインストールすると、`helm` は有効な API バージョンのセットを把握できなくなります。これが CRD のテンプレート化サポートを削除した理由でもあります。新しい `crds` メソッドにより、`helm` がクラスターの現在の状態について完全に有効な情報を持つことが保証されます。 ### 方法2: chart を分離する もう1つの方法は、CRD 定義を1つの chart に配置し、その CRD を使用するリソースを _別の_ chart に配置することです。 この方法では、各 chart を個別にインストールする必要があります。しかし、このワークフローはクラスターへの管理者アクセス権を持つクラスターオペレーターにとってはより有用な場合があります。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: 依存関係 description: Chart の依存関係に関するベストプラクティスを解説します。 sidebar_position: 4 --- ベストプラクティスガイドのこの部分では、`Chart.yaml` で宣言する `dependencies` について解説します。 ## バージョン 可能な限り、特定のバージョンを固定するのではなく、バージョン範囲を使用してください。 推奨されるデフォルトの方法は、パッチレベルでのバージョンマッチです: ```yaml version: ~1.2.3 ``` これはバージョン `1.2.3` およびそのパッチリリースにマッチします。 つまり、`~1.2.3` は `>= 1.2.3, < 1.3.0` と同等です。 バージョンマッチの完全な構文については、[semver documentation](https://github.com/Masterminds/semver#checking-version-constraints) を参照してください。 ### プレリリースバージョン 上記のバージョン制約は、プレリリースバージョンにはマッチしません。 例えば、`version: ~1.2.3` は `version: ~1.2.4` にマッチしますが、`version: ~1.2.3-1` にはマッチしません。 以下の書き方で、パッチレベルだけでなくプレリリースにもマッチさせることができます: ```yaml version: ~1.2.3-0 ``` ### リポジトリ URL 可能な限り `https://` の URL を優先し、次に `http://` の URL を使用してください。 リポジトリがリポジトリインデックスファイルに追加されている場合、リポジトリ名を URL のエイリアスとして使用できます。`alias:` または `@` の後にリポジトリ名を指定してください。 ファイル URL（`file://...`）は、固定のデプロイパイプラインで組み立てられた chart 向けの「特殊なケース」と見なされます。 [ダウンローダープラグイン](/topics/plugins.md#downloader-plugins)を使用する場合、URL スキームはプラグイン固有になります。chart を利用するユーザーは、依存関係を更新またはビルドするために、そのスキームに対応したプラグインをインストールする必要があります。 `repository` フィールドが空の場合、Helm は依存関係の管理操作を実行できません。この場合、Helm は依存関係が `charts` フォルダ内のサブディレクトリにあり、そのディレクトリ名が依存関係の `name` プロパティと同じであると見なします。 ## condition と tag **オプションの**依存関係には、condition または tag を追加してください。`condition` はデフォルトで `true` になることに注意してください。 condition の推奨される書き方: ```yaml condition: somechart.enabled ``` ここで `somechart` は依存関係の chart 名です。 複数のサブチャート（依存関係）が連携してオプションまたは交換可能な機能を提供する場合、これらの chart には同じ tag を設定してください。 例えば、`nginx` と `memcached` の両方が chart 内のメインアプリケーションに対してパフォーマンス最適化を提供し、その機能を有効にするには両方が必要な場合、両方に次のような tags セクションを含めます: ```yaml tags: - webaccelerator ``` これにより、ユーザーは 1 つの tag でその機能のオン・オフを切り替えることができます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: ベストプラクティス sidebar: true sidebar_position: 4 --- # チャートのベストプラクティスガイド このガイドでは、チャートを作成するために Helm チームが検討したベストプラクティスについて説明します。 チャートの構造に焦点を当てています。 主に、公に展開される可能性のあるチャートのベストプラクティスに焦点を当てています。 多くのチャートは内部使用のみであることを認識しており、 そのようなチャートの作成者は、内部の関心がここでの提案をオーバーライドすることに気付く場合があります。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: ラベルとアノテーション description: chart でラベルとアノテーションを使用するためのベストプラクティスを解説します。 sidebar_position: 5 --- ベストプラクティスガイドのこの部分では、chart でのラベルとアノテーションの使い方を説明します。 ## ラベルかアノテーションか？ メタデータの項目は、以下の条件に該当する場合はラベルにしてください: - Kubernetes がリソースを識別するために使用する - システムへのクエリ目的でオペレータに公開すると便利である 例えば、オペレータが特定の chart のすべてのインスタンスを簡単に検索できるように、`helm.sh/chart: NAME-VERSION` をラベルとして使用することを推奨します。 メタデータの項目がクエリ目的で使用されない場合は、代わりにアノテーションを使用してください。 Helm hook は常にアノテーションです。 ## 標準ラベル 以下の表は、Helm chart が使用する一般的なラベルを定義しています。Helm 自体は特定のラベルの存在を必須としていません。REC とマークされたラベルは推奨であり、一貫性のために chart に含める**べき**です。OPT とマークされたラベルは任意です。これらは慣用的に使用されていますが、運用上必須ではありません。 | 名前 | ステータス | 説明 | |------|---------|------| | `app.kubernetes.io/name` | REC | アプリ全体を反映する名前です。通常は `{{ template "name" . }}` を使用します。多くの Kubernetes マニフェストで使用されており、Helm 固有ではありません。 | | `helm.sh/chart` | REC | chart 名とバージョンを設定します: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}` | | `app.kubernetes.io/managed-by` | REC | 常に `{{ .Release.Service }}` に設定します。Helm が管理するリソースの検索に使用されます。 | | `app.kubernetes.io/instance` | REC | `{{ .Release.Name }}` を設定します。同じアプリケーションの異なるインスタンスを区別するのに役立ちます。 | | `app.kubernetes.io/version` | OPT | アプリのバージョンです。`{{ .Chart.AppVersion }}` を設定できます。 | | `app.kubernetes.io/component` | OPT | アプリケーション内の役割を示す一般的なラベルです。例: `app.kubernetes.io/component: frontend` | | `app.kubernetes.io/part-of` | OPT | 複数の chart やソフトウェアが連携して 1 つのアプリケーションを構成する場合に使用します。例: Web サイトを構成するアプリケーションとデータベース。サポートするトップレベルのアプリケーションを設定できます。 | `app.kubernetes.io` プレフィックスが付いた Kubernetes ラベルの詳細については、[Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)を参照してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pod と PodTemplate description: chart マニフェストにおける Pod と PodTemplate 部分のフォーマットについて説明します。 sidebar_position: 6 --- ベストプラクティスガイドのこの部分では、chart マニフェストにおける Pod と PodTemplate 部分のフォーマットについて説明します。 以下のリソース（網羅的ではありません）が PodTemplate を使用します: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## イメージ コンテナイメージには固定されたタグ、またはイメージの SHA を使用してください。`latest`、`head`、`canary` など、常に最新を指すフローティングタグは使用しないでください。 イメージを `values.yaml` ファイルに定義しておくと、簡単に差し替えられます。 ```yaml image: {{ .Values.redisImage | quote }} ``` イメージとタグを `values.yaml` で別々のフィールドとして定義することもできます: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` は、`deployment.yaml` で以下のように記述することで、`imagePullPolicy` をデフォルトで `IfNotPresent` に設定します: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` 同様に、Kubernetes も `imagePullPolicy` が定義されていない場合、デフォルトで `IfNotPresent` を使用します。`IfNotPresent` 以外の値が必要な場合は、`values.yaml` の値を希望する値に更新してください。 ## PodTemplate には selector を宣言する すべての PodTemplate セクションで selector を指定してください。例: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` selector を指定することで、ワークロードリソースと Pod の関係が明確になり、推奨されるプラクティスです。 Deployment などのワークロードリソースでは、これは特に重要です。selector を指定しないと、**すべての**ラベルが一致する Pod の選択に使用されます。バージョンやリリース日など変化するラベルを使用している場合、意図しない動作を引き起こす可能性があります。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: ロールベースアクセス制御 description: Chart マニフェストにおける RBAC リソースの作成とフォーマットについて解説します。 sidebar_position: 8 --- ベストプラクティスガイドのこの部分では、chart マニフェストにおける RBAC リソースの作成とフォーマットについて解説します。 RBAC リソースには以下が含まれます: - ServiceAccount（namespace スコープ） - Role（namespace スコープ） - ClusterRole - RoleBinding（namespace スコープ） - ClusterRoleBinding ## YAML の設定 RBAC と ServiceAccount の設定は、別々のキーで管理してください。 これらは異なる概念であり、YAML 内で分離することで明確になります。 ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` この構造は、複数の ServiceAccount を必要とするより複雑な chart にも拡張できます。 ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC リソースはデフォルトで作成する `rbac.create` は RBAC リソースを作成するかどうかを制御するブール値です。 デフォルト値は `true` にしてください。 RBAC のアクセス制御を自分で管理したいユーザーは、この値を `false` に設定できます（その場合は以下を参照）。 ## RBAC リソースの使用 `serviceAccount.name` には、chart が作成するアクセス制御対象リソースで使用する ServiceAccount の名前を設定します。 - `serviceAccount.create` が true の場合: この名前で ServiceAccount が作成されます。名前が設定されていない場合は、`fullname` テンプレートを使用して名前が生成されます。 - `serviceAccount.create` が false の場合: ServiceAccount は作成されませんが、同じリソースに関連付けられたままにしておく必要があります。これにより、後で手動で作成した RBAC リソースがこの ServiceAccount を参照しても正しく機能します。名前が指定されていない場合は、デフォルトの ServiceAccount が使用されます。 ServiceAccount には以下のヘルパーテンプレートを使用してください。 ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: テンプレート description: テンプレートに関するベストプラクティスを詳しく解説します。 sidebar_position: 3 --- ベストプラクティスガイドのこの部分では、テンプレートについて焦点を当てます。 ## `templates/` の構造 `templates/` ディレクトリは次のように構造化してください: - YAML を出力するテンプレートファイルには `.yaml` 拡張子を使用します。 フォーマットされた内容を出力しないテンプレートファイルには `.tpl` 拡張子を使用できます。 - テンプレートファイル名はキャメルケースではなく、ダッシュ記法（`my-example-configmap.yaml`） を使用します。 - 各リソース定義は個別のテンプレートファイルに配置します。 - テンプレートファイル名にはリソースの種類を含めます。 例: `foo-pod.yaml`、`bar-svc.yaml` ## 定義済みテンプレートの名前 定義済みテンプレート（`{{ define }}` ディレクティブ内で作成されたテンプレート）は グローバルにアクセス可能です。つまり、chart とそのすべてのサブチャートから、 `{{ define }}` で作成されたすべてのテンプレートにアクセスできます。 そのため、_すべての定義済みテンプレート名には namespace を含めてください。_ 正しい書き方: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` 正しくない書き方: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` 新しい chart は `helm create` コマンドで作成することを強く推奨します。 このコマンドを使用すると、テンプレート名がこのベストプラクティスに従って自動的に定義されます。 ## テンプレートのフォーマット テンプレートは _2 つのスペース_ でインデントします（タブは使用しません）。 テンプレートディレクティブでは、開き中括弧の後と閉じ中括弧の前にスペースを入れます: 正しい書き方: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` 正しくない書き方: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` 可能な場合、テンプレートでは空白を削除します: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` ブロック（制御構造など）は、テンプレートコードのフローを示すために インデントできます。 ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` ただし、YAML は空白に依存する言語であるため、コードのインデントが この規則に従えない場合もあります。 ## 生成されるテンプレートの空白 生成されるテンプレートに含まれる空白の量は最小限に抑えるのが望ましいです。 特に、複数の空行が連続して並ぶべきではありません。 ただし、論理的なセクション間などで時折空行を入れることは問題ありません。 ベストな書き方: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 問題のない書き方: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 避けるべき書き方: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## コメント（YAML コメント vs. テンプレートコメント） YAML と Helm テンプレートの両方にコメント記法があります。 YAML コメント: ```yaml # This is a comment type: sprocket ``` テンプレートコメント: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` テンプレートコメントは、テンプレートの機能を文書化する際に使用します。 たとえば、定義済みテンプレートを説明する場合: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` テンプレート内で YAML コメントを使用するのは、Helm ユーザーがデバッグ中に そのコメントを見ると便利な場合です。 ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` 上記のコメントは、ユーザーが `helm install --debug` を実行したときに表示されます。 一方、`{{- /* */}}` セクションで指定されたコメントは表示されません。 特定のテンプレート関数で必要になる可能性のある Helm 値を含むテンプレートセクションに `#` YAML コメントを追加する際は注意してください。 たとえば、上記の例に `required` 関数を導入し、`maxMem` が設定されていない場合、 `#` YAML コメントはレンダリングエラーを引き起こします。 正しい書き方: `helm template` はこのブロックをレンダリングしません ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` 正しくない書き方: `helm template` は `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` を返します ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` YAML コメントがそのまま残される動作の別の例については、 [テンプレートのデバッグ](/chart_template_guide/debugging.md)を参照してください。 ## テンプレートとテンプレート出力での JSON の使用 YAML は JSON のスーパーセットです。場合によっては、JSON 構文の方が 他の YAML 表現よりも読みやすいことがあります。 たとえば、この YAML は通常の YAML のリスト表現方法に近いです: ```yaml arguments: - "--dirname" - "/foo" ``` しかし、JSON リストスタイルに折りたたむと読みやすくなります: ```yaml arguments: ["--dirname", "/foo"] ``` 可読性を高めるために JSON を使用することは良い方法です。ただし、JSON 構文は より複雑な構造を表現するために使用すべきではありません。 YAML 内に純粋な JSON を埋め込む場合（init コンテナの設定など）は、 もちろん JSON フォーマットを使用するのが適切です。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: 値 description: どのように値を設定するかを解説します。 sidebar_position: 2 --- ベストプラクティスガイドのこの部分では、値の設定方法を解説します。 チャートの`values.yaml`の書き方に重点を置いて、値を構造化して利用するおすすめの方法を解説します。 ## 命名規則 変数名は小文字で始める必要があります。また、単語はキャメルケースで区切ってください。 正しい書き方: ```yaml chicken: true chickenNoodleSoup: true ``` 正しくない書き方: ```yaml Chicken: true # 最初を大文字にすると組み込み変数と衝突することがあります chicken-noodle-soup: true # ハイフンは使わないでください ``` ユーザー定義のパラメータと区別しやすくするため、Helmの全ての組み込み変数は大文字で始まります。 例: `.Release.Name`、`.Capabilities.KubeVersion` ## フラット・ネスト構造の値 YAMLは柔軟な形式なので、値を深くネストすることも、フラットにすることもできます。 ネスト: ```yaml server: name: nginx port: 80 ``` フラット: ```yaml serverName: nginx serverPort: 80 ``` ほとんどの場合、ネストよりフラットな方が好まれます。フラットな方がテンプレートの開発者・ユーザーがよりシンプルに理解できるからです。 ネストされた値を安全に扱うためには、全ての階層で値をチェックする必要があります。 ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` ネストされた全ての階層では値が存在するかをチェックする必要があります。 その一方でフラット構成の場合、このようなチェックをせずにテンプレートを読みやすく、使いやすくすることができます。 ``` {{ default "none" .Values.serverName }} ``` 関連する変数が多数あり、そのうちの少なくとも1つが必須の変数である場合は、 読みやすさを向上させるためにネストされた値を使うことがあります。 ## 型の明確化 YAMLの型強制ルールは直感に反することがあります。例えば `foo: false`と `foo: "false"`は同じではありません。`foo: 12345678` のように大きな整数は、 科学的表記に変換される場合があります。 型変換エラーを回避する最も簡単な方法は、文字列は明示的に扱い、その他全ては暗黙的に扱うことです。 簡潔に言えば、_すべての文字列をクォートする_ ということです。 多くの場合、整数キャストの問題を回避するには整数を文字列として格納し、 テンプレートで`{{ int $value }}`のように使用して文字列から整数に戻すと便利です。 ほとんどの場合、明示的な型のタグが優先されるため、`foo: !!string 1234`は文字列の`1234`として扱われます。 _ただし_、YAMLパーサーはタグを消費してしまうので、パースされた後は型情報が失われます。 ## ユーザーがどのように値を扱うかについて考える 値は3つの方法で設定することができます。 - チャートの`values.yaml`ファイル - `helm install -f`、`helm upgrade -f`で渡されるファイル - `helm install`、`helm upgrade`の`--set`、`--set-string` フラグで渡される値 値の構造を設計するときは、ユーザーが`-f`フラグや`--set`オプションで 値を上書きしたい場合があることに注意してください。 `--set`が一番表現力が制限されているので、`values.yaml`を書くにあたって最初に考えるべきことは、 `--set`で簡単に上書きできるようにすることです。 そのような理由から、大抵の場合はマップを使用して値を構造化するほうがよいです。 `--set`の利用が難しい例: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` 上の例は、Helm `<=2.4` では `--set` で表現できません。Helm 2.5では fooのportを `--set servers[0].port=80`と書くことができます。ユーザーが理解しにくいだけでなく、 後に`servers`の順番が変更されたときにエラーが発生しやすくなります。 使いやすい例: ```yaml servers: foo: port: 80 bar: port: 81 ``` fooのportへのアクセスは非常に明確です: `--set servers.foo.port=80` ## `values.yaml`のドキュメント `values.yaml`で定義された全てのプロパティは文書化されているべきです。 説明文は説明するプロパティ名で始めて、少なくとも1文以上書いてください。 正しくない例: ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` 正しい例: ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` 各コメントをパラメータ名で始めるとドキュメントをgrepするのが簡単になるのに加え、 文書化ツールが説明文をパラメータと確実に紐付けることができるようになります。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: テンプレート内からファイルにアクセスする description: テンプレート内からファイルにアクセスする方法について説明します。 sidebar_position: 10 --- 前のセクションでは、名前付きテンプレートを作成してアクセスするいくつかの方法を説明しました。これにより、あるテンプレートから別のテンプレートを簡単にインポートできます。しかし、_テンプレートではないファイル_ をインポートして、テンプレートレンダリングエンジンを通さずにその内容を挿入したい場合もあります。 Helm では、`.Files` オブジェクトを通じてファイルにアクセスできます。テンプレートの例に入る前に、この機能の仕組みについていくつか注意事項があります: - Helm chart に追加のファイルを含めることができます。これらのファイルは chart にバンドルされます。ただし、Kubernetes オブジェクトのストレージ制限があるため、chart は 1M 未満でなければなりません。 - セキュリティ上の理由から、一部のファイルは `.Files` オブジェクトからアクセスできません。 - `templates/` ディレクトリ内のファイルにはアクセスできません。 - `.helmignore` で除外されたファイルにはアクセスできません。 - Helm アプリケーションの[サブチャート](/chart_template_guide/subcharts_and_globals.md)外のファイル（親 chart のファイルを含む）にはアクセスできません。 - chart は UNIX モード情報を保持しません。そのため、ファイルレベルのパーミッションは `.Files` オブジェクトを通じたファイルの利用可否に影響しません。 - [基本的な例](#basic-example) - [パスヘルパー](#path-helpers) - [Glob パターン](#glob-patterns) - [ConfigMap と Secret のユーティリティ関数](#configmap-and-secrets-utility-functions) - [エンコーディング](#encoding) - [行ごとの処理](#lines) ## 基本的な例 {#basic-example} 以上の注意事項を踏まえ、3 つのファイルを読み込んで ConfigMap に格納するテンプレートを作成します。まず、chart に 3 つのファイルを追加し、すべて `mychart/` ディレクトリ直下に配置します。 `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` これらは簡単な TOML ファイルです（昔の Windows INI ファイルのようなものです）。ファイル名がわかっているので、`range` 関数を使ってループし、内容を ConfigMap に挿入できます。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` この ConfigMap は、前のセクションで説明したいくつかのテクニックを使用しています。たとえば、`.Files` オブジェクトへの参照を保持する `$files` 変数を作成しています。また、`tuple` 関数を使用してループ対象のファイルリストを作成しています。そして、各ファイル名（`{{ . }}: |-`）とその内容（`{{ $files.Get . }}`）を出力しています。 このテンプレートを実行すると、3 つすべてのファイル内容を含む単一の ConfigMap が生成されます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## パスヘルパー {#path-helpers} ファイルを扱う際、ファイルパス自体に対して標準的な操作を行うと便利なことがあります。Helm は Go の [path](https://golang.org/pkg/path/) パッケージの関数を多数インポートしており、これらを利用できます。Go パッケージと同じ名前で、先頭の文字が小文字になっています。たとえば、`Base` は `base` になります。 インポートされている関数は以下の通りです: - Base - Dir - Ext - IsAbs - Clean ## Glob パターン {#glob-patterns} chart が大きくなるにつれて、ファイルをより整理する必要が出てくることがあります。そのため、[glob パターン](https://godoc.org/github.com/gobwas/glob)の柔軟性を活かして特定のファイルを抽出できる `Files.Glob(pattern string)` メソッドを提供しています。 `.Glob` は `Files` 型を返すため、返されたオブジェクトに対して `Files` のメソッドを呼び出せます。 たとえば、次のようなディレクトリ構造があるとします: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Glob ではいくつかのオプションがあります: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` または ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap と Secret のユーティリティ関数 {#configmap-and-secrets-utility-functions} （Helm 2.0.2 以降で利用可能） ファイルの内容を ConfigMap と Secret の両方に配置し、実行時に Pod にマウントしたいことがよくあります。これを支援するため、`Files` 型にいくつかのユーティリティメソッドを提供しています。 さらに整理するために、これらのメソッドを `Glob` メソッドと組み合わせて使用すると特に便利です。 [Glob パターン](#glob-patterns)の例で示したディレクトリ構造を使用すると: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## エンコーディング {#encoding} ファイルをインポートして、転送の成功を確実にするために Base64 エンコードすることができます: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` 上記は、前に使用した同じ `config1.toml` ファイルをエンコードします: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## 行ごとの処理 {#lines} テンプレート内でファイルの各行にアクセスしたい場合があります。このために便利な `Lines` メソッドを提供しています。 `range` 関数を使用して `Lines` をループ処理できます: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` `helm install` 時に chart 外部からファイルを渡す方法はありません。そのため、ユーザーにデータを提供してもらう場合は、`helm install -f` または `helm install --set` を使用して読み込む必要があります。 この説明で、Helm テンプレートを作成するためのツールとテクニックの解説は終わりです。次のセクションでは、特別なファイル `templates/NOTES.txt` を使用して、chart のユーザーにインストール後の手順を送信する方法を説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: 組み込みオブジェクト description: テンプレートで利用可能な組み込みオブジェクトについて説明します。 sidebar_position: 3 --- オブジェクトはテンプレートエンジンからテンプレートに渡されます。コード内でオブジェクトを受け渡すこともできます（`with` 文や `range` 文で例を見ていきます）。また、`tuple` 関数など、テンプレート内で新しいオブジェクトを作成する方法もいくつかあります。 オブジェクトは単純なもので、単一の値だけを持つこともあります。あるいは、他のオブジェクトや関数を含むこともできます。たとえば、`Release` オブジェクトは複数のオブジェクト（`Release.Name` など）を含み、`Files` オブジェクトはいくつかの関数を持っています。 前のセクションでは、`{{ .Release.Name }}` を使用して release 名をテンプレートに挿入しました。`Release` は、テンプレート内でアクセスできるトップレベルオブジェクトの一つです。 - `Release`: release 自体を表すオブジェクトです。内部にいくつかのオブジェクトを持っています: - `Release.Name`: release 名 - `Release.Namespace`: release 先の namespace（マニフェストで上書きされない場合） - `Release.IsUpgrade`: 現在の操作がアップグレードまたはロールバックの場合、`true` に設定されます。 - `Release.IsInstall`: 現在の操作がインストールの場合、`true` に設定されます。 - `Release.Revision`: この release のリビジョン番号。インストール時は 1 で、アップグレードやロールバックごとに増加します。 - `Release.Service`: 現在のテンプレートをレンダリングしているサービス。Helm では常に `Helm` です。 - `Values`: `values.yaml` ファイルおよびユーザー指定のファイルからテンプレートに渡される値。デフォルトでは `Values` は空です。 - `Chart`: `Chart.yaml` ファイルの内容。`Chart.yaml` 内のすべてのデータにアクセスできます。たとえば、`{{ .Chart.Name }}-{{ .Chart.Version }}` は `mychart-0.1.0` のように出力されます。 - 利用可能なフィールドの一覧は [Chart ガイド](/topics/charts.md#the-chartyaml-file) を参照してください。 - `Subcharts`: サブチャートのスコープ（.Values、.Charts、.Releases など）に親 chart からアクセスできます。たとえば、`.Subcharts.mySubChart.myValue` で `mySubChart` chart 内の `myValue` にアクセスできます。 - `Files`: chart 内の特殊ファイル以外のすべてのファイルにアクセスできます。テンプレートへのアクセスには使用できませんが、chart 内の他のファイルにアクセスするために使用できます。詳細は[ファイルへのアクセス](/chart_template_guide/accessing_files.md)のセクションを参照してください。 - `Files.Get` は名前でファイルを取得する関数です（`.Files.Get config.ini`）。 - `Files.GetBytes` はファイルの内容を文字列ではなくバイト配列として取得する関数です。画像などに便利です。 - `Files.Glob` は指定したシェルの glob パターンに一致する名前のファイルリストを返す関数です。 - `Files.Lines` はファイルを1行ずつ読み込む関数です。ファイル内の各行を反復処理するのに便利です。 - `Files.AsSecrets` はファイルの内容を Base 64 エンコードされた文字列として返す関数です。 - `Files.AsConfig` はファイルの内容を YAML マップとして返す関数です。 - `Capabilities`: Kubernetes クラスターがサポートする機能に関する情報を提供します。 - `Capabilities.APIVersions` はバージョンのセットです。 - `Capabilities.APIVersions.Has $version` は、バージョン（例: `batch/v1`）またはリソース（例: `apps/v1/Deployment`）がクラスターで利用可能かどうかを示します。 - `Capabilities.KubeVersion` と `Capabilities.KubeVersion.Version` は Kubernetes のバージョンです。 - `Capabilities.KubeVersion.Major` は Kubernetes のメジャーバージョンです。 - `Capabilities.KubeVersion.Minor` は Kubernetes のマイナーバージョンです。 - `Capabilities.HelmVersion` は Helm のバージョン詳細を含むオブジェクトで、`helm version` の出力と同じです。 - `Capabilities.HelmVersion.Version` は semver 形式の現在の Helm バージョンです。 - `Capabilities.HelmVersion.GitCommit` は Helm の git sha1 です。 - `Capabilities.HelmVersion.GitTreeState` は Helm の git ツリーの状態です。 - `Capabilities.HelmVersion.GoVersion` は使用されている Go コンパイラのバージョンです。 - `Template`: 現在実行中のテンプレートに関する情報を含みます。 - `Template.Name`: 現在のテンプレートへの namespace を含むファイルパス（例: `mychart/templates/mytemplate.yaml`） - `Template.BasePath`: 現在の chart の templates ディレクトリへの namespace を含むパス（例: `mychart/templates`）。 組み込み値は常に大文字で始まります。これは Go の命名規則に従っています。独自の名前を作成する場合は、チームに合った規則を自由に使用できます。[Artifact Hub](https://artifacthub.io/packages/search?kind=0) で見られる多くの chart を作成しているチームのように、一部のチームでは、組み込みの名前とローカルの名前を区別するために、小文字で始めることを選択しています。このガイドでは、その規則に従います。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: フロー制御 description: テンプレート内のフロー構造について概説します。 sidebar_position: 7 --- 制御構造（テンプレート用語では「アクション」と呼ばれます）を使うと、テンプレートの生成フローを制御できます。Helm のテンプレート言語では、以下の制御構造を提供しています: - `if`/`else`: 条件分岐ブロックの作成 - `with`: スコープの指定 - `range`: 「for each」スタイルのループ これらに加えて、名前付きテンプレートセグメントを宣言・使用するためのアクションもあります: - `define`: テンプレート内で新しい名前付きテンプレートを宣言 - `template`: 名前付きテンプレートをインポート - `block`: 埋め込み可能な特殊なテンプレート領域を宣言 このセクションでは、`if`、`with`、`range` について解説します。その他のアクションについては、本ガイドの後半にある「名前付きテンプレート」セクションで説明します。 ## If/Else 最初に紹介する制御構造は、テンプレート内で条件付きのテキストブロックを含めるためのものです。これが `if`/`else` ブロックです。 条件分岐の基本構文は次のとおりです: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` ここでは値ではなく _パイプライン_ について説明しています。これは、制御構造が単に値を評価するだけでなく、パイプライン全体を実行できることを明示するためです。 パイプラインは以下の場合に _false_ として評価されます: - boolean の false - 数値のゼロ - 空文字列 - `nil`（空または null） - 空のコレクション（`map`、`slice`、`tuple`、`dict`、`array`） これら以外の条件では、すべて true として評価されます。 ConfigMap に簡単な条件分岐を追加してみましょう。drink が coffee に設定されている場合に、別の設定を追加します: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` 前の例で `drink: coffee` をコメントアウトしていたため、出力には `mug: "true"` フラグは含まれません。しかし、`values.yaml` ファイルにその行を戻すと、出力は次のようになります: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## ホワイトスペースの制御 条件分岐を見ているうちに、テンプレート内でホワイトスペースがどのように制御されるかを簡単に確認しておきましょう。前の例を読みやすいように整形してみます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` 一見よさそうに見えます。しかし、テンプレートエンジンを通すと、残念な結果になります: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` 何が起きたのでしょうか? 上記のホワイトスペースが原因で、不正な YAML が生成されました。 ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` のインデントが正しくありません。この行のインデントを減らして、再実行してみましょう: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` これを実行すると、有効な YAML が得られますが、まだ少し見た目がおかしいです: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` YAML に空行がいくつか含まれています。なぜでしょうか? テンプレートエンジンは `{{` と `}}` の間の内容を _削除_ しますが、残りのホワイトスペースはそのまま残します。 YAML ではホワイトスペースに意味があるため、その管理は非常に重要です。幸い、Helm テンプレートにはこれを支援するツールがいくつかあります。 まず、テンプレート宣言の波括弧構文を特殊文字で修飾して、テンプレートエンジンにホワイトスペースを削除するよう指示できます。`{{- `（ダッシュとスペースを追加）は左側のホワイトスペースを削除することを示し、` -}}` は右側のホワイトスペースを削除することを意味します。_注意: 改行もホワイトスペースです!_ > `-` とディレクティブの残りの部分の間には必ずスペースを入れてください。`{{- 3 }}` は「左側のホワイトスペースを削除して 3 を出力する」ことを意味しますが、`{{-3 }}` は「-3 を出力する」ことを意味します。 この構文を使って、テンプレートを修正して空行を削除しましょう: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` このポイントを明確にするために、上記を調整して、このルールに従って削除されるホワイトスペースを `*` で置き換えてみましょう。行末の `*` は削除される改行文字を表します。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` これを念頭に置いて、テンプレートを Helm で実行すると、結果は次のようになります: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ホワイトスペース削除修飾子には注意が必要です。次のような間違いをしやすいです: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` これは `food: "PIZZA"mug: "true"` を出力します。両側の改行が削除されたためです。 > テンプレートでのホワイトスペース制御の詳細については、[Go テンプレートの公式ドキュメント](https://godoc.org/text/template)を参照してください。 最後に、テンプレートディレクティブのスペースを調整するよりも、テンプレートシステムにインデントを指示する方が簡単な場合があります。そのような場合は、`indent` 関数（`{{ indent 2 "mug:true" }}`）が便利です。 ## `with` によるスコープの変更 次に紹介する制御構造は `with` アクションです。これは変数のスコープを制御します。`.` は _現在のスコープ_ への参照であることを思い出してください。したがって `.Values` は、現在のスコープで `Values` オブジェクトを探すようにテンプレートに指示します。 `with` の構文は単純な `if` 文に似ています: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` スコープは変更できます。`with` を使うと、現在のスコープ（`.`）を特定のオブジェクトに設定できます。たとえば、これまで `.Values.favorite` を使って作業してきました。`.` スコープが `.Values.favorite` を指すように ConfigMap を書き換えてみましょう: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` 前の演習から `if` 条件を削除しました。`PIPELINE` の値が空でない場合にのみ `with` の後のブロックが実行されるため、もう不要です。 `.drink` と `.food` を修飾なしで参照できるようになったことに注目してください。これは `with` 文が `.` を `.Values.favorite` を指すように設定したためです。`.` は `{{ end }}` の後に元のスコープにリセットされます。 ただし注意が必要です! 制限されたスコープ内では、`.` を使って親スコープの他のオブジェクトにアクセスできません。たとえば、以下のコードは失敗します: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` が `.` の制限されたスコープ内にないため、エラーが発生します。しかし、最後の 2 行を入れ替えると、`{{ end }}` の後にスコープがリセットされるため、すべて期待どおりに動作します: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` または、`$` を使って親スコープから `Release.Name` オブジェクトにアクセスできます。`$` はテンプレート実行開始時にルートスコープにマップされ、テンプレート実行中に変更されません。以下のコードも動作します: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` `range` を見た後、上記のスコープ問題に対する解決策の 1 つであるテンプレート変数について説明します。 ## `range` アクションによるループ 多くのプログラミング言語では、`for` ループ、`foreach` ループ、または同様の仕組みを使ったループをサポートしています。Helm のテンプレート言語では、`range` 演算子を使ってコレクションを反復処理します。 まず、`values.yaml` ファイルにピザのトッピングリストを追加しましょう: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` これで `pizzaToppings` のリスト（テンプレートでは `slice` と呼ばれます）ができました。このリストを ConfigMap に出力するようにテンプレートを変更しましょう: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` `$` を使って親スコープから `Values.pizzaToppings` リストにアクセスすることもできます。`$` はテンプレート実行開始時にルートスコープにマップされ、テンプレート実行中に変更されません。以下のコードも動作します: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` `toppings:` リストを詳しく見てみましょう。`range` 関数は `pizzaToppings` リストを反復処理します。ここで興味深いことが起こります。`with` が `.` のスコープを変更するのと同様に、`range` 演算子もスコープを変更します。ループの各イテレーションで、`.` は現在のピザトッピングに設定されます。最初のイテレーションでは `.` は `mushrooms` になります。2 回目は `cheese`、以降同様に続きます。 `.` の値を直接パイプラインに送ることができるので、`{{ . | title | quote }}` と書くと、`.` を `title`（タイトルケース関数）に送り、次に `quote` に送ります。このテンプレートを実行すると、出力は次のようになります: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` この例では少しトリッキーなことをしています。`toppings: |-` 行は複数行の文字列を宣言しています。したがって、トッピングのリストは実際には YAML のリストではなく、大きな文字列です。なぜこうするのでしょうか? ConfigMap の `data` はキー/値のペアで構成され、キーと値はどちらも単純な文字列だからです。この詳細については [Kubernetes ConfigMap ドキュメント](https://kubernetes.io/docs/concepts/configuration/configmap/)を参照してください。ただし、ここではそれほど重要ではありません。 > YAML の `|-` マーカーは複数行の文字列を取ります。これは、この例のようにマニフェスト内に大きなデータブロックを埋め込むのに便利なテクニックです。 テンプレート内で素早くリストを作成し、そのリストを反復処理したい場合があります。Helm テンプレートにはこれを簡単にする関数 `tuple` があります。コンピュータサイエンスでは、タプルは固定サイズのリスト形式のコレクションですが、任意のデータ型を持つことができます。これは `tuple` の使い方を大まかに表しています。 ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` 上記は次のように出力されます: ```yaml sizes: |- - small - medium - large ``` リストやタプルに加えて、`range` はキーと値を持つコレクション（`map` や `dict` など）を反復処理するためにも使用できます。次のセクションでテンプレート変数を紹介する際に、その方法を説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "付録: Go データ型とテンプレート" description: テンプレート内の変数についての簡単な解説です。 sidebar_position: 16 --- Helm テンプレート言語は、強い型付けを持つ Go プログラミング言語で実装されています。そのため、テンプレート内の変数には _型_ があります。ほとんどの場合、変数は以下のいずれかの型として扱われます: - string: テキスト文字列 - bool: `true` または `false` - int: 整数値（8、16、32、64 ビットの符号付きおよび符号なしのバリエーションもあります） - float64: 64 ビット浮動小数点値（8、16、32 ビットのバリエーションもあります） - バイトスライス（`[]byte`）: （潜在的に）バイナリデータを格納する際によく使用されます - struct: プロパティとメソッドを持つオブジェクト - スライス（インデックス付きリスト）: 上記のいずれかの型を要素として持ちます - 文字列キーのマップ（`map[string]interface{}`）: 値は上記の型のいずれかになります Go には他にも多くの型があり、テンプレート内でそれらを変換する必要がある場合もあります。オブジェクトの型を調べる最も簡単な方法は、テンプレート内で `printf "%T"` に渡すことです。これにより型名が出力されます。`typeOf` 関数や `kindOf` 関数も併せて参照してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: テンプレートのデバッグ description: デプロイに失敗する chart のトラブルシューティング方法。 sidebar_position: 13 --- テンプレートのデバッグは難しいことがあります。レンダリングされたテンプレートは Kubernetes API サーバーに送信され、フォーマット以外の理由で YAML ファイルが拒否される可能性があるためです。 デバッグに役立つコマンドをいくつか紹介します。 - `helm lint`: chart がベストプラクティスに従っているかを検証する基本ツールです。 - `helm template --debug`: chart テンプレートをローカルでレンダリングしてテストします。 - `helm install --dry-run --debug`: chart をローカルでレンダリングし、インストールは行いません。また、競合するリソースがクラスター上で既に実行されていないかもチェックします。`--dry-run=server` を指定すると、chart 内の `lookup` もサーバーに対して実行されます。 - `helm get manifest`: サーバーにインストールされているテンプレートを確認できます。 YAML のパースに失敗したが、生成された内容を確認したい場合は、テンプレート内の問題箇所をコメントアウトしてから `helm install --dry-run --debug` を再実行する方法があります: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` 上記はコメントを含んだままレンダリングされます: ```yaml apiVersion: v2 # some: problem section # "bar" ``` この方法により、YAML パースエラーに妨げられずに生成内容を素早く確認できます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: テンプレート関数リスト description: Helm で利用可能なテンプレート関数の一覧です sidebar_position: 6 --- Helm にはテンプレートで活用できる多くのテンプレート関数が用意されています。 以下のカテゴリごとに一覧を掲載します: * [暗号化とセキュリティ](#cryptographic-and-security-functions) * [日付](#date-functions) * [辞書](#dictionaries-and-dict-functions) * [エンコーディング](#encoding-functions) * [ファイルパス](#file-path-functions) * [Kubernetes と Chart](#kubernetes-and-chart-functions) * [論理とフロー制御](#logic-and-flow-control-functions) * [リスト](#lists-and-list-functions) * [算術](#math-functions) * [浮動小数点算術](#float-math-functions) * [ネットワーク](#network-functions) * [リフレクション](#reflection-functions) * [正規表現](#regular-expressions) * [セマンティックバージョン](#semantic-version-functions) * [文字列](#string-functions) * [型変換](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## 論理とフロー制御関数 Helm には多くの論理・制御フロー関数が含まれています: [and](#and)、 [coalesce](#coalesce)、[default](#default)、[empty](#empty)、[eq](#eq)、 [fail](#fail)、[ge](#ge)、[gt](#gt)、[le](#le)、[lt](#lt)、[ne](#ne)、 [not](#not)、[or](#or)、[required](#required)。 ### and 2つ以上の引数のブール論理積（AND）を返します （最初の空の引数、または最後の引数を返します）。 ``` and .Arg1 .Arg2 ``` ### or 2つ以上の引数のブール論理和（OR）を返します （最初の空でない引数、または最後の引数を返します）。 ``` or .Arg1 .Arg2 ``` ### not 引数のブール否定を返します。 ``` not .Arg ``` ### eq 引数のブール等価性を返します（例: Arg1 == Arg2）。 ``` eq .Arg1 .Arg2 ``` ### ne 引数のブール不等価性を返します（例: Arg1 != Arg2）。 ``` ne .Arg1 .Arg2 ``` ### lt 第1引数が第2引数より小さい場合に true を返します。 それ以外は false を返します（例: Arg1 < Arg2）。 ``` lt .Arg1 .Arg2 ``` ### le 第1引数が第2引数以下の場合に true を返します。 それ以外は false を返します（例: Arg1 <= Arg2）。 ``` le .Arg1 .Arg2 ``` ### gt 第1引数が第2引数より大きい場合に true を返します。 それ以外は false を返します（例: Arg1 > Arg2）。 ``` gt .Arg1 .Arg2 ``` ### ge 第1引数が第2引数以上の場合に true を返します。 それ以外は false を返します（例: Arg1 >= Arg2）。 ``` ge .Arg1 .Arg2 ``` ### default シンプルなデフォルト値を設定するには `default` を使用します: ``` default "foo" .Bar ``` 上記の場合、`.Bar` が空でない値に評価されればその値が使用されます。 空の場合は代わりに `foo` が返されます。 「空」の定義は型によって異なります: - 数値: 0 - 文字列: "" - リスト: `[]` - 辞書: `{}` - ブール: `false` - および常に `nil`（null） 構造体には空の定義がないため、構造体がデフォルト値を返すことはありません。 ### required `required` を使用して必須の値を指定します: ``` required "A valid foo is required!" .Bar ``` `.Bar` が空または未定義の場合（評価方法については [default](#default) を参照）、 テンプレートはレンダリングされず、指定されたエラーメッセージが返されます。 ### empty `empty` 関数は、指定された値が空と見なされる場合に `true` を返し、 それ以外は `false` を返します。空の値は `default` セクションに記載されています。 ``` empty .Foo ``` Go テンプレートの条件文では、空かどうかは自動的に計算されます。 そのため、`if not empty .Foo` はほとんど必要ありません。代わりに `if .Foo` を使用してください。 ### fail 無条件に空の `string` と指定されたテキストを含む `error` を返します。 これは、他の条件によってテンプレートのレンダリングが失敗すべきと判断された シナリオで役立ちます。 ``` fail "Please accept the end user license agreement" ``` ### coalesce `coalesce` 関数は値のリストを受け取り、最初の空でない値を返します。 ``` coalesce 0 1 2 ``` 上記は `1` を返します。 この関数は複数の変数や値をスキャンする際に便利です: ``` coalesce .name .parent.name "Matt" ``` 上記はまず `.name` が空かどうかを確認します。空でなければその値を返します。 空の場合、`coalesce` は `.parent.name` の空をチェックします。 最終的に `.name` と `.parent.name` の両方が空の場合、`Matt` を返します。 ### ternary `ternary` 関数は2つの値とテスト値を受け取ります。テスト値が true の場合は 第1の値を返します。テスト値が空の場合は第2の値を返します。 これは C や他のプログラミング言語の三項演算子に似ています。 #### true テスト値 ``` ternary "foo" "bar" true ``` または ``` true | ternary "foo" "bar" ``` 上記は `"foo"` を返します。 #### false テスト値 ``` ternary "foo" "bar" false ``` または ``` false | ternary "foo" "bar" ``` 上記は `"bar"` を返します。 ## 文字列関数 Helm には以下の文字列関数が含まれています: [abbrev](#abbrev)、 [abbrevboth](#abbrevboth)、[camelcase](#camelcase)、[cat](#cat)、 [contains](#contains)、[hasPrefix](#hasprefix-and-hassuffix)、 [hasSuffix](#hasprefix-and-hassuffix)、[indent](#indent)、[initials](#initials)、 [kebabcase](#kebabcase)、[lower](#lower)、[nindent](#nindent)、 [nospace](#nospace)、[plural](#plural)、[print](#print)、[printf](#printf)、 [println](#println)、[quote](#quote-and-squote)、 [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii)、 [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii)、 [randAscii](#randalphanum-randalpha-randnumeric-and-randascii)、 [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii)、 [repeat](#repeat)、[replace](#replace)、[shuffle](#shuffle)、 [snakecase](#snakecase)、[squote](#quote-and-squote)、[substr](#substr)、 [swapcase](#swapcase)、[title](#title)、[trim](#trim)、[trimAll](#trimall)、 [trimPrefix](#trimprefix)、[trimSuffix](#trimsuffix)、[trunc](#trunc)、 [untitle](#untitle)、[upper](#upper)、[wrap](#wrap)、[wrapWith](#wrapwith)。 ### print パーツを組み合わせて文字列を返します。 ``` print "Matt has " .Dogs " dogs" ``` 文字列でない型は可能な限り文字列に変換されます。 隣り合う2つの引数が文字列でない場合、間にスペースが追加されます。 ### println [print](#print) と同様に動作しますが、末尾に改行を追加します。 ### printf フォーマット文字列と順番に渡す引数に基づいて文字列を返します。 ``` printf "%s has %d dogs." .Name .NumberDogs ``` 使用するプレースホルダーは渡す引数の型によって異なります。 以下が含まれます: 汎用: * `%v` デフォルトフォーマットでの値 * 辞書を出力する場合、プラスフラグ（%+v）でフィールド名を追加 * `%%` リテラルのパーセント記号、値を消費しない ブール: * `%t` true または false という単語 整数: * `%b` 2進数 * `%c` 対応する Unicode コードポイントで表される文字 * `%d` 10進数 * `%o` 8進数 * `%O` 0o プレフィックス付き8進数 * `%q` 安全にエスケープされたシングルクォート文字リテラル * `%x` 16進数（a-f は小文字） * `%X` 16進数（A-F は大文字） * `%U` Unicode フォーマット: U+1234、"U+%04X" と同等 浮動小数点と複素数の構成要素: * `%b` 指数が2のべき乗の10進なし科学的記数法（例: -123456p-78） * `%e` 科学的記数法（例: -1.234456e+78） * `%E` 科学的記数法（例: -1.234456E+78） * `%f` 小数点あり、指数なし（例: 123.456） * `%F` %f と同義 * `%g` 大きな指数には %e、それ以外は %f * `%G` 大きな指数には %E、それ以外は %F * `%x` 16進表記（2のべき乗の10進指数付き、例: -0x1.23abcp+20） * `%X` 大文字16進表記（例: -0X1.23ABCP+20） 文字列とバイトスライス（これらの動詞で同等に扱われます）: * `%s` 文字列またはスライスの解釈されないバイト * `%q` 安全にエスケープされたダブルクォート文字列 * `%x` 16進（小文字、バイトあたり2文字） * `%X` 16進（大文字、バイトあたり2文字） スライス: * `%p` 先頭 0x 付き16進表記での第0要素のアドレス ### trim `trim` 関数は文字列の両側から空白を削除します: ``` trim " hello " ``` 上記は `hello` を生成します。 ### trimAll 文字列の前後から指定した文字を削除します: ``` trimAll "$" "$5.00" ``` 上記は `5.00`（文字列として）を返します。 ### trimPrefix 文字列からプレフィックスのみを削除します: ``` trimPrefix "-" "-hello" ``` 上記は `hello` を返します。 ### trimSuffix 文字列からサフィックスのみを削除します: ``` trimSuffix "-" "hello-" ``` 上記は `hello` を返します。 ### lower 文字列全体を小文字に変換します: ``` lower "HELLO" ``` 上記は `hello` を返します。 ### upper 文字列全体を大文字に変換します: ``` upper "hello" ``` 上記は `HELLO` を返します。 ### title タイトルケースに変換します: ``` title "hello world" ``` 上記は `Hello World` を返します。 ### untitle タイトルケースを解除します。`untitle "Hello World"` は `hello world` を生成します。 ### repeat 文字列を複数回繰り返します: ``` repeat 3 "hello" ``` 上記は `hellohellohello` を返します。 ### substr 文字列から部分文字列を取得します。3つのパラメータを取ります: - start（int） - end（int） - string（string） ``` substr 0 5 "hello world" ``` 上記は `hello` を返します。 ### nospace 文字列からすべての空白を削除します。 ``` nospace "hello w o r l d" ``` 上記は `helloworld` を返します。 ### trunc 文字列を切り詰めます。 ``` trunc 5 "hello world" ``` 上記は `hello` を生成します。 ``` trunc -5 "hello world" ``` 上記は `world` を生成します。 ### abbrev 文字列を省略記号（`...`）付きで切り詰めます。 パラメータ: - 最大長 - 文字列 ``` abbrev 5 "hello world" ``` 上記は `he...` を返します。省略記号の幅も最大長に含まれます。 ### abbrevboth 両側を省略します: ``` abbrevboth 5 10 "1234 5678 9123" ``` 上記は `...5678...` を生成します。 パラメータ: - 左オフセット - 最大長 - 文字列 ### initials 複数の単語から各単語の最初の文字を取得して組み合わせます。 ``` initials "First Try" ``` 上記は `FT` を返します。 ### randAlphaNum、randAlpha、randNumeric、randAscii これら4つの関数は暗号学的に安全な（```crypto/rand``` を使用） ランダム文字列を生成しますが、基本文字セットが異なります: - `randAlphaNum` は `0-9a-zA-Z` を使用 - `randAlpha` は `a-zA-Z` を使用 - `randNumeric` は `0-9` を使用 - `randAscii` はすべての印刷可能 ASCII 文字を使用 それぞれ1つのパラメータ（文字列の整数長）を取ります。 ``` randNumeric 3 ``` 上記は3桁のランダム文字列を生成します。 ### wrap 指定した列数でテキストを折り返します: ``` wrap 80 $someText ``` 上記は `$someText` 内の文字列を80列で折り返します。 ### wrapWith `wrapWith` は `wrap` と同様に動作しますが、折り返しに使用する文字列を指定できます （`wrap` は `\n` を使用）。 ``` wrapWith 5 "\t" "Hello World" ``` 上記は `Hello World` を生成します（空白は ASCII タブ文字）。 ### contains ある文字列が別の文字列に含まれているかテストします: ``` contains "cat" "catch" ``` 上記は `true` を返します。`catch` には `cat` が含まれているためです。 ### hasPrefix と hasSuffix `hasPrefix` と `hasSuffix` 関数は、文字列が指定したプレフィックスまたは サフィックスを持っているかテストします: ``` hasPrefix "cat" "catch" ``` 上記は `true` を返します。`catch` にはプレフィックス `cat` があるためです。 ### quote と squote これらの関数は文字列をダブルクォート（`quote`）または シングルクォート（`squote`）で囲みます。 ### cat `cat` 関数は複数の文字列をスペースで区切りながら1つに連結します: ``` cat "hello" "beautiful" "world" ``` 上記は `hello beautiful world` を生成します。 ### indent `indent` 関数は指定した文字列のすべての行を指定したインデント幅で インデントします。複数行の文字列を揃える際に便利です: ``` indent 4 $lots_of_text ``` 上記はテキストのすべての行を4つのスペース文字でインデントします。 ### nindent `nindent` 関数は indent 関数と同じですが、文字列の先頭に改行を追加します。 ``` nindent 4 $lots_of_text ``` 上記はテキストのすべての行を4つのスペース文字でインデントし、 先頭に改行を追加します。 ### replace 単純な文字列置換を行います。 3つの引数を取ります: - 置換する文字列 - 置換後の文字列 - ソース文字列 ``` "I Am Henry VIII" | replace " " "-" ``` 上記は `I-Am-Henry-VIII` を生成します。 ### plural 文字列を複数形にします。 ``` len $fish | plural "one anchovy" "many anchovies" ``` 上記で、文字列の長さが1の場合は第1引数が出力されます（`one anchovy`）。 それ以外の場合は第2引数が出力されます（`many anchovies`）。 引数: - 単数形文字列 - 複数形文字列 - 長さ整数 NOTE: 現在 Helm はより複雑な複数形ルールを持つ言語をサポートしていません。 また、`0` は複数形として扱われます。英語ではそのように扱われるためです （`zero anchovies`）。 ### snakecase 文字列を camelCase から snake_case に変換します。 ``` snakecase "FirstName" ``` 上記は `first_name` を生成します。 ### camelcase 文字列を snake_case から CamelCase に変換します。 ``` camelcase "http_server" ``` 上記は `HttpServer` を生成します。 ### kebabcase 文字列を camelCase から kebab-case に変換します。 ``` kebabcase "FirstName" ``` 上記は `first-name` を生成します。 ### swapcase 単語ベースのアルゴリズムを使用して文字列の大文字小文字を入れ替えます。 変換アルゴリズム: - 大文字は小文字に変換 - タイトルケース文字は小文字に変換 - 空白の後または先頭の小文字はタイトルケースに変換 - その他の小文字は大文字に変換 - 空白は unicode.IsSpace(char) で定義 ``` swapcase "This Is A.Test" ``` 上記は `tHIS iS a.tEST` を生成します。 ### shuffle 文字列をシャッフルします。 ``` shuffle "hello" ``` 上記は `hello` の文字をランダムに並べ替えます。`oelhl` のような結果になる可能性があります。 ## 型変換関数 Helm は以下の型変換関数を提供しています: - `atoi`: 文字列を整数に変換 - `float64`: `float64` に変換 - `int`: システムのビット幅で `int` に変換 - `int64`: `int64` に変換 - `toDecimal`: Unix 8進数を `int64` に変換 - `toString`: 文字列に変換 - `toStrings`: リスト、スライス、または配列を文字列のリストに変換 - `toJson`（`mustToJson`）: リスト、スライス、配列、辞書、またはオブジェクトを JSON に変換 - `toPrettyJson`（`mustToPrettyJson`）: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き JSON に変換 - `toRawJson`（`mustToRawJson`）: リスト、スライス、配列、辞書、またはオブジェクトを HTML 文字がエスケープされていない JSON に変換 - `fromYaml`: YAML 文字列をオブジェクトに変換 - `fromJson`: JSON 文字列をオブジェクトに変換 - `fromJsonArray`: JSON 配列をリストに変換 - `toYaml`: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き yaml に変換。任意のソースから yaml のチャンクをコピーするのに使用できます。この関数は GoLang の yaml.Marshal 関数と同等です。詳細はこちらを参照: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: リスト、スライス、配列、辞書、またはオブジェクトをインデント付き yaml に変換。`toYaml` と同等ですが、リストを2スペースでさらにインデントします。 - `toToml`: リスト、スライス、配列、辞書、またはオブジェクトを toml に変換。任意のソースから toml のチャンクをコピーするのに使用できます。 - `fromYamlArray`: YAML 配列をリストに変換 `atoi` のみ入力が特定の型である必要があります。その他は任意の型から 目的の型への変換を試みます。例えば、`int64` は浮動小数点を整数に変換でき、 文字列を整数に変換することもできます。 ### toStrings リスト型のコレクションを与えると、文字列のスライスを生成します。 ``` list 1 2 3 | toStrings ``` 上記は `1` を `"1"` に、`2` を `"2"` に変換し、リストとして返します。 ### toDecimal Unix 8進数パーミッションを与えると、10進数を生成します。 ``` "0777" | toDecimal ``` 上記は `0777` を `511` に変換し、int64 として値を返します。 ### toJson、mustToJson `toJson` 関数は項目を JSON 文字列にエンコードします。項目を JSON に変換できない場合、 関数は空の文字列を返します。`mustToJson` は項目を JSON にエンコードできない場合に エラーを返します。 ``` toJson .Item ``` 上記は `.Item` の JSON 文字列表現を返します。 ### toPrettyJson、mustToPrettyJson `toPrettyJson` 関数は項目をインデント付きの整形された JSON 文字列にエンコードします。 ``` toPrettyJson .Item ``` 上記は `.Item` のインデント付き JSON 文字列表現を返します。 ### toRawJson、mustToRawJson `toRawJson` 関数は項目を HTML 文字がエスケープされていない JSON 文字列にエンコードします。 ``` toRawJson .Item ``` 上記は `.Item` のエスケープされていない JSON 文字列表現を返します。 ### fromYaml `fromYaml` 関数は YAML 文字列を受け取り、テンプレートで使用できるオブジェクトを返します。 `File at: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson `fromJson` 関数は JSON 文字列を受け取り、テンプレートで使用できるオブジェクトを返します。 `File at: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray `fromJsonArray` 関数は JSON 配列を受け取り、テンプレートで使用できるリストを返します。 `File at: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml、toYamlPretty `toYaml` と `toYamlPretty` 関数はオブジェクト（リスト、スライス、配列、辞書、またはオブジェクト）をインデント付き YAML 文字列にエンコードします。 > `toYamlPretty` は機能的に同等ですが、リスト要素を追加でインデントした YAML を出力します。 ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray `fromYamlArray` 関数は YAML 配列を受け取り、テンプレートで使用できるリストを返します。 `File at: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## 正規表現 Helm には以下の正規表現関数が含まれています: [regexFind （mustRegexFind）](#regexfindall-mustregexfindall)、[regexFindAll （mustRegexFindAll）](#regexfind-mustregexfind)、[regexMatch （mustRegexMatch）](#regexmatch-mustregexmatch)、[regexReplaceAll （mustRegexReplaceAll）](#regexreplaceall-mustregexreplaceall)、 [regexReplaceAllLiteral （mustRegexReplaceAllLiteral）](#regexreplaceallliteral-mustregexreplaceallliteral)、 [regexSplit（mustRegexSplit）](#regexsplit-mustregexsplit)。 ### regexMatch、mustRegexMatch 入力文字列が正規表現にマッチするものを含む場合に true を返します。 ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` 上記は `true` を生成します。 `regexMatch` は問題があるとパニックし、`mustRegexMatch` は問題があると テンプレートエンジンにエラーを返します。 ### regexFindAll、mustRegexFindAll 入力文字列内の正規表現のすべてのマッチのスライスを返します。 最後のパラメータ n は返す部分文字列の数を決定し、-1 はすべてのマッチを返すことを意味します。 ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` 上記は `[2 4 6 8]` を生成します。 `regexFindAll` は問題があるとパニックし、`mustRegexFindAll` は問題があると テンプレートエンジンにエラーを返します。 ### regexFind、mustRegexFind 入力文字列内の正規表現の最初の（最も左の）マッチを返します。 ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` 上記は `d1` を生成します。 `regexFind` は問題があるとパニックし、`mustRegexFind` は問題があると テンプレートエンジンにエラーを返します。 ### regexReplaceAll、mustRegexReplaceAll 入力文字列のコピーを返し、正規表現のマッチを置換文字列で置換します。 置換文字列内では、$ 記号は Expand と同様に解釈されます。 例えば、$1 は最初のサブマッチのテキストを表します。 第1引数は ``、第2引数は ``、第3引数は `` です。 ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` 上記は `-W-xxW-` を生成します。 `regexReplaceAll` は問題があるとパニックし、`mustRegexReplaceAll` は問題があると テンプレートエンジンにエラーを返します。 ### regexReplaceAllLiteral、mustRegexReplaceAllLiteral 入力文字列のコピーを返し、正規表現のマッチを置換文字列で置換します。 置換文字列は Expand を使用せずに直接代入されます。 第1引数は ``、第2引数は ``、第3引数は `` です。 ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` 上記は `-${1}-${1}-` を生成します。 `regexReplaceAllLiteral` は問題があるとパニックし、 `mustRegexReplaceAllLiteral` は問題があるとテンプレートエンジンにエラーを返します。 ### regexSplit、mustRegexSplit 入力文字列を正規表現で区切られた部分文字列にスライスし、 それらの正規表現マッチ間の部分文字列のスライスを返します。 最後のパラメータ `n` は返す部分文字列の数を決定し、 `-1` はすべてのマッチを返すことを意味します。 ``` regexSplit "z+" "pizza" -1 ``` 上記は `[pi a]` を生成します。 `regexSplit` は問題があるとパニックし、`mustRegexSplit` は問題があると テンプレートエンジンにエラーを返します。 ## 暗号化とセキュリティ関数 Helm はいくつかの高度な暗号化関数を提供しています: [adler32sum](#adler32sum)、[buildCustomCert](#buildcustomcert)、 [decryptAES](#decryptaes)、[derivePassword](#derivepassword)、 [encryptAES](#encryptaes)、[genCA](#genca)、[genPrivateKey](#genprivatekey)、 [genSelfSignedCert](#genselfsignedcert)、[genSignedCert](#gensignedcert)、 [htpasswd](#htpasswd)、[randBytes](#randbytes)、[sha1sum](#sha1sum)、 [sha256sum](#sha256sum)。 ### sha1sum `sha1sum` 関数は文字列を受け取り、その SHA1 ダイジェストを計算します。 ``` sha1sum "Hello world!" ``` ### sha256sum `sha256sum` 関数は文字列を受け取り、その SHA256 ダイジェストを計算します。 ``` sha256sum "Hello world!" ``` 上記は印刷しても安全な「ASCII アーマー」形式で SHA 256 サムを計算します。 ### adler32sum `adler32sum` 関数は文字列を受け取り、その Adler-32 チェックサムを計算します。 ``` adler32sum "Hello world!" ``` ### htpasswd `htpasswd` 関数は `username` と `password` を受け取り、パスワードの `bcrypt` ハッシュを生成します。結果は [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic) での 基本認証に使用できます。 ``` htpasswd "myUser" "myPassword" ``` パスワードをテンプレートに直接保存することは安全ではありません。 ### randBytes randBytes 関数はカウント N を受け取り、暗号学的に安全な （crypto/rand を使用）N バイトのランダムシーケンスを生成します。 シーケンスは base64 エンコードされた文字列として返されます。 ``` randBytes 24 ``` ### derivePassword `derivePassword` 関数は、共有「マスターパスワード」の制約に基づいて 特定のパスワードを導出するために使用できます。 このアルゴリズムは[明確に仕様化されています](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf)。 ``` derivePassword 1 "long" "password" "user" "example.com" ``` パーツをテンプレートに直接保存することは安全でないと見なされます。 ### genPrivateKey `genPrivateKey` 関数は PEM ブロックにエンコードされた新しい秘密鍵を生成します。 最初のパラメータとして以下のいずれかの値を取ります: - `ecdsa`: 楕円曲線 DSA 鍵を生成（P256） - `dsa`: DSA 鍵を生成（L2048N256） - `rsa`: RSA 4096 鍵を生成 ### buildCustomCert `buildCustomCert` 関数は証明書のカスタマイズを可能にします。 以下の文字列パラメータを取ります: - base64 エンコードされた PEM 形式の証明書 - base64 エンコードされた PEM 形式の秘密鍵 以下の属性を持つ証明書オブジェクトを返します: - `Cert`: PEM エンコードされた証明書 - `Key`: PEM エンコードされた秘密鍵 例: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` 返されたオブジェクトは `genSignedCert` 関数に渡して、この CA を使用して 証明書に署名できます。 ### genCA `genCA` 関数は新しい自己署名 x509 認証局を生成します。 以下のパラメータを取ります: - サブジェクトのコモンネーム（cn） - 証明書の有効期間（日数） 以下の属性を持つオブジェクトを返します: - `Cert`: PEM エンコードされた証明書 - `Key`: PEM エンコードされた秘密鍵 例: ``` $ca := genCA "foo-ca" 365 ``` 返されたオブジェクトは `genSignedCert` 関数に渡して、この CA を使用して 証明書に署名できます。 ### genSelfSignedCert `genSelfSignedCert` 関数は新しい自己署名 x509 証明書を生成します。 以下のパラメータを取ります: - サブジェクトのコモンネーム（cn） - IP のオプションリスト（nil 可） - 代替 DNS 名のオプションリスト（nil 可） - 証明書の有効期間（日数） 以下の属性を持つオブジェクトを返します: - `Cert`: PEM エンコードされた証明書 - `Key`: PEM エンコードされた秘密鍵 例: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert `genSignedCert` 関数は指定した CA によって署名された新しい x509 証明書を生成します。 以下のパラメータを取ります: - サブジェクトのコモンネーム（cn） - IP のオプションリスト（nil 可） - 代替 DNS 名のオプションリスト（nil 可） - 証明書の有効期間（日数） - CA（`genCA` を参照） 例: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES `encryptAES` 関数は AES-256 CBC でテキストを暗号化し、 base64 エンコードされた文字列を返します。 ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES `decryptAES` 関数は AES-256 CBC アルゴリズムでエンコードされた base64 文字列を受け取り、復号されたテキストを返します。 ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## 日付関数 Helm にはテンプレートで使用できる以下の日付関数が含まれています: [ago](#ago)、[date](#date)、[dateInZone](#dateinzone)、[dateModify （mustDateModify）](#datemodify-mustdatemodify)、[duration](#duration)、 [durationRound](#durationround)、[htmlDate](#htmldate)、 [htmlDateInZone](#htmldateinzone)、[now](#now)、[toDate （mustToDate）](#todate-musttodate)、[unixEpoch](#unixepoch)。 ### now 現在の日時を返します。他の日付関数と組み合わせて使用します。 ### ago `ago` 関数は現在からの経過時間を秒単位の解像度で返します。 ``` ago .CreatedAt ``` `time.Duration` の String() 形式で返します。 ``` 2h34m7s ``` ### date `date` 関数は日付をフォーマットします。 日付を YEAR-MONTH-DAY 形式でフォーマット: ``` now | date "2006-01-02" ``` Go での日付フォーマットは[少し異なります](https://pauladamsmith.com/blog/2011/05/go_time.html)。 簡単に言うと、以下を基準日として使用します: ``` Mon Jan 2 15:04:05 MST 2006 ``` これを希望する形式で記述します。上記の `2006-01-02` は同じ日付ですが、 希望する形式になっています。 ### dateInZone `date` と同じですが、タイムゾーン付きです。 ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration 指定した秒数を `time.Duration` としてフォーマットします。 以下は 1m35s を返します。 ``` duration "95" ``` ### durationRound 指定した期間を最も重要な単位に丸めます。文字列と `time.Duration` は 期間として解析され、`time.Time` はそこからの経過時間として計算されます。 以下は 2h を返します。 ``` durationRound "2h10m5s" ``` 以下は 3mo を返します。 ``` durationRound "2400h10m5s" ``` ### unixEpoch `time.Time` に対する Unix エポックからの秒数を返します。 ``` now | unixEpoch ``` ### dateModify、mustDateModify `dateModify` は修正と日付を受け取り、タイムスタンプを返します。 現在時刻から1時間30分を引く: ``` now | dateModify "-1.5h" ``` 修正形式が間違っている場合、`dateModify` は日付を変更せずに返します。 `mustDateModify` はそれ以外の場合にエラーを返します。 ### htmlDate `htmlDate` 関数は HTML の日付ピッカー入力フィールドに挿入するために 日付をフォーマットします。 ``` now | htmlDate ``` ### htmlDateInZone htmlDate と同じですが、タイムゾーン付きです。 ``` htmlDateInZone (now) "UTC" ``` ### toDate、mustToDate `toDate` は文字列を日付に変換します。第1引数は日付レイアウト、 第2引数は日付文字列です。文字列を変換できない場合はゼロ値を返します。 `mustToDate` は文字列を変換できない場合にエラーを返します。 これは文字列の日付を別の形式に変換したい場合に便利です（パイプを使用）。 以下の例は "2017-12-31" を "31/12/2017" に変換します。 ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## 辞書と Dict 関数 Helm は `dict`（Python の「dictionary」の略）と呼ばれるキー/値ストレージ型を 提供しています。`dict` は _順序なし_ の型です。 辞書のキーは **文字列でなければなりません**。ただし、値は任意の型にでき、 別の `dict` や `list` でも構いません。 `list` とは異なり、`dict` は不変ではありません。`set` と `unset` 関数は 辞書の内容を変更します。 Helm は辞書を扱うために以下の関数を提供しています: [deepCopy （mustDeepCopy）](#deepcopy-mustdeepcopy)、[dict](#dict)、[dig](#dig)、[get](#get)、 [hasKey](#haskey)、[keys](#keys)、[merge（mustMerge）](#merge-mustmerge)、 [mergeOverwrite（mustMergeOverwrite）](#mergeoverwrite-mustmergeoverwrite)、 [omit](#omit)、[pick](#pick)、[pluck](#pluck)、[set](#set)、[unset](#unset)、 [values](#values)。 ### dict 辞書の作成は `dict` 関数を呼び出してペアのリストを渡すことで行います。 以下は3つの項目を持つ辞書を作成します: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get マップとキーを与えると、マップから値を取得します。 ``` get $myDict "name1" ``` 上記は `"value1"` を返します。 キーが見つからない場合、この操作は単に `""` を返します。 エラーは生成されません。 ### set `set` を使用して辞書に新しいキー/値ペアを追加します。 ``` $_ := set $myDict "name4" "value4" ``` `set` は _辞書を返す_（Go テンプレート関数の要件）ため、 上記の `$_` 代入のように値をトラップする必要がある場合があります。 ### unset マップとキーを与えると、マップからキーを削除します。 ``` $_ := unset $myDict "name4" ``` `set` と同様に、辞書を返します。 キーが見つからない場合、この操作は単に戻ります。エラーは生成されません。 ### hasKey `hasKey` 関数は、指定した辞書に指定したキーが含まれている場合に `true` を返します。 ``` hasKey $myDict "name1" ``` キーが見つからない場合は `false` を返します。 ### pluck `pluck` 関数は1つのキーと複数のマップを与えて、 すべてのマッチのリストを取得することを可能にします: ``` pluck "name1" $myDict $myOtherDict ``` 上記は見つかったすべての値を含む `list` を返します（`[value1 otherValue1]`）。 指定したキーがマップに _見つからない_ 場合、そのマップはリストに項目を持ちません （返されるリストの長さは `pluck` 呼び出しの辞書の数より少なくなります）。 キーが _見つかった_ が値が空の値の場合、その値は挿入されます。 Helm テンプレートでの一般的なイディオムは、`pluck... | first` を使用して 辞書のコレクションから最初にマッチするキーを取得することです。 ### dig `dig` 関数はネストした辞書のセットを走査し、値のリストからキーを選択します。 関連する辞書でキーが見つからない場合はデフォルト値を返します。 ``` dig "user" "role" "humanName" "guest" $dict ``` 以下のような構造の辞書が与えられた場合 ``` { user: { role: { humanName: "curator" } } } ``` 上記は `"curator"` を返します。辞書に `user` フィールドさえない場合、 結果は `"guest"` になります。 Dig はガード句を避けたい場合に非常に便利です。特に Go のテンプレートパッケージの `and` はショートサーキットしないためです。例えば `and a.maybeNil a.maybeNil.iNeedThis` は 常に `a.maybeNil.iNeedThis` を評価し、`a` に `maybeNil` フィールドがない場合は パニックします。 `dig` はパイプラインをサポートするために辞書引数を最後に受け取ります。例えば: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge、mustMerge 2つ以上の辞書を1つにマージし、dest 辞書を優先します: 与えられた場合: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` 結果は: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` これはディープマージ操作ですが、ディープコピー操作ではありません。 マージされるネストしたオブジェクトは両方の辞書で同じインスタンスです。 マージと一緒にディープコピーが必要な場合は、マージと一緒に `deepCopy` 関数を 使用してください。例えば、 ``` deepCopy $source | merge $dest ``` `mustMerge` はマージが失敗した場合にエラーを返します。 ### mergeOverwrite、mustMergeOverwrite 2つ以上の辞書を1つにマージし、**右から左**への優先順位で、 dest 辞書の値を上書きします: 与えられた場合: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` 結果は: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` これはディープマージ操作ですが、ディープコピー操作ではありません。 マージされるネストしたオブジェクトは両方の辞書で同じインスタンスです。 マージと一緒にディープコピーが必要な場合は、マージと一緒に `deepCopy` 関数を 使用してください。例えば、 ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` はマージが失敗した場合にエラーを返します。 ### keys `keys` 関数は1つ以上の `dict` 型のすべてのキーの `list` を返します。 辞書は _順序なし_ なので、キーは予測可能な順序にはなりません。 `sortAlpha` でソートできます。 ``` keys $myDict | sortAlpha ``` 複数の辞書を指定すると、キーは連結されます。`uniq` 関数と `sortAlpha` を 使用して、一意でソートされたキーのリストを取得できます。 ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick `pick` 関数は辞書から指定したキーのみを選択し、新しい `dict` を作成します。 ``` $new := pick $myDict "name1" "name2" ``` 上記は `{name1: value1, name2: value2}` を返します。 ### omit `omit` 関数は `pick` に似ていますが、指定したキーに _マッチしない_ すべてのキーを持つ新しい `dict` を返します。 ``` $new := omit $myDict "name1" "name3" ``` 上記は `{name2: value2}` を返します。 ### values `values` 関数は `keys` に似ていますが、ソース `dict` のすべての値を持つ 新しい `list` を返します（辞書は1つのみサポート）。 ``` $vals := values $myDict ``` 上記は `list["value1", "value2", "value 3"]` を返します。`values` 関数は 結果の順序を保証しません。順序が重要な場合は `sortAlpha` を使用してください。 ### deepCopy、mustDeepCopy `deepCopy` と `mustDeepCopy` 関数は値を受け取り、その値のディープコピーを作成します。 これには辞書やその他の構造も含まれます。`deepCopy` は問題があるとパニックし、 `mustDeepCopy` はエラーがあるとテンプレートシステムにエラーを返します。 ``` dict "a" 1 "b" 2 | deepCopy ``` ### Dict 内部に関する注記 `dict` は Go では `map[string]interface{}` として実装されています。 Go 開発者は `map[string]interface{}` 値をコンテキストに渡して、 テンプレートで `dict` として利用可能にすることができます。 ## エンコーディング関数 Helm には以下のエンコードおよびデコード関数があります: - `b64enc`/`b64dec`: Base64 でエンコード/デコード - `b32enc`/`b32dec`: Base32 でエンコード/デコード ## リストと List 関数 Helm は任意のデータの連続リストを含むことができるシンプルな `list` 型を提供しています。 これは配列やスライスに似ていますが、リストは不変のデータ型として使用されるように 設計されています。 整数のリストを作成: ``` $myList := list 1 2 3 4 5 ``` 上記は `[1 2 3 4 5]` のリストを作成します。 Helm は以下のリスト関数を提供しています: [append （mustAppend）](#append-mustappend)、[chunk](#chunk)、[compact （mustCompact）](#compact-mustcompact)、[concat](#concat)、[first （mustFirst）](#first-mustfirst)、[has（mustHas）](#has-musthas)、[initial （mustInitial）](#initial-mustinitial)、[last（mustLast）](#last-mustlast)、 [prepend（mustPrepend）](#prepend-mustprepend)、[rest （mustRest）](#rest-mustrest)、[reverse（mustReverse）](#reverse-mustreverse)、 [seq](#seq)、[index](#index)、[slice（mustSlice）](#slice-mustslice)、[uniq （mustUniq）](#uniq-mustuniq)、[until](#until)、[untilStep](#untilstep)、 [without（mustWithout）](#without-mustwithout)。 ### first、mustFirst リストの先頭項目を取得するには `first` を使用します。 `first $myList` は `1` を返します。 `first` は問題があるとパニックし、`mustFirst` は問題があると テンプレートエンジンにエラーを返します。 ### rest、mustRest リストの末尾（先頭項目以外のすべて）を取得するには `rest` を使用します。 `rest $myList` は `[2 3 4 5]` を返します。 `rest` は問題があるとパニックし、`mustRest` は問題があると テンプレートエンジンにエラーを返します。 ### last、mustLast リストの最後の項目を取得するには `last` を使用します: `last $myList` は `5` を返します。これはリストを逆にしてから `first` を呼び出すのとほぼ同じです。 ### initial、mustInitial これは `last` を補完し、最後の要素 _以外_ のすべてを返します。 `initial $myList` は `[1 2 3 4]` を返します。 `initial` は問題があるとパニックし、`mustInitial` は問題があると テンプレートエンジンにエラーを返します。 ### append、mustAppend 既存のリストに新しい項目を追加し、新しいリストを作成します。 ``` $new = append $myList 6 ``` 上記は `$new` を `[1 2 3 4 5 6]` に設定します。`$myList` は変更されません。 `append` は問題があるとパニックし、`mustAppend` は問題があると テンプレートエンジンにエラーを返します。 ### prepend、mustPrepend リストの先頭に要素をプッシュし、新しいリストを作成します。 ``` prepend $myList 0 ``` 上記は `[0 1 2 3 4 5]` を生成します。`$myList` は変更されません。 `prepend` は問題があるとパニックし、`mustPrepend` は問題があると テンプレートエンジンにエラーを返します。 ### concat 任意の数のリストを1つに連結します。 ``` concat $myList ( list 6 7 ) ( list 8 ) ``` 上記は `[1 2 3 4 5 6 7 8]` を生成します。`$myList` は変更されません。 ### reverse、mustReverse 与えられたリストの要素を逆にした新しいリストを生成します。 ``` reverse $myList ``` 上記はリスト `[5 4 3 2 1]` を生成します。 `reverse` は問題があるとパニックし、`mustReverse` は問題があると テンプレートエンジンにエラーを返します。 ### uniq、mustUniq すべての重複を削除したリストを生成します。 ``` list 1 1 1 2 | uniq ``` 上記は `[1 2]` を生成します。 `uniq` は問題があるとパニックし、`mustUniq` は問題があると テンプレートエンジンにエラーを返します。 ### without、mustWithout `without` 関数はリストから項目をフィルタリングします。 ``` without $myList 3 ``` 上記は `[1 2 4 5]` を生成します。 `without` は複数のフィルターを取ることができます: ``` without $myList 1 3 5 ``` これは `[2 4]` を生成します。 `without` は問題があるとパニックし、`mustWithout` は問題があると テンプレートエンジンにエラーを返します。 ### has、mustHas リストに特定の要素があるかテストします。 ``` has 4 $myList ``` 上記は `true` を返しますが、`has "hello" $myList` は false を返します。 `has` は問題があるとパニックし、`mustHas` は問題があると テンプレートエンジンにエラーを返します。 ### compact、mustCompact リストを受け取り、空の値を持つエントリを削除します。 ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` は空（つまり ""）の項目を削除した新しいリストを返します。 `compact` は問題があるとパニックし、`mustCompact` は問題があると テンプレートエンジンにエラーを返します。 ### index リストの n 番目の要素を取得するには `index list [n]` を使用します。 多次元リストにインデックスするには `index list [n] [m] ...` を使用します。 - `index $myList 0` は `1` を返します。`myList[0]` と同じです。 - `index $myList 0 1` は `myList[0][1]` と同じです。 ### slice、mustSlice リストの部分要素を取得するには `slice list [n] [m]` を使用します。 これは `list[n:m]` と同等です。 - `slice $myList` は `[1 2 3 4 5]` を返します。`myList[:]` と同じです。 - `slice $myList 3` は `[4 5]` を返します。`myList[3:]` と同じです。 - `slice $myList 1 3` は `[2 3]` を返します。`myList[1:3]` と同じです。 - `slice $myList 0 3` は `[1 2 3]` を返します。`myList[:3]` と同じです。 `slice` は問題があるとパニックし、`mustSlice` は問題があると テンプレートエンジンにエラーを返します。 ### until `until` 関数は整数の範囲を構築します。 ``` until 5 ``` 上記はリスト `[0, 1, 2, 3, 4]` を生成します。 これは `range $i, $e := until 5` でループする際に便利です。 ### untilStep `until` と同様に、`untilStep` はカウント整数のリストを生成します。 ただし、開始、終了、ステップを定義できます: ``` untilStep 3 6 2 ``` 上記は 3 から開始し、6 以上になるまで 2 を加算して `[3 5]` を生成します。 これは Python の `range` 関数に似ています。 ### seq bash の `seq` コマンドのように動作します。 * 1 パラメータ（end）- 1 から `end` までのすべてのカウント整数を生成します（両端含む）。 * 2 パラメータ（start, end）- `start` から `end` までのすべてのカウント整数を 1 ずつ増減して生成します（両端含む）。 * 3 パラメータ（start, step, end）- `start` から `end` までのすべてのカウント整数を `step` ずつ増減して生成します（両端含む）。 ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk リストを指定したサイズのチャンクに分割するには `chunk size list` を使用します。 これはページネーションに便利です。 ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` これはリストのリスト `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]` を生成します。 ## 算術関数 すべての算術関数は、特に指定がない限り `int64` 値で動作します。 以下の算術関数が利用可能です: [add](#add)、[add1](#add1)、 [ceil](#ceil)、[div](#div)、[floor](#floor)、[len](#len)、[max](#max)、 [min](#min)、[mod](#mod)、[mul](#mul)、[round](#round)、[sub](#sub)。 ### add `add` で数値を合計します。2つ以上の入力を受け付けます。 ``` add 1 2 3 ``` ### add1 1 を加算するには `add1` を使用します。 ### sub 減算するには `sub` を使用します。 ### div `div` で整数除算を行います。 ### mod `mod` で剰余を求めます。 ### mul `mul` で乗算します。2つ以上の入力を受け付けます。 ``` mul 1 2 3 ``` ### max 一連の整数の最大値を返します。 以下は `3` を返します: ``` max 1 2 3 ``` ### min 一連の整数の最小値を返します。 `min 1 2 3` は `1` を返します。 ### len 引数の長さを整数として返します。 ``` len .Arg ``` ## 浮動小数点算術関数 すべての算術関数は `float64` 値で動作します。 ### addf `addf` で数値を合計します。 以下は `5.5` を返します: ``` addf 1.5 2 2 ``` ### add1f 1 を加算するには `add1f` を使用します。 ### subf 減算するには `subf` を使用します。 以下は `7.5 - 2 - 3` と同等で、`2.5` を返します: ``` subf 7.5 2 3 ``` ### divf `divf` で整数除算を行います。 以下は `10 / 2 / 4` と同等で、`1.25` を返します: ``` divf 10 2 4 ``` ### mulf `mulf` で乗算します。 以下は `6` を返します: ``` mulf 1.5 2 2 ``` ### maxf 一連の浮動小数点の最大値を返します: 以下は `3` を返します: ``` maxf 1 2.5 3 ``` ### minf 一連の浮動小数点の最小値を返します。 以下は `1.5` を返します: ``` minf 1.5 2 3 ``` ### floor 入力値以下の最大の浮動小数点値を返します。 `floor 123.9999` は `123.0` を返します。 ### ceil 入力値以上の最小の浮動小数点値を返します。 `ceil 123.001` は `124.0` を返します。 ### round 小数点以下の指定した桁数に余りを丸めた浮動小数点値を返します。 `round 123.555555 3` は `123.556` を返します。 ## ネットワーク関数 Helm には1つのネットワーク関数 `getHostByName` があります。 `getHostByName` はドメイン名を受け取り、IP アドレスを返します。 `getHostByName "www.google.com"` は `www.google.com` に対応する IP アドレスを返します。 この関数を使用するには、helm コマンドラインで `--enable-dns` オプションを渡す必要があります。 ## ファイルパス関数 Helm テンプレート関数はファイルシステムへのアクセスを許可しませんが、 ファイルパスの規則に従う文字列を扱う関数を提供しています。 [base](#base)、[clean](#clean)、[dir](#dir)、[ext](#ext)、[isAbs](#isabs) があります。 ### base パスの最後の要素を返します。 ``` base "foo/bar/baz" ``` 上記は "baz" を出力します。 ### dir 最後の部分を除いたディレクトリを返します。つまり `dir "foo/bar/baz"` は `foo/bar` を返します。 ### clean パスをクリーンアップします。 ``` clean "foo/bar/../baz" ``` 上記は `..` を解決し、`foo/baz` を返します。 ### ext ファイル拡張子を返します。 ``` ext "foo.bar" ``` 上記は `.bar` を返します。 ### isAbs ファイルパスが絶対パスかどうかを確認するには `isAbs` を使用します。 ## リフレクション関数 Helm は初歩的なリフレクションツールを提供しています。 これらは上級テンプレート開発者が特定の値の基盤となる Go の型情報を 理解するのに役立ちます。Helm は Go で書かれており、厳密に型付けされています。 型システムはテンプレート内でも適用されます。 Go には `string`、`slice`、`int64`、`bool` などのいくつかのプリミティブ _kind_ があります。 Go にはオープンな _type_ システムがあり、開発者は独自の型を作成できます。 Helm は [kind 関数](#kind-functions) と [type 関数](#type-functions) を通じて それぞれに対する関数セットを提供しています。2つの値を比較するための [deepEqual](#deepequal) 関数も提供されています。 ### Kind 関数 Kind 関数は2つあります: `kindOf` はオブジェクトの kind を返します。 ``` kindOf "hello" ``` 上記は `string` を返します。単純なテスト（`if` ブロックなど）では、 `kindIs` 関数で値が特定の kind かどうかを確認できます: ``` kindIs "int" 123 ``` 上記は `true` を返します。 ### Type 関数 型は扱いが少し難しいため、3つの異なる関数があります: - `typeOf` は値の基盤となる型を返します: `typeOf $foo` - `typeIs` は `kindIs` のようなものですが、型用です: `typeIs "*io.Buffer" $myVal` - `typeIsLike` は `typeIs` のように動作しますが、ポインタの参照解除も行います **注意:** これらはいずれも、何かが特定のインターフェースを実装しているかどうかを テストできません。そのためには、インターフェースを事前にコンパイルする必要があるためです。 ### deepEqual `deepEqual` は2つの値が["深く等しい"](https://golang.org/pkg/reflect/#DeepEqual) 場合に true を返します。 非プリミティブ型でも動作します（組み込みの `eq` と比較して）。 ``` deepEqual (list 1 2 3) (list 1 2 3) ``` 上記は `true` を返します。 ## セマンティックバージョン関数 一部のバージョンスキームは簡単に解析・比較できます。Helm は [SemVer 2](http://semver.org) バージョンを扱うための関数を提供しています。これには [semver](#semver) と [semverCompare](#semvercompare) が含まれます。以下では、比較のための 範囲の使用方法についても詳しく説明します。 ### semver `semver` 関数は文字列をセマンティックバージョンに解析します: ``` $version := semver "1.2.3-alpha.1+123" ``` _パーサーが失敗した場合、テンプレートの実行はエラーで停止します。_ この時点で、`$version` は以下のプロパティを持つ `Version` オブジェクトへのポインタです: - `$version.Major`: メジャー番号（上記では `1`） - `$version.Minor`: マイナー番号（上記では `2`） - `$version.Patch`: パッチ番号（上記では `3`） - `$version.Prerelease`: プレリリース（上記では `alpha.1`） - `$version.Metadata`: ビルドメタデータ（上記では `123`） - `$version.Original`: 元のバージョン文字列 さらに、`Compare` 関数を使用して `Version` を別の `version` と比較できます: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` 上記は `-1` を返します。 戻り値は: - `-1`: 指定した semver が `Compare` メソッドを呼び出した semver より大きい場合 - `1`: `Compare` 関数を呼び出したバージョンの方が大きい場合 - `0`: 同じバージョンの場合 （SemVer では、バージョン比較操作中に `Metadata` フィールドは比較されません。） ### semverCompare より堅牢な比較関数として `semverCompare` が提供されています。 このバージョンはバージョン範囲をサポートします: - `semverCompare "1.2.3" "1.2.3"` は完全一致をチェックします - `semverCompare "~1.2.0" "1.2.3"` はメジャーとマイナーバージョンが一致し、 第2パラメータのパッチ番号が第1パラメータ _以上_ であることをチェックします。 SemVer 関数は Sprig の作成者による [Masterminds semver ライブラリ](https://github.com/Masterminds/semver) を使用しています。 ### 基本的な比較 比較には2つの要素があります。まず、比較文字列はスペースまたはカンマで区切られた AND 比較のリストです。これらは ||（OR）比較で区切られます。 例えば、`">= 1.2 < 3.0.0 || >= 4.2.3"` は、1.2 以上かつ 3.0.0 未満、 または 4.2.3 以上の比較を探しています。 基本的な比較は: - `=`: 等しい（演算子なしと同義） - `!=`: 等しくない - `>`: より大きい - `<`: より小さい - `>=`: 以上 - `<=`: 以下 ### プレリリースバージョンの扱い プレリリースは、安定版または一般公開リリースの前のソフトウェアリリースに 使用されます。プレリリースの例には、開発版、アルファ版、ベータ版、 リリース候補版などがあります。プレリリースは `1.2.3-beta.1` のようなバージョンで、 安定版リリースは `1.2.3` です。優先順位では、プレリリースは関連するリリースの 前に来ます。この例では `1.2.3-beta.1 < 1.2.3` です。 セマンティックバージョン仕様によると、プレリリースは そのリリース版と API 互換でない場合があります。以下のように述べられています: > プレリリースバージョンは、バージョンが不安定であり、 > 関連する通常バージョンで示される意図された互換性要件を > 満たさない可能性があることを示します。 プレリリース比較子なしの制約を使用した SemVer 比較は、 リリースのリストを見るときにプレリリースバージョンをスキップします。 例えば、`>=1.2.3` はプレリリースをスキップしますが、 `>=1.2.3-0` はプレリリースを評価して見つけます。 比較例でプレリリースバージョンとして `0` を使用する理由は、 プレリリースには仕様に従って ASCII 英数字とハイフン（および `.` 区切り）のみを 含めることができるためです。ソートは仕様に従って ASCII ソート順で行われます。 ASCII ソート順で最も低い文字は `0` です（[ASCII テーブル](http://www.asciitable.com/)を参照）。 ASCII ソート順を理解することは重要です。なぜなら、A-Z は a-z の前に来るからです。 つまり、`>=1.2.3-BETA` は `1.2.3-alpha` を返します。 大文字小文字の区別から期待することはここでは適用されません。 これは仕様で指定されている ASCII ソート順によるものです。 ### ハイフン範囲比較 範囲を扱う方法は複数あり、最初はハイフン範囲です。 以下のような形式になります: - `1.2 - 1.4.5` は `>= 1.2 <= 1.4.5` と同等 - `2.3.4 - 4.5` は `>= 2.3.4 <= 4.5` と同等 ### 比較でのワイルドカード `x`、`X`、`*` 文字はワイルドカード文字として使用できます。 これはすべての比較演算子で動作します。`=` 演算子で使用すると、 パッチレベルの比較にフォールバックします（下記のチルダを参照）。例えば、 - `1.2.x` は `>= 1.2.0, < 1.3.0` と同等 - `>= 1.2.x` は `>= 1.2.0` と同等 - `<= 2.x` は `< 3` と同等 - `*` は `>= 0.0.0` と同等 ### チルダ範囲比較（パッチ） チルダ（`~`）比較演算子は、マイナーバージョンが指定されている場合は パッチレベルの範囲、マイナー番号がない場合はメジャーレベルの変更用です。 例えば、 - `~1.2.3` は `>= 1.2.3, < 1.3.0` と同等 - `~1` は `>= 1, < 2` と同等 - `~2.3` は `>= 2.3, < 2.4` と同等 - `~1.2.x` は `>= 1.2.0, < 1.3.0` と同等 - `~1.x` は `>= 1, < 2` と同等 ### キャレット範囲比較（メジャー） キャレット（`^`）比較演算子は、安定版（1.0.0）リリース後の メジャーレベルの変更用です。1.0.0 リリース前は、マイナーバージョンが API 安定性レベルとして機能します。これは API バージョンの比較に便利です。 メジャーな変更は API を壊すためです。例えば、 - `^1.2.3` は `>= 1.2.3, < 2.0.0` と同等 - `^1.2.x` は `>= 1.2.0, < 2.0.0` と同等 - `^2.3` は `>= 2.3, < 3` と同等 - `^2.x` は `>= 2.0.0, < 3` と同等 - `^0.2.3` は `>=0.2.3 <0.3.0` と同等 - `^0.2` は `>=0.2.0 <0.3.0` と同等 - `^0.0.3` は `>=0.0.3 <0.0.4` と同等 - `^0.0` は `>=0.0.0 <0.1.0` と同等 - `^0` は `>=0.0.0 <1.0.0` と同等 ## URL 関数 Helm には [urlParse](#urlparse)、[urlJoin](#urljoin)、 [urlquery](#urlquery) 関数が含まれており、URL の部分を扱えます。 ### urlParse 文字列を URL として解析し、URL 部分を含む辞書を生成します。 ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` 上記は URL オブジェクトを含む辞書を返します: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` これは Go 標準ライブラリの URL パッケージを使用して実装されています。 詳細は https://golang.org/pkg/net/url/#URL を参照してください。 ### urlJoin マップ（`urlParse` で生成）を結合して URL 文字列を生成します。 ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` 上記は以下の文字列を返します: ``` http://host:80/path?query#fragment ``` ### urlquery 引数として渡された値のエスケープ版を返します。 URL のクエリ部分に埋め込むのに適しています。 ``` $var := urlquery "string for query" ``` ## UUID 関数 Helm は UUID v4 ユニバーサル一意識別子を生成できます。 ``` uuidv4 ``` 上記は v4（ランダム生成）タイプの新しい UUID を返します。 ## Kubernetes と Chart 関数 Helm には Kubernetes を扱うための関数が含まれています: [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas)、 [Files](#file-functions)、[lookup](#lookup)。 ### lookup `lookup` は実行中のクラスターでリソースを検索するために使用されます。 `helm template` コマンドで使用すると、常に空のレスポンスを返します。 詳細は [lookup 関数のドキュメント](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function)を 参照してください。 ### .Capabilities.APIVersions.Has API バージョンまたはリソースがクラスターで利用可能かどうかを返します。 ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` 詳細は[組み込みオブジェクトのドキュメント](/chart_template_guide/builtin_objects.md)を 参照してください。 ### File 関数 chart 内の特別でないファイルにアクセスできる関数がいくつかあります。 例えば、アプリケーション設定ファイルにアクセスする場合などです。 これらは[テンプレート内でのファイルへのアクセス](/chart_template_guide/accessing_files.md)で ドキュメント化されています。 _注意: これらの関数の多くのドキュメントは [Sprig](https://github.com/Masterminds/sprig) から来ています。 Sprig は Go アプリケーションで利用可能なテンプレート関数ライブラリです。_ ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: テンプレート関数とパイプライン description: テンプレートでの関数の使い方を解説します。 sidebar_position: 5 --- これまでに、テンプレートに情報を配置する方法を見てきました。しかし、その情報はそのまま配置されます。時には、データをより使いやすい形に変換したい場合があります。 まずベストプラクティスから始めましょう: `.Values` オブジェクトからの文字列をテンプレートに挿入する際は、その文字列をクォートで囲むべきです。テンプレートディレクティブ内で `quote` 関数を呼び出すことで実現できます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` テンプレート関数は `functionName arg1 arg2...` という構文に従います。上記のスニペットでは、`quote .Values.favorite.drink` が `quote` 関数を呼び出し、1 つの引数を渡しています。 Helm には 60 以上の関数が用意されています。そのうちのいくつかは [Go テンプレート言語](https://godoc.org/text/template)自体で定義されています。その他のほとんどは [Sprig テンプレートライブラリ](https://masterminds.github.io/sprig/)の一部です。これらの関数については、以降の例を進めながら解説していきます。 > 「Helm テンプレート言語」という表現は Helm 固有のものと思われがちですが、実際には Go テンプレート言語、追加の関数、そしてテンプレートに特定のオブジェクトを公開するためのさまざまなラッパーの組み合わせです。Go テンプレートに関する多くのリソースが、テンプレートを学ぶ際に役立ちます。 ## パイプライン テンプレート言語の強力な機能の 1 つに _パイプライン_ の概念があります。UNIX のコンセプトに基づき、パイプラインは一連のテンプレートコマンドを連結して、一連の変換をコンパクトに表現するためのツールです。つまり、複数の処理を順番に効率よく実行できます。上記の例をパイプラインを使って書き直してみましょう。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` この例では、`quote ARGUMENT` と呼び出す代わりに、順序を逆にしています。パイプライン（`|`）を使って引数を関数に「送って」います: `.Values.favorite.drink | quote`。パイプラインを使用すると、複数の関数を連結できます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > 順序を逆にする書き方はテンプレートでよく使われます。`quote .val` よりも `.val | quote` の形式をよく目にするでしょう。どちらでも構いません。 評価されると、このテンプレートは以下のような出力を生成します: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 元の `pizza` が `"PIZZA"` に変換されていることに注目してください。 このようにパイプラインで引数を渡す場合、最初の評価結果（`.Values.favorite.drink`）は _関数の最後の引数_ として送られます。上記の drink の例を、2 つの引数を取る関数 `repeat COUNT STRING` を使って説明してみましょう: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` `repeat` 関数は与えられた文字列を指定された回数だけ繰り返すので、出力は以下のようになります: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## `default` 関数の使用 テンプレートで頻繁に使用される関数の 1 つに `default` 関数があります: `default DEFAULT_VALUE GIVEN_VALUE`。この関数を使用すると、値が省略された場合にテンプレート内でデフォルト値を指定できます。上記の drink の例を修正してみましょう: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` 通常どおり実行すると、`coffee` が表示されます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 次に、`values.yaml` から favorite drink の設定を削除します: ```yaml favorite: #drink: coffee food: pizza ``` `helm install --dry-run --debug fair-worm ./mychart` を再実行すると、以下の YAML が生成されます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` 実際の chart では、すべての静的なデフォルト値は `values.yaml` に定義し、`default` コマンドで重複させるべきではありません（冗長になるため）。ただし、`default` コマンドは `values.yaml` 内で宣言できない計算値に最適です。例: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` 状況によっては、`default` よりも `if` 条件ガードを使用する方が適している場合があります。次のセクションで説明します。 テンプレート関数とパイプラインは、情報を変換して YAML に挿入する強力な方法です。しかし、単に文字列を挿入するだけでなく、より高度なテンプレートロジックが必要な場合もあります。次のセクションでは、テンプレート言語が提供する制御構造について説明します。 ## `lookup` 関数の使用 `lookup` 関数を使用すると、実行中のクラスター内のリソースを _ルックアップ_ できます。lookup 関数の構文は `lookup apiVersion, kind, namespace, name -> resource or resource list` です。 | パラメータ | 型 | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | `name` と `namespace` はどちらもオプションで、空文字列（`""`）として渡すことができます。ただし、namespace スコープのリソースを扱う場合は、`name` と `namespace` の両方を指定する必要があります。 以下のパラメータの組み合わせが可能です: | 動作 | lookup 関数 | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | `lookup` がオブジェクトを返す場合、辞書が返されます。この辞書をさらにナビゲートして特定の値を抽出できます。 以下の例は `mynamespace` オブジェクトに存在するアノテーションを返します: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` `lookup` がオブジェクトのリストを返す場合、`items` フィールドを通じてオブジェクトリストにアクセスできます: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` オブジェクトが見つからない場合、空の値が返されます。これを使用してオブジェクトの存在を確認できます。 `lookup` 関数は Helm の既存の Kubernetes 接続設定を使用して Kubernetes に問い合わせを行います。API サーバーとのやり取り中にエラーが返された場合（たとえば、リソースへのアクセス権限がない場合など）、Helm のテンプレート処理は失敗します。 Helm は `helm template|install|upgrade|delete|rollback --dry-run` 操作中に Kubernetes API サーバーに接続しない点に注意してください。実行中のクラスターに対して `lookup` をテストするには、`helm template|install|upgrade|delete|rollback --dry-run=server` を使用してクラスター接続を許可する必要があります。 ## 演算子は関数である テンプレートでは、演算子（`eq`、`ne`、`lt`、`gt`、`and`、`or` など）はすべて関数として実装されています。パイプラインでは、括弧（`(`、`)`）を使用して演算をグループ化できます。 次は関数とパイプラインから離れて、条件、ループ、スコープ修飾子を使用したフロー制御について説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: はじめに description: chart テンプレートのクイックガイドです。 sidebar_position: 2 --- このガイドのセクションでは、chart を作成し、最初のテンプレートを追加します。ここで作成する chart は、ガイドの残りの部分を通して使用します。 まず、Helm chart について簡単に見ていきましょう。 ## Chart の構造 [Chart ガイド](/topics/charts.md)で説明されているように、Helm chart は次のような構造になっています: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` `templates/` ディレクトリはテンプレートファイル用です。Helm が chart を評価すると、`templates/` ディレクトリ内のすべてのファイルをテンプレートレンダリングエンジンに通して処理します。その後、テンプレートの処理結果を収集し、Kubernetes に送信します。 `values.yaml` ファイルもテンプレートにとって重要です。このファイルには chart の _デフォルト値_ が含まれています。これらの値は、`helm install` や `helm upgrade` の実行時にユーザーが上書きできます。 `Chart.yaml` ファイルには chart の説明が含まれています。テンプレート内からこの情報にアクセスできます。 `charts/` ディレクトリには他の chart（_サブチャート_ と呼びます）を含めることが _できます_。このガイドの後半で、テンプレートレンダリング時にサブチャートがどのように動作するかを説明します。 ## スターター Chart の作成 このガイドでは、`mychart` というシンプルな chart を作成し、その中にいくつかのテンプレートを作成します。 ```console $ helm create mychart Creating mychart ``` ### `mychart/templates/` の概要 `mychart/templates/` ディレクトリを見ると、すでにいくつかのファイルがあることに気づきます。 - `NOTES.txt`: chart の「ヘルプテキスト」です。ユーザーが `helm install` を実行したときに表示されます。 - `deployment.yaml`: Kubernetes の [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) を作成するための基本的なマニフェストです。 - `service.yaml`: Deployment のための [Service エンドポイント](https://kubernetes.io/docs/concepts/services-networking/service/)を作成する基本的なマニフェストです。 - `_helpers.tpl`: chart 全体で再利用できるテンプレートヘルパーを記述する場所です。 これから行うことは... _これらをすべて削除することです！_ そうすることで、チュートリアルを最初から進められます。実際には、ガイドを進めながら独自の `NOTES.txt` と `_helpers.tpl` を作成していきます。 ```console $ rm -rf mychart/templates/* ``` 本番環境用の chart を作成する場合、これらの基本バージョンがあると非常に便利です。そのため、日常的な chart 作成では削除したくないでしょう。 ## 最初のテンプレート 最初に作成するテンプレートは ConfigMap です。Kubernetes では、ConfigMap は設定データを格納するためのオブジェクトです。Pod などの他のリソースから ConfigMap 内のデータにアクセスできます。 ConfigMap は基本的なリソースなので、最初のテンプレートとして最適です。 まず、`mychart/templates/configmap.yaml` というファイルを作成します: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** テンプレート名には厳密な命名パターンはありません。ただし、YAML ファイルには `.yaml` 拡張子を、ヘルパーには `.tpl` を使用することを推奨します。 上記の YAML ファイルは、最小限の必須フィールドだけを持つ基本的な ConfigMap です。このファイルは `mychart/templates/` ディレクトリにあるため、テンプレートエンジンを通して処理されます。 `mychart/templates/` ディレクトリにこのようなプレーンな YAML ファイルを配置しても問題ありません。Helm がこのテンプレートを読み込むと、そのまま Kubernetes に送信します。 このシンプルなテンプレートで、インストール可能な chart ができました。次のようにインストールできます: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Helm を使用して release を取得し、実際に読み込まれたテンプレートを確認できます。 ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` `helm get manifest` コマンドは release 名（`full-coral`）を受け取り、サーバーにアップロードされたすべての Kubernetes リソースを出力します。各ファイルは YAML ドキュメントの開始を示す `---` で始まり、その後にどのテンプレートファイルがこの YAML ドキュメントを生成したかを示す自動生成されたコメント行が続きます。 そこから先を見ると、YAML データは `configmap.yaml` ファイルに記述したものとまったく同じであることがわかります。 では、release をアンインストールしましょう: `helm uninstall full-coral` ### シンプルなテンプレート呼び出しの追加 リソースに `name:` をハードコーディングするのは、一般的に良くないプラクティスと考えられています。名前は release ごとに一意であるべきです。そのため、release 名を挿入して name フィールドを生成したいと思うかもしれません。 **TIP:** `name:` フィールドは DNS システムの制限により 63 文字に制限されています。そのため、release 名は 53 文字に制限されています。Kubernetes 1.3 以前では 24 文字（つまり名前は 14 文字）に制限されていました。 `configmap.yaml` を次のように変更します。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` 大きな変更は `name:` フィールドの値です。現在は `{{ .Release.Name }}-configmap` となっています。 > テンプレートディレクティブは `{{` と `}}` ブロックで囲まれています。 テンプレートディレクティブ `{{ .Release.Name }}` は release 名をテンプレートに挿入します。テンプレートに渡される値は _名前空間付きオブジェクト_ と考えることができ、ドット（`.`）が各名前空間要素を区切ります。 `Release` の前の先頭のドットは、このスコープの最上位の名前空間から開始することを示します（スコープについては後で説明します）。つまり、`.Release.Name` は「最上位の名前空間から開始し、`Release` オブジェクトを見つけ、その中の `Name` というオブジェクトを探す」と読むことができます。 `Release` オブジェクトは Helm の組み込みオブジェクトの 1 つで、後で詳しく説明します。今のところは、これが Helm ライブラリが release に割り当てる release 名を表示するということだけ理解しておいてください。 このテンプレートディレクティブを使用してリソースをインストールすると、すぐに結果が確認できます: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` `helm get manifest clunky-serval` を実行すると、生成された YAML 全体を確認できます。 Kubernetes 内の ConfigMap の名前が、以前の `mychart-configmap` ではなく `clunky-serval-configmap` になっていることに注目してください。 これで、テンプレートの最も基本的な形を見てきました: `{{` と `}}` にテンプレートディレクティブが埋め込まれた YAML ファイルです。次のパートでは、テンプレートについてさらに深く見ていきます。しかし先に進む前に、テンプレートの構築を速くする 1 つのテクニックがあります: テンプレートのレンダリングをテストしたいが、実際には何もインストールしたくない場合は、`helm install --debug --dry-run goodly-guppy ./mychart` を使用できます。これによりテンプレートがレンダリングされます。しかし、chart をインストールする代わりに、レンダリングされたテンプレートを返すので、出力を確認できます: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` `--dry-run` を使用するとコードのテストが簡単になりますが、Kubernetes 自体が生成されたテンプレートを受け入れることは保証されません。`--dry-run` が動作するからといって、chart がインストールされると想定しないでください。 [Chart テンプレートガイド](/chart_template_guide/index.mdx)では、ここで定義した基本的な chart を使用して、Helm テンプレート言語を詳しく探っていきます。そして、組み込みオブジェクトから始めます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: .helmignore ファイル description: "`.helmignore` ファイルは、Helm chart に含めたくないファイルを指定するために使用します。" sidebar_position: 12 --- `.helmignore` ファイルは、Helm chart に含めたくないファイルを指定するために使用します。 このファイルが存在する場合、`helm package` コマンドはアプリケーションをパッケージ化する際に `.helmignore` ファイルで指定されたパターンに一致するすべてのファイルを無視します。 これにより、不要なファイルや機密性の高いファイル、ディレクトリが Helm chart に含まれることを防ぐことができます。 `.helmignore` ファイルは、Unix シェルの glob マッチング、相対パスマッチング、および否定（先頭に ! を付ける）をサポートしています。1 行につき 1 つのパターンのみ認識されます。 以下は `.helmignore` ファイルの例です: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` .gitignore との主な違いは以下のとおりです: - `**` 構文はサポートされていません。 - glob ライブラリは fnmatch(3) ではなく、Go の `filepath.Match` を使用しています。 - 末尾のスペースは常に無視されます（エスケープシーケンスはサポートされていません）。 - `\!` を特別な先頭シーケンスとして使用することはできません。 - `.helmignore` ファイルはデフォルトでは自身を除外しないため、明示的にエントリを追加する必要があります。 **このドキュメントの改善にご協力ください。** 情報の追加、修正、削除については、[issue を作成する](https://github.com/helm/helm-www/issues)か、プルリクエストを送信してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: チャートテンプレートガイド sidebar_position: 5 --- # チャートテンプレート開発者ガイド このガイドでは、テンプレート言語に重点を置いて、 Helm のチャートテンプレートの概要を説明します。 テンプレートは、Kubernetes が理解できる YAML 形式のリソース記述であるマニフェストファイルを生成します。 テンプレートの構造、テンプレートの使用方法、 Go テンプレートの作成方法、作業のデバッグ方法について説明します。 このガイドでは、次の概念に焦点を当てています。 - Helm テンプレート言語 - 値の使用 - テンプレートを操作するためのテクニック このガイドは、Helm テンプレート言語の詳細を学ぶことを目的としています。 他のガイドは、紹介資料、例、 およびベストプラクティスを提供します。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: 名前付きテンプレート description: 名前付きテンプレートの定義方法を解説します。 sidebar_position: 9 --- ここからは 1 つのテンプレートを超えて、複数のテンプレートを作成していきます。このセクションでは、1 つのファイル内で _名前付きテンプレート_ を定義し、それを他の場所で使用する方法を説明します。_名前付きテンプレート_（_partial_ や _subtemplate_ とも呼ばれます）は、ファイル内で定義され、名前が付けられたテンプレートです。作成方法を 2 つ、使用方法をいくつか紹介します。 [フロー制御](/chart_template_guide/control_structures.md)のセクションでは、テンプレートの宣言と管理のための 3 つのアクションを紹介しました: `define`、`template`、`block` です。このセクションでは、これら 3 つのアクションに加えて、`template` アクションと同様に機能する特別な `include` 関数も取り上げます。 テンプレートに名前を付ける際に覚えておくべき重要な点があります: **テンプレート名はグローバルです**。同じ名前のテンプレートを 2 つ宣言した場合、最後に読み込まれたものが使用されます。サブチャートのテンプレートはトップレベルのテンプレートと一緒にコンパイルされるため、_chart 固有の名前_ でテンプレートに名前を付けるように注意してください。 一般的な命名規則として、定義した各テンプレートに chart 名をプレフィックスとして付ける方法があります: `{{ define "mychart.labels" }}`。chart 固有の名前をプレフィックスとして使用することで、同じ名前のテンプレートを実装している異なる chart 間での衝突を回避できます。 この動作は、chart の異なるバージョン間でも同様に適用されます。`mychart` のバージョン `1.0.0` で特定の方法でテンプレートを定義し、`mychart` のバージョン `2.0.0` で既存の名前付きテンプレートを変更した場合、最後に読み込まれたものが使用されます。この問題を回避するには、chart 名にバージョンを含めるという方法もあります: `{{ define "mychart.v1.labels" }}` や `{{ define "mychart.v2.labels" }}` のようにします。 ## Partial と `_` ファイル ここまでは 1 つのファイルを使用し、そのファイルには単一のテンプレートが含まれていました。しかし、Helm のテンプレート言語では、名前付きの埋め込みテンプレートを作成し、他の場所から名前でアクセスすることができます。 これらのテンプレートの書き方の詳細に入る前に、ファイルの命名規則について説明します: * `templates/` 内のほとんどのファイルは、Kubernetes マニフェストを含むものとして扱われます * `NOTES.txt` は例外です * ファイル名がアンダースコア（`_`）で始まるファイルは、マニフェストを含んでいないと見なされます。これらのファイルは Kubernetes オブジェクト定義としてはレンダリングされませんが、他の chart テンプレート内のどこからでも使用できます これらのファイルは、partial やヘルパーを格納するために使用されます。実際、最初に `mychart` を作成したときに、`_helpers.tpl` というファイルがあったことを思い出してください。このファイルがテンプレート partial のデフォルトの保存場所です。 ## `define` と `template` によるテンプレートの宣言と使用 `define` アクションを使用すると、テンプレートファイル内で名前付きテンプレートを作成できます。構文は以下のとおりです: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` たとえば、Kubernetes のラベルブロックをカプセル化するテンプレートを定義できます: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` このテンプレートを既存の ConfigMap に埋め込み、`template` アクションで呼び出すことができます: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` テンプレートエンジンがこのファイルを読み込むと、`mychart.labels` への参照を保存し、`template "mychart.labels"` が呼び出されるまで待機します。そして、そのテンプレートをインラインでレンダリングします。結果は以下のようになります: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 注意: この例のように template で呼び出されない限り、`define` は出力を生成しません。 慣例として、Helm chart ではこれらのテンプレートを partial ファイル（通常は `_helpers.tpl`）に配置します。この関数をそこに移動してみましょう: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` 慣例として、`define` 関数には何をするかを説明する簡単なドキュメントブロック（`{{/* ... */}}`）を付けるべきです。 この定義は `_helpers.tpl` にありますが、`configmap.yaml` からも引き続きアクセスできます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 前述のとおり、**テンプレート名はグローバルです**。そのため、同じ名前で 2 つのテンプレートが宣言された場合、最後に読み込まれたものが使用されます。サブチャートのテンプレートはトップレベルのテンプレートと一緒にコンパイルされるため、_chart 固有の名前_ でテンプレートに名前を付けるのがベストプラクティスです。一般的な命名規則として、定義した各テンプレートに chart 名をプレフィックスとして付ける方法があります: `{{ define "mychart.labels" }}`。 ## テンプレートのスコープ設定 上記で定義したテンプレートでは、オブジェクトを一切使用せず、関数のみを使用しました。定義したテンプレートを修正して、chart 名と chart バージョンを含めてみましょう: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` これをレンダリングすると、以下のようなエラーが発生します: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` レンダリング結果を確認するには、`--disable-openapi-validation` を付けて再実行します: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`。 結果は期待どおりではありません: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` 名前とバージョンはどうなったのでしょうか？定義したテンプレートのスコープ内になかったのです。名前付きテンプレート（`define` で作成されたもの）がレンダリングされると、`template` 呼び出しで渡されたスコープを受け取ります。この例では、テンプレートを以下のように呼び出していました: ```yaml {{- template "mychart.labels" }} ``` スコープが渡されていないため、テンプレート内では `.` の中の何にもアクセスできません。これは簡単に修正できます。テンプレートにスコープを渡すだけです: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` `template` 呼び出しの最後に `.` を渡していることに注目してください。`.Values` や `.Values.favorite` など、任意のスコープを渡すこともできますが、ここではトップレベルのスコープが必要です。名前付きテンプレートのコンテキスト内では、`$` は渡されたスコープを参照し、グローバルスコープを参照するわけではありません。 このテンプレートを `helm install --dry-run --debug plinking-anaco ./mychart` で実行すると、以下の結果が得られます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` これで `{{ .Chart.Name }}` は `mychart` に、`{{ .Chart.Version }}` は `0.1.0` に解決されます。 ## `include` 関数 以下のような単純なテンプレートを定義したとします: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` このテンプレートをテンプレートの `labels:` セクションと `data:` セクションの両方に挿入したいとします: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` これをレンダリングすると、以下のようなエラーが発生します: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` レンダリング結果を確認するには、`--disable-openapi-validation` を付けて再実行します: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`。 出力は期待どおりではありません: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` 両方の場所で `app_version` のインデントがおかしいことに注目してください。なぜでしょうか？置換されたテンプレートのテキストが左揃えになっているからです。`template` はアクションであり関数ではないため、`template` 呼び出しの出力を他の関数に渡す方法がありません。データは単にインラインで挿入されるだけです。 この問題を回避するため、Helm には `template` の代わりとなる方法が用意されています。テンプレートの内容を現在のパイプラインにインポートし、パイプライン内の他の関数に渡すことができます。 以下は、`indent` を使用して `mychart.app` テンプレートを正しくインデントするように修正した例です: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` これで生成される YAML は各セクションで正しくインデントされます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Helm テンプレートでは、`template` よりも `include` を使用することが推奨されます。これにより、YAML ドキュメントの出力フォーマットをより適切に処理できるためです。 場合によっては、テンプレートとしてではなく、コンテンツをそのままインポートしたいことがあります。つまり、ファイルをそのまま取り込みたい場合です。これは、次のセクションで説明する `.Files` オブジェクトを通じてファイルにアクセスすることで実現できます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: NOTES.txt ファイルの作成 description: chart のユーザーに使い方を伝える方法を解説します。 sidebar_position: 10 --- このセクションでは、chart のユーザーに使い方を伝えるための Helm の機能を紹介します。`helm install` や `helm upgrade` の実行後、Helm はユーザーに役立つ情報を出力できます。この情報はテンプレートを使って自由にカスタマイズできます。 chart にインストール時のメモを追加するには、`templates/NOTES.txt` ファイルを作成します。このファイルはプレーンテキストですが、テンプレートとして処理されるため、通常のテンプレート関数やオブジェクトをすべて利用できます。 それでは、簡単な `NOTES.txt` ファイルを作成してみましょう: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` `helm install rude-cardinal ./mychart` を実行すると、以下のようなメッセージが末尾に表示されます: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` `NOTES.txt` を活用すれば、新しくインストールした chart の使い方をユーザーに詳しく伝えられます。`NOTES.txt` ファイルの作成は必須ではありませんが、強く推奨します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: サブ chart とグローバル値 description: サブ chart およびグローバル値との連携について解説します。 sidebar_position: 11 --- これまで 1 つの chart のみを扱ってきました。しかし chart には依存関係を持たせることができ、依存先の chart は _サブ chart_ と呼ばれます。サブ chart も独自の values とテンプレートを持ちます。このセクションでは、サブ chart を作成し、テンプレート内から values にアクセスするさまざまな方法を説明します。 実際のコードに入る前に、アプリケーションのサブ chart に関する重要な点をいくつか説明します。 1. サブ chart は「スタンドアロン」とみなされ、親 chart に明示的に依存することはできません。 2. そのため、サブ chart は親の values にアクセスできません。 3. 親 chart はサブ chart の values を上書きできます。 4. Helm には、すべての chart からアクセスできる _グローバル値_ という概念があります。 > これらの制限は、標準化されたヘルパー機能を提供するために設計された [library chart](/topics/library_charts.md) にはすべて当てはまるわけではありません。 このセクションの例を進めていくうちに、これらの概念がより明確になります。 ## サブ chart の作成 この演習では、ガイドの冒頭で作成した `mychart/` chart を使用し、その中に新しい chart を追加します。 ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` 以前と同様に、ゼロから始めるためベーステンプレートをすべて削除しました。このガイドでは、依存関係の管理ではなく、テンプレートの仕組みに焦点を当てています。サブ chart の詳細については、[Charts ガイド](/topics/charts.md)を参照してください。 ## サブ chart への Values とテンプレートの追加 次に、`mysubchart` chart 用のシンプルなテンプレートと values ファイルを作成します。`mychart/charts/mysubchart` にはすでに `values.yaml` があるはずです。以下のように設定します: ```yaml dessert: cake ``` 次に、`mychart/charts/mysubchart/templates/configmap.yaml` に新しい ConfigMap テンプレートを作成します: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` サブ chart は _スタンドアロン_ であるため、`mysubchart` を単独でテストできます: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## 親 chart からの Values の上書き 元の chart である `mychart` は、`mysubchart` の _親 chart_ になりました。この関係は、`mysubchart` が `mychart/charts` 内にあるという事実のみに基づいています。 `mychart` が親であるため、`mychart` で設定を指定し、その設定を `mysubchart` にプッシュできます。たとえば、`mychart/values.yaml` を以下のように変更できます: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` 最後の 2 行に注目してください。`mysubchart` セクション内のディレクティブはすべて `mysubchart` chart に送信されます。`helm install --generate-name --dry-run --debug mychart` を実行すると、`mysubchart` の ConfigMap が出力に含まれます: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` トップレベルの値がサブ chart の値を上書きしています。 ここで重要な点に注目してください。`mychart/charts/mysubchart/templates/configmap.yaml` のテンプレートを `.Values.mysubchart.dessert` を参照するように変更していません。そのテンプレートの視点からは、値は依然として `.Values.dessert` に配置されています。テンプレートエンジンが values を渡す際にスコープを設定するため、`mysubchart` テンプレートでは `mysubchart` に固有の値のみが `.Values` で利用可能になります。 しかし、特定の値をすべてのテンプレートで利用可能にしたい場合もあります。これはグローバル chart 値で実現できます。 ## グローバル chart 値 グローバル値は、すべての chart またはサブ chart から同じ名前でアクセスできる値です。グローバル値は明示的な宣言が必要です。既存の非グローバル値をグローバルであるかのように使用することはできません。 Values データ型には `Values.global` という予約されたセクションがあり、ここでグローバル値を設定できます。`mychart/values.yaml` ファイルで設定してみましょう。 ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` グローバル値の仕組みにより、`mychart/templates/configmap.yaml` と `mysubchart/templates/configmap.yaml` の両方から `{{ .Values.global.salad }}` としてこの値にアクセスできます。 `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` dry-run インストールを実行すると、両方の出力で同じ値が確認できます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` グローバル値はこのような情報を共有するのに便利ですが、使用するテンプレートを適切に設計する必要があります。 ## サブ chart とのテンプレートの共有 親 chart とサブ chart はテンプレートを共有できます。任意の chart で定義されたブロックは、他の chart から利用可能です。 たとえば、以下のようなシンプルなテンプレートを定義できます: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` テンプレートのラベルは _グローバルに共有される_ ことを思い出してください。したがって、`labels` chart は他の任意の chart からインクルードできます。 chart 開発者は `include` と `template` のどちらかを選択できますが、`include` を使用する利点の 1 つは、テンプレートを動的に参照できることです: ```yaml {{ include $mytemplate }} ``` 上記は `$mytemplate` を参照解決します。一方、`template` 関数は文字列リテラルのみを受け付けます。 ## Blocks の使用を避ける Go テンプレート言語には、開発者がデフォルトの実装を提供し、後でオーバーライドできるようにする `block` キーワードがあります。Helm chart では、同じ block の複数の実装が提供された場合に選択されるものが予測できないため、blocks はオーバーライドに最適なツールではありません。 代わりに `include` の使用を推奨します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Values ファイル description: --values フラグの使い方について解説します。 sidebar_position: 4 --- 前のセクションで、Helm テンプレートが提供する組み込みオブジェクトについて説明しました。組み込みオブジェクトの 1 つに `Values` があります。このオブジェクトは、chart に渡された値へのアクセスを提供します。`Values` の内容は複数のソースから取得されます: - chart 内の `values.yaml` ファイル - サブ chart の場合は、親 chart の `values.yaml` ファイル - `helm install` または `helm upgrade` で `-f` フラグを使用して渡された values ファイル（`helm install -f myvals.yaml ./mychart`） - `--set` で渡された個別のパラメータ（`helm install --set foo=bar ./mychart` など） 上記のリストは具体性の高い順に並んでいます。`values.yaml` がデフォルト値となり、親 chart の `values.yaml` で上書きできます。さらにユーザー指定の values ファイルで上書きでき、最終的に `--set` パラメータで上書きできます。 values ファイルは単純な YAML ファイルです。`mychart/values.yaml` を編集し、続いて ConfigMap テンプレートを編集してみましょう。 `values.yaml` のデフォルト値を削除し、1 つのパラメータだけを設定します: ```yaml favoriteDrink: coffee ``` これをテンプレート内で使用できます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` 最後の行で `favoriteDrink` を `Values` の属性としてアクセスしていることに注目してください: `{{ .Values.favoriteDrink }}`。 レンダリング結果を確認します。 ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` デフォルトの `values.yaml` ファイルで `favoriteDrink` が `coffee` に設定されているため、テンプレートにはその値が表示されています。`helm install` の呼び出しに `--set` フラグを追加することで、簡単に上書きできます: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` `--set` はデフォルトの `values.yaml` ファイルよりも優先順位が高いため、テンプレートは `drink: slurm` を生成します。 values ファイルにはより構造化されたコンテンツを含めることもできます。たとえば、`values.yaml` ファイルに `favorite` セクションを作成し、その中に複数のキーを追加できます: ```yaml favorite: drink: coffee food: pizza ``` テンプレートを少し修正する必要があります: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` このようにデータを構造化することは可能ですが、values ツリーは浅く保ち、フラットな構造を優先することを推奨します。サブ chart への値の割り当てについて説明するときに、ツリー構造を使用した値の命名方法を確認します。 ## デフォルトキーの削除 デフォルト値からキーを削除する必要がある場合は、キーの値を `null` に上書きできます。これにより、Helm はマージされた値からそのキーを削除します。 たとえば、stable Drupal chart ではカスタムイメージを使用する場合に liveness probe を設定できるようになっています。デフォルト値は以下のとおりです: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` を使用して livenessProbe ハンドラを `httpGet` から `exec` に上書きしようとすると、Helm はデフォルト値と上書き値のキーをマージし、以下の YAML が生成されます: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` しかし、Kubernetes では複数の livenessProbe ハンドラを宣言できないため、これは失敗します。この問題を解決するには、`livenessProbe.httpGet` を null に設定して Helm に削除を指示します: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` ここまでで、いくつかの組み込みオブジェクトを確認し、それらを使用してテンプレートに情報を注入する方法を解説しました。次は、テンプレートエンジンのもう 1 つの側面である関数とパイプラインについて説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: 変数 description: テンプレートでの変数の使い方を解説します。 sidebar_position: 8 --- これまでに関数、パイプライン、オブジェクト、制御構造について解説してきました。ここでは、多くのプログラミング言語で基本的な概念である変数について説明します。テンプレートでの使用頻度は高くありませんが、コードを簡潔にしたり、`with` や `range` をより効果的に使ったりするのに役立ちます。 前の例で、以下のコードが失敗することを確認しました: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` は `with` ブロックで制限されたスコープの外にあります。スコープの問題を回避する方法の 1 つは、現在のスコープに関係なくアクセスできる変数にオブジェクトを代入することです。 Helm テンプレートにおける変数は、別のオブジェクトへの名前付き参照です。変数は `$name` という形式で記述します。変数への代入には、特別な代入演算子 `:=` を使用します。上記を変数を使って書き直してみましょう。`Release.Name` を変数に格納できます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` `with` ブロックの開始前に `$relname := .Release.Name` で代入していることに注目してください。これにより、`with` ブロック内でも `$relname` 変数は引き続き release 名を参照できます。 上記を実行すると、以下の出力が得られます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` 変数は `range` ループで特に便利です。リスト型のオブジェクトに対して、インデックスと値の両方を取得できます: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` `range` が最初に来て、次に変数、代入演算子、リストの順になることに注意してください。これにより、整数のインデックス（0 から開始）が `$index` に、値が `$topping` に代入されます。実行結果は次のとおりです: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` キーと値の両方を持つデータ構造に対しても、`range` で両方を取得できます。たとえば、`.Values.favorite` を以下のようにループできます: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 最初のイテレーションでは `$key` が `drink`、`$val` が `coffee` になり、2 回目のイテレーションでは `$key` が `food`、`$val` が `pizza` になります。上記を実行すると、以下の出力が生成されます: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 変数は通常「グローバル」ではありません。宣言されたブロック内でのみ有効です。先ほどの例では、`$relname` をテンプレートのトップレベルで代入しました。この変数はテンプレート全体で有効です。しかし、最後の例の `$key` と `$val` は `{{ range... }}{{ end }}` ブロック内でのみ有効です。 ただし、常にルートコンテキストを参照する変数が 1 つあります: `$` です。これは、range でループしているときに chart の release 名を取得したい場合などに非常に便利です。 以下に使用例を示します: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # 多くの Helm テンプレートでは下記で `.` を使いますが、それでは動作しません。 # しかし、`$` を使えば動作します app.kubernetes.io/name: {{ template "fullname" $ }} # .Chart.Name は参照できませんが、$.Chart.Name は参照できます helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Chart.yaml の appVersion から取得した値 app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` ここまでは、1 つのファイルで宣言された 1 つのテンプレートのみを扱ってきました。しかし、Helm テンプレート言語の強力な機能の 1 つは、複数のテンプレートを宣言し、それらを組み合わせて使用できることです。次のセクションでその方法を説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: 次のステップ description: まとめ - 今後の学習に役立つ参考ドキュメントを紹介します。 sidebar_position: 14 --- このガイドでは、chart 開発者向けに Helm テンプレート言語の使い方を詳しく解説しています。テンプレート開発の技術的な側面に焦点を当てています。 ただし、chart の日常的な開発に関して、このガイドでカバーしていない内容も多くあります。新しい chart を作成する際に参考になるドキュメントを以下に紹介します: - CNCF の [Artifact Hub](https://artifacthub.io/packages/search?kind=0) は、chart を探す上で欠かせない情報源です。 - Kubernetes の[ドキュメント](https://kubernetes.io/docs/home/)では、ConfigMap や Secret から DaemonSet、Deployment まで、さまざまなリソースの種類について詳しい例を確認できます。 - Helm の [Charts ガイド](/topics/charts.md)では、chart を使用するワークフローについて説明しています。 - Helm の [Chart Hooks ガイド](/topics/charts_hooks.md)では、ライフサイクルフックの作成方法について説明しています。 - Helm の [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) の記事では、chart を作成する際に役立つヒントを紹介しています。 - [Sprig ドキュメント](https://github.com/Masterminds/sprig)では、60以上のテンプレート関数について説明しています。 - [Go テンプレートのドキュメント](https://godoc.org/text/template)では、テンプレート構文の詳細が説明されています。 - [Schelm ツール](https://github.com/databus23/schelm)は、chart のデバッグに便利なヘルパーユーティリティです。 経験豊富な開発者に直接質問する方が手っ取り早い場合もあります。そのためには、[Kubernetes Slack](https://kubernetes.slack.com) の Helm チャンネルが最適です: - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) 最後に、このドキュメントに誤りや記載漏れがある場合、新しいコンテンツを提案したい場合、または貢献したい場合は、[The Helm Project](https://github.com/helm/helm-www) をご覧ください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "付録: YAML テクニック" description: YAML 仕様と Helm での活用方法について詳しく解説します。 sidebar_position: 15 --- このガイドでは主にテンプレート言語について説明してきました。ここでは、YAML フォーマットについて見ていきます。YAML には、テンプレート作成者として活用できる便利な機能があり、テンプレートでのエラーを減らし、読みやすくすることができます。 ## スカラーとコレクション [YAML 仕様](https://yaml.org/spec/1.2/spec.html)によると、コレクションには 2 種類あり、スカラー型は多数あります。 コレクションの 2 種類は、マップとシーケンスです: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` スカラー値は（コレクションとは対照的に）個々の値です。 ### YAML のスカラー型 Helm の YAML 方言では、値のスカラーデータ型は、リソース定義の Kubernetes スキーマを含む複雑なルールセットによって決定されます。ただし、型を推論する際には、以下のルールが一般的に当てはまります。 整数または浮動小数点数が引用符なしの単語の場合、通常は数値型として扱われます: ```yaml count: 1 size: 2.34 ``` ただし、引用符で囲むと、文字列として扱われます: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` ブール値も同様です: ```yaml isGood: true # bool answer: "true" # string ``` 空の値を表す単語は `null` です（`nil` ではありません）。 `port: "80"` は有効な YAML であり、テンプレートエンジンと YAML パーサーの両方を通過しますが、Kubernetes が `port` を整数として期待している場合は失敗することに注意してください。 場合によっては、YAML ノードタグを使用して特定の型推論を強制できます: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` 上記では、`!!str` は `age` が整数のように見えても文字列であることをパーサーに伝えます。また、`port` は引用符で囲まれていても整数として扱われます。 ## YAML の文字列 YAML ドキュメントに配置するデータの多くは文字列です。YAML には文字列を表現する方法が複数あります。このセクションでは、その方法を説明し、いくつかの使用方法を示します。 文字列を宣言する「インライン」の方法は 3 つあります: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` すべてのインラインスタイルは 1 行で記述する必要があります。 - ベアワード（引用符なしの語）はエスケープされません。そのため、使用する文字に注意が必要です。 - ダブルクォート文字列では、`\` で特定の文字をエスケープできます。例: `"\"Hello\", she said"`。`\n` で改行をエスケープできます。 - シングルクォート文字列は「リテラル」文字列であり、`\` を使用して文字をエスケープしません。唯一のエスケープシーケンスは `''` で、これは単一の `'` にデコードされます。 1 行の文字列に加えて、複数行の文字列を宣言できます: ```yaml coffee: | Latte Cappuccino Espresso ``` 上記では、`coffee` の値は `Latte\nCappuccino\nEspresso\n` と同等の単一の文字列として扱われます。 `|` の後の最初の行は正しくインデントされている必要があることに注意してください。次のようにすると上記の例は壊れます: ```yaml coffee: | Latte Cappuccino Espresso ``` `Latte` のインデントが正しくないため、次のようなエラーが発生します: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` テンプレートでは、上記のエラーを防ぐために、保護用のダミー行を最初に配置しておくと安全な場合があります: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` 最初の行が何であれ、文字列の出力に保持されることに注意してください。たとえば、この技法を使用してファイルの内容を ConfigMap に挿入する場合、コメントはそのエントリを読み取るものが期待する形式である必要があります。 ### 複数行文字列の空白制御 上記の例では、`|` を使用して複数行文字列を示しました。しかし、文字列の内容の末尾に `\n` が付いていることに注意してください。YAML プロセッサに末尾の改行を削除させたい場合は、`|` の後に `-` を追加できます: ```yaml coffee: |- Latte Cappuccino Espresso ``` これで `coffee` の値は `Latte\nCappuccino\nEspresso` になります（末尾の `\n` なし）。 逆に、すべての末尾の空白を保持したい場合もあります。これは `|+` 記法で実現できます: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` これで `coffee` の値は `Latte\nCappuccino\nEspresso\n\n\n` になります。 テキストブロック内のインデントは保持され、改行も保持されます: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` 上記の場合、`coffee` は `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso` になります。 ### インデントとテンプレート テンプレートを記述するとき、ファイルの内容をテンプレートに挿入したい場合があります。前の章で見たように、これを行う方法は 2 つあります: - `{{ .Files.Get "FILENAME" }}` を使用して chart 内のファイルの内容を取得する。 - `{{ include "TEMPLATE" . }}` を使用してテンプレートをレンダリングし、その内容を chart に配置する。 ファイルを YAML に挿入する場合、上記の複数行ルールを理解することが重要です。多くの場合、静的ファイルを挿入する最も簡単な方法は次のようなものです: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` 上記のインデントの方法に注意してください: `indent 2` はテンプレートエンジンに「myfile.txt」のすべての行を 2 つのスペースでインデントするよう指示します。テンプレート行自体はインデントしないことに注意してください。インデントすると、最初の行のファイル内容が 2 回インデントされてしまいます。 ### 折りたたみ複数行文字列 YAML で文字列を複数行で表現したいが、解釈時には 1 つの長い行として扱いたい場合があります。これは「折りたたみ」と呼ばれます。折りたたみブロックを宣言するには、`|` の代わりに `>` を使用します: ```yaml coffee: > Latte Cappuccino Espresso ``` 上記の `coffee` の値は `Latte Cappuccino Espresso\n` になります。最後の改行を除くすべてがスペースに変換されることに注意してください。空白制御を折りたたみテキストマーカーと組み合わせることができるため、`>-` はすべての改行を置き換えるか削除します。 折りたたみ構文では、テキストをインデントすると行が保持されることに注意してください。 ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` 上記は `Latte\n 12 oz\n 16 oz\nCappuccino Espresso` を生成します。スペースと改行の両方がまだ残っていることに注意してください。 ## 1 つのファイルに複数のドキュメントを埋め込む 1 つのファイルに複数の YAML ドキュメントを配置することができます。これは、新しいドキュメントの前に `---` を付け、ドキュメントの終わりに `...` を付けることで行います。 ```yaml --- document: 1 ... --- document: 2 ... ``` 多くの場合、`---` または `...` のいずれかを省略できます。 Helm の一部のファイルには複数のドキュメントを含めることができません。たとえば、`values.yaml` ファイル内に複数のドキュメントが提供されている場合、最初のドキュメントのみが使用されます。 ただし、テンプレートファイルには複数のドキュメントを含めることができます。この場合、ファイル（およびそのすべてのドキュメント）はテンプレートレンダリング中に 1 つのオブジェクトとして扱われます。ただし、結果の YAML は Kubernetes に渡される前に複数のドキュメントに分割されます。 複数ドキュメントの使用は、本当に必要な場合に限ることを推奨します。ファイルに複数のドキュメントがあると、デバッグが困難になる可能性があります。 ## YAML は JSON のスーパーセット YAML は JSON のスーパーセットであるため、有効な JSON ドキュメントは_有効な_ YAML でもあるはずです。 ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` 上記は、以下を表現する別の方法です: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` そして、2 つを（注意して）混合することもできます: ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` これら 3 つはすべて同じ内部表現にパースされるはずです。 つまり、`values.yaml` などのファイルには JSON データを含めることができますが、Helm はファイル拡張子 `.json` を有効なサフィックスとして扱いません。 ## YAML アンカー YAML 仕様では、値への参照を保存し、後でその値を参照によって参照する方法が提供されています。YAML ではこれを「アンカー」と呼びます: ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` 上記では、`&favoriteCoffee` が `Cappuccino` への参照を設定します。後で、その参照は `*favoriteCoffee` として使用されます。したがって、`coffees` は `Latte, Cappuccino, Espresso` になります。 アンカーが役立つケースはいくつかありますが、気づきにくいバグを引き起こす可能性がある点が 1 つあります: YAML が最初に読み込まれるとき、参照は展開されてから破棄されます。 したがって、上記の例をデコードしてから再エンコードすると、結果の YAML は次のようになります: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Helm と Kubernetes は YAML ファイルを読み取り、変更し、再書き込みすることが多いため、アンカーは失われます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Helm 2 からの変更点 sidebar_position: 1 --- ## Helm 2 からの変更点 Helm 3 で導入された主要な変更点を網羅的に紹介します。 ### Tiller の削除 Helm 2 の開発サイクル中に Tiller を導入しました。Tiller は共有クラスターで作業するチームにとって重要な役割を果たし、複数のオペレーターが同じ release セットを操作できるようにしました。 しかし、Kubernetes 1.6 でロールベースアクセス制御（RBAC）がデフォルトで有効化されたことにより、本番環境で Tiller を安全に運用することが難しくなりました。セキュリティポリシーは多岐にわたるため、Helm チームとしては寛容なデフォルト設定を提供する方針をとりました。これにより、初めてのユーザーはセキュリティ制御を深く学ばなくても Helm と Kubernetes を試すことができました。しかし、この寛容な設定により、ユーザーに意図しない広範な権限が付与される可能性がありました。DevOps エンジニアや SRE は、マルチテナントクラスターに Tiller をインストールする際に追加の運用手順を学ぶ必要がありました。 コミュニティメンバーがさまざまなシナリオでどのように Helm を使用しているかを聞いた結果、Tiller の release 管理システムには、クラスター内オペレーターに状態を維持させたり、Helm release 情報の中央ハブとして機能させたりする必要がないことがわかりました。代わりに、Kubernetes API サーバーから情報を取得し、クライアント側で chart をレンダリングし、インストール記録を Kubernetes に保存するだけで十分です。 Tiller の主な目的は Tiller なしでも達成できるため、Helm 3 に関する最初の決定の 1 つとして、Tiller を完全に削除しました。 Tiller がなくなったことで、Helm のセキュリティモデルは大幅に簡素化されました。Helm 3 は、最新の Kubernetes のセキュリティ、ID、認可機能をすべてサポートしています。Helm の権限は [kubeconfig ファイル](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)を使用して評価されます。クラスター管理者は、必要な粒度でユーザー権限を制限できます。release は引き続きクラスター内に記録され、Helm のその他の機能はそのまま維持されています。 ### アップグレード戦略の改善: 3-way Strategic Merge Patch Helm 2 では、2-way strategic merge patch を使用していました。アップグレード時には、最新の chart のマニフェストと提案された chart のマニフェスト（`helm upgrade` で指定されたもの）を比較し、この 2 つの差分から Kubernetes リソースに適用すべき変更を決定しました。`kubectl edit` などによる手動での変更は考慮されませんでした。そのため、リソースを以前の状態にロールバックできない場合がありました。Helm は最後に適用された chart のマニフェストのみを現在の状態として認識するため、chart の状態に変更がなければ、ライブ状態は変更されませんでした。 Helm 3 では、3-way strategic merge patch を使用しています。パッチを生成する際に、古いマニフェスト、ライブ状態、新しいマニフェストの 3 つを考慮します。 #### 例 この変更が及ぼす影響について、一般的な例をいくつか見ていきます。 ##### ライブ状態が変更された場合のロールバック チームが Helm を使用して Kubernetes の本番環境にアプリケーションをデプロイしたとします。chart には Deployment オブジェクトが含まれており、レプリカ数は 3 に設定されています: ```console $ helm install myapp ./myapp ``` 新しい開発者がチームに加わりました。最初の日に本番クラスターを観察している際、キーボードにコーヒーをこぼしてしまう事故が発生し、`kubectl scale` で本番環境の Deployment のレプリカ数を 3 から 0 に変更してしまいました。 ```console $ kubectl scale --replicas=0 deployment/myapp ``` チームの別の開発者が本番サイトのダウンに気づき、release を以前の状態にロールバックすることにしました: ```console $ helm rollback myapp ``` 何が起こるでしょうか？ Helm 2 では、古いマニフェストと新しいマニフェストを比較してパッチを生成します。これはロールバックなので、同じマニフェストです。Helm は、古いマニフェストと新しいマニフェストに差分がないため、変更の必要がないと判断します。レプリカ数はゼロのまま、問題が発生します。 Helm 3 では、古いマニフェスト、ライブ状態、新しいマニフェストを使用してパッチを生成します。Helm は、古い状態が 3、ライブ状態が 0、新しいマニフェストが 3 に戻したいことを認識し、状態を 3 に戻すパッチを生成します。 ##### ライブ状態が変更された場合のアップグレード 多くのサービスメッシュやコントローラーベースのアプリケーションは、Kubernetes オブジェクトにデータを注入します。サイドカー、ラベル、その他の情報などです。chart からレンダリングされた次のようなマニフェストがあるとします: ```yaml containers: - name: server image: nginx:2.0.0 ``` ライブ状態が別のアプリケーションによって以下のように変更されたとします: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ここで、`nginx` の image タグを `2.1.0` にアップグレードしたいとします。次のマニフェストを持つ chart にアップグレードします: ```yaml containers: - name: server image: nginx:2.1.0 ``` 何が起こるでしょうか？ Helm 2 では、古いマニフェストと新しいマニフェストの間で `containers` オブジェクトのパッチを生成します。パッチ生成時にクラスターのライブ状態は考慮されません。 クラスターのライブ状態は次のように変更されます: ```yaml containers: - name: server image: nginx:2.1.0 ``` サイドカー Pod がライブ状態から削除され、問題が発生します。 Helm 3 では、古いマニフェスト、ライブ状態、新しいマニフェストの間で `containers` オブジェクトのパッチを生成します。新しいマニフェストが image タグを `2.1.0` に変更しようとしていることを認識し、同時にライブ状態にサイドカーコンテナが含まれていることも認識します。 クラスターのライブ状態は次のように変更されます: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### release 名が namespace にスコープ化 Tiller の削除に伴い、各 release の情報を保存する場所が必要でした。Helm 2 では、Tiller と同じ namespace に保存されていました。そのため、一度 release に名前が使用されると、異なる namespace にデプロイされていても、他の release がその名前を使用できませんでした。 Helm 3 では、特定の release に関する情報は release 自体と同じ namespace に保存されます。これにより、ユーザーは 2 つの異なる namespace で `helm install wordpress stable/wordpress` を実行でき、それぞれを現在の namespace コンテキストを変更して `helm list` で参照できます（例: `helm list --namespace foo`）。 この変更により、ネイティブのクラスター namespace との整合性が向上しました。`helm list` コマンドはデフォルトですべての release を一覧表示しなくなり、現在の Kubernetes コンテキストの namespace 内の release のみを一覧表示します（`kubectl config view --minify` を実行したときに表示される namespace）。Helm 2 と同様の動作を得るには、`helm list` に `--all-namespaces` フラグを指定する必要があります。 ### Secret がデフォルトのストレージドライバに Helm 3 では、Secret が[デフォルトのストレージドライバ](/topics/advanced.md#storage-backends)になりました。Helm 2 では、release 情報を保存するためにデフォルトで ConfigMap を使用していました。Helm 2.7.0 で Secret を使用する新しいストレージバックエンドが実装され、Helm 3 からデフォルトになりました。 Helm 3 でデフォルトを Secret に変更することで、Kubernetes の Secret 暗号化機能と組み合わせて chart の追加的なセキュリティ保護が可能になります。 [静止時の Secret 暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)は Kubernetes 1.7 でアルファ機能として利用可能になり、Kubernetes 1.13 で安定版になりました。これにより、ユーザーは Helm release のメタデータを静止時に暗号化でき、将来的に Vault などへの拡張の出発点となります。 ### Go import パスの変更 Helm 3 では、Go import パスが `k8s.io/helm` から `helm.sh/helm/v3` に変更されました。Helm 3 の Go クライアントライブラリにアップグレードする場合は、import パスを変更してください。 ### Capabilities レンダリング段階で利用できる `.Capabilities` ビルトインオブジェクトが簡素化されました。 [ビルトインオブジェクト](/chart_template_guide/builtin_objects.md) ### JSONSchema による chart 値の検証 chart 値に JSON Schema を適用できるようになりました。これにより、ユーザーが提供する値が chart メンテナーの定義したスキーマに従っていることが保証され、不正な値を指定した場合にはより良いエラーレポートが提供されます。 検証は以下のコマンドの実行時に行われます: * `helm install` * `helm upgrade` * `helm template` * `helm lint` 詳細は [Schema ファイル](/topics/charts.md#schema-files)のドキュメントを参照してください。 ### `requirements.yaml` の `Chart.yaml` への統合 chart の依存関係管理システムが requirements.yaml と requirements.lock から Chart.yaml と Chart.lock に移行しました。Helm 3 向けの新しい chart は新しいフォーマットを使用することを推奨します。ただし、Helm 3 は Chart API バージョン 1（`v1`）も引き続き理解し、既存の `requirements.yaml` ファイルを読み込むことができます。 Helm 2 での `requirements.yaml` は次のようになっていました: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Helm 3 では、依存関係は同じように表現されますが、`Chart.yaml` に記述します: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` chart は引き続き `charts/` ディレクトリにダウンロードされるため、`charts/` ディレクトリにベンダリングされたサブチャートは変更なしで動作します。 ### インストール時に名前（または --generate-name）が必須に Helm 2 では、名前が指定されない場合、自動生成された名前が付けられました。本番環境では、これは便利な機能というよりも厄介な問題となることがわかりました。Helm 3 では、`helm install` で名前が指定されない場合、エラーが発生します。 名前を自動生成したい場合は、`--generate-name` フラグを使用してください。 ### OCI レジストリへの chart プッシュ これは Helm 3 で導入された実験的機能です。使用するには、環境変数 `HELM_EXPERIMENTAL_OCI=1` を設定してください。 大まかに言うと、Chart リポジトリは chart を保存および共有できる場所です。Helm クライアントは Helm chart をパッケージ化して Chart リポジトリに送信します。簡単に言えば、Chart リポジトリは index.yaml ファイルといくつかのパッケージ化された chart を格納する基本的な HTTP サーバーです。 Chart リポジトリ API は最も基本的なストレージ要件を満たしていますが、いくつかの欠点が明らかになってきました: - Chart リポジトリでは、本番環境で必要なセキュリティ実装を抽象化することが困難です。本番シナリオでは、認証と認可のための標準 API が非常に重要です。 - chart の署名と整合性・出所の検証に使用される Helm の chart 来歴ツールは、chart 公開プロセスのオプション部分です。 - マルチテナントシナリオでは、同じ chart が別のテナントによってアップロードされる可能性があり、同じコンテンツを保存するのに 2 倍のストレージコストがかかります。よりスマートな chart リポジトリはこれに対処するように設計されていますが、正式な仕様の一部ではありません。 - 検索、メタデータ情報、chart の取得に単一のインデックスファイルを使用することで、安全なマルチテナント実装の設計が困難になっています。 Docker の Distribution プロジェクト（Docker Registry v2 とも呼ばれる）は、Docker Registry プロジェクトの後継です。多くの主要クラウドベンダーが Distribution プロジェクトの製品を提供しており、長年にわたる堅牢化、セキュリティベストプラクティス、実戦での検証の恩恵を受けてきました。 chart をパッケージ化して Docker レジストリにプッシュする方法の詳細については、`helm help chart` と `helm help registry` を参照してください。 詳細は[このページ](/topics/registries.md)を参照してください。 ### `helm serve` の削除 `helm serve` は、開発目的でローカルマシン上で Chart リポジトリを実行するコマンドでした。しかし、開発ツールとしてあまり普及せず、設計上の問題が多数ありました。最終的に、これを削除してプラグインとして分離することにしました。 `helm serve` と同様の体験を得るには、[ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) のローカルファイルシステムストレージオプションと [servecm プラグイン](https://github.com/jdolitsky/helm-servecm)を参照してください。 ### ライブラリ chart のサポート Helm 3 は「ライブラリ chart」と呼ばれる chart のクラスをサポートしています。ライブラリ chart は他の chart で共有されますが、独自の release アーティファクトを作成しません。ライブラリ chart のテンプレートは `define` 要素のみを宣言できます。グローバルスコープの `define` 以外のコンテンツは無視されます。これにより、多くの chart で再利用できるコードスニペットを共有でき、冗長性を回避して chart を [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)（Don't Repeat Yourself）に保つことができます。 ライブラリ chart は Chart.yaml の dependencies ディレクティブで宣言され、他の chart と同様にインストールおよび管理されます。 ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` この機能が chart 開発者にどのようなユースケースを開くか、またライブラリ chart を使用する際のベストプラクティスがどのように生まれるかを楽しみにしています。 ### Chart.yaml の apiVersion の変更 ライブラリ chart のサポートの導入と requirements.yaml の Chart.yaml への統合により、Helm 2 のパッケージフォーマットを理解するクライアントはこれらの新機能を理解できません。そのため、Chart.yaml の apiVersion を `v1` から `v2` に引き上げました。 `helm create` は新しいフォーマットを使用して chart を作成するようになったため、デフォルトの apiVersion もそちらに変更されました。 両方のバージョンの Helm chart をサポートしたいクライアントは、Chart.yaml の `apiVersion` フィールドを調べてパッケージフォーマットの解析方法を決定する必要があります。 ### XDG Base Directory のサポート [XDG Base Directory 仕様](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)は、設定、データ、キャッシュファイルをファイルシステムのどこに保存すべきかを定義するポータブルな標準です。 Helm 2 では、すべての情報を `~/.helm`（俗称「helm home」）に保存していました。これは `$HELM_HOME` 環境変数または `--home` グローバルフラグで変更できました。 Helm 3 では、XDG Base Directory 仕様に従って以下の環境変数を使用します: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Helm プラグインには、`$HELM_HOME` をスクラッチパッド環境として使用するプラグインとの後方互換性のために、`$HELM_HOME` が `$XDG_DATA_HOME` のエイリアスとして引き続き渡されます。 この変更に対応するために、プラグイン環境にいくつかの新しい環境変数も渡されるようになりました: - `$HELM_PATH_CACHE`: キャッシュパス - `$HELM_PATH_CONFIG`: 設定パス - `$HELM_PATH_DATA`: データパス Helm 3 をサポートする Helm プラグインは、これらの新しい環境変数の使用を検討してください。 ### CLI コマンドの名前変更 他のパッケージマネージャーとの用語の整合性を高めるため、`helm delete` は `helm uninstall` に名前変更されました。`helm delete` は `helm uninstall` のエイリアスとして引き続き保持されているため、どちらの形式でも使用できます。 Helm 2 では、release の台帳を削除するために `--purge` フラグを指定する必要がありました。この機能は現在デフォルトで有効になっています。以前の動作を維持するには、`helm uninstall --keep-history` を使用してください。 また、同じ規則に合わせるためにいくつかの他のコマンドも名前変更されました: - `helm inspect` → `helm show` - `helm fetch` → `helm pull` これらのコマンドも以前の動詞がエイリアスとして保持されているため、どちらの形式でも引き続き使用できます。 ### namespace の自動作成 存在しない namespace に release を作成する場合、Helm 2 は namespace を作成しました。Helm 3 は他の Kubernetes ツールの動作に従い、namespace が存在しない場合はエラーを返します。Helm 3 で namespace を作成するには、明示的に `--create-namespace` フラグを指定してください。 ### .Chart.ApiVersion はどうなったか？ Helm は、頭字語を大文字にするという CamelCase の一般的な規則に従っています。これは `.Capabilities.APIVersions.Has` など、コードの他の場所でも行っています。Helm v3 では、このパターンに従うように `.Chart.ApiVersion` を修正し、`.Chart.APIVersion` に名前変更しました。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: よくある質問 sidebar_position: 8 --- # よくある質問 > Helm 2 と Helm 3 の主な違いはなんですか？ > このページでは、最もよくある質問に答えることで、理解の助けとなる事柄を説明します。 このドキュメントを改善する**あなたの助けを歓迎します**。情報の追加、訂正、削除などを行うには、[issue を作る](https://github.com/helm/helm-www/issues)か、pull request を送ってください。 ## Helm 2 からの変更点 以下に、Helm 3 で導入されたすべての主要な変更の包括的なリストを示します。 ### Tiller の削除 Helm 2 の開発サイクルの中で、私たちは Tiller を導入しました。Tiller は共有クラスターで作業をするチームに対して重要な役割を果たしました。Tillerのおかげで複数の異なるオペレータが同じリリースセットとやり取りできるようになったのです。 ロールベースアクセス制御 (RBAC) が Kubernetes 1.6 でデフォルトで有効になると、Tiller を本番環境で使用し続けるのはしだいに管理が難しくなっていきました。セキュリティポリシーには非常に多くの可能性があるため、私たちはデフォルトでパーミッシブな設定にする立場を取りました。このおかげで、初めてのユーザーはセキュリティ制御に頭を悩ませずに Helm と Kubernetes を試せるようになりました。残念ながらこのパーミッシブな設定は、本来は持つべきではないユーザーに広範な権限を与えてしまう可能性があります。DevOps や SRE がマルチテナントのクラスターに Tiller をインストールするときには、追加のオペレーションのステップを学ばなければなりませんでした。 コミュニティメンバーの特定のシナリオ下での Helm の使い方について調査をした結果、Tiller のリリース管理システムがステートを保持して Helm のリリース情報のセントラルハブとして動作するためには、クラスタ内のオペレータに依存する必要はなかったことがわかりました。 Tiller の主目的は Tiller がなくても実現できたことがわかったため、Helm 3 に関して私たちが下した最初の決定は Tiller を完全に取り除くことでした。 Tiller を取り除くと、Helm セキュリティモデルは著しく単純化されました。このおかげで Helm 3 は、最近の Kubernetes が持つモダンなセキュリティ、ID、認証の機能のすべてをサポートできるようになりました。Helm の権限は [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) を使用して評価されます。クラスタ管理者は要求に合った任意の粒度でユーザー権限を制限できます。リリースは今でもクラスター内に保存され、Helm の他の機能もそのまま変わりません。 ### アップグレード戦略の改善: 3方向戦略的マージパッチ (3-way Strategic Merge Patches) Helm 2 では、2方向戦略的マージパッチが使用されていました。アップグレード時には、最新のチャートのマニフェストと (`helm upgrade` 中に) 与えられたチャートのマニフェストを比較します。Helm 2 はこの2つのチャート間で変更を比較して、Kubernetes 内のリソースに適用する必要がある変更を決定します。もしクラスターへの変更がチャート外で (たとえば `kubectl edit` などで) 適用されていた場合、この変更は考慮されません。その結果、リソースは過去の状態にロールバックできなくなります。Helm は最後に適用されたチャートのマニフェストだけを最新状態とみなすため、チャートの状態に変更がなければ、現在の状態は変更されていないと判断されるためです。 Helm 3 では、新しく3方向戦略的マージパッチが使われるようになります。パッチの生成をするときに、Helm は古いマニフェスト、その現在の状態、新しいマニフェストを考慮します。 #### 例 Let's go through a few common examples what this change impacts. ##### 実際の状態が変更した時点へのロールバック Your team just deployed their application to production on Kubernetes using Helm. The chart contains a Deployment object where the number of replicas is set to three: ```console $ helm install myapp ./myapp ``` A new developer joins the team. On their first day while observing the production cluster, a horrible coffee-spilling-on-the-keyboard accident happens and they `kubectl scale` the production deployment from three replicas down to zero. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Another developer on your team notices that the production site is down and decides to rollback the release to its previous state: ```console $ helm rollback myapp ``` What happens? In Helm 2, it would generate a patch, comparing the old manifest against the new manifest. Because this is a rollback, it's the same manifest. Helm would determine that there is nothing to change because there is no difference between the old manifest and the new manifest. The replica count continues to stay at zero. Panic ensues. In Helm 3, the patch is generated using the old manifest, the live state, and the new manifest. Helm recognizes that the old state was at three, the live state is at zero and the new manifest wishes to change it back to three, so it generates a patch to change the state back to three. ##### 実際の状態が変更した時点へのアップグレード Many service meshes and other controller-based applications inject data into Kubernetes objects. This can be something like a sidecar, labels, or other information. Previously if you had the given manifest rendered from a Chart: ```yaml containers: - name: server image: nginx:2.0.0 ``` And the live state was modified by another application to ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Now, you want to upgrade the `nginx` image tag to `2.1.0`. So, you upgrade to a chart with the given manifest: ```yaml containers: - name: server image: nginx:2.1.0 ``` What happens? In Helm 2, Helm generates a patch of the `containers` object between the old manifest and the new manifest. The cluster's live state is not considered during the patch generation. The cluster's live state is modified to look like the following: ```yaml containers: - name: server image: nginx:2.1.0 ``` The sidecar pod is removed from live state. More panic ensues. In Helm 3, Helm generates a patch of the `containers` object between the old manifest, the live state, and the new manifest. It notices that the new manifest changes the image tag to `2.1.0`, but live state contains a sidecar container. The cluster's live state is modified to look like the following: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### リリース名が名前空間でスコープされるようになった Tiller の削除に伴い、各リリースの情報はどこか別の場所に移動する必要が出てきました。Helm 2 では、リリースの情報は Tiller と同じ名前空間に保存されていました。実際には、一度でもリリースで名前が使われてしまうと、たとえ他の名前空間にデプロイしたとしても、他のリリースが同じ名前を使えないということです。 Helm 3 では、特定のリリースの情報は新しくリリース自体と同じ名前空間に保存されるようになりました。つまり、これからはユーザーが `helm install wrodpress stable/wordpress` というコマンドを2つの別の名前空間で実行できるようになったということです。それぞれのリリースは、現在の名前空間のコンテキストを切り替えることで (例: `helm list --namespace foo`)、`helm list` を使用して参照できます。 ネイティブのクラスターの名前空間に大きく近づけたことにより、`helm list` コマンドはデフォルトではすべてのリリースを一覧しなくなりました。代わりに、現在の Kubernetes のコンテキストの名前空間 (たとえば、`kubectl config view --minify` などを実行すると表示される名前空間) の中にあるリリースだけが表示されるようになります。Helm 2 に近い動作にするには、`helm list` に `--all-namespaces` フラッグを与える必要があります。 ### Secret がデフォルトのストレージドライバーになった Helm 3 からは、Secret が[デフォルトのストレージドライバー](/topics/advanced.md#storage-backends)として使われるようになりました。Helm 2 では、ConfigMap がデフォルトでリリース情報を保存するために使用されていました。Helm 2.7.0 でリリース情報を保存するために Secret を使用する新しいストレージバックエンドが実装され、Helm 3 からはデフォルトで使用されるようになりました。 Helm 3 で Secret がデフォルトに変更されたことで、Kubernetes のリリースの Secret の暗号化と組み合わせて、チャートを保護する際のセキュリティが強化できます。 Kubernetesでのシークレット暗号化のリリースに関連してチャートを保護する際のセキュリティが強化されます。 [Secret の保存時の暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)は Kubernetes 1.7 でアルファ版の機能として利用可能になり、Kubernetes 1.13 で安定版になりました。これを利用することで、ユーザーは Helm のリリースのメタデータを保存時に暗号化できるようになるため、あとで Vault などを利用する場合によい出発地点となります。 ### Go の import path の変更 Helm 3 では、Helm は Go のインポートパスを `k8s.io/helm` から `helm.sh/helm/v3` に変更しました。Helm 3 の Go クライアントライブラリをアップグレードする場合には、手元のインポートパスも変更するようにしてください。 ### Capabilities レンダリングステージで利用可能な `.Capabilities` 組み込みオブジェクトが簡略されました。 [ビルトインオブジェクト](/chart_template_guide/builtin_objects.md) ### チャートの Values の JSONSchema による検証 チャートの値に JSON Schema で制約を与えられるようになりました。これにより、ユーザーから与えられた値がチャートのメンテナが作ったスキーマに従っていることが保証されるため、ユーザーが間違った値をチャートに与えた場合によりよいエラー報告を行えるようになります。 検証は次のいずれかのコマンドが呼ばれたときに行われます。 * `helm install` * `helm upgrade` * `helm template` * `helm lint` 詳しい情報は、ドキュメントの [Schema files](/topics/charts.md#schema-files) をご覧ください。 ### `requirements.yaml` の `Chart.yaml` への統合 チャートの依存関係の管理システムは、requirements.yaml と requirements.lock から、Chart.yaml と Chart.lock に変更されました。私たちは、Helm 3 向けの新しいチャートは新しいフォーマットを使用することを推奨します。しかし、Helm 3 は現在でも Chart API バージョン 1 (`v1`) も理解できるため、既存の `requirements.yaml` ファイルを読み込みます。 Helm 2 の `requirements.yaml` は以下のような形式でした。 ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Helm 3 でも依存関係は同じように表現されますが、`Chart.yaml` 以下に移動されます。 ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` 現在でもチャートは `charts/` ディレクトリに配置されるため、`charts/` ディレクトリに追加されたサブチャートは修正なしで動作し続けます。 ### Name (または --generate-name) がインストール時に必須となった Helm 2 では、名前が与えられなかった場合に、自動生成された名前が設定されるようになっていました。本番環境では、この機能は役に立つ場合よりも迷惑になる場合のほうが多いことがわかりました。そのため、Helm 3 では、`helm install` に名前が与えられなかった場合には Helm がエラーを返します。 まだ名前の自動生成が必要なユーザーは、`--generate-name` フラグを使用すると名前を自動生成できます。 ### チャートを OCI レジストリに push する これは Helm 3 で導入された実験的な機能です。使用するには、環境変数 `HELM_EXPERIMENTAL_OCI=1` を設定してください。 At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index.yaml file and some packaged charts. While there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show: - Chart Repositories have a very hard time abstracting most of the security implementations required in a production environment. Having a standard API for authentication and authorization is very important in production scenarios. - Helm’s Chart provenance tools used for signing and verifying the integrity and origin of a chart are an optional piece of the Chart publishing process. - In multi-tenant scenarios, the same Chart can be uploaded by another tenant, costing twice the storage cost to store the same content. Smarter chart repositories have been designed to handle this, but it’s not a part of the formal specification. - Using a single index file for search, metadata information, and fetching Charts has made it difficult or clunky to design around in secure multi-tenant implementations. Docker’s Distribution project (also known as Docker Registry v2) is the successor to the Docker Registry project. Many major cloud vendors have a product offering of the Distribution project, and with so many vendors offering the same product, the Distribution project has benefited from many years of hardening, security best practices, and battle-testing. Please have a look at `helm help chart` and `helm help registry` for more information on how to package a chart and push it to a Docker registry. For more info, please see [this page](/topics/registries.md). ### `helm serve` の廃止 `helm serve` ran a local Chart Repository on your machine for development purposes. However, it didn't receive much uptake as a development tool and had numerous issues with its design. In the end, we decided to remove it and split it out as a plugin. For a similar experience to `helm serve`, have a look at the local filesystem storage option in [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) and the [servecm plugin](https://github.com/jdolitsky/helm-servecm). ### ライブラリチャートのサポート Helm 3 supports a class of chart called a “library chart”. This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart’s templates can only declare `define` elements. Globally scoped non-`define` content is simply ignored. This allows users to re-use and share snippets of code that can be re-used across many charts, avoiding redundancy and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Library charts are declared in the dependencies directive in Chart.yaml, and are installed and managed like any other chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` We’re very excited to see the use cases this feature opens up for chart developers, as well as any best practices that arise from consuming library charts. ### Chart.yaml apiVersion のバージョンアップ With the introduction of library chart support and the consolidation of requirements.yaml into Chart.yaml, clients that understood Helm 2's package format won't understand these new features. So, we bumped the apiVersion in Chart.yaml from `v1` to `v2`. `helm create` now creates charts using this new format, so the default apiVersion was bumped there as well. Clients wishing to support both versions of Helm charts should inspect the `apiVersion` field in Chart.yaml to understand how to parse the package format. ### XDG のベースディレクトリのサポート [XDG ベースディレクトリの仕様](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)は、ファイルシステム上の設定、データ、キャッシュの各ファイルの格納場所を定めたポータブルな標準です。 In Helm 2, Helm stored all this information in `~/.helm` (affectionately known as `helm home`), which could be changed by setting the `$HELM_HOME` environment variable, or by using the global flag `--home`. In Helm 3, Helm now respects the following environment variables as per the XDG Base Directory Specification: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Helm plugins are still passed `$HELM_HOME` as an alias to `$XDG_DATA_HOME` for backwards compatibility with plugins looking to use `$HELM_HOME` as a scratchpad environment. Several new environment variables are also passed in to the plugin's environment to accommodate this change: - `$HELM_PATH_CACHE` for the cache path - `$HELM_PATH_CONFIG` for the config path - `$HELM_PATH_DATA` for the data path Helm plugins looking to support Helm 3 should consider using these new environment variables instead. ### CLI コマンドの名前変更 In order to better align the verbiage from other package managers, `helm delete` was re-named to `helm uninstall`. `helm delete` is still retained as an alias to `helm uninstall`, so either form can be used. In Helm 2, in order to purge the release ledger, the `--purge` flag had to be provided. This functionality is now enabled by default. To retain the previous behavior, use `helm uninstall --keep-history`. Additionally, several other commands were re-named to accommodate the same conventions: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` These commands have also retained their older verbs as aliases, so you can continue to use them in either form. ### 名前空間の自動生成 When creating a release in a namespace that does not exist, Helm 2 created the namespace. Helm 3 follows the behavior of other Kubernetes tooling and returns an error if the namespace does not exist. Helm 3 will create the namespace if you explicitly specify `--create-namespace` flag. ### .Chart.ApiVersion に何が起こりましたか？ Helm follows the typical convention for CamelCasing which is to capitalize an acronym. We have done this elsewhere in the code, such as with `.Capabilities.APIVersions.Has`. In Helm v3, we corrected `.Chart.ApiVersion` to follow this pattern, renaming it to `.Chart.APIVersion`. ## インストール ### Fedora などの Linux ディストリビューション向けの Helm のネイティブパッケージが存在しないのはなぜですか？ The Helm project does not maintain packages for operating systems and environments. The Helm community may provide native packages and if the Helm project is made aware of them they will be listed. This is how the Homebrew formula was started and listed. If you're interested in maintaining a package, we'd love it. ### なぜ `curl ...|bash` で実行するスクリプトを提供しているのですか？ There is a script in our repository (`scripts/get-helm-3`) that can be executed as a `curl ..|bash` script. The transfers are all protected by HTTPS, and the script does some auditing of the packages it fetches. However, the script has all the usual dangers of any shell script. We provide it because it is useful, but we suggest that users carefully read the script first. What we'd really like, though, are better packaged releases of Helm. ### Helm クライアントのファイルをデフォルト以外の場所に配置するにはどうすればいいですか？ Helm uses the XDG structure for storing files. There are environment variables you can use to override these locations: - `$XDG_CACHE_HOME`: set an alternative location for storing cached files. - `$XDG_CONFIG_HOME`: set an alternative location for storing Helm configuration. - `$XDG_DATA_HOME`: set an alternative location for storing Helm data. Note that if you have existing repositories, you will need to re-add them with `helm repo add...`. ## アンインストール ### ローカルの Helm を削除したいです。Helm の全ファイルはどこにありますか？ Along with the `helm` binary, Helm stores some files in the following locations: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME The following table gives the default folder for each of these, by OS: | Operating System | Cache Path | Configuration Path | Data Path | |------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ## トラブルシューティング ### GKE (Google Container Engine) 上で "No SSH tunnels currently open" というメッセージが表示されました ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` エラーメッセージの変種には次のようなものもあります。 ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` The issue is that your local Kubernetes config file must have the correct credentials. When you create a cluster on GKE, it will give you credentials, including SSL certificates and certificate authorities. These need to be stored in a Kubernetes config file (Default: `~/.kube/config` so that `kubectl` and `helm` can access them. ### Helm 2 からのマイグレーション後、`helm list` リリースの一部 (または全部) が表示されません It is likely that you have missed the fact that Helm 3 now uses cluster namespaces throughout to scope releases. This means that for all commands referencing a release you must either: * rely on the current namespace in the active kubernetes context (as described by the `kubectl config view --minify` command), * specify the correct namespace using the `--namespace`/`-n` flag, or * for the `helm list` command, specify the `--all-namespaces`/`-A` flag This applies to `helm ls`, `helm uninstall`, and all other `helm` commands referencing a release. ### macOS 上で `/etc/.mdns_debug` というファイルへのアクセスがあります。なぜですか？ We are aware of a case on macOS where Helm will try to access a file named `/etc/.mdns_debug`. If the file exists, Helm holds the file handle open while it executes. This is caused by macOS's MDNS library. It attempts to load that file to read debugging settings (if enabled). The file handle probably should not be held open, and this issue has been reported to Apple. However, it is macOS, not Helm, that causes this behavior. If you do not want Helm to load this file, you may be able to compile Helm to as a static library that does not use the host network stack. Doing so will inflate the binary size of Helm, but will prevent the file from being open. This issue was originally flagged as a potential security problem. But it has since been determined that there is no flaw or vulnerability caused by this behavior. ### 以前は動作していた helm repo add が失敗する In helm 3.3.1 and before, the command `helm repo add ` will give no output if you attempt to add a repo which already exists. The flag `--no-update` would raise an error if the repo was already registered. In helm 3.3.2 and beyond, an attempt to add an existing repo will error: `Error: repository name (reponame) already exists, please specify a different name` The default behavior is now reversed. `--no-update` is now ignored, while if you want to replace (overwrite) an existing repo, you can use `--force-update`. This is due to a breaking change for a security fix as explained in the [Helm 3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2). import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: インストール sidebar_position: 2 --- ## インストール ### Fedora やその他の Linux ディストリビューション向けのネイティブパッケージがないのはなぜですか？ Helm プロジェクトは、各オペレーティングシステムや環境向けのパッケージを保守していません。Helm コミュニティがネイティブパッケージを提供する場合があり、Helm プロジェクトがそれらを認識した場合はリストに掲載されます。Homebrew formula もこの方法で始まり、リストに掲載されました。パッケージの保守に興味がある方は歓迎します。 ### `curl ...|bash` スクリプトを提供しているのはなぜですか？ リポジトリには `curl ..|bash` スクリプトとして実行できるスクリプト（`scripts/get-helm-3`）があります。すべての転送は HTTPS で保護されており、スクリプトは取得するパッケージに対していくつかの監査を行います。ただし、このスクリプトには他のシェルスクリプトと同様の危険性があります。 このスクリプトは便利なため提供していますが、まずスクリプトの内容を注意深く確認することをお勧めします。本当に望まれているのは、より充実したパッケージ版の Helm リリースです。 ### Helm クライアントのファイルをデフォルト以外の場所に配置するにはどうすればよいですか？ Helm はファイルの保存に XDG 構造を使用しています。以下の環境変数でこれらの場所を上書きできます: - `$XDG_CACHE_HOME`: キャッシュファイルの保存場所を変更します。 - `$XDG_CONFIG_HOME`: Helm 設定の保存場所を変更します。 - `$XDG_DATA_HOME`: Helm データの保存場所を変更します。 既存のリポジトリがある場合は、`helm repo add...` で再度追加する必要があります。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: トラブルシューティング sidebar_position: 4 --- ## トラブルシューティング ### 「"stable" chart リポジトリから更新を取得できません」という警告が表示される場合 `helm repo list` を実行してください。`stable` リポジトリが `storage.googleapis.com` の URL を指している場合、そのリポジトリを更新する必要があります。2020 年 11 月 13 日に、Helm Charts リポジトリは 1 年間の非推奨期間を経て[サポートを終了](https://github.com/helm/charts#deprecation-timeline)しました。アーカイブは `https://charts.helm.sh/stable` で利用可能ですが、今後の更新は行われません。 以下のコマンドを実行してリポジトリを修正してください: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator` リポジトリについても同様で、アーカイブは https://charts.helm.sh/incubator で利用可能です。以下のコマンドを実行して修正してください: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 「WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.」という警告が表示される場合 旧 Google Helm chart リポジトリは、新しい Helm chart リポジトリに置き換えられました。 以下のコマンドを実行して、この問題を恒久的に解決してください: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator` についても同様のエラーが発生する場合は、以下のコマンドを実行してください: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Helm リポジトリを追加しようとすると「Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available」というエラーが発生する場合 Helm Chart リポジトリは [1 年間の非推奨期間](https://github.com/helm/charts#deprecation-timeline)を経て、サポートを終了しました。これらのリポジトリのアーカイブは `https://charts.helm.sh/stable` および `https://charts.helm.sh/incubator` で利用可能ですが、今後の更新は行われません。`helm repo add` コマンドは、`--use-deprecated-repos` を指定しない限り、旧 URL の追加を許可しません。 ### GKE (Google Container Engine) で「No SSH tunnels currently open」というエラーが発生する場合 ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` このエラーメッセージの別のバリエーションとして、以下のようなものもあります: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` この問題は、ローカルの Kubernetes 設定ファイルに正しい認証情報が含まれていないことが原因です。 GKE でクラスターを作成すると、SSL 証明書や認証局などの認証情報が提供されます。これらの認証情報を Kubernetes 設定ファイル（デフォルト: `~/.kube/config`）に保存して、`kubectl` と `helm` がアクセスできるようにする必要があります。 ### Helm 2 から移行後、`helm list` で一部のリリースしか表示されない（または全く表示されない）場合 Helm 3 では、release のスコープにクラスターの namespace を使用するようになったことを見落としている可能性があります。つまり、release を参照するすべてのコマンドで以下のいずれかを行う必要があります: * アクティブな Kubernetes コンテキストの現在の namespace に依存する（`kubectl config view --minify` コマンドで確認できます） * `--namespace`/`-n` フラグを使用して正しい namespace を指定する * `helm list` コマンドの場合は、`--all-namespaces`/`-A` フラグを指定する これは `helm ls`、`helm uninstall`、およびその他の release を参照するすべての `helm` コマンドに適用されます。 ### macOS で Helm が `/etc/.mdns_debug` ファイルにアクセスするのはなぜですか？ macOS において、Helm が `/etc/.mdns_debug` という名前のファイルにアクセスしようとするケースがあることを認識しています。このファイルが存在する場合、Helm は実行中にファイルハンドルを開いたままにします。 これは macOS の MDNS ライブラリが原因です。このライブラリは、デバッグ設定を読み込むために（有効な場合）このファイルの読み込みを試みます。ファイルハンドルを開いたままにすべきではありませんが、この問題は Apple に報告されています。ただし、この動作を引き起こしているのは Helm ではなく macOS です。 Helm にこのファイルを読み込ませたくない場合は、ホストのネットワークスタックを使用しない静的ライブラリとして Helm をコンパイルできます。これにより Helm のバイナリサイズは増加しますが、ファイルが開かれることを防ぐことができます。 この問題は当初、潜在的なセキュリティ問題として報告されました。しかし、その後の調査で、この動作による欠陥や脆弱性は存在しないことが判明しています。 ### 以前は動作していた `helm repo add` が失敗する場合 Helm 3.3.1 以前では、`helm repo add ` コマンドは、既に存在するリポジトリを追加しようとしても何も出力しませんでした。`--no-update` フラグは、リポジトリが既に登録されている場合にエラーを発生させていました。 Helm 3.3.2 以降では、既存のリポジトリを追加しようとするとエラーが発生します: `Error: repository name (reponame) already exists, please specify a different name` デフォルトの動作が逆転しました。`--no-update` は無視されるようになり、既存のリポジトリを置き換える（上書きする）場合は、`--force-update` を使用します。 これはセキュリティ修正に伴う破壊的変更です。詳細は [Helm 3.3.2 リリースノート](https://github.com/helm/helm/releases/tag/v3.3.2)で説明されています。 ### Kubernetes クライアントログの有効化 Kubernetes クライアントのデバッグ用ログメッセージを表示するには、[klog](https://pkg.go.dev/k8s.io/klog) フラグを使用します。`-v` フラグで詳細レベルを設定するだけで、ほとんどの場合は十分です。 例: ``` helm list -v 6 ``` ### Tiller のインストールが動作しなくなり、アクセスが拒否される場合 Helm のリリースは以前 から提供されていました。["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/) で説明されているとおり、2019 年 6 月に公式の提供場所が変更されました。[GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) では、すべての旧 Tiller イメージが利用可能です。 以前使用していたストレージバケットから旧バージョンの Helm をダウンロードしようとすると、以下のようなエラーが表示される場合があります: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [旧 Tiller イメージの場所](https://gcr.io/kubernetes-helm/tiller)は、2021 年 8 月にイメージの削除を開始しました。これらのイメージは [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) で利用可能です。例えば、バージョン v2.17.0 をダウンロードするには、以下を: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` 以下に置き換えます: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Helm v2.17.0 で初期化するには: `helm init —upgrade` または、異なるバージョンが必要な場合は、--tiller-image フラグを使用してデフォルトの場所を上書きし、特定の Helm v2 バージョンをインストールします: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **注:** Helm メンテナーは、現在サポートされている Helm のバージョンへの移行を推奨しています。Helm v2.17.0 は Helm v2 の最終リリースであり、Helm v2 は [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/) で詳述されているとおり、2020 年 11 月以降サポートされていません。それ以降多くの CVE が Helm に対して報告されており、これらの脆弱性は Helm v3 で修正されていますが、Helm v2 では修正されません。[公開されている Helm のセキュリティアドバイザリ一覧](https://github.com/helm/helm/security/advisories?state=published)を確認し、今すぐ [Helm v3 への移行](/topics/v2_v3_migration.md)を計画してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: アンインストール sidebar_position: 3 --- ## アンインストール ### Helm をローカルから削除したい場合、関連ファイルはどこにありますか？ `helm` バイナリ本体のほか、Helm は以下の場所にもファイルを保存しています: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME 上記の各環境変数に対応するデフォルトフォルダは、OS ごとに以下のとおりです: | オペレーティングシステム | キャッシュパス | 設定パス | データパス | |--------------------------|--------------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: 用語集 description: Helm のアーキテクチャのコンポーネントを説明するために使用される用語。 sidebar_position: 9 --- # 用語集 ## チャート Kubernetes リソースのセットを Kubernetes クラスターにインストールするのに 十分な情報が含まれている Helm パッケージ。 チャートには、`Chart.yaml` ファイル、テンプレート、デフォルト値 (`values.yaml`)、 依存関係が含まれています。 チャートは明確に定義されたディレクトリ構造で開発され、 _Chart アーカイブ_ と呼ばれるアーカイブ形式にパッケージ化されます。 ## Chart アーカイブ _Chart アーカイブ_ は、tar 形式で gzip 圧縮された (オプションで署名された) チャートです。 ## チャートの依存関係 (サブチャート) チャートは他のチャートに依存する場合があります。依存関係が発生する方法は2つあります。 - ソフトな依存関係: 別のチャートがクラスターにインストールされていないと、チャートが機能しない可能性があります。 Helm はこの場合のツールを提供していません。 この場合、依存関係は個別に管理できます。 - ハードな依存関係: チャートには、(`charts/` ディレクトリ内に) 依存する別のチャートが含まれる場合があります。 この場合、チャートをインストールすると、 その依存関係がすべてインストールされます。 この場合、チャートとその依存関係はコレクションとして管理されます。 チャートが (`helm package` を介して) パッケージ化されると、 そのすべてのハードな依存関係がチャートにバンドルされます。 ## チャートのバージョン チャートは、[SemVer 2 仕様](https://semver.org) に従ってバージョン管理されています。 すべてのチャートにバージョン番号が必要です。 ## Chart.yaml チャートに関する情報は、`Chart.yaml` と呼ばれる特別なファイルに保存されます。 すべてのチャートにこのファイルが必要です。 ## Helm (と helm) Helm は Kubernetes のパッケージマネージャーです。 オペレーティングシステムのパッケージマネージャーを使用すると、OS にツールを簡単にインストールできます。 Helm を使用すると、アプリケーションやリソースを Kubernetes クラスターに簡単にインストールできます。 _Helm_ はプロジェクトの名前ですが、コマンドラインクライアントの名前も `helm` です。 慣例により、プロジェクトについて言うとき、_Helm_ は大文字です。 クライアントの場合、_helm_ は小文字です。 ## Helm 設定ファイル (XDG) Helm は構成ファイルを XDG ディレクトリに保存します。 これらのディレクトリは、`helm` が初めて実行されたときに作成されます。 ## Kube Config (KUBECONFIG) Helm クライアントは、_Kube config_ ファイル形式のファイルを使用して、 Kubernetes クラスターについて学習します。 デフォルトでは、Helm はこのファイルを `kubectl` が作成した場所 (`$HOME/.kube/config`) で見つけようとします。 ## Lint (Linting) チャートを _lint_ するには、それが Helm チャート標準の規則と要件に従っていることを検証します。 Helm はこれを行うためのツール、 特に `helm lint` コマンドを提供します。 ## Provenance (Provenance ファイル) Helm チャートには、チャートの出所とその内容に関する情報を提供する _Provenance ファイル_ が添付されている場合があります。 Provenance ファイルは、Helm のセキュリティストーリーの一部です。 Provenance には、Chart アーカイブファイルの暗号化ハッシュ、Chart.yaml データ、 および署名ブロック (OpenPGP "clearsign" ブロック) が含まれています。 キーチェーンと組み合わせると、チャートユーザーは次のことができるようになります。 - チャートが信頼できる当事者によって署名されたことを検証する - チャートのファイルが改ざんされていないことを検証する - チャートのメタデータ (`Chart.yaml`) の内容を検証する - チャートをその Provenance データにすばやく一致させる Provenance ファイルには `.prov` 拡張子が付いており、 チャートリポジトリサーバーまたはその他の HTTP サーバーから提供できます。 ## リリース チャートがインストールされると、 Helm ライブラリはそのインストールを追跡するための _リリース_ を作成します。 1 つのチャートを同じクラスターに何度もインストールして、さまざまなリリースを作成できます。 たとえば、`helm install` を異なるリリース名で 3 回実行することで、 3 つの PostgreSQL データベースをインストールできます。 ## リリース番号 (リリースバージョン) 1 つのリリースを複数回更新することができます。 シーケンシャルカウンタは、リリースの変更を追跡するために使用されます。 最初に `helm install` を実行すると、_リリース番号_ は 1 になります。 リリースがアップグレードされたり、ロールバックされたりするたびに、リリース番号は増加します。 ## ロールバック リリースは、新しいチャートまたは構成にアップグレードできます。 ただし、リリース履歴が保存されているため、リリースを前のリリース番号に _ロールバックする_ こともできます。 これは、`helm rollback` コマンドで行われます。 重要なのは、ロールバックされたリリースには新しいリリース番号が付与されます。 | 操作 | リリース番号 | |------------|------------------------------------------------------| | インストール | リリース 1 | | アップグレード | リリース 2 | | アップグレード | リリース 3 | | ロールバック 1 | リリース 4 (ただし リリース 1 と同じ構成を実行している) | 上の表は、インストール、アップグレード、およびロールバックで リリース番号がどのように増加するかを示しています。 ## Helm ライブラリ (または SDK) Helm ライブラリ (または SDK) は、Kubernetes API サーバーと直接対話して、 Kubernetes リソースをインストール、アップグレード、クエリ、および削除する Go コードを指します。 プロジェクトにインポートして、 CLI の代わりに Helm をクライアントライブラリとして使用できます。 ## リポジトリ (レポ, チャートリポジトリ) Helm チャートは、_チャートリポジトリ_ (_リポジトリ_、または単に_レポ_) と呼ばれる 専用の HTTP サーバに保存できます。 チャートリポジトリサーバは、 チャートのバッチを記述する `index.yaml` ファイルを提供できるシンプルな HTTP サーバであり、 各チャートのダウンロード元に関する情報を提供します。 (多くのチャートリポジトリは、チャートと `index.yaml` ファイルを提供します。) Helm クライアントは、0個以上のチャートリポジトリを指すことができます。 デフォルトでは、Helm クライアントはチャートリポジトリで構成されていません。 チャートリポジトリは、`helm repo add` コマンドを使用していつでも追加できます。 ## Values (Values ファイル, values.yaml) Values は、テンプレートのデフォルトを独自の情報で上書きする方法を提供します。 Helm チャートは「パラメータ化」されています。 つまり、チャートの開発者は、インストール時にオーバーライドできる構成を公開することがあります。 たとえば、チャートは、サービスのユーザー名を設定できる `username` フィールドを公開する場合があります。 これらの公開された変数は、Helm の用語では _values_ と呼ばれます。 Values は、`helm install` および `helm upgrade` の操作中に直接渡すか、 または `values.yaml` ファイルを使用して設定できます。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Kubernetes 用 Helm パッケージマネージャー ### 概要 Kubernetes 用パッケージマネージャー Helm の一般的な操作: - helm search: chart を検索します - helm pull: chart をローカルディレクトリにダウンロードして確認します - helm install: chart を Kubernetes にアップロードします - helm list: chart の release を一覧表示します 環境変数: | 名前 | 説明 | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | キャッシュファイルを保存する別の場所を設定します。 | | $HELM_CONFIG_HOME | Helm 設定を保存する別の場所を設定します。 | | $HELM_DATA_HOME | Helm データを保存する別の場所を設定します。 | | $HELM_DEBUG | Helm がデバッグモードで実行されているかどうかを示します。 | | $HELM_DRIVER | バックエンドストレージドライバーを設定します。値: configmap, secret, memory, sql。 | | $HELM_DRIVER_SQL_CONNECTION_STRING | SQL ストレージドライバーが使用する接続文字列を設定します。 | | $HELM_MAX_HISTORY | Helm release 履歴の最大数を設定します。 | | $HELM_NAMESPACE | Helm 操作に使用する namespace を設定します。 | | $HELM_NO_PLUGINS | プラグインを無効にします。プラグインを無効にするには HELM_NO_PLUGINS=1 を設定します。 | | $HELM_PLUGINS | プラグインディレクトリへのパスを設定します。 | | $HELM_REGISTRY_CONFIG | レジストリ設定ファイルへのパスを設定します。 | | $HELM_REPOSITORY_CACHE | リポジトリキャッシュディレクトリへのパスを設定します。 | | $HELM_REPOSITORY_CONFIG | リポジトリファイルへのパスを設定します。 | | $KUBECONFIG | 別の Kubernetes 設定ファイルを設定します（デフォルト "~/.kube/config"）。 | | $HELM_KUBEAPISERVER | 認証用の Kubernetes API サーバーエンドポイントを設定します。 | | $HELM_KUBECAFILE | Kubernetes 認証局ファイルを設定します。 | | $HELM_KUBEASGROUPS | 偽装に使用するグループをカンマ区切りのリストで設定します。 | | $HELM_KUBEASUSER | 操作時に偽装するユーザー名を設定します。 | | $HELM_KUBECONTEXT | kubeconfig コンテキストの名前を設定します。 | | $HELM_KUBETOKEN | 認証に使用する Bearer KubeToken を設定します。 | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Kubernetes API サーバーの証明書検証をスキップするかどうかを示します（非セキュア）。 | | $HELM_KUBETLS_SERVER_NAME | Kubernetes API サーバー証明書の検証に使用するサーバー名を設定します。 | | $HELM_BURST_LIMIT | サーバーに多数の CRD が含まれる場合のデフォルトバースト制限を設定します（デフォルト 100、無効にするには -1）。 | | $HELM_QPS | 高いバースト値を超える多数の呼び出しがある場合の QPS（秒間クエリ数）を設定します。 | Helm は以下の設定順序に基づいてキャッシュ、設定、データを保存します: - HELM_*_HOME 環境変数が設定されている場合、その値が使用されます - それ以外の場合、XDG ベースディレクトリ仕様をサポートするシステムでは XDG 変数が使用されます - 他の場所が設定されていない場合、オペレーティングシステムに基づいたデフォルトの場所が使用されます デフォルトディレクトリはオペレーティングシステムによって異なります。デフォルトは以下のとおりです: | OS | キャッシュパス | 設定パス | データパス | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### オプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm completion](/helm/helm_completion.md) - 指定したシェル用の自動補完スクリプトを生成します * [helm create](/helm/helm_create.md) - 指定した名前で新しい chart を作成します * [helm dependency](/helm/helm_dependency.md) - chart の依存関係を管理します * [helm env](/helm/helm_env.md) - Helm クライアントの環境情報を表示します * [helm get](/helm/helm_get.md) - 指定した release の詳細情報をダウンロードします * [helm history](/helm/helm_history.md) - release の履歴を取得します * [helm install](/helm/helm_install.md) - chart をインストールします * [helm lint](/helm/helm_lint.md) - chart の問題点を検査します * [helm list](/helm/helm_list.md) - release を一覧表示します * [helm package](/helm/helm_package.md) - chart ディレクトリを chart アーカイブにパッケージ化します * [helm plugin](/helm/helm_plugin.md) - Helm プラグインをインストール、一覧表示、またはアンインストールします * [helm pull](/helm/helm_pull.md) - リポジトリから chart をダウンロードし、（オプションで）ローカルディレクトリに展開します * [helm push](/helm/helm_push.md) - chart をリモートにプッシュします * [helm registry](/helm/helm_registry.md) - レジストリにログインまたはログアウトします * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、およびインデックス作成を行います * [helm rollback](/helm/helm_rollback.md) - release を以前のリビジョンにロールバックします * [helm search](/helm/helm_search.md) - chart をキーワード検索します * [helm show](/helm/helm_show.md) - chart の情報を表示します * [helm status](/helm/helm_status.md) - 指定した release のステータスを表示します * [helm template](/helm/helm_template.md) - テンプレートをローカルでレンダリングします * [helm test](/helm/helm_test.md) - release のテストを実行します * [helm uninstall](/helm/helm_uninstall.md) - release をアンインストールします * [helm upgrade](/helm/helm_upgrade.md) - release をアップグレードします * [helm verify](/helm/helm_verify.md) - 指定したパスの chart が署名されており有効であることを検証します * [helm version](/helm/helm_version.md) - クライアントのバージョン情報を出力します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- 指定したシェル用の自動補完スクリプトを生成します ### 概要 指定したシェル用に Helm の自動補完スクリプトを生成します。 ### オプション ``` -h, --help help for completion ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm * [helm completion bash](/helm/helm_completion_bash.md) - bash 用の自動補完スクリプトを生成します * [helm completion fish](/helm/helm_completion_fish.md) - fish 用の自動補完スクリプトを生成します * [helm completion powershell](/helm/helm_completion_powershell.md) - PowerShell 用の自動補完スクリプトを生成します * [helm completion zsh](/helm/helm_completion_zsh.md) - zsh 用の自動補完スクリプトを生成します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- bash 用の自動補完スクリプトを生成します ### 概要 Helm の bash シェル用自動補完スクリプトを生成します。 現在のシェルセッションに補完を読み込むには： source <(helm completion bash) 新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します： - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### オプション ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm completion](/helm/helm_completion.md) - 指定したシェル用の自動補完スクリプトを生成します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- fish 用の自動補完スクリプトを生成します ### 概要 Helm の fish シェル用自動補完スクリプトを生成します。 現在のシェルセッションに補完を読み込むには： helm completion fish | source 新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します： helm completion fish > ~/.config/fish/completions/helm.fish この設定を有効にするには、新しいシェルを起動する必要があります。 ``` helm completion fish [flags] ``` ### オプション ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm completion](/helm/helm_completion.md) - 指定したシェル用の自動補完スクリプトを生成します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- PowerShell 用の自動補完スクリプトを生成します ### 概要 Helm の PowerShell 用自動補完スクリプトを生成します。 現在のシェルセッションに補完を読み込むには： PS C:\> helm completion powershell | Out-String | Invoke-Expression 新しいセッションごとに補完を自動で読み込むには、上記コマンドの出力を PowerShell プロファイルに追加してください。 ``` helm completion powershell [flags] ``` ### オプション ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm completion](/helm/helm_completion.md) - 指定したシェル用の自動補完スクリプトを生成します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- zsh 用の自動補完スクリプトを生成します ### 概要 Helm の zsh シェル用自動補完スクリプトを生成します。 現在のシェルセッションに補完を読み込むには： source <(helm completion zsh) 新しいセッションごとに補完を読み込むには、次のコマンドを一度実行します： helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### オプション ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm completion](/helm/helm_completion.md) - 指定したシェル用の自動補完スクリプトを生成します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- 指定された名前で新しい chart を作成します ### 概要 このコマンドは、chart で一般的に使用されるファイルやディレクトリを含む chart ディレクトリを作成します。 例えば、`helm create foo` を実行すると、次のようなディレクトリ構造が作成されます。 foo/ ├── .helmignore # Helm chart のパッケージ化時に無視するパターンを記述します ├── Chart.yaml # chart に関する情報 ├── values.yaml # テンプレートのデフォルト値 ├── charts/ # この chart が依存する chart └── templates/ # テンプレートファイル └── tests/ # テストファイル `helm create` は引数としてパスを受け取ります。指定されたパスにディレクトリが存在しない場合、Helm は必要に応じてディレクトリを作成します。指定された出力先が既に存在し、そのディレクトリにファイルがある場合、競合するファイルは上書きされますが、それ以外のファイルはそのまま残ります。 ``` helm create NAME [flags] ``` ### オプション ``` -h, --help help for create -p, --starter string Helm starter scaffold の名前または絶対パス ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- chart の依存関係を管理します ### 概要 chart の依存関係を管理します。 Helm chart は依存関係を `charts/` ディレクトリに格納します。chart 開発者にとっては、すべての依存関係を宣言する `Chart.yaml` で依存関係を管理する方が簡単な場合が多いです。 dependency コマンドはこのファイルを操作し、必要な依存関係と `charts/` ディレクトリに格納された実際の依存関係を簡単に同期できるようにします。 たとえば、次の Chart.yaml は 2 つの依存関係を宣言しています: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" `name` には chart の名前を指定します。この名前は、その chart の `Chart.yaml` ファイル内の名前と一致する必要があります。 `version` フィールドには、セマンティックバージョンまたはバージョン範囲を指定します。 `repository` URL は Chart Repository を指す必要があります。Helm は URL に `/index.yaml` を追加することで、chart リポジトリのインデックスを取得できることを期待します。注意: `repository` はエイリアスにすることもできます。エイリアスは `alias:` または `@` で始める必要があります。 バージョン 2.2.0 以降、repository はローカルに格納された依存 chart のディレクトリパスとして定義することもできます。パスは `file://` のプレフィックスで始める必要があります。たとえば: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" 依存 chart がローカルから取得される場合、`helm repo add` でリポジトリを追加する必要はありません。この場合もバージョンマッチングがサポートされます。 ### オプション ``` -h, --help help for dependency ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用の Helm パッケージマネージャー * [helm dependency build](/helm/helm_dependency_build.md) - Chart.lock ファイルに基づいて charts/ ディレクトリを再構築します * [helm dependency list](/helm/helm_dependency_list.md) - 指定した chart の依存関係を一覧表示します * [helm dependency update](/helm/helm_dependency_update.md) - Chart.yaml の内容に基づいて charts/ ディレクトリを更新します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- `Chart.lock` ファイルに基づいて `charts/` ディレクトリを再構築します ### 概要 `Chart.lock` ファイルから `charts/` ディレクトリを構築します。 このコマンドは、ロックファイルで指定された状態に chart の依存関係を再構築します。`helm dependency update` とは異なり、依存関係の再解決は行いません。 ロックファイルが見つからない場合、`helm dependency build` は `helm dependency update` と同じ動作をします。 ``` helm dependency build CHART [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm dependency](/helm/helm_dependency.md) - chart の依存関係を管理します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- 指定した chart の依存関係を一覧表示します ### 概要 chart で宣言されているすべての依存関係を一覧表示します。 このコマンドは、chart アーカイブと chart ディレクトリの両方を入力として受け付けます。chart の内容を変更することはありません。 chart を読み込めない場合はエラーが発生します。 ``` helm dependency list CHART [flags] ``` ### オプション ``` -h, --help help for list --max-col-width uint 出力テーブルの最大列幅 (default 80) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm dependency](/helm/helm_dependency.md) - chart の依存関係を管理します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- `Chart.yaml` の内容に基づいて `charts/` ディレクトリを更新します ### 概要 ディスク上の依存関係を `Chart.yaml` に合わせて更新します。 このコマンドは、`Chart.yaml` で指定された必要な chart が `charts/` ディレクトリに存在し、適切なバージョンであることを確認します。依存関係を満たす最新の chart をダウンロードし、古い依存関係を削除します。 更新が成功すると、依存関係を正確なバージョンで再構築するために使用できるロックファイルが生成されます。 依存関係は `Chart.yaml` に記載されている必要はありません。そのため、update コマンドが chart を削除するのは、(a) `Chart.yaml` ファイルに記載されていて、かつ (b) バージョンが正しくない場合のみです。 ``` helm dependency update CHART [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm dependency](/helm/helm_dependency.md) - chart の依存関係を管理します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- Helm クライアントの環境情報を表示します ### 概要 Helm が使用しているすべての環境情報を出力します。 ``` helm env [flags] ``` ### オプション ``` -h, --help help for env ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- 指定した release の詳細情報を取得します ### 概要 このコマンドは、release に関する詳細情報を取得するための複数のサブコマンドで構成されています。以下の情報を取得できます: - release 生成時に使用された values - 生成された manifest ファイル - chart が提供する notes - release に関連付けられた hook - release のメタデータ ### オプション ``` -h, --help help for get ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm * [helm get all](/helm/helm_get_all.md) - 指定した release のすべての情報を取得します * [helm get hooks](/helm/helm_get_hooks.md) - 指定した release のすべての hook を取得します * [helm get manifest](/helm/helm_get_manifest.md) - 指定した release の manifest を取得します * [helm get metadata](/helm/helm_get_metadata.md) - 指定した release のメタデータを取得します * [helm get notes](/helm/helm_get_notes.md) - 指定した release の notes を取得します * [helm get values](/helm/helm_get_values.md) - 指定した release の values ファイルを取得します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- 指定された release のすべての情報をダウンロードします ### 概要 このコマンドは、指定された release に関する notes、hook、提供された values、生成された manifest ファイルなどの情報を、読みやすい形式で出力します。 ``` helm get all RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- 指定された release のすべての hook をダウンロードします ### 概要 このコマンドは、指定された release の hook をダウンロードします。 hook は YAML 形式で出力され、`---\n` で区切られます。 ``` helm get hooks RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for hooks --revision int get the named release with revision ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- 指定された release のマニフェストをダウンロードします ### 概要 このコマンドは、指定された release に対して生成されたマニフェストを取得します。 マニフェストは、この release の chart から生成された Kubernetes リソースを YAML 形式でエンコードしたものです。chart が他の chart に依存している場合、それらのリソースもマニフェストに含まれます。 ``` helm get manifest RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for manifest --revision int get the named release with revision ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- 指定された release のメタデータを取得します ``` helm get metadata RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- 指定された release のノートをダウンロードします ### 概要 このコマンドは、指定された release の chart が提供するノートを表示します。 ``` helm get notes RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for notes --revision int get the named release with revision ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- 指定された release の values ファイルをダウンロードします ### 概要 このコマンドは、指定された release の values ファイルをダウンロードします。 ``` helm get values RELEASE_NAME [flags] ``` ### オプション ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm get](/helm/helm_get.md) - 指定された release の拡張情報をダウンロードします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- release の履歴を表示します ### 概要 このコマンドは、指定した release の履歴（リビジョン一覧）を表示します。 デフォルトでは最大 256 件のリビジョンが返されます。`--max` オプションで取得するリビジョンの最大件数を設定できます。 履歴はテーブル形式で出力されます。例: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for history --max int 履歴に含めるリビジョンの最大件数 (default 256) -o, --output format 指定したフォーマットで出力します。使用可能な値: table, json, yaml (default table) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- chart をインストールします ### 概要 このコマンドは chart アーカイブをインストールします。 install の引数には、chart 参照、パッケージ化された chart へのパス、展開された chart ディレクトリへのパス、または URL を指定する必要があります。 chart の値をオーバーライドするには、`--values` フラグでファイルを指定するか、`--set` フラグでコマンドラインから設定を渡します。文字列値を強制する場合は `--set-string` を使用します。値自体がコマンドラインには長すぎる場合や動的に生成される場合は、`--set-file` を使用して個々の値をファイルから設定できます。また、`--set-json` を使用してコマンドラインから JSON 値（スカラー/オブジェクト/配列）を設定することもできます。 $ helm install -f myvalues.yaml myredis ./redis または $ helm install --set name=prod myredis ./redis または $ helm install --set-string long_int=1234567890 myredis ./redis または $ helm install --set-file my_script=dothings.sh myredis ./redis または $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis `--values`/`-f` フラグは複数回指定できます。最後（右端）に指定されたファイルが優先されます。例えば、myvalues.yaml と override.yaml の両方に 'Test' というキーが含まれている場合、override.yaml に設定された値が優先されます。 $ helm install -f myvalues.yaml -f override.yaml myredis ./redis `--set` フラグは複数回指定できます。最後（右端）に指定された値が優先されます。例えば、'foo' というキーに対して 'bar' と 'newbar' の両方が設定されている場合、'newbar' の値が優先されます。 $ helm install --set foo=bar --set foo=newbar myredis ./redis 同様に、次の例では 'foo' は '["four"]' に設定されます。 $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis また、次の例では 'foo' は '{"key1":"value1","key2":"bar"}' に設定されます。 $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis chart を実際にインストールせずに release の生成されたマニフェストを確認するには、`--debug` フラグと `--dry-run` フラグを組み合わせて使用できます。 `--dry-run` フラグは、Secret など機密情報を含む可能性があるリソースを含め、生成されたすべての chart マニフェストを出力します。Kubernetes の Secret を非表示にするには `--hide-secret` フラグを使用してください。これらのフラグの使用方法とタイミングには十分注意してください。 `--verify` が設定されている場合、chart には provenance ファイルが必須であり、provenance ファイルはすべての検証ステップを通過する必要があります。 インストールする chart を指定する方法は 6 通りあります。 1. chart 参照: helm install mymaria example/mariadb 2. パッケージ化された chart へのパス: helm install mynginx ./nginx-1.2.3.tgz 3. 展開された chart ディレクトリへのパス: helm install mynginx ./nginx 4. 絶対 URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. chart 参照とリポジトリ URL: helm install --repo https://example.com/charts/ mynginx nginx 6. OCI レジストリ: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx CHART 参照 chart 参照は、chart リポジトリ内の chart を参照する便利な方法です。 リポジトリ接頭辞を含む chart 参照（`example/mariadb`）を使用すると、Helm はローカル設定で 'example' という名前の chart リポジトリを探し、そのリポジトリ内で 'mariadb' という名前の chart を探します。`--devel` フラグを指定して開発バージョン（alpha、beta、リリース候補）も含めるか、`--version` フラグでバージョン番号を指定しない限り、その chart の最新の安定バージョンがインストールされます。 chart リポジトリの一覧を表示するには `helm repo list` を使用します。リポジトリ内の chart を検索するには `helm search` を使用します。 ``` helm install [NAME] [CHART] [flags] ``` ### オプション ``` --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- chart の問題点を検査します ### 概要 このコマンドは、chart のパスを受け取り、一連のテストを実行して chart が正しく構成されているか検証します。 インストールに失敗する原因となる問題を検出した場合は、[ERROR] メッセージを出力します。規約や推奨事項に反する問題を検出した場合は、[WARNING] メッセージを出力します。 ``` helm lint PATH [flags] ``` ### オプション ``` -h, --help help for lint --kube-version string capabilities と非推奨チェックに使用する Kubernetes バージョン --quiet 警告とエラーのみを出力します --set stringArray コマンドラインで値を設定します（複数指定、またはカンマ区切りで指定可能: key1=val1,key2=val2） --set-file stringArray コマンドラインで指定したファイルから値を設定します（複数指定、またはカンマ区切りで指定可能: key1=path1,key2=path2） --set-json stringArray コマンドラインで JSON 値を設定します（複数指定、またはカンマ区切りで指定可能: key1=jsonval1,key2=jsonval2） --set-literal stringArray コマンドラインでリテラル STRING 値を設定します --set-string stringArray コマンドラインで STRING 値を設定します（複数指定、またはカンマ区切りで指定可能: key1=val1,key2=val2） --skip-schema-validation 設定すると、JSON スキーマ検証を無効にします --strict lint の警告を失敗として扱います -f, --values strings YAML ファイルまたは URL で値を指定します（複数指定可能） --with-subcharts 依存 chart も lint します ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- release を一覧表示します ### 概要 このコマンドは、指定した namespace のすべての release を一覧表示します（namespace を指定しない場合は現在の namespace コンテキストを使用します）。 デフォルトでは、deployed または failed 状態の release のみを表示します。`--uninstalled` や `--all` などのフラグを使用すると、この動作を変更できます。これらのフラグは組み合わせることもできます: `--uninstalled --failed`。 デフォルトではアルファベット順にソートされます。リリース日でソートするには `-d` フラグを使用してください。 `--filter` フラグを指定すると、フィルターとして扱われます。フィルターは正規表現（Perl 互換）で、release のリストに適用されます。フィルターに一致した項目のみが返されます。 $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 結果が見つからない場合、`helm list` は終了コード 0 で終了しますが、出力はありません（`-q` フラグを指定していない場合はヘッダーのみ表示されます）。 デフォルトでは最大 256 件の結果が返されます。これを制限するには `--max` フラグを使用してください。`--max` を 0 に設定してもすべての結果が返されるわけではありません。代わりにサーバーのデフォルト値が使用され、これは 256 よりもはるかに大きい場合があります。`--max` フラグと `--offset` フラグを組み合わせることで、結果をページングできます。 ``` helm list [flags] ``` ### オプション ``` -a, --all フィルターを適用せずにすべての release を表示します -A, --all-namespaces すべての namespace の release を一覧表示します -d, --date リリース日でソートします --deployed deployed 状態の release を表示します。他のフラグが指定されていない場合、自動的に有効になります --failed failed 状態の release を表示します -f, --filter string 正規表現（Perl 互換）。この表現に一致するすべての release が結果に含まれます -h, --help help for list -m, --max int 取得する release の最大数 (default 256) --no-headers デフォルトの出力形式を使用する際にヘッダーを表示しません --offset int リストの次の release インデックス。開始値からのオフセットに使用します -o, --output format 指定した形式で出力します。使用可能な値: table, json, yaml (default table) --pending pending 状態の release を表示します -r, --reverse ソート順を逆にします -l, --selector string フィルタリングに使用するセレクター（ラベルクエリ）。'='、'=='、'!=' をサポートします（例: -l key1=value1,key2=value2）。secret（デフォルト）および configmap ストレージバックエンドでのみ動作します -q, --short 短い（静か）なリスト形式で出力します --superseded superseded 状態の release を表示します --time-format string Go の time フォーマッターを使用して時刻をフォーマットします。例: --time-format "2006-01-02 15:04:05Z0700" --uninstalled uninstalled 状態の release を表示します（'helm uninstall --keep-history' が使用された場合） --uninstalling 現在アンインストール中の release を表示します ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- chart ディレクトリを chart アーカイブにパッケージ化します ### 概要 このコマンドは chart をバージョン付き chart アーカイブファイルにパッケージ化します。パスが指定された場合、そのパスにある chart を探し（`Chart.yaml` ファイルが含まれている必要があります）、そのディレクトリをパッケージ化します。 バージョン付き chart アーカイブは Helm パッケージリポジトリで使用されます。 chart に署名するには `--sign` フラグを使用します。ほとんどの場合、`--keyring path/to/secret/keys` と `--key keyname` も指定する必要があります。 $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg `--keyring` を指定しない場合、環境設定で別の場所が指定されていない限り、Helm は公開キーリングをデフォルトとして使用します。 ``` helm package [CHART_PATH] [...] [flags] ``` ### オプション ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用の Helm パッケージマネージャー ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- Helm プラグインのインストール、一覧表示、アンインストールを行います ### 概要 クライアント側の Helm プラグインを管理します。 ### オプション ``` -h, --help help for plugin ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー * [helm plugin install](/helm/helm_plugin_install.md) - Helm プラグインをインストールします * [helm plugin list](/helm/helm_plugin_list.md) - インストール済みの Helm プラグインを一覧表示します * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - 1つまたは複数の Helm プラグインをアンインストールします * [helm plugin update](/helm/helm_plugin_update.md) - 1つまたは複数の Helm プラグインを更新します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- Helm プラグインをインストールします VCS リポジトリの URL またはローカルパスからプラグインをインストールします。 ``` helm plugin install [options] [flags] ``` ### オプション ``` -h, --help help for install --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm plugin](/helm/helm_plugin.md) - Helm プラグインのインストール、一覧表示、アンインストールを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- インストール済みの Helm プラグインを一覧表示します ``` helm plugin list [flags] ``` ### オプション ``` -h, --help help for list ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm plugin](/helm/helm_plugin.md) - Helm プラグインのインストール、一覧表示、アンインストールを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- 1つまたは複数の Helm プラグインをアンインストールします ``` helm plugin uninstall ... [flags] ``` ### オプション ``` -h, --help help for uninstall ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm plugin](/helm/helm_plugin.md) - Helm プラグインのインストール、一覧表示、アンインストールを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- 1つまたは複数の Helm プラグインを更新します ``` helm plugin update ... [flags] ``` ### オプション ``` -h, --help help for update ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm plugin](/helm/helm_plugin.md) - Helm プラグインのインストール、一覧表示、アンインストールを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- リポジトリから chart をダウンロードし、（オプションで）ローカルディレクトリに展開します ### 概要 パッケージリポジトリからパッケージを取得し、ローカルにダウンロードします。 パッケージを検査、変更、再パッケージ化する際に便利です。また、chart をインストールせずに暗号検証を行うためにも使用できます。 ダウンロード後に chart を展開するオプションがあります。この場合、chart 用のディレクトリが作成され、その中に展開されます。 `--verify` フラグが指定された場合、要求された chart には provenance ファイルが必須であり、検証プロセスに合格する必要があります。いずれかの条件を満たさない場合はエラーとなり、chart はローカルに保存されません。 ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用の Helm パッケージマネージャー ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- chart をリモートにプッシュします ### 概要 chart をレジストリにアップロードします。 chart に関連する provenance ファイルがある場合、それも一緒にアップロードされます。 ``` helm push [chart] [remote] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用の Helm パッケージマネージャー ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- レジストリへのログインおよびログアウトを行います ### 概要 このコマンドは、レジストリを操作するための複数のサブコマンドで構成されています。 ### オプション ``` -h, --help help for registry ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用の Helm パッケージマネージャー * [helm registry login](/helm/helm_registry_login.md) - レジストリにログインします * [helm registry logout](/helm/helm_registry_logout.md) - レジストリからログアウトします ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- レジストリにログインします ### 概要 リモートレジストリへの認証を行います。 ``` helm registry login [host] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm registry](/helm/helm_registry.md) - レジストリへのログインおよびログアウトを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- レジストリからログアウトします ### 概要 リモートレジストリに保存されている認証情報を削除します。 ``` helm registry logout [host] [flags] ``` ### オプション ``` -h, --help help for logout ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm registry](/helm/helm_registry.md) - レジストリへのログインおよびログアウトを行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ### 概要 このコマンドには、chart リポジトリを操作するための複数のサブコマンドがあります。 リポジトリの追加、削除、一覧表示、インデックス作成に使用できます。 ### オプション ``` -h, --help help for repo ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー * [helm repo add](/helm/helm_repo_add.md) - chart リポジトリを追加します * [helm repo index](/helm/helm_repo_index.md) - パッケージ化された chart を含むディレクトリからインデックスファイルを生成します * [helm repo list](/helm/helm_repo_list.md) - chart リポジトリを一覧表示します * [helm repo remove](/helm/helm_repo_remove.md) - chart リポジトリを削除します * [helm repo update](/helm/helm_repo_update.md) - chart リポジトリの最新情報をローカルに取得します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- chart リポジトリを追加します ``` helm repo add [NAME] [URL] [flags] ``` ### オプション ``` --allow-deprecated-repos 完全に削除された公式リポジトリの追加を許可します（デフォルトでは禁止） --ca-file string HTTPS 対応サーバーの証明書を検証するための CA バンドル --cert-file string HTTPS クライアント認証に使用する SSL 証明書ファイル --force-update リポジトリが既に存在する場合、上書きします -h, --help help for add --insecure-skip-tls-verify リポジトリの TLS 証明書検証をスキップします --key-file string HTTPS クライアント認証に使用する SSL 鍵ファイル --no-update 無視されます。以前は強制更新を無効にしていましたが、現在は --force-update に置き換えられました。 --pass-credentials すべてのドメインに認証情報を渡します --password string chart リポジトリのパスワード --password-stdin chart リポジトリのパスワードを標準入力から読み取ります --timeout duration インデックスファイルのダウンロード完了を待機する時間 (default 2m0s) --username string chart リポジトリのユーザー名 ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- chart リポジトリのインデックスファイルを生成します ### 概要 カレントディレクトリを読み取り、見つかった chart に基づいてインデックスファイルを生成し、結果を同ディレクトリの `index.yaml` に書き込みます。 このコマンドは chart リポジトリ用の `index.yaml` ファイルを作成します。chart の参照先となる絶対 URL を設定するには `--url` フラグを使用します。 生成したインデックスを既存のインデックスファイルにマージするには `--merge` フラグを使用します。この場合、カレントディレクトリで見つかった chart が `--merge` で指定したインデックスにマージされます。同じ chart が存在する場合はローカルの chart が優先されます。 ``` helm repo index [DIR] [flags] ``` ### オプション ``` -h, --help help for index --json JSON 形式で出力します --merge string 生成したインデックスを指定したインデックスファイルにマージします --url string chart リポジトリの URL ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- chart リポジトリを一覧表示します ``` helm repo list [flags] ``` ### オプション ``` -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- chart リポジトリを削除します ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### オプション ``` -h, --help help for remove ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- chart リポジトリの最新情報をローカルに取得します ### 概要 各 chart リポジトリから最新の chart 情報を取得します。 取得した情報はローカルにキャッシュされ、`helm search` などのコマンドで使用されます。 更新するリポジトリを指定することもできます。 $ helm repo update ... すべてのリポジトリを更新するには `helm repo update` を実行します。 ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### オプション ``` --fail-on-repo-update-fail いずれかのリポジトリの更新に失敗した場合、コマンド全体を失敗させます -h, --help help for update --timeout duration インデックスファイルのダウンロード完了を待機する時間 (default 2m0s) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm repo](/helm/helm_repo.md) - chart リポジトリの追加、一覧表示、削除、更新、インデックス作成を行います ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- release を以前のリビジョンにロールバックします ### 概要 このコマンドは release を以前のリビジョンにロールバックします。 rollback コマンドの第一引数は release 名、第二引数はリビジョン（バージョン）番号です。第二引数を省略するか 0 を指定すると、直前の release にロールバックします。 リビジョン番号を確認するには `helm history RELEASE` を実行してください。 ``` helm rollback [REVISION] [flags] ``` ### オプション ``` --cleanup-on-fail ロールバック失敗時に、このロールバックで作成された新しいリソースの削除を許可します --dry-run ロールバックをシミュレートします --force 必要に応じて削除/再作成によるリソースの強制更新を行います -h, --help help for rollback --history-max int release ごとに保存するリビジョンの最大数を制限します。0 を指定すると無制限になります (default 10) --no-hooks ロールバック中に hook の実行を防止します --recreate-pods 該当するリソースに対して Pod の再起動を行います --timeout duration 個々の Kubernetes 操作（hook 用の Job など）を待機する時間 (default 5m0s) --wait 指定した場合、すべての Pod、PVC、Service、および Deployment・StatefulSet・ReplicaSet の最小 Pod 数が Ready 状態になるまで待機してから release を成功とマークします。待機時間は --timeout で指定した値が上限となります --wait-for-jobs 指定した場合、--wait が有効なときにすべての Job が完了するまで待機してから release を成功とマークします。待機時間は --timeout で指定した値が上限となります ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- chart をキーワード検索します ### 概要 search コマンドは、Helm chart が保存されているさまざまな場所から chart を検索します。 検索対象には Artifact Hub や、ユーザーが追加したリポジトリが含まれます。 検索対象に応じたサブコマンドを使用してください。 ### オプション ``` -h, --help help for search ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー * [helm search hub](/helm/helm_search_hub.md) - Artifact Hub または独自の Hub インスタンスから chart を検索します * [helm search repo](/helm/helm_search_repo.md) - リポジトリから chart をキーワード検索します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- Artifact Hub または独自の Hub インスタンスから chart を検索します ### 概要 Artifact Hub または独自の Hub インスタンスから chart を検索します。 Artifact Hub は、CNCF プロジェクトのパッケージや設定を検索、インストール、公開できる Web アプリケーションです。一般公開されている Helm chart を含みます。Artifact Hub は Cloud Native Computing Foundation のサンドボックスプロジェクトです。https://artifacthub.io/ で閲覧できます。 [KEYWORD] 引数には、キーワード文字列またはクォートで囲んだリッチクエリオプションを指定できます。リッチクエリオプションの詳細については、https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search を参照してください。 以前のバージョンの Helm では、デフォルトの `endpoint` として Monocular インスタンスを使用していました。後方互換性のため、Artifact Hub は Monocular 検索 API と互換性があります。`endpoint` フラグを指定する場合は、Monocular 互換の検索 API エンドポイントを実装している必要があります。なお、Monocular インスタンスを `endpoint` として指定する場合、リッチクエリはサポートされません。API の詳細については、https://github.com/helm/monocular を参照してください。 ``` helm search hub [KEYWORD] [flags] ``` ### オプション ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm search](/helm/helm_search.md) - chart をキーワード検索します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- リポジトリから chart をキーワード検索します ### 概要 このコマンドは、システムに設定されているすべてのリポジトリを読み込み、一致する chart を検索します。 リポジトリの検索には、システムに保存されたメタデータを使用します。 デフォルトでは、見つかった chart の最新安定バージョンが表示されます。 `--devel` フラグを指定すると、プレリリースバージョンも出力に含まれます。 バージョン制約を使用して検索する場合は、`--version` を使用します。 使用例: # "nginx" というキーワードに一致する安定リリースバージョンを検索 $ helm search repo nginx # "nginx" というキーワードに一致するリリースバージョンを検索（プレリリースバージョンを含む） $ helm search repo nginx --devel # メジャーバージョン 1 の nginx-ingress の最新安定リリースを検索 $ helm search repo nginx-ingress --version ^1.0.0 リポジトリは `helm repo` コマンドで管理します。 ``` helm search repo [keyword] [flags] ``` ### オプション ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm search](/helm/helm_search.md) - chart をキーワード検索します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- chart の情報を表示します ### 概要 このコマンドには、chart の情報を表示するサブコマンドが複数あります。 ### オプション ``` -h, --help help for show ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー * [helm show all](/helm/helm_show_all.md) - chart のすべての情報を表示します * [helm show chart](/helm/helm_show_chart.md) - chart の定義を表示します * [helm show crds](/helm/helm_show_crds.md) - chart の CRD を表示します * [helm show readme](/helm/helm_show_readme.md) - chart の README を表示します * [helm show values](/helm/helm_show_values.md) - chart の values を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- chart のすべての情報を表示します ### 概要 このコマンドは chart（ディレクトリ、ファイル、または URL）のすべての内容（`values.yaml`、`Chart.yaml`、README）を表示します。 ``` helm show all [CHART] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm show](/helm/helm_show.md) - chart の情報を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- chart の定義を表示します ### 概要 このコマンドは chart（ディレクトリ、ファイル、または URL）の `Chart.yaml` ファイルの内容を表示します。 ``` helm show chart [CHART] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm show](/helm/helm_show.md) - chart の情報を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- chart の CRD を表示します ### 概要 このコマンドは chart（ディレクトリ、ファイル、または URL）の CustomResourceDefinition ファイルの内容を表示します。 ``` helm show crds [CHART] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm show](/helm/helm_show.md) - chart の情報を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- chart の README を表示します ### 概要 このコマンドは chart（ディレクトリ、ファイル、または URL）の README ファイルの内容を表示します。 ``` helm show readme [CHART] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm show](/helm/helm_show.md) - chart の情報を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- chart の values を表示します ### 概要 このコマンドは chart（ディレクトリ、ファイル、または URL）の `values.yaml` ファイルの内容を表示します。 ``` helm show values [CHART] [flags] ``` ### オプション ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm show](/helm/helm_show.md) - chart の情報を表示します ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- 指定した release のステータスを表示します ### 概要 このコマンドは、指定した release のステータスを表示します。 表示されるステータスは以下の情報で構成されます。 - 最後のデプロイ日時 - release が存在する Kubernetes namespace - release の状態（unknown、deployed、uninstalled、superseded、failed、uninstalling、pending-install、pending-upgrade、pending-rollback のいずれか） - release のリビジョン - release の説明（完了メッセージまたはエラーメッセージ。--show-desc 指定時に表示） - release を構成するリソースの一覧（--show-resources 指定時に表示） - 最後のテスト実行結果（該当する場合） - chart が提供する追加の notes ``` helm status RELEASE_NAME [flags] ``` ### オプション ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision --show-desc if set, display the description message of the named release --show-resources if set, display the resources of the named release ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- テンプレートをローカルでレンダリングします ### 概要 chart のテンプレートをローカルでレンダリングし、出力を表示します。 通常はクラスター内で参照・取得される値は、ローカルではダミー値で代用されます。また、chart の妥当性をサーバー側で検証する処理（例: 使用する API がサポートされているか）は実行されません。 ``` helm template [NAME] [CHART] [flags] ``` ### オプション ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- release のテストを実行します ### 概要 このコマンドは release のテストを実行します。 引数にはデプロイ済みの release 名を指定します。 実行するテストは、インストール時の chart 内で定義されています。 ``` helm test [RELEASE] [flags] ``` ### オプション ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --hide-notes if set, do not show notes in test output. Does not affect presence in chart metadata --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- release をアンインストールします ### 概要 このコマンドは release 名を受け取り、その release をアンインストールします。 chart の最新 release に関連付けられたすべてのリソースと release 履歴を削除し、release 名を再利用可能にします。 `--dry-run` フラグを使用すると、実際にアンインストールせずに、どの release がアンインストールされるかを確認できます。 ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### オプション ``` --cascade string "background"、"orphan"、または "foreground" のいずれかを指定します。依存リソースに対するカスケード削除の方式を選択します。デフォルトは background です。 (default "background") --description string カスタム説明を追加します --dry-run アンインストールをシミュレートします -h, --help help for uninstall --ignore-not-found "release not found" を成功したアンインストールとして扱います --keep-history 関連するすべてのリソースを削除し、release を削除済みとしてマークしますが、release 履歴は保持します --no-hooks アンインストール中に hook の実行を防止します --timeout duration 個々の Kubernetes 操作（hook 用の Job など）を待機する時間 (default 5m0s) --wait 指定した場合、すべてのリソースが削除されるまで待機します。待機時間は `--timeout` で指定した値が上限となります ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- release をアップグレードします ### 概要 release を新しいバージョンの chart にアップグレードします。 引数には release と chart を指定する必要があります。chart の引数には、chart 参照（`example/mariadb`）、chart ディレクトリへのパス、パッケージ化された chart、または完全な URL のいずれかを指定できます。chart 参照の場合、`--version` フラグを指定しない限り、最新バージョンが使用されます。 chart の値をオーバーライドするには、`--values` フラグでファイルを指定するか、`--set` フラグでコマンドラインから設定を渡します。文字列値を強制する場合は `--set-string` を使用します。値自体がコマンドラインには長すぎる場合や動的に生成される場合は、`--set-file` を使用して個々の値をファイルから設定できます。また、`--set-json` を使用してコマンドラインから JSON 値（スカラー/オブジェクト/配列）を設定することもできます。 `--values`/`-f` フラグは複数回指定できます。最後（右端）に指定されたファイルが優先されます。例えば、myvalues.yaml と override.yaml の両方に 'Test' というキーが含まれている場合、override.yaml に設定された値が優先されます。 $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis `--set` フラグは複数回指定できます。最後（右端）に指定された値が優先されます。例えば、'foo' というキーに対して 'bar' と 'newbar' の両方が設定されている場合、'newbar' の値が優先されます。 $ helm upgrade --set foo=bar --set foo=newbar redis ./redis このコマンドで `--reuse-values` フラグを使用すると、既存の release の値を更新することもできます。`RELEASE` と `CHART` の引数には元のパラメータを設定し、既存の値は `--values`/`-f` または `--set` フラグで設定された値とマージされます。新しい値が優先されます。 $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis `--dry-run` フラグは、Secret など機密情報を含む可能性があるリソースを含め、生成されたすべての chart マニフェストを出力します。Kubernetes の Secret を非表示にするには `--hide-secret` フラグを使用してください。これらのフラグの使用には十分注意してください。 ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### オプション ``` --atomic if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- 指定されたパスの chart が署名済みで有効であることを検証します ### 概要 指定された chart に有効な provenance ファイルがあることを検証します。 provenance ファイルは、chart が改ざんされておらず、信頼できるプロバイダーによってパッケージ化されたことを暗号学的に証明します。 このコマンドはローカルの chart を検証するために使用できます。他のコマンドにも同様の検証を行う `--verify` フラグがあります。署名されたパッケージを生成するには、`helm package --sign` コマンドを使用してください。 ``` helm verify PATH [flags] ``` ### オプション ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- クライアントのバージョン情報を出力します ### 概要 Helm のバージョン情報を表示します。 出力は以下のようになります。 version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version はこのリリースのセマンティックバージョンです。 - GitCommit はこのバージョンがビルドされたコミットの SHA です。 - GitTreeState は、このバイナリのビルド時にローカルコードの変更がない場合は "clean"、ローカルで変更されたコードからビルドされた場合は "dirty" になります。 - GoVersion は Helm のコンパイルに使用された Go のバージョンです。 --template フラグを使用する場合、テンプレートで以下のプロパティを使用できます。 - .Version には Helm のセマンティックバージョンが含まれます - .GitCommit には git コミットの SHA が含まれます - .GitTreeState には Helm がビルドされた時点の git ツリーの状態が含まれます - .GoVersion には Helm がコンパイルされた Go のバージョンが含まれます 例: --template='Version: {{.Version}}' は 'Version: v3.2.1' を出力します。 ``` helm version [flags] ``` ### オプション ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### 親コマンドから継承されたオプション ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 関連項目 * [helm](/helm/helm.md) - Kubernetes 用パッケージマネージャー Helm ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Helm コマンド description: helm CLI コマンドの完全なリストのドキュメント。 sidebar_position: 6 id: helm-category --- # Helm コマンド ここでは、Helm の CLI コマンドのリストと、それらの使用法に関するヘルプ情報を確認できます。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action による GitHub Pages での chart 自動公開 description: Chart Releaser Action を使用して GitHub Pages で chart を自動公開する方法について説明します。 sidebar_position: 3 --- このガイドでは、[Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) を使用して GitHub Pages で chart を自動公開する方法について説明します。Chart Releaser Action は、[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI ツールを使用して、GitHub プロジェクトをセルフホスト型の Helm chart リポジトリに変換する GitHub Action ワークフローです。 ## リポジトリの構成 GitHub 組織の下に Git リポジトリを作成します。リポジトリ名は `helm-charts` などが考えられますが、他の名前でも問題ありません。すべての chart のソースは `main` ブランチに配置できます。chart はディレクトリツリーのトップレベルにある `/charts` ディレクトリに配置してください。 chart の公開用に `gh-pages` という別のブランチが必要です。このブランチへの変更は、後述する Chart Releaser Action によって自動的に作成されます。ただし、事前に `gh-pages` ブランチを作成し、ページを訪れるユーザーに表示される `README.md` ファイルを追加することもできます。 `README.md` に chart のインストール手順を追加できます（``、``、`` を適切な値に置き換えてください）: ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` chart は次のような URL の Web サイトに公開されます: https://.github.io/helm-charts ## GitHub Actions ワークフロー `main` ブランチの `.github/workflows/release.yml` に GitHub Actions ワークフローファイルを作成します。 ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` 上記の設定では、[@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) を使用して GitHub プロジェクトをセルフホスト型の Helm chart リポジトリに変換します。main ブランチへのプッシュのたびに、プロジェクト内の各 chart をチェックします。新しい chart バージョンがある場合は、chart バージョンを名前とする GitHub release を作成し、Helm chart アーティファクトをその release に追加します。さらに、リリースに関するメタデータを含む `index.yaml` ファイルを作成または更新し、GitHub Pages でホストします。 上記の例で使用している Chart Releaser Action のバージョンは `v1.6.0` です。[最新の利用可能なバージョン](https://github.com/helm/chart-releaser-action/releases)に変更できます。 補足: Chart Releaser Action は、ほぼ常に [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) および [Kind Action](https://github.com/marketplace/actions/kind-cluster) と組み合わせて使用されます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Chart リポジトリの同期 description: ローカルとリモートの chart リポジトリを同期する方法について説明します。 sidebar_position: 2 --- *注: この例は、chart リポジトリとして機能する Google Cloud Storage（GCS）バケット専用です。* ## 前提条件 * [gsutil](https://cloud.google.com/storage/docs/gsutil) ツールをインストールします。*gsutil rsync 機能を多用します* * Helm バイナリにアクセスできることを確認します * _オプション: 誤ってデータを削除した場合に備えて、GCS バケットで[オブジェクトのバージョニング](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)を設定することを推奨します。_ ## ローカル chart リポジトリディレクトリのセットアップ [chart リポジトリガイド](/topics/chart_repository.md)で説明したように、ローカルディレクトリを作成し、パッケージ化された chart をそのディレクトリに配置します。 例: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## 更新された index.yaml の生成 Helm を使用して、ディレクトリパスとリモートリポジトリの URL を `helm repo index` コマンドに渡し、更新された index.yaml ファイルを生成します。 ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` このコマンドは更新された index.yaml ファイルを生成し、`fantastic-charts/` ディレクトリに配置します。 ## ローカルとリモートの chart リポジトリを同期する `scripts/sync-repo.sh` を実行してディレクトリの内容を GCS バケットにアップロードします。ローカルディレクトリ名と GCS バケット名を引数として渡します。 例: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## chart リポジトリの更新 chart リポジトリの内容のローカルコピーを保持することを推奨します。また、`gsutil rsync` を使用してリモート chart リポジトリの内容をローカルディレクトリにコピーすることもできます。 例: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` 参考リンク: * [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) ドキュメント * [Chart リポジトリガイド](/topics/chart_repository.md) * Google Cloud Storage の[オブジェクトのバージョニングと同時実行制御](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)ドキュメント ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Chart 開発のヒントとコツ description: Helm chart 開発者がプロダクション品質の chart を構築する際に学んだヒントとコツを紹介します。 sidebar_position: 1 --- このガイドでは、Helm chart 開発者がプロダクション品質の chart を構築する際に学んだヒントとコツを紹介します。 ## テンプレート関数を知る Helm はリソースファイルのテンプレート化に [Go テンプレート](https://godoc.org/text/template)を使用します。Go にはいくつかの組み込み関数がありますが、Helm ではさらに多くの関数を追加しています。 まず、[Sprig ライブラリ](https://masterminds.github.io/sprig/)のすべての関数を追加しました。ただし、セキュリティ上の理由から `env` と `expandenv` は除外されています。 また、`include` と `required` という 2 つの特別なテンプレート関数も追加しました。`include` 関数を使用すると、別のテンプレートを取り込んで、その結果を他のテンプレート関数に渡すことができます。 たとえば、次のテンプレートスニペットは `mytpl` というテンプレートを取り込み、その結果を小文字に変換し、二重引用符で囲みます。 ```yaml value: {{ include "mytpl" . | lower | quote }} ``` `required` 関数を使用すると、テンプレートのレンダリングに必要な特定の values エントリを宣言できます。値が空の場合、テンプレートのレンダリングはユーザーが指定したエラーメッセージとともに失敗します。 次の `required` 関数の例では、`.Values.who` エントリが必須であることを宣言し、そのエントリがない場合にエラーメッセージを表示します。 ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## 文字列は引用符で囲み、整数は囲まない 文字列データを扱う場合は、そのまま記述するよりも引用符で囲む方が安全です。 ```yaml name: {{ .Values.MyName | quote }} ``` ただし、整数を扱う場合は _値を引用符で囲まないでください_。多くの場合、Kubernetes 内でパースエラーを引き起こす可能性があります。 ```yaml port: {{ .Values.Port }} ``` この注意点は、整数を表す場合でも文字列として期待される環境変数の値には適用されません。 ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## 'include' 関数の使用 Go には、組み込みの `template` ディレクティブを使用して、あるテンプレートを別のテンプレートに含める方法があります。しかし、この組み込み関数は Go テンプレートのパイプラインでは使用できません。 テンプレートを含め、その出力に対して操作を行えるようにするため、Helm には特別な `include` 関数があります。 ``` {{ include "toYaml" $value | indent 2 }} ``` 上記では `toYaml` というテンプレートを含め、それに `$value` を渡し、そのテンプレートの出力を `indent` 関数に渡しています。 YAML ではインデントレベルと空白が意味を持つため、これはコードスニペットを含めつつ、適切なコンテキストでインデントを処理する優れた方法です。 ## 'required' 関数の使用 Go には、マップに存在しないキーでインデックス付けされた場合の動作を制御するためのテンプレートオプションを設定する方法があります。通常、これは `template.Options("missingkey=option")` で設定し、`option` には `default`、`zero`、または `error` を指定できます。このオプションを error に設定するとエラーで実行が停止しますが、これはマップ内のすべての欠落キーに適用されます。chart 開発者が `values.yaml` ファイル内の選択した値に対してのみこの動作を強制したい場合があるかもしれません。 `required` 関数は、テンプレートのレンダリングに必要な値エントリを宣言する機能を開発者に提供します。`values.yaml` でそのエントリが空の場合、テンプレートはレンダリングされず、開発者が指定したエラーメッセージを返します。 例: ``` {{ required "A valid foo is required!" .Values.foo }} ``` 上記では、`.Values.foo` が定義されている場合はテンプレートをレンダリングしますが、`.Values.foo` が未定義の場合はレンダリングに失敗して終了します。 ## 'tpl' 関数の使用 `tpl` 関数を使用すると、開発者はテンプレート内で文字列をテンプレートとして評価できます。これは、テンプレート文字列を値として chart に渡したり、外部設定ファイルをレンダリングしたりする場合に便利です。構文: `{{ tpl TEMPLATE_STRING VALUES }}` 例: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` 外部設定ファイルのレンダリング: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## イメージプル Secret の作成 イメージプル Secret は、基本的に _registry_、_username_、_password_ の組み合わせです。デプロイするアプリケーションで必要になる場合がありますが、作成するには `base64` を数回実行する必要があります。Secret のペイロードとして使用する Docker 設定ファイルを構成するヘルパーテンプレートを作成できます。以下に例を示します。 まず、`values.yaml` ファイルで認証情報が次のように定義されていると仮定します。 ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` 次に、ヘルパーテンプレートを以下のように定義します。 ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` 最後に、より大きなテンプレート内でヘルパーテンプレートを使用して Secret マニフェストを作成します。 ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Deployment の自動ロール ConfigMap や Secret がコンテナ内の設定ファイルとして注入されている場合や、その他の外部依存関係の変更により Pod のローリングが必要になる場合があります。アプリケーションによっては、後続の `helm upgrade` でこれらが更新された場合に再起動が必要になることがありますが、Deployment の spec 自体が変更されていない場合、アプリケーションは古い設定のまま実行され続け、一貫性のないデプロイメントが発生します。 `sha256sum` 関数を使用すると、別のファイルが変更された場合に Deployment の annotation セクションを確実に更新できます。 ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTE: これを library chart に追加する場合、`$.Template.BasePath` でファイルにアクセスできません。代わりに、`{{ include ("mylibchart.configmap") . | sha256sum }}` のように定義を参照してください。 常に Deployment をロールさせたい場合は、上記と同様の annotation ステップを使用しますが、代わりにランダムな文字列に置き換えて常に変化させ、Deployment がロールするようにします。 ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` テンプレート関数の呼び出しごとに一意のランダム文字列が生成されます。つまり、複数のリソースで使用するランダム文字列を同期させる必要がある場合、関連するすべてのリソースを同じテンプレートファイルに配置する必要があります。 これらの方法はどちらも、Deployment に組み込まれた更新戦略ロジックを活用し、ダウンタイムを回避できます。 NOTE: 以前は別のオプションとして `--recreate-pods` フラグの使用を推奨していました。このフラグは Helm 3 で非推奨となり、上記のより宣言的な方法が推奨されています。 ## リソースをアンインストールしないように Helm に指示する Helm が `helm uninstall` を実行する際にアンインストールすべきでないリソースが存在する場合があります。chart 開発者は、リソースに annotation を追加して、アンインストールされないようにすることができます。 ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` annotation `helm.sh/resource-policy: keep` は、Helm の操作（`helm uninstall`、`helm upgrade`、`helm rollback` など）によってこのリソースが削除される場合に、削除をスキップするよう Helm に指示します。_ただし_、このリソースは孤立した状態になります。Helm はこのリソースをいかなる方法でも管理しなくなります。これは、既にアンインストールされているがリソースを保持している release に対して `helm install --replace` を使用する場合に問題を引き起こす可能性があります。 ## 「Partials」とテンプレートのインクルードの使用 chart 内でブロックやテンプレートの部分的なパーツなど、再利用可能なパーツを作成したい場合があります。多くの場合、これらを独自のファイルに保持する方が整理しやすくなります。 `templates/` ディレクトリでは、アンダースコア（`_`）で始まるファイルは Kubernetes マニフェストファイルを出力しないものと見なされます。そのため、慣例としてヘルパーテンプレートや Partials は `_helpers.tpl` ファイルに配置されます。 ## 多くの依存関係を持つ複雑な Chart CNCF の [Artifact Hub](https://artifacthub.io/packages/search?kind=0) にある多くの chart は、より高度なアプリケーションを作成するための「ビルディングブロック」です。ただし、chart は大規模なアプリケーションのインスタンスを作成するために使用されることもあります。そのような場合、単一のアンブレラ chart が複数のサブチャートを持ち、それぞれが全体の一部として機能することがあります。 個別のパーツから複雑なアプリケーションを構成するための現在のベストプラクティスは、グローバル設定を公開するトップレベルのアンブレラ chart を作成し、`charts/` サブディレクトリを使用して各コンポーネントを埋め込むことです。 ## YAML は JSON のスーパーセット YAML 仕様によると、YAML は JSON のスーパーセットです。つまり、有効な JSON 構造はすべて YAML でも有効です。 これには利点があります。テンプレート開発者は、YAML の空白の扱いに対処するよりも、JSON ライクな構文でデータ構造を表現する方が簡単だと感じることがあります。 ベストプラクティスとして、JSON 構文がフォーマットの問題のリスクを大幅に軽減する場合を _除き_、テンプレートは YAML ライクな構文に従うべきです。 ## ランダム値の生成に注意する Helm にはランダムデータや暗号鍵などを生成する関数があります。これらを使用することは問題ありません。ただし、アップグレード中にテンプレートが再実行されることに注意してください。テンプレートの実行で前回の実行と異なるデータが生成されると、そのリソースの更新がトリガーされます。 ## 1 つのコマンドで release をインストールまたはアップグレード Helm では、インストールまたはアップグレードを単一のコマンドで実行できます。`helm upgrade` に `--install` オプションを付けて使用してください。これにより、Helm は release が既にインストールされているかどうかを確認します。インストールされていない場合はインストールを実行し、インストールされている場合は既存の release をアップグレードします。 ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: How-to sidebar_position: 2 --- # How-to ガイド ここでは、「どうすればよいですか？」といった種類の質問に対する短い回答を示します。 これらの How-to ガイドでは、トピックについて詳しく説明していません。 そのトピックは[トピックガイド](/topics/index.mdx)に記載されています。 ただし、これらのガイドは、一般的なタスクをすばやく実行するのに役立ちます。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "ドキュメントホーム" description: "ドキュメントの構成について知っておく必要のあるすべて。" --- # ようこそ [Helm](https://helm.sh/) ドキュメントへようこそ。Helm は Kubernetes の パッケージマネージャーであり、[CNCF Helm プロジェクトジャーニーレポート](https://www.cncf.io/cncf-helm-project-journey/)で 詳細な背景情報を読むことができます。 # ドキュメントの構成 Helm には多くのドキュメントがあります。それがどのように編成されているかについての ハイレベルの概要は、特定のものを探す場所を知るのに役立ちます。 - [チュートリアル](/intro/index.mdx) では、最初の Helm チャートを作成するための一連の手順を１つずつ説明します。 Helm を初めて使用する場合は、ここから始めてください。 - [トピックガイド](/topics/index.mdx) では、主要なトピックと概念についてかなり高いレベルで説明し、 役立つ背景情報と説明を提供します。 - [コミュニティガイド](/community) は、Helm のコミュニティを中心としたトピックについて話し合っています。 Helm 自体の開発プロセスと貢献方法について詳しく知りたい場合は、 ここから始めてください。 - [How-to ガイド](/howto/index.mdx) はレシピです。 これらは、主要な問題とユースケースへの対処に関連する手順を案内します。 これらはチュートリアルよりも高度で、Helm の動作に関するある程度の知識があることを前提としています。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: チートシート description: Helm チートシート sidebar_position: 4 --- このチートシートでは、Helm でアプリケーションを管理するために必要なコマンドをまとめています。 ----------------------------------------------------------------------------------------------------------------------------------------------- ### 基本的な用語と解釈 Chart: - `helm pull` でダウンロードして展開した chart の場合は、そのディレクトリ名を指します。 - リポジトリを追加済みだが chart を pull していない場合は、`<リポジトリ名>/` の形式で指定します。 - chart への URL または絶対パスでも指定できます。 Name: - インストール時に chart に付ける名前です。 Release: - Helm によるインストールインスタンスを指します。 Revision: - `helm history` コマンドで表示されるリビジョン番号です。 Repo-name: - リポジトリの名前です。 DIR: - ディレクトリ名またはパスです。 ------------------------------------------------------------------------------------------------------------------------------------------------ ### Chart の管理 ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart's dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### アプリケーションのインストールとアンインストール ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### アプリケーションのアップグレードとロールバック ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### リポジトリの一覧表示、追加、削除、更新 ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm release の監視 ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### release 情報のダウンロード ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### プラグイン管理 ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: 概要 sidebar_position: 1 --- # Helm の概要 Helm は初めてですか？ これが出発点です！ import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Helm のインストール description: Helm をインストールして実行する方法を学びます。 sidebar_position: 2 --- このガイドでは、Helm CLI のインストール方法を説明します。Helm はソースから、またはビルド済みのバイナリリリースからインストールできます。 ## Helm プロジェクトから Helm プロジェクトは、Helm を取得してインストールするための 2 つの公式の方法を提供しています。これに加えて、Helm コミュニティがさまざまなパッケージマネージャーを通じたインストール方法を提供しており、それらは公式の方法の後で説明します。 ### バイナリリリースから Helm のすべての[リリース](https://github.com/helm/helm/releases)は、さまざまな OS 向けのバイナリを提供しています。これらのバイナリは手動でダウンロードしてインストールできます。 1. [任意のバージョン](https://github.com/helm/helm/releases)をダウンロードします 2. 展開します（`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`） 3. 展開したディレクトリ内の `helm` バイナリを目的の場所に移動します（`mv linux-amd64/helm /usr/local/bin/helm`） これでクライアントを実行し、[chart リポジトリを初期化](/intro/quickstart.md#initialize-a-helm-chart-repository)できます。`helm help` を実行して確認してください。 **注:** Helm の自動テストは、GitHub Actions のビルドおよびリリース時に Linux AMD64 に対してのみ実行されます。他の OS のテストは、その OS 向けの Helm を必要とするコミュニティの責任で行われます。 ### スクリプトから Helm には、最新バージョンの Helm を自動的に取得して[ローカルにインストールする](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)インストーラースクリプトがあります。 このスクリプトを取得し、ローカルで実行できます。十分にドキュメント化されているため、実行前に内容を確認できます。 ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` 手軽に済ませたい場合は、`curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` も使用できます。 ## パッケージマネージャー経由 Helm コミュニティは、オペレーティングシステムのパッケージマネージャーを通じて Helm をインストールする方法を提供しています。これらは Helm プロジェクトによるサポート対象ではなく、信頼されたサードパーティとは見なされません。 ### Homebrew から（macOS） Helm コミュニティのメンバーが Homebrew に Helm フォーミュラを提供しています。このフォーミュラは一般的に最新の状態に保たれています。 ```console brew install helm ``` （注：emacs-helm という別のプロジェクトのフォーミュラも存在します。） ### Chocolatey から（Windows） Helm コミュニティのメンバーが [Chocolatey](https://chocolatey.org/) に [Helm パッケージ](https://chocolatey.org/packages/kubernetes-helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。 ```console choco install kubernetes-helm ``` ### Scoop から（Windows） Helm コミュニティのメンバーが [Scoop](https://scoop.sh) に [Helm パッケージ](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json)を提供しています。このパッケージは一般的に最新の状態に保たれています。 ```console scoop install helm ``` ### Winget から（Windows） Helm コミュニティのメンバーが [Winget](https://learn.microsoft.com/en-us/windows/package-manager/) に [Helm パッケージ](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。 ```console winget install Helm.Helm ``` ### Apt から（Debian/Ubuntu） Helm コミュニティのメンバーが Debian/Ubuntu 向けに Apt パッケージを提供しています。このパッケージは一般的に最新の状態に保たれています。リポジトリをホスティングしている [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) に感謝します。 ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### dnf/yum から（Fedora） Fedora 35 以降、Helm は公式リポジトリから利用可能です。次のコマンドでインストールできます。 ```console sudo dnf install helm ``` ### Snap から [Snapcrafters](https://github.com/snapcrafters) コミュニティが [Helm パッケージ](https://snapcraft.io/helm)の Snap バージョンをメンテナンスしています。 ```console sudo snap install helm --classic ``` ### pkg から（FreeBSD） FreeBSD コミュニティのメンバーが [FreeBSD Ports Collection](https://man.freebsd.org/ports) に [Helm パッケージ](https://www.freshports.org/sysutils/helm)を提供しています。このパッケージは一般的に最新の状態に保たれています。 ```console pkg install helm ``` ### 開発ビルド リリースバージョンに加えて、Helm の開発スナップショットをダウンロードまたはインストールできます。 ### Canary ビルドから 「Canary」ビルドは、最新の `main` ブランチからビルドされた Helm のバージョンです。これらは公式リリースではなく、安定していない可能性があります。ただし、最新機能をテストする機会を提供します。 Canary Helm バイナリは `get.helm.sh` にあります。一般的なビルドへのリンクは次のとおりです。 - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### ソースから（Linux、macOS） ソースから Helm をビルドするには多少の手間がかかりますが、最新の（プレリリース）Helm バージョンをテストする場合には最適な方法です。 動作する Go 環境が必要です。 ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` 必要に応じて依存関係を取得してキャッシュし、設定を検証します。その後、`helm` をコンパイルして `bin/helm` に配置します。 ## まとめ ほとんどの場合、インストールはビルド済みの `helm` バイナリを取得するだけで完了します。このドキュメントでは、Helm でより高度なことを行いたい方向けの追加オプションについて説明しました。 Helm クライアントのインストールが完了したら、Helm を使用して chart を管理し、[chart リポジトリを初期化](/intro/quickstart.md#initialize-a-helm-chart-repository)できます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: クイックスタートガイド description: Helm をインストールして使い始めるためのガイドです。 sidebar_position: 1 --- このガイドでは、Helm をすぐに使い始める方法を説明します。 ## 前提条件 Helm を正しく安全に使用するには、以下の前提条件が必要です。 1. Kubernetes クラスター 2. インストールに適用するセキュリティ構成の決定（必要な場合） 3. Helm のインストールと設定 ### Kubernetes をインストールするか、クラスターにアクセスする - Kubernetes がインストールされている必要があります。Helm の最新リリースには、Kubernetes の最新の安定リリースを推奨します。ほとんどの場合、これは2番目に新しいマイナーリリースです。 - ローカルに設定された `kubectl` も必要です。 Helm と Kubernetes 間でサポートされる最大バージョン差については、[Helm バージョンサポートポリシー](https://helm.sh/docs/topics/version_skew/)を参照してください。 ## Helm のインストール Helm クライアントのバイナリリリースをダウンロードします。`homebrew` などのツールを使用するか、[公式リリースページ](https://github.com/helm/helm/releases)を参照してください。 詳細やその他のオプションについては、[インストールガイド](/intro/install.md)を参照してください。 ## Helm chart リポジトリを初期化する {#initialize-a-helm-chart-repository} Helm の準備ができたら、chart リポジトリを追加できます。利用可能な Helm chart リポジトリについては、[Artifact Hub](https://artifacthub.io/packages/search?kind=0) を確認してください。 ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` リポジトリを追加すると、インストールできる chart を一覧表示できます。 ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## サンプル chart をインストールする chart をインストールするには、`helm install` コマンドを実行します。Helm には chart を見つけてインストールする方法がいくつかありますが、最も簡単なのは `bitnami` chart を使用する方法です。 ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` 上記の例では、`bitnami/mysql` chart がリリースされ、新しい release の名前は `mysql-1612624192` です。 `helm show chart bitnami/mysql` を実行すると、この MySQL chart の機能の概要を確認できます。`helm show all bitnami/mysql` を実行すると、chart に関するすべての情報を取得できます。 chart をインストールするたびに、新しい release が作成されます。そのため、1つの chart を同じクラスターに複数回インストールできます。各 release は個別に管理およびアップグレードできます。 `helm install` コマンドは多くの機能を備えた強力なコマンドです。詳細については、[Helm の使い方ガイド](/intro/using_helm.md)を参照してください。 ## release について学ぶ Helm を使用してリリースした内容は簡単に確認できます。 ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` `helm list`（または `helm ls`）を実行すると、デプロイ済みのすべての release の一覧が表示されます。 ## release をアンインストールする release をアンインストールするには、`helm uninstall` コマンドを使用します。 ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` これにより、Kubernetes から `mysql-1612624192` がアンインストールされ、release に関連するすべてのリソースと release 履歴が削除されます。 `--keep-history` フラグを指定すると、release 履歴が保持されます。その release に関する情報を取得できます。 ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Helm はアンインストール後も release を追跡するため、クラスターの履歴を監査したり、`helm rollback` で release を復元したりできます。 ## ヘルプテキストを読む 利用可能な Helm コマンドの詳細については、`helm help` を使用するか、コマンドに `-h` フラグを付けて実行してください。 ```console $ helm get -h ``` ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Helm の使い方 description: Helm の基本について説明します。 sidebar_position: 3 --- このガイドでは、Helm を使用して Kubernetes クラスター上のパッケージを管理する基本について説明します。Helm クライアントが既に[インストール済み](/intro/install.md)であることを前提としています。 コマンドをいくつか素早く試したい場合は、[クイックスタートガイド](/intro/quickstart.md)から始めてください。この章では Helm コマンドの詳細を説明し、Helm の使用方法を解説します。 ## 3つの重要な概念 *chart* は Helm パッケージです。Kubernetes クラスター内でアプリケーション、ツール、またはサービスを実行するために必要なすべてのリソース定義が含まれています。Homebrew の formula、Apt の dpkg、Yum の RPM ファイルに相当する Kubernetes 版と考えてください。 *repository* は chart を収集して共有できる場所です。Perl の [CPAN アーカイブ](https://www.cpan.org)や [Fedora Package Database](https://src.fedoraproject.org/) に似ていますが、Kubernetes パッケージを対象としています。 *release* は Kubernetes クラスターで実行されている chart のインスタンスです。1つの chart を同じクラスターに何度もインストールできます。インストールするたびに新しい _release_ が作成されます。たとえば MySQL chart を考えてみます。クラスターで2つのデータベースを実行したい場合、その chart を2回インストールできます。それぞれに独自の _release_ があり、独自の _release 名_ が付けられます。 これらの概念を踏まえると、Helm を次のように説明できます。 Helm は _chart_ を Kubernetes にインストールし、インストールごとに新しい _release_ を作成します。新しい chart を見つけるには、Helm chart _repository_ を検索します。 ## 'helm search': chart を見つける Helm には強力な検索コマンドがあります。2種類のソースを検索できます。 - `helm search hub` は [Artifact Hub](https://artifacthub.io) を検索します。Artifact Hub には多数のリポジトリから Helm chart が集められています。 - `helm search repo` は (`helm repo add` で) ローカルの Helm クライアントに追加したリポジトリを検索します。この検索はローカルデータに対して行われるため、パブリックネットワーク接続は不要です。 `helm search hub` を実行すると、公開されている chart を見つけることができます。 ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` 上記は Artifact Hub 上のすべての `wordpress` chart を検索しています。 フィルターを指定しない場合、`helm search hub` は利用可能なすべての chart を表示します。 `helm search hub` は [artifacthub.io](https://artifacthub.io/) 上の URL を表示しますが、実際の Helm リポジトリは表示しません。`helm search hub --list-repo-url` を使用すると、実際の Helm リポジトリ URL が表示されます。これは新しいリポジトリを追加する際に便利です: `helm repo add [NAME] [URL]`。 `helm search repo` を使用すると、既に追加したリポジトリ内の chart 名を検索できます。 ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm の検索はあいまい文字列マッチングアルゴリズムを使用するため、単語やフレーズの一部を入力できます。 ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` 検索は利用可能なパッケージを見つける良い方法です。インストールしたいパッケージが見つかったら、`helm install` でインストールできます。 ## 'helm install': パッケージをインストールする 新しいパッケージをインストールするには、`helm install` コマンドを使用します。最もシンプルな形式では、2つの引数を取ります。任意の release 名と、インストールする chart の名前です。 ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` これで `wordpress` chart がインストールされました。chart をインストールすると新しい _release_ オブジェクトが作成されます。上記の release は `happy-panda` という名前です。(Helm に名前を自動生成させたい場合は、release 名を省略して `--generate-name` を使用してください。) インストール中、`helm` クライアントは作成されたリソース、release の状態、追加の設定手順など、有用な情報を出力します。 Helm は以下の順序でリソースをインストールします。 - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm はすべてのリソースが実行状態になるまで待機してから終了するわけではありません。多くの chart は 600MB を超える Docker イメージを必要とし、クラスターへのインストールに時間がかかる場合があります。 release の状態を追跡したり、設定情報を再度確認するには、`helm status` を使用します。 ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` 上記は release の現在の状態を表示しています。 ### インストール前に chart をカスタマイズする ここで説明した方法でインストールすると、その chart のデフォルト設定オプションのみが使用されます。多くの場合、好みの設定を使用するように chart をカスタマイズしたいでしょう。 chart で設定可能なオプションを確認するには、`helm show values` を使用します。 ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` YAML 形式のファイルでこれらの設定を上書きし、インストール時にそのファイルを渡すことができます。 ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` 上記は `user0` という名前のデフォルト MariaDB ユーザーを作成し、新しく作成された `user0db` データベースへのアクセスを許可しますが、その chart の他のデフォルト設定はすべてそのまま使用します。 インストール時に設定データを渡す方法は2つあります。 - `--values` (または `-f`): 上書きする値を指定した YAML ファイルを指定します。複数回指定でき、最も右のファイルが優先されます。 - `--set`: コマンドラインで上書きする値を指定します。 両方を使用した場合、`--set` の値は `--values` にマージされ、`--set` が優先されます。`--set` で指定された上書きは Secret に永続化されます。`--set` された値は `helm get values ` で特定の release について確認できます。`--set` された値は `--reset-values` を指定して `helm upgrade` を実行することでクリアできます。 #### `--set` の形式と制限 `--set` オプションは0個以上の名前/値ペアを取ります。最もシンプルな形式は `--set name=value` です。これに相当する YAML は次のとおりです。 ```yaml name: value ``` 複数の値は `,` 文字で区切ります。`--set a=b,c=d` は次のようになります。 ```yaml a: b c: d ``` より複雑な式もサポートされています。たとえば、`--set outer.inner=value` は次のように変換されます。 ```yaml outer: inner: value ``` リストは値を `{` と `}` で囲んで表現できます。たとえば、`--set name={a, b, c}` は次のように変換されます。 ```yaml name: - a - b - c ``` 特定の名前/キーを `null` または空の配列 `[]` に設定できます。たとえば、`--set name=[],a=null` は次のように変換されます。 ```yaml name: - a - b - c a: b ``` を ```yaml name: [] a: null ``` に変換します。 Helm 2.5.0 以降、配列インデックス構文を使用してリストアイテムにアクセスできます。たとえば、`--set servers[0].port=80` は次のようになります。 ```yaml servers: - port: 80 ``` この方法で複数の値を設定できます。`--set servers[0].port=80,servers[0].host=example` は次のようになります。 ```yaml servers: - port: 80 host: example ``` `--set` 行で特殊文字を使用する必要がある場合があります。バックスラッシュを使用して文字をエスケープできます。`--set name=value1\,value2` は次のようになります。 ```yaml name: "value1,value2" ``` 同様に、ドットシーケンスもエスケープできます。これは chart が `toYaml` 関数を使用してアノテーション、ラベル、ノードセレクターを解析する場合に便利です。`--set nodeSelector."kubernetes\.io/role"=master` の構文は次のようになります。 ```yaml nodeSelector: kubernetes.io/role: master ``` 深くネストされたデータ構造は `--set` で表現するのが難しい場合があります。chart の設計者は `values.yaml` ファイルの形式を設計する際に `--set` の使用を考慮することをお勧めします (詳細は [Values ファイル](/chart_template_guide/values_files.md)を参照してください)。 ### その他のインストール方法 `helm install` コマンドは複数のソースからインストールできます。 - chart repository (上記で見たとおり) - ローカルの chart アーカイブ (`helm install foo foo-0.1.1.tgz`) - 展開済みの chart ディレクトリ (`helm install foo path/to/foo`) - 完全な URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' と 'helm rollback': release のアップグレードと障害からの回復 chart の新しいバージョンがリリースされたとき、または release の設定を変更したいときは、`helm upgrade` コマンドを使用します。 アップグレードは既存の release を取得し、指定した情報に従ってアップグレードします。Kubernetes chart は大きく複雑になる可能性があるため、Helm は最も影響の少ないアップグレードを実行しようとします。前回の release 以降に変更されたものだけを更新します。 ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` 上記の場合、`happy-panda` release は同じ chart でアップグレードされますが、新しい YAML ファイルが使用されます。 ```yaml mariadb.auth.username: user1 ``` `helm get values` を使用して、新しい設定が有効になったかどうかを確認できます。 ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` `helm get` コマンドはクラスター内の release を確認するのに役立つツールです。上記のように、`panda.yaml` の新しい値がクラスターにデプロイされたことがわかります。 release 中に何か予定どおりにいかなかった場合、`helm rollback [RELEASE] [REVISION]` を使用して以前の release に簡単にロールバックできます。 ```console $ helm rollback happy-panda 1 ``` 上記は happy-panda を最初の release バージョンにロールバックします。release バージョンは増分リビジョンです。インストール、アップグレード、またはロールバックが発生するたびに、リビジョン番号が1ずつ増加します。最初のリビジョン番号は常に1です。`helm history [RELEASE]` を使用して、特定の release のリビジョン番号を確認できます。 ## install/upgrade/rollback に役立つオプション install/upgrade/rollback 時の Helm の動作をカスタマイズするために指定できる便利なオプションがいくつかあります。これは CLI フラグの完全なリストではありません。すべてのフラグの説明を見るには、`helm --help` を実行してください。 - `--timeout`: Kubernetes コマンドが完了するまで待機する [Go duration](https://golang.org/pkg/time/#ParseDuration) 値。デフォルトは `5m0s` です。 - `--wait`: すべての Pod が準備完了状態になり、PVC がバインドされ、Deployment が準備完了状態の最小 Pod 数 (`Desired` - `maxUnavailable`) を持ち、Service が IP アドレス (および `LoadBalancer` の場合は Ingress) を持つまで待機してから、release を成功とマークします。`--timeout` 値まで待機します。タイムアウトに達すると、release は `FAILED` としてマークされます。注: ローリング更新戦略の一部として Deployment の `replicas` が 1 に設定され、`maxUnavailable` が 0 に設定されていない場合、`--wait` は準備完了状態の最小 Pod 条件を満たしているため、準備完了として返します。 - `--no-hooks`: コマンドの hook の実行をスキップします。 - `--recreate-pods` (`upgrade` と `rollback` でのみ使用可能): このフラグはすべての Pod を再作成します (Deployment に属する Pod を除く)。(Helm 3 では非推奨) ## 'helm uninstall': release をアンインストールする クラスターから release をアンインストールするときは、`helm uninstall` コマンドを使用します。 ```console $ helm uninstall happy-panda ``` これにより、release がクラスターから削除されます。`helm list` コマンドで現在デプロイされているすべての release を確認できます。 ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` 上記の出力から、`happy-panda` release がアンインストールされたことがわかります。 以前のバージョンの Helm では、release が削除されると削除の記録が残りました。Helm 3 では、削除により release レコードも削除されます。削除された release のレコードを保持したい場合は、`helm uninstall --keep-history` を使用してください。`helm list --uninstalled` を使用すると、`--keep-history` フラグでアンインストールされた release のみが表示されます。 `helm list --all` フラグは、失敗したアイテムや削除されたアイテム (`--keep-history` が指定されている場合) のレコードを含む、Helm が保持しているすべての release レコードを表示します。 ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` release がデフォルトで削除されるようになったため、アンインストールされたリソースをロールバックすることはできなくなりました。 ## 'helm repo': repository を操作する Helm 3 にはデフォルトの chart repository が付属しなくなりました。`helm repo` コマンドグループは、repository を追加、一覧表示、削除するコマンドを提供します。 `helm repo list` で設定されている repository を確認できます。 ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` 新しい repository は `helm repo add [NAME] [URL]` で追加できます。 ```console $ helm repo add dev https://example.com/dev-charts ``` chart repository は頻繁に変更されるため、`helm repo update` を実行して Helm クライアントを最新の状態に保つことができます。 repository は `helm repo remove` で削除できます。 ## 独自の chart を作成する [Chart 開発ガイド](/topics/charts.md)で独自の chart を開発する方法を説明しています。`helm create` コマンドを使用すると、すぐに始めることができます。 ```console $ helm create deis-workflow Creating deis-workflow ``` これで `./deis-workflow` に chart ができました。編集して独自のテンプレートを作成できます。 chart を編集する際に、`helm lint` を実行してフォーマットが正しいかどうかを検証できます。 chart を配布用にパッケージ化するときは、`helm package` コマンドを実行します。 ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` そして、その chart は `helm install` で簡単にインストールできます。 ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` パッケージ化された chart は chart repository にロードできます。詳細は [Helm chart repository](/topics/chart_repository.md) のドキュメントを参照してください。 ## まとめ この章では、検索、インストール、アップグレード、アンインストールなど、`helm` クライアントの基本的な使用パターンについて説明しました。`helm status`、`helm get`、`helm repo` などの便利なユーティリティコマンドについても説明しました。 これらのコマンドの詳細については、Helm の組み込みヘルプ `helm help` を参照してください。 [次の章](/howto/charts_tips_and_tricks.md)では、chart を開発するプロセスについて説明します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: はじめに description: Helm Go SDK の概要 sidebar_position: 1 --- Helm の Go SDK を使用すると、カスタムソフトウェアから Helm chart と Helm の機能を活用して Kubernetes ソフトウェアのデプロイを管理できます（実際、Helm CLI もそのようなツールの一つです！）。 現在、SDK は Helm CLI から機能的に分離されており、独立したツールから利用できます。Helm プロジェクトは SDK の API 安定性を約束しています。ただし、CLI と SDK の分離作業で残っている未整備な部分があることに注意してください。Helm プロジェクトはこれらを時間をかけて改善していく予定です。 完全な API ドキュメントは [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3) で確認できます。 以下では、主要なパッケージの概要と簡単な使用例を紹介します。より多くの例や、より充実した機能を持つ「ドライバー」については、[サンプル](/sdk/examples.mdx)セクションを参照してください。 ## 主要パッケージの概要 - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Helm アクションを実行するためのメイン「クライアント」を含みます。CLI が内部で使用しているパッケージと同じです。別の Go プログラムから基本的な Helm コマンドを実行するだけであれば、このパッケージが適しています。 - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart)、[pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): chart の読み込みと操作に使用するメソッドとヘルパー関数 - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) およびそのサブパッケージ: 標準の Helm 環境変数のすべてのハンドラーを含み、サブパッケージには出力と values ファイルの処理が含まれています - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): `Release` オブジェクトとステータスを定義します ここで紹介したもの以外にも多くのパッケージがありますので、詳細はドキュメントを確認してください！ ### 簡単な使用例 これは Go SDK を使用して `helm list` を実行する簡単な例です。 より充実した例については、[サンプル](/sdk/examples.mdx)セクションを参照してください。 ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## 互換性 Helm SDK は Helm の後方互換性ガイドラインに明示的に従っています。 つまり、破壊的変更はメジャーバージョンの更新時にのみ行われます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: 高度な Helm テクニック description: Helm パワーユーザー向けのさまざまな高度な機能について説明します sidebar_position: 9 --- このセクションでは、Helm を使用するためのさまざまな高度な機能とテクニックについて説明します。ここで紹介する内容は、chart や release の高度なカスタマイズや操作を行いたい Helm の「パワーユーザー」を対象としています。これらの高度な機能にはそれぞれトレードオフや注意点があり、Helm の深い知識を持って慎重に使用する必要があります。言い換えれば、[ピーター・パーカーの原則](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)を心に留めておいてください。 ## ポストレンダリング ポストレンダリングは、chart インストーラーに対し、Helm がインストールする前にレンダリング済みマニフェストを手動で操作、設定、または検証する機能を提供します。これにより、高度な設定ニーズを持つユーザーは、パブリック chart をフォークしたり、chart メンテナーがソフトウェアのすべての設定オプションを指定したりする必要なく、[`kustomize`](https://kustomize.io) などのツールを使用して設定変更を適用できます。また、エンタープライズ環境で共通ツールやサイドカーを注入したり、デプロイ前にマニフェストを分析したりするユースケースもあります。 ### 前提条件 - Helm 3.1 以上 ### 使用方法 ポストレンダラーは、STDIN でレンダリングされた Kubernetes マニフェストを受け取り、STDOUT で有効な Kubernetes マニフェストを返す任意の実行可能ファイルです。失敗した場合は、0 以外の終了コードを返す必要があります。これが 2 つのコンポーネント間の唯一の「API」です。これにより、ポストレンダリング処理で実行できる操作に大きな柔軟性がもたらされます。 ポストレンダラーは `install`、`upgrade`、`template` で使用できます。ポストレンダラーを使用するには、使用したいレンダラー実行可能ファイルへのパスを `--post-renderer` フラグで指定します。 ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` パスにセパレータが含まれていない場合は $PATH から検索されます。それ以外の場合は、相対パスが絶対パスに解決されます。 複数のポストレンダラーを使用したい場合は、スクリプト内ですべて呼び出すか、ビルドしたバイナリツールで一緒に呼び出します。bash では、`renderer1 | renderer2 | renderer3` のように簡単に記述できます。 `kustomize` をポストレンダラーとして使用する例は[こちら](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)で確認できます。 ### 注意事項 ポストレンダラーを使用する際には、いくつかの重要な点に注意してください。最も重要なのは、ポストレンダラーを使用する場合、その release を変更するすべてのユーザーが再現可能なビルドを実現するために**同じレンダラーを使用しなければならない**ということです。この機能は、ユーザーが使用するレンダラーを切り替えたり、レンダラーの使用を停止したりできるように意図的に構築されていますが、偶発的な変更やデータ損失を避けるために慎重に行う必要があります。 もう一つの重要な注意点はセキュリティに関するものです。ポストレンダラーを使用する場合は、他の実行可能ファイルと同様に、信頼できるソースからのものであることを確認してください。信頼できない、または検証されていないレンダラーの使用は推奨しません。レンダリングされたテンプレートへの完全なアクセス権があり、機密データが含まれている可能性があるためです。 ### カスタムポストレンダラー ポストレンダリングステップは、Go SDK で使用するとさらに柔軟性が高まります。ポストレンダラーは、以下の Go インターフェースを実装するだけで済みます。 ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Go SDK の使用方法の詳細については、[Go SDK セクション](#go-sdk)を参照してください。 ## Go SDK Helm 3 では、Helm を活用したソフトウェアやツールを構築する際の体験を向上させるため、完全に再構築された Go SDK が導入されました。詳細なドキュメントは [Go SDK セクション](/sdk/gosdk.md)を参照してください。 ## ストレージバックエンド {#storage-backends} Helm 3 では、デフォルトの release 情報ストレージが release の namespace 内の Secret に変更されました。Helm 2 では、デフォルトで release 情報を Tiller インスタンスの namespace 内の ConfigMap として保存していました。以下のサブセクションでは、異なるバックエンドの設定方法を示します。この設定は環境変数 `HELM_DRIVER` に基づいています。`[configmap, secret, sql]` のいずれかの値を設定できます。 ### ConfigMap ストレージバックエンド ConfigMap バックエンドを有効にするには、環境変数 `HELM_DRIVER` を `configmap` に設定する必要があります。 シェルで次のように設定できます。 ```shell export HELM_DRIVER=configmap ``` デフォルトのバックエンドから ConfigMap バックエンドに切り替える場合は、自分でマイグレーションを行う必要があります。release 情報は以下のコマンドで取得できます。 ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **本番環境に関する注意**: release 情報には chart や values ファイルの内容が含まれているため、不正アクセスから保護する必要がある機密データ（パスワード、秘密鍵、その他の認証情報など）が含まれている可能性があります。[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) などで Kubernetes の認可を管理する場合、Secret リソースへのアクセスを制限しつつ、ConfigMap リソースへのより広いアクセスを許可できます。たとえば、デフォルトの[ユーザー向けロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)「view」は、ほとんどのリソースへのアクセスを許可しますが、Secret へのアクセスは許可しません。さらに、Secret データは[暗号化ストレージ](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)を設定できます。ConfigMap バックエンドに切り替える場合は、アプリケーションの機密データが公開される可能性があることに注意してください。 ### SQL ストレージバックエンド release 情報を SQL データベースに保存する ***ベータ版*** の SQL ストレージバックエンドがあります。 このストレージバックエンドは、release 情報が 1MB を超える場合に特に便利です（Kubernetes の基盤となる etcd キーバリューストアの内部制限により、ConfigMap や Secret には保存できないため）。 SQL バックエンドを有効にするには、SQL データベースをデプロイし、環境変数 `HELM_DRIVER` を `sql` に設定する必要があります。データベースの詳細は環境変数 `HELM_DRIVER_SQL_CONNECTION_STRING` で設定します。 シェルで次のように設定できます。 ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > 注意: 現時点では PostgreSQL のみがサポートされています。 **本番環境に関する注意**: 以下を推奨します。 - データベースを本番環境向けに準備すること。PostgreSQL の場合は、[Server Administration](https://www.postgresql.org/docs/12/admin.html) ドキュメントを参照してください - release 情報に対して Kubernetes の RBAC をミラーリングするために[権限管理](/topics/permissions_sql_storage_backend.md)を有効にすること デフォルトのバックエンドから SQL バックエンドに切り替える場合は、自分でマイグレーションを行う必要があります。release 情報は以下のコマンドで取得できます。 ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Helm アーキテクチャ description: Helm アーキテクチャの概要を説明します。 sidebar_position: 8 --- # Helm アーキテクチャ このドキュメントでは、Helm アーキテクチャの概要を説明します。 ## Helm の目的 Helm は _chart_ と呼ばれる Kubernetes パッケージを管理するツールです。Helm では以下のことができます。 - 新しい chart をゼロから作成する - chart を chart アーカイブ（tgz）ファイルにパッケージ化する - chart が保存されている chart リポジトリと連携する - 既存の Kubernetes クラスターに chart をインストール・アンインストールする - Helm でインストールした chart の release サイクルを管理する Helm には 3 つの重要な概念があります。 1. _chart_ は、Kubernetes アプリケーションのインスタンスを作成するために必要な情報をまとめたものです。 2. _config_ は、パッケージ化された chart にマージしてリリース可能なオブジェクトを作成するための設定情報です。 3. _release_ は、特定の _config_ と組み合わせた _chart_ の実行中のインスタンスです。 ## コンポーネント Helm は 2 つの部分で構成される実行可能ファイルです。 **Helm クライアント**は、エンドユーザー向けのコマンドラインクライアントです。クライアントは以下を担当します。 - ローカルでの chart 開発 - リポジトリの管理 - release の管理 - Helm ライブラリとの連携 - インストールする chart の送信 - 既存 release のアップグレードまたはアンインストールのリクエスト **Helm ライブラリ**は、すべての Helm 操作を実行するロジックを提供します。Kubernetes API サーバーと連携し、以下の機能を提供します。 - chart と config を組み合わせて release を構築する - chart を Kubernetes にインストールし、release オブジェクトを提供する - Kubernetes と連携して chart のアップグレードとアンインストールを行う スタンドアロンの Helm ライブラリは Helm のロジックをカプセル化しており、さまざまなクライアントから利用できます。 ## 実装 Helm クライアントとライブラリは Go プログラミング言語で記述されています。 ライブラリは Kubernetes クライアントライブラリを使用して Kubernetes と通信します。現在、このライブラリは REST+JSON を使用しています。情報は Kubernetes 内の Secret に保存されます。独自のデータベースは必要ありません。 設定ファイルは、可能な限り YAML で記述されます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Chart リポジトリガイド description: Helm chart リポジトリの作成と操作方法について説明します。 sidebar_position: 6 --- このセクションでは、Helm chart リポジトリの作成と操作方法について説明します。chart リポジトリとは、パッケージ化された chart を保存・共有するための場所です。 分散型のコミュニティ Helm chart リポジトリは [Artifact Hub](https://artifacthub.io/packages/search?kind=0) にあり、参加を歓迎しています。Helm では独自の chart リポジトリを作成・運用することも可能です。このガイドではその方法を説明します。chart リポジトリの作成を検討している場合は、[OCI レジストリ](/topics/registries.md)の使用も検討してください。 ## 前提条件 * [クイックスタート](/intro/quickstart.md)ガイドを完了してください * [Chart](/topics/charts.md) ドキュメントを読んでください ## Chart リポジトリの作成 _chart リポジトリ_ は、`index.yaml` ファイルと、任意でいくつかのパッケージ化された chart をホストする HTTP サーバーです。chart を共有する準備ができたら、chart リポジトリにアップロードするのが推奨される方法です。 Helm 2.2.0 以降、リポジトリへのクライアント側 SSL 認証がサポートされています。その他の認証プロトコルはプラグインとして利用できる場合があります。 chart リポジトリは YAML ファイルと tar ファイルを提供し、GET リクエストに応答できる任意の HTTP サーバーで構成できるため、独自の chart リポジトリをホストする方法には多くの選択肢があります。たとえば、Google Cloud Storage（GCS）バケット、Amazon S3 バケット、GitHub Pages を使用したり、独自の Web サーバーを作成したりできます。 ### Chart リポジトリの構造 chart リポジトリは、パッケージ化された chart と、リポジトリ内のすべての chart のインデックスを含む `index.yaml` という特別なファイルで構成されます。`index.yaml` が記述する chart は、同じサーバー上にホストされていることが多く、[来歴ファイル](/topics/provenance.md)も同様です。 たとえば、リポジトリ `https://example.com/charts` のレイアウトは以下のようになります: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` この場合、インデックスファイルには Alpine という 1 つの chart に関する情報が含まれ、その chart のダウンロード URL `https://example.com/charts/alpine-0.1.2.tgz` を提供します。 chart パッケージが `index.yaml` ファイルと同じサーバーに配置されている必要はありませんが、そうすることが最も簡単な場合が多いです。 ### インデックスファイル インデックスファイルは `index.yaml` という名前の YAML ファイルです。chart の `Chart.yaml` ファイルの内容を含むパッケージに関するメタデータが含まれます。有効な chart リポジトリにはインデックスファイルが必要です。インデックスファイルには、chart リポジトリ内の各 chart に関する情報が含まれます。`helm repo index` コマンドは、パッケージ化された chart を含むローカルディレクトリに基づいてインデックスファイルを生成します。 以下はインデックスファイルの例です: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Chart リポジトリのホスティング このセクションでは、chart リポジトリを提供するいくつかの方法を紹介します。 ### Google Cloud Storage 最初のステップは、**GCS バケットを作成する**ことです。ここでは `fantastic-charts` という名前にします。 ![GCS バケットを作成する](/img/helm2/create-a-bucket.png) 次に、**バケットの権限を編集**してバケットを公開します。 ![権限を編集](/img/helm2/edit-permissions.png) この行を追加して、**バケットを公開**します: ![バケットを公開する](/img/helm2/make-bucket-public.png) これで、chart を配信するための空の GCS バケットの準備が整いました。 Google Cloud Storage コマンドラインツールまたは GCS Web UI を使用して chart リポジトリをアップロードできます。公開 GCS バケットには、次のアドレスでシンプルな HTTPS 経由でアクセスできます: `https://bucket-name.storage.googleapis.com/` ### Cloudsmith Cloudsmith を使用して chart リポジトリをセットアップすることもできます。Cloudsmith での chart リポジトリについては、[こちら](https://help.cloudsmith.io/docs/helm-chart-repository)を参照してください。 ### JFrog Artifactory 同様に、JFrog Artifactory を使用して chart リポジトリをセットアップすることもできます。JFrog Artifactory での chart リポジトリについては、[こちら](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)を参照してください。 ### GitHub Pages の例 同様の方法で、GitHub Pages を使用して chart リポジトリを作成できます。 GitHub では、2 つの異なる方法で静的 Web ページを提供できます: - プロジェクトの `docs/` ディレクトリの内容を提供するように設定する - プロジェクトの特定のブランチを提供するように設定する ここでは 2 番目のアプローチを使用しますが、1 番目も同様に簡単です。 最初のステップは、**gh-pages ブランチを作成する**ことです。ローカルで以下のように実行できます: ```console $ git checkout -b gh-pages ``` または、GitHub リポジトリの **Branch** ボタンを使用して Web ブラウザ経由で作成できます: ![GitHub Pages ブランチを作成する](/img/helm2/create-a-gh-page-button.png) 次に、**gh-pages ブランチ** が GitHub Pages として設定されていることを確認します。リポジトリの **Settings** をクリックし、**GitHub pages** セクションまでスクロールして、以下のように設定します: ![GitHub Pages ブランチを作成する](/img/helm2/set-a-gh-page.png) デフォルトでは **Source** は通常 **gh-pages branch** に設定されます。デフォルトで設定されていない場合は、選択してください。 必要に応じて、**カスタムドメイン**を使用することもできます。 また、**Enforce HTTPS** がチェックされていることを確認してください。これにより、chart が提供される際に **HTTPS** が使用されます。 このセットアップでは、デフォルトブランチを chart のコード保存に使用し、**gh-pages ブランチ**を chart リポジトリとして使用できます。例: `https://USERNAME.github.io/REPONAME`。デモンストレーション用の [TS Charts](https://github.com/technosophos/tscharts) リポジトリは `https://technosophos.github.io/tscharts/` でアクセスできます。 GitHub Pages を使用して chart リポジトリをホストする場合は、[Chart Releaser Action](/howto/chart_releaser_action.md) を確認してください。Chart Releaser Action は、[helm/chart-releaser](https://github.com/helm/chart-releaser) CLI ツールを使用して、GitHub プロジェクトをセルフホスト型の Helm chart リポジトリに変換する GitHub Action ワークフローです。 ### 通常の Web サーバー Helm chart を提供するために通常の Web サーバーを設定するには、以下の作業が必要です: - インデックスと chart をサーバーが提供できるディレクトリに配置する - `index.yaml` ファイルが認証なしでアクセスできることを確認する - `yaml` ファイルが正しいコンテンツタイプ（`text/yaml` または `text/x-yaml`）で提供されることを確認する たとえば、`$WEBROOT/charts` から chart を提供したい場合は、Web ルートに `charts/` ディレクトリがあることを確認し、そのフォルダ内にインデックスファイルと chart を配置します。 ### ChartMuseum リポジトリサーバー ChartMuseum は Go（Golang）で書かれたオープンソースの Helm Chart リポジトリサーバーで、[Google Cloud Storage](https://cloud.google.com/storage/)、[Amazon S3](https://aws.amazon.com/s3/)、[Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)、[Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss)、[Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/)、[Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage)、[Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html)、[Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos)、[DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/)、[Minio](https://min.io/)、[etcd](https://etcd.io/) などのクラウドストレージバックエンドをサポートしています。 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) サーバーを使用して、ローカルファイルシステムから chart リポジトリをホストすることもできます。 ### GitLab Package Registry GitLab では、プロジェクトの Package Registry で Helm chart を公開できます。GitLab で Helm パッケージリポジトリをセットアップする方法については、[こちら](https://docs.gitlab.com/ee/user/packages/helm_repository/)を参照してください。 ## Chart リポジトリの管理 chart リポジトリができたので、このガイドの最後のパートでは、そのリポジトリで chart を管理する方法を説明します。 ### Chart リポジトリに chart を保存する chart リポジトリができたので、chart とインデックスファイルをリポジトリにアップロードしましょう。chart リポジトリ内の chart は、パッケージ化（`helm package chart-name/`）され、正しくバージョニングされている必要があります（[SemVer 2](https://semver.org/) ガイドラインに従います）。 以下の手順はワークフローの例ですが、chart リポジトリへの chart の保存・更新には好みのワークフローを使用できます。 パッケージ化された chart の準備ができたら、新しいディレクトリを作成し、パッケージ化された chart をそのディレクトリに移動します。 ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` 最後のコマンドは、作成したローカルディレクトリのパスとリモート chart リポジトリの URL を受け取り、指定されたディレクトリパス内に `index.yaml` ファイルを生成します。 これで、同期ツールまたは手動で chart とインデックスファイルを chart リポジトリにアップロードできます。Google Cloud Storage を使用している場合は、gsutil クライアントを使用した[ワークフロー例](/howto/chart_repository_sync_example.md)を確認してください。GitHub の場合は、適切な宛先ブランチに chart を配置するだけです。 ### 既存のリポジトリに新しい chart を追加する リポジトリに新しい chart を追加するたびに、インデックスを再生成する必要があります。`helm repo index` コマンドは、ローカルで見つかった chart のみを含めて、`index.yaml` ファイルを最初から完全に再構築します。 ただし、`--merge` フラグを使用して、既存の `index.yaml` ファイルに新しい chart を増分的に追加できます（GCS などのリモートリポジトリで作業する場合に便利なオプションです）。詳細は `helm repo index --help` を実行してください。 更新された `index.yaml` ファイルと chart の両方をアップロードしてください。来歴ファイルを生成した場合は、それもアップロードしてください。 ### Chart を他のユーザーと共有する chart を共有する準備ができたら、リポジトリの URL を他のユーザーに伝えるだけです。 相手は、リポジトリを参照するために使用したい任意の名前で、`helm repo add [NAME] [URL]` コマンドを使用して Helm クライアントにリポジトリを追加します。 ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` chart が HTTP ベーシック認証で保護されている場合は、ユーザー名とパスワードも指定できます: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **注:** 有効な `index.yaml` が含まれていない場合、リポジトリは追加されません。 **注:** Helm リポジトリが自己署名証明書を使用している場合などは、`helm repo add --insecure-skip-tls-verify ...` を使用して CA 検証をスキップできます。 その後、ユーザーは chart を検索できるようになります。リポジトリを更新した後は、`helm repo update` コマンドを使用して最新の chart 情報を取得できます。 *内部的には、`helm repo add` と `helm repo update` コマンドは index.yaml ファイルを取得し、`$XDG_CACHE_HOME/helm/repository/cache/` ディレクトリに保存します。`helm search` 機能は、ここから chart に関する情報を検索します。* ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: chart のテスト description: chart のテスト方法について説明します。 sidebar_position: 3 --- chart には、連携して動作する多くの Kubernetes リソースとコンポーネントが含まれています。chart 作成者は、chart がインストールされたときに期待どおりに動作することを検証するテストを作成できます。これらのテストは、chart 利用者が chart の目的を理解するのにも役立ちます。 Helm chart における**テスト**は、`templates/` ディレクトリに配置され、特定のコマンドを実行するコンテナを指定する Job 定義です。テストが成功と判定されるには、コンテナが正常に終了（exit 0）する必要があります。Job 定義には、Helm テスト hook アノテーション `helm.sh/hook: test` を含める必要があります。 Helm v3 より前は、Job 定義に `helm.sh/hook: test-success` または `helm.sh/hook: test-failure` のいずれかの Helm テスト hook アノテーションが必要でした。`helm.sh/hook: test-success` は、`helm.sh/hook: test` の後方互換として引き続き使用できます。 テストの例: - `values.yaml` ファイルの設定が正しく注入されたことを検証する - ユーザー名とパスワードが正しく機能することを確認する - 不正なユーザー名とパスワードが機能しないことを確認する - サービスが稼働しており、正しくロードバランシングされていることを確認する - など `helm test ` コマンドを使用して、release に対して Helm で事前定義されたテストを実行できます。chart 利用者にとって、これは chart（またはアプリケーション）の release が期待どおりに動作することを確認する優れた方法です。 ## テストの例 [helm create](/helm/helm_create.md) コマンドは、いくつかのフォルダとファイルを自動的に作成します。Helm テスト機能を試すには、まずデモ用の Helm chart を作成します。 ```console $ helm create demo ``` 作成された demo chart の構造は以下のとおりです。 ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` `demo/templates/tests/test-connection.yaml` にテストが含まれています。Helm テスト Pod 定義は以下のとおりです: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## release でテストスイートを実行する手順 まず、クラスターに chart をインストールして release を作成します。すべての Pod がアクティブになるまで待つ必要がある場合があります。インストール直後にテストを実行すると、一時的な失敗が発生する可能性があるため、再テストが必要になることがあります。 ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## 備考 - 単一の yaml ファイルで複数のテストを定義することも、`templates/` ディレクトリ内の複数の yaml ファイルに分散させることもできます。 - テストスイートをより分離するために、`/templates/tests/` のように `tests/` ディレクトリの下にネストすることもできます。 - テストは [Helm hook](/topics/charts_hooks.md) であるため、`helm.sh/hook-weight` や `helm.sh/hook-delete-policy` などのアノテーションをテストリソースで使用できます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Chart description: chart フォーマットの説明と、Helm で chart を構築するための基本的なガイダンスを提供します。 sidebar_position: 1 --- Helm は _chart_ と呼ばれるパッケージングフォーマットを使用します。chart は、関連する Kubernetes リソースを記述するファイル群です。単一の chart で、memcached pod のようなシンプルなものから、HTTP サーバー、データベース、キャッシュなどを含む完全な Web アプリケーションスタックまでデプロイできます。 chart は特定のディレクトリ構造で作成され、バージョン付きアーカイブとしてパッケージ化してデプロイできます。 公開された chart をインストールせずにダウンロードして中身を確認するには、`helm pull chartrepo/chartname` を使用します。 このドキュメントでは、chart フォーマットについて説明し、Helm で chart を構築するための基本的なガイダンスを提供します。 ## Chart のファイル構造 chart は、ディレクトリ内のファイル群で構成されます。ディレクトリ名が chart の名前になります（バージョン情報は含みません）。たとえば、WordPress を記述する chart は `wordpress/` ディレクトリに格納されます。 このディレクトリ内で、Helm は以下のような構造を期待します: ```text wordpress/ Chart.yaml # chart に関する情報を含む YAML ファイル LICENSE # 任意: chart のライセンスを含むテキストファイル README.md # 任意: 人間が読める README ファイル values.yaml # この chart のデフォルト設定値 values.schema.json # 任意: values.yaml ファイルに構造を課すための JSON Schema charts/ # この chart が依存する chart を含むディレクトリ crds/ # Custom Resource Definition templates/ # values と組み合わせると、有効な Kubernetes マニフェストファイルを # 生成するテンプレートのディレクトリ templates/NOTES.txt # 任意: 短い使用方法のメモを含むテキストファイル ``` Helm は `charts/`、`crds/`、`templates/` ディレクトリ、およびリストされたファイル名を予約しています。その他のファイルはそのまま残されます。 ## Chart.yaml ファイル `Chart.yaml` ファイルは chart に必須です。以下のフィールドが含まれます: ```yaml apiVersion: chart API バージョン（必須） name: chart の名前（必須） version: chart のバージョン（必須） kubeVersion: 互換性のある Kubernetes バージョンの SemVer 範囲（任意） description: このプロジェクトの一文の説明（任意） type: chart のタイプ（任意） keywords: - このプロジェクトに関するキーワードのリスト（任意） home: このプロジェクトのホームページの URL（任意） sources: - このプロジェクトのソースコードへの URL のリスト（任意） dependencies: # chart の依存関係のリスト（任意） - name: chart の名前（nginx） version: chart のバージョン（"1.2.3"） repository: （任意）リポジトリ URL（"https://example.com/charts"）またはエイリアス（"@repo-name"） condition: （任意）boolean に解決される yaml パスで、chart の有効化/無効化に使用（例: subchart1.enabled） tags: # （任意） - タグは chart をグループ化して一括で有効化/無効化するために使用できる import-values: # （任意） - ImportValues はソース値から親キーへのインポートマッピングを保持する。各項目は文字列または child/parent サブリスト項目のペア alias: （任意）chart に使用するエイリアス。同じ chart を複数回追加する必要がある場合に便利 maintainers: # （任意） - name: メンテナーの名前（各メンテナーに必須） email: メンテナーのメールアドレス（各メンテナーに任意） url: メンテナーの URL（各メンテナーに任意） icon: アイコンとして使用される SVG または PNG 画像への URL（任意） appVersion: これに含まれるアプリのバージョン（任意）。SemVer である必要はない。引用符推奨。 deprecated: この chart が非推奨かどうか（任意、boolean） annotations: example: 名前をキーとしたアノテーションのリスト（任意） ``` [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2) 以降、追加のフィールドは許可されていません。カスタムメタデータを追加する場合は `annotations` に追加することを推奨します。 ### Chart とバージョニング すべての chart にはバージョン番号が必要です。バージョンは [SemVer 2](https://semver.org/spec/v2.0.0.html) 標準に従う必要がありますが、厳密には強制されません。Helm Classic とは異なり、Helm v2 以降ではバージョン番号をリリースマーカーとして使用します。リポジトリ内のパッケージは名前とバージョンで識別されます。 たとえば、version フィールドが `version: 1.2.3` に設定された `nginx` chart は以下のように名前が付けられます: ```text nginx-1.2.3.tgz ``` より複雑な SemVer 2 の名前もサポートされています（例: `version: 1.2.3-alpha.1+ef365`）。ただし、非 SemVer 名はシステムによって明示的に禁止されています。例外として、`x` または `x.y` 形式のバージョンは許可されます。 たとえば、先頭に v がある場合や、3 つのパーツすべてがないバージョン（例: v1.2）がある場合、有効なセマンティックバージョンに強制変換されます（例: v1.2.0）。 **注:** Helm Classic と Deployment Manager は chart に関して GitHub 指向でしたが、Helm v2 以降は GitHub や Git に依存も要求もしません。そのため、バージョニングに Git SHA をまったく使用しません。 `Chart.yaml` 内の `version` フィールドは、CLI を含む多くの Helm ツールで使用されます。パッケージを生成する際、`helm package` コマンドは `Chart.yaml` で見つけたバージョンをパッケージ名のトークンとして使用します。システムは、chart パッケージ名のバージョン番号が `Chart.yaml` のバージョン番号と一致することを想定しています。この想定を満たさないとエラーが発生します。 ### `apiVersion` フィールド `apiVersion` フィールドは、Helm 3 以上を必要とする Helm chart では `v2` にする必要があります。以前の Helm バージョンをサポートする chart は `apiVersion` が `v1` に設定されており、Helm 3 でもインストール可能です。 `v1` から `v2` への変更点: - `v1` chart では別の `requirements.yaml` ファイルにあった chart 依存関係を定義する `dependencies` フィールド（[Chart 依存関係](#chart-依存関係)を参照）。 - application chart と library chart を区別する `type` フィールド（[Chart タイプ](#chart-タイプ)を参照）。 ### `appVersion` フィールド `appVersion` フィールドは `version` フィールドとは関係ありません。これはアプリケーションのバージョンを指定するためのフィールドです。たとえば、`drupal` chart には `appVersion: "8.2.1"` があり、chart に含まれる Drupal のバージョン（デフォルト）が `8.2.1` であることを示しています。このフィールドは情報提供用であり、chart バージョンの計算には影響しません。バージョンを引用符で囲むことを強く推奨します。これにより YAML パーサーがバージョン番号を文字列として扱います。引用符で囲まないと、パースの問題が発生する場合があります。たとえば、YAML は `1.0` を浮動小数点値として、`1234e10` のような git commit SHA を指数表記として解釈します。 Helm v3.5.0 以降、`helm create` はデフォルトの `appVersion` フィールドを引用符で囲むようになりました。 ### `kubeVersion` フィールド 任意の `kubeVersion` フィールドでは、サポートされる Kubernetes バージョンの semver 制約を定義できます。Helm は chart をインストールする際にバージョン制約を検証し、クラスターがサポートされていない Kubernetes バージョンで実行されている場合は失敗します。 バージョン制約には、以下のようなスペースで区切られた AND 比較を含めることができます: ``` >= 1.13.0 < 1.15.0 ``` これらは以下の例のように OR 演算子 `||` と組み合わせることができます: ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` この例では、バージョン `1.14.0` が除外されています。これは、特定のバージョンのバグにより chart が正しく動作しないことがわかっている場合に有用です。 演算子 `=` `!=` `>` `<` `>=` `<=` を使用したバージョン制約の他に、以下の省略記法がサポートされています: * ハイフン範囲（閉区間）: `1.1 - 2.3.4` は `>= 1.1 <= 2.3.4` と同等です。 * ワイルドカード `x`、`X`、`*`: `1.2.x` は `>= 1.2.0 < 1.3.0` と同等です。 * チルダ範囲（パッチバージョンの変更を許可）: `~1.2.3` は `>= 1.2.3 < 1.3.0` と同等です。 * キャレット範囲（マイナーバージョンの変更を許可）: `^1.2.3` は `>= 1.2.3 < 2.0.0` と同等です。 サポートされる semver 制約の詳細については、[Masterminds/semver](https://github.com/Masterminds/semver) を参照してください。 ### Chart の非推奨化 Chart リポジトリで chart を管理する際、chart を非推奨にする必要がある場合があります。`Chart.yaml` の任意の `deprecated` フィールドを使用して、chart を非推奨としてマークできます。リポジトリ内の chart の**最新**バージョンが非推奨としてマークされている場合、chart 全体が非推奨と見なされます。非推奨としてマークされていない新しいバージョンを公開することで、chart 名を再利用できます。chart を非推奨にするワークフローは以下のとおりです: 1. chart の `Chart.yaml` を更新して chart を非推奨としてマークし、バージョンをバンプする 2. Chart リポジトリで新しい chart バージョンをリリースする 3. ソースリポジトリ（例: git）から chart を削除する ### Chart タイプ `type` フィールドは chart のタイプを定義します。タイプは `application` と `library` の 2 種類です。application がデフォルトタイプで、完全に操作可能な標準的な chart です。[library chart](/topics/library_charts.md) は chart ビルダー向けのユーティリティや関数を提供します。library chart は application chart とは異なり、インストールできず、通常はリソースオブジェクトを含みません。 **注:** application chart を library chart として使用することもできます。type を `library` に設定すると有効になります。すべてのユーティリティと関数を活用できる library chart としてレンダリングされますが、chart のすべてのリソースオブジェクトはレンダリングされません。 ## Chart の LICENSE、README、NOTES chart には、インストール、設定、使用方法、ライセンスを説明するファイルも含めることができます。 LICENSE は、chart の[ライセンス](https://en.wikipedia.org/wiki/Software_license)を含むテキストファイルです。chart にはテンプレート内にプログラミングロジックが含まれる場合があり、設定のみではないため、ライセンスを含めることができます。必要に応じて、chart によってインストールされるアプリケーションの個別のライセンスも含めることができます。 chart の README は Markdown（README.md）でフォーマットする必要があり、一般的に以下を含めます: - chart が提供するアプリケーションまたはサービスの説明 - chart を実行するための前提条件や要件 - `values.yaml` のオプションとデフォルト値の説明 - chart のインストールや設定に関連するその他の情報 ハブやその他のユーザーインターフェースで chart の詳細を表示する際、その詳細は `README.md` ファイルの内容から取得されます。 chart には、インストール後や release のステータスを表示する際に出力される短いテキストの `templates/NOTES.txt` ファイルも含めることができます。このファイルは[テンプレート](#テンプレートと-values)として評価され、使用方法のメモ、次のステップ、または release に関連するその他の情報を表示するために使用できます。たとえば、データベースへの接続方法や Web UI へのアクセス方法の説明を提供できます。このファイルは `helm install` または `helm status` の実行時に STDOUT に出力されるため、内容は簡潔にし、詳細は README を参照するようにすることを推奨します。 ## Chart 依存関係 Helm では、chart は任意の数の他の chart に依存できます。これらの依存関係は、`Chart.yaml` の `dependencies` フィールドを使用して動的にリンクするか、`charts/` ディレクトリに手動で配置して管理できます。 ### `dependencies` フィールドによる依存関係の管理 現在の chart が必要とする chart は、`dependencies` フィールドにリストとして定義します。 ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - `name` フィールドは必要な chart の名前です。 - `version` フィールドは必要な chart のバージョンです。 - `repository` フィールドは chart リポジトリへの完全な URL です。ローカルにそのリポジトリを追加するには `helm repo add` も使用する必要があります。 - URL の代わりにリポジトリ名を使用することもできます ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` 依存関係を定義したら、`helm dependency update` を実行すると、依存ファイルを使用して指定されたすべての chart を `charts/` ディレクトリにダウンロードできます。 ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` `helm dependency update` が chart を取得すると、`charts/` ディレクトリに chart アーカイブとして保存されます。上記の例では、charts ディレクトリに以下のファイルが存在することになります: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### 依存関係の alias フィールド 上記の他のフィールドに加えて、各依存関係エントリには任意の `alias` フィールドを含めることができます。 依存関係 chart にエイリアスを追加すると、エイリアスを新しい依存関係の名前として使用して chart を依存関係に配置します。 別の名前で chart にアクセスする必要がある場合に `alias` を使用できます。 ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` 上記の例では、`parentchart` に対して合計 3 つの依存関係が取得されます: ```text subchart new-subchart-1 new-subchart-2 ``` これを手動で行う方法は、`charts/` ディレクトリに異なる名前で同じ chart を複数回コピー＆ペーストすることです。 #### 依存関係の tags と condition フィールド 上記の他のフィールドに加えて、各依存関係エントリには任意の `tags` と `condition` フィールドを含めることができます。 すべての chart はデフォルトでロードされます。`tags` または `condition` フィールドが存在する場合、それらが評価され、適用される chart のロードを制御するために使用されます。 condition - condition フィールドは 1 つ以上の YAML パス（カンマ区切り）を保持します。このパスが最上位の親の values に存在し、boolean 値に解決される場合、その boolean 値に基づいて chart が有効または無効になります。リスト内で見つかった最初の有効なパスのみが評価され、パスが存在しない場合、condition は効果がありません。 tags - tags フィールドは、この chart に関連付けるラベルの YAML リストです。最上位の親の values で、タグと boolean 値を指定することで、タグを持つすべての chart を有効または無効にできます。 ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` 上記の例では、タグ `front-end` を持つすべての chart が無効になりますが、親の values で `subchart1.enabled` パスが 'true' と評価されるため、condition が `front-end` タグをオーバーライドし、`subchart1` が有効になります。 `subchart2` はタグ `back-end` を持ち、そのタグが `true` と評価されるため、`subchart2` が有効になります。また、`subchart2` には condition が指定されていますが、親の values に対応するパスと値がないため、その condition は効果がありません。 ##### CLI での tags と conditions の使用 `--set` パラメータを通常どおり使用して、tag と condition の値を変更できます。 ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### tags と condition の解決 - **conditions（values で設定されている場合）は常に tags をオーバーライドします。** 存在する最初の condition パスが優先され、その chart の後続のパスは無視されます。 - tags は「chart のタグのいずれかが true の場合、chart を有効にする」として評価されます。 - tags と conditions の値は最上位の親の values で設定する必要があります。 - values の `tags:` キーはトップレベルキーである必要があります。グローバルおよびネストされた `tags:` テーブルは現在サポートされていません。 #### dependencies による子の values のインポート 場合によっては、子 chart の values を親 chart に伝播させ、共通のデフォルトとして共有することが望ましい場合があります。`exports` フォーマットを使用する追加の利点は、将来のツールがユーザー設定可能な値を調査できるようになることです。 インポートする値を含むキーは、親 chart の `dependencies` の `import-values` フィールドで YAML リストを使用して指定できます。リストの各項目は、子 chart の `exports` フィールドからインポートされるキーです。 `exports` キーに含まれていない値をインポートするには、[child-parent](#child-parent-フォーマットの使用) フォーマットを使用してください。両方のフォーマットの例を以下に示します。 ##### exports フォーマットの使用 子 chart の `values.yaml` ファイルのルートに `exports` フィールドがある場合、以下の例のようにインポートするキーを指定することで、その内容を親の values に直接インポートできます: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` インポートリストでキー `data` を指定しているため、Helm は子 chart の `exports` フィールドで `data` キーを探し、その内容をインポートします。 最終的な親の values にはエクスポートされたフィールドが含まれます: ```yaml # parent's values myint: 99 ``` 親キー `data` は親の最終 values に含まれないことに注意してください。親キーを指定する必要がある場合は、'child-parent' フォーマットを使用してください。 ##### child-parent フォーマットの使用 子 chart の values の `exports` キーに含まれていない値にアクセスするには、インポートする値のソースキー（`child`）と親 chart の values の宛先パス（`parent`）を指定する必要があります。 以下の例の `import-values` は、`child:` パスにある値を取得し、`parent:` で指定されたパスの親の values にコピーするよう Helm に指示しています: ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` 上記の例では、subchart1 の values の `default.data` にある値が、以下に詳述するように親 chart の values の `myimports` キーにインポートされます: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` 親 chart の結果の values は以下のようになります: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` 親の最終 values には、subchart1 からインポートされた `myint` と `mybool` フィールドが含まれるようになりました。 ### `charts/` ディレクトリによる手動の依存関係管理 依存関係をより細かく制御したい場合、依存関係 chart を `charts/` ディレクトリにコピーすることで明示的に表現できます。 依存関係は展開された chart ディレクトリである必要がありますが、名前は `_` または `.` で始めることはできません。そのようなファイルは chart ローダーによって無視されます。 たとえば、WordPress chart が Apache chart に依存している場合、Apache chart（正しいバージョン）が WordPress chart の `charts/` ディレクトリに配置されます: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` 上記の例は、WordPress chart が Apache と MySQL への依存関係を、`charts/` ディレクトリ内にそれらの chart を含めることでどのように表現しているかを示しています。 **ヒント:** _依存関係を `charts/` ディレクトリにドロップするには、`helm pull` コマンドを使用してください_ ### 依存関係使用時の操作面 上記のセクションでは chart 依存関係の指定方法を説明しましたが、`helm install` や `helm upgrade` を使用した chart のインストールにどのように影響するのでしょうか？ "A" という名前の chart が以下の Kubernetes オブジェクトを作成するとします: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" さらに、A は以下のオブジェクトを作成する chart B に依存しています: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" chart A のインストール/アップグレード後、単一の Helm release が作成/変更されます。この release は、上記のすべての Kubernetes オブジェクトを以下の順序で作成/更新します: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet これは、Helm が chart とそのすべての依存関係をインストール/アップグレードする際に、Kubernetes オブジェクトが以下のように処理されるためです: - 単一のセットに集約される - タイプ順、次に名前順でソートされる - その順序で作成/更新される したがって、chart とその依存関係のすべてのオブジェクトを含む単一の release が作成されます。 Kubernetes タイプのインストール順序は、kind_sorter.go の InstallOrder 列挙型で指定されています（[Helm ソースファイル](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)を参照）。 ## テンプレートと Values Helm Chart テンプレートは [Go テンプレート言語](https://golang.org/pkg/text/template/)で記述され、[Sprig ライブラリ](https://github.com/Masterminds/sprig)の 50 以上のアドオンテンプレート関数といくつかの[特殊な関数](/howto/charts_tips_and_tricks.md)が追加されています。 すべてのテンプレートファイルは chart の `templates/` フォルダに格納されます。Helm が chart をレンダリングする際、そのディレクトリ内のすべてのファイルがテンプレートエンジンを通過します。 テンプレートの values は 2 つの方法で提供されます: - chart 開発者は chart 内に `values.yaml` というファイルを提供できます。このファイルにはデフォルト値を含めることができます。 - chart ユーザーは values を含む YAML ファイルを提供できます。これはコマンドラインで `helm install` を使用して提供できます。 ユーザーがカスタム values を提供すると、それらの値は chart の `values.yaml` ファイルの値をオーバーライドします。 ### テンプレートファイル テンプレートファイルは Go テンプレートを記述するための標準的な規約に従います（詳細は [text/template Go パッケージドキュメント](https://golang.org/pkg/text/template/)を参照）。テンプレートファイルの例は以下のようになります: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` 上記の例は [https://github.com/deis/charts](https://github.com/deis/charts) に緩く基づいており、Kubernetes レプリケーションコントローラのテンプレートです。以下の 4 つのテンプレート値を使用できます（通常は `values.yaml` ファイルで定義されます）: - `imageRegistry`: Docker イメージのソースレジストリ。 - `dockerTag`: docker イメージのタグ。 - `pullPolicy`: Kubernetes のプルポリシー。 - `storage`: ストレージバックエンド。デフォルトは `"minio"` に設定されています。 これらの値はすべてテンプレート作成者によって定義されています。Helm はパラメータを要求したり指定したりしません。 動作する多くの chart を見るには、CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) をチェックしてください。 ### 事前定義された Values `values.yaml` ファイル（または `--set` フラグ）を通じて提供される values は、テンプレート内の `.Values` オブジェクトからアクセスできます。ただし、テンプレートでアクセスできる他の事前定義されたデータもあります。 以下の values は事前定義されており、すべてのテンプレートで利用可能で、オーバーライドできません。すべての values と同様に、名前は_大文字と小文字を区別_します。 - `Release.Name`: release の名前（chart ではない） - `Release.Namespace`: chart がリリースされた namespace。 - `Release.Service`: release を実行したサービス。 - `Release.IsUpgrade`: 現在の操作がアップグレードまたはロールバックの場合、これは true に設定されます。 - `Release.IsInstall`: 現在の操作がインストールの場合、これは true に設定されます。 - `Chart`: `Chart.yaml` の内容。したがって、chart バージョンは `Chart.Version` で取得でき、メンテナーは `Chart.Maintainers` にあります。 - `Files`: chart 内のすべての非特殊ファイルを含むマップのようなオブジェクト。これはテンプレートへのアクセスは提供しませんが、存在する追加ファイルへのアクセスを提供します（`.helmignore` を使用して除外されていない限り）。ファイルは `{{ index .Files "file.name" }}` または `{{.Files.Get name }}` 関数を使用してアクセスできます。`{{ .Files.GetBytes }}` を使用してファイルの内容を `[]byte` としてアクセスすることもできます。 - `Capabilities`: Kubernetes のバージョン（`{{ .Capabilities.KubeVersion }}`）やサポートされている Kubernetes API バージョン（`{{ .Capabilities.APIVersions.Has "batch/v1" }}`）に関する情報を含むマップのようなオブジェクト。 **注:** 不明な `Chart.yaml` フィールドは削除されます。`Chart` オブジェクト内でアクセスできません。したがって、`Chart.yaml` を使用して任意の構造化データをテンプレートに渡すことはできません。ただし、values ファイルはそのために使用できます。 ### values ファイル 前のセクションのテンプレートを考慮すると、必要な values を提供する `values.yaml` ファイルは以下のようになります: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` values ファイルは YAML でフォーマットされます。chart にはデフォルトの `values.yaml` ファイルを含めることができます。Helm install コマンドでは、追加の YAML 値を提供することで値をオーバーライドできます: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` この方法で values が渡されると、デフォルトの values ファイルにマージされます。たとえば、以下のような `myvals.yaml` ファイルを考えてみましょう: ```yaml storage: "gcs" ``` これが chart の `values.yaml` とマージされると、生成される内容は以下のようになります: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` 最後のフィールドのみがオーバーライドされたことに注意してください。 **注:** chart 内に含まれるデフォルトの values ファイルは、`values.yaml` という名前である_必要があります_。ただし、コマンドラインで指定するファイルは任意の名前にできます。 **注:** `helm install` または `helm upgrade` で `--set` フラグを使用すると、それらの値はクライアント側で単純に YAML に変換されます。 **注:** values ファイルに必須のエントリが存在する場合、chart テンプレートで ['required' 関数](/howto/charts_tips_and_tricks.md)を使用して必須として宣言できます。 これらの values はすべて、`.Values` オブジェクトを使用してテンプレート内でアクセスできます: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### スコープ、依存関係、Values values ファイルは、トップレベル chart の値と、その chart の `charts/` ディレクトリに含まれる chart の値を宣言できます。言い換えると、values ファイルは chart とその依存関係のいずれにも値を提供できます。たとえば、上記のデモ用 WordPress chart には `mysql` と `apache` が依存関係としてあります。values ファイルはこれらすべてのコンポーネントに値を提供できます: ```yaml title: "My WordPress Site" # WordPress テンプレートに送信される mysql: max_connections: 100 # MySQL に送信される password: "secret" apache: port: 8080 # Apache に渡される ``` 上位レベルの chart は、下位で定義されたすべての変数にアクセスできます。したがって、WordPress chart は MySQL のパスワードに `.Values.mysql.password` としてアクセスできます。ただし、下位レベルの chart は親 chart のものにアクセスできないため、MySQL は `title` プロパティにアクセスできません。同様に、`apache.port` にもアクセスできません。 values は名前空間化されていますが、名前空間はプルーニングされます。したがって、WordPress chart は MySQL のパスワードフィールドに `.Values.mysql.password` としてアクセスできます。しかし、MySQL chart では values のスコープが縮小され、名前空間プレフィックスが削除されるため、パスワードフィールドは単に `.Values.password` として見えます。 #### グローバル Values 2.0.0-Alpha.2 以降、Helm は特別な「グローバル」値をサポートしています。前の例の修正版を考えてみましょう: ```yaml title: "My WordPress Site" # WordPress テンプレートに送信される global: app: MyWordPress mysql: max_connections: 100 # MySQL に送信される password: "secret" apache: port: 8080 # Apache に渡される ``` 上記は `app: MyWordPress` という値を持つ `global` セクションを追加しています。この値は `.Values.global.app` として_すべての_ chart で利用可能です。 たとえば、`mysql` テンプレートは `app` に `{{ .Values.global.app}}` としてアクセスでき、`apache` chart も同様です。実質的に、上記の values ファイルは以下のように再生成されます: ```yaml title: "My WordPress Site" # WordPress テンプレートに送信される global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # MySQL に送信される password: "secret" apache: global: app: MyWordPress port: 8080 # Apache に渡される ``` これにより、1 つのトップレベル変数をすべてのサブチャートと共有できます。これは `metadata` プロパティ（ラベルなど）の設定に便利です。 サブチャートがグローバル変数を宣言した場合、そのグローバルは（サブチャートのサブチャートに）_下方向_に渡されますが、親 chart には_上方向_に渡されません。サブチャートが親 chart の値に影響を与える方法はありません。 また、親 chart のグローバル変数はサブチャートのグローバル変数よりも優先されます。 ### スキーマファイル chart メンテナーは、values に構造を定義したい場合があります。これは `values.schema.json` ファイルでスキーマを定義することで実現できます。スキーマは [JSON Schema](https://json-schema.org/) として表現されます。以下のようになります: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` このスキーマは values に適用され、検証が行われます。検証は以下のコマンドが実行されたときに行われます: - `helm install` - `helm upgrade` - `helm lint` - `helm template` このスキーマの要件を満たす `values.yaml` ファイルの例は以下のようになります: ```yaml name: frontend protocol: https port: 443 ``` スキーマは `values.yaml` ファイルだけでなく、最終的な `.Values` オブジェクトに適用されることに注意してください。つまり、以下の `yaml` ファイルは、以下に示す適切な `--set` オプションで chart がインストールされた場合に有効です。 ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` さらに、最終的な `.Values` オブジェクトは*すべて*のサブチャートスキーマに対してチェックされます。これは、サブチャートの制限が親 chart によって回避できないことを意味します。これは逆方向にも機能します - サブチャートの `values.yaml` ファイルで満たされていない要件がある場合、親 chart はそれらの制限を満たす*必要があります*。 スキーマ検証は以下のオプションを設定することで無効にできます。 これは、chart の JSON Schema ファイルにリモート参照が含まれているエアギャップ環境で特に便利です。 ```console helm install --skip-schema-validation ``` ### リファレンス テンプレート、values、スキーマファイルを記述する際に役立ついくつかの標準的なリファレンスがあります。 - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definition（CRD） Kubernetes は、新しい種類の Kubernetes オブジェクトを宣言するメカニズムを提供しています。CustomResourceDefinition（CRD）を使用すると、Kubernetes 開発者はカスタムリソースタイプを宣言できます。 Helm 3 では、CRD は特別な種類のオブジェクトとして扱われます。chart の残りの部分より前にインストールされ、いくつかの制限があります。 CRD YAML ファイルは chart 内の `crds/` ディレクトリに配置する必要があります。複数の CRD（YAML の開始マーカーと終了マーカーで区切られた）を同じファイルに配置できます。Helm は CRD ディレクトリ内の_すべて_のファイルを Kubernetes にロードしようとします。 CRD ファイルは_テンプレート化できません_。プレーンな YAML ドキュメントである必要があります。 Helm が新しい chart をインストールする際、CRD をアップロードし、API サーバーによって CRD が利用可能になるまで一時停止し、その後テンプレートエンジンを起動して chart の残りをレンダリングし、Kubernetes にアップロードします。この順序のため、CRD 情報は Helm テンプレートの `.Capabilities` オブジェクトで利用可能であり、Helm テンプレートは CRD で宣言されたオブジェクトの新しいインスタンスを作成できます。 たとえば、chart の `crds/` ディレクトリに `CronTab` の CRD がある場合、`templates/` ディレクトリで `CronTab` kind のインスタンスを作成できます: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` `crontab.yaml` ファイルには、テンプレートディレクティブなしで CRD が含まれている必要があります: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` その後、テンプレート `mycrontab.yaml` は新しい `CronTab` を作成できます（通常どおりテンプレートを使用）: ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm は、`templates/` 内のものをインストールする前に、`CronTab` kind がインストールされ、Kubernetes API サーバーから利用可能であることを確認します。 ### CRD の制限 Kubernetes のほとんどのオブジェクトとは異なり、CRD はグローバルにインストールされます。そのため、Helm は CRD の管理に非常に慎重なアプローチを取ります。CRD には以下の制限があります: - CRD は再インストールされません。Helm が `crds/` ディレクトリの CRD がすでに存在すると判断した場合（バージョンに関係なく）、Helm はインストールやアップグレードを試みません。 - CRD はアップグレードやロールバック時にインストールされません。Helm はインストール操作時のみ CRD を作成します。 - CRD は削除されません。CRD を削除すると、クラスター内のすべての namespace にある CRD のすべてのコンテンツが自動的に削除されます。そのため、Helm は CRD を削除しません。 CRD をアップグレードまたは削除したいオペレーターは、手動で十分注意して行うことを推奨します。 ## Helm を使用した Chart の管理 `helm` ツールには chart を操作するためのいくつかのコマンドがあります。 新しい chart を作成できます: ```console $ helm create mychart Created mychart/ ``` chart を編集したら、`helm` で chart アーカイブにパッケージ化できます: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` `helm` を使用して chart のフォーマットや情報の問題を見つけることもできます: ```console $ helm lint mychart No issues found ``` ## Chart リポジトリ _chart リポジトリ_は、1 つ以上のパッケージ化された chart をホストする HTTP サーバーです。`helm` はローカルの chart ディレクトリを管理するために使用できますが、chart を共有する際は chart リポジトリが推奨されるメカニズムです。 YAML ファイルと tar ファイルを提供でき、GET リクエストに応答できる任意の HTTP サーバーをリポジトリサーバーとして使用できます。Helm チームは、Web サイトモードを有効にした Google Cloud Storage や、Web サイトモードを有効にした S3 など、いくつかのサーバーをテストしています。 リポジトリは主に、リポジトリが提供するすべてのパッケージのリストと、それらのパッケージを取得して検証するためのメタデータを持つ `index.yaml` という特別なファイルの存在によって特徴付けられます。 クライアント側では、リポジトリは `helm repo` コマンドで管理されます。ただし、Helm はリモートリポジトリサーバーに chart をアップロードするためのツールを提供していません。これは、実装するサーバーに大きな要件を追加し、リポジトリの設定の障壁を上げるためです。 ## Chart スターターパック `helm create` コマンドには、「スターター chart」を指定できる任意の `--starter` オプションがあります。また、starter オプションには短いエイリアス `-p` があります。 使用例: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` スターターは通常の chart ですが、`$XDG_DATA_HOME/helm/starters` に配置されています。chart 開発者は、スターターとして使用するために特別に設計された chart を作成できます。そのような chart は以下の考慮事項を念頭に置いて設計する必要があります: - `Chart.yaml` はジェネレーターによって上書きされます。 - ユーザーはそのような chart の内容を変更することを期待しているため、ドキュメントでユーザーがどのように変更できるかを示す必要があります。 - `` のすべての出現箇所は指定された chart 名に置き換えられるため、スターター chart をテンプレートとして使用できます。ただし、一部の変数ファイルは例外です。たとえば、`vars` ディレクトリ内のカスタムファイルや特定の `README.md` ファイルを使用する場合、それらの内部では `` は置き換えられません。また、chart の説明は継承されません。 現在、`$XDG_DATA_HOME/helm/starters` に chart を追加する唯一の方法は、手動でコピーすることです。chart のドキュメントで、そのプロセスを説明することを推奨します。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Chart Hook description: chart hook の使い方を説明します。 sidebar_position: 2 --- Helm は、chart 開発者が release のライフサイクルの特定のポイントに介入できる _hook_ メカニズムを提供します。たとえば、hook を使用して以下のことができます: - インストール時に他の chart がロードされる前に ConfigMap や Secret をロードする。 - 新しい chart をインストールする前にデータベースをバックアップする Job を実行し、アップグレード後にデータを復元する 2 番目の Job を実行する。 - release を削除する前に Job を実行し、サービスをローテーションから graceful に切り離してから削除する。 hook は通常のテンプレートと同じように機能しますが、Helm が異なる方法で利用するための特別なアノテーションを持っています。このセクションでは、hook の基本的な使用パターンを説明します。 ## 利用可能な Hook 以下の hook が定義されています: | アノテーション値 | 説明 | | ---------------- | ---------------------------------------------------------------------------------------------- | | `pre-install` | テンプレートがレンダリングされた後、Kubernetes にリソースが作成される前に実行されます | | `post-install` | すべてのリソースが Kubernetes にロードされた後に実行されます | | `pre-delete` | 削除リクエスト時、Kubernetes からリソースが削除される前に実行されます | | `post-delete` | 削除リクエスト時、release のすべてのリソースが削除された後に実行されます | | `pre-upgrade` | アップグレードリクエスト時、テンプレートがレンダリングされた後、リソースが更新される前に実行されます | | `post-upgrade` | アップグレードリクエスト時、すべてのリソースがアップグレードされた後に実行されます | | `pre-rollback` | ロールバックリクエスト時、テンプレートがレンダリングされた後、リソースがロールバックされる前に実行されます | | `post-rollback` | ロールバックリクエスト時、すべてのリソースが変更された後に実行されます | | `test` | Helm test サブコマンドが実行されたときに実行されます（[テストのドキュメント](/topics/chart_tests.md)を参照） | _注: `crd-install` hook は Helm 3 で `crds/` ディレクトリに置き換えられ、削除されました。_ ## Hook と Release ライフサイクル hook を使用すると、chart 開発者は release ライフサイクルの戦略的なポイントで操作を実行できます。たとえば、`helm install` のライフサイクルを考えてみましょう。デフォルトでは、ライフサイクルは以下のようになります: 1. ユーザーが `helm install foo` を実行します 2. Helm ライブラリの install API が呼び出されます 3. いくつかの検証の後、ライブラリが `foo` テンプレートをレンダリングします 4. ライブラリが結果のリソースを Kubernetes にロードします 5. ライブラリが release オブジェクト（およびその他のデータ）をクライアントに返します 6. クライアントが終了します Helm は `install` ライフサイクルに対して 2 つの hook を定義しています: `pre-install` と `post-install` です。`foo` chart の開発者が両方の hook を実装した場合、ライフサイクルは以下のように変更されます: 1. ユーザーが `helm install foo` を実行します 2. Helm ライブラリの install API が呼び出されます 3. `crds/` ディレクトリ内の CRD がインストールされます 4. いくつかの検証の後、ライブラリが `foo` テンプレートをレンダリングします 5. ライブラリが `pre-install` hook の実行を準備します（hook リソースを Kubernetes にロード） 6. ライブラリが hook を weight でソートし（デフォルトは weight 0）、次にリソース kind、最後に名前の昇順でソートします 7. ライブラリが最も低い weight の hook から順にロードします（負から正へ） 8. ライブラリが hook が「Ready」になるまで待機します（CRD を除く） 9. ライブラリが結果のリソースを Kubernetes にロードします。`--wait` フラグが設定されている場合、ライブラリはすべてのリソースが ready 状態になるまで待機し、ready になるまで `post-install` hook を実行しません。 10. ライブラリが `post-install` hook を実行します（hook リソースをロード） 11. ライブラリが hook が「Ready」になるまで待機します 12. ライブラリが release オブジェクト（およびその他のデータ）をクライアントに返します 13. クライアントが終了します hook が ready になるまで待機するとはどういう意味でしょうか？これは hook で宣言されたリソースによって異なります。リソースが `Job` または `Pod` kind の場合、Helm は正常に完了するまで待機します。hook が失敗すると、release は失敗します。これは _ブロッキング操作_ であり、Job の実行中は Helm クライアントが一時停止します。 その他のすべての kind では、Kubernetes がリソースをロード済み（追加または更新）としてマークした時点で、そのリソースは「Ready」と見なされます。hook で多くのリソースが宣言されている場合、リソースは順次実行されます。hook weight がある場合（以下を参照）、weight 順に実行されます。Helm 3.2.0 以降、同じ weight を持つ hook リソースは、通常の非 hook リソースと同じ順序でインストールされます。それ以外の場合、順序は保証されません。（Helm 2.3.0 以降ではアルファベット順にソートされていました。ただし、この動作は拘束力があるとは見なされておらず、将来変更される可能性があります。）hook weight を追加し、weight が重要でない場合は `0` に設定することが推奨されます。 ### hook リソースは対応する release で管理されない hook が作成するリソースは、現在のところ release の一部として追跡または管理されません。Helm が hook が ready 状態に達したことを確認すると、hook リソースはそのまま残されます。対応する release が削除されたときの hook リソースのガベージコレクションは、将来の Helm 3 で追加される可能性があります。そのため、削除されてはならない hook リソースには `helm.sh/resource-policy: keep` アノテーションを付ける必要があります。 実際には、hook でリソースを作成した場合、`helm uninstall` でそのリソースを削除することはできません。このようなリソースを破棄するには、hook テンプレートファイルに[カスタムの `helm.sh/hook-delete-policy` アノテーションを追加する](#hook-削除ポリシー)か、[Job リソースの TTL（Time To Live）フィールドを設定する](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)必要があります。 ## Hook の記述 hook は、`metadata` セクションに特別なアノテーションを持つ Kubernetes マニフェストファイルです。テンプレートファイルであるため、`.Values`、`.Release`、`.Template` の読み取りを含む、すべての通常のテンプレート機能を使用できます。 たとえば、`templates/post-install-job.yaml` に保存されている以下のテンプレートは、`post-install` で実行される Job を宣言しています: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` このテンプレートを hook にしているのは、以下のアノテーションです: ```yaml annotations: "helm.sh/hook": post-install ``` 1 つのリソースで複数の hook を実装できます: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` 同様に、特定の hook を実装するリソースの数に制限はありません。たとえば、Secret と ConfigMap の両方を pre-install hook として宣言できます。 subchart が hook を宣言している場合、それらも評価されます。トップレベルの chart が subchart で宣言された hook を無効にする方法はありません。 hook の weight を定義して、決定論的な実行順序を構築できます。weight は以下のアノテーションで定義します: ```yaml annotations: "helm.sh/hook-weight": "5" ``` hook weight は正または負の数値ですが、文字列として表現する必要があります。Helm が特定の Kind の hook の実行サイクルを開始するとき、それらの hook を昇順でソートします。 ### Hook 削除ポリシー 対応する hook リソースをいつ削除するかを決定するポリシーを定義できます。hook 削除ポリシーは以下のアノテーションで定義します: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` 以下の定義済みアノテーション値から 1 つ以上を選択できます: | アノテーション値 | 説明 | | ---------------------- | ------------------------------------------------------------- | | `before-hook-creation` | 新しい hook が起動される前に以前のリソースを削除します（デフォルト） | | `hook-succeeded` | hook が正常に実行された後にリソースを削除します | | `hook-failed` | 実行中に hook が失敗した場合にリソースを削除します | hook 削除ポリシーアノテーションが指定されていない場合、デフォルトで `before-hook-creation` の動作が適用されます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: トピック sidebar_position: 3 --- # トピックガイド ここでは、Helm の必要な、または知りたいすべての主要部分の概要を 説明します。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: 非推奨の Kubernetes API description: Helm における非推奨の Kubernetes API について説明します --- Kubernetes は API 駆動型のシステムであり、システムへの理解が深まるにつれて API も進化します。これはシステムとその API において一般的なプラクティスです。API を進化させるうえで重要なのは、適切な非推奨ポリシーとプロセスを整備し、API の変更内容をユーザーに通知することです。API の利用者は、どの API がいつ削除または変更されるのかを事前に把握する必要があります。これにより、予期しない破壊的変更を回避できます。 [Kubernetes の非推奨ポリシー](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)には、Kubernetes が API バージョンの変更をどのように扱うかが記載されています。このポリシーでは、非推奨の発表後に各 API バージョンがサポートされる期間が定められています。非推奨の発表を把握し、API バージョンがいつ削除されるかを知っておくことが、影響を最小限に抑えるために重要です。 以下は、[Kubernetes 1.16 における非推奨 API バージョンの削除](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)に関するアナウンスの例です。このアナウンスはリリースの数ヶ月前に告知されました。これらの API バージョンは、この発表より前にすでに非推奨として発表されていたものです。このように、API バージョンのサポート状況を利用者に適切に通知するポリシーが整備されています。 Helm テンプレートでは、Kubernetes オブジェクトを定義する際に [Kubernetes API グループ](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)を指定します。これは Kubernetes のマニフェストファイルと同様です。API グループはテンプレートの `apiVersion` フィールドで指定し、Kubernetes オブジェクトの API バージョンを識別します。Helm ユーザーと chart メンテナーは、Kubernetes API バージョンがいつ非推奨となり、どの Kubernetes バージョンで削除されるかを把握しておく必要があります。 ## Chart メンテナー向け chart を監査し、非推奨または特定の Kubernetes バージョンで削除された API バージョンがないか確認してください。サポートが終了した、または終了予定の API バージョンが見つかった場合は、サポートされているバージョンに更新し、新しいバージョンの chart をリリースしてください。API バージョンは `kind` と `apiVersion` フィールドで定義されます。以下は、Kubernetes 1.16 で削除された `Deployment` オブジェクトの API バージョンの例です。 ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm ユーザー向け 使用している chart を監査し（[Chart メンテナー向け](#chart-メンテナー向け)と同様）、非推奨または特定の Kubernetes バージョンで削除された API バージョンがないか確認してください。該当する chart が見つかった場合は、サポートされている API バージョンを含む最新バージョンの chart を確認するか、自身で chart を更新してください。 さらに、デプロイ済みの chart（Helm release）についても監査し、非推奨または削除された API バージョンがないか確認する必要があります。`helm get manifest` コマンドを使用して release の詳細を取得できます。 サポートされている API への Helm release の更新方法は、調査結果に応じて以下のように異なります。 1. 非推奨の API バージョンのみが見つかった場合: - サポートされている Kubernetes API バージョンを含む chart で `helm upgrade` を実行します - アップグレード時の説明（description）に、現在のバージョンより前にはロールバックしないよう注意書きを追加します 2. 特定の Kubernetes バージョンで削除された API バージョンが見つかった場合: - API バージョンがまだ利用可能な Kubernetes バージョンを実行している場合（例: Kubernetes 1.15 を使用しており、Kubernetes 1.16 で削除される API を使用している場合）: - 手順 1 の方法に従います - すでに一部の API バージョンが利用不可となっている Kubernetes バージョンを実行している場合（例: `helm get manifest` で報告された API バージョンの一部が、現在の Kubernetes バージョンでは利用不可）: - クラスターに保存されている release マニフェストを編集し、API バージョンをサポートされている API に更新する必要があります。詳細は [Release マニフェストの API バージョンの更新](#release-マニフェストの-api-バージョンの更新)を参照してください > 注意: サポートされている API で Helm release を更新した後は、その更新バージョンより前のリリースバージョンには絶対にロールバックしないでください。 > 推奨: ベストプラクティスとして、非推奨の API バージョンを使用している release は、それらの API バージョンが削除される Kubernetes バージョンへのアップグレード前に、サポートされている API バージョンに更新してください。 上記の推奨手順で release を更新しない場合、API バージョンが削除された Kubernetes バージョンで release をアップグレードしようとすると、以下のようなエラーが発生します。 ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` このエラーが発生する理由は、Helm が現在デプロイされている release と、更新後の chart との間で差分パッチを作成しようとするためです。現在の release には、この Kubernetes バージョンで削除された API が含まれています。根本的な原因は、Kubernetes が API バージョンを削除すると、Kubernetes Go クライアントライブラリが非推奨のオブジェクトを解析できなくなることです。その結果、Helm はライブラリの呼び出し時に失敗します。残念ながら、Helm はこの状況から回復できず、該当する release を管理できなくなります。この状況からの回復方法については、[Release マニフェストの API バージョンの更新](#release-マニフェストの-api-バージョンの更新)を参照してください。 ## Release マニフェストの API バージョンの更新 マニフェストは Helm release オブジェクトのプロパティであり、クラスター内の Secret（デフォルト）または ConfigMap のデータフィールドに保存されます。データフィールドには、gzip 圧縮され base64 エンコードされたオブジェクトが含まれます（Secret の場合は追加の base64 エンコードがあります）。release の namespace 内には、release のバージョン/リビジョンごとに Secret/ConfigMap が存在します。 Helm の [mapkubeapis](https://github.com/helm/helm-mapkubeapis) プラグインを使用すると、release をサポートされている API に更新できます。詳細は readme を参照してください。 または、以下の手動手順に従って release マニフェストの API バージョンを更新することもできます。構成に応じて、Secret または ConfigMap バックエンドの手順に従ってください。 - 最新のデプロイ済み release に関連付けられた Secret または ConfigMap の名前を取得します: - Secret バックエンド: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap バックエンド: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - 最新のデプロイ済み release の詳細を取得します: - Secret バックエンド: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap バックエンド: `kubectl get configmap -n -o yaml > release.yaml` - 問題が発生した場合に復元できるよう、release をバックアップします: - `cp release.yaml release.bak` - 問題発生時は次のコマンドで復元します: `kubectl apply -f release.bak -n ` - release オブジェクトをデコードします: - Secret バックエンド: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap バックエンド: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - マニフェストの API バージョンを変更します。任意のツール（エディタなど）を使用できます。変更対象は、デコードした release オブジェクト（`release.data.decoded`）の `manifest` フィールドです - release オブジェクトをエンコードします: - Secret バックエンド: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap バックエンド: `cat release.data.decoded | gzip | base64` - デプロイ済み release ファイル（`release.yaml`）の `data.release` プロパティ値を、新しくエンコードした release オブジェクトで置き換えます - ファイルを namespace に適用します: `kubectl apply -f release.yaml -n ` - サポートされている Kubernetes API バージョンを含む chart で `helm upgrade` を実行します - アップグレード時の説明（description）に、現在のバージョンより前にはロールバックしないよう注意書きを追加します ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Kubernetes ディストリビューションガイド description: 特定の Kubernetes 環境での Helm の使用に関する情報をまとめています。 sidebar_position: 10 --- Helm は [CNCF 適合 Kubernetes](https://github.com/cncf/k8s-conformance)（[認定の有無](https://www.cncf.io/certification/software-conformance/)を問わず）で動作します。 このドキュメントでは、特定の Kubernetes 環境での Helm の使用に関する情報をまとめています。各ディストリビューションに関する情報の追加・更新にご協力いただけると幸いです。 ## AKS Helm は [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm) で動作します。 ## DC/OS Helm は Mesosphere の DC/OS 1.11 Kubernetes プラットフォームでテストされており、追加の設定なしで動作します。 ## EKS Helm は Amazon Elastic Kubernetes Service（Amazon EKS）で動作します。詳細は [Using Helm with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) を参照してください。 ## GKE Google の GKE ホステッド Kubernetes プラットフォームは、Helm で動作することが確認されており、追加の設定は不要です。 ## `scripts/local-cluster` と Hyperkube `scripts/local-cluster.sh` で構成された Hyperkube は動作することが確認されています。Hyperkube を直接使用する場合は、手動での設定が必要になることがあります。 ## IKS Helm は [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm) で動作します。 ## KIND（Kubernetes IN Docker） Helm は [KIND](https://github.com/kubernetes-sigs/kind) で定期的にテストされています。 ## KubeOne Helm は KubeOne によって構築されたクラスターで問題なく動作します。 ## Kubermatic Helm は Kubermatic によって作成されたユーザークラスターで問題なく動作します。シードクラスターはさまざまな方法で構築できるため、Helm のサポートはその構成に依存します。 ## MicroK8s Helm は [MicroK8s](https://microk8s.io) で以下のコマンドを使用して有効化できます。 `microk8s.enable helm3` ## Minikube Helm は [Minikube](https://github.com/kubernetes/minikube) でテストされており、動作することが確認されています。追加の設定は不要です。 ## Openshift Helm は OpenShift Online、OpenShift Dedicated、OpenShift Container Platform（バージョン 3.6 以上）、または OpenShift Origin（バージョン 3.6 以上）で問題なく動作します。詳細は[こちらのブログ記事](https://blog.openshift.com/getting-started-helm-openshift/)を参照してください。 ## Platform9 Helm は [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes) にプリインストールされています。Platform9 は App Catalog UI とネイティブの Kubernetes CLI を通じて、すべての公式 Helm chart へのアクセスを提供しています。追加のリポジトリを手動で追加することも可能です。詳細については、[Platform9 App Catalog に関する記事](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes)を参照してください。 ## Ubuntu と `kubeadm` `kubeadm` でブートストラップされた Kubernetes は、以下の Linux ディストリビューションで動作することが確認されています。 - Ubuntu 16.04 - Fedora release 25 Helm の一部のバージョン（v2.0.0-beta2）では、`export KUBECONFIG=/etc/kubernetes/admin.conf` を実行するか、`~/.kube/config` を作成する必要があります。 ## VMware Tanzu Kubernetes Grid Helm は VMware Tanzu Kubernetes Grid（TKG）で設定変更なしに動作します。Tanzu CLI は [helm-controller](https://fluxcd.io/flux/components/helm/) のパッケージインストールを管理でき、Helm chart リリースを宣言的に管理できます。詳細は TKG ドキュメントの [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5) を参照してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: ライブラリ chart description: ライブラリ chart の概要と使用例を説明します sidebar_position: 4 --- ライブラリ chart は、[Helm chart](/topics/charts.md) の一種で、他の chart の Helm テンプレートで共有できる chart プリミティブや定義を提供します。これにより、chart 間で再利用可能なコードスニペットを共有でき、繰り返しを避けて chart を [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) に保つことができます。 ライブラリ chart は Helm 3 で導入され、Helm 2 時代から chart メンテナーが使用してきた共通 chart やヘルパー chart を正式に認識するためのものです。chart タイプとして含めることで、以下のことが可能になります: - 共通 chart とアプリケーション chart を明確に区別する手段の提供 - 共通 chart のインストールを防止するロジック - リリースアーティファクトを含む可能性のある共通 chart 内のテンプレートをレンダリングしない - 依存 chart がインポーター側のコンテキストを使用できるようにする chart メンテナーは、共通 chart をライブラリ chart として定義できるようになり、Helm が標準的で一貫した方法で chart を処理することを確信できます。また、chart タイプを変更するだけで、アプリケーション chart 内の定義を共有できるようになります。 ## シンプルなライブラリ chart の作成 前述のとおり、ライブラリ chart は [Helm chart](/topics/charts.md) の一種です。つまり、スキャフォールド chart を作成することから始められます: ```console $ helm create mylibchart Creating mylibchart ``` この例では独自のテンプレート定義を作成するため、まず `templates` ディレクトリ内のすべてのファイルを削除します。 ```console $ rm -rf mylibchart/templates/* ``` values ファイルも不要です。 ```console $ rm -f mylibchart/values.yaml ``` 共通コードの作成に入る前に、関連する Helm の概念を簡単に確認しておきましょう。[名前付きテンプレート](/chart_template_guide/named_templates.md)（パーシャルまたはサブテンプレートとも呼ばれます）は、ファイル内で定義され、名前が付けられたテンプレートです。`templates/` ディレクトリでは、アンダースコア（`_`）で始まるファイルは Kubernetes マニフェストファイルを出力しないことが期待されます。そのため、慣例としてヘルパーテンプレートやパーシャルは `_*.tpl` または `_*.yaml` ファイルに配置されます。 この例では、空の ConfigMap リソースを作成する共通 ConfigMap をコーディングします。共通 ConfigMap を `mylibchart/templates/_configmap.yaml` ファイルに以下のように定義します: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` ConfigMap 構造体は名前付きテンプレート `mylibchart.configmap.tpl` で定義されています。これは空のリソース `data` を持つシンプルな ConfigMap です。このファイル内には `mylibchart.configmap` という別の名前付きテンプレートがあります。この名前付きテンプレートは `mylibchart.util.merge` という別の名前付きテンプレートをインクルードし、2 つの名前付きテンプレートを引数として受け取ります: `mylibchart.configmap` を呼び出すテンプレートと `mylibchart.configmap.tpl` です。 ヘルパー関数 `mylibchart.util.merge` は `mylibchart/templates/_util.yaml` にある名前付きテンプレートです。これは [The Common Helm Helper Chart](#the-common-helm-helper-chart) からの便利なユーティリティで、2 つのテンプレートをマージし、両方に共通する部分をオーバーライドします: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` これは、chart が自身の設定でカスタマイズする必要のある共通コードを使用したい場合に重要です。 最後に、chart タイプを `library` に変更します。`mylibchart/Chart.yaml` を以下のように編集する必要があります: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` ライブラリ chart は共有の準備ができ、その ConfigMap 定義を再利用できるようになりました。 先に進む前に、Helm がこの chart をライブラリ chart として認識しているかどうかを確認する価値があります: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## シンプルなライブラリ chart の使用 ライブラリ chart を使用する番です。これは再度スキャフォールド chart を作成することを意味します: ```console $ helm create mychart Creating mychart ``` ConfigMap のみを作成したいので、テンプレートファイルを再度クリーンアップします: ```console $ rm -rf mychart/templates/* ``` Helm テンプレートでシンプルな ConfigMap を作成する場合、以下のようになります: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` しかし、ここでは `mylibchart` で作成済みの共通コードを再利用します。ConfigMap は `mychart/templates/configmap.yaml` ファイルに以下のように作成できます: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` ConfigMap の標準プロパティを追加する共通 ConfigMap 定義を継承することで、作業が簡略化されていることがわかります。テンプレートでは設定（この場合は data キー `myvalue` とその値）を追加しています。この設定は共通 ConfigMap の空のリソースをオーバーライドします。これは前のセクションで説明したヘルパー関数 `mylibchart.util.merge` によって実現されています。 共通コードを使用するには、`mylibchart` を依存関係として追加する必要があります。`mychart/Chart.yaml` ファイルの末尾に以下を追加します: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` これにより、アプリケーション chart と同じ親パスにあるファイルシステムから、ライブラリ chart が動的依存関係としてインクルードされます。ライブラリ chart を動的依存関係としてインクルードしているため、`helm dependency update` を実行する必要があります。これにより、ライブラリ chart が `charts/` ディレクトリにコピーされます。 ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` chart をデプロイする準備ができました。インストール前に、まずレンダリングされたテンプレートを確認する価値があります。 ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` これは `myvalue: Hello World` のデータオーバーライドを持つ、期待どおりの ConfigMap です。インストールしましょう: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` release を取得して、実際のテンプレートがロードされたことを確認できます。 ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## ライブラリ chart の利点 ライブラリ chart はスタンドアロン chart として動作できないため、以下の機能を活用できます: - `.Files` オブジェクトは、ライブラリ chart のローカルパスではなく、親 chart のファイルパスを参照します - `.Values` オブジェクトは親 chart と同じです。これは、親の設定でヘッダー以下に設定された values セクションを受け取るアプリケーション [subchart](/chart_template_guide/subcharts_and_globals.md) とは対照的です ## The Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` この [chart](https://github.com/helm/charts/tree/master/incubator/common) は、共通 chart の元となったパターンです。Kubernetes chart 開発のベストプラクティスを反映したユーティリティを提供します。最大の利点は、chart を開発する際にすぐに使用でき、便利な共有コードを利用できることです。 ここでは簡単な使用方法を示します。詳細については、[README](https://github.com/helm/charts/blob/master/incubator/common/README.md) を参照してください。 再度スキャフォールド chart を作成します: ```console $ helm create demo Creating demo ``` ヘルパー chart の共通コードを使用しましょう。まず、deployment の `demo/templates/deployment.yaml` を以下のように編集します: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` 次に、service ファイル `demo/templates/service.yaml` を以下のように編集します: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` これらのテンプレートは、ヘルパー chart から共通コードを継承することで、コーディングがリソースの設定やカスタマイズに簡略化されることを示しています。 共通コードを使用するには、`common` を依存関係として追加する必要があります。`demo/Chart.yaml` ファイルの末尾に以下を追加します: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` 注意: Helm リポジトリリストに `incubator` リポジトリを追加する必要があります（`helm repo add`）。 chart を動的依存関係としてインクルードしているため、`helm dependency update` を実行する必要があります。これにより、ヘルパー chart が `charts/` ディレクトリにコピーされます。 ヘルパー chart は一部の Helm 2 構造を使用しているため、Helm 3 のスキャフォールド chart で更新された `nginx` イメージをロードできるように、`demo/values.yaml` に以下を追加する必要があります: ```yaml image: tag: 1.16.0 ``` デプロイ前に `helm lint` と `helm template` コマンドを使用して、chart テンプレートが正しいかテストできます。 問題なければ、`helm install` でデプロイしてください！ ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: SQL ストレージバックエンドの権限管理 description: SQL ストレージバックエンドを使用する際の権限設定方法について説明します。 --- このドキュメントでは、SQL ストレージバックエンドにおける権限の設定と管理について説明します。 ## はじめに Helm は権限管理に Kubernetes の RBAC 機能を利用しています。ただし、SQL ストレージバックエンドを使用する場合、Kubernetes の Role ではユーザーが特定のリソースにアクセスできるかどうかを判断できません。このドキュメントでは、これらの権限を作成・管理する方法を説明します。 ## 初期化 Helm CLI が初めてデータベースに接続するとき、クライアントは初期化済みかどうかを確認します。未初期化の場合は、必要なセットアップを自動的に実行します。この初期化には、public スキーマに対する管理者権限、または少なくとも以下の権限が必要です: * テーブルの作成 * public スキーマに対する権限の付与 データベースに対してマイグレーションを実行した後は、他のすべてのロールでクライアントを使用できます。 ## PostgreSQL で管理者以外のユーザーに権限を付与する 権限管理のために、SQL バックエンドドライバは PostgreSQL の [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)（Row Level Security: 行レベルセキュリティ）機能を利用しています。RLS により、すべてのユーザーが同じテーブルに対して読み書きできますが、明示的に許可されていない行は操作できません。デフォルトでは、適切な権限が付与されていないロールは、`helm list` を実行しても空のリストが返され、クラスター内のリソースを取得・変更することはできません。 以下に、特定のロールに特定の namespace へのアクセス権を付与する方法を示します: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` このコマンドは、`namespace = 'default'` の条件を満たすすべてのリソースに対して、ロール `` に読み取りおよび書き込み権限を付与します。このポリシーを作成すると、ロール `` としてデータベースに接続しているユーザーは、`helm list` で `default` namespace 内のすべての release を確認でき、それらを変更・削除できるようになります。 RLS では、テーブルのカラムに基づいて権限をより細かく管理することも可能です: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Helm プラグインガイド description: Helm の機能を拡張するプラグインの使い方と作成方法を紹介します。 sidebar_position: 12 --- Helm プラグインは、`helm` CLI からアクセスできるツールですが、Helm 本体のコードベースには含まれていません。 既存のプラグインは、[関連プロジェクト](/community/related#helm-plugins)セクションや [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) で検索して見つけることができます。 このガイドでは、プラグインの使い方と作成方法を説明します。 ## 概要 Helm プラグインは、Helm とシームレスに統合されるアドオンツールです。Helm のコア機能を拡張する手段を提供しますが、すべての新機能を Go で記述してコアツールに追加する必要はありません。 Helm プラグインには以下の特徴があります: - コアの Helm ツールに影響を与えることなく、Helm インストールに追加・削除できます。 - 任意のプログラミング言語で記述できます。 - Helm と統合され、`helm help` やその他の場所に表示されます。 Helm プラグインは `$HELM_PLUGINS` に配置されます。この値は、環境変数が設定されていない場合のデフォルト値を含めて、`helm env` コマンドで確認できます。 Helm のプラグインモデルは、Git のプラグインモデルを部分的にベースにしています。そのため、`helm` を _porcelain_（磁器）層、プラグインを _plumbing_（配管）と呼ぶことがあります。これは、Helm がユーザー向けのインターフェースと全体的な処理ロジックを提供し、プラグインが目的のアクションを実行する「詳細な作業」を担当することを端的に表しています。 ## プラグインのインストール プラグインは `$ helm plugin install ` コマンドでインストールします。ローカルファイルシステム上のプラグインへのパスか、リモート VCS リポジトリの URL を指定できます。`helm plugin install` コマンドは、指定されたパス/URL のプラグインを `$HELM_PLUGINS` にクローンまたはコピーします。VCS からインストールする場合は、`--version` 引数でバージョンを指定できます。 ```console $ helm plugin install https://github.com/adamreese/helm-env ``` プラグインの tar 配布物がある場合は、`$HELM_PLUGINS` ディレクトリに解凍するだけです。`helm plugin install https://domain/path/to/plugin.tar.gz` を実行すると、URL から tarball プラグインを直接インストールすることもできます。 ## プラグインのファイル構造 多くの点で、プラグインは chart に似ています。各プラグインには、`plugin.yaml` ファイルを含むトップレベルディレクトリがあります。その他のファイルも存在できますが、必須なのは `plugin.yaml` ファイルのみです。 ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## plugin.yaml ファイル plugin.yaml ファイルはプラグインに必須です。以下のフィールドが含まれます: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### `name` フィールド `name` はプラグインの名前です。Helm がこのプラグインを実行するとき、この名前が使用されます（例: `helm NAME` でこのプラグインが呼び出されます）。 _`name` はディレクトリ名と一致する必要があります。_ 上記の例では、`name: last` を持つプラグインは `last` という名前のディレクトリに格納する必要があります。 `name` の制約: - `name` は既存の `helm` トップレベルコマンドと重複できません。 - `name` は ASCII 文字 a-z、A-Z、0-9、`_`、`-` に制限されます。 ### `version` フィールド `version` はプラグインの SemVer 2 バージョンです。`usage` と `description` は両方ともコマンドのヘルプテキスト生成に使用されます。 ### `ignoreFlags` フィールド `ignoreFlags` スイッチは、Helm にフラグをプラグインに渡さ _ない_ よう指示します。プラグインが `helm myplugin --foo` で呼び出され、`ignoreFlags: true` の場合、`--foo` は静かに破棄されます。 ### `platformCommand` フィールド `platformCommand` は、プラグインが呼び出されたときに実行するコマンドを設定します。`platformCommand` と `command` の両方を設定するとエラーになります。使用するコマンドを決定する際には、以下のルールが適用されます: - `platformCommand` が存在する場合、それが使用されます。 - `os` と `arch` の両方が現在のプラットフォームに一致する場合、検索は停止し、そのコマンドが使用されます。 - `os` が一致し、`arch` が空の場合、そのコマンドが使用されます。 - `os` と `arch` の両方が空の場合、そのコマンドが使用されます。 - 一致するものがない場合、Helm はエラーで終了します。 - `platformCommand` が存在せず、非推奨の `command` が存在する場合、それが使用されます。 - コマンドが空の場合、Helm はエラーで終了します。 ### `platformHooks` フィールド `platformHooks` は、ライフサイクルイベントに対してプラグインが実行するコマンドを設定します。`platformHooks` と `hooks` の両方を設定するとエラーになります。使用するフックコマンドを決定する際には、以下のルールが適用されます: - `platformHooks` が存在する場合、それが使用され、ライフサイクルイベントのコマンドが処理されます。 - `os` と `arch` の両方が現在のプラットフォームに一致する場合、検索は停止し、そのコマンドが使用されます。 - `os` が一致し、`arch` が空の場合、そのコマンドが使用されます。 - `os` と `arch` の両方が空の場合、そのコマンドが使用されます。 - 一致するものがない場合、Helm はそのイベントをスキップします。 - `platformHooks` が存在せず、非推奨の `hooks` が存在する場合、ライフサイクルイベントのコマンドが使用されます。 - コマンドが空の場合、Helm はそのイベントをスキップします。 ## プラグインのビルド 最後の release 名を取得するシンプルなプラグインの plugin YAML を以下に示します: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` プラグインには追加のスクリプトや実行可能ファイルが必要な場合があります。 スクリプトはプラグインディレクトリに含めることができ、実行可能ファイルはフックを介してダウンロードできます。以下はプラグインの例です: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` 環境変数はプラグインの実行前に展開されます。上記のパターンは、プラグインの実行ファイルの場所を指定する推奨パターンです。 ### プラグインコマンド プラグインコマンドを扱うためのいくつかの戦略があります: - プラグインに実行可能ファイルが含まれる場合、`platformCommand:` 用の実行可能ファイルはプラグインディレクトリにパッケージ化するか、フックを介してインストールする必要があります。 - `platformCommand:` または `command:` 行は、実行前に環境変数が展開されます。`$HELM_PLUGIN_DIR` はプラグインディレクトリを指します。 - コマンド自体はシェルで実行されません。したがって、シェルスクリプトを 1 行で記述することはできません。 - Helm は多くの設定を環境変数に注入します。利用可能な情報については環境を確認してください。 - Helm はプラグインの言語について何も仮定しません。好みの言語で記述できます。 - コマンドは `-h` と `--help` 用の特定のヘルプテキストを実装する責任があります。Helm は `helm help` と `helm help myplugin` に対して `usage` と `description` を使用しますが、`helm myplugin --help` は処理しません。 ### ローカルプラグインのテスト まず、`HELM_PLUGINS` パスを見つける必要があります。以下のコマンドを実行してください: ``` bash helm env ``` カレントディレクトリを `HELM_PLUGINS` が設定されているディレクトリに変更します。 これで、プラグインのビルド出力へのシンボリックリンクを追加できます。この例では `mapkubeapis` の場合を示しています。 ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## ダウンローダープラグイン デフォルトでは、Helm は HTTP/S を使用して chart を取得できます。Helm 2.4.0 以降、プラグインは任意のソースから chart をダウンロードする特別な機能を持つことができます。 プラグインは、この特別な機能を `plugin.yaml` ファイル（トップレベル）で宣言します: ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` このようなプラグインがインストールされている場合、Helm は指定されたプロトコルスキームを使用して `command` を呼び出し、リポジトリとやり取りできます。特別なリポジトリは、通常のリポジトリと同様に追加します: `helm repo add favorite myprotocol://example.com/`。特別なリポジトリのルールは通常のリポジトリと同じです: Helm は利用可能な chart のリストを検出してキャッシュするために `index.yaml` ファイルをダウンロードできる必要があります。 定義されたコマンドは次のスキームで呼び出されます: `command certFile keyFile caFile full-URL`。SSL 認証情報は、`$HELM_REPOSITORY_CONFIG`（つまり、`$HELM_CONFIG_HOME/repositories.yaml`）に保存されているリポジトリ定義から取得されます。ダウンローダープラグインは、生のコンテンツを標準出力にダンプし、エラーを標準エラー出力に報告することが期待されます。 ダウンローダーコマンドはサブコマンドや引数もサポートしており、`plugin.yaml` で `bin/mydownloader subcommand -d` のように指定できます。これは、メインプラグインコマンドとダウンローダーコマンドで同じ実行可能ファイルを使用したいが、それぞれに異なるサブコマンドを使用したい場合に便利です。 ## 環境変数 Helm がプラグインを実行するとき、外部環境をプラグインに渡し、さらにいくつかの追加環境変数を注入します。 `KUBECONFIG` などの変数は、外部環境で設定されている場合、プラグインに設定されます。 以下の変数は常に設定されることが保証されています: - `HELM_PLUGINS`: プラグインディレクトリへのパス。 - `HELM_PLUGIN_NAME`: `helm` によって呼び出されたプラグインの名前。`helm myplug` の場合、短縮名は `myplug` になります。 - `HELM_PLUGIN_DIR`: プラグインが格納されているディレクトリ。 - `HELM_BIN`: `helm` コマンドへのパス（ユーザーが実行したもの）。 - `HELM_DEBUG`: helm でデバッグフラグが設定されているかどうかを示します。 - `HELM_REGISTRY_CONFIG`: レジストリ設定の場所（使用している場合）。Helm でのレジストリの使用は実験的な機能です。 - `HELM_REPOSITORY_CACHE`: リポジトリキャッシュファイルへのパス。 - `HELM_REPOSITORY_CONFIG`: リポジトリ設定ファイルへのパス。 - `HELM_NAMESPACE`: `helm` コマンドに指定された namespace（通常は `-n` フラグを使用）。 - `HELM_KUBECONTEXT`: `helm` コマンドに指定された Kubernetes 設定コンテキストの名前。 さらに、Kubernetes 設定ファイルが明示的に指定されている場合、`KUBECONFIG` 変数として設定されます。 ## フラグ解析に関する注意 プラグインを実行するとき、Helm は自身が使用するためにグローバルフラグを解析します。これらのフラグはプラグインに渡されません。 - `--burst-limit`: `$HELM_BURST_LIMIT` に変換されます - `--debug`: これが指定されると、`$HELM_DEBUG` が `1` に設定されます - `--kube-apiserver`: `$HELM_KUBEAPISERVER` に変換されます - `--kube-as-group`: `$HELM_KUBEASGROUPS` に変換されます - `--kube-as-user`: `$HELM_KUBEASUSER` に変換されます - `--kube-ca-file`: `$HELM_KUBECAFILE` に変換されます - `--kube-context`: `$HELM_KUBECONTEXT` に変換されます - `--kube-insecure-skip-tls-verify`: `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` に変換されます - `--kube-tls-server-name`: `$HELM_KUBETLS_SERVER_NAME` に変換されます - `--kube-token`: `$HELM_KUBETOKEN` に変換されます - `--kubeconfig`: `$KUBECONFIG` に変換されます - `--namespace` と `-n`: `$HELM_NAMESPACE` に変換されます - `--qps`: `$HELM_QPS` に変換されます - `--registry-config`: `$HELM_REGISTRY_CONFIG` に変換されます - `--repository-cache`: `$HELM_REPOSITORY_CACHE` に変換されます - `--repository-config`: `$HELM_REPOSITORY_CONFIG` に変換されます プラグインは `-h` と `--help` に対してヘルプテキストを表示して終了 _すべきです_。その他のすべての場合、プラグインは適切にフラグを使用できます。 ## シェル自動補完の提供 Helm 3.2 以降、プラグインは Helm の既存の自動補完メカニズムの一部として、オプションでシェル自動補完をサポートできます。 ### 静的自動補完 プラグインが独自のフラグやサブコマンドを提供する場合、プラグインのルートディレクトリに `completion.yaml` ファイルを配置することで、Helm に通知できます。`completion.yaml` ファイルの形式は以下のとおりです: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` 注意事項: 1. すべてのセクションはオプションですが、該当する場合は記述してください。 1. フラグには `-` または `--` プレフィックスを含めないでください。 1. 短いフラグと長いフラグの両方を指定できます（また、指定すべきです）。短いフラグは対応する長い形式に関連付ける必要はありませんが、両方の形式をリストする必要があります。 1. フラグは特定の順序で並べる必要はありませんが、ファイルのサブコマンド階層の正しい位置にリストする必要があります。 1. Helm の既存のグローバルフラグは Helm の自動補完メカニズムですでに処理されているため、プラグインは `--debug`、`--namespace` または `-n`、`--kube-context`、`--kubeconfig`、およびその他のグローバルフラグを指定する必要はありません。 1. `validArgs` リストは、サブコマンドの後に続く最初のパラメータに対して可能な補完の静的リストを提供します。このようなリストを事前に提供できない場合もあります（以下の[動的補完](#動的補完)セクションを参照）。その場合、`validArgs` セクションは省略できます。 `completion.yaml` ファイルは完全にオプションです。提供されていない場合、Helm はプラグインに対してシェル自動補完を提供しません（プラグインが[動的補完](#動的補完)をサポートしている場合を除く）。また、`completion.yaml` ファイルを追加しても後方互換性があり、古いバージョンの Helm を使用している場合でもプラグインの動作に影響しません。 例として、[`fullstatus` プラグイン](https://github.com/marckhouzam/helm-fullstatus)はサブコマンドを持ちませんが、`helm status` コマンドと同じフラグを受け入れます。その `completion.yaml` ファイルは以下のとおりです: ```yaml name: fullstatus flags: - o - output - revision ``` より複雑な例として、[`2to3` プラグイン](https://github.com/helm/helm-2to3)の `completion.yaml` ファイルは以下のとおりです: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### 動的補完 Helm 3.2 以降、プラグインは独自の動的シェル自動補完を提供できます。動的シェル自動補完は、事前に定義できないパラメータ値やフラグ値の補完です。たとえば、クラスター上で現在利用可能な Helm release 名の補完などです。 プラグインが動的自動補完をサポートするには、ルートディレクトリに `plugin.complete` という**実行可能**ファイルを提供する必要があります。Helm の補完スクリプトがプラグインに対して動的補完を必要とする場合、`plugin.complete` ファイルを実行し、補完が必要なコマンドラインを渡します。`plugin.complete` 実行可能ファイルは、適切な補完候補を決定し、Helm の補完スクリプトが使用するために標準出力に出力するロジックを持つ必要があります。 `plugin.complete` ファイルは完全にオプションです。提供されていない場合、Helm はプラグインに対して動的自動補完を提供しません。また、`plugin.complete` ファイルを追加しても後方互換性があり、古いバージョンの Helm を使用している場合でもプラグインの動作に影響しません。 `plugin.complete` スクリプトの出力は、以下のような改行区切りのリストである必要があります: ```console rel1 rel2 rel3 ``` `plugin.complete` が呼び出されると、プラグインのメインスクリプトが呼び出されるときと同様にプラグイン環境が設定されます。したがって、`$HELM_NAMESPACE`、`$HELM_KUBECONTEXT`、およびその他すべてのプラグイン変数はすでに設定されており、対応するグローバルフラグは削除されています。 `plugin.complete` ファイルは任意の実行可能形式にできます。シェルスクリプト、Go プログラム、または Helm が実行できるその他の種類のプログラムにできます。`plugin.complete` ファイルは、ユーザーに対する実行権限を持って ***いなければなりません***。`plugin.complete` ファイルは成功コード（値 0）で終了 ***しなければなりません***。 場合によっては、動的補完で Kubernetes クラスターから情報を取得する必要があります。たとえば、`helm fullstatus` プラグインは入力として release 名を必要とします。`fullstatus` プラグインでは、`plugin.complete` スクリプトが現在の release 名の補完を提供するために、単純に `helm list -q` を実行して結果を出力できます。 プラグインの実行とプラグインの補完に同じ実行可能ファイルを使用したい場合、`plugin.complete` スクリプトは特別なパラメータやフラグを付けてメインプラグイン実行可能ファイルを呼び出すことができます。メインプラグイン実行可能ファイルが特別なパラメータやフラグを検出すると、補完を実行することがわかります。この例では、`plugin.complete` を以下のように実装できます: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` `fullstatus` プラグインの実際のスクリプト（`status.sh`）は `--complete` フラグを探し、見つかった場合は適切な補完を出力する必要があります。 ### ヒントとコツ 1. シェルはユーザー入力に一致しない補完候補を自動的にフィルタリングします。したがって、プラグインはユーザー入力に一致しないものを削除せずに、関連するすべての補完を返すことができます。たとえば、コマンドラインが `helm fullstatus ngin` の場合、`plugin.complete` スクリプトは（`default` namespace の）*すべての* release 名を出力できます。`ngin` で始まるものだけではありません。シェルは `ngin` で始まるものだけを残します。 1. 動的補完サポートを簡素化するために、特に複雑なプラグインの場合、`plugin.complete` スクリプトでメインプラグインスクリプトを呼び出して補完候補を要求できます。上記の[動的補完](#動的補完)セクションの例を参照してください。 1. 動的補完と `plugin.complete` ファイルをデバッグするには、以下を実行して補完結果を確認できます: - `helm __complete `。例: - `helm __complete fullstatus --output js` - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Helm の来歴と完全性 description: chart の完全性と出所を検証する方法について説明します。 sidebar_position: 5 --- Helm は、chart ユーザーがパッケージの完全性と出所を検証するための来歴検証ツールを備えています。PKI、GnuPG、および定評のあるパッケージマネージャーに基づいた業界標準のツールを使用して、署名ファイルの生成と検証を行えます。 ## 概要 完全性は、chart と来歴レコードを比較することで確立されます。来歴レコードは、パッケージ化された chart と一緒に保存される _来歴ファイル_ に保存されます。たとえば、chart の名前が `myapp-1.2.3.tgz` の場合、その来歴ファイルは `myapp-1.2.3.tgz.prov` になります。 来歴ファイルはパッケージング時に生成され（`helm package --sign ...`）、複数のコマンド（特に `helm install --verify`）で検証できます。 ## ワークフロー このセクションでは、来歴データを効果的に使用するための一般的なワークフローについて説明します。 前提条件: - バイナリ形式（ASCII-armored 形式ではない）の有効な PGP 鍵ペア - `helm` コマンドラインツール - GnuPG コマンドラインツール（オプション） - Keybase コマンドラインツール（オプション） **注意:** PGP 秘密鍵にパスフレーズが設定されている場合、`--sign` オプションをサポートするコマンドを実行するときにパスフレーズの入力を求められます。 新しい chart の作成方法は従来と同じです: ```console $ helm create mychart Creating mychart ``` パッケージ化の準備ができたら、`helm package` に `--sign` フラグを追加します。また、署名鍵の名前と、対応する秘密鍵を含むキーリングを指定します: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **注意:** `--key` 引数の値は、目的の鍵の `uid`（`gpg --list-keys` の出力に表示される）の部分文字列である必要があります。たとえば、名前やメールアドレスです。**フィンガープリントは使用できません。** **TIP:** GnuPG ユーザーの場合、秘密キーリングは `~/.gnupg/secring.gpg` にあります。`gpg --list-secret-keys` を使用して、利用可能な鍵の一覧を表示できます。 **警告:** GnuPG v2 では、秘密キーリングがデフォルトの場所 `~/.gnupg/pubring.kbx` に新しい `kbx` 形式で保存されます。次のコマンドを使用して、キーリングを従来の gpg 形式に変換してください: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` この時点で、`mychart-0.1.0.tgz` と `mychart-0.1.0.tgz.prov` の両方のファイルが作成されているはずです。両方のファイルを最終的に目的の chart リポジトリにアップロードします。 `helm verify` を使用して chart を検証できます: ```console $ helm verify mychart-0.1.0.tgz ``` 検証に失敗すると、次のようになります: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` インストール時に検証するには、`--verify` フラグを使用します。 ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` 署名済み chart に関連付けられた公開鍵を含むキーリングがデフォルトの場所にない場合は、`helm package` の例と同様に `--keyring PATH` でキーリングを指定する必要があります。 検証に失敗すると、chart がレンダリングされる前にインストールが中止されます。 ### Keybase.io 認証情報の使用 [Keybase.io](https://keybase.io) サービスを使用すると、暗号化 ID の信頼チェーンを簡単に確立できます。Keybase の認証情報を使用して chart に署名できます。 前提条件: - 設定済みの Keybase.io アカウント - ローカルにインストールされた GnuPG - ローカルにインストールされた `keybase` CLI #### パッケージへの署名 最初のステップは、Keybase の鍵をローカルの GnuPG キーリングにインポートすることです: ```console $ keybase pgp export -s | gpg --import ``` このコマンドは、Keybase の鍵を OpenPGP 形式に変換し、ローカルの `~/.gnupg/secring.gpg` ファイルにインポートします。 `gpg --list-secret-keys` を実行して確認できます。 ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` 秘密鍵には次のような識別子文字列があります: ``` technosophos (keybase.io/technosophos) ``` これが鍵のフルネームです。 次に、`helm package` を使用して chart をパッケージ化し、署名できます。`--key` には、この名前文字列の少なくとも一部を使用してください。 ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` その結果、`package` コマンドは `.tgz` ファイルと `.tgz.prov` ファイルの両方を生成します。 #### パッケージの検証 同様の手順で、他のユーザーの Keybase 鍵で署名された chart を検証することもできます。たとえば、`keybase.io/technosophos` によって署名されたパッケージを検証する場合は、`keybase` ツールを使用します: ```console $ keybase follow technosophos $ keybase pgp pull ``` 上記の最初のコマンドは、ユーザー `technosophos` をフォローします。次に `keybase pgp pull` を実行すると、フォローしているすべてのアカウントの OpenPGP 鍵がダウンロードされ、GnuPG キーリング（`~/.gnupg/pubring.gpg`）に配置されます。 この時点で、`helm verify` または `--verify` フラグを持つコマンドを使用できるようになります: ```console $ helm verify somechart-1.2.3.tgz ``` ### chart が検証できない理由 検証が失敗する一般的な理由を以下に示します。 - `.prov` ファイルが見つからないか、破損しています。これは、何かが正しく設定されていないか、元のメンテナが来歴ファイルを作成しなかったことを示します。 - ファイルの署名に使用された鍵がキーリングにありません。これは、chart に署名したエンティティが、信頼すると表明した相手ではないことを示します。 - `.prov` ファイルの検証に失敗しました。これは、chart または来歴データに問題があることを示します。 - 来歴ファイル内のファイルハッシュがアーカイブファイルのハッシュと一致しません。これは、アーカイブが改ざんされたことを示します。 検証に失敗した場合は、そのパッケージを信頼しない理由があります。 ## 来歴ファイル 来歴ファイルには、chart の YAML ファイルといくつかの検証情報が含まれています。来歴ファイルは自動的に生成されるように設計されています。 以下の来歴データが追加されます: * chart ファイル（`Chart.yaml`）が含まれており、人間とツールの両方が chart の内容を簡単に確認できます。 * chart パッケージ（`.tgz` ファイル）の署名（Docker と同様の SHA256）が含まれており、chart パッケージの完全性を検証するために使用できます。 * 本文全体が OpenPGP で使用されるアルゴリズムで署名されています（暗号署名と検証を簡単にする新しい方法については [Keybase.io](https://keybase.io) を参照してください）。 これらの組み合わせにより、ユーザーは以下のことを保証されます: * パッケージ自体が改ざんされていないこと（パッケージ `.tgz` のチェックサム）。 * このパッケージをリリースしたエンティティが既知であること（GnuPG/PGP 署名による）。 ファイルの形式は次のようになります: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` YAML セクションには 2 つのドキュメントが含まれています（`...\n` で区切られています）。最初のファイルは `Chart.yaml` の内容です。2 番目はチェックサムで、パッケージング時のファイル名とそのファイル内容の SHA-256 ダイジェストのマップです。 署名ブロックは標準の PGP 署名であり、[改ざん耐性](https://www.rossde.com/PGP/pgp_signatures.html)を提供します。 ## Chart リポジトリ Chart リポジトリは、Helm chart の集約された集合として機能します。 Chart リポジトリは、特定のリクエストを介して HTTP 経由で来歴ファイルを提供できる必要があり、chart と同じ URI パスで利用可能にする必要があります。 たとえば、パッケージのベース URL が `https://example.com/charts/mychart-1.2.3.tgz` の場合、来歴ファイルが存在する場合は `https://example.com/charts/mychart-1.2.3.tgz.prov` でアクセスできる必要があります。 エンドユーザーの観点から、`helm install --verify myrepo/mychart-1.2.3` を実行すると、追加のユーザー設定やアクションなしに chart と来歴ファイルの両方がダウンロードされます。 ### OCI ベースのレジストリでの署名 chart を [OCI ベースのレジストリ](/topics/registries.md)に公開する場合、[`helm-sigstore` プラグイン](https://github.com/sigstore/helm-sigstore/)を使用して来歴を [sigstore](https://sigstore.dev/) に公開できます。[ドキュメントに記載されているとおり](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)、来歴の作成と GPG 鍵による署名のプロセスは一般的ですが、`helm sigstore upload` コマンドを使用して来歴を不変の透明性ログに公開できます。 ## 権威と真正性の確立 信頼チェーンシステムを扱う場合、署名者の権威を確立できることが重要です。言い換えれば、上記のシステムは、chart に署名した人を信頼するという事実に基づいています。つまり、署名者の公開鍵を信頼する必要があります。 Helm の設計上の決定の 1 つとして、Helm プロジェクトは信頼チェーンに必須の当事者として介入しないことにしました。すべての chart 署名者の「認証局」にはなりたくありません。代わりに、分散型モデルを強く支持しており、これが OpenPGP を基盤技術として選択した理由の一部です。そのため、権威の確立に関しては、Helm 2 ではこのステップをほぼ未定義のままにしています（この決定は Helm 3 にも引き継がれています）。 ただし、来歴システムの使用に興味がある方のために、いくつかのヒントと推奨事項を示します: - [Keybase](https://keybase.io) プラットフォームは、信頼情報の公開集中リポジトリを提供します。 - Keybase を使用して鍵を保存したり、他のユーザーの公開鍵を取得したりできます。 - Keybase には充実したドキュメントも用意されています。 - 検証していませんが、Keybase の「セキュアウェブサイト」機能を使用して Helm chart を配布できる可能性があります。 - 基本的な考え方は、公式の「chart レビュアー」が自分の鍵で chart に署名し、その来歴ファイルを chart リポジトリにアップロードするというものです。 - リポジトリの `index.yaml` ファイルに有効な署名鍵のリストを含めるというアイデアについて、検討が進められています。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: ロールベースアクセス制御 description: Helm と Kubernetes のロールベースアクセス制御（RBAC）との連携について説明します。 sidebar_position: 11 --- Kubernetes では、ユーザーやアプリケーション固有のサービスアカウントにロールを付与することが推奨されます。これにより、アプリケーションを意図した範囲内で動作させることができます。サービスアカウントの権限については、[Kubernetes 公式ドキュメント](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)を参照してください。 Kubernetes 1.6 以降、ロールベースアクセス制御（RBAC）はデフォルトで有効になっています。RBAC を使用すると、ユーザーとその組織内でのロールに応じて、許可されるアクションの種類を指定できます。 RBAC を使用すると、以下のことが可能です: - 管理者に特権操作（クラスター全体のリソース作成、新しいロールの作成など）を付与する - ユーザーがリソース（Pod、PersistentVolume、Deployment など）を作成できる範囲を、特定の namespace またはクラスター全体のスコープ（ResourceQuota、Role、CustomResourceDefinition）に制限する - ユーザーがリソースを参照できる範囲を、特定の namespace またはクラスター全体のスコープに制限する このガイドは、ユーザーと Kubernetes API のやり取りの範囲を制限したい管理者向けです。 ## ユーザーアカウントの管理 すべての Kubernetes クラスターには、2 種類のユーザーカテゴリがあります: Kubernetes が管理するサービスアカウントと、通常のユーザーです。 通常のユーザーは、外部の独立したサービスによって管理されることが想定されています。たとえば、秘密鍵を配布する管理者、Keystone や Google アカウントなどのユーザーストア、ユーザー名とパスワードを記載したファイルなどが該当します。そのため、Kubernetes には通常のユーザーアカウントを表すオブジェクトがありません。通常のユーザーは API 呼び出しでクラスターに追加することができません。 一方、サービスアカウントは Kubernetes API によって管理されるユーザーです。サービスアカウントは特定の namespace にバインドされ、API サーバーによって自動的に作成されるか、API 呼び出しによって手動で作成されます。サービスアカウントは、Secret として保存された認証情報のセットに紐付けられています。この Secret は Pod にマウントされ、クラスター内のプロセスが Kubernetes API と通信できるようにします。 API リクエストは、通常のユーザーまたはサービスアカウントに紐付けられるか、匿名リクエストとして扱われます。つまり、ワークステーションで `kubectl` を入力する人間のユーザーから、ノード上の kubelet、コントロールプレーンのメンバーに至るまで、クラスター内外のすべてのプロセスは、API サーバーへのリクエスト時に認証を行う必要があります。認証しない場合は匿名ユーザーとして扱われます。 ## Role、ClusterRole、RoleBinding、ClusterRoleBinding Kubernetes では、ユーザーアカウントとサービスアカウントは、アクセスを付与されたリソースのみを参照および編集できます。このアクセスは、Role と RoleBinding を使用して付与されます。Role と RoleBinding は特定の namespace にバインドされ、その Role がアクセス権を提供する namespace 内のリソースを参照または編集する機能をユーザーに付与します。 クラスタースコープでは、これらは ClusterRole と ClusterRoleBinding と呼ばれます。ユーザーに ClusterRole を付与すると、クラスター全体のリソースを参照または編集するアクセス権が付与されます。また、クラスタースコープのリソース（namespace、ResourceQuota、Node）を参照または編集するためにも必要です。 ClusterRole は、RoleBinding 内で参照することで、特定の namespace にバインドできます。デフォルトの ClusterRole である `admin`、`edit`、`view` は、一般的にこの方法で使用されます。 Kubernetes にはデフォルトで利用可能な ClusterRole がいくつかあります。これらはユーザー向けのロールとして設計されています。スーパーユーザーロール（`cluster-admin`）や、より細かいアクセス権を持つロール（`admin`、`edit`、`view`）が含まれます。 | デフォルト ClusterRole | デフォルト ClusterRoleBinding | 説明 |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` グループ | すべてのリソースに対してすべてのアクションを実行できるスーパーユーザーアクセスを許可します。ClusterRoleBinding で使用すると、クラスター内およびすべての namespace 内のすべてのリソースを完全に制御できます。RoleBinding で使用すると、その namespace 内のすべてのリソース（namespace 自体を含む）を完全に制御できます。 | `admin` | なし | 管理者アクセスを許可します。RoleBinding を使用して namespace 内で付与することを想定しています。RoleBinding で使用すると、namespace 内のほとんどのリソースへの読み取り/書き込みアクセス（Role と RoleBinding の作成機能を含む）が許可されます。ResourceQuota や namespace 自体への書き込みアクセスは許可されません。 | `edit` | なし | namespace 内のほとんどのオブジェクトへの読み取り/書き込みアクセスを許可します。Role や RoleBinding の参照や変更は許可されません。 | `view` | なし | namespace 内のほとんどのオブジェクトへの読み取り専用アクセスを許可します。Role や RoleBinding の参照は許可されません。Secret の参照も許可されません（権限昇格につながるため）。 ## RBAC を使用したユーザーアカウントのアクセス制限 ロールベースアクセス制御の基本を理解したところで、管理者がユーザーのアクセス範囲を制限する方法について説明します。 ### 例: 特定の namespace への読み取り/書き込みアクセスを付与する ユーザーのアクセスを特定の namespace に制限するには、`edit` または `admin` ロールを使用します。chart が Role や RoleBinding を作成または操作する場合は、`admin` ClusterRole を使用してください。 また、`cluster-admin` アクセス権を持つ RoleBinding を作成することもできます。namespace スコープで `cluster-admin` アクセスをユーザーに付与すると、namespace 自体を含む namespace 内のすべてのリソースを完全に制御できます。 この例では、`edit` Role を持つユーザーを作成します。まず、namespace を作成します: ```console $ kubectl create namespace foo ``` 次に、その namespace で RoleBinding を作成し、ユーザーに `edit` ロールを付与します。 ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### 例: クラスタースコープでの読み取り/書き込みアクセスを付与する ユーザーがクラスタースコープのリソース（namespace、Role、CustomResourceDefinition など）をインストールする chart をインストールしたい場合、クラスタースコープの書き込みアクセスが必要になります。 これを行うには、ユーザーに `admin` または `cluster-admin` アクセスを付与します。 ユーザーに `cluster-admin` アクセスを付与すると、`kubectl drain` を使用したノードアクセスやその他の管理タスクを含む、Kubernetes で利用可能なすべてのリソースへのアクセスが付与されます。代わりにユーザーに `admin` アクセスを提供するか、ニーズに合わせたカスタム ClusterRole を作成することを強く推奨します。 ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### 例: 特定の namespace への読み取り専用アクセスを付与する Secret を参照するための ClusterRole はデフォルトでは用意されていません。`view` ClusterRole は、権限昇格の懸念から、ユーザーに Secret への読み取りアクセスを付与しません。Helm はデフォルトで release のメタデータを Secret として保存します。 ユーザーが `helm list` を実行するには、これらの Secret を読み取る必要があります。そのために、`secret-reader` という ClusterRole を作成します。 `cluster-role-secret-reader.yaml` ファイルを作成し、以下の内容を記述します: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` 次に、以下のコマンドで ClusterRole を作成します: ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` これで、ユーザーにほとんどのリソースへの読み取りアクセスを付与し、さらに Secret への読み取りアクセスを付与できます: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### 例: クラスタースコープでの読み取り専用アクセスを付与する 特定のシナリオでは、ユーザーにクラスタースコープのアクセスを付与することが有益な場合があります。たとえば、ユーザーが `helm list --all-namespaces` コマンドを実行したい場合、API はユーザーにクラスタースコープの読み取りアクセスを要求します。 これを行うには、上記で説明したように、ユーザーに `view` と `secret-reader` の両方のアクセスを付与しますが、ClusterRoleBinding を使用します。 ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## 補足 上記の例では、Kubernetes に付属するデフォルトの ClusterRole を使用しています。ユーザーがアクセスできるリソースをより細かく制御するには、[Kubernetes のドキュメント](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)を参照して、独自のカスタム Role や ClusterRole を作成してください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: OCI ベースのレジストリの使用 description: OCI を使用した chart の配布方法について説明します。 sidebar_position: 7 --- Helm 3 以降、[OCI](https://www.opencontainers.org/) をサポートするコンテナレジストリを使用して chart パッケージを保存・共有できます。Helm v3.8.0 以降、OCI サポートはデフォルトで有効になっています。 ## v3.8.0 より前の OCI サポート OCI サポートは Helm v3.8.0 で実験的機能から一般提供（GA）に昇格しました。それ以前のバージョンでは OCI サポートの動作が異なります。v3.8.0 より前に OCI サポートを使用していた場合は、各バージョンの変更点を確認してください。 ### v3.8.0 より前の OCI サポートの有効化 Helm v3.8.0 より前では、OCI サポートは*実験的*機能であり、明示的に有効化する必要があります。 v3.8.0 より前のバージョンで OCI サポートを有効にするには、環境変数 `HELM_EXPERIMENTAL_OCI` を設定します。例: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### v3.8.0 での OCI 機能の廃止と動作変更 [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) のリリースで、以下の機能と動作が以前のバージョンと異なっています: - 依存関係で chart を OCI として設定する場合、他の依存関係と同様にバージョンを範囲指定できます。 - ビルド情報を含むセマンティックバージョンタグをプッシュして使用できます。OCI レジストリはタグ文字として `+` をサポートしていません。Helm はタグとして保存する際に `+` を `_` に変換します。 - `helm registry login` コマンドは、認証情報の保存において Docker CLI と同じ構造に従うようになりました。レジストリ設定の同じ場所を Helm と Docker CLI の両方に渡すことができます。 ### v3.7.0 での OCI 機能の廃止と動作変更 [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) のリリースには、OCI サポートの [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) の実装が含まれていました。その結果、以下の機能と動作が以前のバージョンと異なっています: - `helm chart` サブコマンドは削除されました。 - chart キャッシュは削除されました（`helm chart list` などはありません）。 - OCI レジストリ参照には常に `oci://` プレフィックスが必要です。 - レジストリ参照のベース名は*常に* chart の名前と一致する必要があります。 - レジストリ参照のタグは*常に* chart のセマンティックバージョンと一致する必要があります（`latest` タグは使用できません）。 - chart レイヤーのメディアタイプが `application/tar+gzip` から `application/vnd.cncf.helm.chart.content.v1.tar+gzip` に変更されました。 ## OCI ベースのレジストリの使用 ### OCI ベースレジストリにおける Helm リポジトリ [Helm リポジトリ](/topics/chart_repository.md)は、パッケージ化された Helm chart を格納・配布する方法です。OCI ベースのレジストリには複数の Helm リポジトリを含めることができ、各リポジトリには複数のパッケージ化された Helm chart を含めることができます。 ### ホステッドレジストリの使用 OCI 対応のホスト型コンテナレジストリがいくつかあります。例: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) ホステッドコンテナレジストリプロバイダーのドキュメントに従って、OCI サポート付きのレジストリを作成・設定してください。 **注意:** ローカル環境で [Docker Registry](https://docs.docker.com/registry/deploying/) や [`zot`](https://github.com/project-zot/zot) などの OCI レジストリを実行することも可能です。ただし、ローカル環境での実行はテスト目的に限定してください。 ### sigstore を使用した OCI ベース chart の署名 [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) プラグインを使用すると、コンテナイメージの署名と同じツールで [Sigstore](https://sigstore.dev/) を使用して Helm chart に署名できます。これは、従来の [chart リポジトリ](/topics/chart_repository.md)でサポートされている [GPG ベースの provenance](/topics/provenance.md) の代替手段です。 `helm sigstore` プラグインの使用方法の詳細は、[プロジェクトのドキュメント](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)を参照してください。 ## レジストリ操作用のコマンド ### `registry` サブコマンド #### `login` レジストリにログインします（パスワードを手動入力） ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` レジストリからログアウトします ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### `push` サブコマンド OCI ベースのレジストリに chart をアップロードします: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` `push` サブコマンドは、事前に `helm package` で作成した `.tgz` ファイルに対してのみ使用できます。 `helm push` を使用して chart を OCI レジストリにアップロードする場合、参照には `oci://` プレフィックスを付ける必要があり、ベース名やタグを含めてはいけません。 レジストリ参照のベース名は chart の名前から推測され、タグは chart のセマンティックバージョンから推測されます。これは現在、厳格な要件です。 一部のレジストリでは、リポジトリや namespace（指定する場合）を事前に作成しておく必要があります。そうしないと、`helm push` 操作中にエラーが発生します。 [provenance ファイル](/topics/provenance.md)（`.prov`）を作成済みで、chart の `.tgz` ファイルと同じディレクトリにある場合、`push` 時に自動的にレジストリにアップロードされます。これにより、[Helm chart マニフェスト](#helm-chart-manifest)に追加のレイヤーが作成されます。 [helm-push プラグイン](https://github.com/chartmuseum/helm-push)（[ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server) に chart をアップロードするためのプラグイン）のユーザーは、このプラグインが新しい組み込みの `push` と競合するため、問題が発生する可能性があります。バージョン v0.10.0 以降、このプラグインは `cm-push` に名前が変更されました。 ### その他のサブコマンド `oci://` プロトコルは、他のさまざまなサブコマンドでもサポートされています。以下は完全なリストです: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` chart のダウンロードを伴うアクションでは、レジストリ参照のベース名（chart 名）を含めます（`helm push` ではベース名を省略）。 以下は、上記のサブコマンドを OCI ベースの chart に対して使用する例です: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## 依存関係の指定 chart の依存関係は、`dependency update` サブコマンドを使用してレジストリから取得できます。 `Chart.yaml` 内の各エントリの `repository` は、ベース名を除いたレジストリ参照として指定します: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` `dependency update` を実行すると、`oci://localhost:5000/myrepo/mychart:2.7.0` が取得されます。 ## Helm chart マニフェスト レジストリに表示される Helm chart マニフェストの例です（`mediaType` フィールドに注目してください）: ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` 以下の例には [provenance ファイル](/topics/provenance.md)が含まれています（追加のレイヤーに注目してください）: ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## chart リポジトリからの移行 従来の [chart リポジトリ](/topics/chart_repository.md)（index.yaml ベースのリポジトリ）からの移行は、`helm pull` を使用してから、生成された `.tgz` ファイルを `helm push` でレジストリにアップロードするだけです。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Helm v2 から v3 への移行 description: Helm v2 から v3 への移行方法について説明します。 sidebar_position: 13 --- このガイドでは、Helm v2 から v3 への移行方法について説明します。Helm v2 がインストールされており、1 つ以上のクラスターで release を管理している環境が前提です。 ## Helm 3 の変更点の概要 Helm 2 から 3 への変更点の完全なリストは、[FAQ セクション](/faq/changes_since_helm2.md)に記載されています。以下は、移行前および移行中にユーザーが認識しておくべき主な変更点の概要です。 1. Tiller の廃止: - クライアント/サーバー アーキテクチャからクライアント/ライブラリ アーキテクチャに変更（`helm` バイナリのみ） - セキュリティはユーザー単位で管理（Kubernetes ユーザーのクラスターセキュリティに委任） - release はクラスター内の Secret として保存され、release オブジェクトのメタデータが変更 - release は Tiller の namespace ではなく、release ごとの namespace 単位で永続化 2. chart リポジトリの更新: - `helm search` がローカルリポジトリ検索と Artifact Hub への検索クエリの両方をサポート 3. chart の apiVersion が「v2」に更新され、以下の仕様変更を含む: - 動的にリンクされる chart の依存関係が `Chart.yaml` に移動（`requirements.yaml` は廃止、requirements → dependencies に変更） - ライブラリ chart（ヘルパー/共通 chart）を動的にリンクされた chart の依存関係として追加可能 - chart に `type` メタデータフィールドが追加され、`application` または `library` chart として定義可能。デフォルトは application で、レンダリングおよびインストールが可能 - Helm 2 の chart（apiVersion=v1）も引き続きインストール可能 4. XDG ディレクトリ仕様の追加: - Helm home が廃止され、構成ファイルの保存には XDG ディレクトリ仕様を使用 - Helm の初期化が不要に - `helm init` と `helm home` は廃止 5. その他の変更: - Helm のインストール/セットアップが簡素化: - Helm クライアント（helm バイナリ）のみ（Tiller 不要） - インストール後すぐに使用可能 - `local` や `stable` リポジトリはデフォルトで設定されない - `crd-install` hook は廃止され、chart 内の `crds` ディレクトリに置き換え。このディレクトリで定義されたすべての CRD は、chart のレンダリング前にインストールされる - `test-failure` hook のアノテーション値は廃止、`test-success` は非推奨。代わりに `test` を使用 - コマンドの廃止/置き換え/追加: - delete → uninstall：デフォルトですべての release 履歴を削除（以前は `--purge` が必要） - fetch → pull - home（廃止） - init（廃止） - install：release 名または `--generate-name` 引数が必須 - inspect → show - reset（廃止） - serve（廃止） - template：`-x`/`--execute` 引数が `-s`/`--show-only` に名称変更 - upgrade：`--history-max` 引数が追加され、release ごとに保存されるリビジョンの最大数を制限可能（0 で無制限） - Helm 3 の Go ライブラリは大幅に変更されており、Helm 2 ライブラリとは互換性がない - リリースバイナリは `get.helm.sh` でホストされています ## 移行のユースケース 移行のユースケースは以下のとおりです。 1. Helm v2 と v3 で同じクラスターを管理する場合: - このユースケースは、Helm v2 を段階的に廃止する予定があり、v3 で v2 がデプロイした release を管理する必要がない場合にのみ推奨されます。新しい release はすべて v3 でデプロイし、既存の v2 でデプロイされた release は v2 のみで更新/削除してください - Helm v2 と v3 は同じクラスターを問題なく管理できます。両方のバージョンは同じシステムまたは別々のシステムにインストールできます - Helm v3 を同じシステムにインストールする場合、Helm v2 クライアントを削除する準備ができるまで、両方のクライアントバージョンが共存できるように追加の手順が必要です。競合を避けるため、Helm v3 バイナリの名前を変更するか、別のフォルダに配置してください - それ以外の場合、以下の理由により両バージョン間で競合は発生しません: - v2 と v3 の release（履歴）ストレージは互いに独立しています。変更点には、ストレージ用の Kubernetes リソースと、リソースに含まれる release オブジェクトのメタデータが含まれます。release は Tiller の namespace ではなく、ユーザーの namespace ごとに保存されます（例: v2 のデフォルト Tiller namespace は kube-system）。v2 は Tiller namespace 下の「ConfigMaps」または「Secrets」を使用し、`TILLER` 所有権を持ちます。v3 はユーザーの namespace 内の「Secrets」を使用し、`helm` 所有権を持ちます。release は v2 と v3 の両方でインクリメンタルです - 唯一の問題は、Kubernetes クラスタースコープのリソース（例: `clusterroles.rbac`）が chart で定義されている場合です。リソースが競合するため、namespace 内でユニークであっても v3 のデプロイは失敗します - v3 の構成は `$HELM_HOME` を使用せず、代わりに XDG ディレクトリ仕様を使用します。また、必要に応じてオンデマンドで作成されます。そのため、v2 の構成とは独立しています。これは両方のバージョンが同じシステムにインストールされている場合にのみ適用されます 2. Helm v2 から Helm v3 への移行: - このユースケースは、Helm v3 で既存の Helm v2 release を管理したい場合に適用されます - Helm v2 クライアントには以下の特徴があることに注意してください: - 1 つ以上の Kubernetes クラスターを管理可能 - クラスターごとに 1 つ以上の Tiller インスタンスに接続可能 - つまり、release は Tiller とその namespace によってクラスターにデプロイされるため、移行時にはこの点を認識する必要があります。したがって、Helm v2 クライアントインスタンスが管理する各クラスターと各 Tiller インスタンスについて移行を行う必要があります - 推奨されるデータ移行パスは以下のとおりです: 1. v2 データのバックアップ 2. Helm v2 構成の移行 3. Helm v2 release の移行 4. Helm v3 がすべての Helm v2 データ（Helm v2 クライアントインスタンスのすべてのクラスターと Tiller インスタンス）を期待どおりに管理していることを確認したら、Helm v2 データをクリーンアップ - 移行プロセスは Helm v3 の [2to3](https://github.com/helm/helm-2to3) プラグインによって自動化されています ## 参照 - Helm v3 [2to3](https://github.com/helm/helm-2to3) プラグイン - `2to3` プラグインの使用例を説明したブログ[記事](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Helm バージョンサポートポリシー" description: "Helm のパッチリリースポリシーと、Helm と Kubernetes 間でサポートされる最大バージョン差について説明します。" --- このドキュメントでは、Helm と Kubernetes 間でサポートされる最大バージョン差について説明します。 ## サポートされているバージョン Helm のバージョンは `x.y.z` の形式で表されます。ここで、`x` はメジャーバージョン、`y` はマイナーバージョン、`z` はパッチバージョンを表し、[セマンティックバージョニング](https://semver.org/spec/v2.0.0.html)の用語に従っています。 Helm プロジェクトでは、最新のマイナーリリースに対応するリリースブランチを維持しています。重大度と実現可能性に応じて、セキュリティ修正を含む対象の修正がリリースブランチに取り込まれます。詳細は [Helm のリリースポリシー](/community/release_policy)を参照してください。 ## サポートされるバージョン差 Helm の新しいバージョンがリリースされると、特定のマイナーバージョンの Kubernetes に対してコンパイルされます。たとえば、Helm 3.0.0 は Kubernetes 1.16.2 クライアントを使用して Kubernetes と通信するため、Kubernetes 1.16 と互換性があります。 Helm 3 以降では、コンパイル対象となった Kubernetes のバージョンを基準に、そこから 3 つ前のマイナーバージョン（`n-3`）までの互換性が想定されています。Kubernetes はマイナーバージョン間で変更が発生するため、Helm 2 のサポートポリシーはやや厳格であり、1 つ前のバージョン（`n-1`）までの互換性が想定されています。 たとえば、Kubernetes 1.17 クライアント API に対してコンパイルされた Helm 3 のバージョンを使用している場合、Kubernetes 1.17、1.16、1.15、1.14 で安全に使用できます。Kubernetes 1.16 クライアント API に対してコンパイルされた Helm 2 のバージョンを使用している場合は、Kubernetes 1.16 と 1.15 で安全に使用できます。 Helm がコンパイル対象となったバージョンよりも新しいバージョンの Kubernetes で使用することは推奨されません。Helm は前方互換性を保証していないためです。 Helm がサポートしていないバージョンの Kubernetes で Helm を使用する場合は、自己責任でご利用ください。 クラスターと互換性のある Helm バージョンを確認するには、以下の表を参照してください。 | Helm バージョン | サポートされている Kubernetes バージョン | |--------------|-------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "はじめに", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "ハウツー", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "トピック", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "ベストプラクティス", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "チャートテンプレートガイド", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helmコマンド", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "コミュニティ", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "よくある質問", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs-community/current/developers.md ================================================ --- title: 開発者ガイド description: Helmを開発するための環境をセットアップする方法を説明します。 sidebar_position: 1 --- このガイドでは、Helmで開発するための環境をセットアップする方法について説明します。 ## 必要な環境 - Goの最新バージョン - kubectlおよびKubernetesクラスター (optional) - Git ## Helmをビルドする Makeを使用してプログラムを構築します。最も簡単な方法は次のとおりです: ```console $ make ``` 注意: `$GOPATH/src/helm.sh/helm` のパスにて実行されていない場合、このコマンドは失敗します。 また、`build` が関連するパッケージが見つけられないため、`helm.sh`ディレクトリをシンボリックリンクにしてはいけません。 このコマンドは必要に応じて依存関係をインストールし、`vendor/`ツリーを再ビルドしたのち、configurationを検証します。 その後に`helm`をコンパイルして`bin/helm`に配置します。 Helmをローカルで実行するには、`bin/helm`を実行してください。 - Helmは、macOSおよびAlpineを含んだほとんどのLinuxディストリビューションで動作することが知られています。 ## テストの実行 すべてのテスト(`vendor/`のテストを除く)を実行するには、`make test`を実行してください。 前提条件として、[golangci-lint](https://golangci-lint.run) をインストールする必要があります 。 ## コントリビューションガイドライン 私たちはコントリビューションを歓迎します。 このプロジェクトは、（a) コードの品質を高く保ち（b）プロジェクトの一貫性を保ち（c）コントリビューションがオープンソースの法的要件に従うことを保証するため、いくつかのガイドラインを設定しました。 私たちの目的はコントリビューターに負担をかけることではなく、ユーザーが利益を得ることができるようにエレガントで高品質なオープンソースコードを構築することです。 CONTRIBUTINGガイドを読み、理解していることを確認してください。 https://github.com/helm/helm/blob/main/CONTRIBUTING.md ### コードの構造 Helmプロジェクトのコードは、以下のように構成されています。 - 個々のプログラムは`cmd/`にあります。`cmd/`内のコードはライブラリ再利用を目的として設計されていません。 - 共有ライブラリは`pkg/`にあります。 - `scripts/`ディレクトリには多数のユーティリティスクリプトがあります。これらのほとんどはCI/CDパイプラインによって使用されます。 Goの依存関係管理は流動的であり、Helmのライフサイクルの過程で変更される可能性があります。 依存関係を手動で管理 _しない_ ことをお勧めします。 その代わりに、プロジェクトの`Makefile`に依存して管理を行うことをお勧めします。 Helm 3では、Goバージョン1.13以降を使用することをお勧めします。 ### ドキュメントの作成 Helm 3以降、ドキュメントは独自のリポジトリに移動されました。 新しい機能を作成する場合は付属のドキュメントを作成して、[helm-www](https://github.com/helm/helm-www)にsubmitしてください。 例外: [Helm CLI output (英語)](/docs/helm) は `helm` のバイナリ自体から生成されます。 このoutputを生成する方法については[Updating the Helm CLI Reference Docs](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) をご覧ください。 翻訳された場合、CLI出力は生成されず`/content//docs/helm`に生成されます。 ### Git 規約 バージョン管理システムにはGitを使用しています。 `main`ブランチは現在の開発候補の中心です。 リリースにはタグが付けられます。 GitHubのPull Requests（PRs）を介してコードの変更を受け付けています。 これを行うためのワークフローの一例は次のとおりです。 1. `$GOPATH/src` に移動して `mkdir helm.sh; cd helm.sh` を実行し、 `github.com/helm/helm` のリポジトリを`git clone` します。 2. リポジトリをあなたのGitHubアカウントにフォークします 3. あなたのリポジトリを`$GOPATH/src/helm.sh/helm`のリモートとして追加します。 4. 新しい作業ブランチ (`git checkout -b feat/my-feature`) 作成し、そのブランチで作業を行います。 5. レビューの準備ができましたら、あなたのブランチをGitHubにプッシュして新しいプルリクエストを開いてください。 Git commit messagesに関しては[Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) に従います : ``` fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` 一般的なコミットタイプ: - fix: バグまたはエラーを修正 - feat: 新機能を追加 - docs: ドキュメントを変更 - test: テストを改善する - ref: 既存のコードのリファクタリング 一般的なスコープ: - helm: The Helm CLI - pkg/lint: lintパッケージ。どのパッケージでも同様の規則に従ってください - `*`: 2つ以上のスコープ さらに読む: - [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) がこのセクションのインスピレーションになりました。 - Karma Runner はthe semantic commit messageの考えを [定義しています](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)。 ### Go 規約 Go coding style standardsに厳密に従っています。だいたいの場合`go fmt`を実行すればコードが美しくなります。 また、`go lint`および`gometalinter`によって推奨される規則に従います。 `make test-style`を実行してスタイルの適合性をテストしてください。 さらに読む: - Effective Go では[formattingを導入しています](https://golang.org/doc/effective_go.html#formatting). - The Go Wiki には [formatting](https://github.com/golang/go/wiki/CodeReviewComments)に関して素晴らしい記事があります。 `make test`ターゲットを実行すると、単体テストが実行されるだけでなく、スタイルテストも実行されます。 `make test`ターゲットが失敗する場合は、それが文体に起因するものであったとしても、あなたのPRがマージに向けた準備ができていないと判断されます。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs-community/current/history.mdx ================================================ --- title: プロジェクトの歴史 description: プロジェクトの歴史の概要を提供します。 sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm は [CNCF の Graduated プロジェクト](https://helm.sh/blog/celebrating-helms-cncf-graduation/)です。 Helm は、現在 [Helm Classic](https://github.com/helm/helm-classic) として知られているものとして始まりました。 これは、2015年に開始され、 最初の KubeCon で導入された Deis プロジェクトです。 2016 年 1 月、プロジェクトは Kubernetes Deployment Manager と呼ばれる GCS ツールと統合され、 プロジェクトは [Kubernetes](https://kubernetes.io) の下に移動されました。 コードベースの統合の結果、 Helm 2.0 がその年の後半にリリースされました。 Helm 2 で生き残った Deployment Manager の主要な機能はサーバー側のコンポーネントで、 最終的な Helm 2.0 リリースでは DM から Tiller に名前が変更されました。 Helm は、2018 年 6 月に Kubernetes サブプロジェクトから本格的な CNCF プロジェクトに昇格しました。 Helm はトップレベルの管理組織を形成し、 Monocular、Helm Chart Repo、Chart Museum、そして後に Helm Hub など、 いくつかのプロジェクトが Helm プロジェクトに組み込まれました。 Helm 3 の開発サイクルが始まると、Tiller が削除され、 Helm はクライアントツールであるという当初のビジョンに近づきました。 ただし、Helm 3 は引き続き Kubernetes クラスター内のリリースを追跡しているため、 チームが共同で Helm リリースのセットで作業することができます。Helm 3 は 2019 年 11 月にリリースされました。 Helm は、[2020 年 4 月に CNCF の Graduated プロジェクトになりました](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs-community/current/localization.md ================================================ --- title: Helm ドキュメントの国際化 description: Helm ドキュメントを国際化するための手順。 sidebar_position: 5 --- このガイドでは Helm ドキュメントをどのように国際化するかを説明します。 ## はじめに 翻訳への貢献にはドキュメントへの貢献と同様のプロセスを用います。翻訳は [helm-www](https://github.com/helm/helm-www) git リポジトリへの[プルリクエスト](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-pull-requests)によって供給され、プルリクエストはウェブサイトの管理チームによってレビューされます。 ### 2文字言語コード {#two-letter-language-code} ドキュメントは [ISO 639-1 標準](https://www.loc.gov/standards/iso639-2/php/code_list.php) 言語コードによって管理されます。例えば、韓国語の2文字コードは `ko` です。 コンテンツや設定でこの言語コードが使われます。3つ例を示します。 - `content` ディレクトリ内で言語コードがサブディレクトリとして存在し、国際化されたコンテンツがそれぞれのディレクトリに入っています。 - `i18n` ディレクトリはそれぞれの言語について、ウェブサイトで使用されるフレーズについての設定ファイルを保有しています。それらのファイルは `[LANG]` がその言語の2文字コードとなるような `[LANG].toml` というパターンで命名されています。 - トップレベルの `config.toml` ファイルではナビゲーションやその他の詳細が言語コードごとに管理されています。 言語コード `en` を持つ英語が、デフォルトの言語および翻訳元として用いられます。 ### フォーク、ブランチ、変更、プルリクエスト 翻訳に貢献するために、まずは Github の [helm-www リポジトリ](https://github.com/helm/helm-www)の[フォークを作る](https://help.github.com/ja/github/getting-started-with-github/fork-a-repo)ことから始めましょう。あなたはまずあなたのフォークに変更をコミットすることから始めるでしょう。 初期状態であなたのフォークは `main` として知られるデフォルトブランチに設定されているでしょう。あなたの変更を開発するあるいはプルリクエストを作成するためにブランチを使用してください。もしブランチについて不慣れなら[それらについて Github ドキュメントで読む](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-branches)ことができます。 ブランチを作成出来たら、翻訳を追加したり、コンテンツを国際化したりしましょう。 注：helm は [Developers Certificate of Origin](https://developercertificate.org/) を利用しています。すべてのコミットは署名されている必要があります。コミットを作成する際に `-s` か `--signoff` フラグを用いることで、あなたの Git に設定されている名前とメールアドレスを用いてコミットに署名することができます。詳細については [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work) をご覧ください。 準備ができたら、[プルリクエスト](https://help.github.com/ja/github/collaborating-with-issues-and-pull-requests/about-pull-requests) を作成し、helm-www リポジトリに反映しましょう。 作成されたプルリクエストは管理者によってレビューされます。その過程についての詳細は [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md) を参照してください。 ## コンテンツの翻訳 全ての Helm コンテンツを国際化するのは大きな仕事です。小さなことから初めて大丈夫です。時間をかけて翻訳を拡大することができます。 ### 新たな言語を開始する 新たな言語を開始するには以下の最低要件が必要です。 - `_index.md` ファイルを含む `content/[LANG]/docs` ディレクトリを追加する。これはドキュメントランディングページの最上位です。 - `i18n` ディレクトリに `[LANG].toml` ファイルを作成する。まずは開始地点として `en.toml` ファイルをコピーすることができます。 - 新たな言語を公開するため、`config.toml` ファイルにその言語のセクションを追加する。既に存在する言語のセクションを開始地点とすることができます。 ### 翻訳 翻訳されたコンテンツは `content/[LANG]/docs` ディレクトリ内に存在する必要があります。それらは英語ソースと同じURLを持ちます。例えば、イントロダクションを韓国語に翻訳するなら以下のように英語ソースをコピーすると便利です。 ```sh mkdir -p content/ko/docs/intro cp content/en/docs/intro/install.md content/ko/docs/intro/install.md ``` 新しいファイルの内容を別の言語に翻訳することができます。 翻訳されていない英語ファイルのコピーを `content/[LANG]/` に追加しないでください。言語がその場所に存在する場合、未翻訳のページは自動的に英語にリダイレクトされます。翻訳には時間がかかるので、常に古いフォークではなく最新のドキュメントを翻訳するようにしてください。 全ての `aliases` 行をヘッダーセクションから削除するよう気をつけてください。`aliases: ["/docs/using_helm/"]` のような行は翻訳では持ちません。それらは新たなページには存在しない古いリンクへのリダイレクトです。 注：翻訳ツールが助けになるかもしれません。それには機械翻訳が含まれています。機械翻訳は公開前に編集される、またはネイティブ話者によって文法や意味をレビューされる必要があります。 ## 言語間のナビゲーション ![Screen Shot 2020-05-11 at 11 24 22 AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png) サイトグローバルな　[config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89) ファイルで言語ナビゲーションが設定されています。 新たな言語を追加するには、上で定義した新たな[2文字言語コード](#two-letter-language-code)を追加する必要があります。例： ``` # Korean [languages.ko] title = "Helm" description = "Helm - The Kubernetes Package Manager." contentDir = "content/ko" languageName = "한국어 Korean" weight = 1 ``` ## 内部リンクの解決 翻訳されたコンテンツは時々別言語にしか存在しないページへのリンクを含んでいるでしょう。これによって[ビルドエラー](https://app.netlify.com/sites/helm-merge/deploys)が発生します。例： ``` 12:45:31 PM: htmltest started at 12:45:30 on app 12:45:31 PM: ======================================================================== 12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html 12:45:31 PM: hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example 12:45:31 PM: ✘✘✘ failed in 197.566561ms 12:45:31 PM: 1 error in 212 documents ``` これを解決するために、あなたのコンテンツの内部リンクを確認する必要があります。 * アンカーリンクは翻訳された `id` の値を反映する必要があります。 * 内部リンクを修正する必要があります。 存在しない _（もしくはまだ翻訳されていない）_ 内部ページについては、修正がされるまでサイトがビルドされません。代わりに、下記のようにコンテンツが _存在する_ 別の言語にURLを向けることができます。 `< relref path="/docs/topics/library_charts.md" lang="en" >` 詳細については [言語間相互リファレンスについての Hugo ドキュメント](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) をご覧ください。 ================================================ FILE: i18n/ja/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "リリーススケジュールポリシー" description: "Helm のリリーススケジュールポリシーについて説明します。" --- ユーザーの利便性のため、Helm はリリース日を事前に定義し、公開しています。このドキュメントでは、Helm のリリーススケジュールを規定するポリシーについて説明します。 ## リリースカレンダー 今後の Helm リリースを示す公開カレンダーは[こちら](https://helm.sh/calendar/release)で確認できます。 ## セマンティックバージョニング Helm のバージョンは `x.y.z` の形式で表されます。ここで、`x` はメジャーバージョン、`y` はマイナーバージョン、`z` はパッチバージョンを表し、[セマンティックバージョニング](https://semver.org/spec/v2.0.0.html)の用語に従っています。 ## パッチリリース パッチリリースは、バグ修正とセキュリティ修正をユーザーに提供します。新機能は含まれません。 最新のマイナー/メジャーリリースに対する新しいパッチリリースは、通常、毎月第2水曜日に行われます。 重大なリグレッションやセキュリティ問題を修正するパッチリリースは、随時行われます。 パッチリリースは、以下のいずれかの理由によりキャンセルされる場合があります。 - 前回のリリース以降に新しいコンテンツがない場合 - パッチリリースの予定日が、今後のマイナーリリースの最初のリリース候補（RC1）の1週間前以内に該当する場合 - パッチリリースの予定日が、マイナーリリース後4週間以内に該当する場合 ## マイナーリリース マイナーリリースには、セキュリティ修正、バグ修正、および新機能が含まれます。API と CLI の使用方法に関して後方互換性があります。 Kubernetes のリリースに合わせて、Helm のマイナーリリースは4ヶ月ごとに行われます（年3回のリリース）。 追加のマイナーリリースは必要に応じて行われますが、次の定期リリースまで7日以上ある場合に限り、既存のリリーススケジュールには影響しません。 リリースが公開されると同時に、次のマイナーリリースの日程が発表され、Helm のメイン Web ページに掲載されます。 ## メジャーリリース メジャーリリースには、破壊的変更が含まれます。このようなリリースはまれですが、Helm が重要な新しい方向に進化し続けるために必要な場合があります。 メジャーリリースは計画が難しい場合があります。そのため、最終リリース日は、そのようなリリースの最初のベータバージョンが利用可能になった時点で決定し、発表されます。 ================================================ FILE: i18n/ja/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Helmプロジェクト", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "開発", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "コミュニティ", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "ソースコード", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "ブログ", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "イベント", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "行動規範", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "はじめに", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Chartのコツ＆ヒント", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Chartsの開発", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "800以上のChartsを検索", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "貢献ガイド", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "メンテナー", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "週次ミーティング", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "GitHubコミュニティ", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "私たちはCloud Native Computing Foundationの卒業プロジェクトです。
© Helm Authors 2025. ドキュメントはCC-BY-4.0の下で配布されています。
© 2025 The Linux Foundation. All rights reserved. The Linux Foundationは登録商標を有し、商標を使用しています。Linux Foundationの商標リストについては、商標使用ページをご覧ください。", "description": "The footer copyright" }, "logo.alt": { "message": "CNCFロゴ", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/ja/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Helmロゴ", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "ドキュメント", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "ブログ", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "コミュニティ", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/ko/code.json ================================================ { "home.features.manageComplexity": { "message": "복잡성 관리", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "차트는 가장 복잡한 앱도 설명하고, 반복 가능한 애플리케이션 설치를 제공하며, 단일 권한 소스 역할을 합니다.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "쉬운 업데이트", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "제자리 업그레이드와 사용자 정의 후크로 업데이트의 어려움을 없애세요.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "간단한 공유", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "차트는 버전 관리, 공유, 공개 또는 비공개 서버에서의 호스팅이 쉽습니다.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "롤백", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "{helmRollback}을 사용하여 릴리스의 이전 버전으로 쉽게 롤백할 수 있습니다.", "description": "Rollbacks section description" }, "home.features.title": { "message": "기능", "description": "Features section title" }, "home.community.nextFeatureRelease": { "message": "다음 기능 릴리스", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "버전:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "날짜:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "릴리스 일정", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "다가오는 이벤트", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "다가오는 이벤트", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "지난 이벤트", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "도구와 프로젝트를 시연하고 논의하기 위해 {meetLink}. 커뮤니티 회의는 녹화되어 {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "매주 모입니다", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "YouTube에 공유됩니다", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "개발자 스탠드업 회의" }, "home.community.developerStandups.time": { "message": "목요일 오전 9:30-10시 (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "이 회의는 모두에게 열려 있습니다. 메모와 세부 사항은 {communityRepoLink}를 확인하세요.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "커뮤니티 저장소", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Helm 사용, 차트 작업 및 일반적인 오류 해결에 대한 토론.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Helm 개발, 진행 중인 PR, 릴리스 등에 관한 주제.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Helm Charts 사용자 및 기여자를 위한 토론.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "Kubernetes Slack 팀에 참여하려면 {slackLink}.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "여기에서 액세스 요청", "description": "Request access to slack link" }, "home.community.contributing": { "message": "기여하기", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm은 항상 프로젝트에 대한 새로운 기여를 환영합니다!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "어디서부터 시작할까요?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm은 많은 사용자와 기여자가 있는 큰 프로젝트입니다. 받아들일 것이 많을 수 있습니다!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "도움을 주고 싶지만 어디서 시작해야 할지 모르겠다면 {goodFirstIssuesLink} 목록이 있습니다.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "적당한 첫번째 이슈", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "무엇을 해야 하나요?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "코드를 기여하기 전에 {contributionGuideLink}를 읽어주세요. Pull Request 생성 및 검토 프로세스를 다룹니다.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "기여 가이드", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "코드를 작성한 후 Helm이 {cncfLink}에서 사용하는 {dcoLink} 계약을 준수하도록 {signYourCommitsLink}를 해주세요.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "커밋에 서명", "description": "Sign your commits link" }, "home.community.title": { "message": "커뮤니티 참여", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Helm 프로젝트에 대한 자세한 정보와 기여 방법.", "description": "Join the Community subtitle" }, "home.gettingStarted.title": { "message": "시작하기", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "헬름 설치하기!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "패키지 관리자로 Helm을 설치하거나 {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "바이너리를 다운로드하세요", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "설치가 완료되면 helm 바이너리의 압축을 풀고 PATH에 추가하면 바로 사용할 수 있습니다! 자세한 {installationLink} 및 {usageLink}는 {docsLink}를 확인하세요.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "문서", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "설치 방법", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "사용 방법", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "차트 받기", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "{artifactHubLink}를 방문하여 수많은 공개 저장소의 {helmChartsLink}를 탐색하세요.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm 차트", "description": "Helm charts link" }, "home.about.whatIsHelm": { "message": "Helm은 Kubernetes 애플리케이션 관리를 도와줍니다 — Helm Charts는 가장 복잡한 Kubernetes 애플리케이션도 정의, 설치 및 업그레이드할 수 있도록 도와줍니다.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "차트는 생성, 버전 관리, 공유 및 게시가 쉽습니다 — 그러니 Helm을 사용하고 복사-붙여넣기는 그만하세요.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm은 {cncfLink}의 졸업 프로젝트이며 {helmCommunityLink}에 의해 유지 관리됩니다.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "Helm 커뮤니티", "description": "Helm community link" }, "home.about.learnMore": { "message": "자세히 알아보기:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Helm 아키텍처", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "빠른 시작 가이드", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "동영상: Helm 소개", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Helm이란 무엇인가요?", "description": "What is Helm? title" }, "home.header.tagline": { "message": "Kubernetes를 위한 패키지 관리자", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm은 소프트웨어를 찾고, 공유하고, 사용하는 가장 좋은 방법입니다", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "페이지에 오류가 발생하였습니다.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "맨 위로 스크롤하기", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "게시물 목록", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "게시물 목록", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "블로그 게시물 목록 탐색", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "이전 페이지", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "다음 페이지", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "블로그 게시물 탐색", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "이전 게시물", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "다음 게시물", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "모든 태그 보기", "description": "The label of the link targeting the tag list page" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "탐색 경로", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "{count} 항목", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "시스템 모드", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "밝은 모드", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "어두운 모드", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "어두운 모드와 밝은 모드 전환하기 (현재 {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.paginator.navAriaLabel": { "message": "문서 페이지", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "이전", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "다음", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "{count}개 문서가", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} \"{tagName}\" 태그에 분류되었습니다", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "버전: {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "{siteTitle} {versionLabel} 문서는 아직 정식 공개되지 않았습니다.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "{siteTitle} {versionLabel} 문서는 더 이상 업데이트되지 않습니다.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "최신 문서는 {latestVersionLink} ({versionLabel})을 확인하세요.", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "최신 버전", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { "message": "페이지 편집", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "{heading}에 대한 직접 링크", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " {date}에", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " {user}가", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "최종 수정: {atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "버전", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.NotFound.title": { "message": "페이지를 찾을 수 없습니다.", "description": "The title of the 404 page" }, "theme.tags.tagsListLabel": { "message": "태그:", "description": "The label alongside a tag list" }, "theme.admonition.caution": { "message": "주의", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "위험", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "정보", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "노트", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "팁", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "경고", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "닫기", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { "message": "최근 블로그 문서 둘러보기", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "사이드바 분류 '{label}' 펼치기", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "사이드바 분류 '{label}' 접기", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(새 탭에서 열림)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "메인", "description": "The ARIA label for the main navigation" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "언어", "description": "The label for the mobile language switcher dropdown" }, "theme.NotFound.p1": { "message": "원하는 페이지를 찾을 수 없습니다.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "사이트 관리자에게 링크가 깨진 것을 알려주세요.", "description": "The 2nd paragraph of the 404 page" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "이 페이지에서", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "자세히 보기", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "{title} 에 대해 더 읽어보기", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "약 {readingTime}분", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "복사", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "복사했습니다", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "클립보드에 코드 복사", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "줄 바꿈 전환", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "홈", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "문서 사이드바", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "사이드바 숨기기", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "사이드바 숨기기", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "사이드바 닫기", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← 메인 메뉴로 돌아가기", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "사이드바 펼치거나 접기", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "드롭다운 펼치기", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "드롭다운 접기", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "사이드바 열기", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "사이드바 열기", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "{count}개 게시물", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "\"{tagName}\" 태그로 연결된 {nPosts}개의 게시물이 있습니다.", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "저자", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "모든 저자 보기", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "작성자가 아직 게시글을 작성하지 않았습니다.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "색인되지 않은 문서", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "이 문서는 색인되지 않습니다. 검색 엔진이 이 문서를 색인하지 않으며, 주소를 알고 있는 사용자만 접근할 수 있습니다.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "작성 중인 페이지", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "이 페이지는 아직 작성 중입니다. 개발 환경에서만 보이며 프로덕션 빌드에서는 제외됩니다.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "다시 시도해 보세요", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "본문으로 건너뛰기", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "태그", "description": "The title of the tag list page" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2019-11-13-helm-3-released.md ================================================ --- title: "Helm 3.0.0 출시!" slug: "helm-3-released" authors: ["mattfisher"] date: "2019-11-13" --- 헬름 팀은 헬름 3의 첫번째 안정적 릴리스를 발표하게 된 것을 자랑스럽게 생각한다. 헬름 3는 CLI 도구의 최신 주(major) 릴리스이다. 헬름 2의 성공을 기반으로, 헬름 3도 진화하는 생태계의 요구에 계속 부응하고 있다. 헬름 3의 내부 구현은 헬름 2와는 상당히 다르게 변경되었다. 가장 눈에 띄는 변화는 틸러(Tiller)가 제거된 것이다. 다만 새 릴리스에서 다른 변경사항들도 확인해두는 게 좋다. 커뮤니티의 의견과 요구사항에 따라 다양한 새로운 기능들이 추가되었다. 일부 기능은 헬름 2와 호환되지 않는 방식으로, 더 이상 사용되지 않거나 리팩토링되었다. OCI 지원을 포함하는 일부 실험적 기능도 도입되었다. 추가로, 헬름 Go SDK 도 범용적으로 리팩토링되었다. 목표는 오픈 소스로 만든 코드를 Go 커뮤니티와 폭넓게 공유하고 재사용하는 것이다. 자신의 프로젝트에 헬름을 연계하여 사용하는 다른 엔지니어들의 의견을 활발하게 수용하고 있으며, [#헬름-개발 쿠버네티스 슬랙 채널](https://slack.k8s.io/)에서도 여러분들의 의견을 듣고자 한다. 다음은 헬름 3의 몇 가지 리소스이다: - [문서](https://helm.sh/docs/) - [FAQ: 헬름 2에서 바뀐 점](https://helm.sh/docs/faq/#changes-since-helm-2) - [헬름 설치](https://helm.sh/docs/intro/install/) - [헬름 2에서 헬름 3로의 마이그레이션에 대한 문서](https://helm.sh/docs/topics/v2_v3_migration/) - [헬름 2에서 헬름 3로 마이그레이션하는데 도움이 되는 플러그인](https://github.com/helm/helm-2to3) - [#헬름-사용자 쿠버네티스 슬랙 채널](https://slack.k8s.io/)에서 개발자 및 참여자와 채팅 - 에서 버그 신고 ## 헬름이란? 헬름은 쿠버네티스 내에서 애플리케이션의 생성, 설치, 관리를 협업하는 데에 필요한 도구를 팀에 제공한다. 헬름을 통하여, 사용자는 다음과 같은 것들을 할 수 있다. - 설치하여 사용할만한 패키징된 소프트웨어(차트) 찾기 - 자신만의 패키지를 쉽게 만들고 호스팅 - 모든 쿠버네티스 클러스터에 패키지 설치 - 클러스터에 질의하여 설치되어 실행중인 패키지 확인 - 설치된 패키지의 이력을 업데이트, 삭제, 롤백 및 조회 헬름을 사용하면 쉽게 쿠버네티스 내에서 애플리케이션을 실행할 수 있다. ## 함께 살펴보자! 쿠버네티스 클러스터가 구동 중이고 `kubectl` 이 알맞게 설정되었다면, 헬름 작업은 식은 죽 먹기이다. 헬름을 사용하면 커뮤니티에서 호스팅하는 저장소를 추가하여 새 차트를 쉽게 검색할 수 있다. ```bash $ helm repo add nginx https://helm.nginx.com/stable ``` 저장소를 추가했다면 차트를 검색할 수 있다: ```bash $ helm search repo nginx-ingress NAME CHART VERSION APP VERSION DESCRIPTION nginx/nginx-ingress 0.3.7 1.5.7 NGINX Ingress Controller ``` 헬름은 `helm install` 을 사용하여 차트를 빠르게 설치할 수 있는 방법을 제공한다. ```bash $ helm install my-ingress-controller nginx/nginx-ingress ``` `kubectl` 로 클러스터를 확인해 보면: ```bash $ kubectl get deployments ``` 구동 중인 인그레스 컨트롤러(ingress controller)가 있다! `helm uninstall my-ingress-controller` 로 간단히 제거할 수 있다. 자, 이제 몇 가지 차트를 적용해보았다. 또한 일부를 커스터마이즈해보았다. 이제 직접 만들 준비가 되었다. 헬름은 이 부분도 쉽게 해준다. ```bash $ helm create diy Creating diy ``` 이제 `diy` 라는 새 차트가 생겼다. 해당 디렉터리로 이동하여 편집하거나 `helm template` 을 실행하여 렌더링된 출력 결과를 보거나 `helm install` 을 사용하여 설치할 수 있다. [헬름 허브](https://hub.helm.sh/)에 업스트림으로 제출할 것인가? 주의하자! 헬름 허브에 [나만의 저장소를 추가](https://github.com/helm/hub/blob/master/Repositories.md)하기 위한 문서를 따라야 한다. ## 헬름 3에서 변경되는 사항은? 이쯤에서 이런 의문이 들지도 모르겠다. > 헬름 2에서는 워크플로가 어떻게 변경되었나? 헬름 2로 이러한 명령을 실행하면 동일한 출력 결과가 표시될까? 헬름 2는 차트 생성, 설치, 관리를 위한 워크플로를 기술하였다. 헬름 3는 이러한 워크플로를 기반으로 진화하는 생태계의 요구사항을 충족하도록 기본 인프라를 변경하였다. 만약 사용자가 헬름 2에 익숙할 경우, 헬름 3 를 사용하면 마치 집에 있는 것처럼 편안하게 느껴질 것이다. 내부적으로 변경된 사항에 대해 자세히 알아보기 위하여 문서의 [FAQ를 확인](https://helm.sh/docs/faq/)하자. 변경 목록과 관련된 변경 사항에 대한 설명이 여기 제공된다. ## 헬름의 미래 핵심 관리자들은 헬름 3를 출시하게 되어 매우 기쁘다. 헬름의 다음 개발 단계에서는 기존 기능에 대한 안정성 및 향상을 목표로 하는 새로운 기능을 볼 수 있다. 로드맵 상의 기능은 다음과 같다: - `helm test` 의 기능 향상 - 헬름의 OCI 연계 개선 - Go 클라이언트 라이브러리의 기능 향상 ### 헬름 2 지원 계획 헬름 2.15.0 릴리스 발표에서 헬름 2의 향후 계획에 대한 세부사항을 공유했다. 이 계획에 대한 자세한 내용은 [공지 게시물](https://helm.sh/blog/2019-10-22-helm-2150-released/)에서 확인할 수 있다. ## 헬름 3와 헬름 1, 2와의 관계 2015년 11월, 첫 번째 KubeCon 에서 헬름 첫 번째 버전이 출시되었다. macOS 소프트웨어 인스톨러 [Homebrew](https://brew.sh/)에서 모델링된 헬름 1 (팀에서는 "헬름 클래식" 이라고 한다)은 개별 개발자가 쿠버네티스 리소스 패키지를 만들고 클러스터에 배포할 수 있도록 설계되었다. 몇 달 후(2016년 1월), Deis 의 코어 헬름 팀은 구글, Skippbox, Bitnami 와 협력하여 개인들에서 팀으로 방점을 옮겨 새로운 버전의 헬름을 제작하였다. 그 과정에서 여러 경험과 교훈들이 적용되었다. 그 결과 팀워크는 핵심가치가 되었고, 정교한 애플리케이션을 설치하려는 쿠버네티스 사용자들의 참여로 급성장한 커뮤니티의 요구를 충족시키기 위해 설계된 도구가 탄생하였다. 2018년 6월 헬름은 [Cloud Native Computing Foundation에 가입](https://helm.sh/blog/helm-enters-the-cncf/)했다. 헬름 3는 Microsoft, 삼성 SDS, IBM 및 Blood Orange의 구성원을 포함하는 주요 유지관리자들의 공통된 노력이다. 첫 번째 알파 릴리스 이래로, 헬름 3는 여러 시간대(time zone)에 걸쳐 커뮤니티 구성원 37명의 기여가 있었다. 그 결과물은 시시각각 변화하고 진화하며 커뮤니티의 요구를 담아낸 도구이다. ## 결론 우리는 쿠버네티스로의 진입로가 되는 도구를 만들었다. 쿠버네티스 사용자가 운영 수준의 워크로드를 더 쉽게 생성, 공유, 실행할 수 있도록 돕고자 했다. 설립 이래 500명 이상의 커뮤니티 회원이 헬름 CLI를 위한 코드에 기여해왔다. 수천 명의 커뮤니티 회원이 헬름 허브에서 차트를 활성적으로 관리한다. 수많은 활성 커뮤니티 회원들이 있다. 이는 이 프로젝트를 간단한 Deis 인스톨러를 모든 쿠버네티스 사용자를 위한 강력한 도구로 탈바꿈시킨 쿠버네티스 커뮤니티의 엄청난 노력에 의한 산물이다. 모두 감사합니다. 깃헙에서 또 봐요! - 헬름 팀 :heart: ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2019-11-15-helm-at-cloudnativecon.md ================================================ --- title: "KubeCon + CloudNativeCon NA 2019 에서의 헬름" authors: ["mattfarina"] date: "2019-11-15" --- 다음 주에는 연례행사인 [KubeCon 과 CloudNativeCon 이 북미에서](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/) 열린다. 헬름 프로젝트 및 유지관리자들은 몇 가지를 준비하고 있고 여러분을 초대하고 싶다. 헬름 관련으로는 유지관리자 트랙 세션이 2개 있으며, [_헬름 소개_](https://sched.co/UajI) 및 [_헬름 3 심층 분석_](https://sched.co/Uagg)에 초점을 둔 내용이다. 헬름을 처음 사용하거나, 사용해야 하는 이유와 방법에 관심이 있는 사람은 _헬름 소개_ 세션에 참석해보자. [최근 출시된 헬름 3](https://helm.sh/blog/helm-3-released/)가 궁금한 사용자는 _헬름 3 심층 분석_ 세션이 적당할 것 같다. 관심을 가질 법한 주변 사람들에게도 널리 알려주자. 올해는 헬름 프로젝트가 자체 프로젝트만의 독립된 부스를 가지는 첫 해이기도 하다! 헬름 유지관리자와 얘기를 나누고 싶거나 프로젝트에 대해 질문이 있다면 부스를 방문하여, 정기적으로 프로젝트를 진행하는 사람들을 만나보도록 하자. 올해는 커뮤니티에서 준비한 몇 가지 흥미로운 헬름 관련 세션들도 있다. 예를 들어, CERN 의 Ricarto Rocha 는 [_CERN 에서 Gitops와 함께 헬름 배포 관리하기_](https://sched.co/UabD)에 대한 내용을 발표한다. [공식 일정표](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/schedule/)에서 다른 세션에 대한 일정도 확인할 수 있다. 컨퍼런스가 시작하기 전 주말에 가도 될까? [Cloud_Native Rejekts](https://cloud-native.rejekts.io/)가 계속 진행될 것이며, 헬름 프로젝트 유지관리자 중 한 명인 Taylor Thomas는 [_(헬름으로 배우는) 쿠버네티스와의 고급 상호작용_](https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-na-2019/talk/SQ9DWX/)을 발표할 예정이다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-04-02-covid-19-extending-helm-v2-bug-fixes.md ================================================ --- title: "COVID-19: 헬름 v2 버그 수정 확장" slug: "covid-19-extending-helm-v2-bug-fixes" authorname: "Matt Farina & Bridget Kromhout" authorlink: "https://helm.sh" date: "2020-04-03" --- 전 세계가 전염병에 맞서 싸우기 위해 힘을 모으는 것처럼 헬름 유지관리자들도, 개발 및 운영 일정이 조정되는 시기에도 최대 수요로 작동하는 주요 시스템을 유지보수하는 사용자들에게, 도움을 주는 역할을 잘 수행하고 있는지 점검하고자 한다. 헬름 v3가 2019년 11월에 출시되었을 때, 원래의 약속은 6개월 동안 헬름 v2 버그 수정을 제공하겠다는 것이었다. 버그 수정은 2020년 5월 13일에 종료되고, 그 후로 6개월 간 보안 수정이 예정되어 있었다. 감염병 예방이 우선이라는 전제 하에, 헬름 v2 버그 수정을 2020년 8월 13일까지 3개월 연장하여 헬름 사용자들이 커뮤니티의 가장 필요한 요구 사항에 대응할 계획이다. 여러 가지 상황으로 인해 추가 일정 조정이 필요한지 확인하기 위해 상황을 모니터링할 것이다. 현재로서는 헬름 v2 지원이 11월 13일에 종료될 예정이다. (다만 보안 수정만은 3개월간으로 계획되어 있다.) 핵심 업무의 단절을 방지하고 안전을 지키기 위해 우리가 할 수 있는 일이 있다면 [커뮤니티 연락, 채팅, 메일링 리스트, 깃헙 저장소'](https://github.com/helm/community/blob/main/communication.md)를 통해 얘기해보자! ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-04-30-celebrating-helms-cncf-graduation.md ================================================ --- title: "헬름의 CNCF 졸업을 축하하며" slug: "celebrating-helms-cncf-graduation" authors: ["mattbutcher"] date: "2020-04-30" twittertype: "summary_large_image" twitterimage: "blog/images/helmgraduation-twitter.png" --- ![../images/helmgraduation.png](./images/helmgraduation.png) 오늘 헬름이 [CNCF 사다리의 마지막 단계에 도달한 것](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)을 보게 되어 기쁘다. 헬름은 [CNCF 프로젝트](https://www.cncf.io/projects/)의 인큐베이팅 단계에서 졸업 단계로 이동하여, 쿠버네티스 등 다른 선택된 프로젝트들과 나란히 서게 되었다. 헬름은 작은 스타트업 Deis의 해커톤 프로젝트로 소박하게 시작되었는데, 우리의 작은 아기가 완전히 성인으로 성장한 것처럼 기분이 정말 좋다. 그리고 우리는 지난 5년 동안 코딩, 커뮤니티, 조직 정책에 대해 많은 것을 배웠다. 그러나 이것이 우리가 헬름의 졸업을 축하하는 주요 이유는 아니다. 헬름 프로젝트를 시작하고 몇 달 후, 우리는 쿠버네티스의 하위 프로젝트가 되었다. 그게 2016년 초였는데, 얼마 지나지 않아 사이드 프로젝트 수준이 아닌 쿠버네티스 생태계의 패키지 관리자로 자리매김하게 되었다. 쿠버네티스는 복잡성을 감추지 않고 SRE 및 DevOps 스토리에 집중했지만, 헬름은 다른 접근 방식을 취했다. 2016년 2월 회의에서 [Michelle Noorali](https://twitter.com/michellenoorali)는 화이트 보드에 다음과 같은 문구를 썼다. "5분만에 0에서 도파민까지" 이것이 우리 헬름의 만트라였다. 새로운 사용자를 쿠버네티스에 더 쉽게 접근하게 할 수 있다고 보았다. 우리가 옳았다면, 사용자는 헬름을 설치하고 몇 분 내로 운영 수준의 규격품 구성요소들을 설치할 수 있을 것이다. 요즘 헬름은 대학생부터 주요 클라우드 제공 업체에 이르기까지 [쿠버네티스 사용자의 70% 이상이 사용](https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf)하고 있다. 신규 쿠버네티스 사용자가 헬름 덕분에 빠르게 설치하고 구동시킬 수 있었다는 얘기를 들을 때가 가장 뿌듯하다. 한편, 헬름의 졸업은 2번째 구별점을 뜻한다. 헬름의 첫 번째 커밋 이래로 우리는 이것을 "쿠버네티스용 패키지 관리자"라고 불렀다. 즉 전반적인 설계의 초점은 쿠버네티스 리소스 정의 번들의 재배포, 설치, 업그레이드, 삭제를 가능하게 하는 것이다. 우리의 목표는 macOS 에서의 homebrew, 데비안/우분투에서의 apt-get, 윈도우에서의 Chocolatey처럼 쿠버네티스에서의 패키지 관리자가 되는 것이었다. 당시에는 대단하지 않은 목표로 보였다. 쿠버네티스(버전 1.2) 사용자도 거의 없었다. 그런데 갑자기 쿠버네티스의 인기가 폭발적으로 증가했다. 몇몇 유명 회사에서는 운영 환경에 사용하기 시작했다. 그런 다음에는 주요 클라우드 제공 업체가 호스팅된 쿠버네티스 상품을 만들었다. 그리고 화려함보다 안정성을 추구하던 대기업들도 쿠버네티스를 본격적으로 사용하기 시작했다. 이것은 헬름에 대한 시험대(acid test)였다. 서로 다른 목표와 요구를 가진 사용자 수십만 명의 요구를 충족시킬 수 있는가? 그런 것 같아 보인다. "졸업"이라는 용어는 주요 요구사항들을 완수했다는 것을 의미한다. 수많은 사용자 기반을 갖춘 것은 고무적이었지만, CNCF 는 엔터프라이즈 준비도를 시험하는 기준 목록을 제시한다. 안정성, 보안, 강건한 거버넌스, 강력한 커뮤니티 -- 대규모 오픈 소스 프로젝트가 성공하려면 이러한 것들이 절대적으로 필요하다. CNCF는 [프로젝트](https://www.cncf.io/projects/)가 대다수의 사용자들이 사용할 수 있도록 준비되었다는 것을 입증할 때만 졸업시킨다. 인큐베이션에서 졸업으로 이동하기 위한 기준 목록은 안정적인 오픈 소스 프로젝트가 무엇인지를 정의하고 있다. 헬름에는 졸업 기준들이 깊이 녹아있다. 헬름은 보안 검토를 그냥 통과한 수준이 아니라 아주 우수한 성적으로 통과했다. 우리는 [CII 뱃지](https://bestpractices.coreinfrastructure.org/en)를 획득했을 뿐 아니라, [인증테스트에서 198%](https://bestpractices.coreinfrastructure.org/en/projects?q=helm%20package%20manager)를 기록했다. 서로 다른 회사의 커미터 2명만 있었지만, 이제는 전세계적으로 수많은 기여자들이 있다. 그리고 지난 수년간 개방적이고 공정한 거버넌스라는 우리의 약속을 지켜왔다. 그래서 지금 우리는 이 이정표에 서 있다. 우리는 졸업에 관한 마지막 요구사항을 완수하였다. CNCF 기술 감독위원회(TOC)에서 대다수는 헬름이 최고 수준의 프로젝트라는 데에 동의하여 투표하였다. 그렇다면 앞으로 헬름에는 어떤 변화가 있을까? 프로세스 측면에서는 모든 것이 그대로 유지된다. 우리는 메이저 버전에서 마이너 버전까지 안정성과 호환성에 대한 확고한 약속을 계속 유지할 것이다. 헬름 4에서 어떤 것이 더 필요할지에 대한 초기 단계의 조사도 시작하였다. 우리는 (항상 그랬듯이), 커뮤니티에 자신의 경험을 공유하려는 사용자, 상당한 시간을 들여 프로젝트 유지에 기여하려는 노련한 전문가 등 새로운 참여자를 열렬히 환영한다. 또한 우리는 CNCF 내에서 몇 가지 주요 움직임을 하나로 모으게 될 [CNCF 아티팩트 허브](https://devclass.com/2020/03/12/cncf-starts-new-artifact-hub/)에 대해서도 기대하고 있다. CNCF 커뮤니티와의 협업을 계속 해나는 것도 신나는 일이다. 우리의 전통에 따라, 헬름의 성공에 기여한 수만 명의 커뮤니티 회원들에게 커다란 감사의 마음으로 전하며 이 글을 마친다. "5분만에 0에서 도파민까지" 경험을 모든 쿠버네티스 사용자에게 전해주기 위한 오랜 노력이 여기에 있다! ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-08-13-helm-v2-deprecation-timeline.md ================================================ --- title: "헬름 v2 사용중단 타임라인" slug: "helm-v2-deprecation-timeline" authors: ["bridgetkromhout"] date: "2020-08-12" --- _[루이스 캐롤에게 고개를 끄덕이며...](https://www.jabberwocky.com/carroll/walrus.html)_ “때가 되었습니다,” 메인테이너(maintainers)는 말한다, “소프트웨어의 운명에 대하여 이야기하기 위해: 업그레이드와 -- 헬름 v3의 출시와 -- 버그의 수정 -- 그리고 k8s. --” 헬름 v3는 [2019년 11월에 출시되었으며](/blog/helm-3-released/), 커뮤니티의 요구에 부응하여 헬름을 계속 발전시켜온 커뮤니티의 노력의 결과입니다. 간소화된 클라이언트 단독 사용환경, 새로운 보안 관점, 쿠버네티스 API와의 더욱 긴밀한 연계를 통하여 헬름 v3는 쿠버네티스에 대한 운영 테스트 패키지 관리 기능을 계속 제공합니다. 그리고 [졸업한 CNCF 프로젝트](/blog/celebrating-helms-cncf-graduation/)인 헬름은 클라우드 네이티브 생태계의 핵심부분입니다. 운영 환경에 주(major) 버전 변경사항을 반영하려면 시간이 필요하다는 것을 우리도 인지하고 있다. 헬름 메인테이너(maintainer)는 2020년 5월까지 헬름 v2에 대한 버그픽스([2020년 8월로 연장됨](/blog/covid-19-extending-helm-v2-bug-fixes/)), 2020년 11월까지 헬름 v2에 대한 보안패치를 제공하기로 했다. 그리고 이제 버그픽스 창은 닫힙니다. [헬름 v2.16.10](https://github.com/helm/helm/releases/tag/v2.16.10)은 최종 버그픽스 릴리스이며 2.17.0은 [다운로드 위치가 변경](https://github.com/helm/helm/issues/8346)되어 나올 것이다. 헬름 사용자에게 이는 어떤 의미인가? _2020년 8월 13일 이후, 다음의 변경 사항이 적용된다:_ - 만약 아직 헬름 v2를 사용중인 경우 지금 [헬름 v3로 마이그레이션](/blog/migrate-from-helm-v2-to-helm-v3/)하는 것이 좋다. 헬름 3.2.4는 널리 사용되고 있으며 운영준비가 되어있다. 대체로 이전 버전과 호환되지만 마이그레이션을 수행할 때 알아야 할 변경사항들이 있다. - 지금부터, 헬름 v2에 대한 지속적인 지원은 향후 3개월의 보안패치로 제한된다. 즉, 확인된 보안 문제 외에는 더 이상 PR 요청을 수락하지 않는다. - `stable` 및 `incubator` 저장소는 [2018년 12월에 도입된](/blog/intro-helm-hub/) 헬름 허브에서 삭제된다. [헬름 허브](https://hub.helm.sh)에서 선호하는 저장소를 찾아 구성에 추가하고, [새로운 분산 저장소들로의 마이그레이션을 수행해야](https://github.com/helm/charts/issues/21103) 한다. _2020년 11월 13일 이후로 다음과 같은 변경사항이 적용된다._ - 더 이상 헬름 v2는 릴리스되지 않는다. (보안 패치조차도) - 더 이상 [헬름 v2 문서](https://v2.helm.sh/docs)에 대한 업데이트도 없다. 현재로서는 계속 사용될 수도 있지만, 중단될 수도 있다. - v2와 관련된 기존 및 신규 이슈/PR 은 닫히게 된다. - [헬름 릴리스와 차트 호스팅에 대한 소유권(ownership)을 CNCF로 이관](https://github.com/helm/community/issues/114). | | | | - | - | | 제거 예정 | 교체 예정 | | 구글 클라우드 스토리지를 통한 헬름 v2 클라이언트 다운로드 | [get.helm.sh](/blog/get-helm-sh/)을 통한 클라이언트 다운로드 | | 구글 컨테이너 레지스트리에 저장된 틸러(Tiller)용 도커 이미지 | [대신 다른 위치에서 사용 가능한](https://github.com/helm/helm/issues/8346) 틸러 이미지를 배포하며, helm init --tiller-image 명령어로 업데이트 가능하게 할 것이다. | | 안정적(stable)인 인큐베이터 차트 저장소를 위한 구글 클라우드 버킷 | “안정적” 인 “인큐베이터” 저장소 사용 중단; https://github.com/helm/charts 는 사용되지 않음(obsolete)으로 표시 | 커뮤니티는 헬름 v3가 훨씬 개선된 환경임을 확인했으며, [helm-2to3 플러그인](https://github.com/helm/helm-2to3)과 같은 커뮤니티 리소스를 사용하여 필수 마이그레이션을 지원할 수 있다. 더 이상 보안 패치가 제공되지 않는 소프트웨어를 운영하게 되는 위험을 피하는 가장 좋은 방법은, 11월 13일 이전에 헬름 v3로의 마이그레이션을 완료하는 것이다. 이 자리를 빌어, 헬름을 사용하거나 개선을 위해 문제를 제기하거나 요청을 제출한 커뮤니티의 모든 분들께 감사드린다. 여러 훌륭한 아이디어들이 헬름에는 맞지 않더라도 [관련 생태계의 프로젝트](/community/related)에서 많은 성공을 거두었다. 문서에 대한 업데이트를 제출할 때마다 다른 사용자들이 헬름을 시작하고 더 효과적으로 사용하는 데 도움이 된다. 모두들 감사합니다! ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-10-07-helm-hub-moving-artifact-hub.md ================================================ --- title: "헬름 허브의 아티팩트 허브로의 이동" slug: "helm-hub-moving-to-artifact-hub" authors: ["mattfarina"] date: "2020-10-07" --- 오늘 헬름 허브가 [아티팩트 허브](https://artifacthub.io/)로 이동한다. 즉, 헬름 허브로 이동하면 아티팩트 허브로 리다이렉션된다. ## 이것은 무엇을 의미하는가? 헬름 허브를 검색하거나 헬름 허브에서 차트 목록을 조회할 때 의문이 들지도 모르겠다. 무슨 차이가 있는걸까? 아티팩트 허브에서는 헬름 허브에서 조회된 것과 동일한 차트 목록이 모두 조회된다. 더 빠른 검색을 제공하며 [국면 검색](https://en.wikipedia.org/wiki/Faceted_search)을 포함한다. 이전과 비슷한 방식으로 차트를 검색할 수 있다. 검색은 헬름 CLI에서도 계속 작동한다. 아티팩트 허브에는 차트를 검색하는 것 외에도 많은 기능이 있다. 차트가 업데이트되면 이메일 또는 웹훅을 통해 알림을 받을 수 있다. 다른 아티팩트를 찾고 관련 아티팩트를 볼 수 있다. 아티팩트 허브에는 헬름 허브보다도 많은 것을 제공한다. 헬름 허브에 차트 저장소를 나열하고 아티팩트 허브에 아직 나열하지 않은 경우 자동으로 가져온다. 아티팩트 허브는 저장소를 요청하고 새 저장소를 나열하는 수단을 제공한다. 저장소를 나열할 때 사용자 계정 또는 다중 사용자 조직에 연결할 수 있다. ## 왜 이렇게 해야 하는가? 헬름 허브는 모노큘러(Monocular) 프로젝트를 기반으로 구축되었다. 이 프로젝트는 제한된 수의 헬름 저장소를 처리하도록 빌드되었으며, 가능한한 많은 차트 저장소의 공개 목록과 약간 다른 사용 사례를 위해 설계되었다. 헬름 프로젝트를 잘 수행해왔지만, 헬름 차트 및 저장소 수가 증가함에 따라 몇가지 제한 사항들이 나타나기 시작했다.헬름 허브를 사용하여 이 문제에 대해 뭔가를 해야 한다는 것을 우리도 알고 있었다. 우리가 성장에 대한 문제를 경험하기 시작하면서 아티팩트 허브가 등장했다. 아티팩트 허브의 자체 인스턴스를 운영하거나 스케일링 문제를 처리하기 위해 자체 소프트웨어를 작성하는 대신 차트 검색 및 관리를 처리하기 위해 아티팩트 허브를 사용하기로 결정했다. 아티팩트 허브는 단순히 차트만 제공하는 것이 아니라 더 많은 CNCF 생태계를 지원하고 홍보하고 있다. ## 질문, 우려 또는 문제점 만약 전환하다가 문제가 있으면 알려 달라. 알리는 방법은 몇 가지가 있다. 1. 문제가 마이그레이션 간 아티팩트 허브의 차트 저장소에 대한 것이라면, [헬름 허브 저장소](https://github.com/helm/hub)에 이슈를 등록하자. 2. 아티팩트 허브 사이트에 문제가 있다면 [아티팩트 허브 프로젝트](https://github.com/artifacthub/hub)에 이슈를 등록할 수 있다. 이 곳은 CNCF 프로젝트이자 오픈소스 프로젝트이다. 3. 헬름 CLI를 사용하여 아티팩트 허브를 검색하는 데 문제가 있는가? [헬름](https://github.com/helm/helm)에 이 이슈를 등록할 수 있다. 차트의 URL은 검색에서 찾을 때 기본적으로 `hub.helm.sh` 로 시작된다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-10-19-helm-turns-five.md ================================================ --- title: "헬름 5주년과 깃헙으로부터의 차트 선물" slug: "helm-turns-five" authors: ["mattbutcher", "mattfarina"] date: "2020-10-19" --- {{< figure src="https://helm.sh/blog/images/happy-5th.png" alt="헬름의 5번째 생일 축하" >}} 5년 전, Deis(그 후 마이크로스프트에 인수됨)의 해커톤에서 헬름이 탄생했다. ``` commit ecad6e2ef9523a0218864ec552bbfc724f0b9d3d Author: Matt Butcher Date: Mon Oct 19 17:43:26 2015 -0600 initial add ``` [이 커밋](https://github.com/helm/helm-classic/commit/ecad6e2ef9523a0218864ec552bbfc724f0b9d3d)은 헬름 v1 용 코드베이스가 있는 헬름 클래식 깃 저장소에서 찾을 수 있다. 이것은 디플로이먼트 매니저와 병합되어 쿠버네티스에 합쳐지기 전의 원래 헬름이다. 이것이 모든 것이 시작된 곳이다. 첫날부터 헬름 프로젝트는 소스 관리, 풀 요청 관리 및 문제 추적을 위해 깃헙을 사용해왔다. 졸업한 CNCF 프로젝트로서, 헬름 조직은 이제 수십 개의 깃헙 저장소를 운영하고 있다. 하지만 패키징된 차트를 호스팅할 때는, 구글 클라우드에서 호스팅하는 객체 스토리지 버킷에 저장했다. 당시의 이러한 결정은 구글이 헬름의 주요 기여자였다는 점이 반영된 것이다. 최근, 구글의 공식 헬름 차트 저장소 지원기간이 종료되었다. 지난 몇 년동안 구글이 헬름 차트 저장소를 호스팅해준 것에 대해 감사한다. 또한 이 일은 차트 개발 파이프라인을 깃헙과 통합할 수 있는 기회가 되었다. {{< figure src="../images/octocat.png" alt="Hello Github Octocat!" width="350px" >}} 그래서 오늘의 생일 축하 행사에서, 헬름 `stable` 및 `incubator` 차트 저장소가 깃헙에서 직접 호스팅된다는 것을 알리고자 한다. 또한, 깃헙 액션으로 차트 게시를 위한 파이프라인이 강화되었다. 깃헙의 엄청 빠른 네트워크 덕분에 차트 다운로드가 그 어느 때보다 더욱 빨라졌다! 깃헙 마켓 플레이스에 공식 헬름 깃헙 액션을 게시하였다. 깃헙에서 헬름 차트를 호스팅하는 방법에 대해서는 [헬름 차트 릴리서(Helm Chart Releaser)](https://github.com/marketplace/actions/helm-chart-releaser)를 참고하자. 헬름 2는 지원이 종료되었지만, [공식 틸러 도커 이미지](https://github.com/orgs/helm/packages)는 깃헙의 컨테이너 저장소에도 옮겨 놓았다. 깃헙에서 제공한 도구와 여러 오픈 소스 프로젝트에 대한 지원에 깊이 감사한다. 생일 축하한다, 헬름! ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-10-26-new-location-stable-incubator-charts.md ================================================ --- title: "Stable 및 Incubator 차트를 위한 새로운 공간" slug: "new-location-stable-incubator-charts" authors: ["mattfarina"] date: "2020-10-26" --- [이전에 발표한 것과 같이](https://helm.sh/ko/blog/helm-turns-five/), stable 및 incubator 저장소가 새로운 공간으로 이동하게 된다. 이 게시물은 새로운 위치에 대한 업데이트를 제공하고 그것을 사용하는 방법을 제공한다. _**중요한 참고사항:** 이는 2019 년에 발표된 stable 및 incubator 저장소의 오래된 타임 라인에 영향을 주지 않는다. 2020 년 11 월 13 일에 stable 및 incubator 차트 저장소는 개발이 끝나고 아카이브가 된다. 많은 차트가 커뮤니티에서 관리하는 다른 저장소로 이동했음을 알 수 있다. [아티팩트 허브](https://artifacthub.io/)에서 확인할 수 있다. 노후화에 대한 자세한 정보는 향후 블로그 게시물 및 커뮤니케이션에서 이어질 예정이다._ stable 저장소의 새 위치는 https://charts.helm.sh/stable이고 incubator 저장소의 새 위치는 https://charts.helm.sh/incubator 이다. 아래의 이전 위치 중 하나에서 차트를 사용하는 경우 2020 년 11 월 13 일 이전에 사용하는 저장소를 업데이트 해야한다. 새 위치는 깃헙 페이지를 사용하여 호스팅된다. | 이름 | 이전 위치 | 새 위치 | | --------- | ------------ | ------------ | | stable | https://kubernetes-charts.storage.googleapis.com | https://charts.helm.sh/stable | | incubator | https://kubernetes-charts-incubator.storage.googleapis.com | https://charts.helm.sh/incubator | 새 위치와 함께 헬름 v2.17.0 및 v3.4.0 이 릴리스 되어 새 위치에서 사용할 수 있다. 최신 버전으로 업그레이드하는 것이 좋다. ## 헬름 v3.4.0 헬름 v3.4.0은 이제 이전 위치로 구성된 안정 및 인큐베이터 저장소가 있는지 감지하고 구성을 새 위치로 업데이트해야 함을 경고한다. 단일 명령을 사용하여 이를 수행 할 수 있다. 예를 들어 `stable` 이라는 이름으로 설정된 안정적인 저장소를 업데이트하려면 다음을 실행할 수 있다. ``` helm repo add stable https://charts.helm.sh/stable --force-update ``` 이 명령은 v3.4.0 이전의 헬름 v3 버전에서도 작동한다. 최신 헬름 v3 릴리스로 업데이트하지 않고도 사용할 수 있다. 또한 `helm repo add` 를 사용하여 이전 위치에 있는 저장소 중 하나를 추가하려고 하면 Helm v3.4.0 이상 버전은 저장소를 추가하지 못하고 새 위치를 사용하도록 경고한다. 자동으로 새 위치를 추가하는 대신 사람들에게 위치 변경을 알리고 싶은 의도이다. 이전 위치 중 하나를 사용해야하는 이유가 있는 경우 새로운 `--allow-deprecated-repos` 플래그를 사용할 수 있다. 플래그는 이전 위치가 계속 작동하는 동안에만 유용하다. ## 헬름 v2.17.0 헬름 v2 에서는 `helm init` 가 실행될 때 기본적으로 stable 저장소를 추가했다. 이로 인해 v2.17.0 부터는 헬름 v2 에 대한 다른 솔루션이 도입되었다. stable 저장소 또는 로컬 저장소가 필요하지 않은 경우 `helm init` 를 실행할 때 `--skip-repos` 플래그를 사용할 수 있다. 이것은 v2.17.0의 새로운 플래그이다. 안정적인 저장소를 사용하지 않는 CI 시스템과 같은 일부 사용 사례에서 성능상의 이점이 있을 수 있다. v2.17.0 에서 `helm init` 가 실행되면 이전 위치 대신 새 위치가 사용된다. 이것은 정기적으로 `helm init` 를 실행하는 CI 시스템에서 발생한다. 이전 위치를 계속 사용해야 하는 경우 새로운 `--use-deprecated-stable-repository` 플래그를 `helm init` 에 전달할 수 있습니다. 이것은 이전 위치가 계속 작동하는 동안에만 작동한다. stable 또는 incubator 저장소에 대해 구성된 이전 위치가 이미 있는 경우 헬름은 새 위치로 전환해야 한다는 경고를 표시한다. Helm v2에서는 작업 수행 시 두 개의 명령을 사용해야 한다는 점에서 Helm v3와 약간 다르다. 예를 들어 `stable` 저장소를 변경하려면 다음을 실행할 수 있다. ``` helm repo rm stable helm repo add stable https://charts.helm.sh/stable ``` 이 명령은 v2.17.0 이전의 Helm v2 버전에서 작동한다. 최신 Helm v2 릴리스로 업데이트 하지 않고도 사용할 수 있다. _참고 : GitHub 페이지로 이동하는 stable 및 incubator 저장소 외에도 [틸러(Tiller)의 기본 위치가 GitHub 컨테이너 저장소 (ghcr.io)로 이동되었다](https://github.com/orgs/helm/packages/container/package/tiller). [틸러는 GCR에서 계속 사용할 수 있다](https://gcr.io/kubernetes-helm/tiller) (이전 위치). [도커 허브] (https://hub.docker.com/r/helmpack/tiller) 및 [Quay] (http://quay.io/helmpack/tiller)에서도 틸러를 다운로드 할 수 있다. 틸러의 기본 위치가 아닌 위치를 지정하려면 `helm init`를 실행할 때 `-i` 또는 `--tiller-image` 플래그를 사용할 수 있다._ ## 사용자만의 복제본 호스팅 하기 헬름이 네트워크 호출을 할 수 있는 위치를 제어 할 수 있고 헬름이 깃헙 페이지를 호출하지 않도록 하는 경우가 있다. stable 또는 incubator 저장소의 차트가 필요한 경우 한 가지 옵션은 자신의 저장소에 필요한 차트 및 차트 버전의 사본을 호스팅하는 것이다. [ChartMuseum] (https://github.com/helm/chartmuseum), [Harbor] (https://goharbor.io/), 정적 웹 서버 또는 다른 시스템으로 이 저장소를 호스팅 할 수 있다. 헬름 조직 및 차트 관리자 중 한 명인 Scott Rigby는 [차트와 기록의 전체 또는 일부를 복사 할 수있는 스크립트](https://github.com/scottrigby/helm-adopt-package-history)를 만들었다(이전 차트 버전). 이 도구 및 이와 유사한 도구를 사용하여 사용하는 차트의 복사본을 만들 수 있다. 이것은 다른 위치에서 제공 될 수 있다. 헬름 v2 에서는 `--stable-repo-url` 플래그를 사용하여 `helm init` 를 실행할 때 안정적인 저장소의 대체 위치를 지정할 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/2020-10-30-charts-repo-deprecation.md ================================================ --- title: "헬름 차트 저장소 지원 중단 업데이트" slug: "charts-repo-deprecation" authors: ["viciglesias"] date: "2020-10-30" --- 2019 년에 헬름 v2 지원 타임 라인 및 수명 종료 계획이 발표되었을 때 [helm/charts GitHub 저장소](https://github.com/helm/charts)의 [지원 중단](https://github.com/helm/charts#deprecation-timeline)도 발표되었다. 지원 중단의 주된 이유는 [저장소 관리자](https://github.com/helm/charts/blob/master/OWNERS)의 유지 관리가 크게 증가했기 때문이다. 지난 몇 년 동안 유지 관리중인 차트 수가 100 개 이하에서 300 개 이상으로 증가하여 저장소에 대한 풀 요청 및 업데이트가 이에 상응하게 증가했다. 안타깝게도 검토 및 유지 관리 작업을 자동화하려는 많은 노력에도 불구하고 관리자의 유지 관리 시간은 단축되지 않았다. 지원 중단을 발표했을 때 우리는 helm/charts repo를 유지하는 데 사용했던 도구와 지침도 공유하기 시작했다. 자체 저장소를 호스팅하고 유지하려는 사람들을 위해 이제 다음 도구를 사용하여 프로세스를 간소화 할 수 있다. - [차트 테스트](https://github.com/helm/chart-testing)는 차트에 대한 PR 린팅(Linting) 및 테스트를 제공한다. - [차트 Releaser](https://github.com/helm/chart-releaser) 는 아티팩트를 호스팅하는 데 사용되는 깃헙 릴리스 및 페이지를 사용하여 자체 차트 저장소를 호스팅 하는데 도움이 되는 도구를 제공한다. - [깃헙 동작 테스트 및 릴리징](https://github.com/helm?q=chart+action) 는 위에서 설명한 깃헙 동작을 사용하여 도구를 자동화 한다. 이러한 도구를 사용하여 활성 유지 관리를 위해 많은 차트를 [자체 저장소로 마이그레이션] (https://github.com/helm/charts/issues/21103) 할 수 있다. ## 주요 날짜 및 권장되는 조치 계획이 수정되면서 다음에 일어날 일에 대한 혼란/질문이 있었기에 앞으로 진행할 주요 이벤트 및 ** 권장 조치 **의 타임 라인을 제공하고자 한다. * 2020년 11월 2일 - 지원 중단되지 않는 모든 차트의 README 에 더 이상 업데이트 되지 않는다는 메모가 추가된다. * **권장 조치** - 차트 저장소의 차트에 의존하는 경우 새 공식 위치를 찾아야 한다. 존재하지 않을 경우 차트의 적용을 고려하라. * 2020년 11월 6일 - [아티팩트 허브](https://artifacthub.io/)에서 stable 및 incubator 차트 저장소가 삭제된다. * **권장 조치** - 없음 * 2020년 11월 13일 - [helm/charts 저장소](https://github.com/helm/chart)의 CI가 비활성화되고 더 이상 Pull Request 가 허용되지 않는다. * **권장 조치** - 차트를 새 저장소로 재배치하기 위한 진행중인 발의(initiative) 대한 자세한 내용은 [이 문제](https://github.com/helm/charts/issues/21103)를 참조하자. * 2020년 11월 13일 *이후* - 이전 위치에서 차트를 다운로드하면 GitHub 페이지에서 사용할 수있는 읽기 전용 아카이브로 리디렉션된다. 이 날짜 이후에는 이전 위치를 더 이상 사용할 수 없다. * **권장 조치** - [보관된 stable 및 incubator 차트로의 전환](https://helm.sh/docs/faq/#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository)에 대한 정보를 참조하라. 이 차트는 더 이상 버그 수정이나 보안 패치로 업데이트되지 않는다. ## 참조 * [차트 저장소 지원 중단 일정](https://github.com/helm/charts/issues/23944) * [패키지 이력 재배치](https://github.com/helm/charts/issues/23850) * [헬름 차트 호스팅을 CNCF로 전환하도록 요청](https://github.com/helm/community/issues/114) ================================================ FILE: i18n/ko/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "블로그", "description": "The title for the blog used in SEO" }, "description": { "message": "블로그", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "모든 게시물", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/_v4-in-progress.mdx ================================================ :::warning 이 페이지는 아직 Helm 4에 맞게 업데이트되지 않았습니다. 일부 내용은 Helm 4에 부정확하거나 적용되지 않을 수 있습니다. Helm 4의 새로운 기능, 개선 사항, 그리고 비호환 변경 사항에 대한 자세한 내용은 [Helm 4 개요](/overview.md)를 참고하세요. ::: ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/changelog.md ================================================ --- sidebar_position: 2 sidebar_label: 전체 체인지로그 --- # 헬름4 전체 체인지로그 **범위**: `v3.19.0`과 비교, (`v4.0.0-rc.1`) 기준 290개의 PR **v4 전용**: 257개의 PR (v3로 백포트된 33개의 PR 제외) 이들 변경 사항에 대한 실질적 요약은 [개요](/overview.md)에서 확인하세요. ## 새로운 기능 {#new-features} v3로 백포트되지 않은 헬름4의 새로운 기능 | PR | Date | Author | Title | |---|---|---|---| | #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations | | #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise | | #31338 | 2025-10-21 | yzewei | Add loongarch64 support | | #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version | | #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml | | #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions | | #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context | | #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default | | #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions | | #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` | | #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command | | #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build | | #31217 | 2025-09-01 | scottrigby | BREAKING CHANGE: [HIP-0026] Move Postrenderer to a plugin type | | #31196 | 2025-08-31 | scottrigby | BREAKING CHANGE: [HIP-0026] Remove unnecessary file i/o operations from signing and verifying | | #31176 | 2025-08-30 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin packaging, signing, and verification | | #31194 | 2025-08-28 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Plugin extism/v1 runtime | | #30812 | 2025-08-27 | gjenkins8 | BREAKING CHANGE: HIP-0023: Helm support server-side apply | | #31174 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin tarball support for HTTP and local installers | | #31172 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin OCI installer | | #31146 | 2025-08-23 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin types and plugin apiVersion v1 | | #31145 | 2025-08-22 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin runtime interface | | #31142 | 2025-08-21 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Move pkg/plugin -> internal/plugin | | #31030 | 2025-08-14 | gjenkins8 | BREAKING CHANGE: HIP-0023: Kube client support server-side apply | | #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator | | #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues | | #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory | | #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses | | #31057 | 2025-07-18 | danilobuerger | Pass credentials when either chart repo or repo dont specify a port but it matches the default port of that scheme | | #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist | | #31011 | 2025-07-17 | yalosev | feature: add labels to metadata | | #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory | | #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks | | #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates | | #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions | | #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs | | #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 | | #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states | | #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog | | #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher | | #13617 | 2025-02-27 | AustinAbro321 | BREAKING CHANGE: Refactor cmd/helm to allow library usage | | #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output | | #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files | | #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value | | #30294 | 2025-02-19 | Zhanweelee | Supports json arguments | | #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext | | #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable | ## 버그 수정 {#bug-fixes} v3로 백포트되지 않은 헬름4의 버그 수정 | PR | Date | Author | Title | |---|---|---|---| | #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds | | #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package | | #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema | | #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy | | #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails | | #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil | | #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing | | #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle | | #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script | | #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test | | #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names | | #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided | | #31334 | 2025-09-30 | fleaz | Fix typo in bug-report issue template | | #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name | | #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) | | #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command | | #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 | | #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry | | #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message | | #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close | | #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count | | #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow | | #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr | | #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references | | #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests | | #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` | | #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config | | #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI | | #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata | | #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race | | #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 | | #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory | | #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test | | #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands | | #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors | | #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. | | #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex | | #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex | | #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME | | #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex | | #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources | | #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration | | #30884 | 2025-05-21 | mattfarina | Reverting fix "renders int as float" | | #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache | | #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message | | #30842 | 2025-05-15 | ayushontop | Fix : No repository is not an error,use the helm repo list command ,if there is no repository,it should not be an error #30606 | | #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors | | #30803 | 2025-04-25 | mattfarina | Fixing windows build | | #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test | | #30777 | 2025-04-23 | ryanhockstad | fix: null merge | | #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies | | #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly | | #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks | | #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. | | #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors | | #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test | | #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain | | #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts | | #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering | | #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured | | #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified | | #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos | | #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR | | #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` | | #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin | | #13425 | 2024-11-15 | MathieuCesbron | Fix typo "re-use" to "reuse" | ## 리팩터링/정리 {#refactorcleanup} 코드 품질 개선 및 현대화 | PR | Date | Author | Title | |---|---|---|---| | #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions | | #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed | | #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage | | #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor | | #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format | | #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go | | #31391 | 2025-10-15 | TerryHowe | chore: rename test registry | | #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature | | #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up | | #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object | | #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file | | #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces | | #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions | | #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations | | #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify | | #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema | | #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check | | #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer | | #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment | | #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command | | #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning | | #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory | | #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option | | #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions | | #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser | | #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed | | #31287 | 2025-09-16 | miledxz | improve fileutil test coverage | | #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder | | #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix | | #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient | | #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package | | #31225 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move lint pkg to be part of each chart version | | #31220 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: refactor: utilize `pluginTypesIndex` for config unmarshalling | | #31219 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: Remove 'SetupPluginEnv' | | #31216 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move to versioned packages | | #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value | | #31218 | 2025-09-01 | gjenkins8 | BREAKING CHANGE: Remove legacy Command/Hooks from v1 Subprocess (#23) | | #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace | | #31178 | 2025-08-28 | mattfarina | Add content cache to helm env | | #31165 | 2025-08-22 | mattfarina | BREAKING CHANGE: Initial addition of content based cache | | #13629 | 2025-08-22 | gjenkins8 | BREAKING CHANGE: Rename 'atomic' -> 'rollback-on-failure' | | #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 | | #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf | | #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment | | #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code | | #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go | | #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. | | #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable | | #30982 | 2025-08-05 | gjenkins8 | BREAKING CHANGE: Rename 'force' to 'force-replace' | | #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module | | #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 | | #31081 | 2025-07-25 | mattfarina | BREAKING CHANGE: Initial addition of v3 charts | | #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' | | #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq | | #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging | | #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file | | #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' | | #31023 | 2025-07-03 | gjenkins8 | BREAKING CHANGE: Remove deprecated '--create-pods' flag | | #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher | | #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable | | #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter | | #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings | | #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost | | #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter | | #30863 | 2025-05-16 | mattfarina | Adding test for list command | | #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling | | #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage | | #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter | | #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica | | #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code | | #13460 | 2025-04-23 | justenstall | fix: replace "github.com/pkg/errors" with stdlib "errors" package | | #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error | | #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency | | #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` | | #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points | | #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules | | #30749 | 2025-04-11 | mattfarina | BREAKING CHANGE: Removing the alpine test chart | | #30686 | 2025-04-11 | mattfarina | BREAKING CHANGE: Remove deprecated code | | #30736 | 2025-04-09 | robertsirc | manually updating go.mod file | | #13458 | 2025-04-05 | thudi | BREAKING CHANGE: #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation | | #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client | | #30603 | 2025-03-21 | robertsirc | converting inline log to slog | | #30699 | 2025-03-21 | mattfarina | Error when failed repo update. | | #30592 | 2025-02-28 | robertsirc | changing from log to slog | | #30589 | 2025-02-26 | mattfarina | BREAKING CHANGE: Move pkg/release to pkg/release/v1 to support v3 charts | | #30586 | 2025-02-25 | mattfarina | BREAKING CHANGE: Move pkg/chart to pkg/chart/v2 to prepare for v3 charts | | #30585 | 2025-02-25 | robertsirc | removing old apis | | #30580 | 2025-02-24 | mattfarina | BREAKING CHANGE: Move pkg/releaseutil to pkg/release/util | | #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times | | #30567 | 2025-02-21 | mattfarina | BREAKING CHANGE: Moving chartutil to chart/util | | #30566 | 2025-02-21 | robertsirc | remove unused config.go | | #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors | | #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra | | #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code | | #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern | | #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` | | #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions | | #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint | | #13494 | 2025-01-18 | gjenkins8 | BREAKING CHANGE: Remove deprecated `repo add --no-update` flag | | #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code | | #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` | | #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function | | #13611 | 2025-01-07 | mattfarina | BREAKING CHANGE: Updating the internal version to v4 | | #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions | | #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` | | #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` | | #13573 | 2024-12-27 | mattfarina | BREAKING CHANGE: Updating to helm.sh/helm/v4 | | #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags | ## 기타 {#other} 인프라 및 프로젝트 관리 개선 | PR | Date | Author | Title | |---|---|---|---| | #31197 | 2025-09-03 | tzchenxixi | chore: fix function name | | #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow | | #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow | | #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link | | #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go | | #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README | | #31002 | 2025-06-26 | curlwget | chore: fix function in comment | | #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates | | #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment | | #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 | | #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` | | #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge | | #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action | | #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration | | #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure | | #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow | | #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer | | #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment | | #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking | | #30693 | 2025-03-20 | linghuying | chore: make function comment match function name | | #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net | | #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' | | #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link | | #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info | | #30497 | 2025-02-12 | robertsirc | adding-my-key | | #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm | | #13653 | 2025-01-23 | petercover | chore: fix some comments | | #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation | | #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch | | #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo | | #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list | | #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules | | #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md | | #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore | | #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 | ## v3로도 백포트된 v4 변경 사항 {#v4-changes-also-backported-to-v3} 이 PR들은 v4에 포함됐지만 v3 릴리즈에도 백포트되었습니다. ### (백포트된) 새로운 기능 {#new-features-backported} | PR | Date | Author | Title | |---|---|---|---| | #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format | | #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template | | #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error | | #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling | | #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest | | #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields | | #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support | | #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output | ### (백포트된) 버그 수정 {#bug-fixes-backported} | PR | Date | Author | Title | |---|---|---|---| | #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 | | #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() | | #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth | | #31115 | 2025-08-18 | banjoh | fix: use username and password if provided | | #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning | | #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls | | #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original | | #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 | | #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport | | #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login | | #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet | | #30905 | 2025-05-23 | robertsirc | forward porting 30902 | | #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store | | #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 | | #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure | | #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs | | #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match | ### (백포트된) 리팩토링/정리 {#refactorcleanup-backported} | PR | Date | Author | Title | |---|---|---|---| | #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 | | #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 | | #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 | | #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 | | #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface | ### (백포트된 기타) {#other-backported} | PR | Date | Author | Title | |---|---|---|---| | #30775 | 2025-04-19 | benoittgt | Bump toml | | #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float | | #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 | ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/index.mdx ================================================ --- title: "문서 홈" description: "문서 구성에 관해 알아야 할 모든 것" sidebar_position: 1 --- # 환영합니다 [헬름](https://helm.sh/) 문서에 오신 것을 환영합니다. 헬름은 쿠버네티스 패키지 관리자이며, 자세한 배경 정보는 [CNCF 헬름 프로젝트 여정 보고서](https://www.cncf.io/cncf-helm-project-journey/)에서 확인할 수 있습니다. import DocCardList from "@theme/DocCardList"; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/overview.md ================================================ --- sidebar_position: 1 sidebar_label: 헬름 4 개요 --- # 헬름 4 개요 헬름 v4는 v3으로부터의 중대한 진화를 표하는 버전으로 차트에의 하위 호환성을 유지하는 한편으로 비호환적 변경사항, 새로운 아키텍처 패턴, 그리고 향상된 기능성을 도입합니다. 헬름 4 출시 단계별 계획에 대한 자세한 내용은 [헬름 v4로의 여정](https://helm.sh/blog/path-to-helm-v4/)를 참고해주세요. ## 무엇이 새로운가 {#whats-new} 이 섹션에서는 비호환적 변경사항, 주요 신기능, 기타 개선 사항을 포함하여 헬름 4에서 무엇이 새로운지를 간략히 개괄합니다. 전체 기술 세부 정보는 [전체 변경 로그](./changelog.md)를 참조하세요. ### 요약 {#summary} - **새 기능**: Wasm 기반 플러그인, kstatus 감시자, OCI 다이제스트 지원, 다중 문서 값, JSON 인수 - **아키텍처 변경**: 플러그인 시스템 전면 재설계, 패키지 구조 개편, CLI 플래그 이름 변경, 버전 관리 패키지로 전환, 차트 v3 지원, 콘텐츠 기반 캐싱 - **현대화**: slog 마이그레이션, Go 1.24 업데이트, 의존성 정리 - **보안**: OCI/레지스트리 지원 강화, TLS 개선 ### 비호환적 변경사항 {#breaking-changes} #### 플러그인으로 구현된 포스트 렌더러 {#post-renderers-implemented-as-plugins} 포스트 렌더러가 플러그인으로 구현됩니다. 이 변경과 함께 helm render --post-renderer에 실행 파일을 직접 전달하는 건 불가능해지며, 이후부터는 플러그인 이름을 전달해줘야 합니다. 이 변경으로 인해 기존 포스트 렌더러 워크플로우에 업데이트가 필요할 수도 있습니다. #### 레지스트리 로그인은 전체 URL을 허용하지 않음 {#registry-login-does-not-accept-full-urls} v4에서 `helm registry login` 명령은 반드시 도메인명으로 실행해야 합니다. 이는 향후 레지스트리의 다양한 수준에서 로그인 범위를 지정할 수 있게 하기 위함입니다. ### 새로운 기능 {#new-features} #### 플러그인 시스템 전면 개편 {#plugin-system-overhaul} 헬름 4는 보안 강화와 기능 확장을 위해 선택적인 WebAssembly 기반 런타임을 도입합니다. 기존 플러그인이 계속 동작하지만, 새 런타임이 플러그인 커스터마이징을 위해서 헬름의 코어 동작을 더 많이 활용할 수 있게 해줍니다. 헬름4는 CLI 플러그인, getter 플러그인, 포스트 렌더러 플러그인, 세 플러그인 유형 및 추가적인 코어 기능을 가능케 하는 시스템을 포함하여 출시됩니다. [HIP-0026 플러그인 시스템](https://github.com/helm/community/blob/main/hips/hip-0026.md) 및 [헬름 4 예제 플러그인](https://github.com/scottrigby/h4-example-plugins)을 참고하세요. :::tip 기존 플러그인은 이전과 동일하게 동작합니다. 새로운 WebAssembly 런타임은 선택 사항이지만 보안 강화를 위해 권장됩니다. ::: #### 향상된 리소스 모니터링 {#better-resource-monitoring} 신규 kstatus 통합이 배포 상태를 더 상세하게 제공합니다. 이슈를 더 잘 포착하는지 복잡한 애플리케이션으로 테스트해보세요. #### 향상된 OCI 지원 {#enhanced-oci-support} 공급망 보안 강화를 위해 다이제스트로 차트를 설치할 수 있습니다. 예를 들어 `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`와 같이 사용합니다. 다이제스트가 일치하지 않는 차트는 설치되지 않습니다. #### 다중 문서 값 {#multi-document-values} 복잡한 값을 여러 개의 YAML 파일로 분리하여 관리하세요. 다양한 환경 설정을 테스트하는 데 용이합니다. #### 서버 사이드 Apply {#server-side-apply} 여러 도구가 동일한 리소스를 관리할 때 충돌을 더 효과적으로 해결할 수 있습니다. 오퍼레이터나 다른 컨트롤러가 있는 환경에서 테스트해보세요. 헬름4는 새로운 차트 릴리즈를 설치할 때 기본적으로 서버 사이드 apply를 사용합니다. 업그레이드(또는 롤백)을 할 때는 기본적으로 이전 릴리즈의 apply 방식을 따릅니다. 이러한 래칭 동작은 클라이언트 사이드 apply를 사용하던 기존 릴리즈의 운영 연속성을 보장하기 위한 의도입니다. `--server-side` 플래그를 명시적으로 설정하여 이 동작을 오버라이드할 수 있습니다. 그러한 맥락에서 헬름3에 의해 생성된 모든 릴리즈는 헬름4로 업그레이드한 이후에도 기본적으로 클라이언트 사이드 apply를 사용할 것입니다. #### 사용자 정의 템플릿 함수 {#custom-template-functions} 플러그인을 통해 추가한 자체 함수로 헬름의 템플릿 기능을 확장할 수 있습니다. 조직별 템플릿 요구사항에 적합합니다. #### 플러그인으로서의 포스트 렌더러 {#post-renderers-as-plugins} 포스트 렌더러가 플러그인으로 구현되어 더 나은 통합성과 추가적인 기능을 제공합니다. #### 안정화된 SDK API (Stable SDK API) {#stable-sdk-api} API에 관해 호환성이 깨지는 변경 작업이 전부 완료되었습니다. 자유롭게 테스트하고, 문제를 발견하면 피드백을 보내주세요! 또한 이 API는 추가적인 차트 버전을 지원하여, 향후 출시될 차트 v3에서 새로운 기능을 도입할 수 있는 기반을 제공합니다. #### 차트 v3 {#charts-v3} 곧 출시 예정입니다. v2 차트는 변경 없이 계속 사용할 수 있습니다. ### 개선사항 {#improvements} #### 성능 {#performance} 더 빠른 의존성 해결, 새로운 콘텐츠 기반 차트 캐싱을 제공합니다. #### 에러 메시지 {#error-messages} 더 명확하고 유용한 에러 출력을 제공합니다. #### 레지스트리 인증 {#registry-authentication} 프라이빗 레지스트리를 위한 향상된 OAuth 및 토큰 지원을 제공합니다. #### CLI 플래그 이름 변경 {#cli-flags-renamed} 동작을 더 명료하게 표현하기 위해 일부 CLI 플래그명이 변경됐습니다. 기존 플래그는 그대로 유지되지만, deprecated 경고가 출력될겁니다. - `--atomic` → `--rollback-on-failure` - `--force` → `--force-replace` 이름이 변경된 이들 CLI 플래그를 사용하는 자동화 스크립트가 있다면 업데이트해주세요. ## 헬름4로 업그레이드하기 {#upgrading-to-helm-4} 헬름4를 사용자 모두에게 안정적으로 제공하고자 최선을 다하고 있다고 할지라도 헬름4는 완전히 새로운 버전입니다. 이를 고려하여, 기존 워크플로우에서 헬름4를 테스트할 때 업그레이드 전 주의해야 할 몇 가지 팁을 아래 정리해뒀습니다. 항상 그렇듯 잘 동작하는 사항, 문제가 발생하는 사항, 그리고 개선이 필요한 사항에 관한 모든 피드백을 환영합니다. ### 최우선 고려사항 {#high-priority} * 기존 Chart와 릴리즈를 테스트하여 v4에서도 정상적으로 동작하는지 확인하세요. * 세 가지 플러그인 유형(CLI, getter, post-renderer)을 모두 테스트하세요. * 새로운 런타임으로 WebAssembly 플러그인 빌드를 시도해 보세요 (참고: [example plugins](https://github.com/scottrigby/h4-example-plugins)) * SDK 사용자: 안정화된 API를 테스트해 보세요. 문제를 발견하면 피드백을 공유해 주세요. * CI/CD 파이프라인을 테스트하고, 이름이 변경된 CLI 플래그로 인한 스크립트 오류를 수정하세요. * 포스트 렌더러 통합을 테스트하세요. * OCI 워크플로우에서 레지스트리 인증 및 차트 설치를 테스트하세요. ### 그 외 {#other} * 다중 문서 값 설정, 다이제스트 기반 설치, 사용자 정의 템플릿 함수 등 기타 새로운 기능도 테스트해보세요. * 크고 복잡한 Chart를 사용하여 헬름4의 성능을 테스트해보고 기존 워크로드에 대비해 눈에 띄게 빨라졌는지 확인해보세요. * 의도적으로 고장내어 업데이트된 에러 메시지가 도움되는지 확인해보세요. ### 피드백 {#feedback} * 헬름의 코어 기능을 커스터마이징하기 위해 어떤 플러그인 유형이 추가되어야 한다고 생각하시나요? * API가 추가적인 차트 버전을 지원하게 된 만큼, 차트 v3에서 어떤 새로운 기능을 기대하시나요? ## 피드백 제공 방법 {#how-to-give-feedback} 이슈를 발견하셨나요? 제안이 있으신가요? 11월 릴리즈 전 여러분의 의견을 듣고 싶습니다: ### 깃헙 이슈 {#github-issues} 헬름 저장소의 [열린 이슈 및 기능 요청 목록](https://github.com/helm/helm/issues)을 확인하세요. 기존 항목에 댓글을 추가하거나, 새로운 이슈 및 요청을 [생성](https://github.com/helm/helm/issues/new/choose)하세요. ### 커뮤니티 슬랙 {#community-slack} [쿠버네티스 슬랙](https://slack.kubernetes.io/) 채널에 참여하세요: - 개발 관련 논의는 `#helm-dev` - 사용자 지원 및 테스트 피드백은 `#helm-users` ### 주간 개발자 미팅 {#weekly-dev-meetings} 매주 목요일 오전 9시 30분에 [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09)에서 유지관리자들과 함께하는 라이브 토론에 참여하세요. 더 다양한 참여 방법은 Helm 커뮤니티의 [커뮤니케이션 안내](https://github.com/helm/community/blob/main/communication.md)를 참고하세요. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/index.mdx ================================================ --- title: 플러그인 개발자 가이드 sidebar_position: 3 --- import DocCardList from "@theme/DocCardList"; 헬름 플러그인의 개념, 그리고 어떻게 플러그인을 설계하고 설정하는지 개요는 [플러그인 개요](/plugins/overview.md)를 참고하세요. 이번 섹션은 헬름 플러그인 개발에 초점을 두며 [튜토리얼](#tutorials), 사용법 가이드, 레퍼런스 가이드, 헬름 플러그인 작성에 관한 추가적인 개발자용 정보를 포함하고 있습니다. :::info 플러그인 시스템 코드베이스 소개를 위해 문서의 [Go SDK](/sdk/index.mdx) 섹션에 곧 플러그인 페이지가 추가될 예정입니다! ::: ## 튜토리얼 {#tutorials} ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-cli-plugin.mdx ================================================ --- title: "튜토리얼: CLI 플러그인 빌드하기" --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; 시스템 정보를 표시하는 `helm system-info` 명령어를 만들어봅시다. ## 서브프로세스 런타임 {#subprocess-runtime} 서브프로세스 런타임으로 CLI 플러그인을 만드는데서 시작합니다. ### 사전 요구 사항 {#prerequisites} 1. 최신 헬름4 릴리즈를 설치하세요: **** 2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다. ### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory} 파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어: ```bash mkdir -p $HOME/code/helm/plugins/system-info cd $HOME/code/helm/plugins/system-info ``` ### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: cli/v1 name: "system-info" version: "0.1.0" runtime: subprocess config: usage: system-info shortHelp: Display system and Helm information longHelp: Shows OS info, Helm version, and environment details runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/system-info.sh ``` ### 3. 스크립트 생성 {#3-create-script} ```bash title="system-info.sh" showLineNumbers #!/bin/bash echo "=== System Information ===" echo "OS: $(uname -s)" echo "Architecture: $(uname -m)" echo "" echo "=== Helm Information ===" echo "Plugin Dir: $HELM_PLUGIN_DIR" echo "Arguments: $*" echo "" echo "System info complete!" ``` 실행 가능하도록 설정합니다: ```bash chmod +x system-info.sh ``` ### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test} 파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다: ```bash % helm plugin install $HOME/code/helm/plugins/system-info Installing plugin from local directory (development mode) Installed plugin: system-info ``` 로컬 개발 모드 설치는 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성하므로, 원하는 위치에서 계속 개발할 수 있습니다. 내부 환경 변수 `HELM_PLUGINS`로 디렉터리 위치를 나열하여 심볼릭 링크를 확인할 수 있습니다: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 3 r6by staff 96B Nov 10 02:18 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` 설치된 플러그인의 `helm plugin list`에서 플러그인 세부 정보를 확인할 수 있습니다: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE system-info 0.1.0 cli/v1 v1 local dev unknown ``` `helm help`의 사용 가능한 명령어 목록에서도 플러그인을 확인할 수 있으며, `plugin.yaml`에 정의한 플러그인 자체의 도움말 메시지도 볼 수 있습니다: ```bash % helm help | grep system-info system-info Display system and Helm information % helm help system-info Shows OS info, Helm version, and environment details Usage: helm system-info [flags] ``` CLI 서브커맨드를 실행해봅시다: ```bash % helm system-info === System Information === OS: Darwin Architecture: arm64 === Helm Information === Plugin Dir: /Users/r6by/Library/helm/plugins/system-info Arguments: System info complete! ``` 만들어냈습니다. 서브프로세스 런타임을 사용하는 CLI 플러그인을! 다시 한 번 해봅시다. 이번에는 WASM 런타임으로... ## WASM 런타임 {#wasm-runtime} ### 사전 요구 사항 {#prerequisites} - [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항 - Go 1.25 설치 :::warning To-do: 섹션 추가 필요 ::: ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-getter-plugin.mdx ================================================ --- title: "튜토리얼: Getter 플러그인 만들기" --- import GetVersion from "@site/src/components/GetVersion"; 시스템 정보를 표시하는 `helm system-info` 명령어를 만들어봅시다. ## 서브프로세스 런타임 {#subprocess-runtime} 서브프로세스 런타임을 사용하여 Getter 플러그인을 만들어봅시다. ### 사전 요구 사항 {#prerequisites} 1. 최신 헬름4 릴리즈를 설치하세요: **** 2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다. ### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory} 파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어: ```bash mkdir -p $HOME/code/helm/plugins/demo-getter cd $HOME/code/helm/plugins/demo-getter ``` ### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: subprocess config: protocols: ["demo"] runtimeConfig: protocolCommands: - protocols: - demo platformCommand: - command: get-demo.sh ``` ### 3. 스크립트 생성 {#3-create-script} Getter 플러그인은 패키지된 아티팩트(이 경우 차트)를 가져오거나 다운로드하고, 다운로드된 패키지의 경로를 반환하는 역할을 합니다. 데모 목적으로 시스템 유틸리티를 사용하여 임시 디렉터리를 만들고(시간이 지나면 자동으로 정리됩니다), `helm create`와 `helm package` 명령어로 임시 디렉터리에 데모 차트 패키지를 생성한 후 패키지 경로를 반환해봅시다: ```bash title="get-demo.sh" showLineNumbers #!/usr/bin/env sh set -e URI=$@ TMPDIR="$(mktemp -d)" # make a fake chart for testing with the passed URL basename FILENAME=$(basename -- $URI) helm create $TMPDIR/$FILENAME 1>/dev/null helm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null # cat $FILENAME-0.1.0.tgz # just to not need to know the chart version rm -r $TMPDIR/$FILENAME 1>/dev/null cat $TMPDIR/$FILENAME-* ``` 실행 가능하도록 설정합니다: ```bash chmod +x get-demo.sh ``` ### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test} 파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다: ```bash % helm plugin install $HOME/code/helm/plugins/demo-getter Installing plugin from local directory (development mode) Installed plugin: demo-getter ``` [CLI 플러그인 튜토리얼](/plugins/developer/tutorial-cli-plugin.mdx)에서 살펴봤듯이, 로컬 개발 모드 설치는 플러그인 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성합니다. 이제 두 개의 플러그인이 설치되었습니다: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 4 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` CLI 플러그인 튜토리얼과 달리 이 플러그인은 `helm help`의 사용 가능한 명령어 목록에 표시되지 않습니다. CLI 플러그인 유형만 `helm` CLI 서브커맨드 목록에 나타납니다. 하지만 모든 플러그인 유형과 마찬가지로, `helm plugin list`에서 설치된 포스트 렌더러 플러그인 세부 정보를 확인할 수 있습니다: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` 실행해봅시다. "example"이라는 이름의 차트에 대한 템플릿 YAML이 반환되어야 합니다: ```bash % helm template example demo://does-not-matter/example LOTS OF YAML, INCLUDING: --- # Source: example/templates/tests/test-connection.yaml ``` 만들어냈습니다. 서브프로세스 런타임을 사용하는 데모 Getter 플러그인을! 다음으로는 WASM 런타임으로 버전을 만들어봅시다... ## Wasm 런타임 {#wasm-runtime} ### 사전 요구 사항 {#prerequisites-1} - [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항 - Go 1.25 설치 `demo://` URL을 `https://`로 변환하는 커스텀 프로토콜 getter를 만들어봅시다. ### 1. 저장소 설정 {#1-set-up-repository} 템플릿에서 새 저장소를 스캐폴드하거나 클론하세요: https://github.com/gjenkins8/helm-extism-plugin-template ### 2. 플러그인 매니페스트 업데이트 {#2-update-plugin-manifest} 서브프로세스 Getter의 동일한 단계와 거진 유사합니다. 클론한 Git 저장소에서 진행한다는 점만 제외하고 말이죠. Wasm의 경우 `runtime`과 `runtimeConfig` 필드 값이 변경됩니다: ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: extism/v1 config: protocols: ["demo"] runtimeConfig: memory: maxPages: 16 timeout: 30000 ``` ### 3. `main.go` 업데이트 {#3-update-maingo} 플러그인의 입출력 메시지를 지정합니다: ```go title="main.go" showLineNumbers package main ... type InputMessage struct { URL string `json:"url"` Protocol string `json:"protocol"` } type OutputMessage struct { Data []byte `json:"data"` } ``` `replaceMeImplementationGoesHere` 함수를 실제 로직으로 교체합니다: ```go ... // Delete the `replaceMeImplementationGoesHere` function func demoDownloader(input InputMessage) (*OutputMessage, error) { // Convert demo:// to https:// downloadURL := strings.Replace(input.URL, "demo://", "https://", 1) pdk.Log(pdk.LogLevelInfo, fmt.Sprintf("Converted %s to %s", input.URL, downloadURL)) // Download content resp, err := http.Get(downloadURL) if err != nil { return nil, fmt.Errorf("failed to download: %w", err) } defer resp.Body.Close() // Read and output content data, _ := io.ReadAll(resp.Body) output := OutputMessage{Data: data} return &output, nil } ``` `demoDownloader`를 호출하도록 runPlugin 함수를 업데이트합니다: ```go func runPlugin() error { ... // Remove: output, err := replaceMeImplementationGoesHere(input) output, err := demoDownloader(input) ``` ### 4. WebAssembly 빌드 {#4-build-webassembly} ```bash $ make build $ ls -la plugin.wasm ``` ### 5. 개발 모드로 설치 및 테스트 {#5-install-in-dev-mode-and-test} 서브프로세스 CLI 플러그인 단계와 동일합니다. 만들어냈습니다. Extism PDK를 통한 샌드박스 실행과 구조화된 통신을 갖춘 WebAssembly 플러그인! ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-postrenderer-plugin.mdx ================================================ --- title: "튜토리얼: 포스트렌더러 플러그인 만들기" --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; 모든 쿠버네티스 리소스에 커스텀 라벨을 추가하는 플러그인을 만들어봅시다. ## 서브프로세스 런타임 {#subprocess-runtime} 서브프로세스 런타임으로 포스트 렌더러 플러그인을 만들어봅시다. ### 사전 요구 사항 {#prerequisites} 1. 최신 헬름4 릴리즈를 설치하세요: **** 2. 터미널 세션에서 다운로드한 릴리즈에 관해서 `helm`을 별칭으로 설정하세요. 이제 `helm version --short`를 실행하면 해당 터미널 세션에서 올바른 Helm 버전이 표시됩니다. 3. `mikefarah/yq`를 설치하세요: https://github.com/mikefarah/yq/#install ### 1. 플러그인 디렉터리 생성 {#1-create-plugin-directory} 파일 시스템의 어디에서나 생성할 수 있습니다. 예를 들어: ```bash mkdir -p $HOME/code/helm/plugins/label-injector cd $HOME/code/helm/plugins/label-injector ``` ### 2. 플러그인 매니페스트 생성 {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: postrenderer/v1 name: label-injector version: 0.1.0 runtime: subprocess runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/inject-labels.sh ``` ### 3. 스크립트 생성 {#3-create-script} ```bash title="inject-labels.sh" showLineNumbers #!/usr/bin/env sh # set -e cat <&0 | yq '.metadata.labels.postrendered-by = "helm-label-injector-plugin"' ``` 실행 가능하도록 설정합니다: ```bash chmod +x inject-labels.sh ``` ### 4. 개발 모드로 설치 및 테스트 {#4-install-in-dev-mode-and-test} 파일 시스템에서 플러그인을 설치하면 로컬 개발 모드로 설치됩니다. 이 경우 출처 확인 및 검증을 건너뜁니다: ```bash % helm plugin install $HOME/code/helm/plugins/label-injector Installing plugin from local directory (development mode) Installed plugin: label-injector ``` [CLI 플러그인](/plugins/developer/tutorial-cli-plugin.mdx) 및 [Getter 플러그인](/plugins/developer/tutorial-getter-plugin.mdx) 튜토리얼에서 살펴봤듯이 로컬 개발 모드 설치는 플러그인 소스 디렉터리에서 플러그인 디렉터리로 심볼릭 링크를 생성합니다. 이제 세 개의 플러그인이 설치되었습니다: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 5 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` `helm plugin list`를 사용하여 설치된 CLI 및 Getter 플러그인과 함께 설치된 포스트 렌더러 플러그인 세부 정보를 확인할 수 있습니다: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown label-injector 0.1.0 postrenderer/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` 실행해봅시다: ```bash % helm create ../mychart % helm template ../mychart --post-renderer label-injector ``` 출력에서 다음과 같은 레이블을 확인할 수 있습니다: ```yaml metadata: labels: postrendered-by: helm-label-injector-plugin ``` 만들었습니다. 서브프로세스 런타임을 사용한 포스트렌더러 플러그인을! 이번에는 Wasm 런타임으로도 만들어봅시다… ## Wasm 런타임 {#wasm-runtime} ### 사전 요구 사항 {#prerequisites} - [서브프로세스 런타임](#subprocess-runtime)의 사전 요구 사항 - Go 1.25 설치 :::warning To-do: 섹션 추가 필요 ::: ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/index.mdx ================================================ --- title: 플러그인 가이드 sidebar_label: 플러그인 sidebar_position: 5.5 --- 이 가이드는 Helm 플러그인이 무엇인지, 어떻게 사용하는지, 어떻게 만드는지를 설명합니다. import DocCardList from "@theme/DocCardList"; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/overview.md ================================================ --- title: 플러그인 개요 sidebar_label: 개요 sidebar_position: 1 --- 헬름 플러그인은 유저가 모든 새로운 기능을 Go로 작성해 헬름 코어에 추가하지 않고도 Helm의 핵심 기능을 확장할 수 있게 해줍니다. 플러그인은 어떤 프로그래밍 언어로도 작성할 수 있으며 헬름의 코어 기능을 망가뜨리지 않으며 헬름 설치에 추가하거나 제거할 수 있습니다. ## 플러그인 타입 {#plugin-types} 현재 헬름에는 세 가지 유형의 플러그인이 있습니다: - [CLI 플러그인](#cli-plugins): 사용자가 추가적인 `helm` CLI 하위 명령어를 덧붙일 수 있게 해줍니다. - [Getter 플러그인](#getter-plugins): 헬름 코어에서 기본적으로 지원하지 않는 위치에서도 차트나 다른 플러그인을 사용할 수 있게 합니다. - [Postrenderer 플러그인](#postrenderer-plugins): 사용자가 차트에 의해 렌더링된 매니페스트를 쿠버네티스 API로 전송하기 전 수정할 수 있게 해줍니다. 헬름4부터 추가적인 플러그인 유형을 더 쉽게 추가할 수 있도록 플러그인 시스템이 설계되었고, 사용자는 헬름 기능의 다른 영역도 수정할 수 있게 됩니다. ### CLI 플러그인 {#cli-plugins} 별도의 스크립트나 자체적인 독립형 커멘드를 지닌 툴을 사용하는 것과 대비해 플러그인을 이용해 `helm` CLI 하위 명령어를 만드는 것의 이점이 무엇일까요? 가장 큰 장점은 `helm` CLI 하위 명령어를 추가하는 플러그인이 독립 실행형 스크립트나 도구가 직접 구현해야 하는 헬름 고유의 설정, 컨텍스트 및 기능을 활용할 수 있다는 점입니다. 이를 통해 `helm` CLI 사용자 워크플로우를 보다 원활하게 확장할 수 있습니다. ### Getter 플러그인 {#getter-plugins} 헬름은 로컬 파일 시스템에 있거나 [OCI 레지스트리](/topics/registries.mdx)에 아티팩트로 저장된 [Chart](/glossary/index.mdx)와 플러그인을 다루는 기본 기능을 제공합니다. 차트는 추가적으로 [HTTP 저장소](/topics/chart_repository.md)에 저장할 수 있으며 플러그인은 추가적으로 Git과 같은 VCS 저장소에도 저장할 수 있습니다. 헬름의 Getter 플러그인은 이러한 저장 및 다운로드 동작을 확장하여 다른 저장소를 지원할 수 있게 합니다. [s3 버킷](/community/related#helm-plugins)나 그 외 다른 어디든 차트와 플러그인을 저장할 수 있는 커뮤니티 Getter 플러그인이 있습니다. 헬름 워크플로우에서 추가적인 저장 옵션이 필요할 때 getter 플러그인을 사용하길 선호하게 될 겁니다. ### 포스트렌더러 플러그인 {#postrenderer-plugins} 헬름은 사용자가 커스텀 값을 제공해 차트를 구성하게 해줍니다. 사용자에 의해 제공된 값은 차트가 매니페스트를 렌더링하는 데 사용되는데, 이를 통해 헬름은 쿠버네티스에서 어플리케이션을 관리할 수 있습니다. 자기 소유의 차트를 작성할 땐 렌더링된 매니페스트에 추가적인 구성 옵션이 필요할 때마다 템플릿을 업데이트할 수 있습니다. 하지만 자기 소유가 아닌 커뮤니티 차트를 사용한다면 포스트 렌더링으로 차트가 매니페스트를 렌더링한 시점, 하지만 아직 헬름이 그를 사용해 쿠버네티스 리소스를 관리하진 않은 이전 시점에 매니페스트를 수정할 수 있습니다. 헬름4부터는 포스트렌더러 플러그인으로 이를 수행할 수 있습니다. ## 플러그인 API 버전 {#plugin-api-versions} 헬름4부터 모든 플러그인에 포함된 `plugin.yaml` 파일에 `apiVersion` 필드가 추가되며 현재 값은 `v1`입니다. (API 버전 도입 이전의) 레거시 플러그인도 헬름4에서 계속 지원될 것이며, 따라서 헬름3에서 사용하던 기존 플러그인도 헬름5가 나오기 전까지는 계속 작동할 것입니다. 다만 자주 사용하는 플러그인의 개발자에게 새 버전 관리 시스템으로 업데이트하길 요청하는 게 좋습니다. 플러그인 개발자라면, [플러그인 개발자 가이드](/plugins/developer/index.mdx)에서 이에 관해 더 자세히 읽어보세요. ## 플러그인 런타임 {#plugin-runtimes} 헬름은 현재 두 가지 플러그인 런타임을 지원합니다: - 서브프로세스 런타임 - Wasm 런타임 각 런타임에 대한 자세한 내용은 [플러그인 사용자 가이드](/plugins/user/index.md) 또는 [플러그인 개발자 가이드](/plugins/developer/index.mdx)를 참조하세요. ## 파일 구조 {#file-structure} 플러그인의 모든 파일은 단일 디렉터리에 위치하며, 이 디렉터리는 개발, 패키징, 설치에 사용됩니다. 플러그인 디렉터리 내부에서 헬름은 다음 구조를 요구합니다: ``` example-plugin ├── plugin.yaml # REQUIRED ├── plugin.sh # OPTIONAL for Subprocess runtime └── plugin.wasm # REQUIRED for Wasm runtime ``` - 필수 파일은 [plugin.yaml](#pluginyaml)가 유일합니다. - [서브프로세스 런타임](#plugin-runtimes)에는 선택적으로 (노드, 파이썬, Go, 그 외 등등) 플러그인 코드가 담긴 한 가지 이상의 실행 파일을 넣을 수 있습니다. 이 런타임에서는 `plugin.yaml` [런타임 설정](#runtime-configuration)의 `platformCommand` 필드를 통해 사용자의 PATH에서 이미 사용 가능한 실행 파일을 직접 호출할 수도 있습니다. - [Wasm 런타임](#plugin-runtimes)의 경우 `.wasm` 파일을 포함해야 합니다. 이는 Wasm으로 컴파일된 플러그인 코드입니다(Node, Python, Go 등 가능). ## Plugin.yaml {#plugin-yaml} `plugin.yaml` 파일은 플러그인에 필수 요소입니다. 이 파일은 플러그인에 관한 메타데이터와 구성을 담은 YAML 파일입니다. ### 메타데이터 정보 {#metadata-information} ```yaml apiVersion: 필수 - 플러그인 API 버전. 값은 반드시 "v1"이어야 함. type: 필수 - 버전 관리된 플러그인 유형. "cli/v1", "getter/v1", 또는 "postrenderer/v1" 중 하나일 수 있음. name: 필수 - 플러그인의 이름. version: 필수 - 플러그인의 버전. runtime: 필수 - 플러그인 런타임. "subprocess" 또는 "extism/v1"(Wasm) 중 하나일 수 있음. sourceURL: 선택 - 플러그인 소스 코드를 가리키는 URL. config: 플러그인 유형에 따라 달라짐 runtimeConfig: 런타임에 따라 달라짐 ``` - `config` 필드는 [플러그인 유형 구성](#plugin-type-configuration)에 사용되며, `type` 필드에 정의된 [플러그인 유형](#plugin-types)에 따라 구조가 달라집니다. - `runtimeConfig` 필드는 [런타임 구성](#runtime-configuration)에 사용되며, `runtime` 필드에 정의된 [런타임](#plugin-runtimes)에 따라 구조가 달라집니다. - 💡 `sourceURL` 필드는 선택 사항이지만, 플러그인 작성자는 플러그인 소스 코드를 가리키도록 권장됩니다. 이는 플러그인 사용자가 코드가 무엇을 하는지 이해하고, 오픈소스 기여가 가능할 경우 플러그인에 기여할 수 있도록 돕기 위함입니다. ### 플러그인 유형 구성 {#plugin-type-configuration} [plugin.yaml](#pluginyaml)의 `config` 필드는 [플러그인 유형](#plugin-types)마다 서로 다른 옵션을 가집니다. 플러그인의 유형은 `type` 필드로 정의됩니다. #### CLI 플러그인 설정 {#cli-plugin-configuration} 만약 `type` 필드가 `cli/v1`이라면 [CLI 플러그인 유형](#cli-plugins)이며, 다음 플러그인 유형 설정이 허용됩니다: ```yaml usage: 선택 사항 - 도움말에 표시되는 한 줄 사용법 텍스트 shortHelp: `helm help` 출력에 표시되는 짧은 설명 longHelp: `helm help ` 출력에 표시되는 상세 메시지 ignoreFlags: Helm에서 전달된 플래그를 무시합니다 ``` - `usage`는 선택 사항입니다. 커스텀 사용법 문자열로 오버라이드하지 않으면 기본값은 "helm PLUGIN_NAME [flags]"입니다. 권장 문법은 [spf13/cobra.command.Command] Use 필드 주석을 참조하세요: https://pkg.go.dev/github.com/spf13/cobra#Command - `ignoreFlags`는 Helm이 플러그인에 플래그를 전달하지 않도록 합니다. 예를 들어 `helm myplugin --foo`로 플러그인을 호출하고 `ignoreFlags: true`인 경우 `--foo`는 자동으로 무시됩니다. #### Getter 플러그인 설정 {#getter-plugin-configuration} 만약 `type` 필드가 `getter/v1`이라면 [Getter 플러그인 유형](#getter-plugins)이며, 다음 플러그인 유형 설정이 허용됩니다: ```yaml protocols: 이 플러그인이 지원하는 차트 URL의 스킴 목록입니다. ``` #### 포스트 렌더러 플러그인 설정 {#postrenderer-plugin-configuration} 만약 `type` 필드가 `postrenderer/v1`이라면 [포스트 렌더러 플러그인 유형](#postrenderer-plugins)이며, 별도의 설정 옵션이 없습니다. ### 런타임 설정 {#runtime-configuration} [plugin.yaml](#pluginyaml)의 `runtimeConfig` 필드는 [플러그인 런타임](#plugin-runtimes)에 따라 다른 옵션을 가집니다. 플러그인의 런타임은 `runtime` 필드로 정의됩니다. #### 서브프로세스 런타임 설정 {#subprocess-runtime-configuration} 만약 `runtime` 필드가 `subprocess`라면 [서브프로세스 런타임](#plugin-runtimes) 플러그인이며, 다음 런타임 설정이 허용됩니다: ```yaml runtimeConfig: platformCommand: # 플랫폼에 따라 실행할 명령어 설정 - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치 arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치 command: 실행할 플러그인 명령어 args: 플러그인 명령어 인수 platformHooks: # 플랫폼에 따라 플러그인 라이프사이클 훅 설정 install: # 설치 라이프사이클 명령어 - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치 arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치 command: 실행할 플러그인 설치 명령어 args: 플러그인 설치 명령어 인수 update: # 업데이트 라이프사이클 명령어 - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치 arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치 command: 실행할 플러그인 업데이트 명령어 args: 플러그인 업데이트 명령어 인수 delete: # 삭제 라이프사이클 명령어 - os: OS 일치 조건, 비워두거나 생략하면 모든 OS에 일치 arch: 아키텍처 일치 조건, 비워두거나 생략하면 모든 아키텍처에 일치 command: 실행할 플러그인 삭제 명령어 args: 플러그인 삭제 명령어 인수 protocolCommands: # 더 이상 사용되지 않음/지원 중단 - protocols: [] # 차트 URL의 스킴 목록 platformCommand: [] # 위의 "platformCommand"와 동일한 구조 ``` - ⚠️ `protocolCommands`는 `obsolete/deprecated`로 표시되어 있으며, `apiVersion: v1` 이후의 플러그인 시스템 버전에서 제거될 예정입니다. 이 필드는 "getter/v1" 플러그인 유형에만 적용됩니다. 이는 단일 플러그인에서 여러 프로토콜을 지원하도록 확장된 구 플러그인 다운로더 메커니즘의 호환성 잔재입니다. PlatformCommand에 지정된 명령어는 다운로드 URL을 검사하여 프로토콜별 로직을 구현해야 됩니다. #### Wasm 런타임 설정 {#wasm-runtime-configuration} 만약 `runtime` 필드가 `extism/v1`이라면 [Wasm 런타임](#plugin-runtimes) 플러그인이며, 다음 런타임 설정이 허용됩니다: ```yaml runtimeConfig: memory: # 플러그인에 할당될 수 있는 메모리 한도 설정 maxPages: 플러그인이 할당할 수 있는 최대 페이지 수. 1페이지는 64KiB. 예: 16페이지는 1MiB 필요. 기본값은 4페이지(256KiB). maxHttpResponseBytes: Extism HTTP 응답의 최대 크기(바이트). 기본값은 4096바이트(4KiB). maxVarBytes: 모든 Extism 변수의 최대 크기(바이트). 기본값은 4096바이트(4KiB). config: {} # 플러그인에 전달할 수 있는 자유 형식 맵. allowedHosts: [] # 이 플러그인이 통신할 수 있는 호스트 목록(선택 사항). 기본값은 허용된 호스트 없음. fileSystem: createTempDir: 파일 시스템에 임시 디렉터리를 생성할지 여부. "true" 또는 "false". timeout: 플러그인 실행 타임아웃(밀리초) hostFunctions: 플러그인이 접근할 수 있는 헬름에서 노출된 HostFunction 이름. https://extism.org/docs/concepts/host-functions/ 참조 entryFuncName: 플러그인에서 호출할 진입 함수 이름. 기본값은 "helm_plugin_main". ``` - `allowedHosts`는 플러그인이 HTTP 요청을 수행하는 경우에만 적용됩니다. 지정하지 않으면 어떤 호스트도 허용되지 않습니다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current/plugins/user/index.md ================================================ --- title: 플러그인 유저 가이드 sidebar_label: 플러그인 사용하기 sidebar_position: 2 --- 헬름 플러그인의 개념, 그리고 어떻게 그 구조를 읽는지, 어떻게 각 설정들이 사용자로서 당신에게 무얼 의미하는지 이해하려면 [플러그인 개요](/plugins/overview.md)를 참조하세요. 이 섹션은 최종 사용자로서 Helm 플러그인을 사용하는 방법에 초점을 맞춥니다. ## 플러그인 찾기 {#finding-plugins} [ArtifactHub에서 Helm 플러그인](https://artifacthub.io/packages/search?kind=6)을 이미 찾아볼 수 있습니다. Helm 4 플러그인 시스템은 완전히 새로운 기능입니다. 조만간 ArtifactHub에서 유형과 런타임별로 플러그인을 검색할 수 있게 될 예정입니다. 업데이트를 기대해주세요! ## 플러그인 보안 {#plugin-security} 플러그인 런타임에 따라, 시스템에서 실행하기 전에 서드파티 플러그인을 검사해보는 것이 좋습니다. - 서브프로세스 런타임은 명령어를 실행하는 사용자만큼 시스템 접근 권한을 가집니다. 플러그인을 설치하거나 제거하기 전, 또는 해당 플러그인이 실행될 수 있는 helm 명령어를 실행하기 전 반드시 플러그인 코드를 꼼꼼히 검토하세요. - 반면 Wasm 런타임은 명시적으로 승인한 시스템 접근 권한만 허용하는 보안 샌드박스에서 실행됩니다. 이 플러그인 런타임은 훨씬 강력한 제어와 내재적으로 높은 수준의 내장 보안을 제공합니다. 그래도 플러그인이 요청하는 권한을 파악하기 위해 `plugin.yaml`을 확인해보는 게 좋습니다. 두 경우 모두 Wasm 런타임 플러그인일지라도 설치 전 출처를 검증하길 강력히 권장합니다. 어디에서 다운로드됐고 누가 만들었는지 신뢰하기 위해 말이죠. 이는 스푸핑된 URL 공격으로 플러그인을 실수로 설치하는 것을 방지할 뿐만 아니라, 네트워크 탈취 공격으로부터도 보호합니다. 플러그인 검증은 설치 전 차트가 손상되지 않았음을 암호학적으로 확인하게 해줍니다. `helm plugin install --help`의 `--verify` 플래그를 참조하세요. 개발 목적으로 인해 설치 과정에서의 검증이 생략된 경우에도 이미 설치된 플러그인의 출처를 `helm plugin verify --help`를 사용하여 확인할 수 있으며, 또한 언제든 보안 준수 정보를 제공받는 데에도 도움을 줄 겁니다. `helm plugin list` 명령어는 출처 정보도 한눈에 확인할 수 있도록 제공합니다. ## 플러그인 설치하기 {#installing-plugins} Helm에는 기본적으로 안전한 설치를 수행하는 플러그인 설치 명령어가 내장되어 있습니다. 그렇더라도 설치 전 무엇을 확인해봐야 될지 이해하기 위해 [플러그인 보안](#plugin-security) 문서를 반드시 읽어보시기 바랍니다. 자세한 내용은 `helm plugin install --help`를 참조하세요. ## 설치된 플러그인 목록 확인 {#listing-installed-plugins} 플러그인 목록을 확인하는 명령어는 플러그인의 이름, 버전, 유형, API 버전, 출처(provenance) 및 소스를 표시합니다. 자세한 내용은 `helm plugin list --help`를 참조하세요. ## 플러그인 제거 {#uninstalling-plugins} 플러그인 제거는 간단하고 쉽게 수행되도록 설계되어 있습니다. 그렇더라도 제거 시의 위험을 이해하기 위해 [플러그인 보안](#plugin-security) 문서를 반드시 읽어보시기 바랍니다. 자세한 내용은 `helm plugin uninstall --help`를 참조하세요. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Helm 사용하기", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm 명령어", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "차트", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "템플릿 개발", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "모범 사례", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: 일반적인 관례 description: 차트에 대한 일반적인 관례 sidebar_position: 1 --- 이 부분은 모범사례 가이드의 일부로서 일반적인 관례를 설명한다. ## 차트 이름 차트 이름은 소문자와 숫자여야 한다. 단어는 대시(-)로 구분할 수 있다. 예시: ``` drupal nginx-lego aws-cluster-autoscaler ``` 대문자나 밑줄문자는 차트 이름에 사용할 수 없다. 점도 사용할 수 없다. ## 버전 번호 가능하다면 어디서든, 헬름은 버전 번호를 표현할 때 [SemVer 2](https://semver.org)를 사용한다. (도커 이미지 태그는 SemVer를 따를 필요가 없고 아쉽지만 규칙에서 예외로 취급된다는 점을 알아두자.) SemVer 버전을 쿠버네티스 레이블로 저장할 때, 관례적으로 `+` 문자를 `_` 문자로 변경하는데, `+` 기호는 레이블 값으로 허용되지 않기 때문이다. ## YAML 형식 YAML 파일은 _2칸_ (탭이 아니다) 들여쓰기해야 한다. ## 헬름과 차트 단어의 사용 _Helm_ 과 _helm_ 단어 사용에 관한 관례는 다음과 같다. - _Helm_(헬름)은 전체 프로젝트를 가리킨다. - `helm`은 클라이언트측 명령어를 가리킨다. - `chart`는 첫글자를 대문자로 쓸 필요가 없는데, 고유명사가 아니기 때문이다. - 반면, `Chart.yaml`는 첫글자를 대문자로 써야 하는데, 파일명에는 대소문자 구분이 있기 때문이다. 애매할 때는 _Helm_(대문자 'H', 헬름)을 쓰자. ## 차트 템플릿과 네임스페이스 차트 템플릿의 `metadata` 섹션에 `namespace` 속성을 정의하는 것은 피하자. 렌더링된 템플릿에 적용할 네임스페이스는 `--namespace`와 같은 플래그를 통해 쿠버네티스 클라이언트를 호출할 때 지정해야 한다. Helm은 템플릿을 있는 그대로 렌더링하여 쿠버네티스 클라이언트에 전달하는데, 이 클라이언트는 Helm 자체일 수도 있고 다른 프로그램(kubectl, flux, spinnaker 등)일 수도 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: 커스텀 리소스 데피니션(CRD) description: CRD를 생성하고 사용하는 방법 sidebar_position: 7 --- 이 부분은 모범사례 가이드의 일부로서 커스텀 리소스 데피니션 객체를 생성하고 사용하는 것을 다룬다. 커스텀 리소스 데피니션(CRD)를 다룰 때에는, 다음 2가지를 구분하는 것이 중요하다. - CRD의 선언이 있다. 이것은 종류(kind)가 `CustomResourceDefinition`인 YAML 파일이다. - 그리고 그 CRD를 사용하는 리소스들이 있다. 어떤 CRD가 `foo.example.com/v1`를 정의한다고 해보자. `apiVersion: example.com/v1`가 있고 종류(kind)가 `Foo`인 모든 리소스들은 그 CRD를 사용하는 리소스이다. ## 리소스를 사용하기 전에 CRD 선언을 설치하기 헬름은 되도록 많은 리소스들을 빨리 쿠버네티스 내에 로드(load)하도록 최적화되어 있다. 설계상, 쿠버네티스는 전체 매니페스트 세트를 받고 온라인으로 반영한다(이것을 조정(reconciliation) 루프라고 한다). 하지만 CRD의 경우는 약간 다르다. 해당 CRD 종류(kind) 리소스가 사용되기 전에, CRD 선언이 먼저 등록되어 있어야 한다. 그리고 등록 과정은 때에 따라 몇 초 정도 걸린다. ### 방법 1: `helm`이 처리하게 하기 헬름 3이 나오면서, 더 단순한 방안을 위해 구식 `crd-install` 훅(hook)은 없어졌다. 이제는 `crds`라는 특수 디렉토리가 있어서, CRD를 만들고자 할 때 차트 내에 생성할 수 있다. CRD는 템플릿은 아니지만 차트를 `helm install`으로 실행하면 기본으로 설치될 것이다. CRD가 이미 있으면, 경고(warning)가 나오면서 넘어가게 된다. CRD 설치 단계를 그냥 넘기고 싶다면, `--skip-crds` 플래그를 쓰면 된다. #### 주의사항 (및 설명) 지금으로서는 헬름으로 CRD를 업그레이드하거나 삭제하는 것이 지원되지 않는다. 이는 의도치 않은 데이터 유실 위험을 우려한 커뮤니티 상의 많은 논의에 따른 명시적인 결정이다. 또한, 현재로서는 CRD와 그 수명주기를 어떻게 다룰 지에 대해 커뮤니티의 컨센서스가 없다. 논의가 진행되면 헬름은 그러한 사용사례에 대해 지원할 수 있게 될 것이다. 현재 `helm install`와 `helm upgrade`의 `--dry-run` 플래그는 CRD를 지원하지 않는다. "드라이런(Dry Run)"의 목적은 차트가 실제로 서버에 전송되었을 때 처리되어 나올 결과물을 검증하는 것이다. 그런데 CRD는 서버의 행동 자체를 변경시킨다. 헬름은 드라이런으로 CRD를 설치할 수 없으므로, 디스커버리 클라이언트는 커스텀 리소스(CR)에 대해 알 수 없고 검증은 실패하게 될 것이다. 대안으로 CRD를 별도의 CRD 자체의 차트로 옮기거나, `helm template`을 사용할 수 있다. CRD 지원 논의에서 고려할 다른 중요한 포인트는 템플릿 렌더링을 어떻게 처리할 것인지이다. 헬름 2에서 사용되던 `crd-install`의 뚜렷한 단점의 하나는 API 기능범위 변경 때문에 차트를 제대로 검증할 수 없다는 점이다(CRD는 쿠버네티스 클러스터에 사용가능한 API를 실제로 추가한다). 차트가 CRD를 설치하면, `helm`이 사용하던 유효한 API 버전 세트가 더 이상 유효하지 않은 것이다. 이는 CRD에서 템플릿 지원이 제거된 데에 깔린 이유이기도 한다. CRD를 설치하는 새로운 `crds` 방법에서는, `helm`이 클러스터의 현재 상태에 대해 완전히 유효한 정보를 가지고 있음이 보장된다. ### 방법 2: 차트 분리하기 다른 방법으로는 한 차트에는 CRD 정의(definition)를 넣고 _다른_ 차트에는 CRD를 사용하는 리소스들을 넣는 방법이 있다. 이 방법으로 할 때는, 각 차트가 따로 설치되어야 한다. 하지만, 이러한 작업방식은 클러스터에 어드민으로 접근하는 클러스터 운영자들에게 더 유용할 것이다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: 의존성 description: 차트 의존성에 관한 모범사례를 다룬다. sidebar_position: 4 --- 이 부분은 가이드의 일부로서 `Chart.yaml`에서 선언되는 `dependencies`에 관한 모범사례를 다룬다. ## 버전 가능하면 특정 버전을 콕 집어서 사용하기 보다는 버전 범위를 사용하자. 권장되는 기본값은 다음과 같이 패치-수준의 버전 매치(match)를 사용하는 것이다. ```yaml version: ~1.2.3 ``` 이렇게 하면 `1.2.3`과 그 릴리스의 다른 패치들도 매치된다. 다시 말하면 `~1.2.3`은 `>= 1.2.3, < 1.3.0`과 동등하다. 버전 매칭 구문에 대한 자세한 설명은 [semver 문서](https://github.com/Masterminds/semver#checking-version-constraints)에서 볼 수 있다. ### 프리릴리스 버전 앞서 설명한 버전 제약 조건은 프리릴리스 버전에는 적용되지 않는다. 예를 들어 `version: ~1.2.3`은 `version: ~1.2.4`와 매치되지만, `version: ~1.2.3-1`과는 매치되지 않는다. 다음과 같이 하면 프리릴리스뿐 아니라 패치-수준의 매칭도 된다. ```yaml version: ~1.2.3-0 ``` ### 리포지터리 URL 가능하면 `https://` 리포지터리 URL을 우선으로 사용하고, 그 다음으로 `http://` URL을 사용하자. 리포지터리가 리포지터리 인덱스 파일에 추가되면, 리포지터리 이름은 URL의 별칭으로 사용될 수 있다. `alias:`나 `@` 뒤에 리포지터리 이름을 쓰자. 파일 URL(`file://...`)은 고정된 배포 파이프라인에서 조립되는 차트를 위한 "특수한 경우"로 간주된다. [다운로더 플러그인](../topics/plugins.md#downloader-plugins)을 사용하는 경우, URL 스킴은 해당 플러그인에 따라 달라진다. 차트 사용자는 의존성을 업데이트하거나 빌드하려면 해당 스킴을 지원하는 플러그인을 설치해야 한다. `repository` 필드를 비워두면 Helm은 해당 의존성에 대한 관리 작업을 수행할 수 없다. 이 경우 Helm은 의존성이 `charts` 폴더의 하위 디렉터리에 있고, 디렉터리 이름이 의존성의 `name` 속성과 같다고 가정한다. ## 조건과 태그 조건과 태그는 _선택적(optional)_인 모든 의존성에 추가되어야 한다. 기본적으로 `condition`은 `true`라는 점에 주의하자. 조건의 권장되는 형식은 다음과 같다. ```yaml condition: somechart.enabled ``` 여기서 `somechart`는 의존성의 차트 이름이다. 여러 서브차트(의존성)들이 선택적 또는 교체가능한 기능을 공동으로 제공하는 경우, 그 차트들은 동일한 태그를 사용해야 한다. 예를 들어, `nginx`와 `memcached`가 차트 내 메인 앱에 대한 성능 최적화 기능을 공동으로 제공하는 경우, 그리고 그 기능의 활성화시에 둘다 있어야 한다면 둘다 다음과 같은 태그 섹션이 있어야 한다. ```yaml tags: - webaccelerator ``` 이렇게 하면 사용자는 하나의 태그로 기능을 켜거나 끌 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: 모범 사례 sidebar: true sidebar_position: 4 --- # 차트 모범 사례 가이드 이 가이드에서는 헬름 팀이 고려한 차트 생성 모범 사례를 다룹니다. 주로 차트를 구성하는 방법에 중점을 둘 것입니다. 여기에서는 주로 공개 배포 가능한 차트의 모범 사례에 중점을 둡니다. 물론 많은 차트들이 내부 사용 목적으로 작성되고, 그런 차트의 작성자들은 여기에 제안된 것들을 활용하여 내부에서 사용하는 방법을 찾을 것이라는 것도 알고 있습니다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: 레이블과 어노테이션 description: 차트 내에서 레이블과 어노테이션을 사용하는 모범사례를 다룬다. sidebar_position: 5 --- 이 부분은 모범사례 가이드의 일부로서 차트 내에서 레이블과 어노테이션을 사용하는 모범사례에 대해 논한다. ## 레이블인가, 어노테이션인가? 다음 조건에 해당하는 메타데이터 항목은 레이블이어야 한다. - 쿠버네티스에서 해당 리소스를 식별하기 위해 사용된다. - 시스템 쿼리를 목적으로 운영자에게 유용하게 노출되어야 한다. 예를 들어, `helm.sh/chart: NAME-VERSION`을 레이블로서 사용하는 것을 권장하는데, 이렇게 하면 운영자는 레이블을 통해 특정 차트의 모든 인스턴스들을 편리하게 찾을 수 있다. 메타데이터 항목이 쿼리에 사용되지 않는다면, 어노테이션으로 설정해야 한다. 헬름 훅은 항상 어노테이션이다. ## 표준 레이블 아래 표에 헬름 차트에서 널리 사용되는 레이블이 있다. 헬름 자체는 특정 레이블을 필요로 하지 않는다. REC로 표시된 레이블은 권장되는 것으로서, 전체적인 정합성 유지를 위해 차트에 있어야 한다. OPT로 표시된 레이블은 선택사항이다. 이것들은 관용적 또는 일반적으로 사용하지만, 운영 목적에서는 그렇게 자주 사용하지 않는다. 이름|상태|설명 -----|------|---------- `app.kubernetes.io/name` | REC | 전체 앱을 잘 나타내는 앱 이름을 써야 한다. 흔히 `{{ template "name" . }}`로 쓴다. 많은 쿠버네티스 매니페스트에서 사용되는 것으로서, 헬름에만 있는 것이 아니다. `helm.sh/chart` | REC | 차트 이름과 버전을 써야 한다. `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | 항상 `{{ .Release.Service }}`로 설정해야 한다. 헬름이 관리하는 모든 것을 찾기 위한 것이다. `app.kubernetes.io/instance` | REC | `{{ .Release.Name }}`이어야 한다. 동일한 애플리케이션의 다른 인스턴스들을 구별하는 데 도움이 된다. `app.kubernetes.io/version` | OPT | 앱의 버전이며, `{{ .Chart.AppVersion }}`로 설정할 수 있다. `app.kubernetes.io/component` | OPT | 하나의 애플리케이션 내에서 각 부분들이 맡은 역할을 표시하는 일반적인 레이블이다. 예를 들면 `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | 하나의 애플리케이션을 구성하는 데 여러 차트 또는 소프트웨어 부분들이 함께 사용되는 경우(예를 들어, 웹사이트를 제공하는 애플리케이션 소프트웨어와 데이터베이스), 그것들이 지원하는 최상위 애플리케이션으로 설정할 수 있다. `app.kubernetes.io` 접두어를 가진 쿠버네티스 레이블에 대한 더 자세한 정보는 [쿠버네티스 문서](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)에서 찾아볼 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: 파드와 파드템플릿 description: 차트 매니페스트에 있는 파드와 파드템플릿 부분의 형식을 논한다. sidebar_position: 6 --- 이 부분은 모범사례 가이드의 일부로서 차트 매니페스트에 있는 파드와 파드템플릿 부분의 형식을 논한다. 파드템플릿을 사용하는 리소스들(일부)은 다음과 같다. - 디플로이먼트(Deployment) - 레플리케이션컨트롤러(ReplicationController) - 레플리카셋(ReplicaSet) - 데몬셋(DaemonSet) - 스테이트풀셋(StatefulSet) ## 이미지 컨테이너 이미지는 고정된 태그나 이미지의 SHA를 사용해야 한다. `latest`, `head`, `canary` 등 "유동적인" 목적으로 고안된 태그를 사용해서는 안된다. 이미지를 쉽게 교체하기 위해 `values.yaml` 파일 내에 이미지를 정의할 수 있다. ```yaml image: {{ .Values.redisImage | quote }} ``` `values.yaml` 내에서 이미지와 태그를 각각의 필드로 정의할 수도 있다. ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create`는 `deployment.yaml` 파일에서 다음과 같이 설정하여 기본적으로 `imagePullPolicy`를 `IfNotPresent`로 설정한다. ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` 그리고 `values.yaml`에서는 다음과 같이 설정한다. ```yaml image: pullPolicy: IfNotPresent ``` 마찬가지로, Kubernetes에서도 `imagePullPolicy`가 정의되지 않은 경우 기본값은 `IfNotPresent`이다. `IfNotPresent` 외에 다른 값을 사용하려면, `values.yaml`에 있는 값을 원하는 값으로 바꾸면 된다. ## 파드템플릿에는 셀렉터가 선언되어야 한다 모든 파드템플릿 섹션에는 셀렉터를 지정해야 한다. 예를 들면, ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` 이것은 리소스와 파드 간의 관계를 명확히 해주므로 좋은 사례이다. Deployment와 같은 리소스의 경우 이것이 더욱 중요하다. 셀렉터를 지정하지 않으면 _모든_ 레이블이 매칭되는 파드를 선택하는 데 사용되며, 버전이나 릴리스 날짜와 같이 변경되는 레이블을 사용하는 경우 깨질 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: 역할 기반 접근 제어 description: 차트 매니페스트에 있는 RBAC 리소스의 생성과 형식을 논한다. sidebar_position: 8 --- 이 부분은 모범사례 가이드의 일부로서 차트 매니페스트에 있는 RBAC 리소스의 생성과 형식을 논한다. RBAC 리소스는 다음과 같다. - ServiceAccount (네임스페이스 구분) - Role (네임스페이스 구분) - ClusterRole - RoleBinding (네임스페이스 구분) - ClusterRoleBinding ## YAML 설정 RBAC과 서비스어카운트(ServiceAccount) 설정은 개별 키로 되어야 한다. 둘은 별개의 것이다. 이 두가지 개념을 YAML 내에서 구분함으로써 둘 사이의 애매함을 없애고 명확히 할 수 있다. ```yaml rbac: # RBAC 리소스를 생성할지 지정 create: true serviceAccount: # 서비스어카운트를 생성할지 지정 create: true # 사용할 서비스어카운트 이름 # create가 true인데 이름이 지정되지 않으면, 풀네임 템플릿에 따라 이름이 생성됨 name: ``` 이 구조는 여러 개의 서비스어카운트를 필요로 하는 더 복잡한 차트로 확장할 수 있다. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC 리소스는 기본값으로 생성해야 한다 `rbac.create`는 RBAC 리소스를 생성할지를 컨트롤하는 불리언 값이어야 한다. 기본값은 `true`여야 한다. RBAC 접근 제어를 직접 관리하려는 사용자는 이 값을 `false`로 지정할 수 있다. (아래의 사례 참고) ## RBAC 리소스 사용하기 `serviceAccount.name`는 차트로 생성된 접근제어 리소스가 사용할 ServiceAccount 이름으로 설정해야 한다. `serviceAccount.create`가 true이면, 그 이름으로 서비스어카운트가 생성된다. 이름이 설정되지 않았다면 `fullname` 템플릿을 사용하여 이름이 생성된다. `serviceAccount.create`이 false이면, 서비스어카운트가 생성되지는 않지만, 나중에 RBAC 리소스를 수동으로 생성하고 참조하여 정상 작동하게 하려면 동일한 리소스들과 연계되어야 한다. `serviceAccount.create`가 false이고 이름이 지정되지 않으면, 기본 서비스어카운트를 사용한다. 서비스어카운트에 다음 헬퍼 템플릿을 사용해야 한다. ```yaml {{/* 사용할 서비스어카운트 이름 생성 */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: 템플릿 description: 템플릿에 관한 모범사례 들여다보기 sidebar_position: 3 --- 이 부분은 모범사례 가이드의 일부로서 템플릿을 자세히 알아본다. ## `templates/`의 구조 `templates/` 디렉토리는 다음과 같이 구조화되어야 한다. - YAML을 만드는 템플릿 파일들은 확장자가 `.yaml`이어야 한다. 형식이 정해지지 않은 컨텐츠를 만드는 템플릿 파일에는 `.tpl` 확장자를 쓸 수 있다. - 템플릿 파일 이름은 대시 표기법(`my-example-configmap.yaml`)을 따라야 하며, 카멜 표기법이 아니다. - 각 리소스 정의는 자체 템플릿 파일 내에 있어야 한다. - 템플릿 파일 이름은 이름 내에 리소스 종류를 반영해야 한다. 예 : `foo-pod.yaml`,`bar-svc.yaml` ## 정의된 템플릿의 이름 정의된 템플릿 (`{{ define }}` 지시문 내에 생성된 템플릿)은 전역에서 접근가능하다. 즉, 차트와 그 모든 하위 차트는 `{{ define }}` 으로 생성된 모든 템플릿에 접근할 수 있다. 위와 같은 이유로, _모든 정의된 템플릿 이름은 네임스페이스별로 구분되어야 한다._ 올바른 경우: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` 잘못된 경우: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` 이 모범 사례에 따라 템플릿 이름이 자동으로 정의되므로, `helm create` 명령을 통해 새 차트를 생성하는 것이 좋다. ## 템플릿 형식 템플릿은 _스페이스 2개_ (탭 아님)를 사용하여 들여쓰기 해야 한다. 템플릿 지시문에서 여는 중괄호 뒤와 닫는 중괄호 앞에는 공백을 두어야 한다. 올바른 경우: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` 잘못된 경우: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` 템플릿은 가능한 경우 공백을 줄여야 한다. ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` 블록 (예 : 제어 구조)은 템플릿 코드의 흐름을 나타내기 위해 들여쓰기 할 수 있다. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` 하지만, YAML은 공백 지향 언어이기 때문에, 규칙에 따른 코드 들여쓰기가 불가능한 경우가 많다. ## 생성된 템플릿의 화이트스페이스 생성된 템플릿의 공백을 최소로 유지하는 것이 좋다. 특히, 많은 수의 빈 줄이 서로 인접해 있으면 안된다. 그러나 가끔씩 나오는 빈 줄(특히 논리 섹션 사이)은 무방하다. 가장 좋은 경우: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 괜찮은 경우: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 지양해야 할 경우: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## 주석 (YAML 주석 vs. 템플릿 주석) YAML과 헬름 템플릿 모두 주석 마커가 있다. YAML 주석: ```yaml # This is a comment type: sprocket ``` 템플릿 주석: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` 정의된 템플릿 설명과 같이 템플릿의 기능을 문서화할 때는, 템플릿 주석을 사용해야 한다. ```yaml {{- /* mychart.shortname 은 릴리스 이름에서 6자만 자른 것을 제공한다. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` 템플릿 내에서, YAML 주석은 헬름 사용자가 디버깅 중에 주석을 볼 때 유용하게 사용될 수 있다. ```yaml # 값이 100Gi를 넘으면 문제가 발생할 수 있다 memory: {{ .Values.maxMem | quote }} ``` 위의 주석은 사용자가 `helm install --debug` 를 실행할 때 표시되는데, `{{-/ * * /-}}` 섹션에 지정된 주석은 표시되지 않는다. 특정 템플릿 함수에서 필수로 요구될 수 있는 Helm 값이 포함된 템플릿 섹션에 `#` YAML 주석을 추가할 때 주의해야 한다. 예를 들어, 위 예시에 `required` 함수가 추가되고 `maxMem`이 설정되지 않은 경우, `#` YAML 주석은 렌더링 오류를 발생시킨다. 올바른 경우: `helm template`이 이 블록을 렌더링하지 않는다 ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` 잘못된 경우: `helm template`이 `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` 오류를 반환한다 ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` YAML 주석이 그대로 유지되는 동작에 대한 다른 예시는 [템플릿 디버깅](../chart_template_guide/debugging.md)을 참고한다. ## 템플릿과 템플릿 출력에서 JSON 사용하기 YAML은 JSON의 상위집합이다. 경우에 따라서는, JSON 구문을 사용하는 것이 다른 YAML 표현보다 더 읽기 쉬울 수 있다. 예를 들어, 이 YAML은 목록을 표현하는 일반적인 YAML 방법에 더 가깝다. ```yaml arguments: - "--dirname" - "/foo" ``` 그러나 JSON 목록 스타일로 축약하면 읽기가 더 쉽다. ```yaml arguments: ["--dirname", "/foo"] ``` 가독성을 높이기 위해 JSON을 사용하는 것은 좋다. 하지만, 더 복잡한 구조를 나타내는 데에 JSON 구문을 사용해서는 안된다. YAML (예를 들어 init 컨테이너 설정)에 포함된 순수 JSON을 다룰 때에는, 당연히 JSON 형식을 사용하는 것이 적절하다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: 값 description: 값을 구성하고 사용하는 방법을 집중적으로 다룬다. sidebar_position: 2 --- 이 부분은 모범사례 가이드의 일부로서 값(values)을 사용하는 방법을 다룬다. 여기서는 차트의 `values.yaml` 파일을 설계하는 데 초점을 맞추고, 값을 어떻게 구성하고 사용할지에 대한 권고사항을 제시한다. ## 네이밍 컨벤션 변수 이름은 소문자로 시작해야하며 단어는 카멜케이스로 구분해야 한다. 올바른 경우: ```yaml chicken: true chickenNoodleSoup: true ``` 잘못된 경우: ```yaml Chicken: true # 첫 글자가 대문자이면 빌트인 변수와 충돌이 발생할 수 있다 chicken-noodle-soup: true # 변수명에 하이픈(-)을 사용하지 말자 ``` 헬름의 모든 빌트인 변수는 사용자 정의 값과 쉽게 구분할 수 있도록 대문자로 시작한다: `.Release.Name`, `.Capabilities.KubeVersion`. ## 평면화(flat) 값, 중첩된(nested) 값 YAML 은 유연한 형식으로, 값은 깊게 중첩되거나 평면화 될 수 있다. 중첩된 경우: ```yaml server: name: nginx port: 80 ``` 평면화된 경우: ```yaml serverName: nginx serverPort: 80 ``` 대부분의 경우, 중첩된 경우보다는 평면화된 경우를 선호하게 된다. 그 이유는 템플릿 개발자와 사용자에게 더 간단하기 때문이다. 최적의 안전성을 위해, 모든 수준에서 중첩된 값을 확인해야 한다. ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` 모든 중첩된 계층에 대하여 존재 유무를 점검해야 한다. 다만 평면화된 구성의 경우, 이러한 검사를 건너뛸 수 있으므로 템플릿을 더 쉽게 읽고 사용할 수 있다. ``` {{ default "none" .Values.serverName }} ``` 관련 변수가 많고 그 중 하나 이상이 선택 사항이 아닌 경우, 중첩된 값을 사용하여 가독성을 높일 수 있다. ## 자료형을 명확히 하자 YAML 의 유형에 대한 강제적인 규칙은 때때로 직관적이지 못하다. 예를 들어 `foo: false` 는 `foo: "false"` 와 동일하지 않다. `foo: 12345678` 과 같은 큰 정수는 경우에 따라 수학적 표기법으로 변환된다. 유형 변환 오류를 피하는 가장 쉬운 방법은 문자열에 대해서만 명시하고 이 외에는 명시하지 않는 것이다. 혹은 더 간단하게, _모두 인용부호로 감싸서 문자열로 만드는 것이다_. 종종 정수형의 캐스팅 문제를 방지하기위해, 정수도 문자열로 저장하고 템플릿에서 `{{ int $value }}` 를 사용하여 문자열에서 다시 정수로 변환하는 것이 유리하다. 대부분의 경우 명시적 유형 태그가 존중되므로 `foo: !!string 1234` 는 `1234` 를 문자열로 처리해야 한다. _그러나_ YAML 파서는 태그를 사용하므로 한번의 구문 분석 후에는 유형 데이터가 손실된다. ## 사용자가 값을 어떻게 사용할지를 고려하자 값에는 다음과 같은 세 가지 출처가 있다. - 차트의 `values.yaml` 파일 - `helm install -f` 또는 `helm upgrade -f` 에서 제공하는 값 파일 - `helm install` 또는 `helm upgrade` 의 `--set` 또는 `--set-string` 플래그에 전달된 값 값의 구조를 디자인 할 때 차트 사용자는 `-f` 플래그 또는 `--set` 옵션을 통해 값을 재정의 할 수 있다. `--set` 은 표현력이 더 제한적이므로, `values.yaml` 파일을 작성하기 위한 첫 번째 지침은, _`--set` 에서 쉽게 재정의 할 수 있도록 하는 것이다_. 이러한 이유로 맵을 사용하여 값 파일을 구조화하는 것이 더 좋다. `--set` 과 함께 사용하기 어려운 경우 ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` 위의 내용은 헬름 `<=2.4` 에서는 `--set` 으로 표현할 수 없다. 헬름 2.5 에서 foo 의 포트에 액세스 하는 것은 `--set servers[0].port=80` 이다. 사용자가 파악하기 어려울 뿐만 아니라 나중에 `서버` 의 순서가 변경되면 오류가 발생하기 쉽다. 사용하기 쉬운 경우: ```yaml servers: foo: port: 80 bar: port: 81 ``` foo 의 포트에 접근하는 것이 훨씬 명확하다: `--set servers.foo.port=80`. ## `values.yaml`을 문서화하자 `values.yaml` 에 정의된 모든 속성은 문서화 되어야 한다. 문서 문자열은 설명하는 속성의 이름으로 시작하고 최소한 한 문장으로 된 설명을 제공해야 한다. 잘못된 경우: ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` 올바른 경우: ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` 각 주석을 문서화하는 매개 변수의 이름으로 시작하면 문서를 쉽게 정리할 수 있으며, 문서화 도구가 문서 문자열과 이를 설명하는 매개변수를 안정적으로 연관시킬 수 있게 해준다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: 템플릿 내부 파일 접근하기 description: 템플릿 안에 있는 파일에 접근하는 방법 sidebar_position: 10 --- 이전 섹션에서 명명된 템플릿을 만들고 접근하는 몇 가지 방법을 살펴보았다. 이를 통해 다른 템플릿에서 필요한 템플릿을 쉽게 가져올 수 있다. 하지만 때로는 _템플릿이 아닌 파일_ 을 가져와서 그 내용을 템플릿 렌더러를 거치지 않고 직접 주입하고 싶을 때가 있다. Helm은 `.Files` 객체를 통해 파일에 접근할 수 있게 해 준다. 템플릿 예제를 살펴보기 전에 이 기능이 어떻게 작동하는지 알아야 할 몇 가지가 있다: - Helm 차트에 추가 파일을 넣어도 된다. 이 파일들은 함께 번들로 묶인다. 하지만 주의가 필요하다. Kubernetes 객체의 저장 제한 때문에 차트는 1M보다 작아야 한다. - 일부 파일은 `.Files` 객체를 통해 접근할 수 없는데, 주로 보안상의 이유 때문이다. - `templates/` 안에 있는 파일은 접근할 수 없다. - `.helmignore`를 사용하여 제외된 파일은 접근할 수 없다. - 부모 차트를 포함하여, Helm 애플리케이션 [하위 차트](./subcharts_and_globals.md) 외부에 있는 파일은 접근할 수 없다. - 차트는 UNIX 모드 정보를 보존하지 않으므로, `.Files` 객체에 관해서는 파일 수준 권한이 파일 가용성에 영향을 미치지 않는다. - [기본 예제](#기본-예제) - [경로 헬퍼](#경로-헬퍼) - [글롭(Glob) 패턴](#글롭glob-패턴) - [ConfigMap과 Secret 유틸리티 함수](#configmap과-secret-유틸리티-함수) - [인코딩](#인코딩) - [Lines](#lines) ## 기본 예제 위의 주의 사항을 알았으니, 이제 세 개의 파일을 읽어서 ConfigMap에 넣는 템플릿을 작성해 보자. 시작하기 위해 차트에 세 개의 파일을 추가하고, 세 파일 모두 `mychart/` 디렉토리 안에 직접 넣는다. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` 이 파일들은 각각 간단한 TOML 파일이다(옛날 Windows INI 파일을 생각하면 된다). 파일 이름을 알고 있으므로 `range` 함수를 사용하여 파일들을 순회하며 그 내용을 ConfigMap에 주입할 수 있다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` 이 ConfigMap은 이전 섹션에서 논의한 여러 기법을 사용한다. 예를 들어, `.Files` 객체에 대한 참조를 담기 위해 `$files` 변수를 만든다. 또한 `tuple` 함수를 사용하여 순회할 파일 목록을 만든다. 그런 다음 각 파일 이름(`{{ . }}: |-`)을 출력하고 그 뒤에 파일 내용(`{{ $files.Get . }}`)을 출력한다. 이 템플릿을 실행하면 세 파일의 내용이 모두 포함된 단일 ConfigMap이 생성된다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## 경로 헬퍼 파일을 다룰 때, 파일 경로 자체에 대한 표준 작업을 수행하는 것이 매우 유용할 수 있다. 이를 돕기 위해 Helm은 Go의 [path](https://golang.org/pkg/path/) 패키지에서 많은 함수를 가져와 사용할 수 있게 해 준다. 이 함수들은 Go 패키지와 같은 이름으로 접근할 수 있지만, 첫 글자가 소문자이다. 예를 들어, `Base`는 `base`가 된다. 가져온 함수들은 다음과 같다: - Base - Dir - Ext - IsAbs - Clean ## 글롭(Glob) 패턴 차트가 커지면서 파일을 더 체계적으로 정리해야 할 필요가 생길 수 있다. 이를 위해 [글롭 패턴](https://godoc.org/github.com/gobwas/glob)의 모든 유연성을 활용하여 특정 파일을 추출하는 데 도움이 되는 `Files.Glob(pattern string)` 메서드를 제공한다. `.Glob`은 `Files` 타입을 반환하므로, 반환된 객체에서 `Files`의 모든 메서드를 호출할 수 있다. 예를 들어, 다음과 같은 디렉토리 구조를 상상해 보자: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Glob을 사용하는 여러 방법이 있다: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` 또는 ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap과 Secret 유틸리티 함수 (Helm 2.0.2 이후 사용 가능) 파일 내용을 ConfigMap과 Secret에 넣어서 런타임에 파드에 마운트하는 것은 매우 일반적인 작업이다. 이를 돕기 위해 `Files` 타입에 몇 가지 유틸리티 메서드를 제공한다. 파일을 더 체계적으로 정리하려면 이러한 메서드를 `Glob` 메서드와 함께 사용하는 것이 특히 유용하다. 위의 [글롭(Glob) 패턴](#글롭glob-패턴) 예제에서 나온 디렉토리 구조를 가정하면: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## 인코딩 파일을 가져와서 템플릿이 base-64로 인코딩하도록 하여 안전한 전송을 보장할 수 있다: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` 위 코드는 이전에 사용했던 동일한 `config1.toml` 파일을 가져와서 인코딩한다: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Lines 때로는 템플릿에서 파일의 각 줄에 접근하는 것이 필요할 수 있다. 이를 위해 편리한 `Lines` 메서드를 제공한다. `range` 함수를 사용하여 `Lines`를 순회할 수 있다: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` `helm install` 중에 차트 외부의 파일을 전달할 방법은 없다. 따라서 사용자에게 데이터를 제공받으려면 `helm install -f` 또는 `helm install --set`을 사용하여 로드해야 한다. 이것으로 Helm 템플릿 작성을 위한 도구와 기법에 대한 심층 탐구를 마친다. 다음 섹션에서는 특별한 파일인 `templates/NOTES.txt`를 사용하여 차트 사용자에게 설치 후 지침을 보내는 방법을 살펴볼 것이다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: 빌트인 객체 description: 템플릿에서 사용가능한 빌트인 객체 sidebar_position: 3 --- 객체는 템플릿 엔진에서 템플릿으로 전달된다. 그리고 사용자의 코드는 객체를 전달할 수 있다. (`with` 와 `range` 문을 볼 때 예제로 확인할 수 있다.) 이후에 보게 될 `tuple` 함수와 같이 템플릿 내에서 새로운 객체를 만드는 몇 가지 방법이 있다. 객체는 간단히 하나의 값만 가질 수도 있다. 또는 다른 객체나 기능을 포함할 수 있다. 예를 들어, `Release` 객체는 (`Release.Name` 과 같은) 여러 객체를 포함하며 `Files` 객체는 몇 가지 함수를 가지고 있다. 이전 섹션에서는 템플릿에 릴리즈 이름을 삽입하기 위해 `{{.Release.Name}}` 을 사용하였다. `Release` 는 내 템플릿에 접근할 수 있는 최상위 객체 중 하나이다. - `Release`: 이 객체는 릴리스 자체를 서술한다. 여러 객체를 가지고 있다. 그 내부: - `Release.Name`: 릴리스 이름 - `Release.Namespace`: 릴리스될 네임스페이스 (manifest에서 오버라이드하지 않은 경우) - `Release.IsUpgrade`: 현재 작업이 업그레이드 또는 롤백인 경우 `true` 로 설정된다. - `Release.IsInstall`: 현재 작업이 설치일 경우 `true` 로 설정. - `Release.Revision`: 이 릴리스의 리비전 번호. 설치시에는 이 값이 1이며 업그레이드나 롤백을 수행할 때마다 증가한다. - `Release.Service`: 현재 템플릿을 렌더링하는 서비스. Helm 에서는 항상 `Helm` 이다. - `Values`: `values.yaml` 파일 및 사용자 제공 파일에서 템플릿으로 전달된 값. 기본적으로 `Values` 는 비어 있다. - `Chart`: `Chart.yaml` 파일의 내용. `Chart.yaml` 안의 모든 데이터는 여기서 접근 가능하다. 예를 들어 `{{ .Chart.Name }}-{{ .Chart.Version }}` 은 `mychart-0.1.0` 를 출력한다. - 사용가능한 필드는 [차트 가이드](/topics/charts.md#the-chartyaml-file) 에 나열되어 있다. - `Subcharts`: 부모 차트에서 서브차트의 스코프(.Values, .Charts, .Releases 등)에 접근할 수 있게 해준다. 예를 들어 `.Subcharts.mySubChart.myValue` 로 `mySubChart` 차트의 `myValue` 에 접근할 수 있다. - `Files`: 차트 내의 모든 특수하지 않은(non-special) 파일에 대한 접근을 제공한다. 템플릿에 접근하는 데에는 사용할 수 없지만, 차트 내의 다른 파일에 접근하는 데에는 사용할 수 있다. 자세한 내용은 [파일 접근하기](./accessing_files.md) 섹션을 참고하자. - `Files.Get` 은 이름으로 파일을 가지고 오는 함수이다. (`.Files.Get config.ini`) - `Files.GetBytes` 는 파일의 내용을 문자열이 아닌 바이트 배열로 가져오는 함수이다. 이미지 같은 것을 다룰 때 유용하다. - `Files.Glob` 는 이름이 주어진 shell glob 패턴과 매치되는 파일 목록을 반환하는 함수이다. - `Files.Lines` 는 파일을 한 줄씩 읽는 함수이다. 이것은 파일 내의 각 행을 순회(iterate)하는데 유용하다. - `Files.AsSecrets` 은 파일 본문을 Base64로 인코딩된 문자열로 반환하는 함수이다. - `Files.AsConfig` 는 파일 본문을 YAML 맵으로 반환하는 함수이다. - `Capabilities`: 쿠버네티스 클러스터가 지원하는 기능에 대한 정보를 제공한다. - `Capabilities.APIVersions` 는 버전의 집합이다. - `Capabilities.APIVersions.Has $version` 은 버전(예: `batch/v1`) 이나 리소스(예: `apps/v1/Deployment`) 를 클러스터에서 사용할 수 있는지 여부를 나타낸다. - `Capabilities.KubeVersion` 과 `Capabilities.KubeVersion.Version` 는 쿠버네티스 버전이다. - `Capabilities.KubeVersion.Major` 는 쿠버네티스 메이저 버전이다. - `Capabilities.KubeVersion.Minor` 는 쿠버네티스 마이너 버전이다. - `Capabilities.HelmVersion` 는 Helm 버전 정보를 담고 있는 객체이며, `helm version` 의 출력과 동일하다. - `Capabilities.HelmVersion.Version` 는 semver 형식의 현재 Helm 버전이다. - `Capabilities.HelmVersion.GitCommit` 는 Helm git sha1 이다. - `Capabilities.HelmVersion.GitTreeState` 는 Helm git 트리의 상태이다. - `Capabilities.HelmVersion.GoVersion` 는 사용된 Go 컴파일러의 버전이다. - `Template`: 실행 중인 현재 템플릿에 대한 정보를 포함한다. - `Name`: 현재 템플릿에 대한 네임스페이스 파일 경로 (예: `mychart/templates/mytemplate.yaml`) - `BasePath`: 현재 차트의 템플릿 디렉토리에 대한 네임스페이스 경로 (예: `mychart/templates`). 빌트인 값은 항상 대문자로 시작한다. 이것은 Go의 명명 규칙을 따르고 있다. 사용자는 자신만의 이름을 만들 때, 팀에 적합한 규칙을 자유롭게 사용할 수 있다. [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에서 볼 수 있는 많은 차트를 만든 팀들처럼, 일부 팀에서는 로컬 이름과 빌트인 이름을 구분하기 위해 첫 글자로 소문자만 사용하도록 선택한다. 이 가이드에서는 해당 규칙을 따른다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: 흐름 제어 description: 템플릿 내부의 흐름 구조에 대한 간단한 개요 sidebar_position: 7 --- 제어 구조(템플릿 용어로 "액션"이라 함)를 사용하면 템플릿 작성자가 템플릿 생성의 흐름을 제어할 수 있다. Helm의 템플릿 언어는 다음과 같은 제어 구조를 제공한다. - `if`/`else` - 조건부 블록 생성 - `with` - 스코프 지정 - `range` - "for each" 스타일 반복문 제공 이 외에도 명명된(named) 템플릿 세그먼트를 선언하고 사용하기 위한 몇 가지 액션을 제공한다. - `define` - 템플릿 내부에서 새로운 명명된 템플릿을 선언한다 - `template` - 명명된 템플릿을 가져온다 - `block` - 채울 수 있는 특별한 종류의 템플릿 영역을 선언한다 이 섹션에서는 `if`, `with`, `range`에 대해 설명한다. 나머지는 이 가이드의 뒷부분에 있는 "명명된 템플릿" 섹션에서 다룬다. ## If/Else 가장 먼저 살펴볼 제어 구조는 템플릿에 텍스트 블록을 조건부로 포함하기 위한 것이다. 이것이 바로 `if`/`else` 블록이다. 조건문의 기본 구조는 다음과 같다. ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` 여기서 값 대신 _파이프라인_ 에 대해 이야기하고 있다는 점에 주목하자. 이는 제어 구조가 단순히 값을 평가하는 것이 아니라 전체 파이프라인을 실행할 수 있다는 것을 명확히 하기 위함이다. 파이프라인은 다음과 같은 경우 _false_ 로 평가된다. - 불리언 false - 숫자 0 - 빈 문자열 - `nil` (비어있거나 null) - 빈 컬렉션 (`map`, `slice`, `tuple`, `dict`, `array`) 그 외의 모든 조건에서는 true이다. ConfigMap에 간단한 조건문을 추가해 보자. drink가 coffee로 설정된 경우 다른 설정을 추가할 것이다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` 이전 예제에서 `drink: coffee`를 주석 처리했으므로 출력에는 `mug: "true"` 플래그가 포함되지 않을 것이다. 하지만 `values.yaml` 파일에 해당 라인을 다시 추가하면 출력은 다음과 같이 된다. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## 공백 제어 조건문을 살펴보는 김에 템플릿에서 공백을 제어하는 방법도 간단히 살펴보자. 이전 예제를 좀 더 읽기 쉽게 포맷해 보자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` 처음에는 괜찮아 보인다. 하지만 템플릿 엔진을 통해 실행하면 안타까운 결과를 얻게 된다. ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` 무슨 일이 일어난 걸까? 위의 공백 때문에 잘못된 YAML이 생성되었다. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug`의 들여쓰기가 잘못되었다. 해당 라인의 들여쓰기를 줄이고 다시 실행해 보자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` 이렇게 보내면 유효한 YAML을 얻게 되지만, 여전히 조금 이상하게 보인다. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` YAML에 몇 개의 빈 줄이 있는 것을 주목하자. 왜 그럴까? 템플릿 엔진이 실행될 때 `{{`와 `}}` 내부의 내용은 _제거_ 되지만, 남은 공백은 그대로 유지된다. YAML은 공백에 의미를 부여하므로 공백 관리가 상당히 중요해진다. 다행히 Helm 템플릿에는 이를 도와주는 몇 가지 도구가 있다. 첫째, 템플릿 선언의 중괄호 구문에 특수 문자를 추가하여 템플릿 엔진에게 공백을 제거하도록 지시할 수 있다. `{{- `(대시와 공백 추가)는 왼쪽 공백을 제거해야 함을 나타내고, ` -}}`는 오른쪽 공백을 제거해야 함을 의미한다. _주의하자! 개행도 공백이다!_ > `-`와 지시어의 나머지 부분 사이에 공백이 있어야 한다. > `{{- 3 }}`은 "왼쪽 공백을 제거하고 3을 출력"을 의미하고, > `{{-3 }}`은 "-3을 출력"을 의미한다. 이 구문을 사용하여 템플릿을 수정하면 새 줄을 제거할 수 있다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` 이 점을 명확히 하기 위해 위의 내용을 조정하고 이 규칙에 따라 삭제될 각 공백을 `*`로 대체해 보자. 줄 끝의 `*`는 제거될 개행 문자를 나타낸다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` 이를 염두에 두고 Helm을 통해 템플릿을 실행하면 다음과 같은 결과를 볼 수 있다. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` 공백 제거 수정자를 사용할 때 주의하자. 다음과 같은 실수를 저지르기 쉽다. ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` 이렇게 하면 양쪽의 개행을 모두 제거하여 `food: "PIZZA"mug: "true"`가 출력된다. > 템플릿의 공백 제어에 대한 자세한 내용은 [공식 Go 템플릿 문서](https://godoc.org/text/template)를 참조하자. 마지막으로, 템플릿 지시어의 간격을 숙달하려고 노력하는 대신 템플릿 시스템에게 들여쓰기를 지정하도록 하는 것이 더 쉬울 때가 있다. 이런 이유로 `indent` 함수를 사용하는 것이 유용할 때가 있다 (`{{ indent 2 "mug:true" }}`). ## `with`를 사용하여 스코프 수정 다음으로 살펴볼 제어 구조는 `with` 액션이다. 이것은 변수 스코프를 제어한다. `.`는 _현재 스코프_ 에 대한 참조임을 상기하자. 따라서 `.Values`는 템플릿에게 현재 스코프에서 `Values` 객체를 찾으라고 지시한다. `with`의 구문은 간단한 `if` 문과 유사하다. ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` 스코프는 변경될 수 있다. `with`를 사용하면 현재 스코프(`.`)를 특정 객체로 설정할 수 있다. 예를 들어, 우리는 `.Values.favorite`로 작업해 왔다. `.` 스코프가 `.Values.favorite`를 가리키도록 ConfigMap을 다시 작성해 보자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` 이전 예제에서 `if` 조건문을 제거했다는 점에 주목하자. `PIPELINE`의 값이 비어 있지 않은 경우에만 `with` 뒤의 블록이 실행되기 때문에 이제 더 이상 필요하지 않다. 이제 `.drink`와 `.food`를 전체 경로 없이 참조할 수 있다는 점에 주목하자. 이는 `with` 문이 `.`를 `.Values.favorite`를 가리키도록 설정했기 때문이다. `.`는 `{{ end }}` 이후에 이전 스코프로 재설정된다. 하지만 여기서 주의해야 할 점이 있다! 제한된 스코프 내에서는 `.`를 사용하여 부모 스코프의 다른 객체에 접근할 수 없다. 예를 들어 다음은 실패한다. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name`이 `.`의 제한된 스코프 내에 없기 때문에 오류가 발생한다. 그러나 마지막 두 줄을 바꾸면 `{{ end }}` 후에 스코프가 재설정되므로 예상대로 작동한다. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` 또는 `$`를 사용하여 부모 스코프에서 `Release.Name` 객체에 접근할 수 있다. `$`는 템플릿 실행이 시작될 때 루트 스코프에 매핑되며 템플릿 실행 중에 변경되지 않는다. 다음도 작동한다. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` `range`를 살펴본 후, 위의 스코프 문제에 대한 하나의 해결책을 제공하는 템플릿 변수에 대해 살펴볼 것이다. ## `range` 액션으로 반복하기 많은 프로그래밍 언어에서 `for` 루프, `foreach` 루프 또는 유사한 함수형 메커니즘을 사용한 반복을 지원한다. Helm의 템플릿 언어에서 컬렉션을 반복하는 방법은 `range` 연산자를 사용하는 것이다. 시작하기 위해 `values.yaml` 파일에 피자 토핑 목록을 추가해 보자. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` 이제 `pizzaToppings` 목록(템플릿에서는 `slice`라고 함)이 생겼다. 템플릿을 수정하여 이 목록을 ConfigMap에 출력할 수 있다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` `$`를 사용하여 부모 스코프에서 `Values.pizzaToppings` 목록에 접근할 수 있다. `$`는 템플릿 실행이 시작될 때 루트 스코프에 매핑되며 템플릿 실행 중에 변경되지 않는다. 다음도 작동한다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` `toppings:` 목록을 더 자세히 살펴보자. `range` 함수는 `pizzaToppings` 목록을 "range over"(반복) 한다. 하지만 여기서 흥미로운 일이 발생한다. `with`가 `.`의 스코프를 설정하는 것처럼 `range` 연산자도 그렇게 한다. 루프를 통과할 때마다 `.`는 현재 피자 토핑으로 설정된다. 즉, 처음에는 `.`가 `mushrooms`로 설정된다. 두 번째 반복에서는 `cheese`로 설정되는 식이다. `.`의 값을 파이프라인으로 직접 보낼 수 있으므로 `{{ . | title | quote }}`를 실행하면 `.`를 `title`(타이틀 케이스 함수)로 보낸 다음 `quote`로 보낸다. 이 템플릿을 실행하면 출력은 다음과 같다. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` 이 예제에서는 약간의 트릭을 사용했다. `toppings: |-` 줄은 여러 줄 문자열을 선언한다. 따라서 토핑 목록은 실제로 YAML 목록이 아니라 큰 문자열이다. 왜 이렇게 할까? ConfigMap의 `data`는 키와 값이 모두 단순 문자열인 키/값 쌍으로 구성되기 때문이다. 이것이 왜 그런지 이해하려면 [Kubernetes ConfigMap 문서](https://kubernetes.io/docs/concepts/configuration/configmap/)를 참조하자. 하지만 우리에게 이 세부 사항은 그다지 중요하지 않다. > YAML의 `|-` 마커는 여러 줄 문자열을 취한다. 이것은 여기서 예시된 것처럼 > 매니페스트 내부에 큰 데이터 블록을 포함하는 데 유용한 기술일 수 있다. 때때로 템플릿 내부에서 목록을 빠르게 만들고 해당 목록을 반복하는 것이 유용하다. Helm 템플릿에는 이를 쉽게 만드는 함수가 있다: `tuple`. 컴퓨터 과학에서 튜플은 고정 크기이지만 임의의 데이터 타입을 가진 목록과 유사한 컬렉션이다. 이것은 `tuple`이 사용되는 방식을 대략적으로 전달한다. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` 위의 내용은 다음과 같이 출력된다. ```yaml sizes: |- - small - medium - large ``` 목록과 튜플 외에도 `range`는 키와 값이 있는 컬렉션(`map` 또는 `dict` 같은)을 반복하는 데 사용할 수 있다. 다음 섹션에서 템플릿 변수를 소개할 때 그 방법을 살펴볼 것이다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "부록: Go 자료형과 템플릿" description: 템플릿에서의 변수에 관한 간단한 개괄 sidebar_position: 16 --- 헬름 템플릿 언어는 강한 타이핑(strongly typed)인 Go 프로그래밍 언어로 구현된다. 이러한 이유로, 템플릿에서의 변수는 _타이핑(typed)_된다. 대부분의 경우, 변수는 다음 자료형 중 하나로 노출된다. - string: 텍스트 문자열 - bool: `true` 또는 `false` - int: 정수 값 (8, 16, 32, 64 비트의 부호가 있거나(signed) 없는(unsigned) 다양한 자료형이 있다) - float64: 64비트 부동 소수점 값 (8, 16, 32 비트의 다양한 자료형이 있다) - byte slice(`[]byte`), 흔히 (잠재적으로) 바이너리 데이터를 담기 위해 사용된다. - struct(구조체): 프로퍼티와 메소드를 가지는 객체 - 위의 자료형 중 하나에 대한 슬라이스(인덱스 있는 리스트) - 위의 자료형 중 하나에 대한 문자열-키 맵(`map[string]interface{}`) Go에는 다른 여러가지 자료형이 있는데, 템플릿에서는 때에 따라 자료형을 변환해야 할 수도 있다. 객체 자료형을 디버그하는 가장 쉬운 방법은 템플릿 내에서 자료형을 출력하는 `printf "%T"`에 전달하는 것이다. 또한 `typeOf`과 `kindOf` 함수도 살펴보자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: 템플릿 디버깅 description: 배포에 실패한 차트의 트러블슈팅 sidebar_position: 13 --- 렌더링된 템플릿이 쿠버네티스 API 서버로 전송될 때 문서 형식 이외의 이유로 YAML 파일들이 거부될 수 있기 때문에, 템플릿 디버깅은 다소 까다로울 수 있다. 디버깅에 도움이 되는 몇 가지 명령어들이 있다. - `helm lint` 는 내 차트가 모범 사례에 맞는지 검증하는 믿을만한 도구이다. - `helm template --debug` 는 차트 템플릿을 로컬에서 테스트 렌더링한다. - `helm install --dry-run --debug` 도 차트를 로컬에서 렌더링하지만, 실제로 설치하지는 않는다. 클러스터에서 충돌하는 리소스가 이미 실행 중인지도 확인한다. `--dry-run=server`를 설정하면 차트의 `lookup` 함수도 서버를 대상으로 실행한다. - `helm get manifest`: 서버에 어떤 템플릿들이 설치되어 있는지 알아 볼 수 있는 유용한 방법이다. 내 YAML이 파싱에 실패했지만, 무엇이 생성되는지를 확인해보고 싶을 때, 템플릿에서 문제가 되는 섹션을 주석처리하고 `helm install --dry-run --debug` 를 다시 실행해보면 YAML 을 쉽게 확인해 볼 수 있다. ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` 윗쪽 내용은 렌더링되고 주석은 그대로 반환된다. ```yaml apiVersion: v2 # some: problem section # "bar" ``` 이렇게 하면 YAML 파싱 오류로 인한 차단 없이 생성되는 내용을 빠르게 확인해 볼 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: 템플릿 함수 목록 description: 헬름에서 사용가능한 템플릿 함수에 대한 목록 sidebar_position: 6 --- 헬름에는 템플릿에서 활용할 수 있는 많은 템플릿 함수들이 포함되어 있다. 여기에 나열되며 다음 범주로 분류된다. * [암호화 및 보안](#암호화-및-보안-함수) * [날짜](#날짜-함수) * [사전](#사전-및-사전-함수) * [인코딩](#인코딩-함수) * [파일 경로](#파일-경로-함수) * [쿠버네티스 및 차트](#쿠버네티스-및-차트-함수) * [논리 및 흐름 제어](#논리-및-흐름-제어-함수) * [목록](#목록-및-목록-함수) * [수학](#수학-함수) * [실수 수학](#실수-수학-함수) * [네트워크](#네트워크-함수) * [리플렉션](#리플렉션-함수) * [정규 표현식](#정규-표현식) * [유의적 버전](#유의적-버전-함수) * [문자열](#문자열-함수) * [형 변환](#형-변환-함수) * [URL](#url-함수) * [UUID](#uuid-함수) ## 논리 및 흐름 제어 함수 헬름은 [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) 를 포함한 수많은 논리 및 흐름 제어 기능이 포함되어 있다. ### and 두 인수의 불리언 and를 반환한다. ``` and .Arg1 .Arg2 ``` ### or 두 인수의 불리언 or를 반환한다. 비어 있지 않은 첫 번째 인수 또는 마지막 인수를 반환한다. ``` or .Arg1 .Arg2 ``` ### not 인수의 불리언 부정을 반환한다. ``` not .Arg ``` ### eq 인수들이 같은지 여부를 불리언으로 반환한다. (예: Arg1 == Arg2) ``` eq .Arg1 .Arg2 ``` ### ne 인수들이 같지 않은지 여부를 불리언으로 반환한다. (예: Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt 첫 번째 인수가 두 번째 인수보다 작으면 불리언 true를 반환한다. 그렇지 않으면 False가 반환된다 (예 : Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le 첫 번째 인수가 두 번째 인수보다 작거나 같은 경우 불리언 true를 반환한다. 그렇지 않으면 False가 반환된다 (예 : Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt 첫 번째 인수가 두 번째 인수보다 크면 불리언 true를 반환한다. 그렇지 않으면 False가 반환된다 (예 : Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge 첫 번째 인수가 두 번째 인수보다 크거나 같은 경우 불리언 true를 반환한다. 그렇지 않으면 False가 반환된다 (예 : Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default 간단한 기본값을 설정하려면 `default`를 사용한다. ``` default "foo" .Bar ``` 위에서 `.Bar` 가 비어 있지 않은 값으로 평가되면 사용된다. 하지만 비어 있으면 `foo` 가 대신 반환된다. "비어 있음"의 정의는 다음의 유형을 따른다. - 숫자: 0 - 문자열: "" - 리스트형: `[]` - 딕셔너리형: `{}` - 불리언: `false` - `nil` 의 경우 항상 (null 이라고도 함) 구조체의 경우 비어 있다는 정의가 없으므로, 구조체는 기본값을 반환하지 않는다. ### empty `empty` 함수는 주어진 값이 비어 있다고 간주되면 `true` 를 반환하고 그렇지 않으면 `false` 를 반환한다. 빈 값은 `default` 섹션에 나열된다. ``` empty .Foo ``` Go 템플릿 조건부에서는 비어 있음이 자동으로 계산된다. 따라서 `if not empty .Foo` 는 거의 필요하지 않다. 대신 `if .Foo` 를 사용하도록 하자. ### fail 지정된 텍스트와 함께 빈 `문자열` 과 `오류` 를 무조건 반환한다. 이는 다른 조건에서 템플릿 렌더링이 실패해야 한다고 결정한 시나리오에서 유용하다. ``` fail "Please accept the end user license agreement" ``` ### coalesce `coalesce` 함수는 값 목록을 가져와 비어 있지 않은 첫 번째 값을 반환한다. ``` coalesce 0 1 2 ``` 위의 경우 `1` 을 반환한다. 이 함수는 여러 변수 또는 값을 스캔하는데 유용하다. ``` coalesce .name .parent.name "Matt" ``` 위 코드는 먼저 `.name` 이 비어 있는지 확인한다. 그렇지 않은 경우 해당 값을 반환한다. 비어있는 경우 `coalesce` 는 `.parent.name` 이 비어 있는지 평가한다. 마지막으로 `.name` 과 `.parent.name` 이 모두 비어 있으면 `Matt` 를 반환한다. ### ternary `삼항(ternary)` 함수는 두 개의 값과 테스트 값을 취한다. 테스트 값이 참이면 첫 번째 값이 반환된다. 테스트 값이 비어 있으면 두 번째 값이 반환된다. 이것은 C 언어의 삼항 연산자와 유사하다. #### true 테스트 값 ``` ternary "foo" "bar" true ``` 또는 ``` true | ternary "foo" "bar" ``` 위의 결과는 `"foo"` 를 반환한다. #### false 테스트 값 ``` ternary "foo" "bar" false ``` 또는 ``` false | ternary "foo" "bar" ``` 위의 결과는 `"bar"` 를 반환한다. ## 문자열 함수 헬름은 다음과 같은 문자열 함수들을 포함한다. [abbrev](#abbrev),[abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-및-hassuffix), [hasSuffix](#hasprefix-및-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-및-squote), [randAlpha](#randalphanum-randalpha-randnumeric-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-randascii), [randAscii](#randalphanum-randalpha-randnumeric-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-및-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), [wrapWith](#wrapwith). ### print 일부의 조합에서 문자열을 반환한다. ``` print "Matt has " .Dogs " dogs" ``` 문자열이 아닌 유형은 가능한 경우 문자열로 변환된다. 서로 옆에 있는 두 인수가 문자열이 아닌 경우 그 사이에 공백이 추가된다. ### println [print](#print) 와 같은 방식으로 동작하지만, 끝에 새 줄을 추가한다. ### printf 형식화 문자열과 순서대로 전달할 인수를 기반으로 문자열을 반환한다. ``` printf "%s has %d dogs." .Name .NumberDogs ``` 사용할 자리 표시자는 전달되는 인수의 유형에 따라 다르다. 여기에는 다음이 포함된다. 일반적인 목적: * `%v` 기본 형식의 값 * 사전형 출력의 경우, 더하기 플래그(%+v) 는 필드 이름을 추가 * `%%` 는 리터럴 퍼센트 기호로 값을 소비하지 않음 불리언: * `%t` 단어 true 또는 false 정수: * `%b` 2진법 * `%c` 해당 유니코드 포인트가 표현하는 문자 * `%d` 10진법 * `%o` 8진법 * `%O` 접두사 0 이 있는 8진법 * `%q` 홑따옴표로 묶인 문자는 안전하게 통과(escaped) * `%x` a-f 의 소문자를 사용하는 16진법 * `%X` A-F 의 대문자를 사용하는 16진법 * `%U` 유니코드 형식: U+1234("U+%04X"와 동일) 부동 소수점 및 복잡한 요소: * `%b` 지수가 2의 거듭제곱인, 십진수가 없는 과학적 표기법. 예를 들어, -123456p-78 * `%e` 과학적 표기법. 예: -1.234456e+78 * `%E` 과학적 표기법. 예: -1.234456E+78 * `%f` 지수가 없는 소수점. 예: 123.456 * `%F` %f 와 동일 * `%g` 지수가 클 경우 %e, 그렇지 않은 경우 %f. * `%G` 지수가 클 경우 %E, 그렇지 않은 경우 %F. * `%x` (두 지수의 10진수 거듭제곱 형태의) 16진수 표기법, 예를 들어, -0x1.23abcp+20 * `%X` 대문자 16진수 표기법. 예를 들어, -0X1.23ABCP+20 바이트의 문자열 또는 슬라이스(이러한 동사들과 동일하게 취급): * `%s` 문자열 또는 슬라이스의 해석되지 않은 바이트 * `%q` 안전하게 이스케이프된 겹따옴표 문자열 * `%x` 16진법, 소문자이며 바이트 당 2자 * `%X` 16진법, 대문자이며 바이트 당 2자 슬라이스: * `%p` 0x로 시작하는, 16 진수 표기에서의 0번째 요소의 주소 ### trim `trim` 함수는 문자열의 양쪽에서 공백을 제거한다. ``` trim " hello " ``` 위 결과는 `hello` 이다. ### trimAll 문자열의 앞뒤에서 주어진 문자를 제거한다. ``` trimAll "$" "$5.00" ``` 위 결과는 (문자열인) `5.00` 이다. ### trimPrefix 문자열에서 접두어만 제거한다. ``` trimPrefix "-" "-hello" ``` 위 결과는 `hello` 를 반환한다. ### trimSuffix 문자열에서 접미어만 제거한다. ``` trimSuffix "-" "hello-" ``` 위 결과는 `hello` 를 반환한다. ### lower 전체 문자열을 소문자로 변환한다. ``` lower "HELLO" ``` 위 결과는 `hello` 를 반환한다. ### upper 전체 문자열을 대문자로 반환한다. ``` upper "hello" ``` 위 결과는 `HELLO` 를 반환한다. ### title 제목의 형식으로 변환한다. ``` title "hello world" ``` 위 결과는 `Hello World` 반환한다. ### untitle 제목의 형식을 제거한다. `untitle "Hello World"` 는 `hello world` 를 반환한다.. ### repeat 문자열을 여러 번 반복한다. ``` repeat 3 "hello" ``` 위의 결과는 `hellohellohello` 를 반환한다. ### substr 문자열에서 부분문자열을 가져온다. 세가지 매개변수가 필요하다. - 시작 지점 (int) - 끝 지점 (int) - 원본 문자열 (string) ``` substr 0 5 "hello world" ``` 위 결과는 `hello` 를 반환한다. ### nospace 문자열에서 모든 공백을 제거한다. ``` nospace "hello w o r l d" ``` 위 결과는 `helloworld` 를 반환한다. ### trunc 문자열을 자른다. ``` trunc 5 "hello world" ``` 위 결과는 `hello` 을 반환한다. ``` trunc -5 "hello world" ``` 위 결과는 `world` 를 반환한다. ### abbrev 줄임표 (`...`) 로 문자열을 자른다. 매개변수: - 최대 길이 - 문자열 ``` abbrev 5 "hello world" ``` 위 결과는 최대 길이에 대해 너비를 계산하므로, `he...` 를 반환한다. ### abbrevboth 양쪽을 축약한다. ``` abbrevboth 5 10 "1234 5678 9123" ``` 위 결과는 `...5678...` 를 반환한다. 다음이 필요하다. - 왼쪽 오프셋 - 최대 길이 - 원본 문자열 ### initials 주어진 여러 단어에서, 각 단어의 첫 단어를 취하고 결합한다. ``` initials "First Try" ``` 위 결과는 `FT` 를 반환한다. ### randAlphaNum, randAlpha, randNumeric, randAscii 이 네 가지 함수는 암호화적으로 안전한 (```crypto/rand``` 사용) 임의의 문자열을 생성하지만 기본 문자 집합은 상이하다. - `randAlphaNum` 는 `0-9a-zA-Z` 를 사용한다 - `randAlpha` 는 `a-zA-Z` 를 사용한다 - `randNumeric` 는 `0-9` 를 사용한다 - `randAscii` 는 출력가능한 모든 ASCII 문자를 사용한다 각각은 하나의 매개 변수, 즉 문자열의 정수 길이를 취한다. ``` randNumeric 3 ``` 위 결과는 3자리 숫자로 된 임의의 문자열을 생성한다. ### wrap 주어진 열 개수로 텍스트를 래핑(wrap)한다. ``` wrap 80 $someText ``` 위 결과는 80 번째 열에서 `$someText`의 문자열을 래핑한다. ### wrapWith `wrapWith` 는 `wrap` 로 작동하지만, 래핑할 문자열을 지정할 수 있다. (`wrap` 은 `\n` 을 사용) ``` wrapWith 5 "\t" "Hello World" ``` 위는 `hello world` 를 생성한다. (여기서 공백은 ASCII 탭 문자이다.) ### contains 한 문자열이 다른 문자열 안에 포함되어 있는지 테스트한다. ``` contains "cat" "catch" ``` 위 결과는 `catch` 에 `cat` 이 포함되어 있으므로 `true` 를 반환한다. ### hasPrefix 및 hasSuffix `hasPrefix` 및 `hasSuffix` 함수는 문자열에 주어진 접두어 또는 접미어가 있는지 여부를 테스트한다. ``` hasPrefix "cat" "catch" ``` 위 결과는 `catch` 에 접두사 `cat` 이 있으므로, `true` 를 반환한다. ### quote 및 squote 이 함수는 문자열을 겹따옴표("quote") 또는 홑따옴표(`quote`)로 묶는다. ### cat `cat` 함수는 여러 문자열을 하나로 결합하고 공백으로 구분한다. ``` cat "hello" "beautiful" "world" ``` 위 결과는 `hello beautiful world` 이다. ### indent `indent` 함수는 주어진 문자열의 모든 줄을 지정된 들여쓰기 너비로 들여쓴다. 이것은 여러 줄 문자열을 정렬할 때 유용하다. ``` indent 4 $lots_of_text ``` 위 결과는 모든 텍스트 줄을 4개의 공백 문자로 들여쓴다. ### nindent `nindent` 함수는 indent 함수와 동일하지만 문자열 시작 부분에 새 줄을 추가한다. ``` nindent 4 $lots_of_text ``` 위 결과는 모든 텍스트 줄을 공백 문자 4개로 들여쓰기하고 시작 부분에 새 줄을 추가한다. ### replace 간단한 문자열 교체를 수행한다. 3가지 인수를 필요로 한다. - 대체할 문자열 - 대체될 문자열 - 원본 문자열 ``` "I Am Henry VIII" | replace " " "-" ``` 위 결과는 `I-Am-Henry-VIII` 이다. ### plural 문자열을 복수(plural)화 한다. ``` len $fish | plural "one anchovy" "many anchovies" ``` 위에서 문자열의 길이가 1이면 첫 번째 인수(`one anchovy`)가 출력된다. 그렇지 않으면 두 번째 인수(`many anchovies`)가 출력된다. 인수는 다음과 같다. - 단수 문자열 - 복수 문자열 - 길이 정수 참고: 헬름은 현재로서는 더 복잡한 복수화 규칙이 있는 언어를 지원하지 않는다. 그리고 `0` 은, 영어가 그렇게 취급하기 때문에, 복수형으로 간주 된다. (`zero anchovies`) ### snakecase camelCase에서 snake_case로 변환한다. ``` snakecase "FirstName" ``` 위 결과는 `first_name` 이다. ### camelcase snake_case에서 camelCase로 변환한다. ``` camelcase "http_server" ``` 위 결과는 `HttpServer` 이다. ### kebabcase camelCase에서 kebab-case로 변환한다. ``` kebabcase "FirstName" ``` 위 결과는 `first-name` 이다. ### swapcase 단어 기반 알고리즘을 사용하여 문자열의 대소문자를 바꾼다. 변환 알고리즘: - 대문자는 소문자로 변환한다 - 제목 형식의 문자는 소문자로 변환한다 - 공백 뒤 또는 시작시의 소문자는 제목 형식의 대소문자로 변환한다 - 기타 소문자는 대문자로 변환한다 - 화이트스페이스는 unicode.IsSpace(char)로 정의된다 ``` swapcase "This Is A.Test" ``` 위 결과는 `tHIS iS a.tEST` 이다. ### shuffle 문자열을 섞는다. ``` shuffle "hello" ``` 위 결과는 `hello` 의 문자를 무작위로 변경하여, `oelhl` 일 수도 있다. ## 형 변환 함수 헬름에서 제공하는 형 변환 함수는 다음과 같다. - `atoi`: 문자열을 정수로 변환한다. - `float64`: `float64` 로 변환한다. - `int`: 시스템 기준의 `int` 로 변환한다. - `int64`: `int64` 로 변환한다. - `toDecimal`: 유닉스 8진수를 `int64` 로 변환한다. - `toString`: 문자열로 변환한다. - `toStrings`: 목록, 슬라이스 또는 배열을 문자열 목록으로 변환한다. - `toJson` (`mustToJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를 JSON 으로 변환한다. - `toPrettyJson` (`mustToPrettyJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를 들여쓰기 된 JSON 으로 변환한다. - `toRawJson` (`mustToRawJson`): 목록, 슬라이스, 배열, 사전형 또는 객체를 HTML 문자가 이스케이프 되지 않은 JSON 으로 변환한다. `atoi` 함수는 입력이 특정 유형이어야 한다. 나머지는 모든 유형에서 대상 유형으로 변환을 시도한다. 예를 들어 `int64` 는 부동 소수점을 정수로 변환 할 수 있으며 문자열을 정수로 변환 할 수도 있다. ### toStrings 목록과 같은 컬렉션이 주어지면 문자열 슬라이스를 생성한다. ``` list 1 2 3 | toStrings ``` 위는 결과는 `1` 을 `"1"` 로, `2` 를 `"2"` 로 변환한 다음 목록으로 반환한다. ### toDecimal 주어진 유닉스 8진수 권한 값에 대하여, 10진수 값을 생성한다. ``` "0777" | toDecimal ``` 위 코드는 `0777` 을 `511` 로 변환하고 값을 int64 형태로 변환한다. ### toJson, mustToJson `toJson` 함수는 항목을 JSON 문자열로 인코딩한다. 항목을 JSON으로 변환 할 수 없는 경우 함수는 빈 문자열을 반환한다. `mustToJson` 은 항목을 JSON으로 인코딩할 수 없는 경우 오류를 반환한다. ``` toJson .Item ``` 위 결과는 `.Item` 의 JSON 문자열 표현을 반환한다. ### toPrettyJson, mustToPrettyJson `toPrettyJson` 함수는 항목을 잘 정제된(들여쓰기) JSON 문자열로 인코딩한다. ``` toPrettyJson .Item ``` 위 결과는 `.Item` 의 들여쓰기된 JSON 문자열 표현을 반환한다. ### toRawJson, mustToRawJson `toRawJson` 함수는 특정 항목을 HTML 문자가 이스케이프 되지 않은 JSON 문자열로 인코딩한다. ``` toRawJson .Item ``` 위는 `.Item` 의 이스케이프 처리되지 않은 JSON 문자열 표현을 반환합니다. ## 정규 표현식 헬름에는 다음의 정규식 함수가 표현된다: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch 입력 문자열에 정규식과 일치하는 항목이 있으면 true 를 반환한다. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` 위 결과는 `true` 이다. `regexMatch` 는 문제가 있는 경우 패닉이 발생하며, `mustRegexMatch` 는 문제가 있을 경우 템플릿 엔진에 오류를 반환한다. ### regexFindAll, mustRegexFindAll 입력 문자열에서 정규식과 일치하는 모든 항목의 슬라이스를 반환한다. 마지막 매개 변수 n은 반환할 하위 문자열의 수를 결정한다. 여기서 -1은 모든 일치 항목을 반환함을 의미한다. ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` 위 결과는 `[2 4 6 8]` 이다. `regexFindAll` 은 문제가 있으면 패닉이 발생하며 `mustRegexFindAll` 은 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### regexFind, mustRegexFind 입력 문자열에서 정규식의 첫 번째(가장 왼쪽) 일치 항목을 반환한다. ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` 위 결과는 `d1` 이다. `regexFind` 는 문제가 있으면 패닉이 발생하며 `mustRegexFind` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### regexReplaceAll, mustRegexReplaceAll 입력 문자열의 복사본을 반환하여 정규 표현식의 일치 항목을 교체 문자열로 바꾼다. 문자열 교체 내에서 $ 기호는 확장된 차트에서와 같이 해석되므로, 예를 들어 $1은 첫 번째 부분의 일치하는 텍스트를 나타낸다. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` 위 결과는 `-W-xxW-` 이다. `regexReplaceAll` 은 문제가 있는 경우 패닉이 발생하며 `mustRegexReplaceAll` 은 문제가 있는 경우 템플릿 엔진에 오류를 반환한다. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral 입력 문자열의 복사본을 반환하고 정규 표현식의 일치 항목을 대체 문자열로 변경한다. 대체 문자열은 확장(Expand)를 사용하지 않고 직접 대체된다. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` 위 결과는 `-${1}-${1}-` 이다. `regexReplaceAllLiteral` 는 문제가 있으면 패닉이 발생하며, `mustRegexReplaceAllLiteral` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### regexSplit, mustRegexSplit 입력 문자열을 식으로 구분 된 하위 문자열로 분할하고 해당 식 일치 사이의 하위 문자열 슬라이스를 반환한다. 마지막 매개 변수 `n` 은 반환 할 하위 문자열 수를 결정한다. 여기서 `-1` 은 모든 일치 항목을 반환 함을 의미한다. ``` regexSplit "z+" "pizza" -1 ``` 위 결과는 `[pi a]` 이다. `regexSplit` 은 문제가 있는 경우 패닉이 발생하며 `mustRegexSplit` 는 문제가 있는 경우 템플릿 엔진에 오류를 반환한다. ## 암호화 및 보안 함수 헬름은 몇 가지 고급 암호화 함수를 제공한다. [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [sha1sum](#sha1sum), [sha256sum](#sha256sum). ### sha1sum `sha1sum` 함수는 문자열을 수신하고 SHA1 다이제스트를 계산한다. ``` sha1sum "Hello world!" ``` ### sha256sum `sha256sum` 함수는 문자열을 수신하고 SHA256 다이제스트 값을 계산한다. ``` sha256sum "Hello world!" ``` 위 결과는 출력을 위해 안전한 "ASCII armored" 형식의 SHA256 합을 계산한다. ### adler32sum `adler32sum` 함수는 문자열을 수신하고 Adler-32 체크섬을 계산한다. ``` adler32sum "Hello world!" ``` ### htpasswd `htpasswd` 함수는 `username` 과 `password` 를 가져 와서 패스워드의 `bcrypt` 해시를 생성한다. 결과는 [아파치 HTTP 서버] (https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic)에서 기본 인증에 사용될 수 있다. ``` htpasswd "myUser" "myPassword" ``` 템플릿에 직접 암호를 저장하는 것은 안전하지 않음을 유의하자. ### derivePassword `derivePassword` 함수는 일부 공유되는 "마스터 패스워드" 제약 조건을 기반으로 특정 패스워드를 도출하는 데 사용할 수 있다. 이에 대한 알고리즘이 [잘 명세되어] (https://masterpassword.app/masterpassword-algorithm.pdf) 있다. ``` derivePassword 1 "long" "password" "user" "example.com" ``` 일부를 템플릿에 직접 저장하는 것은 안전하지 않을 수 있다는 점에 유의하자. ### genPrivateKey `genPrivateKey` 함수는 PEM 블록으로 인코딩된 새 개인키를 생성한다. 첫 번째 매개변수의 값 중 하나를 사용한다. - `ecdsa`: 타원 곡선 DSA 키 생성 (P256) - `dsa`: DSA 키 생성 (L2048N256) - `rsa`: RSA 4096 키 생성 ### buildCustomCert `buildCustomCert` 함수를 사용하면 커스텀 인증서 설정이 가능하다. 다음의 문자열 매개변수를 사용한다. - base64 인코딩된 PEM 형식의 인증서 - base64 인코딩된 PEM 형식의 개인키 다음 속성을 가진 인증서 객체를 반환한다. - `Cert`: PEM 인코딩 인증서 - `Key`: PEM 인코딩된 개인 키 예: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` 반환된 객체는 `genSignedCert` 함수에 전달되어 이 CA를 사용하여 인증서에 서명할 수 있다. ### genCA `genCA` 함수는 자체 서명된 새로운 x509 인증기관을 생성한다. 다음의 매개 변수를 사용한다. - 주체의 일반 이름 (common name. cn) - 인증서의 유효 기간 (일) 다음 속성을 가진 객체를 반환한다. - `Cert`: PEM 인코딩 인증서 - `Key`: PEM 인코딩된 개인키 예: ``` $ca := genCA "foo-ca" 365 ``` 반환 된 객체는 `genSignedCert` 함수에 전달되어 이 CA를 사용하여 인증서에 서명 할 수 있습니다. ### genSelfSignedCert `genSelfSignedCert` 함수는 자체 서명 된 새로운 x509 인증서를 생성한다. 다음의 매개 변수를 사용한다. - 주체의 일반 이름 (cn) - 선택적인 IP 목록으로 nil도 가능 - 선택적인 대체 DNS 이름으로 nil 도 가능 - 인증서 유효 기간 (일) 다음 속성을 가진 객체를 반환한다. - `Cert`: PEM 인코딩 인증서 - `Key`: PEM 인코딩된 개인키 예: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert `genSignedCert` 함수는 지정된 CA에서 서명 한 새로운 x509 인증서를 생성한다. 다음의 매개 변수를 사용한다. - 주체의 일반 이름 (cn) - 선택적인 IP 목록으로 nil도 가능 - 선택적인 대체 DNS 이름으로 nil 도 가능 - 인증서 유효 기간 (일) - CA (`genCA` 를 참조) 예: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES `encryptAES` 함수는 AES-256 CBC로 텍스트를 암호화하고 base64 인코딩된 문자열을 반환한다. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES `decryptAES` 함수는 AES-256 CBC 알고리즘으로 인코딩된 base64 문자열을 수신하고 디코딩된 텍스트를 반환한다. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## 날짜 함수 헬름에는 템플릿에서 사용할 수 있는 다음의 날짜 함수들이 포함되어 있다. [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate), [unixEpoch](#unixepoch). ### now 현재 날짜/시간으로, 다른 날짜 기능과 함께 사용한다. ### ago `ago` 함수는 time.Now에서 초 단위로 기간을 반환한다. ``` ago .CreatedAt ``` `time.Duration` String() 형식을 반환한다. ``` 2h34m7s ``` ### date `date` 함수는 날짜 형식을 지정한다. 날짜 형식을 YEAR-MONTH-DAY로 지정한다. ``` now | date "2006-01-02" ``` Go 에서의 날짜 형식은 [조금 상이하다](https://pauladamsmith.com/blog/2011/05/go_time.html). 간단히 말해서, 이것을 기준 날짜로 한다. ``` Mon Jan 2 15:04:05 MST 2006 ``` 원하는 형식으로 작성하자. 위의 경우, `2006-01-02` 와 같은 날짜이지만, 우리가 원하는 형식으로 작성되었다. ### dateInZone `date` 와 동일하지만, 시간대가 있다. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration 주어진 시간(초)을 `time.Duration` 형식으로 지정한다. 아래의 경우, 1분 35초를 반환한다. ``` duration 95 ``` ### durationRound 주어진 기간을 가장 중요한 단위로 반올림한다. 문자열과 `time.Duration` 은 기간으로 파싱되며, `time.Time` 은 경과한 기간으로 계산된다. 아래의 경우, 2h 를 반환한다. ``` durationRound "2h10m5s" ``` 이 경우는 3mo를 반환한다. ``` durationRound "2400h10m5s" ``` ### unixEpoch `time.Time` 에 대한 유닉스 시간(unix epoch)를 반환한다. ``` now | unixEpoch ``` ### dateModify, mustDateModify `dateModify` 는 날짜를 가져와서 수정한 후에, 타임 스탬프를 반환한다. 아래의 경우 현재 시간에서 1시간 30분을 뺀 시간을 반환한다. ``` now | date_modify "-1.5h" ``` 수정 형식이 잘못된 경우 `dateModify` 는 수정되지 않은 날짜를 반환한다. `mustDateModify` 는 수정 형식이 잘못된 경우 오류를 반환한다. ### htmlDate `htmlDate` 함수는 HTML 날짜 선택기 입력 필드에 삽입할 날짜 형식을 지정한다. ``` now | htmlDate ``` ### htmlDateInZone htmlDate 와 동일하지만, 시간대가 추가된다. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` 는 문자열을 날짜로 변환한다. 첫 번째 인수는 날짜 레이아웃이고 두 번째 인수는 날짜 문자열이다. 문자열을 변환할 수 없으면 0 값을 반환한다. `mustToDate` 는 문자열을 변환할 수 없는 경우 오류를 반환한다. 이는 문자열 날짜를 파이프를 사용하여 다른 형식으로 변환하려는 경우에 유용하다. 아래 예는 "2017-12-31" 을 "31/12/2017" 로 변환한다. ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## 사전 및 사전 함수 헬름은 `dict` (파이썬에서의 "dictionary"의 약자) 라는 키/값 저장소 유형을 제공한다. `dict` 는 _정렬되지 않는_ 유형이다. 딕셔너리의 키는 **문자열이어야 한다.** 그러나 값은 모든 유형, 심지어 다른 `dict` 또는 `list` 일 수도 있다. `list` 와 달리, `dict` 는 변경 불가능(immutable)하다. `set`과 `unset` 함수는 딕셔너리의 내용을 변경한다. 헬름은 딕셔너리에 대한 작업을 지원하기 위해 다음의 함수를 제공한다: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), [values](#values). ### dict ㅣ `dict` 함수를 호출하고 키/값들의 리스트를 전달함으로써 사전이 생성된다. 다음은 세 항목이 있는 사전을 만든다. ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get 주어진 맵과 그 키에 대하여, 맵으로부터 값을 가져온다. ``` get $myDict "key1" ``` 위 결과는 `"value1"` 을 반환한다. 키를 찾을 수 없는 경우 이 작업은 단순히 `""` 를 반환한다. 별도의 오류가 발생하지는 않는다. ### set `set` 을 사용하여 새 키/값 쌍을 사전에 추가한다. ``` $_ := set $myDict "name4" "value4" ``` `set` 은 (Go 템플릿 함수의 요구 사항으로) _사전을 반환함으로_ 위와 같이 `$ _` 을 이용하여 값을 관리해야 할 수도 있다. ### unset 주어진 맵과 그 키에 대하여, 맵에서 키와 값을 삭제한다. ``` $_ := unset $myDict "name4" ``` `set` 과 마찬가지로, 사전을 반환한다. 키를 찾을 수 없는 경우, 이 작업은 단순하게 반환된다. 별도의 오류는 생성되지 않는다. ### hasKey 주어진 사전에 주어진 키가 포함되어 있으면, `hasKey` 함수는 `true` 를 반환한다. ``` hasKey $myDict "name1" ``` 키를 찾을 수 없는 경우 `false` 를 반환한다. ### pluck `pluck` 함수를 사용하면 하나의 키와 여러 맵을 제공하고 모든 일치 항목의 목록을 가져올 수 있다. ``` pluck "name1" $myDict $myOtherDict ``` 위는 발견된 모든 값 (`[value1 otherValue1]`)을 포함하는 `list` 를 반환한다. 지정된 키가 맵에서 발견되지 _않으면_ 해당 맵은 목록에 항목이 없는 것이며 반환 된 목록의 길이는 `pluck` 호출의 딕셔너리 수보다 적게 된다. 만약 키가 _발견되었는데_ 그 값이 빈 값이면 해당 값이 삽입된다. 헬름 템플릿에서는 일반적으로, 사전 모음에서 첫 번째 일치하는 키를 가져오기 위해 `pluck ... | first` 와 같이 사용한다. ### merge, mustMerge 둘 이상의 사전을 하나로 병합하여 대상 사전에 우선 순위를 부여한다. ``` $newdict := merge $dest $source1 $source2 ``` 이것은 전체 병합 작업이지만 전체 복사 작업은 아니다. 병합되어 중첩된 개체는 두 딕셔너리에서 동일한 인스턴스이다. 병합과 함께 깊은 복사(deep copy)를 원하면 병합하면서 `deepCopy` 기능을 사용하자. 예를 들면 ``` deepCopy $source | merge $dest ``` `mustMerge` 는 병합에 실패한 경우 오류를 반환한다. ### mergeOverwrite, mustMergeOverwrite 둘 이상의 사전을 하나로 병합하여 **오른쪽에서 왼쪽으로** 우선 순위를 지정하여 대상 사전의 값을 효과적으로 덮어쓴다. 아래의 경우 ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` 결과는 다음과 같다. ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` 이것은 전체 병합 작업이지만 전체 복사 작업은 아니다. 병합되어 중첩된(nested) 객체는 두 딕셔너리에서 동일한 인스턴스이다. 병합과 함께 깊은 복사(deep copy)를 원하면 병합할 때 `deepCopy` 기능을 사용하자. 예를 들면, ``` deepCopy $source | mergeOverwrite $dest ``` 병합에 실패한 경우 `mustMergeOverwrite` 는 오류를 반환한다. ### keys `keys` 함수는 하나 이상의 `dict` 유형에 있는 모든 키의 `list` 를 반환한다. 딕셔너리는 _정렬되어 있지 않으므로_ 키는 예측 가능한 순서가 아니다. `sortAlpha` 로 정렬할 수 있다. ``` keys $myDict | sortAlpha ``` 여러 딕셔너리를 제공할 때 키들은 결합된다(concatenated). `sortAlpha` 와 함께 `uniq` 함수를 사용하여 정렬된 키 목록을 얻을 수 있다. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick `pick` 함수는 사전에서 주어진 키만 선택하여 새로운 `dict` 를 만든다. ``` $new := pick $myDict "name1" "name2" ``` 위 결과는 `{name1 : value1, name2 : value2}` 를 반환한다. ### omit `omit` 함수는 주어진 키와 일치하지 _않는_ 모든 키가 포함된 새로운 `dict` 를 반환한다는 점을 제외하면 `pick` 과 유사하다. ``` $new := omit $myDict "name1" "name3" ``` 위 결과는 `{name2: value2}` 를 반환한다. ### values `values` 함수는 원본 `dict` 의 모든 값이 포함된 새로운 `list` 를 반환한다는 점을 제외하면 `keys` 와 유사하다(오직 하나의 딕셔너리만 지원). ``` $vals := values $myDict ``` 위 결과는 `list [ "value1", "value2", "value 3"]` 를 반환한다. `values` 함수는 결과에 대한 순서를 보장하지 않는다. 필요시에는 `sortAlpha` 를 사용하자. ### deepCopy, mustDeepCopy `deepCopy` 및 `mustDeepCopy` 함수는 값을 가져와 값의 깊은 복사본(deep copy)을 만든다. 여기에는 딕셔너리 등 다른 구조가 포함된다. 문제가 있으면 `deepCopy` 의 경우 패닉이 발생하며, `mustDeepCopy` 는 오류가 있을 때 템플릿 시스템에 오류를 반환한다. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Dict 내부에 대한 참고 사항 `dict` 는 Go에서 `map[string] interface{}` 으로 구현된다. Go 개발자는 `map[string] interface{}` 값을 컨텍스트에 전달하여 템플릿에서 `dict` 로 사용하도록 할 수 있다. ## 인코딩 함수 헬름에는 다음과 같은 인코딩 및 디코딩 기능이 있다. - `b64enc`/`b64dec`: Base64로 인코딩 또는 디코딩 - `b32enc`/`b32dec`: Base32로 인코딩 또는 디코딩 ## 목록 및 목록 함수 헬름은 임의의 순차적 데이터 목록을 포함할 수 있는 간단한 `리스트` 형을 제공한다. 이것은 배열 또는 슬라이스와 유사하지만 목록은 변경 불가능한 데이터 유형으로 사용되도록 설계되었다. 정수의 목록을 생성해보자. ``` $myList := list 1 2 3 4 5 ``` 위 결과는 `[1 2 3 4 5]` 의 목록을 생성한다. 헬름은 다음의 함수 목록을 제공한다. [append (mustAppend)](#append-mustappend), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), [without (mustWithout)](#without-mustwithout). ### first, mustFirst 목록에서 머리부분 항목을 얻어 오려면 `first` 를 사용하자. `first $myList` 는 `1` 를 반환한다. 문제가 있으면 `first` 는 패닉이 발생하며, `mustFirst` 의 경우 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### rest, mustRest 목록의 꼬리부분(첫 번째 항목을 제외한 모든 항목)을 얻으려면 `rest` 를 사용하자. `rest $myList` 는 `[2 3 4 5]` 반환한다. 문제가 있으면 `rest` 는 패닉이 발생하며, `mustRest` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### last, mustLast 목록의 마지막 항목을 가져 오려면 `last` 를 사용하자. `last $myList` 는 `5` 를 반환한다. 이것은 목록을 뒤집은 다음 `first` 를 호출하는 것과 거의 유사하다. ### initial, mustInitial 이 함수는 마지막 요소를 _제외한_ 모든 요소를 반환함으로써 `last` 를 보완한다. `initial $myList` 는 `[1 2 3 4]` 를 반환한다. 문제가 있으면 `initial` 은 패닉이 발생하고 `mustInitial` 의 경우, 템플릿 엔진에 오류를 반환한다. ### append, mustAppend 기존 목록에 새 항목을 추가하여 새 목록을 만든다. ``` $new = append $myList 6 ``` 위의 경우 `$new` 를 `[1 2 3 4 5 6]` 로 설정한다. `$myList` 는 변경되지 않는다. 문제가 있으면 `append` 는 패닉이 발생하며 `mustAppend` 의 경우, 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### prepend, mustPrepend 요소를 목록의 맨 앞으로 밀어 새 목록을 만든다. ``` prepend $myList 0 ``` 위의 경우 `[0 1 2 3 4 5]` 가 생성된다. `$myList` 는 변경되지 않는다. 문제가 있을 경우 `prepend` 는 패닉이 발생하며 `mustPrepend` 는 문제가 있을 경우 템플릿 엔진에 오류를 반환한다. ### concat 임의의 수의 목록을 하나로 결합한다. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` 위의 경우 `[1 2 3 4 5 6 7 8]` 이 생성된다. `$myList` 는 변경되지 않는다. ### reverse, mustReverse 주어진 목록의 반전 된 요소로 새 목록을 생성한다. ``` reverse $myList ``` 위의 경우 `[5 4 3 2 1]` 목록이 반환된다. `reverse` 는 문제가 있으면 패닉이 발생하고 `mustReverse` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### uniq, mustUniq 모든 중복 항목이 제거 된 목록을 생성한다. ``` list 1 1 1 2 | uniq ``` 위의 경우 `[1 2]` 가 생성된다. 문제가 있으면 `uniq` 는 패닉이 발생하고 `mustUniq` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### without, mustWithout `without` 함수는 목록에서 항목을 필터링한다. ``` without $myList 3 ``` 위의 경우`[1 2 4 5]` 가 생성된다. without 의 경우 하나 이상의 필터를 사용할 수도 있다. ``` without $myList 1 3 5 ``` 그러면 `[2 4]` 가 생성된다. 문제가 있으면 `without` 의 경우 패닉이 발생하고 `mustWithout` 의 경우는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### has, mustHas 목록에 특정 요소가 있는지를 테스트한다. ``` has 4 $myList ``` 위의 경우 `true` 를 반환하고 `has "hello" $myList` 는 false를 반환한다. 문제가 있으면 `has` 는 패닉이 발생하고 `mustHas` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### compact, mustCompact 목록을 승인하고 값이 비어있는 항목을 제거한다. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` 는 비어 있는 항목(즉, "")이 제거된 새 목록을 반환한다. 문제가 있는 경우 `compact` 는 패닉이 발생하고 `mustCompact` 의 경우 템플릿 엔진에 오류를 반환한다. ### slice, mustSlice 목록의 일부 요소를 가져 오려면 `slice list [n] [m]` 을 사용하자. `list [n : m]` 과도 동일하다. - `slice $myList` 는 `[1 2 3 4 5]` 을 반환한다. `myList[:]` 와 동일하다. - `slice $myList 3` 는 `[4 5]` 을 반환한다. `myList[3:]` 와 동일하다. - `slice $myList 1 3` 는 `[2 3]` 을 반환한다. `myList[1:3]` 와 동일하다. - `slice $myList 0 3` 는 `[1 2 3]` 을 반환한다. `myList[:3]` 와 동일하다. 문제가 있으면 `slice` 는 패닉이 발생하며, `mustSlice` 는 문제가 있으면 템플릿 엔진에 오류를 반환한다. ### until `until` 함수는 정수 범위를 만든다. ``` until 5 ``` 위 결과로 `[0, 1, 2, 3, 4]` 목록을 생성한다. 이것은 `range $i, $e := until 5` 로 반복할 때 유용하다. ### untilStep `until` 과 마찬가지로 `untilStep` 은 지표로서의 정수 목록을 생성한다. 또한 시작 지표, 끝 지표 및 지표 증분을 정의 할 수 있다. ``` untilStep 3 6 2 ``` 위의 코드는 3으로 시작하여 6보다 크거나 같을 때까지 2를 더하여 `[3 5]` 를 생성한다. 이것은 파이썬의 `range` 함수와 유사하다. ### seq bash 셸의 `seq` 명령어와 유사하게 작동한다. * 1 개의 매개 변수 (끝) - 1과 `끝` 사이의 모든 지표 정수를 생성. * 2 개의 매개 변수 (시작, 끝) - `start` 와 `end` 사이에 1 씩 증가 또는 감소하는 모든 지표 정수를 생성. * 3 개의 매개 변수 (시작, 증분, 끝) - `start` 와 `end` 사이의 모든 지표 정수 (`step` 단위 증가 또는 감소 포함)를 생성합니다. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk 목록을 지정된 크기의 청크로 분할하려면 `chunk size list`를 사용한다. 이는 페이지 매김에 유용하다. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` 위의 경우 목록의 목록 `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`이 생성된다. ## 수학 함수 모든 수학 함수는 달리 지정하지 않는 한 `int64` 값으로 작동한다. 다음의 수학 함수를 사용할 수 있다: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), [sub](#sub). ### add 몇 개의 숫자를 더한다. 2개나 그 이상의 입력도 허용된다. ``` add 1 2 3 ``` ### add1 1만큼 증가시키려면 `add1` 을 사용하자. ### sub 빼려면 `sub` 를 사용한다. ### div `div` 로 정수 나누기를 수행한다. ### mod `mod` 로 모듈로 연산을 수행한다. ### mul `mul` 로 곱하기 연산을 수행한다. 2개 이상의 입력을 허용한다. ``` mul 1 2 3 ``` ### max 일련의 정수중 가장 큰 값을 반환한다. 아래의 경우 `3` 을 반환한다. ``` max 1 2 3 ``` ### min 일련의 정수중 가장 작 값을 반환한다. 아래의 경우 `1` 을 반환한다. ### floor 입력 값보다 작거나 같은 가장 큰 부동 소수점 값을 출력한다. `floor 123.9999` 의 경우 `123.0` 을 반환한다. ### ceil 입력 값보다 크거나 같은 가장 작은 부동 소수점 값을 출력한다. `ceil 123.001` 의 경우 `124.0` 을 반환한다. ### round 반올림하여, 주어진 소수점의 자리수를 갖는 부동 소수점 값을 반환한다. `round 123.555555 3` 의 경우 `123.556` 을 반환한다. ### len 인수의 길이를 정수로 반환한다. ``` len .Arg ``` ## 실수 수학 함수 모든 수학 함수는 `float64` 값으로 작동한다. ### addf `addf`로 숫자를 더한다. 아래의 경우 `5.5`를 반환한다. ``` addf 1.5 2 2 ``` ### add1f 1만큼 증가시키려면 `add1f`를 사용한다. ### subf 빼려면 `subf`를 사용한다. 이것은 `7.5 - 2 - 3`과 동일하며 `2.5`를 반환한다. ``` subf 7.5 2 3 ``` ### divf `divf`로 나눗셈을 수행한다. 이것은 `10 / 2 / 4`와 동일하며 `1.25`를 반환한다. ``` divf 10 2 4 ``` ### mulf `mulf`로 곱셈을 수행한다. 아래의 경우 `6`을 반환한다. ``` mulf 1.5 2 2 ``` ### maxf 일련의 실수 중 가장 큰 값을 반환한다. 아래의 경우 `3`을 반환한다. ``` maxf 1 2.5 3 ``` ### minf 일련의 실수 중 가장 작은 값을 반환한다. 아래의 경우 `1.5`를 반환한다. ``` minf 1.5 2 3 ``` ## 네트워크 함수 헬름에는 `getHostByName` 하나의 네트워크 함수가 있다. `getHostByName` 은 도메인 이름을 받고 IP 주소를 반환한다. `getHostByName "www.google.com"`은 `www.google.com`의 해당 IP 주소를 반환한다. 이 함수는 helm 명령줄에 `--enable-dns` 옵션을 전달해야 사용할 수 있다. ## 파일 경로 함수 헬름 템플릿 함수는 파일 시스템에 대한 액세스 권한을 부여하지 않지만 파일 경로 규칙을 따르는 문자열 작업을위한 함수 를 제공한다. 여기에는 [base] (# base), [clean] (# clean), [dir] (# dir), [ext] (# ext) 및 [isAbs] (# isabs)가 포함된다. ### base 경로의 마지막 요소를 반환한다. ``` base "foo/bar/baz" ``` 위 결과는 "baz" 를 반환한다. ### dir 경로의 마지막 부분을 제거하여 디렉토리를 반환한다. 따라서 `dir "foo/bar/baz"` 는 `foo/bar` 를 반환한다. ### clean 경로를 삭제한다. ``` clean "foo/bar/../baz" ``` 위 결과는 `..` 을 찾아서 `foo/baz` 를 반환한다. ### ext 파일의 확장자를 반환한다. ``` ext "foo.bar" ``` 위 결과는 `.bar` 를 반환한다. ### isAbs 파일 경로가 절대경로인지 확인하려는 경우 `isAbs` 를 사용한다. ## 리플렉션 함수 헬름은 기초적인 리플렉션 도구를 제공한다. 이는 고급 템플릿 개발자가 특정 값에 대한 기본 Go 유형 정보를 이해하는 데 도움이 된다. 헬름은 Go로 작성되었으며 강타입 언어이다. 타입 시스템은 템플릿 내에서 적용된다. Go 에는 `string`, `slice`, `int64`, `bool` 과 같은 몇 가지 기본(primitive) _유형(kind)_ 이 있다. Go 에는 개발자가 자신의 자료형을 만들 수 있는 개방형 _자료형_ 체계가 있다. 헬름은 [유형 함수](#유형-함수) 및 [타입 함수](#타입-함수)을 통해 각각에 대한 함수 집합을 제공한다. 값과 비교하기 위해 [deepEqual](#deepequal) 함수도 제공된다. ### 유형 함수 유형 함수에는 두 가지가 있다. `kindOf` 는 객체의 유형을 반환한다. ``` kindOf "hello" ``` 위는 `string` 을 반환한다. (`if` 블록과 같은) 간단한 테스트의 경우 `isKind` 함수를 사용하면 값이 특정 유형인지 확인할 수 있다. ``` kindIs "int" 123 ``` 위 결과는 `true` 를 반환한다. ### 타입 함수 타입은 다루기가 약간 더 어렵기에, 타입 함수는 총 3가지가 있다. - `typeOf` 는 값의 기본 타입을 반환한다. 예) `typeOf $foo` - `typeIs` 는 `kindIs` 와 비슷하지만, 타입에 대한 것이다. 예) `typeIs "*io.Buffer" $myVal` - `typeIsLike` 는 포인터를 역참조한다는 점을 제외하면 `typeIs` 처럼 동작한다. **참고:** 이 중 어느 것도 주어진 인터페이스를 구현하는지 여부를 테스트할 수는 없다. 그렇게 하려면 인터페이스를 미리 컴파일해야 하기 때문이다. ### deepEqual `deepEqual` 은 두 값이 ["깊은 같음"](https://golang.org/pkg/reflect/#DeepEqual)이면 true를 반환한다. 비-기본(non-primitive) 타입에서도 동작한다. (내장된 `eq`와 비교된다.) ``` deepEqual (list 1 2 3) (list 1 2 3) ``` 위 결과는 `true` 를 반환한다. ## 유의적 버전 함수 일부 버전 체계는 쉽게 구문을 분석하고 비교할 수 있다. 헬름은 [유의적 버전 2] (http://semver.org) 버전 작업을 위한 기능을 제공한다. 여기에는 [semver](#semver) 및 [semverCompare](#semvercompare)가 포함된다. 아래에서 비교를 위해 범위를 사용하는 방법에 대한 세부 정보도 찾을 수 있다. ### semver `semver` 함수는 문자열을 유의적 버전으로 구문 분석한다. ``` $version := semver "1.2.3-alpha.1+123" ``` _파서가 실패하면 템플릿 실행이 오류와 함께 중지된다._ 이 시점에서 `$version` 은 다음 속성을 가진 `Version` 객체에 대한 포인터이다. - `$version.Major` : 주 번호 (위의 `1`) - `$version.Minor` : 부 번호 (위의 `2`) - `$version.Patch` : 패치 번호 (위의 `3`) - `$version.Prerelease` : 프리 릴리스 (위의 `alpha.1`) - `$version.Metadata` : 빌드 메타 데이터 (위의 `123`) - `$version.Original` : 문자열로 된 원본 버전 또한 `Compare` 함수를 사용하여 `버전` 을 다른 `버전` 과 비교할 수 있다. ``` semver "1.4.3" | (semver "1.2.3").Compare ``` 위 결과는 `-1` 을 반환한다. 반환 값은 다음과 같다. - 주어진 유의적 버전이 `Compare` 메소드로 호출된 유의적 버전보다 큰 경우 `-1` - `Compare` 함수로 호출 된 버전이 더 큰 경우 `1`. - 동일한 버전인 경우 `0` (유의적 버전에서는 버전 비교 작업 중 `Metadata` 필드는 비교되지 않는 것에 유의하자.) ### semverCompare 보다 강력한 비교 기능은 `semverCompare` 를 통해 제공된다. 이 버전은 버전의 범위를 지원한다. - `semverCompare "1.2.3" "1.2.3"` 은 정확히 일치하는지 확인합니다. - `semverCompare "^ 1.2.0" "1.2.3"` 은 주 버전과 부 버전이 일치하는지, 두 번째 버전의 패치 번호가 첫 번째 매개 변수보다 크거나 같은지 확인한다. SemVer 함수는 Sprig 제작자의 [Masterminds semver 라이브러리] (https://github.com/Masterminds/semver)를 사용한다. ### 기본 비교 비교에는 두 가지 요소가 있다. 첫째, 비교 문자열은 공백 또는 쉼표로 구분 된 AND 비교 목록이다. 그런 다음 || (OR) 비교로 구분된다. 예를 들어 `"> = 1.2 <3.0.0 ||> = 4.2.3"` 은 1.2보다 크거나 같고 3.0.0보다 작거나 4.2.3보다 크거나 같은지를 비교한다. 기본 비교는 다음과 같다. - `=` : 같음 (연산자 없음으로 별칭 지정) - `! =` : 같지 않음 - `>` : 보다 큼 - `<` : 보다 작음 - `> =` : 보다 크거나 같음 - `<=` : 보다 작거나 같음 _참고로, 유의적 버전 사양에 따라 프리 릴리스는 해당 릴리스의 대응하는 부분의 API를 준수하지 않을 수도 있다._ ### 프리 릴리스 버전으로 작업하기 익숙하지 않은 사용자를 위해 프리-릴리스는, 안정된 릴리스 또는 일반적으로 사용 가능한 릴리스 이전의 소프트웨어 릴리스에 사용된다. 프리-릴리스의 예로는 개발, 알파, 베타 및 릴리스 후보 릴리스가 있다. 프리 릴리스는 `1.2.3-beta.1` 와 같은 버전 일 수 있고 안정된 릴리스는 `1.2.3` 이 될 수 있다. 우선 순위에 따라 프리 릴리스가 관련 릴리스보다 먼저 나온다. 이 예에서는 `1.2.3-beta.1 <1.2.3` 이다. 유의적 버전 사양에 따라 프리 릴리스는 해당 릴리스의 대응하는 부분의 API를 준수하지 않을 수도 있다. > 프리-릴리스 버전은 버전이 불안정하고 > 관련 일반 버전에 표시된대로 의도 된 호환성 요구 사항을 > 충족하지 않을 수 있음을 나타낸다. 프리-릴리스 버전을 비교하지 않고 제약 조건을 사용하는 유의적 버전의 비교는 프리-릴리스 버전을 건너 뛴다. 예를 들어 `>=1.2.3` 은 출시 목록을 볼 때 프리 릴리스를 건너 뛰고 `>=1.2.3-0` 은 프리 릴리스를 평가하고 찾는다. 비교의 예에서 `0` 이 출시 전 버전인 이유는 사양에 따라 출시 전 버전에 ASCII 영문/숫자 및 하이픈 (`.` 구분 기호 포함)만 포함할 수 있기 때문이다. 정렬은 사양에 따라 ASCII 정렬 순서로 발생한다. 가장 낮은 문자는 ASCII 정렬 순서로 `0` 이다([ASCII 테이블](http://www.asciitable.com/) 참조). ASCII 정렬 순서를 이해하는 것은 A-Z가 a-z 앞에 오기 때문에 중요하다. 즉, `>=1.2.3-BETA` 는 `1.2.3-alpha` 를 반환한다. 대소문자는 구분되지 않는다. 이것은 지정된 ASCII 정렬 순서 때문이다. ### 하이픈 범위 비교 범위를 처리하는 방법은 여러 가지가 있으며, 첫 번째 방법은 하이픈 범위이다. 다음과 같다. - `1.2 - 1.4.5` 는 `>= 1.2 <= 1.4.5` 과 동일하다. - `2.3.4 - 4.5` 는 `>= 2.3.4 <= 4.5` 과 동일하다. ### 비교에서의 와일드카드 `x` , `X` , `*` 문자는 와일드 카드 문자로 사용할 수 있다. 이것은 모든 비교 연산자에 적용된다. `=` 연산자에 사용하면 패치 수준의 비교로 돌아간다 (아래 물결표 참조). 예를 들면 - `1.2.x` 는 `>= 1.2.0, < 1.3.0` 과 동일하다. - `>= 1.2.x` 는 `>= 1.2.0` 과 동일하다. - `<= 2.x` 는 `< 3` 과 동일하다. - `*` 는 `>= 0.0.0` 과 동일하다. ### 물결표 범위 비교 (패치) 물결표 (`~`) 비교 연산자는 부 버전이 지정되면 패치 수준 범위에 사용되며 부 번호가 누락되면 주 수준이 변경된다. 예를 들면, - `~1.2.3` 는 `>= 1.2.3, < 1.3.0` 과 동일하다. - `~1` 는 `>= 1, < 2` 과 동일하다. - `~2.3` 는 `>= 2.3, < 2.4` 과 동일하다. - `~1.2.x` 는 `>= 1.2.0, < 1.3.0` 과 동일하다. - `~1.x` 는 `>= 1, < 2` 과 동일하다. ### 캐럿 범위 비교 (주) 캐럿 (`^`) 비교 연산자는 안정적인 (1.0.0) 릴리스가 발생했을 때 주요 레벨 변경을 위한 것이다. 1.0.0 릴리스 이전에는 부 버전이 API 안정성 수준으로 작동한다. API 버전을 비교할 때 주요 변경 사항이 API 중단일 때 유용하다. 예를 들면, - `^1.2.3` 는 `>= 1.2.3, < 2.0.0` 과 동일하다. - `^1.2.x` 는 `>= 1.2.0, < 2.0.0` 과 동일하다. - `^2.3` 는 `>= 2.3, < 3` 과 동일하다. - `^2.x` 는 `>= 2.0.0, < 3` 과 동일하다. - `^0.2.3` 는 `>=0.2.3 <0.3.0` 과 동일하다. - `^0.2` 는 `>=0.2.0 <0.3.0` 과 동일하다. - `^0.0.3` 는 `>=0.0.3 <0.0.4` 과 동일하다. - `^0.0` 는 `>=0.0.0 <0.1.0` 과 동일하다. - `^0` 는 `>=0.0.0 <1.0.0` 과 동일하다. ## URL 함수 헬름에는 [urlParse](#urlparse), [urlJoin](#urljoin) 및 [urlquery](#urlquery) 함수가 포함되어있어 URL 부분으로 작업 할 수 있다다. ### urlParse URL에 대한 문자열을 구문 분석하고 URL 부분으로 딕셔너리를 생성한다. ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` 위는 URL 객체를 포함하는 딕셔너리를 반환한다. ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` 이것은 Go 표준 라이브러리의 URL 패키지를 사용하여 구현된다. 자세한 내용은 https://golang.org/pkg/net/url/#URL을 확인하자. ### urlJoin (`urlParse`에서 생성된) 맵을 결합하여 URL 문자열을 생성한다. ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` 위는 다음 문자열을 반환한다. ``` http://host:80/path?query#fragment ``` ### urlquery URL의 쿼리 부분에 포함하기에 적합하도록 인수로 전달된 값의 이스케이프된 버전을 반환한다. ``` $var := urlquery "string for query" ``` ## UUID 함수 헬름은 UUID v4 범용 고유 ID를 생성할 수 있다. ``` uuidv4 ``` 위는 v4 (무작위 생성) 유형의 새 UUID를 반환한다. ## 쿠버네티스 및 차트 함수 헬름에는 [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#파일-함수), [lookup](#lookup) 등 쿠버네티스 작업을 위한 함수가 포함되어 있다. ### lookup `lookup` 은 실행중인 클러스터에서 리소스를 조회하는 데 사용된다. `helm template` 명령어와 함께 사용하면 항상 빈 응답을 반환한다. [조회 함수에 대한 문서](/chart_template_guide/functions_and_pipelines.md#lookup-함수-사용하기)에서 자세한 내용을 확인할 수 있다. ### .Capabilities.APIVersions.Has 클러스터에서 API 버전 또는 리소스를 사용할 수 있는지에 대한 여부를 반환한다. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` 더 많은 정보는 [내장 객체 문서](/chart_template_guide/builtin_objects.md)에서 확인할 수 있다. ### 파일 함수 차트 내에서 비 특수 파일을 얻을 수 있는 함수가 몇 가지 있다. 예를 들면, 애플리케이션 구성 파일에 액세스하는 것이다. 이는 [템플릿 내 파일 액세스](/chart_template_guide/accessing_files.md)에 설명되어 있다. _ 참고로, 이렇게 많은 함수들에 대한 문서화는 [Sprig](https://github.com/Masterminds/sprig)로 이루어졌다. Sprig은 Go 애플리케이션에서 사용할 수 있는 템플릿 함수 라이브러리이다._ ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: 템플릿 함수와 파이프라인 description: 템플릿에서 함수 사용하기 sidebar_position: 5 --- 지금까지 템플릿에 정보를 넣는 방법을 살펴봤다. 하지만 그 정보는 수정 없이 그대로 삽입된다. 때로는 제공된 데이터를 더 유용하게 변환하고 싶을 때가 있다. 가장 좋은 방법부터 시작해보자: `.Values` 객체의 문자열을 템플릿에 삽입할 때는 따옴표로 감싸야 한다. 템플릿 지시어에서 `quote` 함수를 호출하면 된다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` 템플릿 함수는 `functionName arg1 arg2...` 구문을 따른다. 위 코드에서 `quote .Values.favorite.drink`는 `quote` 함수를 호출하고 단일 인자를 전달한다. Helm에는 60개 이상의 함수가 있다. 일부는 [Go 템플릿 언어](https://godoc.org/text/template) 자체에서 정의된 것이고, 대부분은 [Sprig 템플릿 라이브러리](https://masterminds.github.io/sprig/)의 일부다. 예제를 진행하면서 많은 함수들을 살펴볼 것이다. > "Helm 템플릿 언어"를 Helm에서만 사용하는 것처럼 말하지만, 실제로는 Go 템플릿 언어와 몇 가지 추가 함수, 그리고 특정 객체를 템플릿에 노출하기 위한 다양한 래퍼의 조합이다. Go 템플릿에 대한 많은 자료가 템플릿 학습에 도움이 될 것이다. ## 파이프라인 템플릿 언어의 강력한 기능 중 하나는 _파이프라인_ 개념이다. UNIX의 개념을 빌려와서, 파이프라인은 일련의 템플릿 명령을 연결하여 일련의 변환을 간결하게 표현하는 도구다. 다시 말해, 파이프라인은 여러 작업을 순서대로 효율적으로 처리하는 방법이다. 위 예제를 파이프라인을 사용해 다시 작성해보자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` 이 예제에서는 `quote ARGUMENT`를 호출하는 대신 순서를 바꿨다. 파이프라인(`|`)을 사용하여 인자를 함수로 "전송"했다: `.Values.favorite.drink | quote`. 파이프라인을 사용하면 여러 함수를 연결할 수 있다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > 순서를 바꾸는 것은 템플릿에서 흔한 방식이다. `quote .val`보다 `.val | quote`를 더 자주 보게 될 것이다. 두 방식 모두 괜찮다. 위 템플릿을 평가하면 다음과 같은 결과가 나온다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 원래 `pizza`가 `"PIZZA"`로 변환된 것에 주목하자. 이렇게 인자를 파이프라인으로 전달할 때, 첫 번째 평가 결과(`.Values.favorite.drink`)는 _함수의 마지막 인자_로 전달된다. 두 개의 인자를 받는 함수를 사용하여 drink 예제를 수정해보자: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` `repeat` 함수는 주어진 문자열을 지정된 횟수만큼 반복 출력하므로, 다음과 같은 결과가 나온다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## `default` 함수 사용하기 템플릿에서 자주 사용되는 함수 중 하나는 `default` 함수다: `default DEFAULT_VALUE GIVEN_VALUE`. 이 함수는 값이 생략된 경우 템플릿 내에서 기본값을 지정할 수 있게 해준다. 위 drink 예제를 수정해보자: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` 정상적으로 실행하면 `coffee`가 출력된다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 이제 `values.yaml`에서 favorite drink 설정을 제거해보자: ```yaml favorite: #drink: coffee food: pizza ``` 이제 `helm install --dry-run --debug fair-worm ./mychart`를 다시 실행하면 다음 YAML이 생성된다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` 실제 차트에서는 모든 정적 기본값이 `values.yaml`에 있어야 하며, `default` 명령으로 반복해서는 안 된다(그렇지 않으면 중복이 된다). 하지만 `default` 명령은 `values.yaml` 내에 선언할 수 없는 계산된 값에 적합하다. 예를 들어: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` 어떤 곳에서는 `default`보다 `if` 조건문이 더 적합할 수 있다. 다음 섹션에서 이를 살펴볼 것이다. 템플릿 함수와 파이프라인은 정보를 변환한 다음 YAML에 삽입하는 강력한 방법이다. 하지만 때로는 단순히 문자열을 삽입하는 것보다 더 복잡한 템플릿 로직이 필요할 때가 있다. 다음 섹션에서는 템플릿 언어가 제공하는 제어 구조를 살펴볼 것이다. ## `lookup` 함수 사용하기 `lookup` 함수를 사용하면 실행 중인 클러스터에서 리소스를 조회할 수 있다. lookup 함수의 구문은 `lookup apiVersion, kind, namespace, name -> resource or resource list`이다. | 파라미터 | 자료형 | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | `name`과 `namespace`는 선택사항이며 빈 문자열(`""`)로 전달할 수 있다. 하지만 namespace 범위의 리소스를 다룰 때는 `name`과 `namespace`를 모두 지정해야 한다. 다음과 같은 파라미터 조합이 가능하다: | 동작 | lookup 함수 | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | `lookup`이 객체를 반환하면 딕셔너리를 반환한다. 이 딕셔너리를 탐색하여 특정 값을 추출할 수 있다. 다음 예제는 `mynamespace` 객체에 있는 어노테이션을 반환한다: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` `lookup`이 객체 목록을 반환하면 `items` 필드를 통해 객체 목록에 접근할 수 있다: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` 객체를 찾지 못하면 빈 값이 반환된다. 이를 사용하여 객체의 존재 여부를 확인할 수 있다. `lookup` 함수는 Helm의 기존 Kubernetes 연결 설정을 사용하여 Kubernetes에 쿼리한다. API 서버와 상호 작용할 때 오류가 반환되면(예: 리소스 접근 권한이 없는 경우) Helm의 템플릿 처리가 실패한다. `helm template|install|upgrade|delete|rollback --dry-run` 작업 중에는 Helm이 Kubernetes API 서버에 접속하지 않아야 한다는 점을 기억하자. 실행 중인 클러스터에서 `lookup`을 테스트하려면 `helm template|install|upgrade|delete|rollback --dry-run=server`를 사용하여 클러스터 연결을 허용해야 한다. ## 연산자는 함수이다 템플릿에서 연산자(`eq`, `ne`, `lt`, `gt`, `and`, `or` 등)는 모두 함수로 구현되어 있다. 파이프라인에서 연산은 괄호(`(`, `)`)로 그룹화할 수 있다. 이제 함수와 파이프라인에서 조건문, 반복문, 스코프 수정자를 사용한 흐름 제어로 넘어가보자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: 시작하기 description: 차트 템플릿에 관한 빠른 가이드 sidebar_position: 2 --- 이 섹션에서는 차트를 만든 다음 첫 번째 템플릿을 추가할 것이다. 우리가 여기서 만든 차트는 가이드의 나머지 부분에서 쭉 사용될 것이다. 시작하기 위해 헬름 차트를 간단히 살펴보자. ## 차트 [차트 가이드](/topics/charts.md)에 설명된 대로, 헬름 차트는 다음과 같이 구성된다: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` `templates/` 디렉토리는 템플릿 파일을 위한 것이다. 헬름이 차트를 평가할 때, `templates/` 디렉토리의 모든 파일을 템플릿 렌더링 엔진으로 전달한다. 그리고 나서 처리 결과를 모아 쿠버네티스로 보낸다. `values.yaml` 파일도 템플릿에 중요하다. 이 파일은 차트의 _기본값_ 을 포함한다. 이 값들은 `helm install` 또는 `helm upgrade` 하는 중에 사용자가 재정의할 수 있다. `Chart.yaml` 파일은 차트에 대한 설명을 포함한다. 템플릿 안에서 접근할 수 있다. `charts/` 디렉토리는 다른 차트(_하위차트_ 라고 함)를 포함 _할 수도_ 있다. 본 가이드의 뒷부분에서 템플릿 렌더링과 관련하여 이러한 기능이 어떻게 작동하는지 알아볼 것이다. ## 스타터 차트 본 가이드를 위해 `mychart` 라는 간단한 차트를 만든 다음, 차트 안에 템플릿을 만들 것이다. ```console $ helm create mychart mychart 생성 ``` ### `mychart/templates/` 훑어보기 `mychart/templates/` 를 보면 이미 몇 개의 파일이 있는 것을 알 수 있다. - `NOTES.txt` : 차트의 "도움말". 이것은 `helm install` 을 실행할 때 사용자에게 표시될 것이다. - `deployment.yaml` : 쿠버네티스 [디플로이먼트](https://kubernetes.io/ko/docs/concepts/workloads/controllers/deployment/)를 생성하기 위한 기본 매니페스트 - `service.yaml` : 디플로이먼트의 [서비스 엔드포인트](https://kubernetes.io/ko/docs/concepts/services-networking/service/)를 생성하기 위한 기본 매니페스트 - `_helpers.tpl` : 차트 전체에서 다시 사용할 수 있는 템플릿 헬퍼를 지정하는 공간 그리고 우리가 할 일은... _전부 제거하자!_ 그렇게 하면 우리는 튜토리얼의 맨 처음부터 끝까지 실행할 수 있다. 실제로 우리만의 `NOTES.txt` 와 `_helpers.tpl` 을 만들 것이다. ```console $ rm -rf mychart/templates/* ``` 프로덕션용 차트를 작성할 때는 차트의 기본 버전을 사용하는 것이 매우 유용할 수 있다. 따라서 매일 차트를 작성할 때는 차트를 삭제하는 것을 원하지 않을 수도 있다. ## 첫 번째 템플릿 우리가 만들 첫 번째 템플릿은 `ConfigMap` 이 될 것이다. 쿠버네티스에서 컨피그맵은 단순히 환경 설정 데이터를 저장하는 컨테이너일 뿐이다. 파드 같은 다른 것들은 컨피그맵의 데이터에 접근할 수 있다. 컨피그맵은 기본 리소스이기 때문에 우리에게 좋은 출발점이 된다. 먼저 `mychart/templates/configmap.yaml` 이라는 파일을 만들어 보자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** 템플릿 이름은 엄격한 명명 패턴을 따르지 않는다. 단, YAML 파일에는 접미사 `.yaml` 을, 헬퍼에는 `.tpl` 을 사용하는 것이 좋다. 위의 YAML 파일은 최소한의 필수 필드를 가진 가장 기본적인 컨피그맵이다. 이 파일은 `mychart/template/` 디렉토리에 있기 때문에 템플릿 엔진으로 전달된다. `mychart/template/` 디렉토리에 이와 같이 평범한 YAML 파일을 넣는 것은 괜찮다. 헬름이 이 템플릿을 읽으면 쿠버네티스에게 그대로 보낼 뿐이다. 이 간단한 템플릿으로 우리는 이제 설치 가능한 차트를 가지고 있다. 이렇게 설치하면 된다: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` 헬름을 사용하면 릴리스를 검색해 실제 전송된 템플릿을 볼 수 있다. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` `helm get manifest` 명령은 릴리스 이름(`full-coral`)을 가지고 서버에 업로드된 쿠버네티스 리소스를 모두 출력한다. 각 파일은 `---`로 시작하여 YAML 문서의 시작을 표시한 다음 자동으로 생성된 주석이 나타나 이 YAML 문서를 생성한 템플릿 파일을 알려준다. 여기서 이 YAML 데이터가 정확히 `configmap.yaml` 파일에 입력한 것임을 알 수 있다. 이제 릴리스를 제거해도 된다: `helm uninstall full-coral`. ### 단순한 템플릿 호출 추가하기 `name:` 을 리소스 안에 하드 코딩하는 것은 보통 좋지 못한 관행으로 간주된다. 이름은 릴리스에 고유해야 한다. 그래서 릴리스 이름을 삽입하여 이름 필드를 생성하기를 원할 수 있다. **TIP:** DNS 시스템에 대한 제한 때문에 `name:` 필드가 63자로 제한된다. 이 때문에 릴리스 이름은 53자로 제한한다. 쿠버네티스 1.3 이하에서는 단 24자(즉, 14자 이름)로 제한하였다. 이에 따라 `configmap.yaml` 을 바꾸자. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` `name:` 필드의 값에서 `{{ .Release.Name }}-configmap` 이라고 큰 변화가 일어났다. > 템플릿 지시문은 `{{` 와 `}}` 으로 감싼다. 템플릿 지시문 `{{ .Release.Name }}` 은 템플릿에 릴리스 이름을 주입한다. 템플릿으로 전달되는 값은 _네임스페이스 객체_ 로 생각할 수 있으며, 여기서 점(`.`)이 각 네임스페이스 요소를 구분한다. `Release` 앞의 점은 해당 스코프(조금 있으면 스코프에 대해 설명하겠다)의 최상위 네임스페이스부터 시작한다는 것을 나타낸다. 그래서 우리는 `.Release.Name`을 "최상위 네임스페이스에서부터 시작하여 `Release` 객체를 찾은 다음 `Name`이라는 객체를 찾아보라"로 읽을 수 있다. `Release` 객체는 헬름의 내장 객체 중 하나이며, 이후에 좀 더 심층적으로 다룰 것이다. 현재로서는 헬름 라이브러리가 릴리스에 할당한 이름을 나타내는 것이라고 말해도 손색이 없다. 이제 리소스를 설치할 때 이 템플릿 지시어를 사용한 결과를 바로 볼 수 있다. ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` 쿠버네티스 안에 컨피그맵은 이전의 `mychart-configmap` 이 아닌 `clunky-serval-configmap` 이라는 점에 주목하자. `helm get manifest clunky-serval`을 실행하여 생성된 전체 YAML을 볼 수 있다. 이때 템플릿은 가장 기본적인 것으로, `{{` 와 `}}` 에 내장된 템플릿 지시문을 가진 YAML 파일이다. 다음 단계에서는 템플릿에 대해 더 자세히 살펴보도록 하겠다. 그러나 다음 단계로 넘어가기 전에 템플릿을 더 빨리 만들 수 있는 한 가지 요령을 보자: 실제로 아무것도 설치하지 않지만 템플릿 렌더링을 테스트하고 싶다면 `helm install --debug --dry-run goodly-guppy ./mychart` 를 사용할 수 있다. 이렇게 하면 템플릿이 렌더링된다. 그러나 차트를 설치하는 대신 렌더링 된 템플릿을 반환하여 이러한 출력을 볼 수 있다: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` `--dry-run` 을 사용하면 코드를 쉽게 테스트할 수 있지만, 쿠버네티스가 당신이 만든 템플릿을 받아들일지는 확신할 수 없을 것이다. `--dry-run` 이 작동됐다는 이유로 차트가 설치될 것이라고 생각하지 않는 것이 가장 좋다. [차트 템플릿 가이드](/chart_template_guide/index.mdx)에서는 여기서 정의한 기본 차트를 가지고 헬름 템플릿 언어를 자세히 살펴본다. 그럼 내장 객체부터 시작하자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: .helmignore 파일 description: "`.helmignore` 파일은 헬름 차트에 포함시키고 싶지 않은 파일들을 지정하는 데 사용한다." sidebar_position: 12 --- `.helmignore` 파일은 헬름 차트에 포함시키고 싶지 않은 파일들을 지정하는 데 사용한다. 이 파일이 있으면, `helm package` 명령어는 애플리케이션을 패키징할 때 `.helmignore`에서 지정한 패턴에 매칭되는 모든 파일들을 무시할 것이다. 이를 통해 불필요하거나 민감한 파일 또는 디렉토리들이 헬름 차트에 추가되는 것을 막을 수 있다. `.helmignore` 파일은 유닉스 쉘 글롭(glob) 매칭, 상대 경로 매칭, 부정(negation, 접두어 ! 사용)을 지원한다. 한 줄당 하나의 패턴만 인식된다. `.helmignore` 파일 예시는 다음과 같다. ``` # 주석 # .helmignore라는 이름의 파일 또는 경로와 매칭 .helmignore # .git이라는 이름의 파일 또는 경로와 매칭 .git # 모든 텍스트 파일과 매칭 *.txt # mydir이라는 이름의 디렉토리만 매칭 mydir/ # 최상위 디렉토리의 텍스트 파일만 매칭 /*.txt # 최상위 디렉토리의 foo.txt 파일만 매칭 /foo.txt # ab.txt, ac.txt, ad.txt 파일과 매칭 a[b-d].txt # subdir 하위의 temp*와 매칭되는 모든 파일과 매칭 */temp* */*/temp* temp? ``` .gitignore와의 주목할 만한 차이점: - '**' 구문은 지원되지 않는다. - 글로빙 라이브러리는 fnmatch(3)가 아니라 Go의 'filepath.Match'이다. - 후행 공백은 항상 무시된다 (이를 유지하는 이스케이프 시퀀스가 없다). - '\!'를 특수 선행 시퀀스로 지원하지 않는다. - 기본적으로 자기 자신을 제외하지 않으므로, `.helmignore`에 대한 명시적 항목을 추가해야 한다. 이 문서를 개선하는 데 **여러분의 도움이 필요합니다.** 정보를 추가, 수정, 삭제하려면, [이슈를 제기](https://github.com/helm/helm-www/issues)하거나 풀 리퀘스트를 보내주세요. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: 차트 템플릿 가이드 sidebar_position: 5 --- # 차트 템플릿 개발자 가이드 본 가이드는 헬름 차트 템플릿을 소개하며, 템플릿 언어를 중점적으로 다룬다. 템플릿은 쿠버네티스가 이해할 수 있는 YAML-형식 리소스 명세인 매니페스트 파일을 생성한다. 템플릿이 어떻게 구성되는지, 그것을 사용하는 방법, Go 템플릿을 작성하는 방법, 디버그 하는 방법을 살펴볼 것이다. 이 가이드는 다음 개념들을 집중적으로 설명한다. - 헬름 템플릿 언어 - 값(values) 사용 - 템플릿 작성 기법 이 가이드는 헬름 템플릿 언어를 세밀하게 알아 보는 것을 지향점으로 한다. 다른 가이드에서는 소개 자료, 예시, 모범사례를 다룰 것이다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: 네임드 템플릿 description: 네임드 템플릿을 정의하는 방법 sidebar_position: 9 --- 이제 하나의 템플릿을 넘어 여러 템플릿을 만들어 볼 차례이다. 이 섹션에서는 한 파일에서 _네임드 템플릿_을 정의하고 다른 곳에서 사용하는 방법을 알아본다. _네임드 템플릿_(때때로 _partial_ 또는 _subtemplate_이라고도 함)은 단순히 파일 내에 정의되어 이름이 부여된 템플릿이다. 템플릿을 만드는 두 가지 방법과 사용하는 여러 방법을 살펴보겠다. [흐름 제어](./control_structures.md) 섹션에서 템플릿을 선언하고 관리하기 위한 세 가지 액션 `define`, `template`, `block`을 소개했다. 이 섹션에서는 이 세 가지 액션을 다루고, `template` 액션과 유사하게 작동하는 특수 목적의 `include` 함수도 소개한다. 템플릿 이름을 지정할 때 염두에 두어야 할 중요한 사항: **템플릿 이름은 전역적이다**. 동일한 이름으로 두 개의 템플릿을 선언하면 마지막에 로드된 것이 사용된다. 서브차트의 템플릿은 최상위 템플릿과 함께 컴파일되므로 _차트별 고유 이름_으로 템플릿 이름을 지정해야 한다. 일반적인 명명 규칙은 정의된 각 템플릿 앞에 차트 이름을 접두사로 붙이는 것이다: `{{ define "mychart.labels" }}`. 특정 차트 이름을 접두사로 사용하면 동일한 이름의 템플릿을 구현하는 서로 다른 두 차트로 인해 발생할 수 있는 충돌을 피할 수 있다. 이 동작은 차트의 다른 버전에도 적용된다. 한 가지 방식으로 템플릿을 정의한 `mychart` 버전 `1.0.0`이 있고, 기존 네임드 템플릿을 수정하는 `mychart` 버전 `2.0.0`이 있다면 마지막에 로드된 것이 사용된다. 차트 이름에 버전을 추가하여 이 문제를 해결할 수 있다: `{{ define "mychart.v1.labels" }}`와 `{{ define "mychart.v2.labels" }}`. ## Partial과 `_` 파일 지금까지 하나의 파일을 사용했고, 그 파일에는 단일 템플릿이 포함되어 있었다. 하지만 Helm의 템플릿 언어를 사용하면 다른 곳에서 이름으로 접근할 수 있는 네임드 임베디드 템플릿을 만들 수 있다. 템플릿 작성의 핵심에 들어가기 전에, 언급할 가치가 있는 파일 명명 규칙이 있다: * `templates/`에 있는 대부분의 파일은 Kubernetes 매니페스트를 포함하는 것으로 취급된다 * `NOTES.txt`는 예외이다 * 그러나 이름이 밑줄(`_`)로 시작하는 파일은 내부에 매니페스트가 _없는_ 것으로 간주된다. 이 파일들은 Kubernetes 오브젝트 정의로 렌더링되지 않지만, 다른 차트 템플릿 어디서나 사용할 수 있다. 이 파일들은 partial과 helper를 저장하는 데 사용된다. 실제로 처음 `mychart`를 만들 때 `_helpers.tpl`이라는 파일을 보았다. 이 파일은 템플릿 partial의 기본 위치이다. ## `define`과 `template`으로 템플릿 선언 및 사용하기 `define` 액션을 사용하면 템플릿 파일 내에 네임드 템플릿을 만들 수 있다. 문법은 다음과 같다: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` 예를 들어, Kubernetes 레이블 블록을 캡슐화하는 템플릿을 정의할 수 있다: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` 이제 이 템플릿을 기존 ConfigMap에 포함시키고 `template` 액션으로 포함할 수 있다: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 템플릿 엔진이 이 파일을 읽으면 `template "mychart.labels"`가 호출될 때까지 `mychart.labels` 참조를 저장한다. 그런 다음 해당 템플릿을 인라인으로 렌더링한다. 결과는 다음과 같다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 참고: `define`은 이 예제처럼 template으로 호출되지 않으면 출력을 생성하지 않는다. 일반적으로 Helm 차트는 이러한 템플릿을 partial 파일, 보통 `_helpers.tpl`에 넣는다. 이 함수를 그곳으로 옮겨 보자: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` 관례상, `define` 함수에는 기능을 설명하는 간단한 문서화 블록 (`{{/* ... */}}`)이 있어야 한다. 이 정의가 `_helpers.tpl`에 있더라도 `configmap.yaml`에서 여전히 접근할 수 있다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 위에서 언급했듯이, **템플릿 이름은 전역적이다**. 결과적으로 동일한 이름으로 두 개의 템플릿이 선언되면 마지막 것이 사용된다. 서브차트의 템플릿은 최상위 템플릿과 함께 컴파일되므로 _차트별 고유 이름_으로 템플릿 이름을 지정하는 것이 좋다. 일반적인 명명 규칙은 정의된 각 템플릿 앞에 차트 이름을 접두사로 붙이는 것이다: `{{ define "mychart.labels" }}`. ## 템플릿 스코프 설정하기 위에서 정의한 템플릿에서는 어떤 오브젝트도 사용하지 않았다. 함수만 사용했다. 차트 이름과 차트 버전을 포함하도록 정의된 템플릿을 수정해 보자: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` 이것을 렌더링하면 다음과 같은 오류가 발생한다: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` 렌더링 결과를 보려면 `--disable-openapi-validation`과 함께 다시 실행한다: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. 결과는 예상한 것과 다르다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` 이름과 버전은 어떻게 되었을까? 정의된 템플릿의 스코프에 포함되지 않았다. 네임드 템플릿(`define`으로 생성된)이 렌더링될 때, `template` 호출에서 전달된 스코프를 받는다. 예제에서는 다음과 같이 템플릿을 포함했다: ```yaml {{- template "mychart.labels" }} ``` 스코프가 전달되지 않았으므로 템플릿 내에서 `.`의 어떤 것도 접근할 수 없다. 하지만 이것은 쉽게 수정할 수 있다. 템플릿에 스코프를 전달하면 된다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` `template` 호출 끝에 `.`를 전달했다. `.Values`나 `.Values.favorite` 또는 원하는 스코프를 쉽게 전달할 수 있다. 하지만 우리가 원하는 것은 최상위 스코프이다. 네임드 템플릿의 컨텍스트에서 `$`는 전역 스코프가 아니라 전달한 스코프를 참조한다. 이제 `helm install --dry-run --debug plinking-anaco ./mychart`로 이 템플릿을 실행하면 다음을 얻는다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` 이제 `{{ .Chart.Name }}`은 `mychart`로, `{{ .Chart.Version }}`은 `0.1.0`으로 해석된다. ## `include` 함수 다음과 같은 간단한 템플릿을 정의했다고 가정해 보자: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` 이제 이것을 템플릿의 `labels:` 섹션과 `data:` 섹션 모두에 삽입하고 싶다고 가정해 보자: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` 이것을 렌더링하면 다음과 같은 오류가 발생한다: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` 렌더링 결과를 보려면 `--disable-openapi-validation`과 함께 다시 실행한다: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. 출력은 예상한 것과 다르다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` `app_version`의 들여쓰기가 두 곳 모두에서 잘못되어 있다. 왜일까? 대체되는 템플릿의 텍스트가 왼쪽 정렬되어 있기 때문이다. `template`은 액션이며 함수가 아니기 때문에 `template` 호출의 출력을 다른 함수에 전달할 방법이 없다. 데이터는 단순히 인라인으로 삽입된다. 이 경우를 해결하기 위해, Helm은 `template`의 대안으로 템플릿의 내용을 현재 파이프라인으로 가져와서 파이프라인의 다른 함수에 전달할 수 있게 해주는 `include`를 제공한다. 다음은 위의 예제를 `indent`를 사용하여 `mychart.app` 템플릿을 올바르게 들여쓰기하도록 수정한 것이다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` 이제 생성된 YAML은 각 섹션에 대해 올바르게 들여쓰기된다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Helm 템플릿에서 `template`보다 `include`를 사용하는 것이 선호된다. > 단순히 YAML 문서에 대한 출력 포맷팅을 더 잘 처리할 수 있기 때문이다. 때로는 컨텐츠를 템플릿이 아닌 그대로 가져오고 싶을 때가 있다. 즉, 파일을 있는 그대로 가져오고 싶은 경우이다. 다음 섹션에서 설명하는 `.Files` 오브젝트를 통해 파일에 접근하면 이를 달성할 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: NOTES.txt 파일 작성하기 description: 차트 사용자에게 설명서를 제공하는 방법 sidebar_position: 10 --- 이 섹션에서는 차트 사용자에게 지침을 제공하는 헬름의 도구들을 살펴본다. `helm install` 이나 `helm upgrade` 가 끝나면, 헬름은 사용자에게 유용한 정보들을 출력할 수 있다. 이 정보는 템플릿을 사용하여 많은 부분을 커스터마이징할 수 있다. 차트에 설치 메모를 추가하기 위해, 간단하게 `templates/NOTES.txt` 파일을 생성한다. 이 파일은 평범한 텍스트이지만, 템플릿처럼 처리되며 모든 일반 템플릿 기능과 객체를 사용할 수 있다. 간단히 `NOTES.txt` 파일을 생성한다. ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` 이제 `helm install rude-cardinal ./mychart` 를 실행하면 하단에 이런 메세지가 표시된다. ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` 이러한 방식으로 `NOTES.txt` 를 사용하면 새로 설치된 차트를 사용하는 방법에 대한 자세한 정보를 사용자에게 제공할 수 있다. 필수는 아니지만, `NOTES.txt` 파일 생성을 강력히 추천한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: 서브차트와 글로벌 값 description: 서브차트 및 글로벌 값 사용하기 sidebar_position: 11 --- 지금까지 우리는 단일 차트만 가지고 작업해왔다. 하지만 차트는 자체적인 값과 템플릿을 가진 _서브차트_ 라고 불리는 의존성을 가질 수 있다. 이 섹션에서는 서브차트를 만들고 템플릿 내에서 값에 접근하는 다양한 방법을 살펴볼 것이다. 코드로 들어가기 전에 애플리케이션 서브차트에 대해 알아야 할 몇 가지 중요한 사항이 있다. 1. 서브차트는 "독립적"으로 간주된다. 이는 서브차트가 절대로 부모 차트에 명시적으로 의존할 수 없음을 의미한다. 2. 그런 이유로 서브차트는 부모의 값에 접근할 수 없다. 3. 부모 차트는 서브차트의 값을 오버라이드할 수 있다. 4. Helm에는 모든 차트에서 접근할 수 있는 _글로벌 값_ 이라는 개념이 있다. > 이러한 제한 사항은 표준화된 헬퍼 기능을 제공하도록 설계된 [라이브러리 차트](/topics/library_charts.md)에는 반드시 적용되지 않는다. 이 섹션의 예제를 살펴보면서 이러한 개념들이 더 명확해질 것이다. ## 서브차트 작성 이 실습에서는 가이드 시작 부분에서 만든 `mychart/` 차트를 가지고 시작하여 그 안에 새로운 차트를 추가할 것이다. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` 이전과 마찬가지로 처음부터 시작할 수 있도록 모든 기본 템플릿을 삭제했다. 이 가이드에서는 의존성 관리가 아닌 템플릿 작동 방식에 초점을 맞추고 있다. 서브차트 작동 방식에 대한 자세한 내용은 [차트 가이드](/topics/charts.md)를 참조하라. ## 서브차트에 값과 템플릿 추가하기 다음으로 `mysubchart` 차트를 위한 간단한 템플릿과 values 파일을 만들어 보자. `mychart/charts/mysubchart`에 이미 `values.yaml`이 있을 것이다. 다음과 같이 설정하자: ```yaml dessert: cake ``` 다음으로 `mychart/charts/mysubchart/templates/configmap.yaml`에 새 ConfigMap 템플릿을 만들자: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` 모든 서브차트는 _독립적인 차트_ 이기 때문에 `mysubchart`를 단독으로 테스트할 수 있다: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## 부모 차트에서 값 오버라이드하기 원래의 `mychart` 차트가 이제 `mysubchart`의 _부모_ 차트이다. 이 관계는 `mysubchart`가 `mychart/charts` 내에 있기 때문에 성립한다. `mychart`가 부모이기 때문에 `mychart`에서 구성을 지정하고 그 구성을 `mysubchart`로 전달할 수 있다. 예를 들어 `mychart/values.yaml`을 다음과 같이 수정할 수 있다: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` 마지막 두 줄에 주목하라. `mysubchart` 섹션 안의 모든 지시문은 `mysubchart` 차트로 전달된다. 따라서 `helm install --generate-name --dry-run --debug mychart`를 실행하면 `mysubchart` ConfigMap을 볼 수 있다: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` 최상위 레벨의 값이 서브차트의 값을 오버라이드한 것이다. 여기서 주목해야 할 중요한 세부 사항이 있다. `mychart/charts/mysubchart/templates/configmap.yaml`의 템플릿을 `.Values.mysubchart.dessert`를 가리키도록 변경하지 않았다. 해당 템플릿의 관점에서 값은 여전히 `.Values.dessert`에 위치한다. 템플릿 엔진이 값을 전달할 때 스코프를 설정한다. 따라서 `mysubchart` 템플릿의 경우 `mysubchart`에 특정한 값만 `.Values`에서 사용할 수 있다. 하지만 때로는 특정 값을 모든 템플릿에서 사용할 수 있도록 하고 싶을 때가 있다. 이럴 때 글로벌 차트 값을 사용하면 된다. ## 글로벌 차트 값 글로벌 값은 정확히 같은 이름으로 모든 차트나 서브차트에서 접근할 수 있는 값이다. 글로벌은 명시적 선언이 필요하다. 기존의 비글로벌 값을 글로벌인 것처럼 사용할 수는 없다. Values 데이터 타입에는 글로벌 값을 설정할 수 있는 `Values.global`이라는 예약된 섹션이 있다. `mychart/values.yaml` 파일에 하나를 설정해 보자. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` 글로벌의 작동 방식 때문에 `mychart/templates/configmap.yaml`과 `mysubchart/templates/configmap.yaml` 모두 `{{ .Values.global.salad }}`로 해당 값에 접근할 수 있어야 한다. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` 이제 dry run 설치를 실행하면 두 출력에서 같은 값을 볼 수 있다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` 글로벌은 이와 같은 정보를 전달하는 데 유용하지만, 올바른 템플릿이 글로벌을 사용하도록 구성되어 있는지 확인하기 위해 약간의 계획이 필요하다. ## 템플릿과 서브차트 공유하기 부모 차트와 서브차트는 템플릿을 공유할 수 있다. 모든 차트에서 정의된 블록은 다른 차트에서 사용할 수 있다. 예를 들어 다음과 같이 간단한 템플릿을 정의할 수 있다: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` 템플릿의 레이블이 _전역적으로 공유_ 된다는 것을 상기하라. 따라서 `labels` 차트는 다른 어떤 차트에서도 포함될 수 있다. 차트 개발자는 `include`와 `template` 중에서 선택할 수 있지만, `include`를 사용하는 한 가지 장점은 `include`가 템플릿을 동적으로 참조할 수 있다는 것이다: ```yaml {{ include $mytemplate }} ``` 위의 코드는 `$mytemplate`을 역참조한다. 반면에 `template` 함수는 문자열 리터럴만 받아들인다. ## 블록 사용 피하기 Go 템플릿 언어는 개발자가 나중에 오버라이드되는 기본 구현을 제공할 수 있게 해주는 `block` 키워드를 제공한다. Helm 차트에서는 동일한 블록의 여러 구현이 제공되면 어떤 것이 선택될지 예측할 수 없기 때문에 블록은 오버라이드하기에 최적의 도구가 아니다. 대신 `include`를 사용하는 것을 권장한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Values 파일 description: "--values 플래그 사용법 설명" sidebar_position: 4 --- 이전 섹션에서 우리는 헬름 템플릿에서 제공하는 빌트인 객체를 살펴봤다. 빌트인 객체 중 하나는 `Values`이다. 이 객체는 차트로 전달된 값에 접근할 수 있게 해준다. 이 객체의 내용들은 여러 출처에서 나온다: - 본 차트에 포함된 `values.yaml` 파일 - 서브 차트의 경우, 부모 차트의 `values.yaml` 파일 - `-f` 플래그 (`helm install -f myvals.yaml ./mychart`)가 있는 `helm install` 또는 `helm upgrade`로 전달된 `values.yaml` 파일 - `--set` (예: `helm install --set foo=bar ./mychart`)과 함께 전달된 개별 매개변수 위 목록은 적용될 값의 순서이다: 기본 값인 `values.yaml`은 부모 차트의 `values.yaml`에 의해 재정의될 수 있고, 사용자가 제공한 `values.yaml` 파일에 의해 재정의될 수 있으며, `--set` 매개변수에 의해 재정의될 수 있다. Values 파일은 일반 YAML 파일이다. `mychart/values.yaml` 파일을 편집한 후 ConfigMap 템플릿을 편집해보자. `values.yaml`의 기본값을 제거하고, 다음 하나의 매개변수만 설정하자: ```yaml favoriteDrink: coffee ``` 이제 템플릿 내부에서 다음과 같이 사용할 수 있다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` 마지막 줄에서 `Values`의 속성으로 `favoriteDrink`를 사용했다: `{{ .Values.favoriteDrink }}`. 적용된 결과를 확인해보자. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` `favoriteDrink`가 기본 `values.yaml` 파일에서 `coffee`로 설정했기 때문에, 그 값이 템플릿에 표시되었다. 우리는 `helm install` 사용 시 `--set` 플래그를 추가하여 해당 값을 쉽게 재정의할 수 있다: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` `--set` 플래그는 기본 `values.yaml` 파일보다 높은 우선순위를 가지고 있으므로, 템플릿의 값이 `drink: slurm`으로 재정의되었다. Values 파일에는 구조화된 값들을 더 추가할 수 있다. 예를 들어, `values.yaml` 파일에 `favorite` 섹션을 추가한 다음 몇 가지 키를 더 추가할 수 있다: ```yaml favorite: drink: coffee food: pizza ``` 이를 적용하기 위해 템플릿을 약간 수정해보자: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` 이런 방식으로 중첩된 값을 사용할 수 있지만, 평면화(flat)한 값을 사용하여 트리 구조를 얕게 유지하는 것을 권장한다. 서브 차트에 값을 할당할 때, 트리 구조를 사용하여 값을 지정하는 방법을 알아보자. ## 기본 키 삭제하기 기본 값에서 키를 삭제하는 경우, 삭제할 키의 값을 `null`로 지정할 수 있다. 이 경우 헬름은 재정의된 키를 제거할 것이다. 예를 들어, Drupal 차트는 사용자 정의 이미지 사용하는 경우 활성 프로브를 구성할 수 있다. 기본 값은 다음과 같다: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` 만약 활성 프로브를 `httpGet` 대신에 `exec`를 사용하여 `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`로 대체하고 싶다면, Helm은 기본 키와 재정의된 키를 함께 병합하여 다음과 같은 YAML을 생성할 것이다: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` 하지만, Kubernetes는 둘 이상의 활성 프로브 핸들러를 정의할 수 없기 때문에 실행에 실패한다. 이 문제를 해결하려면, `livenessProbe.httpGet`을 null로 설정하여 해당 키를 삭제해야 한다: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` 몇 가지의 빌트인 객체를 이용하여 템플릿에 값을 전달했다. 이제 템플릿 엔진의 함수와 파이프라인에 대해 알아보자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: 변수 description: 템플릿에서 변수 사용하기 sidebar_position: 7 --- 함수, 파이프라인, 객체, 그리고 흐름 제어 구조를 모두 살펴봤으니, 이제 많은 프로그래밍 언어에서 기본적으로 다루는 개념 중 하나인 변수에 대해 알아보겠습니다. 템플릿에서 변수는 자주 사용되지는 않지만, 코드를 단순화하고 `with` 및 `range`를 더 효과적으로 사용하는 방법을 살펴보겠습니다. 이전 예제에서 다음 코드가 실패하는 것을 확인했습니다: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name`은 `with` 블록에서 제한된 스코프 안에 포함되어 있지 않습니다. 스코프 문제를 해결하는 한 가지 방법은 현재 스코프와 관계없이 접근할 수 있는 변수에 객체를 할당하는 것입니다. Helm 템플릿에서 변수는 다른 객체에 대한 이름이 있는 참조입니다. 변수는 `$name` 형식을 따릅니다. 변수는 특별한 할당 연산자 `:=`를 사용하여 할당됩니다. 위의 예제를 `Release.Name`에 변수를 사용하도록 다시 작성해 보겠습니다. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` `with` 블록을 시작하기 전에 `$relname := .Release.Name`을 할당했습니다. 이제 `with` 블록 안에서도 `$relname` 변수는 여전히 릴리스 이름을 가리킵니다. 위 코드를 실행하면 다음과 같은 결과가 생성됩니다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` 변수는 특히 `range` 루프에서 유용합니다. 리스트 형태의 객체에서 인덱스와 값을 모두 캡처하는 데 사용할 수 있습니다: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` `range`가 먼저 오고, 그 다음 변수, 할당 연산자, 그리고 리스트 순서입니다. 이렇게 하면 정수 인덱스(0부터 시작)가 `$index`에 할당되고 값이 `$topping`에 할당됩니다. 실행하면 다음과 같이 생성됩니다: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` 키와 값이 모두 있는 데이터 구조의 경우, `range`를 사용하여 둘 다 가져올 수 있습니다. 예를 들어, `.Values.favorite`를 다음과 같이 순회할 수 있습니다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 첫 번째 반복에서 `$key`는 `drink`이고 `$val`은 `coffee`가 되며, 두 번째 반복에서 `$key`는 `food`이고 `$val`은 `pizza`가 됩니다. 위 코드를 실행하면 다음과 같이 생성됩니다: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 변수는 일반적으로 "전역"이 아닙니다. 변수는 선언된 블록 내에서만 스코프가 유효합니다. 앞서 템플릿의 최상위 레벨에서 `$relname`을 할당했습니다. 해당 변수는 전체 템플릿에서 스코프 내에 있습니다. 하지만 마지막 예제에서 `$key`와 `$val`은 `{{ range... }}{{ end }}` 블록 안에서만 스코프 내에 있습니다. 그러나 항상 루트 컨텍스트를 가리키는 특별한 변수 `$`가 있습니다. range 루프 안에서 차트의 릴리스 이름을 알아야 할 때 매우 유용합니다. 다음은 이를 보여주는 예제입니다: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` 지금까지 하나의 파일에 선언된 하나의 템플릿만 살펴봤습니다. 하지만 Helm 템플릿 언어의 강력한 기능 중 하나는 여러 템플릿을 선언하고 함께 사용할 수 있다는 것입니다. 다음 섹션에서 이에 대해 알아보겠습니다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: 다음 단계 description: 마무리 - 도움이 되는 다른 유용한 문서들 sidebar_position: 14 --- 본 가이드는 차트 개발자에게 Helm의 템플릿 언어를 사용하는 방법을 깊이 이해시키기 위한 것이다. 템플릿 개발의 기술적 관점이 중심이 된다. 그러나 이 가이드에서도 실제 차트 개발에 필요한 많은 것들을 모두 다루지는 못했다. 새로운 차트를 작성할 때 도움이 되는 다른 유용한 문서들은 다음과 같다. - CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0)는 차트를 찾는 데 없어서는 안 될 소스이다. - Kubernetes [문서](https://kubernetes.io/docs/home/)에서는 ConfigMap과 Secret부터 DaemonSet과 Deployment까지, 사용할 수 있는 다양한 리소스의 자세한 예시를 제공한다. - Helm [차트 가이드](/topics/charts.md)에서는 차트 사용 워크플로우를 설명한다. - Helm [차트 훅 가이드](/topics/charts_hooks.md)에서는 라이프사이클 훅을 만드는 방법을 설명한다. - Helm [차트 팁과 트릭](/howto/charts_tips_and_tricks.md) 문서에서는 차트 작성에 유용한 팁을 제공한다. - [Sprig 문서](https://github.com/Masterminds/sprig)에는 60개 이상의 템플릿 함수가 문서화되어 있다. - [Go 템플릿 문서](https://godoc.org/text/template)에서는 템플릿 문법을 자세히 설명한다. - [Schelm 도구](https://github.com/databus23/schelm)는 차트 디버깅에 유용한 헬퍼 유틸리티이다. 때로는 질문을 하고 경험 많은 개발자에게 답을 얻는 것이 더 쉬울 수 있다. 가장 좋은 곳은 [Kubernetes Slack](https://kubernetes.slack.com)의 Helm 채널들이다: - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) 마지막으로, 이 문서에서 오류나 누락을 찾았거나, 새로운 컨텐츠를 제안하거나 기여하고자 한다면, [Helm 프로젝트](https://github.com/helm/helm-www)를 방문하자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "부록: YAML 기법" description: YAML 명세와 그것이 Helm에 어떻게 적용되는지 자세히 알아보기 sidebar_position: 15 --- 이 가이드의 대부분은 템플릿 언어 작성에 초점을 맞추었다. 여기서는 YAML 형식을 살펴볼 것이다. YAML에는 템플릿 작성자로서 템플릿의 오류를 줄이고 가독성을 높이는 데 활용할 수 있는 유용한 기능들이 있다. ## 스칼라(scalar)와 콜렉션(collection) [YAML 명세](https://yaml.org/spec/1.2/spec.html)에 따르면, 두 가지 유형의 콜렉션과 다양한 스칼라 자료형이 있다. 두 가지 콜렉션 유형은 맵(map)과 시퀀스(sequence)이다: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` 스칼라 값은 (콜렉션과 반대되는) 개별 값이다. ### YAML에서의 스칼라 자료형 Helm의 YAML 방언에서 값의 스칼라 자료형은 Kubernetes의 리소스 정의 스키마를 포함한 복잡한 규칙 집합에 의해 결정된다. 하지만 자료형을 추론할 때 다음 규칙들이 일반적으로 적용된다. 정수나 부동 소수점이 따옴표 없는 값이면 일반적으로 숫자형으로 처리된다: ```yaml count: 1 size: 2.34 ``` 그러나 따옴표로 감싸면 문자열로 처리된다: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` 불리언도 마찬가지다: ```yaml isGood: true # bool answer: "true" # string ``` 빈 값을 나타내는 단어는 `null`이다 (`nil`이 아님). `port: "80"`은 유효한 YAML이며 템플릿 엔진과 YAML 파서를 모두 통과하지만, Kubernetes가 `port`를 정수로 기대하는 경우 실패한다는 점에 유의하자. 어떤 경우에는 YAML 노드 태그를 사용하여 특정 자료형 추론을 강제할 수 있다: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` 위 예제에서 `!!str`은 파서에게 `age`가 정수처럼 보여도 문자열이라고 알려준다. 그리고 `port`는 따옴표로 감싸져 있어도 정수로 처리된다. ## YAML에서의 문자열 YAML 문서에 넣는 데이터의 대부분은 문자열이다. YAML에는 문자열을 표현하는 여러 가지 방법이 있다. 이 섹션에서는 그 방법들을 설명하고 일부를 사용하는 방법을 보여준다. 문자열을 선언하는 세 가지 "인라인" 방식이 있다: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` 모든 인라인 스타일은 한 줄에 있어야 한다. - 따옴표 없는 값은 이스케이프되지 않는다. 따라서 어떤 문자를 사용할지 주의해야 한다. - 큰따옴표 문자열은 `\`로 특정 문자를 이스케이프할 수 있다. 예를 들어 `"\"Hello\", she said"`처럼 쓸 수 있다. `\n`으로 줄바꿈을 이스케이프할 수 있다. - 작은따옴표 문자열은 "리터럴" 문자열이며 `\`를 사용하여 문자를 이스케이프하지 않는다. 유일한 이스케이프 시퀀스는 `''`이며, 이것은 단일 `'`로 디코딩된다. 한 줄 문자열 외에도 멀티라인 문자열을 선언할 수 있다: ```yaml coffee: | Latte Cappuccino Espresso ``` 위 예제에서 `coffee`의 값은 `Latte\nCappuccino\nEspresso\n`과 동일한 단일 문자열로 처리된다. `|` 다음의 첫 번째 줄은 올바르게 들여쓰기해야 한다는 점에 유의하자. 따라서 다음과 같이 하면 위 예제가 깨질 수 있다: ```yaml coffee: | Latte Cappuccino Espresso ``` `Latte`가 잘못 들여쓰기되었기 때문에 다음과 같은 오류가 발생한다: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` 템플릿에서는 위 오류를 방지하기 위해 멀티라인 문서에 가짜 "첫 번째 줄" 내용을 넣는 것이 더 안전한 경우가 있다: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` 첫 번째 줄이 무엇이든 문자열의 출력에 그대로 유지된다는 점에 유의하자. 예를 들어 이 기법을 사용하여 파일 내용을 ConfigMap에 주입하는 경우, 주석은 해당 항목을 읽는 쪽에서 기대하는 유형이어야 한다. ### 멀티라인 문자열에서 스페이스 처리 위 예제에서 `|`를 사용하여 멀티라인 문자열을 나타냈다. 그런데 문자열 내용 뒤에 후행 `\n`이 붙는다는 점을 주목하자. YAML 프로세서가 후행 줄바꿈을 제거하게 하려면 `|` 뒤에 `-`를 추가하면 된다: ```yaml coffee: |- Latte Cappuccino Espresso ``` 이제 `coffee` 값은 `Latte\nCappuccino\nEspresso`가 된다 (후행 `\n` 없음). 반대로 모든 후행 공백을 유지하고 싶을 때도 있다. `|+` 표기법을 사용하면 된다: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` 이제 `coffee` 값은 `Latte\nCappuccino\nEspresso\n\n\n`이 된다. 텍스트 블록 내부의 들여쓰기는 그대로 유지되며, 줄바꿈도 보존된다: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` 위 경우 `coffee`는 `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`가 된다. ### 들여쓰기와 템플릿 템플릿을 작성할 때 파일 내용을 템플릿에 주입하고 싶을 수 있다. 이전 챕터에서 보았듯이 두 가지 방법이 있다: - `{{ .Files.Get "FILENAME" }}`을 사용하여 차트 내 파일의 내용을 가져온다. - `{{ include "TEMPLATE" . }}`을 사용하여 템플릿을 렌더링한 다음 그 내용을 차트에 배치한다. 파일을 YAML에 삽입할 때 위의 멀티라인 규칙을 이해하는 것이 좋다. 정적 파일을 삽입하는 가장 쉬운 방법은 보통 다음과 같다: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` 위에서 들여쓰기하는 방식에 주목하자: `indent 2`는 템플릿 엔진에게 "myfile.txt"의 모든 줄을 두 칸 들여쓰기하라고 지시한다. 해당 템플릿 줄 자체는 들여쓰기하지 않는다는 점에 유의하자. 만약 그렇게 하면 첫 번째 줄의 파일 내용이 두 번 들여쓰기되기 때문이다. ### 접힌 멀티라인 문자열 YAML에서 여러 줄로 문자열을 표현하되 해석될 때는 하나의 긴 줄로 처리되길 원할 때가 있다. 이것을 "접기(folding)"라고 한다. 접힌 블록을 선언하려면 `|` 대신 `>`를 사용한다: ```yaml coffee: > Latte Cappuccino Espresso ``` 위에서 `coffee` 값은 `Latte Cappuccino Espresso\n`이 된다. 마지막 줄바꿈을 제외한 모든 줄바꿈이 공백으로 변환된다. 공백 제어를 접힌 텍스트 마커와 결합할 수 있으므로, `>-`는 모든 줄바꿈을 대체하거나 제거한다. 접힌 구문에서 텍스트를 들여쓰기하면 줄이 그대로 보존된다는 점에 유의하자. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` 위 예제는 `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`를 생성한다. 공백과 줄바꿈이 모두 그대로 남아 있다. ## 하나의 파일에 여러 문서 넣기 단일 파일에 둘 이상의 YAML 문서를 넣을 수 있다. 새 문서 앞에 `---`를 붙이고 문서 끝에 `...`을 붙이면 된다. ```yaml --- document: 1 ... --- document: 2 ... ``` 대부분의 경우 `---`나 `...`을 생략할 수 있다. Helm의 일부 파일은 둘 이상의 문서를 포함할 수 없다. 예를 들어 `values.yaml` 파일 내에 둘 이상의 문서가 제공되면 첫 번째 문서만 사용된다. 그러나 템플릿 파일은 둘 이상의 문서를 가질 수 있다. 이 경우 파일(및 모든 문서)은 템플릿 렌더링 중에 하나의 객체로 처리된다. 그러나 결과 YAML은 Kubernetes로 전달되기 전에 여러 문서로 분할된다. 파일당 여러 문서는 절대적으로 필요한 경우에만 사용하는 것을 권장한다. 파일에 여러 문서가 있으면 디버깅이 어려울 수 있다. ## YAML은 JSON의 상위집합이다 YAML은 JSON의 상위집합이므로, 유효한 JSON 문서는 _모두_ 유효한 YAML이어야 한다. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` 위는 다음을 표현하는 또 다른 방법이다: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` 그리고 이 둘을 (주의하여) 혼합할 수 있다: ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` 세 가지 모두 동일한 내부 표현으로 파싱되어야 한다. 이것은 `values.yaml` 같은 파일이 JSON 데이터를 포함할 수 있다는 것을 의미하지만, Helm은 파일 확장자 `.json`을 유효한 접미사로 취급하지 않는다. ## YAML 앵커(anchor) YAML 명세는 값에 대한 참조를 저장하고 나중에 그 참조로 값을 참조하는 방법을 제공한다. YAML에서는 이것을 "앵커링(anchoring)"이라고 한다: ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` 위에서 `&favoriteCoffee`는 `Cappuccino`에 대한 참조를 설정한다. 나중에 해당 참조는 `*favoriteCoffee`로 사용된다. 따라서 `coffees`는 `Latte, Cappuccino, Espresso`가 된다. 앵커가 유용한 경우가 몇 가지 있지만, 미묘한 버그를 일으킬 수 있는 측면이 하나 있다: YAML이 처음 소비될 때 참조가 확장된 다음 버려진다. 따라서 위 예제를 디코딩한 다음 다시 인코딩하면 결과 YAML은 다음과 같다: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Helm과 Kubernetes는 종종 YAML 파일을 읽고, 수정하고, 다시 작성하기 때문에 앵커가 손실된다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: 헬름 2 이후의 변경사항 sidebar_position: 1 --- ## 헬름 2 이후의 변경사항 다음은 헬름 3에서 도입된 모든 주요 변경사항에 대한 전체 목록이다. ### Tiller 제거 헬름 2 개발 주기 동안 Tiller가 도입되었다. Tiller는 공유 클러스터에서 작업하는 팀에 중요한 역할을 했다 - 여러 운영자가 동일한 릴리스 세트와 상호 작용할 수 있도록 해주었다. 쿠버네티스 1.6에서 역할 기반 접근 제어(RBAC)가 기본으로 활성화되면서, 프로덕션 시나리오에서 Tiller를 잠그는 것이 관리하기 더 어려워졌다. 가능한 보안 정책의 수가 방대하기 때문에, 우리의 입장은 허용적인 기본 구성을 제공하는 것이었다. 이를 통해 처음 사용하는 사용자가 보안 제어에 먼저 뛰어들지 않고도 헬름과 쿠버네티스를 실험해 볼 수 있었다. 안타깝게도 이 허용적인 구성은 사용자에게 의도하지 않은 광범위한 권한을 부여할 수 있었다. DevOps와 SRE는 멀티테넌트 클러스터에 Tiller를 설치할 때 추가적인 운영 단계를 배워야 했다. 커뮤니티 구성원들이 특정 시나리오에서 헬름을 어떻게 사용하는지 들은 후, Tiller의 릴리스 관리 시스템이 상태를 유지하거나 헬름 릴리스 정보의 중앙 허브 역할을 하기 위해 클러스터 내 운영자에 의존할 필요가 없다는 것을 발견했다. 대신, 쿠버네티스 API 서버에서 정보를 가져오고, 클라이언트 측에서 차트를 렌더링하고, 쿠버네티스에 설치 기록을 저장하면 되었다. Tiller의 주요 목표는 Tiller 없이도 달성할 수 있었으므로, 헬름 3에 관한 첫 번째 결정 중 하나는 Tiller를 완전히 제거하는 것이었다. Tiller가 사라지면서 헬름의 보안 모델이 근본적으로 단순해졌다. 헬름 3는 이제 현대 쿠버네티스의 모든 보안, 신원 확인 및 권한 부여 기능을 지원한다. 헬름의 권한은 [kubeconfig 파일](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용하여 평가된다. 클러스터 관리자는 원하는 세분화 수준으로 사용자 권한을 제한할 수 있다. 릴리스는 여전히 클러스터 내에 기록되며, 헬름의 나머지 기능은 그대로 유지된다. ### 개선된 업그레이드 전략: 3-way 전략적 병합 패치 헬름 2는 2-way 전략적 병합 패치를 사용했다. 업그레이드 중에 가장 최근 차트의 매니페스트와 제안된 차트의 매니페스트(`helm upgrade` 중에 제공된 것)를 비교했다. 이 두 차트 간의 차이를 비교하여 쿠버네티스의 리소스에 적용해야 할 변경 사항을 결정했다. 대역 외에서 변경이 적용된 경우(예: `kubectl edit` 중에), 해당 변경 사항은 고려되지 않았다. 이로 인해 리소스가 이전 상태로 롤백할 수 없게 되었다: 헬름은 마지막으로 적용된 차트의 매니페스트만을 현재 상태로 간주했기 때문에, 차트 상태에 변경이 없으면 라이브 상태는 변경되지 않고 그대로 유지되었다. 헬름 3에서는 이제 3-way 전략적 병합 패치를 사용한다. 헬름은 패치를 생성할 때 이전 매니페스트, 라이브 상태, 새 매니페스트를 고려한다. #### 예시 이 변경 사항이 영향을 미치는 몇 가지 일반적인 예시를 살펴보자. ##### 라이브 상태가 변경된 곳에서 롤백 팀이 방금 헬름을 사용하여 쿠버네티스의 프로덕션에 애플리케이션을 배포했다. 차트에는 레플리카 수가 3으로 설정된 Deployment 객체가 포함되어 있다: ```console $ helm install myapp ./myapp ``` 새 개발자가 팀에 합류한다. 프로덕션 클러스터를 관찰하던 첫날, 끔찍한 커피-키보드-엎지름 사고가 발생하고 그들은 `kubectl scale`로 프로덕션 deployment를 3개 레플리카에서 0개로 줄인다. ```console $ kubectl scale --replicas=0 deployment/myapp ``` 팀의 다른 개발자가 프로덕션 사이트가 다운된 것을 발견하고 릴리스를 이전 상태로 롤백하기로 결정한다: ```console $ helm rollback myapp ``` 무슨 일이 일어날까? 헬름 2에서는 이전 매니페스트와 새 매니페스트를 비교하여 패치를 생성했다. 이것은 롤백이기 때문에 동일한 매니페스트이다. 헬름은 이전 매니페스트와 새 매니페스트 사이에 차이가 없기 때문에 변경할 것이 없다고 판단했다. 레플리카 수는 계속 0으로 유지된다. 큰 혼란에 빠진다. 헬름 3에서는 이전 매니페스트, 라이브 상태, 새 매니페스트를 사용하여 패치를 생성한다. 헬름은 이전 상태가 3이었고, 라이브 상태가 0이며, 새 매니페스트가 다시 3으로 변경하기를 원한다는 것을 인식하므로, 상태를 다시 3으로 변경하는 패치를 생성한다. ##### 라이브 상태가 변경된 곳에서 업그레이드 많은 서비스 메시와 다른 컨트롤러 기반 애플리케이션은 쿠버네티스 객체에 데이터를 주입한다. 이것은 사이드카, 레이블 또는 기타 정보일 수 있다. 이전에 차트에서 렌더링된 다음 매니페스트가 있었다면: ```yaml containers: - name: server image: nginx:2.0.0 ``` 그리고 라이브 상태가 다른 애플리케이션에 의해 다음과 같이 수정되었다면: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` 이제 `nginx` 이미지 태그를 `2.1.0`으로 업그레이드하려고 한다. 따라서 다음 매니페스트가 있는 차트로 업그레이드한다: ```yaml containers: - name: server image: nginx:2.1.0 ``` 무슨 일이 일어날까? 헬름 2에서 헬름은 이전 매니페스트와 새 매니페스트 사이의 `containers` 객체 패치를 생성한다. 패치 생성 중에 클러스터의 라이브 상태는 고려되지 않는다. 클러스터의 라이브 상태는 다음과 같이 수정된다: ```yaml containers: - name: server image: nginx:2.1.0 ``` 사이드카 파드가 라이브 상태에서 제거된다. 더 큰 혼란에 빠진다. 헬름 3에서 헬름은 이전 매니페스트, 라이브 상태, 새 매니페스트 사이의 `containers` 객체 패치를 생성한다. 새 매니페스트가 이미지 태그를 `2.1.0`으로 변경하지만, 라이브 상태에는 사이드카 컨테이너가 포함되어 있다는 것을 인식한다. 클러스터의 라이브 상태는 다음과 같이 수정된다: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### 릴리스 이름이 이제 네임스페이스 범위로 지정됨 Tiller가 제거되면서 각 릴리스에 대한 정보를 어딘가에 저장해야 했다. 헬름 2에서는 Tiller와 동일한 네임스페이스에 저장되었다. 실제로 이는 릴리스에서 이름이 사용되면 다른 네임스페이스에 배포되더라도 다른 릴리스가 동일한 이름을 사용할 수 없음을 의미했다. 헬름 3에서는 특정 릴리스에 대한 정보가 이제 릴리스 자체와 동일한 네임스페이스에 저장된다. 이는 사용자가 이제 두 개의 별도 네임스페이스에서 `helm install wordpress stable/wordpress`를 실행할 수 있으며, 현재 네임스페이스 컨텍스트를 변경하여 `helm list`로 각각을 참조할 수 있음을 의미한다 (예: `helm list --namespace foo`). 네이티브 클러스터 네임스페이스와의 이러한 더 큰 정렬로 인해 `helm list` 명령은 더 이상 기본적으로 모든 릴리스를 나열하지 않는다. 대신 현재 쿠버네티스 컨텍스트의 네임스페이스에 있는 릴리스만 나열한다(즉, `kubectl config view --minify`를 실행할 때 표시되는 네임스페이스). 또한 헬름 2와 유사한 동작을 얻으려면 `helm list`에 `--all-namespaces` 플래그를 제공해야 한다. ### 기본 스토리지 드라이버로 Secrets 사용 헬름 3에서는 이제 Secrets이 [기본 스토리지 드라이버](/topics/advanced.md#storage-backends)로 사용된다. 헬름 2는 기본적으로 릴리스 정보를 저장하기 위해 ConfigMaps를 사용했다. 헬름 2.7.0에서 릴리스 정보를 저장하기 위해 Secrets를 사용하는 새로운 스토리지 백엔드가 구현되었으며, 이제 헬름 3에서 기본값이 되었다. 헬름 3 기본값으로 Secrets로 변경하면 쿠버네티스의 Secret 암호화 릴리스와 함께 차트를 보호하는 추가 보안이 가능해진다. [저장 시 secrets 암호화](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)는 쿠버네티스 1.7에서 알파 기능으로 사용 가능해졌으며 쿠버네티스 1.13에서 안정화되었다. 이를 통해 사용자는 저장 시 헬름 릴리스 메타데이터를 암호화할 수 있으므로, 나중에 Vault와 같은 것을 사용하도록 확장할 수 있는 좋은 시작점이다. ### Go import 경로 변경 헬름 3에서 헬름은 Go import 경로를 `k8s.io/helm`에서 `helm.sh/helm/v3`로 전환했다. 헬름 3 Go 클라이언트 라이브러리로 업그레이드하려는 경우 import 경로를 변경해야 한다. ### Capabilities 렌더링 단계에서 사용할 수 있는 `.Capabilities` 내장 객체가 단순화되었다. [내장 객체](/chart_template_guide/builtin_objects.md) ### JSONSchema를 사용한 차트 값 검증 이제 차트 값에 JSON Schema를 적용할 수 있다. 이를 통해 사용자가 제공한 값이 차트 관리자가 설정한 스키마를 따르도록 보장하여, 사용자가 차트에 잘못된 값 세트를 제공할 때 더 나은 오류 보고를 제공한다. 검증은 다음 명령어가 호출될 때 발생한다: * `helm install` * `helm upgrade` * `helm template` * `helm lint` 자세한 정보는 [스키마 파일](/topics/charts.md#schema-files) 문서를 참조하라. ### `requirements.yaml`을 `Chart.yaml`로 통합 차트 의존성 관리 시스템이 requirements.yaml 및 requirements.lock에서 Chart.yaml 및 Chart.lock으로 이동했다. 헬름 3용 새 차트는 새 형식을 사용하는 것이 좋다. 그러나 헬름 3는 여전히 Chart API 버전 1(`v1`)을 이해하고 기존 `requirements.yaml` 파일을 로드한다. 헬름 2에서 `requirements.yaml`은 다음과 같았다: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` 헬름 3에서 의존성은 동일한 방식으로 표현되지만, 이제 `Chart.yaml`에서 표현된다: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` 차트는 여전히 `charts/` 디렉토리에 다운로드되고 배치되므로, `charts/` 디렉토리에 벤더링된 서브차트는 수정 없이 계속 작동한다. ### 설치 시 이름(또는 --generate-name) 필수 헬름 2에서는 이름이 제공되지 않으면 자동 생성된 이름이 부여되었다. 프로덕션에서 이것은 유용한 기능이라기보다는 골칫거리로 판명되었다. 헬름 3에서 `helm install`에 이름이 제공되지 않으면 헬름은 오류를 발생시킨다. 여전히 자동으로 이름이 생성되기를 원하는 사람들은 `--generate-name` 플래그를 사용하여 생성할 수 있다. ### OCI 레지스트리에 차트 푸시 이것은 헬름 3에서 도입된 실험적 기능이다. 사용하려면 환경 변수 `HELM_EXPERIMENTAL_OCI=1`을 설정한다. 높은 수준에서 차트 리포지토리는 차트를 저장하고 공유할 수 있는 장소이다. 헬름 클라이언트는 헬름 차트를 패키징하여 차트 리포지토리로 전송한다. 간단히 말해, 차트 리포지토리는 index.yaml 파일과 일부 패키지된 차트를 호스팅하는 기본 HTTP 서버이다. 차트 리포지토리 API가 가장 기본적인 스토리지 요구 사항을 충족하는 데는 여러 이점이 있지만, 몇 가지 단점이 나타나기 시작했다: - 차트 리포지토리는 프로덕션 환경에서 필요한 대부분의 보안 구현을 추상화하기가 매우 어렵다. 프로덕션 시나리오에서 인증 및 권한 부여를 위한 표준 API를 갖는 것이 매우 중요하다. - 차트의 무결성과 출처를 서명하고 확인하는 데 사용되는 헬름의 차트 출처 도구는 차트 게시 프로세스의 선택적 부분이다. - 멀티테넌트 시나리오에서 동일한 차트가 다른 테넌트에 의해 업로드될 수 있어 동일한 콘텐츠를 저장하는 데 두 배의 스토리지 비용이 든다. 이를 처리하도록 설계된 더 스마트한 차트 리포지토리가 있지만 공식 사양의 일부는 아니다. - 검색, 메타데이터 정보 및 차트 가져오기에 단일 인덱스 파일을 사용하면 안전한 멀티테넌트 구현에서 설계하기 어렵거나 투박해진다. Docker의 Distribution 프로젝트(Docker Registry v2라고도 함)는 Docker Registry 프로젝트의 후속작이다. 많은 주요 클라우드 공급업체가 Distribution 프로젝트의 제품을 제공하고 있으며, 많은 공급업체가 동일한 제품을 제공함에 따라 Distribution 프로젝트는 수년간의 강화, 보안 모범 사례 및 실전 테스트의 혜택을 받았다. 차트를 패키징하고 Docker 레지스트리에 푸시하는 방법에 대한 자세한 정보는 `helm help chart` 및 `helm help registry`를 참조하라. 자세한 정보는 [이 페이지](/topics/registries.md)를 참조하라. ### `helm serve` 제거 `helm serve`는 개발 목적으로 로컬 차트 리포지토리를 머신에서 실행했다. 그러나 개발 도구로서 많은 채택을 받지 못했고 설계에 수많은 문제가 있었다. 결국 우리는 이를 제거하고 플러그인으로 분리하기로 결정했다. `helm serve`와 유사한 경험을 위해 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)의 로컬 파일 시스템 스토리지 옵션과 [servecm 플러그인](https://github.com/jdolitsky/helm-servecm)을 살펴보라. ### 라이브러리 차트 지원 헬름 3는 "라이브러리 차트"라는 차트 클래스를 지원한다. 이것은 다른 차트에서 공유되지만 자체 릴리스 아티팩트를 생성하지 않는 차트이다. 라이브러리 차트의 템플릿은 `define` 요소만 선언할 수 있다. 전역 범위의 비-`define` 콘텐츠는 단순히 무시된다. 이를 통해 사용자는 많은 차트에서 재사용할 수 있는 코드 스니펫을 재사용하고 공유하여 중복을 피하고 차트를 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)하게 유지할 수 있다. 라이브러리 차트는 Chart.yaml의 dependencies 지시문에서 선언되며, 다른 차트와 마찬가지로 설치 및 관리된다. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` 우리는 이 기능이 차트 개발자에게 열어주는 사용 사례와 라이브러리 차트를 사용함으로써 발생하는 모범 사례를 보게 되어 매우 기쁘다. ### Chart.yaml apiVersion 증가 라이브러리 차트 지원의 도입과 requirements.yaml의 Chart.yaml로의 통합으로, 헬름 2의 패키지 형식을 이해하는 클라이언트는 이러한 새로운 기능을 이해하지 못할 것이다. 그래서 Chart.yaml의 apiVersion을 `v1`에서 `v2`로 증가시켰다. `helm create`는 이제 이 새로운 형식을 사용하여 차트를 생성하므로, 기본 apiVersion도 거기서 증가되었다. 두 버전의 헬름 차트를 모두 지원하려는 클라이언트는 패키지 형식을 구문 분석하는 방법을 이해하기 위해 Chart.yaml의 `apiVersion` 필드를 검사해야 한다. ### XDG 기본 디렉토리 지원 [XDG 기본 디렉토리 사양](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)은 구성, 데이터 및 캐시 파일이 파일 시스템에 저장되어야 하는 위치를 정의하는 이식 가능한 표준이다. 헬름 2에서 헬름은 이 모든 정보를 `~/.helm`(애칭으로 `helm home`으로 알려진)에 저장했으며, `$HELM_HOME` 환경 변수를 설정하거나 전역 플래그 `--home`을 사용하여 변경할 수 있었다. 헬름 3에서 헬름은 이제 XDG 기본 디렉토리 사양에 따라 다음 환경 변수를 존중한다: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` 헬름 플러그인은 `$HELM_HOME`을 스크래치패드 환경으로 사용하려는 플러그인과의 하위 호환성을 위해 `$XDG_DATA_HOME`의 별칭으로 여전히 `$HELM_HOME`을 전달받는다. 이 변경을 수용하기 위해 플러그인 환경에 여러 새로운 환경 변수도 전달된다: - 캐시 경로를 위한 `$HELM_PATH_CACHE` - 구성 경로를 위한 `$HELM_PATH_CONFIG` - 데이터 경로를 위한 `$HELM_PATH_DATA` 헬름 3를 지원하려는 헬름 플러그인은 이러한 새로운 환경 변수를 대신 사용하는 것을 고려해야 한다. ### CLI 명령어 이름 변경 다른 패키지 관리자의 용어와 더 잘 맞추기 위해 `helm delete`가 `helm uninstall`로 이름이 변경되었다. `helm delete`는 여전히 `helm uninstall`의 별칭으로 유지되므로 어느 형태든 사용할 수 있다. 헬름 2에서 릴리스 원장을 제거하려면 `--purge` 플래그를 제공해야 했다. 이 기능은 이제 기본적으로 활성화되어 있다. 이전 동작을 유지하려면 `helm uninstall --keep-history`를 사용하라. 추가로 동일한 규칙을 수용하기 위해 여러 다른 명령어의 이름이 변경되었다: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` 이러한 명령어들도 이전 동사를 별칭으로 유지하므로 어느 형태로든 계속 사용할 수 있다. ### 자동 네임스페이스 생성 존재하지 않는 네임스페이스에 릴리스를 생성할 때, 헬름 2는 네임스페이스를 생성했다. 헬름 3는 다른 쿠버네티스 도구의 동작을 따르며 네임스페이스가 존재하지 않으면 오류를 반환한다. `--create-namespace` 플래그를 명시적으로 지정하면 헬름 3가 네임스페이스를 생성한다. ### .Chart.ApiVersion은 어떻게 되었나? 헬름은 약어를 대문자로 표기하는 일반적인 CamelCasing 규칙을 따른다. 우리는 `.Capabilities.APIVersions.Has`와 같이 코드의 다른 곳에서도 이 작업을 수행했다. 헬름 v3에서 우리는 `.Chart.ApiVersion`을 이 패턴을 따르도록 수정하여 `.Chart.APIVersion`으로 이름을 변경했다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: 자주 묻는 질문 sidebar_position: 8 --- # 자주 묻는 질문 > 헬름 2와 헬름 3의 중요한 차이점은 무엇일까요? > 이 페이지는 가장 자주 나오는 질문들에 대한 도움말을 제공합니다. 이 문서를 개선시킬 수 있도록 **도와주시면 감사하겠습니다**. 정보를 추가, 수정, 삭제하려면 [이슈를 등록](https://github.com/helm/helm-www/issues)하거나 풀 리퀘스트를 보내주세요. ## 헬름 2 이후 변화 다음은 헬름 3에 도입된 주요 변경사항의 상세 목록입니다. ### 틸러(tiller) 제거 헬름 2 개발 주기에 틸러를 도입했었습니다. 틸러는 공유 클러스터에서 작업하는 팀에게 중요한 역할을 했습니다. 서로 다른 운영자가 동일한 릴리스 집합과 상호 작용할 수 있도록 만들어 주었습니다. 쿠버네티스 1.6에서 역할 기반 접근 제어(RBAC)가 기본적으로 활성화되면서, 운영 시나리오에서 틸러 접근제어를 관리하는 것이 더욱 어려워졌습니다. 수많은 보안 정책 때문에 우리의 입장은 허용 가능한 기본 설정을 제공하는 것이었습니다. 이를 통해 헬름을 처음 접한 사용자는 처음부터 보안 제어를 깊이 알지 못해도 헬름과 쿠버네티스를 시작해볼 수 있었습니다. 아쉽지만, 이러한 허용적(permissive) 설정은 의도치 않게 사용자에게 광범위한 권한을 부여할 수 있습니다. 데브옵스(DevOps)와 사이트 신뢰성 엔지니어(SRE)는 멀티 테넌트 클러스터에 틸러를 설치할 때 추가적인 작업 단계를 알아야 했습니다. 커뮤니티 구성원들이 특정 시나리오에서 헬름을 어떻게 사용하는지 들은 후, 틸러의 릴리스 관리 시스템은 상태를 유지하거나 헬름 릴리스 정보의 중심 허브 역할을 하기 위해 클러스터 내 운영자에게 의존할 필요가 없다는 것을 알게 되었습니다. 그 대신 쿠버네티스 API 서버에서 정보를 간단히 가져오고, 차트 클라이언트 측을 렌더링하며 쿠버네티스에 설치 기록을 보관할 수 있습니다. 틸러의 주요 목표는 틸러 없이도 달성될 수 있습니다. 그래서 헬름 3와 관련하여 우리가 내린 첫 번째 결정 중 하나는 틸러를 완전히 제거하는 것입니다. 틸러가 사라지면 헬름의 보안 모델이 획기적으로 간소화됩니다. 헬름 3는 이제 현대 쿠버네티스의 모든 현대적인 보안, 신원 확인 및 인가 기능을 지원합니다. 헬름의 권한은 [kubeconfig 파일](https://kubernetes.io/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)을 사용하여 평가됩니다. 클러스터 관리자는 세세하게 사용자 권한을 제한할 수 있습니다. 릴리스는 여전히 클러스터 내에 기록되며, 헬름의 나머지 기능은 그대로 유지됩니다. ### 업그레이드 전략 개선: 3 방향 전략적 병합 패치 헬름 2는 양방향 전략적 병합 패치를 사용했었습니다. 업그레이드할 때 최근 차트의 매니페스트와 새로 제시된 차트의 매니페스트(`helm upgrade` 중에 제공된 것 중 하나)를 비교했습니다. 쿠버네티스 리소스에 적용해야 할 변경 사항을 알아내기 위해 두 차트 간의 차이를 비교했습니다. 클러스터 외부의 활동(예: `kubectl edit` 하는) 중에 변경 사항이 적용되었다면, 그러한 변경은 고려되지 않았습니다. 이로 인해 리소스가 이전 상태로 롤백할 수 없게 되었습니다. 헬름은 마지막으로 적용된 차트의 매니페스트만 현재 상태로 간주했기 때문에 차트의 상태가 변경되지 않은 경우 활성 상태는 변경되지 않은 상태로 그대로 유지됩니다. 헬름 3는 현재 3 방향 전략적 병합 패치를 사용하고 있습니다. 헬름은 패치를 생성할 때 이전 매니페스트, 라이브 상태, 새 매니페스트를 고려합니다. #### 예시 이러한 변화가 어떤 영향을 미치는지 몇 가지 일반적인 예를 살펴보겠습니다. ##### 라이브 상태 변경 시 롤백 당신의 팀은 방금 헬름을 사용하여 쿠버네티스 프로덕션 서버에 애플리케이션을 배포했습니다. 차트에는 레플리카 수가 3개로 설정된 디플로이먼트(Deployment) 오브젝트를 포함합니다. ```console $ helm install myapp ./myapp ``` 새로운 개발자가 팀에 합류합니다. 첫날에 프로덕션 클러스터를 살펴보다가, 키보드에 커피를 쏟는 끔찍한 사고가 발생하여 `kubectl scale` 명령어로 프로덕션 디플로이먼트 레플리카 수를 3개에서 0개로 축소시킵니다. ```console $ kubectl scale --replicas=0 deployment/myapp ``` 팀의 다른 개발자는 프로덕션 사이트가 다운된 것을 확인하고 릴리스를 이전 상태로 롤백하기로 합니다. ```console $ helm rollback myapp ``` 어떻게 될까요? 헬름 2에서는 이전 매니페스트를 새 매니페스트와 비교하여 패치를 생성합니다. 이것은 롤백이기 때문에 동일한 매니페스트입니다. 헬름에서는 이전 매니페스트와 새 매니페스트 간에 차이가 없기 때문에 변경할 사항이 없다고 판단합니다. 레플리카 수는 계속 0입니다. 패닉은 계속됩니다. 헬름 3에서 패치는 이전 매니페스트, 라이브 상태, 새 매니페스트를 사용하여 생성됩니다. 헬름은 기존 상태가 3이고 라이브 상태가 0에 있으며, 새 매니페스트는 그것을 다시 3으로 바꾸기를 원하기 때문에, 패치를 생성하여 상태를 다시 3으로 바꾸게 됩니다. ##### 라이브 상태 변경 시 업그레이드 많은 서비스 메쉬 및 기타 컨트롤러 기반 애플리케이션은 데이터를 쿠버네티스 오브젝트에 주입합니다. 이것은 사이드카, 레이블 또는 다른 정보일 수 있습니다. 이전에 차트에서 렌더링된 매니페스트가 있다면 다음과 같습니다. ```yaml containers: - name: server image: nginx:2.0.0 ``` 그리고 다른 애플리케이션이 라이브 상태를 다음과 같이 수정했습니다. ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` 이제 `nginx` 이미지 태그를 `2.1.0`으로 업그레이드하려고 합니다. 따라서 다음과 같은 매니페스트가 있는 차트로 업그레이드합니다. ```yaml containers: - name: server image: nginx:2.1.0 ``` 어떻게 될까요? 헬름 2에서 헬름은 기존 매니페스트와 새로운 매니페스트 사이에 `containers` 오브젝트의 패치를 생성합니다. 패치 생성 중에는 클러스터의 라이브 상태가 고려되지 않습니다. 클러스터의 라이브 상태가 다음과 같이 수정됩니다. ```yaml containers: - name: server image: nginx:2.1.0 ``` 사이드카 파드가 라이브 상태에서 제거됩니다. 더 많은 공포가 뒤따릅니다. 헬름 3에서 헬름은 기존 매니페스트, 라이브 상태, 새 매니페스트 사이에 `container` 오브젝트의 패치를 생성합니다. 새로운 매니페스트가 이미지 태그를 `2.1.0` 으로 바꾸지만 라이브 상태는 사이드카 컨테이너를 포함합니다. 클러스터의 라이브 상태가 다음과 같이 수정됩니다. ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### 이제 릴리스 이름이 네임스페이스에 할당됩니다 틸러가 제거되면서 각 릴리스에 대한 정보는 어디론가 이동해야 했습니다. 헬름 2에서는 틸러와 동일한 네임스페이스에 저장되었습니다. 이는 실제로 릴리스에 이름이 사용되면 다른 네임스페이스에 배포되었더라도 다른 릴리스에서는 동일한 이름을 사용할 수 없음을 의미합니다. 헬름 3에서는 특정 릴리스에 대한 정보가 릴리스 자체와 동일한 네임스페이스에 저장됩니다. 즉, 이제 사용자는 별도의 두 네임스페이스에서 `helm install wordpress stable/wordpress`를 수행할 수 있으며, 현재 네임스페이스 컨텍스트를 변경하여 `helm list` 를 조회할 수 있습니다. (예: `helm list --namespace foo`) 이렇게 네이티브 클러스터 네임스페이스가 보다 개선되면서 `helm list` 명령은 기본적으로 모든 릴리스를 나열하지 않습니다. 대신 현재 쿠버네티스 컨텍스트의 네임스페이스에 있는 릴리스만 나열됩니다(즉, `kubectl config view --minify`를 실행할 때 표시되는 네임스페이스). 또한 헬름 2와 유사한 동작을 수행하려면 `helm list`에 `--all-namespaces` 플래그를 주어야 합니다. ### 기본 스토리지 드라이버로서의 시크릿(Secret) 헬름 3에서 시크릿은 이제 [기본 스토리지 드라이버](//docs/topics/advanced.md#storage-backends)로 사용됩니다. 헬름 2는 기본적으로 컨피그맵(ConfigMap)을 사용하여 릴리스 정보를 저장합니다. 헬름 2.7.0에서 릴리스 정보를 저장하기 위해 시크릿을 사용하는 새로운 스토리지 백엔드가 구현되었으며 헬름 3부터는 기본값이 되었습니다. 헬름 3 기본값을 시크릿으로 변경하면 쿠버네티스의 시크릿 암호화(Secret Encryption) 릴리스와 함께 차트를 보호할 수 있습니다. [미사용 시크릿을 암호화하는 것](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)은 쿠버네티스 1.7에서 알파 기능으로 사용 가능하게 되었고 쿠버네티스 1.13을 기점으로 안정화되었습니다. 이를 통해 사용자는 미사용 헬름 릴리스 메타데이터를 암호화할 수 있으므로 나중에 볼트(Vault)와 같은 용도로 확장할 수 있습니다. ### Go import 경로 변경 헬름 3에서 헬름은 Go import 경로를 `k8s.io/helm`에서 `helm.sh/helm/v3`으로 전환했습니다. 헬름 3 Go 클라이언트 라이브러리로 업그레이드하려면 import 경로를 변경해야 합니다. ### Capabilities 렌더링 단계에서 사용 가능한 `.Capabilities` 빌트인 객체가 간소화되었습니다. [빌트인 객체](/chart_template_guide/builtin_objects.md) ### JSON 스키마로 차트 값 유효성 검사 이제 차트 값(values)에 JSON 스키마를 적용할 수 있습니다. 이렇게 하면 사용자가 입력한 값이 차트 관리자가 제공한 스키마를 따르므로 사용자가 차트에 잘못된 값들을 입력할 때 오류 보고 기능이 향상됩니다. 다음 명령어 중 하나가 호출될 때 유효성 검사가 수행됩니다. * `helm install` * `helm upgrade` * `helm template` * `helm lint` 자세한 내용은 [스키마 파일](/topics/charts.md#schema-files) 문서를 참조하십시오. ### `requirements.yaml`이 `Chart.yaml` 로 통합 차트 의존성 관리 시스템이 requirements.yaml 와 requirements.lock에서 Chart.yaml 와 Chart.lock으로 이동했습니다. 헬름 3에서 새로운 차트는 새로운 형식을 사용하는 것이 권장됩니다. 그러나 헬름 3는 여전히 차트 API 버전 1(`v1`)을 이해하고 있으며 기존 `requirements.yaml` 파일을 로드합니다. 헬름 2에서는 `requirements.yaml`이 이렇게 생겼습니다. ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database ``` 헬름 3에서는 의존성이 동일한 방식으로 표현되지만 이제 `Chart.yaml`에서 표현됩니다. ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database ``` 차트는 여전히 `charts/` 디렉토리에 다운로드되므로 `charts/` 디렉토리에 제공된 하위 차트는 수정 없이 계속 동작합니다. ### 설치 시 이름(또는 --generate-name)이 필요합니다 헬름 2에서 이름이 주어지지 않은 경우 자동으로 생성된 이름이 지정됩니다. 프로덕션에서 이것은 유용한 기능이라기보다는 오히려 골칫거리로 판명되었습니다. 헬름 3에서 `helm install`과 함께 이름이 주어지지 않으면 헬름이 오류를 던집니다. 이름이 자동으로 생성되기를 원하는 사용자는 `--generate-name` 플래그를 사용하여 자동으로 생성할 수 있습니다. ### OCI 레지스트리로 차트 밀어내기 이것은 헬름 3에 도입된 실험적인(experimental) 기능입니다. 사용하려면 환경 변수 `HELM_EXPERIMENTAL_OCI=1`을 설정합니다. 높은 수준에서 차트 저장소는 차트를 저장하고 공유할 수 있는 곳입니다. 헬름 클라이언트는 헬름 차트를 패키징하여 차트 저장소로 보냅니다. 간단히 말해 차트 저장소는 index.yaml 파일과 일부 패키지형 차트를 저장하는 기본 HTTP 서버입니다. 차트 저장소 API가 가장 기본적인 스토리지 요구 사항을 충족하면 몇 가지 이점이 있지만 다음과 같은 몇 가지 문제점이 나타나기 시작했습니다. - 차트 저장소는 프로덕션 환경에 필요한 대부분의 보안 구현을 추상화하는 데 매우 어려움을 겪고 있습니다. 인증 및 인가를 위한 표준 API를 갖는 것은 프로덕션 시나리오에서 매우 중요합니다. - 차트의 무결성과 원본을 표시 및 검증하는 데 사용되는 헬름의 차트 출처(provenance) 도구는 차트 발행 프로세스의 선택 사항입니다. - 멀티 테넌트 시나리오에서는 다른 테넌트에서 동일한 차트를 업로드할 수 있으므로 동일한 컨텐츠를 저장하는 데 드는 스토리지 비용이 두 배가 됩니다. 보다 스마트한 차트 저장소는 이 문제를 처리하도록 설계되었지만 정식 사양에는 포함되지 않습니다. - 검색, 메타데이터 정보, 차트 가져오기에 단일 인덱스 파일을 사용하면 안전한 멀티 테넌트 구현으로 설계하기가 어렵거나 복잡해졌습니다. 도커의 분산 프로젝트(Distribution prject, 도커 레지스트리 v2라고도 함)는 도커 레지스트리 프로젝트의 후속 작업입니다. 많은 주요 클라우드 벤더가 분산 프로젝트를 제공하는 상품을 보유하고 있으며, 수많은 벤더가 동일한 제품을 제공함에 따라 분산 프로젝트는 수년간의 개선, 보안 모범 사례, 실전 테스트의 혜택을 받아 왔습니다. 차트를 패키징하고 도커 레지스트리에 밀어내는 방법에 대한 자세한 내용은 `helm help chart` 및 `helm help registry`를 참조하시기 바랍니다. 자세한 내용은 [이 페이지](/topics/registries.md)를 참조하시기 바랍니다. ### `helm serve` 제거 `helm serve`는 개발 목적으로 머신에서 로컬 차트 저장소를 실행했습니다. 하지만 개발 도구로서 그다지 많은 관심을 받지 못했고 설계에도 많은 문제가 있었습니다. 결국 우리는 이것을 제거하고 플러그인으로 분리하기로 했습니다. `helm serve`와 유사한 경험을 위해서는 [차트뮤지엄 (ChartMuseum)](https://chartmuseum.com/docs/#using-with-local-filesystem-storage)의 로컬 파일 시스템 스토리지 옵션과 [servecm 플러그인](https://github.com/jdolitsky/helm-servecm)에 대해 살펴보세요. ### 라이브러리 차트 지원 헬름 3는 "라이브러리 차트"라고 하는 차트의 클래스를 지원합니다. 다른 차트에서 공유하지만 자체 릴리스 아티팩트는 생성하지 않는 차트입니다. 라이브러리 차트의 템플릿은 `define` 요소만 선언할 수 있습니다. 전역 범위 `define`이 아닌 콘텐츠는 무시됩니다. 이를 통해 사용자는 여러 차트에서 재사용할 수 있는 코드 조작(snippet)을 재사용하고 공유할 수 있으므로 중복성을 방지하고 차트 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)를 유지할 수 있습니다. 라이브러리 차트는 Chart.yaml의 dependencies 지시어에 선언되며 다른 차트처럼 설치 및 관리됩니다. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` 이 기능이 차트 개발자에게 제공되는 유즈 케이스와 라이브러리 차트를 사용하면서 생긴 모범 사례을 보게 되어 매우 기쁩니다. ### Chart.yaml apiVersion 격상 라이브러리 차트 지원이 도입되고 requirements.yaml이 Chart.yaml로 통합됨에 따라 헬름 2의 패키지 형식을 이해하고 있는 클라이언트는 이러한 새로운 기능을 이해할 수 없게 되었습니다. 따라서 Chart.yaml의 apiVersion을 v1에서 v2로 격상했습니다. `helm create`는 이제 이 새로운 형식을 사용하여 차트를 생성하므로 기본 apiVersion도 격상했습니다. 헬름 차트의 두 버전을 모두 지원하려는 클라이언트는 패키지 형식을 해석하는 방법을 이해하기 위해 Chart.yaml의 `apiVersion` 필드를 검사하는 것이 좋습니다. ### XDG 베이스 디렉토리 지원 [XDG 베이스 디렉토리 사양](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)은 파일 시스템에 설정, 데이터, 캐시된 파일을 저장할 위치를 정의하는 이식 가능한 표준입니다. 헬름 2에서 헬름은 이 모든 정보를 `~/.helm`(정확히 `helm home`이라고 함)에 저장했으며, `$HELM_HOME` 환경 변수를 설정하여 변경하거나, 전역 플래그 `--home` 을 사용하여 변경할 수 있습니다. 헬름 3에서 헬름은 XDG 기본 디렉토리 사양에 따라 다음 환경 변수를 고려합니다. - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` 헬름 플러그인은 `$HELM_HOME`을 스크래치패드 환경으로 사용하려는 플러그인과의 하위 호환성을 위해 `$XDG_DATA_HOME`의 별칭으로 `$HELM_HOME`을 여전히 전달됩니다. 이러한 변화에 맞추기 위해 몇 가지 새로운 환경 변수도 플러그인 환경에 전달됩니다. - `$HELM_PATH_CACHE` 로 캐시 경로 지정 - `$HELM_PATH_CONFIG` 로 설정 경로 지정 - `$HELM_PATH_DATA` 로 데이터 경로 지정 헬름 3를 지원하려는 헬름 플러그인은 이 새로운 환경 변수들을 고려해야 합니다. ### CLI 명령어 이름을 변경했습니다 다른 패키지 매니저의 용어와 잘 조화시키기 위해 `helm delete`를 `helm uninstall`로 개명했습니다. `helm delete`은 여전히 `helm uninstall`의 별칭으로 유지되므로 두 형식 중 하나를 사용할 수 있습니다. 헬름 2에서는 릴리스 기록을 제거하기 위해 `--purge` 플래그를 써야 했습니다. 이제 이 기능은 기본적으로 활성화됩니다. 예전 동작을 유지하려면 `helm uninstall --keep-history`를 사용합시다. 또한 동일한 규칙을 수용하기 위해 일부 다른 명령어들이 개명되었습니다. - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` 이러한 명령어는 예전 동사도 별칭으로 유지하므로 두 가지 형식에서 계속 사용할 수 있습니다. ### 네임스페이스 자동 생성 존재하지 않는 네임스페이스에 릴리스를 생성할 때 헬름 2가 네임스페이스를 만들었습니다. 헬름 3는 다른 쿠버네티스 도구의 동작을 따르며 네임스페이스가 없는 경우 오류를 반환합니다. `--create-namespace` 플래그를 명시적으로 지정하면 헬름 3가 네임스페이스를 만듭니다. ### .Chart.ApiVersion 은 없어졌나요? 헬름은 머리글자를 대문자로 나타내는 일반적인 낙타 표기법(CamelCasing)을 따릅니다. `.Capabilities.APIVersions.Has` 와 같은 모든 코드에서 해당 표기법을 사용했습니다. 헬름 3에서는 이 패턴을 지키기 위해 `.Chart.ApiVersion` 을 `.Chart.APIVersion` 으로 변경했습니다. ## 설치 ### 페도라(Fedora) 등의 다른 리눅스 배포판을 위한 네이티브 헬름 패키지는 왜 없나요? 헬름 프로젝트는 운영 체제 및 환경에 대한 패키지를 관리하지 않습니다. 헬름 커뮤니티는 네이티브 패키지를 제공할 수 있으며 헬름 프로젝트에서 알게 되면 목록에 포함될 것입니다. 이렇게 해서 홈브루 포뮬러(HomeBrew formula)가 시작되고 포함되었습니다. 패키지 관리에 관심이 있으시다면 감사하겠습니다. ### 왜 `curl ...|bash` 스크립트를 제공하나요? 저장소에 `curl ..|bash` 스크립트로 실행할 수 있는 스크립트(`scripts/get-helm-3`)가 있습니다. 전송은 모두 HTTPS에 의해 보호되며 스크립트는 가져오는 패키지에 대해 일부 감사를 수행합니다. 그러나 이 스크립트는 쉘 스크립트의 모든 일반적인 위험을 가지고 있습니다. 유용하기 때문에 제공하지만 사용자들이 먼저 대본을 주의 깊게 읽어보는 것이 좋습니다. 우리가 정말 원하는 것은 더 나은 패키지형 헬름 릴리스입니다. ### 헬름 클라이언트 파일들을 기본값 말고 다른 곳에 두려면 어떻게 하나요? 헬름은 파일을 보관할 때 XDG 구조를 사용합니다. 그 위치를 재정의(override)할 수 있는 환경변수를 사용할 수 있습니다. - `$XDG_CACHE_HOME`: 캐시 파일 보관 장소를 다른 곳으로 설정 - `$XDG_CONFIG_HOME`: 헬름 설정 파일 보관 장소를 다른 곳으로 설정 - `$XDG_DATA_HOME`: 헬름 데이터 보관 장소를 다른 곳으로 설정 기존 저장소가 있는 경우, `helm repo add...`를 사용하여 저장소를 다시 추가해야 합니다. ## 삭제 ### 로컬 헬름을 삭제하고 싶어요. 그 파일들은 모두 어디에 있나요? 헬름은 `helm` 바이너리 파일과 함께 일부 파일을 다음 위치에 저장합니다. - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME 다음 표에서는 OS 별로 각 항목에 대한 기본 폴더를 제공합니다. | 운영 체제 | 캐시 경로 | 설정 경로 | 데이터 경로 | |------------------|-----------------------------|----------------------------------|---------------------------| | 리눅스 | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | 맥OS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | 윈도우 | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ## 트러블슈팅 ### "Unable to get an update from the "stable" chart repository"라는 경고가 표시됩니다. `helm repo list` 를 실행합니다. `storage.googleapis.com` URL을 가리키고 있는 `stable` 저장소가 표시되면 해당 저장소를 업데이트해야 합니다. 2020년 11월 13일에 헬름 차트 저장소는 일년 간의 유예기간을 거친 후 [더 이상 지원되지 않습니다](https://github.com/helm/charts#deprecation-timeline). 아카이브를 `https://charts.helm.sh/stable` 에서 사용할 수 있지만 더 이상 업데이트를 받을 수 없습니다. 다음 명령을 실행하여 저장소를 수정할 수 있습니다. ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` https://charts.helm.sh/incubator 에서 사용할 수 있는 아카이브가 있는 `incubator` 저장소도 마찬가지입니다. 다음 명령을 실행하여 고칠 수 있습니다. ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.'라는 경고가 표시됩니다. 기존의 구글 헬름 차트 저장소가 새로운 헬름 차트 저장소로 대체되었습니다. 다음 명령을 실행하여 이 문제를 해결합니다. ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator` 에 비슷한 오류가 발생한다면 다음 명령을 실행합니다. ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 헬름 저장소를 추가하면 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available'라는 오류가 표시됩니다. 헬름 차트 저장소는 [1년 동안의 유예기간](https://github.com/helm/charts#deprecation-timeline)이 지나면 더 이상 지원되지 않습니다. 해당 저장소의 아카이브는 `https://charts.helm.sh/stable` 및 `https://charts.helm.sh/incubator` 에서 사용할 수 있지만, 더 이상 업데이트되지 않습니다. `--use-deprecated-repos` 를 지정하지 않으면 `helm repo add` 명령어로 기존 저장소의 URL을 추가할 수 없습니다. ### GKE (구글 컨테이너 엔진)에서 "현재 열려 있는 SSH 터널이 없습니다"라고 나와요 ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` 오류 메시지의 또 다른 변형판은 다음과 같습니다. ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` 해당 이슈는 로컬 쿠버네티스 설정 파일에 올바른 인증서가 있어야 한다는 것입니다. GKE에 클러스터를 생성하면 SSL 인증서 및 인증 기관을 포함한 인증서가 제공됩니다. 이러한 파일은 `kubectl`과 `helm`이 접근할 수 있도록 쿠버네티스 설정 파일에 저장되어야 합니다(기본값: `~/.kube/config`). ### 헬름 2에서 마이그레이션한 후, `helm list`에는 릴리스들이 일부만 보여요(또는 안 보여요). 헬름 3는 이제 클러스터 네임스페이스를 사용하여 릴리스들을 구획한다는 사실을 깜빡하신 것 같습니다. 릴리스를 참조하는 모든 명령어는 다음 중 하나로 수행해야 합니다. * 활성 쿠버네티스 컨텍스트의 현재 네임스페이스에 의존합니다 (`kubectl config view --minify` 명령어로 확인). * `--namespace`/`-n` 플래그를 사용하여 올바른 네임스페이스를 지정합니다. * `helm list` 명령어에 대해서는 `--all-namespaces`/`-A` 플래그를 지정합니다. 이는 릴리스를 참조하는 `helm list`, `helm uninstall` 및 기타 모든 `helm` 명령어에 적용됩니다. ### 맥OS에서는 `/etc/.mdns_debug` 파일에 접근합니다. 왜 그런가요? 맥OS에서는 헬름이 `/etc/.mdns_debug`라는 파일에 접근하려고 하는 것으로 알려져 있습니다. 파일이 있는 경우, 헬름은 파일이 실행되는 동안 파일 핸들을 열어 둡니다. 이 문제는 맥OS의 MDNS 라이브러리로 인해 발생합니다. 디버깅 설정을 읽기 위해 MDNS 라이브러리를 로드하려고 시도합니다(활성화된 경우). 파일 핸들을 열지 말아야 하며, 이 문제는 애플(Apple)에도 보고되었습니다. 다만, 이러한 동작을 일으키는 것은 헬름이 아닌 맥OS입니다. 헬름이 이 파일을 로드하지 않도록 하려면 호스트 네트워크 스택을 사용하지 않는 정적 라이브러리로서 헬름을 컴파일하면 됩니다. 이렇게 하면 헬름의 바이너리 크기가 커지기는 하지만, 그 파일이 열리는 것은 막을 수 있습니다. 이 문제는 원래 잠재적인 보안 문제로 분류되기도 했습니다. 그러나 이후 이 동작으로 인한 결함이나 취약점은 없는 것으로 판명되었습니다. ### helm repo add가 동작한 후 실패합니다. 헬름 3.3.1 및 이전 버전에서 이미 존재하는 저장소(repo)를 추가하려고 하면 `helm repo add ` 명령어를 실행해도 출력되는 내용은 없습니다. `--no-update` 플래그를 사용하면 저장소가 이미 등록되어 있는 경우 오류를 발생시킵니다. 헬름 3.3.2 이상에서 기존 저장소를 추가하려고 하면 다음 오류가 발생합니다. `Error: repository name (reponame) already exists, please specify a different name` 이제 기본 동작은 반대가 됩니다. `--no-update`는 이제 무시되며, 기존 저장소를 교체(덮어쓰기)하려면 `--force-update`를 사용할 수 있습니다. 이는 [헬름 3.3.2 릴리스 노트](https://github.com/helm/helm/releases/tag/v3.3.2)에서 설명된대로 보안 픽스에 따라 단절적 변경(breaking change)이 있었기 때문입니다. ### 쿠버네티스 클라이언트 로깅 활성화 [klog](https://pkg.go.dev/k8s.io/klog) 플래그를 사용하여 쿠버네티스 클라이언트를 디버깅하기 위한 로그 메시지를 출력할 수 있습니다. 대부분의 경우에는 `-v` 플래그를 사용하여 자세한 수준(verbosity level)으로 설정하는 것만으로도 충분합니다. 예시: ``` helm list -v 6 ``` import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: 설치 sidebar_position: 2 --- ## 설치 ### Fedora나 다른 Linux 배포판에 Helm 네이티브 패키지가 없는 이유는 무엇인가요? Helm 프로젝트는 운영 체제 및 환경별 패키지를 직접 유지 관리하지 않는다. Helm 커뮤니티에서 네이티브 패키지를 제공할 수 있으며, Helm 프로젝트에 알려진 경우 목록에 추가된다. Homebrew formula가 이런 방식으로 시작되어 목록에 추가되었다. 패키지 유지 관리에 관심이 있다면 언제든지 환영한다. ### 왜 `curl ...|bash` 스크립트를 제공하나요? 저장소에 `curl ..|bash` 스크립트로 실행할 수 있는 스크립트(`scripts/get-helm-3`)가 있다. 모든 전송은 HTTPS로 보호되며, 스크립트는 가져온 패키지에 대해 일부 검증을 수행한다. 그러나 이 스크립트는 모든 셸 스크립트가 갖는 일반적인 위험성이 있다. 유용하기 때문에 제공하지만, 사용자가 먼저 스크립트를 주의 깊게 읽어보기를 권장한다. 우리가 정말로 바라는 것은 더 나은 패키지 형태의 Helm 릴리스이다. ### Helm 클라이언트 파일을 기본 위치가 아닌 다른 곳에 저장하려면 어떻게 하나요? Helm은 파일 저장에 XDG 구조를 사용한다. 다음 환경 변수를 사용하여 이 위치들을 변경할 수 있다: - `$XDG_CACHE_HOME`: 캐시 파일 저장을 위한 대체 위치를 설정한다. - `$XDG_CONFIG_HOME`: Helm 설정 저장을 위한 대체 위치를 설정한다. - `$XDG_DATA_HOME`: Helm 데이터 저장을 위한 대체 위치를 설정한다. 참고: 기존 리포지토리가 있는 경우, `helm repo add...`로 다시 추가해야 한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: 문제 해결 sidebar_position: 4 --- ## 문제 해결 ### "stable" 차트 리포지토리에서 업데이트를 가져올 수 없다는 경고가 나타나요 `helm repo list`를 실행한다. `stable` 리포지토리가 `storage.googleapis.com` URL을 가리키고 있다면, 해당 리포지토리를 업데이트해야 한다. 2020년 11월 13일, 1년간의 지원 중단(deprecation) 기간 후에 Helm Charts 리포지토리가 [지원 종료](https://github.com/helm/charts#deprecation-timeline)되었다. 아카이브가 `https://charts.helm.sh/stable`에 제공되고 있지만, 더 이상 업데이트되지 않는다. 다음 명령어를 실행하여 리포지토리를 수정할 수 있다: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator` 리포지토리도 마찬가지로 https://charts.helm.sh/incubator 에서 아카이브를 사용할 수 있다. 다음 명령어를 실행하여 수정할 수 있다: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' 경고가 나타나요 이전 Google helm 차트 리포지토리가 새로운 Helm 차트 리포지토리로 대체되었다. 다음 명령어를 실행하여 영구적으로 수정할 수 있다: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator`에서 비슷한 오류가 발생한다면, 다음 명령어를 실행한다: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Helm 리포지토리를 추가할 때 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' 오류가 발생해요 Helm Chart 리포지토리는 [1년간의 지원 중단 기간](https://github.com/helm/charts#deprecation-timeline) 이후 더 이상 지원되지 않는다. 이 리포지토리들의 아카이브는 `https://charts.helm.sh/stable` 및 `https://charts.helm.sh/incubator`에서 사용할 수 있지만, 더 이상 업데이트되지 않는다. `helm repo add` 명령어는 `--use-deprecated-repos`를 지정하지 않으면 이전 URL을 추가할 수 없다. ### GKE(Google Container Engine)에서 "No SSH tunnels currently open" 오류가 발생해요 ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` 다른 형태의 오류 메시지: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` 이 문제는 로컬 Kubernetes 설정 파일에 올바른 자격 증명이 없어서 발생한다. GKE에서 클러스터를 생성하면, SSL 인증서와 인증 기관을 포함한 자격 증명이 제공된다. 이것들은 Kubernetes 설정 파일(기본값: `~/.kube/config`)에 저장되어야 `kubectl` 및 `helm`이 접근할 수 있다. ### Helm 2에서 마이그레이션한 후, `helm list`에서 일부(또는 전체) 릴리스가 표시되지 않아요 Helm 3에서는 릴리스 범위를 지정하기 위해 클러스터 네임스페이스를 사용한다는 사실을 놓쳤을 가능성이 높다. 이는 릴리스를 참조하는 모든 명령어에서 다음 중 하나를 수행해야 함을 의미한다: * 활성 kubernetes 컨텍스트의 현재 네임스페이스에 의존하거나(`kubectl config view --minify` 명령어로 확인 가능), * `--namespace`/`-n` 플래그를 사용하여 올바른 네임스페이스를 지정하거나, * `helm list` 명령어의 경우, `--all-namespaces`/`-A` 플래그를 지정한다. 이는 `helm ls`, `helm uninstall` 및 릴리스를 참조하는 모든 `helm` 명령어에 적용된다. ### macOS에서 `/etc/.mdns_debug` 파일에 접근하는 이유가 뭔가요? macOS에서 Helm이 `/etc/.mdns_debug`라는 파일에 접근하려고 하는 경우가 있다. 해당 파일이 존재하면, Helm은 실행 중에 파일 핸들을 열린 상태로 유지한다. 이는 macOS의 MDNS 라이브러리 때문이다. 이 라이브러리는 디버깅 설정(활성화된 경우)을 읽기 위해 해당 파일을 로드하려고 시도한다. 파일 핸들이 열린 상태로 유지되는 것은 적절하지 않으며, 이 문제는 Apple에 보고되었다. 그러나 이 동작을 일으키는 것은 Helm이 아니라 macOS이다. Helm이 이 파일을 로드하지 않도록 하려면, 호스트 네트워크 스택을 사용하지 않는 정적 라이브러리로 Helm을 컴파일할 수 있다. 이렇게 하면 Helm의 바이너리 크기가 증가하지만, 파일이 열리는 것을 방지할 수 있다. 이 문제는 원래 잠재적인 보안 문제로 보고되었다. 그러나 이후 이 동작으로 인한 결함이나 취약점이 없는 것으로 확인되었다. ### helm repo add가 예전에는 작동했는데 지금은 실패해요 helm 3.3.1 이전에는, `helm repo add ` 명령어가 이미 존재하는 리포지토리를 추가하려고 해도 아무런 출력을 하지 않았다. `--no-update` 플래그는 리포지토리가 이미 등록된 경우 오류를 발생시켰다. helm 3.3.2부터는, 기존 리포지토리를 추가하려고 하면 오류가 발생한다: `Error: repository name (reponame) already exists, please specify a different name` 이제 기본 동작이 반대로 바뀌었다. `--no-update`는 이제 무시되며, 기존 리포지토리를 대체(덮어쓰기)하려면 `--force-update`를 사용해야 한다. 이는 [Helm 3.3.2 릴리스 노트](https://github.com/helm/helm/releases/tag/v3.3.2)에 설명된 보안 수정을 위한 호환성 변경 때문이다. ### Kubernetes 클라이언트 로깅 활성화 Kubernetes 클라이언트 디버깅을 위한 로그 메시지 출력은 [klog](https://pkg.go.dev/k8s.io/klog) 플래그를 사용하여 활성화할 수 있다. 대부분의 경우 `-v` 플래그를 사용하여 상세 수준(verbosity level)을 설정하면 충분하다. 예시: ``` helm list -v 6 ``` ### Tiller 설치가 작동하지 않고 접근이 거부돼요 Helm 릴리스는 이전에 에서 제공되었다. ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/)에 설명된 것처럼 공식 위치는 2019년 6월에 변경되었다. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)에서 모든 이전 Tiller 이미지를 제공하고 있다. 이전에 사용하던 스토리지 버킷에서 이전 버전의 Helm을 다운로드하려고 하면 해당 파일이 누락된 것을 발견할 수 있다: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [레거시 Tiller 이미지 위치](https://gcr.io/kubernetes-helm/tiller)에서 2021년 8월부터 이미지 제거가 시작되었다. 이러한 이미지는 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) 위치에서 사용할 수 있다. 예를 들어, v2.17.0 버전을 다운로드하려면 다음을 대체한다: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` 다음으로 변경: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Helm v2.17.0으로 초기화하려면: `helm init —upgrade` 또는 다른 버전이 필요한 경우, --tiller-image 플래그를 사용하여 기본 위치를 재정의하고 특정 Helm v2 버전을 설치할 수 있다: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **참고:** Helm 유지관리자들은 현재 지원되는 Helm 버전으로의 마이그레이션을 권장한다. Helm v2.17.0은 Helm v2의 마지막 릴리스였으며, Helm v2는 2020년 11월부터 지원되지 않는다. 자세한 내용은 [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/)를 참고한다. 그 이후로 많은 CVE가 Helm에 대해 보고되었으며, 이러한 취약점은 Helm v3에서 패치되었지만 Helm v2에서는 패치되지 않는다. [현재 게시된 Helm 보안 권고 목록](https://github.com/helm/helm/security/advisories?state=published)을 확인하고 오늘 [Helm v3로 마이그레이션](/topics/v2_v3_migration.md)할 계획을 세우기 바란다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: 삭제 sidebar_position: 3 --- ## 삭제 ### 로컬 헬름을 삭제하고 싶어요. 그 파일들은 모두 어디에 있나요? `helm` 바이너리 외에도 헬름은 일부 파일을 다음 위치에 저장합니다: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME 다음 표는 운영 체제별 각 항목의 기본 폴더를 보여줍니다: | 운영 체제 | 캐시 경로 | 설정 경로 | 데이터 경로 | |-----------|-----------------------------|---------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: 용어집 description: 헬름 아키텍처의 컴포넌트들을 기술하기 위해 사용된 용어. sidebar_position: 9 --- # 용어집 ## 차트 쿠버네티스 클러스터 내에 리소스 세트를 설치하는 데 필요한 정보를 담고 있는 헬름 패키지 차트는 템플릿을 비롯하여 `Chart.yaml` 파일, 기본 값(`values.yaml`), 의존성(dependencies)을 포함한다. 차트는 잘 정의된 디렉토리 구조 속에서 개발되며, _chart archive_라고 하는 아카이브 형식으로 패키징된다. ## 차트 아카이브 _chart archive_는 tar와 gzip으로 (필요시 서명을 추가한) 묶인 차트이다. ## 차트 의존성 (서브차트) 차트는 다른 차트에 의존(depend)할 수 있다. 의존성을 일으키는 2가지 방법은 다음과 같다. - 약한 의존성: 클러스터에 다른 차트가 없으면 차트가 동작하지 않을 수 있다. 헬름은 이런 경우에 필요한 도구를 제공하지 않으며, 별도로 의존성을 관리해야 한다. - 강한 의존성: A chart may contain (inside of its `charts/` directory) another chart upon which it depends. In this case, installing the chart will install all of its dependencies. In this case, a chart and its dependencies are managed as a collection. When a chart is packaged (via `helm package`) all of its hard dependencies are bundled with it. ## Chart Version Charts are versioned according to the [SemVer 2 spec](https://semver.org). A version number is required on every chart. ## Chart.yaml Information about a chart is stored in a special file called `Chart.yaml`. Every chart must have this file. ## Helm (and helm) Helm is the package manager for Kubernetes. As an operating system package manager makes it easy to install tools on an OS, Helm makes it easy to install applications and resources into Kubernetes clusters. While _Helm_ is the name of the project, the command line client is also named `helm`. By convention, when speaking of the project, _Helm_ is capitalized. When speaking of the client, _helm_ is in lowercase. ## Helm Configuration Files (XDG) Helm stores its configuration files in XDG directories. These directories are created the first time `helm` is run. ## Kube Config (KUBECONFIG) The Helm client learns about Kubernetes clusters by using files in the _Kube config_ file format. By default, Helm attempts to find this file in the place where `kubectl` creates it (`$HOME/.kube/config`). ## Lint (Linting) To _lint_ a chart is to validate that it follows the conventions and requirements of the Helm chart standard. Helm provides tools to do this, notably the `helm lint` command. ## Provenance (Provenance file) Helm charts may be accompanied by a _provenance file_ which provides information about where the chart came from and what it contains. Provenance files are one part of the Helm security story. A provenance contains a cryptographic hash of the chart archive file, the Chart.yaml data, and a signature block (an OpenPGP "clearsign" block). When coupled with a keychain, this provides chart users with the ability to: - Validate that a chart was signed by a trusted party - Validate that the chart file has not been tampered with - Validate the contents of a chart metadata (`Chart.yaml`) - Quickly match a chart to its provenance data Provenance files have the `.prov` extension, and can be served from a chart repository server or any other HTTP server. ## Release When a chart is installed, the Helm library creates a _release_ to track that installation. A single chart may be installed many times into the same cluster, and create many different releases. For example, one can install three PostgreSQL databases by running `helm install` three times with a different release name. ## Release Number (Release Version) A single release can be updated multiple times. A sequential counter is used to track releases as they change. After a first `helm install`, a release will have _release number_ 1. Each time a release is upgraded or rolled back, the release number will be incremented. ## Rollback A release can be upgraded to a newer chart or configuration. But since release history is stored, a release can also be _rolled back_ to a previous release number. This is done with the `helm rollback` command. Importantly, a rolled back release will receive a new release number. | Operation | Release Number | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (but running the same config as release 1) | The above table illustrates how release numbers increment across install, upgrade, and rollback. ## Helm Library (or SDK) The Helm Library (or SDK) refers to the Go code that interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It can be imported into a project to use Helm as a client library instead of a CLI. ## Repository (Repo, Chart Repository) Helm charts may be stored on dedicated HTTP servers called _chart repositories_ (_repositories_, or just _repos_). A chart repository server is a simple HTTP server that can serve an `index.yaml` file that describes a batch of charts, and provides information on where each chart can be downloaded from. (Many chart repositories serve the charts as well as the `index.yaml` file.) A Helm client can point to zero or more chart repositories. By default, Helm clients are not configured with any chart repositories. Chart repositories can be added at any time using the `helm repo add` command. ## Values (Values Files, values.yaml) Values provide a way to override template defaults with your own information. Helm Charts are "parameterized", which means the chart developer may expose configuration that can be overridden at installation time. For example, a chart may expose a `username` field that allows setting a user name for a service. These exposed variables are called _values_ in Helm parlance. Values can be set during `helm install` and `helm upgrade` operations, either by passing them in directly, or by using a `values.yaml` file. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- 쿠버네티스를 위한 Helm 패키지 매니저 ### 개요 쿠버네티스 패키지 매니저 일반적으로 사용되는 Helm 작업: - helm search: 차트를 검색 - helm pull: 차트를 로컬 디렉토리에 다운로드하여 확인 - helm install: 쿠버네티스에 차트 업로드 - helm list: 차트 릴리스 목록 표시 환경 변수: | Name | Description | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | 캐시된 파일을 저장할 대체 위치를 지정 | | $HELM_CONFIG_HOME | Helm 설정을 저장할 대체 위치를 지정 | | $HELM_DATA_HOME | Helm 데이터를 저장할 대체 위치를 지정 | | $HELM_DEBUG | Helm이 디버그 모드에서 실행 중인지 여부 표시 | | $HELM_DRIVER | 백엔드 스토리지 드라이버 설정. 값: configmap, secret, memory, sql | | $HELM_DRIVER_SQL_CONNECTION_STRING | SQL 스토리지 드라이버가 사용해야 하는 연결 문자열 지정 | | $HELM_MAX_HISTORY | Helm 릴리스 내역의 최대 수 설정 | | $HELM_NAMESPACE | Helm 작업에 사용되는 네임스페이스 지정 | | $HELM_NO_PLUGINS | 플러그인 비활성화. 비활성화하려면 HELM_NO_PLUGINS=1로 지정 | | $HELM_PLUGINS | 플러그인 디렉토리에 대한 경로 설정 | | $HELM_REGISTRY_CONFIG | 레지스트리 구성 파일의 경로를 설정 | | $HELM_REPOSITORY_CACHE | 리포지토리 캐시 디렉토리에 대한 경로 설정 | | $HELM_REPOSITORY_CONFIG | 리포지토리 파일의 경로 설정 | | $KUBECONFIG | 대체 Kubernetes 설정 파일 지정 (기본값 "~/.kube/config") | | $HELM_KUBEAPISERVER | 인증을 위한 Kubernetes API 서버의 엔드포인트 설정 | | $HELM_KUBECAFILE | Kubernetes 인증 기관 파일 설정 | | $HELM_KUBEASGROUPS | 쉼표로 구분된 목록을 사용하여, 작업에 가장(impersonation)할 그룹 지정 | | $HELM_KUBEASUSER | 작업에 가장(impersonation)할 사용자 이름 설정 | | $HELM_KUBECONTEXT | kubeconfig 컨텍스트의 이름 설정 | | $HELM_KUBETOKEN | 인증에 사용되는 Bearer KubeToken 설정 | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | Kubernetes API 서버의 인증서 유효성 검사를 건너뛸지 여부 표시 (안전하지 않음) | | $HELM_KUBETLS_SERVER_NAME | Kubernetes API 서버 인증서를 검증하는 데 사용할 서버 이름 설정 | | $HELM_BURST_LIMIT | 서버에 CRD가 많은 경우의 기본 버스트 제한 설정 (기본값 100, 비활성화하려면 -1) | | $HELM_QPS | 높은 버스트 값 옵션을 초과하는 호출이 많은 경우의 초당 쿼리 수(QPS) 설정 | Helm은 다음 설정 순서를 기반으로 캐시, 설정 정보, 데이터를 저장한다: - HELM_*_HOME 환경변수가 설정된 경우 이 변수를 사용함 - 그렇지 않으면, XDG 기반 디렉토리 사양을 지원하는 시스템에서 XDG 변수를 사용함 - 다른 위치를 설정하지 않은 경우 운영 체제의 기본 위치를 사용함 기본적으로 기본 디렉토리는 운영체제에 따라 다르며, 기본값은 아래와 같다: | 운영체제 | 캐시 경로 | 설정 경로 | 데이터 경로 | |----------|---------------------------|----------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세한(verbose) 출력 활성화 -h, --help helm 명령어에 대한 도움말 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 가장할 그룹. 이 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 가장할 사용자명 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, Kubernetes API 서버의 인증서 유효성을 검사하지 않음. 이 옵션을 사용하면 HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string Kubernetes API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 Bearer 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 범위 --qps float32 Kubernetes API와 통신 시 사용할 초당 쿼리 수(버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm completion](/helm/helm_completion.md) - 지정된 셸에 대한 자동 완성 스크립트 생성 * [helm create](/helm/helm_create.md) - 주어진 이름으로 새 차트 생성 * [helm dependency](/helm/helm_dependency.md) - 차트의 종속성 관리 * [helm env](/helm/helm_env.md) - Helm 클라이언트 환경 정보 * [helm get](/helm/helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 * [helm history](/helm/helm_history.md) - 릴리스 기록 가져오기 * [helm install](/helm/helm_install.md) - 차트 설치 * [helm lint](/helm/helm_lint.md) - 차트에서 발생 가능한 이슈 검사 * [helm list](/helm/helm_list.md) - 릴리스 목록 * [helm package](/helm/helm_package.md) - 차트 디렉토리를 차트 아카이브로 패키징 * [helm plugin](/helm/helm_plugin.md) - Helm 플러그인 설치, 조회, 제거 * [helm pull](/helm/helm_pull.md) - 리포지토리에서 차트를 다운로드하고 (선택적으로) 로컬 디렉토리에 압축 해제 * [helm push](/helm/helm_push.md) - 차트를 원격에 푸시 * [helm registry](/helm/helm_registry.md) - 레지스트리에 로그인 또는 로그아웃 * [helm repo](/helm/helm_repo.md) - 차트 리포지토리의 추가, 조회, 제거, 업데이트 및 인덱스 생성 * [helm rollback](/helm/helm_rollback.md) - 릴리스를 이전 리비전으로 롤백 * [helm search](/helm/helm_search.md) - 차트에서 키워드 검색 * [helm show](/helm/helm_show.md) - 차트 정보 표시 * [helm status](/helm/helm_status.md) - 명명된 릴리스의 상태 표시 * [helm template](/helm/helm_template.md) - 로컬에서 템플릿 렌더링 * [helm test](/helm/helm_test.md) - 릴리스 테스트 수행 * [helm uninstall](/helm/helm_uninstall.md) - 릴리스 제거 * [helm upgrade](/helm/helm_upgrade.md) - 릴리스 업그레이드 * [helm verify](/helm/helm_verify.md) - 지정된 경로의 차트가 서명되었고 유효한지 검증 * [helm version](/helm/helm_version.md) - 클라이언트 버전 정보 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- 지정된 셸에 대한 자동 완성 스크립트 생성 ### 개요 지정된 셸의 Helm에 대한 자동 완성 스크립트를 생성한다. ### 옵션 ``` -h, --help completion에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](/helm/helm.md) - Kubernetes용 Helm 패키지 관리자 * [helm completion bash](/helm/helm_completion_bash.md) - bash에 대한 자동 완성 스크립트 생성 * [helm completion fish](/helm/helm_completion_fish.md) - fish에 대한 자동 완성 스크립트 생성 * [helm completion powershell](/helm/helm_completion_powershell.md) - powershell에 대한 자동 완성 스크립트 생성 * [helm completion zsh](/helm/helm_completion_zsh.md) - zsh에 대한 자동 완성 스크립트 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- bash에 대한 자동 완성 스크립트 생성 ### 개요 bash 셸의 Helm에 대한 자동 완성 스크립트를 생성한다. 현재 셸 세션에서 완성 기능을 로드하려면: source <(helm completion bash) 새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### 옵션 ``` -h, --help bash에 대한 도움말 --no-descriptions 완성 설명 비활성화 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm completion](/helm/helm_completion.md) - 지정된 셸에 대한 자동 완성 스크립트 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- fish에 대한 자동 완성 스크립트 생성 ### 개요 fish 셸의 Helm에 대한 자동 완성 스크립트를 생성한다. 현재 셸 세션에서 완성 기능을 로드하려면: helm completion fish | source 새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다: helm completion fish > ~/.config/fish/completions/helm.fish 이 설정을 적용하려면 새 셸을 시작해야 한다. ``` helm completion fish [flags] ``` ### 옵션 ``` -h, --help fish에 대한 도움말 --no-descriptions 완성 설명 비활성화 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm completion](/helm/helm_completion.md) - 지정된 셸에 대한 자동 완성 스크립트 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- powershell에 대한 자동 완성 스크립트 생성 ### 개요 powershell 셸의 Helm에 대한 자동 완성 스크립트를 생성한다. 현재 셸 세션에서 완성 기능을 로드하려면: PS C:\> helm completion powershell | Out-String | Invoke-Expression 새로운 세션마다 완성 기능을 로드하려면, 위 명령어의 출력을 powershell 프로필에 추가한다. ``` helm completion powershell [flags] ``` ### 옵션 ``` -h, --help powershell에 대한 도움말 --no-descriptions 완성 설명 비활성화 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm completion](/helm/helm_completion.md) - 지정된 셸에 대한 자동 완성 스크립트 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- zsh에 대한 자동 완성 스크립트 생성 ### 개요 zsh 셸의 Helm에 대한 자동 완성 스크립트를 생성한다. 현재 셸 세션에서 완성 기능을 로드하려면: source <(helm completion zsh) 새로운 세션마다 완성 기능을 로드하려면 다음 작업을 한 번 실행한다: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### 옵션 ``` -h, --help zsh에 대한 도움말 --no-descriptions 완성 설명 비활성화 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm completion](/helm/helm_completion.md) - 지정된 셸에 대한 자동 완성 스크립트 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- 주어진 이름으로 새로운 차트를 생성한다. ### 개요 이 명령은 차트에 사용되는 공통 파일 및 디렉토리와 함께 차트 디렉토리를 만든다. 예를 들어, 'helm create foo'는 다음과 같은 디렉토리 구조를 생성한다: foo/ ├── .helmignore # Helm 차트를 패키징할 때 무시할 패턴 포함 ├── Chart.yaml # 차트에 대한 정보 ├── values.yaml # 템플릿의 기본값 ├── charts/ # 이 차트가 의존하는 차트 └── templates/ # 템플릿 파일 └── tests/ # 테스트 파일 'helm create'는 인수로 경로를 받는다. 지정된 경로에 디렉토리가 존재하지 않으면 Helm은 디렉토리를 생성하려고 시도한다. 지정된 대상이 있고 해당 디렉토리에 파일이 있으면 충돌하는 파일을 덮어 쓰지만 다른 파일은 그대로 둔다. ``` helm create NAME [flags] ``` ### 옵션 ``` -h, --help create에 대한 도움말 -p, --starter string Helm 스타터 스캐폴드의 이름 또는 절대 경로 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string Kubernetes API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹을 지정할 수 있다. --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string Kubernetes API 서버 연결에 사용할 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify 참이면, Kubernetes API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string Kubernetes API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 접속하는 데 사용되는 호스트 이름이 사용된다. --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스팅을 제외하고 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](/helm/helm.md) - Kubernetes용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- 차트의 종속성을 관리 ### 개요 차트의 종속성을 관리한다. 헬름 차트는 종속성을 'charts/' 에 저장한다. 차트 개발자의 경우 모든 종속성을 선언하는 'Chart.yaml' 에서 종속성을 관리하는 것이 더 쉬운 경우가 많다. 종속성 명령은 해당 파일에서 작동하므로 원하는 종속성과 'charts/' 디렉토리에 저장된 실제 종속성을 쉽게 동기화할 수 있다. 예를 들어 이 Chart.yaml 은 두 가지 종속성을 선언한다. # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" 'name' 은 차트의 이름이어야 한다. 여기서 해당 이름은 해당 차트의 'Chart.yaml' 파일에 있는 이름과 일치해야 한다. 'version' 필드에는 의미론적 버전 또는 버전 범위가 포함되어야 한다. 'repository' URL은 차트 리포지토리를 가리켜야한다. 헬름은 URL에 '/index.yaml' 을 추가하여 차트 리포지토리의 인덱스를 검색할 수 있어야 한다고 예상한다. 참고: 'repository' 는 별칭이 될 수도 있다. 별칭은 'alias:' 나 '@'로 시작해야 한다. 2.2.0 부터는 저장소는 로컬에 저장된 종속성 차트의 디렉토리 경로로 정의할 수 있다. 경로는 "file://" 접두사로 시작해야 한다. 예를 들면, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" 종속성 차트가 로컬로 검색되는 경우 "helm add repo" 를 통해 저장소를 헬름에 추가할 필요가 없다. 이 경우 버전 일치 또한 지원된다. ### 옵션 ``` -h, --help helm dependency 명령어의 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 접속할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm](/helm/helm.md) - 쿠버네티스에 대한 헬름 패키지 매니저. * [helm dependency build](/helm/helm_dependency_build.md) - Chart.lock 파일을 기반으로 charts/ 디렉토리를 다시 빌드 * [helm dependency list](/helm/helm_dependency_list.md) - 주어진 차트에 대한 종속성 나열 * [helm dependency update](/helm/helm_dependency_update.md) - Chart.yaml 의 내용에 따라 charts/ 업데이트 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- Chart.lock 파일을 기반으로 charts/ 디렉토리를 다시 빌드 ### 개요 Chart.lock 파일에서 charts/ 디렉토리를 빌드한다. 빌드는 잠금 파일에 지정된 상태로 차트의 종속성을 재구성하는데 사용된다. 이것은 'helm dependency update'처럼 종속성을 다시 협상하지 않는다. 잠금 파일이 없으면 'helm dependency build'는 'helm dependency update'의 동작을 미러링한다. ``` helm dependency build CHART [flags] ``` ### 옵션 ``` --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 -h, --help build 명령어에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드에 대한 TLS 인증서 검사 건너뛰기 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 공개키를 포함하는 키링 (기본값 "~/.gnupg/pubring.gpg") --password string 요청한 차트가 있는 차트 저장소 비밀번호 --plain-http 차트 다운로드에 비보안 HTTP 연결 사용 --skip-refresh 로컬 저장소 캐시를 새로 고치지 않음 --username string 요청한 차트가 있는 차트 저장소 사용자명 --verify 서명과 비교하여 패키지를 확인 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는데 사용된 호스트명이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용하는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm dependency](/helm/helm_dependency.md) - 차트의 종속성을 관리 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- 주어진 차트에 대한 종속성을 나열 ### 개요 차트에 선언된 모든 종속성을 나열한다. 이 명령은 차트 아카이브 및 차트 디렉토리를 입력으로 사용할 수 있다. 차트의 내용은 변경되지 않는다. 차트를 로드할 수 없는 경우 오류가 발생한다. ``` helm dependency list CHART [flags] ``` ### 옵션 ``` -h, --help list 명령어에 대한 도움말 --max-col-width uint 출력 테이블의 최대 열 너비 (기본값 80) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않는다. HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트 이름이 사용된다. --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm dependency](/helm/helm_dependency.md) - 차트의 종속성을 관리 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- Chart.yaml 의 내용에 따라 charts/ 업데이트 ### 개요 Chart.yaml 을 미러링하도록 온-디스크 종속성을 업데이트한다. 이 명령은 'Chart.yaml' 에 표현된 필수 차트가 'charts/' 에 있고 허용 가능한 버전인지를 확인한다. 종속성을 충족하는 최신 차트를 풀다운(pull down)하고 이전 종속성을 정리한다. 업데이트가 성공하면 종속성을 정확한 버전으로 다시 빌드하는데 사용할 수 있는 잠금파일이 생성된다. 종속성은 'Chart.yaml' 에 표시할 필요가 없다. 따라서 업데이트 명령은 차트가 (a)Chart.yaml 파일에 있지만, (b)잘못된 버전이 아니면 차트를 제거하지 않는다. ``` helm dependency update CHART [flags] ``` ### 옵션 ``` --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 -h, --help helm dependency update 명령어에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드에 대한 TLS 인증서 검사 건너뛰기 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 공개키를 포함하는 키링 (기본값 "~/.gnupg/pubring.gpg") --password string 요청한 차트가 있는 차트 저장소 비밀번호 --plain-http 차트 다운로드에 비보안 HTTP 연결 사용 --skip-refresh 로컬 저장소 캐시를 새로 고치지 않음 --username string 요청한 차트가 있는 차트 저장소 사용자명 --verify 서명과 비교하여 패키지를 확인 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는데 사용된 호스트명이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용하는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm dependency](/helm/helm_dependency.md) - 차트의 종속성을 관리 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- Helm 클라이언트 환경 정보 ### 개요 Env 는 Helm에서 사용 중인 모든 환경 정보를 출력한다. ``` helm env [flags] ``` ### 옵션 ``` -h, --help env 에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- 명명된 릴리스의 확장 정보 다운로드 ### 개요 이 명령어는 다음을 포함하여 릴리스에 대한 확장 정보를 가져오는 데 사용할 수 있는 여러 하위 명령어로 구성된다. - 릴리스 생성에 사용된 값 - 생성된 매니페스트 파일 - 릴리스 차트에서 제공하는 노트 - 릴리스와 관련된 훅(hooks) - 릴리스의 메타데이터 ### 옵션 ``` -h, --help get 에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 Helm 패키지 매니저 * [helm get all](./helm_get_all.md) - 명명된 릴리스에 대한 모든 정보 다운로드 * [helm get hooks](./helm_get_hooks.md) - 명명된 릴리스에 대한 모든 훅 다운로드 * [helm get manifest](./helm_get_manifest.md) - 명명된 릴리스에 대한 매니페스트 다운로드 * [helm get metadata](./helm_get_metadata.md) - 주어진 릴리스의 메타데이터를 가져온다 * [helm get notes](./helm_get_notes.md) - 명명된 릴리스에 대한 노트 다운로드 * [helm get values](./helm_get_values.md) - 명명된 릴리스에 대한 값 파일 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- 명명된 릴리스에 대한 모든 정보 다운로드 ### 개요 이 명령어는 지정한 릴리스에서 노트, 훅, 제공된 값 및 생성된 매니페스트 파일에 대한 정보를 사람이 읽을 수 있는 형식으로 출력한다. ``` helm get all RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help all 에 대한 도움말 --revision int 해당 리비전의 릴리스 정보 가져오기 --template string 출력 형식 지정을 위한 go 템플릿. 예: {{.Release.Name}} ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- 명명된 릴리스에 대한 모든 훅 다운로드 ### 개요 이 명령은 주어진 릴리스에 대한 훅을 다운로드한다. 훅은 YAML 형식이며 YAML '---\n' 구분자로 구분된다. ``` helm get hooks RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help hooks 에 대한 도움말 --revision int 지정한 리비전의 릴리스 가져오기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- 명명된 릴리스에 대한 매니페스트 다운로드 ### 개요 이 명령은 주어진 릴리스에 대해 생성된 매니페스트를 가져온다. 매니페스트는 해당 릴리스의 차트에서 생성된 Kubernetes 리소스를 YAML로 인코딩하여 표현한 것이다. 차트가 다른 차트에 의존하는 경우, 해당 리소스도 매니페스트에 포함된다. ``` helm get manifest RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help manifest 에 대한 도움말 --revision int 지정한 리비전의 릴리스 가져오기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- 주어진 릴리스의 메타데이터를 가져온다. ``` helm get metadata RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help metadata 에 대한 도움말 -o, --output format 지정한 형식으로 출력 표시. 허용되는 값: table, json, yaml (기본값 table) --revision int 릴리스 리비전 지정 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- 명명된 릴리스에 대한 노트 다운로드 ### 개요 이 명령어는 명명된 릴리스의 차트에서 제공하는 노트를 보여준다. ``` helm get notes RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help notes 에 대한 도움말 --revision int 리비전으로 명명된 릴리스 가져오기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- 명명된 릴리스에 대한 값 파일 다운로드 ### 개요 이 명령어는 주어진 릴리스에 대한 값 파일을 다운로드한다. ``` helm get values RELEASE_NAME [flags] ``` ### 옵션 ``` -a, --all 모든 (계산된) 값 덤프 -h, --help values 에 대한 도움말 -o, --output format 지정한 형식으로 출력 표시. 허용되는 값: table, json, yaml (기본값 table) --revision int 리비전으로 명명된 릴리스 가져오기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm get](./helm_get.md) - 명명된 릴리스의 확장 정보 다운로드 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- 릴리스 히스토리를 가져온다. ### 개요 History는 주어진 릴리스에 대한 리비전 기록을 출력한다. 기본적으로 최대 256개의 리비전이 반환된다. '--max' 옵션으로 반환되는 리비전 목록의 최대 길이를 지정할 수 있다. 릴리스 기록은 형식이 지정된 테이블의 형태로 출력된다. 예: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help history 명령어에 대한 도움말 --max int 기록에 포함할 최대 리비전 수 (기본값 256) -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- 차트를 설치한다. ### 개요 이 명령은 차트 아카이브를 설치한다. install 인수는 차트 참조, 패키지된 차트 경로, 압축 해제된 차트 디렉토리 경로 또는 URL이어야 한다. 차트의 값을 재정의하려면 '--values' 플래그를 사용하여 파일을 전달하거나 '--set' 플래그를 사용하여 명령줄에서 구성을 전달한다. 문자열 값을 강제하려면 '--set-string'을 사용한다. 값 자체가 명령줄에 사용하기엔 너무 길거나 동적으로 생성되는 경우 '--set-file'을 사용하여 파일에서 개별 값을 설정할 수 있다. '--set-json'을 사용하여 명령줄에서 JSON 값(스칼라/객체/배열)을 설정할 수도 있다. $ helm install -f myvalues.yaml myredis ./redis 또는 $ helm install --set name=prod myredis ./redis 또는 $ helm install --set-string long_int=1234567890 myredis ./redis 또는 $ helm install --set-file my_script=dothings.sh myredis ./redis 또는 $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis '--values'/'-f' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 파일에 우선순위가 부여된다. 예를 들어 myvalues.yaml과 override.yaml에 'Test'라는 키가 포함된 경우 override.yaml에 설정된 값이 우선한다: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis '--set' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 세트에 우선순위가 부여된다. 예를 들어 'foo'라는 키에 대해 'bar'와 'newbar' 값이 모두 설정된 경우 'newbar' 값이 우선한다: $ helm install --set foo=bar --set foo=newbar myredis ./redis 마찬가지로, 다음 예제에서 'foo'는 '["four"]'로 설정된다: $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis 그리고 다음 예제에서 'foo'는 '{"key1":"value1","key2":"bar"}'로 설정된다: $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis 차트를 설치하지 않고 릴리스의 생성된 매니페스트를 확인하려면 --debug와 --dry-run 플래그를 함께 사용할 수 있다. --dry-run 플래그는 민감한 값을 포함할 수 있는 Secret을 포함하여 생성된 모든 차트 매니페스트를 출력한다. Kubernetes Secret을 숨기려면 --hide-secret 플래그를 사용한다. 이러한 플래그를 사용하는 방법과 시기를 신중하게 고려해야 한다. --verify가 설정된 경우, 차트에는 출처 파일이 반드시 있어야 하며, 출처 파일은 모든 검증 단계를 반드시 통과해야 한다. 설치할 차트를 표현하는 여섯 가지 방법이 있다: 1. 차트 참조: helm install mymaria example/mariadb 2. 패키지된 차트 경로: helm install mynginx ./nginx-1.2.3.tgz 3. 압축 해제된 차트 디렉토리 경로: helm install mynginx ./nginx 4. 절대 URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. 차트 참조 및 저장소 URL: helm install --repo https://example.com/charts/ mynginx nginx 6. OCI 레지스트리: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx 차트 참조 차트 참조는 차트 저장소에서 차트를 참조하는 편리한 방법이다. 저장소 접두사가 있는 차트 참조('example/mariadb')를 사용하면, Helm은 로컬 구성에서 'example'이라는 차트 저장소를 찾은 다음 해당 저장소에서 'mariadb'라는 이름의 차트를 찾는다. 개발 버전(알파, 베타, 릴리스 후보)도 포함하려면 '--devel' 플래그를 지정하거나 '--version' 플래그로 버전 번호를 제공하지 않는 한, 해당 차트의 최신 안정 버전을 설치한다. 차트 저장소 목록을 보려면 'helm repo list'를 사용한다. 저장소에서 차트를 검색하려면 'helm search'를 사용한다. ``` helm install [NAME] [CHART] [flags] ``` ### 옵션 ``` --atomic 설정된 경우, 설치 실패 시 설치를 삭제. --atomic을 사용하면 --wait 플래그가 자동으로 설정 --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별 --create-namespace 릴리스 네임스페이스가 없는 경우 생성 --dependency-update 차트를 설치하기 전에 의존성이 누락된 경우 업데이트 --description string 사용자 정의 설명 추가 --devel 개발 버전도 사용. 버전 '>0.0.0-0'과 동일. --version이 설정되면 무시 --disable-openapi-validation 설정된 경우, 설치 프로세스는 렌더링된 템플릿을 Kubernetes OpenAPI 스키마에 대해 검증하지 않음 --dry-run string[="client"] 설치를 시뮬레이션. --dry-run이 옵션 없이 설정되거나 '--dry-run=client'로 설정된 경우, 클러스터 연결을 시도하지 않음. '--dry-run=server'를 설정하면 클러스터 연결을 시도 가능 --enable-dns 템플릿 렌더링 시 DNS 조회를 활성화 --force 교체 전략을 통해 리소스 업데이트를 강제 -g, --generate-name 이름을 생성(NAME 매개변수 생략) -h, --help install 도움말 --hide-notes 설정된 경우, 설치 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향을 주지 않음 --hide-secret --dry-run 플래그와 함께 사용할 때 Kubernetes Secret을 숨김 --insecure-skip-tls-verify 차트 다운로드를 위한 TLS 인증서 검사를 건너뜀 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트를 식별 --keyring string 검증에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") -l, --labels stringToString 릴리스 메타데이터에 추가할 레이블. 쉼표로 구분 (기본값 []) --name-template string 릴리스 이름을 지정하는 데 사용되는 템플릿 지정 --no-hooks 설치 중 훅 실행을 방지 -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트가 위치한 차트 저장소 비밀번호 --plain-http 차트 다운로드에 보안되지 않은 HTTP 연결을 사용 --post-renderer postRendererString 포스트 렌더링에 사용할 실행 파일의 경로. $PATH에 있으면 바이너리가 사용되고, 그렇지 않으면 지정된 경로에서 실행 파일을 탐색 --post-renderer-args postRendererArgsSlice 포스트 렌더러에 대한 인수 (여러 개 지정 가능) (기본값 []) --render-subchart-notes 설정된 경우, 부모 차트와 함께 하위 차트 notes를 렌더링 --replace 지정된 이름이 히스토리에 남아 있는 삭제된 릴리스인 경우에만 해당 이름을 재사용. 프로덕션 환경에서는 안전하지 않음 --repo string 요청된 차트가 위치한 차트 저장소 URL --set stringArray 명령줄에서 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=val1,key2=val2) --set-file stringArray 명령줄에서 지정된 해당 파일에서 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=path1,key2=path2) --set-json stringArray 명령줄에서 JSON 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=jsonval1,key2=jsonval2) --set-literal stringArray 명령줄에서 리터럴 STRING 값을 설정 --set-string stringArray 명령줄에서 STRING 값을 설정 (여러 개 또는 쉼표로 구분된 값을 지정 가능: key1=val1,key2=val2) --skip-crds 설정된 경우, CRD가 설치되지 않음. 기본적으로 CRD가 아직 없으면 설치 --skip-schema-validation 설정된 경우, JSON 스키마 검증을 비활성화 --take-ownership 설정된 경우, install은 helm 어노테이션 검사를 무시하고 기존 리소스의 소유권을 가져옴 --timeout duration 개별 Kubernetes 작업(예: 훅에 대한 Job)을 기다리는 시간 (기본값 5m0s) --username string 요청된 차트가 위치한 차트 저장소 사용자명 -f, --values strings YAML 파일 또는 URL에서 값을 지정 (여러 개 지정 가능) --verify 사용하기 전에 패키지를 검증 --version string 사용할 차트 버전에 대한 버전 제약을 지정. 이 제약은 특정 태그(예: 1.1.1)일 수도 있고 유효한 범위(예: ^2.0.0)를 참조할 수도 있음. 지정하지 않으면 최신 버전이 사용 --wait 설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 Pod, PVC, Service, 그리고 Deployment, StatefulSet 또는 ReplicaSet의 최소 Pod 수가 준비 상태가 될 때까지 --timeout 만큼 대기 --wait-for-jobs 설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 --timeout 만큼 대기 ``` ### 부모 명령에서 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력을 활성화 --kube-apiserver string Kubernetes API 서버의 주소와 포트 --kube-as-group stringArray 작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름을 지정 --kube-ca-file string Kubernetes API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, Kubernetes API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string Kubernetes API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용 --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 Kubernetes API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - Kubernetes를 위한 Helm 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- 차트에 발생 가능한 문제가 있는지 검사한다 ### 개요 이 명령은 차트 경로를 받아 해당 차트가 올바른 형식(well-formed)인지 검증하는 일련의 테스트를 실행한다. 린터(linter)가 차트 설치 실패를 일으킬 사항을 발견하면 [ERROR] 메시지를 출력한다. 컨벤션이나 권장 사항에 어긋난 이슈를 발견하면 [WARNING] 메시지를 출력한다. ``` helm lint PATH [flags] ``` ### 옵션 ``` -h, --help lint에 대한 도움말 --kube-version string 기능 및 사용 중단(deprecation) 검사에 사용할 쿠버네티스 버전 --quiet 경고와 오류만 출력 --set stringArray 명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2) --set-file stringArray 명령줄에서 지정한 파일로부터 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=path1,key2=path2) --set-json stringArray 명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=jsonval1,key2=jsonval2) --set-literal stringArray 명령줄에서 리터럴 STRING 값 설정 --set-string stringArray 명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2) --skip-schema-validation 설정 시 JSON 스키마 검증을 비활성화 --strict lint 경고 시 실패로 처리 -f, --values strings YAML 파일 또는 URL에서 값 지정 (여러 개 지정 가능) --with-subcharts 의존 차트도 함께 lint ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름을 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용 --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- 릴리스를 나열한다. ### 개요 이 명령은 지정된 네임스페이스에 대한 모든 릴리스를 나열한다 (네임스페이스가 지정되지 않은 경우 현재 네임스페이스 컨텍스트 사용). 기본적으로는, 배포되었거나 실패한 릴리스만 나열한다. '--uninstalled' 및 '--all' 과 같은 플래그는 이 동작을 변경한다. 이러한 플래그는 '--uninstalled --failed' 와 같이 결합할 수 있다. 기본적으로, 항목은 알파벳순으로 정렬된다. 릴리스 날짜별로 정렬하려면 '-d' 플래그를 사용한다. --filter 플래그가 제공되면 필터로 처리된다. 필터는 릴리스 목록에 적용되는 정규식 (Perl 호환)이다. 필터와 일치하는 항목만 반환된다. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 결과가 없으면 'helm list' 는 0으로 종료되지만 출력은 표시되지 않는다(또는 '-q' 플래그가 없는 경우 헤더만 표시된다). 기본적으로 최대 256개의 항목이 반환될 수 있다. 이를 제한하려면 '--max' 플래그를 사용한다. '--max' 를 0으로 설정하면 모든 결과가 반환되지 않는다. 대신 서버의 기본값을 반환하는데, 이는 256보다 훨씬 더 클 수 있다. '--max' 플래그와 '--offset' 플래그를 함께 사용하면 결과를 페이징할 수 있다. ``` helm list [flags] ``` ### 옵션 ``` -a, --all 필터가 적용되지 않은 모든 릴리스를 표시 -A, --all-namespaces 모든 네임스페이스의 릴리스를 나열 -d, --date 릴리스 날짜로 정렬 --deployed 배포된 릴리스를 표시. 다른 것을 지정하지 않으면 자동으로 활성화 --failed 실패한 릴리스를 표시 -f, --filter string 정규 표현식(Perl 호환). 표현식과 일치하는 모든 릴리스가 결과에 포함된다 -h, --help list 명령어에 대한 도움말 -m, --max int 가져올 최대 릴리스 수 (기본값 256) --no-headers 기본 출력 형식 사용 시 헤더를 출력하지 않음 --offset int 시작 값에서 오프셋하기 위한 목록의 다음 릴리스 인덱스 -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) --pending 보류 중인 릴리스를 표시 -r, --reverse 정렬 순서 반전 -l, --selector string 필터링할 셀렉터(레이블 쿼리)로, '=', '==', '!='를 지원 (예: -l key1=value1,key2=value2). secret(기본값) 및 configmap 스토리지 백엔드에서만 작동 -q, --short 짧은(간략한) 목록 형식 출력 --superseded 대체된 릴리스를 표시 --time-format string golang 시간 포맷터를 사용한 시간 형식. 예: --time-format "2006-01-02 15:04:05Z0700" --uninstalled 제거된 릴리스 표시('helm uninstall --keep-history' 를 사용한 경우) --uninstalling 현재 제거 중인 릴리스 표시 ``` ### 상위 명령에서 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용 --kube-as-user string 작업을 수행할 사용자로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 bearer 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- 차트 디렉토리를 차트 아카이브로 패키징 ### 개요 이 명령어는 차트를 버전이 지정된 차트 아카이브 파일로 패키징한다. 경로가 지정되면 차트(Chart.yaml 파일을 포함해야 함)에 대한 그 경로를 찾은 다음 해당 디렉토리를 패키징한다. 버전이 지정된 차트 아카이브는 헬름 패키지 저장소에서 사용된다. 차트에 서명하려면 '--sign' 플래그를 사용하자. 대부분의 경우, '--keyring path/to/secret/keys' 와 '--key keyname' 도 지정해야 할 것이다. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg '--keyring' 을 지정하지 않았고 별다른 설정을 하지 않은 환경이라면 헬름은 보통 공개 키링을 기본값으로 사용한다. ``` helm package [CHART_PATH] [...] [flags] ``` ### 옵션 ``` --app-version string 차트의 appVersion 을 이 버전으로 설정 --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 -u, --dependency-update 패키징 전에 "Chart.yaml" 에서 "charts/" 디렉토리로 의존성 업데이트 -d, --destination string 차트를 기록할 위치 지정 (기본값 ".") -h, --help package 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 검사 건너뛰기 --key string 서명할 때 사용하는 키의 이름. --sign 이 true 일 경우 사용 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 공개 키링의 위치 (기본값 "~/.gnupg/pubring.gpg") --passphrase-file string 서명 키의 암호문이 포함된 파일의 위치. 표준 입력에서 읽으려면 "-" 사용. --password string 요청된 차트를 찾을 수 있는 차트 저장소 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --sign PGP 개인 키를 사용하여 패키지에 서명 --username string 요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름 --version string 차트의 버전을 이 유의적(semver) 버전으로 설정 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹. 여러 그룹을 지정하려면 이 플래그를 반복 사용할 수 있음. --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true 이면 쿠버네티스 API 서버의 인증서 유효성 검사 미수행. HTTPS 연결이 안전하지 않게 됨. --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름 사용. --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수, 버스트 제외 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- 헬름 플러그인 설치, 나열, 제거 ### 개요 클라이언트 측 헬름 플러그인을 관리한다. ### 옵션 ``` -h, --help helm plugin 명령어의 도움말 ``` ### 부모 명령어로부터 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 자세한 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능 --kube-as-user string 작업을 가장할 사용자 이름 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 전달자(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청의 네임스페이스 범위 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인을 포함하는 파일 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 이 포함된 파일 경로(기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm](/helm/helm.md) - 쿠버네티스용 헬름 패키지 관리자 * [helm plugin install](/helm/helm_plugin_install.md) - 하나 이상의 헬름 플러그인 설치 * [helm plugin list](/helm/helm_plugin_list.md) - 설치된 헬름 플러그인 나열 * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - 하나 이상의 헬름 플러그인 제거 * [helm plugin update](/helm/helm_plugin_update.md) - 하나 이상의 헬름 플러그인 업데이트 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- 헬름 플러그인을 설치한다 ### 개요 이 명령을 사용하면 VCS 저장소의 URL 또는 로컬 경로에서 플러그인을 설치할 수 있다. ``` helm plugin install [options] [flags] ``` ### 옵션 ``` -h, --help install 명령어에 대한 도움말 --version string 버전 제약 조건을 지정한다. 지정하지 않으면 최신 버전이 설치된다 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm plugin](./helm_plugin.md) - 헬름 플러그인 설치, 나열, 제거 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- 설치된 헬름 플러그인 나열 ### 개요 설치된 헬름 플러그인을 나열한다. ``` helm plugin list [flags] ``` ### 옵션 ``` -h, --help helm plugin list 명령어의 도움말 ``` ### 부모 명령어로부터 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 자세한 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능 --kube-as-user string 작업을 가장할 사용자 이름 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 전달자(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청의 네임스페이스 범위 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인을 포함하는 파일 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm plugin](./helm_plugin.md) - 헬름 플러그인 설치, 나열, 제거 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- 하나 이상의 헬름 플러그인을 제거 ### 개요 하나 이상의 헬름 플러그인을 제거한다. ``` helm plugin uninstall ... [flags] ``` ### 옵션 ``` -h, --help uninstall 명령어에 대한 도움말 ``` ### 상위 명령에서 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용 --kube-as-user string 작업을 수행할 사용자로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 bearer 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm plugin](./helm_plugin.md) - 헬름 플러그인 설치, 나열, 제거 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- 하나 이상의 헬름 플러그인 업데이트 ### Synopsis 하나 이상의 헬름 플러그인을 업데이트한다. ``` helm plugin update ... [flags] ``` ### 옵션 ``` -h, --help helm plugin update 명령어의 도움말 ``` ### 부모 명령어로부터 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 자세한 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 가장(impersonate)하기 위한 그룹. 이 플래그를 반복하여 여러 그룹을 지정 가능 --kube-as-user string 작업을 가장할 사용자 이름 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용할 전달자(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청의 네임스페이스 범위 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인을 포함하는 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm plugin](/helm/helm_plugin.md) - 헬름 플러그인 설치, 나열, 제거 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- 저장소에서 차트를 다운로드하고 (선택적으로) 로컬 디렉터리에 압축 해제 ### 개요 패키지 저장소에서 패키지를 검색하고 로컬로 다운로드한다. 이는 검사, 수정 또는 리패키지를 위하여 패키지를 가져올 때 유용하다. 또한 설치하지 않고 차트의 암호화 검증을 수행하는 데 사용할 수도 있다. 다운로드 후 차트를 풀 수 있는 옵션이 있다. 그러면 차트에 대한 디렉터리가 생성되고 해당 디렉터리에 압축이 해제된다. --verify 플래그가 지정된 경우, 요청된 차트에는 출처 파일이 있어야 하며 확인 프로세스를 통과해야 한다. 프로세스 중 어느 부분에서라도 실패할 경우 오류가 발생하며, 차트가 로컬에 저장되지 않는다. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### 옵션 ``` --ca-file string 이 CA 번들을 사용하여 HTTPS 지원 서버의 인증서를 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 -d, --destination string 차트를 저장할 위치. 이 옵션과 untardir이 지정되면 untardir이 여기에 추가된다. (기본값 ".") --devel 개발용 버전으로도 사용 가능. 버전 '>0.0.0-0'과 동일하다. --version 플래그가 설정되면 이 옵션은 무시된다. -h, --help pull에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인 생략 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명 전달 --password string 요청된 차트를 찾을 수 있는 차트 저장소 비밀번호 --plain-http 차트 다운로드에 비보안 HTTP 연결 사용 --prov 출처 파일을 가져오기만 하고 확인은 수행하지 않음 --repo string 요청된 차트를 찾을 수 있는 차트 저장소 URL --untar true로 설정하면 차트를 다운로드한 후 압축을 해제 --untardir string untar가 지정된 경우 차트가 확장되는 디렉터리의 이름을 지정 (기본값 ".") --username string 요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름 --verify 사용하기 전에 패키지 확인 --version string 사용할 차트 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정하지 않으면 최신 버전이 사용된다. ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 가장할 그룹. 여러 그룹을 지정하려면 이 플래그를 반복할 수 있다. --kube-as-user string 작업을 가장할 사용자 이름 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true이면 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이렇게 하면 HTTPS 연결이 안전하지 않게 된다. --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다. --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- 차트를 원격 저장소로 푸시 ### 개요 차트를 레지스트리에 업로드한다. 차트에 연관된 출처(provenance) 파일이 있으면 함께 업로드한다. ``` helm push [chart] [remote] [flags] ``` ### 옵션 ``` --ca-file string 이 CA 번들을 사용하여 HTTPS 활성화된 서버의 인증서를 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 레지스트리 클라이언트 식별 -h, --help push 에 대한 도움말 --insecure-skip-tls-verify 차트 업로드 시 TLS 인증서 확인 생략 --key-file string 이 SSL 키 파일을 사용하여 레지스트리 클라이언트 식별 --password string 요청된 차트를 찾을 수 있는 차트 저장소 비밀번호 --plain-http 차트 업로드에 비보안 HTTP 연결 사용 --username string 요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 이 플래그는 여러 그룹 지정을 위해 반복 가능 --kube-as-user string 작업을 수행할 사용자 이름으로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 확인하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - Kubernetes용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- 레지스트리에 로그인 또는 로그아웃 ### 개요 이 명령어는 레지스트리와 상호 작용하기 위한 여러 하위 명령어로 구성된다. ### 옵션 ``` -h, --help registry 명령어에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - Kubernetes용 Helm 패키지 매니저 * [helm registry login](./helm_registry_login.md) - 레지스트리에 로그인 * [helm registry logout](./helm_registry_logout.md) - 레지스트리에서 로그아웃 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- 레지스트리에 로그인 ### 개요 원격 레지스트리에 인증한다. ``` helm registry login [host] [flags] ``` ### 옵션 ``` --ca-file string 이 CA 번들을 사용하여 HTTPS 지원 서버의 인증서를 검증 --cert-file string 이 SSL 인증서 파일을 사용하여 레지스트리 클라이언트를 식별 -h, --help login 명령어에 대한 도움말 --insecure 인증서 없이 TLS 레지스트리에 연결 허용 --key-file string 이 SSL 키 파일을 사용하여 레지스트리 클라이언트를 식별 -p, --password string 레지스트리 비밀번호 또는 ID 토큰 --password-stdin stdin에서 비밀번호 또는 ID 토큰 읽기 --plain-http 차트 업로드에 안전하지 않은 HTTP 연결 사용 -u, --username string 레지스트리 사용자명 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm registry](./helm_registry.md) - 레지스트리에 로그인 또는 로그아웃 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- 레지스트리에서 로그아웃 ### 개요 원격 레지스트리에 저장된 자격 증명을 제거한다. ``` helm registry logout [host] [flags] ``` ### 옵션 ``` -h, --help logout 명령어에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm registry](./helm_registry.md) - 레지스트리에 로그인 또는 로그아웃 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- 차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성 ### 개요 이 명령은 차트 저장소와 상호작용하는 여러 하위명령으로 구성된다. 차트 저장소를 추가, 제거, 나열, 색인화하는 데 사용할 수 있다. ### 옵션 ``` -h, --help repo 명령어에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm](./helm.md) - 쿠버네티스를 위한 Helm 패키지 매니저 * [helm repo add](./helm_repo_add.md) - 차트 저장소 추가 * [helm repo index](./helm_repo_index.md) - 패키지된 차트가 포함된 디렉터리에서 인덱스 파일 생성 * [helm repo list](./helm_repo_list.md) - 차트 저장소 나열 * [helm repo remove](./helm_repo_remove.md) - 하나 이상의 차트 저장소 제거 * [helm repo update](./helm_repo_update.md) - 차트 저장소에서 로컬로 사용 가능한 차트 정보 업데이트 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- 차트 저장소를 추가한다 ``` helm repo add [NAME] [URL] [flags] ``` ### 옵션 ``` --allow-deprecated-repos 기본적으로, 이 명령은 영구적으로 삭제된 공식 저장소를 추가하는 것을 허용하지 않으며, 이 옵션을 통해 해당 동작을 비활성화한다 --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인한다 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별한다 --force-update 저장소가 이미 있는 경우 교체(덮어쓰기)한다 -h, --help add 명령어에 대한 도움말 --insecure-skip-tls-verify 저장소에 대한 TLS 인증서 검사를 건너뛴다 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트를 식별한다 --no-update 무시됨. 이전에는 강제 업데이트를 비활성화하기 위해 사용되었다. force-update로 대체되어 더 이상 사용되지 않는다. --pass-credentials 모든 도메인에 자격 증명을 전달한다 --password string 차트 저장소 비밀번호 --password-stdin 표준 입력에서 차트 저장소 비밀번호를 읽는다 --timeout duration 인덱스 파일 다운로드 완료를 기다리는 시간 (기본값 2m0s) --username string 차트 저장소 사용자 이름 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm repo](./helm_repo.md) - 차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- 패키지된 차트가 포함된 디렉터리에서 인덱스 파일을 생성한다 ### 개요 현재 디렉터리를 읽고, 발견된 차트를 기반으로 인덱스 파일을 생성한 후, 결과를 현재 디렉터리의 'index.yaml' 파일에 저장한다. 이 도구는 차트 저장소용 'index.yaml' 파일을 생성하는 데 사용된다. 차트에 대한 절대 URL을 설정하려면 '--url' 플래그를 사용한다. 생성된 인덱스를 기존 인덱스 파일과 병합하려면 '--merge' 플래그를 사용한다. 이 경우 현재 디렉터리에서 발견된 차트가 --merge로 전달된 인덱스에 병합되며, 로컬 차트가 기존 차트보다 우선한다. ``` helm repo index [DIR] [flags] ``` ### 옵션 ``` -h, --help index 명령어에 대한 도움말 --json JSON 형식으로 출력 --merge string 생성된 인덱스를 지정된 인덱스에 병합 --url string 차트 저장소의 URL ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm repo](./helm_repo.md) - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- 차트 저장소 나열 ### 개요 차트 저장소를 나열한다. ``` helm repo list [flags] ``` ### Options ``` -h, --help helm repo list 명령어의 도움말 -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 지정하지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm repo](/helm/helm_repo.md) - 차트 저장소 추가, 나열, 제거, 업데이트, 색인 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- 하나 이상의 차트 저장소 제거 ### 개요 하나 이상의 차트 저장소를 제거한다. ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### 옵션 ``` -h, --help remove 명령어에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm repo](./helm_repo.md) - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- 차트 저장소에서 로컬로 사용 가능한 차트의 정보를 업데이트한다 ### 개요 업데이트 명령어는 각 차트 저장소에서 차트에 대한 최신 정보를 가져온다. 이 정보는 로컬에 캐싱되어 'helm search' 등의 명령에서 사용된다. 원하는 저장소만 지정하여 업데이트할 수도 있다. $ helm repo update ... 모든 저장소를 업데이트하려면 'helm repo update'를 사용한다. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### 옵션 ``` --fail-on-repo-update-fail 저장소 중 하나라도 업데이트에 실패하면 전체 업데이트 실패로 처리 -h, --help update 명령어에 대한 도움말 --timeout duration 인덱스 파일 다운로드 완료까지 대기 시간 (기본값 2m0s) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결할 때 사용한 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용할 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm repo](./helm_repo.md) - 차트 저장소 추가, 나열, 제거, 업데이트, 인덱스 생성 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- 릴리스를 이전 리비젼으로 롤백한다. ### 개요 이 명령은 릴리스를 이전 리비젼으로 롤백한다. rollback 명령어의 첫 번째 인수는 릴리스의 이름이고, 두 번째 인수는 리비젼(버전) 번호이다. 이 인수를 생략하거나 0으로 설정하면 바로 이전 릴리스로 롤백된다. 리비젼 번호를 보려면 'helm history RELEASE'를 실행한다. ``` helm rollback [REVISION] [flags] ``` ### 옵션 ``` --cleanup-on-fail 롤백이 실패할 때 이 롤백에서 생성된 새 리소스의 삭제를 허용 --dry-run 롤백 모의 실행 --force 필요한 경우 삭제/재생성을 통해 리소스를 강제로 업데이트 -h, --help rollback 명령어에 대한 도움말 --history-max int 릴리스당 저장되는 최대 리비젼 수를 제한. 제한이 없는 경우 0을 사용 (기본값 10) --no-hooks 롤백 중 훅 실행 방지 --recreate-pods 해당되는 경우 리소스에 대해 파드 재시작 수행 --timeout duration 개별 쿠버네티스 작업(예: 훅에 대한 작업)을 기다리는 시간 (기본값 5m0s) --wait 설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 파드, PVC, 서비스, 디플로이먼트, 스테이트풀셋, 레플리카셋의 최소 파드 수가 Ready 상태가 될 때까지 대기. --timeout 만큼 대기 --wait-for-jobs 설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 잡(Job)이 완료될 때까지 대기. --timeout 만큼 대기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용되는 호스트 이름을 사용 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- 차트에서 키워드 검색 ### 개요 검색은 Artifact Hub 및 추가한 리포지토리 등 Helm 차트가 저장되어 있는 다양한 위치에서 차트를 검색하는 기능을 제공한다. search 하위 명령어로 다양한 위치의 차트를 검색할 수 있다. ### 옵션 ``` -h, --help search 명령어에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우 쿠버네티스 API 서버 인증서를 검증하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 미지정 시 서버 연결에 사용한 호스트명 사용 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API 통신 시 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 인덱스 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm](./helm.md) - 쿠버네티스용 Helm 패키지 매니저 * [helm search hub](./helm_search_hub.md) - Artifact Hub 또는 사용자 지정 Hub 인스턴스에서 차트 검색 * [helm search repo](./helm_search_repo.md) - 차트에서 키워드에 대한 리포지토리 검색 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- Artifact Hub 또는 사용자 지정 Hub 인스턴스에서 차트를 검색한다. ### 개요 Artifact Hub 또는 사용자 지정 Hub 인스턴스에서 Helm 차트를 검색한다. Artifact Hub는 공개적으로 사용 가능한 분산 Helm 차트를 포함하여 CNCF 프로젝트의 패키지와 설정을 검색, 설치, 게시할 수 있는 웹 기반 애플리케이션이다. Cloud Native Computing Foundation 샌드박스 프로젝트이며, https://artifacthub.io/ 에서 방문할 수 있다. [KEYWORD] 인수로는 단순 키워드 문자열 또는 따옴표로 묶은 고급 쿼리 옵션을 사용할 수 있다. 고급 쿼리 옵션 문서는 https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search 를 참고한다. 이전 버전의 Helm은 Monocular 인스턴스를 기본 'endpoint'로 사용했으므로, 하위 호환성을 위해 Artifact Hub는 Monocular 검색 API와 호환된다. 마찬가지로 'endpoint' 플래그를 설정할 때 지정된 엔드포인트도 Monocular 호환 검색 API 엔드포인트를 구현해야 한다. Monocular 인스턴스를 'endpoint'로 지정하면 고급 쿼리는 지원되지 않는다. API 상세 정보는 https://github.com/helm/monocular 를 참고한다. ``` helm search hub [KEYWORD] [flags] ``` ### 옵션 ``` --endpoint string 차트 검색을 위한 Hub 인스턴스 (기본값 "https://hub.helm.sh") --fail-on-no-result 결과가 없으면 검색 실패 처리 -h, --help hub 명령어에 대한 도움말 --list-repo-url 차트 리포지토리 URL 출력 --max-col-width uint 출력 테이블의 최대 열 너비 (기본값 50) -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우 쿠버네티스 API 서버 인증서를 검증하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 미지정 시 서버 연결에 사용한 호스트명 사용 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API 통신 시 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 인덱스 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm search](./helm_search.md) - 차트에서 키워드 검색 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- 차트에서 키워드에 대한 저장소 검색 ### 개요 검색은 시스템에 구성된 모든 저장소를 읽고 일치하는 항목을 찾는다. 이러한 저장소 검색은 시스템에 저장된 메타 데이터를 사용한다. 찾은 차트의 최신 안정 버전을 표시한다. --devel 플래그를 지정하면 출력에 시험판 버전이 포함된다. 버전 제약을 사용하여 검색하려면 --version 을 사용한다. 예: # 키워드 "nginx" 와 일치하는 안정적인 릴리스 버전 검색 $ helm search repo nginx # 시험판 버전을 포함하여 키워드 "nginx" 와 일치하는 릴리스 버전 검색 $ helm search repo nginx --devel # 주 버전이 1인 nginx-ingress 의 최신 안정 릴리스 검색 $ helm search repo nginx-ingress --version ^1.0.0 저장소는 'helm repo' 명령어로 관리된다. ``` helm search repo [keyword] [flags] ``` ### 옵션 ``` --devel 개발 버전(알파, 베타 및 릴리스 후보 릴리스)도 사용. 버전 '>0.0.0-0' 에 해당하며 --version이 설정되어 있으면 무시됨 --fail-on-no-result 검색 결과가 없으면 실패 처리 -h, --help repo 명령어에 대한 도움말 --max-col-width uint 출력 테이블의 최대 열 너비 (기본값 50) -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) -r, --regexp 추가한 저장소 검색에 정규식 사용 --version string 추가한 저장소에 유의적 버전 제약을 사용하여 검색 -l, --versions 추가한 저장소에 대해 각 차트의 각 버전을 한 줄씩 긴 목록으로 표시 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm search](./helm_search.md) - 차트에서 키워드 검색 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- 차트의 정보를 표시한다 ### 개요 이 명령어는 차트에 대한 정보를 표시하는 여러 하위 명령어들로 구성된다 ### 옵션 ``` -h, --help show 에 대한 도움말 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 Helm 패키지 매니저 * [helm show all](./helm_show_all.md) - 차트의 모든 정보를 표시 * [helm show chart](./helm_show_chart.md) - 차트의 정의를 표시 * [helm show crds](./helm_show_crds.md) - 차트의 CRD를 표시 * [helm show readme](./helm_show_readme.md) - 차트의 README를 표시 * [helm show values](./helm_show_values.md) - 차트의 값을 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- 차트의 모든 정보를 표시한다 ### 개요 이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고 모든 내용을 표시한다. (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### 옵션 ``` --ca-file string CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨 -h, --help all 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인을 건너뜀 --key-file string SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --repo string 요청된 차트를 찾을 수 있는 차트 리포지토리 URL --username string 요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름 --verify 패키지를 사용하기 전에 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm show](./helm_show.md) - 차트의 정보를 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- 차트의 정의를 표시한다 ### 개요 이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, Chart.yaml 파일의 내용을 표시한다. ``` helm show chart [CHART] [flags] ``` ### 옵션 ``` --ca-file string CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨 -h, --help chart 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인을 건너뜀 --key-file string SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --repo string 요청된 차트를 찾을 수 있는 차트 리포지토리 URL --username string 요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름 --verify 패키지를 사용하기 전에 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm show](./helm_show.md) - 차트의 정보를 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- 차트의 CRD를 표시한다 ### 개요 이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, CustomResourceDefinition 파일의 내용을 표시한다. ``` helm show crds [CHART] [flags] ``` ### 옵션 ``` --ca-file string CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨 -h, --help crds 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인을 건너뜀 --key-file string SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --repo string 요청된 차트를 찾을 수 있는 차트 리포지토리 URL --username string 요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름 --verify 패키지를 사용하기 전에 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm show](./helm_show.md) - 차트의 정보를 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- 차트의 README 파일을 표시한다 ### 개요 이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, README 파일의 내용을 보여준다. ``` helm show readme [CHART] [flags] ``` ### 옵션 ``` --ca-file string CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨 -h, --help readme 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인을 건너뜀 --key-file string SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --repo string 요청된 차트를 찾을 수 있는 차트 리포지토리 URL --username string 요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름 --verify 패키지를 사용하기 전에 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm show](./helm_show.md) - 차트의 정보를 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- 차트의 값을 표시한다 ### 개요 이 명령어는 차트(디렉터리, 파일 또는 URL)를 검사하고, values.yaml 파일의 내용을 보여준다. ``` helm show values [CHART] [flags] ``` ### 옵션 ``` --ca-file string CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version 이 설정되면 무시됨 -h, --help values 에 대한 도움말 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 확인을 건너뜀 --jsonpath string 출력을 필터링하기 위한 JSONPath 표현식 제공 --key-file string SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개 키의 위치 (기본값 "~/.gnupg/pubring.gpg") --pass-credentials 모든 도메인에 자격 증명을 전달 --password string 요청된 차트를 찾을 수 있는 차트 리포지토리 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --repo string 요청된 차트를 찾을 수 있는 차트 리포지토리 URL --username string 요청된 차트를 찾을 수 있는 차트 리포지토리 사용자 이름 --verify 패키지를 사용하기 전에 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건을 지정. 특정 태그(예: 1.1.1) 또는 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정되지 않으면 최신 버전이 사용됨 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm show](./helm_show.md) - 차트의 정보를 표시 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- 명명된 릴리스의 상태를 표시한다 ### 개요 이 명령어는 명명된 릴리스의 상태를 표시한다. 상태는 다음으로 구성된다: - 마지막 배포 시간 - 릴리스가 있는 k8s 네임스페이스 - 릴리스의 상태 (가능한 값: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback) - 릴리스의 리비전 - 릴리스의 설명 (완료 메시지 또는 오류 메시지일 수 있으며, --show-desc 옵션 필요) - 이 릴리스를 구성하는 리소스 목록 (--show-resources 옵션 필요) - 해당되는 경우, 마지막 테스트 스위트 수행에 관한 세부 정보 - 차트에서 제공하는 추가 참고 사항 ``` helm status RELEASE_NAME [flags] ``` ### 옵션 ``` -h, --help helm status 에 대한 도움말 -o, --output format 지정된 형식으로 결과를 표시한다. 허용되는 값: table, json, yaml (기본값 table) --revision int 설정된 경우, 해당 리비전의 명명된 릴리스 상태를 표시한다 --show-desc 설정된 경우, 명명된 릴리스의 설명 메시지를 표시한다 --show-resources 설정된 경우, 명명된 릴리스의 리소스를 표시한다 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹 지정. 여러 그룹 지정 시 이 플래그를 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용되는 서버 이름. 제공되지 않으면 서버 접속에 사용된 호스트명이 사용된다 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스팅 제외) --registry-config string 레지스트리 구성 파일의 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- 로컬에서 템플릿을 렌더링한다. ### 개요 차트 템플릿을 로컬에서 렌더링하고 그 결과를 표시한다. 일반적으로 클러스터 내에서 조회되거나 검색되는 모든 값은 로컬에서 모의 처리된다. 또한 차트 유효성에 대한 서버 측 테스트(예: API 지원 여부)는 수행되지 않는다. ``` helm template [NAME] [CHART] [flags] ``` ### 옵션 ``` -a, --api-versions strings Capabilities.APIVersions에 사용되는 쿠버네티스 API 버전 --atomic 설정된 경우, 설치 프로세스는 실패 시 설치본을 삭제한다. --atomic을 사용하면 --wait 플래그가 자동으로 설정된다 --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트 식별 --create-namespace 릴리스 네임스페이스가 없는 경우 생성 --dependency-update 차트를 설치하기 전에 누락된 종속성을 업데이트 --description string 사용자 정의 설명 추가 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며, --version이 설정된 경우 무시된다 --disable-openapi-validation 설정된 경우, 설치 프로세스는 쿠버네티스 OpenAPI 스키마에 대해 렌더링된 템플릿의 유효성 검사를 수행하지 않는다 --dry-run string[="client"] 설치를 시뮬레이션한다. --dry-run을 옵션 없이 설정하거나 '--dry-run=client'로 설정하면 클러스터 연결을 시도하지 않는다. '--dry-run=server'를 설정하면 클러스터 연결을 시도할 수 있다. --enable-dns 템플릿 렌더링 시 DNS 조회 활성화 --force 교체 전략을 통해 리소스 업데이트를 강제 수행 -g, --generate-name 이름을 생성한다 (NAME 매개변수 생략) -h, --help template 명령어에 대한 도움말 --hide-notes 설정된 경우, 설치 출력에 노트를 표시하지 않는다. 차트 메타데이터의 존재에는 영향을 미치지 않는다 --include-crds 템플릿 출력에 CRD 포함 --insecure-skip-tls-verify 차트 다운로드 시 TLS 인증서 검사 건너뛰기 --is-upgrade .Release.IsInstall 대신 .Release.IsUpgrade 설정 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 검증에 사용되는 공개 키 위치 (기본값 "~/.gnupg/pubring.gpg") --kube-version string Capabilities.KubeVersion에 사용되는 쿠버네티스 버전 -l, --labels stringToString 릴리스 메타데이터에 추가될 레이블. 쉼표로 구분한다. (기본값 []) --name-template string 릴리스 이름 지정에 사용되는 템플릿 지정 --no-hooks 설치 중 훅 실행 방지 --output-dir string 실행된 템플릿을 표준 출력 대신 지정된 출력 디렉터리의 파일에 작성 --pass-credentials 모든 도메인에 자격 증명 전달 --password string 요청된 차트를 찾을 차트 리포지토리의 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --post-renderer postRendererString 포스트 렌더링에 사용될 실행 파일 경로. $PATH에 있으면 바이너리가 사용되고, 그렇지 않으면 주어진 경로에서 실행 파일을 찾는다 --post-renderer-args postRendererArgsSlice 포스트 렌더러에 전달할 인수 (여러 개 지정 가능) (기본값 []) --release-name 출력 디렉터리 경로에 릴리스 이름 사용 --render-subchart-notes 설정된 경우, 상위 차트와 함께 하위 차트 노트를 렌더링 --replace 해당 이름이 기록에 남아있는 삭제된 릴리스인 경우에만 주어진 이름을 재사용. 운영 환경에서는 안전하지 않다 --repo string 요청된 차트를 찾을 차트 리포지토리 URL --set stringArray 명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=val1,key2=val2) --set-file stringArray 명령줄에서 지정한 파일에서 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=path1,key2=path2) --set-json stringArray 명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=jsonval1,key2=jsonval2) --set-literal stringArray 명령줄에서 리터럴 STRING 값 설정 --set-string stringArray 명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값 지정 가능: key1=val1,key2=val2) -s, --show-only stringArray 주어진 템플릿에서 렌더링된 매니페스트만 표시 --skip-crds 설정된 경우, CRD를 설치하지 않는다. 기본적으로 CRD가 없으면 설치된다 --skip-schema-validation 설정된 경우, JSON 스키마 유효성 검사를 비활성화한다 --skip-tests 템플릿 출력에서 테스트 건너뛰기 --take-ownership 설정된 경우, 설치 시 헬름 어노테이션 확인을 무시하고 기존 리소스의 소유권을 가져온다 --timeout duration 개별 쿠버네티스 작업(예: 훅에 대한 Job)을 기다리는 시간 (기본값 5m0s) --username string 요청된 차트를 찾을 차트 리포지토리의 사용자 이름 --validate 현재 가리키는 쿠버네티스 클러스터에 대해 매니페스트의 유효성을 검사한다. 설치 시 수행되는 것과 동일한 유효성 검사이다 -f, --values strings YAML 파일 또는 URL에 값 지정 (여러 개 지정 가능) --verify 사용하기 전에 패키지 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건 지정. 특정 태그(예: 1.1.1)이거나 유효한 범위(예: ^2.0.0)를 참조할 수 있다. 지정하지 않으면 최신 버전이 사용된다 --wait 설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 파드, PVC, 서비스, 그리고 Deployment, StatefulSet, ReplicaSet의 최소 파드 수가 Ready 상태가 될 때까지 대기한다. --timeout 시간만큼 대기한다 --wait-for-jobs 설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 대기한다. --timeout 시간만큼 대기한다 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 대해 가장할 그룹. 이 플래그를 반복하여 여러 그룹 지정 가능 --kube-as-user string 작업에 대해 가장할 사용자 이름 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 베어러 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 범위 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 리포지토리 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 리포지토리 이름과 URL이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 함께 보기 * [helm](/helm/helm.md) - 쿠버네티스용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- 릴리스에 대하여 테스트를 수행한다. ### 개요 test 명령어는 릴리스에 대한 테스트를 실행한다. 이 명령어가 받는 인수는 배포된 릴리스의 이름이다. 실행할 테스트는 설치된 차트에 정의되어 있다. ``` helm test [RELEASE] [flags] ``` ### 옵션 ``` --filter strings attribute=value 구문 또는 '!attribute=value'를 사용하여 속성(현재는 "name")으로 테스트 지정 (제외하려면 !를 사용하고, 쉼표로 구분하거나 여러 번 지정 가능: name=test1,name=test2) -h, --help helm test 에 대한 도움말 --hide-notes 설정된 경우, 테스트 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향 없음 --logs 테스트 파드에서 로그를 덤프 (모든 테스트가 완료된 후 정리 전에 실행) --timeout duration 개별 쿠버네티스 작업(예: 훅에 대한 작업)을 기다리는 시간 제한 (기본값 5m0s) ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업에 관해 제시할 그룹. 플래그를 여러 번 사용하여 여러 그룹 지정 가능 --kube-as-user string 작업에 관해 제시할 사용자명 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 제공되지 않으면 서버에 연결하는 데 사용된 호스트명이 사용됨 --kube-token string 인증에 사용될 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 이 요청에 대한 네임스페이스 스코프 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일에 대한 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL 을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- 릴리스 삭제 ### 개요 이 명령어는 릴리스 이름을 사용하여 릴리스를 삭제한다. 차트의 마지막 릴리스와 관련된 모든 리소스 및 릴리스 내역을 제거하여 나중에 다시 사용할 수 있도록 해제한다. 실제 삭제를 수행하지 않고 어떤 릴리스가 삭제될지 확인하려면 '--dry-run' 플래그를 사용한다. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### 옵션 ``` --cascade string "background", "orphan", 또는 "foreground" 중 하나. 종속 항목의 삭제 전략을 선택한다. 기본값은 background. (기본값 "background") --description string 사용자 정의 설명 추가 --dry-run 삭제 시뮬레이션 -h, --help uninstall 명령어에 대한 도움말 --ignore-not-found "릴리스를 찾을 수 없음"을 성공적인 삭제로 처리 --keep-history 모든 관련 리소스를 제거하고 릴리스를 삭제됨으로 표시하지만 릴리스 내역은 유지 --no-hooks 삭제 중 훅(hook) 실행 방지 --timeout duration 개별 쿠버네티스 작업(예: 훅을 위한 작업)을 기다리는 시간 (기본값 5m0s) --wait 설정된 경우, 반환하기 전에 모든 리소스가 삭제될 때까지 대기한다. --timeout에 지정된 시간 동안 대기 ``` ### 상위 명령에서 상속된 옵션 ``` --burst-limit int 클라이언트 측 기본 스로틀링 제한 (기본값 100) --debug 상세 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹으로 가장. 여러 그룹을 지정하려면 이 플래그를 반복 사용 --kube-as-user string 작업을 수행할 사용자로 가장 --kube-ca-file string 쿠버네티스 API 서버 연결용 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않는다. 이 경우 HTTPS 연결이 안전하지 않게 된다 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 유효성 검사에 사용할 서버 이름. 제공되지 않은 경우, 서버에 연결하는 데 사용된 호스트 이름이 사용된다 --kube-token string 인증에 사용할 bearer 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 범위 --qps float32 버스트를 제외한 쿠버네티스 API와의 통신에 사용되는 초당 쿼리 수 --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL이 포함된 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스용 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- 릴리스를 업그레이드한다. ### 개요 이 명령어는 릴리스를 새 버전의 차트로 업그레이드한다. 업그레이드 시 사용되는 인수는 릴리스 및 차트여야 한다. 차트 인수는 차트 참조('example/mariadb'), 차트 디렉터리 경로, 패키지 차트 또는 정규화된 URL 중 하나일 수 있다. 차트 참조 시 '--version' 플래그가 설정되지 않았을 경우 최신 버전이 지정된다. 차트의 값을 재정의하려면 '--values' 플래그를 사용하고 파일을 전달하거나 '--set' 플래그를 사용하고 명령줄에서 구성을 전달한다. 문자열 값을 강제하려면 '--set-string'을 사용한다. 값 자체가 명령줄에 사용하기엔 너무 길거나 동적으로 생성되는 경우 '--set-file'을 사용하여 파일에서 개별 값을 설정할 수 있다. '--set-json'을 사용하여 명령줄에서 JSON 값(스칼라/객체/배열)을 설정할 수도 있다. '--values'/'-f' 플래그를 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 파일에 우선 순위가 부여된다. 예를 들어 myvalues.yaml과 override.yaml에 'Test'라는 키가 포함된 경우 override.yaml에 설정된 값이 우선한다. $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis '--set' 플래그도 여러 번 지정할 수 있다. 지정된 마지막(가장 오른쪽) 세트에 우선 순위가 부여된다. 예를 들어 'foo'라는 키에 대해 'bar'와 'newbar'에서 값이 모두 설정된 경우 'newbar'가 우선한다. $ helm upgrade --set foo=bar --set foo=newbar redis ./redis '--reuse-values' 플래그를 사용하여 기존 릴리스의 값을 업데이트할 수도 있다. 'RELEASE'와 'CHART' 인수는 원래 매개변수로 설정해야 하며, 기존 값은 '--values'/'-f' 또는 '--set' 플래그를 통해 설정된 값과 병합된다. 새 값에 우선 순위가 부여된다. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis --dry-run 플래그는 민감한 값을 포함할 수 있는 Secret을 포함하여 생성된 모든 차트 매니페스트를 출력한다. Kubernetes Secret을 숨기려면 --hide-secret 플래그를 사용한다. 이러한 플래그를 사용하는 방법과 시기를 신중하게 고려해야 한다. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### 옵션 ``` --atomic 설정된 경우, 업그레이드 실패 시 변경 사항을 롤백. --atomic을 사용하면 --wait 플래그가 자동으로 설정 --ca-file string 이 CA 번들을 사용하여 HTTPS 사용 서버의 인증서를 확인 --cert-file string 이 SSL 인증서 파일을 사용하여 HTTPS 클라이언트를 식별 --cleanup-on-fail 업그레이드 실패 시, 이 업그레이드에서 생성된 새 리소스 삭제를 허용 --create-namespace --install이 설정된 경우 릴리스 네임스페이스가 없으면 생성 --dependency-update 차트를 설치하기 전에 종속성이 누락된 경우 업데이트 --description string 사용자 정의 설명을 추가 --devel 개발 버전도 사용. 버전 '>0.0.0-0'에 해당하며 --version이 설정되어 있으면 무시 --disable-openapi-validation 설정된 경우, 업그레이드 프로세스는 쿠버네티스 OpenAPI 스키마에 대해 렌더링된 템플릿의 유효성 검사 미수행 --dry-run string[="client"] 설치를 시뮬레이션. --dry-run이 옵션 없이 설정되거나 '--dry-run=client'로 설정되면 클러스터 연결을 시도하지 않음. '--dry-run=server'로 설정하면 클러스터 연결을 시도 --enable-dns 템플릿 렌더링 시 DNS 조회 활성화 --force 대체 전략을 통해 리소스 강제 업데이트 -h, --help upgrade 명령어에 대한 도움말 --hide-notes 설정된 경우, 업그레이드 출력에 notes를 표시하지 않음. 차트 메타데이터에는 영향 없음 --hide-secret --dry-run 플래그와 함께 사용 시 Kubernetes Secret을 숨김 --history-max int 릴리스당 저장되는 최대 리비전 수를 제한. 0은 무제한 (기본값 10) --insecure-skip-tls-verify 차트 다운로드를 위한 TLS 인증서 검사 건너뛰기 -i, --install 이 이름의 릴리스가 아직 없는 경우 설치 수행 --key-file string 이 SSL 키 파일을 사용하여 HTTPS 클라이언트 식별 --keyring string 확인에 사용되는 공개키의 위치 (기본값 "~/.gnupg/pubring.gpg") -l, --labels stringToString 릴리스 메타데이터에 추가될 레이블. 쉼표로 구분해야 함. 원래 릴리스 레이블이 업그레이드 레이블과 병합됨. null을 사용하여 레이블 해제 가능 (기본값 []) --no-hooks 사전/사후 업그레이드 훅 비활성화 -o, --output format 지정된 형식으로 출력. 허용되는 값: table, json, yaml (기본값 table) --pass-credentials 모든 도메인에 자격 증명 전달 --password string 요청된 차트를 찾을 수 있는 차트 저장소 비밀번호 --plain-http 차트 다운로드에 안전하지 않은 HTTP 연결 사용 --post-renderer postRendererString 포스트 렌더링에 사용될 실행 파일의 경로. $PATH에 있으면 바이너리가 사용되며 그렇지 않은 경우 주어진 경로에서 실행 파일을 탐색 --post-renderer-args postRendererArgsSlice 포스트 렌더러에 대한 인수 (여러 개 지정 가능) (기본값 []) --render-subchart-notes 설정된 경우, 상위 차트와 함께 하위 차트 notes도 렌더링 --repo string 요청된 차트를 찾을 수 있는 차트 저장소 URL --reset-then-reuse-values 업그레이드 할 때, 값을 차트에 내장된 값으로 재설정하고, 마지막 릴리스의 값을 적용한 다음 명령줄의 --set 및 -f를 통한 재정의와 병합. '--reset-values' 또는 '--reuse-values'가 지정되면 무시 --reset-values 업그레이드 할 때, 값을 차트에 내장된 값으로 재설정 --reuse-values 업그레이드 할 때, 마지막 릴리스의 값을 재사용하고 --set 및 -f를 통해 명령줄에서 재정의를 병합. '--reset-values'가 지정되면 무시 --set stringArray 명령줄에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2) --set-file stringArray 명령줄을 통해 지정된 각 파일에서 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=path1,key2=path2) --set-json stringArray 명령줄에서 JSON 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=jsonval1,key2=jsonval2) --set-literal stringArray 명령줄에서 리터럴 STRING 값 설정 --set-string stringArray 명령줄에서 STRING 값 설정 (쉼표로 여러 값 또는 개별 값을 지정 가능: key1=val1,key2=val2) --skip-crds 설정된 경우, 설치 플래그가 활성화된 상태에서 업그레이드를 수행할 때 CRD 미설치. 기본적으로 설치 플래그가 활성화된 상태에서 업그레이드가 수행될 때 CRD가 없으면 설치 --skip-schema-validation 설정된 경우, JSON 스키마 유효성 검사 비활성화 --take-ownership 설정된 경우, 업그레이드는 helm 어노테이션 검사를 무시하고 기존 리소스의 소유권을 가져옴 --timeout duration 개별 쿠버네티스 작업(훅에 대한 Job 등)을 기다리는 시간 (기본값 5m0s) --username string 요청된 차트를 찾을 수 있는 차트 저장소 사용자 이름 -f, --values strings YAML 파일 또는 URL에 값 지정 (여러 개 지정 가능) --verify 사용하기 전에 패키지 확인 --version string 사용할 차트 버전에 대한 버전 제약 조건 지정. 이 제약 조건은 특정 태그(예: 1.1.1)이거나 유효한 범위(예: ^2.0.0)를 참조할 수 있음. 지정하지 않으면 최신 버전 사용 --wait 설정된 경우, 릴리스를 성공으로 표시하기 전에 모든 Pod, PVC, Service, 및 Deployment, StatefulSet 또는 ReplicaSet의 최소 Pod 수가 준비 상태가 될 때까지 대기. --timeout으로 설정된 시간까지 대기 --wait-for-jobs 설정되고 --wait가 활성화된 경우, 릴리스를 성공으로 표시하기 전에 모든 Job이 완료될 때까지 대기. --timeout으로 설정된 시간까지 대기 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름을 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용 --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- 주어진 경로의 차트가 서명되었고 유효한지 확인한다. ### 개요 주어진 차트에 유효한 출처(provenance) 파일이 있는지 검증한다. 출처 파일은 차트가 변조되지 않았으며 신뢰할 수 있는 공급자가 패키징했다는 암호화 검증을 제공한다. 이 명령어는 로컬 차트를 검증하는 데 사용할 수 있다. 다른 여러 명령어는 동일한 유효성 검사를 실행하는 '--verify' 플래그를 제공한다. 서명된 패키지를 생성하려면 'helm package --sign' 명령어를 사용한다. ``` helm verify PATH [flags] ``` ### 옵션 ``` -h, --help verify에 대한 도움말 --keyring string 공개 키를 포함하는 키링(keyring) (기본값 "~/.gnupg/pubring.gpg") ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름을 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용 --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 색인이 포함된 디렉터리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스에 대한 Helm 패키지 매니저 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- 클라이언트 버전 정보를 출력한다. ### 개요 헬름의 버전을 표시한다. 이 명령어는 헬름 버전을 특정 형식으로 출력한다. 출력 결과는 대략 다음과 같을 것이다. version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version은 릴리스의 유의적(semantic) 버전이다. - GitCommit은 이 버전이 빌드된 커밋의 SHA 값이다. - GitTreeState는 이 바이너리를 빌드할 때 로컬 코드 변경이 없었으면 "clean"이고, 로컬에서 수정된 코드로 빌드한 바이너리이면 "dirty"이다. - GoVersion은 헬름을 컴파일할 때 사용된 Go 버전이다. --template 플래그를 사용하면 템플릿에서 다음 속성을 사용할 수 있다: - .Version은 헬름의 유의적 버전을 포함한다. - .GitCommit은 깃 커밋을 의미한다. - .GitTreeState는 헬름이 빌드되었을 때 깃 트리의 상태이다. - .GoVersion은 헬름이 컴파일된 Go 버전을 포함한다. 예: --template='Version: {{.Version}}'은 'Version: v3.2.1'을 출력한다. ``` helm version [flags] ``` ### 옵션 ``` -h, --help version에 대한 도움말 --short 버전 번호만 출력 --template string 버전 문자열 형식에 대한 템플릿 ``` ### 부모 명령어에서 상속된 옵션들 ``` --burst-limit int 클라이언트 측 기본 쓰로틀링 제한 (기본값 100) --debug 장황한(verbose) 출력 활성화 --kube-apiserver string 쿠버네티스 API 서버의 주소 및 포트 --kube-as-group stringArray 작업을 수행할 그룹을 지정. 이 플래그는 여러 그룹을 지정하기 위해 반복 사용 가능 --kube-as-user string 작업을 수행할 사용자 이름을 지정 --kube-ca-file string 쿠버네티스 API 서버 연결을 위한 인증 기관 파일 --kube-context string 사용할 kubeconfig 컨텍스트 이름 --kube-insecure-skip-tls-verify true인 경우, 쿠버네티스 API 서버의 인증서 유효성을 검사하지 않음. HTTPS 연결이 안전하지 않게 됨 --kube-tls-server-name string 쿠버네티스 API 서버 인증서 검증에 사용할 서버 이름. 지정하지 않으면 서버에 연결할 때 사용한 호스트 이름을 사용 --kube-token string 인증에 사용할 베어러(bearer) 토큰 --kubeconfig string kubeconfig 파일 경로 -n, --namespace string 요청에 대한 네임스페이스 지정 --qps float32 쿠버네티스 API와 통신할 때 사용되는 초당 쿼리 수 (버스트 제외) --registry-config string 레지스트리 구성 파일 경로 (기본값 "~/.config/helm/registry/config.json") --repository-cache string 캐시된 저장소 인덱스가 포함된 디렉토리 경로 (기본값 "~/.cache/helm/repository") --repository-config string 저장소 이름 및 URL을 포함하는 파일 경로 (기본값 "~/.config/helm/repositories.yaml") ``` ### 참조 * [helm](./helm.md) - 쿠버네티스를 위한 헬름 패키지 매니저. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: 헬름 명령어 description: 헬름 CLI 명령어 전체 목록 문서 sidebar_position: 6 id: helm-category --- # 헬름 명령어 이곳에서 헬름 CLI 명령어 목록을 찾고, 그 사용법 정보를 얻을 수 있다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action으로 GitHub Pages 차트 릴리스 자동화하기 description: Chart Releaser Action을 사용하여 GitHub Pages를 통해 차트 릴리스를 자동화하는 방법을 설명합니다. sidebar_position: 3 --- 이 가이드는 [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser)을 사용하여 GitHub Pages를 통해 차트 릴리스를 자동화하는 방법을 설명합니다. Chart Releaser Action은 [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI 도구를 활용하여 GitHub 프로젝트를 자체 호스팅 Helm 차트 리포지토리로 전환해 주는 GitHub Action 워크플로우입니다. ## 리포지토리 설정 GitHub 조직 아래에 Git 리포지토리를 생성합니다. 리포지토리 이름은 `helm-charts`로 지정할 수 있지만, 다른 이름도 사용 가능합니다. 모든 차트의 소스는 `main` 브랜치에 배치할 수 있습니다. 차트는 최상위 `/charts` 디렉터리에 위치해야 합니다. 차트를 게시하려면 `gh-pages`라는 이름의 별도 브랜치가 필요합니다. 이 브랜치에 대한 변경 사항은 Chart Releaser Action이 자동으로 생성합니다. 단, 해당 `gh-pages` 브랜치를 직접 생성하고 `README.md` 파일을 추가할 수도 있으며, 이 파일은 페이지 방문자에게 표시됩니다. `README.md`에 다음과 같은 차트 설치 안내를 추가할 수 있습니다(``, ``, ``을 실제 값으로 바꿔주세요): ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` 차트는 다음과 같은 URL의 웹사이트에 게시됩니다: https://.github.io/helm-charts ## GitHub Actions 워크플로우 `main` 브랜치의 `.github/workflows/release.yml` 경로에 GitHub Actions 워크플로우 파일을 생성합니다. ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` 위 설정은 [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action)을 사용하여 GitHub 프로젝트를 자체 호스팅 Helm 차트 리포지토리로 전환합니다. main 브랜치에 푸시할 때마다 프로젝트의 각 차트를 확인하고, 새로운 차트 버전이 발견되면 해당 버전 이름으로 GitHub 릴리스를 생성합니다. 그런 다음 Helm 차트 아티팩트를 릴리스에 추가하고, 릴리스 메타데이터가 포함된 `index.yaml` 파일을 생성하거나 업데이트합니다. 이 파일은 GitHub Pages에서 호스팅됩니다. 위 예제에서 사용된 Chart Releaser Action 버전은 `v1.6.0`입니다. [최신 버전](https://github.com/helm/chart-releaser-action/releases)으로 변경할 수 있습니다. 참고: Chart Releaser Action은 거의 항상 [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) 및 [Kind Action](https://github.com/marketplace/actions/kind-cluster)과 함께 사용됩니다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: 차트 리포지토리 동기화 description: 로컬 및 원격 차트 리포지토리를 동기화하는 방법 sidebar_position: 2 --- *참고: 이곳의 예제들은 차트 리포지토리를 제공하는* *Google Cloud Storage (GCS) 버킷에 맞게 작성되었다.* ## 전제 조건 * [gsutil](https://cloud.google.com/storage/docs/gsutil) 툴을 설치해야 한다. *gsutil rsync 기능이 필요하다.* * 헬름 바이너리에 대한 접근 권한이 있어야 한다. * _선택 사항: 실수로 파일을 삭제할 경우를 대비하여 GCS 버킷에 [오브젝트 버전 관리](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)를 설정하는 것을 추천한다._ ## 로컬 차트 리포지토리 디렉터리 설정 [차트 리포지토리 가이드](/topics/chart_repository.md)에서 한 것처럼 로컬 디렉터리를 만들고, 패키지된 차트를 그 디렉터리로 옮긴다. 예제: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## 업데이트 된 index.yaml 생성 다음과 같이 `helm repo index` 헬름 명령어에 원격 리포지토리의 디렉터리 경로와 URL을 전달하여 업데이트된 index.yaml 파일을 생성한다. ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` 그러면 업데이트된 index.yaml 파일이 생성되고 `fantastic-charts/` 디렉터리에 위치하게 된다. ## 로컬 및 원격 차트 리포지토리 동기화 `scripts/sync-repo.sh` 명령어에 로컬 디렉터리명과 GCS 버킷명을 전달하여 디렉터리 컨텐츠를 GCS 버킷에 업로드한다. 예제: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## 차트 리포지토리 업데이트 필요시 차트 리포지토리 컨텐츠의 로컬 복사본을 따로 보관하거나 `gsutil rsync` 를 사용하여 원격 차트 리포지토리 컨텐츠를 로컬 디렉터리에 복사해 둘 수 있다. 예제: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` 유용한 링크: * [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) 에 대한 문서 * [차트 리포지토리 가이드](/topics/chart_repository.md) * Google Cloud Storage의 [오브젝트 버전 관리 및 동시성 제어](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview)에 대한 문서 ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: 차트 개발 팁과 비법 description: 헬름 차트 개발자들이 프로덕션 수준의 차트를 만들면서 배운 팁과 비법을 다룹니다. sidebar_position: 1 --- 이 가이드는 헬름 차트 개발자들이 프로덕션 수준의 차트를 만들면서 배운 팁과 비법을 담고 있습니다. ## 템플릿 함수 이해하기 헬름은 리소스 파일의 템플릿을 위해 [Go 템플릿](https://godoc.org/text/template)을 사용합니다. Go는 여러 가지 내장 함수를 제공하지만, 헬름은 많은 추가 함수들을 제공합니다. 먼저 [Sprig 라이브러리](https://masterminds.github.io/sprig/)에 있는 모든 함수를 추가했습니다. 보안상의 이유로 `env`와 `expandenv`는 제외됩니다. 그리고 두 가지 특별한 템플릿 함수인 `include`와 `required`를 추가했습니다. `include` 함수는 다른 템플릿을 불러오고, 그 결과를 다른 템플릿 함수에 전달할 수 있게 해줍니다. 예를 들어, 이 템플릿 조각은 `mytpl`이라는 템플릿을 포함한 후, 결과를 소문자로 변환하고, 그것을 큰따옴표로 감쌉니다. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` `required` 함수는 템플릿 렌더링을 위해 특정 값 항목이 필수임을 선언할 수 있게 해줍니다. 만약 값이 비어있다면, 템플릿 렌더링은 사용자가 제출한 오류 메시지와 함께 실패하게 됩니다. 다음은 `required` 함수의 예시로, `.Values.who` 항목이 필수로 선언되며, 해당 항목이 없을 경우 오류 메시지를 출력합니다: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## 문자열에는 따옴표를 쓰고, 정수형에는 쓰지 말자 문자열 데이터를 사용할 때에는 문자열을 그대로 두기보다 쌍따옴표로 값을 묶는 것이 안전합니다: ```yaml name: {{ .Values.MyName | quote }} ``` 하지만 정수형의 경우 많은 경우에 쿠버네티스에서 파싱 에러가 발생할 수 있으니 _쌍따옴표를 사용하지 마세요._ ```yaml port: {{ .Values.Port }} ``` 이 내용은 env 변수 값에는 적용되지 않습니다. 정수를 나타내더라도 문자열로 처리되어야 합니다: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## 'include' 함수 사용하기 Go 언어의 내장 지시어인 `template`를 사용해 다른 템플릿으로부터 템플릿을 가져올 수 있습니다. 하지만 이 지시어는 Go 템플릿 파이프라인과는 함께 사용할 수 없습니다. 헬름에는 특별한 함수 `include`가 있습니다. 이 함수는 다른 템플릿을 가져오고 그 템플릿의 출력 값에 연산을 수행할 수 있도록 합니다: ``` {{ include "toYaml" $value | indent 2 }} ``` 위의 예제에는 `toYaml`이라고 불리는 템플릿이 포함되어 있습니다. 이 템플릿은 `$value`에 값을 전달하고 그 출력 값을 `indent` 함수에 전달합니다. YAML이 들여쓰기와 공백을 중요하게 생각하기 때문에 이 방법은 문맥에 맞는 적절한 들여쓰기를 하면서 코드 스니펫을 가져올 수 있는 좋은 방법입니다. ## 'required' 함수 사용하기 Go 언어는 map에 존재하지 않는 키에 접근하는 상황을 제어하기 위한 템플릿 옵션이 있습니다. 주로 `template.Options("missingkey=option")`로 설정되며 `option` 값은 `default`, `zero` 혹은 `error`가 될 수 있습니다. 옵션 설정을 error로 하면 map에 존재하지 않는 키에 접근하려는 모든 상황에서 에러를 발생하며 실행을 멈출 것입니다. 차트 개발자가 `values.yaml`의 특정 값에 대해 이러한 규칙을 적용하고 싶은 상황이 있을 수 있습니다. `required` 함수는 개발자가 템플릿 렌더링 시 필수로 입력되어야 하는 값 항목을 선언할 수 있도록 합니다. 이 항목이 `values.yaml`에서 비어있다면, 템플릿은 렌더링되지 않고 개발자가 작성한 에러 메시지를 반환할 것입니다. 예를 들어: ``` {{ required "A valid foo is required!" .Values.foo }} ``` 위의 예제는 `.Values.foo`가 정의되어 있다면 값을 렌더링하고, `.Values.foo`가 정의되어 있지 않다면 렌더링에 실패하고 종료할 것입니다. ## 'tpl' 함수 사용하기 `tpl` 함수를 이용하여 템플릿 내에 정의된 템플릿 형식의 문자열의 렌더링 값을 구할 수 있습니다. 이 함수는 차트에 템플릿 문자열을 변수로 전달하거나 외부 설정 파일들을 렌더링할 때 유용합니다. 문법: `{{ tpl TEMPLATE_STRING VALUES }}` 예를 들어: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` 외부 설정 파일을 렌더링하는 예제: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## 이미지 풀 시크릿 생성하기 이미지 풀 시크릿은 기본적으로 _registry_, _username_, 그리고 _password_의 조합입니다. 앱을 배포하는 데 이 값들이 필요할 수 있지만, 이를 만들기 위해서는 `base64`를 몇 번 실행해야 합니다. 헬퍼 템플릿을 작성하여 시크릿 페이로드로 사용될 Docker 설정 파일을 구성할 수 있습니다. 여기 예제가 있습니다: 먼저 `values.yaml`에 다음과 같은 자격 증명이 정의되어 있다고 가정해 봅시다: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` 그 다음, 헬퍼 템플릿을 다음과 같이 정의합니다: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` 마지막으로 더 큰 템플릿에서 헬퍼 템플릿을 사용해 시크릿 매니페스트를 생성합니다: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## 자동 디플로이먼트 롤링 ConfigMap이나 Secret이 컨테이너에 설정 파일로 주입되거나 다른 외부 의존성 변경으로 인해 파드를 롤링해야 하는 경우가 종종 있습니다. 애플리케이션에 따라 후속 `helm upgrade` 시 재시작이 필요할 수 있지만, 디플로이먼트 스펙 자체가 변경되지 않으면 애플리케이션은 이전 설정으로 계속 실행되어 일관성 없는 배포가 발생합니다. `sha256sum` 함수를 사용하여 다른 파일이 변경되면 디플로이먼트의 annotation 섹션이 업데이트되도록 할 수 있습니다: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTE: 라이브러리 차트에 이것을 추가하는 경우 `$.Template.BasePath`에서 파일에 접근할 수 없습니다. 대신 `{{ include ("mylibchart.configmap") . | sha256sum }}`과 같이 정의를 참조할 수 있습니다. 항상 디플로이먼트를 롤링하고 싶다면, 위와 비슷한 annotation 단계를 사용하되 랜덤 문자열로 대체하여 항상 변경되고 디플로이먼트가 롤링되도록 할 수 있습니다: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` 템플릿 함수를 호출할 때마다 고유한 랜덤 문자열이 생성됩니다. 즉, 여러 리소스에서 사용하는 랜덤 문자열을 동기화해야 하는 경우, 관련된 모든 리소스가 동일한 템플릿 파일에 있어야 합니다. 이 두 가지 방법 모두 디플로이먼트가 내장된 업데이트 전략 로직을 활용하여 다운타임을 방지할 수 있습니다. NOTE: 과거에는 `--recreate-pods` 플래그를 다른 옵션으로 권장했습니다. 이 플래그는 위의 더 선언적인 방법을 위해 Helm 3에서 deprecated 되었습니다. ## 헬름에 리소스를 삭제하지 않도록 알리기 `helm uninstall`을 실행할 때 삭제되지 않아야 하는 리소스가 있을 수 있습니다. 차트 개발자는 리소스에 annotation을 추가하여 삭제되지 않도록 할 수 있습니다. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` `helm.sh/resource-policy: keep` annotation은 헬름 작업(`helm uninstall`, `helm upgrade` 또는 `helm rollback`)으로 인해 이 리소스가 삭제될 때 헬름이 삭제를 건너뛰도록 지시합니다. _하지만_ 이 리소스는 고아 상태가 됩니다. 헬름은 더 이상 어떤 방식으로도 이 리소스를 관리하지 않습니다. 이미 제거되었지만 리소스는 유지된 릴리스에 `helm install --replace`를 사용하면 문제가 발생할 수 있습니다. ## "Partials" 및 템플릿 포함 사용하기 차트에서 재사용 가능한 부분을 만들고 싶을 때가 있습니다. 블록이든 템플릿 partial이든 말입니다. 그리고 종종 이것들을 별도의 파일에 보관하는 것이 더 깔끔합니다. `templates/` 디렉터리에서 밑줄(`_`)로 시작하는 파일은 쿠버네티스 매니페스트 파일을 출력하지 않습니다. 따라서 관례적으로 헬퍼 템플릿과 partial은 `_helpers.tpl` 파일에 배치합니다. ## 의존성이 많은 복잡한 차트 CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에 있는 많은 차트들은 더 고급 애플리케이션을 만들기 위한 "빌딩 블록"입니다. 하지만 차트는 대규모 애플리케이션의 인스턴스를 만드는 데 사용될 수도 있습니다. 이러한 경우, 단일 우산(umbrella) 차트가 여러 서브차트를 가질 수 있으며, 각 서브차트는 전체의 일부로 기능합니다. 개별 부분들로 복잡한 애플리케이션을 구성하는 현재 모범 사례는 글로벌 설정을 노출하는 최상위 우산 차트를 만들고, `charts/` 하위 디렉터리를 사용하여 각 컴포넌트를 포함시키는 것입니다. ## YAML은 JSON의 상위집합이다 YAML 명세에 따르면, YAML은 JSON의 상위집합입니다. 즉, 모든 유효한 JSON 구조는 YAML에서도 유효해야 합니다. 이것의 장점이 있습니다: 때때로 템플릿 개발자들은 YAML의 공백 민감성을 다루는 것보다 JSON과 유사한 문법으로 데이터 구조를 표현하는 것이 더 쉽다고 느낄 수 있습니다. 모범 사례로서, 템플릿은 JSON 문법이 포맷팅 문제의 위험을 크게 줄이는 경우가 _아니라면_ YAML과 유사한 문법을 따라야 합니다. ## 랜덤 값을 생성할 때는 주의하자 헬름에는 랜덤 데이터, 암호화 키 등을 생성하는 함수들이 있습니다. 이것들을 사용해도 괜찮습니다. 하지만 업그레이드 중에 템플릿이 다시 실행된다는 점에 유의하세요. 템플릿 실행이 이전 실행과 다른 데이터를 생성하면, 해당 리소스의 업데이트가 트리거됩니다. ## 하나의 명령어로 설치 또는 업그레이드하기 헬름은 설치 또는 업그레이드를 단일 명령으로 수행하는 방법을 제공합니다. `helm upgrade`에 `--install` 플래그를 사용하세요. 이렇게 하면 헬름은 릴리스가 이미 설치되어 있는지 확인합니다. 설치되어 있지 않으면 설치를 실행하고, 설치되어 있으면 기존 릴리스를 업그레이드합니다. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: 사용법 sidebar_position: 2 --- # 사용법 가이드 이곳에서는 “…를 어떻게 하나요.?”와 같은 질문에 대한 짧은 답변들을 찾을 수 있을 것이다. 이 사용법 가이드는 주제를 깊이 있게 다루지는 않으며, 그런 것은 [주제 가이드](/topics/index.mdx)내 자료에서 찾을 수 있을 것이다. 다만, 이곳의 가이드는 일반적인 작업들을 빨리 완수할 수 있게 도움을 줄 것이다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "문서 홈" description: "문서 구성에 관해 알아야 할 모든 것" --- # 환영 [헬름](https://helm.sh/ko) 문서에 온 것을 환영한다. 헬름은 쿠버네티스를 위한 패키지 관리 도구이며, 자세한 배경 지식은 [CNCF 헬름 프로젝트 여정 보고서](https://www.cncf.io/cncf-helm-project-journey/)에서 확인할 수 있다. # 문서 구성 헬름은 많은 문서를 가지고 있다. 구성 방법에 대한 대략의 개요를 보면 무엇을 어디서 찾아볼지를 알 수 있어 도움이 될 것이다. - [튜토리얼](/intro/index.mdx)은 나의 첫번째 차트 만들기 단계별 과정을 통해 이끌어 준다. 헬름이 처음이라면 여기서 시작하자. - [주제 가이드](/topics/index.mdx)는 대략의 핵심 주제와 개념을 다루며 유용한 배경 정보와 설명을 제공한다. - [커뮤니티 가이드](/community)는 헬름 커뮤니터와 관련된 주제를 다룬다. 헬름 자체의 개발 과정이나 기여하는 방법을 알아보려면 여기서 시작하자. - [방법 가이드](/howto/index.mdx)는 일종의 요리법(recipes)이다. 주요 문제 및 사용 사례들을 다루는 절차를 안내한다. 튜토리얼보다 심화된 내용으로서, 헬름이 작동하는 방식에 대한 지식이 어느 정도 있다고 가정한다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: 치트 시트 description: Helm 치트 시트 sidebar_position: 4 --- Helm을 통해 애플리케이션을 관리하는 데 필요한 모든 명령어를 담은 치트 시트입니다. ----------------------------------------------------------------------------------------------------------------------------------------------- ### 기본 해석/맥락 Chart: - pull하여 압축 해제한 차트의 이름입니다. - 저장소는 추가했지만 차트를 pull하지 않은 경우 / 형식입니다. - 차트의 URL 또는 절대 경로입니다. Name: - 현재 Helm 차트 설치에 부여할 이름입니다. Release: - 설치 인스턴스에 할당한 이름입니다. Revision: - Helm history 명령어에서 확인할 수 있는 값입니다. Repo-name: - 저장소의 이름입니다. DIR: - 디렉토리 이름 또는 경로입니다. ------------------------------------------------------------------------------------------------------------------------------------------------ ### 차트 관리 ```bash helm create # 차트에서 사용되는 공통 파일 및 디렉토리와 함께 차트 디렉토리를 생성합니다. helm package # 차트를 버전이 지정된 차트 아카이브 파일로 패키징합니다. helm lint # 차트를 검사하고 가능한 문제를 식별하는 테스트를 실행합니다. helm show all # 차트를 검사하고 내용을 나열합니다. helm show values # values.yaml 파일의 내용을 표시합니다. helm pull # 차트를 다운로드/pull 합니다. helm pull --untar=true # true로 설정하면 다운로드 후 차트 압축을 해제합니다. helm pull --verify # 사용 전에 패키지를 검증합니다. helm pull --version # 기본값은 최신 버전이며, 사용할 차트 버전에 대한 버전 제약을 지정합니다. helm dependency list # 차트의 의존성 목록을 표시합니다. ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### 애플리케이션 설치 및 제거 ```bash helm install # 이름을 지정하여 차트를 설치합니다. helm install --namespace # 특정 네임스페이스에 차트를 설치합니다. helm install --set key1=val1,key2=val2 # 명령줄에서 값을 설정합니다 (여러 값을 쉼표로 구분하여 지정 가능). helm install --values # 지정한 값으로 차트를 설치합니다. helm install --dry-run --debug # 차트를 검증하기 위한 테스트 설치를 실행합니다. helm install --verify # 사용 전에 패키지를 검증합니다. helm install --dependency-update # 차트 설치 전에 누락된 의존성을 업데이트합니다. helm uninstall # 현재(기본) 네임스페이스에서 릴리스를 제거합니다. helm uninstall --namespace # 지정된 네임스페이스에서 릴리스를 제거합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### 애플리케이션 업그레이드 및 롤백 ```bash helm upgrade # 릴리스를 업그레이드합니다. helm upgrade --rollback-on-failure # 설정 시, 업그레이드 실패 시 변경 사항을 롤백합니다. helm upgrade --dependency-update # 차트 설치 전에 누락된 의존성을 업데이트합니다. helm upgrade --version # 사용할 차트 버전에 대한 버전 제약을 지정합니다. helm upgrade --values # YAML 파일 또는 URL로 값을 지정합니다 (여러 개 지정 가능). helm upgrade --set key1=val1,key2=val2 # 명령줄에서 값을 설정합니다 (여러 값 지정 가능). helm upgrade --force # 교체 전략을 통해 리소스를 강제 업데이트합니다. helm rollback # 릴리스를 특정 리비전으로 롤백합니다. helm rollback --cleanup-on-fail # 롤백 실패 시 이 롤백에서 생성된 새 리소스 삭제를 허용합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### 저장소 목록 조회, 추가, 삭제 및 업데이트 ```bash helm repo add # 인터넷에서 저장소를 추가합니다. helm repo list # 추가된 차트 저장소를 나열합니다. helm repo update # 차트 저장소에서 사용 가능한 차트 정보를 로컬에서 업데이트합니다. helm repo remove # 하나 이상의 차트 저장소를 제거합니다. helm repo index # 현재 디렉토리를 읽고 발견된 차트를 기반으로 인덱스 파일을 생성합니다. helm repo index --merge # 생성된 인덱스를 기존 인덱스 파일과 병합합니다. helm search repo # 차트에서 키워드로 저장소를 검색합니다. helm search hub # Artifact Hub 또는 사용자 허브 인스턴스에서 차트를 검색합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm 릴리스 모니터링 ```bash helm list # 지정된 네임스페이스의 모든 릴리스를 나열합니다. 네임스페이스를 지정하지 않으면 현재 네임스페이스 컨텍스트를 사용합니다. helm list --all # 필터 없이 모든 릴리스를 표시합니다. -a 사용 가능합니다. helm list --all-namespaces # 모든 네임스페이스의 릴리스를 나열합니다. -A 사용 가능합니다. helm list -l key1=value1,key2=value2 # 필터링할 셀렉터(레이블 쿼리)입니다. '=', '==', '!='를 지원합니다. helm list --date # 릴리스 날짜로 정렬합니다. helm list --deployed # 배포된 릴리스를 표시합니다. 다른 옵션이 지정되지 않으면 자동으로 활성화됩니다. helm list --pending # 대기 중인 릴리스를 표시합니다. helm list --failed # 실패한 릴리스를 표시합니다. helm list --uninstalled # 제거된 릴리스를 표시합니다 ('helm uninstall --keep-history'를 사용한 경우). helm list --superseded # 대체된 릴리스를 표시합니다. helm list -o yaml # 지정된 형식으로 출력합니다. 허용 값: table, json, yaml (기본값 table). helm status # 지정된 릴리스의 상태를 표시합니다. helm status --revision # 설정 시, 지정된 리비전의 릴리스 상태를 표시합니다. helm history # 지정된 릴리스의 히스토리 리비전을 표시합니다. helm env # Helm에서 사용 중인 모든 환경 정보를 출력합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### 릴리스 정보 다운로드 ```bash helm get all # 지정된 릴리스의 notes, hooks, 제공된 values, 생성된 manifest 파일에 대한 사람이 읽을 수 있는 정보 모음입니다. helm get hooks # 지정된 릴리스의 hooks를 다운로드합니다. Hooks는 YAML 형식이며 YAML '---\n' 구분자로 분리됩니다. helm get manifest # manifest는 이 릴리스의 차트에서 생성된 Kubernetes 리소스의 YAML 인코딩 표현입니다. 차트가 다른 차트에 의존하는 경우 해당 리소스도 manifest에 포함됩니다. helm get notes # 지정된 릴리스의 차트에서 제공하는 notes를 표시합니다. helm get values # 지정된 릴리스의 values 파일을 다운로드합니다. 출력 형식을 지정하려면 -o를 사용합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### 플러그인 관리 ```bash helm plugin install # 플러그인을 설치합니다. helm plugin list # 설치된 모든 플러그인 목록을 봅니다. helm plugin update # 플러그인을 업데이트합니다. helm plugin uninstall # 플러그인을 제거합니다. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: 소개 sidebar_position: 1 --- # 헬름 소개 헬름이 처음이신가요? 이곳에서 시작하세요! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: 헬름 설치하기 description: 헬름 설치하고 작동하는 방법 배우기. sidebar_position: 2 --- 이 가이드는 헬름 CLI를 설치하는 방법을 설명합니다. 헬름은 소스 또는 미리-빌드된(pre-built) 바이너리 릴리스로 설치할 수 있습니다. ## 헬름 프로젝트 설치 방법 헬름 프로젝트는 헬름을 가져와서 설치하는데 2가지 방법을 제공합니다. 이 방법들은 헬름 공식 릴리스를 설치하는 공식적인 방법입니다. 또한, 커뮤니티에서는 다양한 패키지 관리자를 통해 헬름을 설치할 수 있는 방법을 제공합니다. 이러한 방법을 통한 설치는 아래에 있는 공식적인 방법들에서 확인할 수 있습니다. ### 바이너리 릴리스로 헬름의 모든 [릴리스](https://github.com/helm/helm/releases)는 다양한 OS들을 위한 바이너리 릴리스를 제공합니다. 이 바이너리 버전들은 수동으로 다운로드하여 설치할 수 있습니다. 1. [원하는 버전](https://github.com/helm/helm/releases)을 다운로드 2. 압축해제 (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. 압축해제된 디렉토리에서 `helm` 파일을 찾아서, 원하는 목적지로 이동 (`mv linux-amd64/helm /usr/local/bin/helm`) 설치가 완료되면 헬름 클라이언트를 실행하고 [stable 저장소를 추가](/intro/quickstart.md#initialize-a-helm-chart-repository)할 수 있습니다: `helm help`. **참고:** 헬름 자동화 테스트는 GitHub Actions 빌드 및 릴리스 과정에서 리눅스 AMD64에서만 수행됩니다. 다른 OS에 대한 테스트는 해당 OS의 헬름 지원을 요청한 커뮤니티에서 담당합니다. ### 설치 스크립트로 헬름은 최신 버전을 자동으로 가져와서 [로컬에 설치](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)하는 설치 스크립트를 제공합니다. 이 스크립트를 받아서 로컬에서 실행할 수 있습니다. 문서가 잘 작성되어 있으므로, 실행 전에 읽어보면 어떤 작업을 하는 것인지 이해할 수 있습니다. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` 최신 버전을 설치하려면 `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` 로 설치할 수 있습니다. ## 패키지 매니저를 통해서 헬름 커뮤니티 운영체제 패키지 관리자를 통해서 헬름을 설치할 수 있는 기능을 제공합니다. 이것들은 헬름 공식 지원은 아니며, 신뢰할 수 있는 서드파티로 간주되지 않습니다. ### Homebrew로 (맥OS) 헬름 커뮤니티 멤버들은 Homebrew용 헬름 포뮬러 빌드를 기여했습니다. 이 포뮬러는 일반적으로 최신 상태로 유지됩니다. ```console brew install helm ``` (참고: emacs-helm이라는 포뮬러도 있지만, 이는 다른 프로젝트입니다.) ### Chocolatey로 (윈도우) 헬름 커뮤니티 멤버들은 [Chocolatey](https://chocolatey.org/)용 [헬름 패키지](https://chocolatey.org/packages/kubernetes-helm) 빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. ```console choco install kubernetes-helm ``` ### Scoop으로 (윈도우) 헬름 커뮤니티 멤버들은 [Scoop](https://scoop.sh)용 [헬름 패키지](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) 빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. ```console scoop install helm ``` ### Winget로 (윈도우) 헬름 커뮤니티 멤버들은 [Winget](https://learn.microsoft.com/en-us/windows/package-manager/)용 [헬름 패키지](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) 빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. ```console winget install Helm.Helm ``` ### Apt로 (데비안/우분투) 헬름 커뮤니티 멤버들은 Debian/Ubuntu용 Apt 패키지를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. 저장소 호스팅을 제공해준 [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian)에 감사드립니다. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### dnf/yum로 (페도라) Fedora 35부터, 공식 저장소에서 헬름을 사용할 수 있습니다. 다음 명령으로 헬름을 설치할 수 있습니다. ```console sudo dnf install helm ``` ### Snap으로 [Snapcrafters](https://github.com/snapcrafters) 커뮤니티에서 [헬름 패키지](https://snapcraft.io/helm)의 Snap 버전을 유지보수하고 있습니다. ```console sudo snap install helm --classic ``` ### pkg로 (FreeBSD) FreeBSD 커뮤니티 멤버들은 [FreeBSD Ports Collections](https://man.freebsd.org/ports)용 [헬름 패키지](https://www.freshports.org/sysutils/helm) 빌드를 기여했습니다. 이 패키지는 일반적으로 최신 상태로 유지됩니다. ```console pkg install helm ``` ### 개발용 빌드 릴리스 외에도 헬름의 개발 스냅샷을 다운로드하거나 설치할 수 있습니다. ### 카나리(canary) 빌드에서 "카나리" 빌드는 최신 `main` 브랜치로부터 빌드된 헬름 소프트웨어의 버전입니다. 공식 릴리스가 아니므로 안정적이지 않을 수 있습니다. 하지만 최신 기능을 테스트할 기회를 제공합니다. 카나리 헬름 바이너리는 [get.helm.sh](https://get.helm.sh)에서 제공됩니다. 아래는 일반적인 빌드에 대한 링크들입니다: - [리눅스 AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [맥OS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [테스트용 윈도우 AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### 소스에서 (리눅스, 맥OS) 소스로 헬름을 빌드하는 것은 약간 더 많은 작업이 필요하지만, 최신(프리릴리스) Helm 버전을 테스트하려는 경우 가장 좋은 방법입니다. 정상적으로 작동하는 Go 환경이 필요합니다. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` 필요한 경우 의존성을 가져와 캐시하고 설정을 검증합니다. 그 후 `helm`을 컴파일하여 `bin/helm`에 생성합니다. ## 맺음말 대부분의 경우, 미리-빌드된(pre-built) `helm` 바이너리를 가져오는 것으로 설치할 수 있습니다. 이 문서는 헬름으로 더 정교한 작업을 하려는 사용자를 위한 추가적인 경우들을 다룹니다. 헬름 클라이언트가 성공적으로 설치되면, 헬름을 사용하여 차트를 관리하고 [stable 차트 저장소를 추가](/intro/quickstart.md#initialize-a-helm-chart-repository)할 수 있습니다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: 퀵스타트 가이드 description: 배포판, FAQ, 플러그인의 설명을 포함한 헬름 설치 및 시작 방법 sidebar_position: 1 --- 이 가이드는 헬름을 빠르게 시작하는 방법에 대해 다룬다. ## 전제 조건 헬름을 성공적이고 안전하게 사용하려면 다음과 같은 전제 조건들이 필요하다. 1. 쿠버네티스 클러스터 2. 설치를 위해 어떤 보안 구성을 사용할 것인지 결정하기(필요시) 3. 헬름 설치 및 구성 ### 쿠버네티스 설치 혹은 클러스터에 접근 - 쿠버네티스가 설치되어 있어야 한다. 최신 릴리스의 헬름을 사용하기 위해서, 대부분의 경우 두번째 최신 마이너 릴리스 버전인 쿠버네티스 최신 안정(latest stable) 릴리스 버전 설치를 권장한다. - 또한 로컬로 구성된 `kubectl` 복사본이 있어야 한다. 헬름과 쿠버네티스 사이의 버전차이정책(skew) 최대 버전은 [헬름 버전 지원 정책](https://helm.sh/docs/topics/version_skew/)을 참고한다. ## 헬름 설치 헬름 클라이언트의 바이너리 릴리스를 다운로드한다. `homebrew`와 같은 툴을 사용하거나 [공식 릴리스 페이지](https://github.com/helm/helm/releases)를 참고하면 된다. 자세한 내용이나 다른 옵션에 대해서는 [설치 가이드](/intro/install.md)를 참고한다. ## 헬름 차트 리포지토리 초기화 {#initialize-a-helm-chart-repository} 헬름이 준비되면, 차트 리포지토리를 추가할 수 있다. 사용 가능한 헬름 차트 리포지토리는 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에서 확인할 수 있다. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` 차트 리포지토리 추가가 완료되면 설치할 수 있는 차트들의 목록을 볼 수 있다. ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## 예제 차트 설치 차트를 설치하기 위해서, `helm install` 커맨드를 실행한다. 헬름은 차트를 설치하기 위한 몇가지 방법들이 존재하는데, 가장 쉬운 방법은 `bitnami` 차트들을 이용하는 것이다. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` 위의 예에서, `bitnami/mysql` 차트가 릴리스되었고, 새로운 릴리스의 이름은 `mysql-1612624192`이다. MySQL 차트에 대한 간단한 정보를 보려면 `helm show chart bitnami/mysql`를 실행한다. 또는 차트에 대한 모든 정보를 보려면 `helm show all bitnami/mysql`를 실행할 수도 있다. 차트를 설치할 때마다, 새로운 릴리스가 생성된다. 따라서 하나의 차트를 동일한 클러스터에 여러 번 설치할 수 있다. 각각을 독립적으로 관리 및 업그레이드 할 수 있다. `helm install` 커맨드는 다양한 기능을 가진 매우 강력한 커맨드이다. 더 많은 정보를 얻으려면 [헬름 사용 가이드](/intro/using_helm.md)를 참고한다. ## 릴리스에 대해 알아보기 헬름을 사용하여 릴리스된 내용을 쉽게 확인할 수 있다. ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` `helm list` (또는 `helm ls`) 함수는 배포된 모든 릴리스 목록을 보여준다. ## 릴리스 설치 제거 릴리스를 설치 제거하려면, `helm uninstall` 커맨드를 사용한다. ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` 쿠버네티스에서 `mysql-1612624192`를 설치 제거하면, 릴리스 이력 뿐 아니라 릴리스와 관련된 리소스들도 모두 제거된다. `--keep-history` 플래그가 제공되면, 릴리스 이력은 유지된다. 그러면 릴리스에 대한 정보를 요청할 수 있다. ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` 헬름은 릴리스를 제거한 후에도 릴리스를 추적하므로, 클러스터 이력을 감사(audit)할 수 있고, 릴리스 삭제 취소도 가능하다. (`helm rollback`을 사용) ## 도움말 읽기 헬름 커맨드 사용법에 대해 더 배우려면, `helm help`을 사용하거나 커맨드 뒤에 `-h` 플래그를 사용한다. ```console $ helm get -h ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: 헬름 사용하기 description: 헬름의 기본사항을 설명한다. sidebar_position: 3 --- 이 가이드는, 쿠버네티스 클러스터에서 패키지를 관리하는, 헬름 사용시의 기본사항을 설명한다. 헬름 클라이언트는 이미 [설치되어](/intro/install.md) 있다고 가정한다. 명령어 몇 개를 빨리 실행해보는 데에 관심이 있다면 [퀵스타트 가이드](/intro/quickstart.md)를 참고하는 것도 좋다. 이 장은 헬름 명령어들의 세부사항을 다루며, 헬름을 사용하는 방법을 설명한다. ## 주요 개념 3가지 *차트*는 헬름 패키지이다. 이 패키지에는 쿠버네티스 클러스터 내에서 애플리케이션, 도구, 서비스를 구동하는데 필요한 모든 리소스 정의가 포함되어 있다. 쿠버네티스에서의 Homebrew 포뮬러, Apt dpkg, YUM RPM 파일과 같은 것으로 생각할 수 있다. *저장소*는 차트를 모아두고 공유하는 장소이다. 이것은 마치 Perl의 [CPAN 아카이브](https://www.cpan.org)나 [페도라 패키지 데이터베이스](https://src.fedoraproject.org/)와 같은데, 쿠버네티스 패키지용이라고 보면 된다. *릴리스*는 쿠버네티스 클러스터에서 구동되는 차트의 인스턴스이다. 일반적으로 하나의 차트는 동일한 클러스터내에 여러 번 설치될 수 있다. 설치될 때마다, 새로운 _release_ 가 생성된다. MySQL 차트의 경우를 생각해보자. 클러스터 내에 데이터베이스 2대를 구동하려면, 차트를 두번 설치하면 된다. 차례로 각각의 _release name_ 을 가지는, 각각의 _release_ 를 가지게 될 것이다. 이러한 개념을 염두에 두고, 헬름 설명을 이어간다. 헬름은 쿠버네티스 내부에 _charts_ 를 설치하고, 각 설치에 대해 새로운 _release_ 를 생성한다. 새로운 차트를 찾기 위해 헬름 차트 _repositories_ 를 검색할 수 있다. ## 'helm search': 차트 찾기 헬름은 강력한 검색 명령어를 제공한다. 서로 다른 2가지 소스 유형을 검색하는데 사용할 수 있다. - `helm search hub`는 여러 저장소들에 있는 헬름 차트들을 포괄하는 [Artifact Hub](https://artifacthub.io)를 검색한다. - `helm search repo`는 `helm repo add`를 사용하여 로컬 헬름 클라이언트에 추가된 저장소들을 검색한다. 검색은 로컬 데이터 상에서 이루어지며, 퍼블릭 네트워크 접속이 필요하지 않다. `helm search hub`를 실행하면 공개적으로 사용 가능한 차트들을 찾아볼 수 있다. ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` 위와 같이 하면 Artifact Hub에서 모든 `wordpress` 차트를 찾는다. 필터 없이 `helm search hub`을 실행하면 사용 가능한 모든 차트를 보여준다. `helm search hub`는 [artifacthub.io](https://artifacthub.io/)의 위치 URL을 표시하지만, 실제 Helm 리포지토리 URL은 표시하지 않는다. `helm search hub --list-repo-url`을 사용하면 실제 Helm 리포지토리 URL을 확인할 수 있어서 새 리포지토리를 추가할 때 유용하다: `helm repo add [NAME] [URL]`. `helm search repo`를 사용하면, 기존에 추가된 저장소들에 있는 차트 이름을 볼 수 있다. ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` helm search는 퍼지 문자열 매칭 알고리즘을 사용하므로, 단어 또는 문구의 일부분만 입력해도 된다. ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` search는 사용 가능한 패키지를 찾는 좋은 방법이다. 설치하려는 패키지를 찾았다면 `helm install`을 이용하여 설치할 수 있다. ## 'helm install': 패키지 설치 새 패키지를 설치하려면, `helm install` 명령어를 사용하자. 가장 간단하게는 사용자가 지정한 릴리스 이름, 설치하려는 차트 이름의 2개 인수를 받는다. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` 이제 `wordpress` 차트가 설치되었다. 차트를 설치하면 새 _release_ 오브젝트가 생성된다는 점을 알아두자. 위에서 릴리스의 이름이 `happy-panda`이다. (헬름이 생성해주는 이름을 그대로 사용하려면 릴리스 이름을 넣지 말고 `--generate-name`을 사용하자.) 설치하는 동안, `helm` 클라이언트는 어떤 리소스가 생성되는지, 릴리스의 상태는 어떤지, 추가 설정단계가 있는지에 관한 유용한 정보를 출력할 것이다. 헬름은 다음 순서대로 리소스를 설치한다: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration 헬름은 모든 리소스가 구동(running)할 때까지 기다리지 않는다. 많은 차트들이 크기 600M 이상의 Docker 이미지를 필요로 하며, 클러스터에 설치되기까지는 상당한 시간이 걸린다. 릴리스의 상태 추적을 계속하거나, 구성 정보를 재확인하려면, `helm status`를 사용하자. ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` 위와 같이 릴리스의 현재 상태가 표시된다. ### 설치 전 차트 커스터마이징 여기서는 이 차트의 기본 구성 옵션들만 사용할 것이다. 대부분의 경우 선호하는 구성을 사용하기 위해 차트를 커스터마이징하게 될 것이다. 차트에 어떤 옵션이 구성 가능한지 보려면, `helm show values`를 사용하자. ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` YAML 형식 파일에 있는 이러한 설정들을 오버라이드(override)하여, 설치시 파일과 함께 반영시킬 수 있다. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` 위와 같이 하면 `user0`이라는 기본 MariaDB 사용자가 생성될 것이고, 이 사용자에게는 새로 생성된 `user0db` 데이터베이스에 대한 접근권한이 부여되지만, 나머지 모든 기본설정은 해당 차트를 따르게 된다. 설치 작업에 구성 데이터를 전달하는 방법에는 두가지가 있다. - `--values` (또는 `-f`): 오버라이드(override)할 YAML 파일을 지정한다. 여러 번 지정할 수 있지만 가장 오른쪽에 있는 파일이 우선시된다. - `--set`: 명령줄 상에서 오버라이드(override)를 지정한다. 둘 다 사용하면, `--set` 값은 더 높은 우선순위를 가진 `--values`으로 병합된다. `--set`에 명시된 오버라이드 사항들은 Secret으로 보관된다. `helm get values `로 해당 릴리스에 대한 `--set` 설정값들을 조회할 수 있다. `--set` 설정값들은 `helm upgrade`를 실행할 때 `--reset-values`를 명시하여 제거할 수 있다. #### `--set`의 형식과 제한점 `--set` 옵션은 0개 이상의 이름/값 쌍을 받는다. 가장 간단하게는 `--set name=value`와 같이 사용할 수 있다. YAML로 표현하면 다음과 같다. ```yaml name: value ``` 여러 개의 값들은 `,` 문자로 구분된다. 그래서 `--set a=b,c=d`는 다음과 같다. ```yaml a: b c: d ``` 더 복잡한 표현도 지원한다. 예를 들어, `--set outer.inner=value`는 다음과 같이 표현된다. ```yaml outer: inner: value ``` 리스트는 `{`, `}` 를 사용하여 표현할 수 있다. 예를 들어, `--set name={a, b, c}`는 다음과 같이 표현된다. ```yaml name: - a - b - c ``` 특정 이름/키는 `null`이나 빈 배열 `[]`로 설정할 수 있다. 예를 들어, `--set name=[],a=null`은 다음을 ```yaml name: - a - b - c a: b ``` 다음과 같이 바꾼다. ```yaml name: [] a: null ``` 헬름 2.5.0부터는, 배열 인덱스 문법을 써서 리스트 항목들에 접근할 수 있다. 예를 들어 `--set servers[0].port=80`은 다음과 같이 된다. ```yaml servers: - port: 80 ``` 여러 개의 값들이 이런 방식으로 설정될 수 있다. `--set servers[0].port=80,servers[0].host=example` 행은 다음과 같이 된다. ```yaml servers: - port: 80 host: example ``` 때로는 `--set` 행에 특수문자를 써야할 필요가 있을 것이다. 문자를 이스케이프하기 위해 백슬래시를 사용할 수 있다. `--set name=value1\,value2`는 다음과 같다. ```yaml name: "value1,value2" ``` 비슷한 예로, `toYaml` 기능으로 어노테이션, 레이블, 노드 셀렉터를 파싱하는 차트에서 편리하게 사용되는 점 표기를 이스케이프할 수 있다. `--set nodeSelector."kubernetes\.io/role"=master`를 나타내는 구문은 다음과 같다. ```yaml nodeSelector: kubernetes.io/role: master ``` 여러 단계로 중첩된 자료구조는 `--set`로 표현하기 어려울 수 있다. 차트 설계자는 `values.yaml` 파일의 형식을 설계할 때 `--set`를 사용하는 경우도 고려해주면 좋다 (자세한 내용은 [Values 파일](/chart_template_guide/values_files.md)을 참조). ### 더 많은 설치 방법들 `helm install` 명령어를 사용하여 여러 소스에서 설치를 수행할 수 있다. - 차트 저장소 (위에서 살펴본 것) - 로컬 차트 압축파일 (`helm install foo foo-0.1.1.tgz`) - 압축해제된 차트 디렉토리 (`helm install foo path/to/foo`) - 완전한 URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' 및 'helm rollback': 릴리스 업그레이드 및 실패 복구 새로운 버전의 차트가 릴리스되었을 때, 또는 릴리스의 구성을 변경하고자 할 때, `helm upgrade` 명령어를 사용할 수 있다. 업그레이드는 현존하는 릴리스를 가지고, 사용자가 입력한 정보에 따라 업그레이드한다. 쿠버네티스 차트는 크고 복잡할 수 있기 때문에, 헬름은 최소한의 개입으로 업그레이드를 수행하려고 한다. 최근 릴리스 이후로 변경된 것들만 업데이트하게 될 것이다. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` 위의 경우, `happy-panda` 릴리스의 차트가 업그레이드되는데 새 YAML 파일도 반영된다. ```yaml mariadb.auth.username: user1 ``` `helm get values`를 사용하여 새로운 설정이 적용되었는지 확인해 볼 수 있다. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` `helm get` 명령어는 클러스터에서 릴리스 정보를 확인할 때 유용한 도구이다. 위의 예에서 `panda.yaml`의 새로운 값이 클러스터에 배포되었음을 확인할 수 있다. 릴리스가 계획대로 되지 않는다면, `helm rollback [RELEASE] [REVISION]`를 사용하여 이전 릴리스로 간단히 롤백할 수 있다. ```console $ helm rollback happy-panda 1 ``` 위와 같이 하면 happy-panda가 맨 첫번째 릴리스 버전으로 롤백된다. 릴리스 버전은 증분 리비전(incremental revision)을 나타낸다. 설치, 업그레이드, 롤백 등이 실행될 때마다, 리비전 번호는 1씩 증가한다. 첫 번째 리비전 번호는 항상 1이다. 특정 릴리스의 리비전 번호를 확인하기 위해서는 `helm history [RELEASE]`를 사용할 수 있다. ## 설치/업그레이드/롤백에 관한 유용한 옵션들 설치/업그레이드/롤백 시의 헬름 작동을 커스터마이징하는 다른 여러 유용한 옵션들이 있다. 아래 나열한 CLI 플래그가 전체 목록은 아니라는 점을 알아두자. 모든 플래그들에 관한 설명을 보려면, `helm --help`을 실행하자. - `--timeout`: 쿠버네티스 명령어가 완료되기를 기다려주는 [Go duration](https://golang.org/pkg/time/#ParseDuration) 형식의 시간 값. 기본값은 `5m0s`. - `--wait`: 릴리스가 성공적이었다고 기록하기 전에, 모든 포드들이 준비 상태가 되고 PVC들이 연결되고 디플로이먼트가 최소한(`Desired` - `maxUnavailable`)의 준비 상태 포드 수를 갖추며 서비스들이 IP 주소(`LoadBalancer`라면 인그레스)를 가질 때까지 기다린다. `--timeout` 값만큼 기다릴 것이다. 타임아웃되면 릴리스는 `FAILED`로 기록될 것이다. 참고: 롤링 업데이트 전략의 일부로서 `replicas` 설정은 1이고 `maxUnavailable` 설정은 0이 아닌 디플로이먼트의 경우, `--wait`는 최소 준비 상태 포드 수를 만족하면 준비 상태로 응답할 것이다. - `--no-hooks`: 명령어에 대한 훅(hook) 작동을 생략함 - `--recreate-pods` (`upgrade`와 `rollback`에만 적용가능): 이 플래그는 모든 포드들의 재생성을 일으킬 수 있다 (디플로이먼트에 속한 포드들은 제외). (헬름 3에서 사용 중단(DEPRECATED)) ## 'helm uninstall': 릴리스 언인스톨하기 클러스터에서 릴리스를 언인스톨하고자 할 때, `helm uninstall`을 사용해보자. ```console $ helm uninstall happy-panda ``` 이렇게 하면 클러스터에서 릴리스가 제거될 것이다. `helm list` 명령어로 현재 배포된 모든 릴리스들을 확인할 수 있다. ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` 위의 결과에서 `happy-panda` 릴리스가 언인스톨된 것을 확인할 수 있다. Helm 구버전에서는 릴리스를 삭제하면 삭제된 기록이 남았는데, Helm 3에서는 삭제시에 릴리스 기록도 제거한다. 삭제 릴리스 기록을 보존하고 싶다면, `helm uninstall --keep-history`을 사용하자. `helm list --uninstalled`를 사용하면, `--keep-history` 플래그로 언인스톨된 릴리스들만 볼 수 있다. `helm list --all` 플래그는, 실패하거나 삭제(`--keep-history` 지정된 경우)된 기록을 포함하여, 헬름이 가지고 있는 모든 릴리스 기록들을 보여준다. ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` 기본적으로 릴리스는 바로 삭제되기 때문에, 언인스톨된 리소스를 롤백하는 것은 불가능하다는 것을 알아두자. ## 'helm repo': 저장소 작업하기 헬름 3는 더 이상 기본 차트 저장소를 제공하지 않는다. `helm repo` 명령어 그룹은 저장소를 추가, 목록조회, 제거하는 명령어를 제공한다. `helm repo list`를 사용하여 어떤 저장소들이 설정되어 있는지 확인할 수 있다. ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` `helm repo add`로 새 저장소들을 추가할 수 있다. ```console $ helm repo add dev https://example.com/dev-charts ``` 차트 저장소는 자주 바뀌므로, `helm repo update`를 실행하여 언제든 헬름 클라이언트를 업데이트할 수 있다. `helm repo remove`로 저장소들을 삭제할 수 있다. ## 내 차트 만들기 [차트 개발 가이드](/topics/charts.md)는 내 차트를 개발하는 방법을 설명한다. 하지만 `helm create` 명령어를 사용하여 빠르게 시작해볼 수 있다: ```console $ helm create deis-workflow Creating deis-workflow ``` 이제 `./deis-workflow`에 차트가 생겼다. 생성된 차트를 편집하거나 내 템플릿을 생성할 수 있다. 차트를 편집했다면, `helm lint`를 실행하여 형식이 맞는지 검증할 수 있다. 배포용 차트로 패키징하고자 할 때는, `helm package` 명령어를 사용할 수 있다: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` 이 차트는 이제 `helm install`로 쉽게 설치할 수 있다: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` 패키징된 차트들은 차트 저장소에 보관할 수 있다. 자세한 내용은 [헬름 차트 저장소](/topics/chart_repository.md) 문서를 참조하자. ## 맺음말 이 장은 검색, 설치, 업그레이드, 언인스톨을 포함한 `helm` 클라이언트의 기본 사용패턴을 다룬다. 또한 `helm status`, `helm get`, `helm repo`와 같은 유용한 도구 명령어도 다루었다. 이 명령어들에 대해 더 알아보려면, 헬름에 내장된 도움말을 보도록 하자. `helm help` [다음 장](/howto/charts_tips_and_tricks.md)에서는, 차트 개발 프로세스를 살펴볼 것이다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunOption = "none" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) chart, err := loader.Load(chartPath) if err != nil { return err } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil { if err := action.CheckDependencies(chart, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := installClient.RunWithContext(ctx, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created:\n%+v", *release) return nil } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx ================================================ ```go package main import ( "bufio" "context" "fmt" "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver, logger.Printf); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, err } return registryClient, nil } func newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) { if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSverify { registryClient, err := registry.NewRegistryClientWithTLS( logger.Writer(), certFile, keyFile, caFile, insecureSkipTLSverify, settings.RegistryConfig, settings.Debug) if err != nil { return nil, err } return registryClient, nil } registryClient, err := newRegistryClient(settings, plainHTTP) if err != nil { return nil, err } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } registryClient, err := newRegistryClient(settings, false) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient pullClient := action.NewPullWithOpts( action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", *result.Release) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunOption = "none" upgradeClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts chart, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } if req := chart.Metadata.Dependencies; req != nil { if err := action.CheckDependencies(chart, req); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx ================================================ --- title: 예제 description: Helm SDK의 다양한 기능 예제 sidebar_position: 2 --- import Install from './_install.mdx' import List from './_list.mdx' import Main from './_main.mdx' import Pull from './_pull.mdx' import Uninstall from './_uninstall.mdx' import Upgrade from './_upgrade.mdx' 이 문서에서는 Helm SDK 사용 예제를 다룬다. 다양한 SDK 기능을 문서화하기 위한 것이다. 마지막 예제는 `main.go` 드라이버([링크](#driver))를 보여준다. 이 드라이버는 아래 작업들을 실행하며 필요한 헬퍼 함수들을 포함한다. 예제 코드는 [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) 디렉토리에 있다. 완전히 동작하는 코드이다. ## 작업 {#actions} ### Install 작업 {#install-action} 이 예제는 지정된 차트/릴리스를 주어진 버전과 values로 설치한다: ### Upgrade 작업 {#upgrade-action} 이 예제는 지정된 릴리스를 주어진 차트, 버전, values로 업그레이드한다: ### Uninstall 작업 {#uninstall-action} 이 예제는 지정된 릴리스를 삭제한다 ### List 작업 {#list-action} 이 예제는 현재 설정된 네임스페이스의 모든 릴리스된 차트를 나열한다 ### Pull 작업 {#pull-action} 이 예제는 OCI 저장소에서 차트를 가져온다 ## 드라이버 {#driver} 여기서 드라이버는 Helm SDK 작업이 동작하는 데 필요한 보조 함수들을 보여준다. 그리고 위의 예제들을 실제로 실행하여 OCI 저장소에서 'podinfo' 차트를 가져오고, 설치하고, 업데이트하고, 삭제한다.
================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: 소개 description: Helm Go SDK 소개 sidebar_position: 1 --- Helm Go SDK를 사용하면 커스텀 소프트웨어에서 Helm 차트와 Helm 기능을 활용하여 Kubernetes 소프트웨어 배포를 관리할 수 있다. (실제로 Helm CLI도 이러한 도구 중 하나일 뿐이다!) 현재 SDK는 Helm CLI와 기능적으로 분리되어 있다. SDK는 독립적인 도구에서 사용할 수 있으며, 실제로 사용되고 있다. Helm 프로젝트는 SDK에 대한 API 안정성을 보장한다. 참고로, SDK에는 CLI와 SDK를 분리하는 초기 작업에서 남은 다듬어지지 않은 부분이 있다. Helm 프로젝트는 이를 시간이 지남에 따라 개선할 계획이다. 전체 API 문서는 [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3)에서 확인할 수 있다. 아래에서는 주요 패키지 유형에 대한 간략한 개요와 간단한 예제를 제공한다. 더 많은 예제와 더 완전한 기능의 '드라이버'는 [예제](/sdk/examples.mdx) 섹션을 참조한다. ## 주요 패키지 개요 - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Helm 작업을 수행하기 위한 주요 "클라이언트"를 포함한다. 이것은 CLI가 내부적으로 사용하는 것과 동일한 패키지이다. 다른 Go 프로그램에서 기본적인 Helm 명령어만 수행하면 되는 경우 이 패키지를 사용하면 된다. - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): 차트를 로드하고 조작하는 데 사용되는 메서드와 헬퍼 - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) 및 하위 패키지: 표준 Helm 환경 변수에 대한 모든 핸들러를 포함하며, 하위 패키지에는 출력 및 values 파일 처리가 포함되어 있다. - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): `Release` 객체와 상태를 정의한다. 이 외에도 더 많은 패키지가 있으므로 자세한 내용은 문서를 확인한다! ### 간단한 예제 다음은 Go SDK를 사용하여 `helm list`를 수행하는 간단한 예제이다. 더 완전한 기능의 예제는 [예제](/sdk/examples.mdx) 섹션을 참조한다. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## 호환성 Helm SDK는 명시적으로 Helm의 하위 호환성 보장을 따른다: 즉, 주요 버전이 변경될 때만 호환성을 깨는 변경이 이루어진다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: 고급 헬름 기법 description: 헬름의 숙련된 사용자를 위한 다양한 고급 기능을 설명한다. sidebar_position: 9 --- 이 섹션에서는 헬름 사용에 관한 다양한 고급 기능과 기법을 설명한다. 이 섹션의 정보는 차트 및 릴리스의 고급 사용자 정의 및 조작을 수행하려는 헬름의 "숙련 사용자"를 위한 것이다. 이러한 각 고급 기능에는 고유한 장단점 및 주의사항이 있으므로, 각 기능은 헬름에 대해 충분한 지식을 가지고 신중하게 사용해야한다. 바꿔 말해서, [Peter Parker 원칙](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)을 유념하자. ## 포스트 렌더링 포스트 렌더링은 차트 설치 프로그램이 헬름으로 설치하기 전에 렌더링된 매니페스트를 수동으로 조작, 구성 및 유효성 검사를 할 수 있는 기능을 제공한다. 이를 통해 [`kustomize`](https://kustomize.io) 같은 도구를 사용하는 고급 구성 사용자들이, 공개 차트를 포크하거나 차트 유지관리자에게 소프트웨어에 대한 모든 최종 구성옵션을 지정하도록 요구하지 않고도 구성 변경사항을 적용할 수 있도록 해준다. 또한 엔터프라이즈 환경이나 배포 전 매니페스트 분석시에 공통 도구와 사이트카를 주입하는 사용 사례도 있다. ### 전제 조건 - 헬름 버전 3.1 이상 ### 사용법 포스트 렌더러는 STDIN 에서 렌더링된 쿠버네티스 매니페스트를 받고 STDOUT 으로 유효한 쿠버네티스 매니페스트를 반환하는 실행파일이면 된다. 실패 시에는 0이 아닌 종료 코드를 반환해야 한다. 이것은 두 구성 요소 사이의 유일한 "API" 이다. 이러한 구조는 포스트 렌더 프로세스로 수행할 수 있는 작업에 유연성을 제공한다. 포스트 렌더러는 `install`, `upgrade`, `template` 과 함께 사용할 수 있다. 포스트 렌더러를 사용하려면 렌더러 실행파일의 경로와 함께 `--post-renderer` 플래그를 사용한다. ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` 경로에 구분자가 없으면 $PATH 에서 검색하고, 그렇지 않으면 상대경로를 완전한 전체 경로로 풀어낸다. 여러 개의 포스트 렌더러를 사용하려면 스크립트에서 모두 호출하거나 빌드한 바이너리 도구에서 함께 호출해야 한다. bash의 경우, `renderer1 | renderer2 | renderer3` 와 같이 간단하게 표현할 수 있다. `kustomize` 를 포스트 렌더러로 사용하는 예는 [이곳](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)에서 확인할 수 있다. ### 주의사항 포스트 렌더러를 사용할 때 유의해야 하는 몇 가지 중요한 사항들이 있다. 포스트 렌더러를 사용할 때 가장 중요한 것은, 해당 릴리스를 수정하는 모든 사람들이 반복 가능한 빌드를 갖기 위해서는 **반드시** 동일한 렌더러를 사용해야 한다는 것이다. 이 기능은 사용자가 사용 중인 렌더러를 전환하거나 렌더러 사용을 중지할 수 있게 하려고 만들어졌지만 우발적인 수정이나 데이터 손실을 방지하기 위해서는 신중하게 수행해야 한다. 또 다른 중요한 사항은 보안에 관한 것이다. 포스트 렌더러를 사용하는 경우 다른 임의의 실행 파일의 경우와 마찬가지로 신뢰할 수 있는 소스에서 가져온 것인지 확인해야 한다. 신뢰할 수 없거나 확인되지 않은 렌더러를 사용하는 것은 종종 시크릿 데이터를 포함하는 렌더링 된 템플릿에 대한 전체 접근 권한을 갖게 되므로 권장되지 않는다. ### 사용자 정의 포스트 렌더러 포스트 렌더러 단계는 Go SDK에서 사용할 때 훨씬 더 많은 유연성을 제공한다. 모든 포스트 렌더러는 다음 Go 인터페이스만 구현하면 된다. ```go type PostRenderer interface { // Run 함수는 헬름 렌더링 매니페스트로 채워진 단일 버퍼가 필요하다. // 수정된 결과가 별도의 버퍼에 반환되거나 포스트 렌더링 단계를 실행하는 // 동안 이슈나 실패가 발생한 경우 오류가 반환된다. Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Go SDK 사용에 대한 자세한 내용은 [Go SDK 섹션](#go-sdk)를 참조하자. ## Go SDK 헬름 3는 헬름을 활용하는 소프트웨어 및 도구를 빌드할 때 더 나은 경험을 제공하기 위해 완전 재구성된 Go SDK를 선보였다. 전체 문서는 [Go SDK 섹션](/sdk/gosdk.md)에서 찾을 수 있으며, 가장 일반적인 패키지 중 일부와 간단한 예제는 다음과 같다. ### 패키지 개요 다음은 가장 널리 사용되는 패키지들의 목록과 그에 관한 간단한 설명이다. - `pkg/action`: 헬름 작업을 수행하기 위한 기본 "클라이언트"를 포함해야 한다. 이것은 CLI가 내부적으로 사용하는 것과 동일한 패키지이다. 다른 Go 프로그램에서 기본 헬름 명령어만 수행하고자 하는 경우 이 패키지가 적합하다. - `pkg/{chart,chartutil}`: 차트를 로드하고 조작하는데 사용되는 메서드 및 헬퍼이다. - `pkg/cli` 및 해당 하위 패키지: 표준 헬름 환경 변수에 대한 모든 핸들러를 포함하고 하위 패키지에는 출력 및 값 파일 처리를 포함한다. - `pkg/release`: `Release` 오브젝트 및 상태를 정의한다. 이 외에도 더 많은 패키지가 있으므로, 자세한 내용은 설명서를 확인하자! ### 간단한 예 다음은 Go SDK를 사용하여 `helm list` 를 수행하는 간단한 예이다. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## 스토리지 백엔드 {#storage-backends} 헬름 3는 기본 릴리스 정보 저장소를 릴리스의 네임스페이스에서 시크릿으로 변경하였다. 헬름 2는 기본적으로 릴리스 정보를 틸러(Tiller) 인스턴스 네임스페이스의 컨피그맵으로 저장한다. 다음 하위 섹션에서는 다양한 백엔드를 구성하는 방법을 보여준다. 이 구성은 `HELM_DRIVER` 환경 변수를 기반으로 한다. 값은 `[configmap, secret, sql]` 중 하나로 설정될 수 있다. ### 컨피그맵 스토리지 백엔드 컨피그맵 백엔드를 활성화 하려면 환경 변수를 `HELM_DRIVER` 에서 `configmap` 로 설정해야 한다. 다음과 같이 셸에서 설정할 수 있다. ```shell export HELM_DRIVER=configmap ``` 기본 백엔드에서 컨피그맵 백엔드로 전환하려면 직접 마이그레이션을 수행해야 한다. 다음 명령어를 사용하여 릴리스 정보를 검색할 수 있다. ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **운영 참고사항**: 출시 정보에는 무단 접근으로부터 보호해야 하는 민감한 데이터(예: 비밀번호, 개인키 및 기타 자격증명)가 포함될 수 있다. 예를 들어 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)을 사용하여 쿠버네티스 인증을 관리할 때 컨피그맵 리소스에 대한 광범위한 접근 권한을 부여하는 동시에 시크릿 리소스에 대한 접근을 제한할 수 있다. 예를 들어 기본 [사용자 대면 역할](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) 보기 권한은 대부분의 리소스에 접근 권한을 부여하지만, 보안 시크릿에는 부여하지 않는다. 또한 [암호화 된 저장소](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)에 대해 시크릿 데이터를 구성할 수 있다. 컨피그맵 백엔드로 전환하기로 결정한 경우 애플리케이션의 민감한 데이터가 노출될 수 있으므로 유의해야 한다. ### SQL 스토리지 백엔드 SQL 데이터베이스에 릴리스 정보를 저장하는 ***베타*** SQL 스토리지 백엔드가 있다. 이러한 스토리지 백엔드는 릴리스 정보의 무게가 1MB를 초과하는 경우에 사용하면 특히 유용하다. (이 경우 쿠버네티스의 기본 etcd 키-값 저장소의 내부 제한으로 인해 컨피그맵/시크릿에 저장할 수 없다.) SQL 백엔드를 활성화하려면 SQL 데이터베이스를 배포하고 환경변수 `HELM_DRIVER` 에서 `sql` 로 설정해야 한다. DB 세부 정보는 환경변수 `HELM_DRIVER_SQL_CONNECTION_STRING` 으로 설정된다. 다음과 같이 셸에서 설정할 수 있다. ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > 참고: 현재 PostgreSQL 만 지원된다. **운영 참고사항**: 다음을 권장한다. - 운영 데이터베이스를 준비하자. PostgreSQL에 대한 자세한 내용은 [서버 관리](https://www.postgresql.org/docs/12/admin.html) 문서를 참조하자. - 릴리스 정보를 위해 쿠버네티스 RBAC를 미러링하도록 [권한 관리](/topics/permissions_sql_storage_backend.md)를 활성화하자. 기본 백엔드에서 SQL 백엔드로 전환하려면 직접 마이그레이션을 수행해야 한다. 다음 명령어를 통해 릴리스 정보를 검색할 수 있다. ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: 헬름 아키텍처 description: 헬름 아키텍처를 개괄적으로 설명한다. sidebar_position: 8 --- # 헬름 아키텍처 이 문서에서는 헬름 아키텍처를 개괄적으로 설명한다. ## 헬름의 목적 헬름은 _차트_라고 하는 쿠버네티스 패키지를 관리하는 도구이다. 헬름으로 다음과 같은 것들을 할 수 있다. - 스크래치(scratch)부터 새로운 차트 생성 - 차트 아카이브(tgz) 파일로 차트 패키징 - 차트가 저장되는 곳인 차트 리포지터리와 상호작용 - 쿠버네티스 클러스터에 차트 인스톨 및 언인스톨 - 헬름으로 설치된 차트들의 릴리스 주기 관리 헬름에는 다음과 같은 중요한 3가지 개념이 있다. 1. _차트_는 쿠버네티스 애플리케이션의 인스턴스를 생성하는 데에 필요한 정보의 꾸러미이다. 2. _설정_은 릴리스 가능한 객체를 생성하기 위해 패키징된 차트로 병합될 수 있는 설정 정보를 가진다. 3. _릴리스_는 _차트_의 구동중 인스턴스이며, 특정 _설정_이 결합되어 있다. ## 컴포넌트 헬름은 실행프로그램이며, 다음 2가지 부분으로 나누어 구현되었다. **헬름 클라이언트**는 엔드유저용 명령줄 클라이언트이다. 이 클라이언트는 다음과 같은 것들을 관장한다. - 로컬 차트 개발 - 리포지터리 관리 - 릴리스 관리 - 헬름 라이브러리와 인터페이스 제공 - 설치할 차트를 전달 - 기존 릴리스에 대한 업그레이드 또는 언인스톨 요청 **헬름 라이브러리**는 모든 헬름 동작 수행에 대한 로직을 제공한다. 쿠버네티스 API 서버에 대한 인터페이스 역할을 하며 다음의 기능들을 제공한다. - 릴리스를 빌드하기 위해 차트와 설정 결합 - 쿠버네티스에 차트 설치, 후속 릴리스 객체 제공 - 쿠버네티스와 상호작용하여 업그레이드 및 언인스톨 수행 단독형 헬름 라이브러리에는 헬름 로직이 캡슐화되어 있어 다른 클라이언트에서 효과적으로 활용할 수 있다. ## 구현 헬름 클라이언트와 라이브러리는 Go 프로그래밍 언어로 작성되었다. 라이브러리는 쿠버네티스와 소통하기 위해 쿠버네티스 클라이언트 라이브러리를 사용한다. 현재, 라이브러리는 REST+JSON을 사용하며, 쿠버네티스 내부에 위치한 시크릿(secret) 안에 정보를 저장한다. 따라서 별도의 데이터베이스가 필요하지 않다. 설정 파일은 가능하면 YAML로 작성한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: 차트 저장소 가이드 description: Helm 차트 저장소를 만들고 작업하는 방법 sidebar_position: 6 --- 이 섹션에서는 Helm 차트 저장소를 만들고 작업하는 방법을 설명한다. 고수준에서 차트 저장소는 패키지형 차트를 저장하고 공유할 수 있는 장소다. 분산 커뮤니티 Helm 차트 저장소는 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)에 있으며 참여를 환영한다. 하지만 Helm도 자신만의 차트 저장소를 만들고 운영할 수 있게 해준다. 이 가이드에서는 그렇게 하는 방법을 설명한다. 차트 저장소를 만들려고 한다면 대신 [OCI 레지스트리](/topics/registries.md) 사용을 고려해 볼 수도 있다. ## 전제 조건 * [빠른 시작](/intro/quickstart.md) 가이드 살펴보기 * [차트](/topics/charts.md) 문서 읽기 ## 차트 저장소 생성 _차트 저장소_ 는 `index.yaml` 파일과 선택적으로 일부 패키지화된 차트를 저장하는 HTTP 서버다. 차트를 공유할 준비가 되면 차트 저장소에 업로드하는 것이 가장 선호되는 방법이다. Helm 2.2.0부터 저장소에 대한 클라이언트 측 SSL 인증이 지원된다. 다른 인증 프로토콜은 플러그인으로 사용할 수 있다. 차트 저장소는 YAML과 tar 파일을 서비스할 수 있고 GET 요청에 응답할 수 있는 모든 HTTP 서버가 될 수 있기 때문에, 자신만의 차트 저장소를 호스팅하는 것에 관한 한 수많은 옵션이 있다. 예를 들어 Google Cloud Storage(GCS) 버킷, Amazon S3 버킷, GitHub Pages를 사용하거나 직접 웹 서버를 만들 수도 있다. ### 차트 저장소 구조 차트 저장소는 패키지형 차트와 저장소에 있는 모든 차트의 인덱스를 가진 `index.yaml` 이라는 특수 파일로 구성된다. 종종 `index.yaml` 에 기술된 차트도 [출처 파일](/topics/provenance.md)처럼 동일한 서버에서 호스팅된다. 예를 들어, 저장소 `https://example.com/charts` 의 레이아웃은 다음과 같을 수 있다: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` 이 경우에는 인덱스 파일에 하나의 차트, 즉 Alpine 차트에 대한 정보가 포함되며, 해당 차트에 대한 다운로드 URL `https://example.com/charts/alpine-0.1.2.tgz` 을 제공한다. 차트 패키지가 `index.yaml` 파일과 동일한 서버에 위치할 필요는 없다. 하지만 그렇게 하는 것이 종종 가장 쉽다. ### 인덱스 파일 인덱스 파일은 `index.yaml` 이라는 yaml 파일이다. 차트의 `Chart.yaml` 파일의 내용을 포함하여 패키지에 대한 메타데이터가 포함되어 있다. 적합한 차트 저장소는 인덱스 파일이 있어야 한다. 인덱스 파일에는 차트 저장소의 각 차트에 대한 정보가 들어 있다. `helm repo index` 명령은 패키지형 차트를 포함하는 지정된 로컬 디렉토리를 기반으로 인덱스 파일을 생성한다. 인덱스 파일의 예: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## 차트 저장소 호스팅 이 절은 차트 저장소를 서비스하는 몇 가지 방법을 보여준다. ### Google Cloud Storage 첫 번째 단계는 **GCS 버킷 만들기**다. `fantastic-charts` 라고 부를 것이다. ![GCS 버킷 생성](/img/helm2/create-a-bucket.png) 다음으로, **버킷 권한을 수정**하여 버킷을 공개하자. ![권한 수정](/img/helm2/edit-permissions.png) **버킷을 공개하기 위해** 다음 줄을 넣자: ![버킷 공개](/img/helm2/make-bucket-public.png) 축하한다, 이제 차트를 서비스할 빈 GCS 버킷이 준비되었다! Google Cloud Storage 명령줄 도구 또는 GCS 웹 UI를 사용하여 차트 저장소를 업로드할 수 있다. 공용 GCS 버킷은 `https://bucket-name.storage.googleapis.com/` 주소로 간단한 HTTPS를 통해 접근할 수 있다. ### Cloudsmith Cloudsmith를 사용하여 차트 저장소를 설정할 수도 있다. Cloudsmith가 있는 차트 저장소에 대한 자세한 내용은 [여기](https://help.cloudsmith.io/docs/helm-chart-repository)를 참조하자. ### JFrog Artifactory JFrog Artifactory를 사용하여 차트 저장소를 만들 수도 있다. JFrog Artifactory가 있는 차트 저장소에 대한 자세한 내용은 [여기](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)를 참조하자. ### GitHub Pages 예제 비슷한 방법으로 GitHub Pages를 사용하여 차트 저장소를 만들 수 있다. GitHub은 두 가지 방법으로 정적 웹 페이지를 서비스할 수 있도록 한다: - `docs/` 디렉토리의 내용을 서비스하도록 프로젝트를 설정 - 특정 브랜치를 서비스하도록 프로젝트를 설정 두 번째 방법을 택할 것이지만, 첫 번째 방법도 똑같이 쉽다. 첫 번째 단계는 **gh-pages 브랜치를 만드는** 것이다. 로컬에서 만들 수 있다: ```console $ git checkout -b gh-pages ``` GitHub 저장소의 **Branch** 버튼을 눌러 웹 브라우저를 통해 만들 수도 있다: ![GitHub Pages 브랜치 생성](/img/helm2/create-a-gh-page-button.png) 그런 다음 **gh-pages 브랜치**가 GitHub Pages로 설정되어 있는지 확인하고, 저장소의 **Settings**를 클릭한 다음 **GitHub Pages** 섹션으로 스크롤하여 아래와 같이 설정하자: ![GitHub Pages 브랜치 설정](/img/helm2/set-a-gh-page.png) 기본적으로 **Source**는 **gh-pages 브랜치**로 설정된다. 기본적으로 설정되어 있지 않으면 선택하자. 원한다면 거기서 **사용자 지정 도메인(custom domain)** 을 사용할 수 있다. 그리고 차트를 서비스할 때 **HTTPS**가 사용되도록 **Enforce HTTPS**가 선택되어 있는지 확인하자. 이러한 설정에서 기본 브랜치를 사용하여 차트 코드를 저장하고 **gh-pages 브랜치**를 차트 저장소로 사용할 수 있다. 예: `https://USERNAME.github.io/REPONAME`. 데모 [TS Charts](https://github.com/technosophos/tscharts) 저장소는 `https://technosophos.github.io/tscharts/` 에서 접근할 수 있다. GitHub Pages를 사용하여 차트 저장소를 호스팅하기로 결정했다면 [Chart Releaser Action](/howto/chart_releaser_action.md)을 확인하자. Chart Releaser Action은 [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI 도구를 사용하여 GitHub 프로젝트를 자체 호스팅 Helm 차트 저장소로 전환하는 GitHub Action 워크플로우다. ### 일반 웹 서버 Helm 차트를 서비스하도록 일반 웹 서버를 설정하려면 다음 작업만 수행하면 된다: - 서버가 서비스할 수 있는 디렉토리에 인덱스 및 차트 저장 - 인증 요구 사항 없이 `index.yaml` 파일에 접근할 수 있는지 확인 - `yaml` 파일이 올바른 내용 유형(`text/yaml` 또는 `text/x-yaml`)과 함께 서비스되는지 확인 예를 들어, `$WEBROOT/charts` 에서 차트를 서비스하려면 웹 루트에 `charts/` 디렉토리가 있는지 확인하고 인덱스 파일과 차트를 해당 폴더 안에 넣자. ### ChartMuseum 저장소 서버 ChartMuseum은 Go 언어로 작성된 오픈소스 Helm 차트 저장소 서버로, [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), [etcd](https://etcd.io/)를 포함한 클라우드 스토리지 백엔드를 지원한다. [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 서버를 사용하여 로컬 파일 시스템에서 차트 저장소를 호스팅할 수도 있다. ### GitLab Package Registry GitLab을 사용하면 프로젝트의 Package Registry에 Helm 차트를 게시할 수 있다. GitLab에서 Helm 패키지 저장소를 설정하는 방법에 대한 자세한 내용은 [여기](https://docs.gitlab.com/ee/user/packages/helm_repository/)를 참조하자. ## 차트 저장소 관리 차트 저장소가 생겼으니 이 가이드의 마지막 부분에서는 해당 저장소에서 차트를 유지하는 방법을 설명한다. ### 차트 저장소에 차트 저장 차트 저장소가 생겼으니 차트와 인덱스 파일을 저장소에 업로드하자. 차트 저장소의 차트는 올바르게 패키징하고(`helm package chart-name/`) 버전([SemVer 2](https://semver.org/) 가이드라인에 따라)이 제공되어야 한다. 다음 단계는 예제 워크플로우를 구성하지만, 차트 저장소에 차트를 저장하고 갱신하는 데 원하는 워크플로우를 모두 사용해도 좋다. 패키지형 차트가 준비되면 새 디렉토리를 만들고 패키지형 차트를 해당 디렉토리로 이동시키자. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` 마지막 명령은 방금 생성한 로컬 디렉토리의 경로와 원격 차트 저장소의 URL을 사용하여 지정된 디렉토리 경로 내에 `index.yaml` 파일을 구성한다. 이제 동기화 도구를 사용하거나 수동으로 차트 저장소에 차트 및 인덱스 파일을 업로드할 수 있다. Google Cloud Storage를 사용하는 경우 gsutil 클라이언트를 사용하는 이 [예제 워크플로우](/howto/chart_repository_sync_example.md)를 확인하자. GitHub의 경우 해당 목적지 브랜치에 차트를 간단히 넣을 수 있다. ### 기존 저장소에 새로운 차트 추가 저장소에 새로운 차트를 추가할 때마다 인덱스를 재생성해야 한다. `helm repo index` 명령은 로컬에서 찾은 차트만 포함하여 `index.yaml` 파일을 처음부터 완전히 재구성한다. 그러나 `--merge` 플래그를 사용하여 새 차트를 기존 `index.yaml` 파일(GCS와 같은 원격 저장소로 작업할 때 유용한 옵션)에 점진적으로 추가할 수 있다. 자세히 알아보려면 `helm repo index --help`를 실행하자. 수정된 `index.yaml` 파일과 차트를 모두 업로드하자. 그리고 출처 파일을 생성했다면 그것도 업로드하자. ### 다른 사람과 차트 공유 차트를 공유할 준비가 되면 다른 사람에게 저장소의 URL을 알려주자. 그들은 저장소를 조회하기 위해 사용하고자 하는 이름과 `helm repo add [NAME] [URL]` 명령을 통해 저장소를 Helm 클라이언트에 추가할 것이다. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` 차트가 HTTP 기본 인증을 지원할 경우 사용자 이름과 암호도 제공할 수 있다: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **참고:** 저장소에 유효한 `index.yaml`이 포함되어 있지 않으면 저장소가 추가되지 않는다. **참고:** Helm 저장소가 자체 서명된 인증서를 사용하는 경우 CA 검증을 건너뛰기 위해서 `helm repo add --insecure-skip-tls-verify ...` 를 사용할 수 있다. 그 후에 사용자들은 당신의 차트를 검색할 수 있을 것이다. 저장소를 업데이트한 후에는 사용자들이 `helm repo update` 명령을 사용하여 최신 차트 정보를 가져올 수 있다. *내부에서 `helm repo add` 및 `helm repo update` 명령은 index.yaml 파일을 가져와 `$XDG_CACHE_HOME/helm/repository/cache/` 디렉토리에 저장한다. 여기는 `helm search` 기능이 차트에 대한 정보를 찾는 곳이다.* ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: 차트 테스트 description: 차트를 실행하고 테스트하는 방법을 설명한다. sidebar_position: 3 --- 차트에는 함께 작동하는 여러 쿠버네티스 리소스 및 구성요소가 포함되어 있다. 차트 작성자는 차트가 설치될 때 예상대로 작동하는지 확인하는 몇 가지 테스트를 작성할 수 있다. 이러한 테스트는 차트 사용자가 차트에 따라 수행될 작업을 이해하는 데에도 도움이 된다. 헬름 차트의 **테스트**는 `templates/` 디렉토리에 있으며 실행하기 위해 주어진 명령어로 컨테이너를 지정하는 작업 정의이다. 테스트가 성공한 것으로 판정되려면 컨테이너가 성공적으로 종료되어야 한다(exit 0). 작업 정의에는 헬름 테스트 훅 어노테이션(`helm.sh/hook: test`)이 반드시 포함되어야 한다. 헬름 v3까지는, 작업 정의에 `helm.sh/hook: test-success` 또는 `helm.sh/hook: test-failure`와 같은 헬름 테스트 훅 어노테이션 중 하나가 포함되어야 했다. `helm.sh/hook: test-success`는 여전히 `helm.sh/hook: test`과 하위 호환되는 대안으로 허용된다. 예제 테스트: - values.yaml 파일의 구성이 제대로 삽입되었는지 확인 - 사용자 이름과 비밀번호가 올바르게 작동하는지 확인 - 잘못된 사용자 이름과 비밀번호가 작동하지는 않는지 확인 - 서비스가 작동하고 올바르게 로드 밸런싱되는지 확인 - 기타 `helm test ` 명령어를 사용하여 헬름에서 릴리스에 대한 사전 정의된 테스트를 실행할 수 있다. 이렇게 하면 차트 사용자가 차트(또는 애플리케이션)의 릴리스가 기대한대로 작동하는지 확인할 수 있다. ## 예제 테스트 [helm create](/helm/helm_create.md) 명령어는 자동으로 여러 폴더와 파일을 생성한다. 헬름 테스트 기능을 사용해 보려면 먼저 데모 헬름 차트를 생성한다. ```console $ helm create demo ``` 이제 데모 헬름 차트에서 다음과 같은 구조를 볼 수 있다. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` `demo/templates/tests/test-connection.yaml`에서 테스트를 확인할 수 있다. 다음은 헬름 테스트 파드 정의이다: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## 릴리스에서 테스트 스위트를 실행하는 단계 먼저 클러스터에 차트를 설치하여 릴리스를 만든다. 모든 파드가 활성화될 때까지 기다려야 할 수도 있다. 설치 직후 바로 테스트하는 경우, 일시적인 오류가 발생할 수도 있고, 다시 테스트해야 할 수도 있다. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## 참고 - 테스트를 정의할 때는 단일 yaml 파일에 하거나 또는 `templates/` 디렉토리의 여러 yaml 파일에 분산하여 할 수도 있다. - 따로 분리하기 위해 `<차트-이름>/templates/tests/`와 같은 `tests/` 디렉토리 아래에 테스트 스위트를 넣어둘 수도 있다. - 테스트는 [헬름 훅](/topics/charts_hooks.md)이므로, `helm.sh/hook-weight`나 `helm.sh/hook-delete-policy`와 같은 어노테이션을 테스트 리소스와 함께 사용할 수 있다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: 차트 description: 차트 형식을 설명하고, 헬름으로 차트를 빌드하기 위한 기본지침을 제공한다. sidebar_position: 1 --- 헬름은 *charts* 라는 패키지 포맷을 사용한다. 차트는 쿠버네티스 리소스와 관련된 셋을 설명하는 파일의 모음이다. 하나의 차트는 memcached 파드를 배포하는 것처럼 단순한 형태나 HTTP 서버, 데이터베이스, 캐시 등으로 구성된 완전한 웹앱 같이 복잡한 형태로 사용될수 있다. 차트는 특정한 디렉터리 구조를 가진 파일들로 생성된다. 이 파일들은 배포할 버전이 지정된 아카이브로 패키지화 될 수 있다. 설치하지 않고 공개된 차트를 다운로드 받거나 보기 위해, `helm pull chartrepo/chartname` 명령을 사용할 수 있다. 이 문서는 차트 형식을 설명하고, 차트를 헬름으로 구성하는 기본 가이드를 제공한다. ## 차트 파일 구조 차트는 디렉터리 안에 파일들의 모음으로 구성된다. 디렉터리명은 (버전 정보 없는) 차트명이다. 따라서, WordPress 를 설명하는 차트는 `wordpress/` 디렉터리에 저장된다. 디렉터리 안에서 헬름은 다음과 같은 구조를 가진다. ```text wordpress/ Chart.yaml # 차트에 대한 정보를 가진 YAML 파일 LICENSE # 옵션: 차트의 라이센스 정보를 가진 텍스트 파일 README.md # 옵션: README 파일 values.yaml # 차트에 대한 기본 환경설정 값들 values.schema.json # 옵션: values.yaml 파일의 구조를 제약하는 JSON 파일 charts/ # 이 차트에 종속된 차트들을 포함하는 디렉터리 crds/ # 커스텀 자원에 대한 정의 templates/ # values와 결합될 때, 유효한 쿠버네티스 manifest 파일들이 생성될 템플릿들의 디렉터리 templates/NOTES.txt # 옵션: 간단한 사용법을 포함하는 텍스트 파일 ``` 헬름은 `charts/`, `crds/`, `templates/` 디렉터리와 나열된 파일명의 사용을 예약한다. 다른 파일들은 그대로 남는다. ## Chart.yaml 파일 {#the-chartyaml-file} `Chart.yaml` 파일은 차트의 필수 요소이다. 다음과 같은 필드를 포함한다. ```yaml apiVersion: 차트 API 버전 (필수) name: 차트명 (필수) version: SemVer 2 버전 (필수) kubeVersion: 호환되는 쿠버네티스 버전의 SemVer 범위 (선택) description: 이 프로젝트에 대한 간략한 설명 (선택) type: 차트 타입 (선택) keywords: - 이 프로젝트에 대한 키워드 리스트 (선택) home: 프로젝트 홈페이지의 URL (선택) sources: - 이 프로젝트의 소스코드 URL 리스트 (선택) dependencies: # 차트 필요조건들의 리스트 (optional) - name: 차트명 (nginx) version: 차트의 버전 ("1.2.3") repository: 저장소 URL ("https://example.com/charts") 또는 ("@repo-name") condition: (선택) 차트들의 활성/비활성을 결정하는 boolean 값을 만드는 yaml 경로 (예시: subchart1.enabled) tags: # (선택) - 활성화 / 비활성을 함께하기 위해 차트들을 그룹화 할 수 있는 태그들 enabled: (선택) 차트가 로드될수 있는지 결정하는 boolean import-values: # (선택) - ImportValues 는 가져올 상위 키에 대한 소스 값의 맵핑을 보유한다. 각 항목은 문자열이거나 하위 / 상위 하위 목록 항목 쌍일 수 있다. alias: (선택) 차트에 대한 별명으로 사용된다. 같은 차트를 여러번 추가해야할때 유용하다. maintainers: # (선택) - name: maintainer들의 이름 (각 maintainer마다 필수) email: maintainer들의 email (각 maintainer마다 선택) url: maintainer에 대한 URL (각 maintainer마다 선택) icon: 아이콘으로 사용될 SVG나 PNG 이미지 URL (선택) appVersion: 이 앱의 버전 (선택). SemVer인 필요는 없다. deprecated: 차트의 deprecated 여부 (선택, boolean) annotations: example: 키로 매핑된 주석들의 리스트 (선택). ``` [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2) 버전부터 추가 필드는 허용되지 않습니다. 권장되는 방식은 `annotations`에 사용자 정의 메타데이터를 추가하는 것입니다. ### 차트와 버저닝 모든 차트는 버전 번호를 가져야한다. 버전은 [SemVer2](https://semver.org/spec/v2.0.0.html) 표준을 따라야 한다. 이전 헬름과 다르게, 헬름 v2 이상은 버전 번호를 release 마커로 사용한다. 저장소에 있는 패키지들은 이름과 버전으로 구분된다. 예를 들어, 버전 필드가 `version: 1.2.3` 으로 설정된 `nginx` 차트는 다음같이 이름이 지어진다. ```text nginx-1.2.3.tgz ``` `version:1.2.3-alpha.1+ef365` 같은 더 복잡한 SemVer 2 이름도 지원된다. SemVer가 아닌 이름은 시스템에 의해 명백하게 허용되지 않습니다. 예외적으로 `x` 또는 `x.y` 형식의 버전은 허용됩니다. 예를 들어, 앞에 v가 붙거나 세 부분이 모두 없는 버전(예: v1.2)은 유효한 시맨틱 버전(예: v1.2.0)으로 변환하려고 시도합니다. **참고:** 헬름 클래식과 배포 매니저는 둘다 깃허브를 지향한 차트였지만, 헬름 v2와 이후 버전은 깃허브나 깃에 의존하지도, 필요로 하지도 않는다. 따라서 깃 SHA 값의 버전관리에서는 모두 사용하지 않는다. `Chart.yaml` 의 안에 있는 `version` 필드는 CLI를 포함한 많은 헬름 툴에서 사용된다. 패키지를 생성할 때, `helm package` 명령은 `Chart.yaml` 에서 찾은 버전을 패키지 이름에 있는 토큰으로 사용한다. 시스템은 차트 패키지명 안의 버전 번호가 `Chart.yaml` 안의 버전 번호와 일치한다고 가정한다. 이 가정을 충족하지 못하면 에러가 발생한다. ### `apiVersion` 필드 `apiVersion` 필드는 최소 헬름 3을 필요로 하는 헬름 차트에 대해 `v2` 여야 한다. 이전 헬름 버전을 지원하는 차트는 `apiVersion` 이 `v1` 으로 설정되어 있고, 헬름 3에 의해 여전히 설치 가능하다. `v1` 에서 `v2` 로 변경하기: - 종속성을 정의하는 `dependencies`필드는 `v1` 차트를 위한 독립된 `requirements.yaml` 파일에 위치([Chart Dependencies](#차트-의존성) 보기). - `type`필드는 어플리케이션과 라이브러리 차트를 식별([ChartTypes](#차트-타입) 보기) ### `appVersion` 필드 `appVersion` 필드는 `version` 필드와 관련이 없음을 주의하라. 이 필드는 어플리케이션의 버전을 명시하는 방법이다. 예를 들어, `drupal` 차트가 `appVersion: 8.2.1` 을 가진다면, 차트에 (기본값으로) 포함되는 Drupal의 버전은 `8.2.1`임을 나타낸다. 이 필드는 정보만 제공하고, 차트 버전 계산에 영향이 없다. 버전을 따옴표로 감싸는 것을 매우 권장한다. 이것은 YAML 파서가 버전 번호를 string으로 다루게 한다. 따옴표 없이 남기면 몇몇의 경우에 파싱 문제가 생길 수 있다. 예를 들어, YAML은 `1.0` 을 소숫점으로, `1234e10` 같은 깃 커밋 SHA를 과학적 기수법으로 해석한다. 현재 헬름 v3.5.0에서, `helm create`는 기본값으로 `appVersion` 필드를 따옴표로 감싼다. ### `kubeVersion` 필드 선택 필드인 `kubeVersion` 은 지원되는 쿠버네티스 버전에 대한 semver 제약 조건을 정의할 수 있다. 헬름은 차트를 설치할 때 버전 제약을 판단하고, 클러스터가 지원되지 않는 쿠버네티스 버전을 구동하면 실패한다. 버전 제약은 공백으로 분리된 AND 비교로 다음과 같이 구성된다. ``` >= 1.13.0 < 1.15.0 ``` 다음 예제와 같이 표현 각각은 OR `||` 연산과 결합될 수 있다. ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` 이 예제에서 버전 `1.14.0` 은 제외되어, 특정 버전의 버그가 차트를 제대로 실행하지 못하게 하는 것으로 이해할 수 있다. 버전 제약에 사용하는 `=` `!=` `>` `<` `>=` `<=` 연산 외에도, 다음 약칭 표기법이 지원된다. * 닫힌 간격에 대한 하이픈 범위, `1.1 - 2.3.4` 는 `>=1.1 <= 2.3.4` 와 동일하다. * 와일드카드 `x`, `X` ,`*`, 예를 들어 `1.2.x` 는 `>= 1.2.0 < 1.3.0` 와 동일하다. * 물결 범위 (패치 버전 변화는 허용), `~1.2.3`는 `>= 1.2.3 < 1.3.0` 와 동일하다. * 탈자 범위 (마이너 버전 변화는 허용), `^1.2.3` 는`>= 1.2.3 < 2.0.0` 와 동일하다. 지원되는 유의적 버전 제약의 상세한 표현은 [Masterminds/semver](https://github.com/Masterminds/semver)에서 확인한다. ### 미사용 예정 차트 차트 저장소에서 차트를 관리할 때, 가끔 차트를 미사용 예정으로 표시하는 것이 필요하다. `Chart.yaml` 에 있는 선택 필드인 `deprecated` 는 차트가 미사용 예정임을 표시하는데 사용될 수 있다. 저장소에 있는 차트의 **최신** 버전이 미사용 예정으로 표시 된다면, 차트는 전체가 미사용 예정이라고 판단한다. 미사용 예정을 체크하지 않은 새로운 버전을 발행함으로써 차트명을 이후에 재사용 할 수 있습니다. 차트를 미사용 예정으로 만드는 작업흐름은 다음과 같습니다: 1. 차트의 `Chart.yaml` 를 업데이트 하여 차트를 미사용 예정으로 표시하여 버전을 올린다. 2. 차트 저장소에 새로운 차트 버전을 발행한다. 3. 차트를 소스 저장소에서 삭제한다 (예. git) ### 차트 타입 `type` 필드는 차트의 타입을 정의한다. `application`, `library` 의 두가지 타입이 있다. Application은 기본 타입이며 온전하게 작동할 수 있는 표준 차트이다. [library chart](/topics/library_charts.md) 는 차트 빌더에 유틸리티나 함수를 제공한다. library chart는 설치가 불가능하고, 보통 어떤 리소스 오브젝트도 갖지 않는다는 점에서 application chart와는 다르다. **참고:** application chart는 library chart로 사용될 수 있다. 타입을 `library` 로 설정하여 활성화 한다. 차트는 모든 유틸리티와 함수 기능을 활용할 수 있는 상태의 library chart로 렌더링된다. 차트의 모든 리소스 오브젝트는 렌더링되지 않는다. ## 차트 라이센스, README 와 NOTES 차트는 설치, 구성, 사용법, 라이센스를 설명하는 파일을 가질 수 있다. LICENSE는 차트에 대한 [license](https://en.wikipedia.org/wiki/Software_license) 를 포함하는 일반 텍스트 파일이다. 차트는 템플릿 안에서 프로그래밍 로직을 가지는 것으로써의 라이센스를 포함할 수 있으므로 환경 설정 전용이 아니다. 필요한 경우, 차트에 의해 설치된 어플리케이션을 위해 별도의 라이센스로 나눠질 수 있다. 차트에 대한 README는 마크다운(README.md)의 포맷이어야 하며, 일반적으로 다음을 포함한다. - 차트가 제공하는 어플리케이션이나 서비스에 관한 설명 - 차트를 실행하기 위한 전제조건이나 필요조건 - `values.yaml` 에 있는 옵션과 기본값에 대한 설명 - 차트의 설치나 환경설정에 관련이 있을 수 있는 다른 정보 허브 및 기타 사용자 인터페이스가 `README.md` 파일의 콘텐츠에서 가져온 차트에 대한 세부 정보를 표시하는 경우 차트는 릴리즈의 상태를 보여줄때와 설치 후에 출력될 짧은 일반 텍스트를 `template/NOTES.txt` 파일에 적을 수 있다. 이 파일은 [template](#템플릿과-값)으로 평가되고 사용법 메모, 다음 스텝, 차트의 릴리즈와 관련된 다른 정보를 표시하기 위해 사용될 수 있다. 예를 들어, 지시 사항(instructions)은 데이터베이스에 연결하기, 웹 UI에 액세스하기 등에 대해 제공될 수 있다. 이 파일이 `helm install` 이나 `helm status` 가 실행될 때 STDOUT으로 출력되기 때문에, 내용을 간단하게 유지하고, 상세 내용은 README를 참조하도록 하는 것을 권장한다. ## 차트 의존성 헬름에서 하나의 차트는 0개 이상의 다른 차트에 의존한다. 이 의존성은 `Chart.yaml` 에 `dependencies` 필드를 사용하여 직접 연결되거나 `charts/` 디렉터리로 가져와서 수동으로 관리할 수 있다. ### `dependencies` 필드를 통해 의존성 관리하기 현재 차트가 필요로 하는 차트들은 `dependencies` 필드에 리스트로 정의된다. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - `name` 필드는 사용할 차트명이다. - `version` 필드는 사용할 차트의 버전이다. - `repository` 필드는 차트 저장소의 완전한 URL 이다. 반드시 로컬 환경에서 `helm repo add` 를 사용해야 함을 주의하라. - URL 대신 저장소의 이름을 사용할 수 있다. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` 일단 종속성을 정의하면, `helm dependency update` 를 실행할 수 있고, 실행하면 종속성 파일을 사용해서 모든 명시된 차트를 `charts/` 디렉터리 안에 다운로드 받는다. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` `helm dependency update` 가 차트를 가져올 때, 차트 아카이브의 형태로 `charts/` 디렉터리에 저장한다. 위의 예제 같은 경우, 다음 파일들을 차트 디렉터리에서 볼수 있다. ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### 의존성 안에서의 대체 필드 위에서 본 필드 외에도, 각각의 필요 엔트리는 선택적 필드인 `alias` 를 가질 수 있다. 종속성 차트에 대한 별명(alias)을 추가하여, dependencies 안에 새로운 종속성 이름을 별명으로 사용하여 넣게 된다. 다른 이름으로 차트에 엑세스 해야 하는 경우 `alias` 를 사용할 수 있다. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` 위의 예에서 `parentchart` 에 대해 모두 3개의 종속성을 얻게 된다. ```text subchart new-subchart-1 new-subchart-2 ``` 같은 동작을 수동으로 하는 방법은 `charts/` 디렉터리에 같은 차트를 여러번 다른 이름으로 복사/붙여넣기 하면된다. #### 의존성 안에서의 태그와 조건 필드 위에서 본 필드 외에도, 각각의 필요 엔트리는 선택필드인 `tags` 와 `condition` 을 가질 수 있다. 모든 차트는 기본으로 로드된다. `tags` 나 `condition` 필드가 존재하면, 차트가 적용될지에 대한 로딩 제어를 위해 사용되고 평가된다. Condition - condition 필드는 1개 이상의 (콤마로 구분되는) YAML 경로이다. 최상단 부모의 values에 이 경로가 존재하고 boolean 값으로 판단할수 있다면, 차트는 boolean 값에 의해 활성화 혹은 비활성화 된다. 리스트에서 발견된 유효한 첫번째 경로만이 평가되고, 이 경로가 존재하지 않으면 해당 condition은 무효하다. Tags - tags 필드는 이 차트와 관련된 레이블의 YAML 리스트이다. 최상단 부모의 values에서, 태그를 가진 모든 차트는 특정한 태그와 boolean 값에 의해 활성화 또는 비활성화 된다. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled, global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` 위 예에서 `front-end` 태그를 가진 모든 차트는 비활성화 되지만, 부모의 values에서 `subchart1.enabled` 가 true로 평가되었기 때문에, condition은 `front-end` 태그를 덮어쓰고 `subchart1` 은 활성화된다. `subchart2` 는 `back-end` 와 태그되었고 이 태그는 `true` 로 평가되어서, `subchart2` 는 활성화된다. 또한 `subchart2` 가 특정한 condition을 가지지만, 부모의 values에 대응되는 경로가 없어서, 이 condition은 아무 영향이 없다. ##### 태그 및 조건과 함께 CLI 사용 `--set` 파라미터는 보통 tag와 condition 값을 수정할때 사용할 수 있다. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### 태그 및 조건 확인 - **(values에 셋팅된) Condition은 항상 tag를 덮어쓴다.** 존재하는 첫번째 condition 경로가 사용되고 그 차트의 다른 것들은 무시된다. - tag는 '어떤 차트의 tag라도 true면 차트를 활성화 시킬것' 으로 평가한다. - tag와 condition 값은 최상단 부모의 values에 셋팅되어야 한다. - values의 `tags:` 키는 최상단 레벨의 키여야 한다. 전역과 중첩된 `tags:` 테이블은 현재 지원되지 않는다. #### 의존성을 통해 자식 값 가져오기 몇몇 케이스에서 자식 차트의 values가 부모의 차트에 영향을 미치고 공통 기본값으로 공유되도록 하고싶을 수 있다. `exports` 포맷을 사용하는 것의 추가 이점은 향후 도구를 통해 사용자가 설정할수 있는 값을 가능하게 하는 것이다. import 될 값을 포함하는 키는 YAML 리스트를 사용해서 부모 차트의 `dependencies` 안에 `import-values` 필드로 명시할 수 있다. 리스트의 각 아이템은 자식 차트의 `exports` 필드로부터 import 되는 키이다. `exports` 키 안에 포함되지 않은 import value를 사용하려면, [child-parent](#자식-부모-형식-사용하기) 포맷을 사용하라. 두 포맷 모두 아래에서 설명한다. ##### 내보내기 형식 사용하기 자식의 `values.yaml` 파일이 루트에 `exports` 필드를 가진다면, 이 필드의 내용은 다음 예제처럼 import 하기 위한 키를 명시함으로써 부모의 values에 직접 import 될수 있다. ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` import 리스트에 `data` 키를 명시했기 때문에, 헬름은 `data` 키에 대한 자식 차트의 `exports` 필드를 찾고 그것의 내용을 import 한다. 최종 부모의 values는 export된 필드를 포함한다. ```yaml # parent's values myint: 99 ``` 부모의 `data` 키가 부모의 최종 values에 포함되지 않음을 주의하라. 부모의 키에 명시할 필요가 있다면, 'child-parent' 포맷을 사용하라. ##### 자식-부모 형식 사용하기 자식 차트의 values의 `exports` 키에 포함되지 않은 values에 접근하려면, import될 (자식) values의 키와 부모 차트의 values (부모)안의 목적지 경로를 명시해야 한다. 아래의 예제에 있는 `import-values` 는 `child` 경로에서 발견된어떤 값이든 취하고, 값들을 `parent:` 에 명시된 경로에 부모의 값들로 복사하라고 헬름에게 지시한다. ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` 위의 예제에서, subchart1의 값들 안에 `default.data` 에서 발견된 values는 다음과 같이 부모 차트의 values 안의 `myimports` 키로 import 된다. ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` 부모 차트의 values 결과는 다음과 같다. ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` 부모의 최종 values는 이제 subchart1에서 import된 `myint` 와 `mybool` 필드를 가진다. ### `charts/` 디렉터리를 통해 수동으로 의존성 관리 더 많은 종속성 제어가 필요하다면, 이 종속성들은 dependency 차트를 `charts/` 디렉터리로 복사함으로써 정확하게 표현될 수 있다. 종속성은 압축 해제된 차트 디렉터리여야 하며, 이름은 `_`나 `.`로 시작될 수 없습니다. 차트 로더가 무시한다. 예를 들어서, WordPress 차트가 Apache 차트에 의존한다면, (올바른 버전의) Apache 차트는 WordPress 차트의 `charts/` 디렉터리 안에 저장된다. ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` 위의 예제는 어떻게 WordPress 차트가 Apache와 MySQL에 대한 의존성을 표현하는지 `charts/` 디렉터리에 이 차트들을 포함시킴으로써 보여준다. **팁:** _`charts/` 디렉터리 안에 종속성을 가져오려면, `helm pull` 명령을 사용하라._ ### 의존성 사용의 운영적 관점 위 섹션은 차트 종속성을 어떻게 명시하는지 설명하지만, `helm install` 과 `helm upgrade` 를 사용하는 차트 설치에 어떻게 영향을 미치는가? "A"라는 차트가 다음과 같은 쿠버네티스 오브젝트를 생성한다고 가정하자. - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" A가 오브젝트를 생성하는 B 차트에 의존성을 가진다고 하자. - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" 차트 A의 installation / upgrade 후에, 단일 헬름 릴리즈가 생성 / 수정 된다. 릴리즈는 다음 순서로 위의 쿠버네티스 오브젝트를 전부를 생성 / 업데이트한다. - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet 왜냐하면 헬름이 차트를 설치/업그레이드 할때, 차트와 모든 종속성으로부터 쿠버네티스 오브젝트가 - 단일 집합으로 통합된다. - 이름에 따른 타입으로 정렬된다. - 그 순서에 의해 생성/업데이트 된다. 이런 이유로 단일 릴리즈는 차트와 종속성에 대한 모든 오브젝트와 함께 생성된다. 쿠버네티스 타입의 설치 순서는 kind_sorter.go([the Helm source file](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go))의 열거형 타입 설치 순서에 의해 제공된다. ## 템플릿과 값 헬름 차트 템플릿은 [sprig 라이브러리](https://github.com/Masterminds/sprig)에서 50개 정도의 애드온 템플릿 함수와 몇가지 기타 [특수 함수](/howto/charts_tips_and_tricks.md)가 추가된 [Go template language](https://golang.org/pkg/text/template/)로 작성되었다. 모든 템플릿 파일은 차트의 `templates` 디렉터리 안에 저장된다. 헬름이 차트를 렌더링할때, 템플릿 엔진을 통해 이 디렉터리 안에 모든 파일을 전달한다. 템플릿에 대한 values는 2가지 방법으로 제공된다. - 차트 개발자는 차트의 안에 `values.yaml` 이라 부르는 파일을 제공할 수 있다. 이 파일은 기본 값을 포함할 수 있다. - 차트 사용자는 값을 포함한 YAML파일을 제공할 수 있다. `helm install` 커맨드 라인으로 제공받을 수 있다. 사용자가 커스텀 값을 제공할 때, 차트의 `values.yaml` 파일에 있는 값을 덮어쓴다. ### 템플릿 파일 템플릿 파일은 Go 템플릿 작성에 대한 표준 규약을 따른다 ([텍스트/템플릿 Go 패키지 문서](https://golang.org/pkg/text/template/)). 예제 템플릿 파일은 다음과 같을 수 있다. ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ([https://github.com/deis/charts](https://github.com/deis/charts)에 느슨하게 결합된) 위의 예는 쿠버네티스 리플리케이션 컨트롤러에 대한 템플릿이다. 다음 4가지 템플릿 값을 사용할 수 있다. (보통 `values.yaml` 에 정의된다.) - `imageRegistry`: 도커 이미지의 소스 레지스트리 - `dockerTag`: 도커 이미지의 태그 - `pullPolicy`: 쿠버네티스의 pull 정책 - `storage`: 기본값이 `"minio"`로 설정되는 저장소 백엔드 이 모든 값은 템플릿 작성자에 의해 정의된다. 헬름은 파라미터를 요구하거나 지시하지 않는다. 많은 작동중인 차트를 보려면, [쿠버네티스 차트 프로젝트](https://github.com/helm/charts)를 참고하라. ### 미리 정의된 값 `values.yaml` 파일 (혹은 `--set` 플래그)로 제공되는 값은 템플릿 안에서 `.Values` 객체로 접근 가능하다. 그러나 템플릿 안에서 접근 가능한 다른 미리 정의된 데이터의 조각이 있다. 다음 값은 미리 정의되었고, 모든 템플릿에서 접근 가능하며, 덮어쓸수 없다. 모든 값과 마찬가지로, 이름은 대소문자를 구별한다. - `Release.Name`: 릴리즈의 이름(차트의 이름 아님) - `Release.Namespace`: 차트가 릴리즈된 네임스페이스 - `Release.Service`: 릴리즈를 수행하는 서비스 - `Release.IsUpgrade`: 현재 업그레이드나 롤백중이면 true로 설정된다. - `Release.IsInstall`: 현재 설치중이면 true로 설정된다. - `Chart`: `Chart.yaml`의 내용. 차트의 버전은 `Chart.Version`으로, 메인테이너는 `Chart.Maintainers`로 얻을 수 있다. - `Files`: 차트에 모든 특별하지 않은 파일을 포함하는 맵과 같은 오브젝트입니다. 템플릿에 접근을 제공하지는 않지만, (`.helmignore`로 배제되지 않았다면) 존재하는 추가 파일에 대한 액세스를 제공합니다. 파일은 `{{ index .Files "file.name" }}`나 `{{.Files.Get name }}` 함수를 사용해서 접근할 수 있습니다. `{{ .Files.GetBytes }}`를 사용하여 파일 내용을 `[]byte`로 액세스할 수도 있습니다. - `Capabilities`: 쿠버네티스의 버전(`{{ .Capabilities.KubeVersion }}`)과 지원되는 쿠버네티스 API 버전 (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`)에 대한 정보를 포함하는 맵과 같은 오브젝트입니다. **주의:** 익명의 `Chart.yaml` 필드는 무시된다. 이 필드는 `Chart` 오브젝트의 안에서 접근이 불가능하다. 따라서 `Chart.yaml` 은 템플릿으로 구조화된 데이터를 제멋대로 전달하기 위해 사용될 수 없다. ### 값 파일 이전 섹션에서의 템플릿을 고려할때, 필수적인 값을 제공하는 `values.yaml` 은 다음과 같다. ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` values 파일은 YAML 포맷이다. 차트는 기본 `values.yaml` 파일을 포함한다. 헬름 설치 명령은 추가 YAML 값을 제공함으로써 사용자가 값을 덮어쓸 수 있게한다. ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` 이 방법으로 값이 전달될때, 디폴트 values 파일로 이 값들은 병합된다. 예를 들어, `myvals.yaml` 파일은 다음과 같다고 하자. ```yaml storage: "gcs" ``` 차트의 `values.yaml` 로 병합될때, 생성된 내용의 결과는 다음과 같다. ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` 오직 마지막 필드가 덮여쓰여짐을 주의하라. **참고:** 차트의 안에 포함된 디폴트 값 파일은 `values.yaml` 의 이름을 가져야한다. 반면에, 커맨드 라인에 명시하는 파일은 아무 이름이나 가질 수 있다. **참고:** `--set` 플래그가 `helm install` 이나 `helm upgrade` 에 사용된다면, 이 값들은 클라이언트에서 YAML로 간단하게 변환된다. **참고:** values 파일에 필수적인 엔트리가 있다면, 차트 템플릿에서 ['required' 함수](/howto/charts_tips_and_tricks.md)를 사용함으로써 필수로 정의될 수 있다. 값중 어떤 것이라도 템플릿의 안에서 `.Values` 오브젝트를 사용하여 접근이 가능하다. ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### 범위, 의존성, 값 values 파일은 최상위 차트에 대한 값과 차트의 `charts/` 디렉터리에 포함된 차트중 어떤 것이라도 정의할 수 있다. 또는, 다르게 표현하면, values 파일은 차트와 그것의 종속성 모두에게 값을 제공할 수 있다. 예를 들어 위의 데모 WordPress 차트는 `mysql` 과 `apaches` 모두를 종속성으로 가진다. values 파일은 이 요소들의 모두를 값으로 제공할 수 있다. ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` 더 높은 레벨의 차트는 더 아래 레벨에서 정의된 변수에 대해 엑세스할 수 있다. 그러므로 WordPress 차트는 `.Values.mysql.password` 로 MySQL 패스워드에 접근할 수 있다. 더 낮은 레벨의 차트는 부모차트에 엑세스가 불가능하므로, MySQL은 `title` 속성에 접근할 수 없다. 이 문제로 `apache.port` 에도 접근할 수 없다. 값은 네임스페이스가 지정되지만, 네임스페이스는 정리된다. WordPress 차트에서는 MySQL 패스워드 필드를 `.Values.mysql.password` 로 접근 가능하다. 그러나 MySQL 차트에서는 값의 범위가 축소되고 네임스페이스 접두사가 삭제되므로, `.Values.password` 로 간단히 패스워드 필드를 볼수 있다. #### 전역 값 2.0.0-Alpha.2 현재로, 헬름은 특별한 "전역" 값을 제공한다. 이전 예제의 수정된 버전을 보자. ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` 위에서 값 `app: MyWordPress` 도 함께 `global` 섹션에 추가했다. 이 값은 `.Values.global.app` 으로 모든 차트에서 이용 가능하다. 예를 들어, `mysql` 템플릿은 `app` 을 `{{.Values.global.app}}` 로 접근할 수 있고, `apache` 에서도 마찬가지 이다. 사실상, 위의 values 파일은 다음과 같이 다시 만들어진다. ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` 전역값은 하나의 최상위 레벨 변수를 모든 서브 차트와 공유하는 방법을 제공하고, label 같은 `metadata` 속성을 셋팅하는 것 같은 일에서 유용하다. 서브 차트가 전역 변수를 선언하면, (서브차트의 서브차트에게) _하향_으로 전달되지만, 부모의 차트로 _상향_되지는 않는다. 서브차트가 부모 차트의 값에 영향을 주는 방법은 없다. 또한 부모 차트의 전역 변수는 서브 차트의 전역 변수보다 우선한다. ### 스키마 파일 {#schema-files} 가끔, 차트 메인테이너는 값에 구조를 정의하고 싶을 수 있다. `values.schema.json` 파일에 스키마를 정의함으로써 가능하다. 스키마는 [JSON 스키마](https://json-schema.org/)로 표현된다. 이 스키마는 다음과 같이 보인다. ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` 이 스키마는 유효성 검사를 위해 값에 적용된다. 유효성 검사는 다음 명령중 하나가 일어날때 발생한다. - `helm install` - `helm upgrade` - `helm lint` - `helm template` 이 스키마의 필요조건을 만족한 `values.yaml` 파일의 예는 다음과 같다. ```yaml name: frontend protocol: https port: 443 ``` 스키마가 최종 `.Values` 오브젝트에 적용되고, `values.yaml` 파일에만 적용되지 않는 다는 것을 주의하라. 즉, 다음과 같이 적절한 `--set` 옵션과 함께 차트가 설치되면, 다음 `yaml` 파일은 유효하다. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` 게다가, 최종 `.Values` 오브젝트는 _모든_ 서브차트 스키마에서 체크된다. 즉, 부모차트에 의해 서브차트의 제한은 우회될수 없다. 이 또한 반대 방향으로 작동한다. 서브차트가 서브차트의 `values.yaml` 파일에서 만족하지 못한 필요조건을 가진다면, 부모 차트는 이 조건을 만족 시켜야만한다. 스키마 유효성 검사는 아래 옵션을 설정하여 비활성화할 수 있습니다. 이 기능은 특히 차트의 JSON 스키마 파일에 원격 참조가 포함된 경우 에어갭(air-gapped) 환경에서 유용합니다. ```console helm install --skip-schema-validation ``` ### 참고 자료 템플릿, values, 스키마 파일등을 작성하려면 다음 표준 참고자료가 도움이 될 것이다. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## 사용자 지정 리소스정의 (CRDs) 쿠버네티스는 쿠버네티스 오브젝트의 새로운 타입을 정의하는 것에 대한 메커니즘을 제공한다. 사용자 지정 리소스 정의(CRDs, Custom Resource Definitions)를 사용해서, 쿠버네티스 개발자는 커스텀 리소스 타입을 정의할 수 있다. 헬름 3에서, CRDs는 특별한 객체 종류로 다뤄진다. CRDs는 차트의 나머지보다 먼저 설치되고, 몇몇 제한이 적용된다. CRD YAML 파일은 차트안의 `crds/` 디렉터리에 위치해야한다. (YAML 시작과 끝 마커로 분리된) 다수의 CRDs는 같은 파일에 위치할수 있다. 헬름은 CRD 디렉터리의 _모든_ 파일을 쿠버네티스로 로드하려고 시도한다. CRD 파일은 _템플릿화 될수 없다_. 순수 YAML 문서여야 한다. 헬름이 새로운 차트를 설치할때, CRDs를 업로드 하고, API 서버에 의해 이용가능해지도록 CRD가 만들때까지 정지되며, 템플릿 엔진이 시작하고, 나머지 차트를 렌더링 하고, 쿠버네티스로 업로드한다. 순서때문에, CRD 정보는 헬름 템플릿의 `Capabilities` 오브젝트에서 이용 가능하고, 헬름 템플릿은 CRDs에서 정의된 오브젝트의 새로운 인스턴스를 만들 수 있다. 예를 들어, 차트가 `crds/` 디렉터리에 `CronTab` 에 대한 CRD를 가진다면, `templates/` 디렉터리 안에 `CronTab` 종류의 인스턴스를 생성할 수 있다. ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` `crontab.yaml` 파일은 반드시 템플릿 명령 없이 CRD를 포함해야한다. ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` 그러면 템플릿 `mycrontab.yaml` 은 (보통 템플릿을 사용하여) 새로운 `CronTab` 을 생성할 수 있다. ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` 헬름은 `templates/` 안에 것들을 설치하기 전에 `CronTab` kind가 설치되어 있고, 쿠버네티스 API 서버에서 이용 가능한지 확인한다. ### CRD 에서의 제약사항 대부분의 쿠버네티스에서의 오브젝트와 다르게, CRDs는 전역으로 설치된다. 이 이유로, 헬름은 CRDs를 관리하는 것에 매우 조심스럽게 접근한다. CRDs는 다음 제약이 적용된다. - CRDs는 절대 재설치 불가능하다. 헬름이 (버전에 상관 없이) `crds/` 디렉터리에 CRDs가 존재한다는 것을 알아낸다면, 헬름은 설치나 업그레이드 시도를 하지 않는다. - CRDs는 절대 업그레이드나 롤백이 불가능하다. 헬름은 오직 설치 작업시에만 CRDs를 생성한다. - CRDs는 절대 삭제될수 없다. CRD를 자동으로 지우는 것은 모든 클러스터 안의 네임스페이스에 영향을 주는 CRD's 내용의 모든것을 삭제한다. 따라서, 헬름은 CRDs를 삭제하지 않는다. CRDs를 업그레이드나 삭제하고 싶으면 몹시 조심하여 수동으로 수행하라. ## 헬름을 사용하여 차트 관리하기 `helm` 도구에는 차트 작업을 위한 몇몇 명령이 있다. 다음은 새로운 차트를 생성한다. ```console $ helm create mychart Created mychart/ ``` 일단 차트를 수정하면, `helm` 은 차트아카이브로 패키징할 수 있다. ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` 차트의 포맷이나 정보 이슈를 찾는 것에 `helm` 을 사용할 수 있다. ```console $ helm lint mychart No issues found ``` ## 차트 저장소 차트 저장소는 한 개 이상의 패키징된 차트를 저장할 공간을 제공하는 HTTP 서버이다. `helm` 은 로컬 차트 디렉터리를 관리하는데 사용되는 반면, 차트를 공유하려면 우선되는 메커니즘은 차트 저장소이다. YAML 파일과 tar 파일을 제공하고 GET 요청에 응답할 수 있는 어떤 HTTP서버든 저장소 서버로 사용될 수 있다. 헬름 팀은 웹 사이트 모드 활성화로 구글 클라우드 스토리지(Google Cloud Storage) 및 S3를 포함해서 몇몇 서버를 테스트했다. 주로 저장소에 의해 제공되는 패키지의 모든 리스트를 가진 특별한 `index.yaml` 파일의존재와 검색 및 패키지 검증을 허용하는 메타데이터로 저장소를 특정한다. 클라이언트 측면에서, 저장소는 `helm repo` 명령으로 관리된다. 그러나, 헬름은 원격 저장소 서버에 차트를 업로드하는 것에 대한 도구를 제공하지 않는다. 그렇게 하는 것이 서버를 구현하기 위해 상당한 요구사항을 추가하고, 저장소를 셋팅하는 것에 대한 장벽을 만들어내기 때문이다. ## 차트 사용 팩 `helm create` 명령은 "스타터 차트"를 지정할 수 있는 선택적 `--starter` 옵션을 제공합니다. 또한 스타터 옵션은 `-p` 단축 별칭을 가지고 있습니다. 사용 예제: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` 스타터는 일반적인 차트이지만 `$XDG_DATA_HOME/helm/starters`에 위치합니다. 차트 개발자는 스타터로 사용하도록 특별히 디자인된 차트를 작성할 수 있습니다. 이런 차트는 다음 고려사항을 염두에 두고 디자인되어야 합니다: - `Chart.yaml`은 제너레이터에 의해 덮어쓰여진다. - 사용자는 이 차트의 내용을 수정하기 원하므로, 문서는 어떻게 사용자가 그럴 수 있는지 알려줘야한다. - 모든 `` 항목은 지정된 차트 이름으로 교체되어 스타터 차트를 템플릿으로 사용할 수 있습니다. 단, `vars` 디렉터리의 사용자 정의 파일이나 특정 `README.md` 파일 같은 일부 변수 파일은 예외입니다. ``은 이러한 파일 내부에서는 교체되지 않습니다. 또한 차트 설명은 상속되지 않습니다. 현재 `$XDG_DATA_HOME/helm/starters`에 차트를 추가하는 유일한 방법은 수동으로 복사하는 것입니다. 차트의 문서에서 이 과정을 설명할 수 있습니다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: 차트 훅(hooks) description: 차트 훅을 이용하여 작업하는 방법을 설명한다. sidebar_position: 2 --- 헬름은 차트 개발자가 릴리스 수명주기의 특정 지점에 개입할 수 있도록 _hook_ 매커니즘을 제공한다. 예를 들어 다음과 같은 것들을 하기 위해 훅을 사용할 수 있다. - 설치 시 다른 차트가 로드되기 전에 컨피그맵이나 시크릿을 로드한다. - 새 차트를 설치하기 전에 데이터베이스를 백업하는 작업을 실행하고, 데이터 복원을 위해 업그레이드 후 2번째 작업을 수행한다. - 릴리스를 제거하기 전에 서비스를 순환에서 안전하게 제거하기 위하여, 릴리스 삭제 전에 작업을 수행한다. 훅은 일반적인 템플릿처럼 작동하지만 헬름이 다른 방식으로 처리하도록 하는 특수한 어노테이션이 있다. 이 섹션에서는 훅의 기본 사용 패턴을 다룬다. ## 사용 가능한 훅 훅은 다음과 같이 정의되어 있다. | 어노테이션 값 | 설명 | | ---------------- | ----------------------------------------------------------------------------------------------------- | | `pre-install` | 템플릿은 렌더링되었지만, 쿠버네티스에서 아직 아무 리소스도 생성되기 전에 실행된다. | | `post-install` | 쿠버네티스에 모든 리소스가 로드된 후에 실행된다. | | `pre-delete` | 삭제 요청 중에서, 쿠버네티스에서 리소스가 삭제되기 전에 실행된다. | | `post-delete` | 삭제 요청 중에서, 릴리스의 모든 리소스가 삭제된 후 실행된다. | | `pre-upgrade` | 업그레이드 요청 중에서, 템플릿은 렌더링되었지만 리소스는 업데이트되기 전에 실행된다. | | `post-upgrade` | 업그레이드 요청 중에서, 모든 리소스가 업그레이드된 후 실행된다. | | `pre-rollback` | 롤백 요청 중에서, 템플릿은 렌더링되었지만 아직 아무 리소스도 롤백되지 않은 시점에 실행된다. | | `post-rollback` | 롤백 요청 중에서, 모든 리소스가 수정된 후에 실행된다. | | `test` | 헬름 test 하위 명령어가 호출될 때 실행된다. ([테스트 문서 보기](/topics/chart_tests.md)) | _헬름 3에서는 `crd-install` 훅은 제거되었고 대신 `crds/` 디렉터리를 사용한다는 점을 잊지 말자._ ## 훅과 릴리스 수명주기 훅을 사용하면 차트 개발자는 릴리스 수명주기 상의 중요 시점에서 작업이 수행되도록 할 수 있다. 예를 들어 `helm install` 의 수명주기를 생각해보자. 기본적으로 수명주기는 다음과 같다. 1. 사용자가 `helm install foo` 를 실행한다. 2. 헬름 라이브러리 설치 API가 호출된다. 3. 검증 후, 라이브러리는 `foo` 템플릿을 렌더링한다. 4. 라이브러리는 결과로 나온 리소스를 쿠버네티스에 로드한다. 5. 라이브러리는 릴리스 객체(및 다른 데이터)를 클라이언트에 반환한다. 6. 클라이언트가 종료된다. 헬름은 `install` 수명주기에 대해 `pre-install` 및 `post-install` 의 두 가지 훅을 정의한다. `foo` 차트의 개발자가 두 훅을 모두 구현하면 수명주기는 다음과 같이 바뀐다. 1. 사용자가 `helm install foo` 를 실행한다. 2. 헬름 라이브러리 설치 API가 호출된다. 3. `crds/` 디렉터리의 CRD가 설치된다. 4. 검증 후 라이브러리는 `foo` 템플릿을 렌더링한다. 5. 라이브러리는 `pre-install` 훅 실행을 준비한다. (쿠버네티스에 훅 리소스 로딩) 6. 라이브러리는 가중치(기본값으로는 0을 할당), 리소스 종류, 이름을 기준으로 훅을 오름차순으로 정렬한다. 7. 라이브러리는 가장 낮은 가중치의 훅을 먼저 로드한다.(음수에서 양수로) 8. 라이브러리는 훅이 "Ready" 될 때까지 대기한다(CRD 제외). 9. 라이브러리는 결과로 나온 리소스를 쿠버네티스에 로드한다. `--wait` 플래그가 설정된 경우 라이브러리는 모든 리소스가 "Ready" 상태가 될 때까지 대기하고, 준비가 될 때까지 `post-install` 훅을 실행하지 않는다. 10. 라이브러리는 `post-install` 훅을 실행한다. (훅 리소스 로딩) 11. 라이브러리는 훅이 "Ready" 될 때까지 기다린다. 12. 라이브러리는 릴리스 객체(및 다른 데이터)를 클라이언트에 반환한다. 13. 클라이언트가 종료된다. 훅이 준비될 때까지 기다린다는 것은 무엇을 의미하는가? 이것은 훅에 선언된 리소스에 따라 다르다. 리소스가 `Job` 또는 `Pod` 종류인 경우 헬름은 성공적으로 실행 완료될 때까지 기다린다. 훅이 실패하면 릴리스는 실패하게 된다. 이것은 _블로킹(blocking) 작업_이므로 작업이 실행되는 동안 헬름 클라이언트는 일시정지될 것이다. 다른 모든 종류의 경우, 쿠버네티스가 리소스를 로드(추가 또는 업데이트)하였다고 표시하는 즉시, 리소스는 "Ready" 로 간주된다. 훅에 많은 리소스가 선언되면 리소스들은 연속적으로 실행된다. 훅 가중치(아래 참조)가 있으면, 가중치 순서대로 실행된다. 헬름 3.2.0 부터 같은 가중치를 가진 훅 리소스들은 훅이 없는 일반 리소스와 같은 순서로 설치된다. 그밖의 경우에는 순서가 보장되지 않는다. (헬름 2.3.0 이상에서는 알파벳순으로 정렬된다. 그러나 이 동작은 바인딩으로 간주되지 않으며 향후 변경될 수 있다.) 여기까지가 훅 가중치 추가시 고려할 사항이며, 만약 가중치가 중요하지 않다면 `0` 으로 설정하는 것이 좋다. ### 해당 릴리스에 의해 관리되지 않는 훅 리소스 훅이 생성하는 리소스는 현재 릴리스의 일부로 추적되거나 관리되지 않는다. 헬름은 훅이 준비 상태까지 도달했는지를 확인했다면 훅 리소스를 그대로 남겨둔다. 향후 헬름 3에 릴리스 삭제시 훅 리소스에 대한 가비지 수집 기능이 추가될 수 있으므로, 삭제되면 안되는 모든 훅 리소스에 `helm.sh/resource-policy: keep` 어노테이션을 추가해야 한다. 실질적으로, 이는 훅 리소스를 만드는 경우 `helm uninstall` 으로 리소스를 제거할 수 없음을 의미한다. 이러한 리소스를 삭제하려면 훅 템플릿 파일에 [사용자 지정 `helm.sh/hook-delete-policy` 어노테이션을 추가](#훅-삭제-정책)하거나 작업(Job) 리소스의 [time to live(TTL) 필드를 설정](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)해야 한다. ## 훅 작성하기 훅은 `metadata` 섹션에 특별한 어노테이션이 있는 쿠버네티스 매니페스트 파일이다. 템플릿 파일이기 때문에 `.Values`, `.Release` 및 `.Template` 을 읽기를 포함한 모든 일반 템플릿 기능을 사용할 수 있다. 예를 들어 `templates/post-install-job.yaml` 에 저장된 템플릿은 `post-install` 에서 실행할 작업을 선언한다. ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` 다음의 어노테이션으로 이 템플릿을 훅으로 만든다. ```yaml annotations: "helm.sh/hook": post-install ``` 하나의 리소스는 여러 개의 훅으로 구현할 수 있다. ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` 마찬가지로, 주어진 훅을 구현하는 다양한 리소스의 수에는 제한이 없다. 예를 들어 시크릿과 컨피그맵을 둘다 pre-install 훅으로 선언할 수 있다. 하위 차트에 훅이 선언되면 해당 훅도 평가된다. 최상위 차트가 하위 차트에 선언된 훅을 비활성화할 수 있는 방법은 없다. 결정적 실행순서를 정하는데 도움이 되는 훅에 대한 가중치를 정의할 수 있다. 가중치는 다음의 어노테이션을 사용하여 정의한다. ```yaml annotations: "helm.sh/hook-weight": "5" ``` 훅 가중치는 양수여도 되고 음수여도 되지만 문자열로 표기해야 한다. 헬름이 특정 종류의 훅 실행주기를 시작하면 해당 훅을 오름차순으로 정렬한다. ### 훅 삭제 정책 대상 훅 리소스를 언제 삭제할지를 결정하는 정책을 정의할 수 있다. 훅 삭제 정책은 다음과 같은 어노테이션을 사용하여 정의한다. ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` 한개 혹은 그 이상의 정의된 어노테이션 값을 선택할 수 있다. | 어노테이션 값 | 설명 | | ---------------------- | -------------------------------------------------------------------- | | `before-hook-creation` | 새 훅이 시작되기 전에 이전 리소스를 삭제한다. (기본값) | | `hook-succeeded` | 훅이 성공적으로 실행된 후에 리소스를 삭제한다. | | `hook-failed` | 실행 중 훅이 실패한 경우 리소스를 삭제한다. | 훅 삭제 정책 어노테이션이 지정되지 않은 경우, 기본적으로 `before-hook-creation` 동작이 적용된다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: 주제 sidebar_position: 3 --- # 주제 가이드 알고 싶었던 헬름의 모든 핵심부분에 관한 설명을 이곳에서 찾을 수 있을 것이다. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: "사용 중단된 쿠버네티스 APIs" description: "헬름에서 사용 중단된 쿠버네티스 API에 대해 설명한다." --- 쿠버네티스는 API 주도 시스템이며, 시간이 지남에 따라 문제 공간(problem space)에 대한 이해가 깊어지면서 이를 반영하기 위해 API 도 진화한다. 이는 어떤 시스템이나 그에 따른 API에서 나타나는 일반적인 관행이다. 진화하는 API에서 중요한 것은, 적절한 지원 중단 정책과 구현된 API의 변화를 사용자에게 알리는 프로세스이다. 다시 말해서, API 소비자는 사전에 API 가 제거되거나 변경되는 릴리스에 대하여 알 수 있어야 한다. 그렇게 해야 소비자는 예상하지 못한 부분이나 규모가 단절적(breaking) 변화의 요소를 방지할 수 있다. [쿠버네티스 사용 중단 정책](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)은 쿠버네티스가 API 버전의 변경 사항을 처리하는 방법을 담은 문서이다. 지원 중단 정책에는 지원 중단 발표 후 API 버전이 지원되는 기간이 명시되어 있다. 따라서 영향도를 최소화하려면 지원 중단 공지를 주시하고 API 버전이 제거되는 시기를 알아두는 것이 중요하다. 이것은 [쿠버네티스 1.16에서 더 이상 사용되지 않는 API 버전을 제거하기 위한](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) 발표의 예시이며 릴리스 몇 달 전에 발표되었다. 이러한 API 버전은 지원중단에 앞서 한번 더 안내되었다. 이는 API 버전 지원을 소비자에게 알리는 적절한 정책이 있음을 나타낸다. 헬름 템플릿은 쿠버네티스 메니페스트 파일과 유사하게 쿠버네티스 객체를 정의할 때 [쿠버네티스 API 그룹](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)을 지정한다. 템플릿의 `apiVersion` 필드에 지정되며 쿠버네티스 객체의 API 버전을 식별한다. 즉, 헬름 사용자와 차트 유지관리자는 쿠버네티스 API 버전이 언제 사용 중단(deprecated)되고 어느 쿠버네티스 버전에서 제거되는지를 알고 있어야 한다. ## 차트 관리자 차트에 있는 쿠버네티스 API 버전이 어느 쿠버네티스 버전에서 사용중단되거나 제거되는지를 감사(audit)해야 한다. 지원 중단이 예정되어 있거나 이미 중단된 API 버전은 지원되는 버전으로 바꾸고 출시되는 차트도 새로운 버전으로 업데이트해야 한다. API 버전은 `kind` 및 `apiVersion` 필드로 정의된다. 예를 들어 쿠버네티스 1.16 에서 제거된 `Deployment` 객체의 API 버전은 다음과 같다. ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## 헬름 사용자 사용자는 ([차트 관리자](#차트-관리자)와 유사하게) 사용하는 차트를 감사(audit)하고, 쿠버네티스 버전에서 API 버전이 사용중단되거나 제거된 차트를 식별해야 한다. 식별된 차트의 경우 최신 버전의 차트(API 버전을 지원하는)가 있는지 확인하거나 직접 차트를 업데이트해야 한다. 또한, 배포된 모든 차트(예: 헬름 릴리스)를 감사(audit)하여 사용중단되거나 제거된 API 버전을 다시 확인해야 한다. `helm get manifest` 명령어를 사용하여 릴리스의 세부사항을 보면 된다. 확인한 바에 따라, 헬름 릴리스를 지원되는 API로 업데이트하는 방법은 다음과 같다. 1. 지원 중단된 API 버전만을 찾는 경우, - 지원되는 쿠버네티스 API 버전이 포함된 차트 버전으로 `helm upgrade` 수행 - 현재 버전 이전의 헬름 버전으로 롤백되지 않도록 업그레이드에 대한 설명(description) 추가 2. 쿠버네티스 버전에서 제거된 API 버전을 찾는 경우, - API 버전을 계속 사용할 수 있는 쿠버네티스 버전을 실행 중이라면(예: 쿠버네티스 1.15 에 있고, 쿠버네티스 1.16 에서 제거될 API를 사용하는 경우): - 1 단계 절차를 수행한다. - 그렇지 않다면(예: `helm get manifest` 에서 나온 API 버전을 더 이상 사용할 수 없는 쿠버네티스 버전을 사용 중인 경우): - API 버전을 지원되는 API로 업데이트하려면 클러스터에 저장된 릴리스 매니페스트를 편집해야 한다. 자세한 내용은 [릴리스 매니페스트의 api 버전 업데이트](#릴리스-매니페스트의-api-버전-업데이트)를 참조하자. > 참고: 지원되는 API로 헬름 릴리스를 업데이트하는 모든 경우에, 지원되는 API 가 있는 릴리스 버전 이전 버전으로 릴리스를 롤백해서는 안된다. > 권고: 해당 API 버전이 제거되는 쿠버네티스 클러스터 업그레이드 작업 전에, 사용중단된 API 버전을 사용하는 릴리스를 지원되는 API 버전으로 업그레이드하는 것이 모범사례이다. 위와 같이 릴리스를 업데이트하지 않으면, API 버전이 제거된 쿠버네티스 버전에서 릴리스를 업그레이드하려고 할 때 다음과 유사한 오류가 발생할 수 있다. ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` 헬름은 업데이트/지원되는 API 버전과 함께 전달받은 차트를 가지고, 현재 배포된 릴리스간의 diff 패치(이 쿠버네티스 버전에서 제거된 쿠버네티스 API를 포함)를 만드려고 하기 때문에 이 시나리오는 실패하게 된다. 실패의 근본적인 이유는, 쿠버네티스가 API 버전을 제거하면 쿠버네티스 Go 클라이언트 라이브러리가 더 이상 지원 중단된 객체를 파싱할 수 없기 때문에 헬름이 라이브러리를 호출할 수 없기 때문이다. 헬름은 안타깝게도 이 상황을 복구할 수 없으며 더 이상 이러한 릴리스는 관리할 수 없다. 이 시나리오에서 복구하는 방법에 대한 자세한 내용은 [릴리스 매니페스트의 api 버전 업데이트](#릴리스-매니페스트의-api-버전-업데이트)를 참조하자. ## 릴리스 매니페스트의 api 버전 업데이트 매니페스트는 클러스터에서 시크릿(기본값) 또는 컨피그맵의 데이터 필드에 저장되는 헬름 릴리스 객체의 속성이다. 데이터 필드에는 base 64 로 인코딩되어 gzip 으로 압축된 객체가 담겨 있다. (시크릿에는 추가적인 base 64 인코딩이 적용된다.) 릴리스의 네임스페이스에는 릴리스 버전/리비전마다의 시크릿/컨피그맵들이 있게 된다. 사용자는 헬름 [mapkubeapis](https://github.com/helm/helm-mapkubeapis) 플러그인을 사용하여 지원되는 API에 대한 릴리스 업데이트를 수행할 수 있다. 자세한 내용은 readme 를 확인하자. 또는 다음의 단계에 따라 수동으로 릴리스 매니페스트의 API 버전 업데이트를 수행할 수 있다. 구성에 따라 시크릿 또는 컨피그맵 백엔드에 대한 작업단계를 따라야 한다. - 배포된 최신 릴리스와 관련된 시크릿 또는 컨피그맵의 이름을 가져온다. - 시크릿 백엔드: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - 컨피그맵 백엔드: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - 배포된 최신 릴리스 정보를 가져온다. - 시크릿 백엔드: `kubectl get secret -n -o yaml > release.yaml` - 컨피그맵 백엔드: `kubectl get configmap -n -o yaml > release.yaml` - 문제가 발생하여 복원해야 하는 경우 릴리스를 백업한다.: - `cp release.yaml release.bak` - 비상시에 복구해야 할 경우: `kubectl apply -f release.bak -n ` - 릴리스 객체를 디코딩한다: - 시크릿 백엔드:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - 컨피그맵 백엔드: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - 매니페스트의 API 버전을 변경한다. 모든 도구(예: 편집기)를 사용하여 변경할 수 있다. 이것은 디코딩 된 릴리스 객체의 (`release.data.decoded`)의 `manifest` 필드에 존재한다. - 릴리스 객체를 인코딩한다: - 시크릿 백엔드: `cat release.data.decoded | gzip | base64 | base64` - 컨피그맵 백엔드: `cat release.data.decoded | gzip | base64` - 배포된 릴리스 파일(`release.yaml`)의 `data.release` 속성 값을 인코딩 된 새 릴리스 객체로 변경한다. - 파일을 네임스페이스에 적용한다: `kubectl apply -f release.yaml -n ` - 지원되는 쿠버네티스 API 버전이 있는 차트 버전으로 `helm upgrade` 를 수행한다. - 현재 버전 이전의 헬름 버전으로 롤백하지 않도록 업그레이드에 설명을 추가한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: 쿠버네티스 배포판 가이드 description: 특정 쿠버네티스 환경에서 헬름 사용에 대한 정보 정리. sidebar_position: 10 --- 헬름은 ([인증 여부](https://www.cncf.io/certification/software-conformance/)와 관계 없이) 모든 [쿠버네티스 적합 버전](https://github.com/cncf/k8s-conformance)에서 작동해야 한다. 이 문서는 특정 쿠버네티스 환경에서 헬름을 사용하는 방법에 대한 정보를 정리한다. 원한다면, 특정 배포판(알파벳순 정렬)에 대한 추가 내용을 기여하자. ## AKS 헬름은 [Azure 쿠버네티스 서비스](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm)에서 동작한다. ## DC/OS 헬름은 Mesospheres DC/OS 1.11 쿠버네티스 플랫폼에서 테스트를 거쳤고 동작하며, 추가 구성이 필요치 않다. ## EKS 헬름은 Amazon Elastic 쿠버네티스 서비스 (Amazon EKS)에서 동작한다. [Amazon EKS에서 헬름 사용](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE 구글의 GKE 호스팅 쿠버네티스 플랫폼은 헬름이 동작하는 것으로 알려져 있으며, 추가 구성이 필요치 않다. ## `scripts/local-cluster` 와 Hyperkube `scripts/local-cluster.sh` 를 통해 구성된 Hyperkube 에서 동작하는 것으로 알려져 있다. 원시(raw) Hyperkube 는 몇 가지 수동 구성이 필요할 수도 있다. ## IKS 헬름은 [IBM 클라우드 쿠버네티스 서비스](https://cloud.ibm.com/docs/containers?topic=containers-helm)에서 동작한다. ## KIND (Kubernetes IN Docker) 헬름은 [KIND](https://github.com/kubernetes-sigs/kind)에서 정기적으로 테스트된다. ## KubeOne 헬름은 별다른 특이사항 없이 KubeOne 으로 구성된 클러스터에서 동작한다. ## Kubermatic 헬름은 별다른 특이사항 없이 Kubermatic 으로 생성된 사용자 클러스터에서 동작한다. 시드(seed) 클러스터는 다양한 방식으로 설정될 수 있으므로 헬름 지원은 그 설정에 따라 달라진다. ## MicroK8s [MicroK8s](https://microk8s.io) 에서는 명령어 `microk8s.enable helm3`를 사용하여 헬름을 활성화할 수 있다. ## Minikube 헬름은 [Minikube](https://github.com/kubernetes/minikube) 에서 테스트를 거쳤고 동작하는 것으로 알려져 있다. 추가적인 구성이 필요하지 않다. ## Openshift 헬름은 OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (버전 3.6 이상) 또는 OpenShift Origin (버전 3.6 이상)에서 동작한다. 자세한 내용은 [이 블로그](https://blog.openshift.com/getting-started-helm-openshift/) 의 게시물을 참조하자. ## Platform9 헬름은 [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes)와 함께 사전 설치된다. Platform9 은 앱 카탈로그 UI 및 기본 쿠버네티스 CLI를 통해 모든 공식 헬름 차트에 대한 접근을 제공한다. 추가적인 레포지토리들도 수동으로 추가할 수 있다. 상세한 내용은 [Platform9 App Catalog article](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes)에서 확인할 수 있다. ## 우분투와 `kubeadm` `kubeadm` 으로 구성된(bootstrapped) 쿠버네티스는 다음 리눅스 배포판에서 동작하는 것으로 알려져 있다. - 우분투 16.04 - 페도라 릴리스 25 헬름 일부 버전(v2.0.0-beta2)은 `export KUBECONFIG=/etc/kubernetes/admin.conf` 를 수행하거나 `~/.kube/config` 를 생성해야 한다. ## VMware Tanzu Kubernetes Grid 헬름은 VMware Tanzu Kubernetes Grid(TKG)에서 추가 구성 변경 없이 동작한다. Tanzu CLI는 [helm-controller](https://fluxcd.io/flux/components/helm/) 패키지 설치를 관리할 수 있다. 이를 통해 헬름 차트 릴리스를 선언적으로 관리할 수 있다. 자세한 내용은 TKG 문서의 [CLI 관리 패키지](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5)를 참조하자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: 라이브러리 차트 description: 라이브러리 차트의 개념과 사용 예제를 설명합니다 sidebar_position: 4 --- 라이브러리 차트는 [Helm 차트](/topics/charts.md)의 한 유형으로, 다른 차트의 Helm 템플릿에서 공유할 수 있는 차트 기본 요소나 정의를 제공합니다. 이를 통해 사용자는 여러 차트에서 재사용할 수 있는 코드 조각을 공유하고, 반복을 피하며 차트를 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)하게 유지할 수 있습니다. 라이브러리 차트는 Helm 2부터 차트 관리자들이 사용해온 공용 또는 헬퍼 차트를 공식적으로 인정하기 위해 Helm 3에서 도입되었습니다. 차트 유형으로 포함함으로써 다음과 같은 기능을 제공합니다: - 공용 차트와 애플리케이션 차트를 명확하게 구분하는 수단 - 공용 차트의 설치를 방지하는 로직 - 릴리스 아티팩트를 포함할 수 있는 공용 차트의 템플릿 렌더링 방지 - 의존하는 차트가 가져오는 쪽의 컨텍스트를 사용할 수 있도록 허용 차트 관리자는 공용 차트를 라이브러리 차트로 정의하면 Helm이 표준화되고 일관된 방식으로 해당 차트를 처리할 것이라고 확신할 수 있습니다. 또한 차트 유형을 변경하여 애플리케이션 차트의 정의를 공유할 수 있습니다. ## 간단한 라이브러리 차트 만들기 앞서 언급했듯이, 라이브러리 차트는 [Helm 차트](/topics/charts.md)의 한 유형입니다. 따라서 스캐폴드 차트를 생성하는 것부터 시작할 수 있습니다: ```console $ helm create mylibchart Creating mylibchart ``` 먼저 `templates` 디렉토리의 모든 파일을 삭제합니다. 이 예제에서는 직접 템플릿 정의를 만들 것입니다. ```console $ rm -rf mylibchart/templates/* ``` values 파일도 필요하지 않습니다. ```console $ rm -f mylibchart/values.yaml ``` 공용 코드를 작성하기 전에, 관련된 Helm 개념을 간단히 살펴보겠습니다. [이름이 지정된 템플릿](/chart_template_guide/named_templates.md)(partial 또는 subtemplate이라고도 함)은 파일 내에 정의되고 이름이 부여된 템플릿입니다. `templates/` 디렉토리에서 밑줄(_)로 시작하는 파일은 Kubernetes 매니페스트 파일을 출력하지 않습니다. 따라서 관례적으로 헬퍼 템플릿과 partial은 `_*.tpl` 또는 `_*.yaml` 파일에 배치합니다. 이 예제에서는 빈 ConfigMap 리소스를 생성하는 공용 ConfigMap을 작성합니다. 공용 ConfigMap은 `mylibchart/templates/_configmap.yaml` 파일에 다음과 같이 정의합니다: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` ConfigMap 구조는 `mylibchart.configmap.tpl`이라는 이름이 지정된 템플릿에 정의됩니다. 빈 리소스 `data`를 가진 간단한 ConfigMap입니다. 이 파일에는 `mylibchart.configmap`이라는 또 다른 이름이 지정된 템플릿이 있습니다. 이 템플릿은 `mylibchart.util.merge`라는 또 다른 이름이 지정된 템플릿을 포함하며, `mylibchart.configmap`을 호출하는 템플릿과 `mylibchart.configmap.tpl`이라는 두 개의 이름이 지정된 템플릿을 인수로 받습니다. 헬퍼 함수 `mylibchart.util.merge`는 `mylibchart/templates/_util.yaml`에 있는 이름이 지정된 템플릿입니다. 이것은 [공용 Helm 헬퍼 차트](#공용-helm-헬퍼-차트)에서 가져온 유용한 유틸리티로, 두 템플릿을 병합하고 공통 부분을 덮어씁니다: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` 차트가 자체 설정으로 사용자 정의해야 하는 공용 코드를 사용하려는 경우에 이것이 중요합니다. 마지막으로 차트 유형을 `library`로 변경합니다. `mylibchart/Chart.yaml`을 다음과 같이 편집합니다: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` 이제 라이브러리 차트를 공유할 준비가 되었으며, ConfigMap 정의를 재사용할 수 있습니다. 계속 진행하기 전에, Helm이 해당 차트를 라이브러리 차트로 인식하는지 확인해 볼 가치가 있습니다: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## 간단한 라이브러리 차트 사용하기 이제 라이브러리 차트를 사용할 차례입니다. 다시 스캐폴드 차트를 생성합니다: ```console $ helm create mychart Creating mychart ``` ConfigMap만 생성할 것이므로 템플릿 파일들을 다시 정리합니다: ```console $ rm -rf mychart/templates/* ``` Helm 템플릿에서 간단한 ConfigMap을 생성하려면 다음과 비슷한 형태가 됩니다: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` 그러나 우리는 `mylibchart`에 이미 작성된 공용 코드를 재사용할 것입니다. ConfigMap은 `mychart/templates/configmap.yaml` 파일에 다음과 같이 생성할 수 있습니다: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` ConfigMap의 표준 속성을 추가하는 공용 ConfigMap 정의를 상속받아 작업을 단순화한 것을 볼 수 있습니다. 우리의 템플릿에서는 설정만 추가합니다. 이 경우 데이터 키 `myvalue`와 그 값입니다. 이 설정은 공용 ConfigMap의 빈 리소스를 덮어씁니다. 이것은 이전 섹션에서 언급한 헬퍼 함수 `mylibchart.util.merge` 덕분에 가능합니다. 공용 코드를 사용하려면 `mylibchart`를 의존성으로 추가해야 합니다. `mychart/Chart.yaml` 파일 끝에 다음을 추가합니다: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` 이것은 애플리케이션 차트와 동일한 상위 경로에 있는 파일 시스템에서 라이브러리 차트를 동적 의존성으로 포함합니다. 라이브러리 차트를 동적 의존성으로 포함하므로 `helm dependency update`를 실행해야 합니다. 이 명령은 라이브러리 차트를 `charts/` 디렉토리로 복사합니다. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` 이제 차트를 배포할 준비가 되었습니다. 설치하기 전에 먼저 렌더링된 템플릿을 확인해 보는 것이 좋습니다. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` 원하는 대로 `myvalue: Hello World` 데이터가 덮어씌워진 ConfigMap처럼 보입니다. 설치해 봅시다: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` 릴리스를 조회하여 실제 템플릿이 로드되었는지 확인할 수 있습니다. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## 라이브러리 차트의 장점 라이브러리 차트는 독립 실행형 차트로 동작할 수 없기 때문에 다음과 같은 기능을 활용할 수 있습니다: - `.Files` 객체는 라이브러리 차트의 로컬 경로가 아닌 부모 차트의 파일 경로를 참조합니다 - `.Values` 객체는 부모 차트와 동일합니다. 이는 부모의 헤더 아래에 설정된 값 섹션을 받는 애플리케이션 [서브차트](/chart_template_guide/subcharts_and_globals.md)와 대조됩니다 ## 공용 Helm 헬퍼 차트 ```markdown 참고: GitHub의 공용 Helm 헬퍼 차트 리포지토리는 더 이상 적극적으로 유지 관리되지 않으며, 해당 리포지토리는 더 이상 사용되지 않고 보관되었습니다. ``` 이 [차트](https://github.com/helm/charts/tree/master/incubator/common)는 공용 차트의 원래 패턴이었습니다. Kubernetes 차트 개발의 모범 사례를 반영하는 유틸리티를 제공합니다. 무엇보다도 차트를 개발할 때 바로 사용하여 편리한 공유 코드를 활용할 수 있습니다. 다음은 이를 사용하는 빠른 방법입니다. 자세한 내용은 [README](https://github.com/helm/charts/blob/master/incubator/common/README.md)를 참조하세요. 다시 스캐폴드 차트를 생성합니다: ```console $ helm create demo Creating demo ``` 헬퍼 차트의 공용 코드를 사용해 봅시다. 먼저 deployment `demo/templates/deployment.yaml`을 다음과 같이 편집합니다: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` 그리고 service 파일 `demo/templates/service.yaml`을 다음과 같이 편집합니다: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` 이 템플릿들은 헬퍼 차트의 공용 코드를 상속받아 리소스의 설정 또는 사용자 정의만으로 코딩을 단순화하는 방법을 보여줍니다. 공용 코드를 사용하려면 `common`을 의존성으로 추가해야 합니다. `demo/Chart.yaml` 파일 끝에 다음을 추가합니다: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` 참고: Helm 리포지토리 목록에 `incubator` 리포지토리를 추가해야 합니다 (`helm repo add`). 차트를 동적 의존성으로 포함하므로 `helm dependency update`를 실행해야 합니다. 이 명령은 헬퍼 차트를 `charts/` 디렉토리로 복사합니다. 헬퍼 차트가 일부 Helm 2 구조를 사용하므로, Helm 3 스캐폴드 차트에서 업데이트된 `nginx` 이미지를 로드하려면 `demo/values.yaml`에 다음을 추가해야 합니다: ```yaml image: tag: 1.16.0 ``` `helm lint`와 `helm template` 명령을 사용하여 배포 전에 차트 템플릿이 올바른지 테스트할 수 있습니다. 문제가 없다면 `helm install`을 사용하여 배포하세요! ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: "SQL 스토리지 백엔드에 대한 권한 관리" description: "SQL 스토리지 백엔드를 사용할 때 권한을 설정하는 방법을 알아본다." --- 이 문서에서는 SQL 스토리지 백엔드 사용 시 권한을 설정하고 관리하는 방법을 설명한다. ## 소개 권한을 처리하기 위해 헬름은 쿠버네티스의 RBAC 기능을 사용한다. SQL 스토리지 백엔드를 사용할 때는 쿠버네티스의 역할을 사용하여 사용자가 특정 리소스에 액세스할 수 있는지 여부를 결정할 수 없다. 이 문서는 이러한 권한을 생성하고 관리하는 방법을 보여준다. ## 초기화 헬름 CLI가 처음으로 데이터베이스에 연결되면, 클라이언트는 이전에 초기화되었는지 확인한다. 그렇지 않은 경우 필요한 설정을 자동으로 처리한다. 이 초기화에는 퍼블릭 스키마에 대한 관리자 권한이 필요하거나 최소한 다음을 수행할 수 있어야 한다. * 테이블 생성 * 퍼블릭 스키마에 대한 권한 부여 데이터베이스에 대한 마이그레이션이 실행된 후, 다른 모든 역할은 클라이언트를 사용할 수 있다. ## PostgreSQL에서 관리자가 아닌 사용자에게 권한 부여 권한을 관리하기 위해 SQL 백엔드 드라이버는 PostgreSQL의 [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(행 수준 보안) 기능을 활용한다. RLS를 사용하면 모든 사용자가 같은 테이블에서 읽고 쓸 수 있지만, 명시적으로 허용된 행만 조작할 수 있다. 기본적으로 올바른 권한이 명시적으로 부여되지 않은 역할은 `helm list`를 실행할 때 항상 빈 목록을 반환하며, 클러스터의 리소스를 검색하거나 수정할 수 없다. 지정된 역할에 특정 네임스페이스에 대한 액세스 권한을 부여하는 방법을 알아보자: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` 이 명령어는 `namespace = 'default'` 조건을 충족하는 모든 리소스를 읽고 쓸 수 있는 권한을 `role` 역할에 부여한다. 이 정책을 만든 후 `role` 역할을 대신하여 데이터베이스에 연결된 사용자는 `helm list`를 실행할 때 `default` 네임스페이스에 있는 모든 릴리스를 볼 수 있으며, 수정 및 삭제할 수 있다. 권한은 RLS를 사용하여 세분화하여 관리할 수 있으며, 테이블의 다른 열에 대한 접근을 제한할 수도 있다: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Helm 플러그인 가이드 description: Helm의 기능을 확장하기 위해 플러그인을 사용하고 만드는 방법을 소개한다. sidebar_position: 12 --- Helm 플러그인은 `helm` CLI를 통해 접근할 수 있지만, 기본 제공되는 Helm 코드베이스에 포함되지는 않는 도구이다. 기존 플러그인은 [관련](/community/related#helm-plugins) 섹션 또는 [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)을 검색하여 찾을 수 있다. 이 가이드에서는 플러그인을 사용하고 만드는 방법을 설명한다. ## 개요 Helm 플러그인은 Helm과 원활하게 통합되는 애드온 도구이다. 모든 새 기능을 Go로 작성하거나 코어 도구에 추가하지 않고도 Helm의 핵심 기능 세트를 확장하는 방법을 제공한다. Helm 플러그인에는 다음과 같은 특징이 있다. - 코어 Helm 도구에 영향을 주지 않고 Helm 설치에서 추가하거나 제거할 수 있다. - 어떤 프로그래밍 언어로도 작성할 수 있다. - Helm과 통합되며 `helm help` 및 기타 위치에 표시된다. Helm 플러그인은 `$HELM_PLUGINS`에 위치한다. 환경에 설정되지 않은 경우 기본값을 포함하여 현재 값은 `helm env` 명령어로 확인할 수 있다. Helm 플러그인 모델은 부분적으로 Git의 플러그인 모델을 기반으로 한다. 그래서 때때로 `helm`을 _도자기(porcelain)_ 레이어로, 플러그인을 _배관(plumbing)_ 이라고 부르기도 한다. 이것은 Helm이 사용자 경험과 최상위 수준의 처리 로직을 제공하고, 플러그인은 원하는 작업을 수행하는 "세부 작업"을 담당한다는 것을 간략히 표현한 것이다. ## 플러그인 설치하기 플러그인은 `$ helm plugin install ` 명령어를 사용하여 설치한다. 로컬 파일 시스템의 플러그인 경로 또는 원격 VCS 저장소의 URL을 전달할 수 있다. `helm plugin install` 명령어는 지정된 경로/URL에서 플러그인을 `$HELM_PLUGINS`로 복제하거나 복사한다. VCS에서 설치하는 경우 `--version` 인수로 버전을 지정할 수 있다. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` 플러그인 tar 배포판이 있는 경우, 플러그인을 `$HELM_PLUGINS` 디렉터리에 압축 해제하면 된다. `helm plugin install https://domain/path/to/plugin.tar.gz`를 실행하여 URL에서 직접 tarball 플러그인을 설치할 수도 있다. ## 플러그인 파일 구조 여러 면에서 플러그인은 차트와 유사하다. 각 플러그인에는 `plugin.yaml` 파일이 포함된 최상위 디렉터리가 있다. 추가 파일이 있을 수 있지만 `plugin.yaml` 파일만 필수이다. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## plugin.yaml 파일 plugin.yaml 파일은 플러그인에 필수이다. 다음 필드를 포함한다. ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### `name` 필드 `name`은 플러그인의 이름이다. Helm은 이 플러그인을 실행할 때 이 이름을 사용한다(예: `helm NAME`이 이 플러그인을 호출한다). _`name`은 디렉터리 이름과 일치해야 한다._ 위의 예에서 `name: last`인 플러그인은 `last`라는 이름의 디렉터리에 포함되어야 한다. `name`에 대한 제한 사항: - `name`은 기존 `helm` 최상위 명령어와 중복될 수 없다. - `name`은 ASCII 문자 a-z, A-Z, 0-9, `_`, `-`로 제한된다. ### `version` 필드 `version`은 플러그인의 SemVer 2 버전이다. `usage`와 `description`은 모두 명령어의 도움말 텍스트를 생성하는 데 사용된다. ### `ignoreFlags` 필드 `ignoreFlags` 스위치는 Helm에 플래그를 플러그인에 전달하지 _않도록_ 지시한다. 따라서 플러그인이 `helm myplugin --foo`로 호출되고 `ignoreFlags: true`인 경우, `--foo`는 조용히 무시된다. ### `platformCommand` 필드 `platformCommand`는 플러그인이 호출될 때 실행할 명령어를 구성한다. `platformCommand`와 `command`를 동시에 설정하면 오류가 발생한다. 사용할 명령어를 결정할 때 다음 규칙이 적용된다. - `platformCommand`가 있으면 사용된다. - `os`와 `arch`가 모두 현재 플랫폼과 일치하면, 검색을 중지하고 해당 명령어를 사용한다. - `os`가 일치하고 `arch`가 비어 있으면, 해당 명령어를 사용한다. - `os`와 `arch`가 모두 비어 있으면, 해당 명령어를 사용한다. - 일치하는 항목이 없으면, Helm은 오류와 함께 종료된다. - `platformCommand`가 없고 더 이상 사용되지 않는 `command`가 있으면 해당 명령어를 사용한다. - 명령어가 비어 있으면, Helm은 오류와 함께 종료된다. ### `platformHooks` 필드 `platformHooks`는 플러그인이 라이프사이클 이벤트에 대해 실행할 명령어를 구성한다. `platformHooks`와 `hooks`를 동시에 설정하면 오류가 발생한다. 사용할 훅 명령어를 결정할 때 다음 규칙이 적용된다. - `platformHooks`가 있으면 사용되고, 라이프사이클 이벤트에 대한 명령어가 처리된다. - `os`와 `arch`가 모두 현재 플랫폼과 일치하면, 검색을 중지하고 해당 명령어를 사용한다. - `os`가 일치하고 `arch`가 비어 있으면, 해당 명령어를 사용한다. - `os`와 `arch`가 모두 비어 있으면, 해당 명령어를 사용한다. - 일치하는 항목이 없으면, Helm은 해당 이벤트를 건너뛴다. - `platformHooks`가 없고 더 이상 사용되지 않는 `hooks`가 있으면, 라이프사이클 이벤트에 대한 명령어를 사용한다. - 명령어가 비어 있으면, Helm은 해당 이벤트를 건너뛴다. ## 플러그인 빌드하기 다음은 마지막 릴리스 이름을 가져오는 간단한 플러그인의 YAML이다. ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` 플러그인에는 추가 스크립트와 실행 파일이 필요할 수 있다. 스크립트는 플러그인 디렉터리에 포함하고, 실행 파일은 훅을 통해 다운로드할 수 있다. 다음은 예제 플러그인이다. ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` 플러그인이 실행되기 전에 환경 변수가 보간된다. 위의 패턴은 플러그인 프로그램의 위치를 나타내는 권장 방식이다. ### 플러그인 명령어 플러그인 명령어 작업을 위한 몇 가지 전략이 있다. - 플러그인에 실행 파일이 포함된 경우, `platformCommand:` 또는 에 해당하는 실행 파일은 플러그인 디렉터리에 패키징하거나 훅을 통해 설치해야 한다. - `platformCommand:` 또는 `command:` 줄은 실행 전에 환경 변수가 확장된다. `$HELM_PLUGIN_DIR`은 플러그인 디렉터리를 가리킨다. - 명령어 자체는 셸에서 실행되지 않는다. 따라서 셸 스크립트를 한 줄로 작성할 수 없다. - Helm은 많은 설정을 환경 변수에 주입한다. 사용 가능한 정보를 확인하려면 환경을 살펴보자. - Helm은 플러그인 언어에 대해 가정하지 않는다. 원하는 언어로 작성할 수 있다. - 명령어는 `-h`와 `--help`에 대한 특정 도움말 텍스트를 구현해야 한다. Helm은 `helm help`와 `helm help myplugin`에 `usage`와 `description`을 사용하지만, `helm myplugin --help`는 처리하지 않는다. ### 로컬 플러그인 테스트하기 먼저 `HELM_PLUGINS` 경로를 찾아야 한다. 다음 명령어를 실행한다. ``` bash helm env ``` 현재 디렉터리를 `HELM_PLUGINS`가 설정된 디렉터리로 변경한다. 이제 플러그인의 빌드 출력에 대한 심볼릭 링크를 추가할 수 있다. 이 예에서는 `mapkubeapis`에 대해 수행했다. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## 다운로더 플러그인 기본적으로 Helm은 HTTP/S를 사용하여 차트를 가져올 수 있다. Helm 2.4.0부터 플러그인은 임의의 소스에서 차트를 다운로드하는 특수 기능을 가질 수 있다. 플러그인은 `plugin.yaml` 파일(최상위 수준)에서 이 특수 기능을 선언해야 한다. ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` 이러한 플러그인이 설치되면, Helm은 `command`를 호출하여 지정된 프로토콜 스키마를 사용하여 저장소와 상호 작용할 수 있다. 특수 저장소는 일반 저장소와 유사하게 추가된다: `helm repo add favorite myprotocol://example.com/` 특수 저장소에 대한 규칙은 일반 저장소와 동일하다: Helm이 사용 가능한 차트 목록을 검색하고 캐시하려면 `index.yaml` 파일을 다운로드할 수 있어야 한다. 정의된 명령어는 `command certFile keyFile caFile full-URL` 스키마로 호출된다. SSL 자격 증명은 `$HELM_REPOSITORY_CONFIG` (즉, `$HELM_CONFIG_HOME/repositories.yaml`)에 저장된 저장소 정의에서 가져온다. 다운로더 플러그인은 원시 콘텐츠를 stdout에 덤프하고 오류를 stderr에 보고해야 한다. 다운로더 명령어는 하위 명령어나 인수도 지원하므로, 예를 들어 `plugin.yaml`에 `bin/mydownloader subcommand -d`를 지정할 수 있다. 이것은 메인 플러그인 명령어와 다운로더 명령어에 동일한 실행 파일을 사용하되, 각각에 대해 다른 하위 명령어를 사용하려는 경우에 유용하다. ## 환경 변수 Helm은 플러그인을 실행할 때 외부 환경을 플러그인에 전달하고, 추가 환경 변수도 주입한다. `KUBECONFIG`와 같은 변수는 외부 환경에서 설정된 경우 플러그인에 대해 설정된다. 다음 변수는 항상 설정된다. - `HELM_PLUGINS`: 플러그인 디렉터리의 경로. - `HELM_PLUGIN_NAME`: `helm`에 의해 호출된 플러그인의 이름. 따라서 `helm myplug`는 짧은 이름 `myplug`를 갖는다. - `HELM_PLUGIN_DIR`: 플러그인이 포함된 디렉터리. - `HELM_BIN`: (사용자가 실행한) `helm` 명령어의 경로. - `HELM_DEBUG`: Helm에 의해 디버그 플래그가 설정되었는지 나타낸다. - `HELM_REGISTRY_CONFIG`: (사용하는 경우) 레지스트리 설정 위치. 레지스트리와 함께 Helm을 사용하는 것은 실험적 기능임에 유의하자. - `HELM_REPOSITORY_CACHE`: 저장소 캐시 파일의 경로. - `HELM_REPOSITORY_CONFIG`: 저장소 설정 파일의 경로. - `HELM_NAMESPACE`: `helm` 명령어에 지정된 네임스페이스 (일반적으로 `-n` 플래그 사용). - `HELM_KUBECONTEXT`: `helm` 명령어에 제공된 Kubernetes 설정 컨텍스트의 이름. 또한, Kubernetes 설정 파일이 명시적으로 지정된 경우 `KUBECONFIG` 변수로 설정된다. ## 플래그 파싱에 대한 참고 사항 플러그인을 실행할 때, Helm은 자체 사용을 위해 전역 플래그를 파싱한다. 이러한 플래그는 플러그인에 전달되지 않는다. - `--burst-limit`: `$HELM_BURST_LIMIT`로 변환된다. - `--debug`: 지정하면 `$HELM_DEBUG`가 `1`로 설정된다. - `--kube-apiserver`: `$HELM_KUBEAPISERVER`로 변환된다. - `--kube-as-group`: `$HELM_KUBEASGROUPS`로 변환된다. - `--kube-as-user`: `$HELM_KUBEASUSER`로 변환된다. - `--kube-ca-file`: `$HELM_KUBECAFILE`로 변환된다. - `--kube-context`: `$HELM_KUBECONTEXT`로 변환된다. - `--kube-insecure-skip-tls-verify`: `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`로 변환된다. - `--kube-tls-server-name`: `$HELM_KUBETLS_SERVER_NAME`로 변환된다. - `--kube-token`: `$HELM_KUBETOKEN`로 변환된다. - `--kubeconfig`: `$KUBECONFIG`로 변환된다. - `--namespace` 및 `-n`: `$HELM_NAMESPACE`로 변환된다. - `--qps`: `$HELM_QPS`로 변환된다. - `--registry-config`: `$HELM_REGISTRY_CONFIG`로 변환된다. - `--repository-cache`: `$HELM_REPOSITORY_CACHE`로 변환된다. - `--repository-config`: `$HELM_REPOSITORY_CONFIG`로 변환된다. 플러그인은 `-h`와 `--help`에 대해 도움말 텍스트를 표시하고 종료해야 _한다_. 다른 모든 경우에는 플러그인이 적절하게 플래그를 사용할 수 있다. ## 셸 자동 완성 제공 Helm 3.2부터 플러그인은 Helm의 기존 자동 완성 메커니즘의 일부로 셸 자동 완성 지원을 선택적으로 제공할 수 있다. ### 정적 자동 완성 플러그인이 자체 플래그 및/또는 하위 명령어를 제공하는 경우, 플러그인의 루트 디렉터리에 `completion.yaml` 파일을 두어 Helm에 알릴 수 있다. `completion.yaml` 파일의 형식은 다음과 같다. ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` 유의 사항: 1. 모든 섹션은 선택 사항이지만 해당되는 경우 제공해야 한다. 1. 플래그에는 `-` 또는 `--` 접두사를 포함하지 않아야 한다. 1. 짧은 플래그와 긴 플래그 모두 지정할 수 있고 지정해야 한다. 짧은 플래그가 해당하는 긴 형식과 연결될 필요는 없지만, 두 형식 모두 나열해야 한다. 1. 플래그는 어떤 방식으로든 정렬할 필요가 없지만, 파일의 하위 명령어 계층 구조에서 올바른 위치에 나열해야 한다. 1. Helm의 기존 전역 플래그는 이미 Helm의 자동 완성 메커니즘에서 처리되므로, 플러그인은 `--debug`, `--namespace` 또는 `-n`, `--kube-context`, `--kubeconfig` 또는 기타 전역 플래그를 지정할 필요가 없다. 1. `validArgs` 목록은 하위 명령어 다음의 첫 번째 매개변수에 대해 가능한 완성의 정적 목록을 제공한다. 이러한 목록을 미리 제공하는 것이 항상 가능하지는 않다(아래 [동적 완성](#동적-완성) 섹션 참조). 이 경우 `validArgs` 섹션을 생략할 수 있다. `completion.yaml` 파일은 전적으로 선택 사항이다. 제공되지 않으면 Helm은 플러그인에 대한 셸 자동 완성을 제공하지 않는다(플러그인이 [동적 완성](#동적-완성)을 지원하지 않는 한). 또한, `completion.yaml` 파일을 추가하는 것은 이전 버전과 호환되며 이전 Helm 버전을 사용할 때 플러그인 동작에 영향을 주지 않는다. 예를 들어, 하위 명령어는 없지만 `helm status` 명령어와 동일한 플래그를 허용하는 [`fullstatus 플러그인`](https://github.com/marckhouzam/helm-fullstatus)의 경우, `completion.yaml` 파일은 다음과 같다. ```yaml name: fullstatus flags: - o - output - revision ``` 더 복잡한 예로 [`2to3 플러그인`](https://github.com/helm/helm-2to3)의 `completion.yaml` 파일은 다음과 같다. ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### 동적 완성 Helm 3.2부터 플러그인은 자체 동적 셸 자동 완성을 제공할 수 있다. 동적 셸 자동 완성은 미리 정의할 수 없는 매개변수 값 또는 플래그 값의 완성이다. 예를 들어, 현재 클러스터에서 사용 가능한 Helm 릴리스 이름의 완성이 있다. 플러그인이 동적 자동 완성을 지원하려면, 루트 디렉터리에 `plugin.complete`라는 **실행 파일**을 제공해야 한다. Helm 완성 스크립트가 플러그인에 대한 동적 완성을 필요로 할 때, 완성해야 할 명령줄을 전달하여 `plugin.complete` 파일을 실행한다. `plugin.complete` 실행 파일에는 적절한 완성 선택지가 무엇인지 결정하고 Helm 완성 스크립트가 사용할 수 있도록 표준 출력으로 출력하는 로직이 있어야 한다. `plugin.complete` 파일은 전적으로 선택 사항이다. 제공되지 않으면 Helm은 플러그인에 대한 동적 자동 완성을 제공하지 않는다. 또한, `plugin.complete` 파일을 추가하는 것은 이전 버전과 호환되며 이전 Helm 버전을 사용할 때 플러그인 동작에 영향을 주지 않는다. `plugin.complete` 스크립트의 출력은 다음과 같이 줄바꿈으로 구분된 목록이어야 한다. ```console rel1 rel2 rel3 ``` `plugin.complete`가 호출되면, 플러그인의 메인 스크립트가 호출될 때와 마찬가지로 플러그인 환경이 설정된다. 따라서 `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` 및 기타 모든 플러그인 변수가 이미 설정되어 있고, 해당하는 전역 플래그는 제거된다. `plugin.complete` 파일은 어떤 실행 형식이든 될 수 있다. 셸 스크립트, Go 프로그램 또는 Helm이 실행할 수 있는 다른 유형의 프로그램이 될 수 있다. `plugin.complete` 파일은 사용자에 대해 ***반드시*** 실행 권한이 있어야 한다. `plugin.complete` 파일은 ***반드시*** 성공 코드(값 0)와 함께 종료되어야 한다. 경우에 따라 동적 완성은 Kubernetes 클러스터에서 정보를 가져와야 한다. 예를 들어, `helm fullstatus` 플러그인은 입력으로 릴리스 이름이 필요하다. `fullstatus` 플러그인에서 `plugin.complete` 스크립트가 현재 릴리스 이름에 대한 완성을 제공하려면, 단순히 `helm list -q`를 실행하고 결과를 출력하면 된다. 플러그인 실행과 플러그인 완성에 동일한 실행 파일을 사용하려면, `plugin.complete` 스크립트가 특별한 매개변수나 플래그와 함께 메인 플러그인 실행 파일을 호출하도록 만들 수 있다. 메인 플러그인 실행 파일이 특별한 매개변수나 플래그를 감지하면, 완성을 실행해야 함을 알게 된다. 이 예에서 `plugin.complete`는 다음과 같이 구현할 수 있다. ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` `fullstatus` 플러그인의 실제 스크립트(`status.sh`)는 `--complete` 플래그를 찾아야 하며, 발견되면 적절한 완성을 출력해야 한다. ### 팁과 요령 1. 셸은 사용자 입력과 일치하지 않는 완성 선택지를 자동으로 필터링한다. 따라서 플러그인은 사용자 입력과 일치하지 않는 것을 제거하지 않고 관련된 모든 완성을 반환할 수 있다. 예를 들어, 명령줄이 `helm fullstatus ngin`인 경우, `plugin.complete` 스크립트는 `ngin`으로 시작하는 것뿐만 아니라 (`default` 네임스페이스의) *모든* 릴리스 이름을 출력할 수 있다. 셸이 `ngin`으로 시작하는 것만 유지한다. 1. 특히 복잡한 플러그인이 있는 경우, 동적 완성 지원을 단순화하기 위해 `plugin.complete` 스크립트가 메인 플러그인 스크립트를 호출하고 완성 선택지를 요청하도록 할 수 있다. 예제는 위의 [동적 완성](#동적-완성) 섹션을 참조하자. 1. 동적 완성과 `plugin.complete` 파일을 디버깅하려면, 다음을 실행하여 완성 결과를 확인할 수 있다. - `helm __complete `. 예를 들어: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: 헬름 출처 및 무결성 description: 차트의 무결성과 출처를 검증하는 방법을 설명한다. sidebar_position: 5 --- 헬름에는 차트 사용자가 패키지의 무결성과 출처를 검증하는 데 도움이 되는 출처 도구가 있다. 헬름은 PKI, GnuPG 및 평판이 좋은 패키지 관리자에 기반한 업계 표준 도구를 사용하여 서명 파일을 생성하고 검증할 수 있다. ## 개요 무결성은 차트를 출처기록과 비교하여 설정된다. 출처 레코드는 패키지된 차트와 함께 저장되는 _출처 파일_에 저장된다. 예를 들어 차트 이름이 `myapp-1.2.3.tgz` 인 경우 출처 파일은 `myapp-1.2.3.tgz.prov` 이 된다. 출처 파일은 패키징 시 (`helm package --sign ...`) 에 생성되며, 여러 가지 명령어로 확인할 수 있는데 흔히 `helm install --verify` 를 사용한다. ## 작업흐름 이 섹션에서는 출처 데이터를 효과적으로 사용하기 위한 작업흐름 예시를 설명한다. 전제 조건: - (ASCII-armored가 아닌) 바이너리 형식의 유효한 PGP 키페어 - `helm` 명령줄 도구 - GnuPG 명령줄 도구 (선택사항) - 키베이스(Keybase) 명령줄 도구 (선택사항) **참고:** PGP 개인 키에 암호가 있을 경우 `--sign` 옵션을 지원하는 명령어에 대해 해당 암호를 입력하라는 메시지가 표시된다. 새 차트를 만드는 방법은 이전과 동일하다. ```console $ helm create mychart Creating mychart ``` 패키징할 준비가 되면 `--sign` 플래그를 `helm package` 에 추가해야 한다. 또한 서명 키가 알려진 이름과 해당 개인 키를 포함하는 키링을 지정해야 한다. ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **참고:** `--key` 인수의 값은 이름 또는 이메일과 같이 원하는 키의 `uid` (`gpg --list-keys` 출력에 존재)의 하위 문자여야 한다. **지문(fingerprint)은 사용할 수 _없다_** **팁:** GnuPG 사용자의 경우 비밀 키링은 `~/.gnupg/secring.gpg` 에 존재한다. `gpg --list-secret-keys` 를 사용하여 보유한 키를 나열할 수 있다. **경고:** GnuPG v2는 기본 위치 `~/.gnupg/pubring.kbx` 에 새로운 형식 `kbx` 를 사용하여 비밀 키링을 저장한다. 다음 명령어를 사용하여 키링을 레거시 gpg 형식으로 변환한다. ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` 이 시점에서, `mychart-0.1.0.tgz` 와 `mychart-0.1.0.tgz.prov` 가 모두 표시되어야 한다. 결국 두 파일 모두 원하는 차트 저장소에 업로드되어야 한다. `helm verify` 를 사용하여 차트를 검증할 수 있다. ```console $ helm verify mychart-0.1.0.tgz ``` 검증에 실패한 경우 다음과 같다. ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` 설치 중에 검증하려면 `--verify` 플래그를 사용한다. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` 서명된 차트와 연결된 공개키와 포함된 키링이 기본 위치에 없으면 `helm package` 예제에서와 같이 사용자가 `--keyring PATH`로 키링의 위치를 지정해야 할 수 있다. 검증에 실패하면 차트가 렌더링되기 전에 설치가 중단된다. ### Keybase.io 자격증명 사용하기 [Keybase.io](https://keybase.io) 서비스를 사용하면 암호화 ID에 대한 신뢰 체인을 쉽게 설정할 수 있다. keybase 자격 증명은 차트에 서명하는데 사용될 수 있다. 전제 조건: - 구성된 Keybase.io 계정 - 로컬에 설치된 GnuPG - 로컬에 설치된 `keybase` CLI #### 패키지 서명하기 첫 번째 단계는 keybase 키를 로컬 GnuPG 키링으로 가져오는 것이다. ```console $ keybase pgp export -s | gpg --import ``` 이렇게 하면 Kyebase 키가 OpenPGP 형식으로 변환된 다음 `~/.gnupg/secring.gpg` 파일로 로컬에 저장한다. `gpg --list-secret-keys` 를 실행하여 다시 확인할 수 있다. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` 비밀 키에는 식별자 문자열이 있다. ``` technosophos (keybase.io/technosophos) ``` 이것이 키의 전체 이름이다. 다음으로 `helm package` 로 차트를 패키징하고 서명할 수 있다. 최소한 `--key` 에서 해당 이름 문자열의 일부는 사용해야 한다. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` 결과적으로, `package` 명령어는 `.tgz` 파일과 `.tgz.prov` 파일 모두를 생성해야 한다. #### 패키지 검증하기 유사한 기술을 사용하여 다른 사람의 keybase 키로 서명된 차트를 검증할 수 있다. `keybase.io/technosophos` 로 서명된 패키지를 검증하려는 경우를 생각해보자. 그런 경우 `keybase` 도구를 사용해야 한다. ```console $ keybase follow technosophos $ keybase pgp pull ``` 위의 첫 번째 명령어는 `technosophos` 사용자를 추적한다. 다음으로 `keybase pgp pull` 은 팔로우하는 모든 계정의 OpenPGP 키를 다운로드하여 GnuPG 키링(`~/.gnupg/pubring.gpg`)에 배치한다. 이 시점에서 이제 `helm verify` 또는 `--verify` 플래그가 있는 명령어를 사용할 수 있다. ```console $ helm verify somechart-1.2.3.tgz ``` ### 차트가 검증되지 않는 이유 실패하는 이유는 주로 다음과 같다. - `.prov` 파일이 없거나 손상된 경우다. 이것은 무언가가 잘못 구성되었거나 기존 관리자가 출처 파일을 만들지 않은 경우이다. - 파일 서명에 사용된 키가 키링에 없는 경우이다. 이는 차트에 서명한 엔티티가 사용자가 신뢰한다고 신호를 보낸 사람이 아님을 의미한다. - `.prov` 파일 검증에 실패한 경우다. 이는 차트 또는 출처 데이터에 문제가 있음을 나타낸다. - 출처 파일의 파일 해시가 아카이브 파일의 해시와 일치하지 않는 경우이다. 이는 아카이브가 변조되었음을 나타낸다. 검증이 실패한다면 그 패키지를 신뢰할 수 없는 이유가 된다. ## 출처 파일 출처 파일에는 차트의 YAML 파일과 몇 가지 검증 정보가 포함되어 있다. 출처 파일은 자동으로 생성되도록 설계되어 있다. 다음과 같은 출처 데이터가 추가된다. * 차트 파일(`Chart.yaml`) 이 포함되어 있어 사람과 도구 모두 차트 내용을 쉽게 볼 수 있다. * 차트 패키지(`.tgz` 파일)의 서명(도커와 마찬가지로 SHA256)이 포함되어 있으며 차트 패키지의 무결성을 검증하는 데 사용할 수 있다. * 전체 본문은 OpenPGP 에서 사용하는 알고리즘을 사용하여 서명된다(암호화 서명 및 검증을 쉽게 하는 새로운 방법은 [Keybase.io](https://keybase.io) 참고하자). 이러한 조합은 사용자에게 다음과 같은 보증을 제공한다. * 패키지 자체가 변경되지 않았다. (체크섬 패키지 `.tgz`) * 이 패키지를 출시한 엔티티가 (GnuPG/PGP 서명을 통해) 알려져 있다. 파일 형식은 다음과 같다. ``` Hash: SHA512 apiVersion: v2 appVersion: 1.16.0 description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` YAML 섹션에는 (`...\n` 로 구분되는) 두 개의 문서가 포함되어 있다. 첫 번째 파일은 `Chart.yaml` 의 내용이다. 두 번째는 패키징 시 해당 파일 콘텐츠의 SHA-256 다이제스트에 대한 파일 이름 맵인 체크섬 파일이다. 서명 블록은 [변조 방지](https://www.rossde.com/PGP/pgp_signatures.html)를 제공하는 표준 PGP 서명이다. ## 차트 저장소 차트 저장소는 헬름 차트의 중앙 집중식 콜렉션 역할을 한다. 차트 저장소는 특정 요청을 통해 HTTP를 통해 출처 파일을 제공할 수 있도록 해야 하며 차트와 동일하게 URI 경로에서 사용할 수 있도록 해야 한다. 예를 들어 패키지의 기본 URL이 `https://example.com/charts/mychart-1.2.3.tgz` 일 때 출처 파일이 있는 경우에는, `https://example.com/charts/mychart-1.2.3.tgz.prov` 에서 접근할 수 있어야 한다. 최종 사용자의 관점에서 `helm install --verify myrepo/mychart-1.2.3` 은 추가 사용자 구성이나 작업없이 차트와 출처 파일을 모두 다운로드해야 한다. ### OCI 기반 레지스트리에서의 서명 차트를 [OCI 기반 레지스트리](./registries.md)에 게시할 때, [`helm-sigstore` 플러그인](https://github.com/sigstore/helm-sigstore/)을 사용하여 [sigstore](https://sigstore.dev/)에 출처를 게시할 수 있다. [문서에 설명된 바와 같이](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), 출처를 생성하고 GPG 키로 서명하는 과정은 동일하지만, `helm sigstore upload` 명령어를 사용하여 출처를 불변의 투명성 로그에 게시할 수 있다. ## 권한 및 인증 확립하기 신뢰 체인 시스템을 다룰 때는 서명자의 권한을 수립할 수 있게 하는 것이 중요하다. 쉽게 말하면, 이 체계는 차트에 서명한 사람을 신뢰할 수 있는지에 달려 있다. 바꿔 말하면, 서명자의 공개키를 신뢰할 필요가 있다는 것을 의미한다. 헬름의 디자인 철학 중 하나는, 헬름 프로젝트가 신뢰 체인에 필요한 당사자로 자기 자신을 포함시키지 않는다는 것이다. 우리는 모든 차트 서명자의 "인증기관"이 되고 싶지 않다. 대신 우리는 탈중앙화 모델을 선호하며, OpenPGP를 기반 기술로 선택한 이유 중 하나이다. 따라서 권한 수립에 관한 진행단계는 헬름 2(헬름 3로 넘김)에서 정의되지 않은 채로 남아 있다 . 하지만, 출처 시스템 사용에 관심이 있는 분들을 위한 몇 가지 조언과 권장 사항은 있다. - [Keybase](https://keybase.io) 플랫폼은 신뢰 정보를 위한 공개 중앙 저장소를 제공한다. - Keybase를 사용하여 키를 저장하거나 다른 사람의 공개 키를 가져올 수 있다. - Keybase 에는 사용 가능한 훌륭한 문서도 존재한다. - 테스트되진 않았지만, Keybase 의 "보안 웹사이트" 기능을 사용하여 헬름 차트를 제공할 수도 있다. - 기본 아이디어는 공식 "차트 리뷰어"가 자신의 키로 차트에 서명하고 생성된 출처 파일을 차트 저장소에 업로드하는 것이다. - 저장소의 `index.yaml` 파일에 유효한 서명 키 목록이 포함될 수 있다는 아이디어에 대한 몇 가지 작업이 있었다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: 역할 기반 접근 제어 description: 헬름이 쿠버네티스의 역할 기반 접근 제어와 상호 작용하는 방법을 설명한다. sidebar_position: 11 --- 쿠버네티스에서 사용자 또는 애플리케이션별 서비스 계정에 역할을 부여하는 것은 애플리케이션이 지정한 권한범위 내에서 작동하도록 하는 모범 사례이다. [공식 쿠버네티스 문서에서](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions) 서비스 계정 권한에 대해 자세히 알아보도록 하자. 쿠버네티스 1.6 부터는 역할 기반 접근 제어(RBAC)가 기본적으로 활성화된다. RBAC을 사용하면 조직에서 사용자와 역할에 따라 허용되는 작업유형을 지정할 수 있다. RBAC을 사용하여, 사용자는 다음을 수행할 수 있다. - 관리자에게 특별 작업권한(새 역할과 같은 클러스터 전체 리소스 생성)을 부여한다. - 리소스(파드, 퍼시스턴트 볼륨, 디플로이먼트)를 생성하는 사용자의 권한을 특정 네임스페이스 또는 클러스터 전체 범위(리소스 할당량, 역할, 사용자 지정 리소스 정의)로 제한한다. - 특정 네임스페이스 또는 클러스터 전체 범위에서 리소스를 볼 수 있는 사용자의 권한을 제한한다. 이 가이드는 사용자와 쿠버네티스 API 의 상호작용 범위를 제한하려는 관리자를 위한 것이다. ## 사용자 계정 관리 모든 쿠버네티스 클러스터에는 2가지 사용자 카테고리가 있다: 일반 사용자와 쿠버네티스가 관리하는 서비스 계정 일반 사용자는 외부의 독립적인 서비스에 의해 관리되는 것으로 간주한다. 관리자가 개인키를 발급해주면, 사용자는 키스톤이나 구글 어카운트(Google Accounts)에 보관하거나 그냥 사용자 이름 및 비밀번호 목록을 파일에 보관할 수도 있다. 이와 관련하여 쿠버네티스에는 일반 사용자 계정을 나타내는 객체가 없다. 일반 사용자는 API 호출을 통해 클러스터에 추가될 수 없다. 반대로 서비스 계정은 쿠버네티스 API로 관리되는 사용자이다. 특정 네임스페이스에 바인딩 되며 API 서버에 의해 자동으로 생성되거나 API 호출을 통해 수동으로 생성된다. 서비스 계정은 시크릿으로 저장된 자격증명 집합에 연결되어 있으며, 파드에 마운트되어 클러스터 내 프로세스가 쿠버네티스 API와 통신할 수 있도록 한다. API 요청은 일반 사용자 또는 서비스 계정에 연결되거나 익명의 요청으로 처리된다. 즉, 워크스테이션에서 `kubectl` 을 입력하는 실제 사용자, 노드의 kubelet, 컨트롤 플레인의 구성원에 이르기까지 클러스터 내부 또는 외부의 모든 프로세스는 API 서버에 요청할 때 인증을 받거나 익명의 사용자로 취급되어야 한다는 것을 의미한다. ## 롤, 클러스터롤, 롤바인딩, 클러스터롤바인딩 쿠버네티스에서 사용자 계정 및 서비스 계정은 접근 권한이 부여된 리소스만을 보고 편집할 수 있다. 이 접근은 롤 및 롤바인딩을 통해 부여된다. 롤 및 롤바인딩은 특정 네임스페이스에 바인딩되어 롤이 사용자에게 접근을 제공하는 동안 네임스페이스 내의 리소스를 보거나 편집할 수 있는 권한이 부여된다. 클러스터 범위에서는 이를 클러스터롤 및 클러스터롤바인딩이라고 한다. 사용자에게 클러스터롤을 부여하면 전체 클러스터에서 리소스를 보거나 편집할 수 있는 접근 권한이 부여된다. 또한 클러스터 범위(네임스페이스, 리소스 할당량, 노드)에서 리소스를 보거나 편집할 수 있다. 클러스터롤은 롤바인딩의 참조를 통해 특정 네임스페이스에 바인딩 될 수 있다. `admin`, `edit` 및 `view` 기본 클러스터롤은 일반적으로 이러한 방식으로 사용된다. 쿠버네티스에서 기본적으로 사용할 수 있는 몇가지 클러스터롤들이 있다. 이는 사용자와 직접 연계하기 위해서이다. 여기에는 super-user 롤 (`cluster-admin`)과 더 세분화된 접근 권한(`admin`, `edit`, `view`)이 포함된다. | 기본 클러스터롤 | 기본 클러스터롤바인딩 | 설명 |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` group | super-user를 허용하여 모든 리소스에서 작업을 수행할 수 있다. 클러스터롤바인딩에서 사용하면 클러스터 및 모든 네임스페이스의 모든 리소스를 완전히 제어할 수 있다. 롤바인딩에서 사용하면 네임스페이스 자체를 포함하여 롤바인딩의 네임스페이스에 있는 모든 리소스에 대한 모든 권한을 제공한다. | `admin` | None | 롤바인딩을 사용하여 네임스페이스 내에서 부여되도록 의도된 관리자 접근을 허용한다. 롤바인딩에서 사용되는 경우 네임스페이스 내에서 롤 및 롤바인딩을 만드는 기능을 포함하여 네임스페이스의 대부분의 리소스에 대한 읽기/쓰기 접근을 허용한다. 리소스 할당량 또는 네임스페이스 자체에 대한 쓰기 접근은 허용하지 않는다. | `edit` | None | 네임스페이스에 있는 대부분의 오브젝트에 대한 읽기/쓰기 접근을 허용한다. 롤 및 롤바인딩을 보거나 수정할수는 없다. | `view` | None | 읽기 전용 접근을 허용하여 네임스페이스에 있는 대부분의 오브젝트를 볼 수 있다. 롤 및 롤바인딩을 보는 것은 허용되지 않는다. 마찬가지로 시크릿을 보는 것은 허용되지 않는다. ## RBAC을 사용하여 사용자 계정의 접근 제한하기 이제 역할 기반 접근의 기본 사항을 이해했으므로, 관리자가 사용자의 접근 범위를 제한하는 방법에 대해 알아보자. ### 예: 사용자에게 특정 네임스페이스에 대한 읽기/쓰기 접근 권한 부여하기 특정 네임스페이스에 대한 사용자의 접근을 제한하려면 `edit` 또는 `admin` 롤을 사용할 수 있다. 차트가 롤 및 롤바인딩을 생성하거나 상호작용하는 경우 `admin` 클러스터롤을 사용하는 것이 좋다. 또한 `cluster-admin` 접근 권한으로 롤바인딩을 만들 수도 있다. 네임스페이스 범위에서 사용자에게 `cluster-admin` 접근 권한을 부여하면 네임스페이스 자체를 포함하여 네임스페이스의 모든 리소스를 완전히 제어할 수 있다. 이 예시에서는 `edit` 역할을 가진 사용자를 생성한다. 먼저 네임스페이스를 만든다. ```console $ kubectl create namespace foo ``` 이제 해당 네임스페이스에 롤바인딩을 만들어서 사용자에게 `edit` 롤을 부여한다. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### 예: 사용자에게 클러스터 범위에서 읽기/쓰기 접근 권한 부여하기 사용자가 클러스터 범위 리소스 (네임스페이스, 롤, 사용자 지정 리소스 정의 등)를 설치하는 차트를 설치하려는 경우, 클러스터 범위의 쓰기 접근이 필요하다. 이를 위해 사용자에게 `admin` 또는 `cluster-admin` 접근 권한을 부여한다. 사용자에게 `cluster-admin` 접근 권한을 부여하면 `kubectl drain` 을 사용한 노드 접근 및 기타 관리 작업을 포함하여 쿠버네티스에서 사용할 수 있는 모든 리소스에 대한 접근 권한이 부여된다. 이 방식보다는 사용자에 `admin` 접근을 제공하거나 필요에 맞는 사용자 지정 클러스터롤을 생성하는 것을 권장한다. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### 예: 사용자에게 특정 네임스페이스에 대한 읽기 전용 접근 권한 부여하기 시크릿을 볼 수 있는 클러스터롤이 없다는 것을 알아챘을지도 모르겠다. `view` 클러스터롤은 에스컬레이션 문제로 인해 사용자에게 시크릿에 대한 읽기 접근 권한을 부여하지 않는다. 헬름은 기본적으로 릴리스 메타 데이터를 시크릿으로 저장한다. 사용자가 `helm list` 를 실행하려면 이러한 시크릿을 읽을 수 있어야 한다. 이를 위해 특별한 `secret-reader` 클러스터롤을 생성한다. `cluster-role-secret-reader.yaml` 파일을 만들고 아래의 내용을 파일에 작성한다. ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` 그러고 나서, 다음을 사용하여 클러스터롤을 만든다. ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` 완료되면 사용자에게 대부분의 리소스에 대한 접근 권한을 부여한 다음 시크릿에 대한 읽기 접근 권한을 부여할 수 있다. ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### 예: 클러스터 범위에서 사용자에게 읽기전용 접근 권한 부여하기 특정 시나리오에서는 사용자에게 클러스터 범위 접근 권한을 부여하는 것이 유용할 수 있다. 예를 들어 사용자가 `helm list --all-namespaces` 명령을 실행하려는 경우 API는 사용자에게 클러스터 범위 읽기 접근 권한이 있어야 한다. 그렇게 하려면 위에서 설명한대로 사용자에게 `view` 및 `secret-reader` 접근 권한을 부여하되, 클러스터롤바인딩을 사용한다. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## 추가적인 고려사항 위에 표시된 예는 쿠버네티스와 함께 제공되는 기본 클러스터롤을 활용한다. 사용자에게 접근 권한이 부여된 리소스를 더 세밀하게 제어하려면 고유한 사용자 지정 역할 및 클러스터롤 생성에 대한 [쿠버네티스 문서](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)를 참조하자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: OCI 기반 레지스트리 사용 description: 차트 배포를 위한 OCI 사용법을 설명한다. sidebar_position: 7 --- Helm 3부터 [OCI](https://www.opencontainers.org/) 지원이 가능한 컨테이너 레지스트리를 사용하여 차트 패키지를 저장하고 공유할 수 있다. Helm v3.8.0부터 OCI 지원이 기본적으로 활성화되어 있다. ## v3.8.0 이전의 OCI 지원 OCI 지원은 Helm v3.8.0에서 실험적 기능에서 정식(GA) 기능으로 전환되었다. 이전 버전의 Helm에서는 OCI 지원이 다르게 동작했다. Helm v3.8.0 이전에 OCI 지원을 사용했다면, 버전별로 변경된 사항을 이해하는 것이 중요하다. ### v3.8.0 이전 OCI 지원 활성화 Helm v3.8.0 이전에는 OCI 지원이 *실험적* 기능이었으며 수동으로 활성화해야 했다. Helm v3.8.0 이전 버전에서 OCI 실험적 지원을 활성화하려면 환경에서 `HELM_EXPERIMENTAL_OCI`를 설정한다. 예시: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### v3.8.0의 OCI 기능 지원 중단 및 동작 변경 [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) 릴리스에서는 이전 버전과 다음 기능 및 동작이 다르다: - 차트의 dependencies에서 OCI로 설정할 때 버전을 다른 dependencies처럼 범위로 지정할 수 있다. - 빌드 정보가 포함된 SemVer 태그를 푸시하고 사용할 수 있다. OCI 레지스트리는 태그 문자로 `+`를 지원하지 않는다. Helm은 태그로 저장할 때 `+`를 `_`로 변환한다. - `helm registry login` 명령이 이제 자격 증명 저장에 Docker CLI와 동일한 구조를 따른다. 레지스트리 설정에 동일한 위치를 Helm과 Docker CLI 모두에 전달할 수 있다. ### v3.7.0의 OCI 기능 지원 중단 및 동작 변경 [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) 릴리스에는 OCI 지원을 위한 [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) 구현이 포함되었다. 그 결과, 이전 버전과 다음 기능 및 동작이 다르다: - `helm chart` 하위 명령이 제거되었다. - 차트 캐시가 제거되었다 (`helm chart list` 등이 없음). - OCI 레지스트리 참조에는 이제 항상 `oci://` 접두사가 붙는다. - 레지스트리 참조의 기본 이름(basename)은 *항상* 차트의 이름과 일치해야 한다. - 레지스트리 참조의 태그는 *항상* 차트의 시맨틱 버전과 일치해야 한다 (즉, `latest` 태그 사용 불가). - 차트 레이어 미디어 타입이 `application/tar+gzip`에서 `application/vnd.cncf.helm.chart.content.v1.tar+gzip`으로 변경되었다. ## OCI 기반 레지스트리 사용 ### OCI 기반 레지스트리의 Helm 리포지토리 [Helm 리포지토리](/topics/chart_repository.md)는 패키지된 Helm 차트를 저장하고 배포하는 장소다. OCI 기반 레지스트리는 0개 이상의 Helm 리포지토리를 포함할 수 있으며, 각 리포지토리는 0개 이상의 패키지된 Helm 차트를 포함할 수 있다. ### 호스팅 레지스트리 사용 Helm 차트에 사용할 수 있는 OCI 지원 호스팅 컨테이너 레지스트리가 여러 개 있다. 예시: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) 호스팅 컨테이너 레지스트리 제공자의 문서를 따라 OCI 지원이 가능한 레지스트리를 생성하고 구성한다. **참고:** 개발 컴퓨터에서 OCI 기반 레지스트리인 [Docker Registry](https://docs.docker.com/registry/deploying/)나 [`zot`](https://github.com/project-zot/zot)를 실행할 수 있다. 개발 컴퓨터에서 OCI 기반 레지스트리를 실행하는 것은 테스트 목적으로만 사용해야 한다. ### sigstore를 사용한 OCI 기반 차트 서명 [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) 플러그인을 사용하면 컨테이너 이미지 서명에 사용하는 것과 동일한 도구로 [Sigstore](https://sigstore.dev/)를 사용하여 Helm 차트에 서명할 수 있다. 이는 기존 [차트 리포지토리](/topics/chart_repository.md)에서 지원하는 [GPG 기반 출처 확인](/topics/provenance.md)의 대안을 제공한다. `helm sigstore` 플러그인 사용에 대한 자세한 내용은 [해당 프로젝트 문서](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)를 참조한다. ## 레지스트리 작업 명령어 ### `registry` 하위 명령 #### `login` 레지스트리에 로그인 (암호 수동 입력) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` 레지스트리에서 로그아웃 ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### `push` 하위 명령 차트를 OCI 기반 레지스트리에 업로드: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` `push` 하위 명령은 `helm package`를 사용하여 미리 생성된 `.tgz` 파일에 대해서만 사용할 수 있다. `helm push`를 사용하여 OCI 레지스트리에 차트를 업로드할 때, 참조에는 반드시 `oci://` 접두사가 붙어야 하며 기본 이름(basename)이나 태그를 포함해서는 안 된다. 레지스트리 참조의 기본 이름(basename)은 차트 이름에서 추론되고, 태그는 차트의 시맨틱 버전에서 추론된다. 이는 현재 엄격하게 요구되는 사항이다. 일부 레지스트리에서는 리포지토리 및/또는 네임스페이스(지정된 경우)를 미리 생성해야 한다. 그렇지 않으면 `helm push` 작업 중 오류가 발생한다. [출처 파일](/topics/provenance.md) (`.prov`)을 생성했고, 이 파일이 차트 `.tgz` 파일 옆에 있으면 `push` 시 자동으로 레지스트리에 업로드된다. 이 경우 [Helm 차트 매니페스트](#helm-차트-매니페스트)에 추가 레이어가 생성된다. [helm-push 플러그인](https://github.com/chartmuseum/helm-push) (차트를 [ChartMuseum](/topics/chart_repository.md#chartmuseum-리포지토리-서버)에 업로드하기 위한) 사용자는 이 플러그인이 새로운 내장 `push`와 충돌하기 때문에 문제가 발생할 수 있다. v0.10.0 버전부터 플러그인은 `cm-push`로 이름이 변경되었다. ### 기타 하위 명령 `oci://` 프로토콜 지원은 다양한 다른 하위 명령에서도 사용할 수 있다. 전체 목록은 다음과 같다: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` 차트 다운로드가 관련된 모든 유형의 작업에는 레지스트리 참조의 기본 이름(차트 이름)이 포함된다 (`helm push`에서는 생략됨). 다음은 위에 나열된 하위 명령을 OCI 기반 차트에 사용하는 몇 가지 예시다: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## 다이제스트를 사용한 차트 설치 다이제스트를 사용하여 차트를 설치하는 것은 태그보다 더 안전하다. 다이제스트는 불변이기 때문이다. 다이제스트는 차트 URI에 지정한다: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## dependencies 지정 `dependency update` 하위 명령을 사용하여 레지스트리에서 차트의 dependencies를 가져올 수 있다. `Chart.yaml`의 특정 항목에 대한 `repository`는 기본 이름 없이 레지스트리 참조로 지정한다: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` `dependency update`가 실행되면 `oci://localhost:5000/myrepo/mychart:2.7.0`을 가져온다. ## Helm 차트 매니페스트 레지스트리에 표시되는 Helm 차트 매니페스트 예시 (`mediaType` 필드 참고): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` 다음 예시에는 [출처 파일](/topics/provenance.md)이 포함되어 있다 (추가 레이어 참고): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## 차트 리포지토리에서 마이그레이션 기존 [차트 리포지토리](/topics/chart_repository.md) (index.yaml 기반 리포지토리)에서 마이그레이션하는 작업은 `helm pull`을 사용한 다음 `helm push`를 사용하여 생성된 `.tgz` 파일을 레지스트리에 업로드하면 된다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: 헬름 v2를 v3로 마이그레이션 description: 헬름 v2를 v3로 마이그레이션하는 방법을 배운다. sidebar_position: 13 --- 이 가이드에서는 헬름 v2를 v3로 마이그레이션하는 방법을 보여준다. 헬름 v2가 설치되어 있어야 하며, 하나 이상의 클러스터에서 릴리스가 관리되어야 한다. ## 헬름 3 변경사항 개요 헬름 2 에서 3로의 변경사항 전체 목록은 [FAQ](/faq/changes_since_helm2.md) 에 작성되어 있다. 다음은 마이그레이션 준비 및 작업간에 사용자가 알아야 할 몇 가지 변경 사항에 대한 요약이다: 1. Tiller 제거: - 클라이언트/서버 구조는 클라이언트/라이브러리 아키텍처로 대체됨 (`helm` 바이너리만 해당) - 보안 서비스는 이제 사용자 단위로 제공됨 (쿠버네티스 사용자 클러스터 보안에 위임) - 릴리스는 이제 클러스터 내의 시크릿으로 저장되고 릴리스 객체 메타 데이터도 변경됨 - 릴리스는 더 이상 Tiller 네임스페이스가 아니라 릴리스 네임스페이스 기반으로 유지됨 2. 차트 저장소 업데이트: - `helm search` 는 이제 로컬 저장소 검색과 Artifact Hub에 대한 검색 쿼리를 모두 지원함 3. 다음의 사양 변경에 대하여 차트 apiVersion 이 "v2"로 증가: - 동적으로 연결된 차트 의존성이 `Chart.yaml` 로 이동됨 (`requirements.yaml` 제거되고, 요구사항(requirements) --> 의존성(dependencies)으로 변경) - 라이브러리 차트(헬퍼/공통 차트)를 동적으로 연결된 차트 의존성으로 추가 가능 - 차트를 `application` 또는 `library` 차트로 정의하는 `type` 메타 데이터 필드를 가짐. 기본값은 application이며 렌더링 및 설치 가능하다는 의미 - 헬름 2 차트 (apiVersion=v1) 도 여전히 설치 가능함 4. XDG 디렉토리 사양 추가: - 헬름 홈이 제거되고 구성 파일 저장을 위한 XDG 디렉토리 사양으로 대체 - 헬름 초기화 불필요 - `helm init` 와 `helm home` 명령어 제거 5. 추가 변경 사항: - Helm 설치/설정 단순화: - 헬름 클라이언트 (헬름 바이너리) 만 있으면 됨 (Tiller 불필요) - Run-as-is 패러다임 - `local` 또는 `stable` 저장소는 기본적으로 미설정 - `crd-install` 훅은 제거되고, 차트 내 모든 CRD가 정의되어 있고 차트 렌더링 전에 설치되는 `crds` 디렉토리로 대체됨 - `test-failure` 훅 어노테이션 값은 제거되고, `test-success`는 사용 중단(deprecated). 대신 `test` 를 사용하자 - 제거/교체/추가 된 명령어: - delete --> uninstall : 기본적으로 모든 릴리스 기록 제거 (예전에는 `--purge` 옵션이 필요했음) - fetch --> pull - home (제거됨) - init (제거됨) - install: 릴리스 이름 또는 `--generate-name` 인수 필요 - inspect --> show - reset (제거됨) - serve (제거됨) - template: `-x`/`--execute` 인수의 이름이 `-s`/`--show-only` 로 변경 - upgrade: 릴리스당 저장되는 최대 리비젼 수를 제한하는 인수 `--history-max` 추가됨 (0은 무제한) - 헬름 3 Go 라이브러리는 많은 변경을 거쳤으며, 헬름 2 라이브러리와는 호환되지 않음 - 릴리스 바이너리가 이제 `get.helm.sh` 에서 호스팅됨 ## 마이그레이션 사용 사례 마이그레이션 사용 사례는 다음과 같다: 1. 동일 클러스터를 관리하는 헬름 v2 및 v3: - 이 사용 사례는 헬름 v2 를 단계적으로 제거하려는 경우에만 권장되며 v2로 배포한 릴리스를 관리하는 데 v3가 필요한 것은 아니다. 배포되는 모든 새 릴리스는 v3 에서 수행해야 하며, 기존에 v2 로 배포된 릴리스는 v2 에서만 업데이트/제거된다. - 헬름 v2 와 v3 는 같은 클러스터를 원활하게 관리할 수 있다. 헬름 버전들은 동일 또는 개별 시스템에 설치될 수 있다. - 만약 동일한 시스템에 헬름 v3를 설치하는 경우, 헬름 v2 클라이언트를 제거할 준비가 될 때까지 두 클라이언트 버전이 공존할 수 있도록 추가 작업을 수행해야 한다. 충돌을 피하기 위해 헬름 v3 바이너리의 이름을 바꾸거나 다른 폴더에 넣도록 한다. - 그밖에는 다음과 같은 구별에 따라 두 버전 간에 충돌이 발생하지 않는다. - v2 및 v3 릴리스 (이력) 저장소는 서로 독립적이다. 변경 사항으로는 스토리지용 쿠버네티스 리소스와, 리소스에 포함된 릴리스 객체 메타 데이터가 있다. 릴리스는 또한 Tiller 네임스페이스를 사용하는 대신 사용자별 네임스페이스에 있게 된다 (예: v2의 기본 Tiller 네임스페이스는 kube-system). v2는 Tiller 네임스페이스 및 `TILLER` 소유권 아래의 "ConfigMaps" 또는 "Secrets" 를 사용한다. v3는 사용자 네임스페이스에 있는 "Secrets" 과 `helm` 소유권을 사용한다. 릴리스는 v2 및 v3에서 모두 증가한다. - 유일한 문제는 쿠버네티스 클러스터 범위의 리소스(예: `clusterroles.rbac`)가 차트에 정의된 경우이다. 이런 경우 리소스가 충돌할 수 있으므로 네임스페이스에서 고유하더라도 v3 배포는 실패하게 된다. - v3 구성은 더이상 `$HELM_HOME` 을 사용하지 않고 대신 XDG 디렉토리 사양을 사용한다. 또한 필요에 따라 즉시 생성된다. 따라서 v2 구성과는 독립적이다. 이것은 동일한 시스템에 두 버전이 설치된 경우에만 적용된다. 2. 헬름 v2 에서 헬름 v3 로 마이그레이션: - 이 사용 사례는 헬름 v3 에서 기존 헬름 v2 릴리스를 관리하려는 경우에 적용된다. - 헬름 v2 클라이언트에 대해서는 다음과 같은 부분에 유의해야 한다: - 헬름 v2 클라이언트 1개에서 다수의 쿠버네티스 클러스터 관리 가능 - 클러스터에 대해 헬름 v2 클라이언트 1 개가 여러 개의 Tiller 인스턴스에 연결 가능 - 이는 릴리스가 Tiller 및 해당 네임스페이스에 의해 클러스터에 배치되므로 마이그레이션 할 때 이를 알고 있어야 한다는 것을 의미한다. 따라서 헬름 v2 클라이언트 인스턴스에서 관리하는 각 클러스터 및 각 Tiller 인스턴스에 대한 마이그레이션을 알고 있어야 한다. - 권장되는 데이터 마이그레이션 절차는 다음과 같다: 1. v2 데이터 백업 2. 헬름 v2 구성 마이그레이션 3. 헬름 v2 릴리스 마이그레이션 4. 헬름 v3가 모든 헬름 v2 데이터(헬름 v2 클라이언트 인스턴스의 모든 클러스터 및 Tiller 인스턴스에 대한)를 예상한대로 잘 관리한다고 확신할 경우, 헬름 v2 데이터 소거 - 마이그레이션 과정은 헬름 v3 [2to3](https://github.com/helm/helm-2to3) 플러그인으로 자동화된다. ## 참조 - 헬름 v3 [2to3](https://github.com/helm/helm-2to3) 플러그인 - `2to3` 플러그인 사용법을 예제와 함께 설명하는 블로그 [게시글](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "헬름 버전 지원 정책" description: "헬름의 패치 릴리스 정책 및 헬름과 쿠버네티스 간에 지원되는 최대의 버전 차이를 설명" --- 이 문서는 헬름과 쿠버네티스 간에 지원되는 최대의 버전 차이를 설명한다. ## 지원되는 버전 헬름 버전들은 `x.y.z` 로 표현된다. 여기서 `x` 는 주 버전, `y` 는 부 버전, z는 패치 버전으로 [유의적 버전](https://semver.org/spec/v2.0.0.html) 을 따른다. 헬름 프로젝트는 최신 부 릴리스에 대한 릴리스 브랜치를 유지한다. 보안 픽스를 포함하여 적용가능한 픽스는 심각도와 타당성에 따라 릴리스 브랜치로 선별 적용된다. 자세한 내용은 [헬름 릴리스 정책](/community/release_policy)을 참조한다. ## 지원되는 버전 차이(skew) 헬름의 새 버전이 출시 되면, 쿠버네티스의 특정 부 버전에 대해 컴파일된다. 예를 들어 헬름 3.0.0은 쿠버네티스 1.16.2 클라이언트를 사용하여 쿠버네티스와 상호작용하므로 쿠버네티스 1.16 과 호환된다고 할 수 있다. 헬름 3부터는, 헬름은 그에 대응하여 컴파일되는 쿠버네티스 `n-3` 버전과 호환되는 것으로 간주된다. 쿠버네티스 마이너 버전 간의 차이로 인해 헬름 2의 지원 정책은 약간 더 엄격한데, 쿠버네티스의 `n-1` 버전과 호환되는 것으로 간주한다. 예를 들어, 쿠버네티스 1.17 클라이언트 API 에 대응하여 컴파일된 헬름 3 버전을 사용하는 경우, 쿠버네티스 1.17, 1.16, 1.15 및 1.14 와 함께 사용하는 것이 안전할 것이다. 쿠버네티스 1.16 클라이언트 API 에 대해 컴파일 된 헬름 2 버전을 사용하는 경우, 쿠버네티스 1.16 및 1.15 와 함께 사용하는 것이 안전할 것이다. 헬름은 상위호환성을 보장하지 않으므로, 대응하여 컴파일된 버전보다 더 높은 쿠버네티스 버전에서 헬름을 사용하는 것은 권장되지 않는다. 만약 지원하지 않는 쿠버네티스 버전에서 헬름을 사용하고자 하는 경우, 사용자는 위험을 감수하고 사용하게 된다. 클러스터와 호환되는 헬름 버전을 확인하려면 아래의 표를 참조하자. | 헬름 버전 | 지원하는 쿠버네티스 버전 | |--------------|-------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "소개", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "사용법", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "주제", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "모범 사례", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "차트 템플릿 가이드", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm 명령어", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "커뮤니티", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "자주 묻는 질문", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/developers.md ================================================ --- title: 개발자 가이드 description: 헬름을 개발하는 사용자의 환경을 구성하기 위한 지침 sidebar_position: 1 --- 이 가이드에서는 헬름을 개발하기 위해 환경을 설정하는 방법을 설명한다. ## 전제 조건 - Go 최신버전 - kubectl 을 쓸 수 있는 쿠버네티스 클러스터 (선택사항) - Git ## 헬름 빌드하기 프로그램을 빌드하기 위해 Make를 사용한다. 시작하는 가장 간단한 방법은 다음과 같다. ```console $ make ``` 유의사항: `$ GOPATH / src / helm.sh / helm` 경로에서 실행하지 않으면 실패하게 된다. `helm.sh` 디렉토리는 심볼릭 링크가 아니어야 한다. 심볼릭 링크이면 `build`가 관련 패키지를 찾지 못한다. 필요한 경우 먼저 의존성을 설치하고 `vendor/` 트리를 다시 빌드하고 구성을 확인한다. 그런 다음 `helm` 을 컴파일하여 `bin/helm` 로 옮긴다. (`vendor/` 에 대한 테스트는 실행하지 않고) 모든 테스트를 실행하려면 `make test` 를 실행한다. 헬름을 로컬에서 실행하려면 `bin/helm` 을 실행한다. - 헬름은 맥OS 및 Alpine을 포함한 대부분의 리눅스 배포판에서 실행되는 것으로 알려져 있다. ## 기여 가이드라인 우리는 기여를 환영한다. 이 프로젝트는 (a) 코드 품질이 높게 유지되고, (b) 프로젝트가 일관되게 유지되고, (c) 기여가 오픈 소스 법적 요건을 따르기 위해 몇 가지 지침을 설정했다. 우리의 의도는 기여자에게 부담을 주는 것이 아니라 사용자가 혜택을 받을 수 있도록 우아하고 고품질의 오픈 소스 코드를 만드는 것이다. 가장 중심이라 할 수 있는 기여(CONTRIBUTING) 가이드를 읽고 숙지하자. https://github.com/helm/helm/blob/main/CONTRIBUTING.md ### 코드의 구조 Helm 프로젝트의 코드는 다음과 같이 구성된다. - 개별 프로그램은 `cmd/`에 위치한다. `cmd/` 내부의 코드는 라이브러리 재사용을 위해 설계되지는 않았다. - 공유 라이브러리는 `pkg/` 에 저장된다. - `scripts/` 디렉토리에는 여러 유틸리티 스크립트가 들어 있다. 대부분 CI/CD 파이프라인에서 사용한다. Go 의존성 관리는 유동적이며 Helm의 수명주기 동안 변경될 수 있다. 개발자는 의존성을 수동으로 관리하지 _않기를_ 권장한다. 대신 프로젝트의 `Makefile` 에 의존하여 이를 수행하는 것이 좋다. Helm 3에서는 Go 버전 1.13 이상을 사용하는 것이 좋다. ### 문서 작성하기 Helm 3 이후의 문서는 자체 저장소로 이동되었다. 새로운 기능을 작성할 때 함께 제공되는 문서를 작성하여 [helm-www] (https://github.com/helm/helm-www) 레포지터리에 제출하자. ### Git 관례 버전 제어 시스템으로는 Git을 사용한다. `main` 브랜치는 현재 개발 예정 브랜치의 홈 브랜치이다. 릴리스는 태그가 지정되며. GitHub PR (Pull Requests)을 통한 코드 변경을 허용한다. 이를 위한 작업 흐름은 다음과 같다. 1. `$GOPATH/src` 디렉토리로 이동한 후에, `mkdir helm.sh; cd helm.sh` 을 수행하고, `git clone` 으로 `github.com/helm/helm` 레포지터리를 복제한다. 2. 해당 레포지터리를 GitHub 계정으로 포크한다. 3. 레포지터리를 `$GOPATH/src/helm.sh/helm` 에 대한 원격 레포지터리로 추가한다. 4. 새로운 작업 브랜치를 만들고(`git checkout -b feat/my-feature`) 해당 브랜치에서 작업을 수행한다. 5. 리뷰를 위한 준비가 되면 브랜치를 GitHub으로 푸시한 다음 새로운 풀 리퀘스트를 생성한다. Git 커밋 메세지의 경우, 우리는 [유의적 커밋 메세지](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)를 따른다. ``` fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` 일반적인 커밋 유형: - fix: 버그 또는 오류 수정 - feat: 새로운 기능 추가 - docs: 문서 변경 - test: 테스트 개선 - ref: 기존 코드 리팩터링 일반적인 범위: - helm: 헬름 CLI - pkg/lint: 린트(lint) 패키지. 어떤 패키지든 유사한 관례에 따르자. - `*`: 두 개 이상의 스코프 더 읽어보기: - 이 섹션은 [Deis 가이드라인](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)에서 영감을 받아 작성되었다. - Karma Runner는 유의적 커밋 메세지에 대한 아이디어를 [정의](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) 한다. ### Go 관례 우리는 Go 코딩 스타일 표준을 매우 밀접하게 따른다. 일반적으로 `go fmt` 를 실행하여 사용자의 코드를 더욱 아름답게 만들수 있다. 또한 일반적으로 `go lint` 및 `gometalinter` 에서 권장하는 규칙을 따른다. 스타일 적합성을 테스트하려는 경우 `make test-style` 을 실행하자. 더 읽어보기: - Effective Go [포맷 소개](https://golang.org/doc/effective_go.html#formatting). - Go 위키에서 볼 수 있는 훌륭한 [포맷](https://github.com/golang/go/wiki/CodeReviewComments) 글 `make test` 타겟을 실행하면 단위 테스트뿐만 아니라 스타일 테스트도 실행된다. `make test` 대상이 스타일 상의 이유로 실패하면 PR 은 병합할 준비가 되지 않은 것으로 간주한다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/history.mdx ================================================ --- title: 프로젝트 연혁 description: 프로젝트의 연혁에 대한 개요를 설명한다. sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" 헬름 3는 [인큐베이션(incubation) 최종단계](https://github.com/cncf/toc/blob/main/process/graduation_criteria.adoc)에 있는 [CNCF 프로젝트](https://www.cncf.io/projects/)이다. 헬름은, 2015년에 시작되어 KubeCon에서 소개된 바 있는 [헬름 클래식](https://github.com/helm/helm-classic)이라 하는 멋진 프로젝트에서 시작되었다. 2016년 1월, 프로젝트는 쿠버네티스 디플로이먼트 매니저라고 불리는 GCS 도구로 병합되며, [쿠버네티스](https://kubernetes.io) 산하로 옮겨갔다. 코드베이스 병합의 결과로, 그 이듬해 헬름 2.0이 릴리스되었다. 디플로이먼트 매니저(Deployment Manager)의 핵심기능은 헬름 2로 이어져, 최종 헬름 2.0 릴리스에서 틸러(Tiller)라고 명명된 서버측 컴포넌트가 되었다. 2018년 6월에 헬름은 쿠버네티스의 서브프로젝트에서 본격적인 CNCF 프로젝트로 승격되었다. 헬름은 최상위 관리조직을 구성하고 헬름 프로젝트 산하로 여러 프로젝트들을 포괄하였는데, 모노큘러(Monocular), 헬름 차트 저장소(Helm Chart Repo), 차트 뮤지엄(Chart Museum), 나중에 헬름 허브(Helm Hub)를 포함하였다. 헬름 3 개발 사이클이 시작되면서, 틸러(Tiller)가 제거되고, 클라이언트 도구로서의 본래의 지향점에 더 가까워졌다. 그러면서도 헬름 3는 쿠버네티스 클러스터 내부의 릴리스 추적을 계속하여, 팀에서 공동의 헬름 릴리스 세트를 함께 다룰 수 있게 해준다. 헬름 3는 2019년 11월에 릴리스되었다. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/localization.md ================================================ --- title: 헬름 문서 현지화 description: 헬름 문서 현지화를 위한 설명서 sidebar_position: 5 --- 이 가이드에서는 헬름 문서를 현지화하는 방법에 대해 설명한다. ## 시작하기 번역 기여는 문서 기여와 동일한 과정을 거친다. 번역본은 [풀 리퀘스트](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) 를 통해 [helm-www](https://github.com/helm/helm-www) 깃 저장소에 제공되며 풀 리퀘스트는 웹사이트를 관리하는 팀이 검토한다. ### 두 글자 언어 코드 {#two-letter-language-code} 문서는 언어 코드를 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)으로 구성한다. 예를 들어, 한국어의 두 글자 코드는 `ko` 이다. 내용 및 설정에서 사용 중인 언어 코드를 찾을 수 있다. 세 가지 예: - `content` 디렉토리에 언어 코드가 하위 디렉토리로 있고 각 디렉토리마다 번역된 콘텐츠가 있는데, 주로 `docs` 하위 디렉토리에 있다. - `i18n` 디렉토리에는 웹사이트에서 사용하는 문구가 포함된 각 언어에 대한 설정 파일이 있다. 파일 이름은 `[LANG].toml` 로 지정되며, 여기서 `[LANG]` 은 두 글자 언어 코드다. - 프로젝트 최상위에 위치한 `config.toml` 파일에는 언어 코드별로 구성된 네비게이션 및 기타 세부 사항에 대한 설정 정보가 있다. 언어 코드가 `en` 인 영어는, 번역을 위한 기본 언어이자 원본이다. ### 포크, 브랜치, 변경, 풀 리퀘스트 번역본을 기여하려면 먼저 깃헙에 [helm-www 저장소](https://github.com/helm/helm-www)의 [포크를 만드는 것](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)부터 시작한다. 사용자는 자신의 포크를 커밋함으로써 시작하게 된다. 기본적으로 포크는 master라는 기본 브랜치에서 동작하도록 설정된다. 변경 사항을 개발하고 풀 리퀘스트를 생성하기 위해 브랜치를 사용하자. 브랜치가 익숙하지 않다면 [깃헙 문서를 읽어볼 수 있다](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches). 브랜치가 있다면 번역을 추가하고 내용을 현지화하자. 참고로 헬름은 [원본 개발자 증명서](https://developercertificate.org/)를 사용한다. 모든 커밋은 서명이 필요하다. 커밋을 생성할 때, 깃에 설정된 이름과 이메일 주소로 서명하기 위해 `-s` 또는 `--signoff` 플래그를 쓸 수 있다. 자세한 내용은 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work)에서 확인할 수 있다. 준비되면 번역본과 함께 다시 helm-www 저장소로 [풀 리퀘스트](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)를 생성하자. 풀 리퀘스트를 생성하면 관리자 중 한 명이 검토할 것이다. 그 과정에 대한 세부사항은 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md)에 있다. ## 콘텐츠 번역하기 헬름의 모든 내용을 현지화하는 것은 상당한 작업이다. 작은 부분부터 시작해도 괜찮다. 이 후에 더 번역할 수 있다. ### 새로운 언어 등록하기 새로운 언어를 등록할 때 필요한 최소 요건이 있다. 여기에는 다음이 포함된다: - `index.md` 파일이 들어 있는 `content/[LANG]/docs` 디렉토리 추가. 이것은 최상위 문서 랜딩 페이지다. - `i18n` 디렉토리에 `[LANG].toml` 파일 생성. `en.toml` 파일을 복사해서 시작할 수 있다. - 새로운 언어를 서비스하기 위해 `config.toml` 파일에 해당 언어 섹션 추가. 기존 언어 섹션을 써서 등록할 수도 있다. ### 번역하기 번역된 콘텐츠는 `content/[LANG]/docs` 디렉토리에 있어야 한다. 이것은 영어 원문과 동일한 URL을 가져야 한다. 예를 들어, 소개 부분을 한국어로 번역하려면 다음과 같이 영어 원문을 복사하는 것이 유용할 수 있다: ```sh mkdir -p content/ko/docs/intro cp content/en/docs/intro/install.md content/ko/docs/intro/install.md ``` 그러면 새 파일의 내용을 다른 언어로 번역할 수 있다. 영문 파일의 번역되지 않은 사본을 `content/[LANG]/` 에 추가하지 않도록 한다. 사이트에 해당 언어가 존재하면 번역되지 않은 페이지는 자동으로 영문 페이지로 리다이렉션된다. 번역에는 시간이 필요하고, 사용자들은 오래된 버전의 포크가 아닌 최신 버전의 문서를 번역하길 원한다. 헤더 섹션에서 `aliases` 행을 반드시 제거하자. `aliases: ["/docs/using_helm/"]` 과 같은 행은 번역에 속하지 않는다. 이것은 새로운 페이지 링크로 인해 없어진 링크에 대한 리다이렉션이다. 참고로 번역 도구는 이 과정에 도움을 줄 수 있다. 여기에는 번역기로 생성한 번역도 포함된다. 번역기로 생성한 번역은 내보내기 전에 원어민이 문법과 의미를 편집하거나 검토해야 한다. ## 언어 변경 ![Screen Shot 2020-05-11 at 11 24 22 AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png) 사이트 전역 [config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89) 파일에서 언어 변경을 구성한다. 새로운 언어를 추가하려면 위에서 정의한 [두 글자 언어 코드](#two-letter-language-code)를 사용하여 새로운 매개 변수 집합을 추가하자. 예: ``` # Korean [languages.ko] title = "Helm" description = "Helm - The Kubernetes Package Manager." contentDir = "content/ko" languageName = "한국어 Korean" weight = 1 ``` ## 내부 링크 결정하기 번역된 콘텐츠는 간혹 번역되지 않은 페이지에 대한 링크를 포함한다. 이로 인해 사이트 [빌드 오류](https://app.netlify.com/sites/helm-merge/deploys)가 발생할 수 있다. 예: ``` 12:45:31 PM: htmltest started at 12:45:30 on app 12:45:31 PM: ======================================================================== 12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html 12:45:31 PM: hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example 12:45:31 PM: ✘✘✘ failed in 197.566561ms 12:45:31 PM: 1 error in 212 documents ``` 이 문제를 해결하려면 콘텐츠에서 내부 링크를 확인해야 한다. * 앵커 링크는 번역된 `id` 값을 반영해야 한다. * 내부 페이지 링크를 고쳐야 한다. 존재하지 않는 _(혹은 아직 번역되지 않은)_ 내부 페이지가 있을 경우, 교정될 때까지 사이트가 빌드되지 않는다. 그 대신 URL은 다음과 같이 해당 콘텐츠가 _존재하는_ 다른 언어를 가리킬 수 있다. `< relref path="/docs/topics/library_charts.md" lang="en" >` 자세한 내용은 [언어 간 상호 참조에 대한 휴고(Hugo) 문서](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) 를 참조하자. ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/related.md ================================================ --- title: 관련 프로젝트와 문서 description: 커뮤니티에서 제공하는 서드파티 도구, 플러그인 및 문서 sidebar_position: 3 --- 헬름 커뮤니티는 헬름에 대한 많은 추가 도구, 플러그인 및 문서를 만들었습니다. 우리는 이러한 프로젝트에 대해 듣고 싶습니다. 이 목록에 추가하고 싶은 것이 있으면 [이슈](https://github.com/helm/helm-www/issues)나 [풀 리퀘스트(PR)](https://github.com/helm/helm-www/pulls) 할 수 있습니다. ## 헬름 플러그인 {#helm-plugins} - [Helm Diff](https://github.com/databus23/helm-diff) - 컬러 diff로 `helm upgrade` 미리보기 - [helm-gcs](https://github.com/hayorov/helm-gcs) - Google Cloud Storage에서 저장소를 관리하는 플러그인 - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - 프로메테우스/엘라스틱서치 쿼리를 기반으로 릴리스 및 롤백을 모니터링하는 플러그인 - [helm-k8comp](https://github.com/cststack/k8comp) - k8comp 를 사용하여 hiera 에서 헬름 차트를 생성하는 플러그인 - [helm-unittest](https://github.com/helm-unittest/helm-unittest) - YAML로 로컬에서 차트를 단위 테스트하기 위한 플러그인 - [hc-unit](https://github.com/xchapter7x/hcunit) - OPA (Open Policy Agent) 및 Rego로 로컬에서 차트를 단위 테스트하기 위한 플러그인 - [helm-s3](https://github.com/hypnoglow/helm-s3) - [프라이빗] 차트 저장소로 AWS S3를 사용할 수 있게 해주는 헬름 플러그인 - [helm-secrets](https://github.com/jkroepke/helm-secrets) - 비밀정보를 안전하게 관리하고 보관하기 위한 플러그인 ([sops](https://github.com/mozilla/sops) 기반) GitHub 작성자가 플러그인 저장소에 [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) 태그를 사용할 것을 권장한다. ## 추가적인 도구들 헬름의 상위 계층 도구들. - [Chartify](https://github.com/appscode/chartify) - 기존 쿠버네티스 리소스에서 헬름 차트를 생성 - [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - 쿠버네티스 및 헬름용(用) VIM 플러그인 - [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper 는 값(원하는 상태)을 가진 헬름 차트 참조 집합을 가져와서 쿠버네티스 클러스터에서 실현한다." - [Helmfile](https://github.com/helmfile/helmfile) - Helmfile은 헬름 차트 배포를 위한 선언적 사양이다 - [Helmsman](https://github.com/Praqma/helmsman) - Helmsman은 버전 관리되는 원하는 상태 파일들(간단한 TOML 형식으로 기술됨)로부터 릴리스를 설치/업그레이드/보호/이동/삭제할 수 있는 코드로서의-헬름-차트(helm-charts-as-code) 도구이다 - [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - HashiCorp Terraform용 헬름 공급자(provider)는 선언적 코드형 인프라(infrastructure-as-code) 구문으로 헬름 차트의 수명주기를 관리할 수 있게 해준다. 헬름 공급자는 쿠버네티스 공급자처럼, 모든 인프라 서비스에서 통용되는 워크플로를 만들기 위해, 다른 테라폼 공급자와 쌍을 이루는 경우가 많다. - [Monocular](https://github.com/helm/monocular) - 헬름 차트 저장소를 위한 웹 UI - [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - 여러 쿠버네티스 네임스페이스에 걸쳐 접두어가 붙은 릴리스들을 관리하며, 복잡한 배포에서의 완료된 작업들을 제거한다 - [ChartMuseum](https://github.com/helm/chartmuseum) - Amazon S3와 Google Cloud Storage를 지원하는 헬름 차트 저장소 - [Codefresh](https://codefresh.io) - 헬름 차트 및 릴리스를 관리하기 위한 UI 대시보드가 있는 쿠버네티스 네이티브 CI/CD 및 관리 플랫폼 - [Captain](https://github.com/alauda/captain) - HelmRequest 및 릴리스 CRD를 사용하는 Helm3 컨트롤러 - [chart-registry](https://github.com/hangyan/chart-registry) - OCI 저장소 상의 헬름 차트 호스트 - [avionix](https://github.com/zbrookle/avionix) - 상속과 코드중복 저감을 할 수 있는 헬름 차트와 쿠버네티스 yaml 을 생성하는 파이썬 인터페이스. ## 헬름 지원 헬름 지원을 포함하는 플랫폼, 배포판 및 서비스. - [Kubernetic](https://kubernetic.com/) - 쿠버네티스 데스크탑 클라이언트 - [Jenkins X](https://jenkins-x.io/) - GitOps 환경을 통해 애플리케이션을 [프로모션(promotion)](https://jenkins-x.io/docs/getting-started/promotion/)하기 위해 헬름을 사용하는 쿠버네티스용 오픈소스 자동화 CI/CD ## 기타 차트 작성자와 헬름 사용자에게 유용한 것 모음. - [Await](https://github.com/saltside/await) - 다른 조건들에 대해 "대기(await)"하는 도커 이미지--특히 초기화 컨테이너에 유용하다. [더 보기](https://blog.slashdeploy.com/2017/02/16/introducing-await/) ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/release_checklist.md ================================================ --- title: 릴리스 체크리스트 description: 다음 버전의 헬름을 출시할 때 유지관리자를 위한 체크리스트 sidebar_position: 2 --- # 헬름 릴리스에 대한 유지관리자 가이드 새로운 헬름을 출시할 시간이다! 릴리스를 끊는 헬름 유지관리자로서, 자신의 경험이 여기에 문서화된 내용과 다른 점이 있다면 이 릴리스 체크리스트를 업데이트하기에 딱 맞는 사람이다. 모든 릴리스는 vX.Y.Z 형식이다. 여기서 X는 주 버전 번호, Y는 부 버전 번호, Z는 패치 릴리스 번호이다. 이 프로젝트는 [유의적 버전 관리] (https://semver.org/)를 엄격히 따르므로 이 단계를 따르는 것이 매우 중요하다. 헬름은 다음 마이너 릴리스 날짜를 미리 발표한다. 발표된 날짜를 지키기 위해 최선을 다해야 한다. 또한 릴리스 프로세스를 시작할 때, 다음 릴리스 날짜를 선택해야 하며 릴리스 프로세스의 일환이다. 이 지침은 초기 구성에 이어 세 가지 다른 종류의 릴리스에 대한 릴리스 절차를 다룬다. * 주 릴리스 - 상대적으로 낮은 빈도로 릴리스 - 주요 변경 사항이 있음 * 부 릴리스 - 3~4개월마다 릴리스 - 주요 변경 사항 없음 * 패치 릴리스 - 매월 릴리스 - 이 가이드의 모든 단계가 불필요 [초기 구성](#초기-구성) 1. [릴리스 브랜치 생성](#1-릴리스-브랜치-생성) 2. [주 또는 부 릴리스: git에서 버전 번호 변경](#2-git에서-주-또는-부-버전-번호-변경) 3. [주/부 릴리스: 릴리스 브랜치 커밋 및 푸시](#3-주부-릴리스-릴리스-브랜치-커밋-및-푸시) 4. [주/부 릴리스: 릴리스 후보 생성](#4-주부-릴리스-릴리스-후보-생성) 5. [주/부 릴리스: 연속 릴리스 후보 개선](#5-주부-릴리스-연속-릴리스-후보-개선) 6. [릴리스 확정](#6-릴리스-확정) 7. [릴리스 노트 작성](#7-릴리스-노트-작성) 8. [다운로드에 PGP 서명](#8-다운로드에-pgp-서명) 9. [릴리스 출간](#9-릴리스-출간) 10. [문서 업데이트](#10-문서-업데이트) 11. [커뮤니티에 알리기](#11-커뮤니티에-알리기) ## 초기 구성 ### Git 원격 설정하기 이 문서에서는 저장소에서 에 해당하는 Git 원격의 이름이 "upstream"이라고 가정한다는 점에 유의해야 한다. 그렇지 않은 경우(예: 이름을 "origin" 또는 이와 유사한 이름으로 선택한 경우) 그에 따라 로컬 환경에 맞게 나열된 스니핏(snippet)을 조정해야 한다. 업스트림 원격의 이름이 확실하지 않은 경우 `git remote -v` 와 같은 명령을 사용하여 확인하자. [업스트림 원격](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)이 없는 경우 다음과 같이 추가할 수 있다. ```shell git remote add upstream git@github.com:helm/helm.git ``` ### 환경 변수 설정하기 이 문서에서는 편의를 위해 설정할 수 있는 몇 가지 환경 변수를 소개한다. 주/부 릴리스의 경우 다음을 사용하자. ```shell export RELEASE_NAME=vX.Y.0 export RELEASE_BRANCH_NAME="release-X.Y" export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" ``` 패치 릴리스를 만드는 경우 대신 다음을 사용하자. ```shell export PREVIOUS_PATCH_RELEASE=vX.Y.Z export RELEASE_NAME=vX.Y.Z+1 export RELEASE_BRANCH_NAME="release-X.Y" ``` ### 서명 키 설정하기 또한 바이너리를 해싱하고 서명 파일을 제공하여 릴리스 프로세스의 보안 및 검증을 추가한다. 이 작업은 [GitHub 및 GPG] (https://help.github.com/en/articles/about-commit-signature-verification)를 이용하여 수행한다. GPG가 아직 설정되지 않은 경우, 다음 단계를 수행할 수 있다. 1. [GPG 설치] (https://gnupg.org/index.html) 2. [GPG 키 생성] (https://help.github.com/en/articles/generating-a-new-gpg-key) 3. [GitHub 계정에 키 추가] (https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) 4. [Git에서 서명 키 설정] (https://help.github.com/en/articles/telling-git-about-your-signing-key) 서명 키가 있으면 저장소 루트에 있는 KEYS 파일에 추가해야 한다. KEYS 파일에 추가하는 지시어는 그 파일 안에 있다. 아직 공개 키를 키 서버 네트워크에 추가하지 않았다면 추가해야 한다. GnuPG를 사용하는 경우 [Debian에서 제공하는 지침] (https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver)을 따를 수 있다. ## 1. 릴리스 브랜치 생성 ### 주/부 릴리스 주요 릴리스는 *이전 호환성을 깨는* 새로운 기능의 추가 및 동작 변경을 위한 것이다. 부 릴리스는 이전 버전과의 호환성을 깨지 않는 선에서 새로운 기능 추가를 위한 것이다. 주 또는 부 릴리스를 생성하려면 먼저 main에서 `release-X.Y` 브랜치를 생성한다. ```shell git fetch upstream git checkout upstream/main git checkout -b $RELEASE_BRANCH_NAME ``` 이 새 브랜치는 릴리스의 기반이 되며, 이를 기반으로 하여 변경해 나갈 것이다. 릴리스에 대한 [헬름/헬름 마일스톤] (https://github.com/helm/helm/milestones)이 GitHub에 있는지 확인한다(필요한 경우 생성). 이 릴리스에 대한 PR 및 이슈가 이 마일스톤에 있는지 확인하자. 주 또는 부 릴리스의 경우 2 단계로 이동한다. [주 또는 부 릴리스: git에서 버전 번호 변경](#2-git에서-주-또는-부-버전-번호-변경) ### 패치 릴리스 패치 릴리스는 기존 릴리스에 대한 몇 가지 중요한 수정 사항이다. `release-X.Y` 브랜치를 생성하여 시작한다. ```shell git fetch upstream git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME ``` 여기에서 패치 릴리스로 가져올 커밋을 선택할 수 있다. ```shell # 체리-픽(cherry-pick)하려는 커밋 ID 목록 조회 git log --oneline # 병합 커밋을 포함하지 않고 가장 오래된 커밋부터 골라서 선택 git cherry-pick -x ``` 커밋이 체리픽되면 릴리스 브랜치를 푸시해야 한다. ```shell git push upstream $RELEASE_BRANCH_NAME ``` 분기를 푸시하면 테스트가 실행되며, 태그를 만들기 전에 통과해야 한다. 이 새로운 태그는 패치 릴리스의 기반이 된다. 패치 릴리스의 경우 [헬름/헬름 마일스톤] (https://github.com/helm/helm/milestones) 생성은 선택사항이다. 계속 진행하기 전에 릴리스가 CI를 통과했는지 [GitHub Actions 에서의 헬름](https://github.com/helm/helm/actions)를 확인하자. 패치 릴리스는 2-5 단계를 건너 뛰고 6 단계로 진행하여 [릴리스 확정](#6-릴리스-확정)를 수행할 수 있다. ## 2. git에서 주 또는 부 버전 번호 변경 주 또는 부 릴리스를 수행할 때 `internal/version/version.go` 를 새 릴리스 버전으로 업데이트해야 한다. ```shell $ git diff internal/version/version.go diff --git a/internal/version/version.go b/internal/version/version.go index 712aae64..c1ed191e 100644 --- a/internal/version/version.go +++ b/internal/version/version.go @@ -30,7 +30,7 @@ var ( // Increment major number for new feature additions and behavioral changes. // Increment minor number for bug fixes and performance enhancements. // Increment patch number for critical fixes to existing releases. - version = "v3.3" + version = "v3.4" // metadata is extra build time data metadata = "" ``` `version.go` 파일에서 버전을 업데이트하는 것 외에도 해당 버전 번호를 사용하는 해당 테스트도 업데이트해야 한다. * `cmd/helm/testdata/output/version.txt` * `cmd/helm/testdata/output/version-client.txt` * `cmd/helm/testdata/output/version-client-shorthand.txt` * `cmd/helm/testdata/output/version-short.txt` * `cmd/helm/testdata/output/version-template.txt` * `pkg/chartutil/capabilities_test.go` ```shell git add . git commit -m "bump version to $RELEASE_NAME" ``` 이는 $RELEASE_BRANCH_NAME에 대해서만 업데이트된다. [3.2에서 3.3으로의 이 예제](https://github.com/helm/helm/pull/8411/files)에서와 같이 다음 릴리스가 생성될 때 이 변경 사항을 마스터 브랜치로 가져와야 하며, 다음 릴리스의 마일스톤에 추가해야 한다. ```shell # 버전을 올리기 위해 마지막 커밋을 획득 git log --format="%H" -n 1 # 마스터에서 새 브랜치를 생성 git checkout main git checkout -b bump-version- # 첫 번째 명령으로부터 ID를 사용하여 커밋을 체리픽 git cherry-pick -x # 변경 사항 커밋 git push origin bump-version- ``` ## 3. 주/부 릴리스: 릴리스 브랜치 커밋 및 푸시 다른 사람들이 테스트를 시작하기 위해 이제 릴리스 브랜치를 업스트림으로 푸시하고 테스트 프로세스를 시작할 수 있다. ```shell git push upstream $RELEASE_BRANCH_NAME ``` 계속 진행하기 전에 릴리스가 CI를 통과했는지 [GitHub Actions 에서의 헬름] (https://github.com/helm/helm/actions)을 확인하자. 사용 가능한 사람이 있는 경우 모든 적절한 변경 사항이 적용되고 릴리스에 대한 모든 커밋이 있는지 계속 확인하기 전에 다른 사용자와 브랜치에 대해 동료-평가를 진행하자. ## 4. 주/부 릴리스: 릴리스 후보 생성 이제 릴리스 브랜치가 나왔고 준비되었으므로 릴리스 후보를 만들고 반복할 차례이다. ```shell git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` GitHub Actions는 테스트할 태그된 릴리스 이미지와 클라이언트 바이너리를 자동으로 생성한다. 테스터의 경우 GitHub Actions가 아티팩트 빌드를 완료한 후 테스트를 시작하는 프로세스에는 다음과 같이 클라이언트를 받는 단계가 포함된다. 리눅스/amd64 의 경우, /bin/bash 를 사용한다 ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz ``` darwin/amd64 의 경우, Terminal.app 을 사용한다. ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz ``` 윈도우/amd64, 파워셸(PowerShell)을 사용한다. ```shell PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" ``` 그런 다음 바이너리의 압축을 풀고 $PATH의 특정 장소로 이동하거나 특정 장소로 이동하여 $PATH에 추가한다 (예 : linux/macOS의 경우 /usr/local/bin/helm, Windows의 경우 C:\Program Files\helm\helm.exe). ## 5. 주/부 릴리스: 연속 릴리스 후보 개선 릴리스와 관련된 모든 결과를 문서화하여 가능한 모든 방법으로 헬름 테스트를 시도하고 중단하기 위해 명시적으로 시간과 리소스를 투자하는 데 여러 시간을 보내게 된다. 이 시간은 릴리스가 다양한 기능 또는 업그레이드 환경에, 코딩이 아닌 문제를 유발할 수있는 방법을 테스트하고 찾는데 소비되어야 한다. 이 기간 동안 릴리스는 코드 동결 상태이며 추가 코드 변경 사항은 다음 릴리스로 푸시된다. 이 단계에서 $RELEASE_BRANCH_NAME 브랜치는 새로운 출시 후보를 생성함에 따라 계속 발전하게 된다. 새로운 후보의 빈도는 릴리스 관리자에게 달려 있다. 보고된 문제의 심각도, 테스터의 가용성 및 릴리스 기한을 고려하여 최선의 판단을 내리자. 일반적인 경우, 손상된 릴리스를 전달하는 것보다는 릴리스가 마감일을 넘기는게 차라리 더 좋다. 새 릴리스 후보를 생성 할 때마다 마스터 브랜치에서 체리픽 하여 브랜치에 커밋을 추가하는 것으로 시작한다. ```shell git cherry-pick -x ``` 또한 분기를 GitHub으로 푸시하고 CI를 통과하는지도 확인해야 한다. 그럼 다음 태그를 지정하고 사용자들에게 새 릴리스 후보에 대해 알린다. ```shell export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` GitHub에 푸시되면 이 태그가 있는 브랜치가 CI에 빌드 되는지 확인한다. 여기서부터는 이 프로세스를 반복하고 릴리스 후보에 만족할 때까지 지속적으로 테스트한다. 릴리스 후보의 경우 전체 노트를 작성하지는 않지만 일부 [릴리스 노트](#7-릴리스-노트-작성)를 미리 작성(scaffold)할 수 있다. ## 6. 릴리스 확정 최종적으로 릴리스 후보의 품질에 만족한다면 계속 진행하여 진짜를 만들 수 있다. 마지막으로 한 번 더 확인하여 모든 것이 정상인지 확인한 다음, 마지막으로 릴리스 태그를 푸시한다. ```shell git checkout $RELEASE_BRANCH_NAME git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" git push upstream $RELEASE_NAME ``` 릴리스가 [GitHub Actions](https://github.com/helm/helm/actions)에서 성공했는지 확인하자. 그렇지 않은 경우 릴리스를 수정하고 릴리스를 다시 푸시해야 한다. CI 작업을 실행하는 데 약간의 시간이 걸리므로 완료될 때까지 기다리는 동안 릴리스 정보 작성 단계로 넘어갈 수 있다. ## 7. 릴리스 노트 작성 릴리스 주기 동안 발생한 커밋을 기반으로 변경 로그를 자동 생성하지만 일반적으로 수동으로, 인간 생명체든/마케팅 팀이든/심지어 고양이라도 릴리스 노트는 손으로 작성한 경우가 최종 사용자에게 더 유용하다. 주/부 릴리스를 릴리스하는 경우 일반적으로 주목할만한 사용자용 기능을 나열하는 것으로 충분하다. 패치 릴리스의 경우 동일하게 하되 증상이나 영향을 받을 수 있는 사용자에 대해 기재하자. 릴리스 정보에는 다음 릴리스의 버전과 계획된 날짜가 포함되어야 한다. 부 릴리스에 대한 예제 릴리스 노트는 다음과 같다. ```markdown ## vX.Y.Z Helm vX.Y.Z는 기능 릴리스이다. 이번 릴리스에서는 에 중점을 두었다. 사용자는 최상의 환경을 위해 업그레이드하는 것이 좋다. 커뮤니티는 계속 성장하고 있으며, 함께하면 좋겠다! - [Kubernetes Slack] (https://kubernetes.slack.com)에서 토론에 참여해보자. - 질문을 하려면 `#helm-users` - PR, 코드, 버그를 논의하려면 `#helm-dev` - 공개 개발자 전화 : 목요일 오전 9시 30 분 [Zoom]을 통해 행 아웃 (https://zoom.us/j/696660622) - 차트 테스트, 디버그, 기여 : [GitHub/헬름/차트] (https://github.com/helm/charts) ## 주목할 만한 변화 - Kubernetes 1.16은 이제 새 매니페스트 apiVersion도 지원한다. - Sprig은 2.22으로 업그레이드되었다. ## 설치 및 업그레이드 헬름 X.Y 를 다운로드한다. 일반적인 플랫폼 바이너리는 다음과 같다. - [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [리눅스 amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [리눅스 arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) - [리눅스 arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) - [리눅스 i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) - [리눅스 ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) - [리눅스 s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) - [윈도우 amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) [빠른 시작 가이드](/intro/quickstart.md)를 참조하세요. **업그레이드 안내** 또는 자세한 설치 정보는 [설치 가이드](/intro/install.md)를 확인하세요. `bash` 가 있는 모든 시스템에서 [설치할 스크립트] (https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)를 사용할 수도 있다. ## 향후 계획 - vX.Y.Z + 1 에는 버그 수정만 포함되며 <날짜 삽입>에 릴리스 예정이다. - vX.Y + 1.0 은 다음 기능 릴리스이며 <날짜 삽입>에 릴리스 예정이다. 이 릴리스는 ... ## 변경로그 - chore(*) v2.7.0 로 버전 업(bump) 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) - 태그를 작성하지 않는 버그 수정 f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) ``` 변경 로그를 포함하여 부분적으로 완료된 릴리스 정보 집합은 다음 명령을 실행하여 작성할 수 있다. ```shell export VERSION="$RELEASE_NAME" export PREVIOUS_RELEASE=vX.Y.Z make clean make fetch-dist make release-notes ``` 이렇게하면 **주요 변경 사항** 및 **다음 단계** 섹션을 작성하기만 하면 되는 훌륭한 기본 출시 노트 세트가 생성된다. 릴리스 노트에 의견을 자유롭게 추가하도록 하자. 사람들이 볼 때, 우리가 로봇이라는 생각이 들지 않도록 하는 것이 좋다. 또한 자동 생성된 릴리스 노트에서 URL과 체크섬이 올바른지 다시 확인해야 한다. 완료되면 GitHub에서 [헬름/헬름 릴리스](https://github.com/helm/helm/releases)로 이동하고 여기에 작성된 메모로 태그가 지정된 릴리스의 릴리스 노트를 편집한다. 대상 분기의 경우 $RELEASE_BRANCH_NAME로 설정한다. 이제는 릴리스가 게시되기 전에 다른 사람들에게 릴리스 정보를 보여주어 검토 받을 필요가 있다. 검토를 받기 위해 [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG)로 요청을 보내자. 누구든 놓치는 부분이 있을 수 있기 때문에 항상 도움이 된다. ## 8. 다운로드에 PGP 서명 해시는 다운로드 내용이 어떤 것으로 생성되었는지에 대한 서명을 제공하지만, 서명된 패키지는 그 패키지가 어디서 왔는지 출처를 추적할 수 있게 해준다. 이렇게 하기 위하여 다음의 `make` 명령을 실행한다. ```shell export VERSION="$RELEASE_NAME" make clean # if not already run make fetch-dist # if not already run make sign ``` 이렇게 하면 CI가 푸시한 개별 파일에 대하여, ASCII 아머드 서명 파일을 생성한다. 모든 서명 파일(`*.asc`)을 GitHub의 릴리스에 업로드해야 한다. (바이너리 첨부) ## 9. 릴리스 출간 이제 출시를 공식화할 차례이다! 릴리스 노트가 GitHub에 저장되고 CI 빌드가 완료되고 릴리스에 서명 파일을 추가한 후 릴리스에서 "게시"를 누를 수 있다. 그러면 릴리스가 게시되고 "최신(latest)"으로 나열되며 [helm/helm] (https://github.com/helm/helm) 저장소의 첫 페이지에 이 릴리스가 표시된다. ## 10. 문서 업데이트 [헬름 웹 사이트 문서 섹션](/docs)에는 문서의 헬름 버전이 나열된다. 사이트에서 주, 부, 패치 버전을 업데이트해야 한다. 다음 부 릴리스 날짜도 사이트에 게시되며 업데이트해야 한다. 이를 위해 [helm-www 저장소] (https://github.com/helm/helm-www)에 대한 pull 요청을 생성한다. `config.toml` 파일에서 적절한 `params.versions` 섹션을 찾고 [현재 버전 업데이트](https://github.com/helm/helm-www/pull/676/files)의 예와 같이 헬름 버전을 업데이트한다. 동일한`config.toml` 파일에서 `params.nextversion` 섹션을 업데이트한다. 해당되는 경우 릴리스의 [helm/helm 마일스톤](https://github.com/helm/helm/milestones)을 닫는다. 주/부 릴리스의 [버전 차이] (https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md)를 업데이트한다. [여기](https://helm.sh/calendar/release)에서 릴리스 달력을 업데이트한다. * 당일 오후 5시 GMT에 대한 알림과 함께 다음 마이너 릴리스에 대한 항목을 생성한다. * 계획된 릴리스 전의 월요일에 다음 마이너 릴리스의 RC1 항목을 만들고 그날 오후 5시 GMT에 대한 알림을 생성한다. ## 11. 커뮤니티에 알리기 축하한다! 모두 완료했다. $DRINK_OF_CHOICE 를 한모금 하자. 당신은 그럴만한 일을 했다. 좋은 $DRINK_OF_CHOICE 를 즐긴 후, Slack과 Twitter에 [GitHub 릴리스] (https://github.com/helm/helm/releases) 링크를 통해 새 릴리스를 발표하자. 선택적으로, 새 릴리스에 대한 블로그 게시물을 작성하고 그 곳에 몇 가지 새로운 기능을 보여주도록 하자! ================================================ FILE: i18n/ko/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "릴리스 스케줄 정책" description: "헬름의 출시 스케줄 정책을 설명한다." --- 사용자를 위해 헬름은 사전에 출시 날짜를 정의하고 발표한다. 이 문서는 헬름의 출시 스케줄을 관리하는 정책을 설명한다. ## 릴리스 캘린더 {#release-calendar} 예정된 헬름 릴리스를 보여주는 공개 캘린더는 [여기](https://helm.sh/calendar/release)에서 확인할 수 있다. ## 유의적 버전 {#semantic-versioning} 헬름 버전은 `x.y.z` 로 표시된다. 여기서 `x` 는 주 버전, `y` 는 부 버전, `z` 는 패치 버전으로서 [유의적 버전](https://semver.org/spec/v2.0.0.html)을 따른 것이다. ## 패치 릴리스 {#patch-releases} 패치 릴리스는 사용자에게 버그 수정 및 보안 수정을 제공한다. 새로운 기능은 포함되어 있지 않다. 최신 부/주 릴리스와 관련된 새 패치 릴리스는 일반적으로 한 달에 한 번, 각 달의 두 번째 수요일에 나온다. 우선순위가 높은 회귀 또는 보안 문제를 수정하는 패치 릴리스는 필요시마다 나올 수 있다. 다음 이유 중 하나에 해당되면 패치 릴리스가 취소된다: - 이전 릴리스 이후 새로운 콘텐츠가 없는 경우 - 패치 릴리스 날짜가 예정된 부 릴리스의 첫 번째 릴리스 후보(RC1) 1주일 이내인 경우 - 패치 릴리스 날짜가 부 릴리스 이후 4주 이내인 경우 ## 부 릴리스 {#minor-releases} 부 릴리스에는 보안 및 버그 수정과 새로운 기능이 포함되어 있다. API 및 CLI 사용법에 대해서는 하위호환된다. 쿠버네티스 릴리스에 맞추기 위해 부 헬름 릴리스는 4개월마다 나온다. (1년에 릴리스 3개) 필요한 경우 추가 부 릴리스가 나올 수도 있지만 발표된 릴리스가 7일 이내가 아니라면 발표된 향후 릴리스의 일정에 영향을 주지는 않는다. 릴리스가 게시됨과 동시에 다음 부 릴리스 날짜가 발표되고 헬름 메인 웹페이지에 게시된다. ## 주 릴리스 {#major-releases} 주 릴리스에는 단절적(breaking) 변경이 포함되어 있다. 이러한 출시는 드물지만 때로는 새로운 방향으로 헬름을 계속 진화시켜 나가기 위해 필요하다. 주 릴리스는 계획하기 어려울 수 있다. 이를 염두에 두고 최종 릴리스 날짜는 해당 릴리스의 첫 번째 베타 버전이 제공될 때만 선택되고 발표된다. ================================================ FILE: i18n/ko/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Helm 프로젝트", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "차트", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "개발", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "커뮤니티", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "소스 코드", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "블로그", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "이벤트", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "행동 강령", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "소개", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "차트 팁과 요령", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "차트 개발하기", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "800개 이상의 차트 검색", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "기여 가이드", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "유지관리자", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "주간 회의", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "GitHub 커뮤니티", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "우리는 Cloud Native Computing Foundation의 졸업 프로젝트입니다.
© Helm Authors 2025. 문서는 CC-BY-4.0 하에 배포됩니다.
© 2025 The Linux Foundation. 모든 권리 보유. The Linux Foundation은 등록 상표를 보유하고 사용합니다. The Linux Foundation의 상표 목록은 상표 사용 페이지를 참조하세요.", "description": "The footer copyright" }, "logo.alt": { "message": "CNCF 로고", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/ko/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Helm 로고", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "문서", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "차트", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "블로그", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "커뮤니티", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/pt/code.json ================================================ { "home.community.nextFeatureRelease": { "message": "Próximos Lançamentos de Funcionalidades", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Versão:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Data:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Calendário de Lançamentos", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Próximos Eventos", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Próximos Eventos", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Eventos Anteriores", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "Eles {meetLink} para demonstrar e discutir ferramentas e projetos. As reuniões da comunidade são gravadas e {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "reúnem-se semanalmente", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "partilhadas no YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Encontro com Desenvolvedores" }, "home.community.developerStandups.time": { "message": "Quintas-feiras 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Estas reuniões estão abertas a todos. Consulte o {communityRepoLink} para notas e detalhes.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "repositório da comunidade", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Discussão sobre o uso do Helm, trabalho com charts e resolução de erros comuns.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Tópicos relacionados com o desenvolvimento do Helm, PRs em curso, lançamentos, etc.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Discussão para utilizadores e colaboradores dos Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink} para se juntar à equipa Kubernetes Slack.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Solicite acesso aqui", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Contribuir", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "O Helm sempre dá boas-vindas a novas contribuições para o projeto!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "Por onde começar?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "O Helm é um grande projeto com muitos utilizadores e colaboradores. Pode ser muito para absorver!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "Temos uma lista de {goodFirstIssuesLink} se quiser ajudar mas não sabe por onde começar.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "boas primeiras issues", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "O que devo fazer?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Antes de contribuir com código, por favor leia o nosso {contributionGuideLink}. Ele aborda os processos de criação e revisão de pull requests.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Guia de Contribuição", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Depois de escrever algum código, por favor {signYourCommitsLink} para garantir que o Helm adere ao acordo {dcoLink} usado pela {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "assine os seus commits", "description": "Sign your commits link" }, "home.community.title": { "message": "Entre na Comunidade", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Mais informações sobre o projeto Helm e como contribuir.", "description": "Join the Community subtitle" }, "home.about.whatIsHelm": { "message": "O Helm ajuda-o a gerir aplicações Kubernetes — os Helm Charts ajudam-no a definir, instalar e atualizar até as aplicações Kubernetes mais complexas.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Os Charts são fáceis de criar, versionar, partilhar e publicar — então comece a usar o Helm e pare de copiar e colar.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "O Helm é um projeto graduado na {cncfLink} e é mantido pela {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "comunidade Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Saber mais:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Arquitetura do Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Guia de Início Rápido", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Vídeo: Uma Introdução ao Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "O que é o Helm?", "description": "What is Helm? title" }, "home.features.manageComplexity": { "message": "Gerir Complexidade", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Os Charts descrevem até as aplicações mais complexas, fornecem instalação repetível de aplicações e servem como ponto único de autoridade.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Atualizações Fáceis", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Elimine a dor das atualizações com atualizações no local e hooks personalizados.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Partilha Simples", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Os Charts são fáceis de versionar, partilhar e hospedar em servidores públicos ou privados.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Reversões", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Use {helmRollback} para reverter facilmente para uma versão anterior de um lançamento.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Funcionalidades", "description": "Features section title" }, "home.header.tagline": { "message": "O gestor de pacotes para Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "O Helm é a melhor forma de encontrar, partilhar e usar software construído para", "description": "Home page header subtitle" }, "home.gettingStarted.title": { "message": "Começar", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Baixe o Helm!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Instale o Helm com um gestor de pacotes, ou {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "transfira um binário", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Depois de instalado, descompacte o binário helm, adicione-o ao seu PATH e está pronto! Consulte a {docsLink} para mais informações sobre {installationLink} e {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "documentação", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "instalação", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "instruções de utilização", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Baixe os Charts do Helm", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Visite {artifactHubLink} para explorar {helmChartsLink} de inúmeros repositórios públicos.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm charts", "description": "Helm charts link" }, "theme.ErrorPageContent.title": { "message": "Esta página deu erro.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Voltar para o topo", "description": "The ARIA label for the back to top button" }, "theme.blog.paginator.navAriaLabel": { "message": "Navegação da página de listagem do blog", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Publicações mais recentes", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Publicações mais antigas", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.archive.title": { "message": "Arquivo", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Arquivo", "description": "The page & hero description of the blog archive page" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Navegação da página de publicação do blog", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Publicação mais recente", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Publicação mais antiga", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Ver todas as etiquetas", "description": "The label of the link targeting the tag list page" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Trilha", "description": "The ARIA label for the breadcrumbs" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "modo do sistema", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "modo claro", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "modo escuro", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Mudar entre modo claro e escuro ({mode} está ativo)", "description": "The ARIA label for the color mode toggle" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "1 item|{count} itens", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Páginas de documento", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Anterior", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Próxima", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Um documento marcado|{count} documentos marcados", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} com \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "Versão: {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Esta é uma documentação não lançada da versão {versionLabel} para {siteTitle}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Esta é a documentação para {siteTitle} {versionLabel}, que não é mais mantida ativamente.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Para a documentação atualizada, consulte a {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "versão mais recente", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { "message": "Editar esta página", "description": "The link label to edit the current page" }, "theme.common.headingLinkTitle": { "message": "Link direto para {heading}", "description": "Title for link to heading" }, "theme.lastUpdated.atDate": { "message": " em {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " por {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Última atualização{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.NotFound.title": { "message": "Página não encontrada", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Versões", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Etiquetas:", "description": "The label alongside a tag list" }, "theme.admonition.caution": { "message": "cuidado", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "perigo", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "informação", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "observação", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "dica", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "aviso", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Fechar", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { "message": "Navegação das publicações recentes do blog", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Expandir a categoria '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Recolher a categoria '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(abre num novo separador)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Navegação principal", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "Não foi possível encontrar o que você está procurando.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Por favor, entre em contato com o dono do site que ligou você à URL original e informe que o link está quebrado.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Línguas", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Nesta página", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "Ler mais", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Ler mais sobre {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.CodeBlock.copy": { "message": "Copiar", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Copiado", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Copiar código para a área de transferência", "description": "The ARIA label for copy code blocks button" }, "theme.blog.post.readingTime.plurals": { "message": "Um minuto para ler|{readingTime} min para ler", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.wordWrapToggle": { "message": "Alternar quebra de linha", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Recolher painel lateral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Recolher painel lateral", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.breadcrumbs.home": { "message": "Página Inicial", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "Painel lateral de documentos", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Fechar painel de navegação", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Voltar para o menu principal", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Alternar painel de navegação", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Expandir a seleção", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Recolher a seleção", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Expandir painel lateral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Expandir painel lateral", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "Uma publicação|{count} publicações", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} com a etiqueta \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Autores", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Ver todos os autores", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Este autor ainda não escreveu nenhuma publicação.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Página não listada", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Esta página não está listada. Mecanismos de busca não irão indexá-la, e somente usuários que possuam o link direto poderão acessá-la", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Página de rascunho", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Esta página é um rascunho. Ela estará visível apenas no desenvolvimento e será excluída da compilação de produção.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Tentar novamente", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Pular para o conteúdo principal", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Etiquetas", "description": "The title of the tag list page" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Blog", "description": "The title for the blog used in SEO" }, "description": { "message": "Blog", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Todos os artigos", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Usando o Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandos do Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Desenvolvendo Templates", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Melhores Práticas", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Convenções Gerais description: Convenções gerais para charts. sidebar_position: 1 --- Esta parte do guia de boas práticas aborda convenções gerais. ## Nomes de Charts Os nomes de charts devem conter apenas letras minúsculas e números. Palavras _podem_ ser separadas com hífens (-): Exemplos: ``` drupal nginx-lego aws-cluster-autoscaler ``` Letras maiúsculas e underscores não podem ser usados em nomes de charts. Pontos também não devem ser usados. ## Números de Versão Sempre que possível, o Helm usa [SemVer 2](https://semver.org) para representar números de versão. (Note que tags de imagens Docker não seguem necessariamente o SemVer, sendo consideradas uma exceção infeliz à regra.) Quando versões SemVer são armazenadas em labels do Kubernetes, convencionalmente alteramos o caractere `+` para `_`, pois labels não permitem o sinal `+` como valor. ## Formatação YAML Arquivos YAML devem ser indentados usando _dois espaços_ (nunca tabs). ## Uso das Palavras Helm e Chart Existem algumas convenções para o uso das palavras _Helm_ e _helm_. - _Helm_ refere-se ao projeto como um todo - `helm` refere-se ao comando do lado do cliente - O termo `chart` não precisa ser capitalizado, pois não é um nome próprio - No entanto, `Chart.yaml` deve ser capitalizado porque o nome do arquivo é sensível a maiúsculas e minúsculas Em caso de dúvida, use _Helm_ (com 'H' maiúsculo). ## Chart templates e namespaces Evite definir a propriedade `namespace` na seção `metadata` dos seus templates de chart. O namespace a ser aplicado aos templates renderizados deve ser especificado na chamada ao cliente Kubernetes através de uma flag como `--namespace`. O Helm renderiza seus templates como estão e os envia ao cliente Kubernetes, seja o próprio Helm ou outro programa (kubectl, flux, spinnaker, etc). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Como criar e utilizar CRDs. sidebar_position: 7 --- Esta seção do guia de boas práticas aborda a criação e utilização de objetos Custom Resource Definition. Ao trabalhar com Custom Resource Definitions (CRDs), é importante distinguir duas partes diferentes: - Existe uma declaração de um CRD. Este é o arquivo YAML que tem kind `CustomResourceDefinition` - Depois existem recursos que _usam_ o CRD. Digamos que um CRD define `foo.example.com/v1`. Qualquer recurso que tenha `apiVersion: example.com/v1` e kind `Foo` é um recurso que usa o CRD. ## Instalar uma Declaração de CRD Antes de Usar o Recurso O Helm é otimizado para carregar o máximo de recursos possível no Kubernetes o mais rápido possível. Por design, o Kubernetes pode pegar um conjunto inteiro de manifests e colocá-los todos online (isso é chamado de loop de reconciliação). Mas há uma diferença com CRDs. Para um CRD, a declaração deve ser registrada antes que quaisquer recursos dos tipos do CRD possam ser usados. E o processo de registro às vezes leva alguns segundos. ### Método 1: Deixe o `helm` Fazer Por Você Com a chegada do Helm 3, removemos os antigos hooks `crd-install` por uma metodologia mais simples. Agora existe um diretório especial chamado `crds` que você pode criar no seu chart para armazenar seus CRDs. Esses CRDs não são templateados, mas serão instalados por padrão ao executar `helm install` para o chart. Se o CRD já existir, ele será ignorado com um aviso. Se você deseja pular a etapa de instalação de CRD, pode passar a flag `--skip-crds`. #### Algumas ressalvas (e explicações) No momento não há suporte para atualizar ou excluir CRDs usando o Helm. Esta foi uma decisão explícita após muita discussão na comunidade devido ao perigo de perda acidental de dados. Além disso, atualmente não há consenso na comunidade sobre como lidar com CRDs e seu ciclo de vida. À medida que isso evolui, o Helm adicionará suporte para esses casos de uso. A flag `--dry-run` de `helm install` e `helm upgrade` não é suportada atualmente para CRDs. O propósito do "Dry Run" é validar que a saída do chart realmente funcionará se enviada ao servidor. Mas CRDs são uma modificação do comportamento do servidor. O Helm não pode instalar o CRD em um dry run, então o cliente de discovery não saberá sobre aquele Custom Resource (CR), e a validação falhará. Como alternativa, você pode mover os CRDs para seu próprio chart ou usar `helm template` em vez disso. Outro ponto importante a considerar na discussão sobre suporte a CRD é como a renderização de templates é tratada. Uma das desvantagens distintas do método `crd-install` usado no Helm 2 era a incapacidade de validar charts corretamente devido à mudança na disponibilidade de API (um CRD está na verdade adicionando outra API disponível ao seu cluster Kubernetes). Se um chart instalava um CRD, o `helm` não tinha mais um conjunto válido de versões de API para trabalhar. Esta também é a razão para remover o suporte a templates dos CRDs. Com o novo método `crds` de instalação de CRD, agora garantimos que o `helm` tenha informações completamente válidas sobre o estado atual do cluster. ### Método 2: Charts Separados Outra forma de fazer isso é colocar a definição do CRD em um chart, e depois colocar quaisquer recursos que usam esse CRD em _outro_ chart. Neste método, cada chart deve ser instalado separadamente. No entanto, esse fluxo de trabalho pode ser mais útil para operadores de cluster que têm acesso de administrador a um cluster. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Dependências description: Aborda boas práticas para dependências declaradas no Chart. sidebar_position: 4 --- Esta seção do guia aborda boas práticas para `dependencies` declaradas no `Chart.yaml`. ## Versões Sempre que possível, use intervalos de versão em vez de fixar uma versão exata. O padrão sugerido é usar correspondência no nível de patch: ```yaml version: ~1.2.3 ``` Isso corresponderá à versão `1.2.3` e quaisquer patches dessa release. Em outras palavras, `~1.2.3` é equivalente a `>= 1.2.3, < 1.3.0` Para a sintaxe completa de correspondência de versão, consulte a [documentação do semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Versões de Pré-lançamento As restrições de versão acima não corresponderão a versões de pré-lançamento. Por exemplo, `version: ~1.2.3` corresponderá a `version: ~1.2.4`, mas não a `version: ~1.2.3-1`. O seguinte fornece correspondência tanto para pré-lançamento quanto para nível de patch: ```yaml version: ~1.2.3-0 ``` ### URLs de Repositório Sempre que possível, use URLs de repositório `https://`, seguidas por URLs `http://`. Se o repositório foi adicionado ao arquivo de índice de repositórios, o nome do repositório pode ser usado como alias da URL. Use `alias:` ou `@` seguido do nome do repositório. URLs de arquivo (`file://...`) são consideradas um "caso especial" para charts montados por um pipeline de deploy fixo. Ao usar [plugins de download](/topics/plugins.md#downloader-plugins), o esquema de URL será específico do plugin. Note que um usuário do chart precisará ter um plugin que suporte o esquema instalado para atualizar ou construir a dependência. O Helm não pode realizar operações de gerenciamento de dependências quando o campo `repository` é deixado em branco. Nesse caso, o Helm assumirá que a dependência está em um subdiretório da pasta `charts` com o nome sendo o mesmo da propriedade `name` da dependência. ## Condições e Tags Condições ou tags devem ser adicionadas a quaisquer dependências que _sejam opcionais_. Note que, por padrão, uma `condition` é `true`. A forma preferida de uma condição é: ```yaml condition: somechart.enabled ``` Onde `somechart` é o nome do chart da dependência. Quando múltiplos subcharts (dependências) juntos fornecem uma funcionalidade opcional ou substituível, esses charts devem compartilhar as mesmas tags. Por exemplo, se tanto `nginx` quanto `memcached` juntos fornecem otimizações de desempenho para a aplicação principal no chart, e ambos precisam estar presentes quando essa funcionalidade está habilitada, então ambos devem ter uma seção de tags assim: ```yaml tags: - webaccelerator ``` Isso permite que um usuário ative ou desative essa funcionalidade com uma única tag. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Labels e Annotations description: Aborda as boas práticas para o uso de labels e annotations no seu chart. sidebar_position: 5 --- Esta parte do guia de boas práticas discute o uso de labels e annotations no seu chart. ## É uma Label ou uma Annotation? Um item de metadados deve ser uma label nas seguintes condições: - É usado pelo Kubernetes para identificar este recurso - É útil expor aos operadores para fins de consulta ao sistema. Por exemplo, sugerimos usar `helm.sh/chart: NAME-VERSION` como uma label para que os operadores possam encontrar convenientemente todas as instâncias de um chart específico. Se um item de metadados não for usado para consultas, deve ser definido como uma annotation. Hooks do Helm são sempre annotations. ## Labels Padrão A tabela a seguir define labels comuns que os charts do Helm usam. O próprio Helm nunca exige que uma label específica esteja presente. Labels marcadas como REC são recomendadas e _devem_ ser incluídas em um chart para consistência global. As marcadas como OPT são opcionais. Estas são idiomáticas ou comumente usadas, mas não são frequentemente utilizadas para fins operacionais. | Nome | Status | Descrição | |------|--------|-----------| | `app.kubernetes.io/name` | REC | Deve ser o nome da aplicação, refletindo a aplicação como um todo. Geralmente usa-se `{{ template "name" . }}` para isso. É usado por muitos manifestos Kubernetes e não é específico do Helm. | | `helm.sh/chart` | REC | Deve ser o nome e a versão do chart: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | | `app.kubernetes.io/managed-by` | REC | Deve sempre ser definido como `{{ .Release.Service }}`. Serve para encontrar tudo que é gerenciado pelo Helm. | | `app.kubernetes.io/instance` | REC | Deve ser o `{{ .Release.Name }}`. Ajuda a diferenciar entre diferentes instâncias da mesma aplicação. | | `app.kubernetes.io/version` | OPT | A versão da aplicação, podendo ser definida como `{{ .Chart.AppVersion }}`. | | `app.kubernetes.io/component` | OPT | Uma label comum para marcar os diferentes papéis que os componentes podem ter em uma aplicação. Por exemplo, `app.kubernetes.io/component: frontend`. | | `app.kubernetes.io/part-of` | OPT | Quando múltiplos charts ou componentes de software são usados juntos para criar uma aplicação. Por exemplo, software de aplicação e um banco de dados para produzir um website. Pode ser definido como a aplicação principal que está sendo suportada. | Você pode encontrar mais informações sobre as labels do Kubernetes, prefixadas com `app.kubernetes.io`, na [documentação do Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods e PodTemplates description: Discute a formatação das seções Pod e PodTemplate nos manifestos de charts. sidebar_position: 6 --- Esta parte do guia de boas práticas discute a formatação das seções Pod e PodTemplate nos manifestos de charts. A seguinte lista (não exaustiva) de recursos utiliza PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Imagens Uma imagem de container deve usar uma tag fixa ou o SHA da imagem. Não deve usar as tags `latest`, `head`, `canary`, ou outras tags flutuantes. Imagens _podem_ ser definidas no arquivo `values.yaml` para facilitar a troca de imagens. ```yaml image: {{ .Values.redisImage | quote }} ``` Uma imagem e uma tag _podem_ ser definidas no `values.yaml` como dois campos separados: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` define a `imagePullPolicy` como `IfNotPresent` por padrão, fazendo o seguinte no seu `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` E no `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Da mesma forma, o Kubernetes assume por padrão a `imagePullPolicy` como `IfNotPresent` se ela não for definida. Se você quiser um valor diferente de `IfNotPresent`, simplesmente atualize o valor em `values.yaml` para o valor desejado. ## PodTemplates Devem Declarar Selectors Todas as seções de PodTemplate devem especificar um selector. Por exemplo: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Esta é uma boa prática porque torna explícita a relação entre o conjunto de workload e o pod. Mas isto é ainda mais importante para conjuntos como Deployment. Sem isso, o conjunto _inteiro_ de labels é usado para selecionar pods correspondentes, e isso pode falhar se você usar labels que mudam, como versão ou data de lançamento. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Controle de Acesso Baseado em Funções description: Discute a criação e formatação de recursos RBAC em manifestos de Chart. sidebar_position: 8 --- Esta parte do guia de boas práticas discute a criação e formatação de recursos RBAC em manifestos de chart. Os recursos RBAC são: - ServiceAccount (com namespace) - Role (com namespace) - ClusterRole - RoleBinding (com namespace) - ClusterRoleBinding ## Configuração YAML A configuração de RBAC e ServiceAccount deve ser feita em chaves separadas. São conceitos distintos. Separá-los no YAML deixa essa distinção mais clara. ```yaml rbac: # Especifica se os recursos RBAC devem ser criados create: true serviceAccount: # Especifica se uma ServiceAccount deve ser criada create: true # O nome da ServiceAccount a ser usada. # Se não definido e create for true, um nome é gerado usando o template fullname name: ``` Esta estrutura pode ser estendida para charts mais complexos que requerem múltiplas ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Recursos RBAC Devem Ser Criados por Padrão `rbac.create` deve ser um valor booleano que controla se os recursos RBAC são criados. O padrão deve ser `true`. Usuários que desejam gerenciar os controles de acesso RBAC por conta própria podem definir este valor como `false` (nesse caso, veja abaixo). ## Usando Recursos RBAC `serviceAccount.name` deve ser definido como o nome da ServiceAccount a ser usada pelos recursos com controle de acesso criados pelo chart. Se `serviceAccount.create` for true, então uma ServiceAccount com este nome deve ser criada. Se o nome não for definido, então um nome é gerado usando o template `fullname`. Se `serviceAccount.create` for false, então ela não deve ser criada, mas ainda deve ser associada aos mesmos recursos para que recursos RBAC criados manualmente posteriormente que a referenciem funcionem corretamente. Se `serviceAccount.create` for false e o nome não for especificado, então a ServiceAccount padrão é usada. O seguinte template auxiliar deve ser usado para a ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Templates description: Uma visão mais detalhada das boas práticas relacionadas a templates. sidebar_position: 3 --- Esta parte do guia de boas práticas foca em templates. ## Estrutura de `templates/` O diretório `templates/` deve ser estruturado da seguinte forma: - Arquivos de template devem ter a extensão `.yaml` se produzirem saída YAML. A extensão `.tpl` pode ser usada para arquivos de template que não produzem conteúdo formatado. - Nomes de arquivos de template devem usar notação com hífens (`my-example-configmap.yaml`), não camelCase. - Cada definição de recurso deve estar em seu próprio arquivo de template. - Nomes de arquivos de template devem refletir o tipo de recurso no nome. Ex.: `foo-pod.yaml`, `bar-svc.yaml` ## Nomes de Templates Definidos Templates definidos (templates criados dentro de uma diretiva `{{ define }}`) são globalmente acessíveis. Isso significa que um chart e todos os seus subcharts terão acesso a todos os templates criados com `{{ define }}`. Por esse motivo, _todos os nomes de templates definidos devem usar namespace._ Correto: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorreto: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` É altamente recomendado que novos charts sejam criados através do comando `helm create`, pois os nomes dos templates são automaticamente definidos de acordo com esta boa prática. ## Formatação de Templates Templates devem ser indentados usando _dois espaços_ (nunca tabs). As diretivas de template devem ter espaço em branco após as chaves de abertura e antes das chaves de fechamento: Correto: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorreto: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Templates devem suprimir espaços em branco quando possível: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Blocos (como estruturas de controle) podem ser indentados para indicar o fluxo do código do template. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` No entanto, como YAML é uma linguagem orientada a espaços em branco, nem sempre é possível que a indentação do código siga essa convenção. ## Espaços em Branco nos Templates Gerados É preferível manter a quantidade de espaços em branco nos templates gerados no mínimo. Em particular, várias linhas em branco não devem aparecer adjacentes umas às outras. Porém, linhas vazias ocasionais (particularmente entre seções lógicas) são aceitáveis. Ideal: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Aceitável: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Mas isto deve ser evitado: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Comentários (Comentários YAML vs. Comentários de Template) Tanto YAML quanto Helm Templates possuem marcadores de comentário. Comentários YAML: ```yaml # This is a comment type: sprocket ``` Comentários de Template: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` Comentários de template devem ser usados ao documentar funcionalidades de um template, como explicar um template definido: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Dentro dos templates, comentários YAML podem ser usados quando for útil para os usuários do Helm (possivelmente) verem os comentários durante a depuração. ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` O comentário acima é visível quando o usuário executa `helm install --debug`, enquanto comentários especificados em seções `{{- /* */}}` não são. Tenha cuidado ao adicionar comentários YAML `#` em seções de template que contêm values do Helm que podem ser exigidos por certas funções de template. Por exemplo, se a função `required` for introduzida no exemplo acima, e `maxMem` não estiver definido, então um comentário YAML `#` introduzirá um erro de renderização. Correto: `helm template` não renderiza este bloco ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Incorreto: `helm template` retorna `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Consulte [Depuração de Templates](../chart_template_guide/debugging.md) para outro exemplo deste comportamento de como comentários YAML são mantidos intactos. ## Uso de JSON em Templates e Saída de Template YAML é um superconjunto de JSON. Em alguns casos, usar uma sintaxe JSON pode ser mais legível do que outras representações YAML. Por exemplo, este YAML está mais próximo do método normal de YAML para expressar listas: ```yaml arguments: - "--dirname" - "/foo" ``` Mas é mais fácil de ler quando colapsado em estilo de lista JSON: ```yaml arguments: ["--dirname", "/foo"] ``` Usar JSON para maior legibilidade é bom. No entanto, a sintaxe JSON não deve ser usada para representar construções mais complexas. Ao lidar com JSON puro incorporado dentro de YAML (como configuração de init container), é claro que é apropriado usar o formato JSON. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Foca em como você deve estruturar e usar seus values. sidebar_position: 2 --- Esta parte do guia de boas práticas aborda o uso de values. Nesta parte do guia, fornecemos recomendações sobre como você deve estruturar e usar seus values, com foco no design do arquivo `values.yaml` do chart. ## Convenções de Nomenclatura Os nomes das variáveis devem começar com uma letra minúscula, e as palavras devem ser separadas com camelCase: Correto: ```yaml chicken: true chickenNoodleSoup: true ``` Incorreto: ```yaml Chicken: true # letras maiúsculas iniciais podem conflitar com variáveis internas chicken-noodle-soup: true # não use hífens no nome ``` Note que todas as variáveis internas do Helm começam com uma letra maiúscula para facilitar a distinção das variáveis definidas pelo usuário: `.Release.Name`, `.Capabilities.KubeVersion`. ## Values Planos ou Aninhados YAML é um formato flexível, e os values podem ser profundamente aninhados ou planos. Aninhado: ```yaml server: name: nginx port: 80 ``` Plano: ```yaml serverName: nginx serverPort: 80 ``` Na maioria dos casos, prefira o formato plano ao aninhado. O motivo é que ele é mais simples tanto para desenvolvedores de templates quanto para usuários. Para segurança ideal, um valor aninhado deve ser verificado em cada nível: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Para cada camada de aninhamento, uma verificação de existência deve ser feita. Mas para configuração plana, tais verificações podem ser ignoradas, tornando o template mais fácil de ler e usar. ``` {{ default "none" .Values.serverName }} ``` Quando há um grande número de variáveis relacionadas, e pelo menos uma delas é obrigatória, values aninhados podem ser usados para melhorar a legibilidade. ## Seja Claro com os Tipos As regras de conversão de tipos do YAML às vezes são contraintuitivas. Por exemplo, `foo: false` não é o mesmo que `foo: "false"`. Inteiros grandes como `foo: 12345678` serão convertidos para notação científica em alguns casos. A maneira mais fácil de evitar erros de conversão de tipo é ser explícito sobre strings e implícito sobre todo o resto. Ou, em resumo, _coloque aspas em todas as strings_. Frequentemente, para evitar problemas de conversão de inteiros, é vantajoso armazenar seus inteiros como strings também, e usar `{{ int $value }}` no template para converter de uma string de volta para um inteiro. Na maioria dos casos, tags de tipo explícitas são respeitadas, então `foo: !!string 1234` deve tratar `1234` como uma string. _No entanto_, o parser YAML consome as tags, então os dados de tipo são perdidos após um parse. ## Considere Como os Usuários Usarão Seus Values Existem três fontes potenciais de values: - O arquivo `values.yaml` do chart - Um arquivo de values fornecido por `helm install -f` ou `helm upgrade -f` - Os values passados para a flag `--set` ou `--set-string` no `helm install` ou `helm upgrade` Ao projetar a estrutura dos seus values, tenha em mente que os usuários do seu chart podem querer sobrescrevê-los via flag `-f` ou com a opção `--set`. Como `--set` é mais limitado em expressividade, a primeira diretriz para escrever seu arquivo `values.yaml` é _facilitar a sobrescrita via `--set`_. Por essa razão, geralmente é melhor estruturar seu arquivo de values usando maps. Difícil de usar com `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` O exemplo acima não pode ser expresso com `--set` no Helm `<=2.4`. No Helm 2.5, acessar a porta em foo é `--set servers[0].port=80`. Não apenas é mais difícil para o usuário descobrir, mas também é propenso a erros se em algum momento futuro a ordem dos `servers` for alterada. Fácil de usar: ```yaml servers: foo: port: 80 bar: port: 81 ``` Acessar a porta de foo é muito mais óbvio: `--set servers.foo.port=80`. ## Documente o `values.yaml` Cada propriedade definida no `values.yaml` deve ser documentada. A string de documentação deve começar com o nome da propriedade que ela descreve e depois fornecer pelo menos uma descrição de uma frase. Incorreto: ```yaml # o nome do host para o servidor web serverHost: example serverPort: 9191 ``` Correto: ```yaml # serverHost é o nome do host para o servidor web serverHost: example # serverPort é a porta do listener HTTP para o servidor web serverPort: 9191 ``` Começar cada comentário com o nome do parâmetro que ele documenta facilita a busca por documentação com grep, e permitirá que ferramentas de documentação correlacionem de forma confiável as strings de documentação com os parâmetros que elas descrevem. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Acessando Arquivos Dentro de Templates description: Como acessar arquivos de dentro de um template. sidebar_position: 10 --- Na seção anterior, vimos várias maneiras de criar e acessar templates nomeados. Isso facilita a importação de um template de dentro de outro template. Mas às vezes é desejável importar um _arquivo que não é um template_ e injetar seu conteúdo sem enviá-lo pelo renderizador de templates. O Helm fornece acesso a arquivos através do objeto `.Files`. Antes de começarmos com os exemplos de templates, porém, há algumas coisas a observar sobre como isso funciona: - É permitido adicionar arquivos extras ao seu chart do Helm. Esses arquivos serão empacotados. Mas tenha cuidado. Charts devem ter menos de 1M devido às limitações de armazenamento dos objetos do Kubernetes. - Alguns arquivos não podem ser acessados através do objeto `.Files`, geralmente por razões de segurança. - Arquivos em `templates/` não podem ser acessados. - Arquivos excluídos usando `.helmignore` não podem ser acessados. - Arquivos fora de um [subchart](./subcharts_and_globals.md) de uma aplicação Helm, incluindo os do chart pai, não podem ser acessados - Charts não preservam informações de modo UNIX, portanto as permissões a nível de arquivo não terão impacto na disponibilidade de um arquivo quando se trata do objeto `.Files`. - [Exemplo básico](#exemplo-básico) - [Helpers de caminho](#helpers-de-caminho) - [Padrões glob](#padrões-glob) - [Funções utilitárias para ConfigMap e Secrets](#funções-utilitárias-para-configmap-e-secrets) - [Codificação](#codificação) - [Linhas](#linhas) ## Exemplo básico Com essas ressalvas em mente, vamos escrever um template que lê três arquivos em nosso ConfigMap. Para começar, adicionaremos três arquivos ao chart, colocando os três diretamente dentro do diretório `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Cada um destes é um arquivo TOML simples (pense nos arquivos INI do Windows antigo). Sabemos os nomes desses arquivos, então podemos usar uma função `range` para iterar sobre eles e injetar seu conteúdo em nosso ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Este ConfigMap usa várias das técnicas discutidas nas seções anteriores. Por exemplo, criamos uma variável `$files` para manter uma referência ao objeto `.Files`. Também usamos a função `tuple` para criar uma lista de arquivos pela qual iteramos. Então imprimimos cada nome de arquivo (`{{ . }}: |-`) seguido pelo conteúdo do arquivo `{{ $files.Get . }}`. Executar este template produzirá um único ConfigMap com o conteúdo de todos os três arquivos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Helpers de caminho Ao trabalhar com arquivos, pode ser muito útil realizar algumas operações padrão nos próprios caminhos dos arquivos. Para ajudar com isso, o Helm importa muitas das funções do pacote [path](https://golang.org/pkg/path/) do Go para seu uso. Elas são todas acessíveis com os mesmos nomes do pacote Go, mas com a primeira letra em minúsculo. Por exemplo, `Base` se torna `base`, etc. As funções importadas são: - Base - Dir - Ext - IsAbs - Clean ## Padrões glob À medida que seu chart cresce, você pode descobrir que tem uma necessidade maior de organizar seus arquivos, e por isso fornecemos um método `Files.Glob(pattern string)` para ajudar a extrair certos arquivos com toda a flexibilidade dos [padrões glob](https://godoc.org/github.com/gobwas/glob). `.Glob` retorna um tipo `Files`, então você pode chamar qualquer um dos métodos `Files` no objeto retornado. Por exemplo, imagine a estrutura de diretórios: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` Você tem múltiplas opções com Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Ou ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Funções utilitárias para ConfigMap e Secrets (Disponível no Helm 2.0.2 e posteriores) É muito comum querer colocar conteúdo de arquivos tanto em ConfigMaps quanto em Secrets, para montá-los em seus pods em tempo de execução. Para ajudar com isso, fornecemos alguns métodos utilitários no tipo `Files`. Para maior organização, é especialmente útil usar esses métodos em conjunto com o método `Glob`. Dada a estrutura de diretórios do exemplo [Glob](#padrões-glob) acima: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Codificação Você pode importar um arquivo e fazer o template codificá-lo em base-64 para garantir uma transmissão bem-sucedida: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` O exemplo acima pegará o mesmo arquivo `config1.toml` que usamos antes e o codificará: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Linhas Às vezes é desejável acessar cada linha de um arquivo em seu template. Fornecemos um método conveniente `Lines` para isso. Você pode percorrer `Lines` usando uma função `range`: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Não há como passar arquivos externos ao chart durante `helm install`. Portanto, se você está pedindo aos usuários que forneçam dados, eles devem ser carregados usando `helm install -f` ou `helm install --set`. Esta discussão encerra nosso aprofundamento nas ferramentas e técnicas para escrever templates do Helm. Na próxima seção, veremos como você pode usar um arquivo especial, `templates/NOTES.txt`, para enviar instruções pós-instalação aos usuários do seu chart. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Objetos Embutidos description: Objetos embutidos disponíveis para templates. sidebar_position: 3 --- Objetos são passados para um template pelo motor de templates. Seu código também pode passar objetos adiante (veremos exemplos quando analisarmos as instruções `with` e `range`). Existem até algumas formas de criar novos objetos dentro dos seus templates, como com a função `tuple` que veremos mais adiante. Objetos podem ser simples e ter apenas um valor. Ou podem conter outros objetos ou funções. Por exemplo, o objeto `Release` contém vários objetos (como `Release.Name`) e o objeto `Files` possui algumas funções. Na seção anterior, usamos `{{ .Release.Name }}` para inserir o nome de um release em um template. `Release` é um dos objetos de nível superior que você pode acessar nos seus templates. - `Release`: Este objeto descreve o próprio release. Ele contém vários objetos: - `Release.Name`: O nome do release - `Release.Namespace`: O namespace no qual o release será instalado (se o manifesto não sobrescrever) - `Release.IsUpgrade`: Este valor é definido como `true` se a operação atual for um upgrade ou rollback. - `Release.IsInstall`: Este valor é definido como `true` se a operação atual for uma instalação. - `Release.Revision`: O número de revisão deste release. Na instalação, este valor é 1, e é incrementado a cada upgrade e rollback. - `Release.Service`: O serviço que está renderizando o template atual. No Helm, este valor é sempre `Helm`. - `Values`: Valores passados para o template a partir do arquivo `values.yaml` e de arquivos fornecidos pelo usuário. Por padrão, `Values` está vazio. - `Chart`: O conteúdo do arquivo `Chart.yaml`. Qualquer dado em `Chart.yaml` estará acessível aqui. Por exemplo, `{{ .Chart.Name }}-{{ .Chart.Version }}` exibirá `mychart-0.1.0`. - Os campos disponíveis estão listados no [Guia de Charts](/topics/charts.md#the-chartyaml-file) - `Subcharts`: Fornece acesso ao escopo (.Values, .Charts, .Releases etc.) dos subcharts para o chart pai. Por exemplo, `.Subcharts.mySubChart.myValue` para acessar o valor `myValue` no chart `mySubChart`. - `Files`: Fornece acesso a todos os arquivos não especiais em um chart. Embora você não possa usá-lo para acessar templates, pode usá-lo para acessar outros arquivos no chart. Consulte a seção [Acessando Arquivos](/chart_template_guide/accessing_files.md) para mais informações. - `Files.Get` é uma função para obter um arquivo pelo nome (`.Files.Get config.ini`) - `Files.GetBytes` é uma função para obter o conteúdo de um arquivo como um array de bytes em vez de uma string. Isso é útil para coisas como imagens. - `Files.Glob` é uma função que retorna uma lista de arquivos cujos nomes correspondem ao padrão glob fornecido. - `Files.Lines` é uma função que lê um arquivo linha por linha. Isso é útil para iterar sobre cada linha de um arquivo. - `Files.AsSecrets` é uma função que retorna o conteúdo dos arquivos como strings codificadas em Base 64. - `Files.AsConfig` é uma função que retorna o conteúdo dos arquivos como um mapa YAML. - `Capabilities`: Fornece informações sobre as capacidades que o cluster Kubernetes suporta. - `Capabilities.APIVersions` é um conjunto de versões. - `Capabilities.APIVersions.Has $version` indica se uma versão (por exemplo, `batch/v1`) ou recurso (por exemplo, `apps/v1/Deployment`) está disponível no cluster. - `Capabilities.KubeVersion` e `Capabilities.KubeVersion.Version` é a versão do Kubernetes. - `Capabilities.KubeVersion.Major` é a versão major do Kubernetes. - `Capabilities.KubeVersion.Minor` é a versão minor do Kubernetes. - `Capabilities.HelmVersion` é o objeto que contém os detalhes da versão do Helm, o mesmo resultado de `helm version`. - `Capabilities.HelmVersion.Version` é a versão atual do Helm no formato semver. - `Capabilities.HelmVersion.GitCommit` é o sha1 do git do Helm. - `Capabilities.HelmVersion.GitTreeState` é o estado da árvore git do Helm. - `Capabilities.HelmVersion.GoVersion` é a versão do compilador Go utilizado. - `Template`: Contém informações sobre o template atual que está sendo executado - `Template.Name`: Um caminho de arquivo com namespace para o template atual (por exemplo, `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: O caminho com namespace para o diretório de templates do chart atual (por exemplo, `mychart/templates`). Os valores embutidos sempre começam com letra maiúscula. Isso segue a convenção de nomenclatura do Go. Quando você cria seus próprios nomes, você é livre para usar uma convenção que se adeque à sua equipe. Algumas equipes, como muitas cujos charts você pode ver no [Artifact Hub](https://artifacthub.io/packages/search?kind=0), escolhem usar apenas letras minúsculas iniciais para distinguir nomes locais daqueles embutidos. Neste guia, seguimos essa convenção. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Controle de Fluxo description: Uma visão rápida sobre a estrutura de fluxo dentro dos templates. sidebar_position: 7 --- Estruturas de controle (chamadas de "actions" na terminologia de templates) fornecem a você, o autor do template, a capacidade de controlar o fluxo de geração de um template. A linguagem de template do Helm oferece as seguintes estruturas de controle: - `if`/`else` para criar blocos condicionais - `with` para especificar um escopo - `range`, que fornece um loop no estilo "for each" Além destas, ela fornece algumas actions para declarar e usar segmentos de template nomeados: - `define` declara um novo template nomeado dentro do seu template - `template` importa um template nomeado - `block` declara um tipo especial de área de template preenchível Nesta seção, falaremos sobre `if`, `with` e `range`. Os outros são abordados na seção "Templates Nomeados" mais adiante neste guia. ## If/Else A primeira estrutura de controle que veremos é para incluir condicionalmente blocos de texto em um template. Este é o bloco `if`/`else`. A estrutura básica de uma condicional é assim: ``` {{ if PIPELINE }} # Faça algo {{ else if OTHER PIPELINE }} # Faça outra coisa {{ else }} # Caso padrão {{ end }} ``` Note que agora estamos falando sobre _pipelines_ em vez de valores. O motivo é deixar claro que estruturas de controle podem executar um pipeline inteiro, não apenas avaliar um valor. Um pipeline é avaliado como _false_ se o valor for: - um booleano false - um zero numérico - uma string vazia - um `nil` (vazio ou nulo) - uma coleção vazia (`map`, `slice`, `tuple`, `dict`, `array`) Em todas as outras condições, a condição é verdadeira. Vamos adicionar uma condicional simples ao nosso ConfigMap. Adicionaremos outra configuração se a bebida estiver definida como coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Como comentamos `drink: coffee` no nosso último exemplo, a saída não deve incluir a flag `mug: "true"`. Mas se adicionarmos essa linha de volta ao nosso arquivo `values.yaml`, a saída deve ficar assim: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Controlando Espaços em Branco Enquanto olhamos para condicionais, devemos dar uma olhada rápida na forma como os espaços em branco são controlados em templates. Vamos pegar o exemplo anterior e formatá-lo para ser um pouco mais fácil de ler: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Inicialmente, isso parece bom. Mas se passarmos pelo motor de template, teremos um resultado infeliz: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` O que aconteceu? Geramos YAML incorreto por causa dos espaços em branco acima. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` está indentado incorretamente. Vamos apenas remover a indentação dessa linha e executar novamente: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Quando enviarmos isso, obteremos um YAML que é válido, mas ainda parece um pouco estranho: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Note que recebemos algumas linhas vazias no nosso YAML. Por quê? Quando o motor de template executa, ele _remove_ o conteúdo dentro de `{{` e `}}`, mas deixa os espaços em branco restantes exatamente como estão. O YAML atribui significado aos espaços em branco, então gerenciar os espaços em branco se torna bastante importante. Felizmente, os templates do Helm têm algumas ferramentas para ajudar. Primeiro, a sintaxe de chaves das declarações de template pode ser modificada com caracteres especiais para instruir o motor de template a consumir espaços em branco. `{{- ` (com o hífen e espaço adicionados) indica que os espaços em branco à esquerda devem ser consumidos, enquanto ` -}}` significa que os espaços em branco à direita devem ser consumidos. _Cuidado! Quebras de linha são espaços em branco!_ > Certifique-se de que há um espaço entre o `-` e o resto da sua diretiva. > `{{- 3 }}` significa "remover espaços à esquerda e imprimir 3" enquanto > `{{-3 }}` significa "imprimir -3". Usando essa sintaxe, podemos modificar nosso template para eliminar essas novas linhas: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Apenas para deixar esse ponto claro, vamos ajustar o texto acima e substituir um `*` para cada espaço em branco que será removido seguindo esta regra. Um `*` no final da linha indica um caractere de nova linha que seria removido ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Tendo isso em mente, podemos executar nosso template através do Helm e ver o resultado: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Tenha cuidado com os modificadores de remoção de espaços. É fácil acidentalmente fazer coisas assim: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Isso produzirá `food: "PIZZA"mug: "true"` porque consumiu as novas linhas em ambos os lados. > Para detalhes sobre controle de espaços em branco em templates, veja a > [documentação oficial de templates do Go](https://godoc.org/text/template) Finalmente, às vezes é mais fácil dizer ao sistema de templates como indentar para você em vez de tentar dominar o espaçamento das diretivas de template. Por essa razão, você pode às vezes achar útil usar a função `indent` (`{{ indent 2 "mug:true" }}`). ## Modificando o Escopo com `with` A próxima estrutura de controle a ser analisada é a action `with`. Ela controla o escopo de variáveis. Lembre-se de que `.` é uma referência ao _escopo atual_. Então `.Values` diz ao template para encontrar o objeto `Values` no escopo atual. A sintaxe do `with` é similar a uma instrução `if` simples: ``` {{ with PIPELINE }} # escopo restrito {{ end }} ``` Escopos podem ser alterados. `with` permite que você defina o escopo atual (`.`) para um objeto específico. Por exemplo, estivemos trabalhando com `.Values.favorite`. Vamos reescrever nosso ConfigMap para alterar o escopo de `.` para apontar para `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Note que removemos a condicional `if` do exercício anterior porque agora ela é desnecessária - o bloco após `with` só é executado se o valor de `PIPELINE` não for vazio. Observe que agora podemos referenciar `.drink` e `.food` sem qualificá-los. Isso porque a instrução `with` define `.` para apontar para `.Values.favorite`. O `.` é redefinido para seu escopo anterior após `{{ end }}`. Mas aqui vai uma nota de cautela! Dentro do escopo restrito, você não poderá acessar os outros objetos do escopo pai usando `.`. Por exemplo, isso falhará: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Isso produzirá um erro porque `Release.Name` não está dentro do escopo restrito de `.`. No entanto, se trocarmos as duas últimas linhas, tudo funcionará como esperado porque o escopo é redefinido após `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Ou, podemos usar `$` para acessar o objeto `Release.Name` do escopo pai. `$` é mapeado para o escopo raiz quando a execução do template começa e não muda durante a execução do template. O seguinte também funcionaria: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Depois de ver `range`, daremos uma olhada nas variáveis de template, que oferecem uma solução para o problema de escopo acima. ## Iterando com a Action `range` Muitas linguagens de programação têm suporte para iteração usando loops `for`, loops `foreach` ou mecanismos funcionais similares. Na linguagem de template do Helm, a forma de iterar através de uma coleção é usar o operador `range`. Para começar, vamos adicionar uma lista de coberturas de pizza ao nosso arquivo `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Agora temos uma lista (chamada de `slice` em templates) de `pizzaToppings`. Podemos modificar nosso template para imprimir essa lista no nosso ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Podemos usar `$` para acessar a lista `Values.pizzaToppings` do escopo pai. `$` é mapeado para o escopo raiz quando a execução do template começa e não muda durante a execução do template. O seguinte também funcionaria: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Vamos olhar mais de perto a lista `toppings:`. A função `range` irá "iterar sobre" (percorrer) a lista `pizzaToppings`. Mas agora algo interessante acontece. Assim como `with` define o escopo de `.`, um operador `range` também faz isso. Cada vez que passa pelo loop, `.` é definido para a cobertura de pizza atual. Ou seja, na primeira vez, `.` é definido como `mushrooms`. Na segunda iteração, é definido como `cheese`, e assim por diante. Podemos enviar o valor de `.` diretamente para um pipeline, então quando fazemos `{{ . | title | quote }}`, ele envia `.` para `title` (função que coloca em título) e depois para `quote`. Se executarmos esse template, a saída será: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Agora, neste exemplo fizemos algo astuto. A linha `toppings: |-` está declarando uma string de múltiplas linhas. Então nossa lista de coberturas na verdade não é uma lista YAML. É uma grande string. Por que faríamos isso? Porque os dados em `data` de ConfigMaps são compostos de pares chave/valor, onde tanto a chave quanto o valor são strings simples. Para entender por que é assim, dê uma olhada na [documentação de ConfigMap do Kubernetes](https://kubernetes.io/docs/concepts/configuration/configmap/). Para nós, porém, esse detalhe não importa muito. > O marcador `|-` no YAML recebe uma string de múltiplas linhas. Essa pode ser > uma técnica útil para incorporar grandes blocos de dados dentro dos seus > manifests, como exemplificado aqui. Às vezes é útil poder criar rapidamente uma lista dentro do seu template, e depois iterar sobre essa lista. Os templates do Helm têm uma função para facilitar isso: `tuple`. Em ciência da computação, uma tupla é uma coleção semelhante a uma lista de tamanho fixo, mas com tipos de dados arbitrários. Isso transmite aproximadamente a forma como um `tuple` é usado. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` O código acima produzirá isso: ```yaml sizes: |- - small - medium - large ``` Além de listas e tuplas, `range` pode ser usado para iterar sobre coleções que têm uma chave e um valor (como um `map` ou `dict`). Veremos como fazer isso na próxima seção quando introduzirmos variáveis de template. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Apêndice: Tipos de Dados Go e Templates" description: Uma visão geral rápida sobre variáveis em templates. sidebar_position: 16 --- A linguagem de templates do Helm é implementada na linguagem de programação Go, que é fortemente tipada. Por isso, variáveis em templates são _tipadas_. Na maior parte dos casos, as variáveis serão expostas como um dos seguintes tipos: - string: Uma cadeia de texto - bool: `true` ou `false` - int: Um valor inteiro (há também variantes de 8, 16, 32 e 64 bits, com sinal e sem sinal) - float64: Um valor de ponto flutuante de 64 bits (há também variantes de 8, 16 e 32 bits) - um slice de bytes (`[]byte`), frequentemente usado para armazenar dados (potencialmente) binários - struct: um objeto com propriedades e métodos - um slice (lista indexada) de um dos tipos anteriores - um map com chaves string (`map[string]interface{}`) onde o valor é um dos tipos anteriores Existem muitos outros tipos em Go, e às vezes você precisará converter entre eles nos seus templates. A forma mais fácil de identificar o tipo de um objeto é usar `printf "%T"` em um template, que exibirá o tipo. Veja também as funções `typeOf` e `kindOf`. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Depurando Templates description: Solucionando problemas em charts que falham ao fazer deploy. sidebar_position: 13 --- Depurar templates pode ser complicado porque os templates renderizados são enviados para o servidor da API do Kubernetes, que pode rejeitar os arquivos YAML por razões além de formatação. Existem alguns comandos que podem ajudar você a depurar. - `helm lint` é sua ferramenta principal para verificar se seu chart segue as melhores práticas - `helm template --debug` testa a renderização dos templates do chart localmente. - `helm install --dry-run --debug` também renderiza seu chart localmente sem instalá-lo, mas também verifica se recursos conflitantes já estão em execução no cluster. Configurar `--dry-run=server` também executará qualquer `lookup` no seu chart contra o servidor. - `helm get manifest`: Esta é uma boa maneira de ver quais templates estão instalados no servidor. Quando seu YAML falha ao ser analisado, mas você quer ver o que é gerado, uma maneira fácil de obter o YAML é comentar a seção problemática no template e então executar novamente `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` O exemplo acima será renderizado e retornado com os comentários intactos: ```yaml apiVersion: v2 # some: problem section # "bar" ``` Isso fornece uma maneira rápida de visualizar o conteúdo gerado sem que erros de análise YAML bloqueiem o processo. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Lista de Funções de Template description: Uma lista de funções de template disponíveis no Helm sidebar_position: 6 --- O Helm inclui muitas funções de template que você pode utilizar em seus templates. Elas estão listadas aqui e organizadas nas seguintes categorias: * [Criptográficas e de Segurança](#funções-criptográficas-e-de-segurança) * [Data](#funções-de-data) * [Dicionários](#funções-de-dicionário-e-dict) * [Codificação](#funções-de-codificação) * [Caminhos de Arquivo](#funções-de-caminho-de-arquivo) * [Kubernetes e Chart](#funções-de-kubernetes-e-chart) * [Lógica e Controle de Fluxo](#funções-de-lógica-e-controle-de-fluxo) * [Listas](#funções-de-lista-e-list) * [Matemática](#funções-matemáticas) * [Matemática com Float](#funções-matemáticas-com-float) * [Rede](#funções-de-rede) * [Reflexão](#funções-de-reflexão) * [Expressões Regulares](#expressões-regulares) * [Versões Semânticas](#funções-de-versão-semântica) * [String](#funções-de-string) * [Conversão de Tipos](#funções-de-conversão-de-tipos) * [URL](#funções-de-url) * [UUID](#funções-de-uuid) ## Funções de Lógica e Controle de Fluxo O Helm inclui diversas funções de lógica e controle de fluxo, incluindo [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) e [required](#required). ### and Retorna o AND booleano de dois ou mais argumentos (o primeiro argumento vazio, ou o último argumento). ``` and .Arg1 .Arg2 ``` ### or Retorna o OR booleano de dois ou mais argumentos (o primeiro argumento não vazio, ou o último argumento). ``` or .Arg1 .Arg2 ``` ### not Retorna a negação booleana do seu argumento. ``` not .Arg ``` ### eq Retorna a igualdade booleana dos argumentos (ex.: Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Retorna a desigualdade booleana dos argumentos (ex.: Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Retorna verdadeiro se o primeiro argumento for menor que o segundo. Caso contrário, retorna falso (ex.: Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Retorna verdadeiro se o primeiro argumento for menor ou igual ao segundo. Caso contrário, retorna falso (ex.: Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Retorna verdadeiro se o primeiro argumento for maior que o segundo. Caso contrário, retorna falso (ex.: Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Retorna verdadeiro se o primeiro argumento for maior ou igual ao segundo. Caso contrário, retorna falso (ex.: Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default Para definir um valor padrão simples, use `default`: ``` default "foo" .Bar ``` No exemplo acima, se `.Bar` for avaliado como um valor não vazio, ele será usado. Mas se estiver vazio, `foo` será retornado em seu lugar. A definição de "vazio" depende do tipo: - Numérico: 0 - String: "" - Listas: `[]` - Dicts: `{}` - Booleano: `false` - E sempre `nil` (também conhecido como null) Para structs, não há definição de vazio, então uma struct nunca retornará o valor padrão. ### required Especifique valores que devem ser definidos com `required`: ``` required "A valid foo is required!" .Bar ``` Se `.Bar` estiver vazio ou não definido (veja [default](#default) para saber como isso é avaliado), o template não será renderizado e retornará a mensagem de erro fornecida. ### empty A função `empty` retorna `true` se o valor fornecido for considerado vazio, e `false` caso contrário. Os valores vazios estão listados na seção `default`. ``` empty .Foo ``` Note que em condicionais de templates Go, o vazio é calculado automaticamente. Assim, raramente você precisará usar `if not empty .Foo`. Em vez disso, use apenas `if .Foo`. ### fail Retorna incondicionalmente uma `string` vazia e um `error` com o texto especificado. Isso é útil em cenários onde outras condicionais determinaram que a renderização do template deve falhar. ``` fail "Please accept the end user license agreement" ``` ### coalesce A função `coalesce` recebe uma lista de valores e retorna o primeiro que não estiver vazio. ``` coalesce 0 1 2 ``` O exemplo acima retorna `1`. Esta função é útil para verificar múltiplas variáveis ou valores: ``` coalesce .name .parent.name "Matt" ``` O exemplo acima primeiro verificará se `.name` está vazio. Se não estiver, retornará esse valor. Se _estiver_ vazio, `coalesce` avaliará `.parent.name` para verificar se está vazio. Finalmente, se tanto `.name` quanto `.parent.name` estiverem vazios, retornará `Matt`. ### ternary A função `ternary` recebe dois valores e um valor de teste. Se o valor de teste for verdadeiro, o primeiro valor será retornado. Se o valor de teste estiver vazio, o segundo valor será retornado. Isso é semelhante ao operador ternário em C e outras linguagens de programação. #### valor de teste verdadeiro ``` ternary "foo" "bar" true ``` ou ``` true | ternary "foo" "bar" ``` O exemplo acima retorna `"foo"`. #### valor de teste falso ``` ternary "foo" "bar" false ``` ou ``` false | ternary "foo" "bar" ``` O exemplo acima retorna `"bar"`. ## Funções de String O Helm inclui as seguintes funções de string: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-e-hassuffix), [hasSuffix](#hasprefix-e-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-e-squote), [randAlpha](#randalphanum-randalpha-randnumeric-e-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-e-randascii), [randAscii](#randalphanum-randalpha-randnumeric-e-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-e-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-e-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap) e [wrapWith](#wrapwith). ### print Retorna uma string a partir da combinação de suas partes. ``` print "Matt has " .Dogs " dogs" ``` Tipos que não são strings são convertidos para strings quando possível. Note que quando dois argumentos adjacentes não são strings, um espaço é adicionado entre eles. ### println Funciona da mesma forma que [print](#print), mas adiciona uma nova linha no final. ### printf Retorna uma string baseada em uma string de formatação e nos argumentos passados a ela em ordem. ``` printf "%s has %d dogs." .Name .NumberDogs ``` O placeholder a ser usado depende do tipo do argumento que está sendo passado. Isso inclui: Propósito geral: * `%v` o valor em um formato padrão * ao imprimir dicts, a flag plus (%+v) adiciona nomes de campos * `%%` um sinal de porcentagem literal; não consome nenhum valor Booleano: * `%t` a palavra true ou false Inteiro: * `%b` base 2 * `%c` o caractere representado pelo ponto de código Unicode correspondente * `%d` base 10 * `%o` base 8 * `%O` base 8 com prefixo 0o * `%q` um caractere literal entre aspas simples, escapado de forma segura * `%x` base 16, com letras minúsculas para a-f * `%X` base 16, com letras maiúsculas para A-F * `%U` formato Unicode: U+1234; mesmo que "U+%04X" Ponto flutuante e constituintes complexos: * `%b` notação científica decimal com expoente sendo potência de dois, ex.: -123456p-78 * `%e` notação científica, ex.: -1.234456e+78 * `%E` notação científica, ex.: -1.234456E+78 * `%f` ponto decimal sem expoente, ex.: 123.456 * `%F` sinônimo para %f * `%g` %e para expoentes grandes, %f caso contrário. * `%G` %E para expoentes grandes, %F caso contrário * `%x` notação hexadecimal (com expoente decimal de potência de dois), ex.: -0x1.23abcp+20 * `%X` notação hexadecimal maiúscula, ex.: -0X1.23ABCP+20 String e slice de bytes (tratados de forma equivalente com estes verbos): * `%s` os bytes não interpretados da string ou slice * `%q` uma string entre aspas duplas, escapada de forma segura * `%x` base 16, minúsculo, dois caracteres por byte * `%X` base 16, maiúsculo, dois caracteres por byte Slice: * `%p` endereço do elemento 0 em notação base 16, com 0x inicial ### trim A função `trim` remove espaços em branco de ambos os lados de uma string: ``` trim " hello " ``` O exemplo acima produz `hello` ### trimAll Remove os caracteres especificados do início e do final de uma string: ``` trimAll "$" "$5.00" ``` O exemplo acima retorna `5.00` (como uma string). ### trimPrefix Remove apenas o prefixo de uma string: ``` trimPrefix "-" "-hello" ``` O exemplo acima retorna `hello` ### trimSuffix Remove apenas o sufixo de uma string: ``` trimSuffix "-" "hello-" ``` O exemplo acima retorna `hello` ### lower Converte toda a string para minúsculas: ``` lower "HELLO" ``` O exemplo acima retorna `hello` ### upper Converte toda a string para maiúsculas: ``` upper "hello" ``` O exemplo acima retorna `HELLO` ### title Converte para formato de título: ``` title "hello world" ``` O exemplo acima retorna `Hello World` ### untitle Remove a formatação de título. `untitle "Hello World"` produz `hello world`. ### repeat Repete uma string múltiplas vezes: ``` repeat 3 "hello" ``` O exemplo acima retorna `hellohellohello` ### substr Obtém uma substring de uma string. Recebe três parâmetros: - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` O exemplo acima retorna `hello` ### nospace Remove todos os espaços em branco de uma string. ``` nospace "hello w o r l d" ``` O exemplo acima retorna `helloworld` ### trunc Trunca uma string ``` trunc 5 "hello world" ``` O exemplo acima produz `hello`. ``` trunc -5 "hello world" ``` O exemplo acima produz `world`. ### abbrev Trunca uma string com reticências (`...`) Parâmetros: - comprimento máximo - a string ``` abbrev 5 "hello world" ``` O exemplo acima retorna `he...`, pois conta a largura das reticências contra o comprimento máximo. ### abbrevboth Abrevia em ambos os lados: ``` abbrevboth 5 10 "1234 5678 9123" ``` O exemplo acima produz `...5678...` Recebe: - deslocamento à esquerda - comprimento máximo - a string ### initials Dadas múltiplas palavras, pega a primeira letra de cada palavra e as combina. ``` initials "First Try" ``` O exemplo acima retorna `FT` ### randAlphaNum, randAlpha, randNumeric e randAscii Estas quatro funções geram strings aleatórias criptograficamente seguras (usam ```crypto/rand```), mas com diferentes conjuntos de caracteres base: - `randAlphaNum` usa `0-9a-zA-Z` - `randAlpha` usa `a-zA-Z` - `randNumeric` usa `0-9` - `randAscii` usa todos os caracteres ASCII imprimíveis Cada uma delas recebe um parâmetro: o comprimento inteiro da string. ``` randNumeric 3 ``` O exemplo acima produzirá uma string aleatória com três dígitos. ### wrap Quebra texto em uma contagem de colunas especificada: ``` wrap 80 $someText ``` O exemplo acima quebrará a string em `$someText` em 80 colunas. ### wrapWith `wrapWith` funciona como `wrap`, mas permite especificar a string usada para quebrar. (`wrap` usa `\n`) ``` wrapWith 5 "\t" "Hello World" ``` O exemplo acima produz `Hello World` (onde o espaço em branco é um caractere de tabulação ASCII) ### contains Testa se uma string está contida dentro de outra: ``` contains "cat" "catch" ``` O exemplo acima retorna `true` porque `catch` contém `cat`. ### hasPrefix e hasSuffix As funções `hasPrefix` e `hasSuffix` testam se uma string tem um determinado prefixo ou sufixo: ``` hasPrefix "cat" "catch" ``` O exemplo acima retorna `true` porque `catch` tem o prefixo `cat`. ### quote e squote Estas funções envolvem uma string em aspas duplas (`quote`) ou aspas simples (`squote`). ### cat A função `cat` concatena múltiplas strings em uma, separando-as com espaços: ``` cat "hello" "beautiful" "world" ``` O exemplo acima produz `hello beautiful world` ### indent A função `indent` indenta cada linha de uma string com a largura de indentação especificada. Isso é útil ao alinhar strings de múltiplas linhas: ``` indent 4 $lots_of_text ``` O exemplo acima indentará cada linha de texto com 4 caracteres de espaço. ### nindent A função `nindent` é igual à função indent, mas adiciona uma nova linha no início da string. ``` nindent 4 $lots_of_text ``` O exemplo acima indentará cada linha de texto com 4 caracteres de espaço e adicionará uma nova linha no início. ### replace Realiza substituição simples de string. Recebe três argumentos: - string a ser substituída - string de substituição - string fonte ``` "I Am Henry VIII" | replace " " "-" ``` O exemplo acima produzirá `I-Am-Henry-VIII` ### plural Pluraliza uma string. ``` len $fish | plural "one anchovy" "many anchovies" ``` No exemplo acima, se o comprimento da string for 1, o primeiro argumento será impresso (`one anchovy`). Caso contrário, o segundo argumento será impresso (`many anchovies`). Os argumentos são: - string singular - string plural - inteiro de comprimento NOTA: O Helm atualmente não suporta idiomas com regras de pluralização mais complexas. E `0` é considerado plural porque o idioma inglês o trata assim (`zero anchovies`). ### snakecase Converte string de camelCase para snake_case. ``` snakecase "FirstName" ``` O exemplo acima produzirá `first_name`. ### camelcase Converte string de snake_case para CamelCase ``` camelcase "http_server" ``` O exemplo acima produzirá `HttpServer`. ### kebabcase Converte string de camelCase para kebab-case. ``` kebabcase "FirstName" ``` O exemplo acima produzirá `first-name`. ### swapcase Troca o caso de uma string usando um algoritmo baseado em palavras. Algoritmo de conversão: - Caractere maiúsculo converte para minúsculo - Caractere de título converte para minúsculo - Caractere minúsculo após espaço em branco ou no início converte para título - Outro caractere minúsculo converte para maiúsculo - Espaço em branco é definido por unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` O exemplo acima produzirá `tHIS iS a.tEST`. ### shuffle Embaralha uma string. ``` shuffle "hello" ``` O exemplo acima randomizará as letras em `hello`, possivelmente produzindo `oelhl`. ## Funções de Conversão de Tipos As seguintes funções de conversão de tipos são fornecidas pelo Helm: - `atoi`: Converte uma string para um inteiro. - `float64`: Converte para um `float64`. - `int`: Converte para um `int` com a largura do sistema. - `int64`: Converte para um `int64`. - `toDecimal`: Converte um octal unix para um `int64`. - `toString`: Converte para uma string. - `toStrings`: Converte uma list, slice ou array para uma lista de strings. - `toJson` (`mustToJson`): Converte list, slice, array, dict ou objeto para JSON. - `toPrettyJson` (`mustToPrettyJson`): Converte list, slice, array, dict ou objeto para JSON indentado. - `toRawJson` (`mustToRawJson`): Converte list, slice, array, dict ou objeto para JSON com caracteres HTML não escapados. - `fromYaml`: Converte uma string YAML para um objeto. - `fromJson`: Converte uma string JSON para um objeto. - `fromJsonArray`: Converte um array JSON para uma lista. - `toYaml`: Converte list, slice, array, dict ou objeto para yaml indentado, pode ser usado para copiar trechos de yaml de qualquer fonte. Esta função é equivalente à função GoLang yaml.Marshal, veja a documentação aqui: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Converte list, slice, array, dict ou objeto para yaml indentado. Equivalente a `toYaml`, mas adicionalmente indenta listas em 2 espaços. - `toToml`: Converte list, slice, array, dict ou objeto para toml, pode ser usado para copiar trechos de toml de qualquer fonte. - `fromYamlArray`: Converte um array YAML para uma lista. Apenas `atoi` requer que a entrada seja de um tipo específico. As outras tentarão converter de qualquer tipo para o tipo de destino. Por exemplo, `int64` pode converter floats para ints, e também pode converter strings para ints. ### toStrings Dada uma coleção similar a lista, produz uma slice de strings. ``` list 1 2 3 | toStrings ``` O exemplo acima converte `1` para `"1"`, `2` para `"2"`, e assim por diante, e então os retorna como uma lista. ### toDecimal Dada uma permissão octal unix, produz um decimal. ``` "0777" | toDecimal ``` O exemplo acima converte `0777` para `511` e retorna o valor como um int64. ### toJson, mustToJson A função `toJson` codifica um item em uma string JSON. Se o item não puder ser convertido para JSON, a função retornará uma string vazia. `mustToJson` retornará um erro caso o item não possa ser codificado em JSON. ``` toJson .Item ``` O exemplo acima retorna a representação em string JSON de `.Item`. ### toPrettyJson, mustToPrettyJson A função `toPrettyJson` codifica um item em uma string JSON formatada (indentada). ``` toPrettyJson .Item ``` O exemplo acima retorna a representação indentada em string JSON de `.Item`. ### toRawJson, mustToRawJson A função `toRawJson` codifica um item em uma string JSON com caracteres HTML não escapados. ``` toRawJson .Item ``` O exemplo acima retorna a representação em string JSON não escapada de `.Item`. ### fromYaml A função `fromYaml` recebe uma string YAML e retorna um objeto que pode ser usado em templates. `Arquivo em: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson A função `fromJson` recebe uma string JSON e retorna um objeto que pode ser usado em templates. `Arquivo em: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray A função `fromJsonArray` recebe um Array JSON e retorna uma lista que pode ser usada em templates. `Arquivo em: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty As funções `toYaml` e `toYamlPretty` codificam um objeto (list, slice, array, dict ou objeto) em uma string YAML indentada. > Note que `toYamlPretty` é funcionalmente equivalente, mas produzirá YAML com > indentação adicional para elementos de lista ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray A função `fromYamlArray` recebe um Array YAML e retorna uma lista que pode ser usada em templates. `Arquivo em: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Expressões Regulares O Helm inclui as seguintes funções de expressões regulares: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Retorna true se a string de entrada contiver qualquer correspondência da expressão regular. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` O exemplo acima produz `true` `regexMatch` causa panic se houver um problema e `mustRegexMatch` retorna um erro para o motor de templates se houver um problema. ### regexFindAll, mustRegexFindAll Retorna uma slice de todas as correspondências da expressão regular na string de entrada. O último parâmetro n determina o número de substrings a retornar, onde -1 significa retornar todas as correspondências ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` O exemplo acima produz `[2 4 6 8]` `regexFindAll` causa panic se houver um problema e `mustRegexFindAll` retorna um erro para o motor de templates se houver um problema. ### regexFind, mustRegexFind Retorna a primeira (mais à esquerda) correspondência da expressão regular na string de entrada ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` O exemplo acima produz `d1` `regexFind` causa panic se houver um problema e `mustRegexFind` retorna um erro para o motor de templates se houver um problema. ### regexReplaceAll, mustRegexReplaceAll Retorna uma cópia da string de entrada, substituindo correspondências da Regexp pela string de substituição. Dentro da string de substituição, sinais $ são interpretados como em Expand, então, por exemplo, $1 representa o texto da primeira subcorrespondência. O primeiro argumento é ``, o segundo é ``, e o terceiro é ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` O exemplo acima produz `-W-xxW-` `regexReplaceAll` causa panic se houver um problema e `mustRegexReplaceAll` retorna um erro para o motor de templates se houver um problema. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Retorna uma cópia da string de entrada, substituindo correspondências da Regexp pela string de substituição. A string de substituição é substituída diretamente, sem usar Expand. O primeiro argumento é ``, o segundo é ``, e o terceiro é ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` O exemplo acima produz `-${1}-${1}-` `regexReplaceAllLiteral` causa panic se houver um problema e `mustRegexReplaceAllLiteral` retorna um erro para o motor de templates se houver um problema. ### regexSplit, mustRegexSplit Divide a string de entrada em substrings separadas pela expressão e retorna uma slice das substrings entre essas correspondências da expressão. O último parâmetro `n` determina o número de substrings a retornar, onde `-1` significa retornar todas as correspondências ``` regexSplit "z+" "pizza" -1 ``` O exemplo acima produz `[pi a]` `regexSplit` causa panic se houver um problema e `mustRegexSplit` retorna um erro para o motor de templates se houver um problema. ## Funções Criptográficas e de Segurança O Helm fornece algumas funções criptográficas avançadas. Elas incluem [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) e [sha256sum](#sha256sum). ### sha1sum A função `sha1sum` recebe uma string e calcula seu digest SHA1. ``` sha1sum "Hello world!" ``` ### sha256sum A função `sha256sum` recebe uma string e calcula seu digest SHA256. ``` sha256sum "Hello world!" ``` O exemplo acima calculará a soma SHA 256 em um formato "ASCII armored" que é seguro para imprimir. ### adler32sum A função `adler32sum` recebe uma string e calcula seu checksum Adler-32. ``` adler32sum "Hello world!" ``` ### htpasswd A função `htpasswd` recebe um `username` e `password` e gera um hash `bcrypt` da senha. O resultado pode ser usado para autenticação básica em um [Servidor HTTP Apache](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Note que é inseguro armazenar a senha diretamente no template. ### randBytes A função randBytes aceita um número N e gera uma sequência aleatória criptograficamente segura (usa crypto/rand) de N bytes. A sequência é retornada como uma string codificada em base64. ``` randBytes 24 ``` ### derivePassword A função `derivePassword` pode ser usada para derivar uma senha específica baseada em algumas restrições de "senha mestre" compartilhadas. O algoritmo para isso é [bem especificado](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Note que é considerado inseguro armazenar as partes diretamente no template. ### genPrivateKey A função `genPrivateKey` gera uma nova chave privada codificada em um bloco PEM. Ela aceita um dos seguintes valores para seu primeiro parâmetro: - `ecdsa`: Gera uma chave DSA de curva elíptica (P256) - `dsa`: Gera uma chave DSA (L2048N256) - `rsa`: Gera uma chave RSA 4096 ### buildCustomCert A função `buildCustomCert` permite personalizar o certificado. Ela recebe os seguintes parâmetros string: - Um certificado em formato PEM codificado em base64 - Uma chave privada em formato PEM codificada em base64 Retorna um objeto de certificado com os seguintes atributos: - `Cert`: Um certificado codificado em PEM - `Key`: Uma chave privada codificada em PEM Exemplo: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Note que o objeto retornado pode ser passado para a função `genSignedCert` para assinar um certificado usando esta CA. ### genCA A função `genCA` gera uma nova autoridade certificadora x509 autoassinada. Ela recebe os seguintes parâmetros: - Nome comum do sujeito (cn) - Duração da validade do certificado em dias Retorna um objeto com os seguintes atributos: - `Cert`: Um certificado codificado em PEM - `Key`: Uma chave privada codificada em PEM Exemplo: ``` $ca := genCA "foo-ca" 365 ``` Note que o objeto retornado pode ser passado para a função `genSignedCert` para assinar um certificado usando esta CA. ### genSelfSignedCert A função `genSelfSignedCert` gera um novo certificado x509 autoassinado. Ela recebe os seguintes parâmetros: - Nome comum do sujeito (cn) - Lista opcional de IPs; pode ser nil - Lista opcional de nomes DNS alternativos; pode ser nil - Duração da validade do certificado em dias Retorna um objeto com os seguintes atributos: - `Cert`: Um certificado codificado em PEM - `Key`: Uma chave privada codificada em PEM Exemplo: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert A função `genSignedCert` gera um novo certificado x509 assinado pela CA especificada. Ela recebe os seguintes parâmetros: - Nome comum do sujeito (cn) - Lista opcional de IPs; pode ser nil - Lista opcional de nomes DNS alternativos; pode ser nil - Duração da validade do certificado em dias - CA (veja `genCA`) Exemplo: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES A função `encryptAES` criptografa texto com AES-256 CBC e retorna uma string codificada em base64. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES A função `decryptAES` recebe uma string base64 codificada pelo algoritmo AES-256 CBC e retorna o texto decodificado. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Funções de Data O Helm inclui as seguintes funções de data que você pode usar em templates: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) e [unixEpoch](#unixepoch). ### now A data/hora atual. Use isso em conjunto com outras funções de data. ### ago A função `ago` retorna a duração desde o momento. Agora em resolução de segundos. ``` ago .CreatedAt ``` retorna no formato String() de `time.Duration` ``` 2h34m7s ``` ### date A função `date` formata uma data. Formata a data para ANO-MÊS-DIA: ``` now | date "2006-01-02" ``` A formatação de datas em Go é [um pouco diferente](https://pauladamsmith.com/blog/2011/05/go_time.html). Em resumo, use isso como a data base: ``` Mon Jan 2 15:04:05 MST 2006 ``` Escreva-a no formato que você deseja. Acima, `2006-01-02` é a mesma data, mas no formato que queremos. ### dateInZone Igual a `date`, mas com um fuso horário. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formata uma quantidade de segundos como um `time.Duration`. Isso retorna 1m35s ``` duration "95" ``` ### durationRound Arredonda uma duração para a unidade mais significativa. Strings e `time.Duration` são analisados como uma duração, enquanto um `time.Time` é calculado como a duração desde então. Isso retorna 2h ``` durationRound "2h10m5s" ``` Isso retorna 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Retorna os segundos desde a época unix para um `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify O `dateModify` recebe uma modificação e uma data e retorna o timestamp. Subtrai uma hora e trinta minutos do horário atual: ``` now | dateModify "-1.5h" ``` Se o formato de modificação estiver errado, `dateModify` retornará a data sem modificação. `mustDateModify` retornará um erro caso contrário. ### htmlDate A função `htmlDate` formata uma data para inserir em um campo de entrada de seleção de data HTML. ``` now | htmlDate ``` ### htmlDateInZone Igual a htmlDate, mas com um fuso horário. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` converte uma string para uma data. O primeiro argumento é o layout da data e o segundo é a string da data. Se a string não puder ser convertida, retorna o valor zero. `mustToDate` retornará um erro caso a string não possa ser convertida. Isso é útil quando você quer converter uma data em string para outro formato (usando pipe). O exemplo abaixo converte "2017-12-31" para "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Funções de Dicionário e Dict O Helm fornece um tipo de armazenamento chave/valor chamado `dict` (abreviação de "dictionary", como em Python). Um `dict` é um tipo _não ordenado_. A chave de um dicionário **deve ser uma string**. No entanto, o valor pode ser de qualquer tipo, incluindo outro `dict` ou `list`. Diferente de `list`s, `dict`s não são imutáveis. As funções `set` e `unset` modificarão o conteúdo de um dicionário. O Helm fornece as seguintes funções para trabalhar com dicts: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) e [values](#values). ### dict Criar dicionários é feito chamando a função `dict` e passando uma lista de pares. O seguinte cria um dicionário com três itens: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Dado um map e uma chave, obtém o valor do map. ``` get $myDict "name1" ``` O exemplo acima retorna `"value1"` Note que se a chave não for encontrada, esta operação simplesmente retornará `""`. Nenhum erro será gerado. ### set Use `set` para adicionar um novo par chave/valor a um dicionário. ``` $_ := set $myDict "name4" "value4" ``` Note que `set` _retorna o dicionário_ (um requisito das funções de template Go), então você pode precisar capturar o valor como feito acima com a atribuição `$_`. ### unset Dado um map e uma chave, remove a chave do map. ``` $_ := unset $myDict "name4" ``` Assim como `set`, isso retorna o dicionário. Note que se a chave não for encontrada, esta operação simplesmente retornará. Nenhum erro será gerado. ### hasKey A função `hasKey` retorna `true` se o dict fornecido contiver a chave especificada. ``` hasKey $myDict "name1" ``` Se a chave não for encontrada, retorna `false`. ### pluck A função `pluck` permite fornecer uma chave e múltiplos maps, e obter uma lista de todas as correspondências: ``` pluck "name1" $myDict $myOtherDict ``` O exemplo acima retornará uma `list` contendo cada valor encontrado (`[value1 otherValue1]`). Se a chave _não for encontrada_ em um map, esse map não terá um item na lista (e o comprimento da lista retornada será menor que o número de dicts na chamada de `pluck`). Se a chave _for encontrada_ mas o valor estiver vazio, esse valor será inserido. Um idioma comum em templates Helm é usar `pluck... | first` para obter a primeira chave correspondente de uma coleção de dicionários. ### dig A função `dig` percorre um conjunto aninhado de dicts, selecionando chaves de uma lista de valores. Ela retorna um valor padrão se alguma das chaves não for encontrada no dict associado. ``` dig "user" "role" "humanName" "guest" $dict ``` Dado um dict estruturado como ``` { user: { role: { humanName: "curator" } } } ``` o exemplo acima retornaria `"curator"`. Se o dict não tivesse nem um campo `user`, o resultado seria `"guest"`. Dig pode ser muito útil em casos onde você gostaria de evitar cláusulas de guarda, especialmente porque o `and` do pacote de templates Go não faz curto-circuito. Por exemplo, `and a.maybeNil a.maybeNil.iNeedThis` sempre avaliará `a.maybeNil.iNeedThis`, e causará panic se `a` não tiver um campo `maybeNil`.) `dig` aceita seu argumento dict por último para suportar pipelining. Por exemplo: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Mescla dois ou mais dicionários em um, dando precedência ao dicionário de destino: Dado: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` resultará em: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` Esta é uma operação de mesclagem profunda, mas não uma operação de cópia profunda. Objetos aninhados que são mesclados são a mesma instância em ambos os dicts. Se você quiser uma cópia profunda junto com a mesclagem, use a função `deepCopy` junto com a mesclagem. Por exemplo, ``` deepCopy $source | merge $dest ``` `mustMerge` retornará um erro em caso de mesclagem malsucedida. ### mergeOverwrite, mustMergeOverwrite Mescla dois ou mais dicionários em um, dando precedência **da direita para a esquerda**, efetivamente sobrescrevendo valores no dicionário de destino: Dado: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` resultará em: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` Esta é uma operação de mesclagem profunda, mas não uma operação de cópia profunda. Objetos aninhados que são mesclados são a mesma instância em ambos os dicts. Se você quiser uma cópia profunda junto com a mesclagem, use a função `deepCopy` junto com a mesclagem. Por exemplo, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` retornará um erro em caso de mesclagem malsucedida. ### keys A função `keys` retornará uma `list` de todas as chaves em um ou mais tipos `dict`. Como um dicionário é _não ordenado_, as chaves não estarão em uma ordem previsível. Elas podem ser ordenadas com `sortAlpha`. ``` keys $myDict | sortAlpha ``` Ao fornecer múltiplos dicionários, as chaves serão concatenadas. Use a função `uniq` junto com `sortAlpha` para obter uma lista única e ordenada de chaves. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick A função `pick` seleciona apenas as chaves especificadas de um dicionário, criando um novo `dict`. ``` $new := pick $myDict "name1" "name2" ``` O exemplo acima retorna `{name1: value1, name2: value2}` ### omit A função `omit` é similar a `pick`, exceto que retorna um novo `dict` com todas as chaves que _não_ correspondem às chaves especificadas. ``` $new := omit $myDict "name1" "name3" ``` O exemplo acima retorna `{name2: value2}` ### values A função `values` é similar a `keys`, exceto que retorna uma nova `list` com todos os valores do `dict` de origem (apenas um dicionário é suportado). ``` $vals := values $myDict ``` O exemplo acima retorna `list["value1", "value2", "value 3"]`. Note que a função `values` não dá garantias sobre a ordenação do resultado; se você se importa com isso, use `sortAlpha`. ### deepCopy, mustDeepCopy As funções `deepCopy` e `mustDeepCopy` recebem um valor e fazem uma cópia profunda dele. Isso inclui dicts e outras estruturas. `deepCopy` causa panic quando há um problema, enquanto `mustDeepCopy` retorna um erro para o sistema de templates quando há um erro. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Uma Nota sobre Internos de Dict Um `dict` é implementado em Go como um `map[string]interface{}`. Desenvolvedores Go podem passar valores `map[string]interface{}` para o contexto para disponibilizá-los para templates como `dict`s. ## Funções de Codificação O Helm tem as seguintes funções de codificação e decodificação: - `b64enc`/`b64dec`: Codifica ou decodifica com Base64 - `b32enc`/`b32dec`: Codifica ou decodifica com Base32 ## Funções de Lista e List O Helm fornece um tipo simples `list` que pode conter listas sequenciais arbitrárias de dados. Isso é similar a arrays ou slices, mas listas são projetadas para serem usadas como tipos de dados imutáveis. Crie uma lista de inteiros: ``` $myList := list 1 2 3 4 5 ``` O exemplo acima cria uma lista `[1 2 3 4 5]`. O Helm fornece as seguintes funções de lista: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) e [without (mustWithout)](#without-mustwithout). ### first, mustFirst Para obter o primeiro item de uma lista, use `first`. `first $myList` retorna `1` `first` causa panic se houver um problema, enquanto `mustFirst` retorna um erro para o motor de templates se houver um problema. ### rest, mustRest Para obter a cauda da lista (tudo exceto o primeiro item), use `rest`. `rest $myList` retorna `[2 3 4 5]` `rest` causa panic se houver um problema, enquanto `mustRest` retorna um erro para o motor de templates se houver um problema. ### last, mustLast Para obter o último item de uma lista, use `last`: `last $myList` retorna `5`. Isso é aproximadamente análogo a inverter uma lista e então chamar `first`. ### initial, mustInitial Isso complementa `last` retornando todos os elementos _exceto_ o último. `initial $myList` retorna `[1 2 3 4]`. `initial` causa panic se houver um problema, enquanto `mustInitial` retorna um erro para o motor de templates se houver um problema. ### append, mustAppend Adiciona um novo item a uma lista existente, criando uma nova lista. ``` $new = append $myList 6 ``` O exemplo acima definiria `$new` como `[1 2 3 4 5 6]`. `$myList` permaneceria inalterada. `append` causa panic se houver um problema, enquanto `mustAppend` retorna um erro para o motor de templates se houver um problema. ### prepend, mustPrepend Adiciona um elemento no início de uma lista, criando uma nova lista. ``` prepend $myList 0 ``` O exemplo acima produziria `[0 1 2 3 4 5]`. `$myList` permaneceria inalterada. `prepend` causa panic se houver um problema, enquanto `mustPrepend` retorna um erro para o motor de templates se houver um problema. ### concat Concatena um número arbitrário de listas em uma. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` O exemplo acima produziria `[1 2 3 4 5 6 7 8]`. `$myList` permaneceria inalterada. ### reverse, mustReverse Produz uma nova lista com os elementos invertidos da lista fornecida. ``` reverse $myList ``` O exemplo acima geraria a lista `[5 4 3 2 1]`. `reverse` causa panic se houver um problema, enquanto `mustReverse` retorna um erro para o motor de templates se houver um problema. ### uniq, mustUniq Gera uma lista com todas as duplicatas removidas. ``` list 1 1 1 2 | uniq ``` O exemplo acima produziria `[1 2]` `uniq` causa panic se houver um problema, enquanto `mustUniq` retorna um erro para o motor de templates se houver um problema. ### without, mustWithout A função `without` filtra itens de uma lista. ``` without $myList 3 ``` O exemplo acima produziria `[1 2 4 5]` `without` pode receber mais de um filtro: ``` without $myList 1 3 5 ``` Isso produziria `[2 4]` `without` causa panic se houver um problema, enquanto `mustWithout` retorna um erro para o motor de templates se houver um problema. ### has, mustHas Testa se uma lista contém um determinado elemento. ``` has 4 $myList ``` O exemplo acima retornaria `true`, enquanto `has "hello" $myList` retornaria false. `has` causa panic se houver um problema, enquanto `mustHas` retorna um erro para o motor de templates se houver um problema. ### compact, mustCompact Aceita uma lista e remove entradas com valores vazios. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` retornará uma nova lista com o item vazio (ou seja, "") removido. `compact` causa panic se houver um problema e `mustCompact` retorna um erro para o motor de templates se houver um problema. ### index Para obter o n-ésimo elemento de uma lista, use `index list [n]`. Para indexar em listas multidimensionais, use `index list [n] [m] ...` - `index $myList 0` retorna `1`. É o mesmo que `myList[0]` - `index $myList 0 1` seria o mesmo que `myList[0][1]` ### slice, mustSlice Para obter elementos parciais de uma lista, use `slice list [n] [m]`. É equivalente a `list[n:m]`. - `slice $myList` retorna `[1 2 3 4 5]`. É o mesmo que `myList[:]`. - `slice $myList 3` retorna `[4 5]`. É o mesmo que `myList[3:]`. - `slice $myList 1 3` retorna `[2 3]`. É o mesmo que `myList[1:3]`. - `slice $myList 0 3` retorna `[1 2 3]`. É o mesmo que `myList[:3]`. `slice` causa panic se houver um problema, enquanto `mustSlice` retorna um erro para o motor de templates se houver um problema. ### until A função `until` constrói um intervalo de inteiros. ``` until 5 ``` O exemplo acima gera a lista `[0, 1, 2, 3, 4]`. Isso é útil para fazer loop com `range $i, $e := until 5`. ### untilStep Como `until`, `untilStep` gera uma lista de inteiros contados. Mas permite definir um início, fim e passo: ``` untilStep 3 6 2 ``` O exemplo acima produzirá `[3 5]` começando com 3 e adicionando 2 até que seja igual ou maior que 6. Isso é similar à função `range` do Python. ### seq Funciona como o comando `seq` do bash. * 1 parâmetro (end) - gerará todos os inteiros contados entre 1 e `end` inclusive. * 2 parâmetros (start, end) - gerará todos os inteiros contados entre `start` e `end` inclusive, incrementando ou decrementando por 1. * 3 parâmetros (start, step, end) - gerará todos os inteiros contados entre `start` e `end` inclusive, incrementando ou decrementando por `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Para dividir uma lista em pedaços de tamanho especificado, use `chunk size list`. Isso é útil para paginação. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` Isso produz uma lista de listas `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Funções Matemáticas Todas as funções matemáticas operam em valores `int64`, a menos que especificado de outra forma. As seguintes funções matemáticas estão disponíveis: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) e [sub](#sub). ### add Soma números com `add`. Aceita duas ou mais entradas. ``` add 1 2 3 ``` ### add1 Para incrementar por 1, use `add1`. ### sub Para subtrair, use `sub`. ### div Realiza divisão inteira com `div`. ### mod Módulo com `mod`. ### mul Multiplica com `mul`. Aceita duas ou mais entradas. ``` mul 1 2 3 ``` ### max Retorna o maior de uma série de inteiros. Isso retornará `3`: ``` max 1 2 3 ``` ### min Retorna o menor de uma série de inteiros. `min 1 2 3` retornará `1`. ### len Retorna o comprimento do argumento como um inteiro. ``` len .Arg ``` ## Funções Matemáticas com Float Todas as funções matemáticas operam em valores `float64`. ### addf Soma números com `addf` Isso retornará `5.5`: ``` addf 1.5 2 2 ``` ### add1f Para incrementar por 1, use `add1f` ### subf Para subtrair, use `subf` Isso é equivalente a `7.5 - 2 - 3` e retornará `2.5`: ``` subf 7.5 2 3 ``` ### divf Realiza divisão inteira com `divf` Isso é equivalente a `10 / 2 / 4` e retornará `1.25`: ``` divf 10 2 4 ``` ### mulf Multiplica com `mulf` Isso retornará `6`: ``` mulf 1.5 2 2 ``` ### maxf Retorna o maior de uma série de floats: Isso retornará `3`: ``` maxf 1 2.5 3 ``` ### minf Retorna o menor de uma série de floats. Isso retornará `1.5`: ``` minf 1.5 2 3 ``` ### floor Retorna o maior valor float menor ou igual ao valor de entrada. `floor 123.9999` retornará `123.0`. ### ceil Retorna o maior valor float maior ou igual ao valor de entrada. `ceil 123.001` retornará `124.0`. ### round Retorna um valor float com o resto arredondado para o número de dígitos especificado após o ponto decimal. `round 123.555555 3` retornará `123.556`. ## Funções de Rede O Helm tem uma única função de rede, `getHostByName`. O `getHostByName` recebe um nome de domínio e retorna o endereço IP. `getHostByName "www.google.com"` retornaria o endereço IP correspondente de `www.google.com`. Esta função requer que a opção `--enable-dns` seja passada na linha de comando do helm. ## Funções de Caminho de Arquivo Embora as funções de template do Helm não concedam acesso ao sistema de arquivos, elas fornecem funções para trabalhar com strings que seguem convenções de caminhos de arquivo. Essas incluem [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) e [isAbs](#isabs). ### base Retorna o último elemento de um caminho. ``` base "foo/bar/baz" ``` O exemplo acima imprime "baz". ### dir Retorna o diretório, removendo a última parte do caminho. Então `dir "foo/bar/baz"` retorna `foo/bar`. ### clean Limpa um caminho. ``` clean "foo/bar/../baz" ``` O exemplo acima resolve o `..` e retorna `foo/baz`. ### ext Retorna a extensão do arquivo. ``` ext "foo.bar" ``` O exemplo acima retorna `.bar`. ### isAbs Para verificar se um caminho de arquivo é absoluto, use `isAbs`. ## Funções de Reflexão O Helm fornece ferramentas rudimentares de reflexão. Estas ajudam desenvolvedores de templates avançados a entender as informações de tipo Go subjacentes para um determinado valor. O Helm é escrito em Go e é fortemente tipado. O sistema de tipos se aplica dentro de templates. Go tem vários _kinds_ primitivos, como `string`, `slice`, `int64` e `bool`. Go tem um sistema de _tipos_ aberto que permite desenvolvedores criar seus próprios tipos. O Helm fornece um conjunto de funções para cada através de [funções kind](#funções-kind) e [funções type](#funções-type). Uma função [deepEqual](#deepequal) também é fornecida para comparar dois valores. ### Funções Kind Existem duas funções Kind: `kindOf` retorna o kind de um objeto. ``` kindOf "hello" ``` O exemplo acima retornaria `string`. Para testes simples (como em blocos `if`), a função `kindIs` permitirá verificar se um valor é de um kind específico: ``` kindIs "int" 123 ``` O exemplo acima retornará `true`. ### Funções Type Tipos são um pouco mais difíceis de trabalhar, então existem três funções diferentes: - `typeOf` retorna o tipo subjacente de um valor: `typeOf $foo` - `typeIs` é como `kindIs`, mas para tipos: `typeIs "*io.Buffer" $myVal` - `typeIsLike` funciona como `typeIs`, exceto que também desreferencia ponteiros **Nota:** Nenhuma dessas pode testar se algo implementa uma determinada interface, pois fazer isso exigiria compilar a interface antecipadamente. ### deepEqual `deepEqual` retorna true se dois valores são ["profundamente iguais"](https://golang.org/pkg/reflect/#DeepEqual) Funciona para tipos não primitivos também (comparado ao `eq` embutido). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` O exemplo acima retornará `true`. ## Funções de Versão Semântica Alguns esquemas de versão são facilmente analisáveis e comparáveis. O Helm fornece funções para trabalhar com versões [SemVer 2](http://semver.org). Essas incluem [semver](#semver) e [semverCompare](#semvercompare). Abaixo você também encontrará detalhes sobre o uso de intervalos para comparações. ### semver A função `semver` analisa uma string em uma Versão Semântica: ``` $version := semver "1.2.3-alpha.1+123" ``` _Se o analisador falhar, causará a interrupção da execução do template com um erro._ Neste ponto, `$version` é um ponteiro para um objeto `Version` com as seguintes propriedades: - `$version.Major`: O número major (`1` acima) - `$version.Minor`: O número minor (`2` acima) - `$version.Patch`: O número patch (`3` acima) - `$version.Prerelease`: O prerelease (`alpha.1` acima) - `$version.Metadata`: Os metadados de build (`123` acima) - `$version.Original`: A versão original como string Adicionalmente, você pode comparar uma `Version` com outra `version` usando a função `Compare`: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` O exemplo acima retornará `-1`. Os valores de retorno são: - `-1` se a semver fornecida for maior que a semver cujo método `Compare` foi chamado - `1` se a versão cujo função `Compare` foi chamada for maior. - `0` se forem a mesma versão (Note que em SemVer, o campo `Metadata` não é comparado durante operações de comparação de versão.) ### semverCompare Uma função de comparação mais robusta é fornecida como `semverCompare`. Esta versão suporta intervalos de versão: - `semverCompare "1.2.3" "1.2.3"` verifica uma correspondência exata - `semverCompare "~1.2.0" "1.2.3"` verifica se as versões major e minor correspondem, e que o número patch do segundo parâmetro é _maior ou igual_ ao primeiro parâmetro. As funções SemVer usam a [biblioteca semver Masterminds](https://github.com/Masterminds/semver), dos criadores do Sprig. ### Comparações Básicas Existem dois elementos nas comparações. Primeiro, uma string de comparação é uma lista de comparações AND separadas por espaço ou vírgula. Estas são então separadas por || (comparações OR). Por exemplo, `">= 1.2 < 3.0.0 || >= 4.2.3"` está procurando uma comparação que seja maior ou igual a 1.2 e menor que 3.0.0 ou que seja maior ou igual a 4.2.3. As comparações básicas são: - `=`: igual (alias para nenhum operador) - `!=`: diferente - `>`: maior que - `<`: menor que - `>=`: maior ou igual a - `<=`: menor ou igual a ### Trabalhando com Versões Prerelease Prereleases, para quem não está familiarizado com elas, são usadas para lançamentos de software antes de lançamentos estáveis ou geralmente disponíveis. Exemplos de prereleases incluem lançamentos de desenvolvimento, alpha, beta e release candidate. Uma prerelease pode ser uma versão como `1.2.3-beta.1`, enquanto o lançamento estável seria `1.2.3`. Na ordem de precedência, prereleases vêm antes de seus lançamentos associados. Neste exemplo `1.2.3-beta.1 < 1.2.3`. De acordo com a especificação de Versão Semântica, prereleases podem não ser compatíveis com a API de sua contraparte de lançamento. Ela diz, > Uma versão prerelease indica que a versão é instável e pode não satisfazer os > requisitos de compatibilidade pretendidos, conforme indicado por sua versão > normal associada. Comparações SemVer usando restrições sem um comparador de prerelease irão pular versões prerelease. Por exemplo, `>=1.2.3` pulará prereleases ao olhar uma lista de lançamentos, enquanto `>=1.2.3-0` avaliará e encontrará prereleases. A razão para o `0` como uma versão prerelease no exemplo de comparação é porque prereleases podem conter apenas alfanuméricos ASCII e hífens (junto com separadores `.`), conforme a especificação. A ordenação acontece em ordem de classificação ASCII, novamente conforme a especificação. O caractere mais baixo é um `0` na ordem de classificação ASCII (veja uma [Tabela ASCII](http://www.asciitable.com/)) Entender a ordenação de classificação ASCII é importante porque A-Z vem antes de a-z. Isso significa que `>=1.2.3-BETA` retornará `1.2.3-alpha`. O que você pode esperar da sensibilidade a maiúsculas/minúsculas não se aplica aqui. Isso se deve à ordenação de classificação ASCII, que é o que a especificação determina. ### Comparações de Intervalo com Hífen Existem múltiplos métodos para lidar com intervalos e o primeiro são intervalos com hífen. Eles se parecem com: - `1.2 - 1.4.5` que é equivalente a `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` que é equivalente a `>= 2.3.4 <= 4.5` ### Curingas em Comparações Os caracteres `x`, `X` e `*` podem ser usados como caractere curinga. Isso funciona para todos os operadores de comparação. Quando usado no operador `=`, ele volta para a comparação de nível patch (veja til abaixo). Por exemplo, - `1.2.x` é equivalente a `>= 1.2.0, < 1.3.0` - `>= 1.2.x` é equivalente a `>= 1.2.0` - `<= 2.x` é equivalente a `< 3` - `*` é equivalente a `>= 0.0.0` ### Comparações de Intervalo Til (Patch) O operador de comparação til (`~`) é para intervalos de nível patch quando uma versão minor é especificada e mudanças de nível major quando o número minor está faltando. Por exemplo, - `~1.2.3` é equivalente a `>= 1.2.3, < 1.3.0` - `~1` é equivalente a `>= 1, < 2` - `~2.3` é equivalente a `>= 2.3, < 2.4` - `~1.2.x` é equivalente a `>= 1.2.0, < 1.3.0` - `~1.x` é equivalente a `>= 1, < 2` ### Comparações de Intervalo Circunflexo (Major) O operador de comparação circunflexo (`^`) é para mudanças de nível major uma vez que um lançamento estável (1.0.0) tenha ocorrido. Antes de um lançamento 1.0.0, as versões minor funcionam como o nível de estabilidade da API. Isso é útil ao comparar versões de API, pois uma mudança major quebra a API. Por exemplo, - `^1.2.3` é equivalente a `>= 1.2.3, < 2.0.0` - `^1.2.x` é equivalente a `>= 1.2.0, < 2.0.0` - `^2.3` é equivalente a `>= 2.3, < 3` - `^2.x` é equivalente a `>= 2.0.0, < 3` - `^0.2.3` é equivalente a `>=0.2.3 <0.3.0` - `^0.2` é equivalente a `>=0.2.0 <0.3.0` - `^0.0.3` é equivalente a `>=0.0.3 <0.0.4` - `^0.0` é equivalente a `>=0.0.0 <0.1.0` - `^0` é equivalente a `>=0.0.0 <1.0.0` ## Funções de URL O Helm inclui as funções [urlParse](#urlparse), [urlJoin](#urljoin) e [urlquery](#urlquery) permitindo que você trabalhe com partes de URL. ### urlParse Analisa uma string para URL e produz um dict com as partes da URL ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` O exemplo acima retorna um dict, contendo o objeto URL: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Isso é implementado usando os pacotes URL da biblioteca padrão Go. Para mais informações, consulte https://golang.org/pkg/net/url/#URL ### urlJoin Une um map (produzido por `urlParse`) para produzir uma string URL ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` O exemplo acima retorna a seguinte string: ``` http://host:80/path?query#fragment ``` ### urlquery Retorna a versão escapada do valor passado como argumento para que seja adequado para incorporação na parte de query de uma URL. ``` $var := urlquery "string for query" ``` ## Funções de UUID O Helm pode gerar UUIDs v4 universalmente únicos. ``` uuidv4 ``` O exemplo acima retorna um novo UUID do tipo v4 (gerado aleatoriamente). ## Funções de Kubernetes e Chart O Helm inclui funções para trabalhar com Kubernetes, incluindo [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#funções-de-arquivo) e [lookup](#lookup). ### lookup `lookup` é usado para consultar recursos em um cluster em execução. Quando usado com o comando `helm template`, sempre retorna uma resposta vazia. Você pode encontrar mais detalhes na [documentação sobre a função lookup](./functions_and_pipelines.md#usando-a-função-lookup). ### .Capabilities.APIVersions.Has Retorna se uma versão da API ou recurso está disponível em um cluster. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Mais informações estão disponíveis na [documentação de objetos embutidos](./builtin_objects.md). ### Funções de Arquivo Existem várias funções que permitem acessar arquivos não especiais dentro de um chart. Por exemplo, para acessar arquivos de configuração de aplicação. Estas estão documentadas em [Acessando Arquivos Dentro de Templates](./accessing_files.md). _Nota: a documentação para muitas dessas funções vem do [Sprig](https://github.com/Masterminds/sprig). Sprig é uma biblioteca de funções de template disponível para aplicações Go._ ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Funções de Template e Pipelines description: Usando funções em templates. sidebar_position: 5 --- Até agora, vimos como inserir informações em um template. Porém, essas informações são inseridas sem modificação. Às vezes, queremos transformar os dados fornecidos de uma forma que seja mais útil para nós. Uma boa prática: ao injetar strings do objeto `.Values` no template, devemos colocá-las entre aspas. Podemos fazer isso chamando a função `quote` na diretiva do template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` As funções de template seguem a sintaxe `nomeDaFuncao arg1 arg2...`. No trecho acima, `quote .Values.favorite.drink` chama a função `quote` e passa um único argumento para ela. O Helm tem mais de 60 funções disponíveis. Algumas delas são definidas pela própria [linguagem de template do Go](https://godoc.org/text/template). A maioria das outras faz parte da [biblioteca de templates Sprig](https://masterminds.github.io/sprig/). Veremos muitas delas conforme avançamos pelos exemplos. > Embora falemos da "linguagem de template do Helm" como se fosse específica do Helm, > na verdade é uma combinação da linguagem de template do Go, algumas funções extras > e uma variedade de wrappers para expor certos objetos aos templates. Muitos > recursos sobre templates do Go podem ser úteis enquanto você aprende sobre templating. ## Pipelines Uma das funcionalidades poderosas da linguagem de template é o conceito de _pipelines_. Baseando-se em um conceito do UNIX, pipelines são uma ferramenta para encadear uma série de comandos de template para expressar de forma compacta uma série de transformações. Em outras palavras, pipelines são uma forma eficiente de fazer várias coisas em sequência. Vamos reescrever o exemplo acima usando um pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` Neste exemplo, em vez de chamar `quote ARGUMENTO`, invertemos a ordem. "Enviamos" o argumento para a função usando um pipeline (`|`): `.Values.favorite.drink | quote`. Usando pipelines, podemos encadear várias funções juntas: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Inverter a ordem é uma prática comum em templates. Você verá `.val | > quote` com mais frequência do que `quote .val`. Ambas as práticas são válidas. Quando avaliado, esse template produzirá: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Observe que nosso `pizza` original agora foi transformado em `"PIZZA"`. Quando usamos pipelines assim, o resultado da primeira avaliação (`.Values.favorite.drink`) é enviado como o _último argumento para a função_. Podemos modificar o exemplo da bebida acima para ilustrar com uma função que recebe dois argumentos: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` A função `repeat` irá ecoar a string fornecida o número de vezes especificado, então teremos esta saída: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Usando a função `default` Uma função frequentemente usada em templates é a função `default`: `default VALOR_PADRAO VALOR_FORNECIDO`. Esta função permite especificar um valor padrão dentro do template, caso o valor seja omitido. Vamos usá-la para modificar o exemplo da bebida acima: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Se executarmos isso normalmente, obteremos nosso `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Agora, vamos remover a configuração da bebida favorita do `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Agora, executar novamente `helm install --dry-run --debug fair-worm ./mychart` produzirá este YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` Em um chart real, todos os valores padrão estáticos devem estar no `values.yaml` e não devem ser repetidos usando o comando `default` (caso contrário, seriam redundantes). No entanto, o comando `default` é perfeito para valores computados, que não podem ser declarados dentro do `values.yaml`. Por exemplo: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` Em alguns casos, uma condição `if` pode ser mais adequada do que `default`. Veremos isso na próxima seção. Funções e pipelines de template são uma forma poderosa de transformar informações e inseri-las no seu YAML. Mas às vezes é necessário adicionar alguma lógica de template que seja um pouco mais sofisticada do que apenas inserir uma string. Na próxima seção, veremos as estruturas de controle fornecidas pela linguagem de template. ## Usando a função `lookup` A função `lookup` pode ser usada para _consultar_ recursos em um cluster em execução. A sintaxe da função lookup é `lookup apiVersion, kind, namespace, name -> recurso ou lista de recursos`. | parâmetro | tipo | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Tanto `name` quanto `namespace` são opcionais e podem ser passados como uma string vazia (`""`). No entanto, se você estiver trabalhando com um recurso com escopo de namespace, tanto `name` quanto `namespace` devem ser especificados. As seguintes combinações de parâmetros são possíveis: | Comportamento | Função lookup | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Quando `lookup` retorna um objeto, ele retornará um dicionário. Este dicionário pode ser navegado para extrair valores específicos. O exemplo a seguir retornará as annotations presentes no objeto `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Quando `lookup` retorna uma lista de objetos, é possível acessar a lista de objetos através do campo `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* faça algo com cada serviço */}} {{ end }} ``` Quando nenhum objeto é encontrado, um valor vazio é retornado. Isso pode ser usado para verificar a existência de um objeto. A função `lookup` usa a configuração de conexão existente do Helm com o Kubernetes para consultar o Kubernetes. Se algum erro for retornado ao interagir com o servidor da API (por exemplo, devido à falta de permissão para acessar um recurso), o processamento de template do Helm falhará. Tenha em mente que o Helm não deve contatar o Servidor da API do Kubernetes durante uma operação `helm template|install|upgrade|delete|rollback --dry-run`. Para testar `lookup` contra um cluster em execução, deve-se usar `helm template|install|upgrade|delete|rollback --dry-run=server` para permitir a conexão com o cluster. ## Operadores são funções Para templates, os operadores (`eq`, `ne`, `lt`, `gt`, `and`, `or` e assim por diante) são todos implementados como funções. Em pipelines, operações podem ser agrupadas com parênteses (`(` e `)`). Agora podemos passar de funções e pipelines para controle de fluxo com condições, loops e modificadores de escopo. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Primeiros Passos description: Um guia rápido sobre templates de Chart. sidebar_position: 2 --- Nesta seção do guia, criaremos um chart e adicionaremos um primeiro template. O chart que criaremos aqui será usado ao longo do restante do guia. Para começar, vamos dar uma breve olhada em um chart do Helm. ## Charts Conforme descrito no [Guia de Charts](../topics/charts.md), os charts do Helm são estruturados assim: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` O diretório `templates/` é para arquivos de template. Quando o Helm avalia um chart, ele passa todos os arquivos do diretório `templates/` pelo motor de templates. Em seguida, coleta os resultados desses templates e os envia ao Kubernetes. O arquivo `values.yaml` também é importante para templates. Este arquivo contém os _valores padrão_ de um chart. Esses valores podem ser sobrescritos pelos usuários durante `helm install` ou `helm upgrade`. O arquivo `Chart.yaml` contém uma descrição do chart. Você pode acessá-lo de dentro de um template. O diretório `charts/` _pode_ conter outros charts (que chamamos de _subcharts_). Mais adiante neste guia veremos como eles funcionam quando se trata de renderização de templates. ## Um Chart Inicial Para este guia, criaremos um chart simples chamado `mychart`, e depois criaremos alguns templates dentro dele. ```console $ helm create mychart Creating mychart ``` ### Uma Visão Rápida de `mychart/templates/` Se você olhar o diretório `mychart/templates/`, notará que alguns arquivos já estão lá. - `NOTES.txt`: O "texto de ajuda" do seu chart. Será exibido para os usuários quando executarem `helm install`. - `deployment.yaml`: Um manifesto básico para criar um [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) do Kubernetes - `service.yaml`: Um manifesto básico para criar um [endpoint de serviço](https://kubernetes.io/docs/concepts/services-networking/service/) para seu deployment - `_helpers.tpl`: Um lugar para colocar helpers de template que você pode reutilizar em todo o chart E o que vamos fazer é... _remover todos eles!_ Dessa forma, podemos trabalhar no nosso tutorial do zero. Na verdade, criaremos nossos próprios `NOTES.txt` e `_helpers.tpl` conforme avançamos. ```console $ rm -rf mychart/templates/* ``` Quando você estiver escrevendo charts de nível de produção, ter versões básicas desses arquivos pode ser muito útil. Então, no seu dia a dia de criação de charts, você provavelmente não vai querer removê-los. ## Um Primeiro Template O primeiro template que vamos criar será um `ConfigMap`. No Kubernetes, um ConfigMap é simplesmente um objeto para armazenar dados de configuração. Outras coisas, como pods, podem acessar os dados em um ConfigMap. Como ConfigMaps são recursos básicos, eles são um ótimo ponto de partida para nós. Vamos começar criando um arquivo chamado `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **DICA:** Os nomes dos templates não seguem um padrão rígido de nomenclatura. No entanto, recomendamos usar a extensão `.yaml` para arquivos YAML e `.tpl` para helpers. O arquivo YAML acima é um ConfigMap básico, com os campos mínimos necessários. Por estar no diretório `mychart/templates/`, ele passará pelo motor de templates. Não há problema em colocar um arquivo YAML simples como este no diretório `mychart/templates/`. Quando o Helm lê este template, ele simplesmente o envia ao Kubernetes como está. Com este template simples, agora temos um chart instalável. E podemos instalá-lo assim: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Usando o Helm, podemos recuperar a release e ver o template real que foi carregado. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` O comando `helm get manifest` recebe um nome de release (`full-coral`) e imprime todos os recursos do Kubernetes que foram enviados ao servidor. Cada arquivo começa com `---` para indicar o início de um documento YAML, e depois é seguido por uma linha de comentário gerada automaticamente que nos diz qual arquivo de template gerou este documento YAML. A partir daí, podemos ver que os dados YAML são exatamente o que colocamos no nosso arquivo `configmap.yaml`. Agora podemos desinstalar nossa release: `helm uninstall full-coral`. ### Adicionando uma Chamada de Template Simples Codificar o `name:` diretamente em um recurso é geralmente considerado uma má prática. Os nomes devem ser únicos para uma release. Então, podemos querer gerar um campo name inserindo o nome da release. **DICA:** O campo `name:` é limitado a 63 caracteres devido a limitações do sistema DNS. Por isso, os nomes de release são limitados a 53 caracteres. O Kubernetes 1.3 e anteriores eram limitados a apenas 24 caracteres (portanto, nomes de 14 caracteres). Vamos alterar `configmap.yaml` de acordo. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` A grande mudança está no valor do campo `name:`, que agora é `{{ .Release.Name }}-configmap`. > Uma diretiva de template é delimitada por blocos `{{` e `}}`. A diretiva de template `{{ .Release.Name }}` injeta o nome da release no template. Os valores passados para um template podem ser pensados como _objetos com namespace_, onde um ponto (`.`) separa cada elemento do namespace. O ponto inicial antes de `Release` indica que começamos no namespace de nível mais alto para este escopo (falaremos sobre escopo em breve). Assim, podemos ler `.Release.Name` como "comece no namespace de nível superior, encontre o objeto `Release`, e então procure dentro dele por um objeto chamado `Name`". O objeto `Release` é um dos objetos embutidos do Helm, e o abordaremos com mais profundidade depois. Mas, por enquanto, basta dizer que isso exibirá o nome da release que a biblioteca atribui à nossa release. Agora, quando instalamos nosso recurso, veremos imediatamente o resultado de usar esta diretiva de template: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Você pode executar `helm get manifest clunky-serval` para ver o YAML completo gerado. Note que o ConfigMap dentro do Kubernetes agora se chama `clunky-serval-configmap` em vez de `mychart-configmap` como antes. Neste ponto, vimos templates em sua forma mais básica: arquivos YAML que têm diretivas de template incorporadas em `{{` e `}}`. Na próxima parte, daremos uma olhada mais profunda nos templates. Mas antes de seguir em frente, há um truque rápido que pode tornar a construção de templates mais rápida: quando você quiser testar a renderização do template, mas não quiser realmente instalar nada, você pode usar `helm install --debug --dry-run goodly-guppy ./mychart`. Isso renderizará os templates. Mas em vez de instalar o chart, retornará o template renderizado para você, para que você possa ver a saída: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Usar `--dry-run` facilitará o teste do seu código, mas não garantirá que o Kubernetes em si aceitará os templates que você gerar. É melhor não presumir que seu chart será instalado só porque `--dry-run` funciona. No [Guia de Templates de Chart](/chart_template_guide/index.mdx), pegamos o chart básico que definimos aqui e exploramos a linguagem de templates do Helm em detalhes. E começaremos com os objetos embutidos. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: O arquivo .helmignore description: O arquivo `.helmignore` é usado para especificar arquivos que você não deseja incluir no seu chart Helm. sidebar_position: 12 --- O arquivo `.helmignore` é usado para especificar arquivos que você não deseja incluir no seu chart Helm. Se este arquivo existir, o comando `helm package` ignorará todos os arquivos que corresponderem aos padrões especificados no `.helmignore` ao empacotar sua aplicação. Isso ajuda a evitar que arquivos ou diretórios desnecessários ou sensíveis sejam adicionados ao seu chart. O arquivo `.helmignore` suporta padrões glob do shell Unix, correspondência de caminhos relativos e negação (prefixada com !). Apenas um padrão por linha é considerado. Aqui está um exemplo de arquivo `.helmignore`: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Algumas diferenças notáveis em relação ao .gitignore: - A sintaxe '**' não é suportada. - A biblioteca de globbing é `filepath.Match` do Go, não fnmatch(3) - Espaços em branco no final são sempre ignorados (não há sequência de escape para preservá-los) - Não há suporte para '\!' como sequência especial inicial. - O arquivo não se exclui automaticamente; você precisa adicionar uma entrada explícita para `.helmignore` **Adoraríamos sua ajuda** para melhorar este documento. Para adicionar, corrigir ou remover informações, [abra uma issue](https://github.com/helm/helm-www/issues) ou envie-nos um pull request. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Templates Nomeados description: Como definir templates nomeados. sidebar_position: 9 --- É hora de ir além de um único template e começar a criar outros. Nesta seção, veremos como definir _templates nomeados_ em um arquivo e usá-los em outros lugares. Um _template nomeado_ (às vezes chamado de _partial_ ou _subtemplate_) é simplesmente um template definido dentro de um arquivo, que recebe um nome. Veremos duas formas de criá-los e algumas formas diferentes de usá-los. Na seção [Estruturas de Controle](/chart_template_guide/control_structures.md) introduzimos três ações para declarar e gerenciar templates: `define`, `template` e `block`. Nesta seção, abordaremos essas três ações e também apresentaremos uma função especial chamada `include`, que funciona de forma semelhante à ação `template`. Um detalhe importante a ter em mente ao nomear templates: **os nomes de templates são globais**. Se você declarar dois templates com o mesmo nome, aquele que for carregado por último será o utilizado. Como templates em subcharts são compilados junto com templates de nível superior, você deve ter cuidado ao nomear seus templates com _nomes específicos do chart_. Uma convenção de nomenclatura popular é prefixar cada template definido com o nome do chart: `{{ define "mychart.labels" }}`. Usando o nome específico do chart como prefixo, podemos evitar conflitos que possam surgir devido a dois charts diferentes que implementam templates com o mesmo nome. Esse comportamento também se aplica a diferentes versões de um chart. Se você tiver `mychart` versão `1.0.0` que define um template de uma forma, e `mychart` versão `2.0.0` que modifica o template nomeado existente, será usado aquele que foi carregado por último. Você pode contornar esse problema adicionando também uma versão no nome do chart: `{{ define "mychart.v1.labels" }}` e `{{ define "mychart.v2.labels" }}`. ## Partials e arquivos `_` Até agora, usamos um único arquivo, e esse arquivo continha um único template. Mas a linguagem de templates do Helm permite criar templates incorporados nomeados, que podem ser acessados pelo nome em outros lugares. Antes de escrever esses templates, há uma convenção de nomenclatura de arquivos que vale mencionar: * A maioria dos arquivos em `templates/` é tratada como se contivesse manifestos Kubernetes * O `NOTES.txt` é uma exceção * Mas arquivos cujo nome começa com underscore (`_`) assumem-se como _não_ tendo um manifesto dentro. Esses arquivos não são renderizados como definições de objetos Kubernetes, mas estão disponíveis em todos os outros templates do chart para uso. Esses arquivos são usados para armazenar partials e helpers. Na verdade, quando criamos `mychart` pela primeira vez, vimos um arquivo chamado `_helpers.tpl`. Esse arquivo é o local padrão para partials de template. ## Declarando e usando templates com `define` e `template` A ação `define` permite criar um template nomeado dentro de um arquivo de template. Sua sintaxe é assim: ```yaml {{- define "MY.NAME" }} # corpo do template aqui {{- end }} ``` Por exemplo, podemos definir um template para encapsular um bloco de labels do Kubernetes: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Agora podemos incorporar esse template dentro do nosso ConfigMap existente e incluí-lo com a ação `template`: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Quando o motor de templates lê este arquivo, ele armazena a referência ao `mychart.labels` até que `template "mychart.labels"` seja chamado. Então ele renderiza esse template inline. O resultado será assim: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Nota: um `define` não produz saída a menos que seja chamado com um template, como neste exemplo. Convencionalmente, os charts do Helm colocam esses templates dentro de um arquivo de partials, geralmente `_helpers.tpl`. Vamos mover esta função para lá: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Por convenção, funções `define` devem ter um bloco de documentação simples (`{{/* ... */}}`) descrevendo o que fazem. Mesmo que esta definição esteja em `_helpers.tpl`, ela ainda pode ser acessada em `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Como mencionado acima, **os nomes de templates são globais**. Como resultado, se dois templates forem declarados com o mesmo nome, a última ocorrência será a utilizada. Como templates em subcharts são compilados junto com templates de nível superior, é melhor nomear seus templates com _nomes específicos do chart_. Uma convenção de nomenclatura popular é prefixar cada template definido com o nome do chart: `{{ define "mychart.labels" }}`. ## Definindo o escopo de um template No template que definimos acima, não usamos nenhum objeto. Apenas usamos funções. Vamos modificar nosso template definido para incluir o nome e a versão do chart: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Se renderizarmos isso, obteremos um erro como este: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Para ver o que foi renderizado, execute novamente com `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. O resultado não será o que esperamos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` O que aconteceu com o nome e a versão? Eles não estavam no escopo do nosso template definido. Quando um template nomeado (criado com `define`) é renderizado, ele recebe o escopo passado pela chamada `template`. No nosso exemplo, incluímos o template assim: ```yaml {{- template "mychart.labels" }} ``` Nenhum escopo foi passado, então dentro do template não podemos acessar nada em `.`. Isso é fácil de corrigir. Basta passar um escopo para o template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Note que passamos `.` no final da chamada `template`. Poderíamos facilmente passar `.Values` ou `.Values.favorite` ou qualquer escopo que quisermos. Mas o que queremos é o escopo de nível superior. No contexto do template nomeado, `$` se referirá ao escopo que você passou, e não a algum escopo global. Agora, quando executamos este template com `helm install --dry-run --debug plinking-anaco ./mychart`, obtemos isto: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Agora `{{ .Chart.Name }}` resolve para `mychart`, e `{{ .Chart.Version }}` resolve para `0.1.0`. ## A função `include` Digamos que definimos um template simples assim: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Agora digamos que quero inserir isso tanto na seção `labels:` do meu template, quanto na seção `data:`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Se renderizarmos isso, obteremos um erro como este: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Para ver o que foi renderizado, execute novamente com `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. A saída não será o que esperamos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Note que a indentação de `app_version` está errada em ambos os lugares. Por quê? Porque o template substituído tem o texto alinhado à esquerda. Como `template` é uma ação, e não uma função, não há como passar a saída de uma chamada `template` para outras funções; os dados são simplesmente inseridos inline. Para contornar esse caso, o Helm fornece uma alternativa ao `template` que importa o conteúdo de um template para o pipeline atual, onde pode ser passado para outras funções no pipeline. Aqui está o exemplo acima, corrigido usando `indent` para indentar o template `mychart.app` corretamente: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Agora o YAML produzido está corretamente indentado para cada seção: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > É considerado preferível usar `include` em vez de `template` em templates do > Helm simplesmente para que a formatação de saída possa ser melhor controlada > para documentos YAML. Às vezes queremos importar conteúdo, mas não como templates. Ou seja, queremos importar arquivos literalmente. Podemos fazer isso acessando arquivos através do objeto `.Files` descrito na próxima seção. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Criando um Arquivo NOTES.txt description: Como fornecer instruções para os usuários do seu Chart. sidebar_position: 10 --- Nesta seção vamos ver a ferramenta do Helm para fornecer instruções aos usuários do seu chart. No final de um `helm install` ou `helm upgrade`, o Helm pode exibir um bloco de informações úteis para os usuários. Essas informações podem ser personalizadas usando templates. Para adicionar notas de instalação ao seu chart, basta criar um arquivo `templates/NOTES.txt`. Este arquivo é texto simples, mas é processado como um template e tem todas as funções e objetos de template disponíveis. Vamos criar um arquivo `NOTES.txt` simples: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Agora, se executarmos `helm install rude-cardinal ./mychart`, veremos esta mensagem no final: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Usar o `NOTES.txt` dessa forma é uma ótima maneira de fornecer aos seus usuários informações detalhadas sobre como utilizar o chart recém-instalado. A criação de um arquivo `NOTES.txt` é fortemente recomendada, embora não obrigatória. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts e Valores Globais description: Como trabalhar com subcharts e valores globais. sidebar_position: 11 --- Até este ponto, trabalhamos apenas com um único chart. Mas charts podem ter dependências, chamadas _subcharts_, que também possuem seus próprios values e templates. Nesta seção, vamos criar um subchart e ver as diferentes formas de acessar values dentro de templates. Antes de entrarmos no código, há alguns detalhes importantes sobre subcharts de aplicação: 1. Um subchart é considerado "independente", o que significa que um subchart nunca pode depender explicitamente de seu chart pai. 2. Por essa razão, um subchart não pode acessar os values de seu chart pai. 3. Um chart pai pode sobrescrever values para subcharts. 4. O Helm possui um conceito de _valores globais_ que podem ser acessados por todos os charts. > Essas limitações não se aplicam necessariamente a [library charts](/topics/library_charts.md), que são projetados para fornecer funcionalidade auxiliar padronizada. À medida que avançamos pelos exemplos desta seção, muitos desses conceitos ficarão mais claros. ## Criando um Subchart Para estes exercícios, vamos começar com o chart `mychart/` que criamos no início deste guia e adicionar um novo chart dentro dele. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Note que, assim como antes, excluímos todos os templates base para que possamos começar do zero. Neste guia, estamos focados em como os templates funcionam, não em gerenciar dependências. Mas o [Guia de Charts](/topics/charts.md) tem mais informações sobre como subcharts funcionam. ## Adicionando Values e um Template ao Subchart Em seguida, vamos criar um template simples e um arquivo de values para nosso chart `mysubchart`. Já deve existir um `values.yaml` em `mychart/charts/mysubchart`. Vamos configurá-lo assim: ```yaml dessert: cake ``` Em seguida, vamos criar um novo template de ConfigMap em `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Como cada subchart é um _chart independente_, podemos testar `mysubchart` separadamente: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Sobrescrevendo Values de um Chart Pai Nosso chart original, `mychart`, agora é o _chart pai_ de `mysubchart`. Essa relação é baseada inteiramente no fato de que `mysubchart` está dentro de `mychart/charts`. Como `mychart` é um chart pai, podemos especificar configuração em `mychart` e ter essa configuração aplicada ao `mysubchart`. Por exemplo, podemos modificar `mychart/values.yaml` assim: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Note as duas últimas linhas. Qualquer diretiva dentro da seção `mysubchart` será enviada para o chart `mysubchart`. Então, se executarmos `helm install --generate-name --dry-run --debug mychart`, uma das coisas que veremos é o ConfigMap do `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` O valor no nível superior agora sobrescreveu o valor do subchart. Há um detalhe importante a notar aqui. Não alteramos o template de `mychart/charts/mysubchart/templates/configmap.yaml` para apontar para `.Values.mysubchart.dessert`. Da perspectiva desse template, o valor ainda está localizado em `.Values.dessert`. À medida que o motor de templates passa os values, ele define o escopo. Então, para os templates do `mysubchart`, apenas values específicos para `mysubchart` estarão disponíveis em `.Values`. Às vezes, porém, você quer que certos values estejam disponíveis para todos os templates. Isso é realizado usando valores globais de chart. ## Valores Globais de Chart Valores globais são values que podem ser acessados de qualquer chart ou subchart pelo exato mesmo nome. Valores globais requerem declaração explícita. Você não pode usar um valor não-global existente como se fosse global. O tipo de dados Values possui uma seção reservada chamada `Values.global` onde valores globais podem ser definidos. Vamos definir um no nosso arquivo `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Devido à forma como os valores globais funcionam, tanto `mychart/templates/configmap.yaml` quanto `mysubchart/templates/configmap.yaml` devem ser capazes de acessar esse valor como `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Agora, se executarmos uma instalação dry run, veremos o mesmo valor em ambas as saídas: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Valores globais são úteis para passar informações assim, embora exija algum planejamento para garantir que os templates corretos estejam configurados para usar valores globais. ## Compartilhando Templates com Subcharts Charts pai e subcharts podem compartilhar templates. Qualquer bloco definido em qualquer chart está disponível para outros charts. Por exemplo, podemos definir um template simples assim: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Lembre-se de como os labels em templates são _globalmente compartilhados_. Assim, o chart `labels` pode ser incluído de qualquer outro chart. Embora desenvolvedores de charts possam escolher entre `include` e `template`, uma vantagem de usar `include` é que `include` pode referenciar templates dinamicamente: ```yaml {{ include $mytemplate }} ``` O código acima desreferencia `$mytemplate`. A função `template`, em contraste, aceita apenas uma string literal. ## Evite Usar Blocks A linguagem de template Go fornece uma palavra-chave `block` que permite aos desenvolvedores fornecer uma implementação padrão que é sobrescrita posteriormente. Em charts do Helm, blocks não são a melhor ferramenta para sobrescrita porque, se múltiplas implementações do mesmo block forem fornecidas, a selecionada é imprevisível. A recomendação é usar `include` em vez disso. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Arquivos de Values description: Instruções sobre como utilizar a flag --values. sidebar_position: 4 --- Na seção anterior, vimos os objetos embutidos que os templates do Helm oferecem. Um dos objetos embutidos é `Values`. Este objeto fornece acesso aos valores passados para o chart. Seu conteúdo pode vir de múltiplas fontes: - O arquivo `values.yaml` no chart - Se este for um subchart, o arquivo `values.yaml` de um chart pai - Um arquivo de values passado ao `helm install` ou `helm upgrade` com a flag `-f` (`helm install -f myvals.yaml ./mychart`) - Parâmetros individuais passados com `--set` (como `helm install --set foo=bar ./mychart`) A lista acima está em ordem de especificidade: `values.yaml` é o padrão, que pode ser sobrescrito pelo `values.yaml` de um chart pai, que por sua vez pode ser sobrescrito por um arquivo de values fornecido pelo usuário, que por sua vez pode ser sobrescrito por parâmetros `--set`. Arquivos de values são arquivos YAML simples. Vamos editar `mychart/values.yaml` e depois editar nosso template de ConfigMap. Removendo os valores padrão em `values.yaml`, vamos definir apenas um parâmetro: ```yaml favoriteDrink: coffee ``` Agora podemos usar isso dentro de um template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Observe que na última linha acessamos `favoriteDrink` como um atributo de `Values`: `{{ .Values.favoriteDrink }}`. Vamos ver como isso é renderizado. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Como `favoriteDrink` está definido no arquivo `values.yaml` padrão como `coffee`, esse é o valor exibido no template. Podemos facilmente sobrescrever isso adicionando a flag `--set` na nossa chamada ao `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Como `--set` tem maior precedência que o arquivo `values.yaml` padrão, nosso template gera `drink: slurm`. Arquivos de values também podem conter conteúdo mais estruturado. Por exemplo, podemos criar uma seção `favorite` no nosso arquivo `values.yaml` e adicionar várias chaves nela: ```yaml favorite: drink: coffee food: pizza ``` Agora precisamos modificar ligeiramente o template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Embora seja possível estruturar dados dessa forma, a recomendação é manter suas árvores de values rasas, favorecendo a simplicidade. Quando vermos como atribuir values a subcharts, entenderemos como os values são nomeados usando uma estrutura de árvore. ## Excluindo uma chave padrão Se você precisar excluir uma chave dos values padrão, pode sobrescrever o valor da chave para `null`, e nesse caso o Helm removerá a chave da mesclagem de values sobrescritos. Por exemplo, o chart stable do Drupal permite configurar o liveness probe, caso você configure uma imagem personalizada. Aqui estão os values padrão: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Se você tentar sobrescrever o handler do livenessProbe para `exec` em vez de `httpGet` usando `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, o Helm irá mesclar as chaves padrão e sobrescritas, resultando no seguinte YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` No entanto, o Kubernetes falharia porque não é possível declarar mais de um handler de livenessProbe. Para contornar isso, você pode instruir o Helm a excluir o `livenessProbe.httpGet` definindo-o como null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` Neste ponto, já vimos vários objetos embutidos e os utilizamos para injetar informações em um template. Agora vamos analisar outro aspecto do motor de templates: funções e pipelines. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Variáveis description: Usando variáveis em templates. sidebar_position: 8 --- Com funções, pipelines, objetos e estruturas de controle em mãos, podemos passar para uma das ideias mais básicas em muitas linguagens de programação: variáveis. Em templates, elas são usadas com menos frequência. Mas veremos como utilizá-las para simplificar o código e fazer melhor uso de `with` e `range`. Em um exemplo anterior, vimos que este código vai falhar: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` não está dentro do escopo restrito pelo bloco `with`. Uma forma de contornar problemas de escopo é atribuir objetos a variáveis que podem ser acessadas fora do escopo atual. Em templates do Helm, uma variável é uma referência nomeada para outro objeto. Ela segue a forma `$nome`. Variáveis são atribuídas com um operador especial de atribuição: `:=`. Podemos reescrever o exemplo acima para usar uma variável para `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Observe que antes de iniciar o bloco `with`, atribuímos `$relname := .Release.Name`. Agora, dentro do bloco `with`, a variável `$relname` ainda aponta para o nome da release. Ao executar, teremos: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Variáveis são particularmente úteis em loops `range`. Elas podem ser usadas em objetos do tipo lista para capturar tanto o índice quanto o valor: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Note que `range` vem primeiro, depois as variáveis, em seguida o operador de atribuição e por fim a lista. Isso atribuirá o índice inteiro (começando do zero) a `$index` e o valor a `$topping`. O resultado será: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Para estruturas de dados que possuem tanto uma chave quanto um valor, podemos usar `range` para obter ambos. Por exemplo, podemos iterar sobre `.Values.favorite` desta forma: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Agora, na primeira iteração, `$key` será `drink` e `$val` será `coffee`, e na segunda, `$key` será `food` e `$val` será `pizza`. Executar o exemplo acima irá gerar: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Variáveis normalmente não são "globais". Elas têm escopo limitado ao bloco onde foram declaradas. Anteriormente, atribuímos `$relname` no nível superior do template. Essa variável estará disponível em todo o template. Mas no nosso último exemplo, `$key` e `$val` só estarão disponíveis dentro do bloco `{{ range... }}{{ end }}`. No entanto, há uma variável que sempre aponta para o contexto raiz: `$`. Isso pode ser muito útil quando você está iterando em um range e precisa saber o nome da release do chart. Um exemplo ilustrando isso: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Muitos templates do Helm usariam `.` abaixo, mas isso não funcionará, # porém `$` funcionará aqui app.kubernetes.io/name: {{ template "fullname" $ }} # Não posso referenciar .Chart.Name, mas posso fazer $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Valor de appVersion em Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` Até agora vimos apenas um template declarado em um único arquivo. Mas um dos recursos poderosos da linguagem de templates do Helm é a capacidade de declarar múltiplos templates e usá-los juntos. Abordaremos isso na próxima seção. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Próximos Passos description: Finalizando - alguns apontamentos úteis para outras documentações que irão ajudá-lo. sidebar_position: 14 --- Este guia tem o objetivo de fornecer a você, desenvolvedor de charts, uma compreensão sólida de como utilizar a linguagem de templates do Helm. O guia foca nos aspectos técnicos do desenvolvimento de templates. Mas há muitas coisas que este guia não cobriu quando se trata do desenvolvimento prático do dia a dia de charts. Aqui estão alguns apontamentos úteis para outras documentações que irão ajudá-lo na criação de novos charts: - O [Artifact Hub](https://artifacthub.io/packages/search?kind=0) da CNCF é uma fonte indispensável de charts. - A [Documentação](https://kubernetes.io/docs/home/) do Kubernetes fornece exemplos detalhados dos diversos tipos de recursos que você pode utilizar, desde ConfigMaps e Secrets até DaemonSets e Deployments. - O [Guia de Charts](/topics/charts.md) do Helm explica o fluxo de trabalho com charts. - O [Guia de Hooks de Charts](/topics/charts_hooks.md) do Helm explica como criar lifecycle hooks. - O artigo [Dicas e Truques para Charts](/howto/charts_tips_and_tricks.md) do Helm fornece algumas dicas úteis para escrever charts. - A [documentação do Sprig](https://github.com/Masterminds/sprig) documenta mais de sessenta funções de template. - A [documentação de templates Go](https://godoc.org/text/template) explica a sintaxe de templates em detalhes. - A [ferramenta Schelm](https://github.com/databus23/schelm) é um utilitário auxiliar útil para depuração de charts. Às vezes é mais fácil fazer algumas perguntas e obter respostas de desenvolvedores experientes. O melhor lugar para isso é nos canais do Helm no [Slack do Kubernetes](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Por fim, se você encontrar erros ou omissões neste documento, quiser sugerir algum novo conteúdo, ou gostaria de contribuir, visite o [Projeto Helm](https://github.com/helm/helm-www). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Apêndice: Técnicas de YAML" description: Uma análise mais detalhada da especificação YAML e como ela se aplica ao Helm. sidebar_position: 15 --- A maior parte deste guia foi focada em escrever a linguagem de template. Aqui, vamos analisar o formato YAML. O YAML tem alguns recursos úteis que nós, como autores de templates, podemos usar para tornar nossos templates menos propensos a erros e mais fáceis de ler. ## Escalares e Coleções De acordo com a [especificação YAML](https://yaml.org/spec/1.2/spec.html), existem dois tipos de coleções e muitos tipos escalares. Os dois tipos de coleções são mapas e sequências: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Valores escalares são valores individuais (em oposição a coleções) ### Tipos Escalares em YAML No dialeto YAML do Helm, o tipo de dados escalar de um valor é determinado por um conjunto complexo de regras, incluindo o schema do Kubernetes para definições de recursos. Mas ao inferir tipos, as seguintes regras geralmente se aplicam. Se um inteiro ou float for uma palavra simples sem aspas, ele é tipicamente tratado como um tipo numérico: ```yaml count: 1 size: 2.34 ``` Mas se estiverem entre aspas, são tratados como strings: ```yaml count: "1" # <-- string, não int size: '2.34' # <-- string, não float ``` O mesmo vale para booleanos: ```yaml isGood: true # bool answer: "true" # string ``` A palavra para um valor vazio é `null` (não `nil`). Note que `port: "80"` é YAML válido e passará tanto pelo motor de template quanto pelo parser YAML, mas falhará se o Kubernetes esperar que `port` seja um inteiro. Em alguns casos, você pode forçar uma inferência de tipo específica usando tags de tipo YAML: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` No exemplo acima, `!!str` informa ao parser que `age` é uma string, mesmo que pareça um int. E `port` é tratado como int, mesmo estando entre aspas. ## Strings em YAML Grande parte dos dados que colocamos em documentos YAML são strings. O YAML tem mais de uma maneira de representar uma string. Esta seção explica as diferentes formas e demonstra como usar algumas delas. Existem três formas "inline" de declarar uma string: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Todos os estilos inline devem estar em uma única linha. - Palavras simples não têm aspas e não são escapadas. Por isso, você precisa ter cuidado com os caracteres que usa. - Strings com aspas duplas podem ter caracteres específicos escapados com `\`. Por exemplo `"\"Hello\", she said"`. Você pode escapar quebras de linha com `\n`. - Strings com aspas simples são strings "literais" e não usam `\` para escapar caracteres. A única sequência de escape é `''`, que é decodificada como um único `'`. Além das strings de uma linha, você pode declarar strings de múltiplas linhas: ```yaml coffee: | Latte Cappuccino Espresso ``` O exemplo acima tratará o valor de `coffee` como uma única string equivalente a `Latte\nCappuccino\nEspresso\n`. Note que a primeira linha após o `|` deve estar corretamente indentada. Então poderíamos quebrar o exemplo acima fazendo isso: ```yaml coffee: | Latte Cappuccino Espresso ``` Como `Latte` está incorretamente indentado, teríamos um erro como este: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` Em templates, às vezes é mais seguro colocar uma "primeira linha" fictícia de conteúdo em um documento de múltiplas linhas para proteção contra o erro acima: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Seja qual for essa primeira linha, ela será preservada na saída da string. Então, se você estiver usando essa técnica para injetar o conteúdo de um arquivo em um ConfigMap, o comentário deve ser do tipo esperado por qualquer coisa que esteja lendo essa entrada. ### Controlando Espaços em Strings de Múltiplas Linhas No exemplo acima, usamos `|` para indicar uma string de múltiplas linhas. Mas note que o conteúdo da nossa string era seguido por um `\n` final. Se quisermos que o processador YAML remova a nova linha final, podemos adicionar um `-` após o `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Agora o valor de `coffee` será: `Latte\nCappuccino\nEspresso` (sem o `\n` final). Outras vezes, podemos querer preservar todos os espaços em branco finais. Podemos fazer isso com a notação `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Agora o valor de `coffee` será `Latte\nCappuccino\nEspresso\n\n\n`. A indentação dentro de um bloco de texto é preservada e resulta na preservação de quebras de linha também: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` No caso acima, `coffee` será `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indentação e Templates Ao escrever templates, você pode precisar injetar o conteúdo de um arquivo no template. Como vimos em capítulos anteriores, existem duas maneiras de fazer isso: - Use `{{ .Files.Get "FILENAME" }}` para obter o conteúdo de um arquivo no chart. - Use `{{ include "TEMPLATE" . }}` para renderizar um template e então colocar seu conteúdo no chart. Ao inserir arquivos em YAML, é bom entender as regras de múltiplas linhas acima. Frequentemente, a maneira mais fácil de inserir um arquivo estático é fazer algo como isto: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Note como fazemos a indentação acima: `indent 2` instrui o motor de template a indentar cada linha em "myfile.txt" com dois espaços. Note que não indentamos essa linha de template. Isso porque, se fizéssemos, o conteúdo do arquivo da primeira linha seria indentado duas vezes. ### Strings de Múltiplas Linhas Dobradas Às vezes você quer representar uma string em seu YAML com múltiplas linhas, mas quer que ela seja tratada como uma única linha longa quando interpretada. Isso é chamado de "dobramento" (folding). Para declarar um bloco dobrado, use `>` em vez de `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` O valor de `coffee` acima será `Latte Cappuccino Espresso\n`. Note que todas as quebras de linha, exceto a última, serão convertidas em espaços. Você pode combinar os controles de espaço em branco com o marcador de texto dobrado, então `>-` substituirá ou removerá todas as novas linhas. Note que na sintaxe dobrada, indentar o texto fará com que as linhas sejam preservadas. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` O exemplo acima produzirá `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Note que tanto o espaçamento quanto as novas linhas ainda estão lá. ## Incorporando Múltiplos Documentos em Um Arquivo É possível colocar mais de um documento YAML em um único arquivo. Isso é feito prefixando um novo documento com `---` e terminando o documento com `...` ```yaml --- document: 1 ... --- document: 2 ... ``` Em muitos casos, tanto o `---` quanto o `...` podem ser omitidos. Alguns arquivos no Helm não podem conter mais de um documento. Se, por exemplo, mais de um documento for fornecido dentro de um arquivo `values.yaml`, apenas o primeiro será usado. Arquivos de template, no entanto, podem ter mais de um documento. Quando isso acontece, o arquivo (e todos os seus documentos) é tratado como um objeto durante a renderização do template. Mas então o YAML resultante é dividido em múltiplos documentos antes de ser enviado ao Kubernetes. Recomendamos usar múltiplos documentos por arquivo apenas quando for absolutamente necessário. Ter múltiplos documentos em um arquivo pode ser difícil de depurar. ## YAML é um Superconjunto de JSON Como YAML é um superconjunto de JSON, qualquer documento JSON válido _deve_ ser YAML válido. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` O exemplo acima é outra forma de representar isto: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` E os dois podem ser misturados (com cuidado): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Todos os três devem resultar na mesma representação interna. Embora isso signifique que arquivos como `values.yaml` podem conter dados JSON, o Helm não trata a extensão de arquivo `.json` como um sufixo válido. ## Âncoras YAML A especificação YAML fornece uma maneira de armazenar uma referência a um valor e depois referir-se a esse valor por referência. O YAML chama isso de "ancoragem": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` No exemplo acima, `&favoriteCoffee` define uma referência para `Cappuccino`. Depois, essa referência é usada como `*favoriteCoffee`. Então `coffees` se torna `Latte, Cappuccino, Espresso`. Embora existam alguns casos em que âncoras são úteis, há um aspecto delas que pode causar bugs sutis: Na primeira vez que o YAML é consumido, a referência é expandida e depois descartada. Então, se decodificássemos e depois recodificássemos o exemplo acima, o YAML resultante seria: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Como o Helm e o Kubernetes frequentemente leem, modificam e depois reescrevem arquivos YAML, as âncoras serão perdidas. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Mudanças Desde o Helm 2 sidebar_position: 1 --- ## Mudanças desde o Helm 2 Aqui está uma lista completa de todas as principais mudanças introduzidas no Helm 3. ### Remoção do Tiller Durante o ciclo de desenvolvimento do Helm 2, introduzimos o Tiller. O Tiller teve um papel importante para equipes que trabalhavam em um cluster compartilhado — ele tornava possível que vários operadores diferentes interagissem com o mesmo conjunto de releases. Com o controle de acesso baseado em funções (RBAC) habilitado por padrão no Kubernetes 1.6, restringir o Tiller para uso em cenários de produção se tornou mais difícil de gerenciar. Devido ao grande número de possíveis políticas de segurança, nossa posição era fornecer uma configuração permissiva por padrão. Isso permitia que usuários iniciantes começassem a experimentar o Helm e o Kubernetes sem ter que mergulhar de cabeça nos controles de segurança. Infelizmente, essa configuração permissiva podia conceder a um usuário uma ampla gama de permissões que ele não deveria ter. DevOps e SREs precisavam aprender etapas operacionais adicionais ao instalar o Tiller em um cluster multi-tenant. Após ouvir como os membros da comunidade estavam usando o Helm em determinados cenários, descobrimos que o sistema de gerenciamento de releases do Tiller não precisava depender de um operador no cluster para manter o estado ou atuar como um hub central para informações de releases do Helm. Em vez disso, podíamos simplesmente buscar informações do servidor de API do Kubernetes, renderizar os Charts no lado do cliente e armazenar um registro da instalação no Kubernetes. O objetivo principal do Tiller podia ser alcançado sem o Tiller, então uma das primeiras decisões que tomamos em relação ao Helm 3 foi remover completamente o Tiller. Com o Tiller removido, o modelo de segurança do Helm foi radicalmente simplificado. O Helm 3 agora suporta todos os recursos modernos de segurança, identidade e autorização do Kubernetes moderno. As permissões do Helm são avaliadas usando seu [arquivo kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Os administradores de cluster podem restringir as permissões dos usuários na granularidade que considerarem adequada. As releases ainda são registradas no cluster, e o restante da funcionalidade do Helm permanece inalterado. ### Estratégia de Upgrade Aprimorada: 3-way Strategic Merge Patches O Helm 2 usava um patch de mesclagem estratégica de duas vias. Durante um upgrade, ele comparava o manifesto do chart mais recente com o manifesto do chart proposto (aquele fornecido durante o `helm upgrade`). Ele comparava as diferenças entre esses dois charts para determinar quais mudanças precisavam ser aplicadas aos recursos no Kubernetes. Se alterações fossem aplicadas ao cluster fora de banda (como durante um `kubectl edit`), essas alterações não eram consideradas. Isso resultava em recursos que não conseguiam reverter para seu estado anterior: como o Helm considerava apenas o manifesto do último chart aplicado como seu estado atual, se não houvesse mudanças no estado do chart, o estado ativo permanecia inalterado. No Helm 3, agora usamos um patch de mesclagem estratégica de três vias. O Helm considera o manifesto antigo, seu estado ativo e o novo manifesto ao gerar um patch. #### Exemplos Vamos examinar alguns exemplos comuns de como essa mudança impacta. ##### Revertendo quando o estado ativo foi alterado Sua equipe acabou de implantar a aplicação em produção no Kubernetes usando o Helm. O chart contém um objeto Deployment onde o número de réplicas está configurado como três: ```console $ helm install myapp ./myapp ``` Um novo desenvolvedor entra na equipe. No primeiro dia, enquanto observa o cluster de produção, acontece um acidente com café derramado no teclado e ele acaba executando `kubectl scale` no deployment de produção, reduzindo de três réplicas para zero. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Outro desenvolvedor da sua equipe percebe que o site de produção está fora do ar e decide reverter a release para seu estado anterior: ```console $ helm rollback myapp ``` O que acontece? No Helm 2, ele geraria um patch comparando o manifesto antigo com o novo manifesto. Como é um rollback, é o mesmo manifesto. O Helm determinaria que não há nada a mudar porque não há diferença entre o manifesto antigo e o novo manifesto. A contagem de réplicas continua em zero. Pânico geral. No Helm 3, o patch é gerado usando o manifesto antigo, o estado ativo e o novo manifesto. O Helm reconhece que o estado antigo era três, o estado ativo é zero e o novo manifesto deseja alterá-lo de volta para três, então ele gera um patch para mudar o estado de volta para três. ##### Upgrades quando o estado ativo foi alterado Muitas service meshes e outras aplicações baseadas em controllers injetam dados nos objetos do Kubernetes. Isso pode ser algo como um sidecar, labels ou outras informações. Anteriormente, se você tivesse o seguinte manifesto renderizado a partir de um Chart: ```yaml containers: - name: server image: nginx:2.0.0 ``` E o estado ativo fosse modificado por outra aplicação para ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Agora, você quer atualizar a tag da imagem `nginx` para `2.1.0`. Então, você faz upgrade para um chart com o seguinte manifesto: ```yaml containers: - name: server image: nginx:2.1.0 ``` O que acontece? No Helm 2, o Helm gera um patch do objeto `containers` entre o manifesto antigo e o novo manifesto. O estado ativo do cluster não é considerado durante a geração do patch. O estado ativo do cluster é modificado para ficar assim: ```yaml containers: - name: server image: nginx:2.1.0 ``` O pod sidecar é removido do estado ativo. Mais pânico. No Helm 3, o Helm gera um patch do objeto `containers` entre o manifesto antigo, o estado ativo e o novo manifesto. Ele nota que o novo manifesto muda a tag da imagem para `2.1.0`, mas o estado ativo contém um container sidecar. O estado ativo do cluster é modificado para ficar assim: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Nomes de Releases Agora Têm Escopo por Namespace Com a remoção do Tiller, as informações sobre cada release precisavam ser armazenadas em algum lugar. No Helm 2, isso era armazenado no mesmo namespace que o Tiller. Na prática, isso significava que uma vez que um nome era usado por uma release, nenhuma outra release podia usar esse mesmo nome, mesmo se fosse implantada em um namespace diferente. No Helm 3, as informações sobre uma release específica agora são armazenadas no mesmo namespace que a própria release. Isso significa que os usuários agora podem executar `helm install wordpress stable/wordpress` em dois namespaces separados, e cada um pode ser referenciado com `helm list` alterando o contexto do namespace atual (por exemplo, `helm list --namespace foo`). Com esse maior alinhamento aos namespaces nativos do cluster, o comando `helm list` não lista mais todas as releases por padrão. Em vez disso, ele listará apenas as releases no namespace do seu contexto atual do Kubernetes (ou seja, o namespace mostrado quando você executa `kubectl config view --minify`). Isso também significa que você deve fornecer a flag `--all-namespaces` ao `helm list` para obter um comportamento similar ao do Helm 2. ### Secrets como Driver de Armazenamento Padrão No Helm 3, Secrets agora são usados como o [driver de armazenamento padrão](/topics/advanced.md#storage-backends). O Helm 2 usava ConfigMaps por padrão para armazenar informações de releases. No Helm 2.7.0, um novo backend de armazenamento que usa Secrets para armazenar informações de releases foi implementado, e agora é o padrão a partir do Helm 3. A mudança para Secrets como padrão no Helm 3 permite segurança adicional na proteção de charts em conjunto com o lançamento da criptografia de Secrets no Kubernetes. [Criptografar secrets em repouso](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) tornou-se disponível como um recurso alpha no Kubernetes 1.7 e se tornou estável a partir do Kubernetes 1.13. Isso permite que os usuários criptografem os metadados de releases do Helm em repouso, sendo um bom ponto de partida que pode ser expandido posteriormente para usar algo como o Vault. ### Mudanças no Caminho de Import do Go No Helm 3, o Helm alterou o caminho de import do Go de `k8s.io/helm` para `helm.sh/helm/v3`. Se você pretende atualizar para as bibliotecas cliente do Helm 3 em Go, certifique-se de alterar seus caminhos de import. ### Capabilities O objeto embutido `.Capabilities` disponível durante o estágio de renderização foi simplificado. [Objetos Embutidos](/chart_template_guide/builtin_objects.md) ### Validando Valores de Charts com JSONSchema Um JSON Schema agora pode ser imposto sobre os valores do chart. Isso garante que os valores fornecidos pelo usuário sigam o schema definido pelo mantenedor do chart, fornecendo melhor relatório de erros quando o usuário fornece um conjunto incorreto de valores para um chart. A validação ocorre quando qualquer um dos seguintes comandos é invocado: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Consulte a documentação sobre [Arquivos de Schema](/topics/charts.md#schema-files) para mais informações. ### Consolidação do `requirements.yaml` no `Chart.yaml` O sistema de gerenciamento de dependências de Charts foi movido de requirements.yaml e requirements.lock para Chart.yaml e Chart.lock. Recomendamos que novos charts destinados ao Helm 3 usem o novo formato. No entanto, o Helm 3 ainda entende a versão 1 da API de Chart (`v1`) e carregará arquivos `requirements.yaml` existentes. No Helm 2, era assim que um `requirements.yaml` se parecia: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` No Helm 3, a dependência é expressa da mesma forma, mas agora a partir do seu `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Os charts ainda são baixados e colocados no diretório `charts/`, então subcharts incluídos no diretório `charts/` continuarão a funcionar sem modificação. ### Nome (ou --generate-name) Agora é Obrigatório na Instalação No Helm 2, se nenhum nome fosse fornecido, um nome gerado automaticamente seria dado. Em produção, isso provou ser mais um incômodo do que um recurso útil. No Helm 3, o Helm lançará um erro se nenhum nome for fornecido com `helm install`. Para aqueles que ainda desejam que um nome seja gerado automaticamente, você pode usar a flag `--generate-name` para criar um para você. ### Enviando Charts para Registries OCI Este é um recurso experimental introduzido no Helm 3. Para usar, defina a variável de ambiente `HELM_EXPERIMENTAL_OCI=1`. De forma geral, um Repositório de Charts é um local onde Charts podem ser armazenados e compartilhados. O cliente Helm empacota e envia Charts do Helm para um Repositório de Charts. Simplificando, um Repositório de Charts é um servidor HTTP básico que hospeda um arquivo index.yaml e alguns charts empacotados. Embora haja vários benefícios na API do Repositório de Charts atender aos requisitos de armazenamento mais básicos, algumas desvantagens começaram a aparecer: - Repositórios de Charts têm muita dificuldade em abstrair a maioria das implementações de segurança exigidas em um ambiente de produção. Ter uma API padrão para autenticação e autorização é muito importante em cenários de produção. - As ferramentas de proveniência de Charts do Helm usadas para assinar e verificar a integridade e origem de um chart são uma parte opcional do processo de publicação de Charts. - Em cenários multi-tenant, o mesmo Chart pode ser enviado por outro tenant, custando o dobro do custo de armazenamento para armazenar o mesmo conteúdo. Repositórios de charts mais inteligentes foram projetados para lidar com isso, mas não faz parte da especificação formal. - Usar um único arquivo de índice para pesquisa, informações de metadados e busca de Charts tornou difícil ou desajeitado projetar implementações multi-tenant seguras. O projeto Distribution do Docker (também conhecido como Docker Registry v2) é o sucessor do projeto Docker Registry. Muitos grandes provedores de nuvem têm uma oferta de produto do projeto Distribution, e com tantos fornecedores oferecendo o mesmo produto, o projeto Distribution se beneficiou de muitos anos de hardening, melhores práticas de segurança e testes extensivos em produção. Por favor, consulte `helm help chart` e `helm help registry` para mais informações sobre como empacotar um chart e enviá-lo para um registro Docker. Para mais informações, consulte [esta página](/topics/registries.md). ### Remoção do `helm serve` O `helm serve` executava um Repositório de Charts local na sua máquina para fins de desenvolvimento. No entanto, ele não recebeu muita adoção como ferramenta de desenvolvimento e tinha vários problemas com seu design. No final, decidimos removê-lo e separá-lo como um plugin. Para uma experiência similar ao `helm serve`, dê uma olhada na opção de armazenamento em sistema de arquivos local no [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) e no [plugin servecm](https://github.com/jdolitsky/helm-servecm). ### Suporte a Library Charts O Helm 3 suporta uma classe de chart chamada "library chart". Este é um chart que é compartilhado por outros charts, mas não cria nenhum artefato de release próprio. Os templates de um library chart podem apenas declarar elementos `define`. Conteúdo de escopo global que não seja `define` é simplesmente ignorado. Isso permite que os usuários reutilizem e compartilhem trechos de código que podem ser reutilizados em muitos charts, evitando redundância e mantendo os charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Library charts são declarados na diretiva dependencies no Chart.yaml e são instalados e gerenciados como qualquer outro chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Estamos muito empolgados em ver os casos de uso que esse recurso abre para desenvolvedores de charts, bem como quaisquer melhores práticas que surjam do consumo de library charts. ### Atualização da apiVersion do Chart.yaml Com a introdução do suporte a library charts e a consolidação do requirements.yaml no Chart.yaml, clientes que entendiam o formato de pacote do Helm 2 não entenderão esses novos recursos. Então, atualizamos a apiVersion no Chart.yaml de `v1` para `v2`. O `helm create` agora cria charts usando este novo formato, então a apiVersion padrão também foi atualizada lá. Clientes que desejam suportar ambas as versões de charts do Helm devem inspecionar o campo `apiVersion` no Chart.yaml para entender como analisar o formato do pacote. ### Suporte ao XDG Base Directory A [Especificação XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) é um padrão portável que define onde arquivos de configuração, dados e cache devem ser armazenados no sistema de arquivos. No Helm 2, o Helm armazenava todas essas informações em `~/.helm` (carinhosamente conhecido como `helm home`), que podia ser alterado definindo a variável de ambiente `$HELM_HOME` ou usando a flag global `--home`. No Helm 3, o Helm agora respeita as seguintes variáveis de ambiente conforme a Especificação XDG Base Directory: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Os plugins do Helm ainda recebem `$HELM_HOME` como um alias para `$XDG_DATA_HOME` para compatibilidade com plugins que procuram usar `$HELM_HOME` como um ambiente de rascunho. Várias novas variáveis de ambiente também são passadas para o ambiente do plugin para acomodar essa mudança: - `$HELM_PATH_CACHE` para o caminho de cache - `$HELM_PATH_CONFIG` para o caminho de configuração - `$HELM_PATH_DATA` para o caminho de dados Plugins do Helm que desejam suportar o Helm 3 devem considerar o uso dessas novas variáveis de ambiente. ### Renomeação de Comandos CLI Para melhor alinhar a terminologia com outros gerenciadores de pacotes, `helm delete` foi renomeado para `helm uninstall`. O `helm delete` ainda é mantido como um alias para `helm uninstall`, então qualquer uma das formas pode ser usada. No Helm 2, para limpar o registro da release, a flag `--purge` precisava ser fornecida. Essa funcionalidade agora está habilitada por padrão. Para manter o comportamento anterior, use `helm uninstall --keep-history`. Adicionalmente, vários outros comandos foram renomeados para acomodar as mesmas convenções: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Esses comandos também mantiveram seus verbos antigos como aliases, então você pode continuar a usá-los em qualquer forma. ### Criação Automática de Namespaces Ao criar uma release em um namespace que não existe, o Helm 2 criava o namespace. O Helm 3 segue o comportamento de outras ferramentas do Kubernetes e retorna um erro se o namespace não existir. O Helm 3 criará o namespace se você especificar explicitamente a flag `--create-namespace`. ### O que aconteceu com .Chart.ApiVersion? O Helm segue a convenção típica de CamelCasing, que é capitalizar um acrônimo. Fizemos isso em outros lugares no código, como com `.Capabilities.APIVersions.Has`. No Helm v3, corrigimos `.Chart.ApiVersion` para seguir esse padrão, renomeando-o para `.Chart.APIVersion`. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Instalação sidebar_position: 2 --- ## Instalação ### Por que não existem pacotes nativos do Helm para Fedora e outras distribuições Linux? O projeto Helm não mantém pacotes para sistemas operacionais e ambientes. A comunidade do Helm pode fornecer pacotes nativos e, se o projeto Helm tiver conhecimento deles, serão listados. Foi assim que a fórmula do Homebrew foi criada e listada. Se você tiver interesse em manter um pacote, adoraríamos isso. ### Por que vocês fornecem um script `curl ...|bash`? Existe um script em nosso repositório (`scripts/get-helm-3`) que pode ser executado como um script `curl ..|bash`. As transferências são todas protegidas por HTTPS, e o script faz algumas verificações nos pacotes que baixa. No entanto, o script tem os riscos típicos de qualquer script de shell. Nós o fornecemos porque é útil, mas sugerimos que os usuários leiam o script cuidadosamente primeiro. O que realmente gostaríamos, porém, são versões do Helm mais bem empacotadas. ### Como coloco os arquivos do cliente Helm em um local diferente dos padrões? O Helm usa a estrutura XDG para armazenar arquivos. Existem variáveis de ambiente que você pode usar para substituir esses locais: - `$XDG_CACHE_HOME`: define um local alternativo para armazenar arquivos em cache. - `$XDG_CONFIG_HOME`: define um local alternativo para armazenar a configuração do Helm. - `$XDG_DATA_HOME`: define um local alternativo para armazenar dados do Helm. Note que, se você tiver repositórios existentes, precisará adicioná-los novamente com `helm repo add...`. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Solução de Problemas sidebar_position: 4 --- ## Solução de Problemas ### Estou recebendo um aviso sobre "Unable to get an update from the 'stable' chart repository" Execute `helm repo list`. Se mostrar que o seu repositório `stable` aponta para uma URL `storage.googleapis.com`, você precisará atualizar esse repositório. Em 13 de novembro de 2020, o repositório de Charts do Helm [deixou de ser suportado](https://github.com/helm/charts#deprecation-timeline) após um ano de depreciação. Um arquivo está disponível em `https://charts.helm.sh/stable`, mas não receberá mais atualizações. Você pode executar o seguinte comando para corrigir o seu repositório: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` O mesmo vale para o repositório `incubator`, que tem um arquivo disponível em https://charts.helm.sh/incubator. Você pode executar o seguinte comando para corrigi-lo: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Estou recebendo o aviso 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' O antigo repositório de charts do Google foi substituído por um novo repositório de charts do Helm. Execute o seguinte comando para corrigir isso permanentemente: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Se você receber um erro semelhante para o `incubator`, execute este comando: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Quando adiciono um repositório Helm, recebo o erro 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Os repositórios de Charts do Helm não são mais suportados após [um período de depreciação de um ano](https://github.com/helm/charts#deprecation-timeline). Arquivos desses repositórios estão disponíveis em `https://charts.helm.sh/stable` e `https://charts.helm.sh/incubator`, porém não receberão mais atualizações. O comando `helm repo add` não permitirá que você adicione as URLs antigas, a menos que especifique `--use-deprecated-repos`. ### No GKE (Google Container Engine) recebo "No SSH tunnels currently open" ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Outra variação da mensagem de erro é: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` O problema é que o seu arquivo de configuração local do Kubernetes deve ter as credenciais corretas. Quando você cria um cluster no GKE, ele fornece credenciais, incluindo certificados SSL e autoridades certificadoras. Esses precisam ser armazenados em um arquivo de configuração do Kubernetes (Padrão: `~/.kube/config`) para que `kubectl` e `helm` possam acessá-los. ### Após a migração do Helm 2, `helm list` mostra apenas algumas (ou nenhuma) das minhas releases Provavelmente você não percebeu que o Helm 3 agora usa namespaces do cluster para definir o escopo das releases. Isso significa que, para todos os comandos que referenciam uma release, você deve: * usar o namespace atual no contexto ativo do Kubernetes (conforme mostrado pelo comando `kubectl config view --minify`), * especificar o namespace correto usando a flag `--namespace`/`-n`, ou * para o comando `helm list`, especificar a flag `--all-namespaces`/`-A` Isso se aplica a `helm ls`, `helm uninstall` e todos os outros comandos `helm` que referenciam uma release. ### No macOS, o arquivo `/etc/.mdns_debug` é acessado. Por quê? Temos conhecimento de um caso no macOS em que o Helm tenta acessar um arquivo chamado `/etc/.mdns_debug`. Se o arquivo existir, o Helm mantém o handle do arquivo aberto enquanto executa. Isso é causado pela biblioteca MDNS do macOS. Ela tenta carregar esse arquivo para ler configurações de depuração (se habilitadas). O handle do arquivo provavelmente não deveria permanecer aberto, e esse problema foi reportado à Apple. No entanto, é o macOS, não o Helm, que causa esse comportamento. Se você não quiser que o Helm carregue esse arquivo, você pode compilar o Helm como uma biblioteca estática que não usa a pilha de rede do host. Fazer isso aumentará o tamanho do binário do Helm, mas impedirá que o arquivo seja aberto. Esse problema foi inicialmente sinalizado como um potencial problema de segurança. Mas desde então foi determinado que não há falha ou vulnerabilidade causada por esse comportamento. ### helm repo add falha quando funcionava antes No Helm 3.3.1 e anteriores, o comando `helm repo add ` não exibia nenhuma saída se você tentasse adicionar um repositório que já existe. A flag `--no-update` geraria um erro se o repositório já estivesse registrado. No Helm 3.3.2 e posteriores, uma tentativa de adicionar um repositório existente resultará em erro: `Error: repository name (reponame) already exists, please specify a different name` O comportamento padrão agora é invertido. `--no-update` agora é ignorado, enquanto se você quiser substituir (sobrescrever) um repositório existente, você pode usar `--force-update`. Essa mudança foi feita por motivos de segurança, conforme explicado nas [notas de release do Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Habilitando logs do cliente Kubernetes A impressão de mensagens de log para depuração do cliente Kubernetes pode ser habilitada usando as flags do [klog](https://pkg.go.dev/k8s.io/klog). Usar a flag `-v` para definir o nível de verbosidade será suficiente para a maioria dos casos. Por exemplo: ``` helm list -v 6 ``` ### Instalações do Tiller pararam de funcionar e o acesso é negado As releases do Helm costumavam estar disponíveis em . Conforme explicado em ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/), a localização oficial mudou em junho de 2019. O [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) disponibiliza todas as imagens antigas do Tiller. Se você está tentando baixar versões mais antigas do Helm do bucket de armazenamento que usava no passado, pode descobrir que elas estão faltando: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` O [local legado das imagens do Tiller](https://gcr.io/kubernetes-helm/tiller) começou a remoção de imagens em agosto de 2021. Disponibilizamos essas imagens no [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Por exemplo, para baixar a versão v2.17.0, substitua: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` por: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Para inicializar com o Helm v2.17.0: `helm init —upgrade` Ou se uma versão diferente for necessária, use a flag --tiller-image para sobrescrever o local padrão e instalar uma versão específica do Helm v2: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Nota:** Os mantenedores do Helm recomendam a migração para uma versão atualmente suportada do Helm. O Helm v2.17.0 foi a release final do Helm v2; o Helm v2 não é mais suportado desde novembro de 2020, conforme detalhado em [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). Muitos CVEs foram identificados no Helm desde então, e essas vulnerabilidades são corrigidas no Helm v3, mas nunca serão corrigidas no Helm v2. Consulte a [lista atual de avisos de segurança publicados do Helm](https://github.com/helm/helm/security/advisories?state=published) e faça um plano para [migrar para o Helm v3](/topics/v2_v3_migration.md) hoje. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Desinstalação sidebar_position: 3 --- ## Desinstalação ### Quero remover minha instalação local do Helm. Onde estão todos os seus arquivos? Além do binário `helm`, o Helm armazena alguns arquivos nos seguintes locais: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME A tabela a seguir mostra a pasta padrão para cada um desses locais, por sistema operacional: | Sistema Operacional | Caminho do Cache | Caminho de Configuração | Caminho de Dados | |---------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: Glossário description: Termos utilizados para descrever a arquitetura do Helm. sidebar_position: 9 --- # Glossário ## Chart É um pacote Helm que contém as informações necessárias para instalar uma série de recursos e manifestos do Kubernetes em um cluster. Os Charts contém um arquivo `Chart.yaml` bem como _templates_ dos manifestos, valores padrão (`values.yaml`), e outras dependêncas. Os Charts são desenvolvidos dentro de uma estrutura de diretório bem definida, e depois empacotados em um formato de arquivo chamado _chart archive_. ## Chart Archive Um _chart archive_ é um Chart compactado, em tar e gzip, (e opcionalmente assinado). ## Dependência de Charts (Subcharts) Charts podem depender de outros Charts. Há duas maneiras que dependência de Charts podem ocorrer: - _Soft dependency_: Um Chart pode não funcionar se um outro Chart não estiver instalado no cluster. O Helm não fornece ferramental para resolver esse caso. Nesse cenário as dependências são gerenciadas separadamente. - _Hard dependency_: Um Chart pode conter (dentro do diretório `charts/`) outro Chart no qual seja dependente. Nesse caso, ao instalar o Chart também será instalado todas as suas dependências. Os Charts e suas dependências são gerenciadas como uma coleção. Quando um Chart é empacotado (via `helm package`) todas as suas _hard dependencies_ são agrupadas com ele. ## Versão do Chart Charts são versionados de acordo com as [especificações da SemVer 2](https://semver.org). Um número de versão é necessário para cada Chart. ## Chart.yaml Informações sobre o Chart são armazenadas num arquivo específico chamado `Chart.yaml`. Cada Chart deve ter esse arquivo. ## Helm (e o cliente helm) Helm é o gerenciador de pacotes para o Kubernetes. Assim como gerenciadores de pacotes facilitam a instalação de ferramentas para sistemas operacionais, o Helm facilita a instalação de aplicações nos clusters Kubernetes. Enquanto _Helm_ (em maiúsculo) é o nome do projeto, a ferramenta de linha de comando também se chama `helm`. Por convenção utiliza-se _Helm_ em maiúsculo ao falar do projeto. Quando se faz referência ao cliente utiliza-se _helm_ em mínusculo. ## Arquivos de configuração do Helm (XDG) O Helm armazena suas configurações em arquivos de diretórios XDG. Esses diretórios são criados quando o `helm` é executado pela primeira vez. ## Kube Config (KUBECONFIG) O cliente helm tenta encontrar as configurações do cluster Kubernetes utilizando como base o arquivo no formato _Kube config_. Por padrão o helm tentará localizá-lo no mesmo local que o `kubectl` o cria (`$HOME/.kube/config`). ## Lint (Formatação de Charts) Formatar um Chart significa validar se este segue as converções e requerimentos padrões de um Chart do Helm. O Helm tem ferramentas de formatação através do comando `helm lint`. ## Linhagem (Arquivo de Linhagem) Os Charts Helm podem ser acompanhados de _arquivos de linhagem_ o qual provêm informações a cerca da origem do Chart e o que ele contém. Arquivos de Linhagem fazem parte do histórico de segurança do Helm. Uma linhagem contém um hash criptografado do arquivo _chart archive_, dados do Chart.yaml, e, um bloco de assinatura (um bloco "clearsign" OpenPGP). Quando utilizados em conjuto com uma chave habilita o usuário a: - Validar se o Chart foi assinado por uma entidade acreditada - Validar se o arquivo do Chart não foi modificado - Validar o conteúdo dos metadados do Chart (`Chart.yaml`) - Correlacionar rapidamente o Chart com os seus dados de linhagem Arquivos de linhagem tem a extensão `.prov`, e podem ser servidos a partir de um _repositório de Charts_ ou qualquer outro servidor HTTP. ## Release Quando um Chart é instalado, a biblioteca do Helm cria uma _release_ para monitorar aquela instalação em particular. Um mesmo Chart pode ser instalado diversas vezes em um mesmo cluster e criar _releases_ diferentes. Por exemplo, uma pessoa pode instalar três bancos de dados PostgreSQL, a partir de um mesmo Chart, rodando o comando `helm install` três vezes com diferentes nomes para cada _release_. ## Número da _Release_ (Versão da _Release_) Uma única _release_ pode ser atualizada diversas vezes. Um contador sequencial é utilizado para monitorar as alterações da _release_. Após o primerio `helm install` do Chart, a _release_ terá um número de _release_ igual a 1. A cada vez que uma release for atualizada ou regredida, a versão da release será **incrementada**. ## Regressão (Rollback) Uma _release_ pode ser atualizada para uma nova configuração do chart. Contudo é possível regredir a uma versão anterior da release, uma vez que o histórico de _releases_ é armazenado. Essa operação é realizada com o comando `helm rollback`. Importante: uma _release_ regredida recebe um novo número de _release_. | Operação | Número da Release | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (mantendo a configuração da release 1) | A tabela acima ilustra como as versões de release são incrementadas entre as operações de instalação, atualização e regressão. ## Biblioteca do Helm (SDK) A biblioteca do Helm (SDK) refere-se ao código em Go que interage diretamente com o API Server do Kubernetes para instalar, atualizar, buscar e remover recursos do Kubernetes. Ela pode ser importada em um projeto para utilizar o Helm como cliente ao invés da CLI. ## Repositório (Repo, Repositório de Charts) Os Charts do Helm podem ser armazenados em servidores dedicados HTTP chamados _repositório de Charts_ (_repositórios_, ou somente _repos_). Um repositório de Charts é simplesmente um servidor HTTP que retorna um arquivo `index.yaml` o qual descreve um grupo de Charts e identifica onde cada Chart pode ser baixado. (Muitos repositórios também hospedam os Charts para serem baixados, além do arquivo `index.yaml`.) O cliente helm pode apontar para zero ou mais repositórios de Charts. Por padrão o cliente helm não é pré-configurado com nenhum repositório. Um repositório pode ser adicionado a qualquer momento através do comando `helm repo add`. ## Valores de Configuração (values.yaml) Valores de configuração são uma forma de sobrescrever valores padrão dos templates com seu próprio conteúdo. Os Charts do Helm são "parametrizados", o que significa dizer que um desenvolvedor pode expôr configurações padrão que podem ser sobrescritas durante a instalação. Por exemplo, um chart pode expôr o campo `username` que permite configurar um nome de usuário para um serviço. Essas variáveis expostas são chamados de _values_ no linguajar do Helm. Os valores podem ser configurados durante as operações de `helm install` e `helm upgrade`, tanto passando-as diretamente como argumentos de linha de comando, ou, usando um arquivo `values.yaml`. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- O gerenciador de pacotes para o Kubernetes. ### Sinopse O gerenciador de pacotes para o Kubernetes. Comandos comuns para o Helm: - helm search: busca por charts - helm pull: baixa um chart em seu diretório local para visualização - helm install: aplica um chart no Kubernetes - helm list: lista as _releases_ dos charts Variáveis de ambiente: | Nome | Descrição | |------------------------------------|-----------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | configura um local alternativo para armazenamento dos arquivos de cache. | | $HELM_CONFIG_HOME | configura um local alternativo para armazenamento das configurações do Helm. | | $HELM_DATA_HOME | configura um local alternativo para armazenamento dos dados do Helm. | | $HELM_DEBUG | indica se o Helm rodará ou não em modo debug. | | $HELM_DRIVER | configura o driver de armazenamento backend. Valores: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | configura a string de conexão a ser utilizada pelo driver de armazenamento SQL. | | $HELM_MAX_HISTORY | configura o número máximo de _releases_ armazenadas no histórico do Helm. | | $HELM_NAMESPACE | configura o namespace usado para as operações do Helm. | | $HELM_NO_PLUGINS | desabilita os plugins. Configure HELM_NO_PLUGINS=1 para desabilitar os plugins. | | $HELM_PLUGINS | configura o caminho para o diretório dos plugins. | | $HELM_REGISTRY_CONFIG | configura o caminho para o arquivo de configuração do registry. | | $HELM_REPOSITORY_CACHE | configura o caminho para o diretório de cache do repositório. | | $HELM_REPOSITORY_CONFIG | configura o caminho para o arquivo de repositórios. | | $KUBECONFIG | configura um arquivo de configuração alternativo para o Kubernetes (padrão "~/.kube/config"). | | $HELM_KUBEAPISERVER | configura o endpoint do Kubernetes API Server para autenticação. | | $HELM_KUBECAFILE | configura o arquivo de autoridade certificadora do Kubernetes. | | $HELM_KUBEASGROUPS | configura os grupos para impersonação, sendo esta uma lista separada por vírgula. | | $HELM_KUBEASUSER | configura o nome de usuário para impersonação da operação. | | $HELM_KUBECONTEXT | configura o nome do contexto do kubeconfig. | | $HELM_KUBETOKEN | configura o Bearer KubeToken usado para autenticação. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indica se a validação do certificado do Kubernetes API server deve ser ignorada (inseguro). | | $HELM_KUBETLS_SERVER_NAME | configura o nome do servidor usado para validar o certificado do Kubernetes API server. | | $HELM_BURST_LIMIT | configura o limite de burst padrão caso o servidor contenha muitos CRDs (padrão 100, -1 para desabilitar). | | $HELM_QPS | configura as Queries Por Segundo para casos onde muitas chamadas excedem a opção para valores de burst maiores. | O Helm armazena arquivos de cache, configuração, e dados de acordo com a seguinte ordem: - Se uma variável de ambiente HELM_*_HOME é configurada, ela será utilizada. - Caso contrário, em sistemas que suportam a especificação de diretório XDG, as variáveis XDG serão utilizadas. - Quando nenhum outro local é configurado, será utilizado um caminho padrão baseado no sistema operacional. Por padrão, os diretórios dependem do Sistema Operacional. Abaixo seguem os caminhos padrão: | Sistema Operacional | Caminho do Cache | Caminho de Configuração | Caminho para os Dados | |---------------------|---------------------------|--------------------------------|---------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Opções ``` --burst-limit int limite de throttling padrão no lado do cliente (padrão 100) --debug habilita saída verbosa -h, --help exibe ajuda para o helm --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo para impersonação da operação, esse argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário para impersonação da operação --kube-ca-file string arquivo de autoridade certificadora para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será validado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor usado para validação do certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor será utilizado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string namespace para essa requisição --qps float32 queries por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm completion](/helm/helm_completion.md) - gera scripts de autocompletar para o shell especificado * [helm create](/helm/helm_create.md) - cria um novo chart com o nome fornecido * [helm dependency](/helm/helm_dependency.md) - gerencia as dependências de um chart * [helm env](/helm/helm_env.md) - informações do ambiente do cliente Helm * [helm get](/helm/helm_get.md) - obtém informações estendidas de uma _release_ * [helm history](/helm/helm_history.md) - obtém o histórico de uma _release_ * [helm install](/helm/helm_install.md) - instala um chart * [helm lint](/helm/helm_lint.md) - examina um chart em busca de possíveis problemas * [helm list](/helm/helm_list.md) - lista _releases_ * [helm package](/helm/helm_package.md) - empacota um diretório de chart em um chart archive * [helm plugin](/helm/helm_plugin.md) - instala, lista ou desinstala plugins do Helm * [helm pull](/helm/helm_pull.md) - baixa um chart de um repositório e (opcionalmente) descompacta em um diretório local * [helm push](/helm/helm_push.md) - envia um chart para um registry remoto * [helm registry](/helm/helm_registry.md) - faz login ou logout de um registry * [helm repo](/helm/helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts * [helm rollback](/helm/helm_rollback.md) - reverte uma _release_ para uma revisão anterior * [helm search](/helm/helm_search.md) - busca por uma palavra-chave em charts * [helm show](/helm/helm_show.md) - exibe informações de um chart * [helm status](/helm/helm_status.md) - exibe o status de uma _release_ * [helm template](/helm/helm_template.md) - renderiza templates localmente * [helm test](/helm/helm_test.md) - executa os testes de uma _release_ * [helm uninstall](/helm/helm_uninstall.md) - desinstala uma _release_ * [helm upgrade](/helm/helm_upgrade.md) - atualiza uma _release_ * [helm verify](/helm/helm_verify.md) - verifica se um chart em um dado caminho foi assinado e é válido * [helm version](/helm/helm_version.md) - exibe informações sobre a versão do cliente ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- Gera scripts de preenchimento automático para o shell especificado ### Sinopse Gera scripts de preenchimento automático do Helm para o shell especificado. ### Opções ``` -h, --help ajuda para o completion ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos --kube-as-user string usuário a ser representado para a operação --kube-ca-file string o arquivo de autoridade de certificação para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, o hostname usado para contatar o servidor será usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices do repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm](helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. * [helm completion bash](helm_completion_bash.md) - gera o script de preenchimento automático para o bash * [helm completion fish](helm_completion_fish.md) - gera o script de preenchimento automático para o fish * [helm completion powershell](helm_completion_powershell.md) - gera o script de preenchimento automático para o powershell * [helm completion zsh](helm_completion_zsh.md) - gera o script de preenchimento automático para o zsh ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- Gera o script de preenchimento automático para o bash ### Sinopse Gera o script de preenchimento automático do Helm para o bash shell. Para carregar o preenchimento automático na sessão atual do shell: source <(helm completion bash) Para carregar o preenchimento automático para cada nova sessão, execute uma vez: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Opções ``` -h, --help ajuda para o bash --no-descriptions desabilita descrições do preenchimento automático ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos --kube-as-user string usuário a ser representado para a operação --kube-ca-file string o arquivo de autoridade de certificação para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, o hostname usado para contatar o servidor será usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices do repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm completion](helm_completion.md) - gera scripts de preenchimento automático para o shell especificado ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- Gera scripts de preenchimento automático para o fish ### Sinopse Gera scripts de preenchimento automático do Helm para o fish shell. Para carregar o script de preenchimento automático na sessão ativa do fish: helm completion fish | source Para carregar o script para cada nova sessão, execute uma vez: helm completion fish > ~/.config/fish/completions/helm.fish Será necessário iniciar um novo shell para que as modificações tenham efeito. ``` helm completion fish [flags] ``` ### Opções ``` -h, --help ajuda para o preenchimento automático do fish --no-descriptions desabilita descrições do preenchimento automático ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug exibe uma saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray o grupo que representará essa operação, esse argumento pode ser repetido para indicar múltiplos grupos --kube-as-user string o usuário que representará essa operação --kube-ca-file string caminho para o certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso torna suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, será usado o hostname usado para contatar o servidor --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, sem incluir bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm completion](helm_completion.md) - gera scripts de preenchimento automático para um shell específico ###### Gerado automaticamente pelo spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- Gera o script de preenchimento automático para o powershell ### Sinopse Gera o script de preenchimento automático para o powershell. Para carregar o preenchimento automático na sessão atual do shell: PS C:\> helm completion powershell | Out-String | Invoke-Expression Para carregar o preenchimento automático para cada nova sessão, adicione a saída do comando acima ao seu perfil do powershell. ``` helm completion powershell [flags] ``` ### Opções ``` -h, --help ajuda para o powershell --no-descriptions desabilita descrições do preenchimento automático ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos --kube-as-user string usuário a ser representado para a operação --kube-ca-file string o arquivo de autoridade de certificação para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, o hostname usado para contatar o servidor será usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices do repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm completion](helm_completion.md) - gera scripts de preenchimento automático para o shell especificado ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- Gera o script de preenchimento automático para o zsh ### Sinopse Gera o script de preenchimento automático do Helm para o zsh shell. Para carregar o preenchimento automático na sessão atual do shell: source <(helm completion zsh) Para carregar o preenchimento automático para cada nova sessão, execute uma vez: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Opções ``` -h, --help ajuda para o zsh --no-descriptions desabilita descrições do preenchimento automático ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a ser representado para a operação, esse argumento pode ser repetido para especificar múltiplos grupos --kube-as-user string usuário a ser representado para a operação --kube-ca-file string o arquivo de autoridade de certificação para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, o hostname usado para contatar o servidor será usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices do repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm completion](helm_completion.md) - gera scripts de preenchimento automático para o shell especificado ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- Cria um novo Chart com um dado nome ### Sinopse Esse comando cria um diretório para o Chart, bem como os arquivos comuns necessários para o Chart. Por exemplo, `helm create foo` criará uma estrutura de diretório como: foo/ ├── .helmignore # Descreve os arquivos a serem ignorados durante o empacotamento do Chart. ├── Chart.yaml # Informação sobre o seu Chart ├── values.yaml # Valores padrão para os seus templates ├── charts/ # Charts que este Chart depende └── templates/ # Arquivos de template: deployment, service e outros manifestos └── tests/ # Arquivos de teste `helm create` cria um diretório a partir do argumento passado. Se o diretório não existir o helm tentará criá-lo. Se o destino já existir e tiver arquivos dentro do diretório, os arquivos conflitantes serão sobrescritos e os demais serão mantidos. ``` helm create NOME [argumentos] ``` ### Opções ``` -h, --help ajuda para criação do Chart -p, --starter string nome ou caminho absoluto para a base inicial do Helm ``` ### Opções gerais ``` --burst-limit int limite de requisições do lado do cliente (default 100) --debug exibe uma saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray o grupo que representará essa operação, esse argumento pode ser repetido para indicar múltiplos grupos --kube-as-user string o usuário que representará essa operação --kube-ca-file string caminho para o certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor usado para validação do certificado do Kubernetes API server. Se não fornecido, será usado o hostname usado para contactar o servidor --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string namespace para essa requisição --qps float32 consultas por segundo usadas na comunicação com a Kubernetes API, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (default "~/.config/helm/registry/config.json") --repository-cache string caminho para os índices "cacheados" no repositório (default "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (default "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- Gerencia as dependências de um chart ### Sinopse Gerencia as dependências de um chart. Os charts do Helm armazenam suas dependências em 'charts/'. Para desenvolvedores de charts, geralmente é mais fácil gerenciar dependências em 'Chart.yaml', que declara todas as dependências. Os comandos de dependência operam nesse arquivo, facilitando a sincronização entre as dependências desejadas e as dependências reais armazenadas no diretório 'charts/'. Por exemplo, este Chart.yaml declara duas dependências: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" O 'name' deve ser o nome de um chart, que deve corresponder ao nome no arquivo 'Chart.yaml' desse chart. O campo 'version' deve conter uma versão semântica ou um intervalo de versões. A URL 'repository' deve apontar para um repositório de charts. O Helm espera que, ao adicionar '/index.yaml' à URL, seja possível obter o índice do repositório de charts. Nota: 'repository' pode ser um alias. O alias deve começar com 'alias:' ou '@'. A partir da versão 2.2.0, o repository pode ser definido como o caminho para o diretório dos charts de dependência armazenados localmente. O caminho deve começar com um prefixo "file://". Por exemplo, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" Se o chart de dependência for obtido localmente, não é necessário ter o repositório adicionado ao helm por "helm add repo". A correspondência de versão também é suportada neste caso. ### Opções ``` -h, --help help for dependency ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - reconstrói o diretório charts/ com base no arquivo Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) - lista as dependências para o chart especificado * [helm dependency update](/helm/helm_dependency_update.md) - atualiza charts/ com base no conteúdo de Chart.yaml ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- Reconstrói o diretório charts/ com base no arquivo Chart.lock ### Sinopse Constrói o diretório charts/ a partir do arquivo Chart.lock. Build é usado para reconstruir as dependências de um chart para o estado especificado no arquivo de lock. Isso não renegocia as dependências, ao contrário de 'helm dependency update'. Se nenhum arquivo de lock for encontrado, 'helm dependency build' irá espelhar o comportamento de 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores habilitados para HTTPS usando este pacote CA --cert-file string identifica cliente HTTPS usando este arquivo de certificado SSL -h, --help ajuda para build --insecure-skip-tls-verify ignora verificações de certificado tls para o download do chart --key-file string identifica cliente HTTPS usando este arquivo de chave SSL --keyring string keyring contendo chaves públicas (padrão "~/.gnupg/pubring.gpg") --password string senha do repositório de charts onde localizar o chart solicitado --plain-http usa conexões HTTP inseguras para o download do chart --skip-refresh não atualiza o cache local do repositório --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica os pacotes contra assinaturas ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm dependency](/helm/helm_dependency.md) - gerencia as dependências de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- Lista as dependências de um chart especificado ### Sinopse Lista todas as dependências declaradas em um chart. Este comando aceita pacotes de chart e diretórios de chart como entrada. Ele não altera o conteúdo de um chart. Será retornado um erro se o chart não puder ser carregado. ``` helm dependency list CHART [flags] ``` ### Opções ``` -h, --help ajuda para list --max-col-width uint largura máxima da coluna para tabela de saída (padrão 80) ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm dependency](./helm_dependency.md) - gerencia as dependências de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- Atualiza charts/ com base no conteúdo de Chart.yaml ### Sinopse Atualiza as dependências locais para corresponder ao Chart.yaml. Este comando verifica que os charts necessários, conforme expressos em 'Chart.yaml', estão presentes em 'charts/' e em versões aceitáveis. Ele baixará os charts mais recentes que atendam às dependências e removerá dependências antigas. Em uma atualização bem-sucedida, isso gerará um arquivo de lock que pode ser usado para reconstruir as dependências em uma versão exata. As dependências não precisam estar representadas em 'Chart.yaml'. Por isso, um comando de atualização não removerá charts a menos que eles estejam presentes no arquivo Chart.yaml, mas em uma versão incorreta. ``` helm dependency update CHART [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores habilitados para HTTPS usando este pacote CA --cert-file string identifica cliente HTTPS usando este arquivo de certificado SSL -h, --help ajuda para update --insecure-skip-tls-verify ignora verificações de certificado tls para o download do chart --key-file string identifica cliente HTTPS usando este arquivo de chave SSL --keyring string keyring contendo chaves públicas (padrão "~/.gnupg/pubring.gpg") --password string senha do repositório de charts onde localizar o chart solicitado --plain-http usa conexões HTTP inseguras para o download do chart --skip-refresh não atualiza o cache local do repositório --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica os pacotes contra assinaturas ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm dependency](/helm/helm_dependency.md) - gerencia as dependências de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- Informações do ambiente do cliente Helm ### Sinopse Esse comando exibe todas as informações de ambiente utilizadas pelo Helm. ``` helm env [flags] ``` ### Opções ``` -h, --help ajuda para o comando env ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](./helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- Baixa informações adicionais de uma dada _release_ ### Sinopse Esse comando consiste em múltiplos subcomandos utilizados para recuperar informações adicionais sobre uma dada _release_, incluindo: - Os valores utilizados para gerar a _release_ - O arquivo de manifesto gerado - As notas advindas do Chart da _release_ - Os _hooks_ associados a uma _release_ - Os metadados da _release_ ### Opções ``` -h, --help ajuda para o comando get ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](./helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. * [helm get all](./helm_get_all.md) - baixa todas as informações de uma dada _release_ * [helm get hooks](./helm_get_hooks.md) - baixa todos os _hooks_ de uma dada _release_ * [helm get manifest](./helm_get_manifest.md) - baixa o manifesto de uma dada _release_ * [helm get metadata](./helm_get_metadata.md) - busca os metadados de uma dada release * [helm get notes](./helm_get_notes.md) - baixa as notas de uma dada _release_ * [helm get values](./helm_get_values.md) - baixa o arquivo de valores de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- Baixa toda informação sobre uma dada _release_ ### Sinopse Esse comando exibe um conjunto de informações, legíveis para o ser humano, sobre as notas, _hooks_, valores passados e o manifesto gerado para uma dada _release_. ``` helm get all NOME_DA_RELEASE [argumentos] ``` ### Opções ``` -h, --help ajuda para o comando all --revision int recupera uma revisão específica de uma release --template string template em go para formatar a saída do comando, ex: {{.Release.Name}} ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm get](./helm_get.md) - baixa informações adicionais de uma dada release ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- Baixa todos os _hooks_ de uma dada _release_ ### Sinopse Esse comando baixa os _hooks_ de uma dada _release_. _Hooks_ são formatados em YAML e separados pelo separador YAML '---\n'. ``` helm get hooks RELEASE_NAME [flags] ``` ### Opções ``` -h, --help ajuda para hooks --revision int recupera a release nomeada com a revisão especificada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- Baixa o manifesto de uma dada _release_ ### Sinopse Esse comando recupera o manifesto gerado de uma dada _release_. Um manifesto é a representação dos recursos do Kubernetes em um arquivo YAML, o qual foi gerado a partir do(s) chart(s) da _release_ em questão. Se o chart depender de outros charts, os recursos Kubernetes das dependências também serão incluídos no manifesto. ``` helm get manifest NOME_DA_RELEASE [argumentos] ``` ### Opções ``` -h, --help ajuda para recuperar um manifesto --revision int recupera uma revisão específica de uma release ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Recupera os metadados de uma dada _release_ ### Sinopse Esse comando recupera os metadados de uma dada _release_. ``` helm get metadata NOME_DA_RELEASE [argumentos] ``` ### Opções ``` -h, --help ajuda para metadata -o, --output format exibe a saída em um formato específico. Formatos: table, json, yaml (padrão table) --revision int especifica a revisão da release ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- Baixa as notas de uma dada _release_ ### Sinopse Esse comando exibe as notas fornecidas pelo chart de uma dada _release_. ``` helm get notes NOME_DA_RELEASE [argumentos] ``` ### Opções ``` -h, --help ajuda para recuperar as notas --revision int recupera uma revisão específica de uma release ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- Baixa o arquivo com os valores de uma dada _release_ ### Sinopse Esse comando recupera o arquivo com os valores utilizados em uma dada _release_. ``` helm get values NOME_DA_RELEASE [argumentos] ``` ### Opções ``` -a, --all exibe todos os valores (computados) -h, --help ajuda para recuperar os valores -o, --output format exibe a saída em um formato específico. Formatos: table, json, yaml (padrão table) --revision int recupera uma revisão específica de uma release ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm get](/helm/helm_get.md) - baixa informações adicionais de uma dada _release_ ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- Exibe o histórico de revisões de uma release ### Sinopse Esse comando imprime as revisões históricas de uma determinada release. Por padrão, serão retornadas no máximo 256 revisões. Utilize o argumento '--max' para configurar o comprimento máximo da lista de revisões retornada. O histórico de releases é exibido como uma tabela formatada, por exemplo: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando history --max int número máximo de revisões a incluir no histórico (padrão 256) -o, --output format exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string usuário a representar para a operação --kube-ca-file string arquivo de autoridade de certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação do certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- Instala um chart ### Sinopse Esse comando instala um chart archive. O argumento de instalação deve ser uma referência a um chart, um caminho para um chart empacotado, um caminho para um diretório de chart descompactado ou uma URL. Para sobrescrever valores em um chart, use o argumento `--values` indicando um arquivo ou use o argumento `--set` passando configurações pela linha de comando. Para forçar um valor no formato string use `--set-string`. Você pode usar `--set-file` para definir valores individuais a partir de um arquivo quando o valor é muito longo para a linha de comando ou é gerado dinamicamente. Você também pode usar `--set-json` para definir valores JSON (valores escalares, objetos ou arrays) pela linha de comando. $ helm install -f myvalues.yaml myredis ./redis ou $ helm install --set name=prod myredis ./redis ou $ helm install --set-string long_int=1234567890 myredis ./redis ou $ helm install --set-file my_script=dothings.sh myredis ./redis ou $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Você pode especificar o argumento `--values`/`-f` várias vezes. A prioridade será dada ao último arquivo especificado (mais à direita). Por exemplo, se tanto myvalues.yaml quanto override.yaml contêm uma chave chamada 'Test', o valor definido em override.yaml terá precedência: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Você pode especificar o argumento `--set` várias vezes. A prioridade será dada ao último valor especificado (mais à direita). Por exemplo, se ambos os valores 'bar' e 'newbar' são definidos para uma chave chamada 'foo', o valor 'newbar' terá precedência: $ helm install --set foo=bar --set foo=newbar myredis ./redis Da mesma forma, no exemplo a seguir 'foo' é definido como '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis E no exemplo a seguir, 'foo' é definido como '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Para verificar os manifestos gerados de uma release sem instalar o chart, os argumentos --debug e --dry-run podem ser combinados. O argumento --dry-run exibirá todos os manifestos gerados do chart, incluindo Secrets que podem conter valores sensíveis. Para ocultar Secrets do Kubernetes use o argumento --hide-secret. Por favor, considere cuidadosamente como e quando usar esses argumentos. Se --verify for definido, o chart DEVE ter um arquivo de proveniência, e o arquivo de proveniência DEVE passar em todas as etapas de verificação. Há seis maneiras diferentes de expressar o chart que você deseja instalar: 1. Por referência do chart: helm install mymaria example/mariadb 2. Por caminho para um chart empacotado: helm install mynginx ./nginx-1.2.3.tgz 3. Por caminho para um diretório de chart descompactado: helm install mynginx ./nginx 4. Por URL absoluta: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. Por referência do chart e URL do repositório: helm install --repo https://example.com/charts/ mynginx nginx 6. Por registries OCI: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx REFERÊNCIAS DE CHART Uma referência de chart é uma forma conveniente de referenciar um chart em um repositório de charts. Quando você usa uma referência de chart com um prefixo de repositório ('example/mariadb'), o Helm procurará na configuração local por um repositório de charts chamado 'example', e então procurará um chart nesse repositório cujo nome é 'mariadb'. Ele instalará a última versão estável desse chart até que você especifique o argumento '--devel' para também incluir versões de desenvolvimento (releases alfa, beta e candidatas), ou forneça um número de versão com o argumento '--version'. Para ver a lista de repositórios de charts, use 'helm repo list'. Para pesquisar charts em um repositório, use 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Opções ``` --atomic se definido, o processo de instalação exclui a instalação em caso de falha. O argumento --wait será definido automaticamente se --atomic for usado --ca-file string verifica certificados de servidores habilitados para HTTPS usando este pacote CA --cert-file string identifica cliente HTTPS usando este arquivo de certificado SSL --create-namespace cria o namespace da release se não estiver presente --dependency-update atualiza dependências se estiverem faltando antes de instalar o chart --description string adiciona uma descrição personalizada --devel usa versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version for definido, isso é ignorado --disable-openapi-validation se definido, o processo de instalação não validará templates renderizados contra o Kubernetes OpenAPI Schema --dry-run string[="client"] simula uma instalação. Se --dry-run for definido sem opção especificada ou como '--dry-run=client', não tentará conexões com o cluster. Definir '--dry-run=server' permite tentar conexões com o cluster. --enable-dns habilita pesquisas DNS ao renderizar templates --force força atualizações de recursos através de uma estratégia de substituição -g, --generate-name gera o nome (e omite o parâmetro NAME) -h, --help ajuda para install --hide-notes se definido, não mostra notas na saída de instalação. Não afeta a presença nos metadados do chart --hide-secret oculta Secrets do Kubernetes quando também estiver usando o argumento --dry-run --insecure-skip-tls-verify ignora verificações de certificado tls para o download do chart --key-file string identifica cliente HTTPS usando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels que seriam adicionados aos metadados da release. Devem ser separados por vírgula. (padrão []) --name-template string especifica template usado para nomear a release --no-hooks impede que hooks sejam executados durante a instalação -o, --output format imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http usa conexões HTTP inseguras para o download do chart --post-renderer postRendererString o caminho para um executável a ser usado para pós-renderização. Se existir em $PATH, o binário será usado, caso contrário tentará procurar o executável no caminho fornecido --post-renderer-args postRendererArgsSlice um argumento para o post-renderer (pode especificar múltiplos) (padrão []) --render-subchart-notes se definido, renderiza notas de subcharts junto com o principal --replace reutiliza o nome fornecido, apenas se esse nome for uma release excluída que permanece no histórico. Isso não é seguro em produção --repo string URL do repositório de charts onde localizar o chart solicitado --set stringArray define valores na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --set-file stringArray define valores a partir dos respectivos arquivos especificados via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=path1,key2=path2) --set-json stringArray define valores JSON na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2) --set-literal stringArray define um valor STRING literal na linha de comando --set-string stringArray define valores STRING na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --skip-crds se definido, nenhum CRD será instalado. Por padrão, CRDs são instalados se ainda não estiverem presentes --skip-schema-validation se definido, desabilita a validação de JSON schema --take-ownership se definido, install ignorará a verificação de anotações helm e assumirá a propriedade dos recursos existentes --timeout duration tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s) --username string nome de usuário do repositório de charts onde localizar o chart solicitado -f, --values strings especifica valores em um arquivo YAML ou uma URL (pode especificar múltiplos) --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a usar. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não especificado, a última versão é usada --wait se definido, esperará até que todos os Pods, PVCs, Services e número mínimo de Pods de um Deployment, StatefulSet ou ReplicaSet estejam em estado pronto antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout --wait-for-jobs se definido e --wait habilitado, esperará até que todos os Jobs sejam completados antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade de certificação para a conexão com o Kubernetes API server --kube-context string nome do contexto kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação de certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- examina um chart em busca de possíveis problemas ### Sinopse Este comando recebe um caminho para um chart e executa uma série de testes para verificar se o chart está bem-formado. Se o linter encontrar algo que causará falha na instalação do chart, ele emitirá mensagens de [ERROR]. Se encontrar problemas que quebram convenções ou recomendações, ele emitirá mensagens de [WARNING]. ``` helm lint PATH [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando lint --kube-version string versão do Kubernetes utilizada para verificações de capacidades e depreciação --quiet exibe apenas avisos e erros --set stringArray define valores na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --set-file stringArray define valores a partir de arquivos especificados via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=path1,key2=path2) --set-json stringArray define valores JSON na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2) --set-literal stringArray define um valor STRING literal na linha de comando --set-string stringArray define valores STRING na linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --skip-schema-validation se definido, desabilita a validação de JSON schema --strict falha em avisos do lint -f, --values strings especifica valores em um arquivo YAML ou URL (pode especificar múltiplos) --with-subcharts executa lint nos charts dependentes ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- lista as releases ### Sinopse Este comando lista todas as releases de um namespace especificado (utiliza o namespace do contexto atual se nenhum namespace for especificado). Por padrão, lista apenas releases que estão implantadas (deployed) ou com falha (failed). Argumentos como '--uninstalled' e '--all' alteram este comportamento. Esses argumentos podem ser combinados: '--uninstalled --failed'. Por padrão, os itens são ordenados alfabeticamente. Utilize o argumento '-d' para ordenar por data da release. Se o argumento --filter for fornecido, ele será tratado como um filtro. Filtros são expressões regulares (compatíveis com Perl) que são aplicadas à lista de releases. Apenas itens que correspondam ao filtro serão retornados. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Se nenhum resultado for encontrado, 'helm list' retornará com código 0, mas sem saída (ou, no caso de não utilizar o argumento '-q', apenas os cabeçalhos). Por padrão, podem ser retornados até 256 itens. Para limitar isso, utilize o argumento '--max'. Definir '--max' como 0 não retornará todos os resultados. Em vez disso, retornará o padrão do servidor, que pode ser muito maior que 256. Combinar o argumento '--max' com o argumento '--offset' permite paginar os resultados. ``` helm list [flags] ``` ### Opções ``` -a, --all exibe todas as releases sem nenhum filtro aplicado -A, --all-namespaces lista releases em todos os namespaces -d, --date ordena por data da release --deployed exibe releases implantadas. Se nenhuma outra opção for especificada, esta será habilitada automaticamente --failed exibe releases com falha -f, --filter string uma expressão regular (compatível com Perl). Qualquer release que corresponda à expressão será incluída nos resultados -h, --help exibe ajuda para o comando list -m, --max int número máximo de releases a buscar (padrão 256) --no-headers não exibe cabeçalhos ao utilizar o formato de saída padrão --offset int próximo índice de release na lista, utilizado para deslocar do valor inicial -o, --output format imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) --pending exibe releases pendentes -r, --reverse inverte a ordem de classificação -l, --selector string seletor (consulta de label) para filtrar, suporta '=', '==', e '!='.(ex.: -l key1=value1,key2=value2). Funciona apenas para backends de armazenamento secret (padrão) e configmap. -q, --short formato de saída resumido --superseded exibe releases substituídas --time-format string formata a hora utilizando o formatador de tempo do golang. Exemplo: --time-format "2006-01-02 15:04:05Z0700" --uninstalled exibe releases desinstaladas (se 'helm uninstall --keep-history' foi utilizado) --uninstalling exibe releases que estão sendo desinstaladas no momento ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- empacota um diretório de chart em um arquivo de chart ### Sinopse Este comando empacota um chart em um arquivo de chart versionado. Se um caminho for fornecido, ele procurará nesse caminho por um chart (que deve conter um arquivo Chart.yaml) e então empacotará esse diretório. Repositórios de pacotes do Helm utilizam arquivos de chart versionados. Para assinar um chart, utilize a flag '--sign'. Geralmente, você também deve fornecer '--keyring caminho/para/chaves/secretas' e '--key nome_da_chave'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg Se '--keyring' não for especificado, o Helm normalmente utiliza o chaveiro público por padrão, a menos que seu ambiente esteja configurado de outra forma. ``` helm package [CHART_PATH] [...] [flags] ``` ### Opções ``` --app-version string define a appVersion do chart para esta versão --ca-file string verifica certificados de servidores com HTTPS utilizando este pacote CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL -u, --dependency-update atualiza dependências do "Chart.yaml" para o diretório "charts/" antes de empacotar -d, --destination string local para salvar o chart. (padrão ".") -h, --help exibe ajuda para o comando package --insecure-skip-tls-verify ignora verificações de certificado TLS para o download do chart --key string nome da chave a ser usada ao assinar. Utilizado se --sign for verdadeiro --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string local do chaveiro público (padrão "~/.gnupg/pubring.gpg") --passphrase-file string local de um arquivo que contém a frase secreta para a chave de assinatura. Use "-" para ler da entrada padrão. --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --sign utiliza uma chave privada PGP para assinar este pacote --username string nome de usuário do repositório de charts onde localizar o chart solicitado --version string define a versão do chart para esta versão semver ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string token bearer utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta solicitação --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registro (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- instala, lista ou desinstala plugins do Helm ### Sinopse Gerencia plugins do Helm no lado do cliente. ### Opções ``` -h, --help exibe ajuda para o comando plugin ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes para o Kubernetes. * [helm plugin install](./helm_plugin_install.md) - instala um plugin do Helm * [helm plugin list](./helm_plugin_list.md) - lista os plugins instalados do Helm * [helm plugin uninstall](./helm_plugin_uninstall.md) - desinstala um ou mais plugins do Helm * [helm plugin update](./helm_plugin_update.md) - atualiza um ou mais plugins do Helm ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- instala um plugin do Helm ### Sinopse Este comando permite instalar um plugin a partir de uma URL de um repositório VCS ou de um caminho local. ``` helm plugin install [options] [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando install --version string especifica uma restrição de versão. Se não for especificado, a versão mais recente será instalada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm plugin](./helm_plugin.md) - instala, lista ou desinstala plugins do Helm ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- lista os plugins do Helm instalados ``` helm plugin list [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando list ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm plugin](./helm_plugin.md) - instala, lista ou desinstala plugins do Helm ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- desinstala um ou mais plugins do Helm ``` helm plugin uninstall ... [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando uninstall ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm plugin](./helm_plugin.md) - instala, lista ou desinstala plugins do Helm ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- atualiza um ou mais plugins do Helm ``` helm plugin update ... [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando update ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm plugin](./helm_plugin.md) - instala, lista ou desinstala plugins do Helm ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- baixa um chart de um repositório e (opcionalmente) extrai em um diretório local ### Sinopse Obtém um pacote de um repositório de pacotes e faz o download localmente. Isso é útil para obter pacotes para inspecionar, modificar ou reempacotar. Também pode ser usado para realizar verificação criptográfica de um chart sem instalá-lo. Existem opções para descompactar o chart após o download. Isso criará um diretório para o chart e descompactará o conteúdo nesse diretório. Se a flag --verify for especificada, o chart solicitado DEVE ter um arquivo de procedência e DEVE passar pelo processo de verificação. Falha em qualquer parte desse processo resultará em erro, e o chart não será salvo localmente. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores com HTTPS utilizando este pacote CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL -d, --destination string local para salvar o chart. Se este e untardir forem especificados, untardir é anexado a este (padrão ".") --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version for definido, este é ignorado. -h, --help exibe ajuda para o comando pull --insecure-skip-tls-verify ignora verificações de certificado TLS para o download do chart --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string local das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --prov obtém o arquivo de procedência, mas não realiza verificação --repo string URL do repositório de charts onde localizar o chart solicitado --untar se definido como true, descompacta o chart após o download --untardir string se untar for especificado, esta flag especifica o nome do diretório no qual o chart será extraído (padrão ".") --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de utilizá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- envia um chart para um registry remoto ### Sinopse Envia um chart para um registry. Se o chart possuir um arquivo de procedência associado, ele também será enviado. ``` helm push [chart] [remote] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores com HTTPS utilizando este pacote CA --cert-file string identifica o cliente do registry utilizando este arquivo de certificado SSL -h, --help exibe ajuda para o comando push --insecure-skip-tls-verify ignora verificações de certificado TLS para o upload do chart --key-file string identifica o cliente do registry utilizando esta chave SSL --password string senha do repositório de charts --plain-http utiliza conexões HTTP inseguras para o upload do chart --username string nome de usuário do repositório de charts ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- efetua login ou logout de um registry ### Sinopse Este comando possui vários subcomandos para interagir com registries. ### Opções ``` -h, --help exibe ajuda para o comando registry ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. * [helm registry login](./helm_registry_login.md) - efetua login em um registry * [helm registry logout](./helm_registry_logout.md) - encerra sessão de um registry ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- efetua login em um registry ### Sinopse Autentica em um registry remoto. ``` helm registry login [host] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS usando este pacote de CA --cert-file string identifica o cliente do registry usando este arquivo de certificado SSL -h, --help exibe ajuda para o comando login --insecure permite conexões a registries TLS sem certificados --key-file string identifica o cliente do registry usando este arquivo de chave SSL -p, --password string senha do registry ou token de identidade --password-stdin lê a senha ou token de identidade da entrada padrão (stdin) --plain-http usa conexões HTTP inseguras para o upload do chart -u, --username string nome de usuário do registry ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm registry](./helm_registry.md) - efetua login ou logout de um registry ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- encerra sessão de um registry ### Sinopse Remove as credenciais armazenadas para um registry remoto. ``` helm registry logout [host] [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando logout ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm registry](./helm_registry.md) - efetua login ou logout de um registry ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- adiciona, lista, remove, atualiza e indexa repositórios de charts ### Sinopse Este comando possui vários subcomandos para interagir com repositórios de charts. Com ele você pode adicionar, remover, listar e indexar repositórios de charts. ### Opções ``` -h, --help exibe ajuda para o comando repo ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. * [helm repo add](./helm_repo_add.md) - adiciona um repositório de charts * [helm repo index](./helm_repo_index.md) - gera um arquivo de índice dado um diretório contendo charts empacotados * [helm repo list](./helm_repo_list.md) - lista repositórios de charts * [helm repo remove](./helm_repo_remove.md) - remove um ou mais repositórios de charts * [helm repo update](./helm_repo_update.md) - atualiza informações de charts disponíveis localmente a partir dos repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- adiciona um repositório de charts ``` helm repo add [NAME] [URL] [flags] ``` ### Opções ``` --allow-deprecated-repos por padrão, este comando não permite adicionar repositórios oficiais que foram permanentemente removidos. Esta opção desabilita esse comportamento --ca-file string verifica certificados de servidores com HTTPS utilizando este pacote CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --force-update substitui (sobrescreve) o repositório se ele já existir -h, --help exibe ajuda para o comando add --insecure-skip-tls-verify ignora verificações de certificado TLS para o repositório --key-file string identifica o cliente HTTPS utilizando esta chave SSL --no-update Ignorado. Anteriormente, desabilitava atualizações forçadas. Está obsoleto em favor de force-update. --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts --password-stdin lê a senha do repositório de charts da entrada padrão --timeout duration tempo de espera para o download do arquivo de índice ser concluído (padrão 2m0s) --username string nome de usuário do repositório de charts ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm repo](./helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- gera um arquivo de índice a partir de um diretório contendo charts empacotados ### Sinopse Lê o diretório atual, gera um arquivo de índice baseado nos charts encontrados e escreve o resultado em 'index.yaml' no diretório atual. Esta ferramenta é utilizada para criar um arquivo 'index.yaml' para um repositório de charts. Para definir uma URL absoluta para os charts, utilize o argumento '--url'. Para mesclar o índice gerado com um arquivo de índice existente, utilize o argumento '--merge'. Neste caso, os charts encontrados no diretório atual serão mesclados ao índice passado em --merge, com charts locais tendo prioridade sobre charts existentes. ``` helm repo index [DIR] [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando index --json saída em formato JSON --merge string mescla o índice gerado ao índice informado --url string url do repositório de charts ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm repo](./helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- lista repositórios de charts ``` helm repo list [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando list -o, --output format imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm repo](./helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- remove um ou mais repositórios de charts ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando remove ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm repo](./helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- atualiza informações de charts disponíveis localmente a partir dos repositórios de charts ### Sinopse O comando update obtém as informações mais recentes sobre charts dos respectivos repositórios de charts. As informações são armazenadas em cache localmente, onde são utilizadas por comandos como 'helm search'. Você pode opcionalmente especificar uma lista de repositórios que deseja atualizar. $ helm repo update ... Para atualizar todos os repositórios, use 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Opções ``` --fail-on-repo-update-fail a atualização falha se qualquer uma das atualizações de repositório falhar -h, --help exibe ajuda para o comando update --timeout duration tempo de espera para o download do arquivo de índice ser concluído (padrão 2m0s) ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm repo](./helm_repo.md) - adiciona, lista, remove, atualiza e indexa repositórios de charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- Reverte uma release para uma revisão anterior ### Sinopse Esse comando reverte uma release para uma revisão anterior. O primeiro argumento do comando rollback é o nome de uma release, e o segundo é o número de uma revisão (versão). Se esse argumento for omitido ou definido como 0, a release será revertida para a revisão anterior. Para ver os números de revisão, execute 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Opções ``` --cleanup-on-fail permite a exclusão de novos recursos criados neste rollback quando o rollback falhar --dry-run simula um rollback --force força atualização de recursos através de exclusão/recriação se necessário -h, --help exibe ajuda para o comando rollback --history-max int limita o número máximo de revisões salvas por release. Use 0 para sem limite (padrão 10) --no-hooks impede a execução de hooks durante o rollback --recreate-pods reinicia os pods do recurso se aplicável --timeout duration tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s) --wait se configurado, esperará até todos os Pods, PVCs, Services e um número mínimo de Pods de um Deployment, StatefulSet ou ReplicaSet estejam em estado pronto antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout --wait-for-jobs se configurado e --wait habilitado, esperará até todos os Jobs serem completados antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string usuário a representar para a operação --kube-ca-file string arquivo de autoridade de certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação do certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- busca por uma palavra-chave em charts ### Sinopse O search permite buscar charts do Helm nos diversos locais onde podem estar armazenados, incluindo o Artifact Hub e repositórios que você adicionou. Use os subcomandos do search para buscar charts em diferentes locais. ### Opções ``` -h, --help exibe ajuda para o comando search ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes para o Kubernetes. * [helm search hub](./helm_search_hub.md) - busca por charts no Artifact Hub ou na sua própria instância de hub * [helm search repo](./helm_search_repo.md) - busca por uma palavra-chave em charts nos repositórios ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- pesquisa por charts no Artifact Hub ou na sua própria instância de hub ### Sinopse Pesquisa por Helm charts no Artifact Hub ou na sua própria instância de hub. O Artifact Hub é uma aplicação web que permite encontrar, instalar e publicar pacotes e configurações para projetos CNCF, incluindo charts Helm de distribuição pública. É um projeto sandbox da Cloud Native Computing Foundation. Você pode navegar pelo hub em https://artifacthub.io/ O argumento [KEYWORD] aceita uma palavra-chave ou uma consulta avançada entre aspas. Para mais detalhes sobre consultas avançadas, consulte https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Versões anteriores do Helm utilizavam uma instância do Monocular como 'endpoint' padrão. Por isso, para manter compatibilidade, o Artifact Hub é compatível com a API de pesquisa do Monocular. Da mesma forma, ao definir o argumento 'endpoint', o endpoint especificado também deve implementar uma API de pesquisa compatível com o Monocular. Note que ao especificar uma instância do Monocular como 'endpoint', consultas avançadas não são suportadas. Para detalhes da API, consulte https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Opções ``` --endpoint string instância do Hub para consultar charts (padrão "https://hub.helm.sh") --fail-on-no-result a pesquisa falha se nenhum resultado for encontrado -h, --help exibe ajuda para o comando hub --list-repo-url exibe a URL do repositório dos charts --max-col-width uint largura máxima das colunas na tabela de saída (padrão 50) -o, --output format exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm search](./helm_search.md) - pesquisa por uma palavra-chave em charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- pesquisa repositórios por uma palavra-chave em charts ### Sinopse O comando search percorre todos os repositórios configurados no sistema e procura por correspondências. A pesquisa desses repositórios utiliza os metadados armazenados no sistema. Serão exibidas as últimas versões estáveis dos charts encontrados. Se você especificar o argumento --devel, a saída incluirá versões de pré-lançamento. Se você deseja pesquisar usando uma restrição de versão, use --version. Exemplos: # Pesquisa por versões de release estáveis correspondentes à palavra-chave "nginx" $ helm search repo nginx # Pesquisa por versões de release correspondentes à palavra-chave "nginx", incluindo versões de pré-lançamento $ helm search repo nginx --devel # Pesquisa pela última versão estável do nginx-ingress com uma versão major 1 $ helm search repo nginx-ingress --version ^1.0.0 Repositórios são gerenciados com os comandos 'helm repo'. ``` helm search repo [keyword] [flags] ``` ### Opções ``` --devel utiliza versões de desenvolvimento (alfa, beta e release candidates). Equivalente a versão '>0.0.0-0'. Se --version for definido, este argumento é ignorado --fail-on-no-result a pesquisa falha se nenhum resultado for encontrado -h, --help exibe ajuda para o comando repo --max-col-width uint largura máxima das colunas na tabela de saída (padrão 50) -o, --output format exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) -r, --regexp utiliza expressões regulares para pesquisar nos repositórios que você adicionou --version string pesquisa usando restrições de versionamento semântico nos repositórios que você adicionou -l, --versions exibe a listagem completa, com cada versão de cada chart em sua própria linha, para os repositórios que você adicionou ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm search](./helm_search.md) - pesquisa por uma palavra-chave em charts ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- exibe informações de um chart ### Sinopse Este comando consiste em múltiplos subcomandos para exibir informações sobre um chart ### Opções ``` -h, --help exibe ajuda para o comando show ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes para o Kubernetes. * [helm show all](./helm_show_all.md) - exibe todas as informações do chart * [helm show chart](./helm_show_chart.md) - exibe a definição do chart * [helm show crds](./helm_show_crds.md) - exibe os CRDs do chart * [helm show readme](./helm_show_readme.md) - exibe o README do chart * [helm show values](./helm_show_values.md) - exibe os valores do chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- exibe todas as informações do chart ### Sinopse Este comando inspeciona um chart (diretório, arquivo ou URL) e exibe todo o conteúdo (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS utilizando este pacote de CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado -h, --help exibe ajuda para o comando all --insecure-skip-tls-verify ignora verificações de certificado TLS no download do chart --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --repo string URL do repositório de charts onde localizar o chart solicitado --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm show](./helm_show.md) - exibe informações de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- exibe a definição do chart ### Sinopse Este comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo do arquivo Chart.yaml ``` helm show chart [CHART] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS utilizando este pacote de CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado -h, --help exibe ajuda para o comando chart --insecure-skip-tls-verify ignora verificações de certificado TLS no download do chart --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --repo string URL do repositório de charts onde localizar o chart solicitado --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm show](./helm_show.md) - exibe informações de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- exibe os CRDs do chart ### Sinopse Este comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo dos arquivos CustomResourceDefinition ``` helm show crds [CHART] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS utilizando este pacote de CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado -h, --help exibe ajuda para o comando crds --insecure-skip-tls-verify ignora verificações de certificado TLS no download do chart --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --repo string URL do repositório de charts onde localizar o chart solicitado --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm show](./helm_show.md) - exibe informações de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- exibe o README do chart ### Sinopse Este comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo do arquivo README ``` helm show readme [CHART] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS utilizando este pacote de CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado -h, --help exibe ajuda para o comando readme --insecure-skip-tls-verify ignora verificações de certificado TLS no download do chart --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --repo string URL do repositório de charts onde localizar o chart solicitado --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm show](./helm_show.md) - exibe informações de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- exibe os valores do chart ### Sinopse Este comando inspeciona um chart (diretório, arquivo ou URL) e exibe o conteúdo do arquivo values.yaml ``` helm show values [CHART] [flags] ``` ### Opções ``` --ca-file string verifica certificados de servidores HTTPS utilizando este pacote de CA --cert-file string identifica o cliente HTTPS utilizando este arquivo de certificado SSL --devel utiliza versões de desenvolvimento também. Equivalente a version '>0.0.0-0'. Se --version estiver configurado, este será ignorado -h, --help exibe ajuda para o comando values --insecure-skip-tls-verify ignora verificações de certificado TLS no download do chart --jsonpath string fornece uma expressão JSONPath para filtrar a saída --key-file string identifica o cliente HTTPS utilizando este arquivo de chave SSL --keyring string localização das chaves públicas usadas para verificação (padrão "~/.gnupg/pubring.gpg") --pass-credentials passa credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http utiliza conexões HTTP inseguras para o download do chart --repo string URL do repositório de charts onde localizar o chart solicitado --username string nome de usuário do repositório de charts onde localizar o chart solicitado --verify verifica o pacote antes de usá-lo --version string especifica uma restrição de versão para a versão do chart a ser usada. Esta restrição pode ser uma tag específica (ex: 1.1.1) ou pode referenciar um intervalo válido (ex: ^2.0.0). Se não for especificado, a versão mais recente é usada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm show](./helm_show.md) - exibe informações de um chart ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- exibe o status de uma release nomeada ### Sinopse Este comando exibe o status de uma release nomeada. O status consiste em: - data e hora da última implantação - namespace do Kubernetes da release - estado da release (pode ser: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade ou pending-rollback) - revisão da release - descrição da release (pode ser mensagem de conclusão ou mensagem de erro, necessário habilitar --show-desc) - lista de recursos que compõem esta release (necessário habilitar --show-resources) - detalhes da última execução de testes, se aplicável - notas adicionais fornecidas pelo chart ``` helm status RELEASE_NAME [flags] ``` ### Opções ``` -h, --help exibe ajuda para o comando status -o, --output format imprime a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) --revision int se configurado, exibe o status da release nomeada com a revisão especificada --show-desc se configurado, exibe a mensagem de descrição da release nomeada --show-resources se configurado, exibe os recursos da release nomeada ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string endereço e porta do servidor da API do Kubernetes --kube-as-group stringArray grupo a ser representado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser representado para a operação --kube-ca-file string arquivo de autoridade de certificação para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, será utilizado o hostname usado para contatar o servidor --kube-token string bearer token utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo utilizadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### VEJA TAMBÉM * [helm](./helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- Renderiza templates localmente ### Sinopse Renderiza templates de chart localmente e exibe a saída. Todos os valores que normalmente seriam consultados ou recuperados do cluster são simulados localmente. Além disso, nenhuma validação do lado do servidor sobre a validade do chart (por exemplo, se uma API é suportada) é realizada. ``` helm template [NOME] [CHART] [flags] ``` ### Opções ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- Executa os testes de uma release ### Sinopse O comando test executa os testes de uma release. Este comando recebe como argumento o nome de uma release implantada. Os testes executados são definidos no chart que foi instalado. ``` helm test [RELEASE] [flags] ``` ### Opções ``` --filter strings especifica testes por atributo (atualmente "name") usando a sintaxe atributo=valor ou '!atributo=valor' para excluir um teste (pode especificar múltiplos ou separar valores com vírgulas: name=test1,name=test2) -h, --help ajuda para test --hide-notes se definido, não mostra notas na saída do teste. Não afeta a presença nos metadados do chart --logs exibe os logs dos pods de teste (isso é executado após todos os testes serem concluídos, mas antes de qualquer limpeza) --timeout duration tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s) ``` ### Opções herdadas dos comandos superiores ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída detalhada --kube-apiserver string o endereço e a porta para o servidor da API do Kubernetes --kube-as-group stringArray grupo a ser personificado para a operação, este argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string nome de usuário a ser personificado para a operação --kube-ca-file string o arquivo de autoridade certificadora para a conexão com o servidor da API do Kubernetes --kube-context string nome do contexto kubeconfig a ser utilizado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do servidor da API do Kubernetes não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser utilizado para validação do certificado do servidor da API do Kubernetes. Se não for fornecido, o hostname utilizado para contatar o servidor será usado --kube-token string token bearer utilizado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para esta solicitação --qps float32 consultas por segundo utilizadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - Helm, o gerenciador de pacotes para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- Desinstala uma release ### Sinopse Esse comando recebe o nome de uma release e a desinstala. Ele remove todos os recursos associados à última release do chart, assim como o histórico da release, liberando-o para uso futuro. Use o argumento '--dry-run' para visualizar quais releases serão desinstaladas sem realmente desinstalá-las. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Opções ``` --cascade string Deve ser "background", "orphan" ou "foreground". Seleciona a estratégia de exclusão em cascata para os dependentes. O padrão é background. (padrão "background") --description string adiciona uma descrição personalizada --dry-run simula uma desinstalação -h, --help exibe ajuda para o comando uninstall --ignore-not-found Trata "release not found" como uma desinstalação bem-sucedida --keep-history remove todos os recursos associados e marca a release como deletada, mas mantém o histórico da release --no-hooks evita que hooks sejam executados durante a desinstalação --timeout duration tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s) --wait se configurado, esperará até que todos os recursos sejam deletados antes de retornar. Esperará pelo tempo definido em --timeout ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string usuário a representar para a operação --kube-ca-file string arquivo de autoridade de certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação do certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- Atualiza uma release para uma nova versão de um chart ### Sinopse Esse comando atualiza uma release para uma nova versão de um chart. Os argumentos do comando upgrade devem ser uma release e um chart. O argumento do chart pode ser: uma referência de chart ('example/mariadb'), um caminho para um diretório de chart, um chart empacotado, ou uma URL completa. Para referências de chart, a versão mais recente será utilizada a menos que o argumento `--version` seja especificado. Para sobrescrever valores em um chart, use o argumento `--values` indicando um arquivo ou use o argumento `--set` passando a configuração via linha de comando. Para forçar valores no formato string use `--set-string`. Você pode usar `--set-file` para configurar valores individuais a partir de um arquivo quando o valor é muito grande para a linha de comando ou é gerado dinamicamente. Você também pode usar `--set-json` para configurar valores JSON (escalares/objetos/arrays) via linha de comando. Você pode especificar o argumento `--values`/`-f` diversas vezes. A prioridade será concedida para o último (mais a direita) arquivo especificado. Por exemplo, se ambos myvalues.yaml e override.yaml contêm uma chave chamada 'Test', o valor configurado em override.yaml terá precedência: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Você pode especificar o argumento `--set` diversas vezes. A prioridade será concedida para o último (mais a direita) valor especificado. Por exemplo, se ambos os valores 'bar' e 'newbar' são configurados para uma chave chamada 'foo', o valor 'newbar' terá precedência: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis Você pode atualizar os valores de uma release existente com esse comando usando o argumento `--reuse-values`. Os argumentos 'RELEASE' e 'CHART' devem ser definidos com os parâmetros originais, e os valores existentes serão mesclados com quaisquer valores configurados via `--values`/`-f` ou argumentos `--set`. A prioridade é concedida aos novos valores. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis O argumento --dry-run exibirá todos os manifestos gerados do chart, incluindo Secrets que podem conter valores sensíveis. Para ocultar Kubernetes Secrets use o argumento --hide-secret. Por favor considere cuidadosamente como e quando esses argumentos são utilizados. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Opções ``` --atomic se configurado, o processo de upgrade reverte as alterações feitas em caso de falha. O argumento --wait será configurado automaticamente se --atomic for usado --ca-file string verifica os certificados dos servidores HTTPS utilizando o pacote CA especificado --cert-file string identifica o cliente HTTPS utilizando o certificado SSL especificado --cleanup-on-fail permite a exclusão de novos recursos criados neste upgrade quando o upgrade falhar --create-namespace se --install for configurado, cria o namespace da release se não existir --dependency-update atualiza as dependências se estiverem faltando antes de instalar o chart --description string adiciona uma descrição personalizada --devel também considera versões de desenvolvimento. Equivalente a versão '>0.0.0-0'. Ignorado se --version for configurado --disable-openapi-validation se configurado, o processo de upgrade não validará os templates renderizados contra o Kubernetes OpenAPI Schema --dry-run string[="client"] simula uma instalação. Se --dry-run for configurado sem opção especificada ou como '--dry-run=client', não tentará conexões com o cluster. Configurando '--dry-run=server' permite tentar conexões com o cluster. --enable-dns habilita consultas DNS ao renderizar templates --force força atualizações de recursos através de uma estratégia de substituição -h, --help exibe ajuda para o comando upgrade --hide-notes se configurado, não exibe as notas na saída do upgrade. Não afeta a presença nos metadados do chart --hide-secret oculta Kubernetes Secrets quando também usar o argumento --dry-run --history-max int limita o número máximo de revisões salvas por release. Use 0 para sem limite (padrão 10) --insecure-skip-tls-verify ignora a verificação do certificado TLS para o download do chart -i, --install se uma release com esse nome não existir, executa uma instalação --key-file string identifica o cliente HTTPS utilizando a chave SSL especificada --keyring string caminho das chaves públicas para verificação (padrão "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels que seriam adicionados aos metadados da release. Devem ser separados por vírgula. Labels originais da release serão mesclados com os labels do upgrade. Você pode remover um label usando null. (padrão []) --no-hooks desabilita hooks de pré/pós upgrade -o, --output format exibe a saída no formato especificado. Valores permitidos: table, json, yaml (padrão table) --pass-credentials passa as credenciais para todos os domínios --password string senha do repositório de charts onde localizar o chart solicitado --plain-http usa conexões HTTP inseguras para o download do chart --post-renderer postRendererString caminho para um executável a ser usado para pós-renderização. Se existir em $PATH, o binário será usado, senão tentará buscar o executável no caminho especificado --post-renderer-args postRendererArgsSlice um argumento para o post-renderer (pode especificar múltiplos) (padrão []) --render-subchart-notes se configurado, renderiza notas de subcharts juntamente com o chart principal --repo string URL do repositório de charts onde localizar o chart solicitado --reset-then-reuse-values ao atualizar, redefine os valores para os embutidos no chart, aplica os valores da última release e mescla quaisquer sobrescritas da linha de comando via --set e -f. Ignorado se '--reset-values' ou '--reuse-values' for especificado --reset-values ao atualizar, redefine os valores para os embutidos no chart --reuse-values ao atualizar, reutiliza os valores da última release e mescla quaisquer sobrescritas da linha de comando via --set e -f. Ignorado se '--reset-values' for especificado --set stringArray configura valores via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --set-file stringArray configura valores a partir de arquivos especificados via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=path1,key2=path2) --set-json stringArray configura valores JSON via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=jsonval1,key2=jsonval2) --set-literal stringArray configura um valor STRING literal via linha de comando --set-string stringArray configura valores STRING via linha de comando (pode especificar múltiplos ou separar valores com vírgulas: key1=val1,key2=val2) --skip-crds se configurado, nenhum CRD será instalado quando um upgrade for executado com o argumento install habilitado. Por padrão, CRDs são instalados se ainda não estiverem presentes, quando um upgrade for executado com o argumento install habilitado --skip-schema-validation se configurado, desabilita a validação do JSON schema --take-ownership se configurado, o upgrade ignorará a verificação de anotações do helm e assumirá a propriedade dos recursos existentes --timeout duration tempo de espera para qualquer operação individual do Kubernetes (como Jobs para hooks) (padrão 5m0s) --username string usuário do repositório de charts onde localizar o chart solicitado -f, --values strings especifica valores em um arquivo YAML ou uma URL (pode especificar múltiplos) --verify verifica o pacote antes de utilizá-lo --version string especifica uma restrição de versão para a versão do chart a usar. Pode ser uma tag específica (ex: 1.1.1) ou uma referência para um intervalo válido (ex: ^2.0.0). Se não especificado, a versão mais recente é usada --wait se configurado, esperará até todos os Pods, PVCs, Services e um número mínimo de Pods de um Deployment, StatefulSet ou ReplicaSet estejam em estado pronto antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout --wait-for-jobs se configurado e --wait habilitado, esperará até todos os Jobs serem completados antes de marcar a release como bem-sucedida. Esperará pelo tempo definido em --timeout ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esse argumento pode ser repetido para especificar múltiplos grupos. --kube-as-user string usuário a representar para a operação --kube-ca-file string arquivo de autoridade de certificado para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a usar --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a usar para validação do certificado do Kubernetes API server. Se não fornecido, o hostname usado para contatar o servidor é usado --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo do namespace para esta requisição --qps float32 consultas por segundo usadas ao comunicar com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo índices de repositórios em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs de repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para o Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- verifica se um chart no caminho especificado foi assinado e é válido ### Sinopse Verifica se o chart fornecido possui um arquivo de proveniência válido. Arquivos de proveniência fornecem verificação criptográfica de que um chart não foi adulterado e foi empacotado por um provedor confiável. Este comando pode ser usado para verificar um chart local. Vários outros comandos fornecem flags '--verify' que executam a mesma validação. Para gerar um pacote assinado, use o comando 'helm package --sign'. ``` helm verify PATH [flags] ``` ### Opções ``` -h, --help ajuda para verify --keyring string keyring contendo chaves públicas (padrão "~/.gnupg/pubring.gpg") ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esta flag pode ser repetida para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade certificadora para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, será usado o hostname utilizado para contactar o servidor --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- exibe a versão do cliente ### Sinopse Exibe a versão do Helm. Este comando exibirá uma representação da versão do Helm. A saída será algo como: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version é a versão semântica da release. - GitCommit é o SHA do commit a partir do qual esta versão foi construída. - GitTreeState é "clean" se não havia alterações locais no código quando este binário foi construído, e "dirty" se o binário foi construído a partir de código modificado localmente. - GoVersion é a versão do Go utilizada para compilar o Helm. Ao utilizar a flag `--template`, as seguintes propriedades estão disponíveis para uso no template: - .Version contém a versão semântica do Helm - .GitCommit é o commit git - .GitTreeState é o estado da árvore git quando o Helm foi construído - .GoVersion contém a versão do Go com a qual o Helm foi compilado Por exemplo, `--template='Version: {{.Version}}'` produz a saída 'Version: v3.2.1'. ``` helm version [flags] ``` ### Opções ``` -h, --help ajuda para version --short exibe o número da versão --template string template para o formato da string de versão ``` ### Opções gerais ``` --burst-limit int limite de throttling padrão do lado do cliente (padrão 100) --debug habilita saída verbosa --kube-apiserver string o endereço e porta do Kubernetes API server --kube-as-group stringArray grupo a representar para a operação, esta flag pode ser repetida para especificar múltiplos grupos. --kube-as-user string nome de usuário a representar para a operação --kube-ca-file string o arquivo de autoridade certificadora para conexão com o Kubernetes API server --kube-context string nome do contexto do kubeconfig a ser usado --kube-insecure-skip-tls-verify se verdadeiro, o certificado do Kubernetes API server não será verificado quanto à validade. Isso tornará suas conexões HTTPS inseguras --kube-tls-server-name string nome do servidor a ser usado para validação do certificado do Kubernetes API server. Se não for fornecido, será usado o hostname utilizado para contactar o servidor --kube-token string bearer token usado para autenticação --kubeconfig string caminho para o arquivo kubeconfig -n, --namespace string escopo de namespace para esta requisição --qps float32 consultas por segundo usadas na comunicação com a API do Kubernetes, não incluindo bursting --registry-config string caminho para o arquivo de configuração do registry (padrão "~/.config/helm/registry/config.json") --repository-cache string caminho para o diretório contendo os índices de repositório em cache (padrão "~/.cache/helm/repository") --repository-config string caminho para o arquivo contendo nomes e URLs dos repositórios (padrão "~/.config/helm/repositories.yaml") ``` ### Veja Também * [helm](/helm/helm.md) - O gerenciador de pacotes Helm para Kubernetes. ###### Gerado automaticamente por spf13/cobra em 14-Jan-2026 ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Comandos Helm description: Documentação para a lista completa de comandos da CLI do helm. sidebar_position: 6 id: helm-category --- # Comandos Helm Aqui você encontrará uma lista de comandos da CLI do helm, com informações sobre seu uso. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action para Automatizar Charts no GitHub Pages description: Descreve como usar o Chart Releaser Action para automatizar a publicação de charts através do GitHub Pages. sidebar_position: 3 --- Este guia descreve como usar o [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) para automatizar a publicação de charts através do GitHub Pages. O Chart Releaser Action é um workflow do GitHub Actions para transformar um projeto do GitHub em um repositório de charts do Helm auto-hospedado, usando a ferramenta CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Alterações no Repositório Crie um repositório Git na sua organização do GitHub. Você pode dar ao repositório o nome `helm-charts`, embora outros nomes também sejam aceitáveis. Os arquivos fonte de todos os charts podem ser colocados na branch `main`. Os charts devem ser colocados no diretório `/charts` na raiz da árvore de diretórios. Você também precisará de uma branch chamada `gh-pages` para publicar os charts. As alterações nessa branch serão criadas automaticamente pelo Chart Releaser Action descrito aqui. No entanto, você pode criar a branch `gh-pages` e adicionar um arquivo `README.md`, que ficará visível para os usuários que visitarem a página. Você pode adicionar instruções no `README.md` para instalação dos charts assim (substitua ``, `` e ``): ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` Os charts serão publicados em um site com URL assim: https://.github.io/helm-charts ## Workflow do GitHub Actions Crie o arquivo de workflow do GitHub Actions na branch `main` em `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` A configuração acima usa o [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) para transformar seu projeto do GitHub em um repositório de charts do Helm auto-hospedado. Ele faz isso — sempre que houver um push para a branch main — verificando cada chart no seu projeto e, quando encontra uma nova versão, cria uma release correspondente no GitHub com o nome da versão do chart, adiciona os artefatos do chart do Helm à release e cria ou atualiza um arquivo `index.yaml` com metadados sobre essas releases, que é então hospedado no GitHub Pages. A versão do Chart Releaser Action usada no exemplo acima é `v1.6.0`. Você pode alterá-la para a [versão mais recente disponível](https://github.com/helm/chart-releaser-action/releases). Nota: O Chart Releaser Action é quase sempre usado em conjunto com o [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) e o [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Sincronizando Seu Repositório de Charts description: Como sincronizar seus repositórios de charts local e remoto. sidebar_position: 2 --- *Nota: Este exemplo é especificamente para um bucket do Google Cloud Storage (GCS) que hospeda um repositório de charts.* ## Pré-requisitos * Instale a ferramenta [gsutil](https://cloud.google.com/storage/docs/gsutil). *Este processo depende fortemente da funcionalidade gsutil rsync* * Certifique-se de ter acesso ao binário do Helm * _Opcional: Recomendamos que você ative o [versionamento de objetos](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) no seu bucket do GCS para o caso de excluir algo acidentalmente._ ## Configure um diretório de repositório de charts local Crie um diretório local como fizemos no [guia do repositório de charts](/topics/chart_repository.md), e coloque seus charts empacotados nesse diretório. Por exemplo: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Gere um index.yaml atualizado Use o Helm para gerar um arquivo index.yaml atualizado passando o caminho do diretório e a URL do repositório remoto para o comando `helm repo index` assim: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Isso gerará um arquivo index.yaml atualizado e o colocará no diretório `fantastic-charts/`. ## Sincronize seus repositórios de charts local e remoto Faça upload do conteúdo do diretório para seu bucket do GCS executando `scripts/sync-repo.sh` e passando o nome do diretório local e o nome do bucket do GCS. Por exemplo: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Atualizando seu repositório de charts Você vai querer manter uma cópia local do conteúdo do seu repositório de charts ou usar `gsutil rsync` para copiar o conteúdo do seu repositório de charts remoto para um diretório local. Por exemplo: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Links Úteis: * Documentação sobre o [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [O Guia do Repositório de Charts](/topics/chart_repository.md) * Documentação sobre [versionamento de objetos e controle de concorrência](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) no Google Cloud Storage ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Dicas e Truques de Desenvolvimento de Charts description: Cobre algumas das dicas e truques que desenvolvedores de charts do Helm aprenderam enquanto criavam charts de qualidade para produção. sidebar_position: 1 --- Este guia cobre algumas das dicas e truques que desenvolvedores de charts do Helm aprenderam enquanto criavam charts de qualidade para produção. ## Conheça as Funções de Template O Helm usa [Go templates](https://godoc.org/text/template) para criar templates dos seus arquivos de recursos. Embora o Go já inclua várias funções nativas, adicionamos muitas outras. Primeiro, adicionamos todas as funções da [biblioteca Sprig](https://masterminds.github.io/sprig/), exceto `env` e `expandenv`, por razões de segurança. Também adicionamos duas funções especiais de template: `include` e `required`. A função `include` permite trazer outro template e então passar os resultados para outras funções de template. Por exemplo, este trecho de template inclui um template chamado `mytpl`, então converte o resultado para minúsculas e o envolve em aspas duplas. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` A função `required` permite declarar uma entrada de valores específica como obrigatória para a renderização do template. Se o valor estiver vazio, a renderização do template falhará com uma mensagem de erro enviada pelo usuário. O exemplo a seguir da função `required` declara que uma entrada para `.Values.who` é obrigatória, e exibirá uma mensagem de erro quando essa entrada estiver ausente: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Use Aspas em Strings, Não em Inteiros Quando você está trabalhando com dados de string, é sempre mais seguro colocar aspas nas strings do que deixá-las sem: ```yaml name: {{ .Values.MyName | quote }} ``` Mas quando estiver trabalhando com inteiros, _não coloque aspas nos valores._ Isso pode, em muitos casos, causar erros de parsing dentro do Kubernetes. ```yaml port: {{ .Values.Port }} ``` Esta observação não se aplica a valores de variáveis de ambiente que são esperados como strings, mesmo quando representam inteiros: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Usando a Função 'include' O Go fornece uma maneira de incluir um template em outro usando a diretiva nativa `template`. No entanto, a função nativa não pode ser usada em pipelines de template do Go. Para tornar possível incluir um template e então realizar uma operação na saída desse template, o Helm tem uma função especial `include`: ``` {{ include "toYaml" $value | indent 2 }} ``` O código acima inclui um template chamado `toYaml`, passa `$value` para ele, e então passa a saída desse template para a função `indent`. Como o YAML atribui significado aos níveis de indentação e espaços em branco, esta é uma ótima maneira de incluir trechos de código, enquanto manipula a indentação em um contexto relevante. ## Usando a Função 'required' O Go fornece uma maneira de definir opções de template para controlar o comportamento quando um mapa é indexado com uma chave que não está presente no mapa. Isso é tipicamente configurado com `template.Options("missingkey=option")`, onde `option` pode ser `default`, `zero` ou `error`. Embora definir esta opção como error vá parar a execução com um erro, isso se aplicaria a cada chave ausente no mapa. Pode haver situações em que um desenvolvedor de chart queira impor esse comportamento para valores selecionados no arquivo `values.yaml`. A função `required` dá aos desenvolvedores a capacidade de declarar uma entrada de valor como obrigatória para a renderização do template. Se a entrada estiver vazia em `values.yaml`, o template não será renderizado e retornará uma mensagem de erro fornecida pelo desenvolvedor. Por exemplo: ``` {{ required "A valid foo is required!" .Values.foo }} ``` O código acima renderizará o template quando `.Values.foo` estiver definido, mas falhará na renderização e sairá quando `.Values.foo` estiver indefinido. ## Usando a Função 'tpl' A função `tpl` permite que desenvolvedores avaliem strings como templates dentro de um template. Isso é útil para passar uma string de template como valor para um chart ou renderizar arquivos de configuração externos. Sintaxe: `{{ tpl TEMPLATE_STRING VALUES }}` Exemplos: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Renderizando um arquivo de configuração externo: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Criando Image Pull Secrets Image pull secrets são essencialmente uma combinação de _registry_, _username_ e _password_. Você pode precisar deles em uma aplicação que está implantando, mas para criá-los é necessário executar `base64` algumas vezes. Podemos escrever um template auxiliar para compor o arquivo de configuração do Docker para uso como payload do Secret. Aqui está um exemplo: Primeiro, assuma que as credenciais estão definidas no arquivo `values.yaml` assim: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Em seguida, definimos nosso template auxiliar assim: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Finalmente, usamos o template auxiliar em um template maior para criar o manifesto do Secret: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Reiniciando Deployments Automaticamente Muitas vezes ConfigMaps ou Secrets são injetados como arquivos de configuração em containers ou existem outras mudanças de dependências externas que exigem reiniciar pods. Dependendo da aplicação, uma reinicialização pode ser necessária se eles forem atualizados com um subsequente `helm upgrade`, mas se a spec do deployment em si não mudou, a aplicação continua executando com a configuração antiga, resultando em um deployment inconsistente. A função `sha256sum` pode ser usada para garantir que a seção de annotations de um deployment seja atualizada se outro arquivo mudar: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTA: Se você está adicionando isso a um library chart, você não conseguirá acessar seu arquivo em `$.Template.BasePath`. Em vez disso, você pode referenciar sua definição com `{{ include ("mylibchart.configmap") . | sha256sum }}`. No caso de você sempre querer reiniciar seu deployment, você pode usar um passo de annotation similar ao acima, substituindo por uma string aleatória para que ela sempre mude e cause a reinicialização do deployment: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Cada invocação da função de template gerará uma string aleatória única. Isso significa que se for necessário sincronizar as strings aleatórias usadas por múltiplos recursos, todos os recursos relevantes precisarão estar no mesmo arquivo de template. Ambos os métodos permitem que seu Deployment aproveite a lógica de estratégia de atualização nativa para evitar downtime. NOTA: No passado, recomendávamos usar a flag `--recreate-pods` como outra opção. Esta flag foi marcada como obsoleta no Helm 3 em favor do método declarativo acima. ## Instruindo o Helm a Não Desinstalar um Recurso Às vezes existem recursos que não devem ser desinstalados quando o Helm executa um `helm uninstall`. Desenvolvedores de chart podem adicionar uma annotation a um recurso para prevenir que ele seja desinstalado. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` A annotation `helm.sh/resource-policy: keep` instrui o Helm a pular a exclusão deste recurso quando uma operação do helm (como `helm uninstall`, `helm upgrade` ou `helm rollback`) resultaria em sua exclusão. _No entanto_, este recurso se torna órfão. O Helm não o gerenciará mais de forma alguma. Isso pode levar a problemas se usar `helm install --replace` em uma release que já foi desinstalada, mas manteve recursos. ## Usando "Partials" e Template Includes Às vezes você quer criar algumas partes reutilizáveis em seu chart, sejam elas blocos ou partials de template. E frequentemente, é mais limpo mantê-los em seus próprios arquivos. No diretório `templates/`, qualquer arquivo que começa com um underscore (`_`) não é esperado que produza um arquivo de manifesto Kubernetes. Então, por convenção, templates auxiliares e partials são colocados em um arquivo `_helpers.tpl`. ## Charts Complexos com Muitas Dependências Muitos dos charts no [Artifact Hub](https://artifacthub.io/packages/search?kind=0) da CNCF são "blocos de construção" para criar aplicações mais avançadas. Mas charts podem ser usados para criar instâncias de aplicações em grande escala. Nesses casos, um único chart guarda-chuva pode ter múltiplos subcharts, cada um funcionando como uma peça do todo. A prática recomendada atual para compor uma aplicação complexa a partir de partes discretas é criar um chart guarda-chuva de nível superior que expõe as configurações globais, e então usar o subdiretório `charts/` para incorporar cada um dos componentes. ## YAML é um Superset de JSON De acordo com a especificação YAML, YAML é um superset de JSON. Isso significa que qualquer estrutura JSON válida deveria ser válida em YAML. Isso tem uma vantagem: Às vezes, desenvolvedores de template podem achar mais fácil expressar uma estrutura de dados com uma sintaxe similar ao JSON em vez de lidar com a sensibilidade de espaços em branco do YAML. Como melhor prática, templates devem seguir uma sintaxe similar ao YAML _a menos que_ a sintaxe JSON reduza substancialmente o risco de um problema de formatação. ## Cuidado ao Gerar Valores Aleatórios Existem funções no Helm que permitem gerar dados aleatórios, chaves criptográficas, e assim por diante. São boas para usar. Mas esteja ciente de que durante upgrades, os templates são re-executados. Quando uma execução de template gera dados que diferem da última execução, isso acionará uma atualização desse recurso. ## Instalar ou Atualizar uma Release com um Único Comando O Helm fornece uma maneira de realizar um install-or-upgrade como um único comando. Use `helm upgrade` com o comando `--install`. Isso fará com que o Helm verifique se a release já está instalada. Se não estiver, ele executará um install. Se estiver, então a release existente será atualizada. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: Guias de Instruções sidebar_position: 2 --- # Guias de Instruções Nesta seção você encontrará respostas para perguntas do tipo "Como eu faço...?". Os guias de instruções não cobrem a fundo os tópicos abordados - você encontrará mais detalhamento desse material na seção [Guias Temáticos](/topics/index.mdx). Contudo, os Guias de Instruções lhe auxiliarão em realizar tarefas comuns para um usuário do Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Início da Documentação" description: "Tudo o que você precisa saber em como essa documentação é organizada." --- # Bem-vindo Bem-vindo a documentação do [Helm](https://helm.sh/). Helm é um gerenciador de pacotes para o Kubernetes, e você pode ler mais sobre o seu contexto detalhado no [Relatório da Jornada do Projeto Helm na CNCF](https://www.cncf.io/cncf-helm-project-journey/). # Como essa documentação é organizada? O Helm tem uma vasta documentação. Uma visão geral em alto nível de como ela é organizada lhe ajudará por onde procurar certas informações: - [Tutoriais](/intro/index.mdx) pegam na sua mão e lhe guiam por uma série de passos para criar seu primeiro Chart no Helm. Comece por aqui se você é novo no Helm. - [Guias Temáticos](/topics/index.mdx) abordam os principais tópicos e conceitos em alto nível, além de prover contexto e explicações utéis sobre o Helm. - [Guias da Comunidade](/community) abordam tópicos centrados ao redor da comunidade do Helm. Comece por aqui se você quiser se informar sobre o processo de desenvolvimento do Helm em si e como contribuir com o projeto. - [Guias de Instruções](/howto/index.mdx) são receitas prontas. Eles lhe guiam através dos passos envolvidos na resolução dos principais problemas e casos de uso. São mais avançados que tutoriais e demandam conhecimento prévio de como o Helm funciona. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Guia de Referência Rápida description: Guia de referência rápida do Helm sidebar_position: 4 --- Guia de referência rápida do Helm contendo todos os comandos necessários para gerenciar uma aplicação através do Helm. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Conceitos e Contexto Básicos Chart: - É o nome do seu chart caso ele tenha sido baixado e descompactado. - É / caso o repositório tenha sido adicionado mas o chart não foi baixado. - É a URL/Caminho absoluto para o chart. Name: - É o nome que você deseja dar à sua instalação atual do chart Helm. Release: - É o nome que você atribuiu a uma instância de instalação. Revision: - É o valor obtido do comando Helm history. Repo-name: - O nome de um repositório. DIR: - Nome/caminho do diretório. ------------------------------------------------------------------------------------------------------------------------------------------------ ### Gerenciamento de Charts ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart's dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Instalar e Desinstalar Aplicações ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Atualizar Aplicações e Reverter Versões ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Listar, Adicionar, Remover e Atualizar Repositórios ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Monitoramento de Releases do Helm ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Baixar Informações de Releases ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Gerenciamento de Plugins ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: Introdução sidebar_position: 1 --- # Introdução ao Helm Você é novo no Helm? Esse é o lugar por onde começar! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Instalando o Helm description: Aprenda como instalar e rodar o Helm. sidebar_position: 2 --- Esse guia ensina como instalar a CLI do Helm. O Helm pode ser instalado a partir do código-fonte, ou mesmo de um binário pré-buildado. ## A partir do Projeto Helm O projeto Helm disponibiliza duas maneiras de baixar e instalar o Helm. Essas são as formas oficiais de se obter as versões do Helm. Além disso, a comunidade do Helm disponibiliza alternativas de download através de diversos gerenciadores de pacotes. A seção de instalação pelos gerenciadores de pacotes se encontra abaixo dos métodos oficiais. ### A partir das _Releases_ dos Binários Cada [_release_](https://github.com/helm/helm/releases) do Helm gera distribuições do binário para uma gama de sistemas operacionais. Essas versões de binários podem ser baixadas manualmente e instaladas. 1. Baixe uma [versão desejada](https://github.com/helm/helm/releases) 2. Descompacte-a (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Encontre o binário `helm` no diretório descompactado e mova-o para um diretório de destino (`mv linux-amd64/helm /usr/local/bin/helm`) A partir daí, você já deve conseguir rodar o cliente e [adicionar um repositório dos Charts do Helm](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Nota:** Os testes automatizados do Helm são realizados para a plataforma Linux AMD64 somente durante os _builds_ e _releases_ do GitHub Actions. Testes para outros sistemas operacionais não estão cobertos e são de responsabilidade da comunidade em solicitá-los. ### A partir do _Script_ O Helm agora conta com um _script_ que automaticamente baixará a última versão disponível do Helm e [instalará localmente](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Baixe o _script_ e execute-o localmente. O _script_ está bem escrito e documentado, podendo ser verificado e revisado antes de proceder com a instalação local. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Sim, você pode executar `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` se você gosta de viver perigosamente. ## Através de Gerenciadores de Pacote A comunidade do Helm disponibiliza a instalação através de diversos gerenciadores de pacotes para diferentes sistemas operacionais. Eles não são mantidos pelo projeto Helm e não são considerados provedores terceiros acreditados. ### Homebrew (macOS) Membros da comunidade Helm adicionaram uma formula do Helm ao Homebrew. A fórmula geralmente está atualizada. ```console brew install helm ``` (Nota: Atenção, existe uma fórmula do emacs-helm, que é um projeto distinto!) ### Chocolatey (Windows) Membros da comunidade Helm contribuíram com um build do [pacote Helm](https://chocolatey.org/packages/kubernetes-helm) para o [Chocolatey](https://chocolatey.org/). Esse pacote geralmente está atualizado. ```console choco install kubernetes-helm ``` ### Scoop (Windows) Membros da comunidade Helm contribuíram com um build do [pacote Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) para o [Scoop](https://scoop.sh). Esse pacote geralmente está atualizado. ```console scoop install helm ``` ### Winget (Windows) Membros da comunidade Helm contribuíram com um build do [pacote Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) para o [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Esse pacote geralmente está atualizado. ```console winget install Helm.Helm ``` ### Apt (Debian/Ubuntu) Membros da comunidade Helm contribuíram com um pacote Apt para Debian/Ubuntu. Esse pacote geralmente está atualizado. Agradecimentos ao [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) por hospedar o repositório. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### dnf/yum (fedora) A partir do Fedora 35, o Helm está disponível no repositório oficial. Você pode instalar o Helm executando: ```console sudo dnf install helm ``` ### Snap A comunidade dos [_Snapcrafters_](https://github.com/snapcrafters) mantém a versão do [pacote Helm](https://snapcraft.io/helm) para o Snap: ```console sudo snap install helm --classic ``` ### pkg (FreeBSD) Membros da comunidade do FreeBSD contribuíram com um [pacote Helm](https://www.freshports.org/sysutils/helm) buildado para o [_FreeBSD Ports Collection_](https://man.freebsd.org/ports). Esse pacote geralmente está atualizado. ```console pkg install helm ``` ### _Builds_ de Desenvolvimento Além das releases estáveis, é possível baixar e instalar versões de desenvolvimento do Helm. ### _Canary Builds_ _Builds "Canary"_ são versões do Helm construídas a partir das últimas atualizações da branch `main`. Eles não são releases oficiais e podem não ser estáveis! Contudo, oferecem a oportunidade de testar as funcionalidades mais recentes do Helm. Os binários _Canary_ do Helm são armazenados em [get.helm.sh](https://get.helm.sh). Estes são alguns links de _builds_ comuns: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### A partir do Código-Fonte (Linux, macOS) _Buildar_ o Helm a partir do código-fonte é mais trabalhoso, mas é a melhor forma de testar as últimas versões (pré-release) do Helm. Você deve ter um ambiente de execução Go instalado em seu host. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` Se necessário, essa abordagem irá baixar as dependências, armazená-las em cache e validará a configuração. Irá compilar o `helm` e o mover para `bin/helm` também. ## Conclusão Na maioria dos casos, a instalação é simples como baixar um binário pré-buildado do `helm`. Este documento cobre casos de pessoas que querem executar cargas de trabalho mais sofisticadas com o Helm. Uma vez instalado com sucesso o cliente Helm, você pode seguir com o uso do Helm para o gerenciamento de charts e [adicionar um repositório estável](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Guia de Início Rápido description: >- Como instalar e começar com os primeiros passos no Helm, incluindo instruções para Distros, Perguntas Frequentes e plugins. sidebar_position: 1 --- Esse guia cobre como você rapidamente pode começar a utilizar o Helm. ## Pré-requisitos Os pré-requisitos a seguir são exigidos para uma experiência bem sucedida e segura do uso do Helm. 1. Ter acesso a um cluster Kubernetes 2. Decidir quais configurações de segurança serão aplicadas durante a instalação, se houver alguma 3. Instalar e configurar o Helm. ### Instale o Kubernetes ou tenha acesso a um cluster - Você deve ter o Kubernetes instalado. Para a utilização da última versão do Helm, nós recomendamos a última versão estável do Kubernetes, que geralmente é a penúltima _minor version_. - Você deve ter também instalado localmente a ferramenta `kubectl`. Consulte a [Política de Suporte de Versões do Helm](https://helm.sh/docs/topics/version_skew/) para a máxima diferença de versões suportadas entre o Helm e o Kubernetes. ## Instalando o Helm Faça o download do binário do cliente Helm. Você pode utilizar ferramentas como o `homebrew` ou pesquisar na [página oficial de _releases_ do Helm](https://github.com/helm/helm/releases). Para mais detalhes ou outras opções veja o [guia de instalação](/intro/install.md). ## Inicialize um Repositório para os Charts do Helm {#initialize-a-helm-chart-repository} Depois de tudo pronto com a instalação do Helm você pode adicionar um repositório de Charts. Dê uma olhada no [Artifact Hub](https://artifacthub.io/packages/search?kind=0) para encontrar repositórios de Charts do Helm disponíveis. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Você poderá listar os Charts que deseja instalar do repositório recém adicionado: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Instalando um Chart de exemplo Para instalar um Chart você pode rodar o comando `helm install`. O Helm tem diversas formas de encontrar e instalar Charts, porém a mais fácil é utilizar os Charts da `bitnami`. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` No exemplo acima o Chart `bitnami/mysql` foi aplicado no cluster e o nome da nossa nova _release_ é `mysql-1612624192`. Você pode ter uma ideia das funcionalidades deste Chart MySQL ao rodar o comando `helm show chart bitnami/mysql`. Se você quiser ter uma visão completa execute o comando `helm show all bitnami/mysql` para mais informações do Chart. Sempre que você instalar um Chart uma nova _release_ é criada. Dessa forma um mesmo Chart pode ser instalado diversas vezes em um mesmo cluster. Assim cada Chart pode ser gerenciado e atualizado de forma independente. O comando `helm install` é bem poderoso e com muitas funcionalidades. Para saber mais acesse o [Guia de Utilização do Helm](/intro/using_helm.md). ## Saiba mais sobre _Releases_ É fácil visualizar o que foi aplicado utilizando o Helm: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` O comando `helm list` (ou `helm ls`) irá lhe mostrar uma lista de todos os Charts aplicados. ## Desinstalando uma Release Para desinstalar uma _release_ utilize o comando `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` O comando desinstalará o Chart `mysql-1612624192` do Kubernetes, assim como todos os recursos associados a _release_, além do histórico da _release_. Se o argumento `--keep-history` for passado, o histórico da _release_ será mantido. Assim será possível recuperar informações sobre a _release_ específica: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Pelo fato do Helm monitorar as _releases_ até mesmo depois de desinstalá-las com o argumento `--keep-history`, é possível auditar o histórico do cluster, sendo até mesmo capaz de recuperar a _release_ (com o comando `helm rollback`). ## Ajuda no Cliente Helm Use `helm help` ou digite um comando seguido pelo argumento `-h` para saber mais sobre os comandos disponíveis no cliente Helm: ```console $ helm get -h ``` ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Utilizando o Helm description: Explica os fundamentos do Helm. sidebar_position: 3 --- Esse guia explica os fundamentos da utilização do Helm para gerenciar pacotes em seu cluster Kubernetes. Ele assume que você já [instalou](/intro/install.md) o cliente Helm. Se você está simplesmente interessado em executar alguns comandos rápidos, talvez prefira começar pelo [Guia de Início Rápido](/intro/quickstart.md). Este capítulo aborda os detalhes dos comandos do Helm e explica como utilizá-lo. ## Três Grandes Conceitos Um *Chart* é um pacote do Helm. Ele contém todas as definições de recursos necessárias para executar uma aplicação, ferramenta ou serviço dentro de um cluster Kubernetes. Pense nele como o equivalente do Kubernetes a uma fórmula do Homebrew, um pacote dpkg do Apt ou um arquivo RPM do Yum. Um *Repositório* é o lugar onde os Charts podem ser coletados e compartilhados. É como o [arquivo CPAN](https://www.cpan.org) do Perl ou o [Banco de Dados de Pacotes do Fedora](https://src.fedoraproject.org/), mas para pacotes Kubernetes. Uma *Release* é uma instância de um Chart em execução em um cluster Kubernetes. Um Chart frequentemente pode ser instalado várias vezes no mesmo cluster. E cada vez que é instalado, uma nova _release_ é criada. Considere um Chart MySQL. Se você quer dois bancos de dados em execução em seu cluster, você pode instalar esse Chart duas vezes. Cada um terá sua própria _release_, que por sua vez terá seu próprio _release name_. Com esses conceitos em mente, podemos explicar o Helm da seguinte forma: O Helm instala _charts_ no Kubernetes, criando uma nova _release_ para cada instalação. E para encontrar novos Charts, você pode pesquisar em _repositórios_ de Charts do Helm. ## 'helm search': Encontrando Charts O Helm vem com um poderoso comando de pesquisa. Ele pode ser utilizado para pesquisar dois tipos diferentes de fontes: - `helm search hub` pesquisa no [Artifact Hub](https://artifacthub.io), que lista Charts do Helm de dezenas de repositórios diferentes. - `helm search repo` pesquisa nos repositórios que você adicionou ao seu cliente Helm local (com `helm repo add`). Essa pesquisa é feita sobre dados locais, e nenhuma conexão de rede pública é necessária. Você pode encontrar Charts disponíveis publicamente executando `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` O comando acima pesquisa todos os Charts de `wordpress` no Artifact Hub. Sem nenhum filtro, `helm search hub` mostra todos os Charts disponíveis. `helm search hub` expõe a URL para a localização no [artifacthub.io](https://artifacthub.io/), mas não o repositório Helm real. `helm search hub --list-repo-url` expõe a URL real do repositório Helm, o que é útil quando você deseja adicionar um novo repositório: `helm repo add [NAME] [URL]`. Usando `helm search repo`, você pode encontrar os nomes dos Charts nos repositórios que você já adicionou: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` A pesquisa do Helm usa um algoritmo de correspondência aproximada de strings, então você pode digitar partes de palavras ou frases: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` A pesquisa é uma boa maneira de encontrar pacotes disponíveis. Depois de encontrar um pacote que deseja instalar, você pode usar `helm install` para instalá-lo. ## 'helm install': Instalando um Pacote Para instalar um novo pacote, use o comando `helm install`. Na sua forma mais simples, ele recebe dois argumentos: um nome de release que você escolhe e o nome do Chart que deseja instalar. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Agora o Chart `wordpress` está instalado. Note que instalar um Chart cria um novo objeto de _release_. A release acima é chamada `happy-panda`. (Se você quiser que o Helm gere um nome para você, omita o nome da release e use `--generate-name`.) Durante a instalação, o cliente `helm` imprimirá informações úteis sobre quais recursos foram criados, qual é o estado da release, e também se há etapas adicionais de configuração que você pode ou deve executar. O Helm instala os recursos na seguinte ordem: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration O Helm não espera até que todos os recursos estejam em execução antes de finalizar. Muitos Charts requerem imagens Docker com mais de 600MB de tamanho e podem levar muito tempo para serem instalados no cluster. Para acompanhar o estado de uma release ou reler informações de configuração, você pode usar `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` O comando acima mostra o estado atual da sua release. ### Personalizando o Chart Antes de Instalar A instalação da forma que fizemos aqui usará apenas as opções de configuração padrão para este Chart. Muitas vezes, você vai querer personalizar o Chart para usar sua configuração preferida. Para ver quais opções são configuráveis em um Chart, use `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Você pode então sobrescrever qualquer uma dessas configurações em um arquivo formatado em YAML e passá-lo durante a instalação. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` O comando acima criará um usuário MariaDB padrão com o nome `user0` e concederá a esse usuário acesso a um banco de dados `user0db` recém-criado, mas aceitará todos os outros padrões desse Chart. Existem duas formas de passar dados de configuração durante a instalação: - `--values` (ou `-f`): Especifica um arquivo YAML com sobrescritas. Isso pode ser especificado várias vezes, e o arquivo mais à direita terá precedência - `--set`: Especifica sobrescritas na linha de comando. Se ambos forem usados, os valores de `--set` são mesclados em `--values` com maior precedência. As sobrescritas especificadas com `--set` são persistidas em um Secret. Valores que foram definidos com `--set` podem ser visualizados para uma release específica com `helm get values `. Valores que foram definidos com `--set` podem ser limpos executando `helm upgrade` com `--reset-values` especificado. #### Formato e Limitações do `--set` A opção `--set` recebe zero ou mais pares de nome/valor. Na sua forma mais simples, é usada assim: `--set name=value`. O equivalente em YAML seria: ```yaml name: value ``` Múltiplos valores são separados por vírgulas. Então `--set a=b,c=d` se torna: ```yaml a: b c: d ``` Expressões mais complexas são suportadas. Por exemplo, `--set outer.inner=value` é traduzido para: ```yaml outer: inner: value ``` Listas podem ser expressas envolvendo valores em `{` e `}`. Por exemplo, `--set name={a, b, c}` se traduz em: ```yaml name: - a - b - c ``` Certos nomes/chaves podem ser definidos como `null` ou como um array vazio `[]`. Por exemplo, `--set name=[],a=null` transforma ```yaml name: - a - b - c a: b ``` em ```yaml name: [] a: null ``` A partir do Helm 2.5.0, é possível acessar itens de lista usando uma sintaxe de índice de array. Por exemplo, `--set servers[0].port=80` se torna: ```yaml servers: - port: 80 ``` Múltiplos valores podem ser definidos dessa forma. A linha `--set servers[0].port=80,servers[0].host=example` se torna: ```yaml servers: - port: 80 host: example ``` Às vezes você precisa usar caracteres especiais nas suas linhas `--set`. Você pode usar uma barra invertida para escapar os caracteres; `--set name=value1\,value2` se tornará: ```yaml name: "value1,value2" ``` Da mesma forma, você pode escapar sequências de pontos, o que pode ser útil quando os Charts usam a função `toYaml` para analisar annotations, labels e node selectors. A sintaxe de `--set nodeSelector."kubernetes\.io/role"=master` se torna: ```yaml nodeSelector: kubernetes.io/role: master ``` Estruturas de dados muito aninhadas podem ser difíceis de expressar usando `--set`. Recomenda-se que os desenvolvedores de Charts considerem o uso de `--set` ao projetar o formato de um arquivo `values.yaml` (consulte [Arquivos de Values](/chart_template_guide/values_files.md)). ### Mais Métodos de Instalação O comando `helm install` pode instalar a partir de várias fontes: - Um repositório de Charts (como vimos acima) - Um arquivo de Chart local (`helm install foo foo-0.1.1.tgz`) - Um diretório de Chart descompactado (`helm install foo path/to/foo`) - Uma URL completa (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' e 'helm rollback': Atualizando uma Release e Revertendo em Caso de Falha Quando uma nova versão de um Chart é lançada, ou quando você quer alterar a configuração da sua release, você pode usar o comando `helm upgrade`. Um upgrade pega uma release existente e a atualiza de acordo com as informações que você fornece. Como os Charts do Kubernetes podem ser grandes e complexos, o Helm tenta realizar o upgrade menos invasivo possível. Ele atualizará apenas o que mudou desde a última release. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` No caso acima, a release `happy-panda` é atualizada com o mesmo Chart, mas com um novo arquivo YAML: ```yaml mariadb.auth.username: user1 ``` Podemos usar `helm get values` para ver se essa nova configuração foi aplicada. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` O comando `helm get` é uma ferramenta útil para examinar uma release no cluster. E como podemos ver acima, ele mostra que nossos novos valores de `panda.yaml` foram aplicados no cluster. Agora, se algo não sair como planejado durante uma release, é fácil reverter para uma release anterior usando `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` O comando acima reverte nossa happy-panda para sua primeira versão de release. Uma versão de release é uma revisão incremental. Cada vez que uma instalação, upgrade ou rollback acontece, o número de revisão é incrementado em 1. O primeiro número de revisão é sempre 1. E podemos usar `helm history [RELEASE]` para ver os números de revisão de uma release específica. ## Opções Úteis para Install/Upgrade/Rollback Existem várias outras opções úteis que você pode especificar para personalizar o comportamento do Helm durante uma instalação/upgrade/rollback. Por favor, note que esta não é uma lista completa de flags do CLI. Para ver uma descrição de todas as flags, execute `helm --help`. - `--timeout`: Um valor de [duração Go](https://golang.org/pkg/time/#ParseDuration) para esperar a conclusão dos comandos do Kubernetes. O padrão é `5m0s`. - `--wait`: Aguarda até que todos os Pods estejam em estado pronto, PVCs estejam vinculados, Deployments tenham o mínimo (`Desired` menos `maxUnavailable`) de Pods em estado pronto e Services tenham um endereço IP (e Ingress se for um `LoadBalancer`) antes de marcar a release como bem-sucedida. Aguardará pelo tempo definido em `--timeout`. Se o timeout for atingido, a release será marcada como `FAILED`. Nota: Em cenários onde o Deployment tem `replicas` definido como 1 e `maxUnavailable` não está definido como 0 como parte da estratégia de rolling update, `--wait` retornará como pronto assim que satisfizer a condição mínima de Pod pronto. - `--no-hooks`: Pula a execução dos hooks para o comando - `--recreate-pods` (disponível apenas para `upgrade` e `rollback`): Esta flag fará com que todos os pods sejam recriados (com exceção de pods pertencentes a deployments). (DESCONTINUADO no Helm 3) ## 'helm uninstall': Desinstalando uma Release Quando chegar a hora de desinstalar uma release do cluster, use o comando `helm uninstall`: ```console $ helm uninstall happy-panda ``` Isso removerá a release do cluster. Você pode ver todas as suas releases atualmente implantadas com o comando `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` Na saída acima, podemos ver que a release `happy-panda` foi desinstalada. Em versões anteriores do Helm, quando uma release era excluída, um registro de sua exclusão permanecia. No Helm 3, a exclusão remove o registro da release também. Se você deseja manter um registro de exclusão da release, use `helm uninstall --keep-history`. Usando `helm list --uninstalled` mostrará apenas as releases que foram desinstaladas com a flag `--keep-history`. A flag `helm list --all` mostrará todos os registros de release que o Helm manteve, incluindo registros de itens com falha ou excluídos (se `--keep-history` foi especificado): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Note que, como as releases agora são excluídas por padrão, não é mais possível reverter um recurso desinstalado. ## 'helm repo': Trabalhando com Repositórios O Helm 3 não vem mais com um repositório de Charts padrão. O grupo de comandos `helm repo` fornece comandos para adicionar, listar e remover repositórios. Você pode ver quais repositórios estão configurados usando `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` E novos repositórios podem ser adicionados com `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Como os repositórios de Charts mudam frequentemente, a qualquer momento você pode garantir que seu cliente Helm esteja atualizado executando `helm repo update`. Repositórios podem ser removidos com `helm repo remove`. ## Criando Seus Próprios Charts O [Guia de Desenvolvimento de Charts](/topics/charts.md) explica como desenvolver seus próprios Charts. Mas você pode começar rapidamente usando o comando `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Agora há um Chart em `./deis-workflow`. Você pode editá-lo e criar seus próprios templates. Enquanto edita seu Chart, você pode validar se ele está bem formado executando `helm lint`. Quando chegar a hora de empacotar o Chart para distribuição, você pode executar o comando `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` E esse Chart agora pode ser facilmente instalado com `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Charts que são empacotados podem ser carregados em repositórios de Charts. Consulte a documentação sobre [repositórios de Charts do Helm](/topics/chart_repository.md) para mais detalhes. ## Conclusão Este capítulo abordou os padrões básicos de uso do cliente `helm`, incluindo pesquisa, instalação, upgrade e desinstalação. Também abordou comandos utilitários úteis como `helm status`, `helm get` e `helm repo`. Para mais informações sobre esses comandos, consulte a ajuda integrada do Helm: `helm help`. No [próximo capítulo](/howto/charts_tips_and_tricks.md), veremos o processo de desenvolvimento de Charts. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Introdução description: Apresenta o SDK Go do Helm sidebar_position: 1 --- O SDK Go do Helm permite que software personalizado aproveite os charts do Helm e a funcionalidade do Helm para gerenciar a implantação de software no Kubernetes (Na verdade, a CLI do Helm é efetivamente apenas uma dessas ferramentas!) Atualmente, o SDK foi funcionalmente separado da CLI do Helm. O SDK pode ser (e é) utilizado por ferramentas independentes. O projeto Helm se comprometeu com a estabilidade da API para o SDK. Vale ressaltar que o SDK ainda tem algumas arestas, remanescentes do trabalho inicial de separação entre a CLI e o SDK, que o projeto Helm pretende melhorar ao longo do tempo. A documentação completa da API pode ser encontrada em [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Uma breve visão geral de alguns dos principais tipos de pacotes e um exemplo simples seguem abaixo. Consulte a seção [Exemplos](/sdk/examples.mdx) para mais exemplos e um 'driver' mais completo. ## Visão geral dos principais pacotes - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Contém o "cliente" principal para executar ações do Helm. Este é o mesmo pacote que a CLI usa internamente. Se você precisa apenas executar comandos básicos do Helm a partir de outro programa Go, este pacote é para você - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Métodos e utilitários utilizados para carregar e manipular charts - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) e seus subpacotes: Contém todos os manipuladores para as variáveis de ambiente padrão do Helm e seus subpacotes contêm manipulação de saída e arquivos de valores - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Define o objeto `Release` e seus status Existem muitos outros pacotes além desses, então consulte a documentação para mais informações! ### Exemplo simples Este é um exemplo simples de como executar um `helm list` usando o SDK Go. Consulte a seção [Exemplos](/sdk/examples.mdx) para exemplos mais completos. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Compatibilidade O SDK do Helm segue explicitamente as garantias de compatibilidade retroativa do Helm: Ou seja, mudanças que quebram compatibilidade só serão feitas em versões principais (major). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Técnicas Avançadas do Helm description: Explica várias funcionalidades avançadas para usuários experientes do Helm sidebar_position: 9 --- Esta seção explica várias funcionalidades e técnicas avançadas para usar o Helm. As informações nesta seção são destinadas a "usuários experientes" do Helm que desejam fazer personalizações e manipulações avançadas de seus charts e releases. Cada uma dessas funcionalidades avançadas vem com seus próprios compromissos e ressalvas, então cada uma deve ser usada com cuidado e com conhecimento aprofundado do Helm. Em outras palavras, lembre-se do [Princípio do Peter Parker](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Pós-Renderização A pós-renderização permite que instaladores de charts manipulem, configurem e/ou validem manualmente os manifests renderizados antes de serem instalados pelo Helm. Isso permite que usuários com necessidades de configuração avançadas usem ferramentas como [`kustomize`](https://kustomize.io) para aplicar mudanças de configuração sem a necessidade de fazer fork de um chart público ou exigir que os mantenedores de charts especifiquem cada última opção de configuração para um software. Também existem casos de uso para injetar ferramentas comuns e sidecars em ambientes corporativos ou análise dos manifests antes da implantação. ### Pré-requisitos - Helm 3.1+ ### Uso Um pós-renderizador pode ser qualquer executável que aceite manifests Kubernetes renderizados via STDIN e retorne manifests Kubernetes válidos via STDOUT. Ele deve retornar um código de saída diferente de 0 em caso de falha. Esta é a única "API" entre os dois componentes. Isso permite grande flexibilidade no que você pode fazer com seu processo de pós-renderização. Um pós-renderizador pode ser usado com `install`, `upgrade` e `template`. Para usar um pós-renderizador, use a flag `--post-renderer` com o caminho para o executável do renderizador que você deseja usar: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Se o caminho não contiver nenhum separador, ele será buscado em $PATH, caso contrário, caminhos relativos serão resolvidos para um caminho totalmente qualificado. Se você deseja usar múltiplos pós-renderizadores, chame todos eles em um script ou em qualquer ferramenta binária que você tenha construído. Em bash, isso seria tão simples quanto `renderer1 | renderer2 | renderer3`. Você pode ver um exemplo de uso do `kustomize` como pós-renderizador [aqui](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Ressalvas Ao usar pós-renderizadores, existem várias coisas importantes a ter em mente. A mais importante delas é que, ao usar um pós-renderizador, todas as pessoas que modificam essa release **DEVEM** usar o mesmo renderizador para ter builds reprodutíveis. Esta funcionalidade foi propositalmente construída para permitir que qualquer usuário troque qual renderizador está usando ou pare de usar um renderizador, mas isso deve ser feito deliberadamente para evitar modificações acidentais ou perda de dados. Outra nota importante é sobre segurança. Se você está usando um pós-renderizador, você deve garantir que ele venha de uma fonte confiável (como é o caso para qualquer outro executável arbitrário). Usar renderizadores não confiáveis ou não verificados NÃO é recomendado, pois eles têm acesso completo aos templates renderizados, que frequentemente contêm dados sensíveis. ### Pós-Renderizadores Personalizados O passo de pós-renderização oferece ainda mais flexibilidade quando usado no Go SDK. Qualquer pós-renderizador só precisa implementar a seguinte interface Go: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Para mais informações sobre como usar o Go SDK, veja a [seção Go SDK](#go-sdk). ## Go SDK O Helm 3 introduziu um Go SDK completamente reestruturado para uma melhor experiência ao construir software e ferramentas que aproveitam o Helm. Documentação completa pode ser encontrada na [Seção Go SDK](/sdk/gosdk.md). ## Backends de armazenamento O Helm 3 mudou o armazenamento padrão de informações de release para Secrets no namespace da release. O Helm 2 armazenava por padrão informações de release como ConfigMaps no namespace da instância do Tiller. As subseções a seguir mostram como configurar diferentes backends. Esta configuração é baseada na variável de ambiente `HELM_DRIVER`. Ela pode ser definida como um dos valores: `[configmap, secret, sql]`. ### Backend de armazenamento ConfigMap Para habilitar o backend ConfigMap, você precisará definir a variável de ambiente `HELM_DRIVER` para `configmap`. Você pode defini-la no shell da seguinte forma: ```shell export HELM_DRIVER=configmap ``` Se você deseja mudar do backend padrão para o backend ConfigMap, você terá que fazer a migração por conta própria. Você pode recuperar as informações de release com o seguinte comando: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **NOTAS DE PRODUÇÃO**: As informações de release incluem o conteúdo dos charts e arquivos values, e portanto podem conter dados sensíveis (como senhas, chaves privadas e outras credenciais) que precisam ser protegidos de acesso não autorizado. Ao gerenciar autorização no Kubernetes, por exemplo com [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), é possível conceder acesso mais amplo a recursos ConfigMap, enquanto restringe acesso a recursos Secret. Por exemplo, a [role padrão voltada para usuários](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" concede acesso à maioria dos recursos, mas não a Secrets. Além disso, os dados de secrets podem ser configurados para [armazenamento criptografado](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Por favor, tenha isso em mente se você decidir mudar para o backend ConfigMap, pois isso pode expor dados sensíveis da sua aplicação. ### Backend de armazenamento SQL Existe um backend de armazenamento SQL em ***beta*** que armazena informações de release em um banco de dados SQL. Usar tal backend de armazenamento é particularmente útil se suas informações de release pesam mais de 1MB (nesse caso, não podem ser armazenadas em ConfigMaps/Secrets devido a limites internos no armazenamento key-value etcd subjacente do Kubernetes). Para habilitar o backend SQL, você precisará implantar um banco de dados SQL e definir a variável de ambiente `HELM_DRIVER` para `sql`. Os detalhes do banco de dados são definidos com a variável de ambiente `HELM_DRIVER_SQL_CONNECTION_STRING`. Você pode defini-las no shell da seguinte forma: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Nota: Apenas PostgreSQL é suportado no momento. **NOTAS DE PRODUÇÃO**: É recomendado: - Deixar seu banco de dados pronto para produção. Para PostgreSQL, consulte a documentação de [Administração de Servidor](https://www.postgresql.org/docs/12/admin.html) para mais detalhes - Habilitar [gerenciamento de permissões](/topics/permissions_sql_storage_backend.md) para espelhar o RBAC do Kubernetes para informações de release Se você deseja mudar do backend padrão para o backend SQL, você terá que fazer a migração por conta própria. Você pode recuperar as informações de release com o seguinte comando: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Arquitetura do Helm description: Descreve a arquitetura do Helm em alto nível. sidebar_position: 8 --- # Arquitetura do Helm Este documento descreve a arquitetura do Helm em alto nível. ## O Propósito do Helm O Helm é uma ferramenta para gerenciar pacotes do Kubernetes chamados _charts_. O Helm pode fazer o seguinte: - Criar novos charts do zero - Empacotar charts em arquivos compactados (tgz) - Interagir com repositórios de charts onde os charts são armazenados - Instalar e desinstalar charts em um cluster Kubernetes existente - Gerenciar o ciclo de vida de releases de charts que foram instalados com o Helm Para o Helm, existem três conceitos importantes: 1. O _chart_ é um pacote de informações necessárias para criar uma instância de uma aplicação Kubernetes. 2. A _config_ contém informações de configuração que podem ser mescladas em um chart empacotado para criar um objeto de release. 3. Uma _release_ é uma instância em execução de um _chart_, combinada com uma _config_ específica. ## Componentes O Helm é um executável que é implementado em duas partes distintas: **O Cliente Helm** é um cliente de linha de comando para usuários finais. O cliente é responsável pelo seguinte: - Desenvolvimento local de charts - Gerenciamento de repositórios - Gerenciamento de releases - Interface com a biblioteca do Helm - Enviar charts para serem instalados - Solicitar atualização ou desinstalação de releases existentes **A Biblioteca do Helm** fornece a lógica para executar todas as operações do Helm. Ela interage com o servidor de API do Kubernetes e oferece as seguintes funcionalidades: - Combinar um chart e uma configuração para construir uma release - Instalar charts no Kubernetes e fornecer o objeto de release subsequente - Atualizar e desinstalar charts interagindo com o Kubernetes A biblioteca independente do Helm encapsula a lógica do Helm para que possa ser aproveitada por diferentes clientes. ## Implementação O cliente e a biblioteca do Helm são escritos na linguagem de programação Go. A biblioteca usa a biblioteca cliente do Kubernetes para se comunicar com o Kubernetes. Atualmente, essa biblioteca usa REST+JSON. Ela armazena informações em Secrets localizados dentro do Kubernetes. Ela não necessita de um banco de dados próprio. Os arquivos de configuração são, quando possível, escritos em YAML. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Guia do Repositório de Charts description: Como criar e trabalhar com repositórios de charts do Helm. sidebar_position: 6 --- Esta seção explica como criar e trabalhar com repositórios de charts do Helm. De forma geral, um repositório de charts é um local onde charts empacotados podem ser armazenados e compartilhados. O repositório comunitário distribuído de charts do Helm está localizado no [Artifact Hub](https://artifacthub.io/packages/search?kind=0) e aceita participação. Mas o Helm também permite criar e executar seu próprio repositório de charts. Este guia explica como fazer isso. Se você está considerando criar um repositório de charts, pode ser interessante considerar o uso de um [registry OCI](./registries.md) como alternativa. ## Pré-requisitos * Consulte o guia de [Início Rápido](/intro/quickstart.md) * Leia o documento sobre [Charts](./charts.md) ## Criar um repositório de charts Um _repositório de charts_ é um servidor HTTP que hospeda um arquivo `index.yaml` e, opcionalmente, alguns charts empacotados. Quando você estiver pronto para compartilhar seus charts, a forma preferida de fazer isso é enviá-los para um repositório de charts. A partir do Helm 2.2.0, há suporte para autenticação SSL do lado do cliente em um repositório. Outros protocolos de autenticação podem estar disponíveis como plugins. Como um repositório de charts pode ser qualquer servidor HTTP capaz de servir arquivos YAML e tar e responder a requisições GET, há diversas opções para hospedar seu próprio repositório de charts. Por exemplo, você pode usar um bucket do Google Cloud Storage (GCS), um bucket do Amazon S3, GitHub Pages, ou até mesmo criar seu próprio servidor web. ### A estrutura do repositório de charts Um repositório de charts consiste em charts empacotados e um arquivo especial chamado `index.yaml` que contém um índice de todos os charts no repositório. Frequentemente, os charts que o `index.yaml` descreve também são hospedados no mesmo servidor, assim como os [arquivos de proveniência](./provenance.md). Por exemplo, o layout do repositório `https://example.com/charts` pode ser assim: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` Neste caso, o arquivo de índice conteria informações sobre um chart, o chart Alpine, e forneceria a URL de download `https://example.com/charts/alpine-0.1.2.tgz` para esse chart. Não é obrigatório que o pacote do chart esteja localizado no mesmo servidor que o arquivo `index.yaml`. No entanto, fazer isso é frequentemente a opção mais simples. ### O arquivo de índice O arquivo de índice é um arquivo yaml chamado `index.yaml`. Ele contém alguns metadados sobre o pacote, incluindo o conteúdo do arquivo `Chart.yaml` do chart. Um repositório de charts válido deve ter um arquivo de índice. O arquivo de índice contém informações sobre cada chart no repositório de charts. O comando `helm repo index` gera um arquivo de índice com base em um diretório local que contém charts empacotados. Este é um exemplo de um arquivo de índice: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Hospedando Repositórios de Charts Esta parte mostra várias formas de servir um repositório de charts. ### Google Cloud Storage O primeiro passo é **criar seu bucket GCS**. Vamos chamar o nosso de `fantastic-charts`. ![Criar um Bucket GCS](/img/helm2/create-a-bucket.png) Em seguida, torne seu bucket público **editando as permissões do bucket**. ![Editar Permissões](/img/helm2/edit-permissions.png) Insira esta linha para **tornar seu bucket público**: ![Tornar o Bucket Público](/img/helm2/make-bucket-public.png) Parabéns, agora você tem um bucket GCS vazio pronto para servir charts! Você pode enviar seu repositório de charts usando a ferramenta de linha de comando do Google Cloud Storage ou usando a interface web do GCS. Um bucket GCS público pode ser acessado via HTTPS simples neste endereço: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith Você também pode configurar repositórios de charts usando o Cloudsmith. Leia mais sobre repositórios de charts com Cloudsmith [aqui](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory Da mesma forma, você também pode configurar repositórios de charts usando o JFrog Artifactory. Leia mais sobre repositórios de charts com JFrog Artifactory [aqui](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### Exemplo com GitHub Pages De maneira semelhante, você pode criar um repositório de charts usando GitHub Pages. O GitHub permite servir páginas web estáticas de duas formas diferentes: - Configurando um projeto para servir o conteúdo do seu diretório `docs/` - Configurando um projeto para servir uma branch específica Vamos usar a segunda abordagem, embora a primeira seja igualmente fácil. O primeiro passo será **criar sua branch gh-pages**. Você pode fazer isso localmente assim: ```console $ git checkout -b gh-pages ``` Ou pelo navegador web usando o botão **Branch** no seu repositório GitHub: ![Criar branch GitHub Pages](/img/helm2/create-a-gh-page-button.png) Em seguida, você vai querer ter certeza de que sua **branch gh-pages** está configurada como GitHub Pages. Clique nas **Configurações** do seu repositório e role para baixo até a seção **GitHub pages** e configure conforme abaixo: ![Criar branch GitHub Pages](/img/helm2/set-a-gh-page.png) Por padrão, a **Source** geralmente é configurada para a **branch gh-pages**. Se isso não estiver configurado por padrão, selecione-a. Você pode usar um **domínio personalizado** ali, se desejar. E verifique se **Enforce HTTPS** está marcado, para que o **HTTPS** seja usado quando os charts forem servidos. Com essa configuração, você pode usar sua branch padrão para armazenar o código dos seus charts, e a **branch gh-pages** como repositório de charts, por exemplo: `https://USERNAME.github.io/REPONAME`. O repositório de demonstração [TS Charts](https://github.com/technosophos/tscharts) está acessível em `https://technosophos.github.io/tscharts/`. Se você decidiu usar o GitHub Pages para hospedar o repositório de charts, consulte a [Chart Releaser Action](/howto/chart_releaser_action.md). A Chart Releaser Action é um workflow do GitHub Action para transformar um projeto GitHub em um repositório de charts Helm auto-hospedado, usando a ferramenta CLI [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Servidores web comuns Para configurar um servidor web comum para servir charts do Helm, você simplesmente precisa fazer o seguinte: - Colocar seu índice e charts em um diretório que o servidor possa servir - Garantir que o arquivo `index.yaml` possa ser acessado sem requisitos de autenticação - Garantir que arquivos `yaml` sejam servidos com o tipo de conteúdo correto (`text/yaml` ou `text/x-yaml`) Por exemplo, se você quiser servir seus charts a partir de `$WEBROOT/charts`, certifique-se de que existe um diretório `charts/` na raiz web, e coloque o arquivo de índice e os charts dentro dessa pasta. ### Servidor de Repositório ChartMuseum O ChartMuseum é um servidor de Repositório de Charts Helm de código aberto escrito em Go (Golang), com suporte para backends de armazenamento em nuvem, incluindo [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) e [etcd](https://etcd.io/). Você também pode usar o servidor [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) para hospedar um repositório de charts a partir de um sistema de arquivos local. ### GitLab Package Registry Com o GitLab, você pode publicar charts Helm no Package Registry do seu projeto. Leia mais sobre como configurar um repositório de pacotes helm com o GitLab [aqui](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Gerenciando Repositórios de Charts Agora que você tem um repositório de charts, a última parte deste guia explica como manter charts nesse repositório. ### Armazenar charts no seu repositório de charts Agora que você tem um repositório de charts, vamos fazer upload de um chart e um arquivo de índice para o repositório. Charts em um repositório de charts devem ser empacotados (`helm package chart-name/`) e versionados corretamente (seguindo as diretrizes do [SemVer 2](https://semver.org/)). Os próximos passos compõem um exemplo de fluxo de trabalho, mas você pode usar qualquer fluxo de trabalho que preferir para armazenar e atualizar charts no seu repositório de charts. Uma vez que você tenha um chart empacotado pronto, crie um novo diretório e mova seu chart empacotado para esse diretório. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` O último comando pega o caminho do diretório local que você acabou de criar e a URL do seu repositório de charts remoto e compõe um arquivo `index.yaml` dentro do caminho do diretório fornecido. Agora você pode fazer upload do chart e do arquivo de índice para seu repositório de charts usando uma ferramenta de sincronização ou manualmente. Se você estiver usando o Google Cloud Storage, confira este [exemplo de fluxo de trabalho](/howto/chart_repository_sync_example.md) usando o cliente gsutil. Para o GitHub, você pode simplesmente colocar os charts na branch de destino apropriada. ### Adicionar novos charts a um repositório existente Cada vez que você quiser adicionar um novo chart ao seu repositório, você deve regenerar o índice. O comando `helm repo index` irá reconstruir completamente o arquivo `index.yaml` do zero, incluindo apenas os charts que encontrar localmente. No entanto, você pode usar a flag `--merge` para adicionar incrementalmente novos charts a um arquivo `index.yaml` existente (uma ótima opção ao trabalhar com um repositório remoto como o GCS). Execute `helm repo index --help` para saber mais. Certifique-se de fazer upload tanto do arquivo `index.yaml` revisado quanto do chart. E se você gerou um arquivo de proveniência, faça upload dele também. ### Compartilhar seus charts com outros Quando estiver pronto para compartilhar seus charts, simplesmente informe a alguém qual é a URL do seu repositório. A partir daí, eles adicionarão o repositório ao seu cliente helm via o comando `helm repo add [NOME] [URL]` com qualquer nome que desejarem usar para referenciar o repositório. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Se os charts estiverem protegidos por autenticação básica HTTP, você também pode fornecer o nome de usuário e senha aqui: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Nota:** Um repositório não será adicionado se não contiver um `index.yaml` válido. **Nota:** Se seu repositório helm usa, por exemplo, um certificado autoassinado, você pode usar `helm repo add --insecure-skip-tls-verify ...` para ignorar a verificação de CA. Depois disso, seus usuários poderão pesquisar seus charts. Após você atualizar o repositório, eles podem usar o comando `helm repo update` para obter as informações mais recentes do chart. *Por baixo dos panos, os comandos `helm repo add` e `helm repo update` buscam o arquivo index.yaml e o armazenam no diretório `$XDG_CACHE_HOME/helm/repository/cache/`. É onde a função `helm search` encontra informações sobre os charts.* ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Testes de Chart description: Descreve como executar e testar seus charts. sidebar_position: 3 --- Um chart contém vários recursos e componentes do Kubernetes que funcionam juntos. Como autor de um chart, você pode querer escrever alguns testes que validem que seu chart funciona conforme esperado quando é instalado. Esses testes também ajudam o consumidor do chart a entender o que seu chart deve fazer. Um **teste** em um chart Helm fica no diretório `templates/` e é uma definição de job que especifica um container com um comando dado para executar. O container deve sair com sucesso (exit 0) para que o teste seja considerado bem-sucedido. A definição do job deve conter a anotação de hook de teste do Helm: `helm.sh/hook: test`. Note que até o Helm v3, a definição do job precisava conter uma dessas anotações de hook de teste do Helm: `helm.sh/hook: test-success` ou `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` ainda é aceita como uma alternativa para compatibilidade com versões anteriores de `helm.sh/hook: test`. Exemplos de testes: - Validar que sua configuração do arquivo values.yaml foi injetada corretamente. - Certificar-se de que seu nome de usuário e senha funcionam corretamente - Certificar-se de que um nome de usuário e senha incorretos não funcionam - Verificar que seus serviços estão ativos e fazendo balanceamento de carga corretamente - etc. Você pode executar os testes pré-definidos no Helm em uma release usando o comando `helm test `. Para um consumidor de chart, esta é uma ótima maneira de verificar que a release de um chart (ou aplicação) funciona conforme esperado. ## Exemplo de Teste O comando [helm create](/helm/helm_create.md) criará automaticamente várias pastas e arquivos. Para experimentar a funcionalidade de teste do Helm, primeiro crie um chart Helm de demonstração. ```console $ helm create demo ``` Agora você poderá ver a seguinte estrutura no seu chart Helm de demonstração. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` Em `demo/templates/tests/test-connection.yaml` você verá um teste que pode experimentar. Você pode ver a definição do pod de teste do Helm aqui: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Passos para Executar uma Suíte de Testes em uma Release Primeiro, instale o chart no seu cluster para criar uma release. Você pode precisar esperar que todos os pods fiquem ativos; se você testar imediatamente após esta instalação, é provável que ocorra uma falha transitória, e você vai querer testar novamente. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Notas - Você pode definir quantos testes quiser em um único arquivo yaml ou distribuí-los em vários arquivos yaml no diretório `templates/`. - Você pode aninhar sua suíte de testes em um diretório `tests/` como `/templates/tests/` para maior isolamento. - Um teste é um [hook do Helm](/topics/charts_hooks.md), então anotações como `helm.sh/hook-weight` e `helm.sh/hook-delete-policy` podem ser usadas com recursos de teste. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Charts description: Explica o formato de chart e fornece orientações básicas para criar charts com o Helm. sidebar_position: 1 --- O Helm usa um formato de empacotamento chamado _charts_. Um chart é uma coleção de arquivos que descrevem um conjunto relacionado de recursos do Kubernetes. Um único chart pode ser usado para implantar algo simples, como um pod do memcached, ou algo complexo, como uma pilha completa de aplicação web com servidores HTTP, bancos de dados, caches e assim por diante. Os charts são criados como arquivos organizados em uma estrutura de diretórios específica. Eles podem ser empacotados em arquivos compactados versionados para serem implantados. Se você deseja baixar e examinar os arquivos de um chart publicado, sem instalá-lo, você pode fazer isso com `helm pull chartrepo/chartname`. Este documento explica o formato de chart e fornece orientações básicas para criar charts com o Helm. ## A Estrutura de Arquivos do Chart Um chart é organizado como uma coleção de arquivos dentro de um diretório. O nome do diretório é o nome do chart (sem informações de versão). Assim, um chart que descreve o WordPress seria armazenado em um diretório `wordpress/`. Dentro deste diretório, o Helm espera uma estrutura que corresponda a isto: ```text wordpress/ Chart.yaml # Um arquivo YAML contendo informações sobre o chart LICENSE # OPCIONAL: Um arquivo de texto simples contendo a licença do chart README.md # OPCIONAL: Um arquivo README legível values.yaml # Os valores de configuração padrão para este chart values.schema.json # OPCIONAL: Um JSON Schema para impor uma estrutura ao arquivo values.yaml charts/ # Um diretório contendo quaisquer charts dos quais este chart depende. crds/ # Custom Resource Definitions templates/ # Um diretório de templates que, quando combinados com values, # irão gerar arquivos de manifesto Kubernetes válidos. templates/NOTES.txt # OPCIONAL: Um arquivo de texto simples contendo notas de uso breves ``` O Helm reserva o uso dos diretórios `charts/`, `crds/` e `templates/`, e dos nomes de arquivos listados. Outros arquivos serão deixados como estão. ## O Arquivo Chart.yaml O arquivo `Chart.yaml` é obrigatório para um chart. Ele contém os seguintes campos: ```yaml apiVersion: A versão da API do chart (obrigatório) name: O nome do chart (obrigatório) version: A versão do chart (obrigatório) kubeVersion: Um intervalo SemVer de versões compatíveis do Kubernetes (opcional) description: Uma descrição de uma frase deste projeto (opcional) type: O tipo do chart (opcional) keywords: - Uma lista de palavras-chave sobre este projeto (opcional) home: A URL da página inicial deste projeto (opcional) sources: - Uma lista de URLs para o código-fonte deste projeto (opcional) dependencies: # Uma lista das dependências do chart (opcional) - name: O nome do chart (nginx) version: A versão do chart ("1.2.3") repository: (opcional) A URL do repositório ("https://example.com/charts") ou alias ("@repo-name") condition: (opcional) Um caminho yaml que resolve para um booleano, usado para habilitar/desabilitar charts (ex: subchart1.enabled) tags: # (opcional) - Tags podem ser usadas para agrupar charts para habilitar/desabilitar juntos import-values: # (opcional) - ImportValues contém o mapeamento de valores de origem para a chave pai a ser importada. Cada item pode ser uma string ou par de itens de sublista filho/pai. alias: (opcional) Alias a ser usado para o chart. Útil quando você precisa adicionar o mesmo chart várias vezes maintainers: # (opcional) - name: O nome do mantenedor (obrigatório para cada mantenedor) email: O email do mantenedor (opcional para cada mantenedor) url: Uma URL para o mantenedor (opcional para cada mantenedor) icon: Uma URL para uma imagem SVG ou PNG para ser usada como ícone (opcional). appVersion: A versão da aplicação que este contém (opcional). Não precisa ser SemVer. Aspas recomendadas. deprecated: Se este chart está obsoleto (opcional, booleano) annotations: example: Uma lista de anotações identificadas por nome (opcional). ``` A partir da [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), campos adicionais não são permitidos. A abordagem recomendada é adicionar metadados personalizados em `annotations`. ### Charts e Versionamento Cada chart deve ter um número de versão. Uma versão deve seguir o padrão [SemVer 2](https://semver.org/spec/v2.0.0.html), mas não é rigorosamente obrigatório. Diferente do Helm Classic, o Helm v2 e posteriores usam números de versão como marcadores de release. Pacotes em repositórios são identificados por nome mais versão. Por exemplo, um chart `nginx` cujo campo de versão é definido como `version: 1.2.3` será nomeado: ```text nginx-1.2.3.tgz ``` Nomes SemVer 2 mais complexos também são suportados, como `version: 1.2.3-alpha.1+ef365`. Mas nomes não-SemVer são explicitamente proibidos pelo sistema. Exceções são feitas para versões no formato `x` ou `x.y`. Por exemplo, se houver um `v` inicial ou uma versão listada sem todas as 3 partes (ex: v1.2), o sistema tentará convertê-la para uma versão semântica válida (ex: v1.2.0). **NOTA:** Enquanto o Helm Classic e o Deployment Manager eram muito orientados ao GitHub quando se tratava de charts, o Helm v2 e posteriores não dependem ou exigem GitHub ou mesmo Git. Consequentemente, ele não usa Git SHAs para versionamento. O campo `version` dentro do `Chart.yaml` é usado por muitas ferramentas do Helm, incluindo a CLI. Ao gerar um pacote, o comando `helm package` usará a versão que encontrar no `Chart.yaml` como um token no nome do pacote. O sistema assume que o número da versão no nome do pacote do chart corresponde ao número da versão no `Chart.yaml`. Se essa condição não for atendida, ocorrerá um erro. ### O Campo `apiVersion` O campo `apiVersion` deve ser `v2` para charts Helm que requerem pelo menos Helm 3. Charts que suportam versões anteriores do Helm têm um `apiVersion` definido como `v1` e ainda são instaláveis pelo Helm 3. Mudanças de `v1` para `v2`: - Um campo `dependencies` definindo dependências do chart, que estavam localizadas em um arquivo `requirements.yaml` separado para charts `v1` (veja [Dependências do Chart](#dependências-do-chart)). - O campo `type`, discriminando charts de aplicação e biblioteca (veja [Tipos de Chart](#tipos-de-chart)). ### O Campo `appVersion` Note que o campo `appVersion` não está relacionado ao campo `version`. É uma forma de especificar a versão da aplicação. Por exemplo, o chart `drupal` pode ter um `appVersion: "8.2.1"`, indicando que a versão do Drupal incluída no chart (por padrão) é `8.2.1`. Este campo é informativo e não tem impacto nos cálculos de versão do chart. Colocar a versão entre aspas é altamente recomendado. Isso força o parser YAML a tratar o número da versão como uma string. Deixá-lo sem aspas pode levar a problemas de parsing em alguns casos. Por exemplo, o YAML interpreta `1.0` como um valor de ponto flutuante, e um SHA de commit git como `1234e10` como notação científica. A partir do Helm v3.5.0, `helm create` coloca o campo `appVersion` padrão entre aspas. ### O Campo `kubeVersion` O campo opcional `kubeVersion` pode definir restrições semver em versões suportadas do Kubernetes. O Helm validará as restrições de versão ao instalar o chart e falhará se o cluster executar uma versão não suportada do Kubernetes. As restrições de versão podem incluir comparações AND separadas por espaços como ``` >= 1.13.0 < 1.15.0 ``` que podem ser combinadas com o operador OR `||` como no exemplo a seguir ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` Neste exemplo, a versão `1.14.0` é excluída, o que pode fazer sentido se um bug em certas versões é conhecido por impedir o funcionamento adequado do chart. Além das restrições de versão usando operadores `=` `!=` `>` `<` `>=` `<=`, as seguintes notações abreviadas são suportadas: * intervalos com hífen para intervalos fechados, onde `1.1 - 2.3.4` é equivalente a `>= 1.1 <= 2.3.4`. * curingas `x`, `X` e `*`, onde `1.2.x` é equivalente a `>= 1.2.0 < 1.3.0`. * intervalos til (mudanças de versão patch permitidas), onde `~1.2.3` é equivalente a `>= 1.2.3 < 1.3.0`. * intervalos circunflexo (mudanças de versão minor permitidas), onde `^1.2.3` é equivalente a `>= 1.2.3 < 2.0.0`. Para uma explicação detalhada das restrições semver suportadas, veja [Masterminds/semver](https://github.com/Masterminds/semver). ### Descontinuando Charts Ao gerenciar charts em um Repositório de Charts, às vezes é necessário descontinuar um chart. O campo opcional `deprecated` no `Chart.yaml` pode ser usado para marcar um chart como descontinuado. Se a **última** versão de um chart no repositório estiver marcada como descontinuada, então o chart como um todo é considerado descontinuado. O nome do chart pode ser reutilizado posteriormente publicando uma versão mais nova que não esteja marcada como descontinuada. O fluxo de trabalho para descontinuar charts é: 1. Atualizar o `Chart.yaml` do chart para marcá-lo como descontinuado, incrementando a versão 2. Publicar a nova versão do chart no Repositório de Charts 3. Remover o chart do repositório de código-fonte (ex: git) ### Tipos de Chart O campo `type` define o tipo do chart. Existem dois tipos: `application` e `library`. Application é o tipo padrão e é o chart padrão que pode ser operado completamente. O [chart de biblioteca](/topics/library_charts.md) fornece utilitários ou funções para o construtor do chart. Um chart de biblioteca difere de um chart de aplicação porque não é instalável e geralmente não contém objetos de recursos. **Nota:** Um chart de aplicação pode ser usado como um chart de biblioteca. Isso é habilitado definindo o tipo como `library`. O chart será então renderizado como um chart de biblioteca onde todos os utilitários e funções podem ser aproveitados. Todos os objetos de recursos do chart não serão renderizados. ## Chart LICENSE, README e NOTES Os charts também podem conter arquivos que descrevem a instalação, configuração, uso e licença de um chart. Uma LICENSE é um arquivo de texto simples contendo a [licença](https://en.wikipedia.org/wiki/Software_license) do chart. O chart pode conter uma licença pois pode ter lógica de programação nos templates e, portanto, não seria apenas configuração. Também pode haver licença(s) separadas para a aplicação instalada pelo chart, se necessário. Um README para um chart deve ser formatado em Markdown (README.md), e geralmente deve conter: - Uma descrição da aplicação ou serviço que o chart fornece - Quaisquer pré-requisitos ou requisitos para executar o chart - Descrições das opções em `values.yaml` e valores padrão - Qualquer outra informação que possa ser relevante para a instalação ou configuração do chart Quando hubs e outras interfaces de usuário exibem detalhes sobre um chart, esses detalhes são extraídos do conteúdo do arquivo `README.md`. O chart também pode conter um breve arquivo de texto simples `templates/NOTES.txt` que será impresso após a instalação e ao visualizar o status de uma release. Este arquivo é avaliado como um [template](#templates-e-values), e pode ser usado para exibir notas de uso, próximos passos ou qualquer outra informação relevante para uma release do chart. Por exemplo, instruções podem ser fornecidas para conectar a um banco de dados ou acessar uma interface web. Como este arquivo é impresso no STDOUT ao executar `helm install` ou `helm status`, é recomendado manter o conteúdo breve e apontar para o README para mais detalhes. ## Dependências do Chart No Helm, um chart pode depender de qualquer número de outros charts. Essas dependências podem ser vinculadas dinamicamente usando o campo `dependencies` no `Chart.yaml` ou trazidas para o diretório `charts/` e gerenciadas manualmente. ### Gerenciando Dependências com o campo `dependencies` Os charts requeridos pelo chart atual são definidos como uma lista no campo `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - O campo `name` é o nome do chart que você deseja. - O campo `version` é a versão do chart que você deseja. - O campo `repository` é a URL completa para o repositório de charts. Note que você também deve usar `helm repo add` para adicionar esse repositório localmente. - Você pode usar o nome do repositório em vez da URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Depois de definir as dependências, você pode executar `helm dependency update` e ele usará seu arquivo de dependências para baixar todos os charts especificados para o seu diretório `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Quando `helm dependency update` obtém os charts, ele os armazenará como arquivos compactados de chart no diretório `charts/`. Então, para o exemplo acima, seria esperado ver os seguintes arquivos no diretório charts: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Campo alias em dependencies Além dos outros campos acima, cada entrada de requisitos pode conter o campo opcional `alias`. Adicionar um alias para um chart de dependência colocaria um chart nas dependências usando o alias como nome da nova dependência. Pode-se usar `alias` nos casos em que precisam acessar um chart com outro(s) nome(s). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` No exemplo acima, teremos 3 dependências no total para `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` A forma manual de conseguir isso é copiar/colar o mesmo chart no diretório `charts/` várias vezes com nomes diferentes. #### Campos Tags e Condition em dependencies Além dos outros campos acima, cada entrada de requisitos pode conter os campos opcionais `tags` e `condition`. Todos os charts são carregados por padrão. Se os campos `tags` ou `condition` estiverem presentes, eles serão avaliados e usados para controlar o carregamento do(s) chart(s) aos quais são aplicados. Condition - O campo condition contém um ou mais caminhos YAML (delimitados por vírgulas). Se este caminho existir nos values do pai de nível superior e resolver para um valor booleano, o chart será habilitado ou desabilitado com base nesse valor booleano. Apenas o primeiro caminho válido encontrado na lista é avaliado e se nenhum caminho existir, então a condição não tem efeito. Tags - O campo tags é uma lista YAML de rótulos para associar com este chart. Nos values do pai de nível superior, todos os charts com tags podem ser habilitados ou desabilitados especificando a tag e um valor booleano. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` No exemplo acima, todos os charts com a tag `front-end` seriam desabilitados, mas como o caminho `subchart1.enabled` avalia para 'true' nos values do pai, a condição sobrescreverá a tag `front-end` e `subchart1` será habilitado. Como `subchart2` está marcado com `back-end` e essa tag avalia para `true`, `subchart2` será habilitado. Note também que embora `subchart2` tenha uma condição especificada, não há caminho e valor correspondente nos values do pai, então essa condição não tem efeito. ##### Usando a CLI com Tags e Conditions O parâmetro `--set` pode ser usado como de costume para alterar valores de tags e conditions. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Resolução de Tags e Condition - **Conditions (quando definidas em values) sempre sobrescrevem tags.** O primeiro caminho de condition que existir vence e os subsequentes para esse chart são ignorados. - Tags são avaliadas como 'se qualquer uma das tags do chart for true, então habilite o chart'. - Valores de tags e conditions devem ser definidos nos values do pai de nível superior. - A chave `tags:` nos values deve ser uma chave de nível superior. Globals e tabelas `tags:` aninhadas não são atualmente suportadas. #### Importando Child Values via dependencies Em alguns casos, é desejável permitir que os values de um chart filho se propaguem para o chart pai e sejam compartilhados como padrões comuns. Um benefício adicional de usar o formato `exports` é que ele permitirá que ferramentas futuras inspecionem valores configuráveis pelo usuário. As chaves contendo os valores a serem importados podem ser especificadas no campo `import-values` nas `dependencies` do chart pai usando uma lista YAML. Cada item na lista é uma chave que é importada do campo `exports` do chart filho. Para importar valores não contidos na chave `exports`, use o formato [child-parent](#usando-o-formato-child-parent). Exemplos de ambos os formatos são descritos abaixo. ##### Usando o formato exports Se o arquivo `values.yaml` de um chart filho contiver um campo `exports` na raiz, seu conteúdo pode ser importado diretamente para os values do pai especificando as chaves a importar como no exemplo abaixo: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Como estamos especificando a chave `data` em nossa lista de importação, o Helm procura no campo `exports` do chart filho pela chave `data` e importa seu conteúdo. Os values finais do pai conteriam nosso campo exportado: ```yaml # parent's values myint: 99 ``` Note que a chave pai `data` não está contida nos values finais do pai. Se você precisar especificar a chave pai, use o formato 'child-parent'. ##### Usando o formato child-parent Para acessar valores que não estão contidos na chave `exports` dos values do chart filho, você precisará especificar a chave de origem dos valores a serem importados (`child`) e o caminho de destino nos values do chart pai (`parent`). O `import-values` no exemplo abaixo instrui o Helm a pegar quaisquer valores encontrados no caminho `child:` e copiá-los para os values do pai no caminho especificado em `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` No exemplo acima, os valores encontrados em `default.data` nos values do subchart1 serão importados para a chave `myimports` nos values do chart pai como detalhado abaixo: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` Os values resultantes do chart pai seriam: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Os values finais do pai agora contêm os campos `myint` e `mybool` importados do subchart1. ### Gerenciando Dependências manualmente via o diretório `charts/` Se mais controle sobre as dependências for desejado, essas dependências podem ser expressas explicitamente copiando os charts de dependência para o diretório `charts/`. Uma dependência deve ser um diretório de chart descompactado, mas seu nome não pode começar com `_` ou `.`. Tais arquivos são ignorados pelo carregador de charts. Por exemplo, se o chart WordPress depende do chart Apache, o chart Apache (da versão correta) é fornecido no diretório `charts/` do chart WordPress: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` O exemplo acima mostra como o chart WordPress expressa sua dependência do Apache e MySQL incluindo esses charts dentro de seu diretório `charts/`. **DICA:** _Para colocar uma dependência em seu diretório `charts/`, use o comando `helm pull`_ ### Aspectos operacionais do uso de dependências As seções acima explicam como especificar dependências de charts, mas como isso afeta a instalação de charts usando `helm install` e `helm upgrade`? Suponha que um chart chamado "A" crie os seguintes objetos Kubernetes - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Além disso, A é dependente do chart B que cria os objetos - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Após a instalação/atualização do chart A, uma única release Helm é criada/modificada. A release criará/atualizará todos os objetos Kubernetes acima na seguinte ordem: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Isso ocorre porque quando o Helm instala/atualiza charts, os objetos Kubernetes dos charts e todas as suas dependências são - agregados em um único conjunto; então - ordenados por tipo seguido de nome; e então - criados/atualizados nessa ordem. Portanto, uma única release é criada com todos os objetos do chart e suas dependências. A ordem de instalação dos tipos Kubernetes é dada pela enumeração InstallOrder em kind_sorter.go (veja [o arquivo fonte do Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates e Values Os templates de Chart Helm são escritos na [linguagem de template Go](https://golang.org/pkg/text/template/), com a adição de 50 ou mais funções de template adicionais [da biblioteca Sprig](https://github.com/Masterminds/sprig) e algumas outras [funções especializadas](/howto/charts_tips_and_tricks.md). Todos os arquivos de template são armazenados na pasta `templates/` de um chart. Quando o Helm renderiza os charts, ele passará cada arquivo nesse diretório pelo motor de templates. Os values para os templates são fornecidos de duas formas: - Desenvolvedores de charts podem fornecer um arquivo chamado `values.yaml` dentro de um chart. Este arquivo pode conter valores padrão. - Usuários de charts podem fornecer um arquivo YAML que contém values. Isso pode ser fornecido na linha de comando com `helm install`. Quando um usuário fornece values personalizados, esses valores sobrescreverão os valores no arquivo `values.yaml` do chart. ### Arquivos de Template Os arquivos de template seguem as convenções padrão para escrever templates Go (veja [a documentação do pacote Go text/template](https://golang.org/pkg/text/template/) para detalhes). Um exemplo de arquivo de template pode parecer algo assim: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` O exemplo acima, baseado livremente em [https://github.com/deis/charts](https://github.com/deis/charts), é um template para um replication controller do Kubernetes. Ele pode usar os seguintes quatro valores de template (geralmente definidos em um arquivo `values.yaml`): - `imageRegistry`: O registro de origem para a imagem Docker. - `dockerTag`: A tag para a imagem docker. - `pullPolicy`: A política de pull do Kubernetes. - `storage`: O backend de armazenamento, cujo padrão é definido como `"minio"` Todos esses valores são definidos pelo autor do template. O Helm não requer ou determina parâmetros. Para ver muitos charts funcionando, confira o [Artifact Hub](https://artifacthub.io/packages/search?kind=0) da CNCF. ### Values Predefinidos Values que são fornecidos via um arquivo `values.yaml` (ou via a flag `--set`) são acessíveis a partir do objeto `.Values` em um template. Mas existem outros dados predefinidos que você pode acessar em seus templates. Os seguintes values são predefinidos, estão disponíveis para todo template, e não podem ser sobrescritos. Como todos os values, os nomes diferenciam maiúsculas de minúsculas. - `Release.Name`: O nome da release (não o chart) - `Release.Namespace`: O namespace em que o chart foi liberado. - `Release.Service`: O serviço que conduziu a release. - `Release.IsUpgrade`: Isso é definido como true se a operação atual for um upgrade ou rollback. - `Release.IsInstall`: Isso é definido como true se a operação atual for uma instalação. - `Chart`: O conteúdo do `Chart.yaml`. Assim, a versão do chart é obtida como `Chart.Version` e os mantenedores estão em `Chart.Maintainers`. - `Files`: Um objeto semelhante a um mapa contendo todos os arquivos não especiais no chart. Isso não dará acesso a templates, mas dará acesso a arquivos adicionais que estão presentes (a menos que sejam excluídos usando `.helmignore`). Arquivos podem ser acessados usando `{{ index .Files "file.name" }}` ou usando a função `{{.Files.Get name }}`. Você também pode acessar o conteúdo do arquivo como `[]byte` usando `{{ .Files.GetBytes }}` - `Capabilities`: Um objeto semelhante a um mapa que contém informações sobre as versões do Kubernetes (`{{ .Capabilities.KubeVersion }}`) e as versões de API do Kubernetes suportadas (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **NOTA:** Qualquer campo desconhecido do `Chart.yaml` será descartado. Eles não serão acessíveis dentro do objeto `Chart`. Assim, `Chart.yaml` não pode ser usado para passar dados estruturados arbitrariamente para o template. O arquivo values pode ser usado para isso. ### Arquivos de Values Considerando o template na seção anterior, um arquivo `values.yaml` que fornece os valores necessários seria assim: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Um arquivo de values é formatado em YAML. Um chart pode incluir um arquivo `values.yaml` padrão. O comando helm install permite que um usuário sobrescreva valores fornecendo valores YAML adicionais: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Quando os values são passados desta forma, eles serão mesclados no arquivo de values padrão. Por exemplo, considere um arquivo `myvals.yaml` que se parece com isto: ```yaml storage: "gcs" ``` Quando isso é mesclado com o `values.yaml` no chart, o conteúdo gerado resultante será: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Note que apenas o último campo foi sobrescrito. **NOTA:** O arquivo de values padrão incluído dentro de um chart _deve_ ser nomeado `values.yaml`. Mas arquivos especificados na linha de comando podem ter qualquer nome. **NOTA:** Se a flag `--set` for usada em `helm install` ou `helm upgrade`, esses valores são simplesmente convertidos para YAML no lado do cliente. **NOTA:** Se existirem entradas obrigatórias no arquivo de values, elas podem ser declaradas como obrigatórias no template do chart usando a [função 'required'](/howto/charts_tips_and_tricks.md) Qualquer um desses valores é então acessível dentro de templates usando o objeto `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Escopo, Dependências e Values Arquivos de values podem declarar valores para o chart de nível superior, bem como para qualquer um dos charts que estão incluídos no diretório `charts/` desse chart. Ou, para colocar de outra forma, um arquivo de values pode fornecer valores para o chart assim como para qualquer uma de suas dependências. Por exemplo, o chart de demonstração WordPress acima tem tanto `mysql` quanto `apache` como dependências. O arquivo de values poderia fornecer valores para todos esses componentes: ```yaml title: "My WordPress Site" # Enviado para o template WordPress mysql: max_connections: 100 # Enviado para MySQL password: "secret" apache: port: 8080 # Passado para Apache ``` Charts de níveis superiores têm acesso a todas as variáveis definidas abaixo. Então o chart WordPress pode acessar a senha do MySQL como `.Values.mysql.password`. Mas charts de níveis inferiores não podem acessar coisas em charts pais, então MySQL não será capaz de acessar a propriedade `title`. Nem, aliás, pode acessar `apache.port`. Os values têm namespaces, mas os namespaces são podados. Então para o chart WordPress, ele pode acessar o campo de senha do MySQL como `.Values.mysql.password`. Mas para o chart MySQL, o escopo dos values foi reduzido e o prefixo de namespace removido, então ele verá o campo password simplesmente como `.Values.password`. #### Global Values A partir da versão 2.0.0-Alpha.2, o Helm suporta um "global" value especial. Considere esta versão modificada do exemplo anterior: ```yaml title: "My WordPress Site" # Enviado para o template WordPress global: app: MyWordPress mysql: max_connections: 100 # Enviado para MySQL password: "secret" apache: port: 8080 # Passado para Apache ``` O acima adiciona uma seção `global` com o valor `app: MyWordPress`. Este valor está disponível para _todos_ os charts como `.Values.global.app`. Por exemplo, os templates `mysql` podem acessar `app` como `{{ .Values.global.app}}`, e assim pode o chart `apache`. Efetivamente, o arquivo de values acima é regenerado assim: ```yaml title: "My WordPress Site" # Enviado para o template WordPress global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Enviado para MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passado para Apache ``` Isso fornece uma maneira de compartilhar uma variável de nível superior com todos os subcharts, o que é útil para coisas como definir propriedades de `metadata` como labels. Se um subchart declarar uma variável global, essa global será passada _para baixo_ (para os subcharts do subchart), mas não _para cima_ para o chart pai. Não há como um subchart influenciar os values do chart pai. Além disso, variáveis globais de charts pais têm precedência sobre as variáveis globais de subcharts. ### Arquivos de Schema Às vezes, um mantenedor de chart pode querer definir uma estrutura em seus values. Isso pode ser feito definindo um schema no arquivo `values.schema.json`. Um schema é representado como um [JSON Schema](https://json-schema.org/). Pode parecer algo assim: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Este schema será aplicado aos values para validá-lo. A validação ocorre quando qualquer um dos seguintes comandos é invocado: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Um exemplo de um arquivo `values.yaml` que atende aos requisitos deste schema pode parecer algo assim: ```yaml name: frontend protocol: https port: 443 ``` Note que o schema é aplicado ao objeto `.Values` final, e não apenas ao arquivo `values.yaml`. Isso significa que o seguinte arquivo `yaml` é válido, dado que o chart é instalado com a opção `--set` apropriada mostrada abaixo. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Além disso, o objeto `.Values` final é verificado contra *todos* os schemas de subcharts. Isso significa que restrições em um subchart não podem ser contornadas por um chart pai. Isso também funciona ao contrário - se um subchart tem um requisito que não é atendido no arquivo `values.yaml` do subchart, o chart pai *deve* satisfazer essas restrições para ser válido. A validação de schema pode ser desabilitada definindo a opção mostrada abaixo. Isso é particularmente útil em ambientes air-gapped quando o arquivo JSON Schema de um chart contém referências remotas. ```console helm install --skip-schema-validation ``` ### Referências Quando se trata de escrever templates, values e arquivos de schema, existem várias referências padrão que ajudarão você. - [Templates Go](https://godoc.org/text/template) - [Funções de template extras](https://godoc.org/github.com/Masterminds/sprig) - [O formato YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) O Kubernetes fornece um mecanismo para declarar novos tipos de objetos Kubernetes. Usando CustomResourceDefinitions (CRDs), desenvolvedores Kubernetes podem declarar tipos de recursos personalizados. No Helm 3, CRDs são tratados como um tipo especial de objeto. Eles são instalados antes do resto do chart e estão sujeitos a algumas limitações. Arquivos YAML de CRD devem ser colocados no diretório `crds/` dentro de um chart. Múltiplos CRDs (separados por marcadores de início e fim YAML) podem ser colocados no mesmo arquivo. O Helm tentará carregar _todos_ os arquivos no diretório CRD para o Kubernetes. Arquivos CRD _não podem conter templates_. Eles devem ser documentos YAML simples. Quando o Helm instala um novo chart, ele fará upload dos CRDs, pausará até que os CRDs estejam disponíveis pelo servidor de API, e então iniciará o motor de templates, renderizará o resto do chart, e fará upload para o Kubernetes. Por causa dessa ordenação, informações de CRD estão disponíveis no objeto `.Capabilities` nos templates Helm, e templates Helm podem criar novas instâncias de objetos que foram declarados em CRDs. Por exemplo, se seu chart tiver um CRD para `CronTab` no diretório `crds/`, você pode criar instâncias do kind `CronTab` no diretório `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` O arquivo `crontab.yaml` deve conter o CRD sem diretivas de template: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Então o template `mycrontab.yaml` pode criar um novo `CronTab` (usando templates como de costume): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` O Helm garantirá que o kind `CronTab` foi instalado e está disponível no servidor de API do Kubernetes antes de prosseguir instalando as coisas em `templates/`. ### Limitações em CRDs Diferente da maioria dos objetos no Kubernetes, CRDs são instalados globalmente. Por essa razão, o Helm adota uma abordagem muito cautelosa no gerenciamento de CRDs. CRDs estão sujeitos às seguintes limitações: - CRDs nunca são reinstalados. Se o Helm determinar que os CRDs no diretório `crds/` já estão presentes (independentemente da versão), o Helm não tentará instalar ou atualizar. - CRDs nunca são instalados em upgrade ou rollback. O Helm só criará CRDs em operações de instalação. - CRDs nunca são deletados. Deletar um CRD automaticamente deleta todo o conteúdo do CRD em todos os namespaces no cluster. Consequentemente, o Helm não deletará CRDs. Operadores que desejam atualizar ou deletar CRDs são encorajados a fazer isso manualmente e com muito cuidado. ## Usando o Helm para Gerenciar Charts A ferramenta `helm` tem vários comandos para trabalhar com charts. Ela pode criar um novo chart para você: ```console $ helm create mychart Created mychart/ ``` Uma vez que você tenha editado um chart, `helm` pode empacotá-lo em um arquivo compactado de chart para você: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Você também pode usar `helm` para ajudá-lo a encontrar problemas com a formatação ou informações do seu chart: ```console $ helm lint mychart No issues found ``` ## Repositórios de Charts Um _repositório de charts_ é um servidor HTTP que hospeda um ou mais charts empacotados. Embora `helm` possa ser usado para gerenciar diretórios de charts locais, quando se trata de compartilhar charts, o mecanismo preferido é um repositório de charts. Qualquer servidor HTTP que pode servir arquivos YAML e tar e pode responder requisições GET pode ser usado como um servidor de repositório. A equipe do Helm testou alguns servidores, incluindo Google Cloud Storage com modo website habilitado, e S3 com modo website habilitado. Um repositório é caracterizado principalmente pela presença de um arquivo especial chamado `index.yaml` que tem uma lista de todos os pacotes fornecidos pelo repositório, junto com metadados que permitem obter e verificar esses pacotes. No lado do cliente, repositórios são gerenciados com os comandos `helm repo`. No entanto, o Helm não fornece ferramentas para fazer upload de charts para servidores de repositório remotos. Isso ocorre porque fazer isso adicionaria requisitos substanciais a um servidor implementador, e assim aumentaria a barreira para configurar um repositório. ## Chart Starter Packs O comando `helm create` aceita uma opção opcional `--starter` que permite especificar um "starter chart". A opção starter também tem um alias curto `-p`. Exemplos de uso: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Starters são apenas charts regulares, mas estão localizados em `$XDG_DATA_HOME/helm/starters`. Como desenvolvedor de charts, você pode criar charts que são especificamente projetados para serem usados como starters. Tais charts devem ser projetados com as seguintes considerações em mente: - O `Chart.yaml` será sobrescrito pelo gerador. - Os usuários esperarão modificar o conteúdo de tal chart, então a documentação deve indicar como os usuários podem fazer isso. - Todas as ocorrências de `` serão substituídas pelo nome do chart especificado para que starter charts possam ser usados como templates, exceto para alguns arquivos variáveis. Por exemplo, se você usar arquivos personalizados no diretório `vars` ou certos arquivos `README.md`, `` NÃO será substituído dentro deles. Além disso, a descrição do chart não é herdada. Atualmente, a única maneira de adicionar um chart a `$XDG_DATA_HOME/helm/starters` é copiá-lo manualmente para lá. Na documentação do seu chart, você pode querer explicar esse processo. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Hooks de Chart description: Descreve como trabalhar com hooks de chart. sidebar_position: 2 --- O Helm fornece um mecanismo de _hook_ que permite aos desenvolvedores de charts intervir em certos pontos do ciclo de vida de uma release. Por exemplo, você pode usar hooks para: - Carregar um ConfigMap ou Secret durante a instalação antes que qualquer outro chart seja carregado. - Executar um Job para fazer backup de um banco de dados antes de instalar um novo chart, e então executar um segundo job após a atualização para restaurar os dados. - Executar um Job antes de deletar uma release para retirar um serviço de operação de forma controlada antes de removê-lo. Os hooks funcionam como templates normais, mas possuem anotações especiais que fazem com que o Helm os utilize de forma diferente. Nesta seção, abordamos o padrão básico de uso de hooks. ## Os Hooks Disponíveis Os seguintes hooks são definidos: | Valor da Anotação | Descrição | | ------------------ | ----------------------------------------------------------------------------------------------------- | | `pre-install` | Executa após os templates serem renderizados, mas antes de qualquer recurso ser criado no Kubernetes | | `post-install` | Executa após todos os recursos serem carregados no Kubernetes | | `pre-delete` | Executa em uma requisição de exclusão antes de qualquer recurso ser deletado do Kubernetes | | `post-delete` | Executa em uma requisição de exclusão após todos os recursos da release terem sido deletados | | `pre-upgrade` | Executa em uma requisição de upgrade após os templates serem renderizados, mas antes de qualquer recurso ser atualizado | | `post-upgrade` | Executa em uma requisição de upgrade após todos os recursos terem sido atualizados | | `pre-rollback` | Executa em uma requisição de rollback após os templates serem renderizados, mas antes de qualquer recurso ser revertido | | `post-rollback` | Executa em uma requisição de rollback após todos os recursos terem sido modificados | | `test` | Executa quando o subcomando helm test é invocado ([veja a documentação de testes](/topics/chart_tests.md)) | _Nota: o hook `crd-install` foi removido em favor do diretório `crds/` no Helm 3._ ## Hooks e o Ciclo de Vida da Release Hooks permitem que você, o desenvolvedor do chart, tenha a oportunidade de realizar operações em pontos estratégicos do ciclo de vida de uma release. Por exemplo, considere o ciclo de vida para um `helm install`. Por padrão, o ciclo de vida se parece com isto: 1. Usuário executa `helm install foo` 2. A API de instalação da biblioteca Helm é chamada 3. Após alguma verificação, a biblioteca renderiza os templates de `foo` 4. A biblioteca carrega os recursos resultantes no Kubernetes 5. A biblioteca retorna o objeto da release (e outros dados) para o cliente 6. O cliente encerra O Helm define dois hooks para o ciclo de vida do `install`: `pre-install` e `post-install`. Se o desenvolvedor do chart `foo` implementar ambos os hooks, o ciclo de vida é alterado desta forma: 1. Usuário executa `helm install foo` 2. A API de instalação da biblioteca Helm é chamada 3. CRDs no diretório `crds/` são instalados 4. Após alguma verificação, a biblioteca renderiza os templates de `foo` 5. A biblioteca se prepara para executar os hooks `pre-install` (carregando recursos de hook no Kubernetes) 6. A biblioteca ordena os hooks por peso (atribuindo um peso de 0 por padrão), pelo tipo de recurso e finalmente pelo nome em ordem crescente. 7. A biblioteca então carrega o hook com o menor peso primeiro (negativo para positivo) 8. A biblioteca espera até que o hook esteja "Pronto" (exceto para CRDs) 9. A biblioteca carrega os recursos resultantes no Kubernetes. Note que se a flag `--wait` estiver definida, a biblioteca esperará até que todos os recursos estejam em estado pronto e não executará o hook `post-install` até que estejam prontos. 10. A biblioteca executa o hook `post-install` (carregando recursos de hook) 11. A biblioteca espera até que o hook esteja "Pronto" 12. A biblioteca retorna o objeto da release (e outros dados) para o cliente 13. O cliente encerra O que significa esperar até que um hook esteja pronto? Isso depende do recurso declarado no hook. Se o recurso for do tipo `Job` ou `Pod`, o Helm esperará até que ele seja executado com sucesso até a conclusão. E se o hook falhar, a release falhará. Esta é uma _operação bloqueante_, então o cliente Helm pausará enquanto o Job é executado. Para todos os outros tipos, assim que o Kubernetes marcar o recurso como carregado (adicionado ou atualizado), o recurso é considerado "Pronto". Quando muitos recursos são declarados em um hook, os recursos são executados em série. Se eles tiverem pesos de hook (veja abaixo), são executados em ordem de peso. A partir do Helm 3.2.0, recursos de hook com o mesmo peso são instalados na mesma ordem que os recursos normais não-hook. Caso contrário, a ordenação não é garantida. (No Helm 2.3.0 e posteriores, eles são ordenados alfabeticamente. Esse comportamento, no entanto, não é considerado vinculante e pode mudar no futuro.) É considerado boa prática adicionar um peso de hook, e definí-lo como `0` se o peso não for importante. ### Recursos de hook não são gerenciados com as releases correspondentes Os recursos que um hook cria atualmente não são rastreados ou gerenciados como parte da release. Assim que o Helm verificar que o hook atingiu seu estado pronto, ele deixará o recurso de hook intocado. A coleta de lixo de recursos de hook quando a release correspondente é deletada pode ser adicionada ao Helm 3 no futuro, portanto qualquer recurso de hook que nunca deve ser deletado deve ser anotado com `helm.sh/resource-policy: keep`. Na prática, isso significa que se você criar recursos em um hook, você não pode depender do `helm uninstall` para remover os recursos. Para destruir tais recursos, você precisa ou [adicionar uma anotação personalizada `helm.sh/hook-delete-policy`](#hook-deletion-policies) ao arquivo de template do hook, ou [definir o campo time to live (TTL) de um recurso Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Escrevendo um Hook Os hooks são simplesmente arquivos de manifesto Kubernetes com anotações especiais na seção `metadata`. Como são arquivos de template, você pode usar todos os recursos normais de template, incluindo ler `.Values`, `.Release` e `.Template`. Por exemplo, este template, armazenado em `templates/post-install-job.yaml`, declara um job para ser executado em `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` O que faz este template um hook é a anotação: ```yaml annotations: "helm.sh/hook": post-install ``` Um recurso pode implementar múltiplos hooks: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Da mesma forma, não há limite para o número de recursos diferentes que podem implementar um dado hook. Por exemplo, pode-se declarar tanto um secret quanto um config map como um hook pre-install. Quando subcharts declaram hooks, esses também são avaliados. Não há como um chart de nível superior desabilitar os hooks declarados por subcharts. É possível definir um peso para um hook que ajudará a construir uma ordem de execução determinística. Pesos são definidos usando a seguinte anotação: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Pesos de hook podem ser números positivos ou negativos, mas devem ser representados como strings. Quando o Helm inicia o ciclo de execução de hooks de um tipo particular, ele ordenará esses hooks em ordem crescente. ### Políticas de exclusão de hook É possível definir políticas que determinam quando deletar os recursos de hook correspondentes. Políticas de exclusão de hook são definidas usando a seguinte anotação: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Você pode escolher um ou mais valores de anotação definidos: | Valor da Anotação | Descrição | | ---------------------- | ------------------------------------------------------------------------ | | `before-hook-creation` | Deleta o recurso anterior antes que um novo hook seja lançado (padrão) | | `hook-succeeded` | Deleta o recurso após o hook ser executado com sucesso | | `hook-failed` | Deleta o recurso se o hook falhou durante a execução | Se nenhuma anotação de política de exclusão de hook for especificada, o comportamento `before-hook-creation` é aplicado por padrão. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: Guias Temáticos sidebar_position: 3 --- # Guias Temáticos Aqui você encontrará introdução a todos os principais conceitos do Helm que você precisará saber. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: APIs do Kubernetes Obsoletas description: Explica APIs do Kubernetes obsoletas no Helm --- O Kubernetes é um sistema orientado por APIs, e a API evolui ao longo do tempo para refletir uma melhor compreensão do domínio. Esta é uma prática comum em sistemas e suas APIs. Uma parte importante da evolução das APIs é ter uma boa política e processo de deprecação para informar os usuários sobre como as mudanças são implementadas. Em outras palavras, os consumidores da sua API precisam saber com antecedência em qual release uma API será removida ou alterada. Isso evita surpresas e quebras de compatibilidade para os consumidores. A [política de deprecação do Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documenta como o Kubernetes lida com as mudanças em suas versões de API. A política de deprecação estabelece o prazo em que as versões de API serão suportadas após um anúncio de deprecação. Portanto, é importante estar ciente dos anúncios de deprecação e saber quando as versões de API serão removidas, para ajudar a minimizar o impacto. Este é um exemplo de um anúncio [para a remoção de versões de API obsoletas no Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), que foi divulgado alguns meses antes do release. Essas versões de API teriam sido anunciadas como obsoletas antes disso novamente. Isso mostra que existe uma boa política em vigor que informa os consumidores sobre o suporte às versões de API. Os templates do Helm especificam um [grupo de API do Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) ao definir um objeto do Kubernetes, semelhante a um arquivo de manifesto do Kubernetes. Isso é especificado no campo `apiVersion` do template e identifica a versão da API do objeto Kubernetes. Isso significa que usuários do Helm e mantenedores de charts precisam estar cientes de quando versões de API do Kubernetes foram deprecadas e em qual versão do Kubernetes elas serão removidas. ## Mantenedores de Charts Você deve auditar seus charts verificando versões de API do Kubernetes que estão obsoletas ou foram removidas em uma versão do Kubernetes. As versões de API que estão obsoletas ou já não são suportadas devem ser atualizadas para a versão suportada, e uma nova versão do chart deve ser lançada. A versão da API é definida pelos campos `kind` e `apiVersion`. Por exemplo, aqui está uma versão de API do objeto `Deployment` removida no Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Usuários do Helm Você deve auditar os charts que utiliza (semelhante aos [mantenedores de charts](#mantenedores-de-charts)) e identificar quaisquer charts onde as versões de API estão obsoletas ou foram removidas em uma versão do Kubernetes. Para os charts identificados, você precisa verificar a versão mais recente do chart (que possui versões de API suportadas) ou atualizar o chart você mesmo. Além disso, você também precisa auditar quaisquer charts implantados (ou seja, releases do Helm) verificando novamente se há versões de API obsoletas ou removidas. Isso pode ser feito obtendo detalhes de um release usando o comando `helm get manifest`. A forma de atualizar um release do Helm para APIs suportadas depende das suas descobertas, conforme segue: 1. Se você encontrar apenas versões de API obsoletas: - Execute um `helm upgrade` com uma versão do chart que possui versões de API do Kubernetes suportadas - Adicione uma descrição no upgrade, algo como "não realizar rollback para uma versão do Helm anterior a esta versão atual" 2. Se você encontrar alguma versão de API que foi removida em uma versão do Kubernetes: - Se você estiver executando uma versão do Kubernetes onde a(s) versão(ões) de API ainda está(ão) disponível(is) (por exemplo, você está no Kubernetes 1.15 e descobriu que usa APIs que serão removidas no Kubernetes 1.16): - Siga o procedimento do passo 1 - Caso contrário (por exemplo, você já está executando uma versão do Kubernetes onde algumas versões de API reportadas pelo `helm get manifest` não estão mais disponíveis): - Você precisa editar o manifesto do release que está armazenado no cluster para atualizar as versões de API para APIs suportadas. Consulte [Atualizando Versões de API de um Manifesto de Release](#atualizando-versões-de-api-de-um-manifesto-de-release) para mais detalhes > Nota: Em todos os casos de atualização de um release do Helm com APIs suportadas, você nunca deve fazer rollback do release para uma versão anterior à versão do release com as APIs suportadas. > Recomendação: A melhor prática é atualizar os releases que usam versões de API obsoletas para versões de API suportadas, antes de atualizar para um cluster Kubernetes que remove essas versões de API. Se você não atualizar um release conforme sugerido anteriormente, você terá um erro semelhante ao seguinte ao tentar atualizar um release em uma versão do Kubernetes onde sua(s) versão(ões) de API foi(ram) removida(s): ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` O Helm falha neste cenário porque tenta criar um patch de diferença entre o release atualmente implantado (que contém as APIs do Kubernetes que foram removidas nesta versão do Kubernetes) e o chart que você está passando com as versões de API atualizadas/suportadas. A razão subjacente para a falha é que quando o Kubernetes remove uma versão de API, a biblioteca cliente Go do Kubernetes não consegue mais fazer parse dos objetos obsoletos e, portanto, o Helm falha ao chamar a biblioteca. Infelizmente, o Helm não consegue se recuperar desta situação e não é mais capaz de gerenciar tal release. Consulte [Atualizando Versões de API de um Manifesto de Release](#atualizando-versões-de-api-de-um-manifesto-de-release) para mais detalhes sobre como se recuperar deste cenário. ## Atualizando Versões de API de um Manifesto de Release O manifesto é uma propriedade do objeto release do Helm que é armazenado no campo de dados de um Secret (padrão) ou ConfigMap no cluster. O campo de dados contém um objeto comprimido com gzip que está codificado em base 64 (há uma codificação base 64 adicional para um Secret). Existe um Secret/ConfigMap por versão/revisão do release no namespace do release. Você pode usar o plugin [mapkubeapis](https://github.com/helm/helm-mapkubeapis) do Helm para realizar a atualização de um release para APIs suportadas. Consulte o readme para mais detalhes. Alternativamente, você pode seguir estes passos manuais para realizar uma atualização das versões de API de um manifesto de release. Dependendo da sua configuração, você seguirá os passos para o backend Secret ou ConfigMap. - Obtenha o nome do Secret ou ConfigMap associado ao último release implantado: - Backend Secrets: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Backend ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Obtenha os detalhes do último release implantado: - Backend Secrets: `kubectl get secret -n -o yaml > release.yaml` - Backend ConfigMap: `kubectl get configmap -n -o yaml > release.yaml` - Faça backup do release caso precise restaurar se algo der errado: - `cp release.yaml release.bak` - Em caso de emergência, restaure: `kubectl apply -f release.bak -n ` - Decodifique o objeto release: - Backend Secrets: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - Backend ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Altere as versões de API dos manifestos. Pode usar qualquer ferramenta (por exemplo, editor) para fazer as alterações. Isso está no campo `manifest` do seu objeto release decodificado (`release.data.decoded`) - Codifique o objeto release: - Backend Secrets: `cat release.data.decoded | gzip | base64 | base64` - Backend ConfigMap: `cat release.data.decoded | gzip | base64` - Substitua o valor da propriedade `data.release` no arquivo do release implantado (`release.yaml`) pelo novo objeto release codificado - Aplique o arquivo ao namespace: `kubectl apply -f release.yaml -n ` - Execute um `helm upgrade` com uma versão do chart que possui versões de API do Kubernetes suportadas - Adicione uma descrição no upgrade, algo como "não realizar rollback para uma versão do Helm anterior a esta versão atual" ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Guia de Distribuições Kubernetes description: Informações sobre o uso do Helm em ambientes Kubernetes específicos. sidebar_position: 10 --- O Helm deve funcionar com qualquer [versão conforme do Kubernetes](https://github.com/cncf/k8s-conformance) (seja ela [certificada](https://www.cncf.io/certification/software-conformance/) ou não). Este documento contém informações sobre o uso do Helm em ambientes Kubernetes específicos. Contribua com mais detalhes sobre quaisquer distribuições (ordenadas alfabeticamente), se desejar. ## AKS O Helm funciona com o [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS O Helm foi testado e funciona na plataforma Kubernetes do DC/OS 1.11 da Mesosphere, e não requer configuração adicional. ## EKS O Helm funciona com o Amazon Elastic Kubernetes Service (Amazon EKS): [Usando o Helm com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE A plataforma Kubernetes hospedada do Google, GKE, funciona com o Helm e não requer configuração adicional. ## `scripts/local-cluster` e Hyperkube O Hyperkube configurado via `scripts/local-cluster.sh` funciona corretamente. Para o Hyperkube direto, pode ser necessário realizar alguma configuração manual. ## IKS O Helm funciona com o [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) O Helm é testado regularmente no [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne O Helm funciona em clusters configurados pelo KubeOne sem ressalvas. ## Kubermatic O Helm funciona em clusters de usuário criados pelo Kubermatic sem ressalvas. Como o seed cluster pode ser configurado de diferentes maneiras, o suporte ao Helm depende da configuração específica. ## MicroK8s O Helm pode ser habilitado no [MicroK8s](https://microk8s.io) usando o comando: `microk8s.enable helm3` ## Minikube O Helm é testado e funciona com o [Minikube](https://github.com/kubernetes/minikube). Não requer configuração adicional. ## Openshift O Helm funciona diretamente no OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (versão >= 3.6) ou OpenShift Origin (versão >= 3.6). Para saber mais, leia esta [postagem no blog](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 O Helm vem pré-instalado no [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). O Platform9 fornece acesso a todos os charts oficiais do Helm através da interface App Catalog e da CLI nativa do Kubernetes. Repositórios adicionais podem ser adicionados manualmente. Mais detalhes estão disponíveis neste [artigo do Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu com `kubeadm` O Kubernetes inicializado com `kubeadm` funciona nas seguintes distribuições Linux: - Ubuntu 16.04 - Fedora release 25 Algumas versões do Helm (v2.0.0-beta2) requerem que você execute `export KUBECONFIG=/etc/kubernetes/admin.conf` ou crie um arquivo `~/.kube/config`. ## VMware Tanzu Kubernetes Grid O Helm funciona no VMware Tanzu Kubernetes Grid, TKG, sem necessidade de alterações na configuração. A CLI do Tanzu pode gerenciar a instalação de pacotes para o [helm-controller](https://fluxcd.io/flux/components/helm/), permitindo o gerenciamento declarativo de releases de charts Helm. Mais detalhes estão disponíveis na documentação do TKG para [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Charts de Biblioteca description: Explica charts de biblioteca e exemplos de uso sidebar_position: 4 --- Um chart de biblioteca é um tipo de [chart Helm](/topics/charts.md) que define primitivas ou definições de charts que podem ser compartilhadas por templates Helm em outros charts. Isso permite que os usuários compartilhem trechos de código que podem ser reutilizados em diferentes charts, evitando repetição e mantendo os charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). O chart de biblioteca foi introduzido no Helm 3 para reconhecer formalmente os charts comuns ou auxiliares que têm sido usados por mantenedores de charts desde o Helm 2. Ao incluí-lo como um tipo de chart, ele fornece: - Um meio de distinguir explicitamente entre charts comuns e de aplicação - Lógica para impedir a instalação de um chart comum - Sem renderização de templates em um chart comum que pode conter artefatos de release - Permite que charts dependentes usem o contexto do chart importador Um mantenedor de chart pode definir um chart comum como um chart de biblioteca e ter a confiança de que o Helm irá manipular o chart de forma padrão e consistente. Também significa que definições em um chart de aplicação podem ser compartilhadas alterando o tipo do chart. ## Criando um Chart de Biblioteca Simples Como mencionado anteriormente, um chart de biblioteca é um tipo de [chart Helm](/topics/charts.md). Isso significa que você pode começar criando um chart base: ```console $ helm create mylibchart Creating mylibchart ``` Primeiro, você vai remover todos os arquivos no diretório `templates`, pois criaremos nossas próprias definições de templates neste exemplo. ```console $ rm -rf mylibchart/templates/* ``` O arquivo values também não será necessário. ```console $ rm -f mylibchart/values.yaml ``` Antes de começarmos a criar código comum, vamos fazer uma rápida revisão de alguns conceitos relevantes do Helm. Um [template nomeado](/chart_template_guide/named_templates.md) (às vezes chamado de partial ou subtemplate) é simplesmente um template definido dentro de um arquivo e que recebe um nome. No diretório `templates/`, qualquer arquivo que começa com underscore (_) não é esperado que gere um arquivo de manifesto do Kubernetes. Então, por convenção, templates auxiliares e partials são colocados em arquivos `_*.tpl` ou `_*.yaml`. Neste exemplo, vamos criar um ConfigMap comum que cria um recurso ConfigMap vazio. Vamos definir o ConfigMap comum no arquivo `mylibchart/templates/_configmap.yaml` da seguinte forma: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` A estrutura do ConfigMap é definida no template nomeado `mylibchart.configmap.tpl`. É um ConfigMap simples com um recurso vazio, `data`. Dentro deste arquivo, há outro template nomeado chamado `mylibchart.configmap`. Este template nomeado inclui outro template nomeado `mylibchart.util.merge` que recebe 2 templates nomeados como argumentos: o template que chama `mylibchart.configmap` e `mylibchart.configmap.tpl`. A função auxiliar `mylibchart.util.merge` é um template nomeado em `mylibchart/templates/_util.yaml`. É um utilitário prático do [Chart Auxiliar Comum do Helm](#o-chart-auxiliar-comum-do-helm) porque ele mescla os 2 templates e sobrescreve quaisquer partes comuns em ambos: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Isso é importante quando um chart deseja usar código comum que precisa personalizar com sua configuração. Finalmente, vamos alterar o tipo do chart para `library`. Isso requer editar `mylibchart/Chart.yaml` da seguinte forma: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` O chart de biblioteca agora está pronto para ser compartilhado e sua definição de ConfigMap para ser reutilizada. Antes de prosseguir, vale verificar se o Helm reconhece o chart como um chart de biblioteca: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Usando o Chart de Biblioteca Simples É hora de usar o chart de biblioteca. Isso significa criar um chart base novamente: ```console $ helm create mychart Creating mychart ``` Vamos limpar os arquivos de template novamente, pois queremos criar apenas um ConfigMap: ```console $ rm -rf mychart/templates/* ``` Quando queremos criar um ConfigMap simples em um template Helm, ele poderia se parecer com o seguinte: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` No entanto, vamos reutilizar o código comum já criado em `mylibchart`. O ConfigMap pode ser criado no arquivo `mychart/templates/configmap.yaml` da seguinte forma: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Você pode ver que isso simplifica o trabalho que temos que fazer ao herdar a definição comum do ConfigMap que adiciona propriedades padrão para o ConfigMap. Em nosso template, adicionamos a configuração, neste caso a chave de dados `myvalue` e seu valor. A configuração sobrescreve o recurso vazio do ConfigMap comum. Isso é possível por causa da função auxiliar `mylibchart.util.merge` que mencionamos na seção anterior. Para poder usar o código comum, precisamos adicionar `mylibchart` como uma dependência. Adicione o seguinte ao final do arquivo `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Isso inclui o chart de biblioteca como uma dependência dinâmica do sistema de arquivos que está no mesmo caminho pai do nosso chart de aplicação. Como estamos incluindo o chart de biblioteca como uma dependência dinâmica, precisamos executar `helm dependency update`. Ele copiará o chart de biblioteca para o diretório `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Agora estamos prontos para implantar nosso chart. Antes de instalar, vale verificar o template renderizado primeiro. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Isso parece o ConfigMap que queremos com a sobrescrita de dados de `myvalue: Hello World`. Vamos instalá-lo: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Podemos recuperar o release e ver que o template real foi carregado. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Benefícios do Chart de Biblioteca Por causa da sua incapacidade de atuar como charts independentes, charts de biblioteca podem aproveitar as seguintes funcionalidades: - O objeto `.Files` referencia os caminhos de arquivo no chart pai, em vez do caminho local do chart de biblioteca - O objeto `.Values` é o mesmo do chart pai, em contraste com [subcharts](/chart_template_guide/subcharts_and_globals.md) de aplicação que recebem a seção de valores configurada sob seu cabeçalho no pai. ## O Chart Auxiliar Comum do Helm ```markdown Nota: O repositório do Chart Auxiliar Comum do Helm no GitHub não é mais mantido ativamente, e o repositório foi descontinuado e arquivado. ``` Este [chart](https://github.com/helm/charts/tree/master/incubator/common) foi o padrão original para charts comuns. Ele fornece utilitários que refletem as melhores práticas do desenvolvimento de charts Kubernetes. Melhor ainda, você pode usá-lo imediatamente ao desenvolver seus charts para obter código compartilhado útil. Aqui está uma maneira rápida de usá-lo. Para mais detalhes, consulte o [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Crie um chart base novamente: ```console $ helm create demo Creating demo ``` Vamos usar o código comum do chart auxiliar. Primeiro, edite o deployment `demo/templates/deployment.yaml` da seguinte forma: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` E agora o arquivo de service, `demo/templates/service.yaml` da seguinte forma: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Estes templates mostram como herdar o código comum do chart auxiliar simplifica sua codificação até a configuração ou personalização dos recursos. Para poder usar o código comum, precisamos adicionar `common` como uma dependência. Adicione o seguinte ao final do arquivo `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Nota: Você precisará adicionar o repositório `incubator` à lista de repositórios do Helm (`helm repo add`). Como estamos incluindo o chart como uma dependência dinâmica, precisamos executar `helm dependency update`. Ele copiará o chart auxiliar para o diretório `charts/`. Como o chart auxiliar usa algumas estruturas do Helm 2, você precisará adicionar o seguinte ao `demo/values.yaml` para habilitar o carregamento da imagem `nginx` pois isso foi atualizado no chart base do Helm 3: ```yaml image: tag: 1.16.0 ``` Você pode testar se os templates do chart estão corretos antes de implantar usando os comandos `helm lint` e `helm template`. Se estiver tudo certo, implante usando `helm install`! ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Gerenciamento de permissões para backend de armazenamento SQL description: Saiba como configurar permissões ao usar o backend de armazenamento SQL. --- Este documento fornece orientações para configurar e gerenciar permissões ao usar o backend de armazenamento SQL. ## Introdução Para gerenciar permissões, o Helm utiliza o recurso RBAC do Kubernetes. Ao usar o backend de armazenamento SQL, os roles do Kubernetes não podem ser usados para determinar se um usuário pode acessar um determinado recurso. Este documento mostra como criar e gerenciar essas permissões. ## Inicialização Na primeira vez que o CLI do Helm se conectar ao seu banco de dados, o client verificará se ele foi previamente inicializado. Caso contrário, realizará a configuração necessária automaticamente. Esta inicialização requer privilégios de administrador no schema public, ou pelo menos a capacidade de: * criar uma tabela * conceder privilégios no schema public Após a migração ser executada no seu banco de dados, todos os outros roles podem usar o client. ## Conceder privilégios a um usuário não administrador no PostgreSQL Para gerenciar permissões, o driver do backend SQL utiliza o recurso [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Security Level) do PostgreSQL. O RLS permite que todos os usuários possam ler/escrever na mesma tabela, sem conseguir manipular as mesmas linhas se não tiverem sido explicitamente autorizados. Por padrão, qualquer role que não tenha recebido explicitamente os privilégios adequados sempre retornará uma lista vazia ao executar `helm list` e não conseguirá recuperar ou modificar nenhum recurso no cluster. Veja como conceder a um determinado role acesso a namespaces específicos: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Este comando concederá as permissões de leitura e escrita de todos os recursos que atendem à condição `namespace = 'default'` ao role `role`. Após criar esta política, o usuário conectado ao banco de dados com o role `role` poderá ver todos os releases no namespace `default` ao executar `helm list`, além de modificá-los e excluí-los. Os privilégios podem ser gerenciados de forma granular com RLS, e pode ser interessante restringir o acesso de acordo com as diferentes colunas da tabela: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Guia de Plugins do Helm description: Apresenta como usar e criar plugins para estender a funcionalidade do Helm. sidebar_position: 12 --- Um plugin do Helm é uma ferramenta que pode ser acessada através da CLI `helm`, mas que não faz parte do código-base principal do Helm. Plugins existentes podem ser encontrados na seção [relacionados](/community/related#helm-plugins) ou pesquisando no [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Este guia explica como usar e criar plugins. ## Visão Geral Plugins do Helm são ferramentas complementares que se integram perfeitamente com o Helm. Eles fornecem uma maneira de estender o conjunto de recursos principais do Helm, sem exigir que cada novo recurso seja escrito em Go e adicionado à ferramenta principal. Plugins do Helm têm as seguintes características: - Podem ser adicionados e removidos de uma instalação do Helm sem impactar a ferramenta principal. - Podem ser escritos em qualquer linguagem de programação. - Integram-se com o Helm e aparecem em `helm help` e outros locais. Plugins do Helm ficam em `$HELM_PLUGINS`. Você pode encontrar o valor atual desta variável, incluindo o valor padrão quando não definida no ambiente, usando o comando `helm env`. O modelo de plugins do Helm é parcialmente baseado no modelo de plugins do Git. Por isso, você pode às vezes ouvir o `helm` ser referido como a camada _porcelain_, com os plugins sendo a _plumbing_. Isso significa que o Helm fornece a interface de alto nível para o usuário, enquanto os plugins realizam o "trabalho pesado" de executar ações específicas. ## Instalando um Plugin Plugins são instalados usando o comando `$ helm plugin install `. Você pode passar um caminho para um plugin no seu sistema de arquivos local ou uma URL de um repositório VCS remoto. O comando `helm plugin install` clona ou copia o plugin do caminho/URL fornecido para `$HELM_PLUGINS`. Se você estiver instalando a partir de um VCS, pode especificar a versão com o argumento `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Se você tiver uma distribuição tar de um plugin, extraia o plugin no diretório `$HELM_PLUGINS`. Você também pode instalar plugins tarball diretamente de uma URL usando `helm plugin install https://domain/path/to/plugin.tar.gz` ## Estrutura de Arquivos do Plugin De muitas formas, um plugin é semelhante a um chart. Cada plugin tem um diretório de nível superior contendo um arquivo `plugin.yaml`. Arquivos adicionais podem estar presentes, mas apenas o arquivo `plugin.yaml` é obrigatório. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## O Arquivo plugin.yaml O arquivo plugin.yaml é obrigatório para um plugin. Ele contém os seguintes campos: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### O Campo `name` O `name` é o nome do plugin. Quando o Helm executa este plugin, este é o nome que ele usará (por exemplo, `helm NAME` invocará este plugin). _`name` deve corresponder ao nome do diretório._ No nosso exemplo acima, isso significa que o plugin com `name: last` deve estar contido em um diretório chamado `last`. Restrições em `name`: - `name` não pode duplicar um dos comandos de nível superior existentes do `helm`. - `name` deve ser restrito aos caracteres ASCII a-z, A-Z, 0-9, `_` e `-`. ### O Campo `version` O `version` é a versão SemVer 2 do plugin. `usage` e `description` são ambos usados para gerar o texto de ajuda de um comando. ### O Campo `ignoreFlags` A opção `ignoreFlags` diz ao Helm para _não_ passar flags para o plugin. Então, se um plugin for chamado com `helm myplugin --foo` e `ignoreFlags: true`, então `--foo` é silenciosamente descartado. ### O Campo `platformCommand` O `platformCommand` configura o comando que o plugin executará quando for chamado. Você não pode definir tanto `platformCommand` quanto `command`, pois isso resultará em um erro. As seguintes regras se aplicam na decisão de qual comando usar: - Se `platformCommand` estiver presente, ele será usado. - Se tanto `os` quanto `arch` corresponderem à plataforma atual, a busca parará e o comando será usado. - Se `os` corresponder e `arch` estiver vazio, o comando será usado. - Se `os` e `arch` estiverem ambos vazios, o comando será usado. - Se não houver correspondência, o Helm sairá com um erro. - Se `platformCommand` não estiver presente e o `command` depreciado estiver presente, ele será usado. - Se o comando estiver vazio, o Helm sairá com um erro. ### O Campo `platformHooks` O `platformHooks` configura os comandos que o plugin executará para eventos de ciclo de vida. Você não pode definir tanto `platformHooks` quanto `hooks`, pois isso resultará em um erro. As seguintes regras se aplicam na decisão de qual comando de hook usar: - Se `platformHooks` estiver presente, ele será usado e os comandos para o evento de ciclo de vida serão processados. - Se tanto `os` quanto `arch` corresponderem à plataforma atual, a busca parará e o comando será usado. - Se `os` corresponder e `arch` estiver vazio, o comando será usado. - Se `os` e `arch` estiverem ambos vazios, o comando será usado. - Se não houver correspondência, o Helm pulará o evento. - Se `platformHooks` não estiver presente e o `hooks` depreciado estiver presente, o comando para o evento de ciclo de vida será usado. - Se o comando estiver vazio, o Helm pulará o evento. ## Construindo um Plugin Aqui está o YAML do plugin para um plugin simples que ajuda a obter o nome do último release: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Plugins podem requerer scripts e executáveis adicionais. Scripts podem ser incluídos no diretório do plugin e executáveis podem ser baixados via hook. O seguinte é um exemplo de plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Variáveis de ambiente são interpoladas antes do plugin ser executado. O padrão acima ilustra a maneira preferida de indicar onde o programa do plugin está localizado. ### Comandos de Plugin Existem algumas estratégias para trabalhar com comandos de plugin: - Se um plugin inclui um executável, o executável para um `platformCommand:` ou deve ser empacotado no diretório do plugin ou instalado via hook. - A linha `platformCommand:` ou `command:` terá quaisquer variáveis de ambiente expandidas antes da execução. `$HELM_PLUGIN_DIR` apontará para o diretório do plugin. - O comando em si não é executado em um shell. Então você não pode colocar um script shell em uma linha. - O Helm injeta muitas configurações em variáveis de ambiente. Examine o ambiente para ver quais informações estão disponíveis. - O Helm não faz suposições sobre a linguagem do plugin. Você pode escrevê-lo na linguagem que preferir. - Comandos são responsáveis por implementar texto de ajuda específico para `-h` e `--help`. O Helm usará `usage` e `description` para `helm help` e `helm help myplugin`, mas não tratará `helm myplugin --help`. ### Testando um Plugin Local Primeiro você precisa encontrar o caminho do seu `HELM_PLUGINS`. Para isso, execute o seguinte comando: ``` bash helm env ``` Mude seu diretório atual para o diretório definido em `HELM_PLUGINS`. Agora você pode adicionar um link simbólico para a saída de build do seu plugin. Neste exemplo, fizemos isso para o `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Plugins de Download Por padrão, o Helm pode baixar Charts usando HTTP/S. A partir do Helm 2.4.0, plugins podem ter uma capacidade especial de baixar Charts de fontes arbitrárias. Plugins devem declarar esta capacidade especial no arquivo `plugin.yaml` (nível superior): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Se tal plugin for instalado, o Helm pode interagir com o repositório usando o esquema de protocolo especificado, invocando o `command`. O repositório especial deve ser adicionado de forma similar aos regulares: `helm repo add favorite myprotocol://example.com/`. As regras para repositórios especiais são as mesmas dos regulares: o Helm deve ser capaz de baixar o arquivo `index.yaml` para descobrir e armazenar em cache a lista de Charts disponíveis. O comando definido será invocado com o seguinte esquema: `command certFile keyFile caFile full-URL`. As credenciais SSL vêm da definição do repositório, armazenadas em `$HELM_REPOSITORY_CONFIG` (ou seja, `$HELM_CONFIG_HOME/repositories.yaml`). Um plugin de download deve enviar o conteúdo bruto para stdout e reportar erros em stderr. O comando de download também suporta subcomandos ou argumentos, permitindo que você especifique, por exemplo, `bin/mydownloader subcommand -d` no `plugin.yaml`. Isso é útil se você quiser usar o mesmo executável para o comando principal do plugin e o comando de download, mas com um subcomando diferente para cada um. ## Variáveis de Ambiente Quando o Helm executa um plugin, ele passa o ambiente externo para o plugin e também injeta algumas variáveis de ambiente adicionais. Variáveis como `KUBECONFIG` são definidas para o plugin se estiverem definidas no ambiente externo. As seguintes variáveis são garantidas de estar definidas: - `HELM_PLUGINS`: O caminho para o diretório de plugins. - `HELM_PLUGIN_NAME`: O nome do plugin, como invocado pelo `helm`. Então `helm myplug` terá o nome curto `myplug`. - `HELM_PLUGIN_DIR`: O diretório que contém o plugin. - `HELM_BIN`: O caminho para o comando `helm` (como executado pelo usuário). - `HELM_DEBUG`: Indica se a flag de debug foi definida pelo helm. - `HELM_REGISTRY_CONFIG`: A localização para a configuração do registro (se usado). Note que o uso do Helm com registros é um recurso experimental. - `HELM_REPOSITORY_CACHE`: O caminho para os arquivos de cache do repositório. - `HELM_REPOSITORY_CONFIG`: O caminho para o arquivo de configuração do repositório. - `HELM_NAMESPACE`: O namespace dado ao comando `helm` (geralmente usando a flag `-n`). - `HELM_KUBECONTEXT`: O nome do contexto de configuração do Kubernetes dado ao comando `helm`. Além disso, se um arquivo de configuração do Kubernetes foi especificado explicitamente, ele será definido como a variável `KUBECONFIG`. ## Uma Nota sobre Processamento de Flags Ao executar um plugin, o Helm processa as flags globais para seu próprio uso. Nenhuma dessas flags é passada para o plugin. - `--burst-limit`: Convertido para `$HELM_BURST_LIMIT` - `--debug`: Se especificado, `$HELM_DEBUG` é definido como `1` - `--kube-apiserver`: Convertido para `$HELM_KUBEAPISERVER` - `--kube-as-group`: Convertido para `$HELM_KUBEASGROUPS` - `--kube-as-user`: Convertido para `$HELM_KUBEASUSER` - `--kube-ca-file`: Convertido para `$HELM_KUBECAFILE` - `--kube-context`: Convertido para `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: Convertido para `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: Convertido para `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: Convertido para `$HELM_KUBETOKEN` - `--kubeconfig`: Convertido para `$KUBECONFIG` - `--namespace` e `-n`: Convertido para `$HELM_NAMESPACE` - `--qps`: Convertido para `$HELM_QPS` - `--registry-config`: Convertido para `$HELM_REGISTRY_CONFIG` - `--repository-cache`: Convertido para `$HELM_REPOSITORY_CACHE` - `--repository-config`: Convertido para `$HELM_REPOSITORY_CONFIG` Plugins _devem_ exibir texto de ajuda e então sair para `-h` e `--help`. Em todos os outros casos, plugins podem usar flags conforme apropriado. ## Fornecendo Auto-Completação de Shell A partir do Helm 3.2, um plugin pode opcionalmente fornecer suporte para auto-completação de shell como parte do mecanismo de auto-completação existente do Helm. ### Auto-Completação Estática Se um plugin fornece suas próprias flags e/ou subcomandos, ele pode informar o Helm sobre eles tendo um arquivo `completion.yaml` localizado no diretório raiz do plugin. O arquivo `completion.yaml` tem a seguinte forma: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Notas: 1. Todas as seções são opcionais, mas devem ser fornecidas se aplicável. 1. Flags não devem incluir o prefixo `-` ou `--`. 1. Tanto flags curtas quanto longas podem e devem ser especificadas. Uma flag curta não precisa estar associada à sua forma longa correspondente, mas ambas as formas devem ser listadas. 1. Flags não precisam estar ordenadas de nenhuma forma, mas precisam estar listadas no ponto correto na hierarquia de subcomandos do arquivo. 1. As flags globais existentes do Helm já são tratadas pelo mecanismo de auto-completação do Helm, portanto os plugins não precisam especificar as seguintes flags: `--debug`, `--namespace` ou `-n`, `--kube-context` e `--kubeconfig`, ou qualquer outra flag global. 1. A lista `validArgs` fornece uma lista estática de possíveis completações para o primeiro parâmetro após um subcomando. Nem sempre é possível fornecer tal lista antecipadamente (veja a seção [Completação Dinâmica](#completação-dinâmica) abaixo), caso em que a seção `validArgs` pode ser omitida. O arquivo `completion.yaml` é totalmente opcional. Se não for fornecido, o Helm simplesmente não fornecerá auto-completação de shell para o plugin (a menos que [Completação Dinâmica](#completação-dinâmica) seja suportada pelo plugin). Além disso, adicionar um arquivo `completion.yaml` é retrocompatível e não impactará o comportamento do plugin ao usar versões mais antigas do Helm. Como exemplo, para o [plugin `fullstatus`](https://github.com/marckhouzam/helm-fullstatus) que não tem subcomandos mas aceita as mesmas flags que o comando `helm status`, o arquivo `completion.yaml` é: ```yaml name: fullstatus flags: - o - output - revision ``` Um exemplo mais elaborado para o [plugin `2to3`](https://github.com/helm/helm-2to3), tem um arquivo `completion.yaml` de: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Completação Dinâmica Também a partir do Helm 3.2, plugins podem fornecer sua própria auto-completação dinâmica de shell. Auto-completação dinâmica de shell é a completação de valores de parâmetros ou valores de flags que não podem ser definidos antecipadamente. Por exemplo, completação dos nomes de releases do Helm atualmente disponíveis no cluster. Para que o plugin suporte completação dinâmica, ele deve fornecer um arquivo **executável** chamado `plugin.complete` em seu diretório raiz. Quando o script de completação do Helm requer completações dinâmicas para o plugin, ele executará o arquivo `plugin.complete`, passando a linha de comando que precisa ser completada. O executável `plugin.complete` precisará ter a lógica para determinar quais são as escolhas de completação adequadas e exibi-las na saída padrão para serem consumidas pelo script de completação do Helm. O arquivo `plugin.complete` é totalmente opcional. Se não for fornecido, o Helm simplesmente não fornecerá auto-completação dinâmica para o plugin. Além disso, adicionar um arquivo `plugin.complete` é retrocompatível e não impactará o comportamento do plugin ao usar versões mais antigas do Helm. A saída do script `plugin.complete` deve ser uma lista separada por novas linhas como: ```console rel1 rel2 rel3 ``` Quando `plugin.complete` é chamado, o ambiente do plugin é configurado da mesma forma que quando o script principal do plugin é chamado. Portanto, as variáveis `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` e todas as outras variáveis do plugin já estarão definidas, e suas flags globais correspondentes terão sido removidas. O arquivo `plugin.complete` pode estar em qualquer forma executável; pode ser um script shell, um programa Go, ou qualquer outro tipo de programa que o Helm possa executar. O arquivo `plugin.complete` ***deve*** ter permissões de execução para o usuário. O arquivo `plugin.complete` ***deve*** sair com um código de sucesso (valor 0). Em alguns casos, a completação dinâmica precisará obter informações do cluster Kubernetes. Por exemplo, o plugin `helm fullstatus` requer um nome de release como entrada. No plugin `fullstatus`, para que seu script `plugin.complete` forneça completação para nomes de releases atuais, ele pode simplesmente executar `helm list -q` e exibir o resultado. Se for desejado usar o mesmo executável para execução do plugin e para completação do plugin, o script `plugin.complete` pode ser feito para chamar o executável principal do plugin com algum parâmetro ou flag especial; quando o executável principal do plugin detectar o parâmetro ou flag especial, ele saberá que deve executar a completação. No nosso exemplo, `plugin.complete` poderia ser implementado assim: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` O script real do plugin `fullstatus` (`status.sh`) deve então procurar pela flag `--complete` e, se encontrada, exibir as completações adequadas. ### Dicas e Truques 1. O shell filtrará automaticamente escolhas de completação que não correspondam à entrada do usuário. Um plugin pode, portanto, retornar todas as completações relevantes sem remover as que não correspondem à entrada do usuário. Por exemplo, se a linha de comando for `helm fullstatus ngin`, o script `plugin.complete` pode exibir *todos* os nomes de releases (do namespace `default`), não apenas os que começam com `ngin`; o shell reterá apenas os que começam com `ngin`. 1. Para simplificar o suporte à completação dinâmica, especialmente se você tiver um plugin complexo, você pode fazer seu script `plugin.complete` chamar seu script principal do plugin e solicitar escolhas de completação. Veja a seção [Completação Dinâmica](#completação-dinâmica) acima para um exemplo. 1. Para depurar a completação dinâmica e o arquivo `plugin.complete`, você pode executar o seguinte para ver os resultados de completação: - `helm __complete `. Por exemplo: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Proveniência e Integridade do Helm description: Descreve como verificar a integridade e origem de um Chart. sidebar_position: 5 --- O Helm possui ferramentas de proveniência que ajudam os usuários de charts a verificar a integridade e origem de um pacote. Usando ferramentas padrão da indústria baseadas em PKI, GnuPG e gerenciadores de pacotes bem conceituados, o Helm pode gerar e verificar arquivos de assinatura. ## Visão Geral A integridade é estabelecida comparando um chart com um registro de proveniência. Os registros de proveniência são armazenados em _arquivos de proveniência_, que ficam junto ao chart empacotado. Por exemplo, se um chart se chama `myapp-1.2.3.tgz`, seu arquivo de proveniência será `myapp-1.2.3.tgz.prov`. Os arquivos de proveniência são gerados no momento do empacotamento (`helm package --sign ...`) e podem ser verificados por vários comandos, principalmente `helm install --verify`. ## O Fluxo de Trabalho Esta seção descreve um fluxo de trabalho potencial para usar dados de proveniência de forma eficaz. Pré-requisitos: - Um par de chaves PGP válido em formato binário (não ASCII-armored) - A ferramenta de linha de comando `helm` - Ferramentas de linha de comando GnuPG (opcional) - Ferramentas de linha de comando Keybase (opcional) **NOTA:** Se sua chave privada PGP possui uma passphrase, você será solicitado a digitá-la para qualquer comando que suporte a opção `--sign`. Criar um novo chart é igual a antes: ```console $ helm create mychart Creating mychart ``` Quando estiver pronto para empacotar, adicione a flag `--sign` ao `helm package`. Especifique também o nome sob o qual a chave de assinatura é conhecida e o keyring (chaveiro) contendo a chave privada correspondente: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Nota:** O valor do argumento `--key` deve ser uma substring do `uid` da chave desejada (na saída de `gpg --list-keys`), por exemplo o nome ou email. **A impressão digital _não pode_ ser usada.** **DICA:** para usuários GnuPG, seu keyring secreto está em `~/.gnupg/secring.gpg`. Você pode usar `gpg --list-secret-keys` para listar as chaves que possui. **Aviso:** o GnuPG v2 armazena seu keyring secreto usando um novo formato `kbx` no local padrão `~/.gnupg/pubring.kbx`. Por favor, use o seguinte comando para converter seu keyring para o formato gpg legado: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` Neste ponto, você deve ver tanto `mychart-0.1.0.tgz` quanto `mychart-0.1.0.tgz.prov`. Ambos os arquivos devem eventualmente ser enviados para o repositório de charts desejado. Você pode verificar um chart usando `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Uma verificação com falha aparece assim: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Para verificar durante uma instalação, use a flag `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Se o keyring contendo a chave pública associada ao chart assinado não estiver no local padrão, você pode precisar apontar para o keyring com `--keyring PATH` como no exemplo do `helm package`. Se a verificação falhar, a instalação será abortada antes mesmo do chart ser renderizado. ### Usando credenciais do Keybase.io O serviço [Keybase.io](https://keybase.io) facilita o estabelecimento de uma cadeia de confiança para uma identidade criptográfica. As credenciais do Keybase podem ser usadas para assinar charts. Pré-requisitos: - Uma conta Keybase.io configurada - GnuPG instalado localmente - A CLI `keybase` instalada localmente #### Assinando pacotes O primeiro passo é importar suas chaves Keybase para seu keyring GnuPG local: ```console $ keybase pgp export -s | gpg --import ``` Este comando converte sua chave Keybase para o formato OpenPGP e a importa para o arquivo local `~/.gnupg/secring.gpg`. Você pode verificar executando `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Note que sua chave secreta terá uma string identificadora: ``` technosophos (keybase.io/technosophos) ``` Esse é o nome completo da sua chave. Em seguida, você pode empacotar e assinar um chart com `helm package`. Certifique-se de usar pelo menos parte dessa string de nome em `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Como resultado, o comando `package` deve produzir tanto um arquivo `.tgz` quanto um arquivo `.tgz.prov`. #### Verificando pacotes Você também pode usar uma técnica similar para verificar um chart assinado pela chave Keybase de outra pessoa. Digamos que você quer verificar um pacote assinado por `keybase.io/technosophos`. Para fazer isso, use a ferramenta `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` O primeiro comando acima rastreia o usuário `technosophos`. Em seguida, `keybase pgp pull` baixa as chaves OpenPGP de todas as contas que você segue, colocando-as no seu keyring GnuPG (`~/.gnupg/pubring.gpg`). Neste ponto, você agora pode usar `helm verify` ou qualquer um dos comandos com a flag `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Razões pelas quais um chart pode não ser verificado Estas são razões comuns para falha. - O arquivo `.prov` está faltando ou corrompido. Isso indica que algo está mal configurado ou que o mantenedor original não criou um arquivo de proveniência. - A chave usada para assinar o arquivo não está no seu keyring. Isso indica que a entidade que assinou o chart não é alguém em quem você já sinalizou que confia. - A verificação do arquivo `.prov` falhou. Isso indica que algo está errado com o chart ou com os dados de proveniência. - Os hashes de arquivo no arquivo de proveniência não correspondem ao hash do arquivo de pacote. Isso indica que o pacote foi adulterado. Se uma verificação falhar, há razão para desconfiar do pacote. ## O Arquivo de Proveniência O arquivo de proveniência contém o arquivo YAML do chart mais várias informações de verificação. Os arquivos de proveniência são projetados para serem gerados automaticamente. Os seguintes dados de proveniência são adicionados: * O arquivo do chart (`Chart.yaml`) é incluído para dar tanto a humanos quanto a ferramentas uma visão fácil do conteúdo do chart. * A assinatura (SHA256, assim como o Docker) do pacote do chart (o arquivo `.tgz`) é incluída e pode ser usada para verificar a integridade do pacote do chart. * O corpo inteiro é assinado usando o algoritmo usado pelo OpenPGP (veja [Keybase.io](https://keybase.io) para uma forma emergente de tornar a assinatura e verificação criptográfica fáceis). A combinação disso dá aos usuários as seguintes garantias: * O pacote em si não foi adulterado (checksum do pacote `.tgz`). * A entidade que lançou este pacote é conhecida (via a assinatura GnuPG/PGP). O formato do arquivo se parece com algo assim: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Note que a seção YAML contém dois documentos (separados por `...\n`). O primeiro arquivo é o conteúdo de `Chart.yaml`. O segundo são os checksums, um mapa de nomes de arquivo para digests SHA-256 do conteúdo desse arquivo no momento do empacotamento. O bloco de assinatura é uma assinatura PGP padrão, que fornece [resistência à adulteração](https://www.rossde.com/PGP/pgp_signatures.html). ## Repositórios de Charts Os repositórios de charts servem como uma coleção centralizada de charts Helm. Os repositórios de charts devem tornar possível servir arquivos de proveniência via HTTP através de uma requisição específica, e devem disponibilizá-los no mesmo caminho URI que o chart. Por exemplo, se a URL base para um pacote é `https://example.com/charts/mychart-1.2.3.tgz`, o arquivo de proveniência, se existir, DEVE estar acessível em `https://example.com/charts/mychart-1.2.3.tgz.prov`. Da perspectiva do usuário final, `helm install --verify myrepo/mychart-1.2.3` deve resultar no download tanto do chart quanto do arquivo de proveniência sem configuração ou ação adicional do usuário. ### Assinaturas em registries baseados em OCI Ao publicar charts em um [registry baseado em OCI](/topics/registries.md), o [plugin `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) pode ser usado para publicar proveniência no [sigstore](https://sigstore.dev/). [Conforme descrito na documentação](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), o processo de criar proveniência e assinar com uma chave GPG são comuns, mas o comando `helm sigstore upload` pode ser usado para publicar a proveniência em um log de transparência imutável. ## Estabelecendo Autoridade e Autenticidade Ao lidar com sistemas de cadeia de confiança, é importante ser capaz de estabelecer a autoridade de um assinante. Em outras palavras, o sistema acima depende do fato de você confiar na pessoa que assinou o chart. Isso, por sua vez, significa que você precisa confiar na chave pública do assinante. Uma das decisões de design do Helm foi que o projeto Helm não se inseriria na cadeia de confiança como uma parte necessária. Não queremos ser "a autoridade certificadora" para todos os assinantes de charts. Em vez disso, favorecemos fortemente um modelo descentralizado, que é parte da razão pela qual escolhemos OpenPGP como nossa tecnologia fundamental. Então, quando se trata de estabelecer autoridade, deixamos esta etapa mais ou menos indefinida no Helm 2 (uma decisão mantida no Helm 3). No entanto, temos algumas indicações e recomendações para aqueles interessados em usar o sistema de proveniência: - A plataforma [Keybase](https://keybase.io) fornece um repositório público centralizado para informações de confiança. - Você pode usar o Keybase para armazenar suas chaves ou para obter as chaves públicas de outros. - O Keybase também tem documentação fantástica disponível - Embora não tenhamos testado, o recurso "secure website" do Keybase poderia ser usado para servir charts Helm. - A ideia básica é que um "revisor de charts" oficial assina charts com sua chave, e o arquivo de proveniência resultante é então enviado para o repositório de charts. - Houve algum trabalho na ideia de que uma lista de chaves de assinatura válidas pode ser incluída no arquivo `index.yaml` de um repositório. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Controle de Acesso Baseado em Funções description: Explica como o Helm interage com o Controle de Acesso Baseado em Funções (RBAC) do Kubernetes. sidebar_position: 11 --- No Kubernetes, conceder funções a um usuário ou a uma service account específica da aplicação é uma prática recomendada para garantir que sua aplicação esteja operando dentro do escopo que você especificou. Leia mais sobre permissões de service account [na documentação oficial do Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). A partir do Kubernetes 1.6, o Controle de Acesso Baseado em Funções é habilitado por padrão. O RBAC permite especificar quais tipos de ações são permitidas dependendo do usuário e de sua função na organização. Com o RBAC, você pode - conceder operações privilegiadas (como criar recursos com escopo de cluster, como novas funções) a administradores - limitar a capacidade de um usuário criar recursos (pods, persistent volumes, deployments) a namespaces específicos, ou em escopos de todo o cluster (resource quotas, roles, custom resource definitions) - limitar a capacidade de um usuário visualizar recursos em namespaces específicos ou em escopo de todo o cluster. Este guia é para administradores que desejam restringir o escopo de interação de um usuário com a API do Kubernetes. ## Gerenciando contas de usuário Todos os clusters Kubernetes possuem duas categorias de usuários: service accounts gerenciadas pelo Kubernetes e usuários normais. Usuários normais são assumidos como gerenciados por um serviço externo e independente. Um administrador distribuindo chaves privadas, um armazenamento de usuários como Keystone ou Google Accounts, ou mesmo um arquivo com uma lista de nomes de usuário e senhas. Nesse sentido, o Kubernetes não possui objetos que representem contas de usuário normais. Usuários normais não podem ser adicionados a um cluster através de uma chamada de API. Em contraste, service accounts são usuários gerenciados pela API do Kubernetes. Elas são vinculadas a namespaces específicos e criadas automaticamente pelo API server ou manualmente através de chamadas de API. As service accounts estão associadas a um conjunto de credenciais armazenadas como Secrets, que são montados em pods permitindo que processos dentro do cluster se comuniquem com a API do Kubernetes. Requisições de API são associadas a um usuário normal ou a uma service account, ou são tratadas como requisições anônimas. Isso significa que todo processo dentro ou fora do cluster, desde um usuário humano digitando `kubectl` em uma estação de trabalho, até kubelets nos nós, até membros do control plane, deve se autenticar ao fazer requisições ao API server, ou ser tratado como um usuário anônimo. ## Roles, ClusterRoles, RoleBindings e ClusterRoleBindings No Kubernetes, contas de usuário e service accounts só podem visualizar e editar recursos aos quais foi concedido acesso. Esse acesso é concedido através do uso de Roles e RoleBindings. Roles e RoleBindings são vinculados a um namespace específico, concedendo aos usuários a capacidade de visualizar e/ou editar recursos dentro desse namespace aos quais o Role fornece acesso. Em escopo de cluster, estes são chamados de ClusterRoles e ClusterRoleBindings. Conceder a um usuário um ClusterRole concede acesso para visualizar e/ou editar recursos em todo o cluster. Também é necessário para visualizar e/ou editar recursos em escopo de cluster (namespaces, resource quotas, nodes). ClusterRoles podem ser vinculados a um namespace específico através de referência em um RoleBinding. Os ClusterRoles padrão `admin`, `edit` e `view` são comumente usados dessa maneira. Existem alguns ClusterRoles disponíveis por padrão no Kubernetes. Eles são destinados a ser funções voltadas para o usuário. Incluem funções de super-usuário (`cluster-admin`) e funções com acesso mais granular (`admin`, `edit`, `view`). | ClusterRole Padrão | ClusterRoleBinding Padrão | Descrição |---------------------|----------------------------|------------- | `cluster-admin` | grupo `system:masters` | Permite acesso de super-usuário para executar qualquer ação em qualquer recurso. Quando usado em um ClusterRoleBinding, dá controle total sobre todos os recursos no cluster e em todos os namespaces. Quando usado em um RoleBinding, dá controle total sobre todos os recursos no namespace do RoleBinding, incluindo o próprio namespace. | `admin` | Nenhum | Permite acesso administrativo, destinado a ser concedido dentro de um namespace usando um RoleBinding. Se usado em um RoleBinding, permite acesso de leitura/escrita à maioria dos recursos em um namespace, incluindo a capacidade de criar roles e rolebindings dentro do namespace. Não permite acesso de escrita a resource quotas ou ao próprio namespace. | `edit` | Nenhum | Permite acesso de leitura/escrita à maioria dos objetos em um namespace. Não permite visualizar ou modificar roles ou rolebindings. | `view` | Nenhum | Permite acesso somente leitura para ver a maioria dos objetos em um namespace. Não permite visualizar roles ou rolebindings. Não permite visualizar secrets, pois isso pode permitir escalação de privilégios. ## Restringindo o acesso de uma conta de usuário usando RBAC Agora que entendemos os conceitos básicos de Controle de Acesso Baseado em Funções, vamos discutir como um administrador pode restringir o escopo de acesso de um usuário. ### Exemplo: Conceder acesso de leitura/escrita a um namespace específico Para restringir o acesso de um usuário a um namespace específico, podemos usar o role `edit` ou `admin`. Se seus charts criam ou interagem com Roles e RoleBindings, você deve usar o ClusterRole `admin`. Além disso, você também pode criar um RoleBinding com acesso `cluster-admin`. Conceder a um usuário acesso `cluster-admin` no escopo do namespace fornece controle total sobre todos os recursos no namespace, incluindo o próprio namespace. Para este exemplo, criaremos um usuário com o Role `edit`. Primeiro, crie o namespace: ```console $ kubectl create namespace foo ``` Agora, crie um RoleBinding nesse namespace, concedendo ao usuário o role `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Exemplo: Conceder acesso de leitura/escrita em escopo de cluster Se um usuário deseja instalar um chart que instala recursos com escopo de cluster (namespaces, roles, custom resource definitions, etc.), ele precisará de acesso de escrita em escopo de cluster. Para isso, conceda ao usuário acesso `admin` ou `cluster-admin`. Conceder a um usuário acesso `cluster-admin` concede acesso a absolutamente todos os recursos disponíveis no Kubernetes, incluindo acesso a nós com `kubectl drain` e outras tarefas administrativas. É altamente recomendado considerar fornecer ao usuário acesso `admin` em vez disso, ou criar um ClusterRole personalizado adaptado às suas necessidades. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Exemplo: Conceder acesso somente leitura a um namespace específico Você pode ter notado que não há um ClusterRole disponível para visualizar secrets. O ClusterRole `view` não concede acesso de leitura a Secrets devido a preocupações de escalação. O Helm armazena metadados de release como Secrets por padrão. Para que um usuário possa executar `helm list`, ele precisa ser capaz de ler esses secrets. Para isso, criaremos um ClusterRole especial `secret-reader`. Crie o arquivo `cluster-role-secret-reader.yaml` e escreva o seguinte conteúdo no arquivo: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Em seguida, crie o ClusterRole usando ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Uma vez feito isso, podemos conceder a um usuário acesso de leitura à maioria dos recursos e, em seguida, conceder acesso de leitura aos secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Exemplo: Conceder acesso somente leitura em escopo de cluster Em certos cenários, pode ser benéfico conceder a um usuário acesso em escopo de cluster. Por exemplo, se um usuário deseja executar o comando `helm list --all-namespaces`, a API requer que o usuário tenha acesso de leitura em escopo de cluster. Para isso, conceda ao usuário acesso `view` e `secret-reader` conforme descrito acima, mas com um ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Considerações Adicionais Os exemplos mostrados acima utilizam os ClusterRoles padrão fornecidos com o Kubernetes. Para um controle mais refinado sobre quais recursos os usuários podem acessar, consulte [a documentação do Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) sobre como criar seus próprios Roles e ClusterRoles personalizados. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Usando registries baseados em OCI description: Descreve como usar OCI para distribuição de charts. sidebar_position: 7 --- A partir do Helm 3, você pode usar registries de containers com suporte a [OCI](https://www.opencontainers.org/) para armazenar e compartilhar pacotes de charts. A partir do Helm v3.8.0, o suporte a OCI é habilitado por padrão. ## Suporte a OCI antes da v3.8.0 O suporte a OCI evoluiu de experimental para disponibilidade geral com o Helm v3.8.0. Em versões anteriores do Helm, o suporte a OCI se comportava de maneira diferente. Se você estava usando o suporte a OCI antes do Helm v3.8.0, é importante entender o que mudou nas diferentes versões do Helm. ### Habilitando o suporte a OCI antes da v3.8.0 Antes do Helm v3.8.0, o suporte a OCI é *experimental* e deve ser habilitado manualmente. Para habilitar o suporte experimental a OCI para versões do Helm anteriores à v3.8.0, defina `HELM_EXPERIMENTAL_OCI` no seu ambiente. Por exemplo: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Depreciações e mudanças de comportamento do OCI com a v3.8.0 Com o lançamento do [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), as seguintes funcionalidades e comportamentos são diferentes das versões anteriores do Helm: - Ao definir um chart nas dependências como OCI, a versão pode ser definida como um intervalo, assim como outras dependências. - Tags SemVer que incluem informações de build podem ser enviadas e usadas. Registries OCI não suportam `+` como caractere de tag. O Helm converte o `+` para `_` ao armazenar como tag. - O comando `helm registry login` agora segue a mesma estrutura do Docker CLI para armazenar credenciais. O mesmo local de configuração do registry pode ser passado tanto para o Helm quanto para o Docker CLI. ### Depreciações e mudanças de comportamento do OCI com a v3.7.0 Com o lançamento do [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0), foi incluída a implementação do [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) para suporte a OCI. Como resultado, as seguintes funcionalidades e comportamentos são diferentes das versões anteriores do Helm: - O subcomando `helm chart` foi removido. - O cache de charts foi removido (sem `helm chart list` etc.). - Referências a registries OCI agora sempre são prefixadas com `oci://`. - O nome base da referência do registry deve *sempre* corresponder ao nome do chart. - A tag da referência do registry deve *sempre* corresponder à versão semântica do chart (ou seja, sem tags `latest`). - O media type da camada do chart foi alterado de `application/tar+gzip` para `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Usando um registry baseado em OCI ### Repositórios Helm em registries baseados em OCI Um [repositório Helm](/topics/chart_repository.md) é uma forma de hospedar e distribuir charts Helm empacotados. Um registry baseado em OCI pode conter zero ou mais repositórios Helm e cada um desses repositórios pode conter zero ou mais charts Helm empacotados. ### Usando registries hospedados Existem vários registries de containers hospedados com suporte a OCI que você pode usar para seus charts Helm. Por exemplo: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Siga a documentação do provedor do registry de containers hospedado para criar e configurar um registry com suporte a OCI. **Nota:** Você pode executar o [Docker Registry](https://docs.docker.com/registry/deploying/) ou [`zot`](https://github.com/project-zot/zot), que são registries baseados em OCI, no seu computador de desenvolvimento. Executar um registry baseado em OCI no seu computador de desenvolvimento deve ser usado apenas para fins de teste. ### Usando sigstore para assinar charts baseados em OCI O plugin [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) permite usar o [Sigstore](https://sigstore.dev/) para assinar charts Helm com as mesmas ferramentas usadas para assinar imagens de containers. Isso fornece uma alternativa ao [provenance baseado em GPG](/topics/provenance.md) suportado pelos [repositórios de charts](/topics/chart_repository.md) clássicos. Para mais detalhes sobre como usar o plugin `helm sigstore`, consulte a [documentação do projeto](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Comandos para trabalhar com registries ### O subcomando `registry` #### `login` fazer login em um registry (com entrada manual de senha) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` fazer logout de um registry ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### O subcomando `push` Enviar um chart para um registry baseado em OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` O subcomando `push` só pode ser usado com arquivos `.tgz` criados anteriormente usando `helm package`. Ao usar `helm push` para enviar um chart para um registry OCI, a referência deve ser prefixada com `oci://` e não deve conter o nome base ou a tag. O nome base da referência do registry é inferido do nome do chart, e a tag é inferida da versão semântica do chart. Este é atualmente um requisito estrito. Certos registries exigem que o repositório e/ou namespace (se especificado) sejam criados previamente. Caso contrário, um erro será produzido durante a operação `helm push`. Se você criou um [arquivo de provenance](/topics/provenance.md) (`.prov`) e ele estiver presente ao lado do arquivo `.tgz` do chart, ele será automaticamente enviado para o registry durante o `push`. Isso resulta em uma camada extra no [manifesto do chart Helm](#manifesto-do-chart-helm). Usuários do [plugin helm-push](https://github.com/chartmuseum/helm-push) (para enviar charts ao [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) podem ter problemas, já que o plugin conflita com o novo `push` integrado. A partir da versão v0.10.0, o plugin foi renomeado para `cm-push`. ### Outros subcomandos O suporte para o protocolo `oci://` também está disponível em vários outros subcomandos. Aqui está a lista completa: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` O nome base (nome do chart) da referência do registry *é* incluído para qualquer tipo de ação envolvendo download de chart (diferente do `helm push` onde é omitido). Aqui estão alguns exemplos de uso dos subcomandos listados acima com charts baseados em OCI: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Instalando charts com digest Instalar um chart com um digest é mais seguro do que com uma tag, pois os digests são imutáveis. O digest é especificado na URI do chart: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Especificando dependências As dependências de um chart podem ser baixadas de um registry usando o subcomando `dependency update`. O `repository` para uma entrada específica no `Chart.yaml` é especificado como a referência do registry sem o nome base: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Isso buscará `oci://localhost:5000/myrepo/mychart:2.7.0` quando `dependency update` for executado. ## Manifesto do chart Helm Exemplo de manifesto de chart Helm como representado em um registry (observe os campos `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` O exemplo a seguir contém um [arquivo de provenance](/topics/provenance.md) (observe a camada extra): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migrando de repositórios de charts Migrar dos [repositórios de charts](/topics/chart_repository.md) clássicos (repositórios baseados em index.yaml) é simples: use `helm pull` e depois `helm push` para enviar os arquivos `.tgz` resultantes para um registry. ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Migrando do Helm v2 para v3 description: Aprenda como migrar do Helm v2 para o v3. sidebar_position: 13 --- Este guia mostra como migrar do Helm v2 para o v3. O Helm v2 precisa estar instalado e gerenciando releases em um ou mais clusters. ## Visão Geral das Mudanças do Helm 3 A lista completa de mudanças do Helm 2 para o 3 está documentada na [seção de FAQ](/faq/changes_since_helm2.md). A seguir está um resumo de algumas dessas mudanças que o usuário deve conhecer antes e durante a migração: 1. Remoção do Tiller: - Substitui a arquitetura cliente/servidor por uma arquitetura cliente/biblioteca (apenas o binário `helm`) - A segurança agora é baseada por usuário (delegada à segurança do usuário no cluster Kubernetes) - Os releases agora são armazenados como secrets dentro do cluster e os metadados do objeto release foram alterados - Os releases são persistidos com base no namespace do release e não mais no namespace do Tiller 2. Repositório de charts atualizado: - `helm search` agora suporta tanto buscas em repositórios locais quanto consultas no Artifact Hub 3. apiVersion do chart elevada para "v2" devido às seguintes mudanças na especificação: - Dependências de charts vinculadas dinamicamente foram movidas para `Chart.yaml` (`requirements.yaml` removido e requirements --> dependencies) - Charts de biblioteca (helper/common charts) agora podem ser adicionados como dependências de charts vinculadas dinamicamente - Charts possuem um campo de metadados `type` para definir se o chart é do tipo `application` ou `library`. Por padrão, é application, o que significa que é renderizável e instalável - Charts do Helm 2 (apiVersion=v1) ainda podem ser instalados 4. Especificação de diretórios XDG adicionada: - Helm home foi removido e substituído pela especificação de diretórios XDG para armazenar arquivos de configuração - Não é mais necessário inicializar o Helm - `helm init` e `helm home` foram removidos 5. Mudanças adicionais: - A instalação/configuração do Helm foi simplificada: - Apenas o cliente Helm (binário helm) (sem Tiller) - Paradigma de execução direta - Repositórios `local` ou `stable` não são configurados por padrão - O hook `crd-install` foi removido e substituído pelo diretório `crds` no chart, onde todos os CRDs definidos nele serão instalados antes de qualquer renderização do chart - O valor de anotação do hook `test-failure` foi removido, e `test-success` foi descontinuado. Use `test` em vez disso - Comandos removidos/substituídos/adicionados: - delete --> uninstall : remove todo o histórico de releases por padrão (anteriormente era necessário `--purge`) - fetch --> pull - home (removido) - init (removido) - install: requer nome do release ou argumento `--generate-name` - inspect --> show - reset (removido) - serve (removido) - template: argumento `-x`/`--execute` renomeado para `-s`/`--show-only` - upgrade: Adicionado argumento `--history-max` que limita o número máximo de revisões salvas por release (0 para sem limite) - A biblioteca Go do Helm 3 passou por muitas mudanças e é incompatível com a biblioteca do Helm 2 - Os binários de release agora são hospedados em `get.helm.sh` ## Casos de Uso da Migração Os casos de uso da migração são os seguintes: 1. Helm v2 e v3 gerenciando o mesmo cluster: - Esse caso de uso é recomendado apenas se você pretende descontinuar o Helm v2 gradualmente e não precisa que o v3 gerencie nenhum release implantado pelo v2. Todos os novos releases sendo implantados devem ser realizados pelo v3 e os releases existentes implantados pelo v2 devem ser atualizados/removidos apenas pelo v2 - O Helm v2 e v3 podem gerenciar o mesmo cluster sem problemas. As versões do Helm podem ser instaladas no mesmo sistema ou em sistemas separados - Se instalar o Helm v3 no mesmo sistema, você precisa realizar um passo adicional para garantir que ambas as versões do cliente possam coexistir até que você esteja pronto para remover o cliente Helm v2. Renomeie ou coloque o binário do Helm v3 em uma pasta diferente para evitar conflitos - Caso contrário, não há conflitos entre ambas as versões devido às seguintes distinções: - O armazenamento de releases (histórico) do v2 e v3 são independentes um do outro. As mudanças incluem o recurso Kubernetes usado para armazenamento e os metadados do objeto release contidos no recurso. Os releases também estarão em um namespace por usuário em vez de usar o namespace do Tiller (por exemplo, namespace padrão do Tiller no v2 é kube-system). O v2 usa "ConfigMaps" ou "Secrets" no namespace do Tiller com propriedade `TILLER`. O v3 usa "Secrets" no namespace do usuário com propriedade `helm`. Os releases são incrementais tanto no v2 quanto no v3 - O único problema possível seria se recursos com escopo de cluster Kubernetes (por exemplo, `clusterroles.rbac`) forem definidos em um chart. A implantação do v3 falharia mesmo sendo única no namespace, pois os recursos entrariam em conflito - A configuração do v3 não usa mais `$HELM_HOME` e usa a especificação de diretórios XDG em vez disso. Ela também é criada sob demanda. Portanto, é independente da configuração do v2. Isso se aplica apenas quando ambas as versões estão instaladas no mesmo sistema 2. Migrando do Helm v2 para o Helm v3: - Esse caso de uso se aplica quando você deseja que o Helm v3 gerencie releases existentes do Helm v2 - Deve-se observar que um cliente Helm v2: - pode gerenciar 1 ou mais clusters Kubernetes - pode conectar-se a 1 ou mais instâncias do Tiller em um cluster - Isso significa que você deve estar ciente disso ao migrar, pois os releases são implantados nos clusters pelo Tiller e seu namespace. Você deve, portanto, estar ciente de migrar cada cluster e cada instância do Tiller que é gerenciada pela instância do cliente Helm v2 - O caminho recomendado para migração de dados é o seguinte: 1. Fazer backup dos dados do v2 2. Migrar a configuração do Helm v2 3. Migrar os releases do Helm v2 4. Quando estiver confiante de que o Helm v3 está gerenciando todos os dados do Helm v2 (para todos os clusters e instâncias do Tiller da instância do cliente Helm v2) conforme esperado, então limpe os dados do Helm v2 - O processo de migração é automatizado pelo plugin [2to3](https://github.com/helm/helm-2to3) do Helm v3 ## Referência - Plugin [2to3](https://github.com/helm/helm-2to3) do Helm v3 - [Post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) do blog explicando o uso do plugin `2to3` com exemplos ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Política de Suporte de Versão do Helm" description: "Descreve a política de releases de correção do Helm, bem como a diferença máxima de versões suportada entre o Helm e o Kubernetes." --- Este documento descreve a diferença máxima de versões suportada entre o Helm e o Kubernetes. ## Versões Suportadas As versões do Helm são expressas como `x.y.z`, onde `x` é a versão principal (major), `y` é a versão secundária (minor) e `z` é a versão de correção (patch), seguindo a terminologia de [Versionamento Semântico](https://semver.org/spec/v2.0.0.html). O projeto Helm mantém um branch de release para a versão secundária mais recente. Correções aplicáveis, incluindo correções de segurança, são incorporadas ao branch de release, dependendo da severidade e viabilidade. Mais detalhes podem ser encontrados na [política de releases do Helm](/community/release_policy). ## Diferença de Versão Suportada Quando uma nova versão do Helm é lançada, ela é compilada com uma versão secundária específica do Kubernetes. Por exemplo, o Helm 3.0.0 interage com o Kubernetes usando o cliente Kubernetes 1.16.2, portanto é compatível com o Kubernetes 1.16. A partir do Helm 3, o Helm é compatível com versões `n-3` do Kubernetes com o qual foi compilado. Devido às mudanças do Kubernetes entre versões secundárias, a política de suporte do Helm 2 é um pouco mais restrita, sendo compatível com versões `n-1` do Kubernetes. Por exemplo, se você estiver usando uma versão do Helm 3 que foi compilada com as APIs do cliente Kubernetes 1.17, ela deve funcionar de forma segura com o Kubernetes 1.17, 1.16, 1.15 e 1.14. Se você estiver usando uma versão do Helm 2 que foi compilada com as APIs do cliente Kubernetes 1.16, ela deve funcionar de forma segura com o Kubernetes 1.16 e 1.15. Não é recomendado usar o Helm com uma versão do Kubernetes mais recente do que aquela com a qual ele foi compilado, pois o Helm não oferece garantias de compatibilidade futura. Se você optar por usar o Helm com uma versão do Kubernetes que não é suportada, você estará fazendo isso por sua própria conta e risco. Consulte a tabela abaixo para determinar qual versão do Helm é compatível com o seu cluster. | Versão do Helm | Versões do Kubernetes Suportadas | |----------------|----------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Introdução", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Como fazer", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Tópicos", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Melhores Práticas", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Guia de Templates de Chart", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Comandos do Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Comunidade", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Perguntas Frequentes", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/pt/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Política de Cronograma de Releases" description: "Descreve a política de cronograma de releases do Helm." --- Para benefício de seus usuários, o Helm define e anuncia as datas de releases com antecedência. Este documento descreve a política que governa o cronograma de releases do Helm. ## Calendário de Releases Um calendário público mostrando os próximos releases do Helm pode ser encontrado [aqui](https://helm.sh/calendar/release). ## Versionamento Semântico As versões do Helm são expressas como `x.y.z`, onde `x` é a versão principal (major), `y` é a versão secundária (minor) e `z` é a versão de correção (patch), seguindo a terminologia de [Versionamento Semântico](https://semver.org/spec/v2.0.0.html). ## Releases de Correção Os releases de correção fornecem aos usuários correções de bugs e correções de segurança. Eles não contêm novas funcionalidades. Um novo release de correção relacionado ao release secundário/principal mais recente normalmente será feito uma vez por mês, na segunda quarta-feira de cada mês. Um release de correção para resolver uma regressão de alta prioridade ou um problema de segurança pode ser feito sempre que necessário. Um release de correção será cancelado por qualquer um dos seguintes motivos: - se não houver novo conteúdo desde o release anterior - se a data do release de correção cair dentro de uma semana antes do primeiro release candidate (RC1) de um próximo release secundário - se a data do release de correção cair dentro de quatro semanas após um release secundário ## Releases Secundários Os releases secundários contêm correções de segurança e bugs, bem como novas funcionalidades. Eles são retrocompatíveis em relação à API e ao uso da CLI. Para alinhar com os releases do Kubernetes, um release secundário do Helm será feito a cada 4 meses (3 releases por ano). Releases secundários extras podem ser feitos se necessário, mas não afetarão o cronograma de um release futuro anunciado, a menos que o release anunciado esteja a menos de 7 dias. Ao mesmo tempo em que um release é publicado, a data do próximo release secundário será anunciada e publicada na página principal do Helm. ## Releases Principais Os releases principais contêm mudanças incompatíveis. Tais releases são raros, mas às vezes são necessários para permitir que o Helm continue a evoluir em novas direções importantes. Os releases principais podem ser difíceis de planejar. Com isso em mente, uma data final de release só será escolhida e anunciada quando a primeira versão beta de tal release estiver disponível. ================================================ FILE: i18n/pt/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Projeto Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Desenvolvimento", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Comunidade", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Código fonte", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Blog", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Eventos", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Código de Conduta", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Introdução", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Dicas e truques de Charts", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Desenvolver Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Pesquisar 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Guia de Contribuição", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Mantenedores", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Reuniões Semanais", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Comunidade no GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Somos um projeto graduado da Cloud Native Computing Foundation.
© Autores do Helm 2025. Documentação distribuída sob CC-BY-4.0.
© 2025 The Linux Foundation. Todos os direitos reservados. A The Linux Foundation possui marcas registadas e usa marcas registadas. Para uma lista de marcas da The Linux Foundation, consulte a nossa página de Uso de Marcas.", "description": "The footer copyright" }, "logo.alt": { "message": "Logótipo CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/pt/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Logótipo Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Documentação", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Blog", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Comunidade", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/ru/code.json ================================================ { "home.about.whatIsHelm": { "message": "Helm помогает управлять приложениями Kubernetes — Helm Charts помогают определять, устанавливать и обновлять даже самые сложные приложения Kubernetes.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Charts легко создавать, версионировать, делиться ими и публиковать — поэтому начните использовать Helm и прекратите копировать и вставлять.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm — это дипломированный проект в {cncfLink} и поддерживается {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "сообществом Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Узнать больше:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Архитектура Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Руководство по быстрому старту", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Видео: Введение в Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Что такое Helm?", "description": "What is Helm? title" }, "home.community.nextFeatureRelease": { "message": "Следующая версия", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Версия:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Дата:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Календарь релизов", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "Предстоящие события", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Предстоящие события", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Прошедшие события", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "Они {meetLink}, чтобы демонстрировать и обсуждать инструменты и проекты. Встречи сообщества записываются и {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "встречаются каждую неделю", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "публикуются на YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Стендапы разработчиков" }, "home.community.developerStandups.time": { "message": "Четверг 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Эти встречи открыты для всех. Проверьте {communityRepoLink} для заметок и деталей.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "репозиторий сообщества", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Обсуждение использования Helm, работы с чартами и решения распространённых ошибок.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Темы, касающиеся разработки Helm, текущих PR, релизов и т.д.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Обсуждение для пользователей и разработчиков Helm Charts.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink}, чтобы присоединиться к команде Kubernetes Slack.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Запросите доступ здесь", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Вклад в проект", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm всегда приветствует новые вклады в проект!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "С чего начать?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm — это большой проект с множеством пользователей и разработчиков. Это может быть сложно для восприятия!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "У нас есть список {goodFirstIssuesLink}, если вы хотите помочь, но не знаете, с чего начать.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "хороших первых задач", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Что мне делать?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Прежде чем вносить код, пожалуйста, прочитайте наше {contributionGuideLink}. Оно описывает процессы создания и проверки пул-реквестов.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Руководство по вкладу", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "После того, как вы напишете код, пожалуйста, {signYourCommitsLink}, чтобы убедиться, что Helm соблюдает соглашение {dcoLink}, используемое {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "подпишите свои коммиты", "description": "Sign your commits link" }, "home.community.title": { "message": "Присоединиться к сообществу", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Больше информации о проекте Helm и о том, как внести свой вклад.", "description": "Join the Community subtitle" }, "home.features.manageComplexity": { "message": "Управление сложностью", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Charts описывают даже самые сложные приложения, обеспечивают повторяемую установку приложений и служат единой точкой авторитета.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Простые обновления", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Избавьтесь от проблем с обновлениями благодаря обновлениям на месте и пользовательским хукам.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Простой обмен", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Charts легко версионировать, делиться ими и размещать на публичных или частных серверах.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Откаты", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Используйте {helmRollback}, чтобы легко откатиться к более старой версии релиза.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Возможности", "description": "Features section title" }, "home.gettingStarted.title": { "message": "Начало работы", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Скачайте Helm!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Установите Helm с помощью менеджера пакетов или {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "скачайте бинарный файл", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "После установки распакуйте бинарный файл helm, добавьте его в ваш PATH — и всё готово! Проверьте {docsLink} для получения дополнительной информации об {installationLink} и {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "документацию", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "установке", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "инструкциях по использованию", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Скачайте Chart-ы", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Посетите {artifactHubLink}, чтобы изучить {helmChartsLink} из множества публичных репозиториев.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "чарты Helm", "description": "Helm charts link" }, "home.header.tagline": { "message": "Менеджер пакетов для Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm — лучший способ находить, делиться и использовать программное обеспечение, созданное для", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "На странице произошёл сбой.", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Прокрутка к началу", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "Архив", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Архив", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "Навигация по странице списка блогов", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Следующие записи", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Предыдущие записи", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Навигация по странице поста блога", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Следующий пост", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Предыдущий пост", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Посмотреть все теги", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "системный режим", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "Светлый режим", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "Тёмный режим", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Переключение между темным и светлым режимом (сейчас используется {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Навигационная цепочка текущей страницы", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "{count} элемент|{count} элемента|{count} элементов", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "Страница документа", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Предыдущая страница", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Следующая страница", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Одна страница|{count} страницы|{count} страниц", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} с тегом \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versionBadge.label": { "message": "Версия: {versionLabel}" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Это документация для будущей версии {siteTitle} {versionLabel}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Это документация {siteTitle} для версии {versionLabel}, которая уже не поддерживается.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Актуальная документация находится на странице {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "последней версии", "description": "The label used for the latest version suggestion link label" }, "theme.common.editThisPage": { "message": "Отредактировать эту страницу", "description": "The link label to edit the current page" }, "theme.lastUpdated.atDate": { "message": " {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " от {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Последнее обновление{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.common.headingLinkTitle": { "message": "Прямая ссылка на {heading}", "description": "Title for link to heading" }, "theme.NotFound.title": { "message": "Страница не найдена", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Версии", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Теги:", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Закрыть", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "предупреждение", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "осторожно", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "к сведению", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "примечание", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "подсказка", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "предупреждение", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.blog.sidebar.navAriaLabel": { "message": "Навигация по последним постам в блоге", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Развернуть категорию сайдбара '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Свернуть категорию сайдбара '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(откроется в новой вкладке)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Главная", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "К сожалению, мы не смогли найти запрашиваемую вами страницу.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Пожалуйста, обратитесь к владельцу сайта, с которого вы перешли на эту ссылку, чтобы сообщить ему, что ссылка не работает.", "description": "The 2nd paragraph of the 404 page" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Содержание этой страницы", "description": "The label used by the button on the collapsible TOC component" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Языки", "description": "The label for the mobile language switcher dropdown" }, "theme.blog.post.readMore": { "message": "Читать дальше", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Подробнее о {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "{readingTime} мин. чтения|{readingTime} мин. чтения|{readingTime} мин. чтения", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "Скопировать", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Скопировано", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Скопировать в буфер обмена", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "Переключить перенос по строкам", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "Главная страница", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Свернуть сайдбар", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Свернуть сайдбар", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.navAriaLabel": { "message": "Сайдбар документации", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Закрыть панель навигации", "description": "The ARIA label for close button of mobile sidebar" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Переключить навигационную панель", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Перейти к главному меню", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Развернуть выпадающее меню", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Свернуть выпадающее меню", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Развернуть сайдбар", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Развернуть сайдбар", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "{count} запись|{count} записи|{count} записей", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} с тегом \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Авторы", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Посмотреть всех авторов", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Этот автор ещё не написал ни одной публикации.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Страница не в списке", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Эта страница не включена в список. Поисковые системы не будут индексировать её, и доступ к ней имеют только пользователи с прямой ссылкой.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Черновик страницы", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Это черновик страницы. Она будет видна только в режиме разработки и будет исключена из продакшен-сборки.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Попробуйте ещё раз", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Перейти к основному содержимому", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Теги", "description": "The title of the tag list page" } } ================================================ FILE: i18n/ru/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Блог", "description": "The title for the blog used in SEO" }, "description": { "message": "Блог", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Все записи", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Использование Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Команды Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Чарты", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Разработка шаблонов", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Лучшие практики", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Общие соглашения description: Общие соглашения для чартов. sidebar_position: 1 --- Эта часть руководства по лучшим практикам посвящена общим соглашениям. ## Названия чартов Названия чартов должны содержать только строчные буквы и цифры. Слова _могут_ быть разделены дефисами (-): Примеры: ``` drupal nginx-lego aws-cluster-autoscaler ``` В названиях чартов нельзя использовать заглавные буквы и подчёркивания. Точки также не следует использовать в названиях чартов. ## Номера версий По возможности Helm использует [SemVer 2](https://semver.org) для представления номеров версий. (Обратите внимание, что теги Docker-образов не обязательно соответствуют SemVer и поэтому считаются досадным исключением из этого правила.) При хранении версий SemVer в метках Kubernetes символ `+` принято заменять на `_`, так как метки не допускают использование символа `+` в качестве значения. ## Форматирование YAML Файлы YAML должны использовать отступы в _два пробела_ (и никогда табуляцию). ## Использование слов Helm и чарт Существует несколько соглашений по использованию слов _Helm_ и _helm_. - _Helm_ относится к проекту в целом - `helm` относится к клиентской команде - Термин `chart` не нужно писать с заглавной буквы, так как это не имя собственное - Однако `Chart.yaml` нужно писать с заглавной буквы, так как имя файла чувствительно к регистру Если есть сомнения, используйте _Helm_ (с заглавной «H»). ## Шаблоны чартов и пространства имён Избегайте определения свойства `namespace` в секции `metadata` шаблонов вашего чарта. Пространство имён для применения отрендеренных шаблонов должно указываться при вызове клиента Kubernetes через флаг `--namespace`. Helm рендерит ваши шаблоны как есть и отправляет их клиенту Kubernetes — будь то сам Helm или другая программа (kubectl, flux, spinnaker и т.д.). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Пользовательские определения ресурсов description: Как создавать и использовать CRD. sidebar_position: 7 --- Эта часть руководства по лучшим практикам посвящена созданию и использованию объектов Custom Resource Definition. При работе с Custom Resource Definition (CRD) важно различать две составляющие: - Есть декларация CRD. Это YAML-файл с kind `CustomResourceDefinition` - Есть ресурсы, которые _используют_ CRD. Например, если CRD определяет `foo.example.com/v1`, то любой ресурс с `apiVersion: example.com/v1` и kind `Foo` является ресурсом, использующим этот CRD. ## Установите декларацию CRD перед использованием ресурса Helm оптимизирован для максимально быстрой загрузки ресурсов в Kubernetes. Kubernetes спроектирован так, что может принять целый набор манифестов и привести в рабочее состояние (это называется циклом согласования). Но с CRD есть одно отличие. Для CRD декларация должна быть зарегистрирована до того, как можно будет использовать какие-либо ресурсы этого типа CRD. А процесс регистрации иногда занимает несколько секунд. ### Метод 1: Позвольте `helm` сделать это за вас С выходом Helm 3 мы убрали старые хуки `crd-install` в пользу более простой методологии. Теперь вы можете создать в своём чарте специальную директорию `crds` для хранения ваших CRD. Эти CRD не шаблонизируются, но устанавливаются по умолчанию при выполнении `helm install` для чарта. Если CRD уже существует, он будет пропущен с предупреждением. Если вы хотите пропустить шаг установки CRD, можете передать флаг `--skip-crds`. #### Некоторые оговорки (и объяснения) На данный момент обновление или удаление CRD с помощью Helm не поддерживается. Это было осознанное решение после длительного обсуждения в сообществе из-за опасности непреднамеренной потери данных. Кроме того, в настоящее время нет консенсуса в сообществе относительно того, как обращаться с CRD и их жизненным циклом. По мере развития ситуации Helm добавит поддержку этих сценариев использования. Флаг `--dry-run` команд `helm install` и `helm upgrade` в настоящее время не поддерживается для CRD. Цель «Dry Run» — проверить, что вывод чарта действительно будет работать при отправке на сервер. Но CRD изменяют поведение сервера. Helm не может установить CRD при dry run, поэтому клиент обнаружения не будет знать об этом Custom Resource (CR), и валидация завершится неудачей. В качестве альтернативы вы можете вынести CRD в отдельный чарт или использовать `helm template` вместо этого. Ещё один важный момент при обсуждении поддержки CRD — это то, как обрабатывается рендеринг шаблонов. Одним из существенных недостатков метода `crd-install`, использовавшегося в Helm 2, была невозможность правильной валидации чартов из-за изменения доступности API (CRD фактически добавляет ещё один доступный API в ваш кластер Kubernetes). Если чарт устанавливал CRD, у `helm` больше не было актуального набора версий API для работы. Это также причина удаления поддержки шаблонизации из CRD. С новым методом установки CRD через директорию `crds` мы теперь гарантируем, что `helm` имеет полностью достоверную информацию о текущем состоянии кластера. ### Метод 2: Разделение на отдельные чарты Другой способ — поместить определение CRD в один чарт, а все ресурсы, использующие этот CRD, — в _другой_ чарт. При этом методе каждый чарт должен устанавливаться отдельно. Однако такой рабочий процесс может быть более полезен для операторов кластера, имеющих административный доступ к кластеру. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Зависимости description: Рекомендации по работе с зависимостями чартов. sidebar_position: 4 --- Эта часть руководства по лучшим практикам посвящена зависимостям (`dependencies`), объявленным в файле `Chart.yaml`. ## Версии По возможности используйте диапазоны версий вместо фиксации на конкретной версии. Рекомендуемый подход — использовать соответствие на уровне патч-версии: ```yaml version: ~1.2.3 ``` Это выражение соответствует версии `1.2.3` и всем патчам этого релиза. Другими словами, `~1.2.3` эквивалентно `>= 1.2.3, < 1.3.0`. Полное описание синтаксиса версий см. в [документации semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Предварительные версии (prerelease) Указанные выше ограничения версий не применяются к предварительным версиям. Например, `version: ~1.2.3` будет соответствовать `version: ~1.2.4`, но не `version: ~1.2.3-1`. Следующий синтаксис позволяет сопоставлять как патч-версии, так и предварительные версии: ```yaml version: ~1.2.3-0 ``` ### URL репозиториев По возможности используйте URL с `https://`, затем — с `http://`. Если репозиторий добавлен в индексный файл репозиториев, имя репозитория можно использовать как псевдоним URL. Используйте `alias:` или `@` перед именем репозитория. URL-адреса файлов (`file://...`) рассматриваются как «особый случай» для чартов, которые собираются в рамках фиксированного конвейера развёртывания. При использовании [плагинов-загрузчиков](../topics/plugins.md#плагины-загрузчики) схема URL будет специфичной для плагина. Обратите внимание: пользователю чарта потребуется установленный плагин, поддерживающий данную схему, для обновления или сборки зависимости. Helm не может выполнять операции управления зависимостями, если поле `repository` оставлено пустым. В этом случае Helm предполагает, что зависимость находится в подкаталоге папки `charts` с именем, совпадающим со значением свойства `name` зависимости. ## Условия и теги Условия (conditions) или теги (tags) следует добавлять к любым зависимостям, которые являются _опциональными_. Обратите внимание, что по умолчанию `condition` имеет значение `true`. Предпочтительная форма условия: ```yaml condition: somechart.enabled ``` Где `somechart` — это имя чарта-зависимости. Когда несколько подчартов (зависимостей) вместе предоставляют опциональную или взаимозаменяемую функциональность, эти чарты должны использовать одинаковые теги. Например, если `nginx` и `memcached` вместе обеспечивают оптимизацию производительности основного приложения в чарте и должны присутствовать одновременно при включении этой функции, то оба должны иметь следующий раздел тегов: ```yaml tags: - webaccelerator ``` Это позволяет пользователю включать или отключать данную функциональность с помощью одного тега. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: Лучшие практики sidebar: true sidebar_position: 4 --- # Руководство по лучшим практикам для чартов Это руководство описывает лучшие практики создания чартов, рекомендованные командой Helm. Оно фокусируется на том, как должны быть структурированы чарты. Мы уделяем основное внимание лучшим практикам для чартов, которые могут быть публично развёрнуты. Мы понимаем, что многие чарты предназначены только для внутреннего использования, и авторы таких чартов могут обнаружить, что их внутренние требования расходятся с нашими рекомендациями. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Метки и аннотации description: Рекомендации по использованию меток и аннотаций в чартах. sidebar_position: 5 --- Эта часть руководства по лучшим практикам посвящена использованию меток и аннотаций в чартах. ## Метка или аннотация? Элемент метаданных должен быть меткой, если: - Он используется Kubernetes для идентификации ресурса - Он полезен администраторам для запросов к системе. Например, мы рекомендуем использовать `helm.sh/chart: NAME-VERSION` в качестве метки, чтобы администраторы могли легко находить все экземпляры определённого чарта. Если элемент метаданных не используется для запросов, его следует устанавливать как аннотацию. Хуки Helm всегда являются аннотациями. ## Стандартные метки В таблице ниже перечислены общепринятые метки, используемые в чартах Helm. Сам Helm не требует наличия какой-либо конкретной метки. Метки, отмеченные как REC, являются рекомендуемыми и **должны** присутствовать в чарте для обеспечения единообразия. Метки, отмеченные как OPT, являются опциональными. Они широко распространены, но редко требуются в рабочих процессах. Имя|Статус|Описание -----|------|---------- `app.kubernetes.io/name` | REC | Название приложения целиком. Обычно используется `{{ template "name" . }}`. Эта метка используется во многих манифестах Kubernetes, не только в Helm. `helm.sh/chart` | REC | Название и версия чарта: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | Всегда устанавливается в `{{ .Release.Service }}`. Используется для поиска всех ресурсов, управляемых Helm. `app.kubernetes.io/instance` | REC | Устанавливается в `{{ .Release.Name }}`. Помогает различать разные экземпляры одного и того же приложения. `app.kubernetes.io/version` | OPT | Версия приложения. Может быть установлена в `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | Общепринятая метка для обозначения роли компонентов в приложении. Например, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | Используется, когда несколько чартов или программных компонентов вместе составляют единое приложение. Например, прикладное ПО и база данных для создания веб-сайта. Может быть установлена в название приложения верхнего уровня. Подробную информацию о метках Kubernetes с префиксом `app.kubernetes.io` можно найти в [документации Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pod и PodTemplate description: Рекомендации по форматированию секций Pod и PodTemplate в манифестах чартов. sidebar_position: 6 --- Эта часть руководства по лучшим практикам посвящена форматированию секций Pod и PodTemplate в манифестах чартов. Следующий (неполный) список ресурсов использует PodTemplate: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Образы Образ контейнера должен использовать фиксированный тег или SHA образа. Не следует использовать теги `latest`, `head`, `canary` или другие теги, которые являются «плавающими». Образы _могут_ быть определены в файле `values.yaml` для удобной замены образов. ```yaml image: {{ .Values.redisImage | quote }} ``` Образ и тег _могут_ быть определены в `values.yaml` как два отдельных поля: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy Команда `helm create` устанавливает `imagePullPolicy` в значение `IfNotPresent` по умолчанию, добавляя следующее в ваш `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` И в `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Аналогично, Kubernetes устанавливает `imagePullPolicy` в значение `IfNotPresent` по умолчанию, если оно не задано вообще. Если вам нужно значение, отличное от `IfNotPresent`, просто обновите значение в `values.yaml` на желаемое. ## Секции PodTemplate должны объявлять селекторы Все секции PodTemplate должны указывать селектор. Например: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Это хорошая практика, поскольку она явно определяет связь между набором и Pod. Но это ещё более важно для таких ресурсов, как Deployment. Без этого для выбора соответствующих Pod будет использоваться _весь_ набор меток, что приведёт к сбоям, если вы используете метки, которые изменяются, например версию или дату релиза. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Управление доступом на основе ролей description: Рекомендации по созданию и форматированию ресурсов RBAC в манифестах чартов. sidebar_position: 8 --- Эта часть руководства по лучшим практикам посвящена созданию и форматированию ресурсов RBAC в манифестах чартов. К ресурсам RBAC относятся: - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## Конфигурация YAML Настройки RBAC и ServiceAccount должны располагаться в отдельных ключах. Это разные сущности. Разделение этих концепций в YAML устраняет неоднозначность и делает конфигурацию более понятной. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` Эту структуру можно расширить для более сложных чартов, требующих несколько ServiceAccount. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Ресурсы RBAC должны создаваться по умолчанию Параметр `rbac.create` должен быть булевым значением, управляющим созданием ресурсов RBAC. Значение по умолчанию должно быть `true`. Пользователи, которые хотят управлять доступом RBAC самостоятельно, могут установить это значение в `false` (в этом случае см. ниже). ## Использование ресурсов RBAC В параметре `serviceAccount.name` должно быть указано имя ServiceAccount, который будет использоваться ресурсами с контролем доступа, создаваемыми чартом. Если `serviceAccount.create` равен true, то ServiceAccount с этим именем должен быть создан. Если имя не указано, оно генерируется с помощью шаблона `fullname`. Если `serviceAccount.create` равен false, то ServiceAccount не создаётся, но он всё равно должен быть связан с теми же ресурсами, чтобы вручную созданные ресурсы RBAC, ссылающиеся на него, работали корректно. Если `serviceAccount.create` равен false и имя не указано, используется ServiceAccount по умолчанию. Для ServiceAccount следует использовать следующий вспомогательный шаблон. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Шаблоны description: Подробные рекомендации по работе с шаблонами. sidebar_position: 3 --- Эта часть руководства по лучшим практикам посвящена работе с шаблонами. ## Структура директории `templates/` Директория `templates/` должна быть организована следующим образом: - Файлы шаблонов должны иметь расширение `.yaml`, если они генерируют YAML-вывод. Расширение `.tpl` может использоваться для файлов шаблонов, которые не производят форматированного содержимого. - Имена файлов шаблонов должны использовать нотацию с дефисами (`my-example-configmap.yaml`), а не camelCase. - Каждое определение ресурса должно находиться в отдельном файле шаблона. - Имена файлов шаблонов должны отражать тип ресурса в названии, например: `foo-pod.yaml`, `bar-svc.yaml` ## Имена именованных шаблонов Именованные шаблоны (шаблоны, созданные внутри директивы `{{ define }}`) доступны глобально. Это означает, что чарт и все его субчарты будут иметь доступ ко всем шаблонам, созданным с помощью `{{ define }}`. По этой причине _все имена именованных шаблонов должны иметь уникальный префикс._ Правильно: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Неправильно: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Настоятельно рекомендуется создавать новые чарты с помощью команды `helm create`, поскольку при этом имена шаблонов автоматически формируются в соответствии с этой лучшей практикой. ## Форматирование шаблонов Шаблоны должны иметь отступы в _два пробела_ (никогда не используйте табуляцию). Директивы шаблона должны иметь пробел после открывающих фигурных скобок и перед закрывающими фигурными скобками: Правильно: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Неправильно: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` По возможности шаблоны должны удалять лишние пробельные символы: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Блоки (такие как управляющие конструкции) могут иметь отступы для отображения потока кода шаблона. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Однако, поскольку YAML является языком, ориентированным на пробельные символы, часто невозможно следовать этому соглашению для отступов кода. ## Пробельные символы в сгенерированных шаблонах Предпочтительно минимизировать количество пробельных символов в сгенерированных шаблонах. В частности, множество пустых строк не должно располагаться рядом друг с другом. Однако отдельные пустые строки (особенно между логическими секциями) допустимы. Лучше всего так: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Так тоже допустимо: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Но такого следует избегать: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Комментарии (YAML-комментарии и комментарии шаблонов) И YAML, и шаблоны Helm имеют маркеры комментариев. YAML-комментарии: ```yaml # Это комментарий type: sprocket ``` Комментарии шаблонов: ```yaml {{- /* Это комментарий. */}} type: frobnitz ``` Комментарии шаблонов следует использовать для документирования возможностей шаблона, например, для пояснения именованного шаблона: ```yaml {{- /* mychart.shortname предоставляет обрезанную до 6 символов версию имени релиза. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Внутри шаблонов YAML-комментарии могут использоваться, когда полезно, чтобы пользователи Helm могли (возможно) видеть комментарии во время отладки. ```yaml # Это может вызвать проблемы, если значение превышает 100Gi memory: {{ .Values.maxMem | quote }} ``` Комментарий выше виден, когда пользователь выполняет `helm install --debug`, тогда как комментарии, указанные в секциях `{{- /* */}}`, не видны. Будьте осторожны при добавлении YAML-комментариев `#` к секциям шаблона, содержащим значения Helm, которые могут потребоваться для некоторых функций шаблона. Например, если к приведённому выше примеру добавить функцию `required`, и `maxMem` не задано, то YAML-комментарий `#` вызовет ошибку рендеринга. Правильно: `helm template` не выполняет рендеринг этого блока ```yaml {{- /* # Это может вызвать проблемы, если значение превышает 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Неправильно: `helm template` возвращает `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # Это может вызвать проблемы, если значение превышает 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Смотрите [Отладка шаблонов](/chart_template_guide/debugging.md), где приведён другой пример такого поведения — YAML-комментарии остаются без изменений. ## Использование JSON в шаблонах и выводе шаблонов YAML является надмножеством JSON. В некоторых случаях использование синтаксиса JSON может быть более читаемым, чем другие представления YAML. Например, этот YAML ближе к обычному методу YAML для выражения списков: ```yaml arguments: - "--dirname" - "/foo" ``` Но его легче читать, когда он свёрнут в стиле JSON-списка: ```yaml arguments: ["--dirname", "/foo"] ``` Использование JSON для повышения читаемости — хорошая практика. Однако синтаксис JSON не следует использовать для представления более сложных конструкций. При работе с чистым JSON, встроенным в YAML (например, конфигурация init-контейнера), конечно, уместно использовать формат JSON. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Рекомендации по структуре и использованию values. sidebar_position: 2 --- Эта часть руководства по лучшим практикам посвящена использованию values. Здесь мы даём рекомендации по структуре и использованию values с акцентом на проектирование файла `values.yaml` чарта. ## Соглашения об именовании Имена переменных должны начинаться со строчной буквы, а слова разделяться в стиле camelCase: Правильно: ```yaml chicken: true chickenNoodleSoup: true ``` Неправильно: ```yaml Chicken: true # заглавная буква может конфликтовать со встроенными переменными chicken-noodle-soup: true # не используйте дефисы в именах ``` Обратите внимание, что все встроенные переменные Helm начинаются с заглавной буквы, чтобы их можно было легко отличить от пользовательских значений: `.Release.Name`, `.Capabilities.KubeVersion`. ## Плоские или вложенные значения YAML — гибкий формат, и значения могут быть как глубоко вложенными, так и плоскими. Вложенные: ```yaml server: name: nginx port: 80 ``` Плоские: ```yaml serverName: nginx serverPort: 80 ``` В большинстве случаев плоская структура предпочтительнее вложенной. Причина в том, что так проще и для разработчиков шаблонов, и для пользователей. Для обеспечения безопасности вложенное значение необходимо проверять на каждом уровне: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Для каждого уровня вложенности требуется проверка существования. Для плоской конфигурации такие проверки можно пропустить, что делает шаблон проще для чтения и использования. ``` {{ default "none" .Values.serverName }} ``` Вложенные значения можно использовать для улучшения читаемости, когда имеется большое количество связанных переменных и хотя бы одна из них является обязательной. ## Явно указывайте типы Правила приведения типов в YAML иногда неинтуитивны. Например, `foo: false` — это не то же самое, что `foo: "false"`. Большие целые числа, такие как `foo: 12345678`, в некоторых случаях преобразуются в экспоненциальную запись. Самый простой способ избежать ошибок преобразования типов — быть явным со строками и неявным со всем остальным. Или, коротко, _заключайте все строки в кавычки_. Часто бывает полезно хранить целые числа также в виде строк, чтобы избежать проблем с приведением типов, и использовать `{{ int $value }}` в шаблоне для преобразования строки обратно в целое число. В большинстве случаев явные теги типов корректно обрабатываются, поэтому `foo: !!string 1234` будет воспринимать `1234` как строку. _Однако_ YAML-парсер обрабатывает теги, и информация о типе теряется после первого разбора. ## Учитывайте, как пользователи будут использовать ваши values Существует три возможных источника values: - Файл `values.yaml` чарта - Файл values, переданный через `helm install -f` или `helm upgrade -f` - Значения, переданные через флаг `--set` или `--set-string` при выполнении `helm install` или `helm upgrade` При проектировании структуры values помните, что пользователи вашего чарта могут захотеть переопределить их с помощью флага `-f` или опции `--set`. Поскольку `--set` более ограничен в выразительности, первое правило при написании файла `values.yaml` — _упростите переопределение через `--set`_. По этой причине часто лучше структурировать файл values с помощью словарей (maps). Сложно использовать с `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Приведённую выше структуру невозможно выразить с помощью `--set` в Helm `<=2.4`. В Helm 2.5 обращение к порту foo выглядит как `--set servers[0].port=80`. Это не только сложнее для понимания пользователем, но и подвержено ошибкам, если впоследствии порядок `servers` изменится. Удобно использовать: ```yaml servers: foo: port: 80 bar: port: 81 ``` Обращение к порту foo гораздо очевиднее: `--set servers.foo.port=80`. ## Документируйте `values.yaml` Каждое определённое свойство в `values.yaml` должно быть задокументировано. Строка документации должна начинаться с имени свойства, которое она описывает, и содержать как минимум одно предложение с описанием. Неправильно: ```yaml # имя хоста для веб-сервера serverHost: example serverPort: 9191 ``` Правильно: ```yaml # serverHost — имя хоста для веб-сервера serverHost: example # serverPort — порт HTTP-слушателя для веб-сервера serverPort: 9191 ``` Начало каждого комментария с имени параметра, который он документирует, упрощает поиск документации с помощью grep и позволяет инструментам документирования надёжно сопоставлять строки документации с описываемыми параметрами. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Доступ к файлам внутри шаблонов description: Как получить доступ к файлам из шаблона. sidebar_position: 10 --- В предыдущем разделе мы рассмотрели несколько способов создания и использования именованных шаблонов. Это упрощает импорт одного шаблона из другого. Однако иногда необходимо импортировать _файл, который не является шаблоном_, и вставить его содержимое без обработки движком шаблонов. Helm предоставляет доступ к файлам через объект `.Files`. Прежде чем мы перейдём к примерам шаблонов, следует учесть несколько особенностей работы этого механизма: - В чарт Helm можно добавлять дополнительные файлы. Эти файлы будут включены в пакет чарта. Однако будьте осторожны: из-за ограничений на размер объектов Kubernetes чарты должны быть меньше 1 МБ. - Некоторые файлы недоступны через объект `.Files`, как правило, по соображениям безопасности: - Файлы в директории `templates/` недоступны. - Файлы, исключённые с помощью `.helmignore`, недоступны. - Файлы, находящиеся за пределами приложения Helm — [субчарта](/chart_template_guide/subcharts_and_globals.md), включая файлы родительского чарта, недоступны. - Чарты не сохраняют информацию о правах доступа UNIX, поэтому права на уровне файлов не влияют на доступность файла через объект `.Files`. - [Базовый пример](#базовый-пример) - [Вспомогательные функции для путей](#вспомогательные-функции-для-путей) - [Glob-паттерны](#glob-паттерны) - [Вспомогательные функции для ConfigMap и Secret](#вспомогательные-функции-для-configmap-и-secret) - [Кодирование](#кодирование) - [Строки](#строки) ## Базовый пример Учитывая вышеописанные ограничения, давайте напишем шаблон, который читает три файла и помещает их в ConfigMap. Для начала добавим три файла в чарт, разместив их непосредственно в директории `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Каждый из этих файлов представляет собой простой TOML-файл (напоминает старые INI-файлы Windows). Мы знаем имена этих файлов, поэтому можем использовать функцию `range` для перебора и вставки их содержимого в ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` В этом ConfigMap используются несколько техник, рассмотренных в предыдущих разделах. Например, мы создаём переменную `$files` для хранения ссылки на объект `.Files`. Также мы используем функцию `tuple` для создания списка файлов, по которому выполняем перебор. Затем выводим имя каждого файла (`{{ . }}: |-`), а за ним — содержимое файла `{{ $files.Get . }}`. Выполнение этого шаблона создаст один ConfigMap с содержимым всех трёх файлов: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Вспомогательные функции для путей При работе с файлами часто бывает полезно выполнять стандартные операции над путями. Для этого Helm импортирует многие функции из пакета Go [path](https://golang.org/pkg/path/). Все они доступны с теми же именами, что и в Go, но с первой буквой в нижнем регистре. Например, `Base` становится `base` и так далее. Импортированные функции: - Base - Dir - Ext - IsAbs - Clean ## Glob-паттерны По мере роста вашего чарта может возникнуть потребность в лучшей организации файлов. Для этого мы предоставляем метод `Files.Glob(pattern string)`, который помогает извлекать определённые файлы с гибкостью [glob-паттернов](https://godoc.org/github.com/gobwas/glob). `.Glob` возвращает объект типа `Files`, поэтому вы можете вызывать любые методы `Files` на возвращённом объекте. Например, представим следующую структуру директорий: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` С glob-паттернами у вас есть несколько вариантов: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Или ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Вспомогательные функции для ConfigMap и Secret (Доступно начиная с Helm 2.0.2) Очень часто возникает необходимость помещать содержимое файлов в ConfigMap и Secret для монтирования в Pod'ы во время выполнения. Для этого мы предоставляем несколько вспомогательных методов для типа `Files`. Для лучшей организации особенно полезно использовать эти методы совместно с методом `Glob`. Используя структуру директорий из примера [Glob-паттернов](#glob-паттерны): ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Кодирование Вы можете импортировать файл и закодировать его в base64 в шаблоне для обеспечения успешной передачи: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Этот пример возьмёт тот же файл `config1.toml`, который мы использовали ранее, и закодирует его: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Строки Иногда бывает необходимо получить доступ к каждой строке файла в шаблоне. Для этого мы предоставляем удобный метод `Lines`. Вы можете выполнить перебор строк с помощью функции `range`: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Невозможно передать файлы извне чарта во время выполнения `helm install`. Поэтому, если вы хотите, чтобы пользователи предоставили данные, их необходимо загрузить с помощью `helm install -f` или `helm install --set`. На этом мы завершаем изучение инструментов и техник написания шаблонов Helm. В следующем разделе мы рассмотрим, как использовать специальный файл `templates/NOTES.txt` для отправки инструкций по завершении установки пользователям вашего чарта. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Встроенные объекты description: Встроенные объекты, доступные в шаблонах. sidebar_position: 3 --- Объекты передаются в шаблон движком шаблонов. Ваш код может передавать объекты дальше (мы увидим примеры при рассмотрении операторов `with` и `range`). Существует даже несколько способов создания новых объектов внутри шаблонов, например, с помощью функции `tuple`, которую мы рассмотрим позже. Объекты могут быть простыми и содержать только одно значение. Или они могут содержать другие объекты или функции. Например, объект `Release` содержит несколько объектов (таких как `Release.Name`), а объект `Files` имеет несколько функций. В предыдущем разделе мы использовали `{{ .Release.Name }}` для вставки имени релиза в шаблон. `Release` — это один из объектов верхнего уровня, к которым вы можете обращаться в своих шаблонах. - `Release`: Этот объект описывает сам релиз. Он содержит несколько объектов: - `Release.Name`: Имя релиза - `Release.Namespace`: Пространство имён, в которое будет выполнен релиз (если манифест не переопределяет его) - `Release.IsUpgrade`: Устанавливается в `true`, если текущая операция — обновление или откат. - `Release.IsInstall`: Устанавливается в `true`, если текущая операция — установка. - `Release.Revision`: Номер ревизии для этого релиза. При установке равен 1 и увеличивается с каждым обновлением и откатом. - `Release.Service`: Сервис, который выполняет рендеринг текущего шаблона. В Helm это всегда `Helm`. - `Values`: Значения, переданные в шаблон из файла `values.yaml` и из пользовательских файлов. По умолчанию `Values` пуст. - `Chart`: Содержимое файла `Chart.yaml`. Любые данные из `Chart.yaml` будут доступны здесь. Например, `{{ .Chart.Name }}-{{ .Chart.Version }}` выведет `mychart-0.1.0`. - Доступные поля перечислены в [Руководстве по чартам](/topics/charts.md#the-chartyaml-file) - `Subcharts`: Обеспечивает доступ к области видимости (.Values, .Charts, .Releases и т.д.) субчартов из родительского чарта. Например, `.Subcharts.mySubChart.myValue` для доступа к `myValue` в чарте `mySubChart`. - `Files`: Обеспечивает доступ ко всем неспециальным файлам в чарте. Хотя вы не можете использовать его для доступа к шаблонам, вы можете использовать его для доступа к другим файлам в чарте. Подробнее см. в разделе [Доступ к файлам](/chart_template_guide/accessing_files.md). - `Files.Get` — функция для получения файла по имени (`.Files.Get config.ini`) - `Files.GetBytes` — функция для получения содержимого файла в виде массива байтов вместо строки. Это полезно для таких вещей, как изображения. - `Files.Glob` — функция, возвращающая список файлов, имена которых соответствуют заданному шаблону glob. - `Files.Lines` — функция для построчного чтения файла. Полезна для перебора каждой строки в файле. - `Files.AsSecrets` — функция, возвращающая содержимое файлов в виде строк, закодированных в Base 64. - `Files.AsConfig` — функция, возвращающая содержимое файлов в виде YAML-карты. - `Capabilities`: Предоставляет информацию о возможностях, которые поддерживает кластер Kubernetes. - `Capabilities.APIVersions` — набор версий. - `Capabilities.APIVersions.Has $version` — указывает, доступна ли в кластере версия (например, `batch/v1`) или ресурс (например, `apps/v1/Deployment`). - `Capabilities.KubeVersion` и `Capabilities.KubeVersion.Version` — версия Kubernetes. - `Capabilities.KubeVersion.Major` — мажорная версия Kubernetes. - `Capabilities.KubeVersion.Minor` — минорная версия Kubernetes. - `Capabilities.HelmVersion` — объект, содержащий информацию о версии Helm; это тот же вывод, что и у `helm version`. - `Capabilities.HelmVersion.Version` — текущая версия Helm в формате semver. - `Capabilities.HelmVersion.GitCommit` — git sha1 Helm. - `Capabilities.HelmVersion.GitTreeState` — состояние git-дерева Helm. - `Capabilities.HelmVersion.GoVersion` — версия использованного компилятора Go. - `Template`: Содержит информацию о текущем выполняемом шаблоне - `Template.Name`: Путь к текущему шаблону с указанием пространства имён (например, `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: Путь к директории templates текущего чарта с указанием пространства имён (например, `mychart/templates`). Имена встроенных значений всегда начинаются с заглавной буквы. Это соответствует соглашению об именовании Go. При создании собственных имён вы можете использовать любое соглашение, которое подходит вашей команде. Некоторые команды, в том числе многие авторы чартов на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), предпочитают использовать только строчные буквы в начале имён, чтобы отличать локальные имена от встроенных. В этом руководстве мы следуем этому соглашению. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Управление потоком выполнения description: Краткий обзор управляющих структур в шаблонах. sidebar_position: 7 --- Управляющие структуры (называемые в терминологии шаблонов «действиями») позволяют вам, как автору шаблона, управлять генерацией шаблона. Язык шаблонов Helm предоставляет следующие управляющие структуры: - `if`/`else` для создания условных блоков - `with` для указания области видимости - `range` для организации цикла в стиле «для каждого» Кроме того, язык предоставляет несколько действий для объявления и использования именованных фрагментов шаблонов: - `define` объявляет новый именованный шаблон внутри вашего шаблона - `template` импортирует именованный шаблон - `block` объявляет особый вид заполняемой области шаблона В этом разделе мы рассмотрим `if`, `with` и `range`. Остальные описаны в разделе «Именованные шаблоны» далее в этом руководстве. ## If/Else Первая управляющая структура предназначена для условного включения блоков текста в шаблон. Это блок `if`/`else`. Базовая структура условия выглядит следующим образом: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Обратите внимание: речь идёт о _конвейерах_, а не просто о значениях. Это подчёркивает, что управляющие структуры могут выполнять целый конвейер, а не только вычислять одно значение. Конвейер вычисляется как _false_, если значение: - булево false - числовой ноль - пустая строка - `nil` (пустое или null) - пустая коллекция (`map`, `slice`, `tuple`, `dict`, `array`) Во всех остальных случаях условие истинно. Добавим простое условие в наш ConfigMap. Мы добавим ещё одну настройку, если напиток установлен как coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Поскольку в предыдущем примере мы закомментировали `drink: coffee`, в выводе не будет флага `mug: "true"`. Но если добавить эту строку обратно в файл `values.yaml`, вывод будет выглядеть так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Управление пробелами Рассматривая условия, стоит кратко остановиться на управлении пробелами в шаблонах. Возьмём предыдущий пример и отформатируем его для удобства чтения: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` На первый взгляд всё хорошо. Но если пропустить его через движок шаблонов, получим неожиданный результат: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Что произошло? Мы сгенерировали некорректный YAML из-за пробелов. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` имеет неправильный отступ. Уберём лишний отступ в этой строке и запустим снова: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Теперь YAML корректен, но выглядит несколько странно: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` В YAML появились пустые строки. Почему? Движок шаблонов _удаляет_ содержимое внутри `{{` и `}}`, но оставляет окружающие пробелы без изменений. В YAML пробелы имеют значение, поэтому управление ими становится важным. К счастью, в шаблонах Helm есть несколько инструментов для этого. Во-первых, синтаксис фигурных скобок можно модифицировать специальными символами, чтобы указать движку обрезать пробелы. `{{- ` (с дефисом и пробелом) означает, что пробелы слева должны быть обрезаны, а ` -}}` — что пробелы справа должны быть обрезаны. _Будьте внимательны! Переводы строк тоже считаются пробелами!_ > Убедитесь, что между `-` и остальной частью директивы есть пробел. > `{{- 3 }}` означает «обрезать пробелы слева и вывести 3», тогда как `{{-3 }}` означает «вывести -3». Используя этот синтаксис, мы можем изменить наш шаблон, чтобы избавиться от пустых строк: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Для наглядности заменим символом `*` каждый пробел, который будет обрезан согласно этому правилу. Символ `*` в конце строки обозначает перевод строки, который будет удалён: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Учитывая это, запустим наш шаблон через Helm и посмотрим результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Будьте осторожны с модификаторами обрезки. Легко случайно сделать что-то вроде этого: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Это даст `food: "PIZZA"mug: "true"`, потому что будут обрезаны переводы строк с обеих сторон. > Подробнее об управлении пробелами в шаблонах см. в [официальной документации Go template](https://godoc.org/text/template). Наконец, иногда проще указать системе шаблонов, как делать отступы, вместо того чтобы пытаться управлять пробелами вручную. Для этого может быть полезна функция `indent` (`{{ indent 2 "mug:true" }}`). ## Изменение области видимости с помощью `with` Следующая управляющая структура — действие `with`. Оно управляет областью видимости переменных. Напомним, что `.` — это ссылка на _текущую область видимости_. Таким образом, `.Values` указывает шаблону искать объект `Values` в текущей области видимости. Синтаксис `with` похож на простой оператор `if`: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Область видимости можно изменять. `with` позволяет установить текущую область видимости (`.`) на конкретный объект. Например, мы работали с `.Values.favorite`. Перепишем наш ConfigMap, изменив область видимости `.` так, чтобы она указывала на `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Обратите внимание: мы убрали условие `if` из предыдущего примера, поскольку оно больше не нужно — блок после `with` выполняется только если значение `PIPELINE` не пустое. Теперь мы можем ссылаться на `.drink` и `.food` без полного пути. Это возможно потому, что оператор `with` устанавливает `.` так, чтобы она указывала на `.Values.favorite`. После `{{ end }}` область видимости `.` сбрасывается к предыдущему значению. Но будьте осторожны! Внутри ограниченной области видимости вы не сможете обращаться к другим объектам из родительской области через `.`. Например, следующий код не сработает: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Это вызовет ошибку, потому что `Release.Name` недоступен внутри ограниченной области видимости `.`. Однако если поменять местами две последние строки, всё будет работать корректно, поскольку область видимости сбрасывается после `{{ end }}`: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Также можно использовать `$` для доступа к объекту `Release.Name` из родительской области видимости. Переменная `$` указывает на корневую область видимости при начале выполнения шаблона и не изменяется в процессе выполнения. Следующий вариант тоже будет работать: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` После рассмотрения `range` мы разберём переменные шаблонов, которые предлагают ещё одно решение описанной выше проблемы с областью видимости. ## Циклы с действием `range` Многие языки программирования поддерживают циклы с помощью `for`, `foreach` или аналогичных механизмов. В языке шаблонов Helm для итерации по коллекции используется оператор `range`. Для начала добавим список начинок для пиццы в файл `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Теперь у нас есть список (в терминологии шаблонов называемый `slice`) `pizzaToppings`. Мы можем изменить шаблон, чтобы вывести этот список в ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Мы можем использовать `$` для доступа к списку `Values.pizzaToppings` из родительской области видимости. Переменная `$` указывает на корневую область видимости при начале выполнения шаблона и не изменяется в процессе выполнения. Следующий вариант тоже будет работать: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Рассмотрим список `toppings:` подробнее. Функция `range` перебирает (итерирует) список `pizzaToppings`. Здесь происходит кое-что интересное: как и `with`, оператор `range` устанавливает область видимости `.`. На каждой итерации `.` устанавливается на текущий элемент списка. То есть на первой итерации `.` равна `mushrooms`, на второй — `cheese`, и так далее. Мы можем передать значение `.` напрямую в конвейер, поэтому когда мы пишем `{{ . | title | quote }}`, `.` передаётся в `title` (функция преобразования к заглавным буквам), а затем в `quote`. Результат выполнения: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` В этом примере мы применили один трюк. Строка `toppings: |-` объявляет многострочную строку. Таким образом, наш список начинок на самом деле не является YAML-списком — это одна большая строка. Почему? Потому что данные в ConfigMap `data` состоят из пар ключ/значение, где и ключ, и значение являются простыми строками. Подробнее об этом см. в [документации Kubernetes по ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Впрочем, для нас эта деталь не так важна. > Маркер `|-` в YAML обозначает многострочную строку. Это полезный приём для встраивания больших блоков данных в манифесты, как показано здесь. Иногда бывает удобно быстро создать список прямо в шаблоне и затем перебрать его. В шаблонах Helm есть функция для этого: `tuple`. В информатике кортеж — это коллекция фиксированного размера, похожая на список, но с произвольными типами данных. Примерно так `tuple` используется и здесь. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Результат: ```yaml sizes: |- - small - medium - large ``` Помимо списков и кортежей, `range` можно использовать для итерации по коллекциям с ключом и значением (таким как `map` или `dict`). Мы рассмотрим это в следующем разделе, когда познакомимся с переменными шаблонов. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Приложение: типы данных Go и шаблоны" description: Краткий обзор переменных в шаблонах. sidebar_position: 16 --- Язык шаблонов Helm реализован на строго типизированном языке программирования Go. По этой причине переменные в шаблонах являются _типизированными_. Как правило, переменные имеют один из следующих типов: - string: строка текста - bool: значение `true` или `false` - int: целочисленное значение (существуют также 8-, 16-, 32- и 64-битные варианты со знаком и без знака) - float64: 64-битное значение с плавающей точкой (существуют также 8-, 16- и 32-битные варианты) - срез байтов (`[]byte`), часто используется для хранения (потенциально) бинарных данных - struct: объект со свойствами и методами - срез (индексированный список) одного из предыдущих типов - словарь со строковыми ключами (`map[string]interface{}`), где значение относится к одному из предыдущих типов В Go существует множество других типов, и иногда вам придётся преобразовывать их в шаблонах. Самый простой способ узнать тип объекта — передать его в `printf "%T"` внутри шаблона, что выведет тип. Также смотрите функции `typeOf` и `kindOf`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Отладка шаблонов description: Устранение неполадок в чартах, которые не удаётся развернуть. sidebar_position: 13 --- Отладка шаблонов может быть сложной, поскольку обработанные шаблоны отправляются на сервер API Kubernetes, который может отклонить YAML-файлы по причинам, не связанным с форматированием. Несколько команд помогут вам в отладке: - `helm lint` — ваш главный инструмент для проверки соответствия чарта лучшим практикам. - `helm template --debug` позволяет протестировать рендеринг шаблонов чарта локально. - `helm install --dry-run --debug` также рендерит чарт локально без фактической установки, но дополнительно проверяет, не запущены ли уже конфликтующие ресурсы в кластере. При указании `--dry-run=server` также выполняются все функции `lookup` из вашего чарта на сервере. - `helm get manifest` — хороший способ увидеть, какие шаблоны установлены на сервере. Когда YAML не удаётся разобрать, но вы хотите увидеть сгенерированный результат, простой способ получить YAML — закомментировать проблемный участок в шаблоне и повторно выполнить `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` Этот код будет обработан и возвращён с сохранёнными комментариями: ```yaml apiVersion: v2 # some: problem section # "bar" ``` Это позволяет быстро просмотреть сгенерированное содержимое, не сталкиваясь с ошибками парсинга YAML. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Список функций шаблонов description: Список функций шаблонов, доступных в Helm sidebar_position: 6 --- Helm включает множество функций шаблонов, которые вы можете использовать в шаблонах. Они перечислены здесь и разбиты на следующие категории: * [Криптографические функции и функции безопасности](#криптографические-функции-и-функции-безопасности) * [Функции даты](#функции-даты) * [Словари](#словари-и-функции-dict) * [Функции кодирования](#функции-кодирования) * [Функции путей файлов](#функции-путей-файлов) * [Функции Kubernetes и Chart](#функции-kubernetes-и-chart) * [Логика и управление потоком](#функции-логики-и-управления-потоком) * [Списки](#списки-и-функции-list) * [Математические функции](#математические-функции) * [Математические функции с плавающей точкой](#математические-функции-с-плавающей-точкой) * [Сетевые функции](#сетевые-функции) * [Функции рефлексии](#функции-рефлексии) * [Регулярные выражения](#регулярные-выражения) * [Семантические версии](#функции-семантических-версий) * [Строковые функции](#строковые-функции) * [Функции преобразования типов](#функции-преобразования-типов) * [URL-функции](#url-функции) * [UUID-функции](#uuid-функции) ## Функции логики и управления потоком Helm включает множество функций логики и управления потоком, включая [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) и [required](#required). ### and Возвращает логическое И двух или более аргументов (первый пустой аргумент или последний аргумент). ``` and .Arg1 .Arg2 ``` ### or Возвращает логическое ИЛИ двух или более аргументов (первый непустой аргумент или последний аргумент). ``` or .Arg1 .Arg2 ``` ### not Возвращает логическое отрицание аргумента. ``` not .Arg ``` ### eq Возвращает логическое равенство аргументов (например, Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Возвращает логическое неравенство аргументов (например, Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Возвращает `true`, если первый аргумент меньше второго. В противном случае возвращается `false` (например, Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Возвращает `true`, если первый аргумент меньше или равен второму. В противном случае возвращается `false` (например, Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Возвращает `true`, если первый аргумент больше второго. В противном случае возвращается `false` (например, Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Возвращает `true`, если первый аргумент больше или равен второму. В противном случае возвращается `false` (например, Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default Чтобы задать простое значение по умолчанию, используйте `default`: ``` default "foo" .Bar ``` Выше, если `.Bar` имеет непустое значение, оно будет использовано. Если же оно пустое, вместо него будет возвращено `foo`. Определение «пустого» зависит от типа: - Числовые: 0 - Строки: "" - Списки: `[]` - Словари: `{}` - Логические: `false` - И всегда `nil` (также называемый null) Для структур определения пустоты не существует, поэтому структура никогда не вернёт значение по умолчанию. ### required Укажите значения, которые должны быть заданы, с помощью `required`: ``` required "A valid foo is required!" .Bar ``` Если `.Bar` пустой или не определён (см. [default](#default) о том, как это вычисляется), шаблон не будет отрисован и вместо этого будет возвращено указанное сообщение об ошибке. ### empty Функция `empty` возвращает `true`, если данное значение считается пустым, и `false` в противном случае. Пустые значения перечислены в разделе `default`. ``` empty .Foo ``` Обратите внимание, что в условных конструкциях шаблонов Go пустота вычисляется автоматически. Поэтому вам редко нужен `if not empty .Foo`. Вместо этого используйте просто `if .Foo`. ### fail Безусловно возвращает пустую строку (`string`) и ошибку (`error`) с указанным текстом. Это полезно в сценариях, когда другие условия определили, что отрисовка шаблона должна завершиться неудачей. ``` fail "Please accept the end user license agreement" ``` ### coalesce Функция `coalesce` принимает список значений и возвращает первое непустое из них. ``` coalesce 0 1 2 ``` Вернёт `1`. Эта функция полезна для проверки нескольких переменных или значений: ``` coalesce .name .parent.name "Matt" ``` Выше сначала проверяется, пусто ли `.name`. Если нет, это значение будет возвращено. Если оно _пустое_, `coalesce` проверит `.parent.name` на пустоту. Наконец, если и `.name`, и `.parent.name` пусты, будет возвращено `Matt`. ### ternary Функция `ternary` принимает два значения и тестовое значение. Если тестовое значение истинно, возвращается первое значение. Если тестовое значение пустое, возвращается второе значение. Это похоже на тернарный оператор в C и других языках программирования. #### Истинное тестовое значение ``` ternary "foo" "bar" true ``` или ``` true | ternary "foo" "bar" ``` Выше возвращается `"foo"`. #### Ложное тестовое значение ``` ternary "foo" "bar" false ``` или ``` false | ternary "foo" "bar" ``` Выше возвращается `"bar"`. ## Строковые функции Helm включает следующие строковые функции: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-и-hassuffix), [hasSuffix](#hasprefix-и-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-и-squote), [randAlpha](#randalphanum-randalpha-randnumeric-и-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-и-randascii), [randAscii](#randalphanum-randalpha-randnumeric-и-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-и-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-и-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap) и [wrapWith](#wrapwith). ### print Возвращает строку из комбинации своих частей. ``` print "Matt has " .Dogs " dogs" ``` Типы, не являющиеся строками, преобразуются в строки, где это возможно. Обратите внимание: когда два соседних аргумента не являются строками, между ними добавляется пробел. ### println Работает так же, как [print](#print), но добавляет новую строку в конце. ### printf Возвращает строку на основе форматирующей строки и передаваемых ей аргументов по порядку. ``` printf "%s has %d dogs." .Name .NumberDogs ``` Используемый заполнитель зависит от типа передаваемого аргумента. Это включает: Общего назначения: * `%v` значение в формате по умолчанию * при выводе словарей флаг плюс (%+v) добавляет имена полей * `%%` буквальный знак процента; не потребляет значение Логические: * `%t` слово true или false Целочисленные: * `%b` по основанию 2 * `%c` символ, соответствующий данной кодовой точке Unicode * `%d` по основанию 10 * `%o` по основанию 8 * `%O` по основанию 8 с префиксом 0o * `%q` символьный литерал в одинарных кавычках, безопасно экранированный * `%x` по основанию 16 со строчными буквами a-f * `%X` по основанию 16 с заглавными буквами A-F * `%U` формат Unicode: U+1234; эквивалентно "U+%04X" Для чисел с плавающей точкой и комплексных чисел: * `%b` десятичная запись без научной нотации с показателем степени, являющимся степенью двойки, например -123456p-78 * `%e` научная нотация, например -1.234456e+78 * `%E` научная нотация, например -1.234456E+78 * `%f` десятичная точка без экспоненты, например 123.456 * `%F` синоним для %f * `%g` %e для больших экспонент, %f в остальных случаях * `%G` %E для больших экспонент, %F в остальных случаях * `%x` шестнадцатеричная нотация (с десятичной степенью двойки), например -0x1.23abcp+20 * `%X` шестнадцатеричная нотация в верхнем регистре, например -0X1.23ABCP+20 Строки и срезы байтов (обрабатываются одинаково с этими спецификаторами): * `%s` неинтерпретированные байты строки или среза * `%q` строка в двойных кавычках, безопасно экранированная * `%x` по основанию 16, нижний регистр, два символа на байт * `%X` по основанию 16, верхний регистр, два символа на байт Срезы: * `%p` адрес 0-го элемента в шестнадцатеричной нотации с ведущим 0x ### trim Функция `trim` удаляет пробельные символы с обеих сторон строки: ``` trim " hello " ``` Результат: `hello` ### trimAll Удаляет указанные символы с начала и конца строки: ``` trimAll "$" "$5.00" ``` Результат: `5.00` (как строка). ### trimPrefix Удаляет только префикс строки: ``` trimPrefix "-" "-hello" ``` Результат: `hello` ### trimSuffix Удаляет только суффикс строки: ``` trimSuffix "-" "hello-" ``` Результат: `hello` ### lower Преобразует всю строку в нижний регистр: ``` lower "HELLO" ``` Результат: `hello` ### upper Преобразует всю строку в верхний регистр: ``` upper "hello" ``` Результат: `HELLO` ### title Преобразует в заглавный регистр: ``` title "hello world" ``` Результат: `Hello World` ### untitle Убирает заглавный регистр. `untitle "Hello World"` возвращает `hello world`. ### repeat Повторяет строку несколько раз: ``` repeat 3 "hello" ``` Результат: `hellohellohello` ### substr Получает подстроку из строки. Принимает три параметра: - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` Результат: `hello` ### nospace Удаляет все пробельные символы из строки. ``` nospace "hello w o r l d" ``` Результат: `helloworld` ### trunc Обрезает строку ``` trunc 5 "hello world" ``` Результат: `hello`. ``` trunc -5 "hello world" ``` Выше возвращается `world`. ### abbrev Обрезает строку с многоточием (`...`) Параметры: - максимальная длина - строка ``` abbrev 5 "hello world" ``` Выше возвращается `he...`, так как ширина многоточия учитывается в максимальной длине. ### abbrevboth Сокращает с обеих сторон: ``` abbrevboth 5 10 "1234 5678 9123" ``` Выше возвращается `...5678...` Принимает: - смещение слева - максимальную длину - строку ### initials При наличии нескольких слов берёт первую букву каждого слова и объединяет. ``` initials "First Try" ``` Результат: `FT` ### randAlphaNum, randAlpha, randNumeric и randAscii Эти четыре функции генерируют криптографически безопасные (используют ```crypto/rand```) случайные строки с разными базовыми наборами символов: - `randAlphaNum` использует `0-9a-zA-Z` - `randAlpha` использует `a-zA-Z` - `randNumeric` использует `0-9` - `randAscii` использует все печатные ASCII-символы Каждая из них принимает один параметр: целочисленную длину строки. ``` randNumeric 3 ``` Выше возвращается случайная строка из трёх цифр. ### wrap Переносит текст на заданное количество столбцов: ``` wrap 80 $someText ``` Выше переносит строку в `$someText` на 80 столбцах. ### wrapWith `wrapWith` работает как `wrap`, но позволяет указать строку для переноса. (`wrap` использует `\n`) ``` wrapWith 5 "\t" "Hello World" ``` Результат: `Hello World` (где пробельный символ — это ASCII-символ табуляции) ### contains Проверяет, содержится ли одна строка внутри другой: ``` contains "cat" "catch" ``` Результат: `true`, потому что `catch` содержит `cat`. ### hasPrefix и hasSuffix Функции `hasPrefix` и `hasSuffix` проверяют, имеет ли строка заданный префикс или суффикс: ``` hasPrefix "cat" "catch" ``` Результат: `true`, потому что `catch` имеет префикс `cat`. ### quote и squote Эти функции оборачивают строку в двойные кавычки (`quote`) или одинарные кавычки (`squote`). ### cat Функция `cat` объединяет несколько строк в одну, разделяя их пробелами: ``` cat "hello" "beautiful" "world" ``` Результат: `hello beautiful world` ### indent Функция `indent` добавляет отступ к каждой строке заданной строки на указанную ширину отступа. Это полезно при выравнивании многострочных строк: ``` indent 4 $lots_of_text ``` Выше добавляет отступ в 4 пробела к каждой строке текста. ### nindent Функция `nindent` аналогична функции indent, но добавляет новую строку в начало. ``` nindent 4 $lots_of_text ``` Выше добавляет отступ в 4 пробела к каждой строке текста и добавляет новую строку в начало. ### replace Выполняет простую замену строки. Принимает три аргумента: - строку для замены - строку для замены ею - исходную строку ``` "I Am Henry VIII" | replace " " "-" ``` Результат: `I-Am-Henry-VIII` ### plural Склоняет строку. ``` len $fish | plural "one anchovy" "many anchovies" ``` Выше, если длина строки равна 1, будет выведен первый аргумент (`one anchovy`). В противном случае будет выведен второй аргумент (`many anchovies`). Аргументы: - строка единственного числа - строка множественного числа - целое число длины ПРИМЕЧАНИЕ: Helm в настоящее время не поддерживает языки с более сложными правилами склонения. И `0` считается множественным числом, потому что английский язык обрабатывает его таким образом (`zero anchovies`). ### snakecase Преобразует строку из camelCase в snake_case. ``` snakecase "FirstName" ``` Результат: `first_name`. ### camelcase Преобразует строку из snake_case в CamelCase ``` camelcase "http_server" ``` Результат: `HttpServer`. ### kebabcase Преобразует строку из camelCase в kebab-case. ``` kebabcase "FirstName" ``` Результат: `first-name`. ### swapcase Меняет регистр строки с использованием алгоритма на основе слов. Алгоритм преобразования: - Символ верхнего регистра преобразуется в нижний регистр - Символ титульного регистра преобразуется в нижний регистр - Символ нижнего регистра после пробела или в начале преобразуется в титульный регистр - Другие символы нижнего регистра преобразуются в верхний регистр - Пробел определяется функцией unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` Результат: `tHIS iS a.tEST`. ### shuffle Перемешивает строку. ``` shuffle "hello" ``` Выше перемешает буквы в `hello`, возможно возвращая `oelhl`. ## Функции преобразования типов Helm предоставляет следующие функции преобразования типов: - `atoi`: Преобразует строку в целое число. - `float64`: Преобразует в `float64`. - `int`: Преобразует в `int` системной разрядности. - `int64`: Преобразует в `int64`. - `toDecimal`: Преобразует восьмеричное число unix в `int64`. - `toString`: Преобразует в строку. - `toStrings`: Преобразует список, срез или массив в список строк. - `toJson` (`mustToJson`): Преобразует список, срез, массив, словарь или объект в JSON. - `toPrettyJson` (`mustToPrettyJson`): Преобразует список, срез, массив, словарь или объект в форматированный JSON с отступами. - `toRawJson` (`mustToRawJson`): Преобразует список, срез, массив, словарь или объект в JSON с неэкранированными HTML-символами. - `fromYaml`: Преобразует YAML-строку в объект. - `fromJson`: Преобразует JSON-строку в объект. - `fromJsonArray`: Преобразует JSON-массив в список. - `toYaml`: Преобразует список, срез, массив, словарь или объект в форматированный yaml, может использоваться для копирования фрагментов yaml из любого источника. Эта функция эквивалентна функции GoLang yaml.Marshal, см. документацию: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Преобразует список, срез, массив, словарь или объект в форматированный yaml. Эквивалентно `toYaml`, но дополнительно добавляет отступ в 2 пробела для списков. - `toToml`: Преобразует список, срез, массив, словарь или объект в toml, может использоваться для копирования фрагментов toml из любого источника. - `fromYamlArray`: Преобразует YAML-массив в список. Только `atoi` требует, чтобы входные данные были определённого типа. Остальные попытаются преобразовать любой тип в целевой. Например, `int64` может преобразовывать числа с плавающей точкой в целые числа, а также строки в целые числа. ### toStrings При наличии коллекции, похожей на список, возвращает срез строк. ``` list 1 2 3 | toStrings ``` Выше преобразует `1` в `"1"`, `2` в `"2"` и так далее, а затем возвращает их как список. ### toDecimal При наличии восьмеричного разрешения unix возвращает десятичное число. ``` "0777" | toDecimal ``` Выше преобразует `0777` в `511` и возвращает значение как int64. ### toJson, mustToJson Функция `toJson` кодирует элемент в JSON-строку. Если элемент не может быть преобразован в JSON, функция вернёт пустую строку. `mustToJson` вернёт ошибку, если элемент не может быть закодирован в JSON. ``` toJson .Item ``` Выше возвращается строковое представление `.Item` в формате JSON. ### toPrettyJson, mustToPrettyJson Функция `toPrettyJson` кодирует элемент в форматированную (с отступами) JSON-строку. ``` toPrettyJson .Item ``` Выше возвращается форматированное строковое представление `.Item` в формате JSON. ### toRawJson, mustToRawJson Функция `toRawJson` кодирует элемент в JSON-строку с неэкранированными HTML-символами. ``` toRawJson .Item ``` Выше возвращается неэкранированное строковое представление `.Item` в формате JSON. ### fromYaml Функция `fromYaml` принимает YAML-строку и возвращает объект, который можно использовать в шаблонах. `Файл: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson Функция `fromJson` принимает JSON-строку и возвращает объект, который можно использовать в шаблонах. `Файл: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray Функция `fromJsonArray` принимает JSON-массив и возвращает список, который можно использовать в шаблонах. `Файл: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty Функции `toYaml` и `toYamlPretty` кодируют объект (список, срез, массив, словарь или объект) в форматированную YAML-строку. > Обратите внимание, что `toYamlPretty` функционально эквивалентна, но выводит > YAML с дополнительными отступами для элементов списка ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray Функция `fromYamlArray` принимает YAML-массив и возвращает список, который можно использовать в шаблонах. `Файл: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Регулярные выражения Helm включает следующие функции регулярных выражений: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Возвращает true, если входная строка содержит любое совпадение с регулярным выражением. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` Результат: `true` `regexMatch` вызывает панику при возникновении проблемы, а `mustRegexMatch` возвращает ошибку в движок шаблонов при возникновении проблемы. ### regexFindAll, mustRegexFindAll Возвращает срез всех совпадений регулярного выражения во входной строке. Последний параметр n определяет количество возвращаемых подстрок, где -1 означает возврат всех совпадений. ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` Выше возвращается `[2 4 6 8]` `regexFindAll` вызывает панику при возникновении проблемы, а `mustRegexFindAll` возвращает ошибку в движок шаблонов при возникновении проблемы. ### regexFind, mustRegexFind Возвращает первое (самое левое) совпадение регулярного выражения во входной строке. ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` Выше возвращается `d1` `regexFind` вызывает панику при возникновении проблемы, а `mustRegexFind` возвращает ошибку в движок шаблонов при возникновении проблемы. ### regexReplaceAll, mustRegexReplaceAll Возвращает копию входной строки, заменяя совпадения с регулярным выражением строкой замены. Внутри строки замены знаки $ интерпретируются как в Expand, поэтому, например, $1 представляет текст первого подсовпадения. Первый аргумент — ``, второй — ``, третий — ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` Выше возвращается `-W-xxW-` `regexReplaceAll` вызывает панику при возникновении проблемы, а `mustRegexReplaceAll` возвращает ошибку в движок шаблонов при возникновении проблемы. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Возвращает копию входной строки, заменяя совпадения с регулярным выражением строкой замены. Строка замены подставляется напрямую, без использования Expand. Первый аргумент — ``, второй — ``, третий — ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` Выше возвращается `-${1}-${1}-` `regexReplaceAllLiteral` вызывает панику при возникновении проблемы, а `mustRegexReplaceAllLiteral` возвращает ошибку в движок шаблонов при возникновении проблемы. ### regexSplit, mustRegexSplit Разбивает входную строку на подстроки, разделённые выражением, и возвращает срез подстрок между совпадениями выражения. Последний параметр `n` определяет количество возвращаемых подстрок, где `-1` означает возврат всех совпадений. ``` regexSplit "z+" "pizza" -1 ``` Выше возвращается `[pi a]` `regexSplit` вызывает панику при возникновении проблемы, а `mustRegexSplit` возвращает ошибку в движок шаблонов при возникновении проблемы. ## Криптографические функции и функции безопасности Helm предоставляет несколько продвинутых криптографических функций, включая [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) и [sha256sum](#sha256sum). ### sha1sum Функция `sha1sum` получает строку и вычисляет её дайджест SHA1. ``` sha1sum "Hello world!" ``` ### sha256sum Функция `sha256sum` получает строку и вычисляет её дайджест SHA256. ``` sha256sum "Hello world!" ``` Выше вычисляется SHA 256 сумма в «ASCII armored» формате, который безопасен для вывода. ### adler32sum Функция `adler32sum` получает строку и вычисляет её контрольную сумму Adler-32. ``` adler32sum "Hello world!" ``` ### htpasswd Функция `htpasswd` принимает `username` и `password` и генерирует `bcrypt`-хэш пароля. Результат можно использовать для базовой аутентификации на [сервере Apache HTTP](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Обратите внимание, что хранение пароля непосредственно в шаблоне небезопасно. ### randBytes Функция randBytes принимает число N и генерирует криптографически безопасную (использует crypto/rand) случайную последовательность из N байт. Последовательность возвращается как строка в кодировке base64. ``` randBytes 24 ``` ### derivePassword Функция `derivePassword` может использоваться для получения конкретного пароля на основе некоторого общего «мастер-пароля» с ограничениями. Алгоритм для этого [хорошо описан](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Обратите внимание, что хранение частей непосредственно в шаблоне считается небезопасным. ### genPrivateKey Функция `genPrivateKey` генерирует новый закрытый ключ, закодированный в блок PEM. Принимает одно из значений в качестве первого параметра: - `ecdsa`: Генерирует ключ эллиптической кривой DSA (P256) - `dsa`: Генерирует ключ DSA (L2048N256) - `rsa`: Генерирует ключ RSA 4096 ### buildCustomCert Функция `buildCustomCert` позволяет настроить сертификат. Принимает следующие строковые параметры: - Сертификат в формате PEM, закодированный в base64 - Закрытый ключ в формате PEM, закодированный в base64 Возвращает объект сертификата со следующими атрибутами: - `Cert`: Сертификат в кодировке PEM - `Key`: Закрытый ключ в кодировке PEM Пример: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Обратите внимание, что возвращённый объект можно передать в функцию `genSignedCert` для подписания сертификата этим CA. ### genCA Функция `genCA` генерирует новый самоподписанный центр сертификации x509. Принимает следующие параметры: - Common name субъекта (cn) - Срок действия сертификата в днях Возвращает объект со следующими атрибутами: - `Cert`: Сертификат в кодировке PEM - `Key`: Закрытый ключ в кодировке PEM Пример: ``` $ca := genCA "foo-ca" 365 ``` Обратите внимание, что возвращённый объект можно передать в функцию `genSignedCert` для подписания сертификата этим CA. ### genSelfSignedCert Функция `genSelfSignedCert` генерирует новый самоподписанный сертификат x509. Принимает следующие параметры: - Common name субъекта (cn) - Необязательный список IP-адресов; может быть nil - Необязательный список альтернативных DNS-имён; может быть nil - Срок действия сертификата в днях Возвращает объект со следующими атрибутами: - `Cert`: Сертификат в кодировке PEM - `Key`: Закрытый ключ в кодировке PEM Пример: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert Функция `genSignedCert` генерирует новый сертификат x509, подписанный указанным CA. Принимает следующие параметры: - Common name субъекта (cn) - Необязательный список IP-адресов; может быть nil - Необязательный список альтернативных DNS-имён; может быть nil - Срок действия сертификата в днях - CA (см. `genCA`) Пример: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES Функция `encryptAES` шифрует текст с помощью AES-256 CBC и возвращает строку в кодировке base64. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES Функция `decryptAES` получает строку base64, закодированную алгоритмом AES-256 CBC, и возвращает расшифрованный текст. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Функции даты Helm включает следующие функции даты, которые вы можете использовать в шаблонах: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) и [unixEpoch](#unixepoch). ### now Текущая дата/время. Используйте это в сочетании с другими функциями даты. ### ago Функция `ago` возвращает продолжительность от текущего времени с разрешением в секундах. ``` ago .CreatedAt ``` возвращает в формате `time.Duration` String() ``` 2h34m7s ``` ### date Функция `date` форматирует дату. Форматирует дату в формате ГОД-МЕСЯЦ-ДЕНЬ: ``` now | date "2006-01-02" ``` Форматирование даты в Go [немного отличается](https://pauladamsmith.com/blog/2011/05/go_time.html). Вкратце, возьмите это как базовую дату: ``` Mon Jan 2 15:04:05 MST 2006 ``` Запишите её в нужном формате. Выше `2006-01-02` — это та же дата, но в нужном нам формате. ### dateInZone То же, что и `date`, но с часовым поясом. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Форматирует заданное количество секунд как `time.Duration`. Результат: 1m35s ``` duration "95" ``` ### durationRound Округляет заданную продолжительность до наиболее значимой единицы. Строки и `time.Duration` парсятся как продолжительность, а `time.Time` вычисляется как продолжительность с того момента. Результат: 2h ``` durationRound "2h10m5s" ``` Результат: 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Возвращает количество секунд с начала эпохи unix для `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify `dateModify` принимает модификацию и дату и возвращает метку времени. Вычесть час и тридцать минут из текущего времени: ``` now | dateModify "-1.5h" ``` Если формат модификации неверен, `dateModify` вернёт дату без изменений. `mustDateModify` вернёт ошибку в противном случае. ### htmlDate Функция `htmlDate` форматирует дату для вставки в поле ввода выбора даты HTML. ``` now | htmlDate ``` ### htmlDateInZone То же, что и htmlDate, но с часовым поясом. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` преобразует строку в дату. Первый аргумент — это формат даты, второй — строка даты. Если строка не может быть преобразована, возвращается нулевое значение. `mustToDate` вернёт ошибку, если строка не может быть преобразована. Это полезно, когда вы хотите преобразовать строковую дату в другой формат (используя конвейер). Пример ниже преобразует "2017-12-31" в "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Словари и функции Dict Helm предоставляет тип хранения ключ/значение, называемый `dict` (сокращение от «dictionary», как в Python). `dict` — это _неупорядоченный_ тип. Ключом словаря **должна быть строка**. Однако значением может быть любой тип, даже другой `dict` или `list`. В отличие от `list`, `dict` не является неизменяемым. Функции `set` и `unset` будут изменять содержимое словаря. Helm предоставляет следующие функции для работы со словарями: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) и [values](#values). ### dict Создание словарей выполняется вызовом функции `dict` с передачей списка пар. Следующее создаёт словарь с тремя элементами: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get При наличии map и ключа получает значение из map. ``` get $myDict "name1" ``` Вернёт `"value1"` Обратите внимание, что если ключ не найден, операция просто вернёт `""`. Ошибка не будет сгенерирована. ### set Используйте `set` для добавления новой пары ключ/значение в словарь. ``` $_ := set $myDict "name4" "value4" ``` Обратите внимание, что `set` _возвращает словарь_ (требование функций шаблонов Go), поэтому вам может потребоваться перехватить значение, как показано выше с присваиванием `$_`. ### unset При наличии map и ключа удаляет ключ из map. ``` $_ := unset $myDict "name4" ``` Как и `set`, это возвращает словарь. Обратите внимание, что если ключ не найден, операция просто вернётся. Ошибка не будет сгенерирована. ### hasKey Функция `hasKey` возвращает `true`, если данный словарь содержит данный ключ. ``` hasKey $myDict "name1" ``` Если ключ не найден, возвращается `false`. ### pluck Функция `pluck` позволяет задать один ключ и несколько map и получить список всех совпадений: ``` pluck "name1" $myDict $myOtherDict ``` Выше вернётся `list`, содержащий каждое найденное значение (`[value1 otherValue1]`). Если данный ключ _не найден_ в map, этот map не будет иметь элемента в списке (и длина возвращённого списка будет меньше количества словарей в вызове `pluck`). Если ключ _найден_, но значение является пустым, это значение будет вставлено. Распространённая идиома в шаблонах Helm — использовать `pluck... | first` для получения первого совпадающего ключа из коллекции словарей. ### dig Функция `dig` проходит по вложенному набору словарей, выбирая ключи из списка значений. Возвращает значение по умолчанию, если какой-либо из ключей не найден в соответствующем словаре. ``` dig "user" "role" "humanName" "guest" $dict ``` При наличии словаря со структурой ``` { user: { role: { humanName: "curator" } } } ``` выше вернётся `"curator"`. Если в словаре отсутствует даже поле `user`, результатом будет `"guest"`. Dig может быть очень полезен в случаях, когда вы хотите избежать защитных условий, особенно учитывая, что `and` в пакете шаблонов Go не использует короткое замыкание. Например, `and a.maybeNil a.maybeNil.iNeedThis` всегда будет вычислять `a.maybeNil.iNeedThis` и вызовет панику, если у `a` отсутствует поле `maybeNil`.) `dig` принимает аргумент словаря последним для поддержки конвейеров. Например: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Объединяет два или более словарей в один, отдавая приоритет целевому словарю: При наличии: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом будет: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` Это операция глубокого объединения, но не глубокого копирования. Вложенные объекты, которые объединяются, являются одним и тем же экземпляром в обоих словарях. Если вы хотите глубокое копирование вместе с объединением, используйте функцию `deepCopy` вместе с объединением. Например, ``` deepCopy $source | merge $dest ``` `mustMerge` вернёт ошибку в случае неудачного объединения. ### mergeOverwrite, mustMergeOverwrite Объединяет два или более словарей в один, отдавая приоритет **справа налево**, фактически перезаписывая значения в целевом словаре: При наличии: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом будет: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` Это операция глубокого объединения, но не глубокого копирования. Вложенные объекты, которые объединяются, являются одним и тем же экземпляром в обоих словарях. Если вы хотите глубокое копирование вместе с объединением, используйте функцию `deepCopy` вместе с объединением. Например, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` вернёт ошибку в случае неудачного объединения. ### keys Функция `keys` вернёт `list` всех ключей в одном или нескольких типах `dict`. Поскольку словарь _неупорядочен_, ключи не будут в предсказуемом порядке. Их можно отсортировать с помощью `sortAlpha`. ``` keys $myDict | sortAlpha ``` При передаче нескольких словарей ключи будут объединены. Используйте функцию `uniq` вместе с `sortAlpha` для получения уникального отсортированного списка ключей. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick Функция `pick` выбирает только указанные ключи из словаря, создавая новый `dict`. ``` $new := pick $myDict "name1" "name2" ``` Выше возвращается `{name1: value1, name2: value2}` ### omit Функция `omit` похожа на `pick`, но возвращает новый `dict` со всеми ключами, которые _не соответствуют_ указанным ключам. ``` $new := omit $myDict "name1" "name3" ``` Выше возвращается `{name2: value2}` ### values Функция `values` похожа на `keys`, но возвращает новый `list` со всеми значениями исходного `dict` (поддерживается только один словарь). ``` $vals := values $myDict ``` Выше возвращается `list["value1", "value2", "value 3"]`. Обратите внимание, что функция `values` не гарантирует порядок результата; если это важно, используйте `sortAlpha`. ### deepCopy, mustDeepCopy Функции `deepCopy` и `mustDeepCopy` принимают значение и делают его глубокую копию. Это включает словари и другие структуры. `deepCopy` вызывает панику при возникновении проблемы, а `mustDeepCopy` возвращает ошибку в систему шаблонов при возникновении ошибки. ``` dict "a" 1 "b" 2 | deepCopy ``` ### Примечание о внутренней реализации Dict `dict` реализован в Go как `map[string]interface{}`. Разработчики Go могут передавать значения `map[string]interface{}` в контекст, чтобы сделать их доступными для шаблонов как `dict`. ## Функции кодирования Helm имеет следующие функции кодирования и декодирования: - `b64enc`/`b64dec`: Кодирование или декодирование с помощью Base64 - `b32enc`/`b32dec`: Кодирование или декодирование с помощью Base32 ## Списки и функции List Helm предоставляет простой тип `list`, который может содержать произвольные последовательные списки данных. Это похоже на массивы или срезы, но списки разработаны для использования как неизменяемые типы данных. Создание списка целых чисел: ``` $myList := list 1 2 3 4 5 ``` Выше создаётся список `[1 2 3 4 5]`. Helm предоставляет следующие функции списков: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) и [without (mustWithout)](#without-mustwithout). ### first, mustFirst Чтобы получить первый элемент списка, используйте `first`. `first $myList` возвращает `1` `first` вызывает панику при возникновении проблемы, а `mustFirst` возвращает ошибку в движок шаблонов при возникновении проблемы. ### rest, mustRest Чтобы получить хвост списка (всё, кроме первого элемента), используйте `rest`. `rest $myList` возвращает `[2 3 4 5]` `rest` вызывает панику при возникновении проблемы, а `mustRest` возвращает ошибку в движок шаблонов при возникновении проблемы. ### last, mustLast Чтобы получить последний элемент списка, используйте `last`: `last $myList` возвращает `5`. Это примерно аналогично обращению списка и последующему вызову `first`. ### initial, mustInitial Это дополняет `last`, возвращая всё, _кроме_ последнего элемента. `initial $myList` возвращает `[1 2 3 4]`. `initial` вызывает панику при возникновении проблемы, а `mustInitial` возвращает ошибку в движок шаблонов при возникновении проблемы. ### append, mustAppend Добавляет новый элемент в существующий список, создавая новый список. ``` $new = append $myList 6 ``` Выше установит `$new` в `[1 2 3 4 5 6]`. `$myList` останется неизменным. `append` вызывает панику при возникновении проблемы, а `mustAppend` возвращает ошибку в движок шаблонов при возникновении проблемы. ### prepend, mustPrepend Добавляет элемент в начало списка, создавая новый список. ``` prepend $myList 0 ``` Выше вернёт `[0 1 2 3 4 5]`. `$myList` останется неизменным. `prepend` вызывает панику при возникновении проблемы, а `mustPrepend` возвращает ошибку в движок шаблонов при возникновении проблемы. ### concat Объединяет произвольное количество списков в один. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` Выше вернёт `[1 2 3 4 5 6 7 8]`. `$myList` останется неизменным. ### reverse, mustReverse Создаёт новый список с обратным порядком элементов данного списка. ``` reverse $myList ``` Выше сгенерирует список `[5 4 3 2 1]`. `reverse` вызывает панику при возникновении проблемы, а `mustReverse` возвращает ошибку в движок шаблонов при возникновении проблемы. ### uniq, mustUniq Генерирует список с удалением всех дубликатов. ``` list 1 1 1 2 | uniq ``` Выше вернёт `[1 2]` `uniq` вызывает панику при возникновении проблемы, а `mustUniq` возвращает ошибку в движок шаблонов при возникновении проблемы. ### without, mustWithout Функция `without` отфильтровывает элементы из списка. ``` without $myList 3 ``` Выше вернёт `[1 2 4 5]` `without` может принимать более одного фильтра: ``` without $myList 1 3 5 ``` Это вернёт `[2 4]` `without` вызывает панику при возникновении проблемы, а `mustWithout` возвращает ошибку в движок шаблонов при возникновении проблемы. ### has, mustHas Проверяет, содержит ли список определённый элемент. ``` has 4 $myList ``` Выше вернёт `true`, тогда как `has "hello" $myList` вернёт false. `has` вызывает панику при возникновении проблемы, а `mustHas` возвращает ошибку в движок шаблонов при возникновении проблемы. ### compact, mustCompact Принимает список и удаляет записи с пустыми значениями. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` вернёт новый список с удалённым пустым (т.е. "") элементом. `compact` вызывает панику при возникновении проблемы, а `mustCompact` возвращает ошибку в движок шаблонов при возникновении проблемы. ### index Чтобы получить n-й элемент списка, используйте `index list [n]`. Для индексации многомерных списков используйте `index list [n] [m] ...` - `index $myList 0` возвращает `1`. Это то же самое, что `myList[0]` - `index $myList 0 1` было бы эквивалентно `myList[0][1]` ### slice, mustSlice Чтобы получить частичные элементы списка, используйте `slice list [n] [m]`. Это эквивалентно `list[n:m]`. - `slice $myList` возвращает `[1 2 3 4 5]`. Это то же самое, что `myList[:]`. - `slice $myList 3` возвращает `[4 5]`. Это то же самое, что `myList[3:]`. - `slice $myList 1 3` возвращает `[2 3]`. Это то же самое, что `myList[1:3]`. - `slice $myList 0 3` возвращает `[1 2 3]`. Это то же самое, что `myList[:3]`. `slice` вызывает панику при возникновении проблемы, а `mustSlice` возвращает ошибку в движок шаблонов при возникновении проблемы. ### until Функция `until` создаёт диапазон целых чисел. ``` until 5 ``` Выше генерируется список `[0, 1, 2, 3, 4]`. Это полезно для циклов с `range $i, $e := until 5`. ### untilStep Как и `until`, `untilStep` генерирует список счётных целых чисел. Но позволяет определить начало, конец и шаг: ``` untilStep 3 6 2 ``` Выше вернёт `[3 5]`, начиная с 3 и прибавляя 2, пока значение не станет равным или больше 6. Это похоже на функцию `range` в Python. ### seq Работает как команда bash `seq`. * 1 параметр (end) - сгенерирует все счётные целые числа от 1 до `end` включительно. * 2 параметра (start, end) - сгенерирует все счётные целые числа от `start` до `end` включительно с шагом 1 или -1. * 3 параметра (start, step, end) - сгенерирует все счётные целые числа от `start` до `end` включительно с указанным `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Чтобы разбить список на части заданного размера, используйте `chunk size list`. Это полезно для пагинации. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` Это создаёт список списков `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Математические функции Все математические функции работают со значениями `int64`, если не указано иное. Доступны следующие математические функции: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) и [sub](#sub). ### add Суммирует числа с помощью `add`. Принимает два или более входных значения. ``` add 1 2 3 ``` ### add1 Чтобы увеличить на 1, используйте `add1`. ### sub Для вычитания используйте `sub`. ### div Выполняет целочисленное деление с помощью `div`. ### mod Остаток от деления с помощью `mod`. ### mul Умножает с помощью `mul`. Принимает два или более входных значения. ``` mul 1 2 3 ``` ### max Возвращает наибольшее из серии целых чисел. Это вернёт `3`: ``` max 1 2 3 ``` ### min Возвращает наименьшее из серии целых чисел. `min 1 2 3` вернёт `1`. ### len Возвращает длину аргумента как целое число. ``` len .Arg ``` ## Математические функции с плавающей точкой Все математические функции работают со значениями `float64`. ### addf Суммирует числа с помощью `addf` Это вернёт `5.5`: ``` addf 1.5 2 2 ``` ### add1f Чтобы увеличить на 1, используйте `add1f` ### subf Для вычитания используйте `subf` Это эквивалентно `7.5 - 2 - 3` и вернёт `2.5`: ``` subf 7.5 2 3 ``` ### divf Выполняет деление с плавающей точкой с помощью `divf` Это эквивалентно `10 / 2 / 4` и вернёт `1.25`: ``` divf 10 2 4 ``` ### mulf Умножает с помощью `mulf` Это вернёт `6`: ``` mulf 1.5 2 2 ``` ### maxf Возвращает наибольшее из серии чисел с плавающей точкой: Это вернёт `3`: ``` maxf 1 2.5 3 ``` ### minf Возвращает наименьшее из серии чисел с плавающей точкой. Это вернёт `1.5`: ``` minf 1.5 2 3 ``` ### floor Возвращает наибольшее значение с плавающей точкой, меньшее или равное входному значению. `floor 123.9999` вернёт `123.0`. ### ceil Возвращает наименьшее значение с плавающей точкой, большее или равное входному значению. `ceil 123.001` вернёт `124.0`. ### round Возвращает значение с плавающей точкой с остатком, округлённым до указанного количества цифр после десятичной точки. `round 123.555555 3` вернёт `123.556`. ## Сетевые функции Helm имеет одну сетевую функцию, `getHostByName`. `getHostByName` получает доменное имя и возвращает IP-адрес. `getHostByName "www.google.com"` вернёт соответствующий IP-адрес `www.google.com`. Эта функция требует передачи опции `--enable-dns` в командной строке helm. ## Функции путей файлов Хотя функции шаблонов Helm не предоставляют доступа к файловой системе, они предоставляют функции для работы со строками, которые следуют соглашениям о путях файлов. К ним относятся [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) и [isAbs](#isabs). ### base Возвращает последний элемент пути. ``` base "foo/bar/baz" ``` Выше выводится "baz". ### dir Возвращает директорию, удаляя последнюю часть пути. Так `dir "foo/bar/baz"` возвращает `foo/bar`. ### clean Очищает путь. ``` clean "foo/bar/../baz" ``` Выше разрешается `..` и возвращается `foo/baz`. ### ext Возвращает расширение файла. ``` ext "foo.bar" ``` Выше возвращается `.bar`. ### isAbs Чтобы проверить, является ли путь файла абсолютным, используйте `isAbs`. ## Функции рефлексии Helm предоставляет базовые инструменты рефлексии. Они помогают продвинутым разработчикам шаблонов понять информацию о базовом типе Go для конкретного значения. Helm написан на Go и является строго типизированным. Система типов применяется внутри шаблонов. Go имеет несколько примитивных _видов_ (kinds), таких как `string`, `slice`, `int64` и `bool`. Go имеет открытую _систему типов_, которая позволяет разработчикам создавать собственные типы. Helm предоставляет набор функций для каждого через [функции kind](#функции-kind) и [функции type](#функции-type). Также предоставляется функция [deepEqual](#deepequal) для сравнения двух значений. ### Функции Kind Существует две функции Kind: `kindOf` возвращает вид объекта. ``` kindOf "hello" ``` Выше вернёт `string`. Для простых тестов (например, в блоках `if`) функция `kindIs` позволит вам проверить, что значение является определённым видом: ``` kindIs "int" 123 ``` Выше вернёт `true`. ### Функции Type С типами немного сложнее работать, поэтому существует три разные функции: - `typeOf` возвращает базовый тип значения: `typeOf $foo` - `typeIs` похож на `kindIs`, но для типов: `typeIs "*io.Buffer" $myVal` - `typeIsLike` работает как `typeIs`, но также разыменовывает указатели **Примечание:** Ни одна из этих функций не может проверить, реализует ли что-то данный интерфейс, так как для этого потребовалось бы скомпилировать интерфейс заранее. ### deepEqual `deepEqual` возвращает true, если два значения ["глубоко равны"](https://golang.org/pkg/reflect/#DeepEqual) Работает и для непримитивных типов (в отличие от встроенного `eq`). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` Выше вернёт `true`. ## Функции семантических версий Некоторые схемы версионирования легко парсятся и сравниваются. Helm предоставляет функции для работы с версиями [SemVer 2](http://semver.org). К ним относятся [semver](#semver) и [semverCompare](#semvercompare). Ниже вы также найдёте подробности об использовании диапазонов для сравнений. ### semver Функция `semver` парсит строку в семантическую версию: ``` $version := semver "1.2.3-alpha.1+123" ``` _Если парсер завершится с ошибкой, это приведёт к остановке выполнения шаблона с ошибкой._ На этом этапе `$version` является указателем на объект `Version` со следующими свойствами: - `$version.Major`: Мажорный номер (`1` выше) - `$version.Minor`: Минорный номер (`2` выше) - `$version.Patch`: Номер патча (`3` выше) - `$version.Prerelease`: Пререлиз (`alpha.1` выше) - `$version.Metadata`: Метаданные сборки (`123` выше) - `$version.Original`: Оригинальная версия как строка Кроме того, вы можете сравнить `Version` с другой `version`, используя функцию `Compare`: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` Выше вернёт `-1`. Возвращаемые значения: - `-1` если данный semver больше, чем semver, метод `Compare` которого был вызван - `1` если версия, чья функция `Compare` была вызвана, больше - `0` если это одна и та же версия (Обратите внимание, что в SemVer поле `Metadata` не сравнивается при операциях сравнения версий.) ### semverCompare Более надёжная функция сравнения предоставляется как `semverCompare`. Эта версия поддерживает диапазоны версий: - `semverCompare "1.2.3" "1.2.3"` проверяет на точное совпадение - `semverCompare "~1.2.0" "1.2.3"` проверяет, что мажорная и минорная версии совпадают, и что номер патча второго параметра _больше или равен_ первому параметру. Функции SemVer используют [библиотеку semver от Masterminds](https://github.com/Masterminds/semver), от создателей Sprig. ### Базовые сравнения В сравнениях есть два элемента. Во-первых, строка сравнения — это список сравнений И, разделённых пробелами или запятыми. Затем они разделяются || (ИЛИ). Например, `">= 1.2 < 3.0.0 || >= 4.2.3"` ищет сравнение, которое больше или равно 1.2 и меньше 3.0.0 или больше или равно 4.2.3. Базовые сравнения: - `=`: равно (синоним отсутствия оператора) - `!=`: не равно - `>`: больше чем - `<`: меньше чем - `>=`: больше или равно - `<=`: меньше или равно ### Работа с пререлизными версиями Пререлизы, для тех, кто не знаком с ними, используются для релизов программного обеспечения до стабильного или общедоступного релиза. Примерами пререлизов являются релизы development, alpha, beta и release candidate. Пререлиз может быть версией, такой как `1.2.3-beta.1`, тогда как стабильный релиз будет `1.2.3`. В порядке приоритета пререлизы идут перед связанными с ними релизами. В этом примере `1.2.3-beta.1 < 1.2.3`. Согласно спецификации семантического версионирования, пререлизы могут не быть API-совместимыми со своим релизным аналогом. Она гласит: > Пререлизная версия указывает, что версия нестабильна и может не > удовлетворять предполагаемым требованиям совместимости, обозначенным её > соответствующей нормальной версией. Сравнения SemVer с использованием ограничений без компаратора пререлиза будут пропускать пререлизные версии. Например, `>=1.2.3` пропустит пререлизы при просмотре списка релизов, тогда как `>=1.2.3-0` оценит и найдёт пререлизы. Причина `0` в качестве пререлизной версии в примере сравнения в том, что пререлизы могут содержать только ASCII буквенно-цифровые символы и дефисы (вместе с разделителями `.`), согласно спецификации. Сортировка происходит в порядке ASCII, снова согласно спецификации. Наименьший символ — `0` в порядке сортировки ASCII (см. [таблицу ASCII](http://www.asciitable.com/)) Понимание порядка сортировки ASCII важно, потому что A-Z идёт перед a-z. Это означает, что `>=1.2.3-BETA` вернёт `1.2.3-alpha`. То, что вы могли бы ожидать от чувствительности к регистру, здесь не применяется. Это связано с порядком сортировки ASCII, который указан в спецификации. ### Сравнения с диапазонами через дефис Существует несколько методов работы с диапазонами, и первый — это диапазоны через дефис. Они выглядят так: - `1.2 - 1.4.5` что эквивалентно `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` что эквивалентно `>= 2.3.4 <= 4.5` ### Подстановочные знаки в сравнениях Символы `x`, `X` и `*` могут использоваться как подстановочный знак. Это работает для всех операторов сравнения. При использовании с оператором `=` он возвращается к сравнению на уровне патча (см. тильду ниже). Например, - `1.2.x` эквивалентно `>= 1.2.0, < 1.3.0` - `>= 1.2.x` эквивалентно `>= 1.2.0` - `<= 2.x` эквивалентно `< 3` - `*` эквивалентно `>= 0.0.0` ### Сравнения с диапазоном тильды (Patch) Оператор сравнения тильда (`~`) предназначен для диапазонов на уровне патча, когда указана минорная версия, и изменений на уровне мажорной версии, когда минорный номер отсутствует. Например, - `~1.2.3` эквивалентно `>= 1.2.3, < 1.3.0` - `~1` эквивалентно `>= 1, < 2` - `~2.3` эквивалентно `>= 2.3, < 2.4` - `~1.2.x` эквивалентно `>= 1.2.0, < 1.3.0` - `~1.x` эквивалентно `>= 1, < 2` ### Сравнения с диапазоном каретки (Major) Оператор сравнения каретка (`^`) предназначен для изменений на уровне мажорной версии после выхода стабильного релиза (1.0.0). До релиза 1.0.0 минорные версии действуют как уровень стабильности API. Это полезно при сравнении версий API, так как мажорное изменение ломает API. Например, - `^1.2.3` эквивалентно `>= 1.2.3, < 2.0.0` - `^1.2.x` эквивалентно `>= 1.2.0, < 2.0.0` - `^2.3` эквивалентно `>= 2.3, < 3` - `^2.x` эквивалентно `>= 2.0.0, < 3` - `^0.2.3` эквивалентно `>=0.2.3 <0.3.0` - `^0.2` эквивалентно `>=0.2.0 <0.3.0` - `^0.0.3` эквивалентно `>=0.0.3 <0.0.4` - `^0.0` эквивалентно `>=0.0.0 <0.1.0` - `^0` эквивалентно `>=0.0.0 <1.0.0` ## URL-функции Helm включает функции [urlParse](#urlparse), [urlJoin](#urljoin) и [urlquery](#urlquery), позволяющие работать с частями URL. ### urlParse Парсит строку для URL и возвращает словарь с частями URL ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` Выше возвращается словарь, содержащий объект URL: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Это реализовано с использованием пакетов URL из стандартной библиотеки Go. Для дополнительной информации см. https://golang.org/pkg/net/url/#URL ### urlJoin Объединяет map (созданный `urlParse`) для создания строки URL ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` Выше возвращается следующая строка: ``` http://host:80/path?query#fragment ``` ### urlquery Возвращает экранированную версию переданного значения, чтобы его можно было безопасно встроить в запросную часть URL. ``` $var := urlquery "string for query" ``` ## UUID-функции Helm может генерировать универсально уникальные идентификаторы UUID v4. ``` uuidv4 ``` Выше возвращается новый UUID типа v4 (случайно сгенерированный). ## Функции Kubernetes и Chart Helm включает функции для работы с Kubernetes, включая [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#функции-files) и [lookup](#lookup). ### lookup `lookup` используется для поиска ресурса в работающем кластере. При использовании с командой `helm template` всегда возвращается пустой ответ. Вы можете найти более подробную информацию в [документации по функции lookup](./functions_and_pipelines.md#использование-функции-lookup). ### .Capabilities.APIVersions.Has Возвращает, доступна ли версия API или ресурс в кластере. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Дополнительная информация доступна в [документации по встроенным объектам](./builtin_objects.md). ### Функции Files Существует несколько функций, которые позволяют получить доступ к неспециальным файлам внутри chart. Например, для доступа к файлам конфигурации приложения. Они документированы в [Доступ к файлам внутри шаблонов](./accessing_files.md). _Примечание: документация для многих из этих функций взята из [Sprig](https://github.com/Masterminds/sprig). Sprig — это библиотека функций шаблонов, доступная для приложений Go._ ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Функции шаблонов и конвейеры description: Использование функций в шаблонах. sidebar_position: 5 --- До сих пор мы рассматривали, как размещать информацию в шаблоне. Но эта информация вставляется в шаблон без изменений. Иногда нам нужно преобразовать полученные данные, чтобы сделать их более полезными. Начнём с рекомендации: при вставке строк из объекта `.Values` в шаблон следует заключать эти строки в кавычки. Для этого можно вызвать функцию `quote` в директиве шаблона: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Функции шаблона имеют синтаксис `functionName arg1 arg2...`. В приведённом выше примере `quote .Values.favorite.drink` вызывает функцию `quote` и передаёт ей один аргумент. В Helm доступно более 60 функций. Некоторые из них определены в самом [языке шаблонов Go](https://godoc.org/text/template). Большинство остальных являются частью [библиотеки шаблонов Sprig](https://masterminds.github.io/sprig/). Мы рассмотрим многие из них по мере изучения примеров. > Хотя мы говорим о «языке шаблонов Helm» как о чём-то специфичном для Helm, на > самом деле это комбинация языка шаблонов Go, некоторых дополнительных функций > и различных обёрток для предоставления определённых объектов шаблонам. Многие > ресурсы по шаблонам Go могут быть полезны при изучении шаблонизации. ## Конвейеры Одной из мощных возможностей языка шаблонов является концепция _конвейеров_ (pipelines). Заимствуя идею из UNIX, конвейеры позволяют объединять несколько команд шаблона в цепочку для компактного выражения серии преобразований. Другими словами, конвейеры — это эффективный способ выполнить несколько операций последовательно. Давайте перепишем приведённый выше пример, используя конвейер. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` В этом примере вместо вызова `quote ARGUMENT` мы изменили порядок. Мы «отправили» аргумент в функцию с помощью конвейера (`|`): `.Values.favorite.drink | quote`. Используя конвейеры, можно объединять несколько функций в цепочку: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Изменение порядка — распространённая практика в шаблонах. Вы будете чаще > встречать `.val | quote`, чем `quote .val`. Оба варианта допустимы. При обработке этот шаблон создаст следующий результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Обратите внимание, что исходное значение `pizza` теперь преобразовано в `"PIZZA"`. При передаче аргументов через конвейер результат первого вычисления (`.Values.favorite.drink`) передаётся как _последний аргумент функции_. Мы можем модифицировать пример с напитком, чтобы проиллюстрировать это с помощью функции, принимающей два аргумента: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` Функция `repeat` повторяет заданную строку указанное количество раз, поэтому результат будет следующим: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Использование функции `default` Одна из часто используемых в шаблонах функций — это `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Эта функция позволяет указать значение по умолчанию внутри шаблона на случай, если значение не задано. Давайте используем её для модификации примера с напитком: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Если мы запустим это как обычно, получим наш `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Теперь удалим настройку любимого напитка из `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Теперь повторный запуск `helm install --dry-run --debug fair-worm ./mychart` создаст следующий YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` В реальном чарте все статические значения по умолчанию должны находиться в файле `values.yaml` и не должны дублироваться с помощью команды `default` (иначе они будут избыточными). Однако функция `default` идеально подходит для вычисляемых значений, которые нельзя объявить внутри `values.yaml`. Например: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` В некоторых случаях условная проверка с `if` может быть более подходящей, чем `default`. Мы рассмотрим их в следующем разделе. Функции шаблонов и конвейеры — это мощный способ преобразования информации и её вставки в YAML. Но иногда необходимо добавить логику шаблона, которая немного сложнее, чем просто вставка строки. В следующем разделе мы рассмотрим управляющие конструкции, предоставляемые языком шаблонов. ## Использование функции `lookup` Функция `lookup` может использоваться для _поиска_ ресурсов в работающем кластере. Синтаксис функции lookup: `lookup apiVersion, kind, namespace, name -> resource or resource list`. | параметр | тип | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Параметры `name` и `namespace` являются необязательными и могут быть переданы как пустая строка (`""`). Однако при работе с ресурсом, ограниченным пространством имён, оба параметра `name` и `namespace` должны быть указаны. Возможны следующие комбинации параметров: | Поведение | Функция lookup | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Когда `lookup` возвращает объект, он представляет собой словарь (dictionary). Этот словарь можно использовать для извлечения конкретных значений. Следующий пример вернёт аннотации объекта `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Когда `lookup` возвращает список объектов, доступ к списку можно получить через поле `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` Если объект не найден, возвращается пустое значение. Это можно использовать для проверки существования объекта. Функция `lookup` использует существующую конфигурацию подключения Helm к Kubernetes для выполнения запросов к Kubernetes. Если при взаимодействии с API-сервером возвращается ошибка (например, из-за отсутствия прав доступа к ресурсу), обработка шаблона Helm завершится с ошибкой. Имейте в виду, что Helm не должен обращаться к API-серверу Kubernetes во время операций `helm template|install|upgrade|delete|rollback --dry-run`. Чтобы протестировать `lookup` на работающем кластере, следует использовать `helm template|install|upgrade|delete|rollback --dry-run=server`, что позволит установить соединение с кластером. ## Операторы — это функции Для шаблонов операторы (`eq`, `ne`, `lt`, `gt`, `and`, `or` и т.д.) реализованы как функции. В конвейерах операции можно группировать с помощью круглых скобок (`(` и `)`). Теперь мы можем перейти от функций и конвейеров к управлению потоком выполнения с помощью условий, циклов и модификаторов области видимости. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Начало работы description: Краткое руководство по шаблонам чартов. sidebar_position: 2 --- В этом разделе руководства мы создадим чарт и добавим первый шаблон. Созданный здесь чарт будет использоваться на протяжении всего руководства. Для начала давайте кратко рассмотрим структуру чарта Helm. ## Чарты Как описано в [Руководстве по чартам](/topics/charts.md), чарты Helm имеют следующую структуру: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Директория `templates/` предназначена для файлов шаблонов. Когда Helm обрабатывает чарт, он пропускает все файлы из директории `templates/` через движок шаблонов. Затем собирает результаты обработки шаблонов и отправляет их в Kubernetes. Файл `values.yaml` также важен для шаблонов. Этот файл содержит _значения по умолчанию_ для чарта. Эти значения могут быть переопределены пользователями при выполнении команд `helm install` или `helm upgrade`. Файл `Chart.yaml` содержит описание чарта. Вы можете обращаться к нему изнутри шаблона. Директория `charts/` _может_ содержать другие чарты (которые мы называем _субчартами_). Далее в этом руководстве мы рассмотрим, как они работают при рендеринге шаблонов. ## Создание начального чарта Для этого руководства мы создадим простой чарт под названием `mychart`, а затем добавим в него несколько шаблонов. ```console $ helm create mychart Creating mychart ``` ### Краткий обзор `mychart/templates/` Если вы посмотрите в директорию `mychart/templates/`, то увидите несколько уже существующих файлов: - `NOTES.txt`: «Текст справки» для вашего чарта. Он будет показан пользователям при выполнении команды `helm install`. - `deployment.yaml`: Базовый манифест для создания [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) в Kubernetes. - `service.yaml`: Базовый манифест для создания [Service](https://kubernetes.io/docs/concepts/services-networking/service/) для вашего Deployment. - `_helpers.tpl`: Место для размещения вспомогательных шаблонов, которые можно повторно использовать в чарте. И мы собираемся... _удалить их все!_ Таким образом, мы сможем пройти руководство с нуля. На самом деле мы создадим собственные `NOTES.txt` и `_helpers.tpl` по ходу работы. ```console $ rm -rf mychart/templates/* ``` При написании production-чартов наличие базовых версий этих файлов может быть очень полезным. Поэтому в повседневной работе с чартами вы, скорее всего, не будете их удалять. ## Первый шаблон Первый шаблон, который мы создадим — это `ConfigMap`. В Kubernetes ConfigMap — это простой объект для хранения конфигурационных данных. Другие объекты, например Pod'ы, могут получать доступ к данным в ConfigMap. Поскольку ConfigMap — это базовый ресурс, он отлично подходит для начала работы. Давайте создадим файл `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **СОВЕТ:** Имена шаблонов не следуют строгим правилам именования. Однако мы рекомендуем использовать расширение `.yaml` для файлов YAML и `.tpl` для вспомогательных шаблонов. Приведённый выше YAML-файл — это минимальный ConfigMap с необходимыми полями. Поскольку этот файл находится в директории `mychart/templates/`, он будет обработан движком шаблонов. Совершенно нормально размещать обычные YAML-файлы в директории `mychart/templates/`. Когда Helm прочитает этот шаблон, он просто отправит его в Kubernetes как есть. С этим простым шаблоном у нас уже есть чарт, готовый к установке. Установить его можно так: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` С помощью Helm мы можем получить релиз и увидеть фактический шаблон, который был загружен. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` Команда `helm get manifest` принимает имя релиза (`full-coral`) и выводит все ресурсы Kubernetes, которые были загружены на сервер. Каждый файл начинается с `---` для обозначения начала YAML-документа, за которым следует автоматически сгенерированный комментарий, указывающий, какой файл шаблона создал этот YAML-документ. Далее мы видим, что YAML-данные полностью соответствуют тому, что мы написали в файле `configmap.yaml`. Теперь мы можем удалить наш релиз: `helm uninstall full-coral`. ### Добавление простого вызова шаблона Жёстко заданное значение `name:` в ресурсе обычно считается плохой практикой. Имена должны быть уникальными для каждого релиза. Поэтому мы можем сгенерировать поле name, подставив в него имя релиза. **СОВЕТ:** Поле `name:` ограничено 63 символами из-за ограничений системы DNS. По этой причине имена релизов ограничены 53 символами. Kubernetes 1.3 и более ранние версии ограничивались только 24 символами (то есть 14 символами для имени). Давайте изменим `configmap.yaml` соответствующим образом. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Главное изменение — в значении поля `name:`, которое теперь равно `{{ .Release.Name }}-configmap`. > Директива шаблона заключается в блоки `{{` и `}}`. Директива шаблона `{{ .Release.Name }}` подставляет имя релиза в шаблон. Значения, передаваемые в шаблон, можно рассматривать как _объекты с пространством имён_, где точка (`.`) разделяет каждый элемент пространства имён. Начальная точка перед `Release` означает, что мы начинаем с самого верхнего пространства имён для данной области видимости (об областях видимости мы поговорим чуть позже). Таким образом, `.Release.Name` можно прочитать как «начать с верхнего пространства имён, найти объект `Release`, затем найти внутри него объект `Name`». Объект `Release` — это один из встроенных объектов Helm, и мы рассмотрим его подробнее позже. Пока достаточно сказать, что он отображает имя релиза, которое библиотека присваивает нашему релизу. Теперь, когда мы установим наш ресурс, мы сразу увидим результат использования этой директивы шаблона: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Вы можете выполнить `helm get manifest clunky-serval`, чтобы увидеть весь сгенерированный YAML. Обратите внимание, что имя ConfigMap внутри Kubernetes теперь `clunky-serval-configmap` вместо прежнего `mychart-configmap`. На данный момент мы рассмотрели шаблоны в их самом базовом виде: YAML-файлы с директивами шаблонов, заключёнными в `{{` и `}}`. В следующей части мы подробнее изучим шаблоны. Но прежде чем двигаться дальше, есть один полезный приём, который может ускорить создание шаблонов: если вы хотите протестировать рендеринг шаблона, но не устанавливать ничего, используйте команду `helm install --debug --dry-run goodly-guppy ./mychart`. Она отрендерит шаблоны, но вместо установки чарта вернёт вам результат рендеринга, чтобы вы могли увидеть вывод: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Использование `--dry-run` упростит тестирование вашего кода, но не гарантирует, что Kubernetes примет сгенерированные шаблоны. Лучше не предполагать, что ваш чарт установится только потому, что `--dry-run` отработал успешно. В [Руководстве по шаблонам чартов](/chart_template_guide/index.mdx) мы возьмём базовый чарт, созданный здесь, и подробно изучим язык шаблонов Helm. А начнём мы со встроенных объектов. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: Файл .helmignore description: Файл `.helmignore` используется для указания файлов, которые не должны включаться в ваш чарт. sidebar_position: 12 --- Файл `.helmignore` используется для указания файлов, которые не должны включаться в ваш чарт. Если этот файл существует, команда `helm package` при упаковке вашего приложения будет игнорировать все файлы, соответствующие шаблонам, указанным в файле `.helmignore`. Это помогает избежать включения ненужных или конфиденциальных файлов и директорий в ваш чарт. Файл `.helmignore` поддерживает шаблоны glob в стиле Unix shell, относительные пути и отрицание (с префиксом !). На каждой строке допускается только один шаблон. Вот пример файла `.helmignore`: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Некоторые важные отличия от .gitignore: - Синтаксис '**' не поддерживается - Библиотека для glob-шаблонов — это Go 'filepath.Match', а не fnmatch(3) - Завершающие пробелы всегда игнорируются (способа их сохранить не предусмотрено) - Нет поддержки '\!' в качестве специальной начальной последовательности - Файл `.helmignore` не исключает сам себя по умолчанию — вам нужно явно добавить для него запись `.helmignore` **Мы будем рады вашей помощи** в улучшении этого документа. Чтобы добавить, исправить или удалить информацию, [создайте issue](https://github.com/helm/helm-www/issues) или отправьте нам pull request. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: Руководство по шаблонам чартов sidebar_position: 5 --- # Руководство разработчика шаблонов чартов Это руководство представляет введение в шаблоны чартов Helm с акцентом на язык шаблонов. Шаблоны генерируют файлы манифестов — описания ресурсов в формате YAML, которые понимает Kubernetes. Мы рассмотрим, как структурированы шаблоны, как их можно использовать, как писать шаблоны Go и как отлаживать вашу работу. Это руководство фокусируется на следующих концепциях: - Язык шаблонов Helm - Использование значений (values) - Техники работы с шаблонами Это руководство ориентировано на изучение тонкостей языка шаблонов Helm. Другие руководства предоставляют вводные материалы, примеры и лучшие практики. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Именованные шаблоны description: Как определять именованные шаблоны. sidebar_position: 9 --- Пришло время выйти за рамки одного шаблона и начать создавать новые. В этом разделе мы рассмотрим, как определять _именованные шаблоны_ в одном файле и использовать их в других местах. _Именованный шаблон_ (иногда называемый _частичным шаблоном_ или _подшаблоном_) — это просто шаблон, определённый внутри файла, которому присвоено имя. Мы рассмотрим два способа их создания и несколько способов использования. В разделе [Управление потоком выполнения](./control_structures.md) мы познакомились с тремя действиями для объявления и управления шаблонами: `define`, `template` и `block`. В этом разделе мы подробнее рассмотрим эти три действия, а также специальную функцию `include`, которая работает аналогично действию `template`. Важная деталь, которую следует помнить при именовании шаблонов: **имена шаблонов глобальны**. Если вы объявите два шаблона с одинаковым именем, будет использован тот, который загружен последним. Поскольку шаблоны субчартов компилируются вместе с шаблонами верхнего уровня, следует давать шаблонам _имена, специфичные для чарта_. Популярное соглашение об именовании — добавлять к каждому определённому шаблону префикс с именем чарта: `{{ define "mychart.labels" }}`. Использование конкретного имени чарта в качестве префикса позволяет избежать конфликтов, которые могут возникнуть из-за двух разных чартов с шаблонами одинакового имени. Это поведение также применимо к разным версиям одного чарта. Если у вас есть `mychart` версии `1.0.0`, который определяет шаблон одним способом, и `mychart` версии `2.0.0`, который изменяет существующий именованный шаблон, будет использован тот, который загружен последним. Чтобы обойти эту проблему, можно также добавить версию в имя чарта: `{{ define "mychart.v1.labels" }}` и `{{ define "mychart.v2.labels" }}`. ## Частичные шаблоны и файлы с `_` До сих пор мы использовали один файл с одним шаблоном. Но язык шаблонов Helm позволяет создавать именованные встроенные шаблоны, к которым можно обращаться по имени из других мест. Прежде чем перейти к деталям написания таких шаблонов, стоит упомянуть соглашение об именовании файлов: * Большинство файлов в `templates/` обрабатываются как содержащие манифесты Kubernetes * `NOTES.txt` является исключением * Однако файлы, имена которых начинаются с подчёркивания (`_`), считаются _не содержащими_ манифестов. Эти файлы не преобразуются в определения объектов Kubernetes, но доступны везде в других шаблонах чарта для использования. Эти файлы используются для хранения частичных шаблонов и вспомогательных функций. Когда мы впервые создали `mychart`, мы видели файл `_helpers.tpl`. Этот файл является местом по умолчанию для хранения частичных шаблонов. ## Объявление и использование шаблонов с `define` и `template` Действие `define` позволяет создать именованный шаблон внутри файла шаблона. Его синтаксис выглядит так: ```yaml {{- define "MY.NAME" }} # тело шаблона здесь {{- end }} ``` Например, мы можем определить шаблон для инкапсуляции блока меток Kubernetes: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Теперь мы можем встроить этот шаблон в наш существующий ConfigMap и включить его с помощью действия `template`: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Когда шаблонизатор читает этот файл, он сохраняет ссылку на `mychart.labels` до тех пор, пока не будет вызван `template "mychart.labels"`. Затем он отрисует этот шаблон на месте. Результат будет выглядеть так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Примечание: `define` не производит вывод, пока не будет вызван с помощью `template`, как в этом примере. По соглашению, в чартах Helm эти шаблоны помещаются в файл частичных шаблонов, обычно `_helpers.tpl`. Давайте переместим эту функцию туда: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` По соглашению, функции `define` должны иметь простой блок документации (`{{/* ... */}}`), описывающий их назначение. Хотя это определение находится в `_helpers.tpl`, к нему всё равно можно обращаться из `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Как упоминалось выше, **имена шаблонов глобальны**. В результате, если два шаблона объявлены с одинаковым именем, будет использован последний. Поскольку шаблоны субчартов компилируются вместе с шаблонами верхнего уровня, лучше давать шаблонам _имена, специфичные для чарта_. Популярное соглашение об именовании — добавлять к каждому определённому шаблону префикс с именем чарта: `{{ define "mychart.labels" }}`. ## Установка области видимости шаблона В определённом выше шаблоне мы не использовали никаких объектов — только функции. Давайте изменим наш определённый шаблон, чтобы включить имя и версию чарта: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Если мы отрисуем это, получим ошибку: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Чтобы увидеть результат рендеринга, выполните команду с `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат будет не таким, как ожидалось: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Что произошло с именем и версией? Они не были в области видимости нашего определённого шаблона. Когда именованный шаблон (созданный с помощью `define`) отрисовывается, он получает область видимости, переданную при вызове `template`. В нашем примере мы включили шаблон так: ```yaml {{- template "mychart.labels" }} ``` Область видимости не была передана, поэтому внутри шаблона мы не можем обращаться к чему-либо в `.`. Это легко исправить — просто передайте область видимости в шаблон: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Обратите внимание, что мы передаём `.` в конце вызова `template`. Мы могли бы также передать `.Values` или `.Values.favorite` или любую другую нужную область видимости. Но нам нужна область видимости верхнего уровня. В контексте именованного шаблона `$` будет ссылаться на переданную область видимости, а не на какую-то глобальную. Теперь, если мы выполним этот шаблон с `helm install --dry-run --debug plinking-anaco ./mychart`, получим: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Теперь `{{ .Chart.Name }}` преобразуется в `mychart`, а `{{ .Chart.Version }}` — в `0.1.0`. ## Функция `include` Допустим, мы определили простой шаблон, который выглядит так: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Теперь допустим, что мы хотим вставить его как в раздел `labels:` нашего шаблона, так и в раздел `data:`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Если мы отрисуем это, получим ошибку: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Чтобы увидеть результат рендеринга, выполните команду с `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Результат будет не таким, как ожидалось: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Обратите внимание, что отступы у `app_version` неправильные в обоих местах. Почему? Потому что подставляемый шаблон имеет текст, выровненный по левому краю. Поскольку `template` является действием, а не функцией, невозможно передать вывод вызова `template` другим функциям — данные просто вставляются на место. Чтобы обойти этот случай, Helm предоставляет альтернативу `template`, которая импортирует содержимое шаблона в текущий конвейер, где его можно передать другим функциям в конвейере. Вот исправленный пример с использованием `indent` для правильного отступа шаблона `mychart.app`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Теперь сгенерированный YAML правильно отформатирован для каждого раздела: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > В шаблонах Helm предпочтительнее использовать `include` вместо `template`, чтобы лучше контролировать форматирование вывода для YAML-документов. Иногда нам нужно импортировать содержимое, но не как шаблоны — то есть импортировать файлы как есть. Мы можем сделать это, обращаясь к файлам через объект `.Files`, который описан в следующем разделе. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Создание файла NOTES.txt description: Как предоставить инструкции пользователям вашего чарта. sidebar_position: 10 --- В этом разделе мы рассмотрим инструмент Helm для предоставления инструкций пользователям вашего чарта. По завершении команды `helm install` или `helm upgrade` Helm может вывести блок полезной информации для пользователей. Эта информация легко настраивается с помощью шаблонов. Чтобы добавить инструкции по установке в ваш чарт, просто создайте файл `templates/NOTES.txt`. Это обычный текстовый файл, но он обрабатывается как шаблон и имеет доступ ко всем стандартным функциям и объектам шаблонов. Давайте создадим простой файл `NOTES.txt`: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Теперь, если мы выполним `helm install rude-cardinal ./mychart`, в конце вывода мы увидим следующее сообщение: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Использование `NOTES.txt` таким образом — отличный способ предоставить пользователям подробную информацию о том, как работать с только что установленным чартом. Создание файла `NOTES.txt` настоятельно рекомендуется, хотя и не является обязательным. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Субчарты и глобальные значения description: Работа со значениями субчартов и глобальными значениями. sidebar_position: 11 --- До сих пор мы работали только с одним чартом. Но чарты могут иметь зависимости, называемые _субчартами_, которые также имеют собственные значения и шаблоны. В этом разделе мы создадим субчарт и рассмотрим различные способы доступа к значениям из шаблонов. Прежде чем перейти к коду, следует узнать несколько важных деталей о субчартах приложений: 1. Субчарт считается «автономным», то есть субчарт никогда не может явно зависеть от родительского чарта. 2. По этой причине субчарт не может обращаться к значениям родительского чарта. 3. Родительский чарт может переопределять значения субчартов. 4. В Helm существует концепция _глобальных значений_, которые доступны всем чартам. > Эти ограничения не обязательно применимы к [library-чартам](/topics/library_charts.md), которые предназначены для предоставления стандартизированных вспомогательных функций. В процессе изучения примеров этого раздела многие концепции станут понятнее. ## Создание субчарта Для этих упражнений мы начнём с чарта `mychart/`, созданного в начале руководства, и добавим внутрь него новый чарт. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Обратите внимание: как и ранее, мы удалили все базовые шаблоны, чтобы начать с нуля. В этом руководстве мы сосредоточены на работе шаблонов, а не на управлении зависимостями. Дополнительную информацию о работе субчартов можно найти в [руководстве по чартам](/topics/charts.md). ## Добавление значений и шаблона в субчарт Далее создадим простой шаблон и файл values для нашего чарта `mysubchart`. В директории `mychart/charts/mysubchart` уже должен быть файл `values.yaml`. Настроим его следующим образом: ```yaml dessert: cake ``` Затем создадим новый шаблон ConfigMap в `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Поскольку каждый субчарт является _автономным чартом_, мы можем протестировать `mysubchart` отдельно: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Переопределение значений из родительского чарта Наш исходный чарт `mychart` теперь является _родительским чартом_ для `mysubchart`. Эта связь основана исключительно на том, что `mysubchart` находится внутри `mychart/charts`. Поскольку `mychart` является родительским, мы можем указать конфигурацию в `mychart` и передать её в `mysubchart`. Например, можно изменить `mychart/values.yaml` следующим образом: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Обратите внимание на последние две строки. Все директивы внутри секции `mysubchart` будут переданы в чарт `mysubchart`. Поэтому, если мы выполним `helm install --generate-name --dry-run --debug mychart`, среди прочего мы увидим ConfigMap субчарта `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` Значение верхнего уровня переопределило значение субчарта. Здесь важно отметить одну деталь. Мы не изменяли шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, чтобы он указывал на `.Values.mysubchart.dessert`. С точки зрения этого шаблона значение по-прежнему находится в `.Values.dessert`. Когда движок шаблонов передаёт значения, он устанавливает область видимости. Поэтому для шаблонов `mysubchart` в `.Values` будут доступны только значения, предназначенные специально для `mysubchart`. Однако иногда требуется, чтобы определённые значения были доступны всем шаблонам. Это достигается с помощью глобальных значений чарта. ## Глобальные значения чарта Глобальные значения — это значения, к которым можно обращаться из любого чарта или субчарта по одному и тому же имени. Глобальные значения требуют явного объявления. Нельзя использовать существующее неглобальное значение как глобальное. Тип данных Values имеет зарезервированную секцию `Values.global`, в которой можно задавать глобальные значения. Давайте добавим её в файл `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Благодаря тому, как работают глобальные значения, и `mychart/templates/configmap.yaml`, и `mysubchart/templates/configmap.yaml` смогут получить доступ к этому значению через `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Теперь, если мы выполним пробную установку, мы увидим одинаковое значение в обоих результатах: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Глобальные значения полезны для передачи подобной информации, хотя их использование требует предварительного планирования, чтобы правильно настроить соответствующие шаблоны. ## Совместное использование шаблонов с субчартами Родительские чарты и субчарты могут совместно использовать шаблоны. Любой определённый блок в любом чарте доступен другим чартам. Например, можно определить простой шаблон следующим образом: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Напомним, что метки в шаблонах являются _глобально разделяемыми_. Поэтому шаблон `labels` может быть включён из любого другого чарта. Хотя разработчики чартов могут выбирать между `include` и `template`, одно из преимуществ использования `include` заключается в том, что `include` позволяет динамически ссылаться на шаблоны: ```yaml {{ include $mytemplate }} ``` Приведённый код разыменует переменную `$mytemplate`. Функция `template`, напротив, принимает только строковый литерал. ## Избегайте использования блоков Язык шаблонов Go предоставляет ключевое слово `block`, которое позволяет разработчикам задавать реализацию по умолчанию, переопределяемую позднее. В чартах Helm блоки — не лучший инструмент для переопределения, поскольку при наличии нескольких реализаций одного и того же блока выбор реализации непредсказуем. Вместо этого рекомендуется использовать `include`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Файлы Values description: Инструкции по использованию флага --values. sidebar_position: 4 --- В предыдущем разделе мы рассмотрели встроенные объекты, которые предоставляют шаблоны Helm. Один из встроенных объектов — `Values`. Этот объект обеспечивает доступ к значениям, переданным в чарт. Его содержимое формируется из нескольких источников: - Файл `values.yaml` в чарте - Если это субчарт — файл `values.yaml` родительского чарта - Файл values, переданный в `helm install` или `helm upgrade` с помощью флага `-f` (`helm install -f myvals.yaml ./mychart`) - Отдельные параметры, переданные с помощью `--set` (например, `helm install --set foo=bar ./mychart`) Список выше приведён в порядке возрастания приоритета: `values.yaml` используется по умолчанию и может быть переопределён файлом `values.yaml` родительского чарта, который, в свою очередь, может быть переопределён пользовательским файлом values, а тот — параметрами `--set`. Файлы values — это обычные YAML-файлы. Давайте отредактируем `mychart/values.yaml`, а затем изменим наш шаблон ConfigMap. Удалим значения по умолчанию из `values.yaml` и установим только один параметр: ```yaml favoriteDrink: coffee ``` Теперь мы можем использовать это значение в шаблоне: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Обратите внимание: в последней строке мы обращаемся к `favoriteDrink` как к атрибуту `Values`: `{{ .Values.favoriteDrink }}`. Посмотрим на результат. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Поскольку `favoriteDrink` в файле `values.yaml` по умолчанию установлен как `coffee`, именно это значение отображается в шаблоне. Мы можем легко переопределить его, добавив флаг `--set` при вызове `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Поскольку `--set` имеет более высокий приоритет, чем файл `values.yaml` по умолчанию, наш шаблон генерирует `drink: slurm`. Файлы values также могут содержать более структурированное содержимое. Например, мы можем создать раздел `favorite` в нашем файле `values.yaml` и добавить туда несколько ключей: ```yaml favorite: drink: coffee food: pizza ``` Теперь нам нужно немного изменить шаблон: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Хотя такая структуризация данных возможна, рекомендуется сохранять деревья значений неглубокими, отдавая предпочтение плоской структуре. Когда мы рассмотрим присвоение значений субчартам, вы увидите, как значения именуются с использованием древовидной структуры. ## Удаление ключа по умолчанию Если вам нужно удалить ключ из значений по умолчанию, вы можете переопределить его значение как `null` — тогда Helm удалит этот ключ при слиянии переопределённых значений. Например, стабильный чарт Drupal позволяет настраивать проверку работоспособности (liveness probe), если вы используете собственный образ. Вот значения по умолчанию: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Если вы попытаетесь переопределить обработчик livenessProbe на `exec` вместо `httpGet` с помощью `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm объединит ключи по умолчанию и переопределённые, что приведёт к следующему YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Однако Kubernetes выдаст ошибку, поскольку нельзя объявлять более одного обработчика livenessProbe. Чтобы решить эту проблему, вы можете указать Helm удалить `livenessProbe.httpGet`, установив его в null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` На данный момент мы рассмотрели несколько встроенных объектов и использовали их для внедрения информации в шаблон. Теперь перейдём к другому аспекту движка шаблонов: функциям и конвейерам. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Переменные description: Использование переменных в шаблонах. sidebar_position: 8 --- Освоив функции, конвейеры, объекты и управляющие структуры, мы можем перейти к одной из базовых концепций многих языков программирования: переменным. В шаблонах они используются реже. Тем не менее мы рассмотрим, как с их помощью упростить код и более эффективно использовать конструкции `with` и `range`. В предыдущем примере мы видели, что этот код не работает: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` недоступен внутри области видимости, ограниченной блоком `with`. Один из способов обойти проблемы с областью видимости — присвоить объекты переменным, к которым можно обращаться независимо от текущей области видимости. В шаблонах Helm переменная — это именованная ссылка на другой объект. Она записывается в формате `$name`. Переменные присваиваются с помощью специального оператора присваивания: `:=`. Перепишем приведённый выше пример, используя переменную для `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Обратите внимание: перед началом блока `with` мы присваиваем `$relname := .Release.Name`. Теперь внутри блока `with` переменная `$relname` по-прежнему указывает на имя релиза. Выполнение даст следующий результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Переменные особенно полезны в циклах `range`. Их можно использовать с объектами типа списка для получения как индекса, так и значения: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Обратите внимание: сначала идёт `range`, затем переменные, оператор присваивания и список. Это присвоит целочисленный индекс (начиная с нуля) переменной `$index`, а значение — переменной `$topping`. Выполнение даст: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Для структур данных, содержащих и ключ, и значение, можно использовать `range` для получения обоих. Например, мы можем перебрать `.Values.favorite` следующим образом: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` На первой итерации `$key` будет равен `drink`, а `$val` — `coffee`. На второй итерации `$key` будет равен `food`, а `$val` — `pizza`. Результат выполнения: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Переменные обычно не являются «глобальными». Их область видимости ограничена блоком, в котором они объявлены. Ранее мы присвоили `$relname` на верхнем уровне шаблона. Эта переменная будет доступна во всём шаблоне. Но в последнем примере `$key` и `$val` будут доступны только внутри блока `{{ range... }}{{ end }}`. Однако существует одна переменная, которая всегда указывает на корневой контекст: `$`. Она позволяет обращаться к данным верхнего уровня (например, `.Release.Name` или `.Chart.Name`) из любого места шаблона, даже внутри цикла `range`. Пример: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` До сих пор мы рассматривали только один шаблон в одном файле. Но язык шаблонов Helm позволяет объявлять несколько шаблонов и использовать их совместно. Об этом пойдёт речь в следующем разделе. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Дальнейшие шаги description: Подведение итогов — полезные ссылки на другую документацию, которая поможет вам в работе. sidebar_position: 14 --- Это руководство создано для того, чтобы дать вам, как разработчику чартов, глубокое понимание языка шаблонов Helm. Основной акцент сделан на технических аспектах разработки шаблонов. Однако многие вопросы практической повседневной разработки чартов здесь не рассмотрены. Ниже приведены полезные ссылки на другую документацию, которая поможет вам при создании новых чартов: - [Artifact Hub](https://artifacthub.io/packages/search?kind=0) от CNCF — незаменимый источник чартов. - [Документация Kubernetes](https://kubernetes.io/docs/home/) содержит подробные примеры различных видов ресурсов: от ConfigMaps и Secrets до DaemonSets и Deployments. - [Руководство по чартам](/topics/charts.md) описывает рабочий процесс использования чартов. - [Руководство по хукам чартов](/topics/charts_hooks.md) объясняет, как создавать хуки жизненного цикла. - [Советы и рекомендации по чартам](/howto/charts_tips_and_tricks.md) — полезные советы по написанию чартов. - [Документация Sprig](https://github.com/Masterminds/sprig) описывает более шестидесяти функций шаблонов. - [Документация Go template](https://godoc.org/text/template) подробно объясняет синтаксис шаблонов. - [Schelm](https://github.com/databus23/schelm) — удобная утилита для отладки чартов. Иногда проще задать несколько вопросов и получить ответы от опытных разработчиков. Лучшее место для этого — каналы Helm в [Kubernetes Slack](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Если вы обнаружите ошибки или пропуски в этом документе, хотите предложить новый контент или внести свой вклад, посетите [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Приложение: Техники работы с YAML" description: Подробный обзор спецификации YAML и её применения в Helm. sidebar_position: 15 --- Большая часть этого руководства была посвящена написанию языка шаблонов. В этом разделе мы рассмотрим формат YAML. YAML обладает рядом полезных возможностей, которые мы, как авторы шаблонов, можем использовать для уменьшения количества ошибок и улучшения читаемости наших шаблонов. ## Скаляры и коллекции Согласно [спецификации YAML](https://yaml.org/spec/1.2/spec.html), существует два типа коллекций и множество скалярных типов. Два типа коллекций — это словари (map) и последовательности (sequence): ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Скалярные значения — это отдельные значения (в отличие от коллекций). ### Скалярные типы в YAML В диалекте YAML, используемом Helm, тип данных скалярного значения определяется сложным набором правил, включая схему Kubernetes для определений ресурсов. Однако при выводе типов обычно действуют следующие правила. Если целое число или число с плавающей точкой записано без кавычек, оно обычно рассматривается как числовой тип: ```yaml count: 1 size: 2.34 ``` Но если они заключены в кавычки, они рассматриваются как строки: ```yaml count: "1" # <-- строка, не int size: '2.34' # <-- строка, не float ``` То же самое относится к булевым значениям: ```yaml isGood: true # bool answer: "true" # строка ``` Слово для пустого значения — `null` (не `nil`). Обратите внимание, что `port: "80"` является допустимым YAML и пройдёт как через движок шаблонов, так и через парсер YAML, но вызовет ошибку, если Kubernetes ожидает, что `port` будет целым числом. В некоторых случаях можно принудительно указать определённый тип с помощью тегов узлов YAML: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` В примере выше `!!str` указывает парсеру, что `age` является строкой, даже если выглядит как целое число. А `port` рассматривается как целое число, несмотря на то что заключён в кавычки. ## Строки в YAML Большая часть данных, которые мы размещаем в документах YAML, — это строки. YAML предоставляет несколько способов представления строк. В этом разделе описываются эти способы и демонстрируется применение некоторых из них. Существует три «встроенных» способа объявления строки: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` Все встроенные стили должны располагаться на одной строке. - Слова без кавычек (bare words) не экранируются. По этой причине нужно внимательно следить за используемыми символами. - Строки в двойных кавычках могут содержать экранированные символы с помощью `\`. Например, `"\"Hello\", she said"`. Переносы строк можно экранировать с помощью `\n`. - Строки в одинарных кавычках являются «литеральными» строками и не используют `\` для экранирования символов. Единственная последовательность экранирования — `''`, которая декодируется как одинарная кавычка `'`. Помимо однострочных строк, можно объявлять многострочные строки: ```yaml coffee: | Latte Cappuccino Espresso ``` В примере выше значение `coffee` будет рассматриваться как единая строка, эквивалентная `Latte\nCappuccino\nEspresso\n`. Обратите внимание, что первая строка после `|` должна иметь правильный отступ. Поэтому мы можем нарушить работу примера выше, сделав так: ```yaml coffee: | Latte Cappuccino Espresso ``` Поскольку `Latte` имеет неправильный отступ, мы получим ошибку вроде этой: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` В шаблонах иногда безопаснее добавить фиктивную «первую строку» содержимого в многострочном документе для защиты от подобной ошибки: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Обратите внимание, что какой бы ни была первая строка, она сохранится в выходных данных строки. Поэтому если вы используете эту технику для вставки содержимого файла в ConfigMap, комментарий должен быть того типа, который ожидается программой, читающей эту запись. ### Управление пробелами в многострочных строках В примере выше мы использовали `|` для обозначения многострочной строки. Обратите внимание, что содержимое строки заканчивается символом `\n`. Если нужно, чтобы процессор YAML убрал завершающий перенос строки, можно добавить `-` после `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Теперь значение `coffee` будет: `Latte\nCappuccino\nEspresso` (без завершающего `\n`). В других случаях может потребоваться сохранить все завершающие пробельные символы. Это можно сделать с помощью нотации `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Теперь значение `coffee` будет `Latte\nCappuccino\nEspresso\n\n\n`. Отступы внутри текстового блока сохраняются, что также приводит к сохранению переносов строк: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` В этом случае `coffee` будет `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Отступы и шаблоны При написании шаблонов вам может понадобиться вставить содержимое файла в шаблон. Как мы видели в предыдущих главах, есть два способа сделать это: - Используйте `{{ .Files.Get "FILENAME" }}` для получения содержимого файла из чарта. - Используйте `{{ include "TEMPLATE" . }}` для рендеринга шаблона и последующей вставки его содержимого в чарт. При вставке файлов в YAML полезно знать правила работы с многострочными строками, описанные выше. Часто самый простой способ вставить статический файл — сделать что-то вроде этого: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Обратите внимание на отступ выше: `indent 2` указывает движку шаблонов добавить отступ в два пробела к каждой строке «myfile.txt». Обратите внимание, что мы не делаем отступ для самой строки шаблона. Если бы мы это сделали, содержимое первой строки файла имело бы двойной отступ. ### Свёрнутые многострочные строки Иногда нужно представить строку в YAML на нескольких строках, но при интерпретации она должна рассматриваться как одна длинная строка. Это называется «свёртывание» (folding). Чтобы объявить свёрнутый блок, используйте `>` вместо `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` Значение `coffee` выше будет `Latte Cappuccino Espresso\n`. Обратите внимание, что все переносы строк, кроме последнего, будут преобразованы в пробелы. Вы можете комбинировать управление пробельными символами с маркером свёртывания, поэтому `>-` заменит или обрежет все переносы строк. Обратите внимание, что в синтаксисе свёртывания текст с отступом сохраняет переносы строк. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Результат будет `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Обратите внимание, что пробелы и переносы строк сохранены. ## Размещение нескольких документов в одном файле В один файл можно поместить несколько документов YAML. Для этого новый документ начинается с `---`, а заканчивается `...` ```yaml --- document: 1 ... --- document: 2 ... ``` Во многих случаях `---` или `...` можно опустить. Некоторые файлы в Helm не могут содержать более одного документа. Например, если в файле `values.yaml` указано более одного документа, будет использован только первый. Однако файлы шаблонов могут содержать несколько документов. В этом случае файл (и все его документы) обрабатывается как один объект во время рендеринга шаблона. Но затем результирующий YAML разделяется на несколько документов перед отправкой в Kubernetes. Мы рекомендуем использовать несколько документов в одном файле только при крайней необходимости. Наличие нескольких документов в файле может усложнить отладку. ## YAML — надмножество JSON Поскольку YAML является надмножеством JSON, любой допустимый документ JSON _должен_ быть допустимым YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Выше показан другой способ представления этого: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` И их можно смешивать (с осторожностью): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Все три варианта должны разбираться в одно и то же внутреннее представление. Хотя это означает, что такие файлы, как `values.yaml`, могут содержать данные JSON, Helm не рассматривает расширение файла `.json` как допустимый суффикс. ## Якоря YAML Спецификация YAML предоставляет способ сохранить ссылку на значение и затем обращаться к этому значению по ссылке. YAML называет это «якорением» (anchoring): ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` В примере выше `&favoriteCoffee` устанавливает ссылку на `Cappuccino`. Позже эта ссылка используется как `*favoriteCoffee`. Таким образом, `coffees` становится `Latte, Cappuccino, Espresso`. Хотя есть несколько случаев, когда якоря полезны, есть один аспект, который может вызвать незаметные ошибки: при первом чтении YAML ссылка раскрывается, а затем отбрасывается. Поэтому если мы декодируем и затем снова закодируем пример выше, результирующий YAML будет таким: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Поскольку Helm и Kubernetes часто читают, модифицируют и затем перезаписывают файлы YAML, якоря будут утеряны. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Изменения с Helm 2 description: Исчерпывающий список всех основных изменений, появившихся в Helm 3. sidebar_position: 1 --- ## Изменения с Helm 2 Ниже приведён исчерпывающий список всех основных изменений, появившихся в Helm 3. ### Удаление Tiller В процессе разработки Helm 2 мы представили Tiller. Tiller играл важную роль для команд, работающих в общем кластере — он позволял нескольким операторам взаимодействовать с одним и тем же набором релизов. С включением управления доступом на основе ролей (RBAC) по умолчанию в Kubernetes 1.6, защита Tiller для использования в production-среде стала сложнее в управлении. Из-за множества возможных политик безопасности мы придерживались позиции предоставления разрешительной конфигурации по умолчанию. Это позволяло новым пользователям начать экспериментировать с Helm и Kubernetes без необходимости сразу погружаться в настройки безопасности. К сожалению, такая разрешительная конфигурация могла предоставить пользователю широкий набор прав, которые не были предусмотрены. DevOps-инженерам и SRE приходилось изучать дополнительные операционные шаги при установке Tiller в мультитенантный кластер. Узнав, как участники сообщества использовали Helm в определённых сценариях, мы обнаружили, что системе управления релизами Tiller не обязательно полагаться на оператор внутри кластера для поддержания состояния или как на центральный узел для информации о релизах Helm. Вместо этого мы могли просто получать информацию от API-сервера Kubernetes, выполнять рендеринг чартов на стороне клиента и сохранять запись об установке в Kubernetes. Основная цель Tiller могла быть достигнута без него, поэтому одним из первых решений относительно Helm 3 стало полное удаление Tiller. С удалением Tiller модель безопасности Helm радикально упростилась. Helm 3 теперь поддерживает все современные функции безопасности, идентификации и авторизации Kubernetes. Права Helm определяются с помощью вашего [файла kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Администраторы кластера могут ограничивать права пользователей с любой необходимой детализацией. Релизы по-прежнему записываются в кластер, а остальная функциональность Helm сохраняется. ### Улучшенная стратегия обновления: трёхстороннее стратегическое слияние патчей В Helm 2 использовалось двухстороннее стратегическое слияние патчей. При обновлении сравнивался манифест последнего чарта с предложенным манифестом чарта (предоставленным во время `helm upgrade`). Сравнивались различия между этими двумя чартами, чтобы определить, какие изменения необходимо применить к ресурсам в Kubernetes. Если изменения вносились в кластер вне Helm (например, во время `kubectl edit`), они не учитывались. Это приводило к невозможности откатить ресурсы к предыдущему состоянию: поскольку Helm рассматривал только последний применённый манифест чарта как текущее состояние, при отсутствии изменений в состоянии чарта фактическое состояние оставалось неизменным. В Helm 3 мы используем трёхстороннее стратегическое слияние патчей. При генерации патча Helm учитывает старый манифест, его фактическое состояние и новый манифест. #### Примеры Рассмотрим несколько типичных примеров того, на что влияет это изменение. ##### Откат при изменении фактического состояния Ваша команда только что развернула приложение в production на Kubernetes с помощью Helm. Чарт содержит объект Deployment, в котором количество реплик установлено на три: ```console $ helm install myapp ./myapp ``` В команду приходит новый разработчик. В первый рабочий день, наблюдая за production-кластером, он случайно проливает кофе на клавиатуру и выполняет `kubectl scale`, уменьшая количество реплик production-deployment с трёх до нуля. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Другой разработчик в команде замечает, что production-сайт не работает, и решает откатить релиз к предыдущему состоянию: ```console $ helm rollback myapp ``` Что происходит? В Helm 2 генерировался патч путём сравнения старого манифеста с новым. Поскольку это откат, манифесты одинаковые. Helm определял, что нечего менять, так как нет различий между старым и новым манифестом. Количество реплик продолжало оставаться на нуле. Начиналась паника. В Helm 3 патч генерируется с использованием старого манифеста, фактического состояния и нового манифеста. Helm распознаёт, что старое состояние было три, фактическое состояние — ноль, а новый манифест хочет вернуть значение к трём, поэтому генерирует патч для возврата состояния к трём. ##### Обновление при изменении фактического состояния Многие service mesh и другие приложения на основе контроллеров внедряют данные в объекты Kubernetes. Это может быть sidecar-контейнер, метки или другая информация. Допустим, у вас был такой манифест, сгенерированный из чарта: ```yaml containers: - name: server image: nginx:2.0.0 ``` А фактическое состояние было изменено другим приложением на: ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Теперь вы хотите обновить тег образа `nginx` до `2.1.0`. Вы обновляетесь до чарта с таким манифестом: ```yaml containers: - name: server image: nginx:2.1.0 ``` Что происходит? В Helm 2 генерировался патч объекта `containers` между старым и новым манифестом. Фактическое состояние кластера не учитывалось при генерации патча. Фактическое состояние кластера изменялось на: ```yaml containers: - name: server image: nginx:2.1.0 ``` Sidecar-контейнер удалялся из фактического состояния. Опять паника. В Helm 3 генерируется патч объекта `containers` между старым манифестом, фактическим состоянием и новым манифестом. Helm замечает, что новый манифест изменяет тег образа на `2.1.0`, но фактическое состояние содержит sidecar-контейнер. Фактическое состояние кластера изменяется на: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Имена релизов теперь ограничены namespace С удалением Tiller информация о каждом релизе должна была где-то храниться. В Helm 2 она хранилась в том же namespace, что и Tiller. На практике это означало, что после использования имени для релиза никакой другой релиз не мог использовать то же имя, даже при развёртывании в другом namespace. В Helm 3 информация о конкретном релизе теперь хранится в том же namespace, что и сам релиз. Это означает, что пользователи могут выполнить `helm install wordpress stable/wordpress` в двух разных namespace, и на каждый можно ссылаться через `helm list`, изменив контекст текущего namespace (например, `helm list --namespace foo`). Благодаря лучшему соответствию нативным namespace кластера, команда `helm list` больше не показывает все релизы по умолчанию. Вместо этого она показывает только релизы в namespace вашего текущего контекста Kubernetes (то есть namespace, отображаемый при выполнении `kubectl config view --minify`). Это также означает, что необходимо указать флаг `--all-namespaces` для команды `helm list`, чтобы получить поведение, аналогичное Helm 2. ### Secrets как хранилище по умолчанию В Helm 3 Secrets теперь используются как [хранилище по умолчанию](/topics/advanced.md#storage-backends). В Helm 2 по умолчанию использовались ConfigMaps для хранения информации о релизах. В Helm 2.7.0 был реализован новый бэкенд хранилища, использующий Secrets, и теперь он является значением по умолчанию в Helm 3. Переход на Secrets в Helm 3 по умолчанию обеспечивает дополнительную безопасность для защиты чартов в сочетании с появлением шифрования Secrets в Kubernetes. [Шифрование secrets в покое](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) появилось как alpha-функция в Kubernetes 1.7 и стало стабильным в Kubernetes 1.13. Это позволяет пользователям шифровать метаданные релизов Helm в покое, что является хорошей отправной точкой для последующего расширения на использование чего-то вроде Vault. ### Изменения путей импорта Go В Helm 3 путь импорта Go изменился с `k8s.io/helm` на `helm.sh/helm/v3`. Если вы планируете перейти на клиентские библиотеки Go Helm 3, убедитесь, что изменили пути импорта. ### Capabilities Встроенный объект `.Capabilities`, доступный на этапе рендеринга, был упрощён. [Встроенные объекты](/chart_template_guide/builtin_objects.md) ### Валидация значений чарта с помощью JSONSchema Теперь к значениям чарта можно применить JSON Schema. Это гарантирует, что значения, предоставленные пользователем, соответствуют схеме, определённой разработчиком чарта, обеспечивая лучшую отчётность об ошибках при предоставлении некорректных значений. Валидация выполняется при вызове следующих команд: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Подробнее см. в документации по [файлам схем](/topics/charts.md#schema-files). ### Консолидация `requirements.yaml` в `Chart.yaml` Система управления зависимостями чартов переехала из requirements.yaml и requirements.lock в Chart.yaml и Chart.lock. Мы рекомендуем использовать новый формат для новых чартов, предназначенных для Helm 3. Однако Helm 3 по-прежнему понимает Chart API версии 1 (`v1`) и загрузит существующие файлы `requirements.yaml`. В Helm 2 `requirements.yaml` выглядел так: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` В Helm 3 зависимость выражается так же, но теперь в вашем `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Чарты по-прежнему загружаются и помещаются в директорию `charts/`, поэтому подчарты, находящиеся в директории `charts/`, продолжат работать без изменений. ### Имя (или --generate-name) теперь обязательно при установке В Helm 2 при отсутствии имени автоматически генерировалось имя. На практике это оказалось скорее неудобством, чем полезной функцией. В Helm 3 Helm выдаст ошибку, если имя не указано при `helm install`. Для тех, кто по-прежнему хочет автоматически сгенерированное имя, можно использовать флаг `--generate-name`. ### Публикация чартов в OCI-реестры Это экспериментальная функция, представленная в Helm 3. Для её использования установите переменную окружения `HELM_EXPERIMENTAL_OCI=1`. На высоком уровне репозиторий чартов — это место, где чарты могут храниться и распространяться. Клиент Helm упаковывает и отправляет чарты в репозиторий. Проще говоря, репозиторий чартов — это базовый HTTP-сервер, содержащий файл index.yaml и упакованные чарты. Хотя API репозитория чартов удовлетворяет базовым требованиям к хранению, у него есть ряд недостатков: - Репозиториям чартов очень сложно абстрагировать большинство реализаций безопасности, необходимых в production-среде. Стандартный API для аутентификации и авторизации очень важен в production-сценариях. - Инструменты Helm для подписи и проверки целостности и происхождения чарта являются необязательной частью процесса публикации чарта. - В мультитенантных сценариях один и тот же чарт может быть загружен другим арендатором, что удваивает затраты на хранение одного и того же содержимого. Более продвинутые репозитории чартов были разработаны для решения этой проблемы, но это не является частью формальной спецификации. - Использование одного индексного файла для поиска, информации о метаданных и получения чартов затрудняет проектирование безопасных мультитенантных реализаций. Проект Distribution от Docker (также известный как Docker Registry v2) является преемником проекта Docker Registry. Многие крупные облачные провайдеры предлагают продукты на основе проекта Distribution, и благодаря этому проект получил многолетнюю закалку, лучшие практики безопасности и проверку в боевых условиях. Подробнее о том, как упаковать чарт и отправить его в Docker-реестр, см. в `helm help chart` и `helm help registry`. Дополнительная информация на [этой странице](/topics/registries.md). ### Удаление `helm serve` `helm serve` запускал локальный репозиторий чартов на вашем компьютере для целей разработки. Однако он не получил широкого распространения как инструмент разработки и имел множество проблем с архитектурой. В итоге мы решили удалить его и выделить в плагин. Для аналогичного опыта работы с `helm serve` обратите внимание на опцию локального файлового хранилища в [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) и [плагин servecm](https://github.com/jdolitsky/helm-servecm). ### Поддержка библиотечных чартов Helm 3 поддерживает класс чартов, называемых «библиотечными чартами». Это чарты, которые используются другими чартами, но не создают собственных артефактов релиза. Шаблоны библиотечного чарта могут объявлять только элементы `define`. Глобальный контент, не являющийся `define`, просто игнорируется. Это позволяет пользователям повторно использовать и делиться фрагментами кода, которые можно использовать в нескольких чартах, избегая избыточности и сохраняя чарты [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Библиотечные чарты объявляются в директиве dependencies в Chart.yaml и устанавливаются и управляются как любой другой чарт. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Мы с нетерпением ждём сценариев использования, которые откроет эта функция для разработчиков чартов, а также лучших практик, возникающих при использовании библиотечных чартов. ### Обновление apiVersion в Chart.yaml С появлением поддержки библиотечных чартов и консолидацией requirements.yaml в Chart.yaml, клиенты, понимавшие формат пакетов Helm 2, не смогут понять эти новые функции. Поэтому мы изменили apiVersion в Chart.yaml с `v1` на `v2`. `helm create` теперь создаёт чарты с использованием нового формата, поэтому apiVersion по умолчанию также был изменён. Клиенты, желающие поддерживать обе версии чартов Helm, должны проверять поле `apiVersion` в Chart.yaml, чтобы понять, как разбирать формат пакета. ### Поддержка XDG Base Directory [Спецификация XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) — это переносимый стандарт, определяющий, где в файловой системе должны храниться файлы конфигурации, данных и кэша. В Helm 2 вся эта информация хранилась в `~/.helm` (известной как `helm home`), которую можно было изменить, установив переменную окружения `$HELM_HOME` или используя глобальный флаг `--home`. В Helm 3 Helm теперь использует следующие переменные окружения в соответствии со спецификацией XDG Base Directory: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Плагинам Helm по-прежнему передаётся `$HELM_HOME` как псевдоним для `$XDG_DATA_HOME` для обратной совместимости с плагинами, использующими `$HELM_HOME` как рабочую директорию. Для адаптации к этому изменению в окружение плагина также передаются несколько новых переменных окружения: - `$HELM_PATH_CACHE` — путь к кэшу - `$HELM_PATH_CONFIG` — путь к конфигурации - `$HELM_PATH_DATA` — путь к данным Плагинам Helm, желающим поддерживать Helm 3, следует рассмотреть использование этих новых переменных окружения. ### Переименование команд CLI Для лучшего соответствия терминологии других пакетных менеджеров `helm delete` была переименована в `helm uninstall`. `helm delete` по-прежнему сохраняется как псевдоним для `helm uninstall`, поэтому можно использовать любую форму. В Helm 2 для очистки истории релиза необходимо было указать флаг `--purge`. Эта функциональность теперь включена по умолчанию. Чтобы сохранить предыдущее поведение, используйте `helm uninstall --keep-history`. Кроме того, несколько других команд были переименованы для соответствия тем же соглашениям: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` Эти команды также сохранили свои старые названия как псевдонимы, поэтому вы можете продолжать использовать их в любой форме. ### Автоматическое создание namespace При создании релиза в несуществующем namespace Helm 2 создавал namespace. Helm 3 следует поведению других инструментов Kubernetes и возвращает ошибку, если namespace не существует. Helm 3 создаст namespace, если вы явно укажете флаг `--create-namespace`. ### Что произошло с .Chart.ApiVersion? Helm следует типичному соглашению CamelCase, которое требует использования заглавных букв в аббревиатурах. Мы применяли это в других частях кода, например, в `.Capabilities.APIVersions.Has`. В Helm v3 мы исправили `.Chart.ApiVersion` в соответствии с этим паттерном, переименовав его в `.Chart.APIVersion`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: Часто задаваемые вопросы sidebar_position: 9 --- # Часто задаваемые вопросы > Этот раздел содержит ответы на наиболее распространённые вопросы. **Мы будем рады вашей помощи** в улучшении этого документа. Чтобы добавить, исправить или удалить информацию, [создайте issue](https://github.com/helm/helm-www/issues) или отправьте нам pull request. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Установка sidebar_position: 2 --- ## Установка ### Почему нет нативных пакетов Helm для Fedora и других дистрибутивов Linux? Проект Helm не поддерживает пакеты для операционных систем и окружений. Сообщество Helm может предоставлять нативные пакеты, и если проект узнает о них, они будут добавлены в список. Именно так появилась и была добавлена формула для Homebrew. Если вы заинтересованы в поддержке пакета, мы будем рады вашему участию. ### Почему вы предоставляете скрипт `curl ...|bash`? В нашем репозитории есть скрипт (`scripts/get-helm-3`), который можно выполнить как `curl ..|bash`. Все передачи данных защищены протоколом HTTPS, а скрипт выполняет проверку загружаемых пакетов. Тем не менее, он несёт все риски, характерные для любого shell-скрипта. Мы предоставляем его, потому что он полезен, но рекомендуем пользователям внимательно изучить скрипт перед использованием. В идеале мы бы предпочли более качественные упакованные релизы Helm. ### Как разместить файлы клиента Helm в месте, отличном от расположения по умолчанию? Helm использует структуру XDG для хранения файлов. Для изменения этих расположений вы можете использовать следующие переменные окружения: - `$XDG_CACHE_HOME`: альтернативное расположение для кэшированных файлов. - `$XDG_CONFIG_HOME`: альтернативное расположение для конфигурации Helm. - `$XDG_DATA_HOME`: альтернативное расположение для данных Helm. Обратите внимание: если у вас есть существующие репозитории, вам потребуется добавить их заново с помощью `helm repo add...`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Решение проблем sidebar_position: 4 --- ## Решение проблем ### Я получаю предупреждение «Unable to get an update from the "stable" chart repository» Выполните `helm repo list`. Если вы видите, что ваш репозиторий `stable` указывает на URL `storage.googleapis.com`, вам необходимо обновить этот репозиторий. 13 ноября 2020 года репозиторий Helm Charts [прекратил поддержку](https://github.com/helm/charts#deprecation-timeline) после годового периода устаревания. Архив доступен по адресу `https://charts.helm.sh/stable`, но больше не будет получать обновления. Вы можете выполнить следующую команду для исправления репозитория: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` То же самое относится к репозиторию `incubator`, архив которого доступен по адресу https://charts.helm.sh/incubator. Вы можете выполнить следующую команду для его исправления: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Я получаю предупреждение 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' Старый репозиторий чартов Google Helm был заменён новым репозиторием чартов Helm. Выполните следующую команду для окончательного решения этой проблемы: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Если вы получаете аналогичную ошибку для `incubator`, выполните эту команду: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### При добавлении репозитория Helm я получаю ошибку 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Репозитории Helm Charts больше не поддерживаются после [годового периода устаревания](https://github.com/helm/charts#deprecation-timeline). Архивы этих репозиториев доступны по адресам `https://charts.helm.sh/stable` и `https://charts.helm.sh/incubator`, однако они больше не будут получать обновления. Команда `helm repo add` не позволит вам добавить старые URL, если вы не укажете `--use-deprecated-repos`. ### В GKE (Google Container Engine) я получаю ошибку «No SSH tunnels currently open» ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Другой вариант сообщения об ошибке: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` Проблема в том, что ваш локальный файл конфигурации Kubernetes должен содержать корректные учётные данные. При создании кластера в GKE вы получаете учётные данные, включая SSL-сертификаты и центры сертификации. Они должны храниться в файле конфигурации Kubernetes (по умолчанию: `~/.kube/config`), чтобы `kubectl` и `helm` могли получить к ним доступ. ### После миграции с Helm 2 команда `helm list` показывает только часть (или ни одного) моих релизов Скорее всего, вы упустили тот факт, что Helm 3 теперь использует пространства имён кластера для определения области видимости релизов. Это означает, что для всех команд, обращающихся к релизу, вы должны либо: * полагаться на текущее пространство имён в активном контексте Kubernetes (как показывает команда `kubectl config view --minify`), * указать корректное пространство имён с помощью флага `--namespace`/`-n`, или * для команды `helm list` указать флаг `--all-namespaces`/`-A` Это относится к `helm ls`, `helm uninstall` и всем другим командам `helm`, которые обращаются к релизу. ### В macOS происходит обращение к файлу `/etc/.mdns_debug`. Почему? Нам известен случай в macOS, когда Helm пытается получить доступ к файлу `/etc/.mdns_debug`. Если файл существует, Helm удерживает дескриптор файла открытым во время выполнения. Это вызвано библиотекой MDNS в macOS. Она пытается загрузить этот файл для чтения настроек отладки (если они включены). Дескриптор файла, вероятно, не должен удерживаться открытым, и об этой проблеме сообщено в Apple. Однако это поведение вызвано macOS, а не Helm. Если вы не хотите, чтобы Helm загружал этот файл, вы можете скомпилировать Helm как статическую библиотеку, которая не использует сетевой стек хоста. Это увеличит размер бинарного файла Helm, но предотвратит открытие файла. Изначально эта проблема была отмечена как потенциальная уязвимость безопасности. Однако позже было установлено, что данное поведение не вызывает никаких уязвимостей или недостатков. ### helm repo add завершается ошибкой, хотя раньше работал В Helm 3.3.1 и более ранних версиях команда `helm repo add ` не выдавала никакого вывода при попытке добавить уже существующий репозиторий. Флаг `--no-update` вызывал ошибку, если репозиторий уже был зарегистрирован. В Helm 3.3.2 и более поздних версиях попытка добавить существующий репозиторий вызовет ошибку: `Error: repository name (reponame) already exists, please specify a different name` Поведение по умолчанию теперь изменено на противоположное. Флаг `--no-update` теперь игнорируется, а если вы хотите заменить (перезаписать) существующий репозиторий, используйте `--force-update`. Это связано с критическим изменением для исправления уязвимости безопасности, как описано в [примечаниях к релизу Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Включение логирования клиента Kubernetes Вывод логов для отладки клиента Kubernetes можно включить с помощью флагов [klog](https://pkg.go.dev/k8s.io/klog). Использование флага `-v` для установки уровня подробности будет достаточно в большинстве случаев. Например: ``` helm list -v 6 ``` ### Установка Tiller перестала работать, и доступ запрещён Релизы Helm раньше были доступны по адресу . Как описано в публикации [«Announcing get.helm.sh»](https://helm.sh/blog/get-helm-sh/), официальное расположение изменилось в июне 2019 года. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) предоставляет все старые образы Tiller. Если вы пытаетесь загрузить старые версии Helm из бакета хранилища, который использовали ранее, вы можете обнаружить, что они отсутствуют: ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [Устаревшее расположение образов Tiller](https://gcr.io/kubernetes-helm/tiller) начало удаление образов в августе 2021 года. Мы сделали эти образы доступными в [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Например, чтобы загрузить версию v2.17.0, замените: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` на: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Для инициализации с Helm v2.17.0: `helm init —upgrade` Или, если нужна другая версия, используйте флаг --tiller-image для переопределения расположения по умолчанию и установки определённой версии Helm v2: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Примечание:** Мейнтейнеры Helm рекомендуют миграцию на текущую поддерживаемую версию Helm. Helm v2.17.0 был последним релизом Helm v2; Helm v2 не поддерживается с ноября 2020 года, как указано в публикации [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). С тех пор было обнаружено множество CVE для Helm, и эти уязвимости исправлены в Helm v3, но никогда не будут исправлены в Helm v2. Ознакомьтесь с [текущим списком опубликованных рекомендаций по безопасности Helm](https://github.com/helm/helm/security/advisories?state=published) и составьте план [миграции на Helm v3](/topics/v2_v3_migration.md) уже сегодня. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Удаление sidebar_position: 3 --- ## Удаление ### Я хочу удалить локальную установку Helm. Где находятся все его файлы? Помимо бинарного файла `helm`, Helm хранит файлы в следующих местах: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME В следующей таблице приведены пути по умолчанию для каждой из этих директорий в зависимости от операционной системы: | Операционная система | Путь к кэшу | Путь к конфигурации | Путь к данным | |----------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: Глоссарий description: Термины, используемые для описания компонентов архитектуры Helm. sidebar_position: 10 --- # Глоссарий ## Chart (Чарт) Пакет Helm, содержащий информацию, достаточную для установки набора ресурсов Kubernetes в кластер Kubernetes. Чарты содержат файл `Chart.yaml`, а также шаблоны, значения по умолчанию (`values.yaml`) и зависимости. Чарты разрабатываются в чётко определённой структуре каталогов, а затем упаковываются в архивный формат, называемый _архивом чарта_. ## Chart Archive (Архив чарта) _Архив чарта_ — это упакованный в tar и сжатый gzip (и опционально подписанный) чарт. ## Chart Dependency (Зависимость чарта, подчарты) Чарты могут зависеть от других чартов. Существует два способа возникновения зависимости: - Мягкая зависимость: чарт может просто не функционировать без установки другого чарта в кластере. Helm не предоставляет инструментов для этого случая. В этом случае зависимости управляются отдельно. - Жёсткая зависимость: чарт может содержать (внутри своего каталога `charts/`) другой чарт, от которого он зависит. В этом случае установка чарта приведёт к установке всех его зависимостей. В этом случае чарт и его зависимости управляются как единое целое. Когда чарт упаковывается (с помощью `helm package`), все его жёсткие зависимости включаются в пакет. ## Chart Version (Версия чарта) Чарты версионируются в соответствии со [спецификацией SemVer 2](https://semver.org). Номер версии обязателен для каждого чарта. ## Chart.yaml Информация о чарте хранится в специальном файле `Chart.yaml`. Каждый чарт должен иметь этот файл. ## Helm (и helm) Helm — это менеджер пакетов для Kubernetes. Подобно тому, как менеджер пакетов операционной системы упрощает установку инструментов в ОС, Helm упрощает установку приложений и ресурсов в кластеры Kubernetes. Хотя _Helm_ — это название проекта, клиент командной строки также называется `helm`. По соглашению, когда речь идёт о проекте, _Helm_ пишется с заглавной буквы. Когда речь идёт о клиенте, _helm_ пишется строчными буквами. ## Helm Configuration Files (Файлы конфигурации Helm, XDG) Helm хранит свои файлы конфигурации в каталогах XDG. Эти каталоги создаются при первом запуске `helm`. ## Kube Config (KUBECONFIG) Клиент Helm получает информацию о кластерах Kubernetes с помощью файлов в формате _Kube config_. По умолчанию Helm пытается найти этот файл в том месте, где `kubectl` его создаёт (`$HOME/.kube/config`). ## Lint (Линтинг) _Линтинг_ чарта — это проверка того, что он соответствует соглашениям и требованиям стандарта чартов Helm. Helm предоставляет для этого инструменты, в частности команду `helm lint`. ## Provenance (Файл происхождения) Чарты Helm могут сопровождаться _файлом происхождения_, который предоставляет информацию о том, откуда взялся чарт и что он содержит. Файлы происхождения являются частью модели безопасности Helm. Файл происхождения содержит криптографический хеш файла архива чарта, данные Chart.yaml и блок подписи (блок OpenPGP "clearsign"). При наличии связки ключей это даёт пользователям чарта возможность: - Проверить, что чарт был подписан доверенной стороной - Проверить, что файл чарта не был изменён - Проверить содержимое метаданных чарта (`Chart.yaml`) - Быстро сопоставить чарт с его данными происхождения Файлы происхождения имеют расширение `.prov` и могут размещаться на сервере репозитория чартов или любом другом HTTP-сервере. ## Release (Релиз) Когда чарт устанавливается, библиотека Helm создаёт _релиз_ для отслеживания этой установки. Один чарт может быть установлен много раз в один и тот же кластер и создавать множество разных релизов. Например, можно установить три базы данных PostgreSQL, выполнив `helm install` три раза с разными именами релизов. ## Release Number (Номер релиза, версия релиза) Один релиз может быть обновлён несколько раз. Последовательный счётчик используется для отслеживания релизов по мере их изменения. После первого `helm install` релиз будет иметь _номер релиза_ 1. Каждый раз при обновлении или откате релиза номер релиза будет увеличиваться. ## Rollback (Откат) Релиз может быть обновлён до более нового чарта или конфигурации. Но поскольку история релизов сохраняется, релиз также может быть _откачен_ к предыдущему номеру релиза. Это делается командой `helm rollback`. Важно отметить, что откаченный релиз получит новый номер релиза. | Операция | Номер релиза | |------------|-----------------------------------------------------------| | install | релиз 1 | | upgrade | релиз 2 | | upgrade | релиз 3 | | rollback 1 | релиз 4 (но с той же конфигурацией, что и релиз 1) | Приведённая выше таблица иллюстрирует, как номера релизов увеличиваются при установке, обновлении и откате. ## Helm Library (Библиотека Helm, или SDK) Библиотека Helm (или SDK) относится к коду Go, который напрямую взаимодействует с API-сервером Kubernetes для установки, обновления, запроса и удаления ресурсов Kubernetes. Она может быть импортирована в проект для использования Helm как клиентской библиотеки вместо CLI. ## Repository (Репозиторий, Repo, репозиторий чартов) Чарты Helm могут храниться на выделенных HTTP-серверах, называемых _репозиториями чартов_ (_репозиториями_ или просто _repo_). Сервер репозитория чартов — это простой HTTP-сервер, который может отдавать файл `index.yaml`, описывающий набор чартов и предоставляющий информацию о том, откуда можно скачать каждый чарт. (Многие репозитории чартов также предоставляют сами чарты вместе с файлом `index.yaml`.) Клиент Helm может указывать на ноль или более репозиториев чартов. По умолчанию клиенты Helm не настроены ни на один репозиторий чартов. Репозитории чартов могут быть добавлены в любое время с помощью команды `helm repo add`. ## Chart Registry (Реестр чартов, реестр на основе OCI) Реестр чартов Helm — это система хранения и распространения на основе [OCI](https://opencontainers.org/about/overview/), которая используется для размещения и распространения пакетов чартов Helm. Дополнительную информацию см. в [документации Helm по реестрам](https://helm.sh/docs/topics/registries/). ## Values (Значения, файлы значений, values.yaml) Значения позволяют переопределять значения по умолчанию из шаблонов вашей собственной информацией. Чарты Helm являются «параметризованными», что означает, что разработчик чарта может предоставить конфигурацию, которую можно переопределить во время установки. Например, чарт может предоставлять поле `username`, позволяющее задать имя пользователя для сервиса. Эти предоставляемые переменные называются _значениями_ в терминологии Helm. Значения можно задавать во время операций `helm install` и `helm upgrade`, либо передавая их напрямую, либо используя файл `values.yaml`. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Пакетный менеджер Helm для Kubernetes. ### Краткое описание Пакетный менеджер для Kubernetes Основные действия в Helm: - helm search: поиск чартов - helm pull: загрузка чарта в локальную директорию для просмотра - helm install: установка чарта в Kubernetes - helm list: вывод списка релизов чартов Переменные окружения: | Имя | Описание | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | альтернативное расположение для хранения кэшированных файлов. | | $HELM_CONFIG_HOME | альтернативное расположение для хранения конфигурации Helm. | | $HELM_DATA_HOME | альтернативное расположение для хранения данных Helm. | | $HELM_DEBUG | указывает, запущен ли Helm в режиме отладки | | $HELM_DRIVER | драйвер хранилища. Возможные значения: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | строка подключения для SQL-драйвера хранилища. | | $HELM_MAX_HISTORY | максимальное количество записей в истории релизов helm. | | $HELM_NAMESPACE | пространство имён для операций helm. | | $HELM_NO_PLUGINS | отключение плагинов. Установите HELM_NO_PLUGINS=1 для отключения. | | $HELM_PLUGINS | путь к директории с плагинами | | $HELM_REGISTRY_CONFIG | путь к файлу конфигурации реестра. | | $HELM_REPOSITORY_CACHE | путь к директории с кэшем репозиториев | | $HELM_REPOSITORY_CONFIG | путь к файлу с репозиториями. | | $KUBECONFIG | альтернативный файл конфигурации Kubernetes (по умолчанию "~/.kube/config") | | $HELM_KUBEAPISERVER | адрес сервера API Kubernetes для аутентификации | | $HELM_KUBECAFILE | файл центра сертификации Kubernetes. | | $HELM_KUBEASGROUPS | группы для имперсонации, через запятую. | | $HELM_KUBEASUSER | имя пользователя для имперсонации. | | $HELM_KUBECONTEXT | имя контекста kubeconfig. | | $HELM_KUBETOKEN | Bearer-токен для аутентификации. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | указывает, следует ли пропустить проверку сертификата сервера API Kubernetes (небезопасно) | | $HELM_KUBETLS_SERVER_NAME | имя сервера для проверки сертификата сервера API Kubernetes | | $HELM_BURST_LIMIT | лимит burst по умолчанию при большом количестве CRD на сервере (по умолчанию 100, -1 для отключения) | | $HELM_QPS | количество запросов в секунду при большом числе вызовов, превышающих лимит burst | Helm хранит кэш, конфигурацию и данные в соответствии со следующим порядком приоритета: - Если установлена переменная окружения HELM_*_HOME, она будет использоваться - Иначе, в системах, поддерживающих спецификацию XDG base directory, используются переменные XDG - Если другое расположение не задано, используется расположение по умолчанию для операционной системы По умолчанию директории зависят от операционной системы. Значения по умолчанию приведены ниже: | Операционная система | Путь к кэшу | Путь к конфигурации | Путь к данным | |----------------------|---------------------------|--------------------------------|---------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Опции ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### СМ. ТАКЖЕ * [helm completion](/helm/helm_completion.md) - генерация скриптов автодополнения для указанной оболочки * [helm create](/helm/helm_create.md) - создание нового чарта с указанным именем * [helm dependency](/helm/helm_dependency.md) - управление зависимостями чарта * [helm env](/helm/helm_env.md) - информация об окружении клиента helm * [helm get](/helm/helm_get.md) - получение расширенной информации об именованном релизе * [helm history](/helm/helm_history.md) - получение истории релиза * [helm install](/helm/helm_install.md) - установка чарта * [helm lint](/helm/helm_lint.md) - проверка чарта на возможные проблемы * [helm list](/helm/helm_list.md) - вывод списка релизов * [helm package](/helm/helm_package.md) - упаковка директории чарта в архив чарта * [helm plugin](/helm/helm_plugin.md) - установка, вывод списка или удаление плагинов Helm * [helm pull](/helm/helm_pull.md) - загрузка чарта из репозитория и (опционально) распаковка в локальную директорию * [helm push](/helm/helm_push.md) - отправка чарта на удалённый сервер * [helm registry](/helm/helm_registry.md) - вход или выход из реестра * [helm repo](/helm/helm_repo.md) - добавление, вывод списка, удаление, обновление и индексация репозиториев чартов * [helm rollback](/helm/helm_rollback.md) - откат релиза к предыдущей ревизии * [helm search](/helm/helm_search.md) - поиск по ключевому слову в чартах * [helm show](/helm/helm_show.md) - показ информации о чарте * [helm status](/helm/helm_status.md) - отображение статуса именованного релиза * [helm template](/helm/helm_template.md) - локальный рендеринг шаблонов * [helm test](/helm/helm_test.md) - запуск тестов для релиза * [helm uninstall](/helm/helm_uninstall.md) - удаление релиза * [helm upgrade](/helm/helm_upgrade.md) - обновление релиза * [helm verify](/helm/helm_verify.md) - проверка подписи и валидности чарта по указанному пути * [helm version](/helm/helm_version.md) - вывод информации о версии клиента ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- генерация скриптов автодополнения для указанной оболочки ### Краткое описание Генерирует скрипты автодополнения Helm для указанной оболочки. ### Опции ``` -h, --help help for completion ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm completion bash](./helm_completion_bash.md) - генерация скрипта автодополнения для bash * [helm completion fish](./helm_completion_fish.md) - генерация скрипта автодополнения для fish * [helm completion powershell](./helm_completion_powershell.md) - генерация скрипта автодополнения для powershell * [helm completion zsh](./helm_completion_zsh.md) - генерация скрипта автодополнения для zsh ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- генерация скрипта автодополнения для bash ### Краткое описание Генерирует скрипт автодополнения Helm для оболочки bash. Для загрузки автодополнения в текущей сессии: source <(helm completion bash) Для загрузки автодополнения во всех новых сессиях выполните однократно: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Опции ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm completion](./helm_completion.md) - генерация скриптов автодополнения для указанной оболочки ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- генерация скрипта автодополнения для fish ### Краткое описание Генерирует скрипт автодополнения Helm для оболочки fish. Для загрузки автодополнения в текущей сессии: helm completion fish | source Для загрузки автодополнения во всех новых сессиях выполните однократно: helm completion fish > ~/.config/fish/completions/helm.fish Чтобы изменения вступили в силу, необходимо перезапустить оболочку. ``` helm completion fish [flags] ``` ### Опции ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm completion](./helm_completion.md) - генерация скриптов автодополнения для указанной оболочки ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- генерация скрипта автодополнения для powershell ### Краткое описание Генерирует скрипт автодополнения Helm для оболочки powershell. Для загрузки автодополнения в текущей сессии выполните: PS C:\> helm completion powershell | Out-String | Invoke-Expression Для загрузки автодополнения во всех новых сессиях добавьте вывод указанной выше команды в ваш профиль powershell. ``` helm completion powershell [flags] ``` ### Опции ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm completion](./helm_completion.md) - генерация скриптов автодополнения для указанной оболочки ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- генерация скрипта автодополнения для zsh ### Краткое описание Генерирует скрипт автодополнения Helm для оболочки zsh. Для загрузки автодополнения в текущей сессии: source <(helm completion zsh) Для загрузки автодополнения во всех новых сессиях выполните однократно: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Опции ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm completion](./helm_completion.md) - генерация скриптов автодополнения для указанной оболочки ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- создание нового чарта с указанным именем ### Краткое описание Эта команда создаёт директорию чарта вместе со стандартными файлами и директориями, используемыми в чарте. Например, 'helm create foo' создаст структуру директорий, которая выглядит примерно так: foo/ ├── .helmignore # Шаблоны для игнорирования при упаковке чартов Helm ├── Chart.yaml # Информация о вашем чарте ├── values.yaml # Значения по умолчанию для ваших шаблонов ├── charts/ # Чарты, от которых зависит данный чарт └── templates/ # Файлы шаблонов └── tests/ # Файлы тестов 'helm create' принимает путь в качестве аргумента. Если директории в указанном пути не существуют, Helm попытается создать их. Если указанная директория уже существует и в ней есть файлы, конфликтующие файлы будут перезаписаны, но остальные файлы останутся нетронутыми. ``` helm create NAME [flags] ``` ### Опции ``` -h, --help help for create -p, --starter string the name or absolute path to Helm starter scaffold ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- управление зависимостями чарта ### Краткое описание Управление зависимостями чарта. Чарты Helm хранят свои зависимости в каталоге 'charts/'. Для разработчиков чартов часто удобнее управлять зависимостями в файле 'Chart.yaml', в котором объявляются все зависимости. Команды для работы с зависимостями оперируют этим файлом, упрощая синхронизацию между желаемым и фактическим состоянием зависимостей в каталоге 'charts/'. Например, этот Chart.yaml объявляет две зависимости: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" Поле 'name' должно содержать имя чарта, которое должно совпадать с именем в файле 'Chart.yaml' соответствующего чарта. Поле 'version' должно содержать семантическую версию или диапазон версий. URL в поле 'repository' должен указывать на репозиторий чартов. Helm ожидает, что при добавлении '/index.yaml' к URL он сможет получить индекс репозитория чартов. Примечание: 'repository' может быть псевдонимом. Псевдоним должен начинаться с 'alias:' или '@'. Начиная с версии 2.2.0, в качестве репозитория можно указать путь к локальному каталогу, содержащему зависимые чарты. Путь должен начинаться с префикса "file://". Например: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" При использовании локального чарта добавление репозитория через команду "helm add repo" не требуется. Сопоставление версий также поддерживается в этом случае. ### Параметры ``` -h, --help help for dependency ``` ### Параметры, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](/helm/helm.md) — менеджер пакетов Helm для Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) — пересборка каталога charts/ на основе файла Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) — просмотр списка зависимостей указанного чарта * [helm dependency update](/helm/helm_dependency_update.md) — обновление каталога charts/ на основе содержимого Chart.yaml ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- пересборка каталога charts/ на основе файла Chart.lock ### Краткое описание Собирает каталог charts/ из файла Chart.lock. Команда build используется для восстановления зависимостей чарта в состояние, указанное в lock-файле. В отличие от 'helm dependency update', эта команда не пересогласовывает зависимости. Если lock-файл не найден, 'helm dependency build' будет работать аналогично 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Параметры ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Параметры, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- вывод списка зависимостей для указанного чарта ### Краткое описание Выводит все зависимости, объявленные в чарте. Команда принимает на вход как архивы чартов, так и каталоги с чартами. Содержимое чарта не изменяется. Если чарт не удаётся загрузить, команда завершится с ошибкой. ``` helm dependency list CHART [flags] ``` ### Параметры ``` -h, --help help for list --max-col-width uint maximum column width for output table (default 80) ``` ### Параметры, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- обновление каталога charts/ на основе содержимого Chart.yaml ### Краткое описание Обновляет зависимости на диске в соответствии с Chart.yaml. Эта команда проверяет, что необходимые чарты, указанные в 'Chart.yaml', присутствуют в каталоге 'charts/' и имеют допустимую версию. Команда загружает последние версии чартов, соответствующих требованиям зависимостей, и удаляет устаревшие зависимости. При успешном обновлении создаётся lock-файл, который можно использовать для восстановления зависимостей до точной версии. Чарты в каталоге charts/ не обязательно должны быть объявлены в 'Chart.yaml'. Поэтому команда обновления удалит чарт только в том случае, если он (a) указан в файле Chart.yaml, но (b) имеет неправильную версию. ``` helm dependency update CHART [flags] ``` ### Параметры ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Параметры, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm dependency](/helm/helm_dependency.md) — управление зависимостями чарта ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- информация об окружении клиента Helm ### Краткое описание Команда env выводит всю информацию об окружении, используемом Helm. ``` helm env [flags] ``` ### Опции ``` -h, --help help for env ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- получение расширенной информации об указанном релизе ### Краткое описание Эта команда состоит из нескольких подкоманд, которые можно использовать для получения расширенной информации о релизе, включая: - Значения, использованные для создания релиза - Сгенерированный файл манифеста - Заметки чарта релиза - Хуки, связанные с релизом - Метаданные релиза ### Опции ``` -h, --help help for get ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes * [helm get all](./helm_get_all.md) - получение всей информации об указанном релизе * [helm get hooks](./helm_get_hooks.md) - получение всех хуков для указанного релиза * [helm get manifest](./helm_get_manifest.md) - получение манифеста для указанного релиза * [helm get metadata](./helm_get_metadata.md) - получение метаданных для указанного релиза * [helm get notes](./helm_get_notes.md) - получение заметок для указанного релиза * [helm get values](./helm_get_values.md) - получение файла values для указанного релиза ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- получение всей информации об указанном релизе ### Краткое описание Эта команда выводит удобочитаемую сводку информации об указанном релизе, включая заметки, хуки, переданные значения и сгенерированный манифест. ``` helm get all RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- получение всех хуков для указанного релиза ### Краткое описание Эта команда получает хуки для указанного релиза. Хуки представлены в формате YAML и разделены стандартным YAML-разделителем '---\n'. ``` helm get hooks RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for hooks --revision int get the named release with revision ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- получение манифеста для указанного релиза ### Краткое описание Эта команда получает сгенерированный манифест для указанного релиза. Манифест представляет собой YAML-описание ресурсов Kubernetes, сгенерированных из чартов данного релиза. Если чарт зависит от других чартов, их ресурсы также будут включены в манифест. ``` helm get manifest RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for manifest --revision int get the named release with revision ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- получение метаданных для указанного релиза Эта команда получает метаданные для указанного релиза. ``` helm get metadata RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- получение примечаний для указанного релиза ### Краткое описание Эта команда показывает примечания, предоставленные чартом для указанного релиза. ``` helm get notes RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for notes --revision int get the named release with revision ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- получение файла values для указанного релиза ### Краткое описание Эта команда получает файл values для указанного релиза. ``` helm get values RELEASE_NAME [flags] ``` ### Опции ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm get](./helm_get.md) - получение расширенной информации об указанном релизе ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- вывод истории релиза ### Краткое описание Эта команда выводит историю ревизий для указанного релиза. По умолчанию возвращается не более 256 ревизий. Флаг '--max' позволяет настроить максимальную длину возвращаемого списка ревизий. История релиза выводится в виде форматированной таблицы, например: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for history --max int maximum number of revision to include in history (default 256) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- установка чарта ### Краткое описание Эта команда устанавливает чарт. Аргументом команды install должна быть ссылка на чарт, путь к упакованному чарту, путь к директории с распакованным чартом или URL-адрес. Чтобы переопределить значения в чарте, используйте флаг '--values' и передайте файл или используйте флаг '--set' для передачи конфигурации из командной строки. Для принудительного задания строковых значений используйте '--set-string'. Флаг '--set-file' позволяет задавать отдельные значения из файла, когда значение слишком длинное для командной строки или генерируется динамически. Также можно использовать '--set-json' для задания JSON-значений (скаляров/объектов/массивов) из командной строки. $ helm install -f myvalues.yaml myredis ./redis или $ helm install --set name=prod myredis ./redis или $ helm install --set-string long_int=1234567890 myredis ./redis или $ helm install --set-file my_script=dothings.sh myredis ./redis или $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis Флаг '--values'/'-f' можно указывать несколько раз. Приоритет отдаётся последнему (самому правому) указанному файлу. Например, если оба файла myvalues.yaml и override.yaml содержат ключ 'Test', значение из override.yaml будет иметь приоритет: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis Флаг '--set' можно указывать несколько раз. Приоритет отдаётся последнему (самому правому) указанному значению. Например, если для ключа 'foo' заданы значения 'bar' и 'newbar', значение 'newbar' будет иметь приоритет: $ helm install --set foo=bar --set foo=newbar myredis ./redis Аналогично, в следующем примере 'foo' принимает значение '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis А в следующем примере 'foo' принимает значение '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis Чтобы проверить сгенерированные манифесты релиза без фактической установки чарта, можно комбинировать флаги --debug и --dry-run. Флаг --dry-run выведет все сгенерированные манифесты чарта, включая Secrets, которые могут содержать конфиденциальные данные. Чтобы скрыть Kubernetes Secrets, используйте флаг --hide-secret. Используйте эти флаги с осторожностью. Если указан флаг --verify, чарт ДОЛЖЕН иметь файл происхождения (provenance), и этот файл ДОЛЖЕН пройти все проверки. Существует шесть различных способов указать чарт для установки: 1. По ссылке на чарт: helm install mymaria example/mariadb 2. По пути к упакованному чарту: helm install mynginx ./nginx-1.2.3.tgz 3. По пути к директории с распакованным чартом: helm install mynginx ./nginx 4. По абсолютному URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. По ссылке на чарт и URL репозитория: helm install --repo https://example.com/charts/ mynginx nginx 6. Через OCI-реестры: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx ССЫЛКИ НА ЧАРТЫ Ссылка на чарт — это удобный способ обращения к чарту в репозитории чартов. При использовании ссылки на чарт с префиксом репозитория ('example/mariadb'), Helm ищет в локальной конфигурации репозиторий чартов с именем 'example', а затем ищет в этом репозитории чарт с именем 'mariadb'. Будет установлена последняя стабильная версия чарта, если не указан флаг '--devel' для включения версий в разработке (alpha, beta и release candidate), или если не указана конкретная версия с помощью флага '--version'. Для просмотра списка репозиториев чартов используйте 'helm repo list'. Для поиска чартов в репозитории используйте 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Опции ``` --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- проверка чарта на наличие возможных проблем ### Краткое описание Эта команда принимает путь к чарту и запускает серию тестов, чтобы проверить, что чарт правильно сформирован. Если линтер обнаруживает проблемы, которые помешают установке чарта, он выводит сообщения [ERROR]. При обнаружении отклонений от соглашений или рекомендаций выводятся сообщения [WARNING]. ``` helm lint PATH [flags] ``` ### Опции ``` -h, --help help for lint --kube-version string Kubernetes version used for capabilities and deprecation checks --quiet print only warnings and errors --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-schema-validation if set, disables JSON schema validation --strict fail on lint warnings -f, --values strings specify values in a YAML file or a URL (can specify multiple) --with-subcharts lint dependent charts ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](/helm/helm.md) - менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- вывод списка релизов ### Краткое описание Эта команда выводит список всех релизов для указанного namespace (если namespace не указан, используется текущий контекст kubeconfig). По умолчанию выводятся только релизы со статусом deployed или failed. Флаги '--uninstalled' и '--all' изменяют это поведение. Эти флаги можно комбинировать: '--uninstalled --failed'. По умолчанию элементы сортируются в алфавитном порядке. Используйте флаг '-d' для сортировки по дате релиза. Если указан флаг --filter, его значение будет использоваться как фильтр. Фильтры — это регулярные выражения (Perl-совместимые), которые применяются к списку релизов. Будут возвращены только элементы, соответствующие фильтру. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 Если результаты не найдены, 'helm list' завершится с кодом 0, но без вывода (или, если флаг '-q' не указан, только с заголовками). По умолчанию возвращается не более 256 элементов. Чтобы изменить лимит, используйте флаг '--max'. Установка '--max' в 0 не вернёт все результаты. Вместо этого будет использовано значение по умолчанию сервера, которое может быть значительно больше 256. Комбинация флагов '--max' и '--offset' позволяет осуществлять постраничный вывод результатов. ``` helm list [flags] ``` ### Опции ``` -a, --all show all releases without any filter applied -A, --all-namespaces list releases across all namespaces -d, --date sort by release date --deployed show deployed releases. If no other is specified, this will be automatically enabled --failed show failed releases -f, --filter string a regular expression (Perl compatible). Any releases that match the expression will be included in the results -h, --help help for list -m, --max int maximum number of releases to fetch (default 256) --no-headers don't print headers when using the default output format --offset int next release index in the list, used to offset from start value -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pending show pending releases -r, --reverse reverse the sort order -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Works only for secret(default) and configmap storage backends. -q, --short output short (quiet) listing format --superseded show superseded releases --time-format string format time using golang time formatter. Example: --time-format "2006-01-02 15:04:05Z0700" --uninstalled show uninstalled releases (if 'helm uninstall --keep-history' was used) --uninstalling show releases that are currently being uninstalled ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- упаковка директории чарта в архив чарта ### Краткое описание Эта команда упаковывает чарт в версионированный архивный файл чарта. Если указан путь, команда будет искать чарт по этому пути (который должен содержать файл Chart.yaml) и затем упакует эту директорию. Версионированные архивы чартов используются репозиториями пакетов Helm. Для подписи чарта используйте флаг '--sign'. В большинстве случаев вам также следует указать '--keyring path/to/secret/keys' и '--key keyname'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg Если '--keyring' не указан, Helm обычно использует публичное хранилище ключей, если ваше окружение не настроено иначе. ``` helm package [CHART_PATH] [...] [flags] ``` ### Опции ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- установка, просмотр и удаление плагинов Helm ### Краткое описание Управление клиентскими плагинами Helm. ### Опции ``` -h, --help help for plugin ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm plugin install](./helm_plugin_install.md) - установка плагина Helm * [helm plugin list](./helm_plugin_list.md) - просмотр списка установленных плагинов Helm * [helm plugin uninstall](./helm_plugin_uninstall.md) - удаление одного или нескольких плагинов Helm * [helm plugin update](./helm_plugin_update.md) - обновление одного или нескольких плагинов Helm ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- установка плагина Helm Эта команда позволяет установить плагин по URL VCS-репозитория или по локальному пути. ``` helm plugin install [options] [flags] ``` ### Опции ``` -h, --help help for install --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm plugin](./helm_plugin.md) - установка, просмотр и удаление плагинов Helm ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- просмотр установленных плагинов Helm ``` helm plugin list [flags] ``` ### Опции ``` -h, --help help for list ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm plugin](./helm_plugin.md) - установка, просмотр и удаление плагинов Helm ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- удаление одного или нескольких плагинов Helm ``` helm plugin uninstall ... [flags] ``` ### Опции ``` -h, --help help for uninstall ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm plugin](./helm_plugin.md) - установка, просмотр и удаление плагинов Helm ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- обновление одного или нескольких плагинов Helm ``` helm plugin update ... [flags] ``` ### Опции ``` -h, --help help for update ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm plugin](./helm_plugin.md) - установка, просмотр и удаление плагинов Helm ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- скачивание чарта из репозитория с возможностью локальной распаковки ### Краткое описание Загружает пакет из репозитория пакетов и сохраняет его локально. Полезно для получения пакетов, чтобы изучить, изменить или перепаковать их. Также позволяет выполнить криптографическую проверку чарта без его установки. Есть опции для распаковки чарта после загрузки. При этом создаётся директория для чарта, в которую он распаковывается. Если указан флаг --verify, запрашиваемый чарт ДОЛЖЕН иметь файл provenance и ДОЛЖЕН пройти проверку. Любая ошибка приведёт к прерыванию операции, и чарт не будет сохранён локально. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- отправка чарта в реестр ### Краткое описание Загружает чарт в реестр. Если у чарта есть связанный файл provenance, он также будет загружен. ``` helm push [chart] [remote] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- вход в реестр или выход из реестра ### Краткое описание Эта команда включает несколько подкоманд для взаимодействия с реестрами. ### Опции ``` -h, --help help for registry ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm registry login](./helm_registry_login.md) - вход в реестр * [helm registry logout](./helm_registry_logout.md) - выход из реестра ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- вход в реестр ### Краткое описание Аутентификация в удалённом реестре. ``` helm registry login [host] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm registry](./helm_registry.md) - вход в реестр или выход из реестра ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- выход из реестра ### Краткое описание Удаление сохранённых учётных данных для удалённого реестра. ``` helm registry logout [host] [flags] ``` ### Опции ``` -h, --help help for logout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm registry](./helm_registry.md) - вход в реестр или выход из реестра ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ### Краткое описание Эта команда включает несколько подкоманд для работы с репозиториями чартов: добавление, удаление, просмотр списка и индексирование. ### Опции ``` -h, --help help for repo ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm repo add](./helm_repo_add.md) - добавление репозитория чартов * [helm repo index](./helm_repo_index.md) - генерация индексного файла для директории с упакованными чартами * [helm repo list](./helm_repo_list.md) - просмотр списка репозиториев чартов * [helm repo remove](./helm_repo_remove.md) - удаление одного или нескольких репозиториев чартов * [helm repo update](./helm_repo_update.md) - обновление информации о доступных чартах из репозиториев ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- добавление репозитория чартов ``` helm repo add [NAME] [URL] [flags] ``` ### Опции ``` --allow-deprecated-repos by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --force-update replace (overwrite) the repo if it already exists -h, --help help for add --insecure-skip-tls-verify skip tls certificate checks for the repository --key-file string identify HTTPS client using this SSL key file --no-update Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update. --pass-credentials pass credentials to all domains --password string chart repository password --password-stdin read chart repository password from stdin --timeout duration time to wait for the index file download to complete (default 2m0s) --username string chart repository username ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm repo](./helm_repo.md) - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- генерация индексного файла на основе директории с упакованными чартами ### Описание Сканирует текущую директорию, генерирует индексный файл на основе найденных чартов и записывает результат в файл 'index.yaml' в текущей директории. Этот инструмент используется для создания файла 'index.yaml' для репозитория чартов. Для указания абсолютного URL чартов используйте флаг '--url'. Для объединения сгенерированного индекса с существующим файлом индекса используйте флаг '--merge'. В этом случае чарты из текущей директории будут объединены с индексом, указанным в --merge. Локальные чарты имеют приоритет над существующими. ``` helm repo index [DIR] [flags] ``` ### Опции ``` -h, --help help for index --json output in JSON format --merge string merge the generated index into the given index --url string url of chart repository ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm repo](./helm_repo.md) - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- вывод списка репозиториев чартов ``` helm repo list [flags] ``` ### Опции ``` -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm repo](./helm_repo.md) - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- удаление одного или нескольких репозиториев чартов ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Опции ``` -h, --help help for remove ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm repo](./helm_repo.md) - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- обновление локальной информации о доступных чартах из репозиториев ### Краткое описание Команда update получает актуальную информацию о чартах из соответствующих репозиториев. Информация кешируется локально и используется такими командами, как 'helm search'. Вы можете указать список репозиториев, которые хотите обновить. $ helm repo update ... Чтобы обновить все репозитории, используйте 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Опции ``` --fail-on-repo-update-fail update fails if any of the repository updates fail -h, --help help for update --timeout duration time to wait for the index file download to complete (default 2m0s) ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm repo](./helm_repo.md) - добавление, просмотр, удаление, обновление и индексирование репозиториев чартов ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- откат релиза к предыдущей ревизии ### Краткое описание Эта команда откатывает релиз к предыдущей ревизии. Первым аргументом команды rollback является имя релиза, вторым — номер ревизии (версии). Если этот аргумент опущен или установлен в 0, откат будет выполнен к предыдущему релизу. Чтобы увидеть номера ревизий, выполните 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Опции ``` --cleanup-on-fail allow deletion of new resources created in this rollback when rollback fails --dry-run simulate a rollback --force force resource update through delete/recreate if needed -h, --help help for rollback --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --no-hooks prevent hooks from running during rollback --recreate-pods performs pods restart for the resource if applicable --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- поиск по ключевому слову в чартах ### Краткое описание Search позволяет искать Helm чарты в разных местах их хранения, включая Artifact Hub и добавленные вами репозитории. Используйте подкоманды search для поиска чартов в разных источниках. ### Опции ``` -h, --help help for search ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm search hub](./helm_search_hub.md) - поиск чартов в Artifact Hub или вашем собственном экземпляре hub * [helm search repo](./helm_search_repo.md) - поиск чартов по ключевому слову в репозиториях ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- поиск чартов в Artifact Hub или вашем собственном экземпляре hub ### Краткое описание Эта команда выполняет поиск Helm чартов в Artifact Hub или вашем собственном экземпляре hub. Artifact Hub — это веб-приложение для поиска, установки и публикации пакетов и конфигураций для проектов CNCF, включая публично доступные Helm чарты. Это проект-песочница Cloud Native Computing Foundation. Вы можете просмотреть hub по адресу https://artifacthub.io/ В качестве аргумента [KEYWORD] можно указать строку ключевого слова или строку в кавычках с расширенными параметрами запроса. Документацию по расширенным параметрам запроса см. на https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Предыдущие версии Helm использовали экземпляр Monocular в качестве значения по умолчанию для 'endpoint'. Для обратной совместимости Artifact Hub поддерживает API поиска Monocular. При установке флага 'endpoint' указанная конечная точка также должна реализовывать совместимый с Monocular API поиска. Обратите внимание: при указании экземпляра Monocular в качестве 'endpoint' расширенные запросы не поддерживаются. Подробности см. на https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Опции ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm search](./helm_search.md) - поиск по ключевому слову в чартах ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- поиск чартов по ключевому слову в репозиториях ### Краткое описание Эта команда просматривает все репозитории, настроенные в системе, и ищет совпадения. Поиск по этим репозиториям использует метаданные, сохранённые в системе. Команда отображает последние стабильные версии найденных чартов. При указании флага --devel в результаты будут включены предварительные версии. Для поиска с ограничением версии используйте флаг --version. Примеры: # Поиск стабильных версий по ключевому слову "nginx" $ helm search repo nginx # Поиск версий по ключевому слову "nginx", включая предварительные версии $ helm search repo nginx --devel # Поиск последней стабильной версии nginx-ingress с мажорной версией 1 $ helm search repo nginx-ingress --version ^1.0.0 Репозитории управляются командами 'helm repo'. ``` helm search repo [keyword] [flags] ``` ### Опции ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm search](./helm_search.md) - поиск по ключевому слову в чартах ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- отображение информации о чарте ### Краткое описание Эта команда состоит из нескольких подкоманд для отображения информации о чарте ### Опции ``` -h, --help help for show ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - менеджер пакетов Helm для Kubernetes. * [helm show all](./helm_show_all.md) - показать всю информацию о чарте * [helm show chart](./helm_show_chart.md) - показать определение чарта * [helm show crds](./helm_show_crds.md) - показать CRD чарта * [helm show readme](./helm_show_readme.md) - показать README чарта * [helm show values](./helm_show_values.md) - показать values чарта ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- показать всю информацию о чарте ### Краткое описание Эта команда анализирует чарт (директорию, файл или URL) и отображает всё его содержимое (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm show](./helm_show.md) - отображение информации о чарте ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- показать определение чарта ### Краткое описание Эта команда анализирует чарт (директорию, файл или URL) и отображает содержимое файла Chart.yaml ``` helm show chart [CHART] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm show](./helm_show.md) - отображение информации о чарте ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- показать CRD чарта ### Краткое описание Эта команда анализирует чарт (директорию, файл или URL) и отображает содержимое файлов CustomResourceDefinition ``` helm show crds [CHART] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm show](./helm_show.md) - отображение информации о чарте ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- показать README чарта ### Краткое описание Эта команда анализирует чарт (директорию, файл или URL) и отображает содержимое файла README ``` helm show readme [CHART] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm show](./helm_show.md) - отображение информации о чарте ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- показать значения чарта ### Краткое описание Эта команда анализирует чарт (директорию, файл или URL) и отображает содержимое файла values.yaml ``` helm show values [CHART] [flags] ``` ### Опции ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm show](./helm_show.md) - отображение информации о чарте ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- отображение статуса указанного релиза ### Краткое описание Эта команда отображает статус указанного релиза. Статус включает: - время последнего развёртывания - namespace Kubernetes, в котором находится релиз - состояние релиза (возможные значения: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade или pending-rollback) - ревизия релиза - описание релиза (может быть сообщением о завершении или сообщением об ошибке, требуется флаг --show-desc) - список ресурсов данного релиза (требуется флаг --show-resources) - результаты последнего тестирования, если применимо - дополнительные примечания, предоставленные чартом ``` helm status RELEASE_NAME [flags] ``` ### Опции ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision --show-desc if set, display the description message of the named release --show-resources if set, display the resources of the named release ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- локальный рендеринг шаблонов ### Краткое описание Рендеринг шаблонов чарта локально с выводом результата. Значения, которые обычно запрашиваются из кластера, будут эмулированы локально. Серверная проверка валидности чарта также не выполняется (например, проверка поддержки конкретного API). ``` helm template [NAME] [CHART] [flags] ``` ### Опции ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- запуск тестов для релиза ### Краткое описание Команда test запускает тесты для релиза. Команда принимает в качестве аргумента имя развёрнутого релиза. Тесты, которые будут запущены, определены в установленном чарте. ``` helm test [RELEASE] [flags] ``` ### Опции ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --hide-notes if set, do not show notes in test output. Does not affect presence in chart metadata --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- удаление релиза ### Краткое описание Эта команда принимает имя релиза и удаляет его. Она удаляет все ресурсы, связанные с последним релизом чарта, а также историю релиза, освобождая имя для повторного использования. Используйте флаг '--dry-run', чтобы увидеть, какие релизы будут удалены, без фактического удаления. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Опции ``` --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run simulate a uninstall -h, --help help for uninstall --ignore-not-found Treat "release not found" as a successful uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --no-hooks prevent hooks from running during uninstallation --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- обновление релиза до новой версии чарта ### Краткое описание Эта команда обновляет релиз до новой версии чарта. Аргументами команды upgrade должны быть релиз и чарт. Аргумент чарта может быть: ссылкой на чарт ('example/mariadb'), путём к директории с чартом, упакованным чартом или полным URL-адресом. Если не указан флаг '--version', будет использоваться последняя версия чарта. Чтобы переопределить значения в чарте, используйте флаг '--values' и передайте файл или используйте флаг '--set' для передачи конфигурации из командной строки. Для принудительного задания строковых значений используйте '--set-string'. Флаг '--set-file' позволяет задавать отдельные значения из файла, когда значение слишком длинное для командной строки или генерируется динамически. Также можно использовать '--set-json' для задания JSON-значений (скаляров/объектов/массивов) из командной строки. Флаг '--values'/'-f' можно указывать несколько раз. Приоритет отдаётся последнему (самому правому) указанному файлу. Например, если оба файла myvalues.yaml и override.yaml содержат ключ 'Test', значение из override.yaml будет иметь приоритет: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Флаг '--set' можно указывать несколько раз. Приоритет отдаётся последнему (самому правому) указанному значению. Например, если для ключа 'foo' заданы значения 'bar' и 'newbar', значение 'newbar' будет иметь приоритет: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis С помощью этой команды также можно обновить значения существующего релиза, используя флаг '--reuse-values'. Аргументы 'RELEASE' и 'CHART' должны соответствовать исходным параметрам, и существующие значения будут объединены со значениями, указанными через флаги '--values'/'-f' или '--set'. Приоритет отдаётся новым значениям. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis Флаг --dry-run выведет все сгенерированные манифесты чарта, включая Secrets, которые могут содержать конфиденциальные данные. Чтобы скрыть Kubernetes Secrets, используйте флаг --hide-secret. Используйте эти флаги с осторожностью. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Опции ``` --atomic if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- проверка подписи и валидности чарта по указанному пути ### Краткое описание Проверяет, что указанный чарт имеет действительный файл происхождения (provenance). Файлы происхождения обеспечивают криптографическую проверку того, что чарт не был изменён и упакован доверенным поставщиком. Эту команду можно использовать для проверки локального чарта. У некоторых других команд есть флаг '--verify', который выполняет ту же проверку. Чтобы создать подписанный пакет, используйте команду 'helm package --sign'. ``` helm verify PATH [flags] ``` ### Опции ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- вывод информации о версии клиента ### Краткое описание Показывает версию Helm. Эта команда выводит информацию о версии Helm. Вывод будет выглядеть примерно так: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version — это семантическая версия релиза. - GitCommit — это SHA коммита, из которого была собрана эта версия. - GitTreeState имеет значение "clean", если при сборке бинарного файла не было локальных изменений кода, и "dirty", если бинарный файл был собран из локально изменённого кода. - GoVersion — это версия Go, которая использовалась для компиляции Helm. При использовании флага --template доступны следующие свойства для использования в шаблоне: - .Version содержит семантическую версию Helm - .GitCommit — это git-коммит - .GitTreeState — это состояние git-дерева на момент сборки Helm - .GoVersion содержит версию Go, с которой был скомпилирован Helm Например, --template='Version: {{.Version}}' выведет 'Version: v3.2.1'. ``` helm version [flags] ``` ### Опции ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### Опции, унаследованные от родительских команд ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### Смотрите также * [helm](./helm.md) - Менеджер пакетов Helm для Kubernetes. ###### Автоматически сгенерировано spf13/cobra 14-Jan-2026 ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Команды Helm description: Документация по полному списку команд CLI Helm. sidebar_position: 6 id: helm-category --- # Команды Helm Здесь вы найдёте список команд CLI для Helm со справочной информацией по их использованию. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action для автоматизации публикации чартов на GitHub Pages description: Как использовать Chart Releaser Action для автоматической публикации чартов через GitHub Pages. sidebar_position: 3 --- Это руководство описывает, как использовать [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) для автоматической публикации чартов через GitHub Pages. Chart Releaser Action — это GitHub Action, который превращает проект GitHub в собственный репозиторий Helm-чартов с помощью CLI-инструмента [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Изменения в репозитории Создайте Git-репозиторий в вашей организации GitHub. Вы можете назвать репозиторий `helm-charts`, хотя допустимы и другие имена. Исходные файлы всех чартов можно разместить в ветке `main`. Чарты должны находиться в каталоге `/charts` в корне дерева каталогов. Также необходима отдельная ветка `gh-pages` для публикации чартов. Изменения в этой ветке будут автоматически создаваться Chart Releaser Action, описанным здесь. Однако вы можете создать ветку `gh-pages` и добавить файл `README.md`, который будет виден пользователям, посещающим страницу. Вы можете добавить инструкции по установке чартов в `README.md` следующим образом (замените ``, `` и ``): ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` Чарты будут опубликованы на сайте с URL вида: https://.github.io/helm-charts ## Рабочий процесс GitHub Actions Создайте файл рабочего процесса GitHub Actions в ветке `main` по пути `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` Эта конфигурация использует [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), чтобы превратить ваш проект GitHub в собственный репозиторий Helm-чартов. При каждом push в ветку `main` он проверяет все чарты в проекте и при обнаружении новой версии чарта выполняет следующие действия: - Создаёт GitHub-релиз с именем, соответствующим версии чарта - Добавляет артефакты Helm-чарта к релизу - Создаёт или обновляет файл `index.yaml` с метаданными об этих релизах Файл `index.yaml` затем размещается на GitHub Pages. В примере выше используется Chart Releaser Action версии `v1.6.0`. Вы можете заменить её на [последнюю доступную версию](https://github.com/helm/chart-releaser-action/releases). Примечание: Chart Releaser Action почти всегда используется совместно с [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) и [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Синхронизация репозитория чартов description: Как синхронизировать локальный и удалённый репозитории чартов. sidebar_position: 2 --- *Примечание: этот пример предназначен специально для бакета Google Cloud Storage (GCS), используемого в качестве репозитория чартов.* ## Предварительные требования * Установите инструмент [gsutil](https://cloud.google.com/storage/docs/gsutil). *Основная часть работы выполняется через gsutil rsync* * Убедитесь, что Helm установлен и доступен * _Опционально: мы рекомендуем включить [версионирование объектов](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) в вашем GCS-бакете на случай случайного удаления данных._ ## Настройка локального каталога репозитория чартов Создайте локальный каталог, как описано в [руководстве по репозиториям чартов](/topics/chart_repository.md), и поместите в него упакованные чарты. Например: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Генерация обновлённого index.yaml Используйте Helm для генерации обновлённого файла index.yaml, передав путь к каталогу и URL удалённого репозитория команде `helm repo index`: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Эта команда сгенерирует обновлённый файл index.yaml и поместит его в каталог `fantastic-charts/`. ## Синхронизация локального и удалённого репозиториев чартов Загрузите содержимое каталога в ваш GCS-бакет, запустив скрипт `scripts/sync-repo.sh` с указанием имени локального каталога и имени GCS-бакета. Например: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Обновление репозитория чартов Храните локальную копию содержимого вашего репозитория чартов или используйте `gsutil rsync` для копирования содержимого удалённого репозитория чартов в локальный каталог. Например: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Полезные ссылки: * Документация по [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Руководство по репозиториям чартов](/topics/chart_repository.md) * Документация по [версионированию объектов и управлению конкурентным доступом](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) в Google Cloud Storage ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Советы и приёмы при разработке чартов description: Описание советов и приёмов, которые разработчики чартов Helm освоили при создании чартов производственного качества. sidebar_position: 1 --- В этом руководстве описаны советы и приёмы, которые разработчики чартов Helm освоили при создании чартов производственного качества. ## Знайте свои функции шаблонов Helm использует [Go templates](https://godoc.org/text/template) для шаблонизации ваших файлов ресурсов. Хотя Go включает несколько встроенных функций, мы добавили множество других. Во-первых, мы добавили все функции из [библиотеки Sprig](https://masterminds.github.io/sprig/), за исключением `env` и `expandenv` по соображениям безопасности. Также мы добавили две специальные функции шаблонов: `include` и `required`. Функция `include` позволяет подключить другой шаблон, а затем передать результат другим функциям шаблонов. Например, этот фрагмент шаблона подключает шаблон `mytpl`, приводит результат к нижнему регистру, а затем оборачивает его в двойные кавычки. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` Функция `required` позволяет объявить определённое значение как обязательное для рендеринга шаблона. Если значение пустое, рендеринг шаблона завершится с ошибкой, содержащей сообщение, указанное пользователем. Следующий пример функции `required` объявляет запись `.Values.who` как обязательную и выводит сообщение об ошибке, если эта запись отсутствует: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Оборачивайте строки в кавычки, не оборачивайте целые числа При работе со строковыми данными всегда безопаснее оборачивать строки в кавычки, чем оставлять их без кавычек: ```yaml name: {{ .Values.MyName | quote }} ``` Но при работе с целыми числами _не оборачивайте значения в кавычки._ Это может во многих случаях вызвать ошибки парсинга в Kubernetes. ```yaml port: {{ .Values.Port }} ``` Это замечание не относится к значениям переменных окружения, которые ожидаются как строки, даже если представляют собой числа: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Использование функции 'include' Go предоставляет способ подключения одного шаблона в другой с помощью встроенной директивы `template`. Однако встроенную функцию нельзя использовать в конвейерах Go templates. Чтобы сделать возможным подключение шаблона и последующее выполнение операции над его выводом, Helm предоставляет специальную функцию `include`: ``` {{ include "toYaml" $value | indent 2 }} ``` Приведённый выше код подключает шаблон `toYaml`, передаёт ему `$value`, а затем передаёт вывод этого шаблона функции `indent`. Поскольку YAML придаёт значение уровням отступов и пробелам, это отличный способ подключать фрагменты кода с правильной обработкой отступов в нужном контексте. ## Использование функции 'required' Go позволяет устанавливать параметры шаблона для управления поведением при обращении к map с ключом, который в ней отсутствует. Обычно это делается с помощью `template.Options("missingkey=option")`, где `option` может быть `default`, `zero` или `error`. Установка этого параметра в значение error остановит выполнение с ошибкой, но это будет применяться к каждому отсутствующему ключу в map. Могут возникать ситуации, когда разработчик чарта хочет применить такое поведение к определённым значениям в файле `values.yaml`. Функция `required` позволяет разработчикам объявлять значение как обязательное для рендеринга шаблона. Если запись пуста в `values.yaml`, шаблон не будет отрендерен и вернёт сообщение об ошибке, указанное разработчиком. Пример: ``` {{ required "A valid foo is required!" .Values.foo }} ``` Приведённый выше код отрендерит шаблон, когда `.Values.foo` определена, но не сможет отрендерить его и завершится с ошибкой, когда `.Values.foo` не определена. ## Использование функции 'tpl' Функция `tpl` позволяет разработчикам вычислять строки как шаблоны внутри шаблона. Это полезно для передачи строки шаблона в качестве значения чарту или для рендеринга внешних конфигурационных файлов. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}` Примеры: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Рендеринг внешнего конфигурационного файла: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Создание Image Pull Secrets Image pull secrets — это комбинация _registry_, _username_ и _password_. Они могут понадобиться в развёртываемом приложении, но для их создания необходимо несколько раз выполнить кодирование `base64`. Можно написать вспомогательный шаблон, который создаст конфигурационный файл Docker для использования в Secret. Вот пример: Сначала предположим, что учётные данные определены в файле `values.yaml` следующим образом: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Затем мы определяем вспомогательный шаблон следующим образом: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Наконец, мы используем вспомогательный шаблон в более крупном шаблоне для создания манифеста Secret: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Автоматический перезапуск Deployment Часто ConfigMap или Secret внедряются как конфигурационные файлы в контейнеры, или есть другие изменения внешних зависимостей, требующие перезапуска подов. В зависимости от приложения при последующем `helm upgrade` может потребоваться перезапуск, но если спецификация deployment не изменилась, приложение продолжит работать со старой конфигурацией, что приведёт к несогласованному развёртыванию. Функцию `sha256sum` можно использовать для обновления секции аннотаций deployment при изменении другого файла: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` ПРИМЕЧАНИЕ: Если вы добавляете это в библиотечный чарт, вы не сможете получить доступ к вашему файлу через `$.Template.BasePath`. Вместо этого вы можете сослаться на ваше определение с помощью `{{ include ("mylibchart.configmap") . | sha256sum }}`. Если вы хотите, чтобы ваш deployment всегда перезапускался, можно использовать аналогичную аннотацию, заменив значение случайной строкой, чтобы оно всегда менялось и вызывало перезапуск deployment: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Каждый вызов функции шаблона будет генерировать уникальную случайную строку. Это означает, что если необходимо синхронизировать случайные строки, используемые файле шаблона. Оба эти метода позволяют вашему Deployment использовать встроенную логику стратегии обновления для избежания простоев. ПРИМЕЧАНИЕ: Ранее мы рекомендовали использовать флаг `--recreate-pods` как альтернативный вариант. Этот флаг был помечен как устаревший в Helm 3 в пользу более декларативного метода, описанного выше. ## Запрет удаления ресурса при деинсталляции Иногда есть ресурсы, которые не должны удаляться при выполнении `helm uninstall`. Разработчики чартов могут добавить аннотацию к ресурсу, чтобы предотвратить его удаление. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` Аннотация `helm.sh/resource-policy: keep` указывает Helm пропустить удаление этого ресурса при операции helm (например, `helm uninstall`, `helm upgrade` или `helm rollback`), которая привела бы к его удалению. _Однако_ этот ресурс становится осиротевшим. Helm больше не будет им управлять. Это может привести к проблемам при использовании `helm install --replace` для релиза, который был удалён, но сохранил ресурсы. ## Использование «Partials» и подключение шаблонов Иногда требуется создать переиспользуемые части в чарте — блоки или частичные шаблоны. Часто удобнее хранить их в отдельных файлах. В директории `templates/` любой файл, начинающийся с подчёркивания (`_`), не будет выводиться как манифест Kubernetes. По соглашению вспомогательные шаблоны и partials размещаются в файле `_helpers.tpl`. ## Сложные чарты с множеством зависимостей Многие чарты в [Artifact Hub](https://artifacthub.io/packages/search?kind=0) CNCF являются «строительными блоками» для создания более сложных приложений. Но чарты также могут использоваться для создания экземпляров крупномасштабных приложений. В таких случаях один зонтичный чарт может иметь несколько подчартов, каждый из которых функционирует как часть целого. Текущая лучшая практика для создания сложного приложения из отдельных частей — создать зонтичный чарт верхнего уровня, который предоставляет глобальные конфигурации, и использовать поддиректорию `charts/` для встраивания каждого из компонентов. ## YAML — это надмножество JSON Согласно спецификации YAML, YAML является надмножеством JSON. Это означает, что любая допустимая структура JSON должна быть допустимой в YAML. Это даёт преимущество: иногда разработчикам шаблонов может быть проще выразить структуру данных с помощью JSON-подобного синтаксиса, чем работать с чувствительностью YAML к пробелам. В качестве лучшей практики шаблоны должны следовать YAML-подобному синтаксису, _если только_ синтаксис JSON существенно не снижает риск проблем с форматированием. ## Будьте осторожны при генерации случайных значений В Helm есть функции для генерации случайных данных, криптографических ключей и т.д. Их можно использовать. Но имейте в виду, что при обновлениях шаблоны выполняются повторно. Когда выполнение шаблона генерирует данные, отличающиеся от предыдущего выполнения, это вызовет обновление этого ресурса. ## Установка или обновление релиза одной командой Helm предоставляет возможность выполнить установку или обновление одной командой. Используйте `helm upgrade` с флагом `--install`. Это заставит Helm проверить, установлен ли уже релиз. Если нет — будет выполнена установка. Если да — существующий релиз будет обновлён. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: Практические руководства sidebar_position: 2 --- # Практические руководства Здесь вы найдёте краткие ответы на вопросы типа «Как мне…?». Эти практические руководства не рассматривают темы углублённо — подробный материал вы найдёте в [Тематических руководствах](/topics/index.mdx). Однако эти руководства помогут вам быстро выполнить типичные задачи. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Документация Главная" description: "Все то, что вам необходимо знать о том, как организована документация." --- # Добро пожаловать Добро пожаловать в документацию по [Helm](https://helm.sh/). Helm – это менеджер пакетов Kubernetes. Подробную справочную информацию можно прочитать в отчете [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). # Как организована документация У Helm много документации. Обзор поможет узнать, где искать необходимую информацию - [Обучающие материалы](https://helm.sh/docs/intro) проведут вас за руку через ряд шагов, которые помогут создать первый Helm chart Начните с этого, если вы новичок в Helm. - [Тематические руководства](https://helm.sh/docs/topics) обсуждают ключевые темы и концепции на достаточно высоком уровне, предоставляют полезную справочную информацию и разъяснения. - [Путеводители сообщества](/community) обсуждают темы, сосредоточенные вокруг Helm сообщества. Начните отсюда, если вы хотите узнать больше о процессе разработки самого Helm и о том, как вы можете внести свой вклад. - [Инструкции по применению](https://helm.sh/docs/howto) это готовые советы по использованию. Они проведут вас через шаги, связанные с решением ключевых проблем и вариантов их разрешения. Инструкции по применению более продвинуты, чем [обучающие материалы](https://helm.sh/docs/intro), и предлагают некоторые расширенные знания о том, как работает Helm. --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Шпаргалка description: Шпаргалка по Helm sidebar_position: 4 --- Шпаргалка Helm со всеми командами, необходимыми для управления приложениями. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Основные термины Chart: - Это имя вашего чарта, если он был загружен и распакован. - Это <имя_репозитория>/<имя_чарта>, если репозиторий был добавлен, но чарт не загружен. - Это URL или абсолютный путь к чарту. Name: - Это имя, которое вы хотите присвоить текущей установке чарта Helm. Release: - Это имя, которое вы присвоили экземпляру установки. Revision: - Это значение из вывода команды `helm history`. Repo-name: - Имя репозитория. DIR: - Имя директории или путь к ней. ------------------------------------------------------------------------------------------------------------------------------------------------ ### Управление чартами ```bash helm create # Создаёт директорию чарта вместе с общими файлами и директориями, используемыми в чарте. helm package # Упаковывает чарт в версионированный архивный файл. helm lint # Запускает тесты для проверки чарта и выявления возможных проблем. helm show all # Проверяет чарт и выводит его содержимое. helm show values # Отображает содержимое файла values.yaml. helm pull # Скачивает чарт. helm pull --untar=true # Если true, распаковывает чарт после скачивания. helm pull --verify # Проверяет пакет перед использованием. helm pull --version # По умолчанию используется последняя версия; указывает ограничение версии чарта. helm dependency list # Отображает список зависимостей чарта. ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Установка и удаление приложений ```bash helm install # Устанавливает чарт с указанным именем. helm install --namespace # Устанавливает чарт в указанное пространство имён. helm install --set key1=val1,key2=val2 # Задаёт значения в командной строке (можно указать несколько значений через запятую). helm install --values # Устанавливает чарт с указанными значениями. helm install --dry-run --debug # Запускает тестовую установку для проверки чарта. helm install --verify # Проверяет пакет перед использованием. helm install --dependency-update # Обновляет зависимости, если они отсутствуют, перед установкой чарта. helm uninstall # Удаляет релиз из текущего (по умолчанию) пространства имён. helm uninstall --namespace # Удаляет релиз из указанного пространства имён. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Обновление и откат приложений ```bash helm upgrade # Обновляет релиз. helm upgrade --rollback-on-failure # При неудачном обновлении откатывает внесённые изменения. helm upgrade --dependency-update # Обновляет зависимости, если они отсутствуют, перед установкой чарта. helm upgrade --version # Указывает ограничение версии чарта. helm upgrade --values # Указывает значения в YAML-файле или по URL (можно указать несколько). helm upgrade --set key1=val1,key2=val2 # Задаёт значения в командной строке (можно указать несколько значений через запятую). helm upgrade --force # Принудительно обновляет ресурсы через стратегию замены. helm rollback # Откатывает релиз к указанной ревизии. helm rollback --cleanup-on-fail # Позволяет удалить новые ресурсы, созданные при откате, если откат не удался. ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Работа с репозиториями ```bash helm repo add # Добавляет репозиторий из интернета. helm repo list # Выводит список добавленных репозиториев чартов. helm repo update # Обновляет локальную информацию о доступных чартах из репозиториев. helm repo remove # Удаляет один или несколько репозиториев чартов. helm repo index # Читает текущую директорию и генерирует индексный файл на основе найденных чартов. helm repo index --merge # Объединяет сгенерированный индекс с существующим индексным файлом. helm search repo # Ищет чарты по ключевому слову в репозиториях. helm search hub # Ищет чарты в Artifact Hub или вашем собственном хабе. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Мониторинг релизов Helm ```bash helm list # Выводит все релизы для указанного пространства имён; использует текущий контекст, если пространство имён не указано. helm list --all # Показывает все релизы без фильтров (можно использовать -a). helm list --all-namespaces # Выводит релизы из всех пространств имён (можно использовать -A). helm list -l key1=value1,key2=value2 # Селектор (запрос по меткам) для фильтрации; поддерживает '=', '==' и '!='. helm list --date # Сортирует по дате релиза. helm list --deployed # Показывает развёрнутые релизы. Включается автоматически, если не указано иное. helm list --pending # Показывает ожидающие релизы. helm list --failed # Показывает неудавшиеся релизы. helm list --uninstalled # Показывает удалённые релизы (если использовался 'helm uninstall --keep-history'). helm list --superseded # Показывает замещённые релизы. helm list -o yaml # Выводит результат в указанном формате. Допустимые значения: table, json, yaml (по умолчанию table). helm status # Показывает статус указанного релиза. helm status --revision # Показывает статус указанного релиза с определённой ревизией. helm history # Показывает историю ревизий для указанного релиза. helm env # Выводит всю информацию об окружении, используемую Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Получение информации о релизе ```bash helm get all # Выводит удобочитаемую информацию о заметках, хуках, переданных значениях и сгенерированном манифесте релиза. helm get hooks # Скачивает хуки для указанного релиза. Хуки форматируются в YAML и разделяются разделителем '---\n'. helm get manifest # Манифест — это YAML-представление ресурсов Kubernetes, сгенерированных из чарта(ов) релиза. Включает ресурсы зависимых чартов. helm get notes # Показывает заметки, предоставленные чартом указанного релиза. helm get values # Скачивает файл значений для указанного релиза. Используйте -o для форматирования вывода. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Управление плагинами ```bash helm plugin install # Устанавливает плагины. helm plugin list # Показывает список всех установленных плагинов. helm plugin update # Обновляет плагины. helm plugin uninstall # Удаляет плагин. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: Введение sidebar_position: 1 --- # Введение в Helm Вы новичок в Helm? Это самое подходящее место для начала! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Установка Helm description: Узнайте, как установить и начать работать с Helm. sidebar_position: 2 --- В этом руководстве описывается, как установить CLI Helm. Helm можно установить из исходного кода или из предварительно собранных бинарных файлов. ## Из проекта Helm Проект Helm предоставляет два способа получения и установки Helm. Это официальные методы получения релизов Helm. Помимо этого, сообщество Helm предоставляет методы установки через различные менеджеры пакетов. Установка с помощью этих методов описана ниже. ### Из бинарных релизов Каждый [релиз](https://github.com/helm/helm/releases) Helm предоставляет бинарные файлы для различных операционных систем. Эти бинарные версии можно загрузить и установить вручную. 1. Скачайте нужную вам [версию](https://github.com/helm/helm/releases) 2. Распакуйте её (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Найдите бинарный файл `helm` в распакованной директории и переместите его в нужное место (`mv linux-amd64/helm /usr/local/bin/helm`) После этого вы сможете запустить клиент и [добавить репозиторий чартов stable](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Примечание:** Автоматические тесты Helm выполняются только для Linux AMD64 во время сборок и релизов в GitHub Actions. Тестирование на других ОС является обязанностью сообщества, использующего Helm на этих системах. ### Из скрипта Helm теперь имеет скрипт установки, который автоматически загружает последнюю версию Helm и [устанавливает её локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Вы можете скачать этот скрипт и затем выполнить его локально. Он хорошо документирован, так что вы можете прочитать его и понять, что он делает, прежде чем запускать. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Да, вы можете выполнить `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`, если хотите рискнуть. ## Через менеджеры пакетов Сообщество Helm предоставляет возможность установки Helm через менеджеры пакетов операционной системы. Они не поддерживаются проектом Helm и не считаются доверенными сторонними источниками. ### Используя Homebrew (macOS) Участники сообщества Helm добавили формулу Helm в Homebrew. Эта формула обычно актуальна. ```console brew install helm ``` (Примечание: Существует также формула для emacs-helm — это другой проект.) ### Используя Chocolatey (Windows) Участники сообщества Helm добавили [пакет Helm](https://chocolatey.org/packages/kubernetes-helm) в [Chocolatey](https://chocolatey.org/). Этот пакет обычно актуален. ```console choco install kubernetes-helm ``` ### Используя Scoop (Windows) Участники сообщества Helm добавили [пакет Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) в [Scoop](https://scoop.sh). Этот пакет обычно актуален. ```console scoop install helm ``` ### Используя Winget (Windows) Участники сообщества Helm добавили [пакет Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) в [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Этот пакет обычно актуален. ```console winget install Helm.Helm ``` ### Используя Apt (Debian/Ubuntu) Участники сообщества Helm добавили пакет Apt для Debian/Ubuntu. Этот пакет обычно актуален. Благодарим [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) за хостинг репозитория. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Используя dnf/yum (Fedora) Начиная с Fedora 35, Helm доступен в официальном репозитории. Вы можете установить Helm, выполнив: ```console sudo dnf install helm ``` ### Используя Snap Сообщество [Snapcrafters](https://github.com/snapcrafters) поддерживает Snap-версию [пакета Helm](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### Используя pkg (FreeBSD) Участники сообщества FreeBSD добавили [пакет Helm](https://www.freshports.org/sysutils/helm) в [FreeBSD Ports Collection](https://man.freebsd.org/ports). Этот пакет обычно актуален. ```console pkg install helm ``` ### Сборки для разработчиков Помимо релизов вы можете скачать или установить сборки для разработки Helm. ### Canary-сборки Canary-сборки — это версии программного обеспечения Helm, собранные из последней ветки `main`. Они не являются официальными релизами и могут быть нестабильными. Тем не менее, они позволяют протестировать новейшие функции. Бинарные файлы Canary Helm хранятся на `get.helm.sh`. Вот ссылки на распространённые сборки: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Из исходного кода (Linux, macOS) Сборка Helm из исходного кода требует немного больше усилий, но это лучший способ, если вы хотите протестировать последнюю (предрелизную) версию Helm. У вас должна быть настроена рабочая среда Go. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` При необходимости скрипт загружает зависимости, кэширует их и проверяет конфигурацию. Затем он скомпилирует `helm` и поместит его в `bin/helm`. ## Заключение В большинстве случаев установка сводится к получению предварительно собранного бинарного файла `helm`. В этом документе описаны дополнительные варианты для тех, кто хочет делать с Helm более сложные вещи. После успешной установки клиента Helm вы можете перейти к использованию Helm для управления чартами и [добавить репозиторий чартов stable](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Краткое руководство description: Как установить и начать работу с Helm, включая инструкции для дистрибутивов, FAQ и плагины. sidebar_position: 1 --- Это руководство описывает, как быстро начать использовать Helm. ## Предварительные требования Для успешного и безопасного использования Helm необходимо: 1. Кластер Kubernetes 2. Определение настроек безопасности для вашей установки (если требуется) 3. Установка и настройка Helm ### Установите Kubernetes или получите доступ к кластеру - У вас должен быть установлен Kubernetes. Для последней версии Helm мы рекомендуем последнюю стабильную версию Kubernetes, которая в большинстве случаев является предпоследней минорной версией. - Также у вас должна быть локально настроенная копия `kubectl`. Смотрите [Политику поддержки версий Helm](https://helm.sh/docs/topics/version_skew/), чтобы узнать максимально допустимое расхождение версий между Helm и Kubernetes. ## Установка Helm Загрузите бинарный релиз клиента Helm. Вы можете использовать такие инструменты, как `homebrew`, или посмотреть [официальную страницу релизов](https://github.com/helm/helm/releases). Для получения более подробной информации или других вариантов смотрите [руководство по установке](/intro/install.md). ## Инициализация репозитория чартов Helm После установки Helm вы можете добавить репозиторий чартов. Смотрите [Artifact Hub](https://artifacthub.io/packages/search?kind=0) для поиска доступных репозиториев чартов Helm. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` После этого вы сможете посмотреть список чартов, которые можно установить: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Пример установки чарта Чтобы установить чарт, используйте команду `helm install`. У Helm есть несколько способов найти и установить чарт, но самый простой — использовать чарты `bitnami`. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` В приведённом выше примере был установлен чарт `bitnami/mysql`, а имя нашего нового релиза — `mysql-1612624192`. Чтобы получить представление о возможностях этого чарта MySQL, выполните команду `helm show chart bitnami/mysql`. Или выполните `helm show all bitnami/mysql`, чтобы получить всю информацию о чарте. При каждой установке чарта создаётся новый релиз. Таким образом, один чарт можно установить несколько раз в один и тот же кластер. И каждый из них может управляться и обновляться независимо. Команда `helm install` очень мощная и имеет множество возможностей. Чтобы узнать больше, смотрите [Руководство по использованию Helm](/intro/using_helm.md). ## Информация о релизах С помощью Helm легко увидеть, что было развёрнуто: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` Функция `helm list` (или `helm ls`) покажет вам список всех развёрнутых релизов. ## Удаление релиза Чтобы удалить релиз, используйте команду `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Эта команда удалит `mysql-1612624192` из Kubernetes, а также удалит все ресурсы, связанные с этим релизом, и историю релизов. Если указать флаг `--keep-history`, история релизов будет сохранена. В этом случае вы сможете запросить информацию об этом релизе: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Поскольку Helm отслеживает ваши релизы даже после их удаления, вы можете проверить историю кластера и даже восстановить релиз с помощью команды `helm rollback`. ## Чтение справки Чтобы узнать больше о доступных командах Helm, используйте `helm help` или введите команду с флагом `-h`: ```console $ helm get -h ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Использование Helm description: Объясняет основы работы с Helm. sidebar_position: 3 --- В этом руководстве объясняются основы использования Helm для управления пакетами на вашем кластере Kubernetes. Руководство предполагает, что вы уже [установили](/intro/install.md) Helm. Если вас просто интересует выполнение нескольких команд, вы можете начать с [Краткого руководства](/intro/quickstart.md). В этой главе описаны особенности команд Helm и объясняется, как использовать Helm. ## Три основных концепции *Чарт* — это пакет Helm. Он содержит все определения ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes. Можно представить его как Kubernetes-эквивалент формулы Homebrew, пакета Apt dpkg или RPM-файла Yum. *Репозиторий* — это место, где можно собирать чарты и делиться ими. Это похоже на [архив CPAN](https://www.cpan.org) для Perl или [базу пакетов Fedora](https://src.fedoraproject.org/), но для пакетов Kubernetes. *Релиз* — это экземпляр чарта, работающий в кластере Kubernetes. Один чарт часто может быть установлен многократно в одном и том же кластере. Каждый раз при установке создаётся новый _релиз_. Рассмотрим чарт MySQL. Если вам нужны две базы данных в кластере, вы можете установить этот чарт дважды. Каждая установка будет иметь свой собственный _релиз_ со своим уникальным _именем релиза_. Зная эти концепции, можно описать работу Helm так: Helm устанавливает _чарты_ в Kubernetes, создавая новый _релиз_ для каждой установки. Чтобы найти новые чарты, можно воспользоваться поиском в _репозиториях_ чартов Helm. ## 'helm search': Поиск чартов Helm поставляется с мощной командой поиска. Она может использоваться для поиска в двух различных типах источников: - `helm search hub` выполняет поиск в [Artifact Hub](https://artifacthub.io), который содержит списки чартов Helm из множества различных репозиториев. - `helm search repo` выполняет поиск в репозиториях, которые вы добавили в свой локальный клиент Helm (с помощью `helm repo add`). Этот поиск выполняется по локальным данным и не требует подключения к сети. Вы можете найти общедоступные чарты, выполнив `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` Команда выше ищет все чарты `wordpress` в Artifact Hub. Без фильтра `helm search hub` показывает все доступные чарты. `helm search hub` показывает URL-адрес на [artifacthub.io](https://artifacthub.io/), но не фактический репозиторий Helm. `helm search hub --list-repo-url` показывает фактический URL репозитория Helm, что удобно, когда вы хотите добавить новый репозиторий: `helm repo add [NAME] [URL]`. Используя `helm search repo`, вы можете найти названия чартов в уже добавленных вами репозиториях: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search использует нечёткий поиск (fuzzy string matching), поэтому вы можете вводить части слов или фраз: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Поиск — это хороший способ найти доступные пакеты. Как только вы нашли пакет, который хотите установить, вы можете использовать `helm install` для его установки. ## 'helm install': Установка пакета Чтобы установить новый пакет, используйте команду `helm install`. В простейшем случае она принимает два аргумента: имя релиза, которое вы выбираете, и имя чарта, который вы хотите установить. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Теперь чарт `wordpress` установлен. Обратите внимание, что при установке чарта создаётся новый объект _релиза_. Релиз выше называется `happy-panda`. (Если вы хотите, чтобы Helm сгенерировал имя за вас, не указывайте имя релиза и используйте `--generate-name`.) Во время установки клиент `helm` выводит полезную информацию о том, какие ресурсы были созданы, каково состояние релиза, а также есть ли дополнительные шаги настройки, которые вы можете или должны выполнить. Helm устанавливает ресурсы в следующем порядке: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm не ждёт, пока все ресурсы будут запущены, прежде чем завершить работу. Многие чарты требуют Docker-образы размером более 600 МБ, и их установка в кластер может занять много времени. Чтобы отслеживать состояние релиза или повторно прочитать информацию о конфигурации, вы можете использовать `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Выше показано текущее состояние вашего релиза. ### Настройка чарта перед установкой При установке описанным способом будут использованы только параметры конфигурации по умолчанию для данного чарта. Часто вам потребуется настроить чарт в соответствии с вашими предпочтениями. Чтобы увидеть, какие параметры можно настроить в чарте, используйте `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Затем вы можете переопределить любой из этих параметров в файле формата YAML и передать этот файл при установке. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Команда выше создаст пользователя MariaDB с именем `user0` и предоставит этому пользователю доступ к вновь созданной базе данных `user0db`, но примет все остальные значения по умолчанию для этого чарта. Существует два способа передачи конфигурационных данных во время установки: - `--values` (или `-f`): указывает YAML-файл с переопределениями. Можно указать несколько раз, при этом самый правый файл будет иметь приоритет. - `--set`: указывает переопределения в командной строке. Если используются оба параметра, значения `--set` объединяются со значениями `--values` с более высоким приоритетом. Переопределения, указанные с помощью `--set`, сохраняются в Secret. Значения, которые были заданы через `--set`, можно просмотреть для данного релиза с помощью `helm get values `. Значения `--set` можно сбросить, выполнив `helm upgrade` с указанием `--reset-values`. #### Формат и ограничения `--set` Параметр `--set` принимает ноль или более пар имя/значение. В простейшем случае он используется так: `--set name=value`. Эквивалент в YAML: ```yaml name: value ``` Несколько значений разделяются символом `,`. Таким образом, `--set a=b,c=d` становится: ```yaml a: b c: d ``` Поддерживаются более сложные выражения. Например, `--set outer.inner=value` преобразуется в: ```yaml outer: inner: value ``` Списки можно задать, заключив значения в `{` и `}`. Например, `--set name={a, b, c}` преобразуется в: ```yaml name: - a - b - c ``` Определённые имена/ключи можно установить в `null` или в пустой массив `[]`. Например, `--set name=[],a=null` преобразует ```yaml name: - a - b - c a: b ``` в ```yaml name: [] a: null ``` Начиная с Helm 2.5.0, доступ к элементам списка возможен с помощью синтаксиса индекса массива. Например, `--set servers[0].port=80` становится: ```yaml servers: - port: 80 ``` Таким образом можно задать несколько значений. Строка `--set servers[0].port=80,servers[0].host=example` становится: ```yaml servers: - port: 80 host: example ``` Иногда вам нужно использовать специальные символы в строках `--set`. Вы можете использовать обратную косую черту для экранирования символов; `--set name=value1\,value2` станет: ```yaml name: "value1,value2" ``` Аналогично можно экранировать точки, что может пригодиться, когда чарты используют функцию `toYaml` для разбора аннотаций, меток и селекторов узлов. Синтаксис `--set nodeSelector."kubernetes\.io/role"=master` становится: ```yaml nodeSelector: kubernetes.io/role: master ``` Глубоко вложенные структуры данных может быть сложно выразить с помощью `--set`. Разработчикам чартов рекомендуется учитывать использование `--set` при проектировании формата файла `values.yaml` (подробнее см. [Файлы Values](/chart_template_guide/values_files.md)). ### Дополнительные методы установки Команда `helm install` может устанавливать из нескольких источников: - Репозиторий чартов (как мы видели выше) - Локальный архив чарта (`helm install foo foo-0.1.1.tgz`) - Распакованная директория чарта (`helm install foo path/to/foo`) - Полный URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' и 'helm rollback': Обновление релиза и восстановление после сбоя Когда выходит новая версия чарта или когда вы хотите изменить конфигурацию своего релиза, вы можете использовать команду `helm upgrade`. Обновление берёт существующий релиз и обновляет его согласно предоставленной вами информации. Поскольку чарты Kubernetes могут быть большими и сложными, Helm пытается выполнить наименее инвазивное обновление. Он обновит только то, что изменилось с момента последнего релиза. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` В приведённом выше случае релиз `happy-panda` обновляется тем же чартом, но с новым YAML-файлом: ```yaml mariadb.auth.username: user1 ``` Мы можем использовать `helm get values`, чтобы проверить, применились ли новые настройки. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` Команда `helm get` — полезный инструмент для просмотра релиза в кластере. Как мы видим выше, она показывает, что наши новые значения из `panda.yaml` были развёрнуты в кластере. Теперь, если что-то пошло не так во время релиза, легко откатиться к предыдущему релизу с помощью `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` Команда выше откатывает happy-panda к самой первой версии релиза. Версия релиза — это инкрементная ревизия. Каждый раз при установке, обновлении или откате номер ревизии увеличивается на 1. Первый номер ревизии всегда 1. Мы можем использовать `helm history [RELEASE]`, чтобы увидеть номера ревизий для определённого релиза. ## Полезные опции для установки/обновления/отката Существует несколько других полезных параметров, которые вы можете указать для настройки поведения Helm во время установки/обновления/отката. Обратите внимание, что это не полный список флагов CLI. Чтобы увидеть описание всех флагов, просто выполните `helm --help`. - `--timeout`: значение [Go duration](https://golang.org/pkg/time/#ParseDuration), определяющее время ожидания завершения команд Kubernetes. По умолчанию `5m0s`. - `--wait`: ожидает, пока все Pod не перейдут в состояние готовности, PVC не будут привязаны, Deployment не будут иметь минимум (`Desired` минус `maxUnavailable`) Pod в состоянии готовности, а Service не получат IP-адрес (и Ingress при наличии `LoadBalancer`), прежде чем пометить релиз как успешный. Ожидание продолжается в течение времени, указанного в `--timeout`. Если таймаут достигнут, релиз будет помечен как `FAILED`. Примечание: в сценариях, где у Deployment значение `replicas` равно 1, а `maxUnavailable` не установлен в 0 как часть стратегии rolling update, `--wait` вернёт готовность, как только будет удовлетворено условие минимального количества Pod в состоянии готовности. - `--no-hooks`: пропускает выполнение хуков для команды. - `--recreate-pods` (доступно только для `upgrade` и `rollback`): этот флаг приведёт к пересозданию всех Pod (за исключением Pod, принадлежащих Deployment). (УСТАРЕЛО в Helm 3) ## 'helm uninstall': Удаление релиза Когда потребуется удалить релиз из кластера, используйте команду `helm uninstall`: ```console $ helm uninstall happy-panda ``` Это удалит релиз из кластера. Вы можете просмотреть все ваши текущие развёрнутые релизы с помощью команды `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` Из вывода выше видно, что релиз `happy-panda` был удалён. В предыдущих версиях Helm при удалении релиза запись о его удалении сохранялась. В Helm 3 удаление также удаляет запись о релизе. Если вы хотите сохранить запись об удалении релиза, используйте `helm uninstall --keep-history`. Команда `helm list --uninstalled` покажет только те релизы, которые были удалены с флагом `--keep-history`. Флаг `helm list --all` покажет вам все записи о релизах, которые сохранил Helm, включая записи о неудачных или удалённых элементах (если был указан `--keep-history`): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Обратите внимание, что поскольку релизы теперь удаляются по умолчанию, откат удалённого ресурса больше невозможен. ## 'helm repo': Работа с репозиториями Helm 3 больше не поставляется с репозиторием чартов по умолчанию. Группа команд `helm repo` предоставляет команды для добавления, просмотра и удаления репозиториев. Вы можете посмотреть, какие репозитории настроены, с помощью `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Новые репозитории можно добавить с помощью `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Поскольку репозитории чартов часто меняются, в любой момент вы можете убедиться, что ваш клиент Helm обновлён, выполнив `helm repo update`. Репозитории можно удалить с помощью `helm repo remove`. ## Создание собственных чартов [Руководство по разработке чартов](/topics/charts.md) объясняет, как создавать свои собственные чарты. Но вы можете быстро начать работу с помощью команды `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Теперь у вас есть чарт в `./deis-workflow`. Вы можете редактировать его и создавать свои собственные шаблоны. По мере редактирования чарта вы можете проверить его корректность с помощью `helm lint`. Когда придёт время упаковать чарт для распространения, вы можете выполнить команду `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` И этот чарт теперь можно легко установить с помощью `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Упакованные чарты могут быть загружены в репозитории чартов. Подробнее см. документацию по [репозиториям чартов Helm](/topics/chart_repository.md). ## Заключение В этой главе рассмотрены основные способы использования клиента `helm`, включая поиск, установку, обновление и удаление. Также были рассмотрены полезные служебные команды, такие как `helm status`, `helm get` и `helm repo`. Для получения дополнительной информации об этих командах обратитесь к встроенной справке Helm: `helm help`. В [следующей главе](/howto/charts_tips_and_tricks.md) мы рассмотрим процесс разработки чартов. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunOption = "none" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) chart, err := loader.Load(chartPath) if err != nil { return err } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil { if err := action.CheckDependencies(chart, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := installClient.RunWithContext(ctx, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created:\n%+v", *release) return nil } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx ================================================ ```go package main import ( "bufio" "context" "fmt" "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver, logger.Printf); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, err } return registryClient, nil } func newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) { if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSverify { registryClient, err := registry.NewRegistryClientWithTLS( logger.Writer(), certFile, keyFile, caFile, insecureSkipTLSverify, settings.RegistryConfig, settings.Debug) if err != nil { return nil, err } return registryClient, nil } registryClient, err := newRegistryClient(settings, plainHTTP) if err != nil { return nil, err } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } registryClient, err := newRegistryClient(settings, false) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient pullClient := action.NewPullWithOpts( action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", *result.Release) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunOption = "none" upgradeClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts chart, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } if req := chart.Metadata.Dependencies; req != nil { if err := action.CheckDependencies(chart, req); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx ================================================ --- title: Примеры description: Примеры различных возможностей Helm SDK sidebar_position: 2 --- import Install from './_install.mdx' import List from './_list.mdx' import Main from './_main.mdx' import Pull from './_pull.mdx' import Uninstall from './_uninstall.mdx' import Upgrade from './_upgrade.mdx' В этом документе представлен ряд примеров использования Helm SDK. Цель — продемонстрировать различные функциональные возможности SDK. Финальный пример показывает драйвер `main.go` ([ссылка](#driver)), который запускает приведённые ниже действия и включает необходимые вспомогательные функции. Код примеров находится в директории [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples). Он полностью функционален. ## Действия ### Действие Install Этот пример устанавливает указанный чарт/релиз для заданной версии и значений: ### Действие Upgrade Этот пример обновляет указанный релиз с заданным чартом, версией и значениями: ### Действие Uninstall Этот пример удаляет указанный релиз: ### Действие List Этот пример выводит список всех установленных чартов (в текущем настроенном пространстве имён): ### Действие Pull Этот пример загружает чарт из OCI-репозитория: ## Драйвер Драйвер демонстрирует вспомогательные функции, необходимые для работы действий Helm SDK. Он показывает приведённые выше примеры в действии: загрузку, установку, обновление и удаление чарта 'podinfo' из OCI-репозитория.
================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Введение description: Введение в Helm Go SDK sidebar_position: 1 --- Helm Go SDK позволяет пользовательскому программному обеспечению использовать чарты Helm и функциональность Helm для управления развёртыванием программного обеспечения в Kubernetes. (На самом деле, CLI Helm — это всего лишь один из таких инструментов!) В настоящее время SDK функционально отделён от CLI Helm. SDK может использоваться (и используется) автономными инструментами. Проект Helm гарантирует стабильность API для SDK. Следует отметить, что в SDK всё ещё есть некоторые шероховатости, оставшиеся после первоначальной работы по отделению CLI и SDK. Проект Helm намерен улучшить их со временем. Полная документация API доступна по адресу [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Ниже приведён краткий обзор основных типов пакетов и простой пример. Дополнительные примеры и более полнофункциональный драйвер смотрите в разделе [Примеры](/sdk/examples.mdx). ## Обзор основных пакетов - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Содержит основной «клиент» для выполнения операций Helm. Это тот же пакет, который CLI использует «под капотом». Если вам нужно просто выполнять базовые команды Helm из другой программы на Go, этот пакет для вас - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Методы и вспомогательные функции для загрузки и работы с чартами - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) и его подпакеты: Содержит все обработчики для стандартных переменных окружения Helm, а подпакеты отвечают за обработку вывода и файлов values - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Определяет объект `Release` и статусы Помимо этих существует множество других пакетов, поэтому обратитесь к документации за дополнительной информацией! ### Простой пример Это простой пример выполнения `helm list` с использованием Go SDK. Дополнительные примеры смотрите в разделе [Примеры](/sdk/examples.mdx). ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Совместимость Helm SDK явно следует гарантиям обратной совместимости Helm: То есть несовместимые изменения будут вноситься только при смене мажорных версий. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Расширенные методы работы с Helm description: Описание различных расширенных возможностей для опытных пользователей Helm sidebar_position: 9 --- В этом разделе описываются различные расширенные возможности и методы использования Helm. Информация предназначена для опытных пользователей Helm, которые хотят выполнять расширенную настройку и управление чартами и релизами. Каждая из этих возможностей имеет свои особенности и ограничения, поэтому использовать их следует осторожно и с глубоким пониманием Helm. Иными словами, помните о [принципе Питера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Пост-рендеринг Пост-рендеринг позволяет вручную изменять, настраивать и проверять отрендеренные манифесты перед их установкой в Helm. Это даёт возможность пользователям с расширенными потребностями применять инструменты вроде [`kustomize`](https://kustomize.io) для изменения конфигурации без необходимости форкать публичный чарт или требовать от разработчиков чарта указания каждого параметра. Также существуют сценарии для внедрения общих инструментов и sidecar-контейнеров в корпоративных средах или анализа манифестов перед развёртыванием. ### Предварительные требования - Helm 3.1+ ### Использование Пост-рендерер может быть любым исполняемым файлом, который принимает отрендеренные манифесты Kubernetes через STDIN и возвращает валидные манифесты Kubernetes через STDOUT. В случае ошибки он должен вернуть ненулевой код завершения. Это единственный «API» между двумя компонентами и он обеспечивает большую гибкость в работе с процессом пост-рендеринга. Пост-рендерер можно использовать с командами `install`, `upgrade` и `template`. Для этого укажите флаг `--post-renderer` с путём к исполняемому файлу рендерера: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Если путь не содержит разделителей, поиск будет выполняться в $PATH, в противном случае относительные пути будут преобразованы в полные. Если вы хотите использовать несколько пост-рендереров, вызывайте их все в скрипте или вместе в любом созданном вами бинарном инструменте. В bash это может выглядеть так: `renderer1 | renderer2 | renderer3`. Пример использования `kustomize` в качестве пост-рендерера можно посмотреть [здесь](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Предостережения При использовании пост-рендереров важно помнить о нескольких вещах. Главное — все, кто изменяет данный релиз, **ДОЛЖНЫ** использовать тот же рендерер для обеспечения воспроизводимых сборок. Эта функция намеренно позволяет любому пользователю менять или отключать используемый рендерер, но делать это следует осознанно, чтобы избежать случайных изменений или потери данных. Ещё один важный момент — безопасность. Если вы используете пост-рендерер, убедитесь, что он получен из надёжного источника (как и любой другой исполняемый файл). Использование непроверенных или ненадёжных рендереров НЕ рекомендуется, поскольку они имеют полный доступ к отрендеренным шаблонам, которые часто содержат секретные данные. ### Пользовательские пост-рендереры Этап пост-рендеринга предоставляет ещё большую гибкость при использовании Go SDK. Пост-рендерер должен лишь реализовать следующий интерфейс: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Для получения дополнительной информации об использовании Go SDK смотрите [раздел Go SDK](#go-sdk). ## Go SDK В Helm 3 появился полностью переработанный Go SDK для улучшения работы при создании программного обеспечения и инструментов, использующих Helm. Полная документация находится в [разделе Go SDK](/sdk/gosdk.md). ## Бэкенды хранения В Helm 3 по умолчанию информация о релизах хранится в объектах Secret в пространстве имён релиза. В Helm 2 по умолчанию информация о релизах хранилась в объектах ConfigMap в пространстве имён экземпляра Tiller. В следующих подразделах описывается настройка различных бэкендов. Конфигурация выполняется через переменную окружения `HELM_DRIVER`, которую можно установить в одно из значений: `[configmap, secret, sql]`. ### Бэкенд хранения ConfigMap Чтобы включить бэкенд ConfigMap, установите переменную окружения `HELM_DRIVER` в значение `configmap`. В оболочке это делается так: ```shell export HELM_DRIVER=configmap ``` Если вы хотите перейти с бэкенда по умолчанию на бэкенд ConfigMap, вам придётся выполнить миграцию самостоятельно. Получить информацию о релизах можно с помощью следующей команды: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **ВАЖНО ДЛЯ ПРОДАКШЕНА**: Информация о релизах включает содержимое чартов и файлов values, поэтому может содержать конфиденциальные данные (пароли, закрытые ключи и другие учётные данные), которые необходимо защищать от несанкционированного доступа. При управлении авторизацией Kubernetes с помощью [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) можно предоставить более широкий доступ к ресурсам ConfigMap, ограничив при этом доступ к ресурсам Secret. Например, встроенная [роль](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) «view» предоставляет доступ к большинству ресурсов, но не к Secret. Кроме того, данные Secret можно настроить для [зашифрованного хранения](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Учитывайте это при переходе на бэкенд ConfigMap, так как это может раскрыть конфиденциальные данные вашего приложения. ### Бэкенд хранения SQL Существует бэкенд хранения SQL в ***бета***-версии, который хранит информацию о релизах в базе данных SQL. Такой бэкенд хранения особенно полезен, если информация о ваших релизах превышает 1 МБ (в этом случае её нельзя хранить в ConfigMap/Secret из-за внутренних ограничений базового хранилища etcd в Kubernetes). Чтобы включить бэкенд SQL, разверните базу данных SQL и установите переменную окружения `HELM_DRIVER` в значение `sql`. Данные подключения к БД задаются через переменную окружения `HELM_DRIVER_SQL_CONNECTION_STRING`. В оболочке это делается так: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Примечание: На данный момент поддерживается только PostgreSQL. **ВАЖНО ДЛЯ ПРОДАКШЕНА**: Рекомендуется: - Подготовить базу данных для продакшена. Для PostgreSQL обратитесь к документации по [администрированию сервера](https://www.postgresql.org/docs/12/admin.html) - Включить [управление правами доступа](/topics/permissions_sql_storage_backend.md) для отражения Kubernetes RBAC для информации о релизах Если вы хотите перейти с бэкенда по умолчанию на бэкенд SQL, вам придётся выполнить миграцию самостоятельно. Получить информацию о релизах можно с помощью следующей команды: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Архитектура Helm description: Описание архитектуры Helm на высоком уровне. sidebar_position: 8 --- # Архитектура Helm Этот документ описывает архитектуру Helm на высоком уровне. ## Назначение Helm Helm — это инструмент для управления пакетами Kubernetes, называемыми _чартами_. Helm может выполнять следующие задачи: - Создавать новые чарты с нуля - Упаковывать чарты в архивные файлы (tgz) - Взаимодействовать с репозиториями чартов, где они хранятся - Устанавливать и удалять чарты в существующий кластер Kubernetes - Управлять жизненным циклом релизов чартов, установленных с помощью Helm Для Helm существуют три важных концепции: 1. _Чарт_ — это набор информации, необходимой для создания экземпляра приложения Kubernetes. 2. _Конфигурация_ содержит информацию о настройках, которая может быть объединена с упакованным чартом для создания объекта, готового к релизу. 3. _Релиз_ — это работающий экземпляр _чарта_, объединённый с конкретной _конфигурацией_. ## Компоненты Helm — это исполняемый файл, реализованный в виде двух отдельных частей: **Клиент Helm** — это клиент командной строки для конечных пользователей. Клиент отвечает за следующее: - Локальная разработка чартов - Управление репозиториями - Управление релизами - Взаимодействие с библиотекой Helm - Отправка чартов на установку - Запрос на обновление или удаление существующих релизов **Библиотека Helm** предоставляет логику для выполнения всех операций Helm. Она взаимодействует с сервером API Kubernetes и обеспечивает следующие возможности: - Объединение чарта и конфигурации для создания релиза - Установка чартов в Kubernetes с предоставлением соответствующего объекта релиза - Обновление и удаление чартов посредством взаимодействия с Kubernetes Автономная библиотека Helm инкапсулирует логику Helm, что позволяет использовать её различными клиентами. ## Реализация Клиент и библиотека Helm написаны на языке программирования Go. Библиотека использует клиентскую библиотеку Kubernetes для взаимодействия с Kubernetes. В настоящее время эта библиотека использует REST+JSON. Информация хранится в объектах Secret в Kubernetes. Для работы Helm не требуется собственная база данных. Файлы конфигурации по возможности пишутся на YAML. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Руководство по репозиториям чартов description: Как создавать репозитории чартов Helm и работать с ними. sidebar_position: 6 --- В этом разделе объясняется, как создавать репозитории чартов Helm и работать с ними. Репозиторий чартов — это место, где можно хранить и распространять упакованные чарты. Распределённый репозиторий чартов сообщества Helm находится на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) и открыт для участия. Однако Helm также позволяет создавать и запускать собственный репозиторий чартов. Это руководство объясняет, как это сделать. Если вы планируете создать репозиторий чартов, возможно, стоит рассмотреть использование [OCI-реестра](/topics/registries.md). ## Предварительные требования * Пройдите [Руководство по быстрому старту](/intro/quickstart.md) * Ознакомьтесь с документом [Чарты](/topics/charts.md) ## Создание репозитория чартов _Репозиторий чартов_ — это HTTP-сервер, содержащий файл `index.yaml` и, опционально, упакованные чарты. Когда вы готовы поделиться своими чартами, предпочтительный способ — загрузить их в репозиторий чартов. Начиная с Helm 2.2.0 поддерживается клиентская SSL-аутентификация к репозиторию. Другие протоколы аутентификации могут быть доступны через плагины. Поскольку репозиторий чартов может быть любым HTTP-сервером, способным отдавать YAML и tar-файлы и отвечать на GET-запросы, у вас есть множество вариантов для размещения собственного репозитория чартов. Например, вы можете использовать бакет Google Cloud Storage (GCS), бакет Amazon S3, GitHub Pages или даже создать собственный веб-сервер. ### Структура репозитория чартов Репозиторий чартов состоит из упакованных чартов и специального файла `index.yaml`, содержащего индекс всех чартов в репозитории. Часто чарты, описанные в `index.yaml`, размещаются на том же сервере, что и [файлы происхождения](/topics/provenance.md). Например, структура репозитория `https://example.com/charts` может выглядеть так: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` В этом случае индексный файл будет содержать информацию об одном чарте — Alpine — и предоставлять URL для скачивания `https://example.com/charts/alpine-0.1.2.tgz` для этого чарта. Не обязательно, чтобы пакет чарта находился на том же сервере, что и файл `index.yaml`. Однако часто это самый простой вариант. ### Индексный файл Индексный файл — это YAML-файл с именем `index.yaml`. Он содержит метаданные о пакете, включая содержимое файла `Chart.yaml` чарта. Валидный репозиторий чартов должен иметь индексный файл. Индексный файл содержит информацию о каждом чарте в репозитории чартов. Команда `helm repo index` генерирует индексный файл на основе заданного локального каталога, содержащего упакованные чарты. Вот пример индексного файла: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Размещение репозиториев чартов В этой части показаны несколько способов размещения репозитория чартов. ### Google Cloud Storage Первый шаг — **создать бакет GCS**. Назовём его `fantastic-charts`. ![Создание бакета GCS](/img/helm2/create-a-bucket.png) Затем сделайте бакет публичным, **отредактировав права доступа**. ![Редактирование прав](/img/helm2/edit-permissions.png) Добавьте эту запись, чтобы **сделать бакет публичным**: ![Сделать бакет публичным](/img/helm2/make-bucket-public.png) Поздравляем, теперь у вас есть пустой бакет GCS, готовый для размещения чартов! Вы можете загружать репозиторий чартов с помощью командной строки Google Cloud Storage или через веб-интерфейс GCS. Публичный бакет GCS доступен по простому HTTPS-адресу: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith Вы также можете настроить репозитории чартов с помощью Cloudsmith. Подробнее о репозиториях чартов с Cloudsmith читайте [здесь](https://help.cloudsmith.io/docs/helm-chart-repository). ### JFrog Artifactory Аналогично вы можете настроить репозитории чартов с помощью JFrog Artifactory. Подробнее о репозиториях чартов с JFrog Artifactory читайте [здесь](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). ### Пример с GitHub Pages Аналогичным образом можно создать репозиторий чартов с помощью GitHub Pages. GitHub позволяет размещать статические веб-страницы двумя способами: - Настроив проект для обслуживания содержимого каталога `docs/` - Настроив проект для обслуживания определённой ветки Мы используем второй подход, хотя первый столь же прост. Первый шаг — **создать ветку gh-pages**. Вы можете сделать это локально: ```console $ git checkout -b gh-pages ``` Или через веб-браузер, используя кнопку **Branch** в вашем репозитории GitHub: ![Создание ветки GitHub Pages](/img/helm2/create-a-gh-page-button.png) Далее убедитесь, что ваша **ветка gh-pages** настроена как GitHub Pages. Перейдите в **Settings** репозитория и прокрутите вниз до раздела **GitHub Pages**, настроив его следующим образом: ![Настройка ветки GitHub Pages](/img/helm2/set-a-gh-page.png) По умолчанию **Source** обычно устанавливается на **gh-pages branch**. Если это не так, выберите её. При желании вы можете использовать **собственный домен**. Также убедитесь, что включена опция **Enforce HTTPS**, чтобы при обслуживании чартов использовался **HTTPS**. При такой настройке вы можете использовать основную ветку для хранения кода чартов, а **ветку gh-pages** — как репозиторий чартов, например: `https://USERNAME.github.io/REPONAME`. Демонстрационный репозиторий [TS Charts](https://github.com/technosophos/tscharts) доступен по адресу `https://technosophos.github.io/tscharts/`. Если вы решили использовать GitHub Pages для размещения репозитория чартов, ознакомьтесь с [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action — это рабочий процесс GitHub Action для превращения проекта GitHub в самостоятельный репозиторий чартов Helm с использованием CLI-инструмента [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Обычные веб-серверы Чтобы настроить обычный веб-сервер для обслуживания чартов Helm, вам нужно сделать следующее: - Поместите индекс и чарты в каталог, который может обслуживать сервер - Убедитесь, что файл `index.yaml` доступен без аутентификации - Убедитесь, что файлы `yaml` отдаются с правильным типом содержимого (`text/yaml` или `text/x-yaml`) Например, если вы хотите обслуживать чарты из `$WEBROOT/charts`, создайте каталог `charts/` в корне веб-сервера и поместите индексный файл и чарты в эту папку. ### Сервер репозитория ChartMuseum ChartMuseum — это сервер репозитория чартов Helm с открытым исходным кодом, написанный на Go (Golang), с поддержкой облачных хранилищ, включая [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) и [etcd](https://etcd.io/). Вы также можете использовать сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для размещения репозитория чартов в локальной файловой системе. ### GitLab Package Registry С помощью GitLab вы можете публиковать чарты Helm в Package Registry вашего проекта. Подробнее о настройке репозитория пакетов Helm с GitLab читайте [здесь](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Управление репозиториями чартов Теперь, когда у вас есть репозиторий чартов, в последней части этого руководства объясняется, как поддерживать чарты в этом репозитории. ### Хранение чартов в репозитории Теперь загрузим чарт и индексный файл в репозиторий. Чарты в репозитории должны быть упакованы (`helm package chart-name/`) и правильно версионированы (в соответствии с рекомендациями [SemVer 2](https://semver.org/)). Следующие шаги представляют пример рабочего процесса, но вы можете использовать любой удобный вам процесс для хранения и обновления чартов в репозитории. Когда у вас есть готовый упакованный чарт, создайте новый каталог и переместите упакованный чарт в него. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` Последняя команда принимает путь к только что созданному локальному каталогу и URL вашего удалённого репозитория чартов, создавая файл `index.yaml` в указанном каталоге. Теперь вы можете загрузить чарт и индексный файл в репозиторий с помощью инструмента синхронизации или вручную. Если вы используете Google Cloud Storage, посмотрите этот [пример рабочего процесса](/howto/chart_repository_sync_example.md) с использованием клиента gsutil. Для GitHub просто поместите чарты в соответствующую целевую ветку. ### Добавление новых чартов в существующий репозиторий Каждый раз, когда вы хотите добавить новый чарт в репозиторий, необходимо заново сгенерировать индекс. Команда `helm repo index` полностью перестраивает файл `index.yaml` с нуля, включая только те чарты, которые находятся локально. Однако вы можете использовать флаг `--merge` для инкрементального добавления новых чартов в существующий файл `index.yaml` (отличный вариант при работе с удалённым репозиторием, таким как GCS). Выполните `helm repo index --help`, чтобы узнать больше. Убедитесь, что вы загружаете как обновлённый файл `index.yaml`, так и чарт. И если вы сгенерировали файл происхождения, загрузите и его. ### Распространение чартов Когда вы готовы поделиться своими чартами, просто сообщите кому-нибудь URL вашего репозитория. Оттуда они добавят репозиторий в свой клиент Helm с помощью команды `helm repo add [NAME] [URL]`, используя любое имя для ссылки на репозиторий. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Если чарты защищены HTTP-аутентификацией (Basic Auth), вы также можете указать имя пользователя и пароль: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Примечание:** Репозиторий не будет добавлен, если он не содержит валидного файла `index.yaml`. **Примечание:** Если ваш репозиторий Helm использует, например, самоподписанный сертификат, вы можете использовать `helm repo add --insecure-skip-tls-verify ...`, чтобы пропустить проверку CA. После этого ваши пользователи смогут искать ваши чарты. После обновления репозитория они могут использовать команду `helm repo update` для получения актуальной информации о чартах. *Под капотом команды `helm repo add` и `helm repo update` загружают файл index.yaml и сохраняют его в каталоге `$XDG_CACHE_HOME/helm/repository/cache/`. Именно там функция `helm search` находит информацию о чартах.* ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Тестирование чартов description: Описывает, как запускать и тестировать ваши чарты. sidebar_position: 3 --- Чарт содержит множество ресурсов и компонентов Kubernetes, работающих вместе. Как автор чарта, вы можете написать тесты, которые проверят, что ваш чарт работает корректно после установки. Эти тесты также помогут пользователям чарта понять, что именно должен делать ваш чарт. **Тест** в Helm-чарте располагается в директории `templates/` и представляет собой определение Job, указывающее контейнер с заданной командой для выполнения. Контейнер должен завершиться успешно (код выхода 0), чтобы тест считался пройденным. Определение Job должно содержать аннотацию тестового хука: `helm.sh/hook: test`. Обратите внимание, что до Helm v3 определение Job должно было содержать одну из следующих аннотаций: `helm.sh/hook: test-success` или `helm.sh/hook: test-failure`. Аннотация `helm.sh/hook: test-success` по-прежнему принимается для обратной совместимости как альтернатива `helm.sh/hook: test`. Примеры тестов: - Проверка того, что конфигурация из файла values.yaml была правильно применена. - Убедитесь, что имя пользователя и пароль работают корректно - Убедитесь, что неправильные имя пользователя и пароль не работают - Проверка того, что ваши сервисы запущены и правильно балансируют нагрузку - и т.д. Вы можете запустить предопределённые тесты Helm для релиза с помощью команды `helm test `. Для пользователя чарта это отличный способ убедиться, что их релиз чарта (или приложения) работает как ожидается. ## Пример теста Команда [helm create](/helm/helm_create.md) автоматически создаёт ряд папок и файлов. Чтобы попробовать функциональность helm test, сначала создайте демо-чарт. ```console $ helm create demo ``` Теперь вы увидите следующую структуру в вашем демо-чарте. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` В файле `demo/templates/tests/test-connection.yaml` вы найдёте тест, который можете попробовать. Ниже приведено определение тестового Pod: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Запуск набора тестов для релиза Сначала установите чарт в ваш кластер для создания релиза. Возможно, вам придётся подождать, пока все Pod станут активными; если вы запустите тест сразу после установки, велика вероятность временного сбоя, и вам потребуется повторить тестирование. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Примечания - Вы можете определить любое количество тестов в одном yaml-файле или распределить их по нескольким yaml-файлам в директории `templates/`. - Рекомендуется размещать набор тестов в поддиректории `tests/`, например `/templates/tests/`, для лучшей изоляции. - Тест является [хуком Helm](/topics/charts_hooks.md), поэтому к тестовым ресурсам можно применять аннотации `helm.sh/hook-weight` и `helm.sh/hook-delete-policy`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Чарты description: Описывает формат чартов и даёт базовое руководство по созданию чартов в Helm. sidebar_position: 1 --- Helm использует формат упаковки, называемый _чартами_. Чарт — это набор файлов, описывающих связанный набор ресурсов Kubernetes. Один чарт может использоваться для развёртывания чего-то простого, например пода с memcached, или чего-то сложного, например полного стека веб-приложения с HTTP-серверами, базами данных, кешами и так далее. Чарты создаются как файлы, организованные в определённую структуру каталогов. Их можно упаковывать в версионированные архивы для развёртывания. Если вы хотите скачать и посмотреть файлы опубликованного чарта без его установки, вы можете сделать это с помощью команды `helm pull chartrepo/chartname`. Этот документ описывает формат чартов и даёт базовое руководство по созданию чартов в Helm. ## Файловая структура чарта Чарт организован как набор файлов внутри каталога. Имя каталога — это имя чарта (без информации о версии). Таким образом, чарт, описывающий WordPress, будет храниться в каталоге `wordpress/`. Внутри этого каталога Helm ожидает структуру, соответствующую следующей: ```text wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file values.yaml # The default configuration values for this chart values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file charts/ # A directory containing any charts upon which this chart depends. crds/ # Custom Resource Definitions templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Helm резервирует использование каталогов `charts/`, `crds/` и `templates/`, а также перечисленных имён файлов. Остальные файлы останутся без изменений. ## Файл Chart.yaml Файл `Chart.yaml` является обязательным для чарта. Он содержит следующие поля: ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` Начиная с версии [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), дополнительные поля не допускаются. Рекомендуемый подход — добавлять пользовательские метаданные в `annotations`. ### Чарты и версионирование Каждый чарт должен иметь номер версии. Версия должна соответствовать стандарту [SemVer 2](https://semver.org/spec/v2.0.0.html), но это не строго обязательно. В отличие от Helm Classic, Helm v2 и более поздние версии используют номера версий как маркеры релизов. Пакеты в репозиториях идентифицируются по имени и версии. Например, чарт `nginx`, в котором поле version установлено как `version: 1.2.3`, будет называться: ```text nginx-1.2.3.tgz ``` Поддерживаются и более сложные имена SemVer 2, такие как `version: 1.2.3-alpha.1+ef365`. Однако имена, не соответствующие SemVer, явно запрещены системой. Исключение составляют версии в формате `x` или `x.y`. Например, если указана версия с начальной буквой v или без всех 3 частей (например, v1.2), система попытается преобразовать её в корректную семантическую версию (например, v1.2.0). **ПРИМЕЧАНИЕ:** В то время как Helm Classic и Deployment Manager были сильно ориентированы на GitHub при работе с чартами, Helm v2 и более поздние версии не полагаются на GitHub или даже Git и не требуют их. Соответственно, Git SHA вообще не используются для версионирования. Поле `version` внутри `Chart.yaml` используется многими инструментами Helm, включая CLI. При создании пакета команда `helm package` использует версию из `Chart.yaml` как токен в имени пакета. Система предполагает, что номер версии в имени пакета чарта соответствует номеру версии в `Chart.yaml`. Несоответствие этому требованию приведёт к ошибке. ### Поле `apiVersion` Поле `apiVersion` должно быть `v2` для чартов Helm, требующих как минимум Helm 3. Чарты, поддерживающие предыдущие версии Helm, имеют `apiVersion`, установленный в `v1`, и по-прежнему могут быть установлены Helm 3. Изменения с `v1` на `v2`: - Поле `dependencies`, определяющее зависимости чарта, которое для чартов `v1` находилось в отдельном файле `requirements.yaml` (см. [Зависимости чартов](#зависимости-чартов)). - Поле `type`, разделяющее прикладные и библиотечные чарты (см. [Типы чартов](#типы-чартов)). ### Поле `appVersion` Обратите внимание, что поле `appVersion` не связано с полем `version`. Это способ указания версии приложения. Например, чарт `drupal` может иметь `appVersion: "8.2.1"`, указывающий, что версия Drupal, включённая в чарт (по умолчанию), — `8.2.1`. Это поле носит информационный характер и не влияет на расчёт версии чарта. Рекомендуется заключать версию в кавычки. Это заставляет парсер YAML обрабатывать номер версии как строку. Без кавычек в некоторых случаях могут возникнуть проблемы парсинга. Например, YAML интерпретирует `1.0` как число с плавающей точкой, а git commit SHA вроде `1234e10` — как научную нотацию. Начиная с Helm v3.5.0, `helm create` заключает поле `appVersion` по умолчанию в кавычки. ### Поле `kubeVersion` Необязательное поле `kubeVersion` позволяет определить ограничения на поддерживаемые версии Kubernetes в формате semver. Helm проверяет ограничения версий при установке чарта и завершается с ошибкой, если кластер работает на неподдерживаемой версии Kubernetes. Ограничения версий могут включать сравнения AND, разделённые пробелами, например: ``` >= 1.13.0 < 1.15.0 ``` которые можно комбинировать с оператором OR `||`, как в следующем примере: ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` В этом примере версия `1.14.0` исключена, что может иметь смысл, если известно о баге в определённых версиях, препятствующем корректной работе чарта. Помимо ограничений версий с использованием операторов `=` `!=` `>` `<` `>=` `<=`, поддерживаются следующие сокращённые нотации: * диапазоны через дефис для закрытых интервалов, где `1.1 - 2.3.4` эквивалентно `>= 1.1 <= 2.3.4`. * подстановочные знаки `x`, `X` и `*`, где `1.2.x` эквивалентно `>= 1.2.0 < 1.3.0`. * тильда-диапазоны (допускаются изменения патч-версии), где `~1.2.3` эквивалентно `>= 1.2.3 < 1.3.0`. * каретка-диапазоны (допускаются изменения минорной версии), где `^1.2.3` эквивалентно `>= 1.2.3 < 2.0.0`. Подробное объяснение поддерживаемых ограничений semver см. в [Masterminds/semver](https://github.com/Masterminds/semver). ### Устаревание чартов При управлении чартами в репозитории чартов иногда необходимо пометить чарт как устаревший. Для этого можно использовать необязательное поле `deprecated` в `Chart.yaml`. Если **последняя** версия чарта в репозитории помечена как устаревшая, то весь чарт считается устаревшим. Имя чарта можно использовать повторно, опубликовав более новую версию, не помеченную как устаревшая. Процедура устаревания чартов: 1. Обновите `Chart.yaml` чарта, чтобы пометить его как устаревший, увеличив версию 2. Опубликуйте новую версию чарта в репозитории чартов 3. Удалите чарт из исходного репозитория (например, git) ### Типы чартов Поле `type` определяет тип чарта. Есть два типа: `application` и `library`. Application — это тип по умолчанию, представляющий собой стандартный чарт, с которым можно выполнять все операции. [Библиотечный чарт](/topics/library_charts.md) предоставляет утилиты или функции для разработчика чартов. Библиотечный чарт отличается от прикладного тем, что он не устанавливается и обычно не содержит объектов ресурсов. **Примечание:** Прикладной чарт может использоваться как библиотечный. Для этого нужно установить тип в `library`. Тогда чарт будет отрендерен как библиотечный, где можно использовать все утилиты и функции. Все объекты ресурсов чарта не будут рендериться. ## Файлы LICENSE, README и NOTES чарта Чарты также могут содержать файлы, описывающие установку, конфигурацию, использование и лицензию чарта. LICENSE — это простой текстовый файл, содержащий [лицензию](https://en.wikipedia.org/wiki/Software_license) чарта. Чарт может содержать лицензию, так как может иметь программную логику в шаблонах и, следовательно, не является только конфигурацией. При необходимости могут быть также отдельные лицензии для приложения, устанавливаемого чартом. README для чарта должен быть отформатирован в Markdown (README.md) и обычно содержит: - Описание приложения или сервиса, предоставляемого чартом - Любые предварительные требования для запуска чарта - Описание опций в `values.yaml` и значений по умолчанию - Любую другую информацию, которая может быть полезна при установке или конфигурации чарта Когда хабы и другие пользовательские интерфейсы отображают информацию о чарте, эта информация берётся из содержимого файла `README.md`. Чарт также может содержать короткий текстовый файл `templates/NOTES.txt`, который будет выводиться после установки и при просмотре статуса релиза. Этот файл обрабатывается как [шаблон](#шаблоны-и-значения) и может использоваться для отображения примечаний по использованию, следующих шагов или любой другой информации, относящейся к релизу чарта. Например, можно предоставить инструкции по подключению к базе данных или доступу к веб-интерфейсу. Поскольку этот файл выводится в STDOUT при выполнении `helm install` или `helm status`, рекомендуется делать содержимое кратким и ссылаться на README для получения более подробной информации. ## Зависимости чартов В Helm один чарт может зависеть от любого количества других чартов. Эти зависимости могут быть динамически связаны с помощью поля `dependencies` в `Chart.yaml` или добавлены в каталог `charts/` и управляться вручную. ### Управление зависимостями с помощью поля `dependencies` Чарты, требуемые текущим чартом, определяются как список в поле `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Поле `name` — это имя нужного вам чарта. - Поле `version` — это версия нужного вам чарта. - Поле `repository` — это полный URL репозитория чартов. Обратите внимание, что вы также должны использовать `helm repo add` для локального добавления этого репозитория. - Вы можете использовать имя репозитория вместо URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` После определения зависимостей вы можете выполнить `helm dependency update`, и команда использует ваш файл зависимостей для загрузки всех указанных чартов в каталог `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Когда `helm dependency update` получает чарты, она сохраняет их как архивы чартов в каталоге `charts/`. Таким образом, для примера выше можно ожидать следующие файлы в каталоге charts: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Поле alias в зависимостях В дополнение к другим полям выше, каждая запись зависимости может содержать необязательное поле `alias`. Добавление псевдонима для зависимого чарта добавляет чарт в зависимости, используя псевдоним в качестве имени новой зависимости. `alias` можно использовать, когда нужно обращаться к чарту под другим именем (именами). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` В примере выше мы получим 3 зависимости для `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` Ручной способ достижения этого — копирование одного и того же чарта в каталог `charts/` несколько раз с разными именами. #### Поля tags и condition в зависимостях В дополнение к другим полям выше, каждая запись зависимости может содержать необязательные поля `tags` и `condition`. По умолчанию загружаются все чарты. Если присутствуют поля `tags` или `condition`, они вычисляются и используются для управления загрузкой чартов, к которым они применяются. Condition — поле condition содержит один или несколько путей YAML (разделённых запятыми). Если этот путь существует в значениях верхнего родительского чарта и разрешается в булево значение, чарт будет включён или отключён в зависимости от этого булева значения. Вычисляется только первый найденный допустимый путь из списка, и если ни один путь не существует, условие не имеет эффекта. Tags — поле tags представляет собой YAML-список меток для ассоциации с этим чартом. В значениях верхнего родительского чарта все чарты с тегами могут быть включены или отключены путём указания тега и булева значения. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` В примере выше все чарты с тегом `front-end` будут отключены, но поскольку путь `subchart1.enabled` в значениях родителя разрешается в 'true', условие переопределяет тег `front-end`, и `subchart1` будет включён. Поскольку `subchart2` помечен тегом `back-end`, и этот тег разрешается в `true`, `subchart2` будет включён. Также обратите внимание, что хотя для `subchart2` указано условие, в значениях родителя нет соответствующего пути и значения, поэтому это условие не имеет эффекта. ##### Использование CLI с тегами и условиями Параметр `--set` можно использовать как обычно для изменения значений тегов и условий. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Разрешение тегов и условий - **Условия (когда установлены в значениях) всегда переопределяют теги.** Первый существующий путь условия побеждает, последующие пути для этого чарта игнорируются. - Теги вычисляются как «если любой из тегов чарта истинен, то включить чарт». - Значения тегов и условий должны быть установлены в значениях верхнего родительского чарта. - Ключ `tags:` в значениях должен быть ключом верхнего уровня. Глобальные и вложенные таблицы `tags:` в настоящее время не поддерживаются. #### Импорт значений дочерних чартов через dependencies В некоторых случаях желательно, чтобы значения дочернего чарта передавались в родительский чарт и использовались как общие значения по умолчанию. Дополнительное преимущество использования формата `exports` заключается в том, что это позволит будущим инструментам анализировать настраиваемые пользователем значения. Ключи, содержащие импортируемые значения, могут быть указаны в `dependencies` родительского чарта в поле `import-values` с использованием YAML-списка. Каждый элемент списка — это ключ, который импортируется из поля `exports` дочернего чарта. Для импорта значений, не содержащихся в ключе `exports`, используйте формат [child-parent](#использование-формата-child-parent). Примеры обоих форматов описаны ниже. ##### Использование формата exports Если файл `values.yaml` дочернего чарта содержит поле `exports` в корне, его содержимое может быть импортировано непосредственно в значения родителя путём указания ключей для импорта, как в примере ниже: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Поскольку мы указываем ключ `data` в нашем списке импорта, Helm ищет в поле `exports` дочернего чарта ключ `data` и импортирует его содержимое. Итоговые значения родителя будут содержать наше экспортированное поле: ```yaml # parent's values myint: 99 ``` Обратите внимание, что родительский ключ `data` не содержится в итоговых значениях родителя. Если вам нужно указать родительский ключ, используйте формат 'child-parent'. ##### Использование формата child-parent Для доступа к значениям, не содержащимся в ключе `exports` значений дочернего чарта, вам нужно указать исходный ключ импортируемых значений (`child`) и путь назначения в значениях родительского чарта (`parent`). `import-values` в примере ниже указывает Helm взять любые значения по пути `child:` и скопировать их в значения родителя по пути, указанному в `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` В примере выше значения, найденные по пути `default.data` в значениях subchart1, будут импортированы в ключ `myimports` в значениях родительского чарта, как показано ниже: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` Итоговые значения родительского чарта будут: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Итоговые значения родителя теперь содержат поля `myint` и `mybool`, импортированные из subchart1. ### Ручное управление зависимостями через каталог `charts/` Если требуется больший контроль над зависимостями, их можно явно указать, скопировав зависимые чарты в каталог `charts/`. Зависимость должна быть распакованным каталогом чарта, но её имя не может начинаться с `_` или `.`. Такие файлы игнорируются загрузчиком чартов. Например, если чарт WordPress зависит от чарта Apache, чарт Apache (правильной версии) поставляется в каталоге `charts/` чарта WordPress: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` Пример выше показывает, как чарт WordPress выражает свою зависимость от Apache и MySQL, включая эти чарты в свой каталог `charts/`. **СОВЕТ:** _Чтобы добавить зависимость в каталог `charts/`, используйте команду `helm pull`_ ### Операционные аспекты использования зависимостей Разделы выше объясняют, как указывать зависимости чартов, но как это влияет на установку чарта с помощью `helm install` и `helm upgrade`? Предположим, что чарт с именем "A" создаёт следующие объекты Kubernetes: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Кроме того, A зависит от чарта B, который создаёт объекты: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" После установки/обновления чарта A создаётся/модифицируется один релиз Helm. Релиз создаст/обновит все вышеперечисленные объекты Kubernetes в следующем порядке: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Это происходит потому, что при установке/обновлении чартов объекты Kubernetes из чартов и всех их зависимостей: - агрегируются в единый набор; затем - сортируются по типу, а затем по имени; и затем - создаются/обновляются в этом порядке. Таким образом, создаётся один релиз со всеми объектами для чарта и его зависимостей. Порядок установки типов Kubernetes задаётся перечислением InstallOrder в kind_sorter.go (см. [исходный файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Шаблоны и значения Шаблоны чартов Helm написаны на [языке шаблонов Go](https://golang.org/pkg/text/template/) с добавлением около 50 дополнительных функций шаблонов [из библиотеки Sprig](https://github.com/Masterminds/sprig) и нескольких других [специализированных функций](/howto/charts_tips_and_tricks.md). Все файлы шаблонов хранятся в папке `templates/` чарта. Когда Helm рендерит чарты, он пропускает каждый файл в этом каталоге через движок шаблонов. Значения для шаблонов предоставляются двумя способами: - Разработчики чартов могут предоставить файл `values.yaml` внутри чарта. Этот файл может содержать значения по умолчанию. - Пользователи чартов могут предоставить YAML-файл со значениями. Его можно указать в командной строке с помощью `helm install`. Когда пользователь предоставляет пользовательские значения, они переопределяют значения в файле `values.yaml` чарта. ### Файлы шаблонов Файлы шаблонов следуют стандартным соглашениям для написания шаблонов Go (подробности см. в [документации пакета text/template Go](https://golang.org/pkg/text/template/)). Пример файла шаблона может выглядеть примерно так: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` Пример выше, основанный на [https://github.com/deis/charts](https://github.com/deis/charts), является шаблоном для контроллера репликации Kubernetes. Он может использовать следующие четыре значения шаблона (обычно определяемые в файле `values.yaml`): - `imageRegistry`: Исходный реестр для Docker-образа. - `dockerTag`: Тег для docker-образа. - `pullPolicy`: Политика pull для Kubernetes. - `storage`: Бэкенд хранилища, значение по умолчанию — `"minio"` Все эти значения определяются автором шаблона. Helm не требует и не диктует параметры. Чтобы увидеть множество работающих чартов, посетите CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Предопределённые значения Значения, предоставляемые через файл `values.yaml` (или через флаг `--set`), доступны из объекта `.Values` в шаблоне. Но есть и другие предопределённые данные, к которым вы можете получить доступ в шаблонах. Следующие значения предопределены, доступны в каждом шаблоне и не могут быть переопределены. Как и все значения, имена _чувствительны к регистру_. - `Release.Name`: Имя релиза (не чарта) - `Release.Namespace`: Пространство имён, в которое был выпущен чарт. - `Release.Service`: Сервис, выполнивший релиз. - `Release.IsUpgrade`: Устанавливается в true, если текущая операция — обновление или откат. - `Release.IsInstall`: Устанавливается в true, если текущая операция — установка. - `Chart`: Содержимое `Chart.yaml`. Таким образом, версия чарта доступна как `Chart.Version`, а мейнтейнеры — в `Chart.Maintainers`. - `Files`: Объект, подобный map, содержащий все неспециальные файлы в чарте. Он не даст вам доступа к шаблонам, но предоставит доступ к дополнительным файлам, которые присутствуют (если они не исключены с помощью `.helmignore`). Доступ к файлам осуществляется с помощью `{{ index .Files "file.name" }}` или функции `{{.Files.Get name }}`. Вы также можете получить доступ к содержимому файла как `[]byte` с помощью `{{ .Files.GetBytes }}` - `Capabilities`: Объект, подобный map, содержащий информацию о версиях Kubernetes (`{{ .Capabilities.KubeVersion }}`) и поддерживаемых версиях API Kubernetes (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **ПРИМЕЧАНИЕ:** Любые неизвестные поля `Chart.yaml` будут отброшены. Они не будут доступны внутри объекта `Chart`. Таким образом, `Chart.yaml` нельзя использовать для передачи произвольно структурированных данных в шаблон. Для этого можно использовать файл values. ### Файлы values Рассматривая шаблон из предыдущего раздела, файл `values.yaml`, предоставляющий необходимые значения, будет выглядеть так: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Файл values форматируется в YAML. Чарт может включать файл `values.yaml` по умолчанию. Команда helm install позволяет пользователю переопределять значения, предоставляя дополнительные YAML-значения: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Когда значения передаются таким образом, они объединяются с файлом значений по умолчанию. Например, рассмотрим файл `myvals.yaml`, который выглядит так: ```yaml storage: "gcs" ``` Когда он объединяется с `values.yaml` в чарте, результирующее сгенерированное содержимое будет: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Обратите внимание, что было переопределено только последнее поле. **ПРИМЕЧАНИЕ:** Файл значений по умолчанию, включённый в чарт, _должен_ называться `values.yaml`. Но файлы, указанные в командной строке, могут называться как угодно. **ПРИМЕЧАНИЕ:** Если флаг `--set` используется с `helm install` или `helm upgrade`, эти значения просто преобразуются в YAML на стороне клиента. **ПРИМЕЧАНИЕ:** Если в файле values существуют обязательные записи, они могут быть объявлены как обязательные в шаблоне чарта с помощью [функции 'required'](/howto/charts_tips_and_tricks.md) Любые из этих значений затем доступны внутри шаблонов с помощью объекта `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Область видимости, зависимости и значения Файлы values могут объявлять значения для чарта верхнего уровня, а также для любых чартов, включённых в каталог `charts/` этого чарта. Или, другими словами, файл values может предоставлять значения как чарту, так и любым его зависимостям. Например, демонстрационный чарт WordPress выше имеет `mysql` и `apache` в качестве зависимостей. Файл values может предоставлять значения всем этим компонентам: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Чарты более высокого уровня имеют доступ ко всем переменным, определённым ниже. Поэтому чарт WordPress может обращаться к паролю MySQL как `.Values.mysql.password`. Но чарты более низкого уровня не могут обращаться к данным в родительских чартах, поэтому MySQL не сможет получить доступ к свойству `title`. Также он не может обратиться к `apache.port`. Значения имеют пространства имён, но пространства имён обрезаются. Поэтому для чарта WordPress можно обращаться к полю пароля MySQL как `.Values.mysql.password`. Но для чарта MySQL область значений была сужена, и префикс пространства имён удалён, поэтому он увидит поле пароля просто как `.Values.password`. #### Глобальные значения Начиная с версии 2.0.0-Alpha.2, Helm поддерживает специальные "глобальные" значения. Рассмотрим эту модифицированную версию предыдущего примера: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Выше добавлен раздел `global` со значением `app: MyWordPress`. Это значение доступно _всем_ чартам как `.Values.global.app`. Например, шаблоны `mysql` могут обращаться к `app` как `{{ .Values.global.app}}`, и так же может чарт `apache`. Фактически файл values выше регенерируется следующим образом: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` Это обеспечивает способ совместного использования одной переменной верхнего уровня со всеми подчартами, что полезно для таких вещей, как установка свойств `metadata`, например меток. Если подчарт объявляет глобальную переменную, эта глобальная переменная передаётся _вниз_ (подчартам подчарта), но не _вверх_ к родительскому чарту. Подчарт не может влиять на значения родительского чарта. Кроме того, глобальные переменные родительских чартов имеют приоритет над глобальными переменными подчартов. ### Файлы Schema Иногда мейнтейнер чарта может захотеть определить структуру своих значений. Это можно сделать, определив схему в файле `values.schema.json`. Схема представляется в виде [JSON Schema](https://json-schema.org/). Она может выглядеть примерно так: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Эта схема будет применяться к значениям для их валидации. Валидация происходит при вызове любой из следующих команд: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Пример файла `values.yaml`, соответствующего требованиям этой схемы, может выглядеть примерно так: ```yaml name: frontend protocol: https port: 443 ``` Обратите внимание, что схема применяется к итоговому объекту `.Values`, а не только к файлу `values.yaml`. Это означает, что следующий `yaml` файл валиден при условии, что чарт установлен с соответствующей опцией `--set`, показанной ниже. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Кроме того, итоговый объект `.Values` проверяется на соответствие *всем* схемам подчартов. Это означает, что ограничения подчарта нельзя обойти через родительский чарт. Это также работает в обратную сторону — если подчарт имеет требование, которое не выполнено в файле `values.yaml` подчарта, родительский чарт *должен* удовлетворить эти ограничения, чтобы быть валидным. Валидацию схемы можно отключить, установив опцию, показанную ниже. Это особенно полезно в изолированных средах, когда файл JSON Schema чарта содержит удалённые ссылки. ```console helm install --skip-schema-validation ``` ### Справочные материалы Когда дело доходит до написания шаблонов, значений и файлов схем, есть несколько стандартных справочных материалов, которые вам помогут. - [Шаблоны Go](https://godoc.org/text/template) - [Дополнительные функции шаблонов](https://godoc.org/github.com/Masterminds/sprig) - [Формат YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRD) Kubernetes предоставляет механизм для объявления новых типов объектов Kubernetes. С помощью CustomResourceDefinitions (CRD) разработчики Kubernetes могут объявлять пользовательские типы ресурсов. В Helm 3 CRD рассматриваются как особый вид объектов. Они устанавливаются перед остальной частью чарта и имеют некоторые ограничения. Файлы CRD YAML должны размещаться в каталоге `crds/` внутри чарта. Несколько CRD (разделённых маркерами начала и конца YAML) могут быть размещены в одном файле. Helm попытается загрузить _все_ файлы из каталога CRD в Kubernetes. Файлы CRD _не могут быть шаблонизированы_. Они должны быть обычными YAML-документами. Когда Helm устанавливает новый чарт, он загружает CRD, приостанавливается до тех пор, пока CRD не станут доступны через API-сервер, а затем запускает движок шаблонов, рендерит остальную часть чарта и загружает её в Kubernetes. Благодаря такому порядку информация о CRD доступна в объекте `.Capabilities` в шаблонах Helm, и шаблоны Helm могут создавать новые экземпляры объектов, объявленных в CRD. Например, если ваш чарт имеет CRD для `CronTab` в каталоге `crds/`, вы можете создавать экземпляры вида `CronTab` в каталоге `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Файл `crontab.yaml` должен содержать CRD без директив шаблона: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Затем шаблон `mycrontab.yaml` может создать новый `CronTab` (используя шаблоны как обычно): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm убедится, что вид `CronTab` установлен и доступен из API-сервера Kubernetes, прежде чем продолжить установку объектов из `templates/`. ### Ограничения CRD В отличие от большинства объектов в Kubernetes, CRD устанавливаются глобально. По этой причине Helm очень осторожен в управлении CRD. CRD имеют следующие ограничения: - CRD никогда не переустанавливаются. Если Helm определяет, что CRD в каталоге `crds/` уже присутствуют (независимо от версии), Helm не будет пытаться установить или обновить их. - CRD никогда не устанавливаются при обновлении или откате. Helm создаёт CRD только при операциях установки. - CRD никогда не удаляются. Удаление CRD автоматически удаляет всё содержимое CRD во всех пространствах имён кластера. Следовательно, Helm не удаляет CRD. Операторам, желающим обновить или удалить CRD, рекомендуется делать это вручную и с большой осторожностью. ## Использование Helm для управления чартами Инструмент `helm` имеет несколько команд для работы с чартами. Он может создать для вас новый чарт: ```console $ helm create mychart Created mychart/ ``` После редактирования чарта `helm` может упаковать его в архив чарта: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Вы также можете использовать `helm` для поиска проблем с форматированием или информацией вашего чарта: ```console $ helm lint mychart No issues found ``` ## Репозитории чартов _Репозиторий чартов_ — это HTTP-сервер, на котором размещается один или несколько упакованных чартов. Хотя `helm` можно использовать для управления локальными каталогами чартов, когда дело доходит до совместного использования чартов, предпочтительным механизмом является репозиторий чартов. Любой HTTP-сервер, который может обслуживать YAML-файлы и tar-файлы и отвечать на GET-запросы, может использоваться в качестве сервера репозитория. Команда Helm протестировала некоторые серверы, включая Google Cloud Storage с включённым режимом веб-сайта и S3 с включённым режимом веб-сайта. Репозиторий характеризуется в первую очередь наличием специального файла `index.yaml`, который содержит список всех пакетов, предоставляемых репозиторием, вместе с метаданными, позволяющими получить и проверить эти пакеты. На стороне клиента управление репозиториями осуществляется командами `helm repo`. Однако Helm не предоставляет инструментов для загрузки чартов на удалённые серверы репозиториев. Это связано с тем, что это добавило бы существенные требования к реализующему серверу и, таким образом, повысило бы барьер для настройки репозитория. ## Стартовые пакеты чартов Команда `helm create` принимает необязательную опцию `--starter`, позволяющую указать "стартовый чарт". Также опция starter имеет короткий псевдоним `-p`. Примеры использования: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Стартеры — это обычные чарты, расположенные в `$XDG_DATA_HOME/helm/starters`. Как разработчик чартов, вы можете создавать чарты, специально предназначенные для использования в качестве стартеров. Такие чарты должны разрабатываться со следующими соображениями: - `Chart.yaml` будет перезаписан генератором. - Пользователи будут ожидать возможности изменять содержимое такого чарта, поэтому документация должна указывать, как пользователи могут это делать. - Все вхождения `` будут заменены указанным именем чарта, чтобы стартовые чарты могли использоваться как шаблоны, за исключением некоторых переменных файлов. Например, если вы используете пользовательские файлы в каталоге `vars` или определённые файлы `README.md`, `` НЕ будет переопределён внутри них. Кроме того, описание чарта не наследуется. В настоящее время единственный способ добавить чарт в `$XDG_DATA_HOME/helm/starters` — скопировать его туда вручную. В документации вашего чарта вы можете описать этот процесс. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Хуки чартов description: Описывает работу с хуками чартов. sidebar_position: 2 --- Helm предоставляет механизм _хуков_, позволяющий разработчикам чартов вмешиваться в определённые этапы жизненного цикла релиза. Например, хуки можно использовать для: - Загрузки ConfigMap или Secret перед загрузкой остальных чартов при установке. - Выполнения Job для резервного копирования базы данных перед установкой нового чарта, а затем выполнения другого Job после обновления для восстановления данных. - Запуска Job перед удалением релиза для корректного вывода сервиса из ротации. Хуки работают как обычные шаблоны, но имеют специальные аннотации, которые указывают Helm обрабатывать их особым образом. В этом разделе рассматриваются основные паттерны использования хуков. ## Доступные хуки Определены следующие хуки: | Значение аннотации | Описание | | ------------------ | --------------------------------------------------------------------------------------------------------- | | `pre-install` | Выполняется после рендеринга шаблонов, но до создания каких-либо ресурсов в Kubernetes | | `post-install` | Выполняется после загрузки всех ресурсов в Kubernetes | | `pre-delete` | Выполняется при запросе на удаление до удаления каких-либо ресурсов из Kubernetes | | `post-delete` | Выполняется при запросе на удаление после удаления всех ресурсов релиза | | `pre-upgrade` | Выполняется при запросе на обновление после рендеринга шаблонов, но до обновления каких-либо ресурсов | | `post-upgrade` | Выполняется при запросе на обновление после обновления всех ресурсов | | `pre-rollback` | Выполняется при запросе на откат после рендеринга шаблонов, но до отката каких-либо ресурсов | | `post-rollback` | Выполняется при запросе на откат после изменения всех ресурсов | | `test` | Выполняется при вызове подкоманды Helm test ([см. документацию по тестам](/topics/chart_tests.md)) | _Обратите внимание, что хук `crd-install` был удалён в Helm 3 в пользу директории `crds/`._ ## Хуки и жизненный цикл релиза Хуки позволяют разработчику чарта выполнять операции в ключевых точках жизненного цикла релиза. Например, рассмотрим жизненный цикл команды `helm install`. По умолчанию он выглядит так: 1. Пользователь запускает `helm install foo` 2. Вызывается API установки библиотеки Helm 3. После проверки библиотека рендерит шаблоны `foo` 4. Библиотека загружает полученные ресурсы в Kubernetes 5. Библиотека возвращает объект релиза (и другие данные) клиенту 6. Клиент завершает работу Helm определяет два хука для жизненного цикла установки: `pre-install` и `post-install`. Если разработчик чарта `foo` реализует оба хука, жизненный цикл изменяется следующим образом: 1. Пользователь запускает `helm install foo` 2. Вызывается API установки библиотеки Helm 3. Устанавливаются CRD из директории `crds/` 4. После проверки библиотека рендерит шаблоны `foo` 5. Библиотека готовится к выполнению хуков `pre-install` (загружая ресурсы хуков в Kubernetes) 6. Библиотека сортирует хуки по весу (по умолчанию вес равен 0), затем по типу ресурса и, наконец, по имени в порядке возрастания 7. Библиотека загружает хук с наименьшим весом первым (от отрицательных к положительным) 8. Библиотека ждёт, пока хук не станет «Ready» (за исключением CRD) 9. Библиотека загружает полученные ресурсы в Kubernetes. Обратите внимание: если указан флаг `--wait`, библиотека будет ждать, пока все ресурсы не перейдут в состояние готовности, и не запустит хук `post-install` до их готовности. 10. Библиотека выполняет хук `post-install` (загружая ресурсы хука) 11. Библиотека ждёт, пока хук не станет «Ready» 12. Библиотека возвращает объект релиза (и другие данные) клиенту 13. Клиент завершает работу Что означает ожидание готовности хука? Это зависит от типа ресурса, объявленного в хуке. Если ресурс имеет тип `Job` или `Pod`, Helm будет ждать его успешного завершения. Если хук завершается с ошибкой, релиз также завершится с ошибкой. Это _блокирующая операция_, поэтому клиент Helm приостановит выполнение на время работы Job. Для всех остальных типов ресурсов, как только Kubernetes отметит ресурс как загруженный (добавленный или обновлённый), он считается готовым («Ready»). Когда в хуке объявлено много ресурсов, они выполняются последовательно. Если у них есть веса (см. ниже), они выполняются в порядке весов. Начиная с Helm 3.2.0, ресурсы хуков с одинаковым весом устанавливаются в том же порядке, что и обычные ресурсы без хуков. В противном случае порядок не гарантируется. (В Helm 2.3.0 и новее они сортируются по алфавиту. Однако это поведение не является обязательным и может измениться в будущем.) Рекомендуется указывать вес хука и устанавливать его в `0`, если порядок не важен. ### Ресурсы хуков не управляются вместе с релизами Ресурсы, создаваемые хуком, в настоящее время не отслеживаются и не управляются как часть релиза. После того как Helm убедится, что хук достиг состояния готовности, он оставляет ресурс хука без изменений. Сборка мусора для ресурсов хуков при удалении соответствующего релиза может быть добавлена в Helm 3 в будущем, поэтому любые ресурсы хуков, которые не должны удаляться, следует аннотировать с помощью `helm.sh/resource-policy: keep`. На практике это означает, что если вы создаёте ресурсы в хуке, вы не можете полагаться на `helm uninstall` для их удаления. Чтобы удалить такие ресурсы, вам нужно либо [добавить аннотацию `helm.sh/hook-delete-policy`](#hook-deletion-policies) в файл шаблона хука, либо [установить поле времени жизни (TTL) для ресурса Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Написание хука Хуки — это обычные файлы манифестов Kubernetes со специальными аннотациями в секции `metadata`. Поскольку они являются файлами шаблонов, вы можете использовать все стандартные возможности шаблонизации, включая чтение `.Values`, `.Release` и `.Template`. Например, этот шаблон, сохранённый в `templates/post-install-job.yaml`, объявляет Job, который будет выполнен после установки (`post-install`): ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Что делает этот шаблон хуком — это аннотация: ```yaml annotations: "helm.sh/hook": post-install ``` Один ресурс может реализовывать несколько хуков: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Аналогично, нет ограничений на количество ресурсов, которые могут реализовывать один хук. Например, можно объявить и Secret, и ConfigMap как хуки `pre-install`. Когда субчарты объявляют хуки, они также обрабатываются. Родительский чарт не может отключить хуки, объявленные в субчартах. Можно определить вес хука, который поможет установить детерминированный порядок выполнения. Вес определяется с помощью следующей аннотации: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Вес хука может быть положительным или отрицательным числом, но должен быть представлен в виде строки. Когда Helm начинает цикл выполнения хуков определённого типа, он сортирует их в порядке возрастания веса. ### Политики удаления хуков Можно определить политики, определяющие, когда удалять соответствующие ресурсы хуков. Политики удаления хуков определяются с помощью следующей аннотации: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Вы можете выбрать одно или несколько значений аннотации: | Значение аннотации | Описание | | ---------------------- | --------------------------------------------------------------------- | | `before-hook-creation` | Удалить предыдущий ресурс перед запуском нового хука (по умолчанию) | | `hook-succeeded` | Удалить ресурс после успешного выполнения хука | | `hook-failed` | Удалить ресурс, если хук завершился с ошибкой | Если аннотация политики удаления хука не указана, по умолчанию применяется поведение `before-hook-creation`. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: Темы sidebar_position: 3 --- # Тематические руководства Здесь вы найдёте введение во все ключевые части Helm, которые вам нужно или хочется знать. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: Устаревшие API Kubernetes description: Объясняет работу с устаревшими API Kubernetes в Helm --- Kubernetes — это система, управляемая через API, и этот API развивается со временем, отражая всё более глубокое понимание предметной области. Это обычная практика для систем и их API. Важная часть развития API — это грамотная политика устаревания и процесс информирования пользователей об изменениях в API. Иными словами, пользователи вашего API должны заранее знать, в каком релизе API будет удалён или изменён. Это устраняет неожиданности и предотвращает критические изменения для пользователей. [Политика устаревания Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) описывает, как Kubernetes обрабатывает изменения версий API. Политика определяет сроки поддержки версий API после объявления об их устаревании. Поэтому важно следить за объявлениями об устаревании и знать, когда версии API будут удалены, чтобы минимизировать последствия. Вот пример объявления [об удалении устаревших версий API в Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), которое было опубликовано за несколько месяцев до выхода релиза. Эти версии API были объявлены устаревшими ещё раньше. Это показывает, что существует грамотная политика информирования пользователей о поддержке версий API. Шаблоны Helm указывают [группу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при определении объекта Kubernetes, аналогично файлу манифеста Kubernetes. Группа указывается в поле `apiVersion` шаблона и идентифицирует версию API объекта Kubernetes. Это означает, что пользователи Helm и мейнтейнеры чартов должны знать, когда версии API Kubernetes устарели и в какой версии Kubernetes они будут удалены. ## Мейнтейнеры чартов Вам следует проверить свои чарты на наличие версий API Kubernetes, которые устарели или удалены в определённой версии Kubernetes. Найденные версии API, которые скоро перестанут поддерживаться или уже не поддерживаются, следует обновить до поддерживаемой версии и выпустить новую версию чарта. Версия API определяется полями `kind` и `apiVersion`. Например, вот удалённая версия API объекта `Deployment` в Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Пользователи Helm Вам следует проверить используемые чарты (аналогично [мейнтейнерам чартов](#мейнтейнеры-чартов)) и выявить те, где версии API устарели или удалены в определённой версии Kubernetes. Для выявленных чартов вам нужно найти последнюю версию чарта (с поддерживаемыми версиями API) или обновить чарт самостоятельно. Кроме того, вам необходимо проверить все развёрнутые чарты (то есть релизы Helm), также проверяя наличие устаревших или удалённых версий API. Это можно сделать, получив информацию о релизе с помощью команды `helm get manifest`. Способ обновления релиза Helm до поддерживаемых API зависит от результатов проверки: 1. Если вы обнаружили только устаревшие версии API: - Выполните `helm upgrade` с версией чарта, содержащей поддерживаемые версии API Kubernetes - Добавьте описание при обновлении, примерно следующего содержания: не выполнять откат к версии Helm, предшествующей текущей 2. Если вы обнаружили версии API, удалённые в определённой версии Kubernetes: - Если вы используете версию Kubernetes, где эти версии API ещё доступны (например, вы на Kubernetes 1.15 и обнаружили API, которые будут удалены в Kubernetes 1.16): - Следуйте процедуре из пункта 1 - В противном случае (например, вы уже используете версию Kubernetes, где некоторые версии API, отображаемые `helm get manifest`, более недоступны): - Вам нужно отредактировать манифест релиза, хранящийся в кластере, чтобы обновить версии API до поддерживаемых. Подробнее см. [Обновление версий API в манифесте релиза](#обновление-версий-api-в-манифесте-релиза) > Примечание: Во всех случаях обновления релиза Helm до поддерживаемых API никогда не выполняйте откат релиза к версии, предшествующей версии с поддерживаемыми API. > Рекомендация: Лучшая практика — обновлять релизы с устаревшими версиями API до поддерживаемых версий API до обновления кластера Kubernetes, в котором эти версии API будут удалены. Если вы не обновите релиз, как было предложено выше, вы получите ошибку, похожую на следующую, при попытке обновить релиз в версии Kubernetes, где его версии API удалены: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm завершается с ошибкой в этом сценарии, потому что пытается создать diff-патч между текущим развёрнутым релизом (содержащим версии API Kubernetes, удалённые в этой версии Kubernetes) и чартом, который вы передаёте с обновлёнными/поддерживаемыми версиями API. Основная причина ошибки в том, что когда Kubernetes удаляет версию API, клиентская библиотека Kubernetes Go больше не может разбирать устаревшие объекты, и Helm завершается с ошибкой при вызове библиотеки. К сожалению, Helm не может восстановиться после этой ситуации и больше не может управлять таким релизом. Подробнее о том, как восстановиться после этого сценария, см. [Обновление версий API в манифесте релиза](#обновление-версий-api-в-манифесте-релиза). ## Обновление версий API в манифесте релиза Манифест — это свойство объекта релиза Helm, которое хранится в поле data Secret (по умолчанию) или ConfigMap в кластере. Поле data содержит сжатый gzip объект, закодированный в base64 (для Secret применяется дополнительное кодирование base64). Для каждой версии/ревизии релиза существует отдельный Secret/ConfigMap в пространстве имён релиза. Вы можете использовать плагин Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для обновления релиза до поддерживаемых API. Подробности см. в readme плагина. Альтернативно вы можете выполнить следующие ручные шаги для обновления версий API в манифесте релиза. В зависимости от вашей конфигурации следуйте шагам для Secret или ConfigMap. - Получите имя Secret или ConfigMap, связанного с последним развёрнутым релизом: - Для Secret: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Для ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Получите данные последнего развёрнутого релиза: - Для Secret: `kubectl get secret -n -o yaml > release.yaml` - Для ConfigMap: `kubectl get configmap -n -o yaml > release.yaml` - Создайте резервную копию релиза на случай, если что-то пойдёт не так: - `cp release.yaml release.bak` - В случае проблем восстановите: `kubectl apply -f release.bak -n ` - Декодируйте объект релиза: - Для Secret: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - Для ConfigMap: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Измените версии API в манифестах. Можно использовать любой инструмент (например, редактор) для внесения изменений. Это находится в поле `manifest` вашего декодированного объекта релиза (`release.data.decoded`) - Закодируйте объект релиза: - Для Secret: `cat release.data.decoded | gzip | base64 | base64` - Для ConfigMap: `cat release.data.decoded | gzip | base64` - Замените значение свойства `data.release` в файле развёрнутого релиза (`release.yaml`) на новый закодированный объект релиза - Примените файл к пространству имён: `kubectl apply -f release.yaml -n ` - Выполните `helm upgrade` с версией чарта, содержащей поддерживаемые версии API Kubernetes - Добавьте описание при обновлении, примерно следующего содержания: не выполнять откат к версии Helm, предшествующей текущей ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: "Руководство по дистрибутивам Kubernetes" description: "Содержит информацию об использовании Helm в различных средах Kubernetes." sidebar_position: 10 --- Helm должен работать с любой [совместимой версией Kubernetes](https://github.com/cncf/k8s-conformance) (как [сертифицированной](https://www.cncf.io/certification/software-conformance/), так и нет). В этом документе собрана информация об использовании Helm в конкретных средах Kubernetes. Пожалуйста, добавляйте информацию о других дистрибутивах (в алфавитном порядке) при необходимости. ## AKS Helm работает с [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm протестирован и работает на платформе Kubernetes в Mesosphere DC/OS 1.11, дополнительная настройка не требуется. ## EKS Helm работает с Amazon Elastic Kubernetes Service (Amazon EKS): [Использование Helm с Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Облачная платформа Google GKE работает с Helm и не требует дополнительной настройки. ## `scripts/local-cluster` и Hyperkube Hyperkube, настроенный через `scripts/local-cluster.sh`, работает без проблем. Для чистого Hyperkube может потребоваться ручная настройка. ## IKS Helm работает с [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm регулярно тестируется на [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm работает в кластерах, созданных KubeOne, без ограничений. ## Kubermatic Helm работает в пользовательских кластерах, созданных Kubermatic, без ограничений. Поскольку seed-кластер может быть настроен различными способами, поддержка Helm зависит от его конфигурации. ## MicroK8s Helm можно включить в [MicroK8s](https://microk8s.io) с помощью команды: `microk8s.enable helm3` ## Minikube Helm протестирован и работает с [Minikube](https://github.com/kubernetes/minikube). Дополнительная настройка не требуется. ## OpenShift Helm работает на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версия >= 3.6) и OpenShift Origin (версия >= 3.6). Подробнее читайте в [этой статье в блоге](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm предустановлен в [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 предоставляет доступ ко всем официальным чартам Helm через интерфейс App Catalog и CLI Kubernetes. Дополнительные репозитории можно добавить вручную. Подробнее см. в [статье о Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu с `kubeadm` Kubernetes, развёрнутый с помощью `kubeadm`, работает на следующих дистрибутивах Linux: - Ubuntu 16.04 - Fedora release 25 Некоторые версии Helm (v2.0.0-beta2) требуют выполнения `export KUBECONFIG=/etc/kubernetes/admin.conf` или создания файла `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm работает на VMware Tanzu Kubernetes Grid (TKG) без дополнительной настройки. Tanzu CLI позволяет управлять установкой пакетов для [helm-controller](https://fluxcd.io/flux/components/helm/), что обеспечивает декларативное управление релизами чартов Helm. Подробнее см. в документации TKG по [пакетам, управляемым через CLI](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Библиотечные чарты description: Описывает библиотечные чарты и примеры их использования sidebar_position: 4 --- Библиотечный чарт — это тип [чарта Helm](/topics/charts.md), который определяет примитивы или конструкции, которые могут использоваться шаблонами Helm в других чартах. Это позволяет разработчикам создавать повторно используемые фрагменты кода, избегая дублирования и соблюдая принцип [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (не повторяйся). Библиотечные чарты были введены в Helm 3 для формализации общих или вспомогательных чартов, которые использовались разработчиками чартов ещё со времён Helm 2. Выделение их в отдельный тип чарта обеспечивает: - Возможность явно различать общие и прикладные чарты - Логику, предотвращающую установку общего чарта - Отсутствие рендеринга шаблонов в общем чарте, которые могут содержать артефакты релиза - Возможность зависимым чартам использовать контекст импортирующего чарта Разработчик чартов может определить общий чарт как библиотечный и быть уверенным, что Helm будет обрабатывать его стандартным, согласованным образом. Это также означает, что определения из прикладного чарта можно переиспользовать, изменив тип чарта. ## Создание простого библиотечного чарта Как упоминалось ранее, библиотечный чарт — это тип [чарта Helm](/topics/charts.md). Это означает, что вы можете начать с создания заготовки чарта: ```console $ helm create mylibchart Creating mylibchart ``` Сначала удалите все файлы в директории `templates`, поскольку в этом примере мы создадим собственные определения шаблонов. ```console $ rm -rf mylibchart/templates/* ``` Файл values также не потребуется. ```console $ rm -f mylibchart/values.yaml ``` Прежде чем создавать общий код, рассмотрим несколько важных концепций Helm. [Именованный шаблон](/chart_template_guide/named_templates.md) (иногда называемый partial или subtemplate) — это просто шаблон, определённый внутри файла и имеющий имя. В директории `templates/` любой файл, имя которого начинается с подчёркивания (_), не предполагает вывод манифеста Kubernetes. По соглашению вспомогательные шаблоны и partial размещаются в файлах `_*.tpl` или `_*.yaml`. В этом примере мы создадим общий ConfigMap, который генерирует пустой ресурс ConfigMap. Определим общий ConfigMap в файле `mylibchart/templates/_configmap.yaml` следующим образом: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Конструкция ConfigMap определена в именованном шаблоне `mylibchart.configmap.tpl`. Это простой ConfigMap с пустым ресурсом `data`. В этом же файле есть другой именованный шаблон `mylibchart.configmap`, который вызывает именованный шаблон `mylibchart.util.merge`, принимающий 2 именованных шаблона в качестве аргументов: шаблон, вызывающий `mylibchart.configmap`, и `mylibchart.configmap.tpl`. Вспомогательная функция `mylibchart.util.merge` — это именованный шаблон в файле `mylibchart/templates/_util.yaml`. Это полезная утилита из [Common Helm Helper Chart](#common-helm-helper-chart), которая объединяет 2 шаблона и переопределяет общие части в обоих: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Это важно, когда чарт использует общий код, который нужно настроить под собственную конфигурацию. Наконец, изменим тип чарта на `library`. Для этого отредактируйте файл `mylibchart/Chart.yaml` следующим образом: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` Библиотечный чарт готов к использованию, и его определение ConfigMap можно переиспользовать. Прежде чем продолжить, стоит проверить, распознаёт ли Helm чарт как библиотечный: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Использование простого библиотечного чарта Теперь используем библиотечный чарт. Для этого снова создадим заготовку чарта: ```console $ helm create mychart Creating mychart ``` Снова очистим файлы шаблонов, так как мы хотим создать только ConfigMap: ```console $ rm -rf mychart/templates/* ``` Если бы мы хотели создать простой ConfigMap в шаблоне Helm, он мог бы выглядеть примерно так: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Однако мы собираемся переиспользовать общий код, уже созданный в `mylibchart`. ConfigMap можно создать в файле `mychart/templates/configmap.yaml` следующим образом: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Это упрощает работу: мы наследуем общее определение ConfigMap, которое добавляет стандартные свойства. В нашем шаблоне мы добавляем конфигурацию — в данном случае ключ данных `myvalue` и его значение. Конфигурация переопределяет пустой ресурс общего ConfigMap. Это возможно благодаря вспомогательной функции `mylibchart.util.merge`, которую мы упомянули в предыдущем разделе. Чтобы использовать общий код, нужно добавить `mylibchart` как зависимость. Добавьте следующее в конец файла `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Это подключает библиотечный чарт как динамическую зависимость из файловой системы, расположенную на том же родительском уровне, что и наш прикладной чарт. Поскольку мы подключаем библиотечный чарт как динамическую зависимость, нужно выполнить `helm dependency update`. Эта команда скопирует библиотечный чарт в директорию `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Теперь мы готовы развернуть наш чарт. Перед установкой стоит сначала проверить отрендеренный шаблон. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Это выглядит как ConfigMap, который нам нужен, с переопределением данных `myvalue: Hello World`. Установим его: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Мы можем получить релиз и убедиться, что фактический шаблон был загружен. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Преимущества библиотечных чартов Поскольку библиотечные чарты не могут работать как самостоятельные чарты, они могут использовать следующие возможности: - Объект `.Files` ссылается на пути к файлам в родительском чарте, а не в локальном пути библиотечного чарта - Объект `.Values` такой же, как у родительского чарта, в отличие от прикладных [субчартов](/chart_template_guide/subcharts_and_globals.md), которые получают раздел значений, настроенный под их именем в родительском чарте ## Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` Этот [чарт](https://github.com/helm/charts/tree/master/incubator/common) был оригинальным примером общих чартов. Он предоставляет утилиты, отражающие лучшие практики разработки чартов Kubernetes. Его можно сразу использовать при разработке ваших чартов, чтобы получить удобный общий код. Вот краткое руководство по его использованию. Подробнее читайте в [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Снова создайте заготовку чарта: ```console $ helm create demo Creating demo ``` Используем общий код из вспомогательного чарта. Сначала отредактируйте deployment `demo/templates/deployment.yaml` следующим образом: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` Теперь файл сервиса `demo/templates/service.yaml`: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Эти шаблоны показывают, как наследование общего кода из вспомогательного чарта упрощает написание кода до настройки или кастомизации ресурсов. Чтобы использовать общий код, нужно добавить `common` как зависимость. Добавьте следующее в конец файла `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Примечание: вам потребуется добавить репозиторий `incubator` в список репозиториев Helm (`helm repo add`). Поскольку мы подключаем чарт как динамическую зависимость, нужно выполнить `helm dependency update`. Эта команда скопирует вспомогательный чарт в директорию `charts/`. Так как вспомогательный чарт использует некоторые конструкции Helm 2, вам потребуется добавить следующее в файл `demo/values.yaml`, чтобы образ `nginx` загрузился, поскольку это было обновлено в базовой структуре чарта Helm 3: ```yaml image: tag: 1.16.0 ``` Вы можете проверить корректность шаблонов чарта перед развёртыванием с помощью команд `helm lint` и `helm template`. Если всё в порядке, развёртывайте с помощью `helm install`! ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Управление правами доступа для SQL-хранилища description: Узнайте, как настроить права доступа при использовании SQL-хранилища. --- Этот документ содержит руководство по настройке и управлению правами доступа при использовании SQL в качестве хранилища данных. ## Введение Для управления правами доступа Helm использует функциональность RBAC в Kubernetes. При использовании SQL-хранилища роли Kubernetes не могут использоваться для определения того, имеет ли пользователь доступ к конкретному ресурсу. В этом документе описывается, как создавать и управлять такими правами. ## Инициализация При первом подключении Helm CLI к вашей базе данных клиент проверяет, была ли она ранее инициализирована. Если нет, необходимая настройка выполняется автоматически. Для этой инициализации требуются права администратора на схему public или, как минимум, возможность: * создавать таблицы * назначать привилегии на схему public После выполнения миграции в вашей базе данных все остальные роли смогут использовать клиент. ## Предоставление привилегий пользователю без прав администратора в PostgreSQL Для управления правами доступа драйвер SQL-хранилища использует функцию [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row Level Security — безопасность на уровне строк) в PostgreSQL. RLS позволяет всем пользователям читать и записывать данные в одну и ту же таблицу, не имея при этом возможности манипулировать строками, к которым им явно не предоставлен доступ. По умолчанию любая роль без соответствующих привилегий будет получать пустой список при выполнении `helm list` и не сможет получить или изменить какой-либо ресурс в кластере. Рассмотрим, как предоставить роли доступ к определённым namespace: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Эта команда предоставляет роли `role` права на чтение и запись всех ресурсов, соответствующих условию `namespace = 'default'`. После создания этой политики пользователь, подключённый к базе данных от имени роли `role`, сможет видеть все релизы в namespace `default` при выполнении `helm list`, а также изменять и удалять их. С помощью RLS привилегии можно настраивать детально. Вы можете ограничивать доступ на основе различных столбцов таблицы: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Руководство по плагинам Helm description: Описывает, как использовать и создавать плагины для расширения функциональности Helm. sidebar_position: 12 --- Плагин Helm — это инструмент, доступный через CLI `helm`, но не являющийся частью встроенной кодовой базы Helm. Существующие плагины можно найти в разделе [связанные проекты](/community/related#helm-plugins) или в результатах поиска на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). В этом руководстве описывается, как использовать и создавать плагины. ## Обзор Плагины Helm — это дополнительные инструменты, которые легко интегрируются с Helm. Они позволяют расширять основную функциональность Helm без необходимости писать каждую новую возможность на Go и добавлять её в основной инструмент. Плагины Helm имеют следующие особенности: - Их можно добавлять и удалять из установки Helm без влияния на основной инструмент. - Они могут быть написаны на любом языке программирования. - Они интегрируются с Helm и отображаются в `helm help` и других местах. Плагины Helm располагаются в директории `$HELM_PLUGINS`. Вы можете узнать текущее значение этой переменной, включая значение по умолчанию, если она не задана в окружении, с помощью команды `helm env`. Модель плагинов Helm частично основана на модели плагинов Git. По этой причине `helm` иногда называют _фарфоровым_ (porcelain) слоем, а плагины — _сантехникой_ (plumbing). Иными словами, Helm отвечает за пользовательский интерфейс и логику верхнего уровня, а плагины выполняют конкретную работу по реализации нужного действия. ## Установка плагина Плагины устанавливаются с помощью команды `$ helm plugin install `. Вы можете указать путь к плагину в локальной файловой системе или URL удалённого VCS-репозитория. Команда `helm plugin install` клонирует или копирует плагин по указанному пути/URL в директорию `$HELM_PLUGINS`. При установке из VCS вы можете указать версию с помощью аргумента `--version`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Если у вас есть архив плагина в формате tar, просто распакуйте его в директорию `$HELM_PLUGINS`. Вы также можете установить плагин непосредственно из URL архива, выполнив команду `helm plugin install https://domain/path/to/plugin.tar.gz` ## Структура файлов плагина Во многих отношениях плагин похож на чарт. Каждый плагин имеет директорию верхнего уровня, содержащую файл `plugin.yaml`. Могут присутствовать дополнительные файлы, но обязательным является только `plugin.yaml`. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Файл plugin.yaml Файл plugin.yaml является обязательным для плагина. Он содержит следующие поля: ```yaml name: Имя плагина (ОБЯЗАТЕЛЬНО) version: Версия в формате SemVer 2 (ОБЯЗАТЕЛЬНО) usage: Однострочный текст использования, отображаемый в справке description: Длинное описание, отображаемое в helm help и т.д. ignoreFlags: Игнорировать флаги, переданные из Helm platformCommand: # Настройка команды для выполнения в зависимости от платформы - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами command: Команда плагина для выполнения args: Аргументы команды плагина command: (УСТАРЕЛО) Команда плагина, используйте platformCommand вместо этого platformHooks: # Настройка хуков жизненного цикла плагина в зависимости от платформы install: # Команды установки - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами command: Команда установки плагина для выполнения args: Аргументы команды установки update: # Команды обновления - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами command: Команда обновления плагина для выполнения args: Аргументы команды обновления delete: # Команды удаления - os: Совпадение с ОС, можно оставить пустым или опустить для совпадения со всеми ОС arch: Совпадение с архитектурой, можно оставить пустым или опустить для совпадения со всеми архитектурами command: Команда удаления плагина для выполнения args: Аргументы команды удаления hooks: # (Устарело) Хуки жизненного цикла плагина, используйте platformHooks вместо этого install: Команда для установки плагина update: Команда для обновления плагина delete: Команда для удаления плагина downloaders: # Настройка возможности загрузки - command: Команда для вызова protocols: - Поддерживаемая схема протокола ``` ### Поле `name` Поле `name` определяет имя плагина. Когда Helm выполняет этот плагин, он использует именно это имя (например, `helm NAME` вызовет данный плагин). _`name` должно совпадать с именем директории._ В нашем примере выше плагин с `name: last` должен находиться в директории с именем `last`. Ограничения для `name`: - `name` не может дублировать одну из существующих команд верхнего уровня `helm`. - `name` должно содержать только символы ASCII a-z, A-Z, 0-9, `_` и `-`. ### Поле `version` Поле `version` содержит версию плагина в формате SemVer 2. Поля `usage` и `description` используются для генерации текста справки команды. ### Поле `ignoreFlags` Параметр `ignoreFlags` указывает Helm _не_ передавать флаги плагину. Если плагин вызывается с `helm myplugin --foo` и установлено `ignoreFlags: true`, то флаг `--foo` будет проигнорирован. ### Поле `platformCommand` Поле `platformCommand` настраивает команду, которую плагин выполнит при вызове. Нельзя одновременно задавать `platformCommand` и `command` — это приведёт к ошибке. При выборе команды применяются следующие правила: - Если присутствует `platformCommand`, он будет использоваться. - Если и `os`, и `arch` совпадают с текущей платформой, поиск прекращается и команда выполняется. - Если `os` совпадает, а `arch` пуст, команда выполняется. - Если `os` и `arch` оба пусты, команда выполняется. - Если совпадение не найдено, Helm завершится с ошибкой. - Если `platformCommand` отсутствует, но присутствует устаревшее поле `command`, оно будет использовано. - Если команда пуста, Helm завершится с ошибкой. ### Поле `platformHooks` Поле `platformHooks` настраивает команды, которые плагин выполнит для событий жизненного цикла. Нельзя одновременно задавать `platformHooks` и `hooks` — это приведёт к ошибке. При выборе команды хука применяются следующие правила: - Если присутствует `platformHooks`, он будет использоваться и команды для события жизненного цикла будут обработаны. - Если и `os`, и `arch` совпадают с текущей платформой, поиск прекращается и команда выполняется. - Если `os` совпадает, а `arch` пуст, команда выполняется. - Если `os` и `arch` оба пусты, команда выполняется. - Если совпадение не найдено, Helm пропустит событие. - Если `platformHooks` отсутствует, но присутствует устаревшее поле `hooks`, команда для события жизненного цикла будет использована. - Если команда пуста, Helm пропустит событие. ## Создание плагина Ниже приведён YAML плагина для простого плагина, который помогает получить имя последнего релиза: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Плагинам могут потребоваться дополнительные скрипты и исполняемые файлы. Скрипты можно включить в директорию плагина, а исполняемые файлы загрузить через хук. Вот пример плагина: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Переменные окружения интерполируются перед выполнением плагина. Паттерн выше демонстрирует рекомендуемый способ указания расположения программы плагина. ### Команды плагина Существует несколько стратегий работы с командами плагина: - Если плагин включает исполняемый файл, он для `platformCommand:` должен быть упакован в директорию плагина или установлен через хук. - В строке `platformCommand:` или `command:` все переменные окружения будут раскрыты перед выполнением. `$HELM_PLUGIN_DIR` будет указывать на директорию плагина. - Сама команда не выполняется в оболочке. Поэтому нельзя записать shell-скрипт в одну строку. - Helm добавляет множество конфигурационных данных в переменные окружения. Изучите окружение, чтобы узнать, какая информация доступна. - Helm не делает предположений о языке плагина. Вы можете писать на любом языке, который предпочитаете. - Команды должны самостоятельно реализовывать текст справки для `-h` и `--help`. Helm будет использовать `usage` и `description` для `helm help` и `helm help myplugin`, но не будет обрабатывать `helm myplugin --help`. ### Тестирование локального плагина Сначала необходимо найти путь `HELM_PLUGINS`. Для этого выполните команду: ``` bash helm env ``` Перейдите в директорию, на которую указывает `HELM_PLUGINS`. Теперь вы можете создать символическую ссылку на выходные файлы сборки вашего плагина. В этом примере мы делаем это для `mapkubeapis`: ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Плагины-загрузчики По умолчанию Helm может скачивать чарты по протоколам HTTP/S. Начиная с Helm 2.4.0, плагины могут иметь специальную возможность загружать чарты из произвольных источников. Плагины объявляют эту специальную возможность в файле `plugin.yaml` (на верхнем уровне): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Если такой плагин установлен, Helm может взаимодействовать с репозиторием, используя указанную схему протокола, вызывая `command`. Специальный репозиторий добавляется так же, как обычный: `helm repo add favorite myprotocol://example.com/` Правила для специальных репозиториев такие же, как для обычных: Helm должен иметь возможность загрузить файл `index.yaml`, чтобы обнаружить и закешировать список доступных чартов. Определённая команда будет вызываться по схеме: `command certFile keyFile caFile full-URL`. SSL-учётные данные берутся из определения репозитория, хранящегося в `$HELM_REPOSITORY_CONFIG` (то есть `$HELM_CONFIG_HOME/repositories.yaml`). Плагин-загрузчик должен выводить сырое содержимое в stdout и сообщать об ошибках в stderr. Команда загрузчика также поддерживает подкоманды или аргументы, что позволяет указать, например, `bin/mydownloader subcommand -d` в `plugin.yaml`. Это полезно, если вы хотите использовать один исполняемый файл как для основной команды плагина, так и для команды загрузчика, но с разными подкомандами. ## Переменные окружения Когда Helm выполняет плагин, он передаёт плагину внешнее окружение, а также добавляет некоторые дополнительные переменные окружения. Переменные вроде `KUBECONFIG` будут установлены для плагина, если они заданы во внешнем окружении. Следующие переменные гарантированно установлены: - `HELM_PLUGINS`: Путь к директории плагинов. - `HELM_PLUGIN_NAME`: Имя плагина в том виде, в котором оно было вызвано через `helm`. Так, `helm myplug` будет иметь короткое имя `myplug`. - `HELM_PLUGIN_DIR`: Директория, содержащая плагин. - `HELM_BIN`: Путь к команде `helm` (как она была выполнена пользователем). - `HELM_DEBUG`: Указывает, был ли установлен флаг debug в helm. - `HELM_REGISTRY_CONFIG`: Расположение конфигурации реестра (при использовании). Обратите внимание, что использование Helm с реестрами является экспериментальной возможностью. - `HELM_REPOSITORY_CACHE`: Путь к файлам кеша репозиториев. - `HELM_REPOSITORY_CONFIG`: Путь к файлу конфигурации репозиториев. - `HELM_NAMESPACE`: namespace, переданный команде `helm` (обычно с флагом `-n`). - `HELM_KUBECONTEXT`: Имя контекста конфигурации Kubernetes, переданное команде `helm`. Кроме того, если файл конфигурации Kubernetes был явно указан, он будет установлен как переменная `KUBECONFIG`. ## Замечание о разборе флагов При выполнении плагина Helm разбирает глобальные флаги для собственного использования. Ни один из этих флагов не передаётся плагину. - `--burst-limit`: Преобразуется в `$HELM_BURST_LIMIT` - `--debug`: Если указан, `$HELM_DEBUG` устанавливается в `1` - `--kube-apiserver`: Преобразуется в `$HELM_KUBEAPISERVER` - `--kube-as-group`: Преобразуется в `$HELM_KUBEASGROUPS` - `--kube-as-user`: Преобразуется в `$HELM_KUBEASUSER` - `--kube-ca-file`: Преобразуется в `$HELM_KUBECAFILE` - `--kube-context`: Преобразуется в `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: Преобразуется в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: Преобразуется в `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: Преобразуется в `$HELM_KUBETOKEN` - `--kubeconfig`: Преобразуется в `$KUBECONFIG` - `--namespace` и `-n`: Преобразуется в `$HELM_NAMESPACE` - `--qps`: Преобразуется в `$HELM_QPS` - `--registry-config`: Преобразуется в `$HELM_REGISTRY_CONFIG` - `--repository-cache`: Преобразуется в `$HELM_REPOSITORY_CACHE` - `--repository-config`: Преобразуется в `$HELM_REPOSITORY_CONFIG` Плагины _должны_ выводить справочный текст и завершаться для `-h` и `--help`. В остальных случаях плагины могут использовать флаги по своему усмотрению. ## Поддержка автодополнения в оболочке Начиная с Helm 3.2, плагин может опционально предоставлять поддержку автодополнения в оболочке как часть существующего механизма автодополнения Helm. ### Статическое автодополнение Если плагин предоставляет собственные флаги и/или подкоманды, он может сообщить о них Helm, разместив файл `completion.yaml` в корневой директории плагина. Файл `completion.yaml` имеет следующий формат: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: <и так далее, рекурсивно> ``` Примечания: 1. Все секции необязательны, но должны быть предоставлены при необходимости. 1. Флаги не должны включать префикс `-` или `--`. 1. Следует указывать как короткие, так и длинные флаги. Короткий флаг не обязательно должен быть связан с соответствующей длинной формой, но обе формы должны быть перечислены. 1. Флаги не требуют определённого порядка, но должны быть указаны в правильной точке иерархии подкоманд файла. 1. Существующие глобальные флаги Helm уже обрабатываются механизмом автодополнения Helm, поэтому плагинам не нужно указывать флаги `--debug`, `--namespace` или `-n`, `--kube-context`, `--kubeconfig` и другие глобальные флаги. 1. Список `validArgs` предоставляет статический список возможных вариантов завершения для первого параметра после подкоманды. Не всегда возможно предоставить такой список заранее (см. раздел [Динамическое автодополнение](#динамическое-автодополнение) ниже), в этом случае секцию `validArgs` можно опустить. Файл `completion.yaml` полностью необязателен. Если он не предоставлен, Helm просто не будет предоставлять автодополнение в оболочке для плагина (если только плагин не поддерживает [Динамическое автодополнение](#динамическое-автодополнение)). Кроме того, добавление файла `completion.yaml` обратно совместимо и не повлияет на поведение плагина при использовании более старых версий Helm. В качестве примера для плагина [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), который не имеет подкоманд, но принимает те же флаги, что и команда `helm status`, файл `completion.yaml` выглядит так: ```yaml name: fullstatus flags: - o - output - revision ``` Более сложный пример для плагина [`2to3`](https://github.com/helm/helm-2to3), файл `completion.yaml` которого: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Динамическое автодополнение Также начиная с Helm 3.2, плагины могут предоставлять собственное динамическое автодополнение в оболочке. Динамическое автодополнение — это завершение значений параметров или флагов, которые невозможно определить заранее. Например, автодополнение имён релизов Helm, доступных в кластере. Для поддержки динамического автодополнения плагин должен предоставить **исполняемый** файл `plugin.complete` в своей корневой директории. Когда скрипту автодополнения Helm требуются динамические варианты для плагина, он выполняет файл `plugin.complete`, передавая ему командную строку, которую нужно завершить. Исполняемый файл `plugin.complete` должен содержать логику для определения подходящих вариантов завершения и выводить их на стандартный вывод для использования скриптом автодополнения Helm. Файл `plugin.complete` полностью необязателен. Если он не предоставлен, Helm просто не будет предоставлять динамическое автодополнение для плагина. Кроме того, добавление файла `plugin.complete` обратно совместимо и не повлияет на поведение плагина при использовании более старых версий Helm. Вывод скрипта `plugin.complete` должен быть списком, разделённым символами новой строки: ```console rel1 rel2 rel3 ``` При вызове `plugin.complete` окружение плагина настраивается так же, как при вызове основного скрипта плагина. Поэтому переменные `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` и все остальные переменные плагина уже будут установлены, а соответствующие глобальные флаги будут удалены. Файл `plugin.complete` может быть в любой исполняемой форме: shell-скрипт, программа на Go или любая другая программа, которую Helm может выполнить. Файл `plugin.complete` ***должен*** иметь права на выполнение для пользователя. Файл `plugin.complete` ***должен*** завершаться с кодом успеха (значение 0). В некоторых случаях для динамического автодополнения потребуется получить информацию из кластера Kubernetes. Например, плагину `helm fullstatus` требуется имя релиза на входе. В плагине `fullstatus` скрипт `plugin.complete` может просто выполнить `helm list -q` и вывести результат для автодополнения текущих имён релизов. Если желательно использовать один исполняемый файл как для выполнения плагина, так и для автодополнения плагина, скрипт `plugin.complete` может вызывать основной исполняемый файл плагина с каким-либо специальным параметром или флагом; когда основной исполняемый файл обнаружит специальный параметр или флаг, он будет знать, что нужно запустить автодополнение. В нашем примере `plugin.complete` может быть реализован так: ```sh #!/usr/bin/env sh # "$@" — это вся командная строка, требующая завершения. # Важно заключить "$@" в двойные кавычки, чтобы сохранить возможно пустой последний параметр. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Реальный скрипт плагина `fullstatus` (`status.sh`) должен искать флаг `--complete` и при его обнаружении выводить соответствующие варианты завершения. ### Советы и рекомендации 1. Оболочка автоматически отфильтровывает варианты завершения, не соответствующие вводу пользователя. Поэтому плагин может возвращать все релевантные варианты, не удаляя те, что не соответствуют вводу. Например, если командная строка `helm fullstatus ngin`, скрипт `plugin.complete` может вывести *все* имена релизов (в namespace `default`), а не только начинающиеся с `ngin`; оболочка оставит только те, что начинаются с `ngin`. 1. Для упрощения поддержки динамического автодополнения, особенно для сложного плагина, скрипт `plugin.complete` может вызывать основной скрипт плагина и запрашивать варианты завершения. См. раздел [Динамическое автодополнение](#динамическое-автодополнение) выше для примера. 1. Для отладки динамического автодополнения и файла `plugin.complete` можно выполнить следующее, чтобы увидеть результаты завершения: - `helm __complete `. Например: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Происхождение и целостность Helm description: Описывает проверку целостности и происхождения чарта. sidebar_position: 5 --- Helm предоставляет инструменты проверки происхождения, которые помогают пользователям чартов подтвердить целостность и происхождение пакета. Используя отраслевые стандарты на основе PKI, GnuPG и проверенных менеджеров пакетов, Helm может генерировать и проверять файлы подписей. ## Обзор Целостность устанавливается путём сравнения чарта с записью о происхождении. Записи о происхождении хранятся в *файлах происхождения*, которые размещаются вместе с упакованным чартом. Например, если чарт называется `myapp-1.2.3.tgz`, его файл происхождения будет называться `myapp-1.2.3.tgz.prov`. Файлы происхождения создаются при упаковке (`helm package --sign ...`) и могут быть проверены несколькими командами, в частности `helm install --verify`. ## Рабочий процесс В этом разделе описывается возможный рабочий процесс для эффективного использования данных о происхождении. Предварительные требования: - Действительная пара ключей PGP в бинарном формате (не ASCII-armored) - Инструмент командной строки `helm` - Инструменты командной строки GnuPG (опционально) - Инструменты командной строки Keybase (опционально) **ПРИМЕЧАНИЕ:** Если ваш закрытый ключ PGP защищён парольной фразой, вам будет предложено ввести её для всех команд, поддерживающих опцию `--sign`. Создание нового чарта выполняется как обычно: ```console $ helm create mychart Creating mychart ``` Когда чарт готов к упаковке, добавьте флаг `--sign` к команде `helm package`. Также укажите имя, под которым известен ключ подписи, и связку ключей, содержащую соответствующий закрытый ключ: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Примечание:** Значение аргумента `--key` должно быть подстрокой `uid` нужного ключа (из вывода `gpg --list-keys`), например, именем или email. **Отпечаток (fingerprint) использовать _нельзя_.** **СОВЕТ:** Для пользователей GnuPG секретная связка ключей находится в `~/.gnupg/secring.gpg`. Вы можете использовать команду `gpg --list-secret-keys` для просмотра доступных ключей. **Предупреждение:** В GnuPG v2 секретная связка ключей хранится в новом формате `kbx` в стандартном расположении `~/.gnupg/pubring.kbx`. Используйте следующую команду для преобразования связки ключей в устаревший формат gpg: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` На этом этапе вы должны увидеть файлы `mychart-0.1.0.tgz` и `mychart-0.1.0.tgz.prov`. Оба файла следует загрузить в выбранный вами репозиторий чартов. Вы можете проверить чарт с помощью `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Неудачная проверка выглядит следующим образом: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Для проверки при установке используйте флаг `--verify`: ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Если связка ключей с открытым ключом, соответствующим подписанному чарту, находится не в стандартном расположении, вам может потребоваться указать путь к ней с помощью `--keyring PATH`, как в примере с `helm package`. При неудачной проверке установка будет прервана ещё до рендеринга чарта. ### Использование учётных данных Keybase.io Сервис [Keybase.io](https://keybase.io) упрощает создание цепочки доверия для криптографической идентичности. Учётные данные Keybase можно использовать для подписи чартов. Предварительные требования: - Настроенная учётная запись Keybase.io - Локально установленный GnuPG - Локально установленный CLI `keybase` #### Подпись пакетов Первый шаг — импорт ваших ключей Keybase в локальную связку ключей GnuPG: ```console $ keybase pgp export -s | gpg --import ``` Эта команда преобразует ваш ключ Keybase в формат OpenPGP и импортирует его локально в файл `~/.gnupg/secring.gpg`. Вы можете проверить результат командой `gpg --list-secret-keys`: ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Обратите внимание, что ваш секретный ключ имеет идентификационную строку: ``` technosophos (keybase.io/technosophos) ``` Это полное имя вашего ключа. Теперь вы можете упаковать и подписать чарт командой `helm package`. Убедитесь, что используете хотя бы часть этой строки имени в аргументе `--key`: ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` В результате команда `package` создаст файлы `.tgz` и `.tgz.prov`. #### Проверка пакетов Аналогичным образом можно проверить чарт, подписанный ключом Keybase другого пользователя. Допустим, вы хотите проверить пакет, подписанный `keybase.io/technosophos`. Для этого используйте инструмент `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` Первая команда начинает отслеживание пользователя `technosophos`. Затем `keybase pgp pull` загружает OpenPGP-ключи всех отслеживаемых вами учётных записей и помещает их в вашу связку ключей GnuPG (`~/.gnupg/pubring.gpg`). После этого вы можете использовать `helm verify` или любые команды с флагом `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Причины, по которым проверка чарта может не пройти Вот типичные причины неудачной проверки: - Файл `.prov` отсутствует или повреждён. Это указывает на ошибку конфигурации или на то, что исходный сопровождающий не создал файл происхождения. - Ключ, использованный для подписи файла, отсутствует в вашей связке ключей. Это означает, что подписавшая сторона не входит в число тех, кому вы уже выразили доверие. - Проверка файла `.prov` не прошла. Это указывает на проблему либо с чартом, либо с данными о происхождении. - Хеши файлов в файле происхождения не совпадают с хешем файла архива. Это указывает на то, что архив был изменён. При неудачной проверке есть основания не доверять пакету. ## Файл происхождения Файл происхождения содержит YAML-файл чарта плюс несколько элементов проверочной информации. Файлы происхождения предназначены для автоматической генерации. Добавляются следующие данные о происхождении: * Файл чарта (`Chart.yaml`) включается для того, чтобы люди и инструменты могли легко просмотреть содержимое чарта. * Подпись (SHA256, как в Docker) пакета чарта (файла `.tgz`) включается для проверки целостности пакета. * Всё тело подписывается с использованием алгоритма OpenPGP (см. [Keybase.io](https://keybase.io) как современный способ упростить криптографическую подпись и проверку). Комбинация этих элементов даёт пользователям следующие гарантии: * Сам пакет не был изменён (контрольная сумма пакета `.tgz`). * Сторона, выпустившая этот пакет, известна (через подпись GnuPG/PGP). Формат файла выглядит примерно так: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Обратите внимание, что YAML-секция содержит два документа (разделённых `...\n`). Первый файл — содержимое `Chart.yaml`. Второй — контрольные суммы: соответствие имён файлов и SHA-256 дайджестов содержимого этих файлов на момент упаковки. Блок подписи — это стандартная PGP-подпись, обеспечивающая [защиту от изменений](https://www.rossde.com/PGP/pgp_signatures.html). ## Репозитории чартов Репозитории чартов служат централизованным хранилищем чартов Helm. Репозитории чартов должны обеспечивать возможность получения файлов происхождения по HTTP через определённый запрос и делать их доступными по тому же URI-пути, что и чарт. Например, если базовый URL пакета — `https://example.com/charts/mychart-1.2.3.tgz`, то файл происхождения, если он существует, ДОЛЖЕН быть доступен по адресу `https://example.com/charts/mychart-1.2.3.tgz.prov`. С точки зрения конечного пользователя, команда `helm install --verify myrepo/mychart-1.2.3` должна приводить к загрузке как чарта, так и файла происхождения без дополнительной настройки или действий со стороны пользователя. ### Подписи в реестрах на базе OCI При публикации чартов в [реестре на базе OCI](/topics/registries.md) можно использовать [плагин `helm-sigstore`](https://github.com/sigstore/helm-sigstore/) для публикации данных о происхождении в [sigstore](https://sigstore.dev/). [Как описано в документации](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), процесс создания данных о происхождении и подписи ключом GPG остаётся стандартным, но команда `helm sigstore upload` позволяет опубликовать данные о происхождении в неизменяемый журнал прозрачности. ## Установление авторитета и подлинности При работе с системами цепочки доверия важно иметь возможность установить авторитет подписывающей стороны. Иными словами, описанная выше система основана на том, что вы доверяете лицу, подписавшему чарт. А это, в свою очередь, означает, что вам нужно доверять открытому ключу подписывающей стороны. Одним из проектных решений Helm стало то, что проект Helm не будет включать себя в цепочку доверия как обязательную сторону. Мы не хотим быть «центром сертификации» для всех подписывающих чарты. Вместо этого мы настоятельно поддерживаем децентрализованную модель, что является одной из причин выбора OpenPGP в качестве базовой технологии. Поэтому, когда речь идёт об установлении авторитета, мы оставили этот шаг практически неопределённым в Helm 2 (это решение сохранено и в Helm 3). Тем не менее у нас есть рекомендации для тех, кто заинтересован в использовании системы происхождения: - Платформа [Keybase](https://keybase.io) предоставляет публичный централизованный репозиторий информации о доверии. - Вы можете использовать Keybase для хранения своих ключей или получения открытых ключей других пользователей. - Keybase также предоставляет отличную документацию. - Хотя мы не тестировали это, функция «безопасного веб-сайта» Keybase может использоваться для размещения чартов Helm. - Основная идея заключается в том, что официальный «рецензент чартов» подписывает чарты своим ключом, а полученный файл происхождения загружается в репозиторий чартов. - Ведётся работа над идеей включения списка допустимых ключей подписи в файл `index.yaml` репозитория. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Управление доступом на основе ролей description: Описывает взаимодействие Helm с системой управления доступом на основе ролей (RBAC) в Kubernetes. sidebar_position: 11 --- В Kubernetes назначение ролей пользователям или сервисным учётным записям приложений является лучшей практикой, позволяющей ограничить права приложения заданной областью. Подробнее о правах сервисных учётных записей читайте в [официальной документации Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). Начиная с Kubernetes 1.6, управление доступом на основе ролей (RBAC) включено по умолчанию. RBAC позволяет определять, какие типы действий разрешены в зависимости от пользователя и его роли в организации. С помощью RBAC вы можете: - предоставлять администраторам привилегированные операции (создание ресурсов на уровне кластера, таких как новые роли) - ограничивать возможности пользователя по созданию ресурсов (Pod, PersistentVolume, Deployment) в определённых namespace или на уровне всего кластера (квоты ресурсов, роли, CustomResourceDefinition) - ограничивать возможности пользователя по просмотру ресурсов в определённых namespace или на уровне всего кластера Руководство адресовано администраторам, которые хотят ограничить область взаимодействия пользователей с API Kubernetes. ## Управление учётными записями пользователей Все кластеры Kubernetes имеют две категории пользователей: сервисные учётные записи, управляемые Kubernetes, и обычные пользователи. Предполагается, что обычные пользователи управляются внешним независимым сервисом — администратор распределяет приватные ключи, используется хранилище пользователей вроде Keystone или Google Accounts, либо файл со списком имён пользователей и паролей. Поэтому в Kubernetes нет объектов, представляющих обычные учётные записи пользователей. Обычных пользователей нельзя добавить в кластер через вызов API. Сервисные учётные записи, напротив, управляются через API Kubernetes. Они привязаны к определённым namespace и создаются автоматически сервером API или вручную через вызовы API. Сервисные учётные записи связаны с набором учётных данных, хранящихся как Secret, которые монтируются в Pod, позволяя процессам внутри кластера взаимодействовать с API Kubernetes. Запросы к API связаны либо с обычным пользователем, либо с сервисной учётной записью, либо обрабатываются как анонимные. Это означает, что каждый процесс — как внутри, так и вне кластера — от пользователя, выполняющего `kubectl` на рабочей станции, до kubelet на узлах и компонентов плоскости управления, должен аутентифицироваться при обращении к серверу API или будет рассматриваться как анонимный пользователь. ## Role, ClusterRole, RoleBinding и ClusterRoleBinding В Kubernetes учётные записи пользователей и сервисные учётные записи могут просматривать и редактировать только те ресурсы, к которым им предоставлен доступ. Этот доступ предоставляется с помощью Role и RoleBinding. Role и RoleBinding привязаны к определённому namespace и предоставляют пользователям возможность просматривать и/или редактировать ресурсы в этом namespace в соответствии с назначенной Role. На уровне кластера используются ClusterRole и ClusterRoleBinding. Предоставление пользователю ClusterRole даёт ему доступ к просмотру и/или редактированию ресурсов во всём кластере. Это также необходимо для просмотра и/или редактирования ресурсов на уровне кластера (namespace, квоты ресурсов, узлы). ClusterRole можно привязать к определённому namespace через RoleBinding. Стандартные ClusterRole `admin`, `edit` и `view` часто используются таким образом. В Kubernetes по умолчанию доступно несколько ClusterRole. Они предназначены для пользователей и включают роли суперпользователя (`cluster-admin`) и роли с более детальным контролем доступа (`admin`, `edit`, `view`). | Стандартная ClusterRole | Стандартный ClusterRoleBinding | Описание |---------------------|----------------------------|------------- | `cluster-admin` | группа `system:masters` | Предоставляет доступ суперпользователя для выполнения любого действия над любым ресурсом. При использовании в ClusterRoleBinding даёт полный контроль над всеми ресурсами в кластере и во всех namespace. При использовании в RoleBinding даёт полный контроль над всеми ресурсами в namespace привязки роли, включая сам namespace. | `admin` | Нет | Предоставляет административный доступ, предназначенный для назначения в рамках namespace через RoleBinding. При использовании в RoleBinding разрешает чтение/запись большинства ресурсов в namespace, включая возможность создания Role и RoleBinding в этом namespace. Не разрешает запись в квоты ресурсов или сам namespace. | `edit` | Нет | Разрешает чтение/запись большинства объектов в namespace. Не разрешает просмотр или изменение Role или RoleBinding. | `view` | Нет | Разрешает просмотр большинства объектов в namespace (только чтение). Не разрешает просмотр Role, RoleBinding или Secret из соображений безопасности. ## Ограничение доступа учётной записи пользователя с помощью RBAC Теперь, когда мы разобрались с основами управления доступом на основе ролей, рассмотрим, как администратор может ограничить область доступа пользователя. ### Пример: предоставление пользователю доступа на чтение/запись в определённом namespace Чтобы ограничить доступ пользователя определённым namespace, можно использовать роль `edit` или `admin`. Если ваши чарты создают или взаимодействуют с Role и RoleBinding, следует использовать ClusterRole `admin`. Кроме того, можно создать RoleBinding с доступом `cluster-admin`. Предоставление пользователю доступа `cluster-admin` на уровне namespace даёт полный контроль над всеми ресурсами в этом namespace, включая сам namespace. В этом примере мы создадим пользователя с ролью `edit`. Сначала создайте namespace: ```console $ kubectl create namespace foo ``` Теперь создайте RoleBinding в этом namespace, назначив пользователю роль `edit`. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Пример: предоставление пользователю доступа на чтение/запись на уровне кластера Если пользователю нужно устанавливать чарты, создающие ресурсы на уровне кластера (namespace, роли, CustomResourceDefinition и т.д.), ему потребуется доступ на запись на уровне кластера. Для этого предоставьте пользователю доступ `admin` или `cluster-admin`. Предоставление пользователю доступа `cluster-admin` даёт доступ абсолютно ко всем ресурсам в Kubernetes, включая доступ к узлам через `kubectl drain` и другие административные операции. Настоятельно рекомендуется предоставлять пользователю доступ `admin` или создать пользовательскую ClusterRole, соответствующую его потребностям. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Пример: предоставление пользователю доступа только на чтение в определённом namespace Вы могли заметить, что стандартной ClusterRole для просмотра Secret не существует. ClusterRole `view` не предоставляет доступ на чтение Secret из соображений безопасности. По умолчанию Helm хранит метаданные релиза как Secret. Чтобы пользователь мог выполнить `helm list`, ему нужен доступ на чтение Secret. Для этого мы создадим специальную ClusterRole `secret-reader`. Создайте файл `cluster-role-secret-reader.yaml` и добавьте в него следующее содержимое: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Затем создайте ClusterRole с помощью команды: ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` После этого мы можем предоставить пользователю доступ на чтение большинства ресурсов, а затем добавить доступ на чтение Secret: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Пример: предоставление пользователю доступа только на чтение на уровне кластера В некоторых сценариях может быть полезно предоставить пользователю доступ на уровне кластера. Например, если пользователь хочет выполнить команду `helm list --all-namespaces`, API требует, чтобы у пользователя был доступ на чтение на уровне кластера. Для этого предоставьте пользователю доступ `view` и `secret-reader`, как описано выше, но с использованием ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Дополнительные соображения В приведённых выше примерах используются стандартные ClusterRole, поставляемые с Kubernetes. Для более детального контроля над доступом пользователей к ресурсам обратитесь к [документации Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по созданию собственных Role и ClusterRole. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Использование реестров на базе OCI description: Описывает, как использовать OCI для распространения чартов. sidebar_position: 7 --- Начиная с Helm 3, вы можете использовать контейнерные реестры с поддержкой [OCI](https://www.opencontainers.org/) для хранения и распространения пакетов чартов. Начиная с Helm v3.8.0, поддержка OCI включена по умолчанию. ## Поддержка OCI до версии v3.8.0 Поддержка OCI перешла из экспериментальной стадии в общедоступную в Helm v3.8.0. В более ранних версиях Helm поддержка OCI работала иначе. Если вы использовали поддержку OCI до Helm v3.8.0, важно понимать, что изменилось в разных версиях Helm. ### Включение поддержки OCI до версии v3.8.0 До версии Helm v3.8.0 поддержка OCI была *экспериментальной* и требовала явного включения. Чтобы включить экспериментальную поддержку OCI для версий Helm до v3.8.0, установите переменную окружения `HELM_EXPERIMENTAL_OCI`. Например: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Устаревшие возможности OCI и изменения поведения в v3.8.0 В релизе [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) следующие возможности и поведение отличаются от предыдущих версий Helm: - При указании чарта в зависимостях как OCI версию можно задавать в виде диапазона, как и для других зависимостей. - Теги SemVer, содержащие информацию о сборке, можно отправлять и использовать. Реестры OCI не поддерживают символ `+` в тегах. Helm преобразует `+` в `_` при сохранении в виде тега. - Команда `helm registry login` теперь следует той же структуре, что и Docker CLI для хранения учётных данных. Одно и то же расположение конфигурации реестра можно использовать как для Helm, так и для Docker CLI. ### Устаревшие возможности OCI и изменения поведения в v3.7.0 В релизе [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) была реализована поддержка OCI согласно [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md). В результате следующие возможности и поведение отличаются от предыдущих версий Helm: - Подкоманда `helm chart` удалена. - Кеш чартов удалён (нет `helm chart list` и т.д.). - Ссылки на реестры OCI теперь всегда должны иметь префикс `oci://`. - Базовое имя ссылки на реестр *всегда* должно совпадать с именем чарта. - Тег ссылки на реестр *всегда* должен совпадать с семантической версией чарта (т.е. теги `latest` не поддерживаются). - Медиатип слоя чарта изменён с `application/tar+gzip` на `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Использование реестров на базе OCI ### Репозитории Helm в реестрах на базе OCI [Репозиторий Helm](/topics/chart_repository.md) — это способ размещения и распространения упакованных чартов Helm. Реестр на базе OCI может содержать ноль или более репозиториев Helm, и каждый из этих репозиториев может содержать ноль или более упакованных чартов Helm. ### Использование облачных реестров Существует несколько облачных контейнерных реестров с поддержкой OCI, которые вы можете использовать для своих чартов Helm. Например: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Следуйте документации вашего провайдера облачных контейнерных реестров для создания и настройки реестра с поддержкой OCI. **Примечание:** Вы можете запустить [Docker Registry](https://docs.docker.com/registry/deploying/) или [`zot`](https://github.com/project-zot/zot) — реестры на базе OCI — на локальном компьютере. Локальные реестры следует использовать только для тестирования. ### Использование sigstore для подписи чартов на базе OCI Плагин [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) позволяет использовать [Sigstore](https://sigstore.dev/) для подписи чартов Helm теми же инструментами, что используются для подписи контейнерных образов. Это альтернатива [происхождению на основе GPG](/topics/provenance.md), поддерживаемому классическими [репозиториями чартов](/topics/chart_repository.md). Подробнее об использовании плагина `helm sigstore` см. в [документации проекта](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Команды для работы с реестрами ### Подкоманда `registry` #### `login` вход в реестр (с ручным вводом пароля) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` выход из реестра ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Подкоманда `push` Загрузка чарта в реестр на базе OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Подкоманда `push` работает только с файлами `.tgz`, предварительно созданными с помощью `helm package`. При использовании `helm push` для загрузки чарта в реестр OCI ссылка должна иметь префикс `oci://` и не должна содержать базовое имя или тег. Базовое имя берётся из имени чарта, а тег — из семантической версии чарта. это строгое требование. Некоторые реестры требуют предварительного создания репозитория и/или namespace (если указан). В противном случае во время операции `helm push` возникнет ошибка. Если вы создали [файл происхождения](/topics/provenance.md) (`.prov`) и он находится рядом с файлом чарта `.tgz`, он будет автоматически загружен в реестр при выполнении `push`. Это приводит к появлению дополнительного слоя в [манифесте чарта Helm](#манифест-чарта-helm). Пользователи [плагина helm-push](https://github.com/chartmuseum/helm-push) (для загрузки чартов в [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) могут столкнуться с проблемами, поскольку плагин конфликтует с новой встроенной командой `push`. Начиная с версии v0.10.0, плагин был переименован в `cm-push`. ### Другие подкоманды Поддержка протокола `oci://` также доступна в различных других подкомандах. Вот полный список: - `helm pull` - `helm push` - `helm show` - `helm template` - `helm install` - `helm upgrade` Базовое имя (имя чарта) ссылки на реестр *включается* для любых действий, связанных с загрузкой чарта (в отличие от `helm push`, где оно опускается). Примеры использования подкоманд с OCI-чартами: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Установка чартов с использованием дайджеста Установка чарта с использованием дайджеста более безопасна, чем с использованием тега, поскольку дайджесты неизменяемы. Дайджест указывается в URI чарта: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Указание зависимостей Зависимости чарта можно загружать из реестра с помощью подкоманды `dependency update`. Значение `repository` для записи в `Chart.yaml` указывается как ссылка на реестр без базового имени: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` При выполнении `dependency update` будет загружен `oci://localhost:5000/myrepo/mychart:2.7.0`. ## Манифест чарта Helm Пример манифеста чарта Helm в том виде, как он представлен в реестре (обратите внимание на поля `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Следующий пример содержит [файл происхождения](/topics/provenance.md) (обратите внимание на дополнительный слой): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Миграция с репозиториев чартов Миграция с классических [репозиториев чартов](/topics/chart_repository.md) (репозиториев на основе index.yaml) выполняется просто: используйте `helm pull`, а затем `helm push` для загрузки полученных файлов `.tgz` в реестр. ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Миграция с Helm v2 на v3 description: Узнайте, как мигрировать с Helm v2 на v3. sidebar_position: 13 --- В этом руководстве описано, как мигрировать с Helm v2 на v3. Helm v2 должен быть установлен и управлять релизами в одном или нескольких кластерах. ## Обзор изменений в Helm 3 Полный список изменений между Helm 2 и 3 задокументирован в [FAQ](/faq/changes_since_helm2.md). Ниже приведено краткое изложение некоторых изменений, о которых пользователю следует знать до и во время миграции: 1. Удаление Tiller: - Архитектура клиент/сервер заменена на клиент/библиотека (только бинарный файл `helm`) - Безопасность теперь реализована на уровне пользователя (делегирована системе безопасности кластера Kubernetes) - Релизы теперь хранятся как Secrets внутри кластера, и метаданные объекта релиза изменились - Релизы сохраняются в namespace релиза, а не в namespace Tiller 2. Обновления репозитория чартов: - `helm search` теперь поддерживает как поиск по локальным репозиториям, так и запросы к Artifact Hub 3. Версия apiVersion чарта обновлена до "v2" для следующих изменений спецификации: - Динамически связанные зависимости чартов перенесены в `Chart.yaml` (`requirements.yaml` удалён, requirements --> dependencies) - Чарты-библиотеки (вспомогательные/общие чарты) теперь можно добавлять как динамически связанные зависимости - У чартов появилось поле метаданных `type` для определения типа чарта: `application` или `library`. По умолчанию — application, что означает возможность рендеринга и установки - Чарты Helm 2 (apiVersion=v1) по-прежнему можно устанавливать 4. Добавлена спецификация директорий XDG: - Домашняя директория Helm удалена и заменена спецификацией директорий XDG для хранения файлов конфигурации - Больше не нужно инициализировать Helm - Команды `helm init` и `helm home` удалены 5. Дополнительные изменения: - Упрощена установка/настройка Helm: - Только клиент Helm (бинарный файл helm), без Tiller - Парадигма «запустил и работает» - Репозитории `local` и `stable` не настраиваются по умолчанию - Хук `crd-install` удалён и заменён директорией `crds` в чарте, где все CRD устанавливаются перед рендерингом чарта - Значение аннотации хука `test-failure` удалено, `test-success` объявлено устаревшим. Используйте `test` вместо них - Команды удалены/заменены/добавлены: - delete --> uninstall: по умолчанию удаляет всю историю релиза (раньше требовался флаг `--purge`) - fetch --> pull - home (удалена) - init (удалена) - install: требует имя релиза или аргумент `--generate-name` - inspect --> show - reset (удалена) - serve (удалена) - template: аргумент `-x`/`--execute` переименован в `-s`/`--show-only` - upgrade: добавлен аргумент `--history-max`, ограничивающий максимальное количество сохраняемых ревизий на релиз (0 — без ограничений) - Go-библиотека Helm 3 значительно изменилась и несовместима с библиотекой Helm 2 - Бинарные файлы релизов теперь размещаются на `get.helm.sh` ## Сценарии миграции Возможны следующие сценарии миграции: 1. Helm v2 и v3 управляют одним кластером: - Этот сценарий рекомендуется только если вы планируете постепенно отказаться от Helm v2 и не нуждаетесь в управлении v3 релизами, развёрнутыми через v2. Все новые релизы должны развёртываться через v3, а существующие релизы v2 обновляются/удаляются только через v2 - Helm v2 и v3 могут без проблем управлять одним кластером. Версии Helm можно установить на одной или разных системах - Если вы устанавливаете Helm v3 на ту же систему, необходим дополнительный шаг для сосуществования обеих версий клиента до удаления клиента Helm v2. Переименуйте бинарный файл Helm v3 или поместите его в другую папку для избежания конфликта - В остальном конфликтов между версиями нет благодаря следующим различиям: - Хранилища релизов (истории) v2 и v3 независимы друг от друга. Изменения включают ресурс Kubernetes для хранения и метаданные объекта релиза. Релизы также привязаны к namespace пользователя, а не к namespace Tiller (например, namespace Tiller по умолчанию в v2 — kube-system). v2 использует "ConfigMaps" или "Secrets" в namespace Tiller с владельцем `TILLER`. v3 использует "Secrets" в namespace пользователя с владельцем `helm`. Релизы инкрементальны как в v2, так и в v3 - Единственная проблема может возникнуть, если в чарте определены кластерные ресурсы Kubernetes (например, `clusterroles.rbac`). В этом случае развёртывание v3 завершится ошибкой, даже если ресурс уникален в namespace, поскольку ресурсы будут конфликтовать - Конфигурация v3 больше не использует `$HELM_HOME` и вместо этого использует спецификацию директорий XDG. Она создаётся по мере необходимости и независима от конфигурации v2. Это актуально только при установке обеих версий на одной системе 2. Миграция с Helm v2 на Helm v3: - Этот сценарий применяется, когда вы хотите, чтобы Helm v3 управлял существующими релизами Helm v2 - Следует учитывать, что клиент Helm v2: - может управлять от 1 до нескольких кластеров Kubernetes - может подключаться к нескольким экземплярам Tiller в кластере - Это означает, что при миграции нужно учитывать, что релизы развёртываются в кластеры через Tiller и его namespace. Поэтому необходимо выполнять миграцию для каждого кластера и каждого экземпляра Tiller, которыми управляет экземпляр клиента Helm v2 - Рекомендуемый путь миграции данных: 1. Создайте резервную копию данных v2 2. Мигрируйте конфигурацию Helm v2 3. Мигрируйте релизы Helm v2 4. Когда убедитесь, что Helm v3 управляет всеми данными Helm v2 (для всех кластеров и экземпляров Tiller экземпляра клиента Helm v2) как ожидалось, очистите данные Helm v2 - Процесс миграции автоматизирован плагином Helm v3 [2to3](https://github.com/helm/helm-2to3) ## Справочные материалы - Плагин Helm v3 [2to3](https://github.com/helm/helm-2to3) - [Статья в блоге](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) с описанием использования плагина `2to3` и примерами ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Политика поддержки версий Helm" description: "Описывает политику патч-релизов Helm, а также максимально допустимое расхождение версий между Helm и Kubernetes." --- В этом документе описывается максимально допустимое расхождение версий между Helm и Kubernetes. ## Поддерживаемые версии Версии Helm записываются в формате `x.y.z`, где `x` — мажорная версия, `y` — минорная версия, а `z` — патч-версия, в соответствии с терминологией [семантического версионирования](https://semver.org/spec/v2.0.0.html). Проект Helm поддерживает ветку релиза для последней минорной версии. Применимые исправления, включая исправления безопасности, переносятся в ветку релиза в зависимости от серьёзности и выполнимости. Подробнее см. в [политике релизов Helm](/community/release_policy). ## Поддерживаемое расхождение версий При выпуске новой версии Helm она компилируется с определённой минорной версией Kubernetes. Например, Helm 3.0.0 взаимодействует с Kubernetes через клиент Kubernetes 1.16.2, поэтому совместим с Kubernetes 1.16. Начиная с Helm 3, он совместим с версиями Kubernetes `n-3` относительно той версии, с которой был скомпилирован. Для Helm 2 политика поддержки строже из-за различий между минорными версиями Kubernetes — он совместим только с версиями `n-1`. Например, если вы используете версию Helm 3, скомпилированную с клиентскими API Kubernetes 1.17, то её безопасно использовать с Kubernetes 1.17, 1.16, 1.15 и 1.14. Если вы используете версию Helm 2, скомпилированную с клиентскими API Kubernetes 1.16, то её безопасно использовать с Kubernetes 1.16 и 1.15. Не рекомендуется использовать Helm с версией Kubernetes новее той, с которой он был скомпилирован, поскольку Helm не гарантирует совместимость с более новыми версиями. Если вы решите использовать Helm с неподдерживаемой версией Kubernetes, вы делаете это на свой страх и риск. Используйте таблицу ниже, чтобы определить, какая версия Helm совместима с вашим кластером. | Версия Helm | Поддерживаемые версии Kubernetes | |--------------|----------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Введение", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Как делать", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Темы", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Лучшие практики", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Руководство по шаблонам чартов", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Команды Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Сообщество", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Часто задаваемые вопросы", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/ru/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "Политика расписания релизов" description: "Описывает политику расписания релизов Helm." --- Для удобства пользователей Helm объявляет даты релизов заранее. В этом документе описывается политика, определяющая расписание релизов Helm. ## Календарь релизов Публичный календарь с предстоящими релизами Helm доступен [здесь](https://helm.sh/calendar/release). ## Семантическое версионирование Версии Helm записываются в формате `x.y.z`, где `x` — мажорная версия, `y` — минорная версия, а `z` — патч-версия, в соответствии с терминологией [семантического версионирования](https://semver.org/spec/v2.0.0.html). ## Патч-релизы Патч-релизы предоставляют пользователям исправления ошибок и исправления безопасности. Они не содержат новых функций. Новый патч-релиз для последней минорной/мажорной версии обычно выпускается во вторую среду каждого месяца. Патч-релиз для исправления критической регрессии или проблемы безопасности может быть выпущен в любое время. Патч-релиз будет отменён по любой из следующих причин: - если с момента предыдущего релиза нет новых изменений - если дата патч-релиза попадает в период за неделю до первого релиз-кандидата (RC1) предстоящего минорного релиза - если дата патч-релиза попадает в период четырёх недель после минорного релиза ## Минорные релизы Минорные релизы содержат исправления безопасности и ошибок, а также новые функции. Они обратно совместимы с точки зрения API и использования CLI. Для согласования с релизами Kubernetes минорный релиз Helm выпускается каждые 4 месяца (3 релиза в год). Дополнительные минорные релизы могут быть выпущены при необходимости, но это не повлияет на график объявленного будущего релиза, если до объявленного релиза не осталось менее 7 дней. Одновременно с публикацией релиза объявляется дата следующего минорного релиза, которая размещается на главной странице сайта Helm. ## Мажорные релизы Мажорные релизы содержат изменения, нарушающие обратную совместимость. Такие релизы редки, но иногда необходимы, чтобы позволить Helm развиваться в важных новых направлениях. Мажорные релизы сложно планировать. С учётом этого окончательная дата релиза будет выбрана и объявлена только после выхода первой бета-версии такого релиза. ================================================ FILE: i18n/ru/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Проект Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Разработка", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Сообщество", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Исходный код", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Блог", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "События", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Кодекс поведения", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Введение", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Советы и хитрости для чартов", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Разработка чартов", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Поиск 800+ чартов", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Руководство по вкладу", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Мейнтейнеры", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Еженедельные встречи", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Сообщество на GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Мы — дипломированный проект Cloud Native Computing Foundation.
© Авторы Helm 2025. Документация распространяется под лицензией CC-BY-4.0.
© 2025 The Linux Foundation. Все права защищены. The Linux Foundation имеет зарегистрированные товарные знаки и использует товарные знаки. Для получения списка товарных знаков The Linux Foundation посетите нашу страницу использования товарных знаков.", "description": "The footer copyright" }, "logo.alt": { "message": "Логотип CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/ru/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Логотип Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Документация", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Блог", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Сообщество", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/uk/code.json ================================================ { "home.community.nextFeatureRelease": { "message": "Наступний реліз", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "Версія:", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "Дата:", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "Календар релізів", "description": "Release Calendar link" }, "home.community.events": { "message": "Події", "description": "Events section title" }, "home.community.upcomingEvents": { "message": "Майбутні події", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "Майбутні події", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "Минулі події", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "Робоча група SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "Зустрічі робочої групи проходять {meetLink}. На зустрічах відбуваються обговорення та демонстрації інструментів та проєктів. Зустрічі спільноти записуються та {youtubeLink}.", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "щотижня", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "розміщуються на YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "Зустрічі розробників" }, "home.community.developerStandups.time": { "message": "Четвер 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "Ці зустрічі відкриті для всіх. Перегляньте {communityRepoLink} для ознайомалення з нотатками зустрічей та отримання докладних відомостей.", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "репозиторій спільноти", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "Обговорення використання Helm, роботи з чартами та вирішення типових помилок.", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "Теми, що стосуються розробки Helm, поточних PR, релізів тощо.", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "Обговорення для користувачів та контрибʼюторів чартів Helm.", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink}, щоб приєднатися до команди в Slack Kubernetes.", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "Отримайте доступ тут", "description": "Request access to slack link" }, "home.community.contributing": { "message": "Участь в проєкті", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm завжди радий вашій допомозі!", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "З чого почати?", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm — це великий проєкт з багатьма користувачами та учасниками. Тут багато чого можна дізнатися!", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "У нас є список {goodFirstIssuesLink}, якщо ви хочете допомогти, але не знаєте, з чого розпочати.", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "перших завдань", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "Що мені робити?", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "Перш ніж писати код, будь ласка, прочитайте наші {contributionGuideLink}. Вони описують процеси створення та рецензування пул-реквестів.", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "Настанови щодо участі", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "Після того, як ви напишете код, будь ласка, {signYourCommitsLink}, щоб переконатися, що Helm дотримується угоди {dcoLink}, яка використовується {cncfLink}.", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "підпишіть свої коміти", "description": "Sign your commits link" }, "home.community.title": { "message": "Приєднуйтесь до спільноти", "description": "Join the Community title" }, "home.community.subtitle": { "message": "Більше інформації про проєкт Helm та про те, як зробити свій внесок.", "description": "Join the Community subtitle" }, "home.about.whatIsHelm": { "message": "Helm допомагає керувати застосунками Kubernetes — чарти Helm допомагають визначати, встановлювати та оновлювати навіть найскладніші застосунки Kubernetes.", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Чарти легко створювати, версіонувати, ділитися ними та публікувати — тому почніть використовувати Helm і перестаньте займатися копіюванням та вставкою.", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm є дипломованим проєктом {cncfLink}, який підтримується {helmCommunityLink}.", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "спільнотою Helm", "description": "Helm community link" }, "home.about.learnMore": { "message": "Дізнайтеся більше:", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Архітектура Helm", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "Швидкий старт", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "Відео: Вступ до Helm", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "Що таке Helm?", "description": "What is Helm? title" }, "home.features.manageComplexity": { "message": "Керування складністю", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Чарти описують навіть найскладніші застосунки, забезпечують повторюваність встановлення застосунків і слугують єдиним авторитетним джерелом інформації.", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "Прості оновлення", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "Позбудьтеся складнощів оновлення за допомогою оновлень на місці та використання власних хуків.", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "Просте поширення", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Чарти легко версіонувати, поширювати та розміщувати на публічних або приватних серверах.", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "Відкат змін", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "Використовуйте {helmRollback}, щоб легко повернутися до старішої версії релізу.", "description": "Rollbacks section description" }, "home.features.title": { "message": "Функції", "description": "Features section title" }, "home.header.tagline": { "message": "Менеджер пакетів для Kubernetes", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm — найкращий спосіб знайти, поділитися та використовувати програмне забезпечення, створене для", "description": "Home page header subtitle" }, "home.gettingStarted.title": { "message": "Початок роботи", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "Отримайте Helm!", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "Встановіть Helm за допомогою менеджера пакетів або {downloadLink}.", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "завантажте бінарний файл", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "Після встановлення розпакуйте бінарний файл helm, додайте його до вашого PATH — і все готово! Ознайомтесь з {docsLink} для отримання детальної інформації про {installationLink} та {usageLink}.", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "документацією", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "встановлення", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "інструкціями з використання", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "Отримання чартів", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "Відвідайте {artifactHubLink}, щоб ознайомитися з {helmChartsLink} з численних публічних репозиторіїв.", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "чартами Helm", "description": "Helm charts link" }, "home.support.title": { "message": "Нас підтримують", "description": "Community support section title" }, "home.support.subtitle": { "message": "Helm підтримується та розвивається спільнотою, що налічує понад 400 розробників.", "description": "Community support section subtitle" }, "home.support.maintainers": { "message": "...та {maintainersLink}.", "description": "Link to core maintainers" }, "home.support.maintainersLink": { "message": "багато інших чудових розробників ядра Helm", "description": "Core maintainers link text" }, "theme.ErrorPageContent.title": { "message": "На сторінці стався збій.", "description": "The title of the fallback page when the page crashed" }, "theme.blog.archive.title": { "message": "Архів", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "Архів", "description": "The page & hero description of the blog archive page" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "Прокрутити до початку", "description": "The ARIA label for the back to top button" }, "theme.blog.paginator.navAriaLabel": { "message": "Навігація по сторінці списку блогів", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "Наступні дописи", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "Попередні дописи", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "Навігація по сторінці посту блогу", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "Наступний пост", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "Попередній пост", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "Переглянути всі теґи", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "Автоматичний режим", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "Світлий режим", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "Темний режим", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "Перемикання між темним та світлим режимом (зараз використовується {mode})", "description": "The ARIA label for the color mode toggle" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "{count} елемент|{count} елементи|{count} елементів", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "Навігаційний ланцюжок поточної сторінки", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.paginator.navAriaLabel": { "message": "сторінка документації", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "Попередня сторінка", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "Наступна сторінка", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "Одна сторінка|{count} сторінки|{count} сторінок", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged} з теґом \"{tagName}\"", "description": "The title of the page for a docs tag" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "Це документація для майбутньої версії {siteTitle} {versionLabel}.", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "Це документація {siteTitle} для версії {versionLabel}, яка вже не підтримується.", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "Актуальна документація знаходиться на сторінці {latestVersionLink} ({versionLabel}).", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "останньої версії", "description": "The label used for the latest version suggestion link label" }, "theme.docs.versionBadge.label": { "message": "Версія: {versionLabel}" }, "theme.common.editThisPage": { "message": "Редагувати цю сторінку", "description": "The link label to edit the current page" }, "theme.lastUpdated.atDate": { "message": " {date}", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": " від {user}", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "Останнє оновлення{atDate}{byUser}", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.common.headingLinkTitle": { "message": "Пряме посилання на {heading}", "description": "Title for link to heading" }, "theme.NotFound.title": { "message": "Сторінку не знайдено", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "Версії", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "Теґи:", "description": "The label alongside a tag list" }, "theme.admonition.caution": { "message": "обережно", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "небезпека", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "інформація", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "примітка", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "порада", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "попередження", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "Закрити", "description": "The ARIA label for close button of announcement bar" }, "theme.blog.sidebar.navAriaLabel": { "message": "Навігація за останніми постами у блозі", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "Розгорнути категорію в панелі '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "Згорнути категорію в панелі '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(відкриється в новій вкладці)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "Головна", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "На жаль, ми не змогли знайти сторінку, яку ви запитували.", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "Будь ласка, зверніться до власника сайту, з якого ви перейшли за цим посиланням, щоб повідомити, що воно не працює.", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "Мови", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "Зміст цієї сторінки", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "Читати далі", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "Докладніше про {title}", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "{readingTime} хв. читання|{readingTime} хв. читання|{readingTime} хв. читання", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.copy": { "message": "Копіювати", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "Скопійовано", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "Копіювати в буфер обміну", "description": "The ARIA label for copy code blocks button" }, "theme.CodeBlock.wordWrapToggle": { "message": "Перенос рядків", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.docs.breadcrumbs.home": { "message": "Головна сторінка", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "Згорнути панель", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "Згорнути панель", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.navAriaLabel": { "message": "Панель документації", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "Закрити панель", "description": "The ARIA label for close button of mobile sidebar" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "Показати/сховати панель", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← Перейти до головного меню", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "Розгорнути випадаючий список", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "Згорнути випадаючий список", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.docs.sidebar.expandButtonTitle": { "message": "Розгорнути панель", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "Розгорнути панель", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.blog.post.plurals": { "message": "{count} запис|{count} записи|{count} записів", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} з теґом \"{tagName}\"", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "Автори", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "Переглянути всіх авторів", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "Цей автор ще не написав жодної публікації.", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "Непублічна сторінка", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "Ця сторінка є непублічною. Пошукові системи її не індексуватимуть, і доступ до неї матимуть лише користувачі з прямим посиланням.", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "Чернетка", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "Це чернетка. Ця сторінка видима лише в режимі розробки й буде виключена з фінальної збірки.", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "Спробуйте ще раз", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "Перейти до основного вмісту", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "Теґи", "description": "The title of the tag list page" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-blog/2024-10-07-kubecon-na-24/index.md ================================================ --- title: "Helm на KubeCon/CloudNativeCon SLC" slug: "kubecon-slc" authors: ["mattfarina"] date: "2024-11-07" --- ![Логотип KubeCon / CloudNativeCon](kubecon.png) Helm буде присутній на KubeCon / CloudNativeCon North America в Солт-Лейк-Сіті. Щодня під час основної частини конференції відбуватимуться різні події, зокрема: * Середа: * Присутність на стенді в павільйоні проєктів з 3:15pm до 8pm. * О 7pm MST ми плануємо наживо зробити реліз. * Четвер: * Присутність на стенді в павільйоні проєктів з 1:45pm до 5pm. * Сесія: [Contribfest: Helm 4: Наступне покоління менеджера пакетів для Kubernetes](https://kccncna2024.sched.com/event/1howt) * Сесія: [Шлях до Helm 4](https://kccncna2024.sched.com/event/1hoxU) * Пʼятниця: * З 12:30pm до 2:30pm у павільйоні проєктів Якщо ви хочете поспілкуватися з мейнтейнером, щоб дізнатися більше про Helm або залишити свої відгуки, павільйон проєктів — це ідеальне місце для цього. Якщо вас цікавить Helm v4, сесія "Шлях до Helm 4" надасть огляд. А якщо ви хочете зробити свій перший внесок у Helm, сесія Contribfest стане гарним стартом. Якщо ви будете в Солт-Лейк-Сіті, сподіваємось побачити вас там. ================================================ FILE: i18n/uk/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md ================================================ --- title: "Шлях до випуску Helm v4" slug: "path-to-helm-v4" authors: ["mattfarina"] date: "2025-09-09" --- Випущено [першу альфа-версію Helm v4](https://github.com/helm/helm/releases/tag/v4.0.0-alpha.1). Тепер, коли розробка Helm v4 вступає у фінальну стадію, ми хотіли б поділитися деталями про те, що відбувається, і як широкий загал може долучитися до цього процесу. ## Альфа-період {#alpha-period} З початком вересня введення нових основних функцій для Helm v4 призупинено. Починається альфа-фаза, під час якої все ще будуть відбуватися зміни, що порушують API, але основна увага приділятиметься стабільності та забезпеченню очікуваної роботи вже внесених змін. Якщо ви користуєтеся Helm, протягом цього періоду ви можете протестувати поточні можливості та надати відгук, якщо щось не працює як очікується. Просто памʼятайте, що це програмне забезпечення альфа-якості, і зміни все ще відбуваються. Для користувачів Helm SDK зараз хороший час, щоб ознайомитися з API і перевірити, чи є якісь занепокоєння щодо змін у дизайні, а також чи вплинуть вони на вашу роботу. Період Альфа триватиме протягом вересня. ## Бета-період {#beta-period} Бета-період розпочинається в жовтні. На цьому етапі основна увага приділяється стабільності в рамках підготовки до випуску. Зміни, що порушують API, повинні бути завершені, і основна увага переходить до виправлення будь-яких помилок, щоб забезпечити стабільний випуск. Тестувальники повинні повідомляти про помилки, коли вони стикаються з будь-якими проблемами. Відповідно до [політики випуску версій](/community/release_policy#major-releases), після виходу першої бета-версії буде обрано та оголошено остаточну дату випуску версії 4.0.0. ## Претенденти на випуск {#release-candidates} Наприкінці жовтня буде створено першого претендента на випуск. Він представляє те, що, на нашу думку, буде випущено як Helm v4. Якщо будуть виявлені якісь серйозні проблеми, їх буде виправлено і буде створено нового претендента на випуск. ## 🎉 Випуск 🎉 {#-release-} Випуск заплановано на KubeCon + CloudNativeCon North America 2025 в середині листопада, що через 6 років після випуску Helm v3 і через 10 років після створення Helm. Більш детальну інформацію про випуск буде надано згодом. ================================================ FILE: i18n/uk/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "Блог", "description": "The title for the blog used in SEO" }, "description": { "message": "Блог", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "Всі записи", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/_v4-in-progress.mdx ================================================ :::warning Цю сторінку ще не було оновлено для Helm 4. Деякі відомості можуть бути неточними або не стосуватися Helm 4. Докладнішу інформацію про нові функції, вдосконалення та істотні зміни в Helm 4 див. в [Огляді Helm 4](/overview.md). ::: ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/changelog.md ================================================ --- sidebar_position: 2 sidebar_label: Повний список змін --- # Helm 4 Повний список змін **Обсяг**: 290 PR від (`v4.0.0-rc.1`) порівняно з `v3.19.0`
**Тільки v4**: 257 PR (33, перенесені до v3, виключені) Дивіться [Огляд](/overview.md) для отримання детального опису цих змін. ## Нові функції {#new-features} Нові функції в Helm 4, які не були перенесені в v3 | PR | Дата | Автор | Назва | |---|---|---|---| | #31435 | 2025-11-03 | matheuscscp | Introduce a context for canceling wait operations | | #31389 | 2025-10-30 | TerryHowe | chore: fix pkg/registry warnings to reduce noise | | #31338 | 2025-10-21 | yzewei | Add loongarch64 support | | #31351 | 2025-10-21 | gjenkins8 | feat: `helm version` print Kubernetes (client-go) version | | #31376 | 2025-10-21 | benoittgt | Do not ignore *.yml file on linting while accepting *.yaml | | #31362 | 2025-10-21 | fabiocarneiro | Clarify the intent of the resource instructions | | #31392 | 2025-10-16 | TerryHowe | feature: create copilot structured context | | #31295 | 2025-10-13 | TerryHowe | Fix make helm list show all by default | | #31372 | 2025-10-10 | mattfarina | Enable Releases To Have Multiple Versions | | #31254 | 2025-09-23 | benoittgt | Warn when we fallback to a different version on `helm pull` | | #31275 | 2025-09-10 | benoittgt | Extend --skip-schema-validation for lint command | | #31116 | 2025-09-02 | banjoh | chore: check if go modules are tidy before build | | #31217 | 2025-09-01 | scottrigby | BREAKING CHANGE: [HIP-0026] Move Postrenderer to a plugin type | | #31196 | 2025-08-31 | scottrigby | BREAKING CHANGE: [HIP-0026] Remove unnecessary file i/o operations from signing and verifying | | #31176 | 2025-08-30 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin packaging, signing, and verification | | #31194 | 2025-08-28 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Plugin extism/v1 runtime | | #30812 | 2025-08-27 | gjenkins8 | BREAKING CHANGE: HIP-0023: Helm support server-side apply | | #31174 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin tarball support for HTTP and local installers | | #31172 | 2025-08-26 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin OCI installer | | #31146 | 2025-08-23 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin types and plugin apiVersion v1 | | #31145 | 2025-08-22 | scottrigby | BREAKING CHANGE: [HIP-0026] Plugin runtime interface | | #31142 | 2025-08-21 | gjenkins8 | BREAKING CHANGE: [HIP-0026] Move pkg/plugin -> internal/plugin | | #31030 | 2025-08-14 | gjenkins8 | BREAKING CHANGE: HIP-0023: Kube client support server-side apply | | #12624 | 2025-08-13 | papdaniel | show crds command output separated by document separator | | #13111 | 2025-08-13 | rawtaz | style(pkg/chartutil): add missing dots and indentation to defaultValues | | #31076 | 2025-08-11 | matheuscscp | pkg/registry: Login option for passing TLS config in memory | | #31034 | 2025-08-05 | Mazafard | Feat: Add color output functionality and tests for release statuses | | #31057 | 2025-07-18 | danilobuerger | Pass credentials when either chart repo or repo dont specify a port but it matches the default port of that scheme | | #31019 | 2025-07-17 | zachburg | Return early when linting if the `templates/` directory does not exist | | #31011 | 2025-07-17 | yalosev | feature: add labels to metadata | | #31015 | 2025-07-17 | zachburg | Add linter support for the `crds/` directory | | #13154 | 2025-07-10 | carloslima | Allow post-renderer to process hooks | | #13586 | 2025-06-04 | jessesimpson36 | feat: add formatting for errors to make multiline stacktraces in helm templates | | #30553 | 2025-05-07 | Zhanweelee | feat: Add mustToYaml and mustToJson template functions | | #30734 | 2025-04-21 | ipaqsa | feat(pkg/engine): add support for custom template funcs | | #13283 | 2025-04-14 | win-t | adding support for JSON Schema 2020 | | #30751 | 2025-04-13 | benoittgt | Add detailed debug logging for resource readiness states | | #30708 | 2025-04-11 | benoittgt | Migrate pkg to slog | | #13604 | 2025-04-05 | AustinAbro321 | Introduce kstatus watcher | | #13617 | 2025-02-27 | AustinAbro321 | BREAKING CHANGE: Refactor cmd/helm to allow library usage | | #30571 | 2025-02-24 | yardenshoham | feat: error out when post-renderer produces no output | | #13655 | 2025-02-20 | LuBingtan | feat: support multi-document values files | | #13471 | 2025-02-19 | wangjingcun | Use a more direct and less error-prone return value | | #30294 | 2025-02-19 | Zhanweelee | Supports json arguments | | #13538 | 2025-01-17 | godhanipayal | Add Contextual Error Messages to RunWithContext | | #12588 | 2024-11-22 | rynowak | Make the authorizer and registry authorizer configurable | ## Виправлення помилок {#bug-fixes} Виправлення в Helm 4, які не були перенесені в v3 | PR | Дата | Автор | Назва | |---|---|---|---| | #31323 | 2025-10-29 | mattfarina | Reproducible chart archive builds | | #31411 | 2025-10-29 | banjoh | fix: reinstate logger parameter to actions package | | #31204 | 2025-10-22 | benoittgt | Avoid panic in helm.sh/helm/v3/pkg/chartutil.ValidateAgainstSchema | | #31337 | 2025-10-22 | rachelvweber | Fixing rollback and uninstall client WaitStrategy | | #31393 | 2025-10-21 | benoittgt | Return errors during upgrade when the deletion of resources fails | | #31406 | 2025-10-21 | jessesimpson36 | fix: kube client should return empty results objects instead of nil | | #31375 | 2025-10-13 | TerryHowe | fix: release info time parsing | | #31349 | 2025-10-07 | TerryHowe | fix: flakey lint test on shuffle | | #31327 | 2025-10-07 | TerryHowe | fix: broken `--html` flag to coverage script | | #31354 | 2025-10-07 | TerryHowe | fix: flake upgrade test | | #31227 | 2025-10-03 | evankanderson | Use filepath.Path when handling directory names | | #31307 | 2025-10-02 | TerryHowe | fix: Ignore absolute path when RepoUrl is provided | | #31334 | 2025-09-30 | fleaz | Fix typo in bug-report issue template | | #31330 | 2025-09-25 | mattfarina | Restore lint rule for excluding meaningless name | | #31320 | 2025-09-25 | kosiew | provenance: allow RSA signing when ed25519 keys are present (switch to ProtonMail/go-crypto) | | #31285 | 2025-09-12 | bennsimon | fix: remove leftover debugging line that outputs invalid YAML for helm template command | | #31277 | 2025-09-11 | benoittgt | Fix deprecation warning for spf13/pflag from 1.0.7 to 1.0.10 | | #31272 | 2025-09-09 | TerryHowe | fix: idea gitignore entry | | #31252 | 2025-09-05 | kamilswiec | fix:chartfile tests - semver2 error message | | #31199 | 2025-09-05 | TerryHowe | fix: flaky registry data race on mockdns close | | #31200 | 2025-09-05 | TerryHowe | fix: installer action goroutine count | | #31222 | 2025-09-03 | benoittgt | Prevent failing `helm push` on ghcr.io using standard GET auth token flow | | #31191 | 2025-08-26 | TerryHowe | fix: send logging to stderr | | #31138 | 2025-08-19 | islewis | fix(helm-lint): Add HTTP/HTTPS URL support for json schema references | | #31152 | 2025-08-18 | TerryHowe | fix: enable shuffle in Makefile for unit tests | | #12968 | 2025-08-13 | sjeandeaux | helm uninstall dry run support `--ignore-not-found` | | #31126 | 2025-08-12 | paologallinaharbur | fix(transport): leverage same tls config | | #31109 | 2025-08-06 | carlossg | fix: prevent panic when ChartDownloader.getOciURI | | #31074 | 2025-07-18 | joejulian | add missing template directory to badcrdfile testdata | | #31042 | 2025-07-10 | TerryHowe | fix: test teardown dns data race | | #30898 | 2025-07-06 | AshmitBhardwaj | Fix issue 13198 | | #31021 | 2025-07-05 | zachburg | Update tests in create_test.go and package_test.go to work in a temp directory | | #31024 | 2025-07-03 | gjenkins8 | fix: 'TestRunLinterRule' stateful test | | #30900 | 2025-06-23 | unguiculus | Add timeout flag to repo add and update commands | | #30981 | 2025-06-15 | TerryHowe | fix: lint test SetEnv errors | | #30973 | 2025-06-12 | manslaughter03 | fix: wrap run release test error in case GetPodLogs failed. | | #30972 | 2025-06-10 | TerryHowe | fix: kube client create mutex | | #30958 | 2025-06-06 | TerryHowe | fix: repo update cmd mutex | | #30955 | 2025-06-04 | carloslima | Fix tests deleting XDG_DATA_HOME | | #30939 | 2025-06-03 | TerryHowe | fix: action hooks delete policy mutex | | #12581 | 2025-06-03 | MichaelMorrisEst | Consider full GroupVersionKind when matching resources | | #30930 | 2025-05-28 | benoittgt | Fix flaky TestFindChartURL due to non-deterministic map iteration | | #30884 | 2025-05-21 | mattfarina | Reverting fix "renders int as float" | | #30862 | 2025-05-20 | OmriSteiner | fix: correctly concat absolute URIs in repo cache | | #30864 | 2025-05-16 | jessesimpson36 | fix: remove duplicate error message | | #30842 | 2025-05-15 | ayushontop | Fix : No repository is not an error,use the helm repo list command ,if there is no repository,it should not be an error #30606 | | #30800 | 2025-04-25 | mmorel-35 | fix: dep fs errors | | #30803 | 2025-04-25 | mattfarina | Fixing windows build | | #30783 | 2025-04-23 | rpolishchuk | fix: chart icon presence test | | #30777 | 2025-04-23 | ryanhockstad | fix: null merge | | #9175 | 2025-04-23 | dastrobu | fix: copy dependencies on aliasing to avoid sharing chart references on multiply aliased dependencies | | #12382 | 2025-04-20 | edbmiller | fix(pkg/lint): unmarshals Chart.yaml strictly | | #30766 | 2025-04-17 | benoittgt | Fix main branch by defining wait strategy parameter on hooks | | #30718 | 2025-04-16 | klihub | Allow signing multiple charts with a single passphrase from stdin. | | #30752 | 2025-04-16 | benoittgt | Bump golangci lint to last major version and fix static-check errors | | #30737 | 2025-04-11 | rpolishchuk | fix: order dependent test | | #9318 | 2025-04-07 | wahabmk | Fix issue with helm pull failing if pulling from a repository that redirects to another domain | | #13119 | 2025-04-05 | idsulik | fix(concurrency): Use channel for repoFailList errors in updateCharts | | #30618 | 2025-03-04 | AustinAbro321 | Fix namespace flag not registering | | #30590 | 2025-03-01 | SantalScript | fix:add proxy support when mTLS configured | | #30572 | 2025-02-25 | yardenshoham | fix: error when more than one post-renderer is specified | | #30576 | 2025-02-23 | felipecrs | Fix flaky TestDedupeRepos | | #30562 | 2025-02-20 | robertsirc | fixing error handling from a previous PR | | #13656 | 2025-02-03 | gjenkins8 | fix: Bind repotest server to `localhost` | | #13633 | 2025-01-17 | mattfarina | Ensuring the file paths are clean prior to passing to securejoin | | #13425 | 2024-11-15 | MathieuCesbron | Fix typo "re-use" to "reuse" | ## Рефакторинг/Очищення {#refactorcleanup} Покращення якості коду та модернізація | PR | Дата | Автор | Назва | |---|---|---|---| | #31440 | 2025-10-29 | mattfarina | Updating Go and golangci-lint versions | | #31408 | 2025-10-21 | AndiDog | Improve error message when plugin source cannot be determined or a non-directory is passed | | #31390 | 2025-10-21 | TerryHowe | fix: improve pkg/cmd/list test coverage | | #31365 | 2025-10-21 | reddaisyy | refactor: use reflect.TypeFor | | #31395 | 2025-10-21 | wyrapeseed | chore: fix some comment format | | #31401 | 2025-10-17 | TerryHowe | refactor: remove unused err from pkg/registry/client.go | | #31391 | 2025-10-15 | TerryHowe | chore: rename test registry | | #31302 | 2025-10-13 | TerryHowe | fix: helm verify Run signature | | #31270 | 2025-10-13 | TerryHowe | chore: registry utils clean up | | #31383 | 2025-10-13 | dirkmueller | Avoid accessing .Items on nil object | | #31379 | 2025-10-13 | TerryHowe | fix: clean up coverage script temp file | | #30980 | 2025-10-10 | gjenkins8 | cleanup: Remove/consolidate redundant kube client Interfaces | | #30712 | 2025-10-10 | gjenkins8 | cleanup: Remove extra lint/rules.Template functions | | #30833 | 2025-10-09 | gjenkins8 | refactor/cleanup: Replace action 'DryRun' string with DryRunStrategy type + deprecations | | #31326 | 2025-10-07 | TerryHowe | Update sign tests to use testify | | #31312 | 2025-10-01 | gjenkins8 | Remove unused 'Settings' from plugin schema | | #31143 | 2025-09-25 | TerryHowe | fix: remove redundant error check | | #31249 | 2025-09-25 | banjoh | chore: add additional logging to plugin installer | | #31321 | 2025-09-24 | juejinyuxitu | chore: fix some typos in comment | | #31297 | 2025-09-22 | TerryHowe | fix: hide notes in helm test command | | #31315 | 2025-09-22 | benoittgt | Remove unused golangci-lint rules that produce warning | | #31294 | 2025-09-19 | TerryHowe | Remove implicit support for helm lint current directory | | #31301 | 2025-09-19 | TerryHowe | chore: remove helm version `--client` option | | #31303 | 2025-09-18 | mattfarina | Update the action interfaces for chart apiversions | | #31198 | 2025-09-16 | TerryHowe | refactor: replace pkg/engine regular expressions with parser | | #31293 | 2025-09-16 | TerryHowe | chore: remove pkg/time which is no longer needed | | #31287 | 2025-09-16 | miledxz | improve fileutil test coverage | | #31292 | 2025-09-16 | reddaisyy | refactor: use strings.builder | | #31286 | 2025-09-12 | yajianggroup | refactor: use strings.CutPrefix | | #31258 | 2025-09-08 | StephanieHhnbrg | Refactor unreachableKubeClient for testing into failingKubeClient | | #31259 | 2025-09-07 | StephanieHhnbrg | Adapt test-coverage command to be able to run for a certain package | | #31225 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move lint pkg to be part of each chart version | | #31220 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: refactor: utilize `pluginTypesIndex` for config unmarshalling | | #31219 | 2025-09-02 | gjenkins8 | BREAKING CHANGE: Remove 'SetupPluginEnv' | | #31216 | 2025-09-02 | mattfarina | BREAKING CHANGE: Move to versioned packages | | #31224 | 2025-09-01 | gjenkins8 | fix: Adjust PostRenderer plugin output to value | | #31218 | 2025-09-01 | gjenkins8 | BREAKING CHANGE: Remove legacy Command/Hooks from v1 Subprocess (#23) | | #31151 | 2025-08-30 | TerryHowe | fix: make file whitespace | | #31178 | 2025-08-28 | mattfarina | Add content cache to helm env | | #31165 | 2025-08-22 | mattfarina | BREAKING CHANGE: Initial addition of content based cache | | #13629 | 2025-08-22 | gjenkins8 | BREAKING CHANGE: Rename 'atomic' -> 'rollback-on-failure' | | #31175 | 2025-08-21 | cuiweixie | pkg/register: refactor to use atomic.Uint64 | | #31132 | 2025-08-19 | joemicky | refactor: replace []byte(fmt.Sprintf) with fmt.Appendf | | #31133 | 2025-08-14 | joemicky | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #31134 | 2025-08-14 | joemicky | refactor: omit unnecessary reassignment | | #11700 | 2025-08-13 | suzaku | Refactor, use sort.Slice to reduce boilerplate code | | #31058 | 2025-08-07 | farazkhawaja | Add test coverage for get_values/metadata.go | | #31107 | 2025-08-06 | Pavanipogula | test(pkg/kube): Add unit tests to wait and roundtripper files. | | #31106 | 2025-08-05 | irikeish | test(pkg/kube): add test for Client.isReachable | | #30982 | 2025-08-05 | gjenkins8 | BREAKING CHANGE: Rename 'force' to 'force-replace' | | #31094 | 2025-08-04 | mikelolasagasti | chore(deps): remove phayes/freeport module | | #31101 | 2025-07-30 | banjoh | feat: switch yaml library to go.yaml.in/yaml/v3 | | #31081 | 2025-07-25 | mattfarina | BREAKING CHANGE: Initial addition of v3 charts | | #31079 | 2025-07-22 | gjenkins8 | cleanup: Remove plugin deprecated 'UseTunnelDeprecated' | | #31060 | 2025-07-18 | yumeiyin | refactor: replace Split in loops with more efficient SplitSeq | | #31065 | 2025-07-15 | TerryHowe | chore: improve OCI debug logging | | #31033 | 2025-07-14 | navinag1989 | test: increase test coverage for pkg/cli/options.go file | | #31029 | 2025-07-07 | gjenkins8 | chore(refactor): Privatize 'k8sYamlStruct' | | #31023 | 2025-07-03 | gjenkins8 | BREAKING CHANGE: Remove deprecated '--create-pods' flag | | #31009 | 2025-07-02 | tpresa | test: increase test coverage for pkg/pusher | | #31018 | 2025-07-01 | mattfarina | Move logging setup to be configurable | | #30909 | 2025-06-03 | jinjiadu | refactor: replace HasPrefix+TrimPrefix with CutPrefix | | #30809 | 2025-06-03 | mmorel-35 | chore: enable usetesting linter | | #30865 | 2025-05-22 | mmorel-35 | refactor: update json-patch import path and add gomodguard settings | | #30871 | 2025-05-20 | gjenkins8 | Run test OCI registry localhost | | #30866 | 2025-05-20 | mmorel-35 | chore: enable thelper linter | | #30863 | 2025-05-16 | mattfarina | Adding test for list command | | #30850 | 2025-05-12 | yetyear | refactor: use maps.Copy for cleaner map handling | | #30829 | 2025-05-09 | TerryHowe | Increase pkg/time test coverage | | #30810 | 2025-05-08 | mmorel-35 | chore: enable usestdlibvars linter | | #30844 | 2025-05-08 | TerryHowe | fix: rename slave replica | | #30827 | 2025-05-06 | findnature | refactor: use slices.Contains to simplify code | | #13460 | 2025-04-23 | justenstall | fix: replace "github.com/pkg/errors" with stdlib "errors" package | | #30788 | 2025-04-23 | stephenpmurray | ref(helm): Export Chart Not Found error | | #30781 | 2025-04-22 | mmorel-35 | chore: remove `github.com/hashicorp/go-multierror` dependency | | #13578 | 2025-04-18 | gjenkins8 | refactor: Remove ChartRepository `[]ChartPaths` | | #30760 | 2025-04-16 | robertsirc | adding slog debug to a few points | | #30713 | 2025-04-11 | gjenkins8 | cleanup: Remove Helm v2 template lint rules | | #30749 | 2025-04-11 | mattfarina | BREAKING CHANGE: Removing the alpine test chart | | #30686 | 2025-04-11 | mattfarina | BREAKING CHANGE: Remove deprecated code | | #30736 | 2025-04-09 | robertsirc | manually updating go.mod file | | #13458 | 2025-04-05 | thudi | BREAKING CHANGE: #13449 Resolves: Replacing NewSimpleClientSet to NewClientSet due to deprecation | | #30684 | 2025-03-21 | twz123 | Remove ClientOptResolver from OCI Client | | #30603 | 2025-03-21 | robertsirc | converting inline log to slog | | #30699 | 2025-03-21 | mattfarina | Error when failed repo update. | | #30592 | 2025-02-28 | robertsirc | changing from log to slog | | #30589 | 2025-02-26 | mattfarina | BREAKING CHANGE: Move pkg/release to pkg/release/v1 to support v3 charts | | #30586 | 2025-02-25 | mattfarina | BREAKING CHANGE: Move pkg/chart to pkg/chart/v2 to prepare for v3 charts | | #30585 | 2025-02-25 | robertsirc | removing old apis | | #30580 | 2025-02-24 | mattfarina | BREAKING CHANGE: Move pkg/releaseutil to pkg/release/util | | #11112 | 2025-02-22 | felipecrs | perf(dep-up): do not update the same repo multiple times | | #30567 | 2025-02-21 | mattfarina | BREAKING CHANGE: Moving chartutil to chart/util | | #30566 | 2025-02-21 | robertsirc | remove unused config.go | | #30470 | 2025-02-19 | gjenkins8 | Cleanup `repotest.Server` constructors | | #30550 | 2025-02-19 | mattfarina | Moving to SetOut and SetErr for Cobra | | #30546 | 2025-02-19 | hugehope | refactor: using slices.Contains to simplify the code | | #13535 | 2025-02-05 | gjenkins8 | refactor: tlsutil use options pattern | | #13665 | 2025-02-05 | gjenkins8 | chore: Remove unused `WaitAndGetCompletedPodPhase` | | #13579 | 2025-02-05 | gjenkins8 | refactor: Remove duplicate `FindChartIn*RepoURL` functions | | #13516 | 2025-01-24 | TerryHowe | chore: fix problems with latest lint | | #13494 | 2025-01-18 | gjenkins8 | BREAKING CHANGE: Remove deprecated `repo add --no-update` flag | | #13602 | 2025-01-17 | crystalstall | refactor: using slices.Contains to simplify the code | | #13600 | 2025-01-14 | gjenkins8 | cleanup: `NewShowWithConfig` -> `NewShow` | | #13601 | 2025-01-09 | gjenkins8 | cleanup: Remove superseded 'lint/rules.Values' function | | #13611 | 2025-01-07 | mattfarina | BREAKING CHANGE: Updating the internal version to v4 | | #13576 | 2025-01-07 | gjenkins8 | refactor: Consolidate lint package Run() functions | | #13577 | 2025-01-07 | gjenkins8 | refactor: Remove redundant `NewPullWithOpts` | | #13599 | 2025-01-07 | gjenkins8 | cleanup: `ProcessDependenciesWithMerge` -> `ProcessDependencies` | | #13573 | 2024-12-27 | mattfarina | BREAKING CHANGE: Updating to helm.sh/helm/v4 | | #13444 | 2024-12-07 | justenstall | refactor(status): remove --show-desc and --show-resources flags | ## Інше {#other} Покращення інфраструктури та управління проєктом | PR | Дата | Автор | Назва | |---|---|---|---| | #31197 | 2025-09-03 | tzchenxixi | chore: fix function name | | #31150 | 2025-08-18 | TerryHowe | Feature add stale pr workflow | | #31149 | 2025-08-18 | TerryHowe | fix: stale issue workflow | | #31077 | 2025-07-21 | gaspergrom | fix: LFX health score badge link | | #31047 | 2025-07-10 | jingchanglu | chore: fix typo in pkg/repo/chartrepo.go | | #31004 | 2025-06-26 | andreped | fix(docs): Typofix in README | | #31002 | 2025-06-26 | curlwget | chore: fix function in comment | | #30912 | 2025-06-17 | Bhargavkonidena | Fix #30893 - issue templates | | #30957 | 2025-06-04 | acceptacross | chore: fix some function names in comment | | #30914 | 2025-05-27 | benoittgt | Fix dependabot upgrade of jsonschema to v6.0.2 | | #30904 | 2025-05-23 | benoittgt | [Doc] Help users avoid specifying URL scheme and path with `helm registry` | | #30882 | 2025-05-20 | caniszczyk | Add new LFX Insights Health Score Badge | | #30872 | 2025-05-20 | benoittgt | Bump golangci-lint version to match last golangci-lint-action | | #30824 | 2025-05-05 | adharsh277 | Fix bug in .golangci.yml configuration | | #30786 | 2025-04-25 | mmorel-35 | refactor: reorganize .golangci.yml for better clarity and structure | | #30785 | 2025-04-23 | mmorel-35 | fix: govulncheck workflow | | #30784 | 2025-04-22 | scottrigby | chore(OWNERS): Add TerryHowe as Triage Maintainer | | #30773 | 2025-04-18 | wangcundashang | chore: fix function name in comment | | #30754 | 2025-04-16 | mattfarina | Simplify the JSON Schema checking | | #30693 | 2025-03-20 | linghuying | chore: make function comment match function name | | #30665 | 2025-03-13 | mattfarina | Updating to 0.37.0 for x/net | | #30611 | 2025-03-04 | gjenkins8 | chore: Remove 'coveralls' | | #30612 | 2025-03-04 | gjenkins8 | fix: Fix go report card badge reference/link | | #30508 | 2025-02-19 | eimhin-rover | Update version option description with more accurate info | | #30497 | 2025-02-12 | robertsirc | adding-my-key | | #30295 | 2025-02-07 | edithturn | Add Percona to the list of organizations using Helm | | #13653 | 2025-01-23 | petercover | chore: fix some comments | | #13625 | 2025-01-13 | shahbazaamir | ading info to install helm , referring the documentation | | #13563 | 2024-12-21 | gjenkins8 | Run `build-test` action on `dev-v3` branch | | #13552 | 2024-12-20 | gjenkins8 | Fix `dependabot.yml` `target-branch` typo | | #13529 | 2024-12-15 | godhanipayal | Adding Oracle to the adopters list | | #13509 | 2024-12-06 | gjenkins8 | Dependabot update `dev-v3` branch go modules | | #13212 | 2024-12-01 | mbianchidev | Update ADOPTERS.md | | #13465 | 2024-11-20 | banjoh | Add precommit config to .gitignore | | #13443 | 2024-11-15 | mattfarina | Updating docs around v3 and v4 | ## Зміни v4 також перенесені до v3 {#v4-changes-also-backported-to-v3} Ці PR були включені до v4, але також перенесені до випусків v3. ### Нові функції {#new-features-backported} | PR | Дата | Автор | Назва | |---|---|---|---| | #30696 | 2025-03-24 | benoittgt | Inform about time spent waiting resources to be ready in slog format | | #12912 | 2025-03-11 | hegerdes | feat: add httproute from gateway-api to create chart template | | #10309 | 2025-02-21 | Bez625 | Add hook annotation to output hook logs to client on error | | #13481 | 2025-02-18 | banjoh | feat: Enable CPU and memory profiling | | #12690 | 2025-01-01 | TerryHowe | feat: OCI install by digest | | #13232 | 2024-12-20 | dnskr | ref(create): don't render empty resource fields | | #12962 | 2024-12-04 | stevehipwell | feat: Added multi-platform plugin hook support | | #13343 | 2024-11-19 | niladrih | Add annotations and dependencies to get metadata output | ### Виправлення помилок {#bug-fixes-backported} | PR | Дата | Автор | Назва | |---|---|---|---| | #31064 | 2025-09-05 | kamilswiec | lint: throw warning when chart version is not semverv2 | | #31156 | 2025-08-22 | estroz | fix: set repo authorizer in registry.Client.Resolve() | | #30992 | 2025-08-18 | TerryHowe | fix: force bearer oauth for if registry requests bearer auth | | #31115 | 2025-08-18 | banjoh | fix: use username and password if provided | | #30891 | 2025-08-13 | gjenkins8 | fix: Port pluginCommand & command warning | | #31050 | 2025-08-08 | heyLu | Fix `helm pull` untar dir check with repo urls | | #31078 | 2025-07-24 | 8tomat8 | fix: k8s version parsing to match original | | #30979 | 2025-06-17 | TerryHowe | fix: OAuth username password login for v4 | | #30917 | 2025-06-01 | TerryHowe | fix: add debug logging to oci transport | | #30937 | 2025-05-30 | TerryHowe | fix: legacy docker support broken for login | | #30928 | 2025-05-28 | TerryHowe | fix: plugin installer test with no Internet | | #30905 | 2025-05-23 | robertsirc | forward porting 30902 | | #30894 | 2025-05-23 | benoittgt | Prevent push cmd failure in 3.18 by handling version tag resolution in ORAS memory store | | #30697 | 2025-04-17 | p-se | Fix --take-ownership for custom resources - closes #30622 | | #30673 | 2025-04-16 | nvanthao | fix: Process all hook deletions on failure | | #30701 | 2025-04-11 | zanuka | updates mutate and validate web hook configs | | #13583 | 2025-01-15 | jiashengz | fix: check group for resource info match | ### Рефакторинг/очищення {#refactorcleanup-backported} | PR | Дата | Автор | Назва | |---|---|---|---| | #30677 | 2025-04-18 | dongjiang1989 | chore: Update Golang to v1.24 | | #30741 | 2025-04-11 | benoittgt | Bumps github.com/distribution/distribution/v3 from 3.0.0-rc.3 to 3.0.0 | | #13382 | 2025-02-03 | TerryHowe | chore(oci): migrate to ORAS Golang library v2 | | #13546 | 2024-12-19 | mattfarina | Update to Go 1.23 | | #13499 | 2024-12-06 | gjenkins8 | Shadow ORAS remote.Client interface | ### Інше {#other-backported} | PR | Дата | Автор | Назва | |---|---|---|---| | #30775 | 2025-04-19 | benoittgt | Bump toml | | #13533 | 2025-01-24 | althmoha | fix: (toToml) renders int as float | | #13581 | 2024-12-31 | ldlb9527 | Upgrade golang.org/x/net to v0.33.0 to address CVE-2024-45338 | ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/conventions.md ================================================ --- title: Загальні домовленості description: Загальні домовленості для чартів. sidebar_position: 1 --- Ця частина Посібника з найкращих практик пояснює загальні домовленості. ## Назви чартів {#chart-names} Назви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-): Приклади: ```none drupal nginx-lego aws-cluster-autoscaler ``` У назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки. ## Номери версій {#version-numbers} По можливості, Helm використовує [SemVer 2](https://semver.org/lang/uk/) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.) Коли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення. ## Форматування YAML {#formatting-yaml} Файли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією). ## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart} Існує кілька домовленостей щодо використання слів _Helm_ і _helm_. - _Helm_ відноситься до проєкту в цілому - `helm` відноситься до клієнтської команди - Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва - Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру У разі сумніву використовуйте _Helm_ (з великої літери "H"). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Як створювати та використовувати CRDs (Custom Resource Definitions). sidebar_position: 7 --- Цей розділ Посібника з найкращих практик присвячений створенню та використанню обʼєктів Custom Resource Definition. При роботі з Custom Resource Definitions (CRDs) важливо розрізняти два різні аспекти: - Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`. - Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD. ## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource} Helm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається процедурою узгодження). Але є різниця з CRDs. Для CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд. ### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you} З приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRDs. Ці CRDs не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`. #### Декілька застережень (і пояснень) {#some-caveats-and-explanations} Зараз не підтримується оновлення або видалення CRDs за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRDs та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків. Прапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRDs. Мета "Dry Run" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRDs є модифікацією поведінки сервера. Helm не може встановити CRD під час тестового запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRDs до окремого чарту або використовувати `helm template` замість цього. Ще один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з явних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRDs. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера. ### Метод 2: Окремі чарти {#method-2-separate-charts} Ще один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті. В цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/dependencies.mdx ================================================ --- title: Залежності description: Охоплює найкращі практики щодо залежностей чартів. sidebar_position: 4 --- import Helm4 from "../_v4-in-progress.mdx" Цей розділ посібника охоплює найкращі практики для `dependencies`, оголошених у `Chart.yaml`. ## Версії {#versions} По можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу: ```yaml version: ~1.2.3 ``` Це буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`. Для повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Передрелізні версії {#prereleases-versions} Вищезазначені обмеження версій не будуть відповідати передрелізним версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Нижче наведено приклад передрелізного та патч-рівня відповідності: ```yaml version: ~1.2.3-0 ``` ### URL-адреси репозиторіїв {#repository-urls} По можливості використовуйте URL-адреси репозиторію `https://`, а потім URL-адреси `http://`. Якщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв. URL-адреси файлів (`file://...`) вважаються "особливим випадком" для чартів, які збираються фіксованим процесом розгортання. При використанні [втулків завантажувача](/topics/plugins.mdx#downloader-plugins) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності. Helm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності. ## Умови та теґи {#conditions-and-tags} Умови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_. Бажана форма умови є такою: ```yaml condition: somechart.enabled ``` Де `somechart` є іменем чарту залежності. Коли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи. Наприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей: ```yaml tags: - webaccelerator ``` Це дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/index.mdx ================================================ --- title: Найкращі практики sidebar: true sidebar_position: 4 --- # Поради щодо використання чартів Цей посібник охоплює найкращі практики створення чартів, які команда Helm вважає оптимальними. Основна увага приділяється структурі чартів. Ми зосереджуємося переважно на найкращих практиках для чартів, які можуть бути публічно розгорнуті. Ми розуміємо, що багато чартів призначені лише для внутрішнього використання, і автори таких чартів можуть вважати, що їхні внутрішні інтереси мають пріоритет над нашими пропозиціями, викладеними тут. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/labels.md ================================================ --- title: Мітки та Анотації description: Охоплює найкращі практики використання міток та анотацій у вашому чарті. sidebar_position: 5 --- У цій частині Посібника розглядаються найкращі практики використання міток та анотацій у ваших чартах. ## Це мітка чи анотація? {#is-it-a-label-or-an-annotation} Елемент метаданих слід вважати міткою за таких умов: - Він використовується Kubernetes для ідентифікації цього ресурсу - Він корисний для експонування операторам з метою запиту системи. Наприклад, рекомендується використовувати `helm.sh/chart: NAME-VERSION` як мітку, щоб оператори могли зручно знаходити всі екземпляри конкретного чарту. Якщо елемент метаданих не використовується для запитів, його слід встановити як анотацію. Helm hooks завжди є анотаціями. ## Стандартні Мітки {#standard-labels} Наступна таблиця визначає загальні мітки, які використовуються в Helm чарті. Helm сам по собі ніколи не вимагає наявності конкретної мітки. Мітки, які позначені як REC, є рекомендованими та _повинні_ бути розміщені в чарті для глобальної узгодженості. Ті, що позначені як OPT, є необовʼязковими. Це ідіоматичні або часто використовувані мітки, але не є критично важливими для операційних цілей. Назва|Статус|Опис -----|------|---------- `app.kubernetes.io/name` | REC | Це повинно бути імʼя застосунку, яке відображає весь застосунок. Зазвичай використовується `{{ template "name" . }}`. Це використовується багатьма маніфестами Kubernetes і не є специфічним для Helm. `helm.sh/chart` | REC | Це повинно бути імʼя чарту та версія: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | Це завжди повинно бути встановлено як `{{ .Release.Service }}`. Це для знаходження всього, що управляється Helm. `app.kubernetes.io/instance` | REC | Це повинно бути `{{ .Release.Name }}`. Це допомагає відрізняти різні екземпляри одного й того ж застосунку. `app.kubernetes.io/version` | OPT | Версія застосунку і може бути встановлена як `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | Це загальна мітка для позначення різних ролей, які елементи можуть відігравати в застосунку. Наприклад, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | Коли кілька чартів або програмних частин використовуються разом для створення одного застосунку. Наприклад, програмне забезпечення та база даних для створення вебсайту. Це можна встановити на рівні основного застосунку, що підтримується. Ви можете знайти більше інформації про мітки Kubernetes, що починаються з `app.kubernetes.io`, в [документації Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/pods.md ================================================ --- title: Pods та PodTemplates description: Розглядається форматування частин Pod і PodTemplate в маніфестах чартів. sidebar_position: 6 --- У цій частині посібника з найкращих практик розглядається форматування частин Pod і PodTemplate у маніфестах чартів. Наступний (неповний) список ресурсів використовує PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Образи {#images} Образ контейнера повинен використовувати фіксований теґ або SHA образу. Він не повинен використовувати теги `latest`, `head`, `canary` або інші теґи, які призначені для "плаваючих" версій. Образи _можуть_ бути визначені у файлі `values.yaml`, щоб спростити заміну образів. ```yaml image: {{ .Values.redisImage | quote }} ``` Образ та теґ можуть бути визначені у файлі `values.yaml` як два окремі поля: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` стандартно встановлює `imagePullPolicy` на `IfNotPresent`, роблячи це у вашому `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` А у `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Аналогічно, Kubernetes стандартно встановлює `imagePullPolicy` на `IfNotPresent`, якщо він зовсім не визначений. Якщо вам потрібне інше значення, просто оновіть його в `values.yaml` на потрібне значення. ## PodTemplates повинні оголошувати селектори {#podtemplates-should-declare-selectors} Усі розділи PodTemplate повинні містити селектор. Наприклад: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Це хороша практика, оскільки вона встановлює звʼязок між набором і podʼом. Але це ще важливіше для таких наборів, як Deployment. Без цього, _весь_ набір міток використовується для вибору відповідних podʼів, і це може зламатися, якщо ви використовуєте мітки, які змінюються, такі як версія або дата релізу. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/rbac.md ================================================ --- title: Role-Based Access Control description: Розглядається створення та форматування ресурсів RBAC у маніфестах чартів. sidebar_position: 8 --- У цій частині Посібника з найкращих практик розглядається створення та форматування ресурсів RBAC у маніфестах чартів. Ресурси RBAC це: - ServiceAccount (обмежений простором імен) - Role (обмежений простором імен) - ClusterRole - RoleBinding (обмежений простором імен) - ClusterRoleBinding ## Конфігурація YAML {#yaml-configuration} Конфігурація RBAC та ServiceAccount повинна здійснюватися під окремими ключами. Це окремі речі. Розділення цих двох концепцій у YAML знімає неоднозначність і робить це яснішим. ```yaml rbac: # Вказує, чи повинні бути створені ресурси RBAC create: true serviceAccount: # Вказує, чи повинен бути створений ServiceAccount create: true # Імʼя ServiceAccount для використання. # Якщо не вказано і create дорівнює true, імʼя генерується за допомогою шаблону fullname name: ``` Цю структуру можна розширити для комплексних чартів, які потребують кількох ServiceAccount. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Ресурси RBAC повинні бути стандартно створені {#rbac-resources-should-be-created-by-default} `rbac.create` має бути булевим значенням, яке контролює, чи створюються ресурси RBAC. Стандартне значення має бути `true`. Користувачі, які бажають самостійно управляти контролем доступу RBAC, можуть встановити це значення в `false` (у цьому випадку дивіться нижче). ## Using RBAC Resources `serviceAccount.name` має бути встановлено на імʼя ServiceAccount, яке буде використовуватися доступними ресурсами, створеними чартом. Якщо `serviceAccount.create` дорівнює true, то ServiceAccount з цим імʼям має бути створено. Якщо імʼя не вказано, то імʼя генерується за допомогою шаблону `fullname`. Якщо `serviceAccount.create` дорівнює false, то ServiceAccount не створюється, але він має бути асоційований з тими ж ресурсами, щоб пізніше створені вручну ресурси RBAC, що посилаються на нього, функціонували правильно. Якщо `serviceAccount.create` дорівнює false та імʼя не вказано, то використовується стандартний ServiceAccount. Для ServiceAccount слід використовувати наступний допоміжний шаблон. ```go {{/* Створення імені службового облікового запису, який буде використовуватися */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/templates.md ================================================ --- title: Шаблони description: Детальний огляд найкращих практик щодо шаблонів. sidebar_position: 3 --- Ця частина Посібника з найкращих практик присвячена шаблонам. ## Структура `templates/` {#structure-of-templates} Теку `templates/` слід структурувати наступним чином: - Файли шаблонів повинні мати розширення `.yaml`, якщо вони генерують YAML-вихід. Розширення `.tpl` можна використовувати для файлів шаблонів, які не генерують форматований контент. - Імена файлів шаблонів повинні використовувати дефіси (`my-example-configmap.yaml`), а не camelCase. - Кожне визначення ресурсу повинно бути у власному файлі шаблону. - Імена файлів шаблонів повинні відображати тип ресурсу в імені. Наприклад, `foo-pod.yaml`, `bar-svc.yaml`. ## Імена визначених шаблонів {#names-of-defined-templates} Визначені шаблони (шаблони, створені всередині директиви `{{ define }}`) є глобально доступними. Це означає, що чарт і всі його субчарти матимуть доступ до всіх шаблонів, створених з `{{ define }}`. З цієї причини _усі імена визначених шаблонів повинні обмежені простором імен_. Правильно: ```go {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Неправильно: ```go {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Рекомендується, щоб нові чарти створювалися за допомогою команди `helm create`, оскільки імена шаблонів автоматично визначаються відповідно до цієї найкращої практики. ## Форматування шаблонів {#formatting-templates} Шаблони повинні мати відступи у _два пробіли_ (ніколи табуляцію). Директиви шаблону повинні мати пробіл після відкриваючих дужок і перед закриваючими дужками: Правильно: ```go {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Неправильно: ```go {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Шаблони повинні обрізати пробіли, де це можливо: ```go foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Блоки (такі як структури управління) можуть бути з відступами, щоб позначити потік коду шаблону. ```go {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Однак, оскільки YAML є мовою, орієнтованою на пробіли, часто неможливо, щоб відступи коду слідували цій конвенції. ## Пробіли у згенерованих шаблонах {#whitespace-in-generated-templates} Бажано мінімізувати кількість пробілів у згенерованих шаблонах. Особливо слід уникати численних порожніх рядків, які йдуть один за одним. Але випадкові порожні рядки (особливо між логічними секціями) допустимі. Це краще: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Це прийнятно: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Але цього слід уникати: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Коментарі (Коментарі YAML vs. Коментарі шаблонів){#comments-yaml-comments-vs-template-comments} Як YAML, так і шаблони Helm мають маркери коментарів. Коментарі YAML: ```yaml # Це коментар type: sprocket ``` Коментарі шаблонів: ```go {{- /* Це коментар. */}} type: frobnitz ``` Коментарі шаблонів слід використовувати для документування функцій шаблону, наприклад, пояснюючи визначений шаблон: ```go {{- /* mychart.shortname надає скорочену версію імені релізу до 6 символів. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Всередині шаблонів коментарі YAML можуть використовуватися, коли це корисно для користувачів Helm (можливо) бачити коментарі під час налагодження. ```yaml # Це може спричинити проблеми, якщо значення більше ніж 100Gi memory: {{ .Values.maxMem | quote }} ``` Вищенаведений коментар видимий, коли користувач виконує `helm install --debug`, тоді як коментарі, вказані в секціях `{{- /* */}}`, не видно. Остерігайтеся додавання `#` коментарів YAML у секції шаблону, що містять значення Helm, які можуть бути потрібні для деяких функцій шаблону. Наприклад, якщо функція `required` вводиться у наведеному вище прикладі, і `maxMem` не встановлено, коментар `#` YAML спричинить помилку рендерингу. Правильно: `helm template` не рендерить цей блок ```go {{- /* # Це може спричинити проблеми, якщо значення більше ніж 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Неправильно: `helm template` повертає `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # Це може спричинити проблеми, якщо значення більше ніж 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Гляньте [Налагодження шаблонів](/chart_template_guide/debugging.md) для іншого прикладу цієї поведінки того, як коментарі YAML залишаються недоторканими. ## Використання JSON у шаблонах і виході шаблонів {#use-of-json-in-templates-and-template-output} YAML є надмножиною JSON. У деяких випадках використання синтаксису JSON може бути більш читабельним, ніж інші представлення YAML. Наприклад, цей YAML ближчий до звичайного методу представлення списків у YAML: ```yaml arguments: - "--dirname" - "/foo" ``` Але його легше читати, коли його стисло представлено у стилі списку JSON: ```yaml arguments: ["--dirname", "/foo"] ``` Використання JSON для підвищення читабельності є корисним. Однак синтаксис JSON не слід використовувати для представлення cкладніших конструкцій. При роботі з чистим JSON, вбудованим всередині YAML (наприклад, конфігурація контейнера ініціалізації), звичайно, доречно використовувати формат JSON. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_best_practices/values.md ================================================ --- title: Значення description: Орієнтовано на те, як ви повинні структурувати та використовувати значення. sidebar_position: 2 --- Ця частина посібника з найкращих практик охоплює використання значень. Ми надаємо рекомендації щодо структурування та використання значень, зосереджуючись на дизайні файлу `values.yaml` чарту. ## Домовленості щодо назв {#naming-conventions} Назви змінних повинні починатися з малої літери, а слова мають поєднуватись верблюжим регістром (camelCase): Правильно: ```yaml chicken: true chickenNoodleSoup: true ``` Неправильно: ```yaml Chicken: true # початкова велика літера може конфліктувати з вбудованими змінними chicken-noodle-soup: true # не використовуйте дефіси в назвах ``` Зверніть увагу, що всі вбудовані змінні Helm починаються з великої літери, щоб їх легко було відрізнити від користувацьких значень: `.Release.Name`, `.Capabilities.KubeVersion`. ## Пласкі або вкладені значення {#flat-or-nested-values} YAML — це гнучкий формат, і значення можуть бути вкладеними або пласкими. Вкладені: ```yaml server: name: nginx port: 80 ``` Пласкі: ```yaml serverName: nginx serverPort: 80 ``` У більшості випадків слід віддавати перевагу пласким структурам над вкладеними. Це зумовлено тим, що їх простіше використовувати розробникам шаблонів та користувачам. Для забезпечення максимальної безпеки вкладене значення має перевірятися на кожному рівні: ```go {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Для кожного шару вкладення необхідно виконувати перевірку на наявність. Однак для пласкої конфігурації такі перевірки можна пропустити, що спрощує читання та використання шаблону. ```go {{ default "none" .Values.serverName }} ``` Коли існує велика кількість пов’язаних змінних і хоча б одна з них є обов’язковою, вкладені значення можуть використовуватися для підвищення зручності читання. ## Чітке визначення типів {#make-types-clear} Правила перетворення типів YAML іноді можуть бути неінтуїтивними. Наприклад, `foo: false` не те саме, що і `foo: "false"`. Великі цілі числа, такі як `foo: 12345678`, у деяких випадках будуть перетворюватися на наукову нотацію. Найпростіший спосіб уникнути помилок перетворення типів — бути явним щодо рядків і неявним щодо всього іншого. Або, коротко кажучи, _беріть всі рядки в лапки_. Часто для уникнення проблем із перетворенням чисел наукової нотації вигідно зберігати ваші цілі числа у вигляді рядків і використовувати `{{ int $value }}` у шаблоні для перетворення з рядкового значення назад на ціле число. У більшості випадків явні типи поважаються, тому `foo: !!string 1234` має обробляти `1234` як рядок. _Проте_ парсер YAML споживає теґи, тому дані про типи втрачаються після одного аналізу. ## Враховуйте, як користувачі будуть використовувати ваші значення {#consider-how-users-will-use-your-values} Існує три потенційні джерела значень: - Файл `values.yaml` чарту - Файл значень, переданий за допомогою `helm install -f` або `helm upgrade -f` - Значення, передані з прапорцем `--set` або `--set-string` під час `helm install` або `helm upgrade` При проєктуванні структури ваших значень майте на увазі, що користувачі вашого чарту можуть захотіти перевизначити їх за допомогою прапорця `-f` або опції `--set`. Оскільки `--set` більш обмежений у виразності, перше правило написання файлу `values.yaml` — _зробіть його зручним для перевизначення за допомогою `--set`_. З цієї причини часто краще структурувати файл значень, використовуючи map. Важко використовувати з `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Вищезазначене не можна виразити за допомогою `--set` у Helm `<=2.4`. У Helm 2.5 доступ до порту на foo здійснюється за допомогою `--set servers[0].port=80`. Це не тільки ускладнює розуміння для користувача, але й може призвести до помилок, якщо пізніше порядок `servers` буде змінено. Легше використовувати: ```yaml servers: foo: port: 80 bar: port: 81 ``` Отримання доступу до порту foo стає набагато очевиднішим: `--set servers.foo.port=80`. ## Документуйте `values.yaml` {#document-valuesyaml} Кожна визначена властивість у `values.yaml` повинна бути задокументована. Рядок документації повинен починатися з назви властивості, яку він описує, а потім надавати принаймні одне речення опису. Неправильно: ```yaml # назва хосту для вебсервера serverHost: example serverPort: 9191 ``` Правильно: ```yaml # serverHost - це назва хосту для вебсервера serverHost: example # serverPort - це порт HTTP-сервера для вебсервера serverPort: 9191 ``` Початок кожного коментаря з назви параметра, який він документує, дозволяє легко знаходити документацію та дозволяє інструментам документації надійно співвідносити рядки документації з параметрами, які вони описують. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/accessing_files.md ================================================ --- title: Доступ до файлів всередині шаблонів description: Як отримати доступ до файлів зсередини шаблону. sidebar_position: 10 --- У попередньому розділі ми розглянули кілька способів створення та доступу до іменованих шаблонів. Це полегшує імпорт одного шаблону в інший шаблон. Але іноді корисно імплементувати _файл, який не є шаблоном_ і вбудувати його вміст без використання рендерера шаблонів. Helm надає доступ до файлів через обʼєкт `.Files`. Перш ніж переходити до прикладів шаблонів, є кілька моментів, які слід врахувати: - Можна додавати додаткові файли до вашого Helm чарту. Ці файли будуть упаковані. Але будьте обережні. Чарти мають бути меншими за 1М через обмеження зберігання обʼєктів Kubernetes. - Деякі файли не можна отримати через обʼєкт `.Files`, зазвичай з міркувань безпеки. - Файли в `templates/` не можна отримати. - Файли, виключені за допомогою `.helmignore`, не можна отримати. - Файли поза межами [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, включаючи файли батьківського чарту, не можна отримати. - Чарти не зберігають інформацію про режим UNIX, тому дозволи на рівні файлу не вплинуть на доступність файлу в обʼєкті `.Files`. - [Базовий приклад](#basic-example) - [Помічники оброки шляхів](#path-helpers) - [Шаблони Glob](#glob-patterns) - [Утиліти для ConfigMap і Secrets](#configmap-and-secrets-utility-functions) - [Кодування](#encoding) - [Рядки](#lines) ## Базовий приклад {#basic-example} З урахуванням цих застережень, створимо шаблон, який читає три файли в наш ConfigMap. Для початку додамо три файли до чарту, розміщуючи всі три безпосередньо в теці `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Кожен з цих файлів є простим TOML-файлом (згадайте про старі INI-файли Windows). Ми знаємо імена цих файлів, тому можемо використовувати функцію `range`, щоб перебрати їх і вставити їх вміст у наш ConfigMap. ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Цей ConfigMap використовує кілька технік, обговорених у попередніх розділах. Наприклад, ми створюємо змінну `$files`, щоб зберегти посилання на обʼєкт `.Files`. Ми також використовуємо функцію `tuple`, щоб створити список файлів, які ми перебираємо. Потім ми виводимо кожне імʼя файлу (`{{ . }}: |-`) після чого йде вміст файлу `{{ $files.Get . }}`. Запуск цього шаблону створить один ConfigMap з вмістом усіх трьох файлів: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Помічники оброки шляхів {#path-helpers} При роботі з файлами може бути дуже корисно виконувати деякі стандартні операції з самими шляхами файлів. Для цього Helm імплементує багато функцій з пакета Go [path](https://golang.org/pkg/path/). Вони всі доступні з такими ж іменами, як у пакеті Go, але з маленькою першою літерою. Наприклад, `Base` стає `base` і т.д. Імпортовані функції: - Base - Dir - Ext - IsAbs - Clean ## Шаблони glob {#glob-patterns} Коли ваш чарт зростає, ви можете знайти необхідність організувати ваші файли більше, і тому ми надаємо метод `Files.Glob(pattern string)` для допомоги у витягуванні певних файлів з усією гнучкістю [шаблонів glob](https://godoc.org/github.com/gobwas/glob). `.Glob` повертає тип `Files`, тому ви можете викликати будь-які методи `Files` на повернутому обʼєкті. Наприклад, уявіть структуру директорій: ```none foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` У вас є кілька варіантів з Globs: ```go {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` або ```go {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Утиліти для ConfigMap і Secrets {#configmap-and-secrets-utility-functions} (Доступні з Helm 2.0.2 і далі) Дуже часто потрібно помістити вміст файлів як у ConfigMaps, так і в Secrets, для монтування в ваші podʼи під час виконання. Для цього ми надаємо кілька методів утиліт для типу `Files`. Для подальшої організації особливо корисно використовувати ці методи разом з методом `Glob`. Задана структура теки з прикладу [Glob](#glob-patterns): ```go --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Кодування {#encoding} Ви можете імплементувати файл і змусити шаблон закодувати його в base-64, щоб забезпечити успішну передачу: ```go apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Вищенаведене візьме той самий файл `config1.toml`, який ми використовували раніше, і закодує його: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Рядки {#lines} Іноді потрібно отримати доступ до кожного рядка файлу у вашому шаблоні. Ми надаємо зручний метод `Lines` для цього. Ви можете перебрати `Lines`, використовуючи функцію `range`: ```go data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Немає можливості передавати файли, що знаходяться поза чартом, під час `helm install`. Тому, якщо ви просите користувачів надати дані, їх потрібно завантажити за допомогою `helm install -f` або `helm install --set`. Це опис завершує наше занурення в інструменти та техніки написання шаблонів Helm. У наступному розділі ми побачимо, як можна використовувати один спеціальний файл, `templates/NOTES.txt`, для надсилання інструкцій після установки користувачам вашого чарту. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/builtin_objects.md ================================================ --- title: Вбудовані обʼєкти description: Вбудовані обʼєкти, доступні для шаблонів. sidebar_position: 3 --- Обʼєкти передаються в шаблон з рушія обробки шаблонів. І ваш код може передавати обʼєкти далі (ми побачимо приклади, коли розглянемо оператори `with` та `range`). Є навіть кілька способів створити нові обʼєкти всередині ваших шаблонів, як, наприклад, з функцією `tuple`, яку ми розглянемо пізніше. Обʼєкти можуть бути простими та мати лише одне значення. Або вони можуть містити інші обʼєкти чи функції. Наприклад, обʼєкт `Release` містить кілька обʼєктів (наприклад, `Release.Name`), а обʼєкт `Files` має кілька функцій. У попередньому розділі ми використовували `{{ .Release.Name }}`, щоб вставити імʼя релізу в шаблон. `Release` — один з обʼєктів верхнього рівня, до якого ви можете отримати доступ у своїх шаблонах. - `Release`: Цей обʼєкт описує сам реліз. Він містить кілька обʼєктів: - `Release.Name`: Імʼя релізу - `Release.Namespace`: Простір імен, у який буде здійснено реліз (якщо маніфест не перевизначить) - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. - `Release.Revision`: Номер ревізії для цього релізу. Під час встановлення це 1, і він збільшується з кожним оновленням або відкатом. - `Release.Service`: Сервіс, який обробляє поточний шаблон. У Helm це завжди `Helm`. - `Values`: Значення, передані в шаблон з файлу `values.yaml` і з файлів, наданих користувачем. Стандартно `Values` порожній. - `Chart`: Вміст файлу `Chart.yaml`. Будь-які дані в `Chart.yaml` будуть доступні тут. Наприклад, `{{ .Chart.Name }}-{{ .Chart.Version }}` виведе `mychart-0.1.0`. - Доступні поля перелічені в [Посібнику чартів](/topics/charts.mdx#the-chartyaml-file) - `Subcharts`: Надає доступ до області дії (.Values, .Charts, .Releases тощо) субшаблонів з батьківського шаблону. Наприклад, `.Subcharts.mySubChart.myValue`, щоб отримати доступ до `myValue` у шаблоні `mySubChart`. - `Files`: Надає доступ до всіх не-спеціальних файлів у шаблоні. Ви не можете використовувати його для доступу до шаблонів, але можете використовувати його для доступу до інших файлів у шаблоні. Див. розділ [Доступ до файлів](/chart_template_guide/accessing_files.md) для отримання додаткової інформації. - `Files.Get` — це функція для отримання файлу за іменем (`.Files.Get config.ini`). - `Files.GetBytes` — це функція для отримання вмісту файлу у вигляді масиву байтів, а не рядка. Це корисно для таких речей, як образи. - `Files.Glob` — це функція, яка повертає список файлів, імена яких відповідають заданому шаблону оболонки. - `Files.Lines` — це функція, яка зчитує файл рядок за рядком. Це корисно для ітерації по кожному рядку у файлі. - `Files.AsSecrets` — це функція, яка повертає вміст файлів у вигляді Base64-кодованих рядків. - `Files.AsConfig` — це функція, яка повертає вміст файлів у вигляді YAML map. - `Capabilities`: Надає інформацію про можливості, які підтримує кластер Kubernetes. - `Capabilities.APIVersions` — це набір версій. - `Capabilities.APIVersions.Has $version` вказує на те, чи доступна версія (наприклад, `batch/v1`) або ресурс (наприклад, `apps/v1/Deployment`) у кластері. - `Capabilities.KubeVersion` і `Capabilities.KubeVersion.Version` — це версія Kubernetes. - `Capabilities.KubeVersion.Major` — це основна версія Kubernetes. - `Capabilities.KubeVersion.Minor` — це мінорна версія Kubernetes. - `Capabilities.HelmVersion` — це обʼєкт, який містить деталі версії Helm, це той самий вивід, що і `helm version`. - `Capabilities.HelmVersion.Version` — це поточна версія Helm у форматі semver. - `Capabilities.HelmVersion.GitCommit` — це Git-ідентифікатор SHA1 для Helm. - `Capabilities.HelmVersion.GitTreeState` — це стан дерева git для Helm. - `Capabilities.HelmVersion.GoVersion` — це версія компілятора Go, який використовувався. - `Template`: Містить інформацію про поточний шаблон, який виконується. - `Template.Name`: Шлях до файлу поточного шаблону з простору імен (наприклад, `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: Шлях до теки шаблонів поточного чарта з простору імен (наприклад, `mychart/templates`). Вбудовані значення завжди починаються з великої літери. Це відповідає угоді про найменування у Go. Коли ви створюєте власні імена, ви можете використовувати угоду, яка підходить вашій команді. Деякі команди, як і багато тих, чиї шаблони ви можете бачити на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), обирають використовувати лише початкові малі літери, щоб відрізнити локальні імена від вбудованих. У цьому посібнику ми дотримуємося цієї угоди. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/control_structures.md ================================================ --- title: Керування потоком description: Швидкий огляд структури керування потоком в шаблонах. sidebar_position: 7 --- Структури керування (називаються "діями" (actions) в термінології шаблонів) надають вам, автору шаблонів, можливість контролювати потік генерації шаблону. Мова шаблонів Helm надає такі структури керування: - `if`/`else` для створення умовних блоків - `with` для визначення області видимості - `range`, який надає цикл "for each" Окрім цих, є кілька дій для оголошення та використання іменованих сегментів шаблону: - `define` оголошує новий іменований шаблон всередині вашого шаблону - `template` імплементує іменований шаблон - `block` оголошує спеціальний тип заповнювальної області шаблону У цьому розділі ми розглянемо `if`, `with` та `range`. Інші дії будуть розглянуті в розділі "Іменовані шаблони" пізніше в цьому посібнику. ## If/Else Перша структура керування, яку ми розглянемо, використовується для умовного включення блоків тексту в шаблоні. Це блоки `if`/`else`. Основна структура блоку з умовою виглядає так: ```go {{ if PIPELINE }} # Щось зробити {{ else if OTHER PIPELINE }} # Зробити щось інше {{ else }} # Стандартне значення {{ end }} ``` Зверніть увагу, що зараз ми говоримо про _конвеєри_, а не про значення. Причина цього полягає в тому, щоб чітко показати, що структури управління можуть виконувати весь конвеєр, а не тільки обчислювати значення. Конвеєр вважається _false_, якщо значення є: - логічне значення false - числове значення нуль - порожній рядок - значення `nil` (порожнє або null) - порожня колекція (`map`, `slice`, `tuple`, `dict`, `array`) У всіх інших умовах умова є істинною. Додамо просту умовну конструкцію до нашого ConfigMap. Ми додамо ще одне налаштування, якщо напій встановлений на каву: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Оскільки ми закоментували `drink: coffee` у нашому останньому прикладі, вихідний файл не повинен містити прапорець `mug: "true"`. Але якщо ми додамо цей рядок назад у наш файл `values.yaml`, вихід виглядатиме так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Контроль пробілів {#controlling-whitespace} Під час роботи з умовами варто звернути увагу на те, як контролюється кількість пробілів у шаблонах. Розглянемо попередній приклад і відформатуємо його для зручнішого читання: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Спочатку це має гарний вигляд. Але якщо ми пропустимо його через рушій шаблонів, отримаємо неприємний результат: ```sh $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Що сталося? Ми створили некоректний YAML через пробіли, зазначені вище. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` має невірний відступ. Виправимо це, зменшивши відступ цього рядка, і запустимо знову: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Коли ми запустимо це, отримаємо валідний YAML, але з кількома порожніми рядками: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Помітно, що у нас є кілька пустих рядків у YAML. Чому? Коли рушій шаблонів виконує шаблон, він _видаляє_ вміст всередині `{{` і `}}`, але залишає пробіли без змін. YAML надає значення пробілам, тому управління пробілами стає важливим. На щастя, шаблони Helm мають кілька інструментів у поміч. По-перше, синтаксис фігурних дужок шаблонів можна модифікувати за допомогою спеціальних символів, щоб вказати рушію шаблонів обрізати пробіли. `{{- ` (з тире і пробілом) вказує, що пробіли зліва повинні бути видалені, тоді як ` -}}` означає, що пробіли справа повинні бути видалені. _Будьте обережні! Нові рядки — це пробіли!_ > Переконайтеся, що є пробіл між `-` і рештою вашої директиви. `{{- 3 }}` означає "вирізати ліві пробіли та вивести 3", тоді як `{{-3 }}` означає "вивести -3". Використовуючи цей синтаксис, ми можемо змінити наш шаблон, щоб позбутися від тих нових рядків: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Щоб прояснити це, відзначимо кожен пробіл, який буде видалено відповідно до цього правила. `*` в кінці рядка вказує на символ нового рядка, який буде видалений: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Зважаючи на це, ми можемо запустити наш шаблон через Helm і побачити результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Будьте обережні з модифікаторами обрізання пробілів. Легко випадково зробити ось так: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Це створить `food: "PIZZA"mug: "true"`, оскільки пробіли з обох сторін будуть видалені. > Для деталей про контроль пробілів у шаблонах дивіться [Офіційну документацію Go шаблонів](https://godoc.org/text/template) Нарешті, іноді легше сказати системі шаблонів, як вам потрібно робити відступи, замість того, щоб намагатися освоїти розташування пробілів у директивах шаблону. З цієї причини іноді корисно використовувати функцію `indent` (`{{ indent 2 "mug:true" }}`). ## Модифікація області видимості за допомогою `with` {#modifying-scope-using-with} Наступна структура управління, яку розглянемо, це дія `with`. Вона контролює область видимості змінних. Нагадаємо, що `.` є посиланням на _поточну область видимості_. Отже, `.Values` вказує шаблону знайти обʼєкт `Values` у поточній області видимості. Синтаксис для `with` схожий на простий оператор `if`: ```go {{ with PIPELINE }} # обмежена область видимості {{ end }} ``` Області видимості можуть змінюватися. `with` дозволяє вам встановити поточну область видимості (`.`) на певний обʼєкт. Наприклад, ми працювали з `.Values.favorite`. Перепишемо наш ConfigMap, щоб змінити область видимості `.` на `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Зверніть увагу, що ми видалили умову `if` з попереднього прикладу, оскільки вона тепер непотрібна — блок після `with` виконується лише якщо значення `PIPELINE` не є порожнім. Тепер ми можемо звертатися до `.drink` і `.food` без додаткових уточнень. Це відбувається тому, що оператор `with` встановлює `.` на `.Values.favorite`. `.` скидається до попередньої області видимості після `{{ end }}`. Але є одне застереження! Усередині обмеженої області видимості ви не зможете отримати доступ до інших обʼєктів з батьківської області видимості за допомогою `.`. Наприклад, це не спрацює: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Це викличе помилку, оскільки `Release.Name` не знаходиться в межах обмеженої області видимості для `.`. Однак, якщо ми поміняємо місцями останні два рядки, все працюватиме як очікувалося, тому що область видимості скидається після `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Або ми можемо використовувати `$` для доступу до обʼєкта `Release.Name` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Після розгляду `range` ми перейдемо до змінних шаблону, які пропонують одне рішення для проблеми з областю видимості вище. ## Цикли за допомогою дії `range` {#looping-with-the-range-action} Багато мов програмування підтримують цикли за допомогою `for` циклів, `foreach` циклів або подібних функціональних механізмів. У мові шаблонів Helm, для перебору колекції використовується оператор `range`. Спочатку додамо список інгредієнтів для піци до нашого файлу `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Тепер у нас є список (в шаблонах він називається `slice`) інгредієнтів для піци. Ми можемо змінити наш шаблон, щоб вивести цей список у наш ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Ми можемо використовувати `$` для доступу до списку `Values.pizzaToppings` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Розглянемо детальніше список `toppings:`. Функція `range` буде "перебирати" список `pizzaToppings`. Але тепер відбувається щось цікаве. Так само як `with` встановлює область видимості для `.`, так і оператор `range` встановлює область видимості. Кожного разу під час циклу `.` встановлюється на поточний інгредієнт для піци. Тобто, під час першої ітерації `.` буде дорівнювати `mushrooms`. Під час другої ітерації він буде дорівнювати `cheese`, і так далі. Ми можемо безпосередньо передавати значення `.` в конвеєр, тому коли ми використовуємо `{{ . | title | quote }}`, воно передається в `title` (функцію для перетворення на заголовні літери) і потім в `quote`. Якщо ми запустимо цей шаблон, результат буде: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` У цьому прикладі ми зробили дещо хитре. Лінія `toppings: |-` оголошує багаторядковий рядок. Отже, наш список інгредієнтів для піци насправді не є YAML списком. Це великий рядок. Чому ми так робимо? Тому що дані в ConfigMaps `data` складаються з пар ключ/значення, де і ключ, і значення є простими рядками. Щоб зрозуміти, чому це так, ознайомтеся з [документацією Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Для нас цей нюанс не так важливий. > Маркер `|-` в YAML приймає багаторядковий рядок. Це може бути корисною технікою для вбудовування великих блоків даних у ваші маніфести, як показано тут. Іноді корисно швидко створити список у шаблоні, а потім перебирати цей список. Шаблони Helm мають функцію для спрощення цього завдання: `tuple`. У компʼютерних науках кортеж (tuple) — це список фіксованого розміру, але з довільними типами даних. Це приблизно передає те, як використовується `tuple`. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` The above will produce this: ```yaml sizes: |- - small - medium - large ``` Окрім списків і кортежів, `range` можна використовувати для перебору колекцій, які мають ключ і значення (як `map` або `dict`). Ми розглянемо, як це зробити в наступному розділі, коли введемо змінні шаблону. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/data_types.md ================================================ --- title: "Додаток: Типи даних Go та шаблони" description: Короткий огляд змінних у шаблонах. sidebar_position: 16 --- Мова шаблонів Helm реалізована мовою програмування Go, яка має сувору типізацію. З цієї причини змінні в шаблонах мають _типи_. Здебільшого змінні будуть представлені одним із наступних типів: - `string`: Рядок тексту - `bool`: значення `true` або `false` - `int`: Ціле число (існують також 8, 16, 32 і 64-бітні знакові та беззнакові варіанти) - `float64`: 64-бітне число з плаваючою комою (також є 8, 16 та 32-бітні різновиди) - `byte slice` (`[]byte`): Масив байтів, часто використовується для зберігання (потенційно) бінарних даних - `struct`: Обʼєкт із властивостями та методами - `slice`: (індексований список) одного з попередніх типів - `map`: словник з ключами-рядками (`map[string]interface{}`), де значенням є один із попередніх типів У Go існує багато інших типів, і іноді вам доведеться виконувати перетворення між ними у своїх шаблонах. Найпростіший спосіб налагодження типу обʼєкта — це передати його через `printf "%T"` у шаблоні, що виведе тип на екран. Дивіться також функції `typeOf` та `kindOf`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/debugging.md ================================================ --- title: Виправлення помилок у шаблонах description: Виправлення проблем з розгортанням чартів. sidebar_position: 13 --- Відлагодження шаблонів може бути складним, оскільки відрендерений шаблон надсилається на сервер API Kubernetes, який може відхилити файли YAML з причин, не повʼязаних із форматуванням. Існує кілька команд, які можуть допомогти у відлагодженні. - `helm lint` — це ваш основний інструмент для перевірки того, чи відповідає ваш чарт найкращим практикам - `helm template --debug` перевірить рендеринг шаблонів чартів локально. - `helm install --dry-run --debug` також візуалізує чарт локально без його встановлення, але також перевірить, чи конфліктують ресурси з іншими, що вже працюють у кластері. Встановлення `--dry-run=server` додатково виконає будь-який `lookup` у чарті щодо сервера. - `helm get manifest`: це хороший спосіб перевірити, які шаблони встановлені на сервері. Коли ваш YAML не проходить перевірку, але ви хочете побачити, що було згенеровано, простий спосіб отримати YAML — закоментувати проблемний розділ у шаблоні, а потім повторно запустити `helm install --dry-run --debug`: ```go apiVersion: v2 # деяка: проблемна секція # {{ .Values.foo | quote }} ``` Вищезазначене буде відтворено та повернуто з коментарями без змін: ```yaml apiVersion: v2 # деяка: проблемна секція # "bar" ``` Це забезпечує швидкий спосіб перегляду згенерованого контенту без блокування помилками парсингу YAML. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/function_list.mdx ================================================ --- title: Список функцій шаблонів description: Список функцій шаблонів, доступних у Helm sidebar_position: 6 --- import Helm4 from "../_v4-in-progress.mdx" Helm містить багато функцій шаблонів, якими ви можете скористатися у шаблонах. Вони перераховані тут і розбиті на наступні категорії: * [Криптографія та безпека](#cryptographic-and-security-functions) * [Дата](#date-functions) * [Словники](#dictionaries-and-dict-functions) * [Кодування](#encoding-functions) * [Шлях до файлу](#file-path-functions) * [Kubernetes та чарти](#kubernetes-and-chart-functions) * [Логіка та керування потоком](#logic-and-flow-control-functions) * [Списки](#lists-and-list-functions) * [Математичні функції](#math-functions) * [Математичні обчислення з комою](#float-math-functions) * [Мережа](#network-functions) * [Аналіз](#reflection-functions) * [Регулярні вирази](#regular-expressions) * [Семантичні версії](#semantic-version-functions) * [Рядки](#string-functions) * [Перетворення типів](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## Логічні функції та функції керування потоком {#logic-and-flow-control-functions} Helm включає в себе численні логічні функції та функції управління потоком, включаючи [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or) та [required](#required). ### and Повертає логічне AND для двох або більше аргументів (перший порожній аргумент або останній аргумент). ```go and .Arg1 .Arg2 ``` ### or Повертає логічне OR двох або більше аргументів (перший непорожній аргумент або останній аргумент). ```go or .Arg1 .Arg2 ``` ### not Повертає логічне заперечення свого аргументу. ```go not .Arg ``` ### eq Повертає логічну рівність аргументів (наприклад, Arg1 == Arg2). ```go eq .Arg1 .Arg2 ``` ### ne Повертає логічну нерівність аргументів (наприклад, Arg1 != Arg2) ```go ne .Arg1 .Arg2 ``` ### lt Повертає логічне `true`, якщо перший аргумент менший за другий. В іншому випадку повертає `false` (наприклад, Arg1 < Arg2). ```go lt .Arg1 .Arg2 ``` ### le Повертає логічне `true`, якщо перший аргумент менший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 <= Arg2). ```go le .Arg1 .Arg2 ``` ### gt Повертає логічне `true`, якщо перший аргумент більший за другий. В іншому випадку повертає `false` (наприклад, Arg1 > Arg2). ```go gt .Arg1 .Arg2 ``` ### ge Повертає логічне `true`, якщо перший аргумент більший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 >= Arg2). ```go ge .Arg1 .Arg2 ``` ### default Щоб встановити просте стандартне значення, використовуйте `default`: ```go default "foo" .Bar ``` У наведеному прикладі, якщо `.Bar` має непорожнє значення, воно буде використане. Якщо ж воно порожнє, повернеться `foo`. Визначення "порожньості" залежить від типу: * Числові: 0 * Рядок: "" * Списки: `[]` * Словники: `{}` * Логічний: `false` * І завжди `nil` (або null) Для структур немає визначення порожнього значення, тому структура ніколи не поверне стандартного значення. ### required Вкажіть значення, які повинні бути встановлені, за допомогою `required`: ```go required "A valid foo is required!" .Bar ``` Якщо `.Bar` є порожнім або не визначеним (див. [default](#default) щодо того, як це оцінюється), шаблон не буде згенерований і поверне надане повідомлення про помилку. ### empty Функція `empty` повертає `true`, якщо надане значення вважається порожнім, і `false` в іншому випадку. Пусті значення перелічені в розділі `default`. ```go empty .Foo ``` Зверніть увагу, що в умовах шаблонів Go порожність розраховується автоматично. Таким чином, рідко потрібно використовувати `if not empty .Foo`. Замість цього просто використовуйте `if .Foo`. ### fail Безумовно повертає порожні `string` та `error` з зазначеним текстом. Це корисно в ситуаціях, коли інші умови визначили, що рендеринг шаблону повинен зазнати невдачі. ```go fail "Please accept the end user license agreement" ``` ### coalesce Функція `coalesce` приймає список значень і повертає перше непорожнє значення. ```go coalesce 0 1 2 ``` У наведеному випадку повертає `1`. Ця функція корисна для перевірки кількох змінних або значень: ```go coalesce .name .parent.name "Matt" ``` Цей приклад спочатку перевірить, чи `.name` порожній. Якщо ні, то поверне це значення. Якщо він _є_ порожнім, `coalesce` перевірить `.parent.name` на порожність. Нарешті, якщо і `.name`, і `.parent.name` порожні, то поверне `Matt`. ### ternary Функція `ternary` приймає два значення і тестове значення. Якщо тестове значення є `true`, повернеться перше значення. Якщо тестове значення є порожнім, повернеться друге значення. Це подібно до тернарного оператора в C та інших мовах програмування. #### тестове значення true {#true-test-value} ```go ternary "foo" "bar" true ``` або ```go true | ternary "foo" "bar" ``` У цьому випадку повертається `"foo"`. #### тестове значення false {#false-test-value} ```go ternary "foo" "bar" false ``` або ```gol false | ternary "foo" "bar" ``` У цьому випадку повертається `"bar"`. ## Функції для роботи з рядками {#string-functions} Helm має такі функції для обробки рядків: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap) та [wrapWith](#wrapwith). ### print Повертає рядок, що є комбінацією його частин. ```go print "Matt has " .Dogs " dogs" ``` Типи, які не є рядками, перетворюються на рядки, якщо це можливо. Зверніть увагу, що коли два аргументи поруч один з одним не є рядками, між ними додається пробіл. ### println Працює так само як [print](#print), але додає новий рядок наприкінці. ### printf Повертає рядок на основі відформатованого рядка та аргументів, що передаються у до нього. ```go printf "%s has %d dogs." .Name .NumberDogs ``` Заповнювач, який слід використовувати, залежить від типу переданого аргументу. Серед них: Загального призначення: * `%v` значення в стандартному форматі * при друку словників, прапорець `+` (%+v) додає імена полів * `%%` літеральний знак відсотка; не використовує значення Логічний: * `%t` слово true або false Цілі числа: * `%b` двійкові, основа 2 * `%c` символ, представлений відповідною кодовою точкою Unicode * `%d` десяткові, основа 10 * `%o` вісімкові, основа 8 * `%O` основа 8 з префіксом 0o * `%q` вісімкові, однорядковий літерал символу, безпечно екранований * `%x` шістнадцяткові, основа 16, з малими літерами для a-f * `%X` шістнадцяткові, основа 16, з великими літерами для A-F * `%U` Unicode формат: U+1234; те ж саме, що "U+%04X" Компоненти з рухомою комою та комплексні компоненти: * `%b` десятковий формат без наукової нотації з показником ступеня двійки, наприклад -123456p-78 * `%e` наукова нотація, наприклад -1.234456e+78 * `%E` наукова нотація, наприклад -1.234456E+78 * `%f` десятковий формат без експоненти, наприклад 123.456 * `%F` синонім для %f * `%g` %e для великих експонент, %f в іншому випадку * `%G` %E для великих експонент, %F в іншому випадку * `%x` шістнадцяткова нотація (з десятковим показником ступеня), наприклад -0x1.23abcp+20 * `%X` шістнадцяткова нотація у верхньому регістрі, наприклад -0X1.23ABCP+20 Рядок та зріз (slice) байтів (обробляються однаково з цими діями): * `%s` необроблені байти рядка або зрізу * `%q` рядок в подвійних лапках, безпечно екранований * `%x` основа 16, малий регістр, два символи на байт * `%X` основа 16, великий регістр, два символи на байт Зріз (Slice): * `%p` адреса 0-го елемента у шістнадцятковій нотації, з передуючим 0x ### trim Функція `trim` видаляє пробіли з обох сторін рядка: ```go trim " hello " ``` У результаті отримаємо `hello`. ### trimAll Видаляє зазначені символи з початку та кінця рядка: ```go trimAll "$" "$5.00" ``` У результаті отримаємо `5.00` (як рядок). ### trimPrefix Видаляє лише префікс з рядка: ```go trimPrefix "-" "-hello" ``` У результаті отримаємо `hello`. ### trimSuffix Видаляє лише суфікс з рядка: ```go trimSuffix "-" "hello-" ``` У результаті отримаємо `hello`. ### lower Перетворює весь рядок у нижній регістр: ```go lower "HELLO" ``` У результаті отримаємо `hello`. ### upper Перетворює весь рядок у верхній регістр: ```go upper "hello" ``` У результаті отримаємо `HELLO`. ### title Перетворює рядок у титульний регістр: ```go title "hello world" ``` У результаті отримаємо `Hello World`. ### untitle Видаляє титульне оформлення. `untitle "Hello World"` поверне `hello world`. ### repeat Повторює рядок кілька разів: ```go repeat 3 "hello" ``` У результаті отримаємо `hellohellohello`. ### substr Отримує підрядок з рядка. Приймає три парамтери: * початок (int) * кінець (int) * рядок (string) ```go substr 0 5 "hello world" ``` У результаті отримаємо `hello`. ### nospace Видаляє всі пробіли з рядка: ```go nospace "hello w o r l d" ``` У результаті отримаємо `helloworld`. ### trunc Обрізає рядок: ```go trunc 5 "hello world" ``` У результаті отримаємо `hello`. ```go trunc -5 "hello world" ``` У результаті отримаємо `world`. ### abbrev Обрізає рядок додаючи три крапки (`...`): Параметри: * максимальна довжина * рядок ```go abbrev 5 "hello world" ``` У результаті отримаємо `he...`, оскільки ширина трьох крапок враховується до максимальної довжини. ### abbrevboth Обрізає обидві сторони: ```go abbrevboth 5 10 "1234 5678 9123" ``` У результаті отримаємо `...5678...`. Параметри: * зсув ліворуч * максимальна довжина * рядок ### initials Для кількох слів бере першу літеру кожного слова та обʼєднує їх: ```go initials "First Try" ``` У результаті отримаємо `FT`. ### randAlphaNum, randAlpha, randNumeric та randAscii {#randalphanum-randalpha-randnumeric-and-randascii} Ці чотири функції генерують криптографічно безпечні (використовує ```crypto/rand```) випадкові рядки, але з різними базовими наборами символів: * `randAlphaNum` використовує `0-9a-zA-Z` * `randAlpha` використовує `a-zA-Z` * `randNumeric` використовує `0-9` * `randAscii` використовує всі друковані ASCII символи Кожна з них приймає один параметр: цілу довжину рядка. ```go randNumeric 3 ``` У результаті отримаємо випадковий рядок з трьох цифр. ### wrap Виконує перенесення тексту на вказаній кількості стовпців: ```go wrap 80 $someText ``` У результаті для рядка `$someText` буде виконано перенесення на 80-му стовпці. ### wrapWith `wrapWith` працює так само як і `wrap`, але дозволяє вказати рядок для перенесення. (`wrap` використовує `\n`) ```go wrapWith 5 "\t" "Hello World" ``` У результаті отримаємо `Hello World` (де пробіл є символом ASCII табуляції). ### contains Перевіряє, чи один рядок міститься всередині іншого: ```go contains "cat" "catch" ``` У результаті отримаємо `true`, оскільки `catch` містить `cat`. ### hasPrefix і hasSuffix {#hasprefix-and-hassuffix} Функції `hasPrefix` і `hasSuffix` перевіряють, чи має рядок заданий префікс або суфікс: ```go hasPrefix "cat" "catch" ``` У результаті отримаємо `true`, оскільки `catch` має префікс `cat`. ### quote і squote {#quote-and-squote} Ці функції обгортають рядок у подвійні лапки (`quote`) або одинарні лапки (`squote`). ### cat Функція `cat` обʼєднує кілька рядків в один, розділяючи їх пробілами: ```go cat "hello" "beautiful" "world" ``` У результаті отримаємо `hello beautiful world`. ### indent Функція `indent` додає відступ у кожному рядку вказаного тексту на зазначену кількість символів. Це корисно для вирівнювання багаторядкових текстів: ```go indent 4 $lots_of_text ``` У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу. ### nindent Функція `nindent` є такою ж, як і `indent`, але додає новий рядок на початку рядка. ```go nindent 4 $lots_of_text ``` У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу, а також буде додано новий рядок на початку. ### replace Виконує просту заміну рядків. Вона приймає три аргументи: * рядок для заміни * рядок, на який замінювати * вихідний рядок ```go "I Am Henry VIII" | replace " " "-" ``` У результаті отримаємо `I-Am-Henry-VIII`. ### plural Форма множини. ```go len $fish | plural "one anchovy" "many anchovies" ``` У наведеному випадку, якщо довжина рядка дорівнює 1, буде надруковано перший аргумент (`one anchovy`). В іншому випадку буде надруковано другий аргумент (`many anchovies`). Аргументи: * однина * множина * довжина (ціле число) :::note Helm наразі не підтримує мови зі складнішими правилами множини. І `0` вважається множиною, оскільки англійська мова ставиться до нього саме так (`zero anchovies`). ::: ### snakecase Перетворює рядок з camelCase в snake_case. ```go snakecase "FirstName" ``` У результаті отримаємо `first_name`. ### camelcase Перетворює рядок з snake_case в CamelCase. ```go camelcase "http_server" ``` У результаті отримаємо `HttpServer`. ### kebabcase Перетворює рядок з camelCase в kebab-case. ```go kebabcase "FirstName" ``` У результаті отримаємо `first-name`. ### swapcase Змінює регістр рядка за допомогою алгоритму на основі слів. Алгоритм перетворення: * Символи у верхньому регістрі перетворюються у нижній регістр * Символи в титульному регістрі перетворюються у нижній регістр * Символи у нижньому регістрі після пробілу або на початку перетворюються у титульний регістр * Інші символи у нижньому регістрі перетворюються у верхній регістр * Пробіли визначаються як unicode.IsSpace(char) ```go swapcase "This Is A.Test" ``` У результаті отримаємо `tHIS iS a.tEST`. ### shuffle Перемішує рядок. ```go shuffle "hello" ``` У результаті отримаємо випадковий порядок літер у `hello`, можливо, `oelhl`. ## Функції перетворення типів {#type-conversion-functions} Helm пропонує такі функції для перетворення типів: * `atoi`: Перетворює рядок на ціле число. * `float64`: Перетворює на `float64`. * `int`: Перетворює на `int` відповідно до ширини системи. * `int64`: Перетворює на `int64`. * `toDecimal`: Перетворює unix octal на `int64`. * `toString`: Перетворює на рядок. * `toStrings`: Перетворює список, зріз або масив на список рядків. * `toJson` (`mustToJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON. * `toPrettyJson` (`mustToPrettyJson`): Перетворює список, зріз, масив, словник або обʼєкт на форматований JSON. * `toRawJson` (`mustToRawJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON з неекранованими HTML символами. * `fromYaml`: Перетворює YAML рядок на обʼєкт. * `fromJson`: Перетворює JSON рядок на обʼєкт. * `fromJsonArray`: Перетворює JSON масив на список. * `toYaml`: Перетворює список, зріз, масив, словник або обʼєкт у формат YAML з відступами, може використовуватися для копіювання фрагментів YAML з будь-якого джерела. Ця функція еквівалентна функції GoLang yaml.Marshal, див. документацію тут: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal * `toYamlPretty`: Перетворює список, зріз, масив, словник або обʼєкт у формат YAML з відступами. Еквівалентний функції `toYaml`, але додатково робить відступи у списках на 2 пробіли. * `toToml`: Перетворює список, зріз, масив, словник або обʼєкт у toml, може використовуватися для копіювання фрагментів toml з будь-якого джерела. * `fromYamlArray`: Перетворює YAML масив на список. Тільки `atoi` вимагає, щоб вхідні дані були певного типу. Інші функції намагатимуться перетворити будь-який тип у тип призначення. Наприклад, `int64` може перетворювати числа з рухомою комою в цілі числа, а також перетворювати рядки в цілі числа. ### toStrings Перетворює колекцію схожу на список на зріз рядків. ```go list 1 2 3 | toStrings ``` Перетворює `1` на `"1"`, `2` на `"2"` і так далі, а потім повертає їх як список. ### toDecimal Перетворює unix octal на десятковий формат. ```go "0777" | toDecimal ``` Перетворює `0777` на `511` і повертає значення як int64. ### toJson, mustToJson The `toJson` function encodes an item into a JSON string. If the item cannot be converted to JSON the function will return an empty string. `mustToJson` will return an error in case the item cannot be encoded in JSON. ```go toJson .Item ``` Поверне JSON рядкове представлення `.Item`. ### toPrettyJson, mustToPrettyJson Функція `toPrettyJson` кодує елемент у форматований (з відступами) JSON рядок. ```go toPrettyJson .Item ``` Поверне відформатоване JSON рядкове представлення `.Item`. ### toRawJson, mustToRawJson The `toRawJson` function encodes an item into JSON string with HTML characters unescaped. ```go toRawJson .Item ``` Поверне неекрановане JSON рядкове представлення `.Item`. ### fromYaml Функція `fromYaml` приймає YAML рядок і повертає обʼєкт, який можна використовувати в шаблонах. Файл `yamls/person.yaml`: ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```go {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson Функція `fromJson` приймає JSON рядок і повертає обʼєкт, який можна використовувати в шаблонах. Файл `jsons/person.json`: ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```go {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray Функція `fromJsonArray` приймає JSON масив і повертає список, який можна використовувати в шаблонах. Файл `jsons/people.json`: ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```go {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty Функції `toYaml` та `toYamlPretty` кодують обʼєкт (список, зріз, масив, словник або обʼєкт) у формат YAML із відступами. > Зверніть увагу, що `toYamlPretty` є функціонально еквівалентним, але виведе YAML з додатковими відступами для елементів списку. ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray Функція `fromYamlArray` приймає YAML масив і повертає список, який можна використовувати в шаблонах. Файл `yamls/people.yml`: ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```go {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Регулярні Вирази {#regular-expressions} Helm включає такі функції для роботи з регулярними виразами: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Повертає `true`, якщо вхідний рядок містить хоча б один збіг для регулярного виразу. ```go regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` Поверне `true`. `regexMatch` викликає паніку у разі проблеми, а `mustRegexMatch` поверне помилку у рушії шаблонів у разі проблеми. ### regexFindAll, mustRegexFindAll Повертає зріз усіх збігів регулярного виразу у вхідному рядку. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги. ```go regexFindAll "[2,4,6,8]" "123456789" -1 ``` Поверне `[2 4 6 8]`. `regexFindAll` викликає паніку у разі проблеми, а `mustRegexFindAll` поверне помилку у рушії шаблонів у разі проблеми. ### regexFind, mustRegexFind Повертає перший (зліва) збіг регулярного виразу у вхідному рядку. ```go regexFind "[a-zA-Z][1-9]" "abcd1234" ``` Поверне `d1`. `regexFind` викликає паніку у разі проблеми, а `mustRegexFind` поверне помилку у рушії шаблонів у разі проблеми. ### regexReplaceAll, mustRegexReplaceAll Повертає копію вхідного рядка, замінюючи збіги Regexp на рядок заміни replacement. Усередині заміни рядка знаки $ інтерпретуються як в Expand, тому, наприклад, $1 представляє текст першого підзбігу. Перший аргумент — ``, другий — ``, а третій — ``. ```go regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` Поверне `-W-xxW-`. `regexReplaceAll` викликає паніку у разі проблеми, а `mustRegexReplaceAll` поверне помилку у рушії шаблонів у разі проблеми. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Повертає копію вхідного рядка, замінюючи збіги Regexp на рядок заміни replacement. Рядок заміни підставляється безпосередньо, без використання Expand. Перший аргумент — ``, другий — ``, третій — ``. ```go regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` Поверне `-${1}-${1}-`. `regexReplaceAllLiteral` викликає паніку у разі проблеми, а `mustRegexReplaceAllLiteral` поверне помилку у рушії шаблонів у разі проблеми. ### regexSplit, mustRegexSplit Розбиває вхідний рядок на підрядки, розділені виразом, і повертає фрагмент підрядків між цими збігами виразу. Останній параметр `n` визначає кількість підрядків, що повертаються, де `-1` означає повернути всі збіги. ```go regexSplit "z+" "pizza" -1 ``` Поверне `[pi a]`. `regexSplit` викликає паніку у разі проблеми, а `mustRegexSplit` поверне помилку у рушії шаблонів у разі проблеми. ## Функції криптографії та безпеки {#cryptographic-and-security-functions} Helm надає декілька розширених криптографічних функцій, серед яких: [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum) та [sha256sum](#sha256sum). ### sha1sum Функція `sha1sum` отримує рядок і обчислює його SHA1-дайджест. ```go sha1sum "Hello world!" ``` ### sha256sum Функція `sha256sum` отримує рядок і обчислює його SHA256-дайджест. ```go sha256sum "Hello world!" ``` Це обчислює SHA 256 контрольну суму у форматі "ASCII armored", який є безпечним для друку. ### adler32sum Функція `adler32sum` отримує рядок і обчислює його контрольну суму Adler-32. ```go adler32sum "Hello world!" ``` ### htpasswd Функція `htpasswd` приймає `username` та `password` і генерує хеш `bcrypt` пароля. Результат можна використовувати для базової автентифікації в [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ```go htpasswd "myUser" "myPassword" ``` Зверніть увагу, що небезпечно зберігати пароль безпосередньо в шаблоні. ### randBytes Функція randBytes приймає число N і генерує криптографічно захищену (використовує crypto/rand) випадкову послідовність з N байтів. Послідовність повертається у вигляді рядка, закодованого в base64. ```go randBytes 24 ``` ### derivePassword Функція `derivePassword` може бути використана для отримання конкретного пароля на основі деяких спільних обмежень «головного пароля». Алгоритм для цього добре [описаний](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ```go derivePassword 1 "long" "password" "user" "example.com" ``` Зверніть увагу, що небезпечно зберігати частини безпосередньо в шаблоні. ### genPrivateKey Функція `genPrivateKey` генерує новий приватний ключ, закодований у PEM-блок. Вона приймає одне з наступних значень для свого першого параметра: * `ecdsa`: Генерує ключ еліптичної кривої DSA (P256) * `dsa`: Генерує DSA ключ (L2048N256) * `rsa`: Генерує RSA 4096 ключ ### buildCustomCert Функція `buildCustomCert` дозволяє налаштувати сертифікат. Вона приймає наступні строкові параметри: * Сертифікат у форматі PEM, закодований у base64 * Приватний ключ у форматі PEM, закодований у base64 Функція повертає обʼєкт сертифіката з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```go $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. ### genCA Функція `genCA` генерує новий самопідписний сертифікат x509 для центру сертифікацї. Вона приймає наступні параметри: * Загальне імʼя субʼєкта (cn) * Термін дії сертифіката у днях Функція повертає обʼєкт з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```go $ca := genCA "foo-ca" 365 ``` Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. ### genSelfSignedCert Функція `genSelfSignedCert` генерує новий самопідписаний сертифікат x509. Вона приймає наступні параметри: * Загальне імʼя субʼєкта (cn) * Необовʼязковий список IP-адрес; може бути nil * Необовʼязковий список альтернативних DNS-імен; може бути nil * Термін дії сертифіката у днях Функція повертає обʼєкт з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```go $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert Функція `genSignedCert` генерує новий сертифікат x509, підписаний зазначеним CA. Вона приймає наступні параметри: * Спільне імʼя субʼєкта (cn) * Необовʼязковий список IP-адрес; може бути nil * Необовʼязковий список альтернативних DNS-імен; може бути nil * Термін дії сертифіката у днях * CA (див. `genCA`) Приклад: ```go $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES Функція `encryptAES` шифрує текст за допомогою AES-256 CBC і повертає рядок, закодований у base64. ```go encryptAES "secretkey" "plaintext" ``` ### decryptAES Функція `decryptAES` отримує рядок у форматі base64, закодований за допомогою алгоритму AES-256 CBC, і повертає розкодований текст. ```go "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Функції дати {#date-functions} Helm включає наступні функції дати, які ви можете використовувати в шаблонах: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) та [unixEpoch](#unixepoch). ### now Поточна дата/час. Використовуйте це разом з іншими функціями дати. ### ago Функція `ago` повертає тривалість від часу. Зараз у секундах. ```go ago .CreatedAt ``` повертає у форматі `time.Duration` String() ```go 2h34m7s ``` ### date Функція `date` форматує дату. Формат дати до РІК-МІСЯЦЬ-ДЕНЬ: ```go now | date "2006-01-02" ``` Форматування дати в Go [дещо відрізняється](https://pauladamsmith.com/blog/2011/05/go_time.html). Коротко, візьміть цю базову дату: ```go Mon Jan 2 15:04:05 MST 2006 ``` Запишіть її у потрібному форматі. Вище, `2006-01-02` — це та ж дата, але в потрібному форматі. ### dateInZone Те ж саме, що і `date`, але з часовою зоною. ```go dateInZone "2006-01-02" (now) "UTC" ``` ### duration Форматує задану кількість секунд як `time.Duration`. Це повертає 1m35s ```go duration "95" ``` ### durationRound Округлює задану тривалість до найзначнішої одиниці. Рядки та `time.Duration` аналізуються як тривалість, тоді як `time.Time` обчислюється як тривалість з моменту. Це повертає 2h ```go durationRound "2h10m5s" ``` Це повертає 3mo ```go durationRound "2400h10m5s" ``` ### unixEpoch Повертає кількість секунд з unix-епохи для `time.Time`. ```go now | unixEpoch ``` ### dateModify, mustDateModify Функція `dateModify` приймає модифікацію та дату і повертає часову мітку. Відніміть годину і тридцять хвилин від поточного часу: ```go now | dateModify "-1.5h" ``` Якщо формат модифікації неправильний, `dateModify` поверне дату немодифікованою. `mustDateModify` поверне помилку в іншому випадку. ### htmlDate Функція `htmlDate` форматує дату для вставки в поле введення дати в HTML. ```go now | htmlDate ``` ### htmlDateInZone Те ж саме, що і htmlDate, але з часовою зоною. ```go htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate Функція `toDate` перетворює рядок у дату. Перший аргумент — це макет дати, а другий — рядок дати. Якщо рядок не можна перетворити, він поверне нульове значення. `mustToDate` поверне помилку в разі, якщо рядок не можна перетворити. Це корисно, коли ви хочете перетворити дату-рядок в інший формат (використовуючи конвеєр). Нижче наведений приклад перетворює "2017-12-31" на "31/12/2017". ```go toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Словники та функції словників {#dictionaries-and-dict-functions} Helm надає тип зберігання ключ/значення, який називається `dict` (скорочено від "dictionary" ["словник"], як у Python). `dict` є _невпорядкованим_ типом. Ключ у словнику **має бути рядком**. Однак значення може бути будь-якого типу, навіть іншим `dict` або `list`. На відміну від `list`, `dict` не є незмінним. Функції `set` та `unset` змінюють вміст словника. Helm надає такі функції для роботи зі словниками: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) та [values](#values). ### dict Створення словників здійснюється шляхом виклику функції `dict` і передачі їй списку пар. Наступний приклад створює словник з трьома елементами: ```go $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get За наявності map і ключа отримає значення з map. ```go get $myDict "name1" ``` Наведений вище приклад поверне `"value1"`. Зверніть увагу, що якщо ключ не знайдено, ця операція просто поверне `""`. Помилка не буде згенерована. ### set Використовуйте `set`, щоб додати нову пару ключ/значення до словника. ```go $_ := set $myDict "name4" "value4" ``` Зверніть увагу, що `set` _повертає словник_ (вимога функцій шаблону Go), тому вам може знадобитися захопити значення, як це зроблено вище за допомогою присвоєння `$_`. ### unset За наявності map і ключа видалить ключ з map. ```go $_ := unset $myDict "name4" ``` As with `set`, this returns the dictionary. Зверніть увагу, що якщо ключ не знайдено, ця операція просто виконає вивід. Помилка не буде згенерована. ### hasKey Функція `hasKey` повертає `true`, якщо даний словник містить даний ключ. ```go hasKey $myDict "name1" ``` Якщо ключ не знайдено, це повертає `false`. ### pluck Функція `pluck` дозволяє вказати один ключ і кілька map, і отримати список усіх знайдених збігів: ```go pluck "name1" $myDict $myOtherDict ``` Наведений вище приклад поверне `list`, що містить усі знайдені значення (`[value1 otherValue1]`). Якщо даний ключ _не знайдено_ в map, цей map не буде мати елемента у списку (і довжина повернутого списку буде меншою, ніж кількість словників у виклику `pluck`). Якщо ключ _знайдено_, але значення є порожнім, це значення буде вставлено. Поширеною ідіомою у шаблонах Helm є використання `pluck... | first`, щоб отримати перший відповідний ключ із колекції словників. ### dig Функція `dig` проходить через вкладені набори словників, вибираючи ключі зі списку значень. Вона повертає стандартне значення, якщо будь-який з ключів не знайдено в асоційованому словнику. ```go dig "user" "role" "humanName" "guest" $dict ``` За наявності словника, структурованого таким чином: ```json { user: { role: { humanName: "curator" } } } ``` наведений вище приклад поверне `"curator"`. Якщо у словнику навіть не було поля `user`, результатом буде `"guest"`. Dig може бути дуже корисним у випадках, коли ви хочете уникнути захисних конструкцій, особливо з огляду на те, що `and` у пакеті шаблонів Go не є скороченням. Наприклад, `and a.maybeNil a.maybeNil.iNeedThis` завжди оцінюватиме `a.maybeNil.iNeedThis` і викликатиме паніку, якщо `a` не має поля `maybeNil`. `dig` приймає свій аргумент словника останнім, щоб підтримувати конвеєрну обробку. Наприклад: ```go merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Обʼєднує два або більше словників в один, надаючи перевагу словнику призначення: Наприклад: ```yaml dst: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом буде: ```yaml newdict: default: default overwrite: me key: true ``` ```go $newdict := merge $dest $source1 $source2 ``` Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, ```go deepCopy $source | merge $dest ``` `mustMerge` поверне помилку в разі невдалого обʼєднання. ### mergeOverwrite, mustMergeOverwrite Обʼєднує два або більше словників в один, надаючи перевагу **зправа наліво**, ефективно перезаписуючи значення в словнику призначення: Наприклад: ```yaml dst: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом буде: ```yaml newdict: default: default overwrite: overwritten key: false ``` ```go $newdict := mergeOverwrite $dest $source1 $source2 ``` Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, ```go deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` поверне помилку в разі невдалого обʼєднання. ### keys Функція `keys` повертає `list` усіх ключів одного або декількох типів `dict`. Оскільки словник є _невпорядкованим_, ключі не будуть у передбачуваному порядку. Їх можна відсортувати за допомогою `sortAlpha`. ```go keys $myDict | sortAlpha ``` При поданні кількох словників ключі будуть обʼєднані. Використовуйте функцію `uniq` разом із `sortAlpha`, щоб отримати унікальний, відсортований список ключів. ```go keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick Функція `pick` вибирає тільки зазначені ключі зі словника, створюючи новий `dict`. ```go $new := pick $myDict "name1" "name2" ``` Наведений вище приклад поверне `{name1: value1, name2: value2}`. ### omit Функція `omit` схожа на `pick`, за винятком того, що вона повертає новий `dict` з усіма ключами, які _не_ збігаються з даними ключами. ```go $new := omit $myDict "name1" "name3" ``` Наведений вище приклад поверне `{name2: value2}`. ### values Функція `values` схожа на `keys`, за винятком того, що вона повертає новий `list` з усіма значеннями вихідного `dict` (підтримується тільки один словник). ```go $vals := values $myDict ``` Наведений вище приклад поверне `list["value1", "value2", "value 3"]`. Зверніть увагу, що функція `values` не дає жодних гарантій щодо порядку результатів; якщо це важливо, використовуйте `sortAlpha`. ### deepCopy, mustDeepCopy Функції `deepCopy` і `mustDeepCopy` приймають значення і роблять глибоку копію цього значення. Це включає словники та інші структури. `deepCopy` викликає паніку, коли виникає проблема, тоді як `mustDeepCopy` повертає помилку системі шаблонів, коли виникає помилка. ```go dict "a" 1 "b" 2 | deepCopy ``` ### Примітка про внутрішню структуру Dict {#a-note-on-dict-internals} `dict` реалізовано в Go як `map[string]interface{}`. Розробники Go можуть передавати значення `map[string]interface{}` у контекст, щоб зробити їх доступними для шаблонів як `dict`. ## Функції кодування {#encoding-functions} Helm має такі функції для кодування та декодування: * `b64enc`/`b64dec`: Кодування або декодування з використанням Base64 * `b32enc`/`b32dec`: Кодування або декодування з використанням Base32 ## Списки та функції для роботи зі списками {#lists-and-list-functions} Helm надає простий тип `list`, який може містити довільні послідовні дані. Це схоже на масиви або зрізи, але списки призначені для використання як незмінні типи даних. Створення списку цілих чисел: ```go $myList := list 1 2 3 4 5 ``` Це створить список `[1 2 3 4 5]`. Helm надає наступні функції для роботи зі списками: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) та [without (mustWithout)](#without-mustwithout). ### first, mustFirst Щоб отримати перший елемент списку, використовуйте `first`. `first $myList` повертає `1`. `first` викликає panic у разі проблеми, тоді як `mustFirst` повертає помилку в рушій шаблонів, якщо виникає проблема. ### rest, mustRest Щоб отримати залишок списку (все, окрім першого елемента), використовуйте `rest`. `rest $myList` повертає `[2 3 4 5]`. `rest` викликає panic у разі проблеми, тоді як `mustRest` повертає помилку в рушій шаблонів, якщо виникає проблема. ### last, mustLast Щоб отримати останній елемент списку, використовуйте `last`: `last $myList` повертає `5`. Це аналогічно до реверсування списку та виклику `first`. ### initial, mustInitial Ця функція доповнює `last`, повертаючи всі елементи, окрім останнього. `initial $myList` повертає `[1 2 3 4]`. `initial` викликає panic у разі проблеми, тоді як `mustInitial` повертає помилку в рушій шаблонів, якщо виникає проблема. ### append, mustAppend Додає новий елемент до існуючого списку, створюючи новий список. ```go $new = append $myList 6 ``` Це встановлює `$new` до `[1 2 3 4 5 6]`. `$myList` залишається незмінним. `append` викликає panic у разі проблеми, тоді як `mustAppend` повертає помилку в рушій шаблонів, якщо виникає проблема. ### prepend, mustPrepend Додає елемент на початок списку, створюючи новий список. ```go prepend $myList 0 ``` Це створить `[0 1 2 3 4 5]`. `$myList` залишається незмінним. `prepend` викликає panic у разі проблеми, тоді як `mustPrepend` повертає помилку в рушій шаблонів, якщо виникає проблема. ### concat Обʼєднує довільну кількість списків в один. ```go concat $myList ( list 6 7 ) ( list 8 ) ``` Це створить `[1 2 3 4 5 6 7 8]`. `$myList` залишається незмінним. ### reverse, mustReverse Створює новий список з елементами у зворотному порядку. ```go reverse $myList ``` Це генерує список `[5 4 3 2 1]`. `reverse` викликає panic у разі проблеми, тоді як `mustReverse` повертає помилку в рушій шаблонів, якщо виникає проблема. ### uniq, mustUniq Створює список, з якого видалено всі дублікати. ```go list 1 1 1 2 | uniq ``` The above would produce `[1 2]` `uniq` викликає panic у разі проблеми, тоді як `mustUniq` повертає помилку в рушій шаблонів, якщо виникає проблема. ### without, mustWithout Функція `without` відфільтровує елементи зі списку. ```go without $myList 3 ``` Це створить `[1 2 4 5]`. `without` може приймати більше одного фільтра: ```go without $myList 1 3 5 ``` Це створить `[2 4]`. `without` викликає panic у разі проблеми, тоді як `mustWithout` повертає помилку в рушій шаблонів, якщо виникає проблема. ### has, mustHas Перевіряє, чи містить список певний елемент. ```go has 4 $myList ``` Це поверне `true`, а `has "hello" $myList` поверне `false`. `has` викликає panic у разі проблеми, тоді як `mustHas` повертає помилку в рушій шаблонів, якщо виникає проблема. ### compact, mustCompact Приймає список та видаляє елементи з пустими значеннями. ```go $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` поверне новий список з видаленим пустим (тобто "") елементом. `compact` викликає panic у разі проблеми, тоді як `mustCompact` повертає помилку в рушій шаблонів, якщо виникає проблема. ### index Щоб отримати n-й елемент списку, використовуйте `index list [n]`. Щоб отримати елемент у багатовимірних списках, використовуйте `index list [n] [m] ...`. * `index $myList 0` повертає `1`. Це те саме, що і `myList[0]`. * `index $myList 0 1` повертає той самий результат, що і `myList[0][1]`. ### slice, mustSlice Щоб отримати часткові елементи списку, використовуйте `slice list [n] [m]`. Це еквівалентно до `list[n:m]`. * `slice $myList` повертає `[1 2 3 4 5]`. Це те саме, що і `myList[:]`. * `slice $myList 3` повертає `[4 5]`. Це те саме, що і `myList[3:]`. * `slice $myList 1 3` повертає `[2 3]`. Це те саме, що і `myList[1:3]`. * `slice $myList 0 3` повертає `[1 2 3]`. Це те саме, що і `myList[:3]`. `slice` викликає panic у разі проблеми, тоді як `mustSlice` повертає помилку в рушій шаблонів, якщо виникає проблема. ### until Функція `until` створює діапазон цілих чисел. ```go until 5 ``` Це генерує список `[0, 1, 2, 3, 4]`. Це корисно для циклів з `range $i, $e := until 5`. ### untilStep Як і `until`, функція `untilStep` створює список рахуючих цілих чисел. Але вона дозволяє визначити початок, кінець та крок: ```go untilStep 3 6 2 ``` Це створить `[3 5]`, починаючи з 3 та додаючи 2, поки не буде досягнуто або перевищено 6. Це схоже на функцію `range` в Python. ### seq Працює як команда `seq` у bash. * 1 параметр (end) — генерує всі натуральні числа від 1 до `end` включно. * 2 параметри (start, end) — генерує всі натуральні числа від `start` до `end` включно, збільшуючи або зменшуючи їх на 1. * 3 параметри (start, step, end) — генерують всі натуральні числа від `start` до `end` включно, збільшуючи або зменшуючи їх на `step`. ```go seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk Щоб розділити список на частини заданого розміру, використовуйте `chunk size list`. Це корисно для розбиття на сторінки. ```go chunk 3 (list 1 2 3 4 5 6 7 8) ``` Це створює список списків `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Математичні функції {#math-functions} Усі математичні функції працюють із значеннями типу `int64`, якщо не зазначено інше. Доступні наступні математичні функції: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub). ### add Додавайте числа за допомогою `add`. Приймає два або більше аргументів. ```go add 1 2 3 ``` ### add1 Щоб збільшити на 1, використовуйте `add1`. ### sub Щоб відняти, використовуйте `sub`. ### div Виконуйте цілочисельне ділення за допомогою `div`. ### mod Залишок від ділення можна отримати за допомогою `mod`. ### mul Множте за допомогою `mul`. Приймає два або більше аргументів. ```go mul 1 2 3 ``` ### max Повертає найбільше із серії цілих чисел. Це поверне `3`: ```go max 1 2 3 ``` ### min Повертає найменше із серії цілих чисел. `min 1 2 3` поверне `1`. ### len Повертає довжину аргументу у вигляді цілого числа. ```go len .Arg ``` ## Математичні функції з рухомою комою {#float-math-functions} Усі математичні функції працюють із значеннями типу `float64`. ### addf Додавайте числа за допомогою `addf`. Це поверне `5.5`: ```go addf 1.5 2 2 ``` ### add1f Щоб збільшити на 1, використовуйте `add1f`. ### subf Щоб відняти, використовуйте `subf`. Це еквівалентно `7.5 - 2 - 3` і поверне `2.5`: ```go subf 7.5 2 3 ``` ### divf Виконуйте ділення з рухомою комою за допомогою `divf`. Це еквівалентно `10 / 2 / 4` і поверне `1.25`: ```go divf 10 2 4 ``` ### mulf Множте за допомогою `mulf`. Це поверне `6`: ```go mulf 1.5 2 2 ``` ### maxf Повертає найбільше із серії чисел з рухомою комою: Це поверне `3`: ```go maxf 1 2.5 3 ``` ### minf Повертає найменше із серії чисел з рухомою комою. Це поверне `1.5`: ```go minf 1.5 2 3 ``` ### floor Повертає найбільше число з рухомою комою, яке менше або рівне вхідному значенню. `floor 123.9999` поверне `123.0`. ### ceil Повертає найбільше число з рухомою комою, яке більше або рівне вхідному значенню. `ceil 123.001` поверне `124.0`. ### round Повертає значення типу float, округленого до заданої кількості знаків після десяткової крапки. `round 123.555555 3` поверне `123.556`. ## Мережеві функції {#network-functions} Helm має одну мережеву функцію, `getHostByName`. Функція `getHostByName` приймає доменне імʼя і повертає IP-адресу. `getHostByName "www.google.com"` поверне відповідну IP-адресу для `www.google.com`. Для роботи цієї функції необхідно передати опцію `--enable-dns` у командному рядку helm. ## Функції роботи з шляхами до файлів {#file-path-functions} Хоча функції шаблонів Helm не надають доступу до файлової системи, вони надають функції для роботи з рядками, які відповідають домовленостям щодо шляхів до файлів. До них належать: [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) та [isAbs](#isabs). ### base Повертає останній елемент шляху. ```go base "foo/bar/baz" ``` Вищезазначене поверне "baz". ### dir Повертає теку, видаляючи останню частину шляху. Отже, `dir "foo/bar/baz"` повертає `foo/bar`. ### clean Очищує шлях. ```go clean "foo/bar/../baz" ``` Вищезазначене знаходить `..` і повертає `foo/baz`. ### ext Повертає розширення файлу. ```go ext "foo.bar" ``` Вищезазначене поверне `.bar`. ### isAbs Щоб перевірити, чи є шлях до файлу абсолютним, використовуйте `isAbs`. ## Функції аналізу {#reflection-functions} Helm надає базові інструменти аналізу. Це допомагає розробникам шаблонів зрозуміти основну інформацію про типи Go для конкретного значення. Helm написано на Go і він має строгий типізований підхід. Система типів застосовується всередині шаблонів. Go має кілька примітивів _видів (kind)_, таких як `string`, `slice`, `int64` і `bool`. Go має відкриту систему _типів_, яка дозволяє розробникам створювати власні типи. Helm надає набір функцій для кожного з них через [функції kind](#kind-functions) і [функції type](#type-functions). Також надана функція [deepEqual](#deepequal) для порівняння значень. ### Функції kind {#kind-functions} Є дві функції видів: `kindOf` повертає вид обʼєкта. ```go kindOf "hello" ``` Вищезазначене поверне `string`. Для простих тестів (наприклад, у блоці `if`), функція `kindIs` дозволяє перевірити, що значення має певний вид: ```go kindIs "int" 123 ``` Вищезазначене поверне `true`. ### Type Functions Типи трохи складніше обробляти, тому є три різні функції: * `typeOf` повертає основний тип значення: `typeOf $foo` * `typeIs` подібна до `kindIs`, але для типів: `typeIs "*io.Buffer" $myVal` * `typeIsLike` працює як `typeIs`, але також розіменовує покажчики :::note Жодна з цих функцій не може перевірити, чи реалізує щось певний інтерфейс, оскільки це вимагало б компіляції інтерфейсу заздалегідь. ::: ### deepEqual `deepEqual` повертає `true`, якщо два значення є ["глибоко рівними"](https://golang.org/pkg/reflect/#DeepEqual). Працює і для типів непримітивів (в порівнянні з вбудованим `eq`). ```go deepEqual (list 1 2 3) (list 1 2 3) ``` Вищезазначене поверне `true`. ## Функції семантичного версіонування {#semantic-version-functions} Some version schemes are easily parseable and comparable. Helm Деякі схеми версій легко розпізнати та порівнювати. Helm надає функції для роботи з версіями [SemVer 2](https://semver.org/lang/uk/). До них відносяться [semver](#semver) і [semverCompare](#semvercompare). Нижче ви також знайдете деталі про використання діапазонів для порівнянь. ### semver Функція `semver` розбирає рядок у семантичну версію: ```go $version := semver "1.2.3-alpha.1+123" ``` _Якщо синтаксичний аналізатор не спрацює, виконання шаблону буде зупинено з помилкою._ На цьому етапі `$version` є покажчиком на обʼєкт `Version` з наступними властивостями: * `$version.Major`: Основний номер (`1` вище) * `$version.Minor`: Мінорний номер (`2` вище) * `$version.Patch`: Номер патчу (`3` вище) * `$version.Prerelease`: Пре-реліз (`alpha.1` вище) * `$version.Metadata`: Метадані збірки (`123` вище) * `$version.Original`: Оригінальна версія у вигляді рядка Крім того, ви можете порівнювати `Version` з іншою версією, використовуючи функцію `Compare`: ```go semver "1.4.3" | (semver "1.2.3").Compare ``` Вищезазначене поверне `-1`. Значення повернення такі: * `-1`, якщо дана версія SemVer більша за версію, метод `Compare` якої був викликаний * `1`, якщо версія, для якої була викликана функція `Compare`, більша * `0`, якщо версії однакові (Зверніть увагу, що в SemVer поле `Metadata` не порівнюється під час операцій порівняння версій.) ### semverCompare Більш надійна функція порівняння надається як `semverCompare`. Ця версія підтримує діапазони версій: * `semverCompare "1.2.3" "1.2.3"` перевіряє на точний збіг * `semverCompare "~1.2.0" "1.2.3"` перевіряє, що основні та мінорні версії збігаються, і що номер патчу другої версії _більший або рівний_ першому параметру. Функції SemVer використовують бібліотеку [Masterminds semver](https://github.com/Masterminds/semver), від авторів Sprig. ### Основні порівняння {#basic-comparisons} Є два елементи порівнянь. По-перше, рядок порівняння є списком порівнянь з AND, розділених пробілом або комою. Ці порівняння потім розділяються операцією || (OR). Наприклад, `">= 1.2 < 3.0.0 || >= 4.2.3"` шукає порівняння, яке більше або дорівнює 1.2 і менше 3.0.0 або більше або дорівнює 4.2.3. Основні порівняння: * `=`: рівно (аналогічно відсутності оператора) * `!=`: не рівно * `>`: більше ніж * `<`: менше ніж * `>=`: більше або рівно * `<=`: менше або рівно ### Робота з версіями пре-релізів {#working-with-prerelease-versions} Пре-релізи, для тих, хто не знайомий з ними, використовуються для випусків програмного забезпечення до стабільних або загальнодоступних випусків. Прикладами пре-релізів є розробка, альфа, бета та реліз-кандидат. Пре-реліз може бути версією, наприклад, `1.2.3-beta.1`, в той час як стабільний реліз буде `1.2.3`. За порядком пріоритету пре-релізи йдуть перед їх повʼязаними релізами. У цьому прикладі `1.2.3-beta.1 < 1.2.3`. Згідно з специфікацією Semantic Version, пре-релізи можуть не відповідати API сумісності зі своїм релізом. Вона говорить, > Версія пре-релізу вказує, що версія нестабільна і може не відповідати запланованим вимогам сумісності, як зазначено у відповідній нормальній версії. Порівняння SemVer з використанням обмежень без компаратора пре-релізу пропустять пре-релізи. Наприклад, `>=1.2.3` пропустить пре-релізи при перегляді списку релізів, тоді як `>=1.2.3-0` буде оцінювати і знаходити пре-релізи. Причина для `0` як версії пре-релізу у прикладі порівняння полягає в тому, що пре-релізи можуть містити лише ASCII числа, літери та дефіси (разом з роздільниками `.`), згідно з специфікацією. Сортування відбувається в ASCII порядку сортування, згідно з специфікацією. Найнижчий символ — це `0` в ASCII порядку сортування (див. [ASCII Таблицю](http://www.asciitable.com/)). Розуміння ASCII порядку сортування важливе, оскільки A-Z йде перед a-z. Це означає, що `>=1.2.3-BETA` поверне `1.2.3-alpha`. Те, що ви могли б очікувати від чутливості до регістру, тут не застосовується. Це через ASCII порядок сортування, який зазначено у специфікації. ### Порівняння діапазонів з дефісами {#hyphen-range-comparisons} Є кілька методів обробки діапазонів, і перший — діапазони з дефісами. Вони виглядають так: * `1.2 - 1.4.5`, що еквівалентно `>= 1.2 <= 1.4.5` * `2.3.4 - 4.5`, що еквівалентно `>= 2.3.4 <= 4.5` ### Підстановочні символи в порівняннях {#wildcard-in-comparisons} Символи `x`, `X` та `*` можуть використовуватися як символи заміщення. Це працює для всіх операторів порівняння. Коли використовується з оператором `=`, він переходить до порівняння рівня патчу (див. тильду нижче). Наприклад, * `1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` * `>= 1.2.x` еквівалентно `>= 1.2.0` * `<= 2.x` еквівалентно `< 3` * `*` еквівалентно `>= 0.0.0` ### Порівняння діапазонів з тильдою (patch) {#tilde-range-comparisons-patch} Оператор порівняння тильди (`~`) використовується для діапазонів рівня патчу, коли вказана мінорна версія, і для змін на рівні основної версії, коли мінорний номер відсутній. Наприклад, * `~1.2.3` еквівалентно `>= 1.2.3, < 1.3.0` * `~1` еквівалентно `>= 1, < 2` * `~2.3` еквівалентно `>= 2.3, < 2.4` * `~1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` * `~1.x` еквівалентно `>= 1, < 2` ### Порівняння діапазонів з кареткою (major) {#caret-range-comparisons-major} Оператор порівняння каретка (`^`) використовується для змін на рівні основної версії після випуску стабільної (1.0.0) версії. До випуску 1.0.0 мінорні версії діють як рівень стабільності API. Це корисно при порівнянні версій API, оскільки велика зміна є порушенням API. Наприклад, * `^1.2.3` еквівалентно `>= 1.2.3, < 2.0.0` * `^1.2.x` еквівалентно `>= 1.2.0, < 2.0.0` * `^2.3` еквівалентно `>= 2.3, < 3` * `^2.x` еквівалентно `>= 2.0.0, < 3` * `^0.2.3` еквівалентно `>=0.2.3 <0.3.0` * `^0.2` еквівалентно `>=0.2.0 <0.3.0` * `^0.0.3` еквівалентно `>=0.0.3 <0.0.4` * `^0.0` еквівалентно `>=0.0.0 <0.1.0` * `^0` еквівалентно `>=0.0.0 <1.0.0` ## Функції URL {#url-functions} Helm включає функції [urlParse](#urlparse), [urlJoin](#urljoin) і [urlquery](#urlquery), які дозволяють працювати з частинами URL. ### urlParse Розбирає рядок для URL і створює словник з частинами URL ```go urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` Вищезазначене повертає словник, що містить обʼєкт URL: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Це реалізовано за допомогою пакетів URL з стандартної бібліотеки Go. Для отримання додаткової інформації перевірте https://golang.org/pkg/net/url/#URL ### urlJoin Обʼєднує словник (створений за допомогою `urlParse`) для створення рядка URL ```go urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` Вищезазначене поверне наступний рядок: ```go http://host:80/path?query#fragment ``` ### urlquery Повертає екрановану версію значення, переданого як аргумент, так що воно підходить для вбудовування в частину запиту URL. ```go $var := urlquery "string for query" ``` ## Функції UUID {#uuid-functions} Helm може генерувати UUID v4, унікальні ідентифікатори. ```go uuidv4 ``` Вищезазначене повертає новий UUID типу v4 (згенерований випадковим чином). ## Функції Kubernetes і Chart {#kubernetes-and-chart-functions} Helm включає функції для роботи з Kubernetes, зокрема [`.Capabilities.APIVersions.Has`](#capabilitiesapiversionshas), [Files](#file-functions) та [lookup](#lookup). ### lookup `lookup` використовується для пошуку ресурсу в працюючому кластері. При використанні з командою `helm template` він завжди повертає порожній результат. Більше деталей можна знайти в [документації по функції lookup](/chart_template_guide/functions_and_pipelines.mdx#using-the-lookup-function). ### .Capabilities.APIVersions.Has Повертає, чи доступна API-версія або ресурс у кластері. ```go .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Більше інформації доступно в [документації по вбудованих обʼєктах](/chart_template_guide/builtin_objects.md). ### Функції файлів {#file-functions} Є кілька функцій, які дозволяють отримати доступ до не-спеціальних файлів всередині chart. Наприклад, для доступу до конфігураційних файлів програми. Ці функції документовані в [Доступ до файлів всередині шаблонів](/chart_template_guide/accessing_files.md). _Зверніть увагу, що документація для багатьох з цих функцій надходить з [Sprig](https://github.com/Masterminds/sprig). Sprig — це бібліотека функцій шаблонів, доступна для застосунків на Go._ ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/functions_and_pipelines.mdx ================================================ --- title: Функції шаблонів та конвеєри description: Використання функцій у шаблонах. sidebar_position: 5 --- import Helm4 from "../_v4-in-progress.mdx" Дотепер ми бачили, як розміщувати інформацію в шаблоні. Але ця інформація розміщується в шаблоні без змін. Іноді ми хочемо перетворити надані дані таким чином, щоб вони були більш корисними для нас. Почнемо з найкращої практики: коли вставляємо рядки з об’єкта `.Values` у шаблон, ми повинні обов’язково обгорнути ці рядки в лапки. Ми можемо зробити це, викликавши функцію `quote` в директиві шаблону: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Функції шаблонів дотримуються синтаксису `functionName arg1 arg2...`. У наведеному вище фрагменті `quote .Values.favorite.drink` викликає функцію `quote` і передає їй один аргумент. Helm має понад 60 доступних функцій. Деякі з них визначені [мовою шаблонів Go](https://godoc.org/text/template). Більшість інших є частиною [бібліотеки шаблонів Sprig](https://masterminds.github.io/sprig/). Ми побачимо багато з них у міру того, як будемо розглядати приклади. > Хоча ми говоримо про "мову шаблонів Helm", як про щось специфічне для Helm, насправді це комбінація мови шаблонів Go, деяких додаткових функцій і різноманітних обгорток, які дозволяють передавати певні обʼєкти в шаблони. Багато ресурсів про шаблони Go можуть бути корисними, коли ви вивчаєте шаблони. ## Конвеєри {#pipelines} Однією з потужних функцій мови шаблонів є концепція _конвеєрів_. Запозичивши концепцію з UNIX, конвеєри є інструментом для обʼєднання серії команд шаблонів для компактного вираження низки перетворень. Іншими словами, конвеєри — це ефективний спосіб виконання кількох завдань послідовно. Перепишемо наведений вище приклад, використовуючи конвеєр. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` У цьому прикладі замість виклику `quote ARGUMENT` ми інвертували порядок. Ми "надіслали" аргумент функції за допомогою конвеєра (`|`): `.Values.favorite.drink | quote`. Використовуючи конвеєри, ми можемо обʼєднати кілька функцій: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Інверсія порядку є поширеною практикою в шаблонах. Ви частіше побачите `.val | quote`, ніж `quote .val`. Обидві практики є правильними. Під час обробки цей шаблон створить такий результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Зверніть увагу, що наша початкова `pizza` тепер перетворилася на `"PIZZA"`. Коли аргументи передаються за допомогою конвеєра, результат першого обчислення (`.Values.favorite.drink`) надсилається як _останній аргумент функції_. Ми можемо змінити приклад із напоєм вище, щоб продемонструвати функцію, яка приймає два аргументи: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` Функція `repeat` буде повторювати даний рядок задану кількість разів, тому ми отримаємо такий вихідний результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Використання функції `default` {#using-the-default-function} Однією з функцій, яку часто використовують у шаблонах, є функція `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Ця функція дозволяє вам вказати стандартне значення в шаблоні, у разі якщо значення відсутнє. Використаємо її, щоб змінити приклад з напоєм вище: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Якщо ми запустимо це як зазвичай, ми отримаємо наш `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Тепер ми видалимо параметр улюбленого напою з `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Тепер повторний запуск `helm install --dry-run --debug fair-worm ./mychart` створить такий YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` В реальній схемі всі статичні стандартні значення повинні зберігатися у файлі `values.yaml` і не повинні дублюватися за допомогою команди `default` (інакше вони будуть надлишковими). Однак команда `default` ідеально підходить для обчислюваних значень, які не можуть бути оголошені у файлі `values.yaml`. Наприклад: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` У деяких випадках умова `if` може бути кращим рішенням, ніж `default`. Ми побачимо їх у наступному розділі. Функції та конвеєри шаблонів — це потужний спосіб перетворення інформації та її вставки у ваш YAML. Але іноді необхідно додати деяку логіку шаблонів, яка трохи складніша, ніж просто вставка рядка. У наступному розділі ми розглянемо структури керування, які надає мова шаблонів. ## Використання функції `lookup` {#using-the-lookup-function} Функцію `lookup` можна використовувати для _пошуку_ ресурсів у працюючому кластері. Синопсис функції lookup — це `lookup apiVersion, kind, namespace, name -> resource or resource list`. | параметр | тип | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Як `name`, так і `namespace` є необовʼязковими і можуть бути передані як порожній рядок (`""`). Однак, якщо ви працюєте з ресурсом, що належить до простору імен, необхідно вказати як `name`, так і `namespace`. Можливі такі комбінації параметрів: | Поведінка | Функція пошуку | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Коли `lookup` повертає обʼєкт, він поверне словник. Цей словник може бути додатково досліджений для отримання конкретних значень. Наступний приклад поверне анотації, присутні для обʼєкта `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Коли `lookup` повертає список обʼєктів, можливо отримати доступ до списку обʼєктів через поле `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* робимо щось з кожним сервісом */}} {{ end }} ``` Коли обʼєкт не знайдено, повертається порожнє значення. Це може бути використано для перевірки наявності обʼєкта. Функція `lookup` використовує поточну конфігурацію зʼєднання Kubernetes Helm для запиту до Kubernetes. Якщо при взаємодії з викликом сервера API виникає помилка (наприклад, через відсутність дозволу на доступ до ресурсу), обробка шаблонів Helm зазнає невдачі. Майте на увазі, що Helm не призначений для контакту з Kubernetes API Server під час операцій `helm template|install|upgrade|delete|rollback --dry-run`. Щоб протестувати `lookup` на працюючому кластера, слід використовувати `helm template|install|upgrade|delete|rollback --dry-run=server`, щоб дозволити з’єднання з кластером. ## Оператори як функції {#operators-are-functions} Для шаблонів оператори (`eq`, `ne`, `lt`, `gt`, `and`, `or` і так далі) реалізовані як функції. У конвеєрах операції можуть бути згруповані дужками (`(` і `)`). Тепер ми можемо перейти від функцій і конвеєрів до управління потоком з умовами, циклами та модифікаторами області видимості. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/getting_started.md ================================================ --- title: Початок роботи description: Короткий посібник з шаблонів чартів sidebar_position: 2 --- У цьому розділі посібника ми створимо чарт і додамо перший шаблон. Чарт, який ми створимо тут, буде використовуватися протягом усього цього посібника. Щоб розпочати, давайте швидко ознайомимося з чартом Helm. ## Чарти {#charts} Як описано в [Посібнику з чартів](/topics/charts.mdx), чарти Helm мають таку структуру: ```none mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Тека `templates/` призначена для файлів шаблонів. Коли Helm обробляє чарт, він передає всі файли з теки `templates/` до механізму рендерингу шаблонів. Потім збирає результати цих шаблонів і передає їх до Kubernetes. Файл `values.yaml` також важливий для шаблонів. Цей файл містить _стандартні значення_ для чарту. Користувачі можуть перевизначити ці значення виконуючи `helm install` або `helm upgrade`. Файл `Chart.yaml` містить опис чарту. Ви можете отримати до нього доступ із шаблону. Тека `charts/` _може_ містити інші чарти (які ми називаємо _субчартами_). Пізніше в цьому посібнику ми побачимо, як вони працюють під час рендерингу шаблонів. ## Простий чарт {#a-starter-chart} У цьому посібнику ми створимо простий чарт з назвою `mychart`, а потім створимо кілька шаблонів всередині чарту. ```sh $ helm create mychart Creating mychart ``` ### Швидкий огляд `mychart/templates/` {#a-quick-glimpse-of-mycharttemplates} Якщо ви поглянете на теку `mychart/templates/`, то помітите кілька файлів, які вже там є. - `NOTES.txt`: Вміст тексту довідки для вашого чарту. Його буде показана користувачам під час виконання `helm install`. - `deployment.yaml`: Основний маніфест для створення [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) у Kubernetes. - `service.yaml`: Основний маніфест для створення [точки доступу сервісу](https://kubernetes.io/docs/concepts/services-networking/service/) для вашого deployment. - `_helpers.tpl`: Місце для розміщення допоміжних шаблонів, які ви можете використовувати повторно по всьому чарту. І що ми збираємося зробити, це… _видалити їх усі!_ Таким чином, ми зможемо працювати з нашим посібником з нуля. Ми фактично створимо власні `NOTES.txt` та `_helpers.tpl` під час роботи. ```sh $ rm -rf mychart/templates/* ``` Коли ви створюєте чарти промислового рівня, наявність базових версій цих чартів може бути дуже корисною. Тому під час щоденного створення чартів ви, ймовірно, не захочете їх видаляти. ## Перший шаблон {#a-first-template} Перший шаблон, який ми створимо, буде `ConfigMap`. У Kubernetes ConfigMap — це просто об'єкт для зберігання даних конфігурації. Інші об'єкти, наприклад, pods, можуть отримувати доступ до даних у ConfigMap. Оскільки ConfigMaps є базовими ресурсами, вони є для нас чудовою відправною точкою. Почнемо зі створення файлу з назвою `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` :::tip Імена шаблонів не підпорядковуються жорстким правилам іменування. Однак ми рекомендуємо використовувати розширення `.yaml` для файлів YAML і `.tpl` для допоміжних файлів. ::: Вищезазначений файл YAML є базовим ConfigMap, що містить мінімально необхідні поля. Оскільки цей файл знаходиться в теці `mychart/templates/`, він буде переданий до рушія шаблонів. Цей простий файл YAML можна розмістити в теці `mychart/templates/`. Коли Helm прочитає цей шаблон, він просто надішле його до Kubernetes у незмінному вигляді. Завдяки цьому простому шаблону ми тепер маємо чарт, який можна встановити. І ми можемо встановити його наступним чином: ```sh $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` За допомогою Helm ми можемо отримати реліз і побачити фактичний шаблон, який був завантажений. ```sh $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` Команда `helm get manifest` використовує імʼя релізу (`full-coral`) і виводить всі ресурси Kubernetes, які були завантажені на сервер. Кожен файл починається з `---`, що позначає початок документа YAML, а потім йде автоматично згенерований рядок коментаря, який повідомляє, який файл шаблону згенерував цей документ YAML. З цього моменту ми можемо побачити, що YAML-дані саме такі, як ми їх розмістили у файлі `configmap.yaml`. Тепер ми можемо видалити наш реліз: `helm uninstall full-coral`. ### Додавання простого виклику шаблону {#adding-a-simple-template-call} Жорстке кодування поля `name:` у ресурсі зазвичай вважається поганою практикою. Імена повинні бути унікальними для кожного релізу. Тому ми можемо захотіти згенерувати поле імені, вставивши назву релізу. :::info Поле `name:` обмежене 63 символами через обмеження системи DNS. З цієї причини імена релізів обмежені 53 символами. У Kubernetes версії 1.3 та раніше було обмежено лише 24 символами (тобто імена довжиною до 14 символів). ::: Змінимо файл `configmap.yaml` відповідно. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Основна зміна полягає в значенні поля `name:`, яке тепер має вигляд `{{ .Release.Name }}-configmap`. > Директива шаблону міститься у дужках `{{` та `}}`. Директива шаблону `{{ .Release.Name }}` вставляє назву релізу в шаблон. Значення, які передаються в шаблон, можна вважати _обʼєктами в просторах імен_, де точка (`.`) розділяє кожен елемент простору імен. Точка перед `Release` вказує, що ми починаємо з найвищого простору імен для цієї області застосування (про область ми поговоримо трохи пізніше). Таким чином, ми могли б прочитати `Release.Name` як: "почати з верхнього простору імен, знайти обʼєкт `Release`, а потім шукати всередині нього обʼєкт з назвою `Name`". Обʼєкт `Release` є одним із вбудованих обʼєктів для Helm, і ми розглянемо його більш детально пізніше. Але поки достатньо сказати, що це покаже назву релізу, яку бібліотека присвоює нашому релізу. Тепер, коли ми встановлюємо наш ресурс, ми одразу побачимо результат використання цієї директиви шаблону: ```sh $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Ви можете запустити `helm get manifest clunky-serval`, щоб побачити весь згенерований YAML. Зверніть увагу, що ConfigMap всередині Kubernetes має назву `clunky-serval-configmap`, а не `mychart-configmap`, як раніше. На цьому етапі ми розглянули найпростіші шаблони: файли YAML, що містять директиви шаблону, вкладені в `{{` та `}}`. У наступній частині ми детальніше розглянемо шаблони. Але перш ніж рухатися далі, є один швидкий трюк, який може пришвидшити створення шаблонів: якщо ви хочете протестувати рендеринг шаблону, але не встановлювати нічого, ви можете використати `helm install --debug --dry-run goodly-guppy ./mychart`. Ця команда рендерить шаблони. Але замість встановлення чарту, вона поверне вам опрацьований шаблон, щоб ви могли побачити результат: ```sh $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Використання `--dry-run` полегшить тестування вашого коду, але це не гарантує, що сам Kubernetes прийме згенеровані вами шаблони. Краще не припускати, що ваш чарт буде встановлений тільки тому, що `--dry-run` працює. У [Посібнику з шаблонів чарту](/chart_template_guide/index.mdx) ми розглянемо базовий чарт, який ми визначили тут, і детально дослідимо мову шаблонів Helm. І ми почнемо з вбудованих обʼєктів. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/helm_ignore_file.md ================================================ --- title: Файл .helmignore description: Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт. sidebar_position: 12 --- Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт. Якщо цей файл існує, команда `helm package` ігноруватиме всі файли, які відповідають шаблону, зазначеному у файлі `.helmignore`, під час упаковки вашого застосунку. Це може допомогти уникнути додавання непотрібних або конфіденційних файлів або тек у ваш Helm чарт. Файл `.helmignore` підтримує глобальне зіставлення оболонки Unix, зіставлення відносних шляхів та заперечення (з префіксом !). Враховується лише один шаблон на рядок. Ось приклад файлу `.helmignore`: ```none # коментар # Відповідає будь-якому файлу або шляху з імʼям .helmignore .helmignore # Відповідає будь-якому файлу або шляху з імʼям .git .git # Відповідає будь-якому текстовому файлу *.txt # Відповідає тільки текам з імʼям mydir mydir/ # Відповідає тільки текстовим файлам на верхньому рівні теки /*.txt # Відповідає тільки файлу foo.txt в теці верхнього рівня /foo.txt # Відповідає будь-якому файлу з імʼям ab.txt, ac.txt або ad.txt a[b-d].txt # Відповідає будь-якому файлу у субтеці subdir, що відповідає temp* */temp* */*/temp* temp? ``` Декілька важливих відмінностей від `.gitignore`: - Синтаксис '**' не підтримується. - Бібліотека globbing є Go's `filepath.Match`, а не `fnmatch(3)`. - Пробіли на кінці ігноруються завжди (немає підтримки екранованих послідовностей). - Немає підтримки '\!' як спеціальної початкової послідовності. - Файл `.helmignore` стандартно не виключає себе, потрібно додати явний запис для `.helmignore`. **Ми будемо вдячні за вашу допомогу** у покращенні цього документа. Щоб додати, виправити або видалити інформацію, [відкрийте тікет](https://github.com/helm/helm-www/issues) або надішліть нам запит на внесення змін. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/index.mdx ================================================ --- title: Шаблони чартів sidebar_position: 5 --- # Посібник розробника шаблонів чартів Цей посібник надає введення в шаблони чартів Helm, з акцентом на мову шаблонів. Шаблони генерують файли маніфестів, які є описами ресурсів у форматі YAML, зрозумілому для Kubernetes. Ми розглянемо, як побудовані шаблони, як їх можна використовувати, як створювати шаблони Go та як відлагоджувати свою роботу. Цей посібник зосереджується на таких поняттях: - Мова шаблонів Helm - Використання значень - Техніки роботи з шаблонами Цей посібник орієнтований на вивчення особливостей мови шаблонів Helm. Інші посібники надають вступні матеріали, приклади та найкращі практики. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/named_templates.md ================================================ --- title: Іменовані шаблони description: Як визначити іменовані шаблони. sidebar_position: 9 --- Пора перейти від одного шаблону до створення інших. У цьому розділі ми побачимо, як визначити _іменовані шаблони_ в одному файлі, а потім використовувати їх в інших місцях. _Іменований шаблон_ (іноді його називають _partial_ або _субшаблоном_) — це просто шаблон, визначений у файлі, якому надали імʼя. Ми розглянемо два способи створення таких шаблонів і кілька способів їх використання. У розділі [Керування потоком](/chart_template_guide/control_structures.md) ми представили три дії для оголошення та управління шаблонами: `define`, `template` і `block`. У цьому розділі ми розглянемо ці три дії, а також введемо спеціальну функцію `include`, яка працює подібно до дії `template`. Важлива деталь, яку слід памʼятати при іменуванні шаблонів: **імена шаблонів є глобальними**. Якщо ви оголосите два шаблони з однаковим імʼям, використовуватиметься той, який був завантажений останнім. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, слід бути обережним при іменуванні шаблонів, використовуючи _імена, специфічні для чарту_. Популярним способом іменування є префіксування кожного визначеного шаблону іменем чарту: `{{ define "mychart.labels" }}`. Використовуючи конкретне імʼя чарту як префікс, ми можемо уникнути будь-яких конфліктів, які можуть виникнути через два різних чарти, що реалізують шаблони з однаковим іменем. Ця поведінка також стосується різних версій чарту. Якщо у вас є `mychart` версії `1.0.0`, яка визначає шаблон одним способом, і `mychart` версії `2.0.0`, яка змінює наявний іменований шаблон, буде використовуватися той, який був завантажений останнім. Ви можете обійти цю проблему, додавши версію в імʼя чарту: `{{ define "mychart.v1.labels" }}` та `{{ define "mychart.v2.labels" }}`. ## Файли partials та `_` {#partials-and-_files} До цього часу ми використовували один файл, і цей один файл містив один шаблон. Але мова шаблонів Helm дозволяє створювати іменовані вкладені шаблони, до яких можна звертатися за іменем в інших місцях. Перед тим як перейти до деталей написання цих шаблонів, варто згадати про правила іменування файлів: * Більшість файлів у `templates/` обробляються як файли з маніфестами Kubernetes * `NOTES.txt` є винятком * Але файли, імʼя яких починається з підкреслення (`_`), вважаються такими, що _не мають_ маніфесту всередині. Ці файли не перетворюються на обʼєкти Kubernetes, але доступні в інших шаблонах чартів для використання. Ці файли використовуються для зберігання часток шаблонів і допоміжних функцій. Насправді коли ми вперше створили `mychart`, ми бачили файл з назвою `_helpers.tpl`. Цей файл є стандартним місцем для часток шаблонів. ## Оголошення та використання шаблонів з `define` та `template` {#declaring-and-using-templates-with-define-and-template} Дія `define` дозволяє створювати іменовані шаблони всередині файлу шаблону. Її синтаксис виглядає так: ```go {{- define "MY.NAME" }} # тіло шаблону тут {{- end }} ``` Наприклад, ми можемо визначити шаблон для інкапсуляції блоку міток Kubernetes: ```go {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Тепер ми можемо вбудувати цей шаблон всередині нашого наявного ConfigMap і включити його за допомогою дії `template`: ```go {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Коли рушій шаблонів читає цей файл, він зберігає посилання на `mychart.labels` до того часу, поки не буде викликано `template "mychart.labels"`. Тоді він рендерить цей шаблон безпосередньо. Результат виглядатиме так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` :::note `define` не створює виводу, якщо не буде викликано шаблон, як у цьому прикладі. ::: Зазвичай шаблони Helm розміщують у файлах часток шаблонів, зазвичай у `_helpers.tpl`. Перенесемо цю функцію туди: ```go {{/* Генерація базових міток */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Згідно з домовленостями, функції `define` повинні мати простий блок документації (`{{/* ... */}}`), що описує їх призначення. Навіть якщо це визначення знаходиться в `_helpers.tpl`, його все ще можна використовувати в `configmap.yaml`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Як уже згадувалося, **імена шаблонів є глобальними**. В результаті, якщо два шаблони оголошені з однаковим імʼям, буде використано останній варіант. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, краще давати шаблонам _специфічні для чарту імена_. Популярний спосіб іменування — це префіксувати кожен визначений шаблон іменем чарту: `{{ define "mychart.labels" }}`. ## Встановлення області видимості шаблону {#setting-the-scope-of-a-template} У шаблоні, який ми визначили вище, ми не використовували жодних обʼєктів. Ми просто використовували функції. Змінимо наш визначений шаблон, щоб включити назву чарту та версію чарту: ```go {{/* Генерація базових міток */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Якщо ми його відрендеримо, ми отримаємо помилку, схожу на цю: ```sh $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Щоб побачити, що було відрендерено, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат не буде таким, як ми очікували: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Що сталося з назвою та версією? Вони не були в області видимості для нашого визначеного шаблону. Коли іменований шаблон (створений за допомогою `define`) рендериться, він отримує область видимості, передану через виклик `template`. У нашому прикладі ми включили шаблон ось так: ```go {{- template "mychart.labels" }} ``` Область видимості не була передана, тому в шаблоні ми не можемо отримати доступ до чогось в `.`. Однак це легко виправити. Ми просто передаємо область видимості в шаблон: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Зверніть увагу, що ми передаємо `.` в кінці виклику `template`. Ми могли б так само легко передати `.Values` або `.Values.favorite`, або будь-яку іншу область видимості, яку хочемо. Але те, що нам потрібно, це область видимості верхнього рівня. Тепер, коли ми виконаємо цей шаблон з `helm install --dry-run --debug plinking-anaco ./mychart`, ми отримаємо таке: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Тепер `{{ .Chart.Name }}` стає `mychart`, а `{{ .Chart.Version }}` стає `0.1.0`. ## Функція `include` {#the-include-function} Припустимо, ми визначили простий шаблон, який виглядає ось так: ```go {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Тепер припустимо, я хочу вставити це як в розділ `labels:`, так і в розділ `data:`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Якщо ми це відрендеримо, ми отримаємо помилку, схожу на цю: ```sh $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Щоб побачити, що було відрендеровано, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Вихідні дані не будуть такими, як ми очікували: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Зверніть увагу, що відступ на `app_version` неправильний в обох місцях. Чому? Тому що шаблон, який вставляється, має текст вирівняний по лівому краю. Оскільки `template` є дією, а не функцією, немає способу передати вихідний результат виклику `template` іншим функціям; дані просто вставляються в рядок. Щоб обійти цю проблему, Helm надає альтернативу `template`, яка імплементує вміст шаблону в поточний конвеєр, де він може бути переданий іншим функціям у конвеєрі. Ось приклад вище, виправлений з використанням `indent`, щоб правильно відступити шаблон `mychart.app`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Тепер створений YAML має вірний відступ для кожного розділу: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Вважається за краще використовувати `include` замість `template` у шаблонах Helm, щоб краще керувати форматуванням виводу для YAML-документів. Іноді ми хочемо імплементувати вміст, але не як шаблони. Тобто, ми хочемо імплементувати файли без змін. Ми можемо досягти цього, звертаючись до файлів через обʼєкт `.Files`, описаний у наступному розділі. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/notes_files.md ================================================ --- title: Створення файлу NOTES.txt description: Як надати інструкції користувачам вашого чарту. sidebar_position: 10 --- У цьому розділі ми розглянемо інструмент Helm для надання інструкцій користувачам вашого чарту. Після виконання `helm install` або `helm upgrade` Helm може вивести блок корисної інформації для користувачів. Цю інформацію можна налаштувати за допомогою шаблонів. Щоб додати нотатки по установці до вашого чарту, просто створіть файл `templates/NOTES.txt`. Цей файл є звичайним текстовим файлом, але обробляється як шаблон і має всі звичайні функції та обʼєкти шаблонів. Створимо простий файл `NOTES.txt`: ```go Дякуємо за встановлення {{ .Chart.Name }}. Ваш реліз називається {{ .Release.Name }}. Щоб дізнатися більше про реліз, спробуйте: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Тепер, якщо ми виконаємо `helm install rude-cardinal ./mychart`, ми побачимо це повідомлення внизу: ```none RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Дякуємо за встановлення mychart. Ваш реліз називається rude-cardinal. Щоб дізнатися більше про реліз, спробуйте: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Використання `NOTES.txt` таким чином є чудовим способом надати вашим користувачам детальну інформацію про те, як використовувати новостворений чарт. Створення файлу `NOTES.txt` наполегливо рекомендується, хоча це і не є обовʼязковим. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Субчарти та глобальні значення description: Взаємодія з значеннями субчартів і глобальними значеннями. sidebar_position: 11 --- До цього моменту ми працювали тільки з одним чартом. Але чарти можуть мати залежності, які називаються _субчартами_, що також мають свої власні значення і шаблони. У цьому розділі ми створимо субчарт і розглянемо різні способи доступу до значень зсередини шаблонів. Перед тим, як перейти до коду, є кілька важливих деталей, які слід знати про субчарти: 1. Субчарт вважається "автономним", що означає, що субчарт ніколи не може прямо залежати від батьківського чарту. 2. Тому субчарт не може отримувати доступ до значень свого пращура. 3. Батьківський чарт може перевизначати значення для субчартів. 4. Helm має концепцію _глобальних значень_, які можуть бути доступні всім чартам. > Ці обмеження не завжди застосовуються до [бібліотечних чартів](/topics/library_charts.md), які розроблені для надання стандартної функціональності. Під час роботи з прикладами в цьому розділі ці концепції стануть зрозумілішими. ## Створення субчарту {#creating-a-subchart} Для цих вправ ми почнемо з чарту `mychart/`, який ми створили на початку цього посібника, і додамо новий чарт всередину його. ```sh $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Зверніть увагу, що ми видалили всі базові шаблони, щоб почати з нуля. У цьому посібнику ми зосереджені на тому, як працюють шаблони, а не на управлінні залежностями. Але [Посібник з Чартів](/topics/charts.mdx) містить більше інформації про те, як працюють субчарти. ## Додавання значень та шаблону до субчарту {#adding-values-and-a-template-to-the-subchart} Далі створимо простий шаблон і файл значень для чарту `mysubchart`. У `mychart/charts/mysubchart` вже має бути файл `values.yaml`. Налаштуємо його так: ```yaml dessert: cake ``` Далі створимо новий шаблон ConfigMap у `mychart/charts/mysubchart/templates/configmap.yaml`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Оскільки кожен субчарт є _самостіним чартом_, ми можемо протестувати `mysubchart` окремо: ```sh $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Перевизначення значень з батьківського чарту {#overriding-values-from-a-parent-chart} Наш оригінальний чарт, `mychart`, тепер є _батьківським_ чартом для `mysubchart`. Ці стосунки базується виключно на тому, що `mysubchart` знаходиться в `mychart/charts`. Оскільки `mychart` є батьківським чартом, ми можемо вказати конфігурацію в `mychart` і передати цю конфігурацію в `mysubchart`. Наприклад, ми можемо змінити `mychart/values.yaml` таким чином: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Зверніть увагу на останні два рядки. Будь-які директиви всередині секції `mysubchart` будуть передані в чарт `mysubchart`. Отже, якщо ми виконаємо `helm install --generate-name --dry-run --debug mychart`, однією з речей, які ми побачимо, буде ConfigMap `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` Значення на верхньому рівні тепер замінило значення субчарту. Тут слід звернути увагу на важливу деталь. Ми не змінювали шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, щоб він вказував на `.Values.mysubchart.dessert`. З точки зору цього шаблону, значення все ще знаходиться в `.Values.dessert`. Коли рушій шаблонів передає значення, він встановлює область дії. Тому для шаблонів `mysubchart` у `.Values` будуть доступні тільки значення, що стосуються конкретно `mysubchart`. Однак іноді ви хочете, щоб певні значення були доступні для всіх шаблонів. Це можна зробити за допомогою глобальних значень чартів. ## Глобальні значення чарту {#global-chart-values} Глобальні значення — це значення, до яких можна отримати доступ з будь-якого ччарту або субчарту за допомогою однакового імені. Глобальні значення вимагають явного оголошення. Ви не можете використовувати існуюче неглобальне значення так, ніби воно є глобальним. Тип даних Values має зарезервовану секцію `Values.global`, де можна задати глобальні значення. Визначимо одне в нашому файлі `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Завдяки способу роботи глобальних значень, як `mychart/templates/configmap.yaml`, так і `mysubchart/templates/configmap.yaml` повинні мати змогу отримати це значення як `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Тепер, якщо ми протестуємо установку в режимі dry run, ми побачимо одне й те ж значення в обох виводах: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Глобальні значення корисні для передачі такої інформації, хоча це вимагає певного планування, щоб переконатися, що правильні шаблони налаштовані для використання глобальних значень. ## Поширення шаблонів з субчартами {#sharing-templates-with-subcharts} Батьківські чарти та субчарти можуть ділитися шаблонами. Будь-який визначений блок у будь-якому чарті доступний іншим чартам. Наприклад, ми можемо визначити простий шаблон таким чином: ```go {{- define "labels" }}from: mychart{{ end }} ``` Згадайте, як мітки в шаблонах є _глобально спільними_. Отже, шаблон `labels` можна включити з будь-якого іншого чарту. Хоча розробники чартів можуть вибирати між `include` та `template`, однією з переваг використання `include` є те, що `include` може динамічно посилатися на шаблони: ```go {{ include $mytemplate }} ``` The above will dereference `$mytemplate`. The `template` function, in contrast, will only accept a string literal. ## Уникнення використання блоків {#avoid-using-blocks} Мова шаблонів Go надає ключове слово `block`, яке дозволяє розробникам надавати стандартну реалізацію, яка згодом замінюється. У чартах Helm блоки не є найкращим інструментом для заміни, оскільки якщо надано кілька реалізацій одного і того ж блоку, вибір конкретної реалізації є непередбачуваним. Замість цього рекомендується використовувати `include`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/values_files.mdx ================================================ --- title: Файли значень description: Інструкції щодо використання прапорця --values. sidebar_position: 4 --- import Helm4 from "../_v4-in-progress.mdx" У попередньому розділі ми розглянули вбудовані обʼєкти, які пропонують шаблони Helm. Один з вбудованих обʼєктів — це `Values`. Цей обʼєкт надає доступ до значень, переданих у шаблон. Його вміст походить з кількох джерел: - Файл `values.yaml` у чарті - Якщо це субчарт, файл `values.yaml` батьківського чарту - Файл значень передається в `helm install` або `helm upgrade` з прапорцем `-f` (`helm install -f myvals.yaml ./mychart`) - Окремі параметри передаються за допомогою `--set` (наприклад, `helm install --set foo=bar ./mychart`) Вищезазначений список наведений у порядку специфічності: `values.yaml` є стандартним, який може бути замінений файлом `values.yaml` батьківського чарту, який, у свою чергу, може бути замінений файлом значень, наданим користувачем, який, у свою чергу, може бути замінений параметрами `--set`. Файли значень є простими файлами YAML. Давайте відредагуємо `mychart/values.yaml`, а потім відредагуємо наш шаблон ConfigMap. Видаливши стандартні значення у `values.yaml`, ми встановимо лише один параметр: ```yaml favoriteDrink: coffee ``` Тепер ми можемо використовувати його всередині шаблону: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Зверніть увагу, що в останньому рядку ми отримуємо доступ до `favoriteDrink` як до атрибута `Values`: `{{ .Values.favoriteDrink }}`. Подивімося, як це відобразиться. ```sh $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Оскільки `favoriteDrink` встановлено в стандартне значення у файлі `values.yaml` як `coffee`, це значення відображається в шаблоні. Ми можемо легко перевизначити його, додавши прапорець `--set` у наш виклик `helm install`: ```sh $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Оскільки `--set` має вищий пріоритет, ніж файл `values.yaml`, наш шаблон генерує `drink: slurm`. Файли значень також можуть містити більш структурований контент. Наприклад, ми могли б створити розділ `favorite` у нашому файлі `values.yaml`, а потім додати туди кілька ключів: there: ```yaml favorite: drink: coffee food: pizza ``` Тепер нам потрібно трохи змінити шаблон: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Хоча структурування даних таким чином є можливим, рекомендується зберігати дерева значень неглибокими, віддаючи перевагу пласким структурам. Коли ми розглянемо присвоєння значень субчартам, ми побачимо, як значення називаються, використовуючи структуру дерева. ## Видалення стандартного ключа {#deleting-a-default-key} Якщо вам потрібно видалити ключ зі стандартних значень, ви можете перевизначити значення ключа як `null`, у цьому випадку Helm видалить ключ з злиття перевизначених значень. Наприклад, стабільний шаблон Drupal дозволяє налаштовувати перевірку життєздатності (liveness probe) у випадку, якщо ви налаштовуєте власний образ. Ось стандартні значення: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Якщо ви спробуєте перевизначити обробник livenessProbe на `exec` замість `httpGet`, використовуючи `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm обʼєднає стандартні ключі разом з перевизначеними, що дасть нам наступний YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Однак Kubernetes тоді видасть помилку, оскільки не можна оголошувати більше одного обробника livenessProbe. Щоб це обійти, ви можете інструктувати Helm видалити `livenessProbe.httpGet`, встановивши його значення в null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` На цьому етапі ми розглянули кілька вбудованих обʼєктів і використали їх для вставки інформації в шаблон. Тепер ми розглянемо інший аспект рушія шаблонів: функції та конвеєри. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/variables.md ================================================ --- title: Змінні description: Використання змінних у шаблонах. sidebar_position: 8 --- Маючи функції, конвеєри, обʼєкти та структури управління, ми можемо перейти до однієї з основних ідей у багатьох мовах програмування: змінних. У шаблонах вони використовуються рідше. Але ми побачимо, як їх можна використовувати для спрощення коду та для кращого використання `with` і `range`. У попередньому прикладі ми побачили, що цей код не працює: ```go {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` не знаходиться в межах області видимості, обмеженої блоком `with`. Один зі способів обійти проблеми з областю видимості — присвоїти обʼєкти змінним, до яких можна отримати доступ без врахування поточної області видимості. У шаблонах Helm змінна є іменованим посиланням на інший обʼєкт. Вона має формат `$name`. Змінні присвоюються за допомогою спеціального оператора присвоєння: `:=`. Ми можемо переписати вищезазначене, використовуючи змінну для `Release.Name`. ```go apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Зверніть увагу, що перед тим як почати блок `with`, ми присвоюємо `$relname := .Release.Name`. Тепер всередині блоку `with` змінна `$relname` все ще вказує на імʼя релізу. Запуск цього коду дасть наступний результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Змінні особливо корисні в циклах `range`. Їх можна використовувати для спископодібних обʼєктів, щоб захопити як індекс, так і значення: ```go toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Зверніть увагу, що `range` йде першим, потім змінні, потім оператор присвоєння, а потім список. Це присвоїть ціле число (починаючи з нуля) змінній `$index` і значення змінній `$topping`. Запуск цього коду дасть: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Для структур даних, які мають як ключ, так і значення, ми можемо використовувати `range`, щоб отримати обидва. Наприклад, ми можемо перебрати `.Values.favorite` таким чином: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Тепер на першій ітерації `$key` буде `drink`, а `$val` буде `coffee`, а на другій `$key` буде `food`, а `$val` буде `pizza`. Запуск цього коду створить: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Змінні зазвичай не є "глобальними". Вони мають область видимості в межах блоку, в якому вони оголошені. Раніше ми присвоїли `$relname` на верхньому рівні шаблону. Ця змінна буде видима для всього шаблону. Але в нашому останньому прикладі змінні `$key` і `$val` будуть видимі лише всередині блоку `{{ range... }}{{ end }}`. Однак є одна змінна, яка завжди є глобальною — `$`, ця змінна завжди буде вказувати на кореневий контекст. Це може бути дуже корисно, коли ви перебираєте в діапазоні і вам потрібно знати імʼя релізу чарту. Приклад, що ілюструє це: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Багато шаблонів Helm використовували б `.` тут, але це не спрацює, # однак `$` спрацює тут app.kubernetes.io/name: {{ template "fullname" $ }} # Я не можу звертатися до .Chart.Name, але можу використовувати $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Значення з appVersion у Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` До цього часу ми розглянули лише один шаблон, оголошений в одному файлі. Але одна з потужних можливостей мови шаблонів Helm — це можливість оголошувати кілька шаблонів і використовувати їх разом. Ми перейдемо до цього в наступному розділі. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/wrapping_up.md ================================================ --- title: Наступні кроки description: "Підсумок — корисні вказівки на іншу документацію, яка може допомогти вам." sidebar_position: 14 --- Цей посібник призначений для того, щоб дати вам, розробнику чартів, глибоке розуміння того, як використовувати мову шаблонів Helm. Посібник зосереджується на технічних аспектах розробки шаблонів. Однак є багато речей, які цей посібник не охоплює, коли йдеться про практичну щоденну розробку чартів. Ось кілька корисних посилань на іншу документацію, яка допоможе вам під час створення нових чартів: - CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є незамінним джерелом чартів. - [Документація Kubernetes](https://kubernetes.io/docs/home/) надає детальні приклади різних ресурсів, які ви можете використовувати, від ConfigMaps і Secrets до DaemonSets і Deployments. - Посібник [Чарти Helm](/topics/charts.mdx) пояснює робочий процес використання чартів. - Посібник [Хуки чартів Helm](/topics/charts_hooks.md) пояснює, як створювати хуки життєвого циклу. - Стаття [Поради та підказки для розробки чартів](/howto/charts_tips_and_tricks.md) надає кілька корисних порад для написання чартів. - Документація [Sprig](https://github.com/Masterminds/sprig) описує більше ніж шістдесят функцій шаблонів. - Документація [Go templates](https://godoc.org/text/template) детально пояснює синтаксис шаблонів. - Інструмент [Schelm](https://github.com/databus23/schelm) є корисною утилітою для налагодження чартів. Іноді легше поставити кілька запитань і отримати відповіді від досвідчених розробників. Найкраще місце для цього — канали Helm у [Slack Kubernetes](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Нарешті, якщо ви знайдете помилки або упущення в цьому документі, хочете запропонувати новий контент або хотіли б внести зробити внесок, відвідайте [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/chart_template_guide/yaml_techniques.md ================================================ --- title: "Додаток: Техніки YAML" description: Ближчий погляд на специфікацію YAML та її застосування в Helm. sidebar_position: 15 --- Більшість цього посібника зосереджена на мові шаблонів. Тут ми розглянемо формат YAML. YAML має кілька корисних функцій, які ми, як автори шаблонів, можемо використовувати для того, щоб зробити наші шаблони менш схильними до помилок і легшими для читання. ## Масиви та Колекції {#scalars-and-collections} Згідно зі [специфікацією YAML](https://yaml.org/spec/1.2/spec.html), існують два типи колекцій та багато типів скалярів. Два типи колекцій — це map та послідовності: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Скалярні значення – це окремі значення (на відміну від колекцій). ### Типи скалярів у YAML {#scalar-types-in-yaml} У діалекті YAML від Helm тип скалярних даних значення визначається складною сукупністю правил, включаючи схему Kubernetes для визначень ресурсів. Але при виведенні типів, як правило, діють наступні правила. Якщо ціле число або число з рухомою комою є словом без лапок, воно зазвичай розглядається як числовий тип: ```yaml count: 1 size: 2.34 ``` Але якщо вони укладені в лапки, вони трактуються як рядки: ```yaml count: "1" # <-- рядок, не int size: '2.34' # <-- рядок, не float ``` Те ж саме стосується булевих значень: ```yaml isGood: true # bool answer: "true" # рядок ``` Слово для порожнього значення — `null` (не `nil`). Зверніть увагу, що `port: "80"` є дійсним YAML і пройде через рушій шаблонів та парсер YAML, але зазнає невдачі, якщо Kubernetes очікує, що `port` буде цілим числом. У деяких випадках ви можете примусово визначити певний тип, використовуючи теґи вузлів YAML: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` У наведеному вище прикладі `!!str` говорить парсеру, що `age` є рядком, навіть якщо він виглядає як int. А `port` трактуватиметься як int, навіть якщо він укладений в лапки. ## Рядки в YAML {#strings-in-yaml} Більшість даних, які ми розміщуємо в документах YAML, є рядками. YAML має кілька способів представлення рядків. Цей розділ пояснює способи та демонструє, як використовувати деякі з них. Існують три "вбудовані" способи оголошення рядка: ```yaml way1: просто слова way2: "рядки в подвійних лапках" way3: 'рядки в одинарних лапках' ``` Всі вбудовані стилі мають бути в одному рядку. - Невкладені слова не мають лапок і не екрановані. Тому потрібно бути обережним із символами, які ви використовуєте. - Рядки в подвійних лапках можуть мати спеціальні символи екрановані за допомогою `\`. Наприклад, `"\"Hello\", she said"`. Можна екранувати розриви рядка за допомогою `\n`. - Рядки в одинарних лапках є "літеральними" рядками та не використовують `\` для екранування символів. Єдине екранування — це `''`, яке декодується як один символ `'`. Окрім рядків в один рядок, можна оголосити багаторядкові рядки: ```yaml coffee: | Latte Cappuccino Espresso ``` Вищенаведене буде трактувати значення `coffee` як один рядок, еквівалентний `Latte\nCappuccino\nEspresso\n`. Зверніть увагу, що перший рядок після `|` повинен мати вірний відступ. Тому ми можемо зламати приклад вище, зробивши це: ```yaml coffee: | Latte Cappuccino Espresso ``` Оскільки `Latte` має неправильний відступ, ми отримаємо помилку на кшталт: ```none Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` У шаблонах іноді безпечніше помістити несправжній "перший рядок" у багаторядковому документі лише для захисту від цієї помилки: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Зауважте, що яким би не був цей перший рядок, його буде збережено у виведенні рядка. Тому, якщо ви, наприклад, використовуєте цю техніку для вливання вмісту файлу в ConfigMap, коментар має бути типу, який очікується тим, хто читає цей запис. ### Керування пробілами в багаторядкових рядках {#controlling-spaces-in-multiline-strings} У наведеному вище прикладі ми використовували `|`, щоб позначити багаторядковий рядок. Але зверніть увагу, що вміст нашого рядка завершувався з кінцевим `\n`. Якщо ми хочемо, щоб обробник YAML видалив кінцевий перенос рядка, ми можемо додати `-` після `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Тепер значення `coffee` буде: `Latte\nCappuccino\nEspresso` (без кінцевого `\n`). В інших випадках ми можемо захотіти зберегти весь кінцевий пробіл. Ми можемо зробити це за допомогою позначення `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Тепер значення `coffee` буде `Latte\nCappuccino\nEspresso\n\n\n`. Відступи всередині текстового блоку зберігаються, що призводить до збереження переносу рядків: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` У наведеному вище випадку значення `coffee` буде `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Відступи та шаблони {#indenting-and-templates} Коли ви пишете шаблони, ви можете захотіти вставити вміст файлу в шаблон. Як ми бачили в попередніх розділах, є два способи зробити це: - Використовуйте `{{ .Files.Get "FILENAME" }}`, щоб отримати вміст файлу в чартах. - Використовуйте `{{ include "TEMPLATE" . }}`, щоб відобразити шаблон, а потім вставити його вміст у чарти. Коли ви вставляєте файли в YAML, корисно розуміти правила багаторядкових рядків. Найчастіше найпростіший спосіб вставити статичний файл — зробити щось на кшталт цього: ```go myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Зверніть увагу, як ми робимо відступ вище: `indent 2` вказує рушію шаблонів зробити відступ у два пробіли в кожному рядку файлу «myfile.txt». Зверніть увагу, що ми не робимо відступ у цьому рядку шаблону. Це тому, що якщо ми це зробимо, вміст першого рядка файлу буде відступлений двічі. ### Згортання багаторядкових рядків {#folded-multi-line-strings} Іноді вам потрібно представити рядок у вашому YAML на кількох рядках, але ви хочете, щоб він трактувався як один довгий рядок під час інтерпретації. Це називається "згортанням". Щоб оголосити згортання блоку, використовуйте `>` замість `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` Значення `coffee` буде `Latte Cappuccino Espresso\n`. Зверніть увагу, що всі, крім останнього переносу рядка, будуть перетворені на пробіли. Ви можете поєднувати контроль пробілів із позначкою згортання тексту, тому `>-` замінить або обрізає всі нові рядки. Зверніть увагу, що в згортанні синтаксису відступ тексту призведе до збереження рядків. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Наведене вище створить `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Зверніть увагу, що і пробіли, і нові рядки все ще присутні. ## Вбудовування кількох документів в один файл {#embedding-multiple-documents-in-one-file} Можливо розмістити більше одного YAML-документа в одному файлі. Це робиться шляхом префіксації нового документа `---` і закінчення документа `...` ```yaml --- document: 1 ... --- document: 2 ... ``` У багатьох випадках можна опустити `---` або `...`. Деякі файли в Helm не можуть містити більше одного документа. Якщо, наприклад, у файлі `values.yaml` надано більше одного документа, буде використано лише перший. Однак файли шаблонів можуть мати більше одного документа. Коли це трапляється, файл (і всі його документи) обробляється як один обʼєкт під час рендерингу шаблонів. Але потім отриманий YAML розділяється на кілька документів, перш ніж він буде переданий Kubernetes. Ми рекомендуємо використовувати кілька документів у файлі лише в разі крайньої потреби. Наявність кількох документів у файлі може ускладнити налагодження. ## YAML є надмножиною JSON {#yaml-is-a-superset-of-json} Оскільки YAML є надмножиною JSON, будь-який дійсний JSON-документ _повинен_ бути дійсним YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Вищенаведене є іншим способом представлення цього: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` І їх можна змішувати (з обережністю): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Усі три повинні перетворюватись в однакове внутрішнє подання. Це означає, що файли, такі як `values.yaml`, можуть містити дані JSON, але Helm не трактує розширення файлу `.json` як дійсний суфікс. ## Якорі YAML {#yaml-anchors} Специфікація YAML надає спосіб зберігати посилання на значення і пізніше посилатися на це значення за допомогою посилання. YAML називає це "якорінням":g": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` У наведеному вище прикладі `&favoriteCoffee` встановлює посилання на `Cappuccino`. Пізніше це посилання використовується як `*favoriteCoffee`. Таким чином, `coffees` стає `Latte, Cappuccino, Espresso`. Хоча є кілька випадків, коли якорі корисні, існує один аспект їх використання, який може спричинити тонкі помилки: під час першого використання YAML посилання розширюється і потім видаляється. Тому, якщо ми декодуємо і потім повторно кодуємо приклад вище, отриманий YAML буде таким: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Оскільки Helm і Kubernetes часто читають, змінюють і потім переписують файли YAML, якорі будуть втрачені. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/faq/index.mdx ================================================ --- title: Часті питання sidebar_position: 9 --- # Часті питання > В цьому розділі містяться відповіді на поширені запитання. **Ми будемо вдячні за вашу допомогу** у покращенні цього документу. Щоб додати, виправити або видалити інформацію, [створіть тікет](https://github.com/helm/helm-www/issues) або надішліть нам пул-реквест. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/faq/installing.mdx ================================================ --- title: Встановлення sidebar_position: 2 --- import Helm4 from "../_v4-in-progress.mdx" ## Встановлення {#installing} ### Чому немає нативних пакетів Helm для Fedora та інших дистрибутивів Linux? {#why-arent-there-native-packages-of-helm-for-fedora-and-other-linux-distros} Проєкт Helm не підтримує пакети для операційних систем та середовищ. Спільнота Helm може надавати нативні пакети, і якщо проєкт Helm дізнається про них, вони будуть внесені до списку. Саме так було започатковано та внесено до списку формулу Homebrew. Якщо ви зацікавлені в підтримці пакета, ми будемо раді. ### Чому ви надаєте скрипт `curl ...|bash`? {#why-do-you-provide-a-curl-bash-script} У нашому репозиторії є скрипт (`scripts/get-helm-3`), який можна виконати як скрипт `curl ..|bash`. Передача захищена HTTPS, а скрипт проводить деякий аудит пакетів, які він завантажує. Проте скрипт має всі звичайні небезпеки будь-якого скрипта оболонки. Ми надаємо його, тому що це корисно, але ми радимо користувачам ретельно ознайомитися зі скриптом перед виконанням. Те, що ми насправді хотіли б, — це кращі упаковані релізи Helm. ### Як мені помістити файли клієнта Helm в інше місце, не стандартне місце? {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults} Helm використовує структуру XDG для зберігання файлів. Існують змінні середовища, які ви можете використовувати для зміни цих місць: - `$XDG_CACHE_HOME`: встановіть альтернативне місце для зберігання кешованих файлів. - `$XDG_CONFIG_HOME`: встановіть альтернативне місце для зберігання конфігурацій Helm. - `$XDG_DATA_HOME`: встановіть альтернативне місце для зберігання даних Helm. Зверніть увагу, що якщо у вас є наявні репозиторії, вам доведеться повторно їх додати за допомогою `helm repo add...`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/faq/uninstalling.mdx ================================================ --- title: Видалення sidebar_position: 3 --- import Helm4 from "../_v4-in-progress.mdx" ## Видалення {#uninstalling} ### Я хочу видалити свій локальний Helm. Де зберігаються всі його файли? {#i-want-to-delete-my-local-helm-where-are-all-its-files} Разом з бінарним файлом `helm`, Helm зберігає деякі файли в наступних розташуваннях: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME Наступна таблиця показує стандартні теки для кожного з цих розташувань, за операційними системами: | Операційна система | Шлях до кешу | Шлях до конфігурацій | Шлях до даних | |--------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/glossary/index.mdx ================================================ --- title: Глосарій description: Терміни, які використовуються для опису компонентів архітектури Helm. sidebar_position: 10 --- # Глосарій import Helm4 from "../_v4-in-progress.mdx" ## Чарт {#chart} Пакет Helm, що містить інформацію, достатню для встановлення набору ресурсів Kubernetes у кластер Kubernetes. Чарти містять файл `Chart.yaml`, а також шаблони, стандартні значення (`values.yaml`) та залежності. Чарти створюються у чітко визначеній структурі тек, а потім упаковуються в архів, який називається _архів чарту_. ## Архів чарту {#chart-archive} _Архів чарту_ — це архів у форматі tar та gzip (та підписом, за бажанням). ## Залежності чартів (субчарти) {#chart-dependency-subcharts} Чарти можуть залежати від інших чартів. Існує два типи залежностей: - Мʼякі залежності: чарт може просто не працювати без іншого чарту, встановленого в кластері. Helm не надає інструментів для цього випадку. У цьому випадку залежності можна керувати окремо. - Жорсткі залежності: чарт може містити (у своїй теці `charts/`) інший чарт, від якого він залежить. У цьому випадку під час встановлення чарту будуть встановлені всі його залежності. У цьому випадку чарт і його залежності управляються як колекція. Коли чарт упаковується (за допомогою `helm package`), всі його жорсткі залежності додаються до нього. ## Версія чарту {#chart-version} Чарти версіонуються відповідно до [специфікації SemVer 2](https://semver.org). Номер версії обовʼязково вказується у кожному чарті. ## Chart.yaml Інформація про чарт зберігається в спеціальному файлі з назвою `Chart.yaml`. Кожен чарт повинен мати цей файл. ## Helm (та helm) {#helm-and-helm} Helm — це менеджер пакетів для Kubernetes. Так само, як менеджер пакетів операційної системи спрощує встановлення інструментів в ОС, Helm спрощує встановлення застосунків та ресурсів у кластерах Kubernetes. Хоча _Helm_ — це назва проєкту, клієнт командного рядка також називається `helm`. За домовленістю, коли йдеться про проєкт, _Helm_ пишеться з великої літери. Коли йдеться про клієнта, _helm_ пишеться з малої літери. ## Файли конфігурації Helm (XDG) {#helm-configuration-files-xdg} Helm зберігає свої файли конфігурації в теках XDG. Ці теки створюються під час першого запуску `helm`. ## Kube Config (KUBECONFIG) {#kube-config-kubeconfig} Клієнт Helm отримує інформацію про кластери Kubernetes за допомогою файлів у форматі _Kube config_. Стандартно Helm намагається знайти цей файл у місці, де його створює `kubectl` (`$HOME/.kube/config`). ## Lint (Перевірка) {#lint-linting} _Lint_ чартів означає перевірку їх відповідності стандартам і вимогам Helm chart. Helm надає інструменти для цього, зокрема команду `helm lint`. ## Походження (файл походження) {#provenance-provenance-file} До чартів Helm може додаватися файл походження, який містить інформацію про походження чарту та його вміст. Файли походження є частиною системи безпеки Helm. Походження містить криптографічний хеш файлу архіву чарта, дані Chart.yaml та блок підпису (блок OpenPGP «clearsign»). У поєднанні з ланцюжком ключів це надає користувачам чартів можливість: - Перевірити, чи чарт було підписано довіреною стороною - Перевірити, чи файл чарту не було підроблено - Перевірити вміст метаданих чарту (`Chart.yaml`) - Швидко порівняти чарт з даними про його походження Файли provenance мають розширення `.prov` і можуть бути надані з сервера репозиторію чартів або будь-якого іншого HTTP-сервера. ## Release Коли чарт встановлено, бібліотека Helm створює _release_ для відстеження цього встановлення. Один чарт може бути встановлений багато разів в одному кластері і може створити багато різних релізів. Наприклад, можна встановити три бази даних PostgreSQL, тричі запустивши `helm install` з різними іменами релізів. ## Номер релізу (версія релізу) {#release-number-release-version} Один реліз може бути оновлений кілька разів. Для відстеження змін у релізах використовується послідовний лічильник. Після першого `helm install` реліз матиме _номер релізу_ 1. Кожного разу, коли реліз оновлюється або відкочується, номер релізу збільшується. ## Відкат {#rollback} Реліз можна оновити до нової версії або конфігурації. Але оскільки історія релізів зберігається, реліз також можна повернути до попереднього номера релізу. Це робиться за допомогою команди `helm rollback`. Важливо, що повернений реліз отримає новий номер релізу. | Операція | Номер релізу | |------------|---------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (але з тією ж конфігурацією, що і у версії 1) | У таблиці вище показано, як збільшуються номери релізів під час встановлення, оновлення та відкату. ## Бібліотека Helm (або SDK) {#helm-library-or-sdk} Бібліотека Helm (або SDK) — це код Go, який безпосередньо взаємодіє з сервером API Kubernetes для встановлення, оновлення, запиту та видалення ресурсів Kubernetes. Її можна імпортувати в проєкт, щоб використовувати Helm як клієнтську бібліотеку замість CLI. ## Репозиторій (Repo, Chart Repository) {#repository-repo-chart-repository} Helm-чарти можуть зберігатися на спеціальних HTTP-серверах, які називаються _репозиторіями чартів_ (_репозиторіями_ або просто _репозиторіями_). Сервер репозиторію чарту — це простий HTTP-сервер, здатний обробляти файл `index.yaml`, що описує набір чартів і надає інформацію про те, звідки можна завантажити кожен чарт. (Багато репозиторіїв чартів підтримують як чарти, так і файл `index.yaml`.) Клієнт Helm може вказувати на нуль або більше репозиторіїв чартів. Стандартно клієнти Helm не налаштовані на жодні репозиторії чартів. Репозиторії чартів можна додати в будь-який час за допомогою команди `helm repo add`. ## Реєстр чартів (реєстр OCI) {#chart-registry-oci-based-registry} Реєстр чартів Helm — це система зберігання та розподілу на основі [OCI](https://opencontainers.org/about/overview/), яка використовується для розміщення та обміну пакетами чартів Helm. Докладнішу інформацію див. у [документації Helm про реєстри](https://helm.sh/docs/topics/registries/). ## Значення (файли значень, values.yaml) {#values-values-files-valuesyaml} Значення дають змогу замінити стандартні значення шаблону вашою власною інформацією. Чарти Helm є «параметризованими», що означає, що розробник чарту може надати конфігурацію, яку можна замінити під час встановлення. Наприклад, чарт може надати поле `username`, яке дозволяє встановити імʼя користувача для сервісу. Ці доступні змінні в термінології Helm називаються _values_. Значення можна встановити під час операцій `helm install` та `helm upgrade`, або шляхом їх прямого введення, або за допомогою файлу `values.yaml`. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm.md ================================================ --- title: helm slug: helm --- Менеджер пакетів Helm для Kubernetes. ### Опис {#synopsis} Менеджер пакетів для Kubernetes Загальні дії для Helm: - helm search: пошук чартів - helm pull: завантаження чарту у вашу локальну теку для перегляду - helm install: завантаження чарту в Kubernetes - helm list: перегляд списку релізів чартів Змінні середовища: | Імʼя | Опис | |------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | вказує альтернативне місце для зберігання кешованих файлів. | | $HELM_CONFIG_HOME | вказує альтернативне місце для зберігання конфігурації Helm. | | $HELM_DATA_HOME | sвказує альтернативне місце для зберігання даних Helm. | | $HELM_DEBUG | вказує, чи працює Helm в режимі налагодження. | | $HELM_DRIVER | вказує драйвер бекенду для зберігання. Значення: configmap, secret, memory, sql.. | | $HELM_DRIVER_SQL_CONNECTION_STRING | визначає рядок зʼєднання, який повинен використовувати драйвер сховища SQL. | | $HELM_MAX_HISTORY | вказує максимальну кількість історії релізів Helm. | | $HELM_NAMESPACE | вказує простір імен, що використовується для операцій Helm. | | $HELM_NO_PLUGINS | відключає втулки. Встановіть HELM_NO_PLUGINS=1, щоб відключити втулки. | | $HELM_PLUGINS | вказує шлях до теки втулків. | | $HELM_REGISTRY_CONFIG | вказує шлях до файлу конфігурації реєстру. | | $HELM_REPOSITORY_CACHE | вказує шлях до теки кешу репозиторіїв. | | $HELM_REPOSITORY_CONFIG | вказує шлях до файлу репозиторіїв. | | $KUBECONFIG | вказує альтернативний файл конфігурації Kubernetes (стандартно "~/.kube/config") | | $HELM_KUBEAPISERVER | вказує точку доступу сервера API Kubernetes для автентифікації. | | $HELM_KUBECAFILE | вказує файл центру сертифікації для Kubernetes. | | $HELM_KUBEASGROUPS | вказує групи для використання імперсонації, використовуючи список, розділений комами. | | $HELM_KUBEASUSER | вказує імʼя користувача для імперсонації під час операції. | | $HELM_KUBECONTEXT | вказує імʼя контексту kubeconfig. | | $HELM_KUBETOKEN | вказує токен Bearer KubeToken для автентифікації. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | вказує, чи слід пропустити перевірку сертифіката сервера API Kubernetes (небезпечний режим). | | $HELM_KUBETLS_SERVER_NAME | вказує імʼя сервера для перевірки сертифіката сервера API Kubernetes. | | $HELM_BURST_LIMIT | вказує стандартне обмеження на кількість викликів у випадку великої кількості CRD (стандартно — 100, -1 для відключення) | | $HELM_QPS | вказує кількість запитів в секунду (Queries Per Second — QPS) у випадках, коли велика кількість викликів перевищує параметр для більш високих значень. | | $HELM_COLOR | встановлює режим кольорового виводу. Допустимі значення: never, always, auto (стандартно: never) | | $NO_COLOR | встановлює будь-яке непорожнє значення, щоб вимкнути будь-який кольоровий вивід (перевизначає $HELM_COLOR) | Helm зберігає кеш, конфігурацію та дані відповідно до наступного порядку конфігурації: - Якщо встановлено змінну середовища HELM_*_HOME, вона буде використовуватися - В іншому випадку, в системах, що підтримують специфікацію базової теки XDG, будуть використовуватися змінні XDG - Якщо не встановлено інше місце розташування, буде використовуватися стандартне місце розташування, залежно від операційної системи Типово, стандартні теки залежать від операційної системи. Нижче наведені їх значення: | Операційна система | Шлях до кешу | Шлях до конфігурації | Шлях до даних | |--------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Параметри {#options} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід -h, --help довідка helm --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки * [helm create](/helm/helm_create.md) — створення нового чарта з вказаною назвою * [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта * [helm env](/helm/helm_env.md) — інформація про середовище клієнта helm * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз * [helm history](/helm/helm_history.md) — отримання історії релізу * [helm install](/helm/helm_install.md) — встановлення чарту * [helm lint](/helm/helm_lint.md) — перевірка чарту на предмет можливих проблем * [helm list](/helm/helm_list.md) — отримати перелік релізів * [helm package](/helm/helm_package.md) — упакувати теку чарту в архів чарту * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm * [helm pull](/helm/helm_pull.md) — завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальній теці * [helm push](/helm/helm_push.md) — завантажити чарт до віддаленого сервера * [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів * [helm rollback](/helm/helm_rollback.md) — відкотити реліз до попередньої версії * [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах * [helm show](/helm/helm_show.md) — показати інформацію про чарт * [helm status](/helm/helm_status.md) — показати статус зазначеного релізу * [helm template](/helm/helm_template.md) — локально рендерити шаблони * [helm test](/helm/helm_test.md) — запустити тести для релізу * [helm uninstall](/helm/helm_uninstall.md) — видалити реліз * [helm upgrade](/helm/helm_upgrade.md) — оновити реліз * [helm verify](/helm/helm_verify.md) — перевірити, чи підписаний та, чи є дійсним чарт за вказаним шляхом * [helm version](/helm/helm_version.md) — показати інформацію про версію helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion.md ================================================ --- title: helm completion --- Генерація скриптів автодоповнення для вказаної оболонки ### Опис {#synopsis} Генерація скриптів автодоповнення Helm для вказаної оболонки. ### Параметри {#options} ```none -h, --help довідка completion ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) — скрипт автодоповнення для bash * [helm completion fish](/helm/helm_completion_fish.md) — скрипт автодоповнення для fish * [helm completion powershell](/helm/helm_completion_powershell.md) — скрипт автодоповнення для powershell * [helm completion zsh](/helm/helm_completion_zsh.md) — скрипт автодоповнення для zsh ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- Генерація скрипта автодоповнення для bash ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для shell bash. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell source <(helm completion bash) ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: Linux: ```shell helm completion bash > /etc/bash_completion.d/helm ``` - MacOS: ```shell helm completion bash > /usr/local/etc/bash_completion.d/helm ``` ```shell helm completion bash [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка bash --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- Генерація скрипта автодоповнення для fish ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для shell fish. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell helm completion fish | source ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: ```shell helm completion fish > ~/.config/fish/completions/helm.fish ``` Потрібно запустити нову shell-сесію, щоб ці налаштування набули чинності. ```shell helm completion fish [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка fish --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- Генерація скрипта автодоповнення для powershell ### Опис {#synopsis} Генерація скрипта автодоповнення для PowerShell. Для завантаження автодоповнень у вашій поточній shell-сесії: ```powershell PS C:\> helm completion powershell | Out-String | Invoke-Expression ``` Для завантаження автодоповнень для кожної нової сесії, додайте вивід вищенаведеної команди до вашого профілю PowerShell. ```powershell helm completion powershell [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка powershell --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- Генерація скрипта автодоповнення для zsh ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для оболонки zsh. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell source <(helm completion zsh) ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: ```shell helm completion zsh > "${fpath[1]}/_helm" ``` ```shell helm completion zsh [прапорці] ``` ### Параметри {#options} ``` -h, --help довідка zsh --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ``` --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — створення скриптів автодоповнення команд для вказаної оболонки ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_create.md ================================================ --- title: helm create --- Створення нового чарта з вказаним іменем ### Опис {#synopsis} Ця команда створює теку чарта разом із загальними файлами та теками, що використовуються в чартах. Наприклад, `helm create foo` створить структуру тек, що виглядає приблизно так: ```none foo/ ├── .helmignore # Містить шаблони для ігнорування при упаковці Helm-чартів. ├── Chart.yaml # Інформація про ваш чарт ├── values.yaml # Стандартні значення для ваших шаблонів ├── charts/ # Чарти, від яких залежить цей чарт └── templates/ # Файли шаблонів └── tests/ # Файли тестів ``` `helm create` приймає шлях як аргумент. Якщо теки у вказаному шляху не існують, Helm спробує створити їх у процесі роботи. Якщо вказане місце призначення існує і в цій теці є файли, що викликають конфлікт, вони будуть перезаписані, а інші файли залишаться без змін. ```sh helm create NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка create -p, --starter string імʼя або абсолютний шлях до стартового шаблону Helm ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency.md ================================================ --- title: helm dependency --- Керування залежностями чарту ### Опис {#synopsis} Керуйте залежностями чарту. Чарти Helm зберігають свої залежності в теці `charts/`. Розробникам чартів часто простіше керувати залежностями у файлі `Chart.yaml`, який декларує всі залежності. Команди `dependency` працюють з цим файлом, полегшуючи синхронізацію між бажаними залежностями та фактичними залежностями, збереженими в теці `charts/`. Наприклад, цей файл Chart.yaml декларує дві залежності: ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" ``` Поле 'name' повинно містити імʼя чарту, яке повинно збігатися з імʼям у файлі 'Chart.yaml' цього чарту. Поле 'version' повинно містити семантичну версію або діапазон версій. URL-адреса 'repository' повинна вказувати на репозиторій чарту. Helm очікує, що додавання '/index.yaml' до URL-адреси дозволить отримати індекс репозиторію чарту. :::note 'repository' може бути псевдонімом, який повинен починатися з 'alias:' або '@'. ::: Починаючи з версії 2.2.0, репозиторій може бути визначений як шлях до теки залежних чартів, збережених локально. Шлях повинен починатися з префіксу "file://". Наприклад, ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" ``` Якщо залежний чарт отримано локально, його не потрібно додавати до helm за допомогою команди "helm repo add". Підтримується також відповідність версій для цього випадку. ### Параметри {#options} ```none -h, --help довідка dependency ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) — відновлення теки charts/ на основі файлу Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) — перелік залежностей для даного чарта * [helm dependency update](/helm/helm_dependency_update.md) — оновлення charts/ на основі вмісту Chart.yaml ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- Відновлення теки charts/ на основі файлу Chart.lock ### Опис {#synopsis} Ця команда будує теку `charts/` на основі файлу `Chart.lock`. Команда `build` використовується для відновлення залежностей чарту до стану, зазначеного у файлі блокування. Вона не переузгоджуватиме залежності, як це робить `helm dependency update`. Якщо файл блокування не знайдено, `helm dependency build` дзеркально повторюватиме поведінку команди `helm dependency update`. ```sh helm dependency build CHART [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL -h, --help довідка build --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string вʼязка ключів, що містить відкриті ключі ( стандартно "~/.gnupg/pubring.gpg") --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --skip-refresh не оновлювати кеш локального репозиторію --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакети на відповідність підписам ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- Список залежностей для заданого чарту ### Опис {#synopsis} Перелічує всі залежності, зазначені в чарті. Ця команда приймає на вхід як архіви чарту, так і теки чарту. Вона не змінює вміст чарту. Викликається помилка, якщо чарт не може бути завантажений. ```sh helm dependency list CHART [flags] ``` ### Параметри {#options} ```none -h, --help довідка list --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 80) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- Оновлення charts/ на основі вмісту Chart.yaml ### Опис {#synopsis} Оновлює залежності на диску, щоб відобразити стан, зазначений у Chart.yaml. Ця команда перевіряє, що необхідні чарти, зазначені в `Chart.yaml`, присутні в `charts/` і відповідають прийнятній версії. Вона завантажує найновіші чарти, що задовольняють залежності, та очищає застарілі залежності. У разі успішного оновлення буде згенеровано файл блокування, який можна використовувати для відновлення залежностей до точної версії. Залежності не обовʼязково повинні бути представлені в `Chart.yaml`. З цієї причини команда оновлення не видалить чарти, якщо вони (а) присутні у файлі `Chart.yaml`, але (б) мають неправильну версію. ```sh helm dependency update CHART [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL -h, --help довідка update --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string вʼязка ключів, що містить відкриті ключі ( стандартно "~/.gnupg/pubring.gpg") --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --skip-refresh не оновлювати кеш локального репозиторію --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакети на відповідність підписам ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm dependency](/helm/helm_dependency.md) — керування залежностями чарта ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_env.md ================================================ --- title: helm env --- Інформація про середовище клієнта Helm ### Опис {#synopsis} Команда `helm env` виводить усю інформацію про середовище, в якому використовється Helm. ```sh helm env [flags] ``` ### Параметри {#options} ```none -h, --help довідка env ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get.md ================================================ --- title: helm get --- Завантаження розширеної інформації про вказаний реліз ### Опис {#synopsis} Ця команда складається з кількох підкоманд, які можна використовувати для отримання розширеної інформації про реліз, включаючи: - Значення, що використовувалися для генерації релізу - Сгенерований файл маніфесту - Примітки, надані чартом релізу - Хуки, асоційовані з релізом - Метадані релізу ### Параметри {#options} ```none -h, --help довідка get ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm get all](/helm/helm_get_all.md) — завантажити всю інформацію про вказаний реліз * [helm get hooks](/helm/helm_get_hooks.md) — завантажити всі хуки для вказаного релізу * [helm get manifest](/helm/helm_get_manifest.md) — завантажити маніфест для вказаного релізу * [helm get metadata](/helm/helm_get_metadata.md) — отримати метадані для вказаного релізу * [helm get notes](/helm/helm_get_notes.md) — завантажити примітки для вказаного релізу * [helm get values](/helm/helm_get_values.md) — завантажити файл значень для вказаного релізу ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_all.md ================================================ --- title: helm get all --- Завантажити всю інформацію про вказаний реліз ### Опис {#synopsis} Ця команда виводить зрозумілий для людини набір інформації про нотатки, хуки, надані значення та згенерований маніфест для вказаного релізу. ```shell helm get all RELEASE_NAME [flags] ``` get all RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка all --revision int отримати вказаний реліз з ревізією --template string шаблон Go для форматування виводу, напр: {{.Release.Name}} ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- Завантажити всі хуки для вказаного релізу ### Опис {#synopsis} Ця команда завантажує хуки для вказаного релізу. Хуки форматуються у YAML і розділені роздільником YAML '---\n'. ```shell helm get hooks RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка hooks --revision int отримати вказаний реліз з ревізією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- Завантажити маніфест для вказаного релізу ### Опис {#synopsis} Ця команда завантажує згенерований маніфест для вказаного релізу. Маніфест є YAML-кодованим представленням ресурсів Kubernetes, які були згенеровані з чарту(ів) цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест. ```shell helm get manifest RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка manifest --revision int отримати вказаний реліз з ревізією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Ця команда завантажує метадані для вказаного релізу ```shell helm get metadata RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка metadata -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int вказати версію релізу ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_notes.md ================================================ --- title: helm get notes --- Завантажити нотатки для вказаного релізу ### Опис {#synopsis} Ця команда відображає нотатки, надані чартом для вказаного релізу. ```shell helm get notes RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка notes --revision int отримати вказаний реліз з ревізією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_get_values.md ================================================ --- title: helm get values --- Завантажити файл значень для вказаного релізу ### Опис {#synopsis} Ця команда завантажує файл значень для вказаного релізу. ```shell helm get values RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -a, --all вивести всі (обчислені) значення -h, --help довідка values -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int отримати вказаний реліз з ревізією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm get](/helm/helm_get.md) — завантаження розширеної інформації про зазначений реліз ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_history.md ================================================ --- title: helm history --- Отримати історію релізу ### Опис {#synopsis} History виводить історичні ревізії для вказаного релізу. Стандартна максимальна кількість ревізій, що повертається — 256. Встановлення '--max' налаштовує максимальну довжину списку ревізій, що повертаються. Історичний набір релізів виводиться у вигляді відформатованої таблиці, наприклад: ```console $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` ```shell helm history RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка history --max int максимальна кількість ревізій, включених в історію (стандартно 256) -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_install.md ================================================ --- title: helm install --- Встановлює чарт ### Опис {#synopsis} Ця команда встановлює архів чарту. Аргумент для `install` має бути посиланням на чарт, шляхом до запакованого чарту, шляхом до розпакованої теки чарту або URL. Щоб перезаписати значення в чартах, використовуйте прапорець `--values` та передайте файл або прапорець `--set`, щоб передати конфігурацію з командного рядка. Щоб примусово встановити значення string, використовуйте `--set-string`. Ви також можете використовувати `--set-file`, щоб задати окремі значення з файлу, якщо значення занадто велике для командного рядка або є динамічно згенерованим. Ви також можете використовувати `--set-json`, щоб встановити значення JSON (скаляри/обʼєкти/масиви) з командного рядка. ```shell $ helm install -f myvalues.yaml myredis ./redis ``` або ```shell $ helm install --set name=prod myredis ./redis ``` або ```shell $ helm install --set-string long_int=1234567890 myredis ./redis ``` або ```shell $ helm install --set-file my_script=dothings.sh myredis ./redis ``` або ```shell $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis ``` або ```shell $ helm install --set-json '{"master":{"sidecars":[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]}}' myredis ./redis ``` Ви можете вказати прапорець `--values`/`-f` кілька разів. Пріоритет буде наданий останньому (правому) файлу, що вказаний. Наприклад, якщо як `myvalues.yaml`, так і `override.yaml` містять ключ `Test`, значення, встановлене в `override.yaml`, матиме пріоритет: ```shell $ helm install -f myvalues.yaml -f override.yaml myredis ./redis ``` Ви можете вказати прапорець `--set` кілька разів. Пріоритет буде наданий останньому (правому) встановленому значенню. Наприклад, якщо для ключа `foo` встановлені значення `bar` і `newbar`, значення `newbar` матиме пріоритет: ```shell $ helm install --set foo=bar --set foo=newbar myredis ./redis ``` Аналогічно, у наступному прикладі `foo` встановлено в `["four"]`: ```shell $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis ``` А в наступному прикладі `foo` встановлено в `{"key1":"value1","key2":"bar"}`: ```shell $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis ``` Щоб перевірити згенеровані маніфести релізу без встановлення чарту, можна поєднати прапорці `--debug` і `--dry-run`. Прапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з Secrets які можуть містити конфіденційні значення. Щоб приховати секрети Kubernetes, скористайтеся прапорцем `--hide-secret`. Будь ласка, ретельно обміркуйте, як і коли використовувати ці прапорці. Якщо встановлено прапорець `--verify`, чарт ПОВИНЕН мати файл автентифікації, і цей файл ПОВИНЕН пройти всі кроки перевірки. Є шість різних способів вказати чарт, який ви хочете встановити: 1. З посиланням на чарт: `helm install mymaria example/mariadb` 2. З шляхом до запакованого чарту: `helm install mynginx ./nginx-1.2.3.tgz` 3. З шляхом до розпакованої теки чарту: `helm install mynginx ./nginx` 4. З абсолютним URL: `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz` 5. З посиланням на чарт і URL репозиторію: `helm install --repo https://example.com/charts/ mynginx nginx` 6. З OCI реєстрами: `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx` ПОСИЛАННЯ НА ЧАРТ Посилання на чарт — це зручний спосіб посилатися на чарт у репозиторії чарту. Коли ви використовуєте посилання на чарт з префіксом репозиторію (`example/mariadb`), Helm шукатиме в локальній конфігурації репозиторій чарту з імʼям `example`, а потім шукатиме чарт у цьому репозиторії, чия назва є `mariadb`. Він встановить останню стабільну версію цього чарту, поки ви не вкажете прапорець `--devel`, щоб також включити версії розробки (альфа, бета та реліз-кандидати), або не надасте номер версії за допомогою прапорця `--version`. Щоб переглянути список репозиторіїв чартів, використовуйте `helm repo list`. Щоб шукати чарти в репозиторії, використовуйте `helm search`. ```shell helm install [NAME] [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --create-namespace створити простір імен релізу, якщо його не існує --dependency-update оновити залежності, якщо вони відсутні, перед встановленням чарту --description string додати власний опис --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes --dry-run string[="unset"] імітує операцію без збереження змін. Повинно бути одним із таких: "none" (стандартно), "client" або "server". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). "--dry-run=client" імітує операцію лише на стороні клієнта та уникає підключень до кластера. "--dry-run=server" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно "none") --enable-dns увімкнути DNS запити при рендерингу шаблонів --force-conflicts якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти --force-replace примусове оновлення ресурсів шляхом заміни -g, --generate-name згенерувати імʼя (та опустити параметр NAME) -h, --help довідка install --hide-notes якщо встановлено, не показувати нотатки у виводі встановлення. Не впливає на присутність у метаданих чарту --hide-secret приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) --name-template string вказати шаблон для назви релізу --no-hooks запобігти виконанню хуків під час встановлення -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --post-renderer postRendererString назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися --post-renderer-args postRendererArgsSlice аргумент до пост-рендерера (можна вказати кілька) (стандартно []) --render-subchart-notes якщо вказано, рендерити нотатки субчартів разом з батьківським --replace повторно використовувати задане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі. --repo string URL репозиторію чартів, де розташований запитуваний чарт --rollback-on-failure якщо встановлено, Helm скасує (деінсталює) встановлення у разі невдачі. Прапорець --wait буде стандартно встановлений у "watcher", якщо встановлено --rollback-on-failure. --server-side оновлення обʼєктів виконуються на сервері, а не на клієнті (стандартно true) --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray встановити літеральне значення STRING в командному рядку --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-crds якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --take-ownership якщо встановлено, встановлення ігноруватиме перевірку анотацій Helm і перейматиме право власності на наявні ресурси --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' --wait WaitStrategy[=watcher] якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: "watcher" і "legacy" (стандартно hookOnly). --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_lint.md ================================================ --- title: helm lint --- Перевіряє чарт на можливі проблеми ### Опис {#synopsis} Ця команда приймає шлях до чарту і виконує ряд тестів, щоб перевірити, чи чарт добре сформований. Якщо лінтер знайде речі, які можуть призвести до помилки при встановленні чарту, він видасть повідомлення [ERROR]. Якщо він знайде проблеми, які порушують конвенції або рекомендації, він видасть повідомлення [WARNING]. ```shell helm lint PATH [flags] ``` ### Параметри {#options} ```none -h, --help довідка lint --kube-version string версія Kubernetes, що використовується для перевірки можливостей і застарілостей --quiet виводити лише попередження та помилки --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=pshellath2) --set-json stringArray встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray встановити літеральне значення STRING в командному рядку --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --strict видавати стан помилки на попередження перевірки -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --with-subcharts перевірити залежні чарти ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_list.md ================================================ --- title: helm list --- Вивід списку релізів ### Опис {#synopsis} Ця команда виводить список усіх релізів для вказаного простору імен (використовується поточний контекст простору імен, якщо не вказано). Стандартно показуються всі релізи в будь-якому статусі. Для показу релізів у певному статусі можна використовувати окремі фільтри статусу, такі як `--deployed`, `--failed`, `--pending`, `--uninstalled`, `--superseded` та `--uninstalling`. Ці прапорці можна комбінувати: `--deployed --failed`. Як правило елементи сортуються в алфавітному порядку. Використовуйте прапорець `-d`, щоб сортувати за датою релізу. Якщо надано прапорець `--filter`, він буде використовуватися як фільтр. Фільтри є регулярними виразами (сумісними з Perl), які застосовуються до списку релізів. Будуть повернуті тільки ті елементи, які відповідають фільтру. ```console $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 ``` Якщо результати не знайдені, команда `helm list` завершиться з кодом 0, але без виводу (або, у випадку без прапорця `-q`, тільки заголовки). Стандартно повертається до 256 елементів. Щоб обмежити це, використовуйте прапорець `--max`. Встановлення `--max` в 0 не поверне всі результати. Замість цього повернеться стандартне значення сервера, яке може бути значно більше ніж 256. Поєднання прапорців `--max` та `--offset` дозволяє переглядати результати посторінково. ```shell helm list [flags] ``` ### Параметри {#options} ```none -A, --all-namespaces список релізів по всіх просторах імен -d, --date сортувати за датою релізу --deployed показати розгорнуті релізи --failed показати релізи, що зазнали невдачі -f, --filter string регулярний вираз (сумісний з Perl). Будь-які релізи, що відповідають виразу, будуть включені в результати -h, --help довідка list -m, --max int максимальна кількість релізів для отримання (стандартно 256) --no-headers не друкувати заголовки при використанні стандартного формату виводу --offset int наступний індекс релізу у списку, використовується для зсуву від початкового значення -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pending показати релізи, які перебувають в очікуванні -r, --reverse змінити порядок сортування на зворотний -l, --selector string Селектор (запит за міткою) для фільтрації, підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Працює тільки для сховищ secret (стандартно) та configmap. -q, --short короткий (простий) формат виводу списку --superseded показати замінені релізи --time-format string форматувати час використовуючи форматування часу golang. Наприклад: --time-format "2006-01-02 15:04:05Z0700" --uninstalled показати видалені релізи (якщо використовувався 'helm uninstall --keep-history') --uninstalling показати релізи, які в даний час видаляються ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_package.md ================================================ --- title: helm package --- Упакувати теку чарту в архів чартів ### Опис {#synopsis} Ця команда упаковує чарт в архів чартів з версією. Якщо вказано шлях, команда перевіряє цей шлях на наявність чарту (який повинен містити файл `Chart.yaml`) і потім упаковує цю теку. Архіви чартів з версією використовуються репозиторіями пакетів Helm. Щоб підписати чарт, використовуйте прапорець `--sign`. У більшості випадків вам також слід вказати `--keyring path/to/secret/keys` та `--key keyname`. ```shell $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg ``` Якщо `--keyring` не вказано, Helm зазвичай використовує публічний ключ, якщо тільки ваше середовище не налаштоване інакше. ```shell helm package [CHART_PATH] [...] [flags] ``` ### Параметри {#options} ```none --app-version string встановити appVersion в чарті на цю версію --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL -u, --dependency-update оновити залежності з "Chart.yaml" в теці "charts/" перед упаковкою -d, --destination string місце для збереження чарту. (стандартно ".") -h, --help довідка package --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key string імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string місце для публічного ключа (стандартно "~/.gnupg/pubring.gpg") --passphrase-file string місце розташування файлу, що містить пароль для ключа підпису. Використовуйте "-" для читання з stdin. --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --sign використовувати приватний ключ PGP для підписання цього пакета --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --version string встановити версію чарту на цю версію semver ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin.md ================================================ --- title: helm plugin --- Встановлення, перегляд списку або видалення втулків Helm ### Опис {#synopsis} Керування втулками Helm на стороні клієнта. ### Параметри {#options} ```none -h, --help довідка plugin ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) — встановлення втулків Helm * [helm plugin list](/helm/helm_plugin_list.md) — перегляд встановлених втулків Helm * [helm plugin package](/helm/helm_plugin_package.md) — створення пакунку з теки втулка * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) — видалення одного чи кількох втулків Helm * [helm plugin update](/helm/helm_plugin_update.md) — оновлення одного чи кількох втулків Helm * [helm plugin verify](/helm/helm_plugin_verify.md) — перевірка, що втулок за вказаним шляхом має підпис і є дійсним ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- Встановлення втулків Helm ### Опис {#synopsis} Ця команда дозволяє встановити втулок з вказаної URL-адреси в репозиторій VCS або з локального шляху. Зазвичай підписи втулків перевіряються перед встановленням під час встановлення з архівів (.tgz або .tar.gz). Для цього потрібно, щоб відповідний файл .prov був доступний разом з архівом. Для локальної розробки втулки, встановлені з локальних текстових файлів, автоматично розглядаються як «локальна розробка» і не потребують підписів. Використовуйте `--verify=false`, щоб пропустити перевірку підписів для віддалених втулків. ```shell helm plugin install [options] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL -h, --help довідка install --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження втулка --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --password string пароль реєстру --plain-http використовувати незахищені HTTP-зʼєднання для завантаження втулка --username string імʼя користувача реєстру --verify перевірити підпис втулка перед встановленням (стандартно true) --version string вказати обмеження версії. Якщо це не вказано, встановлюється остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- Вивести перелік встановлених втулків Helm ```shell helm plugin list [flags] ``` ### Параметри {#options} ```none -h, --help довідка list --type string тип втулка ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_package.md ================================================ --- title: helm plugin package --- Упакувати теку втулка в архів втулка ### Опис {#synopsis} Ця команда упаковує теку втулка Helm в архів tarball. Зазвичай, команда створює файл provenance, підписаний ключем PGP. Це гарантує, що втулок можна перевірити після встановлення. Використовуйте `--sign=false`, щоб пропустити підписання (не рекомендується для розповсюдження). ```shell helm plugin package [PATH] [flags] ``` ### Параметри {#options} ```none -d, --destination string місце для збереження архіву втулка. (стандартно ".") -h, --help довідка package --key string імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true --keyring string місце для публічного ключа (стандартно "~/.gnupg/pubring.gpg") --passphrase-file string розташування файлу, що містить пароль для ключа підпису. Використовуйте "-" для читання зі стандартного вводу. --sign використовувати приватний ключ PGP для підписання цього втулка (стандартно true) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- Видалити один або кілька втулків Helm ```shell helm plugin uninstall ... [flags] ``` ### Параметри {#options} ```none -h, --help довідка uninstall ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- Оновити один або кілька втулків Helm ```shell helm plugin update ... [flags] ``` ### Параметри {#options} ```none -h, --help довідка update ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_plugin_verify.md ================================================ --- title: helm plugin verify --- Перевірити, чи втулок за вказаним шляхом має підпис і є дійсним ### Опис {#synopsis} Ця команда перевіряє, чи має втулок Helm дійсний файл походження і чи підписаний цей файл походження надійним ключем PGP. Вона підтримує обидва типи: - Архіви втулків (файли .tgz або .tar.gz) - Теки встановлених втулків Для встановлених втулків використовуйте шлях, показаний командою `helm env HELM_PLUGINS`, а потім вкажіть назву втулка. Наприклад: ```shell helm plugin verify ~/.local/share/helm/plugins/example-cli ``` Щоб створити підписаний втулок, використовуйте команду `helm plugin package --sign`. ```shell helm plugin verify [PATH] [flags] ``` ### Параметри {#options} ```none -h, --help довідка verify --keyring string вʼязка ключів, що містить відкриті ключі ( стандартно "~/.gnupg/pubring.gpg") ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_pull.md ================================================ --- title: helm pull --- Завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальну теку ### Опис {#synopsis} Отримати пакет із репозиторію пакетів і завантажити його локально. Це корисно для отримання пакетів з метою перевірки, модифікації або перепакування. Також це можна використовувати для криптографічної перевірки чарта без його встановлення . Існують опції для розпакування чарта після завантаження. Це створить теку для чарта і розпакує його в цю теку. Якщо вказано прапорець `--verify`, запитуваний чарт ПОВИНЕН мати файл походження і ПОВИНЕН пройти процес перевірки. Неуспіх у будь-якій частині цього призведе до помилки, і чарт не буде збережений локально. ```shell helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL -d, --destination string місце для збереження чарту. Якщо вказано разом із untardir, то untardir буде додано до нього (стандартно ".") --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка pull --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --prov завантажити файл підтвердження автентичності, але не виконувати перевірку --repo string URL репозиторію чартів, де розташований запитуваний чарт --untar якщо встановлено, чарт буде розпаковано після завантаження --untardir string якщо вказано untar, цей прапорець вказує назву теки, в яку буде розпаковано чарт (стандартно ".") --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_push.md ================================================ --- title: helm push --- Завантажити чарт на віддалений сервер ### Опис {#synopsis} Завантаження чарту до реєстру. Якщо чарт має повʼязаний файл підтвердження автентичності, він також буде завантажений. ```shell helm push [chart] [remote] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL -h, --help довідка push --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry.md ================================================ --- title: helm registry --- Вхід до або вихід з реєстру ### Опис {#synopsis} Ця команда містить декілька субкоманд для взаємодії з реєстрами. ### Параметри {#options} ```none -h, --help довідка registry ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm registry login](/helm/helm_registry_login.md) — вхід до реєстру * [helm registry logout](/helm/helm_registry_logout.md) — вихід з реєстру ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry_login.md ================================================ --- title: helm registry login --- Вхід до реєстру ### Опис {#synopsis} Автентифікація у віддаленому реєстрі. Наприклад, для реєстру контейнерів Github: ```shell echo "$GITHUB_TOKEN" | helm registry login ghcr.io -u $GITHUB_USER --password-stdin ``` ```shell helm registry login [host] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта реєстру за допомогою цього файлу сертифіката SSL -h, --help довідка login --insecure дозволити зʼєднання з TLS-реєстром без сертифікатів --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL -p, --password string пароль для реєстру або токен ідентифікації --password-stdin пароль для реєстру або токен ідентифікації --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів -u, --username string імʼя користувача реєстру ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- Вихід з реєстру ### Опис {#synopsis} Видалення збережених облікових даних для віддаленого реєстру. ```shell helm registry logout [host] [flags] ```registry logout [host] [flags] ``` ### Параметри {#options} ```none -h, --help довідка logout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo.md ================================================ --- title: helm repo --- Додати, вивести перелік, видалити, оновити та індексувати репозиторії чартів ### Опис {#synopsis} Ця команда містить кілька субкоманд для взаємодії з репозиторіями чартів. Вона може використовуватися для додавання, видалення, виводу переліку та індексування репозиторіїв чартів. ### Параметри {#options} ```none -h, --help довідка repo ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm repo add](/helm/helm_repo_add.md) — додати репозиторій чартів * [helm repo index](/helm/helm_repo_index.md) — згенерувати файл індексу для теки, що містить упаковані чарти * [helm repo list](/helm/helm_repo_list.md) — вивести перелік репозиторіїв чартів * [helm repo remove](/helm/helm_repo_remove.md) — видалити один або кілька репозиторіїв чартів * [helm repo update](/helm/helm_repo_update.md) — оновити інформацію про доступні чарти локально з репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_add.md ================================================ --- title: helm repo add --- Додати репозиторій чартів ```shell helm repo add [NAME] [URL] [flags] ``` ### Параметри {#options} ```none --allow-deprecated-repos стандартно ця команда не дозволяє додавати офіційні репозиторії, які були назавжди видалені. Ця опція вимикає таку поведінку --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --force-update замінити (перезаписати) репозиторій, якщо він уже існує -h, --help довідка add --insecure-skip-tls-verify пропустити перевірку tls-сертифікатів для репозиторію --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --pass-credentials передати облікові дані всім доменам --password string пароль до репозиторію чартів --password-stdin зчитати пароль до репозиторію чартів з stdin --timeout duration час очікування завершення завантаження індексного файлу (стандартно 2m0s) --username string імʼя користувача репозиторію чартів ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_index.md ================================================ --- title: helm repo index --- Згенерувати файл індексу для теки, що містить упаковані чарти ### Опис {#synopsis} Читає поточну теку, створює індексний файл на основі знайдених чартів і записує результат у файл `index.yaml` у поточній теці. Цей інструмент використовується для створення файлу `index.yaml` для репозиторію чартів. Щоб встановити абсолютний URL-адресу чартів, використовуйте прапорець `--url`. Щоб обʼєднати згенерований індекс з наявним індексним файлом, використовуйте прапорець `--merge`. У цьому випадку чарти, знайдені в поточній теці, будуть обʼєднані з індексом, переданим за допомогою `--merge`, причому локальні чарти матимуть пріоритет над наявними чартами. ```shell helm repo index [DIR] [flags] ``` ### Параметри {#options} ```none -h, --help довідка index --json вивід у форматі JSON --merge string обʼєднати згенерований індекс із вказаним індексом --url string URL репозиторію чартів ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_list.md ================================================ --- title: helm repo list --- Вивести перелік репозиторії чартів ```shell helm repo list [flags] ``` ### Параметри {#options} ```none -h, --help довідка list -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- Видалити один або кілька репозиторіїв чартів ```shell helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Параметри {#options} ```none -h, --help довідка remove ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_repo_update.md ================================================ --- title: helm repo update --- Оновити інформацію про доступні чарти локально з репозиторіїв чартів ### Опис {#synopsis} Команда update отримує останню інформацію про чарти з відповідних репозиторіїв чартів. Інформація кешується локально, де її використовують такі команди, як `helm search`. Ви можете опційно вказати список репозиторіїв, які ви хочете оновити. ```shell helm repo update ... ``` Щоб оновити всі репозиторії, використовуйте `helm repo update`. ```shell helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Параметри {#options} ```none -h, --help довідка update --timeout duration час очікування завершення завантаження індексного файлу (стандартно 2m0s) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_rollback.md ================================================ --- title: helm rollback --- Відкотити реліз до попередньої версії ### Опис {#synopsis} Ця команда відкотить реліз до попередньої версії. Перший аргумент команди rollback — це імʼя релізу, а другий — номер версії (revision). Якщо цей аргумент пропущений або встановлений на 0, реліз буде повернено до попередньої версії. Щоб побачити номери версій, виконайте команду `helm history RELEASE`. ```shell helm rollback [REVISION] [flags] ``` ### Параметри {#options} ```none --cleanup-on-fail дозволити видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдається --dry-run string[="unset"] імітує операцію без збереження змін. Повинно бути одним із таких: "none" (стандартно), "client" або "server". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). "--dry-run=client" імітує операцію лише на стороні клієнта та уникає підключень до кластера. "--dry-run=server" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно "none") --force-conflicts якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти --force-replace примусове оновлення ресурсів шляхом заміни -h, --help довідка rollback --history-max int обмежити максимальну кількість збережених ревізій для кожного релізу. Вкажіть 0, щоб не встановлювати обмеження (стандартно 10). --no-hooks запобігти виконанню хуків під час відкату --server-side string повинно бути "true", "false" або "auto". Оновлення обʼєкта виконуються на сервері, а не на клієнті (стандартно "auto" використовує значення з попереднього релізу чарту) (стандартно "auto") --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --wait WaitStrategy[=watcher] якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: "watcher" і "legacy" (стандартно hookOnly). --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search.md ================================================ --- title: helm search --- Пошук за ключовим словом у чартах ### Опис {#synopsis} Команда Search надає можливість шукати чарти Helm у різних місцях, де вони можуть зберігатися, включаючи Artifact Hub та репозиторії, які ви додали. Використовуйте підкоманди search для пошуку чартів у різних місцях. ### Параметри {#options} ``` -h, --help довідка search ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm search hub](/helm/helm_search_hub.md) — шукати чарти в Artifact Hub або у власному екземплярі хабу * [helm search repo](/helm/helm_search_repo.md) — шукати репозиторії за ключовим словом у чартах ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search_hub.md ================================================ --- title: helm search hub --- Шукати чарти в Artifact Hub або у власному екземплярі хабу ### Опис {#synopsis} Шукайте Helm чарти в Artifact Hub або у власному екземплярі хабу. Artifact Hub — це вебдодаток, що дозволяє знаходити, встановлювати та публікувати пакети та конфігурації для проєктів CNCF, включаючи загальнодоступні розподілені чарти Helm. Це проєкт пісочниці Cloud Native Computing Foundation. Ви можете переглянути хаб за адресою https://artifacthub.io/ Аргумент [KEYWORD] приймає або рядок ключового слова, або рядок у лапках з розширеними параметрами запиту. Документацію щодо розширених параметрів запиту див. за адресою https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Попередні версії Helm використовували екземпляр Monocular як стандартну «точку доступу», тому для забезпечення зворотної сумісності Artifact Hub сумісний з API пошуку Monocular. Аналогічно, при встановленні прапорця `endpoint` вказана точка доступу також повинна реалізовувати точку доступу API пошуку, сумісну з Monocular. Зверніть увагу, що при вказанні екземпляра Monocular як `endpoint` розширені запити не підтримуються. Детальні відомості про API див. на https://github.com/helm/monocular ```shell helm search hub [KEYWORD] [flags] ``` ### Параметри {#options} ```none --endpoint string Екземпляр хаба для запитів чартів (стандартно "https://hub.helm.sh") --fail-on-no-result пошук завершується невдачею, якщо немає результатів -h, --help довідка hub --list-repo-url вивести URL репозиторію чартів --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_search_repo.md ================================================ --- title: helm search repo --- Пошук репозиторіїв за ключовим словом у чартах ### Опис {#synopsis} Команда search проходить через всі репозиторії, налаштовані в системі, і шукає збіги. Пошук цих репозиторіїв використовує метадані, збережені в системі. Вона відобразить останні стабільні версії знайдених чартів. Якщо ви вказуєте прапорець `--devel`, у виводі будуть включені передрелізні версії. Якщо ви хочете шукати за допомогою обмеження версії, використовуйте `--version`. Приклади: ```shell # Шукати стабільні версії релізів, що відповідають ключовому слову "nginx" $ helm search repo nginx # Шукати версії релізів, що відповідають ключовому слову "nginx", включаючи передрелізні версії $ helm search repo nginx --devel # Шукати останній стабільний реліз для nginx-ingress з основною версією 1 $ helm search repo nginx-ingress --version ^1.0.0 ``` Репозиторії управляються командами `helm repo`. ```shell helm search repo [keyword] [flags] ``` ### Параметри {#options} ```none --devel використовувати також версії, що знаходяться в розробці ( alpha, beta та release candidate). Еквівалентно версії “>0.0.0-0”. Якщо встановлено --version, це ігнорується. --fail-on-no-result пошук завершується невдачею, якщо немає результатів -h, --help довідка repo --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) -r, --regexp використовувати регулярні вирази для пошуку в репозиторіях, які ви додали --version string шукати, використовуючи обмеження семантичного версіонування в репозиторіях, які ви додали -l, --versions показати довгий список, з кожною версією кожного чарту на окремому рядку, для репозиторіїв, які ви додали ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm search](/helm/helm_search.md) — пошук за ключовим словом в чартах ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show.md ================================================ --- title: helm show --- показати інформацію про чарт ### Опис {#synopsis} Ця команда складається з кількох підкоманд для показу інформації про чарт ### Параметри {#options} ```none -h, --help довідка show ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. * [helm show all](/helm/helm_show_all.md) — показати всю інформацію про чарт * [helm show chart](/helm/helm_show_chart.md) — показати визначення чарту * [helm show crds](/helm/helm_show_crds.md) — показати CRDs чарту * [helm show readme](/helm/helm_show_readme.md) — показати README чарту * [helm show values](/helm/helm_show_values.md) — показати значення чарту ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_all.md ================================================ --- title: helm show all --- Показати всю інформацію про чарт ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує весь його вміст (values.yaml, Chart.yaml, README). ```shell helm show all [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка all --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_chart.md ================================================ --- title: helm show chart --- Показати визначення чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) і показує вміст файлу Chart.yaml. ```shell helm show chart [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка chart --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_crds.md ================================================ --- title: helm show crds --- Показати CRDs чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлів CustomResourceDefinition (CRD). ```shell helm show crds [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка crds --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_readme.md ================================================ --- title: helm show readme --- Показати README файл чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу README ```shell helm show readme [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка readme --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_show_values.md ================================================ --- title: helm show values --- Показати значення чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу values.yaml ```shell helm show values [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка values --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --jsonpath string надайте вираз JSONPath для фільтрування виводу --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_status.md ================================================ --- title: helm status --- Показати статус вказаного релізу ### Опис {#synopsis} Ця команда показує статус вказаного релізу. Статус складається з: - часу останнього розгортання - простору імен k8s, в якому знаходиться реліз - стану релізу (може бути: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade або pending-rollback) - ревізії релізу - опис релізу (може бути повідомленням про завершення або повідомленням про помилку) - списку ресурсів, які входять до складу цього релізу - детальної інформації про останнє виконання набору тестів, якщо це доречно - додаткових приміток, надані в чарті ```shell helm status RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка status -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int якщо вказано, показати статус вказаного релізу з ревізією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_template.md ================================================ --- title: helm template --- Локальний рендеринг шаблонів ### Опис {#synopsis} Створює локально шаблон чарту та показує результат. Будь-які значення, які зазвичай шукалися б або отримувалися в кластері, будуть імітуватися локально. Крім того, жодна з перевірок валідності чарту на сервері (наприклад, перевірка підтримки API) не проводиться. ```shell helm template [NAME] [CHART] [flags] ``` ### Параметри {#options} ```none -a, --api-versions strings версії API Kubernetes, які використовуються для Capabilities.APIVersions (можна вказати декілька) --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --create-namespace створити простір імен релізу, якщо його не існує --dependency-update оновити залежності, якщо вони відсутні, перед встановленням чарту --description string додати власний опис --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes --dry-run string[="unset"] імітує роботу на стороні клієнта або сервера. Повинно бути або: "client", або "server". '--dry-run=client' імітує роботу тільки на стороні клієнта і уникає підключень до кластера. '--dry-run=server' імітує/перевіряє роботу на сервері, вимагаючи підключення до кластера. (стандартно "client") --enable-dns увімкнути DNS запити при рендерингу шаблонів --force-conflicts якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти --force-replace примусове оновлення ресурсів шляхом заміни -g, --generate-name згенерувати імʼя (та опустити параметр NAME) -h, --help довідка template --hide-notes якщо встановлено, не показувати нотатки у виводі встановлення. Не впливає на присутність у метаданих чарту --include-crds включити CRDs у вивід шаблонів --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта --is-upgrade встановити .Release.IsUpgrade замість .Release.IsInstall --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --kube-version string версія Kubernetes, яка використовується для Capabilities.KubeVersion -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) --name-template string вказати шаблон для назви релізу --no-hooks запобігти виконанню хуків під час встановлення --output-dir string записувати оброблені шаблони у файли в output-dir замість stdout --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --post-renderer postRendererString назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися --post-renderer-args postRendererArgsSlice аргумент до пост-рендерера (можна вказати кілька) (стандартно []) --release-name використовувати імʼя релізу в шляху output-dir --render-subchart-notes якщо вказано, рендерити нотатки субчартів разом з батьківським --replace повторно використовувати задане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі. --repo string URL репозиторію чартів, де розташований запитуваний чарт --rollback-on-failure якщо встановлено, Helm скасує (деінсталює) встановлення у разі невдачі. Прапорець --wait буде стандартно встановлений у "watcher", якщо встановлено --rollback-on-failure. --server-side оновлення обʼєктів виконуються на сервері, а не на клієнті (стандартно true) --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray встановити літеральне значення STRING в командному рядку --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --skip-tests пропустити тести з виводу шаблонів --take-ownership якщо встановлено, встановлення ігноруватиме перевірку анотацій Helm і перейматиме право власності на наявні ресурси --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' --wait WaitStrategy[=watcher] якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: "watcher" і "legacy" (стандартно hookOnly). --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_test.md ================================================ --- title: helm test --- Запуск тестів для релізу ### Опис {#synopsis} Команда test запускає тести для релізу. Аргументом цієї команди є імʼя розгорнутого релізу. Тести, що будуть виконані, визначені у чарті, який був встановлений. ```shell helm test [RELEASE] [flags] ``` ### Параметри {#options} ```none --filter strings вказати тести за атрибутом (в даний час "name") використовуючи синтаксис attribute=value або '!attribute=value', щоб виключити тест (можна вказати кілька або розділити значення комами: name=test1,name=test2) -h, --help довідка test --logs отримати логи з тестових podʼів (це виконується після завершення всіх тестів, але перед будь-яким очищенням) --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- Видалення релізу ### Опис {#synopsis} Ця команда приймає імʼя релізу і видаляє його. Вона видаляє всі ресурси, асоційовані з останнім релізом чарту, а також історію релізу, звільняючи його для подальшого використання. Використовуйте прапорець `--dry-run`, щоб побачити, які релізи будуть видалені без фактичного видалення. ```shell helm uninstall RELEASE_NAME [...] [flags] ``` ### Параметри {#options} ```none --cascade string Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних ресурсів. Стандартно background. (стандартно "background") --description string додати власний опис --dry-run симулювати видалення -h, --help довідка uninstall --ignore-not-found Вважати "release not found" як успішне видалення --keep-history видалити всі асоційовані ресурси і помітити реліз як видалений, але зберегти історію релізу --no-hooks запобігти виконанню хуків під час видалення --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --wait WaitStrategy[=watcher] якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: "watcher" і "legacy" (стандартно hookOnly). ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- Оновлення релізу ### Опис {#synopsis} Ця команда оновлює реліз до нової версії чарту. Аргументи для оновлення повинні містити реліз і чарт. Аргумент чарту може бути або: посилання на чарт ('example/mariadb'), шлях до теки з чартом, упакований чарт або повністю кваліфікований URL. Для посилань на чарт буде використовуватись остання версія 'latest', якщо не встановлено прапорець `--version`. Щоб перевизначити значення в чарті, використовуйте прапорець `--values` з файлом або прапорець `--set` з конфігурацією з командного рядка. Щоб примусово встановити значення string, використовуйте `--set-string`. Ви можете використовувати `--set-file`, щоб встановити окремі значення з файлу, якщо саме значення занадто довге для командного рядка або генерується динамічно. Ви також можете використовувати `--set-json` для встановлення значень json (скалярів/обʼєктів/масивів) з командного рядка. Крім того, ви можете використовувати `--set-json` і передавати обʼєкт json як рядок. Ви можете вказати прапорець `--values`/`-f` кілька разів. Пріоритет буде надано останньому (правому) файлу. Наприклад, якщо і myvalues.yaml, і override.yaml містять ключ 'Test', значення, задане в override.yaml, матиме пріоритет: ```shell $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis ``` Ви можете вказати прапорець `--set` кілька разів. Пріоритет буде надано останньому (правому) заданому значенню. Наприклад, якщо значення 'bar' і 'newbar' встановлені для ключа 'foo', значення 'newbar' матиме пріоритет: ```shell $ helm upgrade --set foo=bar --set foo=newbar redis ./redis ``` Ви також можете оновити значення для поточного релізу за допомогою цієї команди з прапорцем `--reuse-values`. Аргументи 'RELEASE' і 'CHART' повинні бути встановлені на оригінальні параметри, поточні значення будуть обʼєднані з будь-якими значеннями, заданими через прапорці `--values`/`-f` або `--set`. Пріоритет надається новим значенням. ```shell $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis ``` Прапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з секретами, які можуть містити конфіденційні значення. Для приховування секретів Kubernetes використовуйте прапорець `--hide-secret`. Будь ласка, ретельно обміркуйте, як і коли використовувати ці прапорці. ```shell helm upgrade [RELEASE] [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати серверів з підтримкою HTTPS за допомогою цього пакета CA --cert-file string ідентифікувати клієнта HTTPS за допомогою цього файлу сертифіката SSL --cleanup-on-fail дозволити видалення нових ресурсів, створених в цьому оновленні, коли оновлення не вдалося --create-namespace якщо встановлено --install, створити простір імен релізу, якщо його немає --dependency-update оновити залежності, якщо вони відсутні, перед встановленням чарту --description string додати власний опис --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --disable-openapi-validation якщо встановлено, процес оновлення не буде перевіряти відрендерені шаблони на відповідність Kubernetes OpenAPI Schema --dry-run string[="unset"] імітує операцію без збереження змін. Повинно бути одним із таких: "none" (стандартно), "client" або "server". '--dry-run=none' виконує операцію у звичайному режимі та зберігає зміни (без імітації). "--dry-run=client" імітує операцію лише на стороні клієнта та уникає підключень до кластера. "--dry-run=server" імітує операцію на сервері, вимагаючи підключення до кластера. (стандартно "none") --enable-dns увімкнути DNS запити при рендерингу шаблонів --force-conflicts якщо встановлено, 'застосування на стороні сервера' примусово застосує зміни, незважаючи на конфлікти --force-replace примусове оновлення ресурсів шляхом заміни -h, --help довідка upgrade --hide-notes якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту --hide-secret приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run --history-max int обмежити максимальну кількість збережених ревізій для кожного релізу. Вкажіть 0, щоб не встановлювати обмеження (стандартно 10). --insecure-skip-tls-verify пропустити перевірку сертифіката TLS для завантаження чарта -i, --install якщо релізу з цим імʼям ще не існує, виконується установка --key-file string ідентифікувати клієнта HTTPS за допомогою цього файлу ключа SSL --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комою. Оригінальні мітки релізу будуть обʼєднані з мітками оновлення. Ви можете скинути мітку, використовуючи null. (стандартно []) --no-hooks вимкнути хуки перед/після оновлення -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pass-credentials передати облікові дані всім доменам --password string пароль сховища чартів, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чартів --post-renderer postRendererString назва втулка типу postrenderer, який буде використовуватися для пострендерингу. Якщо він існує, втулок буде використовуватися --post-renderer-args postRendererArgsSlice аргумент до пост-рендерера (можна вказати кілька) (стандартно []) --render-subchart-notes якщо вказано, рендерити нотатки субчартів разом з батьківським --repo string URL репозиторію чартів, де розташований запитуваний чарт --reset-then-reuse-values при оновленні, скинути значення до вбудованих у чарт значень, застосувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values' або '--reuse-values', це буде проігноровано --reset-values при оновленні, скинути значення до вбудованих у чарт значень --reuse-values при оновленні, повторно використовувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values', це буде проігноровано --rollback-on-failure якщо встановлено, Helm відновить попередній успішний реліз у разі невдачі. Прапорець --wait буде стандартно встановлений на "watcher", якщо встановлено --rollback-on-failure. --server-side string повинно бути "true", "false" або "auto". Оновлення обʼєкта виконуються на сервері, а не на клієнті (стандартно "auto" використовує значення з попереднього релізу чарту) (стандартно "auto") --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити значення JSON у командному рядку (можна вказати кілька значень або розділити їх комами: key1=jsonval1,key2=jsonval2 або використовувати формат json: {"key1": jsonval1, "key2": "jsonval2"}) --set-literal stringArray встановити літеральне значення STRING в командному рядку --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-crds якщо встановлено, CRDs не будуть встановлені під час виконання оновлення з увімкненим прапорцем install. Стандартно, CRDs встановлюються, якщо ще не присутні, під час виконання оновлення з увімкненим прапорцем install --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --take-ownership якщо встановлено, оновлення проігнорує перевірку анотацій Helm і перейме право власності на наявні ресурси --timeout duration очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --username string імʼя користувача сховища чартів, де знаходиться запитуваний чарт -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія 'latest' --wait WaitStrategy[=watcher] якщо вказано, буде чекати, поки всі ресурси не будуть у бажаному стані, перш ніж позначити операцію як успішну. Буде чекати стільки, скільки вказано в --timeout. Допустимі значення: "watcher" і "legacy" (стандартно hookOnly). --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки вказано в --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_verify.md ================================================ --- title: helm verify --- Перевірити, що чарт за вказаним шляхом підписаний і є дійсним ### Опис {#synopsis} Перевірте, чи має даний чарт дійсний файл походження. Файли походження забезпечують криптографічну перевірку того, що чарт не був підроблений і був упакований надійним постачальником. Цю команду можна використовувати для перевірки локального чарту. Декілька інших команд мають прапорці `—verify`, які виконують ту саму перевірку. Щоб створити підписаний пакет, використовуйте команду `helm package --sign`. ```shell helm verify PATH [flags] ``` ### Параметри {#options} ```none -h, --help довідка verify --keyring string вʼязка ключів, що містить відкриті ключі ( стандартно "~/.gnupg/pubring.gpg") ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/helm_version.md ================================================ --- title: helm version --- Вивід інформації про версію Helm ### Опис {#synopsis} Показує версію Helm. Команда виведе на екран інформацію про версію Helm. Результат буде виглядати приблизно так: ```console version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} ``` - Version — семантична версія релізу. - GitCommit — SHA коміту, з якого була збудована ця версія. - GitTreeState — "clean", якщо при створенні цього бінарного файлу не було локальних змін у коді, і "dirty", якщо бінарний файл був збудований з локально зміненого коду. - GoVersion — версія Go, яка була використана для компіляції Helm. При використанні прапорця `--template` доступні такі властивості для використання в шаблоні: - `.Version` — містить семантичну версію Helm - `.GitCommit` — git коміт - `.GitTreeState` — стан git дерева, коли був збудований Helm - `.GoVersion` — містить версію Go, з якою був зібраний Helm Наприклад, `--template='Version: {{.Version}}'` надрукує `'Version: v3.2.1'`. ```shell helm version [flags] ``` ### Параметри {#options} ```none -h, --help довідка version --short вивести номер версії --template string шаблон для формату рядка версії ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --color string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --colour string використовувати кольоровий вивід (never, auto, always) (стандартно "auto") --content-cache string шлях до теки, що містить кешований вміст (наприклад, чарти) (стандартно "~/.cache/helm/content") --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці (СА) для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання незахищеними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до теки, що містить кешлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Helm, менеджер пакетів для Kubernetes. ###### Автоматично згенеровано spf13/cobra 14 січня 2026 року ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/helm/index.mdx ================================================ --- title: Команди Helm description: Документація для повного списку команд CLI для Helm. sidebar_position: 6 id: helm-category --- # Команди Helm {#helm-commands} Тут ви знайдете список команд CLI для Helm з інформацією щодо їх використання. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action для автоматизації публікації чартів на GitHub Pages description: Описує, як використовувати Chart Releaser Action для автоматизації публікації чартів за допомогою GitHub Pages. sidebar_position: 3 --- Цей посібник описує, як використовувати [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) для автоматизації публікації чартів за допомогою GitHub Pages. Chart Releaser Action — це GitHub Action workflow, який перетворює GitHub проєкт на репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Зміни в репозиторії {#repository-changes} Створіть Git-репозиторій у вашій організації на GitHub. Ви можете назвати репозиторій `helm-charts`, хоча інші назви також прийнятні. Сирці всіх чартів можуть бути розміщені в гілці `main`. Чарти повинні бути розміщені в теці `/charts` на верхньому рівні дерева тек. Також має бути інша гілка з назвою `gh-pages`, щоб публікувати чарти. Зміни в цій гілці будуть автоматично створюватися за допомогою Chart Releaser Action, описаного тут. Крім створення гілки `gh-pages` ви можете додати файл `README.md` до неї, який буде показуватись користувачам, що відвідують сторінку. Ви можете додати інструкції в `README.md` щодо встановлення чартів, як показано нижче (замініть ``, ``, і ``): ```md ## Використання Щоб використовувати чарти, необхідно встановити [Helm](https://helm.sh/uk). Будь ласка, ознайомтеся з [документацією Helm](https://helm.sh/uk/docs), щоб розпочати. Як тільки Helm буде налаштовано правильно, додайте репозиторій наступним чином: helm repo add https://.github.io/helm-charts Якщо ви вже додавали цей репозиторій раніше, виконайте команду `helm repo update`, щоб отримати останні версії пакетів. Потім ви можете виконати `helm search repo `, щоб побачити чарти. Щоб встановити чарт ``: helm install my- / Щоб видалити чарт: helm uninstall my- ``` Чарти будуть опубліковані на вебсайті з URL-адресою типу: https://.github.io/helm-charts ## GitHub Actions Workflow {#github-actions-workflow} Створіть файл GitHub Actions workflow в гілці `main` за адресою `.github/workflows/release.yml`: ```yaml name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v5 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.7.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` Наведена конфігурація використовує [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), щоб перетворити ваш GitHub проєкт на самостійний репозиторій чартів Helm. Вона виконує це під час кожної операції push в гілку `main` шляхом перевірки кожного чарту у вашому проєкті, і коли знаходить нову версію чарту, створює відповідний реліз GitHub, додає артефакти Helm чарту до релізу і створює або оновлює файл `index.yaml` з метаданими про ці релізи, який потім хоститься на GitHub Pages. Версія Chart Releaser Action, використана в наведеному прикладі, — `v1.7.0`. Ви можете змінити її на [останню доступну версію](https://github.com/helm/chart-releaser-action/releases). :::note Chart Releaser Action майже завжди використовується в парі з [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) та [Kind Action](https://github.com/marketplace/actions/kind-cluster). ::: ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/howto/chart_repository_sync_example.md ================================================ --- title: Синхронізація вашого репозиторію чартів description: Описує, як синхронізувати ваші локальні та віддалені репозиторії чартів. sidebar_position: 2 --- :::note Цей приклад для хмарного сховища Google (Google Cloud Storage, GCS), кошик якого використовується як репозиторій чартів. ::: ## Попередні умови {#prerequisites} * Встановіть [gsutil](https://cloud.google.com/storage/docs/gsutil). *Ми значною мірою покладаємося на використання gsutil rsync.* * Переконайтеся, що у вас є доступ до бінарного файлу Helm. * _Опціонально: Ми рекомендуємо увімкнути [версіювання обʼєктів](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) у вашому сховищі GCS, на випадок, якщо ви випадково щось видалите._ ## Налаштування локальної теки репозиторію чартів {#set-up-a-local-chart-repository-directory Створіть локальну теку, як ми це робили в [керівництві з репозиторію чартів](/topics/chart_repository.md), і помістіть ваші упаковані чарти в цю теку. Наприклад: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Генерація оновленого файлу index.yaml {#generate-an-updated-index.yaml} Використовуйте Helm для генерації оновленого файлу index.yaml, передавши шлях до теки та URL-адресу віддаленого репозиторію команді `helm repo index`, як показано нижче: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Це згенерує оновлений файл index.yaml і помістить його в теку `fantastic-charts/`. ## Синхронізація ваших локальних та віддалених репозиторіїв чартів {#sync-your-local-and-remote-chart-repositories} Завантажте вміст теки у ваше сховище GCS, запустивши `scripts/sync-repo.sh` та передавши назву локальної теки та назву сховища GCS. Наприклад: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Оновлення вашого репозиторію чартів {#updating-your-chart-repository} Ви захочете зберегти локальну копію вмісту вашого репозиторію чартів або використати `gsutil rsync` для копіювання вмісту вашого віддаленого репозиторію чартів до локальної теки. Наприклад: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # прапорець -n виконує пробний запуск Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # виконує дії копіювання Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Корисні посилання: * Документація [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Керівництво репозиторію чартів](/topics/chart_repository.md) * Документація щодо [версіювання обʼєктів та керування паралельністю](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) в Google Cloud Storage ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/howto/charts_tips_and_tricks.md ================================================ --- title: Поради та підказки щодо створення чартів description: Містить деякі поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості. sidebar_position: 1 --- Цей посібник містить поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості. ## Знайомство з функціями шаблону {#know-your-template-functions} Helm використовує [шаблони Go](https://godoc.org/text/template) для шаблонування ваших ресурсних файлів. Хоча Go поставляється з кількома вбудованими функціями, ми додали багато інших. По-перше, ми додали всі функції з [бібліотеки Sprig](https://masterminds.github.io/sprig/), за винятком `env` та `expandenv`, з міркувань безпеки. Ми також додали дві спеціальні функції шаблонів: `include` і `required`. Функція `include` дозволяє додавати інший шаблон і передавати результати іншим функціям шаблонів. Наприклад, цей фрагмент шаблону включає шаблон з назвою `mytpl`, потім приводить результат у нижньому регістрі та огртає його подвійними лапками. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` Функція `required` дозволяє оголосити певне значення як обовʼязкове для рендерингу шаблону. Якщо значення порожнє, рендеринг шаблону завершиться з помилкою, про яку буде повідомлено користувачеві. Наступний приклад використання функції `required` оголошує запис для `.Values.who` обовʼязковим і виводить повідомлення про помилку, якщо цього запис відсутній: ```yaml value: {{ required "Потрібен запис .Values.who!" .Values.who }} ``` ## Використовуйте лапки для рядків, не використовуйте лапки для цілих чисел {#quote-strings-dont-quote-integers} Коли ви працюєте з рядковими даними, завжди безпечніше використовувати лапки для рядків, ніж залишати їх без лапок: ```yaml name: {{ .Values.MyName | quote }} ``` Але при роботі з цілими числами _не беріть значення в лапки._ Це може викликати помилки розбору значень всередині Kubernetes. ```yaml port: {{ .Values.Port }} ``` Це зауваження не стосується значень змінних середовища, які повинні бути рядками, навіть якщо вони представляють цілі числа: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Використання функції 'include' {#using-the-include-function} Go надає спосіб включати один шаблон в інший за допомогою вбудованої директиви `template`. Однак вбудована функція не може використовуватися в конвеєрах шаблонів Go. Щоб включити шаблон і виконати операцію з його результатом, Helm має спеціальну функцію `include`: ```go {{ include "toYaml" $value | indent 2 }} ``` Вищезазначене включає шаблон з назвою `toYaml`, передає йому `$value`, а потім передає результат з цього шаблону у функцію `indent`. Оскільки в YAML важливі відступи, це чудовий спосіб включати фрагменти коду, зберігаючи відступи в релевантному контексті. ## Використання функції 'required' {#using-the-required-function} Go надає можливість налаштування опцій шаблону для контролю поведінки, коли map індексується за допомогою ключа, якого немає в map. Зазвичай це налаштовується за допомогою `template.Options("missingkey=option")`, де `option` може бути `default`, `zero` або `error`. Якщо встановити цю опцію на error, виконання зупиниться з помилкою, але це стосуватиметься кожного відсутнього ключа в map. Можуть бути ситуації, коли розробник чарту хоче застосувати цю поведінку для вибраних значень у файлі `values.yaml`. Функція `required` дає розробникам можливість оголосити значення обовʼязковим для роботи в шаблоні. Якщо значення відсутнє в `values.yaml`, шаблон повертає повідомлення про помилку, надане розробником. Наприклад: ```go {{ required "A valid foo is required!" .Values.foo }} ``` Наведена вище конструкція використає шаблон, коли `.Values.foo` визначено, але не зможе це зробити та вийде з помилкою, коли `.Values.foo` не визначено. ## Використання функції 'tpl' {#using-the-tpl-function} Функція `tpl` дозволяє розробникам обробляти рядки як шаблони всередині шаблону. Це корисно для передачі рядка шаблону як значення до чарту або для рендерингу зовнішніх файлів конфігурації. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}` Приклади: ```yaml # значення template: "{{ .Values.name }}" name: "Tom" # шаблон {{ tpl .Values.template . }} # результат Tom ``` Створення зовнішнього файлу конфігурації: ```yaml # зовнішній конфігураційний файл conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # значення firstName: Peter lastName: Parker # шаблон {{ tpl (.Files.Get "conf/app.conf") . }} # результат firstName=Peter lastName=Parker ``` ## Створення секретів для отримання образів {#creating-image-pull-secrets} Секрети для отримання образів по суті є комбінацією _registry_, _username_ та _password_. Вони можуть знадобитися у застосунку, який ви розгортаєте, але для їх створення потрібно кілька разів запустити `base64`. Ми можемо написати допоміжний шаблон, щоб скласти файл конфігурації Docker для використання у вигляді даних для секрету. Ось приклад: По-перше, припустимо, що облікові дані визначені у файлі `values.yaml` наступним чином: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Ми визначаємо наш допоміжний шаблон наступним чином: ```go {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":\"%s\",\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username .password .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Нарешті, ми використовуємо допоміжний шаблон у більшому шаблоні для створення маніфесту Secret: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Автоматичне викатування розгортань {#automatically-roll-deployments} Часто ConfigMaps або Secrets підключаються як конфігураційні файли в контейнери або є інші зовнішні зміни залежностей, які вимагають перезапуску podʼів. Залежно від застосунку, перезапуск може знадобитися, якщо вони оновлюються при наступному `helm upgrade`, але якщо самі специфікації deployment не змінюються, застосунок продовжує працювати зі старою конфігурацією, що призводить до неконсистентного deployment. Функція `sha256sum` може бути використана для забезпечення оновлення секції анотацій розгортання, якщо змінюється інший файл: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` :::note Якщо ви додаєте це до бібліотечного чарту, ви не зможете отримати доступ до вашого файлу в `$.Template.BasePath`. Замість цього можна посилатися на ваше визначення за допомогою `{{ include ("mylibchart.configmap") . | sha256sum }}`. ::: У випадку, коли ви завжди хочете перезапустити свій deployment, ви можете використати аналогічний крок з анотацією, як вище, замінивши його випадковим рядком, щоб він завжди змінювався і викликав перезапуск deployment: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Кожен виклик функції шаблону генеруватиме унікальний випадковий рядок. Це означає, що якщо необхідно синхронізувати випадкові рядки, що використовуються декількома ресурсами, всі відповідні ресурси повинні бути в одному файлі шаблону. Обидва ці методи дозволяють вашому deployment використовувати вбудовану логіку стратегії оновлення, щоб уникнути простоїв. :::note Раніше ми рекомендували використовувати прапорець `--recreate-pods` як інший варіант. Цей прапорець було позначено застарілим у Helm 3 на користь більш декларативного методу, описаного вище. ::: ## Скажіть Helm не видаляти ресурс {#tell-helm-not-to-uninstall-a-resource} Іноді є ресурси, які не слід видаляти під час виконання команди `helm uninstall`. Розробники чартів можуть додати анотацію до ресурсу, щоб запобігти його видаленню. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` Анотація `helm.sh/resource-policy: keep` говорить Helm не видаляти цей ресурс, коли операція Helm (така як `helm uninstall`, `helm upgrade` або `helm rollback`) призвела б до його видалення. _Однак_, цей ресурс стає сиротою. Helm більше не керує ним у будь-який спосіб. Це може призвести до проблем, якщо використовувати `helm install --replace` для релізу, який вже був видалений, але зберіг ресурси. ## Використання "Partials" та включень шаблонів {#using-partials-and-template-includes} Іноді ви хочете створити в чарті деякі повторно використовувані частини, будь то блоки або часткові шаблони. І часто зручніше зберігати їх у власних файлах. У теці `templates/`, будь-який файл, що починається з підкреслення (`_`), не призначений для виведення файлу маніфесту Kubernetes. Таким чином, за домовленістю, допоміжні шаблони та частки шаблонів розміщуються у файлі `_helpers.tpl`. ## Комплексні чарти з багатьма залежностями {#complex-charts-with-many-dependencies} Багато чартів у CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є "будівельними блоками" для створення складніших застосунків. Але чарти можуть бути використані для створення екземплярів великомасштабних застосунків. У таких випадках один основний чарт може мати декілька вкладених субчартів, кожен з яких функціонує як частина цілого. Найкращою практикою для збирання комплексного застосунку з окремих частин є створення основного чарту, який надає глобальні конфігурації, а потім використання підтеки `charts/` для вбудовування кожного з компонентів. ## YAML — це надмножина JSON {#yaml-is-a-superset-of-json} Згідно зі специфікацією YAML, YAML є надмножиною JSON. Це означає, що будь-яка допустима структура JSON має бути дійсною в YAML. Це має перевагу: іноді розробникам шаблонів може бути простіше виразити структуру даних з синтаксисом, схожим на JSON, ніж мати справу з чутливістю YAML до пробілів. Як правило, шаблони повинні відповідати синтаксису, схожому на YAML, _якщо_ синтаксис JSON суттєво не знижує ризик виникнення проблем з форматуванням. ## Будьте обережні з генерацією випадкових значень {#be-careful-with-generating-random-values} У Helm є функції, які дозволяють генерувати випадкові дані, криптографічні ключі тощо. Вони цілком придатні для використання. Але майте на увазі, що під час оновлень шаблони виконуються знову. Коли виконання шаблону генерує дані, що відрізняються від останнього виконання, це викликає оновлення цього ресурсу. ## Встановлення або оновлення релізу однією командою {#install-or-upgrade-a-release-with-one-command} Helm надає можливість виконати встановлення або оновлення як одну команду. Використовуйте команду `helm upgrade` з прапорцем `--install`. Це змусить Helm перевірити, чи реліз вже встановлено. Якщо ні, буде виконано встановлення. Якщо так, то наявний реліз буде оновлено. ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/howto/index.mdx ================================================ --- title: Поради sidebar_position: 3 --- # Поради Тут ви знайдете короткі відповіді на питання типу «Як я можу….?» Ці посібники не охоплюють теми в деталях — ви знайдете такі матеріали в [Тематичних посібниках](/topics/index.mdx). Однак ці посібники допоможуть вам швидко виконати поширені завдання. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/index.mdx ================================================ --- title: Документація description: Все, що вам потрібно знати про те, як організована документація. sidebar_position: 1 --- # Ласкаво просимо Ласкаво просимо до документації [Helm](https://helm.sh/). Helm — це менеджер пакетів для Kubernetes. Детальну інформацію про нього можна знайти у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/). import DocCardList from "@theme/DocCardList"; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/intro/CheatSheet.mdx ================================================ --- title: Шпаргалка description: Шпаргалка Helm sidebar_position: 4 --- import Helm4 from "../_v4-in-progress.mdx" Підказки Helm з усіма необхідними командами для керування застосунками за допомогою Helm. --- ### Основні інтерпретації/контекст {#basic-interpretationscontext} **Chart (Чарт):** - Це назва вашого чарту у випадку, якщо його було завантажено та розпаковано. - Це `/`, якщо репозиторій був доданий, але чарт не завантажений. - Це URL/Абсолютний шлях до чарту. **Name (Назва):** - Це назва, яку ви хочете надати вашій поточній установці Helm-чарту. **Release (Реліз):** - Це назва, яку ви присвоїли екземпляру установки. **Revision (Версія):** - Це значення з команди Helm history. **Repo-name (Назва репозиторію):** - Назва репозиторію. **DIR (Тека):** - Назва/шлях теки. --- ### Управління чартами {#chart-management} ```bash helm create # Cтворює теку чарту разом з загальними файлами та теками, які використовуються в чарті. helm package # Упаковує чарт у файл архіву з версією. helm lint # Запускає тести для перевірки чарту та виявлення можливих проблем. helm show all # Переглядає чарт та виводить його вміст. helm show values # Показує вміст файлу values.yaml. helm pull # Завантажує/витягує чарт. helm pull --untar=true # Якщо встановлено в true, розпаковує чарт після завантаження. helm pull --verify # Перевіряє пакет перед використанням. helm pull --version # Стандартно використовується остання версія, вкажіть обмеження версії для використання чарту. helm dependency list # Відображає список залежностей чарту. ``` --- ### Встановлення та видалення застосунків {#install-and-uninstall-apps} ```bash helm install # Встановлює чарт з зазначеною назвою. helm install --namespace # Встановлює чарт у певному просторі імен. helm install --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень, розділених комами). helm install --values # Встановлює чарт з вказаними вами значеннями. helm install --dry-run --debug # Запускає тестове встановлення для перевірки чарту. helm install --verify # Перевіряє пакет перед використанням. helm install --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. helm uninstall # Видаляє реліз з поточного (default) простору імен helm uninstall --namespace # Видаляє реліз із зазначеного простору імен ``` --- ### Оновлення та відкат застосунків {#perform-app-upgrade-and-rollback} ```bash helm upgrade # Оновлює реліз. helm upgrade --atomic # Якщо встановлено, процес оновлення поверне зміни в разі невдалого оновлення. helm upgrade --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. helm upgrade --version # Вказує обмеження версії для використання чарту. helm upgrade --values # Вказує значення у YAML файлі або URL (можна вказати кілька). helm upgrade --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень). helm upgrade --force # Примусове оновлення ресурсів з використанням стратегії заміни. helm rollback # Повертає реліз до певної версії. helm rollback --cleanup-on-fail # Дозволяє видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдалося здійснити. ``` --- ### Вивід списку, додавання, видалення та оновлення репозиторіїв {#list-add-remove-and-update-repositories} ```bash helm repo add # Додає репозиторій з Інтернету. helm repo list # Переглядає список доданих репозиторіїв чартів. helm repo update # Оновлює інформацію про доступні чарти локально з репозиторіїв чартів. helm repo remove # Видаляє один або кілька репозиторіїв чартів. helm repo index # Читає поточну теку та генерує файл індексу на основі знайдених чартів. helm repo index --merge # Зливає згенерований індекс з наявним файлом індексу. helm search repo # Шукає в репозиторіях за ключовим словом в чарті. helm search hub # Шукає чарт в Artifact Hub або у вашому власному хабі. ``` --- ## Моніторинг релізів Helm {#helm-release-monitoring} ```bash helm list # Виводить список всіх релізів для вказаного простору імен, використовує поточний контекст простору імен, якщо простір імен не вказано. helm list --all # Показує всі релізи без жодних фільтрів, можна використовувати -a. helm list --all-namespaces # Переглядає релізи по всіх просторах імен, можна використовувати -A. helm list -l key1=value1,key2=value2 # Селектор (запит за мітками) для фільтрації, підтримує '=', '==' і '!='. helm list --date # Сортує за датою релізу. helm list --deployed # Показує розгорнуті релізи. Якщо не вказано інше, це буде автоматично увімкнено. helm list --pending # Показує очікуючі релізи. helm list --failed # Показує невдалі релізи. helm list --uninstalled # Показує видалені релізи (якщо використовувався 'helm uninstall --keep-history'). helm list --superseded # Показує замінені релізи. helm list -o yaml # Виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table). helm status # Ця команда показує статус зазначеного релізу. helm status --revision # Якщо встановлено, показує статус зазначеного релізу з версією. helm history # Історичні версії для даного релізу. helm env # Env виводить всю інформацію про середовище, що використовується Helm. ``` --- ### Завантаження інформації про реліз {#download-release-information} ```bash helm get all # Зручний для сприйняття набір інформації про нотатки, хуки, надані значення та згенерований маніфест-файл даного релізу. helm get hooks # Завантажує хуки для вказаного релізу. Хуки форматує у YAML і розділяє за допомогою роздільника YAML '---\n'. helm get manifest # Маніфест — це представлення ресурсів Kubernetes у форматі YAML, які були згенеровані з чартів цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені до маніфесту. helm get notes # Показує нотатки, надані чартом для зазначеного релізу. helm get values # Завантажує файл значень для даного релізу. Використовуйте -o для форматування виводу. ``` --- ### Управління втулками {#plugin-management} ```bash helm plugin install # Встановлення втулків. helm plugin list # Перегляд списку всіх встановлених втулків. helm plugin update # Оновлення втулків. helm plugin uninstall # Видалення втулка. ``` --- ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/intro/index.mdx ================================================ --- title: Вступ sidebar_position: 2 --- # Вступ до Helm Ви не знайомі з Helm? Тоді почніть звідси! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/intro/install.mdx ================================================ --- title: Встановлення Helm description: Дізнайтеся, як встановити та почати працювати з Helm. sidebar_position: 2 --- Цей посібник показує, як встановити Helm CLI. Helm можна встановити або з вихідного коду, або з попередньо скомпільованих бінарних випусків. ## Від проєкту Helm {#from-the-helm-project} Проєкт Helm пропонує два способи завантаження та встановлення Helm. Це офіційні методи отримання випусків Helm. Крім того, спільнота Helm пропонує методи встановлення Helm за допомогою різних менеджерів пакетів. Інформацію про встановлення за допомогою цих методів можна знайти нижче за офіційними методами. ### З бінарних випусків {#from-the-binary-releases} Кожен [випуск](https://github.com/helm/helm/releases) Helm надає бінарні випуски для різних операційних систем. Ці бінарні версії можна завантажити та встановити вручну. 1. Завантажте [бажану версію](https://github.com/helm/helm/releases) 2. Розпакуйте її (`tar -zxvf helm-v4.0.0-linux-amd64.tar.gz`) 3. Знайдіть бінарний файл `helm` у розпакованій теці та перемістіть його у потрібне місце (`mv linux-amd64/helm /usr/local/bin/helm`) Після цього ви зможете запустити клієнта та [додати стабільне сховище чартів](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Примітка:** Автоматизовані тести Helm виконуються лише для Linux AMD64 під час GitHub Actions збірок та випусків. Тестування інших операційних систем є відповідальністю спільноти, якій потрібен Helm для цієї операційної системи. ### Зі скрипту {#from-script} Helm має скрипт встановлення, який автоматично завантажує останню версію Helm і [встановлює її локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4). Ви можете завантажити цей скрипт, а потім виконати його локально. Він добре задокументований, щоб ви могли ознайомитися з ним і зрозуміти, що він робить перед його запуском. ```console $ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 $ chmod 700 get_helm.sh $ ./get_helm.sh ``` Так, ви можете виконати команду `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash`, якщо хочете ризикнути. ## Через менеджери пакетів {#through-package-managers} Спільнота Helm надає можливість встановлювати Helm через менеджери пакетів операційної системи. Вони не підтримуються проєктом Helm і не вважаються надійними постачальниками. ### За допомогою Homebrew (macOS) {#from-homebrew-macos} Члени спільноти Helm зробили свій внесок у створення формули Helm для Homebrew. Ця формула, як правило, є актуальною. ```console brew install helm ``` (Примітка: Існує також формула для emacs-helm, який є іншим проєктом.) ### За допомогою Chocolatey (Windows) {#from-chocolatey-windows} Члени спільноти Helm зробили свій внесок у створення [пакета Helm](https://chocolatey.org/packages/kubernetes-helm) для [Chocolatey](https://chocolatey.org/). Цей пакет, як правило, є актуальним. ```console choco install kubernetes-helm ``` ### За допомогою Scoop (Windows) {#from-scoop-windows} Члени спільноти Helm зробили свій внесок у створення [пакета Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) для [Scoop](https://scoop.sh). Цей пакет, як правило, є актуальним. ```console scoop install helm ``` ### За допомогою Winget (Windows) {#from-winget-windows} Члени спільноти Helm зробили свій внесок у створення [пакета Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) для [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Цей пакет, як правило, є актуальним. ```console winget install Helm.Helm ``` ### За допомогою Apt (Debian/Ubuntu) {#from-apt-debianubuntu} Члени спільноти Helm зробили свій внесок у створення пакета Apt для Debian/Ubuntu. Цей пакет, як правило, є актуальним. Дякуємо [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) за підтримку репозиторію. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### За допомогою dnf/yum (fedora) {#from-dnfyum-fedora} З Fedora 35 Helm доступний у офіційному репозиторії. Ви можете встановити Helm, виконавши: ```console sudo dnf install helm ``` ### За допомогою Snap {#from-snap} Спільнота [Snapcrafters](https://github.com/snapcrafters) підтримує версію Snap пакета [Helm](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### За допомогою pkg (FreeBSD) {#from-pkg-freebsd} Члени спільноти FreeBSD зробили свій внесок у створення пакета [Helm](https://www.freshports.org/sysutils/helm) для [FreeBSD Ports Collection](https://man.freebsd.org/ports). Цей пакет, як правило, є актуальним. ```console pkg install helm ``` ### Збірки для розробки {#development-builds} Окрім випусків, ви можете завантажити або встановити зліпки Helm для розробки. ### Збірки Canary {#from-canary-builds} «Canary» — це версії програмного забезпечення Helm, створені на основі останньої гілки «main». Вони не є офіційними релізами і можуть бути нестабільними. Однак вони дають можливість протестувати найновіші функції. Бінарні файли Canary Helm зберігаються на сайті [get.helm.sh](https://get.helm.sh). Ось посилання на найпоширеніші версії: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### Збірки з сирців (Linux, macOS) {#from-source-linux-macos} Створення Helm з сирців вимагає трохи більше зусиль, але це найкращий спосіб, якщо ви хочете протестувати останню версію Helm. У вас повинно бути налаштоване середовище Go. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` За необхідності, буде отримано залежності та збережено їх у кеші, а також перевірено конфігурацію. Потім буде скомпільовано `helm` та розміщено його у `bin/helm`. ## Підсумки {#conclusion} У більшості випадків встановлення є таким же простим, як отримання готового бінарного файлу `helm`. Цей документ охоплює додаткові випадки для тих, хто хоче робити складніші речі з Helm. Після успішного встановлення клієнта Helm ви можете перейти до використання Helm для управління чартами та [додавання репозиторію стабільних чартів](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/intro/quickstart.md ================================================ --- title: Швидкий старт description: Як встановити та розпочати роботу з Helm, включаючи інструкції для дистрибутивів, поширені запитання та втулки. sidebar_position: 1 --- Цей посібник описує, як швидко розпочати роботу з Helm. ## Передумови {#prerequisites} Для успішного та належного використання Helm необхідні такі передумови. 1. Кластер Kubernetes 2. Визначення конфігурацій безпеки, які слід застосувати до вашого встановлення, якщо такі є 3. Встановлення та налаштування Helm. ### Встановіть Kubernetes або отримайте доступ до кластера {#install-kubernetes-or-have-access-to-a-cluster} - Ви повинні мати встановлений Kubernetes. Для останньої версії Helm ми рекомендуємо останню стабільну версію Kubernetes, яка в більшості випадків є передостанньою мінорною версією. - Ви також повинні мати локальну налаштовану копію `kubectl`. Дивіться [Політику підтримки версій Helm](https://helm.sh/docs/topics/version_skew/) для отримання інформації про максимальну розбіжність версій, що підтримується між Helm і Kubernetes. ## Встановіть Helm {#install-helm} Завантажте бінарну версію клієнта Helm. Ви можете скористатися такими інструментами, як `homebrew`, або переглянути [офіційну сторінку випусків](https://github.com/helm/helm/releases). Більш детальну інформацію та інші варіанти дивіться в [посібнику з встановлення](/intro/install.mdx). ## Ініціалізуйте репозиторій чартів Helm {#initialize-a-helm-chart-repository} Після підготовки Helm ви можете додати репозиторій чартів. Перевірте [Artifact Hub](https://artifacthub.io/packages/search?kind=0), щоб дізнатися про доступні репозиторії чартів Helm. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Після встановлення ви зможете переглянути список чартів, які можна встановити: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Встановіть демонстраційний чарт {#install-an-example-chart} Щоб встановити чарт, можна виконати команду `helm install`. Helm має кілька способів пошуку та встановлення чартів, але найпростіший — це використання чартів `bitnami`. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` У наведеному вище прикладі було встановлено чарт `bitnami/mysql`, а назва нашого нового релізу — `mysql-1612624192`. Ви можете отримати загальне уявлення про функції цього чарту MySQL, виконавши команду `helm show chart bitnami/mysql`. Або ви можете виконати команду `helm show all bitnami/mysql`, щоб отримати всю інформацію про чарт. Кожного разу, коли ви встановлюєте чарт, створюється новий реліз. Отже, один чарт можна встановити кілька разів в один і той самий кластер. І кожним з них можна керувати та оновлювати незалежно. Команда `helm install` — це дуже потужна команда з багатьма можливостями. Щоб дізнатися більше про неї, перегляньте [Посібник з використання Helm](/intro/using_helm.mdx). ## Дізнайтеся про релізи {#learn-about-releases} За допомогою Helm легко побачити, що було встановлено: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` Функція `helm list` (або `helm ls`) покаже вам список усіх розгорнутих релізів. ## Видалення релізу {#uninstall-a-release} Щоб видалити реліз, скористайтеся командою `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Це видалить `mysql-1612624192` з Kubernetes, що призведе до видалення всіх ресурсів, повʼязаних з релізом, а також історії релізів. Якщо вказано прапорець `--keep-history`, історія релізів буде збережена. Ви зможете запитувати інформацію про цей реліз: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Оскільки Helm відстежує ваші релізи навіть після їх видалення, ви можете перевіряти історію кластера і навіть відновлювати релізи (за допомогою команди `helm rollback`). ## Ознайомлення з довідкою {#reading-the-help-text} Щоб дізнатися більше про доступні команди Helm, скористайтеся командою `helm help` або введіть команду, додавши до неї прапорець `-h`: ```console $ helm get -h ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/intro/using_helm.mdx ================================================ --- title: Використання Helm description: Описує основи роботи з Helm. sidebar_position: 3 --- import Helm4 from "../_v4-in-progress.mdx" Цей посібник пояснює основи використання Helm для керування пакетами у вашому кластері Kubernetes. Передбачається, що ви вже [встановили](/intro/install.mdx) клієнт Helm. Якщо вас цікавить лише виконання кількох швидких команд, можливо, ви захочете почати з [Посібника зі швидкого старту](/intro/quickstart.md). У цьому розділі розглядаються особливості команд Helm та пояснюється, як використовувати Helm. ## Три головні концепції {#three-big-concepts} *Chart* — це пакет Helm. Він містить усі необхідні визначення ресурсів для запуску застосунку, інструменту або сервісу всередині кластера Kubernetes. Думайте про це як про еквівалент формули Homebrew, пакету Apt dpkg або файлу Yum RPM для Kubernetes. *Repository* — це місце, де можна зібрати та поділитися чартами. Це як [архів CPAN](https://www.cpan.org) для Perl або [база пакетів Fedora](https://src.fedoraproject.org/), але для пакетів Kubernetes. *Release* — це екземпляр чарту, що працює в кластері Kubernetes. Один чарт можна встановити в кластер кілька разів. І кожного разу при встановленні створюється новий *реліз*. Наприклад, чарт MySQL. Якщо ви хочете, щоб у вашому кластері працювали дві бази даних, ви можете встановити цей чарт двічі. Кожен екземпляр матиме свій *реліз*, а також своє *імʼя релізу*. Маючи ці концепції на увазі, можна пояснити Helm так: Helm встановлює *чарти* у Kubernetes, створюючи новий *реліз* для кожного встановлення. А щоб знайти нові чарти, ви можете шукати їх у репозиторіях *чартів* Helm. ## 'helm search': Пошук чартів {#helm-search-finding-charts} Helm постачається з потужною командою пошуку. Її можна використовувати для пошуку двох типів джерел: - `helm search hub` здійснює пошук у [Artifact Hub](https://artifacthub.io), який містить чарти helm із десятків різних репозиторіїв. - `helm search repo` здійснює пошук у репозиторіях, які ви додали до свого локального клієнта helm (за допомогою `helm repo add`). Цей пошук здійснюється за локальними даними, і підключення до публічної мережі не потрібно. Ви можете знайти загальнодоступні чарти, виконавши команду `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` Вищенаведений пошук знаходить усі чарти `wordpress` в Artifact Hub. Без фільтрації `helm search hub` показує всі доступні чарти. `helm search hub` показує URL-адресу розташування на [artifacthub.io](https://artifacthub.io/), але не власне репозиторій Helm. `helm search hub --list-repo-url` показує фактичну URL-адресу репозиторію Helm, що може бути корисним, коли ви хочете додати новий репозиторій: `helm repo add [NAME] [URL]`. За допомогою `helm search repo` ви можете знайти імена чартів у репозиторіях, які ви вже додали: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search використовує алгоритм нечіткого порівняння рядків, тому можна вводити частини слів або фраз: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Пошук — це чудовий спосіб знайти доступні пакети. Коли ви знайшли потрібний пакет, можете використовувати `helm install`, щоб встановити його. ## 'helm install': Встановлення пакета {#helm-install-installing-a-package} Щоб встановити новий пакет, скористайтеся командою `helm install`. У найпростішому випадку вона приймає два аргументи: потрібне вам імʼя релізу та імʼя чарту, який ви хочете встановити. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Будь ласка, будьте терплячими, поки чарт розгортається ** Доступ до вашого сайту WordPress можна отримати у вашому кластері за допомогою наступного імені DNS: happy-panda-wordpress.default.svc.cluster.local (port 80) Щоб отримати доступ до вашого сайту WordPress з-за меж кластера, виконайте наступні кроки: 1. Отримайте URL WordPress, виконавши наступні команди: ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer. Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL. 3. Увійдіть за допомогою наступних облікових даних: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` :::info ☝️ Тут і далі по тексту переклад українською виводу в терміналі надано для зручності сприйняття. Скоріше за все він буде відсутній в реальному застосуванні. ::: Тепер чарт `wordpress` встановлено. Зверніть увагу, що встановлення чарту створює новий обʼєкт *реліз*. Реліз вище називається `happy-panda`. (Якщо ви хочете, щоб Helm згенерував імʼя для вас, не вказуйте імʼя релізу і використовуйте `--generate-name`.) Під час встановлення клієнт `helm` надасть корисну інформацію про те, які ресурси були створені, який стан релізу, і чи є додаткові кроки конфігурації, які ви можете або повинні виконати. Helm встановлює ресурси в наступному порядку: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm не чекає, поки всі ресурси будуть запущені, перш ніж завершити роботу. Багато чартів потребують Docker-образів розміром понад 600MB, і їхнє встановлення в кластер може тривати певний час. Щоб відстежувати стан релізу або повторно прочитати конфігураційну інформацію, ви можете використати команду `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Будь ласка, будьте терплячими, поки чарт розгортається ** Доступ до вашого сайту WordPress можна отримати у вашому кластері за допомогою наступного імені DNS: happy-panda-wordpress.default.svc.cluster.local (port 80) Щоб отримати доступ до вашого сайту WordPress з-за меж кластера, виконайте наступні кроки: 1. Отримайте URL WordPress, виконавши наступні команди: ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer. Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL. 3. Увійдіть за допомогою наступних облікових даних: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Вищенаведене показує поточний стан вашого релізу. ### Налаштування чарту перед встановленням {#customizing-the-chart-before-installing} Встановлення у спосіб, який ми розглянули, використовуватиме лише стандартні параметри конфігурації для цього чарту. У багатьох випадках вам захочеться налаштувати чарт для використання ваших налаштувань. Щоб побачити, які параметри можна налаштувати в чарті, використовуйте команду `helm show values`: ```console $ helm show values bitnami/wordpress ## Глобальні параметри образу Docker ## Зверніть увагу, що це замінить параметри образу, включаючи залежності, налаштовані для використання глобальних значень. ## Наразі доступні такі глобальні параметри образу Docker: imageRegistry та imagePullSecrets. ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Версія образу Bitnami WordPress ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Ви можете перевизначити будь-які з цих налаштувань у файлі у форматі YAML, а потім передати цей файл під час встановлення. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Вищенаведене створить стандартного користувача MariaDB з імʼям `user0` і надасть цьому користувачеві доступ до новоствореної бази даних `user0db`, але всі інші параметри цього чарту залишаться стандартними. Існує два способи передати дані конфігурації під час встановлення: - `--values` (або `-f`): Вказати YAML-файл із перевизначеннями. Їх можна вказувати кілька разів, причому файл, що стоїть праворуч, матиме пріоритет - `--set`: Вказати перевизначення в командному рядку. Якщо обидва варіанти використовуються, значення `--set` зливаються з `--values` з вищим пріоритетом. Перевизначення, зазначені за допомогою `--set`, зберігаються у Secret. Значення, що були встановлені через `--set`, можна переглянути для конкретного релізу за допомогою команди `helm get values `. Значення, встановлені за допомогою `--set`, можна скинути, виконавши `helm upgrade` з параметром `--reset-values`. #### Формат і обмеження параметра `--set` {#the-format-and-limitations-of---set} Опція `--set` приймає нуль або більше пар імʼя/значення. У найпростішому випадку вона використовується так: `--set name=value`. Еквівалент у YAML виглядає так: ```yaml name: value ``` Кілька значень розділяються символами `,`. Отже, `--set a=b,c=d` стає: ```yaml a: b c: d ``` Підтримуються складніші вирази. Наприклад, `--set outer.inner=value` перетворюється на наступне: ```yaml outer: inner: value ``` Списки можна записати, включивши значення в `{` і `}`. Наприклад, `--set name={a, b, c}` перетворюється на: ```yaml name: - a - b - c ``` Деякі пари імʼя/ключ можна встановити як `null` або як порожній масив `[]`. Наприклад, `--set name=[],a=null` перетворює: ```yaml name: - a - b - c a: b ``` на ```yaml name: [] a: null ``` Починаючи з Helm 2.5.0, можна отримувати доступ до елементів списку, використовуючи синтаксис індексу масиву. Наприклад, `--set servers[0].port=80` стає: ```yaml servers: - port: 80 ``` Кілька значень можна встановити таким чином. Наприклад, рядок `--set servers[0].port=80,servers[0].host=example` перетворюється на: ```yaml servers: - port: 80 host: example ``` Іноді вам потрібно використовувати спеціальні символи у ваших рядках `--set`. Ви можете використовувати зворотний слеш для екранування символів; `--set name=value1\,value2` перетвориться на: ```yaml name: "value1,value2" ``` Аналогічно, можна екранувати послідовності крапок, що може знадобитися, коли чарти використовують функцію `toYaml` для аналізу анотацій, міток і вибору вузлів. Синтаксис для `--set nodeSelector."kubernetes\.io/role"=master`виглядає так: ```yaml nodeSelector: kubernetes.io/role: master ``` Глибоко вкладені структури даних може бути важко вказати використовуючи `--set`. Розробникам чартів рекомендується враховувати використання `--set` при розробці формату файлу `values.yaml` (докладніше про [Файли значень](/chart_template_guide/values_files.mdx)). ### Інші методи встановлення {#more-installation-methods} Команда `helm install` може встановлювати чарт із кількох джерел: - Репозиторій чартів (як ми бачили вище) - Локальний архів чарту (`helm install foo foo-0.1.1.tgz`) - Тека із розпакованим чартом (`helm install foo path/to/foo`) - Повний URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' та 'helm rollback': Оновлення релізу та відновлення у разі невдачі {#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure} Коли виходить нова версія чарту або коли ви хочете змінити конфігурацію вашого релізу, ви можете скористатися командою `helm upgrade`. Оновлення бере поточний реліз і оновлює його відповідно до інформації, що міститься в чарті. Оскільки чарти Kubernetes можуть бути великими та складними, Helm намагається виконати найменш інвазивне оновлення. Він оновлюватиме лише ті елементи, які змінилися з моменту останнього релізу. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` У наведеному випадку реліз `happy-panda` оновлюється з використанням того ж чарту, але з новим YAML файлом: ```yaml mariadb.auth.username: user1 ``` Ми можемо використати команду `helm get values`, щоб переконатися, що нові налаштування набрали чинності. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` Команда `helm get` є корисним інструментом для перегляду релізу в кластері. І як ми бачили вище, вона показує, що наші нові значення з `panda.yaml` були розгорнуті в кластері. Тепер, якщо під час релізу щось піде не так, можна легко повернутися до попереднього релізу, використовуючи команду `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` Ця команда повертає наш реліз `happy-panda` до його першої версії. Версія релізу є інкрементною. Кожного разу, коли відбувається встановлення, оновлення або відкат, номер версії збільшується на 1. Перша версія завжди має номер 1. І ми можемо використовувати команду `helm history [RELEASE]`, щоб побачити номери версій для певного релізу. ## Корисні опції для Install/Upgrade/Rollback {#helpful-options-for-installupgraderollback} Є кілька інших корисних опцій, які можна вказати для налаштування поведінки Helm під час встановлення/оновлення/відкату. Зауважте, що це не повний список CLI-прапорців. Щоб побачити опис усіх прапорців, просто запустіть `helm --help`. - `--timeout`: Значення [Go duration](https://golang.org/pkg/time/#ParseDuration), яке визначає, скільки чекати на завершення команд Kubernetes. Стандартно `5m0s`. - `--wait`: Очікує, доки всі Podʼи не перейдуть у стан готовності, PVC не будуть повʼязані, а Deployment не матиме мінімальну кількість Podʼів у стані готовності (`Desired` мінус `maxUnavailable`), а Services отримає IP-адресу (і Ingress, якщо це `LoadBalancer`) перед тим, як визнати реліз успішним. Чекання триватиме стільки часу, скільки вказано в опції `--timeout`. Якщо тайм-аут досягнуто, реліз буде позначено як `FAILED`. Примітка: У ситуаціях, коли Deployment має в `replicas` значення 1, а `maxUnavailable` не встановлено в 0 як частина стратегії rolling update, `--wait` поверне готовність, коли задоволено мінімальну кількість Podʼів у готовому стані. - `--no-hooks`: Пропускає запуск хуків для команди. - `--recreate-pods` (доступно лише для `upgrade` та `rollback`): Цей прапорець викличе повторне створення всіх Podʼів (за винятком Podʼів, що належать до Deployment). (Визнано застаріле в Helm 3) ## 'helm uninstall': Видалення релізу {#helm-uninstall-uninstalling-a-release} Коли настає час видалити реліз з кластера, використовуйте команду `helm uninstall`: ```console $ helm uninstall happy-panda ``` Це видалить реліз з кластера. Ви можете переглянути всі ваші поточні розгорнуті релізи за допомогою команди `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` З виводу вище ми можемо побачити, що реліз `happy-panda` було видалено. У попередніх версіях Helm, коли реліз видалявся, запис про його видалення залишався. У Helm 3 видалення також видаляє запис про реліз. Якщо ви хочете зберегти запис про видалений реліз, використовуйте `helm uninstall --keep-history`. Використання `helm list --uninstalled` покаже лише ті релізи, які були видалені з прапорцем `--keep-history`. Прапорець `helm list --all` покаже вам всі записи релізів, які зберіг Helm, включаючи записи про елементи, які зазнали збою або записи ппро видалені елементів (якщо було вказано `--keep-history`): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Зверніть увагу, що через те, що релізи тепер стандартно видаляються, більше неможливо зробити відкат до видаленого ресурсу. ## 'helm repo': Робота з репозиторіями {#helm-repo-working-with-repositories} Helm 3 більше не постачається зі стандартним репозиторієм чартів. Група команд `helm repo` надає команди для додавання, перегляду та видалення репозиторіїв. Ви можете переглянути, які репозиторії налаштовані, використовуючи `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Нові репозиторії можна додати за допомогою `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Оскільки репозиторії чартів часто змінюються, у будь-який момент ви можете переконатися, що ваш клієнт Helm актуальний, запустивши `helm repo update`. Репозиторії можна видалити за допомогою `helm repo remove`. ## Створення власних чартів {#creating-your-own-charts} [Посібник з розробки чартів](/topics/charts.mdx) пояснює, як створювати власні чарти. Але ви можете швидко розпочати, використовуючи команду `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Тепер у вас є чарт в теці `./deis-workflow`. Ви можете редагувати його та створювати власні шаблони. Коли ви редагуєте свій чарт, ви можете перевірити, чи він добре сформований, запустивши команду `helm lint`. Коли настане час упакувати чарт для розповсюдження, ви можете скористатися командою `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` І цей чарт тепер може бути легко встановлена за допомогою `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Упаковані чарти можуть бути завантажені в репозиторії чартів. Для отримання додаткової інформації дивіться документацію про [репозиторії чартів Helm](/topics/chart_repository.md). ## Висновки {#conclusion} У цьому розділі було розглянуто основні шаблони використання клієнта `helm`, включаючи пошук, встановлення, оновлення та видалення. Також було розглянуто корисні утиліти, такі як `helm status`, `helm get` і `helm repo`. Для отримання додаткової інформації про ці команди перегляньте вбудовану довідку Helm: `helm help`. У [наступному розділі](/howto/charts_tips_and_tricks.md) ми розглянемо процес створення чартів. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/overview.md ================================================ --- sidebar_position: 1 sidebar_label: Огляд Helm 4 --- # Огляд Helm 4 Helm v4 є значним кроком вперед порівняно з v3, запроваджуючи кардинальні зміни, нові архітектурні шаблони та розширену функціональність, зберігаючи при цьому зворотну сумісність чартів. Більш детальну інформацію про заплановані етапи випуску Helm 4 дивіться у статті [Шлях до випуску Helm v4](/blog/path-to-helm-v4/). ## Що нового {#whats-new} У цьому розділі наведено огляд нововведень у Helm 4, включаючи кардинальні зміни, основні нові функції та інші вдосконалення. Повні технічні деталі див. у [Повному переліку змін](changelog.md). ### Огляд {#summary} - **Нові функції**: втулки на основі Wasm, kstatus watcher, підтримка OCI digest, значення multi-doc, аргументи JSON - **Зміни в архітектурі**: повністю перероблена система втулків, реструктуризація пакетів, перейменування прапорців CLI, перехід на версійні пакети, підтримка chart v3, кешування на основі вмісту - **Модернізація**: міграція slog, оновлення до Go 1.24, очищення залежностей - **Безпека**: розширена підтримка OCI/реєстру, вдосконалення TLS ### Істотні зміни {#breaking-changes} #### Пострендери, реалізовані як втулки {#post-renderers-implemented-as-plugins} Пострендери реалізовані як втулки. З цією зміною більше неможливо передавати виконуваний файл безпосередньо до `helm render --post-renderer`, але необхідно передавати назву втулка. Це може вимагати оновлення наявних робочих процесів пострендера. #### Для входу в реєстр не приймаються повні URL-адреси {#registry-login-does-not-accept-full-urls} Команда `helm registry login` повинна виконуватися тільки з доменним імʼям у v4. Це необхідно для того, щоб у майбутньому можна було здійснювати вхід на різних рівнях реєстру. ### Нові функції {#new-features} #### Переробка системи втулків {#plugin-system-overhaul} Helm 4 представляє опціональну систему виконання на базі WebAssembly для підвищення безпеки та розширення можливостей. Наявні втулки продовжують працювати, але нова система виконання відкриває більше можливостей для налаштування базової поведінки Helm для налаштування втулків. Helm 4 запускається з трьома типами втулків: втулками CLI, втулками getter та втулками post-renderer, а також системою, яка дозволяє використовувати нові типи втулків для налаштування додаткових базових функцій. Дивіться [HIP-0026 plugin system](https://github.com/helm/community/blob/main/hips/hip-0026.md) та [Helm 4 example plugins](https://github.com/scottrigby/h4-example-plugins). :::tip Існуючі втулки працюють як і раніше. Нова система виконання WebAssembly є опціональною, але рекомендується для підвищення безпеки. ::: #### Кращий моніторинг ресурсів {#better-resource-monitoring} Нова інтеграція kstatus показує детальний статус ваших розгортань (deployments). Протестуйте її на комплексних застосунках, щоб перевірити, чи вона краще виявляє проблеми. #### Розширена підтримка OCI {#enhanced-oci-support} Встановлюйте чарти за допомогою дайджестів для кращої безпеки ланцюгів постачання. Наприклад, `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`. Чарти з невідповідними дайджестами не встановлюються. #### Значення з декількох документів {#multi-document-values} Розділіть комплексні значення між декількома файлами YAML. Ідеально підходить для тестування різних конфігурацій середовища. #### Застосування на стороні сервера {#server-side-apply} Краще вирішення конфліктів, коли кілька інструментів керують тими самими ресурсами. Тестуйте в середовищах з операторами або іншими контролерами. #### Функції у шаблонах користувачів {#custom-template-functions} Розширте можливості шаблонів Helm власними функціями за допомогою втулків. Чудово підходить для потреб організації у створенні шаблонів. #### Пострендери як втулки {#post-renderers-as-plugins} Пострендери реалізовані як втулки, що забезпечує кращу інтеграцію та більше можливостей. #### Стабільний SDK API {#stable-sdk-api} Зміни в API, що порушують сумісність, тепер завершені. Тестуйте, ламайте, давайте відгуки! API також підтримує додаткові версії чартів, відкриваючи можливості для нових функцій у майбутній версії Charts v3. #### Charts v3 Скоро. Чарти v2 продовжують працювати без змін. ### Покращення {#improvements} #### Продуктивність {#performance} Швидша обробка залежностей та нове кешування чартів на основі вмісту. #### Повідомлення про помилки {#error-messages} Більш чіткі та корисні повідомлення про помилки. #### Автентифікація в реєстрі {#registry-authentication} Краща підтримка OAuth та токенів для приватних реєстрів. #### Перейменовані прапорці CLI {#cli-flags-renamed} Деякі поширені прапорці CLI перейменовано, щоб краще пояснити їхню роботу. Наявні прапорці залишаються, але видають попередження про їхню застарілість: - `--atomic` → `--rollback-on-failure` - `--force` → `--force-replace` Оновіть будь-які автоматизації, які використовують ці перейменовані прапорці CLI. ## Оновлення до Helm 4 {#upgrading-to-helm-4} Хоча ми докладаємо всіх зусиль, щоб Helm 4 був надійним для всіх, Helm 4 є абсолютно новим. З цією метою перед оновленням ми додали нижче кілька порад щодо конкретних речей, на які слід звернути увагу під час тестування Helm 4 з вашими наявними робочими процесами. Як завжди, ми будемо вдячні за всі відгуки про те, що працює, що не працює і що можна покращити. ### Високий пріоритет {#high-priority} * Перевірте свої наявні чарти та випуски, щоб переконатися, що вони все ще працюють з v4. * Перевірте всі 3 типи втулків (CLI, getter, post-renderer). * Спробуйте створити втулки WebAssembly з новим середовищем виконання (дивіться [приклади втулків](https://github.com/scottrigby/h4-example-plugins)) * Користувачі SDK: протестуйте стабільний API. Спробуйте зламати його та поділіться своїми відгуками. * Протестуйте свої CI/CD- конвеєри та виправте будь-які помилки скриптів, повʼязані зі зміною імен прапорців CLI. * Протестуйте інтеграції post-renderer. * Протестуйте автентифікацію в реєстрі та встановлення чартів у ваших робочих процесах OCI. ### Інше {#other} * Випробуйте інші нові функції, зокрема значення для декількох документів, встановлення на основі дайджесту та функції налаштування шаблонів. * Випробуйте продуктивність Helm 4 із великими комплексними чартами, щоб перевірити, чи помітно пришвидшиться робота ваших робочих навантажень. * Спробуйте навмисно порушити роботу системи, щоб перевірити, чи корисні оновлені повідомлення про помилки. ### Відгуки {#feedback} * Які ще типи втулків ви хотіли б додати для налаштування основних функцій Helm? * З огляду на те, що API підтримує додаткові версії чартів, які нові функції ви хотіли б бачити в Charts v3? ## Як надати відгук {#how-to-give-feedback} Знайшли проблеми? Маєте пропозиції? Ми хочемо почути вашу думку до випуску в листопаді: ### GitHub Issues {#github-issues} Перегляньте [список відкритих питань та запитів на додавання функцій](https://github.com/helm/helm/issues) у репозиторії Helm. Додайте коментарі до наявних або [створіть нові](https://github.com/helm/helm/issues/new/choose) питання та запити. ### Slack спільноти {#community-slack} Приєднуйтесь до каналів в [Slack Kubernetes](https://slack.kubernetes.io/): - `#helm-dev` для обговорення питань розробки - `#helm-users` для підтримки користувачів та відгуків про тестування ### Щотижневі зустрічі розробників {#weekly-dev-meetings} Приєднуйтесь до живої дискусії з супровідниками щочетверга о 9:30 за тихоокеанським часом на [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09). Більше варіантів можна знайти в [інформації про комунікацію](https://github.com/helm/community/blob/main/communication.md) спільноти Helm. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/index.mdx ================================================ --- title: Посібник розробника втулків sidebar_label: Створення втулків sidebar_position: 3 --- import DocCardList from "@theme/DocCardList"; Для ознайомлення з концепціями втулків Helm, а також з тим, як структурувати та налаштовувати втулки, ознайомтеся з [Оглядом втулків](/plugins/overview.md). Цей розділ присвячений розробці втулків Helm — він містить [посібники](#tutorials), інструкції, довідники та додаткову інформацію для розробників щодо створення втулків Helm. :::info Вступ до кодової бази системи втулків буде розміщено на сторінці Втулки в розділі [Go SDK](/sdk/index.mdx) документації, яка зʼявиться найближчим часом! ::: ## Посібники {#tutorials} ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-cli-plugin.mdx ================================================ --- title: "Посібник: Створення втулків CLI" sidebar_label: Створення втулків CLI --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; Створіть команду `helm system-info`, яка виводить інформацію про систему. ## Subprocess Runtime Почнемо з створення втулка CLI з середовищем виконання Subprocess. ### Передумови {#prerequisites} 1. Встановіть останню версію Helm 4: **** 2. У терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі. ### 1. Створіть теку для втулка {#1-create-plugin-directory} Ви можете створити її в будь-якому місці вашої файлової системи. Наприклад: ```bash mkdir -p $HOME/code/helm/plugins/system-info cd $HOME/code/helm/plugins/system-info ``` ### 2. Створіть маніфест втулка {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: cli/v1 name: "system-info" version: "0.1.0" runtime: subprocess config: usage: system-info shortHelp: Показує системну інформацію та інформацію Helm longHelp: Показує інформацію про ОС, версію Helm та деталі середовища runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/system-info.sh ``` ### 3. Створіть скрипт {#3-create-script} ```bash title="system-info.sh" showLineNumbers #!/bin/bash echo "=== System Information ===" echo "OS: $(uname -s)" echo "Architecture: $(uname -m)" echo "" echo "=== Helm Information ===" echo "Plugin Dir: $HELM_PLUGIN_DIR" echo "Arguments: $*" echo "" echo "System info complete!" ``` Зробіть його виконуваним: ```bash chmod +x system-info.sh ``` ### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test} Встановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження: ```bash % helm plugin install $HOME/code/helm/plugins/system-info Installing plugin from local directory (development mode) Installed plugin: system-info ``` Встановлення в локальному режимі розробки створює символічне посилання з вашого теки джерел до теки втулків, тому ви можете продовжувати розробку в бажаному місці. Ви можете побачити символічне посилання, переглянувши розташування теки за допомогою внутрішньої змінної середовища HELM_PLUGINS: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 3 r6by staff 96B Nov 10 02:18 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` Ви можете переглянути детальну інформацію про втулок у списку встановлених втулків `helm plugin list`: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE system-info 0.1.0 cli/v1 v1 local dev unknown ``` Тепер ви також можете побачити свій втулок у списку доступних команд за допомогою команди `helm help` і переглянути власне повідомлення довідки, яке ви визначили у файлі `plugin.yaml`: ```bash % helm help | grep system-info system-info Показує системну інформацію та інформацію Helm % helm help system-info Показує інформацію про ОС, версію Helm та деталі середовища Usage: helm system-info [flags] ``` Спробуємо запустити команду CLI: ```bash % helm system-info === System Information === OS: Darwin Architecture: arm64 === Helm Information === Plugin Dir: /Users/r6by/Library/helm/plugins/system-info Arguments: System info complete! ``` Що ви створили: втулок CLI з використанням середовища виконання Subprocess! Тепер давайте зробимо це ще раз, але цього разу з використанням середовища виконання Wasm… ## Wasm Runtime ### Передумови {#prerequisites-1} - Передумови з [Subprocess Runtime](#subprocess-runtime) - Встановлений Go 1.25 :::warning To-do: додати цей розділ ::: ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-getter-plugin.mdx ================================================ --- title: "Посібник: Створення втулків Getter" sidebar_label: Створення втулків Getter --- import GetVersion from "@site/src/components/GetVersion"; Створіть команду `helm system-info`, яка виводить інформацію про систему. ## Subprocess Runtime Створімо втулок Getter, який виконується в Subprocess. ### Передумови {#prerequisites} 1. Встановіть останню версію Helm 4: **** 2. У терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі. ### 1. Створіть теку для втулка {#1-create-plugin-directory} Ви можете створити її в будь-якому місці вашої файлової системи. Наприклад: ```bash mkdir -p $HOME/code/helm/plugins/demo-getter cd $HOME/code/helm/plugins/demo-getter ``` ### 2. Створіть маніфест втулка {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: subprocess config: protocols: ["demo"] runtimeConfig: protocolCommands: - protocols: - demo platformCommand: - command: get-demo.sh ``` ### 3. Створіть скрипт {#3-create-script} Втулки Getter відповідають за отримання/завантаження упакованого артефакту, в даному випадку чарта, та повернення шляху до завантаженого пакета. Для демонстрації скористаймося утилітою вашої системи, щоб створити тимчасову теку (вона автоматично очищатиметься з часом), а також командами `helm create` та `helm package`, щоб створити демонстраційний пакет чарта в тимчасовій теці та повернути шлях до пакета: ```bash title="get-demo.sh" showLineNumbers #!/usr/bin/env sh set -e URI=$@ TMPDIR="$(mktemp -d)" # створення фальшивого чарта для тестування з переданим базовим імʼям URL FILENAME=$(basename -- $URI) helm create $TMPDIR/$FILENAME 1>/dev/null helm package $TMPDIR/$FILENAME -d $TMPDIR 1>/dev/null # cat $FILENAME-0.1.0.tgz # щоб не потрібно було знати версію чарта rm -r $TMPDIR/$FILENAME 1>/dev/null cat $TMPDIR/$FILENAME-* ``` Зробіть його виконуваним: ```bash chmod +x get-demo.sh ``` ### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test} Встановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження: ```bash % helm plugin install $HOME/code/helm/plugins/demo-getter Installing plugin from local directory (development mode) Installed plugin: demo-getter ``` Як ми бачили в [посібнику з втулків CLI](/plugins/developer/tutorial-cli-plugin.mdx), встановлення в локальному режимі розробки створює символічне посилання з теки джерел вашого втулка до теки втулків. Тепер у вас встановлено два втулки: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 4 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` На відміну від посібника втулків CLI, ви не побачите цей втулок у списку доступних команд за допомогою команди `helm help`. У списку команд CLI `helm` відображаються лише типи втулків CLI. Але, як і для всіх типів втулків, ви можете переглянути детальну інформацію про встановлений втулок Getter за допомогою команди `helm plugin list`: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` Спробуймо. Маємо отримати шаблон YAML для чарту з назвою «example»: ```bash % helm template example demo://does-not-matter/example LOTS OF YAML, INCLUDING: --- # Source: example/templates/tests/test-connection.yaml ``` Що ви створили: демо-втулок Getter, що використовує середовище виконання Subprocess! Далі створімо версію в середовищі виконання Wasm… ## Wasm Runtime ### Передумови {#prerequisites-1} - Вимоги з [Subprocess Runtime](#subprocess-runtime) - Встановлений Go 1.25 Створіть власний протокол getter, який перетворює URL-адреси `demo://` на `https://`. ### 1. Налаштування репозиторію {#1-set-up-repository} Створіть новий репозиторій на основі шаблону (або просто клонуйте): https://github.com/gjenkins8/helm-extism-plugin-template ### 2. Оновлення маніфесту втулка {#2-update-plugin-manifest} Аналогічно до того ж кроку для Subprocess Getter, за винятком того, що ви будете робити це у власному клонованому репозиторії Git. Зверніть увагу, що значення полів `runtime` та `runtimeConfig` зміняться для Wasm: ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: getter/v1 name: demo-getter version: 0.1.0 runtime: extism/v1 config: protocols: ["demo"] runtimeConfig: memory: maxPages: 16 timeout: 30000 ``` ### 3. Update `main.go` {#3-update-maingo} Визначте вхідні/вихідні повідомлення втулків: ```go title="main.go" showLineNumbers package main ... type InputMessage struct { URL string `json:"url"` Protocol string `json:"protocol"` } type OutputMessage struct { Data []byte `json:"data"` } ``` Замініть функцію `replaceMeImplementationGoesHere` фактичною логікою: ```go ... // Видаліть функцію `replaceMeImplementationGoesHere`. func demoDownloader(input InputMessage) (*OutputMessage, error) { // Перетворення demo:// на https:// downloadURL := strings.Replace(input.URL, "demo://", "https://", 1) pdk.Log(pdk.LogLevelInfo, fmt.Sprintf("Converted %s to %s", input.URL, downloadURL)) // Завантаження вмісту resp, err := http.Get(downloadURL) if err != nil { return nil, fmt.Errorf("failed to download: %w", err) } defer resp.Body.Close() // Читання та виведення вмісту data, _ := io.ReadAll(resp.Body) output := OutputMessage{Data: data} return &output, nil } ``` Оновіть функцію runPlugin, щоб замість цього викликати `demoDownloader`: ```go func runPlugin() error { ... // Вилучим: output, err := replaceMeImplementationGoesHere(input) output, err := demoDownloader(input) ``` ### 4. Збирання WebAssembly {#4-build-webassembly} ```bash $ make build $ ls -la plugin.wasm ``` ### 5. Встановлення в режимі розробки та тестування {#5-install-in-dev-mode-and-test} Те саме, що і крок Втулок CLI у Subprocess. Що ви створили: втулок WebAssembly із виконанням у пісочниці та структурованою комунікацією через Extism PDK! ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/developer/tutorial-postrenderer-plugin.mdx ================================================ --- title: "Посібник: Створення втулків Postrenderer" sidebar_label: Створення втулків Postrenderer --- import GetVersion from "@site/src/components/GetVersion"; import CodeBlock from "@theme/CodeBlock"; Створіть втулок, який додає власні мітки до всіх ресурсів Kubernetes. ## Subprocess Runtime Створімо втулок Postrenderer, який виконується в Subprocess. ### Передумови {#prerequisites} 1. Встановіть останню версію Helm 4: **** 2. В терміналі створіть аліас `helm` для завантаженої версії. Команда `helm version --short` повинна показати правильну версію Helm у цьому терміналі. 3. Встановіть `mikefarah/yq`: https://github.com/mikefarah/yq/#install ### 1. Створіть теку для втулка {#1-create-plugin-directory} Ви можете створити її в будь-якому місці вашої файлової системи. Наприклад: ```bash mkdir -p $HOME/code/helm/plugins/label-injector cd $HOME/code/helm/plugins/label-injector ``` ### 2. Створіть маніфест втулка {#2-create-plugin-manifest} ```yaml title="plugin.yaml" showLineNumbers apiVersion: v1 type: postrenderer/v1 name: label-injector version: 0.1.0 runtime: subprocess runtimeConfig: platformCommand: - command: ${HELM_PLUGIN_DIR}/inject-labels.sh ``` ### 3. Створіть скрипт {#3-create-script} ```bash title="inject-labels.sh" showLineNumbers #!/usr/bin/env sh # set -e cat <&0 | yq '.metadata.labels.postrendered-by = "helm-label-injector-plugin"' ``` Зробіть його виконуваним: ```bash chmod +x inject-labels.sh ``` ### 4. Встановлення в режимі розробки та тестування {#4-install-in-dev-mode-and-test} Встановлення втулка з вашої файлової системи відбувається в локальному режимі розробки. Це дозволяє обійти перевірку або підтвердження походження: ```bash % helm plugin install $HOME/code/helm/plugins/label-injector Installing plugin from local directory (development mode) Installed plugin: label-injector ``` Як ми бачили в [посібнику з втулків CLI](/plugins/developer/tutorial-cli-plugin.mdx) та [Getter](/plugins/developer/tutorial-getter-plugin.mdx), встановлення в локальному режимі розробки створює символічне посилання з теки джерел вашого втулка до теки втулків. Тепер у вас встановлено три втулки: ```bash % ls -lah $(helm env HELM_PLUGINS) total 0 drwxr-xr-x@ 5 r6by staff 160B Nov 10 04:04 . drwxr-xr-x@ 3 r6by staff 96B Jan 21 2025 .. lrwxr-xr-x 1 r6by staff 41B Nov 10 04:04 demo-getter -> /Users/r6by/code/helm/plugins/demo-getter lrwxr-xr-x 1 r6by staff 44B Nov 10 03:02 label-injector -> /Users/r6by/code/helm/plugins/label-injector lrwxr-xr-x 1 r6by staff 41B Nov 10 02:18 system-info -> /Users/r6by/code/helm/plugins/system-info ``` Тепер ви можете переглянути детальну інформацію про встановлений втулок Postrenderer, а також про встановлені втулки CLI та Getter, використовуючи команду `helm plugin list`: ```bash % helm plugin list NAME VERSION TYPE APIVERSION PROVENANCE SOURCE demo-getter 0.1.0 getter/v1 v1 local dev unknown label-injector 0.1.0 postrenderer/v1 v1 local dev unknown system-info 0.1.0 cli/v1 v1 local dev unknown ``` Давайте спробуємо: ```bash % helm create ../mychart % helm template ../mychart --post-renderer label-injector ``` У вихідних даних ви повинні побачити такі мітки: ```yaml metadata: labels: postrendered-by: helm-label-injector-plugin ``` Що ви створили: втулок Postrenderer, що використовує середовище виконання Subprocess! Далі створімо версію в середовищі виконання Wasm… ## Wasm Runtime ### Передумови {#prerequisites-1} - Вимоги з [Subprocess Runtime](#subprocess-runtime) - Встановлений Go 1.25 :::warning To-do: додати цей розділ ::: ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/index.mdx ================================================ --- title: Посібник з втулків sidebar_label: Втулки sidebar_position: 5.5 --- У цьому посібнику пояснюється, що таке втулки Helm, як їх використовувати та як створювати. import DocCardList from "@theme/DocCardList"; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/overview.md ================================================ --- title: Огляд втулків sidebar_label: Огляд sidebar_position: 1 --- Втулки Helm дозволяють користувачам розширювати набір основних функцій Helm, не вимагаючи, щоб кожна нова функція була написана на Go і додана до ядра Helm. Вони можуть бути написані будь-якою мовою програмування і можуть бути додані та видалені з встановлення Helm без порушення основної функціональності Helm. ## Типи втулків {#plugin-types} Наразі Helm має 3 типи втулків: - [Втулки CLI](#cli-plugins): дозволяють користувачам додавати додаткові команди CLI `helm`. - [Втулки Getter](#getter-plugins): дозволяють користувачам використовувати чарти та навіть інші втулки в місцях, де ядро Helm не має вбудованої підтримки. - [Втулки Postrenderer](#postrenderer-plugins): дозволяють користувачам модифікувати маніфести, отримані в результаті рендерингу чартів, перед їх надсиланням до API Kubernetes. Починаючи з Helm 4, система втулків налаштована таким чином, щоб полегшити додавання додаткових типів втулків, що дозволить користувачам модифікувати інші області функціональності Helm. ### Втулки CLI {#cli-plugins} У чому полягає перевага використання втулків для створення командних підпрограм CLI `helm` порівняно з використанням окремих скриптів або інструментів із власними автономними командами? Головною причиною є те, що втулки, які додають команди CLI `helm`, можуть використовувати конфігурацію, контекст і функціональність, специфічні для Helm, які в іншому випадку автономні скрипти та інструменти мали б створювати самостійно. Вони дозволяють легше розширювати робочі процеси користувачів CLI `helm`. ### Втулки Getter {#getter-plugins} Helm має вбудовану підтримку для роботи з [чартами](/glossary/index.mdx#chart) та втулками у вашій локальній файловій системі або збереженими як артефакти в [реєстрах OCI](/topics/registries.mdx). Чарти також можна зберігати в [HTTP-репозиторіях](/topics/chart_repository.md), а втулки — у репозиторіях VCS, таких як Git. Втулки Helm Getter дозволяють розширити це сховище та поведінку завантаження для підтримки інших місць зберігання. Існують втулки Getter від спільноти для зберігання чартів та втулків у [s3 buckets](/community/related#helm-plugins) та в інших місцях. Вам знадобляться втулки getter, якщо вам потрібні додаткові опції зберігання для ваших робочих процесів Helm. ### Втулки PostRenderer {#postrenderer-plugins} Helm дозволяє користувачам налаштовувати чарти, вводячи власні значення. Ці значення, надані користувачами, використовуються чартами для рендерингу маніфестів, які дозволяють Helm керувати вашими застосунками в Kubernetes. Якщо ви створюєте власні чарти, ви можете оновлювати шаблони, коли вам потрібна додаткова конфігурація для відрендерених маніфестів. Однак, якщо ви використовуєте чарти спільноти, які вам не належать, пост-рендеринг дозволяє модифікувати маніфести після того, як чарти їх відрендерили, але до того, як Helm використовує їх для управління вашими ресурсами Kubernetes. Починаючи з Helm 4, для цього використовуються втулки postrenderer. ## Версії API втулків {#plugin-api-versions} Починаючи з Helm 4, файл `plugin.yaml`, що входить до складу кожного втулка, тепер має поле `apiVersion`, яке наразі має значення `v1`. Старі втулки (до появи версій API) будуть підтримуватися протягом усього терміну дії Helm 4, тому ваші наявні втулки з Helm 3 будуть працювати до Helm 5. Однак вам слід звернутися до авторів ваших улюблених втулків із проханням оновити їх до нової системи версій. Якщо ви розробник втулків, дізнайтеся більше про це в [Посібнику для розробників втулків](/plugins/developer/index.mdx). ## Середовища виконання втулків {#plugin-runtimes} Helm наразі підтримує 2 середовища виконання втулків: - Середовище виконання Subprocess - Середовище виконання Wasm Відповідну інформацію про кожне середовище виконання дивіться в [Посібнику користувача втулків](/plugins/user/index.md) або [Посібнику розробника втулків](/plugins/developer/index.mdx). ## Структура файлів {#file-structure} Усі файли втулка знаходяться в одній теці, яка використовується для розробки, пакування та встановлення. Усередині теки втулка Helm очікує таку структуру: ```none example-plugin ├── plugin.yaml # ОБОВʼЯЗКОВИЙ ├── plugin.sh # ОПЦІЙНИЙ для середовища Subprocess └── plugin.wasm # ОБОВʼЯЗКОВИЙ для середовища Wasm ``` - Єдиним обовʼязковим файлом є [plugin.yaml](#pluginyaml). - [Subprocess runtime](#plugin-runtimes) може опціонально містити один або декілька власних виконуваних файлів, що містять код вашого втулка (може бути Node, Python, Go тощо). Для цього середовища виконання ви можете також викликати будь-який виконуваний файл, що вже доступний у PATH користувача, безпосередньо з поля `plugin.yaml` [runtime configuration](#runtime-configuration) `platformCommand`. - Для [Wasm runtime](#plugin-runtimes) вам потрібно буде включити файл `.wasm`. Це код вашого втулка (може бути Node, Python, Go тощо), скомпільований у Wasm. ## Plugin.yaml Файл `plugin.yaml` необхідний для роботи втулка. Це файл YAML, що містить метадані та конфігурацію втулка. ### Інформація про метадані {#metadata-information} ```yaml apiVersion: ОБОВʼЯЗКОВО — Версія API втулка. Повинна бути "v1" type: ОБОВʼЯЗКОВО — Версія типу втулка. Може бути "cli/v1", "getter/v1" або "postrenderer/v1" name: ОБОВʼЯЗКОВО — Назва втулка version: ОБОВ'ЯЗКОВО — Версія втулка runtime: ОБОВ'ЯЗКОВО — Час виконання втулка. Може бути "subprocess" або "extism/v1" (Wasm). sourceURL: OPTIONAL — URL-адреса, що вказує на початковий код вашого втулка. config: ЗАЛЕЖИТЬ ВІД ТИПУ ВТУЛКА. runtimeConfig: ЗАЛЕЖИТЬ ВІД СЕРЕДОВИЩА ВИКОНАННЯ. ``` - Поле `config` призначене для [конфігурації типу втулка](#plugin-type-configuration) і має структуру, яка відрізняється залежно від [типу втулка](#plugin-types), як визначено полем `type`. - Поле `runtimeConfig` призначене для [конфігурації середовища виконання](#runtime-configuration) і має структуру, яка відрізняється залежно від [середовища виконання](#plugin-runtimes), як визначено полем `runtime`. - 💡 Хоча поле `sourceURL` є необовʼязковим, авторам втулків наполегливо рекомендується вказувати на початковий код втулка, оскільки це допомагає користувачам втулка зрозуміти, що робить код, і зробити свій внесок у розвиток втулка, якщо він приймає відкриті внески. ### Конфігурація типу втулка {#plugin-type-configuration} Поле `config` у файлі [plugin.yaml](#pluginyaml) має різні опції для кожного [типу втулка](#plugin-types). Тип втулка визначається полем `type`. #### Конфігурація втулка CLI {#cli-plugin-configuration} Якщо поле `type` має значення `cli/v1`, це [тип втулка CLI](#cli-plugins), і дозволені такі конфігурації типу втулка: ```yaml usage: ОПЦІОНАЛЬНО — однорядковий текст використання, що показується в довідці shortHelp: короткий опис, що показується у виводі 'helm help' longHelp: довге повідомлення, що показується у виводі "helm help <ця-команда>" ignoreFlags: ігнорує будь-які прапорці, передані з Helm ``` - `usage` є необовʼязковим. Стандартно встановлено "helm PLUGIN_NAME [прапорці]", якщо не перевизначено за допомогою власного рядка використання. Рекомендовану синтаксичну конструкцію див. у [spf13/cobra.command.Command] Використовуйте коментар до поля: - Перемикач `ignoreFlags` вказує Helm не передавати прапорці до втулка. Отже, якщо втулок викликається за допомогою `helm myplugin --foo` та `ignoreFlags: true`, то `--foo` мовчки відкидається. #### Конфігурація втулка Getter {#getter-plugin-configuration} Якщо поле `type` має значення `getter/v1`, це [тип втулка Getter](#getter-plugins), і дозволені такі конфігурації типу втулка: ```yaml protocols: Список схем з URL-адреси чартів, які підтримує цей втулок. ``` #### Конфігурація втулка Postrenderer {#postrenderer-plugin-configuration} Якщо поле `type` має значення `postrenderer/v1`, це [тип втулка Postrenderer](#postrenderer-plugins), який не має жодних опцій конфігурації. ### Конфігурація середовища виконання {#runtime-configuration} Поле `runtimeConfig` у файлі [plugin.yaml](#pluginyaml) має різні опції для кожного [середовища виконання втулка](#plugin-runtimes). Середовище виконання втулка визначається полем `runtime`. #### Конфігурація runtime Subprocess {#subprocess-runtime-configuration} Якщо поле `runtime` має значення `subprocess`, це середовище виконання втулків [Subprocess Runtime](#plugin-runtimes), і дозволені такі налаштування: ```yaml runtimeconfig: platformCommand: # Налаштування команди для запуску на основі платформи - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі command: команда втулка для виконання args: аргументи команди втулка platformHooks: # Налаштування хуків життєвого циклу втулка відповідно до платформи install: # Команди життєвого циклу встановлення - os: відповідність ОС, може бути порожнім або пропущеним для відповідності будь-якій ОС arch: відповідність архітектури, може бути порожнім або пропущеним для відповідності будь-якій архітектурі command: Команда встановлення втулка для виконання args: Аргументи команди встановлення втулка update: # Команди життєвого циклу оновлення - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі command: Команда оновлення втулка для виконання args: Аргументи команди оновлення втулка delete: # Команди життєвого циклу видалення - os: відповідність ОС, може бути порожньою або пропущеною для відповідності будь-якій ОС arch: відповідність архітектури, може бути порожньою або пропущеною для відповідності будь-якій архітектурі command: команда видалення втулка для виконання args: аргументи команди видалення втулка protocolCommands: # Obsolete/deprecated - protocols: [] # Протоколи — це список схем з URL-адреси чарта. platformCommand: [] # Та сама структура, що й "platformCommand" вище ``` - ⚠️ `protocolCommands` позначено як `obsolete/deprecated` і буде видалено в майбутніх версіях системи втулків після `apiVersion: v1`. Це стосується лише типу втулка "getter/v1". Це залишок сумісності зі старим механізмом завантаження втулків, який було розширено для підтримки декількох протоколів у певному втулку. Команда, надана в PlatformCommand, повинна реалізовувати логіку, специфічну для протоколу, шляхом перевірки URL-адреси завантаження. #### Конфігурація runtime Wasm {#wasm-runtime-configuration} Якщо поле `runtime` має значення `extism/v1`, це середовище виконання втулків [Wasm Runtime](#plugin-runtimes), і дозволені такі налаштування: ```yaml runtimeconfig: memory: # Описує обмеження памʼяті, яку може бути виділено втулку maxPages: Максимальна кількість сторінок, яку може виділити втулок. Одна сторінка становить 64 Кб. Наприклад, 16 сторінок потребують 1 Мб. Стандартно — 4 сторінки (256 Кб). maxHttpResponseBytes: Максимальний розмір відповіді Extism HTTP у байтах. Стандартно — 4096 байт (4 Кбайт). maxVarBytes: Максимальний розмір усіх змінних Extism у байтах. Стандартно — 4096 байт (4 Кбайт). config: {} # Map у довільній формі, який можна передати втулку. allowedHosts: [] # Опціональний набір хостів, з якими цей втулок може спілкуватися. Стандартно жоден хост не дозволений. fileSystem: createTempDir: Чи створювати тимчасову теку в файловій системі. Може бути "true" або "false". timeout: Час очікування в мілісекундах для виконання втулка. hostFunctions: Імена HostFunction, відкриті в Helm, до яких втулок може отримати доступ. Див. https://extism.org/docs/concepts/host-functions/ entryFuncName: Імʼя функції, яку потрібно викликати у втулку. Стандартно — "helm_plugin_main". ``` - `allowedHosts` діє лише в тому випадку, якщо втулок надсилає HTTP-запити. Якщо не вказано, жодні хости не дозволені. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/plugins/user/index.md ================================================ --- title: Посібник користувача втулків sidebar_label: Використання втулків sidebar_position: 2 --- Для ознайомлення з концепціями втулків Helm, їхньою структурою та значенням налаштувань для користувачів, прочитайте [Огляд втулків](/plugins/overview.md). Цей розділ присвячений використанню втулків Helm кінцевими користувачами. ## Пошук втулків {#finding-plugins} Ви вже можете знайти [втулки Helm на ArtifactHub](https://artifacthub.io/packages/search?kind=6). Система втулків Helm 4 є абсолютно новою. У найближчому майбутньому ви зможете шукати втулки за типом і середовищем виконання на ArtifactHub. Слідкуйте за оновленнями! ## Безпека втулків {#plugin-security} Залежно від середовища виконання втулків, перед запуском у вашій системі слід перевіряти будь-які втулки від сторонніх розробників. - Subprocess runtime має такий самий доступ до вашої системи, як і користувач, що виконує команди. Обовʼязково ретельно перевіряйте код втулків перед їх встановленням, видаленням або запуском будь-яких команд Helm, які також можуть запускати ці втулки. - На відміну від цього, середовище виконання Wasm працює в безпечній пісочниці з доступом до вашої системи, який ви явно затверджуєте. Це середовище виконання втулків має набагато сильніший контроль і вбудований вищий рівень безпеки. Вам все одно слід перевірити файл `plugin.yaml`, щоб дізнатися, які дозволи запитує втулок. В обох випадках наполегливо рекомендується перевіряти походження навіть втулків Wasm runtime перед їх встановленням, щоб ви могли бути впевнені в надійності джерела завантаження та авторів. Це не тільки захистить вас від випадкового встановлення втулків із підроблених URL-адрес, але й від атак з перехопленням мережі. Перевірка втулків дозволяє криптографічно переконатися, що чарт не був скомпрометований, перш ніж ви його встановите. Дивіться прапорець `--verify` в `helm plugin install --help`. Ви також можете перевірити походження вже встановлених втулків за допомогою `helm plugin verify --help`, якщо перевірка була пропущена під час встановлення (для цілей розробки), а також для того, щоб у будь-який момент отримати інформацію про відповідність вимогам безпеки. Команда `helm plugin list` також містить загальну інформацію про походження. ## Встановлення втулків {#installing-plugins} Helm має вбудовану команду для встановлення втулків, яка стандартно забезпечує безпечне встановлення. Однак обовʼязково ознайомтесь із розділом [Безпека втулків](#plugin-security), щоб зрозуміти, що слід перевірити перед встановленням. Докладнішу інформацію див. у `helm plugin install --help`. ## Виведення списку встановлених втулків {#listing-installed-plugins} Команда для виведення списку втулків включає назву втулка, версію, тип, версію API, походження та джерело. Докладнішу інформацію див. у `helm plugin list --help`. ## Видалення втулків {#uninstalling-plugins} Видалення втулків має бути простим і легким. Однак обовʼязково ознайомтеся з розділом [Безпека втулків](#plugin-security), щоб зрозуміти ризики, повʼязані з видаленням. Див. `helm plugin uninstall --help`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/sdk/examples.mdx ================================================ --- title: Приклади description: Приклади різних функцій Helm SDK sidebar_position: 2 --- import CodeBlock from '@theme/CodeBlock'; import MainExampleGo from '!!raw-loader!/sdkexamples/main.go'; import InstallExampleGo from '!!raw-loader!/sdkexamples/install.go'; import ListExampleGo from '!!raw-loader!/sdkexamples/list.go'; import PullExampleGo from '!!raw-loader!/sdkexamples/pull.go'; import UninstallExampleGo from '!!raw-loader!/sdkexamples/uninstall.go'; import UpgradeExampleGo from '!!raw-loader!/sdkexamples/upgrade.go'; Цей документ містить низку прикладів використання Helm SDK. Призначений для документування різних функціональних можливостей SDK. Останній приклад показує драйвер `main.go` ([посилання](#driver)). Він виконує наведені нижче дії та містить необхідні допоміжні функції. Код для прикладів знаходиться в теці [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples). Він є повністю функціональним. ## Actions ### Install Action Цей приклад встановлює вказаний чарт/реліз для вказаної версії та значень: {InstallExampleGo} ### Upgrade Action У цьому прикладі оновлюється вказана версія з вказаним чартом, версією та значеннями: {UpgradeExampleGo} ### Uninstall Action Цей приклад видаляє вказану версію: {UninstallExampleGo} ### List Action У цьому прикладі перелічено всі опубліковані чарти (у поточному просторі імен): {ListExampleGo} ### Pull Action Цей приклад витягує чарт з репозиторію OCI: {PullExampleGo} ## Driver Драйвер тут показує необхідні допоміжні функції, потрібні для роботи Helm SDK. А також демонструє на практиці наведені вище приклади, щоб витягнути, встановити, оновити та видалити чарт 'podinfo' з репозиторію OCI: {MainExampleGo} ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/sdk/gosdk.mdx ================================================ --- title: Вступ description: Представляємо SDK Helm Go sidebar_position: 1 --- Helm's Go SDK дозволяє користувацькому програмному забезпеченню використовувати чарти Helm та функціонал Helm для управління розгортанням програмного забезпечення Kubernetes (насправді, Helm CLI є саме таким інструментом!). Наразі SDK функціонально відокремлений від Helm CLI. SDK може використовуватися (і використовується) окремими інструментами. Проєкт Helm прагне забезпечити стабільність API для SDK. Застереження: SDK має деякі недоліки, що залишилися від початкової роботи з відокремлення CLI та SDK. Проєкт Helm прагне виправити це з часом. Повну документацію API можна знайти за адресою [https://pkg.go.dev/helm.sh/helm/v4](https://pkg.go.dev/helm.sh/helm/v4). Нижче наведено короткий огляд деяких основних типів пакетів та простий приклад. Більше прикладів та більш повнофункціональний 'driver' можна знайти в [Прикладах](/sdk/examples.mdx). ## Огляд пакунка main {#main-package-overview} - [pkg/action](https://pkg.go.dev/helm.sh/helm/v4/pkg/action): Містить основного «клієнта» для виконання дій Helm. Це той самий пакунок, який використовує CLI під капотом. Якщо вам потрібно лише виконувати основні команди Helm з іншої програми Go, цей пакунок саме для вас: - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v4/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v4/pkg/chart/v2/util): методи та допоміжні засоби, що використовуються для завантаження та обробки чартів - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v4/pkg/cli) та його підпакети: містять усі обробники для стандартних змінних середовища Helm, а його підпакети містять обробку файлів виводу та значень - [pkg/release](https://pkg.go.dev/helm.sh/helm/v4/pkg/release): Визначає об'єкт `Release` та статуси. Крім цих пакетів, існує ще багато інших, тож перегляньте документацію, щоб отримати додаткову інформацію! ### Простий приклад {#simple-example} Це простий приклад виконання команди `helm list` за допомогою Go SDK. Більш повні приклади дивіться в розділі [Приклади](/sdk/examples.mdx). ```go package main import ( "log" "os" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // Ви можете передати порожній рядок замість settings.Namespace(), щоб перелічити // всі простори імен if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Тільки список розгорнутих client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Сумісність {#compatibility} Helm SDK чітко дотримується гарантій зворотної сумісності Helm: https://github.com/helm/community/blob/main/hips/hip-0004.md Тобто, кардинальні зміни будуть вноситися тільки при випуску нової основної версії або для усунення проблеми безпеки. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/advanced.mdx ================================================ --- title: Розширені техніки Helm description: Різні розширені функції для досвідчених користувачів Helm sidebar_position: 9 --- import Helm4 from "../_v4-in-progress.mdx" Цей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для "досвідчених користувачів" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та релізами. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про [принцип Пітера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Пост-рендеринг {#post-rendering} Пост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як [`kustomize`](https://kustomize.io), для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням. ### Передумови {#prerequisites} - Helm 3.1+ ### Використання {#usage} Пост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний "API" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу. Пост-рендерер можна використовувати з `install`, `upgrade` і `template`. Щоб використовувати пост-рендерер, використовуйте прапорець `--post-renderer` з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Якщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху. Якщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як `renderer1 | renderer2 | renderer3`. Приклад використання `kustomize` як пост-рендерера можна побачити [тут](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). #### Імена файлів {#filenames} Кожен маніфест, що передається до пост-рендерера, містить тимчасову анотацію: ```yaml metadata: annotations: postrenderer.helm.sh/postrender-filename: ``` Helm використовує цю анотацію під час зчитування вихідних даних пост-рендерера, щоб визначити, яке імʼя файлу повʼязати з кожним маніфестом для подальшої обробки. Якщо анотація відсутня, Helm автоматично генерує імʼя файлу у форматі `generated-by-postrender-.yaml`. Нарешті, Helm видаляє анотацію перед надсиланням маніфестів до Kubernetes. ### Обмеження {#caveats} При використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують реліз, **МУСЯТЬ** використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних. Ще одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані. ### Власні пост-рендерери {#custom-post-renderers} Крок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс: ```go type PostRenderer interface { // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він // очікує, що модифіковані результати будуть повернені в окремому буфері або // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Більше інформації про використання Go SDK можна знайти в [розділі Go SDK](#go-sdk). ## Go SDK {#go-sdk} Helm 3 представив повністю реструктуризований Go SDK для кращого результату при створенні програмного забезпечення та інструментів, що використовують Helm. Повна документація знаходиться в [розділі Go SDK](/sdk/gosdk.mdx). ## Сховища даних {#storage-backends} Стандартно інформація про реліз зберігається в Secrets в просторі імен релізу. У наступних розділах показано, як налаштувати різні бекенди. Ця конфігурація заснована на змінній середовища `HELM_DRIVER`. Її можна встановити на одне з таких значень: `[configmap, secret, sql]`. ### Бекенд зберігання ConfigMap {#configmap-storage-backend} Щоб активувати бекенд ConfigMap, потрібно встановити змінну середовища `HELM_DRIVER` на `configmap`. Ви можете встановити її в оболонці наступним чином: ```shell export HELM_DRIVER=configmap ``` Якщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` :::note Примітки щодо операційної діяльності Інформація про реліз включає вміст чартів і файлів значень, а тому може містити конфіденційні дані (такі як паролі, приватні ключі та інші облікові дані), які необхідно захищати від несанкціонованого доступу. При управлінні авторизацією Kubernetes, наприклад за допомогою [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), можна надати ширший доступ до ресурсів ConfigMap, одночасно обмеживши доступ до ресурсів Secret. Наприклад, стандартна [роль для користувачів](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" надає доступ до більшості ресурсів, але не до секретів. Крім того, дані секретів можна налаштувати для [шифрованого зберігання](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Майте це на увазі, якщо ви вирішите перейти на бек-енд ConfigMap, оскільки це може призвести до розкриття конфіденційних даних вашого застосунку. ::: ### Бекенд зберігання SQL {#sql-storage-backend} Існує ***бета-версія*** бекенду зберігання SQL, який зберігає інформацію про релізи в SQL базі даних. Використання такого бекенду для зберігання даних є особливо корисним, якщо розмір інформації про реліз перевищує 1 МБ (у цьому випадку її неможливо зберігати в ConfigMaps/Secrets через внутрішні обмеження в базовому сховищі ключів-значень etcd Kubernetes). Щоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища `HELM_DRIVER` на `sql`. Деталі бази даних задаються змінною середовища `HELM_DRIVER_SQL_CONNECTION_STRING`. Ви можете встановити її в оболонці наступним чином: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` :::note Зараз підтримується лише PostgreSQL. ::: :::note Примітки щодо операційної діяльності Рекомендується: - Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте [документацію з адміністрування сервера](https://www.postgresql.org/docs/12/admin.html) для отримання додаткової інформації. - Увімкнути [управління дозволами](/topics/permissions_sql_storage_backend.md) для дзеркального відображення Kubernetes RBAC для інформації про випуски. ::: Якщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про релізи за допомогою наступної команди: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/architecture.md ================================================ --- title: Архітектура Helm description: Загальний опис архітектури Helm. sidebar_position: 8 --- # Архітектура Helm Цей документ описує загальну архітектуру Helm. ## Призначення Helm {#the-purpose-of-helm} Helm — є інструментом для управління пакетами Kubernetes, які називаються _чарти_. Helm може виконувати такі дії: - Створювати нові чарти з нуля - Пакувати чарти в файли архіву чартів (tgz) - Взаємодіяти з репозиторіями чартів, де зберігаються чарти - Встановлювати та видаляти чарти в наявному кластері Kubernetes - Керувати циклом релізів чартів, які були встановлені за допомогою Helm В Helm є три важливі концепції: 1. _Chart_ — це пакет інформації, необхідної для створення екземпляра застосунку Kubernetes. 2. _Config_ — містить конфігураційну інформацію, яку можна обʼєднати з упакованим чартом для створення обʼєкта, що підлягає випуску. 3. _Release_ — це запущений екземпляр _чарту_, поєднаний з конкретним _конфігом_. ## Компоненти {#components} Helm — це виконуваний файл, який складається з двох окремих частин: **Клієнт Helm** — це клієнт командного рядка для кінцевих користувачів. Клієнт відповідає за наступне: - Розробка локальних чартів - Управління репозиторіями - Управління релізами - Взаємодія з бібліотекою Helm - Надсилання чартів для встановлення - Запит на оновлення або видалення наявних релізів **Бібліотека Helm** забезпечує логіку виконання всіх операцій Helm. Вона взаємодіє з сервером API Kubernetes і надає такі можливості: - Обʼєднання чартів і конфігурацій для створення релізу - Встановлення чартів у Kubernetes і надання подальшого обʼєкта релізу - Оновлення та видалення чартів шляхом взаємодії з Kubernetes Окрема бібліотека Helm інкапсулює логіку Helm, щоб її можна було використовувати різними клієнтами. ## Реалізація {#implementation} Клієнт та бібліотека Helm написані мовою програмування Go. Бібліотека використовує клієнтську бібліотеку Kubernetes для комунікації з Kubernetes. Зараз ця бібліотека використовує REST+JSON. Інформація зберігається у Secrets, розташованих всередині Kubernetes. Вона не потребує власної бази даних. Конфігураційні файли, коли це можливо, написані у YAML. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/chart_repository.md ================================================ --- title: Довідник репозиторіїв чартів description: Як створити та працювати з репозиторіями чартів Helm. sidebar_position: 6 --- У цьому розділі пояснюється, як створювати та працювати з репозиторіями чартів Helm. На загальному рівні репозиторій чартів — це місце, де можуть зберігатися та розповсюджуватися упаковані чарти. Розподілений репозиторій спільноти чартів Helm знаходиться на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) та запрошує вас долучитися. Однак Helm також дозволяє вам створювати власні репозиторії чартів. Цей посібник пояснює, як це зробити. Якщо ви плануєте створити репозиторій чартів, можливо, вам варто розглянути можливість використання [OCI-реєстру](/topics/registries.mdx) замість цього. ## Передумови {#prerequisites} * Ознайомтесь з посібником [Швидкий старт](/intro/quickstart.md) * Ознайомтесь з розділом [Чарти](/topics/charts.mdx) ## Створення репозиторію чартів {#create-a-chart-repository} _Репозиторій чартів_ — це HTTP-сервер, який містить файл `index.yaml` і, за бажанням, деякі упаковані чарти. Коли ви готові поділитися своїми чартами, найкращий спосіб зробити це — завантажити їх до репозиторію чартів. Починаючи з Helm 2.2.0, для репозиторіїв підтримується автентифікація SSL на боці клієнта. Інші протоколи автентифікації можуть бути доступні у вигляді втулків. Оскільки репозиторій чартів може бути будь-яким HTTP-сервером, який може обслуговувати YAML і tar файли та відповідати на GET-запити, у вас є безліч варіантів для хостингу власного репозиторію чартів. Наприклад, ви можете використовувати Google Cloud Storage (GCS), Amazon S3, GitHub Pages або навіть розгорнути власний вебсервер. ### Структура репозиторію чартів {#the-chart-repository-structure} Репозиторій чартів складається з упакованих чартів і спеціального файлу з назвою `index.yaml`, який містить індекс усіх чартів у репозиторії. Зазвичай чарти, описані в `index.yaml`, також розміщуються на тому ж сервері, що й [файли походження](/topics/provenance.mdx). Наприклад, структура репозиторію `https://example.com/charts` може виглядати так: ```none charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` У цьому випадку файл індексу міститиме інформацію про один чарт, Alpine, і надаватиме URL для завантаження `https://example.com/charts/alpine-0.1.2.tgz` для цього чарту. Не обовʼязково, щоб пакет чарту розміщувався на тому ж сервері, що й файл `index.yaml`. Однак, це часто є найпростішим варіантом. ### Файл індексу {#the-index-file} Файл індексу — це YAML-файл з назвою `index.yaml`. Він містить деякі метадані про пакети, включаючи вміст файлу `Chart.yaml` чарту. Дійсний репозиторій чартів повинен мати файл індексу. Файл індексу містить інформацію про кожен чарт у репозиторії чартів. Команда `helm repo index` створить файл індексу на основі заданої локальної теки, яка містить упаковані чарти. Приклад файлу індексу: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Хостинг репозиторіїв чартів {#hosting-chart-repositories} У цьому розділі показано кілька способів хостингу репозиторію чартів. ### Google Cloud Storage Першим кроком є **створення кошика GCS**. Назвемо його `fantastic-charts`. ![Створення кошика GCS](/img/helm2/create-a-bucket.png) Далі, зробіть свій кошик публічним, **встановивши дозволи кошику**. ![Редагування дозволів](/img/helm2/edit-permissions.png) Додайте цей пункт, щоб **зробити кошик публічним**: ![Зробити кошик публічним](/img/helm2/make-bucket-public.png) Вітаємо, тепер у вас є порожній кошик GCS, готовий для обслуговування чартів! Ви можете завантажити свій репозиторій чартів за допомогою командного рядка Google Cloud Storage або через вебінтерфейс GCS. Доступ до публічного кошика GCS можна отримати через простий HTTPS за цією адресою: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith {#cloudsmith} Ви також можете налаштувати репозиторії чартів за допомогою Cloudsmith. Дізнайтеся більше про репозиторії чартів з Cloudsmith [тут](https://help.cloudsmith.io/docs/helm-chart-repository). ### JFrog Artifactory {#jfrog-artifactory} Аналогічно, ви можете налаштувати репозиторії чартів за допомогою JFrog Artifactory. Дізнайтеся більше про репозиторії чартів з JFrog Artifactory [тут](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). ### Приклад GitHub Pages {#github-pages-example} Подібним чином ви можете створити репозиторій чартів за допомогою GitHub Pages. GitHub дозволяє обслуговувати статичні вебсторінки двома різними способами: - Налаштувавши проєкт на обслуговування вмісту його теки `docs/` - Налаштувавши проєкт на обслуговування певної гілки Ми скористаємося другим підходом, хоча перший також простий. Перший крок — **створити гілку gh-pages**. Ви можете зробити це локально: ```console $ git checkout -b gh-pages ``` Або через вебоглядач, використовуючи кнопку **Branch** у вашому репозиторії GitHub: ![Створення гілки GitHub Pages](/img/helm2/create-a-gh-page-button.png) Далі потрібно переконатися, що ваша **гілка gh-pages** налаштована як GitHub Pages. Для цього натисніть у вашому репо кнопку **Settings** і прокрутіть до розділу **GitHub pages** і налаштуйте його, як показано нижче: ![Налаштування гілки GitHub Pages](/img/helm2/set-a-gh-page.png) Стандартно **Source** зазвичай встановлюється на **gh-pages branch**. Якщо це не встановлено, виберіть його. Ви можете використовувати **власний домен**, якщо бажаєте. І переконайтеся, що **Enforce HTTPS** відмічено, щоб **HTTPS** використовувався під час обслуговування чартів. У такому налаштуванні ви можете використовувати основну гілку для зберігання коду чартів, а **гілку gh-pages** як репозиторій чартів, наприклад: `https://USERNAME.github.io/REPONAME`. Демонстраційний репозиторій [TS Charts](https://github.com/technosophos/tscharts) доступний за адресою `https://technosophos.github.io/tscharts/`. Якщо ви вирішили використовувати GitHub Pages для хостингу репозиторію чартів, ознайомтеся з [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action — це робочий процес GitHub Action, який перетворює проєкт GitHub у репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Звичайні вебсервери {#ordinary-web-servers} Щоб налаштувати звичайний вебсервер для обслуговування чартів Helm, вам достатньо зробити наступне: - Помістіть ваш індекс і чарти в теку, яку сервер може обслуговувати - Переконайтеся, що файл `index.yaml` доступний без необхідності автентифікації - Переконайтеся, що файли `yaml` обслуговуються з правильним типом вмісту (`text/yaml` або `text/x-yaml`) Наприклад, якщо ви хочете обслуговувати свої чарти з теки `$WEBROOT/charts`, переконайтеся, що у вашому вебкорені є тека `charts/`, і помістіть туди файл індексу та чарти. ### Сервер репозиторію ChartMuseum {#chartmuseum-repository-server} ChartMuseum — це сервер репозиторію чартів Helm з відкритим кодом, написаний на Go (Golang), з підтримкою хмарних сховищ, включаючи [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) та [etcd](https://etcd.io/). Ви також можете використовувати сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для хостингу репозиторію чартів з локальної файлової системи. ### GitLab Package Registry З GitLab ви можете публікувати чарти Helm у Package Registry вашого проєкту. Дізнайтеся більше про налаштування репозиторію пакетів Helm за допомогою GitLab [тут](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Управління репозиторіями чартів {#managing-chart-repositories} Тепер, коли у вас є репозиторій чартів, остання частина цього посібника пояснює, як підтримувати чарти в цьому репозиторії. ### Зберігання чартів у вашому репозиторії чартів {#store-charts-in-your-chart-repository} Тепер, коли у вас є репозиторій чартів, завантажимо чарти та файл індексу до репозиторію. Чарти в репозиторії мають бути запаковані (`helm package chart-name/`) та правильно версійовані (відповідно до рекомендацій [SemVer 2](https://semver.org/lang/uk/)). Наступні кроки складають приклад робочого процесу, але ви можете використовувати будь-який зручний вам процес для зберігання та оновлення чартів у вашому репозиторії. Як тільки у вас є готовий запакований чарт, створіть нову теку і перемістіть туди ваш запакований чарт. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` Остання команда бере шлях до щойно створеної локальної теки та URL вашого віддаленого репозиторію чартів і створює файл `index.yaml` у вказаній теці. Тепер ви можете завантажити чарт і файл індексу у ваш репозиторій чартів, використовуючи інструмент синхронізації або вручну. Якщо ви використовуєте Google Cloud Storage, ознайомтеся з цим [прикладом робочого процесу](/howto/chart_repository_sync_example.md), що використовує клієнт gsutil. Для GitHub ви можете просто помістити чарти у відповідну гілку призначення. ### Додавання нових чартів до наявного репозиторію {#adding-new-charts-to-an-existing-repository} Щоразу, коли ви хочете додати новий чарт у ваш репозиторій, потрібно перестворити індекс. Команда `helm repo index` повністю перебудовує файл `index.yaml` з нуля, включаючи лише ті чарти, які вона знаходить локально. Однак, ви можете використовувати прапорець `--merge` для поступового додавання нових чартів до наявного файлу `index.yaml` (чудовий варіант під час роботи з віддаленим репозиторієм, як-от GCS). Виконайте команду `helm repo index --help`, щоб дізнатися більше. Переконайтеся, що ви завантажили як оновлений файл `index.yaml`, так і чарт. Якщо ви згенерували файл підтвердження цілісності, завантажте і його. ### Поділитися чартами з іншими {#share-your-charts-with-others} Коли ви готові поділитися чартами, просто повідомте комусь URL вашого репозиторію. Після цього вони додадуть репозиторій до свого клієнта helm через команду `helm repo add [NAME] [URL]` з будь-яким імʼям, яке вони хочуть використовувати для позначення репозиторію. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Якщо чарти захищені за допомогою базової автентифікації HTTP, ви також можете вказати імʼя користувача та пароль як тут: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` :::note Репозиторій не буде додано, якщо він не містить дійсний файл `index.yaml`. ::: :::note Якщо ваш репозиторій helm, наприклад, використовує самопідписний сертифікат, ви можете використовувати `helm repo add --insecure-skip-tls-verify ...`, щоб пропустити перевірку CA. ::: Після цього ваші користувачі зможуть шукати серед ваших чартів. Після того, як ви оновите репозиторій, вони можуть використовувати команду `helm repo update`, щоб отримати найновішу інформацію про чарт. _Під капотом команди `helm repo add` і `helm repo update` завантажують файл index.yaml і зберігають його в теці `$XDG_CACHE_HOME/helm/repository/cache/`. Саме тут функція `helm search` знаходить інформацію про чарти._ ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/chart_tests.md ================================================ --- title: Тести чартів description: Опис того, як запускати та тестувати ваші чарти. sidebar_position: 3 --- Чарт містить ряд ресурсів та компонентів Kubernetes, які працюють разом. Як автор чарту, ви можете захотіти написати деякі тести, щоб перевірити, чи ваш чарт працює відповідно до очікувань після його встановлення. Ці тести також допомагають споживачеві чарту зрозуміти, що саме повинен робити ваш чарт. **Тест** у Helm чарті розміщується в теці `templates/` і є визначенням Job, яке вказує контейнер з певною командою для виконання. Контейнер повинен успішно завершити роботу (exit 0), щоб тест вважався успішним. Визначення Job повинно містити анотацію хука Helm: `helm.sh/hook: test`. Зверніть увагу, що до Helm v3, визначення Job повинно було містити одну з цих анотацій хука Helm: `helm.sh/hook: test-success` або `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` все ще приймається як зворотно сумісна альтернатива `helm.sh/hook: test`. Приклади тестів: - Перевірити, чи правильно завантажено вашу конфігурацію з файлу values.yaml. - Перевірити, чи правильно працюють ваше імʼя користувача та пароль. - Перевірити, чи не працюють неправильне імʼя користувача та пароль. - Перевірити, чи працюють ваші сервіси та чи правильно розподіляється навантаження. - тощо. Ви можете запустити заздалегідь визначені тести у Helm для релізу за допомогою команди `helm test `. Для споживача чарту це чудовий спосіб перевірити, чи їх реліз чарту (або застосунку) працює відповідно до очікувань. ## Приклад тесту {#example-test} Команда [helm create](/helm/helm_create.md) автоматично створює кілька тек і файлів. Щоб спробувати функціональність тестів Helm, спочатку створіть демонстраційний Helm чарт. ```console $ helm create demo ``` Тепер ви побачите таку структуру у вашому демонстраційному Helm чарті. ```console demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` У `demo/templates/tests/test-connection.yaml` ви побачите тест, який ви можете спробувати. Ось визначення Pod для тесту: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Кроки для запуску набору тестів для релізу {#steps-to-run-a-test-suite-on-a-release} По-перше, встановіть чарт у ваш кластер, щоб створити реліз. Можливо, вам доведеться почекати, поки всі podʼи стануть активними; якщо ви запустите тест одразу після цього встановлення, він може показати транзитивну помилку, і вам доведеться повторити тестування. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Примітки {#notes} - Ви можете визначити стільки тестів, скільки бажаєте, в одному файлі yaml або розподілити їх між декількома файлами yaml у теці `templates/`. - Ви можете розмістити набір тестів у теці `tests/`, наприклад `/templates/tests/`, для більшої ізоляції. - Тест є [хуком Helm](/topics/charts_hooks.md), тому з тестовими ресурсами можна використовувати такі анотації, як `helm.sh/hook-weight` та `helm.sh/hook-delete-policy`. - Зазвичай вміст теки `tests/` не потрібно пакувати та публікувати. Розгляньте можливість додавання `tests/` до файлу `.helmignore`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/charts.mdx ================================================ --- title: Чарти description: Пояснення формату чартів та основні рекомендації щодо створення чартів з використанням Helm. sidebar_position: 1 --- import Helm4 from "../_v4-in-progress.mdx" Helm використовує формат пакування, який називається _чарти_. Чарт — це набір файлів, які описують повʼязаний набір ресурсів Kubernetes. Один чарт може бути використаний для розгортання чогось простого, як, наприклад, memcached pod, або чогось складного, як повний вебстек з HTTP серверами, базами даних, кешами й так далі. Чарти створюються як файли, розташовані в певній структурі тек. Вони можуть бути упаковані у версійні архіви для розгортання. Якщо ви хочете завантажити та переглянути файли опублікованого чарту без його встановлення, ви можете зробити це за допомогою команди `helm pull chartrepo/chartname`. Цей документ пояснює формат чарту та надає основні рекомендації щодо створення чартів з використанням Helm. ## Структура файлів чарту {#the-chart-file-structure} Чарт організовано як набір файлів всередині теки. Назва теки відповідає назві чарту (без інформації про версію). Наприклад, чарт, який описує WordPress, буде зберігатися в теці `wordpress/`. Всередині цієї теки Helm очікує структуру, яка відповідає наступному: ```text wordpress/ Chart.yaml # YAML файл, що містить інформацію про чарт LICENSE # НЕОБОВʼЯЗКОВО: Текстовий файл, що містить ліцензію для чарту README.md # НЕОБОВʼЯЗКОВО: Файл README values.yaml # Файл стандартної конфігурації для цього чарту values.schema.json # НЕОБОВʼЯЗКОВО: JSON-схема для накладання структури на файл values.yaml charts/ # Тека, що містить чарти, від яких залежить цей чарт. crds/ # Custom Resource Definitions templates/ # Тека шаблонів, які в поєднанні з values # генерують валідні файли маніфестів Kubernetes. templates/NOTES.txt # НЕОБОВʼЯЗКОВО: Текстовий файл з короткими інструкціями ``` Helm резервує використання тек `charts/`, `crds/` і `templates/`, а також перелічених назв файлів. Інші файли буде залишено без змін. ## Файл Chart.yaml {#the-chartyaml-file} Файл `Chart.yaml` є обовʼязковим для чарту. Він містить наступні поля: ```yaml apiVersion: Версія API чарту (обовʼязкове) name: Назва чарту (обовʼязкове) version: Версія чарту (обовʼязково) kubeVersion: Діапазон сумісних версій Kubernetes за стандартом SemVer (опціонально) description: Короткий опис цього проєкту (опціонально) type: Тип чарту (опціонально) keywords: - Перелік ключів цього проєкту (опціонально) home: URL головної сторінки проєкту (опціонально) sources: - Список URL-адрес з вихідним кодом проєкту (опціонально) dependencies: # Список залежностей чарту (опціонально) - name: Назва чарту (nginx) version: Версія чарту ("1.2.3") repository: (опціонально) URL репозиторію ("https://example.com/charts") або аліас ("@repo-name") condition: (опціонально) Шлях yaml, який перетворюється на логічне значення, використовується для ввімкнення/вимкнення чартів (наприклад, subchart1.enabled) tags: # (опціонально) - Теґи можуть бути використані для групування чартів для одночасного увімкнення/вимкнення import-values: # (опціонально) - ImportValues містить зіставлення вихідних значень з ключем батьківського елемента для імпорту. Кожен елемент може бути рядком або парою дочірніх/батьківських субсписків. alias: (опціонально) Аліас, який буде використовуватися для чарту. Корисно, коли потрібно додати один і той же чарт кілька разів. maintainers: # (опціонально) - name: Імʼя мейнтейнера (обовʼязкове для кожного мейнтейнера) email: Електронна пошта мейнтейнера (опціонально для кожного мейнтейнера) url: URL для мейнтейнера (опціонально для кожного мейнтейнера) icon: URL-адреса зображення SVG або PNG, яке буде використовуватися як піктограма (опціонально). appVersion: Версія застосунку, що містить цей чарт (опціонально). Не обовʼязково має бути SemVer. Рекомендується використовувати лапки. deprecated: Чи цей чарт застарілий (опціонально, булеве значення) annotations: example: Список анотацій, згрупованих за іменами (опціонально). ``` Починаючи з [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), додаткові поля не дозволені. Рекомендований підхід — додавати власні метадані в `annotations`. ### Чарти та версіювання {#charts-and-versioning} Кожен чарт повинен мати номер версії. Версія повинна відповідати стандарту [SemVer 2](https://semver.org/lang/uk/spec/v2.0.0.html). На відміну від Helm Classic, Helm версії 2 та новіші використовують номери версій як маркери випуску. Пакети в репозиторіях ідентифікуються за назвою та версією. Наприклад, чарт `nginx`, у якого в полі версії вказано `version: 1.2.3`, буде мати таку назву: ```text nginx-1.2.3.tgz ``` Також підтримуються більш складні імена SemVer 2, такі як `version: 1.2.3-alpha.1+ef365`. Але імена, що не відповідають SemVer, явно заборонені системою. Виняток становлять версії у форматі `x` або `x.y`. Наприклад, якщо на початку є v або версія вказана без усіх 3 частин (наприклад, v1.2), система спробує перетворити її на коректну семантичну версію (наприклад, v1.2.0). :::note Якщо Helm Classic та Deployment Manager були тісно повʼязані з GitHub у контексті чартів, то Helm версії 2 та новіші не залежать від GitHub або навіть Git. Відповідно, Git SHAs не використовує для версіювання. ::: Поле `version` у файлі `Chart.yaml` використовується багатьма інструментами Helm, включаючи CLI. При генерації пакета, команда `helm package` використовує версію, яку знаходить у `Chart.yaml`, як частину назви пакета. Система припускає, що номер версії в назві пакета чарту збігається з номером версії у `Chart.yaml`. Невідповідність цьому припущенню призведе до помилки. ### Поле `apiVersion` {#the-apiversion-field} Поле `apiVersion` має бути `v2` для чартів Helm, які вимагають Helm версії 3 або новішої. Чарти, які підтримують попередні версії Helm, мають `apiVersion`, встановлену на `v1`, і все ще можуть бути встановлені за допомогою Helm 3. Зміни з `v1` на `v2`: - Поле `dependencies`, що визначає залежності чарту, яке в чартах `v1` знаходилося в окремому файлі `requirements.yaml` (див. [Залежності чарту](#chart-dependencies)). - Поле `type`, що дозволяє відрізняти чарт-застосунок від бібліотеки (див. [Типи чартів](#chart-types)). ### Поле `appVersion` {#the-appversion-field} Зверніть увагу, що поле `appVersion` не повʼязане з полем `version`. Це спосіб вказати версію застосунку. Наприклад, чарт `drupal` може мати `appVersion: "8.2.1"`, що вказує на версію Drupal, включену в чарт (стандартно), і це буде версія `8.2.1`. Це поле є інформаційним і не впливає на розрахунки версії чарту. Наполегливо рекомендується використовувати лапки навколо значення версії. Це змушує YAML-парсер сприймати номер версії як рядок. Якщо залишити його без лапок, це може призвести до проблем із парсингом у деяких випадках. Наприклад, YAML інтерпретує `1.0` як число з плаваючою точкою, а SHA git-коміту типу `1234e10`, як наукову нотацію. З версії Helm v3.5.0 команда `helm create` автоматично обгортає поле `appVersion` у лапки. ### Поле `kubeVersion` {#the-kubeversion-field} Необовʼязкове поле `kubeVersion` може визначати обмеження версій semver для підтримуваної версії Kubernetes. Helm перевірить обмеження версії під час встановлення чарту та відхилить дію, якщо кластер працює на непідтримуваній версії Kubernetes. Обмеження версій можуть складатися з розділених пробілами AND-порівнянь, таких як: ```semver >= 1.13.0 < 1.15.0 ``` які можуть бути обʼєднані за допомогою оператора OR `||`, як у наступному прикладі: ```semver >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` У цьому прикладі версія `1.14.0` виключена, що може мати сенс, якщо відомо про помилку в певних версіях, яка не дозволяє чарту працювати правильно. Окрім обмежень версій з використанням операторів `=` `!=` `>` `<` `>=` `<=`, підтримуються такі скорочені нотації: * Діапазони з дефісом для закритих інтервалів, де `1.1 - 2.3.4` еквівалентно `>= 1.1 <= 2.3.4`. * Підстановочні знаки `x`, `X` та `*`, де `1.2.x` еквівалентно `>= 1.2.0 < 1.3.0`. * Діапазони з тильдою (допускаються зміни патч-версії), де `~1.2.3` еквівалентно `>= 1.2.3 < 1.3.0`. * Діапазони з кареткою `^` (допускаються зміни мінорної версії), де `^1.2.3` еквівалентно `>= 1.2.3 < 2.0.0`. Для детального пояснення підтримуваних обмежень версій semver див. [Masterminds/semver](https://github.com/Masterminds/semver). ### Застарівання чартів {#deprecating-charts} Під час керування чартами в репозиторії чартів іноді виникає необхідність зняти чарт з підтримки, визнати його застарілим (deprecated). Для цього можна використовувати необовʼязкове поле `deprecated` у файлі `Chart.yaml`. Якщо **latest** версія чарту в репозиторії позначена як знята з підтримки, тоді весь чарт вважається застарілим. Назву чарту можна пізніше використовувати повторно, опублікувавши нову версію, яка не позначена як знята з підтримки. Процедура зняття чартів з підтримки включає такі кроки: 1. Оновіть файл `Chart.yaml` чарту, позначивши його як знятий з підтримки, і збільште номер версії. 2. Опублікуйте нову версію чарту в репозиторії чартів. 3. Видаліть чарт із репозиторію коду (наприклад, з git). ### Типи чартів {#chart-types} Поле `type` визначає тип чарту. Є два типи: `application` та `library`. Стандартний тип — `application`, і це стандартний чарт, з яким можна повністю працювати. [Чарт-бібліотека](/topics/library_charts.md) надає утиліти або функції для розробників чарту. Чарт-бібліотека відрізняється від чарту-застосунку тим, що він не встановлюється і зазвичай не містить жодних ресурсних обʼєктіх. :::note Чарт-застосунок можна використовувати як чарт-бібліотеку. Це активується шляхом встановлення типу `library`. Чарт тоді буде оброблятися як чарт-бібліотека, де всі утиліти та функції можуть бути використані. Усі ресурсні обʼєкти чарту не будуть оброблені. ::: ## LICENSE, README та NOTES до чарту {#chart-license-readme-and-notes} Чарти також можуть містити файли, які описують встановлення, конфігурацію, використання та ліцензію чарту. Файл LICENSE є простим текстовим файлом, який містить [ліцензію](https://en.wikipedia.org/wiki/Software_license) для чарту. Чарт може містити ліцензію, оскільки він може містити програмну логіку в шаблонах і, отже, не буде лише конфігураційним. Також можуть бути окремі ліцензії для застосунку, який встановлюється чартом, якщо це необхідно. Файл README чарту повинен бути відформатований у Markdown (README.md) і, як правило, містити: - Опис застосунку або служби, яку надає чарт - Будь-які передумови або вимоги для використання чарту - Опис опцій у `values.yaml` та стандартні значення - Будь-яку іншу інформацію, яка може бути релевантною для встановлення або конфігурування чарту Коли хаби та інші інтерфейси користувача відображають деталі про чарт, ці дані витягуються з вмісту файлу `README.md`. Чарт також може містити короткий текстовий файл `templates/NOTES.txt`, який буде надрукований після встановлення і під час перегляду статусу релізу. Цей файл обробляється як [шаблон](#templates-and-values) і може використовуватися для показу заміток щодо використання, наступних кроків або будь-якої іншої інформації, яка стосується релізу чарту. Наприклад, можна надати інструкції щодо підключення до бази даних або доступу до вебінтерфейсу. Оскільки цей файл виводиться в STDOUT під час виконання команд `helm install` або `helm status`, рекомендується зберігати вміст коротким та вказувати на README для детальнішої інформації. ## Залежності чартів {#chart-dependencies} У Helm один чарт може залежати від будь-якої кількості інших чартів. Ці залежності можна динамічно звʼязувати за допомогою поля `dependencies` у файлі `Chart.yaml` або вручну керувати ними в теці `charts/`. ### Керування залежностями за допомогою поля `dependencies` {#managing-dependencies-with-the-dependencies-field} Чарти, від яких залежить поточний чарт, визначаються як список у полі `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Поле `name` містить імʼя потрібного чарту. - Поле `version` містить версію потрібного чарту. - Поле `repository` містить повну URL-адресу репозиторію чартів. Зверніть увагу, що ви також повинні використовувати команду `helm repo add`, щоб додати цей репозиторій локально. - Ви можете використовувати імʼя репозиторію замість URL-адреси. ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Після того як ви визначили залежності, ви можете виконати команду `helm dependency update`, і вона використає ваш файл залежностей для завантаження всіх вказаних чартів у вашу теку `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Коли `helm dependency update` отримує чарти, їх буде збережено як архіви чартів у теці `charts/`. Тому в наведеному вище прикладі очікується, що в теці charts будуть такі файли: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Поле alias у залежностях {#alias-field-in-dependencies} Крім інших полів, кожен запис у вимогах може містити необовʼязкове поле `alias`. Додавання псевдоніма для чарту-залежності дозволяє додати чарт у залежності, використовуючи псевдонім як назву нової залежності. Можна використовувати `alias` у випадках, коли потрібно отримати доступ до чарту за іншою назвою (назвами). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` У наведеному вище прикладі для `parentchart` буде три залежності: ```text subchart new-subchart-1 new-subchart-2 ``` Ручний спосіб досягнення цього — копіювання/вставка одного й того ж чарту в теку `charts/` кілька разів з різними іменами. #### Поля tags та condition у залежностях {#tags-and-condition-fields-in-dependencies} Крім інших полів, кожен запис у вимогах може містити необовʼязкові поля `tags` та `condition`. Стандартно завантажуються всі чарти. Якщо присутні поля `tags` або `condition`, вони будуть оброблені та використані для управління завантаженням чартів, до яких вони застосовуються. **Condition** — поле condition містить один або кілька шляхів YAML (розділених комами). Якщо цей шлях існує у значеннях основного чарту та оцінюється як булеве значення, чарт буде включений або виключений залежно від цього булевого значення. Оцінюється лише перший дійсний шлях у списку, і якщо шляхи не існують, то condition не має жодного ефекту. **Tags** — поле tags є списком міток YAML, повʼязаних із цим чартом. У значеннях основного чарту всі чарти з мітками можуть бути включені або виключені шляхом вказання мітки та булевого значення. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` У наведеному вище прикладі всі чарти з міткою `front-end` будуть вимкнені, але оскільки шлях `subchart1.enabled` у значеннях основного чарту має значення `true`, умова переважає мітку `front-end`, і `subchart1` буде включений. Оскільки `subchart2` має мітку `back-end`, і ця мітка має значення `true`, `subchart2` буде включений. Також зверніть увагу, що хоча `subchart2` має зазначену умову, у значеннях основного чарту немає відповідного шляху та значення, тому ця умова не має ефекту. ##### Використання CLI з Tags та Conditions {#using-the-cli-with-tags-and-conditions} Параметр `--set` можна використовувати як зазвичай для зміни значень міток та умов. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Опрацювання Tags та Conditions {#tags-and-conditions-resolution} - **Conditions (коли вони встановлені в значеннях) завжди переважають Tags.** Перемагає перший наявний шлях умови, а наступні для цього чарту ігноруються. - Tags оцінюються так: "якщо будь-яка з міток чарту має значення true, тоді увімкніть чарт". - Значення міток та умов повинні бути встановлені у значеннях основного чарту. - Ключ `tags:` у значеннях має бути ключем верхнього рівня. Глобальні та вкладені таблиці `tags:` наразі не підтримуються. #### Імпорт значень дочірніх чартів через залежності {#importing-child-values-via-dependencies} У деяких випадках бажано дозволити значенням дочірнього чарту поширюватися на батьківський чарт і бути спільними стандартними значеннями. Додатковою перевагою використання формату `exports` є те, що він дозволить майбутнім інструментам виконувати інтерпретацію значень, які може встановлювати користувач. Ключі, що містять значення для імпорту, можуть бути вказані у полі `dependencies` батьківського чарту в полі `import-values`, використовуючи список YAML. Кожен елемент у списку — це ключ, який імпортується з поля `exports` дочірнього чарту. Для імпорту значень, які не містяться в ключі `exports`, використовуйте [формат child-parent](#using-the-child-parent-format). Приклади обох форматів описані нижче. ##### Використання формату exports {#using-the-exports-format} Якщо файл `values.yaml` дочірнього чарту містить поле `exports` на рівні кореня, його вміст може бути імпортований безпосередньо у значення батьківського чарту, через вказання ключів для імпорту, як у прикладі нижче: ```yaml # файл Chart.yaml батьківського чарту dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # файл values.yaml дочірнього чарту exports: data: myint: 99 ``` Оскільки ми вказуємо ключ `data` у нашому списку імпорту, Helm шукає цей ключ у полі `exports` дочірнього чарту та імпортує його вміст. Фінальні значення батьківського чарту міститимуть наше експортоване поле: ```yaml # значення батьківського чарту myint: 99 ``` Зверніть увагу, що ключ `data` не міститься у фінальних значеннях батьківського чарту. Якщо вам потрібно вказати ключ батьківського чарту, використовуйте формат 'child-parent'. ##### Використання формату child-parent {#using-the-child-parent-format} Щоб отримати доступ до значень, які не містяться у ключі `exports` значень дочірнього чарту, вам потрібно вказати шлях до джерела значень для імпорту (`child`) та шлях до місця призначення у значеннях батьківського чарту (`parent`). У прикладі нижче `import-values` інструктує Helm взяти будь-які значення, знайдені в шляху `child:`, та скопіювати їх у значення батьківського чарту в шлях, вказаний у `parent:`. ```yaml # файл Chart.yaml батьківського чарту dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` У наведеному вище прикладі значення, знайдені у шляху `default.data` у значеннях subchart1, будуть імпортовані до ключа `myimports` у значеннях батьківського чарту, як показано нижче: ```yaml # файл values.yaml батьківського чарту myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # файл values.yaml subchart1 default: data: myint: 999 mybool: true ``` Фінальні значення батьківського чарту будуть такими: ```yaml # фінальні значення батьківського чарту myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Фінальні значення батьківського чарту тепер містять поля `myint` та `mybool`, імпортовані з subchart1. ### Керування залежностями вручну через теку `charts/` {#managing-dependencies-manually-via-the-charts-directory} Якщо потрібен більший контроль над залежностями, їх можна визначити явно, скопіювавши залежні чарти в теку `charts/`. Залежність повинна бути розпакованою текою чарту, але її імʼя не може починатися з `_` або `.`. Такі файли ігноруються завантажувачем чартів. Наприклад, якщо чарт WordPress залежить від чарту Apache, то чарт Apache (відповідної версії) розміщується в теці `charts/` чарту WordPress: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` Наведений вище приклад показує, як чарт WordPress виражає свою залежність від Apache та MySQL, включаючи ці чарти всередині своєї текиу `charts/`. :::tip _Щоб завантажити залежність у вашу теку `charts/`, використовуйте команду `helm pull`._ ::: ### Операційні аспекти використання залежностей {#operational-aspects-of-using-dependencies} Попередні розділи пояснюють, як визначати залежності чартів, але як це впливає на встановлення чарту за допомогою `helm install` і `helm upgrade`? Припустимо, що чарт з назвою "A" створює такі обʼєкти Kubernetes: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Крім того, A залежить від чарту B, який створює обʼєкти: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Після встановлення/оновлення чарту A створюється або змінюється єдиний реліз Helm. Цей реліз створить або оновить усі вищевказані обʼєкти Kubernetes у такому порядку: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Це відбувається тому що, коли Helm встановлює/оновлює чарти, обʼєкти Kubernetes з чартів та всі їх залежності - обʼєднуються в єдиний набір; потім - сортуються за типом, а потім за назвою; і потім - створюються/оновлюються в тому ж порядку. Таким чином, створюється єдиний реліз, який містить усі обʼєкти для чарту та його залежностей. Порядок встановлення типів Kubernetes визначається переліком InstallOrder у файлі kind_sorter.go (див. [вихідний файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Шаблони та Значення {#templates-and-values} Шаблони Helm Chart написані мовою [шаблонів Go](https://golang.org/pkg/text/template/) з додаванням близько 50 додаткових функцій шаблонів із бібліотеки [Sprig](https://github.com/Masterminds/sprig) та декількох інших [спеціалізованих функцій](/howto/charts_tips_and_tricks.md). Всі файли шаблонів зберігаються у теці `templates/` чарту. Коли Helm обробляє чарти, він пропускає кожен файл у цій теці через рушій шаблонів. Значення для шаблонів надаються двома способами: - Розробники чартів можуть надати файл з назвою `values.yaml` всередині чарту. Цей файл може містити стандартні значення. - Користувачі чартів можуть надати YAML файл, який містить значення. Це можна зробити за допомогою команди `helm install`. Коли користувач надає власні значення, ці значення перезаписують значення у файлі `values.yaml` чарту. ### Template Files Файли шаблонів дотримуються стандартних домовленостей написання Go шаблонів (див. [документацію пакету text/template Go](https://golang.org/pkg/text/template/) для деталей). Приклад файлу шаблону може виглядати так: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` Вищенаведений приклад, заснований на [https://github.com/deis/charts](https://github.com/deis/charts), є шаблоном для контролера реплікацій Kubernetes. Він може використовувати наступні чотири значення шаблону (зазвичай визначені у файлі `values.yaml`): - `imageRegistry`: Джерело реєстру для Docker образу. - `dockerTag`: Теґ для образу Docker. - `pullPolicy`: Політика отримання образу Docker в Kubernetes. - `storage`: Сховище, стандартне значення для якого є `"minio"` Всі ці значення визначені автором шаблону. Helm не вимагає або не диктує параметри. Для ознайомлення з більшою кількістю робочих чартів, перегляньте CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Попередньо визначені значення {#predefined-values} Значення, які постачаються через файл `values.yaml` (або за допомогою прапорця `--set`), доступні у обʼєкті `.Values` в шаблоні. Але є й інші попередньо визначені дані, які можна використовувати у ваших шаблонах. Наступні значення є попередньо визначеними, доступні кожному шаблону і не можуть бути перевизначені. Як і всі значення, імена є _чутливими до регістру_: - `Release.Name`: Назва релізу (не чарту) - `Release.Namespace`: Простір імен, в який був розгорнутий чарт. - `Release.Service`: Сервіс, який здійснив реліз. - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. - `Chart`: Зміст `Chart.yaml`. Таким чином, версію чарту можна отримати як `Chart.Version`, а авторів — з `Chart.Maintainers`. - `Files`: Обʼєкт, подібний до map, що містить усі звичайні файли в чарті. Він не надає доступу до шаблонів, але надає доступ до додаткових файлів, що присутні (якщо вони не виключені за допомогою `.helmignore`). Доступ до файлів можна отримати за допомогою `{{ index .Files "file.name" }}` або функції `{{.Files.Get name }}`. Ви також можете отримати доступ до вмісту файлу як `[]byte` за допомогою `{{ .Files.GetBytes }}`. - `Capabilities`: Обʼєкт, сподібний до map, що містить інформацію про версії Kubernetes (`{{ .Capabilities.KubeVersion }}`) та підтримувані версії API Kubernetes (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) :::note Будь-які невідомі поля `Chart.yaml` будуть відкинуті. Вони не будуть доступні всередині обʼєкта `Chart`. Таким чином, `Chart.yaml` не можна використовувати для передачі довільно структурованих даних у шаблон. Проте для цього можна використовувати файл значень. ::: ### Файли значень {#values-files} Беручи до уваги шаблон у попередньому розділі, файл `values.yaml`, який постачає необхідні значення, виглядатиме так: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Файл значень має формат YAML. Чарт може містити файл стандартних значень `values.yaml`. Команда Helm install дозволяє користувачеві перевизначити значення, надавши додаткові YAML значення: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Коли значення передаються таким чином, вони зливаються з файлом стандартних значень. Наприклад, розглянемо файл `myvals.yaml`, який виглядає так: ```yaml storage: "gcs" ``` При злитті з `values.yaml` у чарті, результат буде: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Зверніть увагу, що тільки останнє поле було перевизначене. :::note Файл стандартних значень, що включений всередині чарту, _повинен_ називатися `values.yaml`. Але файли, вказані в командному рядку, можуть мати будь-яке імʼя. ::: :::note Якщо прапорець `--set` використовується з `helm install` або `helm upgrade`, ці значення просто перетворюються в YAML на клієнтському боці. ::: :::note Якщо будь-які необхідні записи у файлі значень існують, їх можна оголосити як обовʼязкові в шаблоні чарту, використовуючи функцію [ʼrequiredʼ](/howto/charts_tips_and_tricks.md). ::: Будь-які з цих значень доступні всередині шаблонів, використовуючи обʼєкт `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Область видимості, залежності та значення {#scope-dependencies-and-values} Файли значень можуть оголошувати значення як для чарту верхнього рівня, так і для будь-яких чартів, які включені у теку `charts/` цього чарту. Інакше кажучи, файл значень може надавати значення чарту та його залежностям. Наприклад, чарт WordPress, що демонструється вище, має як `mysql`, так і `apache` як залежності. Файл значень може надавати значення всім цим компонентам: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress mysql: max_connections: 100 # Надсилається до MySQL password: "secret" apache: port: 8080 # Передається Apache ``` Чарти вищого рівня мають доступ до всіх змінних, визначених нижче. Отже, чарт WordPress може отримати пароль MySQL як `.Values.mysql.password`. Але чарт нижчого рівня не може отримати доступ до елементів в батьківських чартах, тому MySQL не зможе отримати доступ до властивості `title`. Так само він не може отримати доступ до `apache.port`. Значення обмежені просторами імен, але префікси просторів імен обрізаються. Тобто для чарту WordPress, він може отримати доступ до поля пароля MySQL як `.Values.mysql.password`. Але для чарту MySQL область значень зменшена і префікс простору видалено, тому він буде бачити поле пароля просто як `.Values.password`. #### Глобальні значення {#global-values} З версії 2.0.0-Alpha.2, Helm підтримує спеціальне "глобальне" значення. Розгляньте цю змінену версію попереднього прикладу: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress global: app: MyWordPress mysql: max_connections: 100 # Надсилається до MySQL password: "secret" apache: port: 8080 # Передається Apache ``` Вищенаведене додає розділ `global` зі значенням `app: MyWordPress`. Це значення доступне _всім_ чартам як `.Values.global.app`. Наприклад, шаблони `mysql` можуть отримати доступ до `app` як `{{ .Values.global.app }}`, так само і чарт `apache`. Фактично, файл значень вище перегенерується таким чином: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Надсилається до MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Передається Apache ``` Це забезпечує спосіб поділитися однією змінною верхнього рівня з усіма субчартами, що корисно для таких речей, як встановлення властивостей `metadata`, наприклад, міток. Якщо субчарт оголошує глобальну змінну, ця глобальна змінна буде передана _далі вниз_ (в субчарти субчартів), але не _вгору_ до батьківського чарту. Немає способу, щоб субчарт впливав на значення батьківського чарту. Також, глобальні змінні батьківських чартів мають перевагу над глобальними змінними з субчартів. ### Файли схем {#schema-files} Іноді розробник чарту може захотіти визначити структуру для своїх значень. Це можна зробити, визначивши схему у файлі `values.schema.json`. Схема представляється як [JSON Schema](https://json-schema.org/). Вона може виглядати приблизно так: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Ця схема буде застосовуватися до значень для їх перевірки. Перевірка відбувається при виконанні будь-якої з наступних команд: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Приклад файлу `values.yaml`, який відповідає вимогам цієї схеми, може виглядати так: ```yaml name: frontend protocol: https port: 443 ``` Зверніть увагу, що схема застосовується до фінального обʼєкта `.Values`, а не тільки до файлу `values.yaml`. Це означає, що наступний `yaml` файл є дійсним, за умови що чарт встановлюється з відповідним параметром `--set`, як показано нижче: ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Крім того, фінальний обʼєкт `.Values` перевіряється на відповідність _усім_ схемам субчартів. Це означає, що обмеження на субчарт не можуть бути обійдені батьківським чартом. Це також працює в зворотному напрямку — якщо субчарт має вимогу, яка не виконується у файлі `values.yaml` субчарту, батьківський чарт _повинен_ задовольняти ці вимоги, щоб бути дійсним. Перевірку схеми можна вимкнути, встановивши наведену нижче опцію. Це особливо корисно в ізольованих середовищах, коли файл JSON Schema чарту містить віддалені посилання. ```console helm install --skip-schema-validation ``` ### Довідники {#references} Що стосується написання шаблонів, значень та файлів схем, існує кілька стандартних довідників, які можуть вам допомогти. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) {#custom-resource-definitions-crds} Kubernetes надає механізм для оголошення нових типів обʼєктів Kubernetes. Використовуючи CustomResourceDefinitions (CRDs), розробники Kubernetes можуть оголошувати власні типи ресурсів. У Helm 3, CRDs розглядаються як особливий вид обʼєктів. Вони встановлюються перед рештою чарту і мають певні обмеження. Файли CRD YAML повинні бути поміщені в теку `crds/` всередині чарту. Можна помістити кілька CRDs (розділених маркерами початку та кінця YAML) в один файл. Helm спробує завантажити _всі_ файли в теці CRD в Kubernetes. Файли CRD _не можуть бути шаблонізовані_. Вони повинні бути звичайними YAML документами. Коли Helm встановлює новий чарт, він завантажує CRDs, призупиняється, поки CRDs не будуть доступні через API сервер, а потім запускає рушій шаблонів, рендерить решту чарту та завантажує її в Kubernetes. Завдяки такому порядку інформація CRD доступна в обʼєкті `.Capabilities` в шаблонах Helm, і шаблони Helm можуть створювати нові екземпляри обʼєктів, які були оголошені в CRDs. Наприклад, якщо у вашому чарті є CRD для `CronTab` в теці `crds/`, ви можете створити екземпляри типу `CronTab` в теці `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Файл `crontab.yaml` повинен містити CRD без директив шаблона: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Тоді шаблон `mycrontab.yaml` може створити новий `CronTab` (використовуючи шаблони як звичайно): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm забезпечить, що тип обʼєкта `CronTab` був встановлений і доступний з API сервера Kubernetes, перш ніж продовжити встановлення обʼєктів з `templates/`. ### Обмеження CRDs {#limitations-on-crds} На відміну від більшості обʼєктів у Kubernetes, CRDs встановлюються глобально. З цієї причини Helm застосовує дуже обережний підхід до управління CRDs. CRDs підлягають таким обмеженням: - CRDs ніколи не перевстановлюються. Якщо Helm визначає, що CRDs у теці `crds/` вже присутні (незалежно від версії), Helm не намагатиметься їх встановити чи оновити. - CRDs ніколи не встановлюються під час оновлення або відкату. Helm створює CRDs тільки під час операцій встановлення. - CRDs ніколи не видаляються. Видалення CRD автоматично видаляє весь вміст CRD у всіх просторах імен у кластері. Тому Helm не видалятиме CRDs. Операторам, які хочуть оновити або видалити CRDs, рекомендується робити це вручну і з великою обережністю. ## Використання Helm для управління чартами {#using-helm-to-manage-charts} Інструмент `helm` має кілька команд для роботи з чартами. Він може створити новий чарт для вас: ```console $ helm create mychart Created mychart/ ``` Після редагування чарта, `helm` може упакувати його в архів чартів: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Ви також можете використовувати `helm`, щоб знайти проблеми з форматуванням або інформацією вашого чарта: ```console $ helm lint mychart No issues found ``` ## Репозиторії чартів {#chart-repositories} _Репозиторій чартів_ — це HTTP-сервер, який містить один або більше упакованих чартів. Хоча `helm` можна використовувати для управління локальними теками чартів, для обміну чартами переважно використовують репозиторій чартів. Будь-який HTTP-сервер, який може надавати YAML файли та tar файли та може відповідати на GET запити, можна використовувати як сервер репозиторіїв. Команда Helm тестувала деякі сервери, включаючи Google Cloud Storage з увімкненим режимом вебсайту та S3 з увімкненим режимом вебсайту. Репозиторій характеризується наявністю спеціального файлу з назвою `index.yaml`, який містить список всіх пакетів, наданих репозиторієм, разом із метаданими, які дозволяють отримувати та перевіряти ці пакети. На стороні клієнта репозиторії управляються командами `helm repo`. Однак Helm не надає інструменти для завантаження чартів на віддалені сервери репозиторіїв. Це повʼязано з тим, що така функціональність вимагала б значних вимог до сервера, що реалізує репозиторій, і підвищувала б барʼєр для налаштування репозиторію. ## Стартер-паки чартів {#chart-starter-packs} Команда `helm create` має необовʼязковий параметр `--starter`, який дозволяє вказати "стартовий чарт". Також параметр стартера має короткий псевдонім `-p`. Приклади використання: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Стартери — це звичайні чарти, але вони розташовані в `$XDG_DATA_HOME/helm/starters`. Як розробник чартів, ви можете створювати чарти, які спеціально призначені для використання як стартери. Такі чарти повинні бути спроєктовані з урахуванням наступних міркувань: - Файл `Chart.yaml` буде перезаписаний генератором. - Користувачі очікують, що зміст такого чарта буде змінений, тому документація повинна вказувати, як користувачі можуть це зробити. - Всі входження `` будуть замінені на вказане імʼя чарту, щоб стартові чарти можна було використовувати як шаблони, за винятком деяких файлів змінних. Наприклад, якщо ви використовуєте власні файли в теці `vars` або певні файли `README.md`, `` НЕ буде перевстановлено всередині них. Крім того, опис чарту не успадковується. На даний момент єдиний спосіб додати чарт до `$XDG_DATA_HOME/helm/starters` — це вручну скопіювати його туди. У документації вашого чарту ви можете пояснити цей процес. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/charts_hooks.md ================================================ --- title: Хуки чартів description: Описує, як працювати з хуками чартів. sidebar_position: 2 --- Helm надає механізм _хуків_, що дозволяє розробникам чартів втручатися на певних етапах життєвого циклу релізу. Наприклад, ви можете використовувати хуки для: - Завантаження ConfigMap або Secret під час встановлення до завантаження будь-яких інших чартів. - Виконання Job для резервного копіювання бази даних перед встановленням нового чарту, а потім виконання другого Job після оновлення для відновлення даних. - Запуску Job перед видаленням релізу для належного виведення сервісу з обігу перед його видаленням. Хуки працюють як звичайні шаблони, але мають спеціальні анотації, які змушують Helm використовувати їх по-іншому. У цьому розділі ми розглянемо базовий шаблон використання хуків. ## Доступні хуки {#the-available-hooks} Визначено наступні хуки: | Значення анотації | Опис | | ----------------- | ------------------------------------------------------------------------------------------------------ | | `pre-install` | Виконується після рендерингу шаблонів, але до створення будь-яких ресурсів у Kubernetes | | `post-install` | Виконується після завантаження всіх ресурсів у Kubernetes | | `pre-delete` | Виконується під час запиту на видалення перед видаленням будь-яких ресурсів з Kubernetes | | `post-delete` | Виконується під час запиту на видалення після видалення всіх ресурсів релізу | | `pre-upgrade` | Виконується під час запиту на оновлення після рендерингу шаблонів, але до оновлення будь-яких ресурсів | | `post-upgrade` | Виконується під час запиту на оновлення після оновлення всіх ресурсів релізу | | `pre-rollback` | Виконується під час запиту на відкат після рендерингу шаблонів, але до відкату будь-яких ресурсів | | `post-rollback` | Виконується під час запиту на відкат після модифікації всіх ресурсів | | `test` | Виконується, коли викликано підкоманду Helm test ([див документацію тестів](/topics/chart_tests.md)) | _Зверніть увагу, що хук `crd-install` був видалений на користь теки `crds/` у Helm 3._ ## Хуки та життєвий цикл релізу {#hooks-and-the-release-lifecycle} Хуки дозволяють вам, як розробнику чартів, виконувати операції на стратегічних етапах життєвого циклу релізу. Наприклад, розглянемо життєвий цикл для `helm install`. Стандартно життєвий цикл виглядає так: 1. Користувач виконує `helm install foo`. 2. Викликається API бібліотеки Helm для встановлення. 3. Після деякої перевірки бібліотека рендерить шаблони `foo`. 4. Бібліотека завантажує результуючі ресурси у Kubernetes. 5. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. 6. Клієнт завершує роботу. Helm визначає два хуки для життєвого циклу `install`: `pre-install` і `post-install`. Якщо розробник чарту `foo` реалізує обидва хуки, життєвий цикл змінюється таким чином: 1. Користувач виконує `helm install foo`. 2. Викликається API бібліотеки Helm для встановлення. 3. CRDs у теці `crds/` встановлюються. 4. Після деякої перевірки бібліотека рендерить шаблони `foo`. 5. Бібліотека готується виконати хуки `pre-install` (завантаження ресурсів хука у Kubernetes). 6. Бібліотека сортує хуки за вагою (стандартно вага дорівнює 0), за типом ресурсу та нарешті за імʼям за зростанням. 7. Бібліотека завантажує хук з найменшою вагою спочатку (від негативної до позитивної) 8. Бібліотека чекає, поки хук стане "Ready" (крім CRDs) 9. Бібліотека завантажує результуючі ресурси у Kubernetes. Зверніть увагу, що якщо встановлено прапорець `--wait`, бібліотека чекатиме, поки всі ресурси не стануть готовими, і не запустить хук `post-install`, поки вони не будуть готові. 10. Бібліотека виконує хук `post-install` (завантаження ресурсів хука). 11. Бібліотека чекає, поки хук стане "Ready". 12. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. 13. Клієнт завершує роботу. Що означає чекати, поки хук стане готовим? Це залежить від ресурсу, оголошеного в хуку. Якщо ресурс є типу `Job` або `Pod`, Helm чекатиме, поки він успішно виконається. І якщо хук не вдається, реліз зазнає невдачі. Це _блокуюча операція_, тому клієнт Helm призупиниться, поки Job виконується. Для всіх інших типів, як тільки Kubernetes позначає ресурс як завантажений (доданий або оновлений), ресурс вважається "Ready". Коли оголошено багато ресурсів у хуку, ресурси виконуються послідовно. Якщо у них є ваги хуків (див. нижче), вони виконуються в порядку ваг. Починаючи з Helm 3.2.0, ресурси хуків з однаковою вагою встановлюються в тому ж порядку, що і звичайні не-хукові ресурси. В іншому випадку, порядок не гарантується. (У Helm 2.3.0 і пізніше вони сортуються в алфавітному порядку. Це поведінка не є обовʼязковою і може змінитися в майбутньому.) Вважається гарною практикою додати вагу хуку та встановити її на `0`, якщо вага не є важливою. ## Ресурси хуків не управляються відповідними релізами {#hook-resources-are-not-managed-with-corresponding-releases} Ресурси, які створює хук, наразі не відстежуються та не управляються як частина релізу. Як тільки Helm перевіряє, що хук досяг свого готового стану, він залишає ресурс хука без змін. Збір сміття ресурсів хуків при видаленні відповідного релізу може бути додано до Helm 3 у майбутньому, тому будь-які ресурси хуків, які ніколи не повинні бути видалені, повинні бути анотовані як `helm.sh/resource-policy: keep`. Практично це означає, що якщо ви створюєте ресурси в хуку, ви не можете покладатися на `helm uninstall`, щоб видалити ресурси. Щоб знищити такі ресурси, вам потрібно або [додати власну анотацію `helm.sh/hook-delete-policy`](#hook-deletion-policies) до файлу шаблону хука, або [встановити поле часу життя (TTL) ресурсу Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Написання хуку {#writing-a-hook} Хуки — це просто манифести Kubernetes з особливими анотаціями в секції `metadata`. Оскільки це шаблони, ви можете використовувати всі звичайні можливості шаблонів, включаючи читання `.Values`, `.Release` та `.Template`. Наприклад, цей шаблон, збережений у `templates/post-install-job.yaml`, оголошує Job, який буде виконаний при `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # Це те, що визначає цей ресурс як хук. Без цього рядка # job вважається частиною релізу. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Що робить цей шаблон хуком, так це анотація: ```yaml annotations: "helm.sh/hook": post-install ``` Один ресурс може реалізовувати кілька хуків: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Аналогічно, немає обмежень на кількість різних ресурсів, які можуть реалізувати даний хук. Наприклад, можна оголосити як secret, так і config map як pre-install хук. Коли субчарти оголошують хуки, вони також оцінюються. Немає способу для основного чарту відключити хуки, оголошені субчартами. Можливо визначити вагу для хука, що допоможе створити детерміністичний порядок виконання. Ваги визначаються за допомогою наступної анотації: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Ваги хуків можуть бути позитивними або негативними числами, але повинні бути представлені як рядки. Коли Helm починає цикл виконання хуків певного типу, він сортує ці хуки у висхідному порядку. ### Політики видалення хуків {#hook-deletion-policies} Можливо визначити політики, які визначають, коли видаляти відповідні ресурси хуків. Політики видалення хуків визначаються за допомогою наступної анотації: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Ви можете вибрати одне або кілька визначених значень анотацій: | Значення анотації | Опис | | ---------------------- | ------------------------------------------------------------------ | | `before-hook-creation` | Видалити попередній ресурс перед запуском нового хуку (стандартно) | | `hook-succeeded` | Видалити ресурс після успішного виконання хука | | `hook-failed` | Видалити ресурс, якщо хук зазнав невдачі під час виконання | Якщо анотація політики видалення хука не вказана, стандартно застосовується поведінка `before-hook-creation`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/index.mdx ================================================ --- title: Посібники sidebar_position: 3 --- # Тематичні посібники Тут ви знайдете опис усіх основних частин Helm, які вам знадобляться або про які ви хочете дізнатися. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/kubernetes_apis.md ================================================ --- title: Застарілі API Kubernetes description: Пояснення щодо застарілих API Kubernetes у Helm --- Kubernetes є системою, що керується API, і API еволюціонує з часом, відображаючи зміну розуміння проблемного простору. Це загальноприйнята практика для систем та їх API. Важливою частиною еволюції API є наявність чіткої політики застарівання та процесу, який інформує користувачів про те, як впроваджуються зміни до API. Іншими словами, споживачі вашого API повинні знати заздалегідь, коли та в якій версії API буде видалено або змінено. Це дозволяє уникнути неприємних сюрпризів та руйнівних змін для споживачів. [Політика застарівання Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) документує, як Kubernetes обробляє зміни версій API. Політика щодо застарівання визначає часові рамки підтримки версій API після оголошення про їх застарівання. Тому важливо бути в курсі оголошень про застарівання та знати, коли версії API будуть видалені, щоб мінімізувати вплив. Прикладом такого оголошення є [оголошення про видалення застарілих версій API у Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), яке було опубліковано за кілька місяців до релізу. Ці версії API були оголошені застарілими ще раніше. Це свідчить про наявність чіткої політики, яка інформує споживачів про підтримку версій API. Шаблони Helm вказують [групу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при визначенні обʼєкта Kubernetes, аналогічно до маніфесту Kubernetes. Це вказується в полі `apiVersion` шаблону і визначає версію API обʼєкта Kubernetes. Це означає, що користувачі Helm та підтримувачі чартів повинні знати, коли версії API Kubernetes були оголошені застарілими та в якій версії Kubernetes вони будуть видалені. ## Підтримувачі чартів {#chart-maintainers} Вам слід перевіряти свої чарти на наявність версій API Kubernetes, які оголошені застарілими або видаленими у певній версії Kubernetes. Виявлені версії API, які скоро перестануть підтримуватися або вже не підтримуються, слід оновити до підтримуваних версій і випустити нову версію чарту. Версія API визначається полями `kind` і `apiVersion`. Наприклад, ось версія API обʼєкта `Deployment`, яка була видалена в Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Користувачі Helm {#helm-users} Вам слід перевірити чарти, які ви використовуєте (аналогічно до [підтримувачів чартів](#chart-maintainers)), і визначити будь-які чарти, у яких версії API застарілі або видалені у певній версії Kubernetes. Для виявлених чартів вам потрібно знайти останню версію чарту (яка містить підтримувані версії API) або оновити чарт самостійно. Крім того, вам також потрібно перевірити будь-які розгорнуті чарти (тобто релізи Helm) на наявність застарілих або видалених версій API. Це можна зробити, отримавши деталі релізу за допомогою команди `helm get manifest`. Метод оновлення релізу Helm до підтримуваних API залежить від ваших знахідок, як описано нижче: 1. Якщо ви знайшли лише застарілі версії API, то: - Виконайте `helm upgrade` з версією чарту, яка підтримує версії API Kubernetes. - Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". 2. Якщо ви знайшли будь-яку версію API, яка була видалена у версії Kubernetes, то: - Якщо ви використовуєте версію Kubernetes, де ці версії API все ще доступні (наприклад, ви використовуєте Kubernetes 1.15 і виявили, що використовуєте API, які будуть видалені у Kubernetes 1.16): - Дотримуйтесь процедури, описаної у пункті 1. - Інакше (наприклад, ви вже використовуєте версію Kubernetes, де деякі версії API, зазначені у `helm get manifest`, більше не доступні): - Вам потрібно відредагувати маніфест релізу, який зберігається в кластері, щоб оновити версії API до підтримуваних. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації. :::note У всіх випадках оновлення релізу Helm до підтримуваних API ніколи не слід виконувати відкат релізу до версії, яка передує версії релізу з підтримуваними API. ::: :::tip Рекомендація Найкраща практика — оновлювати релізи, використовуючи застарілі версії API, до підтримуваних версій API до того, як виконати оновлення кластера Kubernetes, який видаляє ці версії API. ::: Якщо ви не оновите реліз, як запропоновано вище, ви отримаєте помилку, схожу на наступну, при спробі оновити реліз у версії Kubernetes, де його версія API була видалена: ```log Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm не вдається виконати оновлення в такому випадку, оскільки він намагається створити патч відмінностей між поточним розгорнутим релізом (який містить версії API Kubernetes, що були видалені в цій версії Kubernetes) та чартом, який ви передаєте з оновленими/підтримуваними версіями API. Основна причина невдачі полягає в тому, що коли Kubernetes видаляє версію API, клієнтська бібліотека Go для Kubernetes більше не може аналізувати застарілі обʼєкти, і тому Helm зазнає невдачі при виклику бібліотеки. На жаль, Helm не в змозі відновитися з такої ситуації та більше не може керувати таким релізом. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації про те, як відновитися з такої ситуації. ## Оновлення версій API маніфесту релізу {#updating-api-versions-of-a-release-manifest} Маніфест є властивістю обʼєкта релізу Helm, який зберігається в полі `data` в Secret (стандартно) або ConfigMap у кластері. Поле `data` містить обʼєкт у стиснутому вигляді, закодований у base64 (існує додаткове кодування base64 для Secret). Для кожної версії/ревізії релізу існує свій Secret/ConfigMap у просторі імен релізу. Ви можете використовувати втулок Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для оновлення релізу до підтримуваних API. Ознайомтеся з readme для отримання додаткової інформації. Альтернативно, ви можете дотримуватися цих ручних кроків для оновлення версій API маніфесту релізу. Залежно від вашої конфігурації, дотримуйтесь кроків для Secret або ConfigMap. - Отримайте імʼя Secret або ConfigMap, повʼязане з останнім розгорнутим релізом: - Secrets backend: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap backend: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Отримайте деталі останнього розгорнутого релізу: - Secrets backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap backend: `kubectl get configmap -n -o yaml > release.yaml` - Зробіть резервну копію релізу на випадок, якщо вам знадобиться відновлення у разі помилки: - `cp release.yaml release.bak` - У разі необхідності, відновіть: `kubectl apply -f release.bak -n ` - Розкодуйте обʼєкт релізу: - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Змініть версії API маніфестів. Ви можете використовувати будь-який інструмент (наприклад, редактор) для внесення змін. Це знаходиться у полі `manifest` вашого розкодованого обʼєкта релізу (`release.data.decoded`). - Закодуйте обʼєкт релізу: - Secrets backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap backend: `cat release.data.decoded | gzip | base64` - Замість значення властивості `data.release` у файлі розгорнутого релізу (`release.yaml`) вставте новий закодований обʼєкт релізу. - Застосуйте файл до простору імен: `kubectl apply -f release.yaml -n ` - Виконайте `helm upgrade` з версією чарта, яка підтримує версії API Kubernetes. - Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/kubernetes_distros.md ================================================ --- title: Дистрибутиви Kubernetes description: Зберігає інформацію про використання Helm у конкретних середовищах Kubernetes. sidebar_position: 10 --- Helm повинен працювати з будь-якою [сумісною версією Kubernetes](https://github.com/cncf/k8s-conformance) (незалежно від того, чи є вона [сертифікованою](https://www.cncf.io/certification/software-conformance/) чи ні). Цей документ містить інформацію про використання Helm у специфічних середовищах Kubernetes. Будь ласка, додайте більше деталей про будь-які дистрибутиви (відсортовано за алфавітом), якщо це потрібно. ## AKS Helm працює з [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm було протестовано і він працює на платформі Kubernetes Mesosphere DC/OS 1.11, і не вимагає додаткової конфігурації. ## EKS Helm працює з Amazon Elastic Kubernetes Service (Amazon EKS): [Використання Helm з Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Платформа Kubernetes, що розміщена на GKE від Google, відома тим, що працює з Helm і не вимагає додаткової конфігурації. ## `scripts/local-cluster` та Hyperkube {#scriptslocal-cluster-and-hyperkube} Hyperkube, налаштований за допомогою `scripts/local-cluster.sh`, працює без проблем. Для використання Hyperkube у початковому вигляді може знадобитися ручне налаштування. ## IKS Helm працює з [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm регулярно тестується з [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm працює у кластерах, які налаштовані за допомогою KubeOne без обмежень. ## Kubermatic Helm працює в кластерах користувачів, які створюються Kubermatic без застережень. Оскільки початковий кластер можна налаштувати різними способами, підтримка Helm залежить від їх конфігурації. ## MicroK8s Helm можна активувати в [MicroK8s](https://microk8s.io) за допомогою команди: `microk8s.enable helm3` ## Minikube Helm протестований і відомий своєю сумісністю з [Minikube](https://github.com/kubernetes/minikube). Додаткової конфігурації не потребує. ## Openshift Helm працює безпосередньо на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версія >= 3.6) або OpenShift Origin (версія >= 3.6). Дізнайтеся більше в [цьому блозі](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm попередньо встановлений у [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 надає доступ до всіх офіційних чартів Helm через інтерфейс App Catalog та вбудований Kubernetes CLI. Додаткові репозиторії можна додати вручну. Більш детальна інформація доступна в цій [статті про Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu з `kubeadm` {#ubuntu-with-kubeadm} Kubernetes, налаштований за допомогою `kubeadm`, відомий своєю сумісністю з наступними дистрибутивами Linux: - Ubuntu 16.04 - Fedora release 25 Деякі версії Helm (v2.0.0-beta2) вимагають від вас `export KUBECONFIG=/etc/kubernetes/admin.conf` або створення `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm працює на VMware Tanzu Kubernetes Grid, TKG, без необхідності змінювати конфігурацію. Tanzu CLI може управляти встановленням пакетів для [helm-controller](https://fluxcd.io/flux/components/helm/), що дозволяє декларативно управляти релізами чартів Helm. Додаткові відомості доступні в документації TKG для [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/library_charts.md ================================================ --- title: Бібліотечні чарти description: Опис бібліотечних чартів та приклади їх використання sidebar_position: 4 --- Бібліотечний чарт — це тип [Helm чарту](/topics/charts.mdx), який визначає примітиви або визначення, що можуть бути спільно використані шаблонами Helm в інших чартах. Це дозволяє користувачам ділитися фрагментами коду, які можна повторно використовувати у різних чартах, уникаючи повторень та підтримуючи чарти [DRY](https://uk.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself). Бібліотечні чарти було представлено у Helm 3 для формального визнання загальних або допоміжних чартів, які використовувалися авторами чартів ще з Helm 2. Додавши їх як тип чарту, вони надають: - Спосіб чітко розрізняти загальні та чарти застосунків - Логіку, що запобігає встановленню загального чарту - Відсутність рендерингу шаблонів у загальному чарті, які можуть містити артефакти релізу - Дозвіл залежним чартам використовувати контекст імпортера Розробник чарту може визначити загальний чарт як бібліотечний чарт і бути впевненим, що Helm оброблятиме цей чарт стандартним та узгодженим чином. Це також означає, що визначення в чарті застосунку можна спільного використання шляхом зміни типу чарту. ## Створення простого бібліотечного чарту {#creating-a-simple-library-chart} Як згадувалося раніше, бібліотечний чарт є різновидом [Helm-чарту](/topics/charts.mdx). Це означає, що ви можете почати з створення шаблонного чарту: ```console $ helm create mylibchart Creating mylibchart ``` Спочатку видаліть усі файли в теці `templates`, оскільки ми будемо створювати власні визначення шаблонів у цьому прикладі. ```console $ rm -rf mylibchart/templates/* ``` Файл значень (values.yaml) також не буде потрібен. ```console $ rm -f mylibchart/values.yaml ``` Перш ніж перейти до створення загального коду, давайте швидко переглянемо деякі відповідні концепції Helm. [Іменований шаблон](/chart_template_guide/named_templates.md) (іноді називають partial або субшаблоном) — це просто шаблон, визначений у файлі та який має назву. У теці `templates/` будь-який файл, який починається з підкреслення (_), не призначений для виводу маніфесту Kubernetes. Тому зазвичай допоміжні шаблони та partials розміщуються у файлах `_*.tpl` або `_*.yaml`. У цьому прикладі ми створимо загальний ConfigMap, який створює порожній ресурс ConfigMap. Ми визначимо загальний ConfigMap у файлі `mylibchart/templates/_configmap.yaml` наступним чином: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Структура ConfigMap визначена в іменованому шаблоні `mylibchart.configmap.tpl`. Це простий ConfigMap з порожнім ресурсом `data`. У цьому файлі є інший іменований шаблон з назвою `mylibchart.configmap`. Цей іменований шаблон включає інший іменований шаблон `mylibchart.util.merge`, який приймає 2 іменованих шаблони як аргументи, шаблон, що викликає `mylibchart.configmap` і `mylibchart.configmap.tpl`. Допоміжна функція `mylibchart.util.merge` є іменованим шаблоном у `mylibchart/templates/_util.yaml`. Це зручний інструмент з [Загального допоміжного чарту Helm](#the-common-helm-helper-chart), оскільки він обʼєднує 2 шаблони та перевизначає будь-які спільні частини в обох: ```yaml {{- /* mylibchart.util.merge обʼєднає два шаблони YAML і виведе результат. Він приймає масив із трьох значень: - контекст верхнього рівня - назву шаблону перевизначення (призначення) - назву базового шаблону (джерело) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Це важливо, коли чарт хоче використовувати загальний код, який йому потрібно налаштувати за допомогою своєї конфігурації. Нарешті, змініть тип чарту на `library`. Це вимагає зміни файлу `mylibchart/Chart.yaml` наступним чином: ```yaml apiVersion: v2 name: mylibchart description: Helm чарт для Kubernetes # Чарт може бути або 'application', або 'library'. # # Чарти застосунків — це набори шаблонів, які можна упакувати в архіви # з версіями для розгортання. # # # Чарт може бути чартом 'application' або 'library'. # # Чарти застосунків — це набір шаблонів, які можна упакувати в архіви з версіями для розгортання. # # Чарти бібліотек надають корисні утиліти або функції для розробника чартів. Вони включаються # як залежності чартів застосунків, щоб вставити ці утиліти та функції в конвеєр рендерингу. # Чарти бібліотек не визначають жодних шаблонів, тому їх неможливо розгорнути. # type: application type: library # Це версія чарту. Це номер версії повинен збільшуватися кожного разу, # коли ви вносите зміни в чарт і його шаблони, включаючи версію програми. version: 0.1.0 # Це номер версії застосунку, що розгортається. Цей номер версії повинен # збільшуватися кожного разу, коли ви вносите зміни в застосунок, # рекомендується використовувати з лапками. appVersion: "1.16.0" ``` Тепер бібліотечний чарт готовий до спільного використання, а його визначення ConfigMap — до повторного використання. Перш ніж продовжити, варто перевірити, чи розпізнає Helm чарт як бібліотечний: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Використання простого бібліотечного чарту {#use-the-simple-library-chart} Настав час використати бібліотечний чарт. Для цього створимо знову шаблонний чарт: ```console $ helm create mychart Creating mychart ``` Знову очистимо файли шаблонів, оскільки ми хочемо створити лише ConfigMap: ```console $ rm -rf mychart/templates/* ``` Якщо ми хочемо створити простий ConfigMap у шаблоні Helm, він може виглядати приблизно так: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Однак, ми будемо повторно використовувати загальний код, створений у `mylibchart`. ConfigMap можна створити у файлі `mychart/templates/configmap.yaml` наступним чином: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Ви можете побачити, що це спрощує роботу, яку ми маємо виконати, завдяки успадкуванню загального визначення ConfigMap, яке додає стандартні властивості для ConfigMap. У нашому шаблоні ми додаємо конфігурацію, в даному випадку ключ даних `myvalue` та його значення. Конфігурація замінює порожній ресурс загального ConfigMap. Це можливо завдяки допоміжній функції `mylibchart.util.merge`, про яку ми згадували в попередньому розділі. Щоб мати можливість використовувати загальний код, нам потрібно додати `mylibchart` як залежність. Додайте наступний код в кінець файлу `mychart/Chart.yaml`: ```yaml # Загальний код у бібліотечному чарті dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Це включає бібліотечний чарт як динамічну залежність у файловій системі, яка знаходиться в тому ж батьківському шляху, що і чарт нашого застосунку. Оскільки ми включаємо бібліотечний чарт як динамічну залежність, нам потрібно запустити `helm dependency update`. Це скопіює бібліотечний чарт у вашу теку `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Тепер ми готові розгорнути наш чарт. Перш ніж встановлювати, варто перевірити спочатку рендеринг шаблону. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Це виглядає як ConfigMap, який нам потрібен, з перезаписуванням даних `myvalue: Hello World`. Встановімо його: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Ми можемо отримати реліз і побачити, що фактичний шаблон був завантажений. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Переваги бібліотечних чартів {#library-chart-benefits} З огляду на те, що бібліотечні чарти не можуть працювати як самостійні чарти, вони можуть використовувати такі функції: - Об’єкт `.Files` посилається на шляхи файлів у головному чарті, а не на локальний шлях бібліотечного чарту. - Об’єкт `.Values` є таким самим, як і в головному чарті, на відміну від [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, які отримують розділ значень, налаштованих під їхнім заголовком у головному чарті. ## Common Helm Helper Chart {#the-common-helm-helper-chart} :::info Репозиторій Common Helm Helper Chart на Github більше не підтримується, і репозиторій було визнано застарілим та зархівовано. ::: Цей [чарт](https://github.com/helm/charts/tree/master/incubator/common) був початковим зразком для спільних чартів. Він надає утиліти, що відповідають найкращим практикам розробки чартів Kubernetes. Найкраще те, що ви можете відразу ж використовувати його під час створення своїх чартів, щоб отримати зручний код для спільного використання. Ось короткий опис того, як ним користуватися. Більш детальну інформацію можна знайти в файлі [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Створіть знову шаблонний чарт: ```console $ helm create demo Creating demo ``` Використаймо загальний код з helper chart. Спочатку відредагуйте файл deployment `demo/templates/deployment.yaml` наступним чином: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Вкажіть перевизначення для вашого ресурсу Deployment тут, наприклад apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` І тепер файл сервісу, `demo/templates/service.yaml`, наступним чином: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Вкажіть перевизначення для вашого ресурсу Service тут, наприклад # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Ці шаблони показують, як успадкування загального коду з helper chart спрощує написання коду до конфігурації або налаштування ресурсів. Щоб мати можливість використовувати загальний код, нам потрібно додати `common` як залежність. Додайте наступне в кінець файлу `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` :::note Вам потрібно буде додати `incubator` до списку репозиторіїв Helm (`helm repo add`). ::: Оскільки ми включаємо чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює helper chart у вашу теку `charts/`. Оскільки helper chart використовує деякі конструкції Helm 2, вам потрібно буде додати наступне до `demo/values.yaml`, щоб дозволити завантаження образу `nginx`, оскільки це було оновлено в шаблонному чарті Helm 3: ```yaml image: tag: 1.16.0 ``` Ви можете перевірити, чи правильні шаблони чарту, перед розгортанням, використовуючи команди `helm lint` і `helm template`. Якщо все добре, розгорніть чарт, використовуючи `helm install`! ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/permissions_sql_storage_backend.md ================================================ --- title: Управління правами доступу для SQL-сховища description: Дізнайтеся, як налаштувати права доступу при використанні SQL-сховища. --- Цей документ надає рекомендації користувачам щодо налаштування та управління правами доступу при використанні SQL-сховища. ## Вступ {#introduction} Для управління дозволами Helm використовує функцію RBAC Kubernetes. При використанні бекенду зберігання SQL ролі Kubernetes не можуть бути використані для визначення того, чи може користувач отримати доступ до певного ресурсу. У цьому документі показано, як створювати та керувати цими дозволами. ## Ініціалізація {#initialization} При першому підключенні CLI Helm до вашої бази даних клієнт перевірить, чи було її попередньо ініціалізовано. Якщо ні, клієнт автоматично подбає про необхідне налаштування. Для цього ініціалізація потребує адміністративних привілеїв у схемі public або принаймні можливості: * створення таблиці; * надання привілеїв на схему public. Після виконання міграції в базі даних всі інші ролі зможуть використовувати клієнта. ## Надання привілеїв користувачеві не адміністратору в PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql} Для керування правами доступу драйвер SQL-сховища використовує функцію [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row-Level Security) PostgreSQL. RLS дозволяє всім користувачам читати/записувати в одну й ту ж таблицю, але без можливості маніпулювати однаковими рядками, якщо їм це не було явно дозволено. Стандартно будь-яка роль, яка не отримала відповідних привілеїв, завжди отримуватиме порожній список при виконанні команди `helm list` і не матиме змоги отримати або змінити будь-який ресурс у кластері. Розглянемо, як надати певній ролі доступ до конкретних просторів імен: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` Ця команда надасть дозволи на читання та запис всіх ресурсів, які відповідають умові `namespace = 'default'`, для ролі `role`. Після створення цієї політики користувач, підключений до бази даних від імені ролі `role`, зможе бачити всі релізи в просторі імен `default` при виконанні команди `helm list`, а також змінювати та видаляти їх. Привілеями можна детально керувати за допомогою RLS, і ви можете бути зацікавлені в обмеженні доступу до різних стовпців таблиці: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/plugins.mdx ================================================ --- title: Втулки Helm description: Вступ до використання та створення втулків для розширення функціональних можливостей Helm. sidebar_position: 12 --- import Helm4 from "../_v4-in-progress.mdx" Втулок Helm — це інструмент, до якого можна отримати доступ через CLI `helm`, але який не є частиною основного коду Helm. Наявні втулки можна знайти у [відповідному](/community/related#helm-plugins) розділі або шукаючи на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Цей посібник пояснює, як використовувати та створювати втулки. ## Огляд {#an-overview} Втулки Helm — це додаткові інструменти, які легко інтегруються з Helm. Вони дають змогу розширити базовий набір функцій Helm, але без необхідності писати кожну нову функцію на Go та додавати її до основного інструменту. Втулки Helm мають такі особливості: - Їх можна додавати та видаляти з установки Helm без впливу на основний інструмент Helm. - Вони можуть бути написані будь-якою мовою програмування. - Вони інтегруються з Helm і будуть відображатися в `helm help` та інших місцях. Втулки Helm знаходяться в `$HELM_PLUGINS`. Ви можете дізнатися поточне значення цієї змінної, включаючи стандартні значення, коли не задано в середовищі, за допомогою команди `helm env`. Модель втулок Helm частково базується на моделі втулків Git. Тому інколи можна почути, що `helm` називають шаром _porcelain_, а втулки — _plumbing_. Це скорочений спосіб сказати, що Helm забезпечує взаємодію з користувачем і логіку обробки на найвищому рівні, а втулки виконують «детальну роботу» з виконання бажаних дій. ## Встановлення втулків {#installing-a-plugin} Втулки встановлюються за допомогою команди `$ helm plugin install `. Ви можете передати шлях до втулка у вашій локальній файловій системі або URL віддаленого репозиторію VCS. Команда `helm plugin install` клонуватиме або копіюватиме втулок за вказаним шляхом/URL у `$HELM_PLUGINS`. ```shell $ helm plugin install https://github.com/adamreese/helm-env ``` Якщо у вас є дистрибутив втулка у форматі tar, просто розпакуйте втулок у теку `$HELM_PLUGINS`. Ви також можете встановлювати втулки з архівів безпосередньо з URL, використовуючи `helm plugin install https://domain/path/to/plugin.tar.gz`. ## Структура файлів втулка {#the-plugin-file-structure} Багато в чому втулок схожий на чарт. Кожен втулок має теку верхнього рівня, що містить файл `plugin.yaml`. Можуть бути присутні додаткові файли, але обовʼязковим є лише файл `plugin.yaml`. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## Файл plugin.yaml {#the-pluginyaml-file} Файл plugin.yaml є обовʼязковим для втулка. Він містить такі поля: ```yaml name: Назва втулка (ОБОВʼЯЗКОВО) version: Версія в форматі SemVer 2 (ОБОВʼЯЗКОВО) usage: Текст використання в один рядок, що показується в довідці description: Довгий опис, що показується в таких місцях, як довідка helm ignoreFlags: Ігнорувати прапорці передані з Helm platformCommand: # Параметри конфігурації команди для виконання залежно від платформи - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам command: Команда втулка для запуску args: Аргументи команди втулка command: (ЗАСТАРІЛЕ) Команда втулка, використовуйте platformCommand натомість platformHooks: # Параметри життєвого циклу втулка залежно від платформи install: # Параметри команд встановлення життєвого циклу - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам command: Команда встановлення втулка для виконання args: Аргументи команди встановлення втулка update: # Параметри команд оновлення життєвого циклу - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам command: Команда оновлення втулка для виконання args: Аргументи команди оновлення втулка delete: # Параметри команд видалення життєвого циклу - os: Відповідність ОС, може бути порожньою або відсутньою для відповідності всім ОС arch: Відповідність архітектури, може бути порожньою або відсутньою для відповідності всім архітектурам command: Команда видалення втулка для виконання args: Аргументи команди видалення втулка hooks: # (ЗАСТАРІЛЕ) Життєвий цикл втулка, використовуйте platformHooks натомість install: Команда встановлення втулка update: Команда оновлення втулка delete: Команда видалення втулка downloaders: # Налаштування можливостей завантажувачів - command: Команда для виклику protocols: - Схема протоколу, що підтримується ``` ### Поле `name` {#the-name-field} Поле `name` є назвою втулка. Коли Helm виконує цей втулок, буде використане це імʼя (наприклад, `helm NAME` викличе цей втулок). _`name` має збігатись з назвою теки._ У нашому прикладі вище це означає, що втулок з `name: last` повинен міститися в теці з назвою `last`. Обмеження для `name`: - `name` не може дублювати одну з наявних верхньорівневих команд `helm`. - `name` повинен містити лише символи ASCII a-z, A-Z, 0-9, `_` та `-`. ### Поле `version` {#the-version-field} Поле `version` є версією втулка у форматі SemVer 2. `usage` та `description` використовуються для генерації тексту довідки команди. ### Поле `ignoreFlags` {#the-ignoreflags-field} Поле `ignoreFlags` вказує Helm _не_ передавати прапорці втулку. Тож, якщо втулок викликається з `helm myplugin --foo` і `ignoreFlags: true`, тоді `--foo` буде мовчки проігноровано. ### Поле `platformCommand` {#the-platformcommand-field} Поле `platformCommand` налаштовує команду, яку втулок виконуватиме при виклику. Ви не можете встановлювати одночасно `platformCommand` та `command`, оскільки це призведе до помилки. Наступні правила застосовуватимуться при виборі команди: - Якщо `platformCommand` присутнє, буде використана вказана команда. - Якщо і `os`, і `arch` збігаються з поточною платформою, пошук припиниться і команда буде використана. - Якщо `os` збігається, а `arch` порожнє, команда буде використана. - Якщо і `os`, і `arch` порожні, команда буде використана. - Якщо немає збігу, Helm завершить роботу з помилкою. - Якщо `platformCommand` відсутнє, а застаріле поле `command` присутнє, воно буде використане. - Якщо команда не вказана, Helm завершить роботу з помилкою. ### Поле `platformHooks` {#the-platformhooks-field} Поле `platformHooks` налаштовує команди, які втулок виконуватиме для подій життєвого циклу. Ви не можете встановлювати одночасно `platformHooks` та `hooks`, оскільки це призведе до помилки. Наступні правила застосовуватимуться при виборі команди для хуку: - Якщо `platformHooks` присутнє, воно буде використане, і команди для події життєвого циклу будуть оброблені. - Якщо і `os`, і `arch` збігаються з поточною платформою, пошук припиниться і команда буде використана. - Якщо `os` збігається, а `arch` порожнє, команда буде використана. - Якщо і `os`, і `arch` порожні, команда буде використана. - Якщо немає збігу, Helm пропустить подію. - Якщо `platformHooks` відсутнє, а застаріле поле `hooks` присутнє, команда для події життєвого циклу буде використана. - Якщо команда не вказана, Helm пропустить подію. ## Створення втулків {#building-a-plugin} Ось YAML-файл для простого втулка, який допомагає отримати назву останнього релізу: ```yaml name: last version: 0.1.0 usage: отримує назву останнього релізу description: отримує назву останнього релізу ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Втулки можуть вимагати додаткових скриптів та виконуваних файлів. Скрипти можуть бути включені в теку втулка, а виконувані файли можна завантажити за допомогою хука. Нижче наведено приклад: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: демонстраційний втулок description: демонстраційний втулок ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Змінні середовища інтерполюються перед виконанням втулка. Наведений вище шаблон ілюструє найкращий спосіб вказати місцезнаходження застосунку втулка. ### Команди втулка {#plugin-commands} Існує кілька стратегій роботи з командами втулка: - Якщо втулок містить виконуваний файл, виконуваний файл для `platformCommand:` або повинен бути упакований у теку втулка або встановлений за допомогою хука. - Перед виконанням рядка `platformCommand:` або `command:` будуть розгорнуті всі змінні середовища. `$HELM_PLUGIN_DIR` вказуватиме на теку втулка. - Сама команда не виконується в оболонці. Тому ви не можете виконати скрипт оболонки в одному рядку. - Helm вводить багато конфігурацій у змінні середовища. Подивіться на середовище, щоб побачити, яка інформація доступна. - Helm не робить жодних припущень щодо мови втулка. Ви можете писати його будь-якою мовою, яку вважаєте за потрібне. - Команди відповідають за реалізацію конкретного тексту довідки для `-h` та `--help`. Helm використовуватиме `usage` та `description` для `helm help` та `helm help myplugin`, але не оброблятиме `helm myplugin --help`. ### Тестування локального втулка {#testing-a-local-plugin} Спочатку потрібно знайти шлях `HELM_PLUGINS`, для цього виконайте наступну команду: ``` bash helm env ``` Змініть поточну теку на теку, в яку встановлено `HELM_PLUGINS`. Тепер ви можете додати символічне посилання на збірку вашого втулка, у цьому прикладі ми зробили це для `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Завантажувач втулків {#downloader-plugins} Стандартно Helm здатен завантажувати чарти за допомогою HTTP/S. Починаючи з версії Helm 2.4.0, втулки можуть мати спеціальну можливість завантажувати чарти з довільних джерел. Втулки повинні оголосити цю спеціальну можливість у файлі `plugin.yaml` (на верхньому рівні): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Якщо такий втулок встановлений, Helm може взаємодіяти з репозиторієм, використовуючи вказану схему протоколу, викликавши `command`. Спеціальний репозиторій слід додати так само як і звичайні: `helm repo add favorite myprotocol://example.com/`. Правила для спеціальних репозиторіїв такі ж, як і для звичайних: Helm повинен бути здатен завантажити файл `index.yaml`, щоб виявити та зберегти список доступних чартів. Визначена команда буде викликана за схемою: `command certFile keyFile caFile full-URL`. Облікові відомості SSL беруться з визначення репозиторію, що зберігається в `$HELM_REPOSITORY_CONFIG` (тобто `$HELM_CONFIG_HOME/repositories.yaml`). Очікується, що команда завантажувача виведе сирий контент на stdout і повідомить про помилки на stderr. Команда завантажувача також підтримує підкоманди або аргументи, що дозволяє, наприклад, вказати `bin/mydownloader subcommand -d` у `plugin.yaml`. Це корисно, якщо ви хочете використовувати один і той же виконуваний файл для основної команди втулка та команди завантажувача, але з різною підкомандою для кожної. ## Змінні середовища {#environment-variables} Коли Helm виконує втулок, він передає змінну зовнішнього середовища втулку та також деякі додаткові змінні середовища. Змінні, такі як `KUBECONFIG`, встановлюються для втулка, якщо вони встановлені у зовнішньому середовищі. Гарантовано будуть встановлені такі змінні: - `HELM_PLUGINS`: Шлях до теки втулків. - `HELM_PLUGIN_NAME`: Імʼя втулка, яке використовується при виклику через `helm`. Тобто `helm myplug` матиме коротке імʼя `myplug`. - `HELM_PLUGIN_DIR`: Тека, що містить втулок. - `HELM_BIN`: Шлях до команди `helm` (як виконана користувачем). - `HELM_DEBUG`: Вказує, чи був встановлений прапорець налагодження. - `HELM_REGISTRY_CONFIG`: Місце для конфігурації реєстру (якщо використовується). Зазначте, що використання Helm з реєстрами є експериментальною функцією. - `HELM_REPOSITORY_CACHE`: Шлях до кеш-файлів репозиторіїв. - `HELM_REPOSITORY_CONFIG`: Шлях до файлу конфігурації репозиторію. - `HELM_NAMESPACE`: Простір імен, вказаний команді `helm` (зазвичай за допомогою прапорця `-n`). - `HELM_KUBECONTEXT`: Назва контексту конфігурації Kubernetes, наданого команді `helm`. Крім того, якщо конфігураційний файл Kubernetes був явно вказаний, він буде встановлений як змінна `KUBECONFIG`. ## Примітка про парсинг прапорців {#note-on-flag-parsing} При виконанні втулка Helm буде розбирати глобальні прапорці для власного використання. Жоден з цих пропорців не передається втулку. - `--burst-limit`: Це перетворюється в `$HELM_BURST_LIMIT`. - `--debug`: Якщо цей прапорець вказаний, `$HELM_DEBUG` встановлюється в `1`. - `--kube-apiserver`: Це перетворюється в `$HELM_KUBEAPISERVER`. - `--kube-as-group`: Ці перетворюються в `$HELM_KUBEASGROUPS`. - `--kube-as-user`: Це перетворюється в `$HELM_KUBEASUSER`. - `--kube-ca-file`: Це перетворюється в `$HELM_KUBECAFILE`. - `--kube-context`: Це перетворюється в `$HELM_KUBECONTEXT`. - `--kube-insecure-skip-tls-verify`: Це перетворюється в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`. - `--kube-tls-server-name`: Це перетворюється в `$HELM_KUBETLS_SERVER_NAME`. - `--kube-token`: Це перетворюється в `$HELM_KUBETOKEN`. - `--kubeconfig`: Це перетворюється в `$KUBECONFIG`. - `--namespace` and `-n`: Це перетворюється в `$HELM_NAMESPACE`. - `--qps`: Це перетворюється в `$HELM_QPS`. - `--registry-config`: Це перетворюється в `$HELM_REGISTRY_CONFIG`. - `--repository-cache`: Це перетворюється в `$HELM_REPOSITORY_CACHE`. - `--repository-config`: Це перетворюється в `$HELM_REPOSITORY_CONFIG`. Втулки _повинні_ відображати текст довідки та виходити для `-h` та `--help`. У всіх інших випадках втулки можуть використовувати прапорці за потреби. ## Надання автозавершення оболонки {#providing-shell-auto-completion} Починаючи з Helm 3.2, втулок може додатково підтримувати автозавершення оболонки як частину наявного механізму автозавершення Helm. ### Статичне автозавершення {#static-auto-completion} Якщо втулок надає свої власні прапорці та/або підкоманди, він може сповістити Helm про них, маючи файл `completion.yaml`, розташований у кореневій теці втулка. Файл `completion.yaml` має форму: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Примітки: 1. Усі секції є необовʼязковими, але їх слід надати, якщо треба. 1. Прапорці не повинні включати префікс `-` або `--`. 1. Як короткі, так і довгі прапорці можуть і повинні бути вказані. Короткий прапорець не потребує асоціації з відповідною довгою формою, але обидві форми слід перерахувати. 1. Прапорці не потрібно упорядковувати будь-яким чином, але їх слід перераховувати в правильному місці в ієрархії підкоманд файлу. 1. Глобальні прапорці Helm вже обробляються механізмом автозавершення Helm, тому втулкам не потрібно вказувати наступні прапорці `--debug`, `--namespace` або `-n`, `--kube-context`, і `--kubeconfig`, або будь-які інші глобальні прапорці. 1. Список `validArgs` надає статичний список можливих завершень для першого параметра після підкоманди. Можливо не завжди надати такий список заздалегідь (див. розділ [Динамічне завершення](#dynamic-completion) нижче), у цьому випадку розділ `validArgs` можна пропустити. Файл `completion.yaml` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати автозавершення оболонки для втулка (якщо не підтримується [Динамічне завершення](#dynamic-completion) втулком). Крім того, додавання файлу `completion.yaml` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. Як приклад, для втулка [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), який не має підкоманд, але приймає ті ж прапорці, що й команда `helm status`, файл `completion.yaml` виглядає так: ```yaml name: fullstatus flags: - o - output - revision ``` ### Динамічне автозавершення {#dynamic-completion} Починаючи з Helm 3.2, втулки можуть надавати динамічне автозавершення оболонки. Динамічне автозавершення забезпечує завершення значень параметрів або прапорців, які не можуть бути визначені заздалегідь. Наприклад, завершення імен Helm релізів, які наразі доступні в кластері. Щоб втулок підтримував динамічне автозавершення, він повинен надати **виконуваний** файл з назвою `plugin.complete` у своїй кореневій теці. Коли скрипт автозавершення Helm потребує динамічного завершення для втулка, він виконає файл `plugin.complete`, передаючи йому командний рядок, який потрібно завершити. Виконуваний файл `plugin.complete` повинен містити логіку для визначення правильних варіантів завершення та виводити їх на стандартний вихід, щоб їх можна було спожити скриптом автозавершення Helm. Файл `plugin.complete` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати динамічне автозавершення для втулка. Крім того, додавання файлу `plugin.complete` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. Вихідний результат скрипту `plugin.complete` повинен бути списком, розділеним символом нового рядка (`\n`), наприклад: ```console rel1 rel2 rel3 ``` Коли `plugin.complete` викликаний, середовище втулка встановлено так само, як і при виклику основного скрипту втулка. Отже, змінні `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` та всі інші змінні втулка вже будуть встановлені, а відповідні глобальні прапорці будуть видалені. Файл `plugin.complete` може бути будь-якої виконуваної форми; це може бути shell-скрипт, програма на Go або будь-яка інша програма, яку Helm може виконати. Файл `plugin.complete` _**повинен**_ мати права на виконання для користувача. Файл `plugin.complete` _**повинен**_ завершитися з кодом успіху (значення 0). У деяких випадках динамічне завершення вимагатиме отримання інформації з кластера Kubernetes. Наприклад, втулок `helm fullstatus` потребує імені релізу як вводу. У втулку `fullstatus`, щоб скрипт `plugin.complete` надав завершення для поточних імен релізів, він може просто виконати `helm list -q` і вивести результат. Якщо ви бажаєте використовувати один і той же виконуваний файл для виконання втулка та для завершення втулка, скрипт `plugin.complete` може викликати основний виконуваний файл втулка з певним спеціальним параметром або прапорцем; коли основний виконуваний файл втулка виявляє спеціальний параметр або прапорець, він буде знати, що потрібно виконати завершення. У нашому прикладі `plugin.complete` може бути реалізований так: ```sh #!/usr/bin/env sh # "$@" є всім командним рядком, який потребує завершення. # Важливо використовувати подвійні лапки в змінній "$@", щоб зберегти можливий пустий останній параметр. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Справжній скрипт втулка `fullstatus` (`status.sh`) повинен тоді шукати прапорець `--complete` і, якщо знайде його, вивести правильні завершення. ### Поради та підказки {#tips-and-tricks} 1. Оболонка автоматично відфільтровує варіанти завершення, які не відповідають введенню користувача. Отже, втулок може повернути всі відповідні завершення без видалення тих, які не відповідають введенню користувача. Наприклад, якщо командний рядок `helm fullstatus ngin`, скрипт `plugin.complete` може вивести _всі_ імена релізів (з простору імен `default`), а не лише ті, що починаються з `ngin`; оболонка зберігає лише ті, що починаються з `ngin`. 2. Щоб спростити підтримку динамічного завершення, особливо якщо у вас складний втулок, ви можете налаштувати скрипт `plugin.complete`, щоб він викликав основний скрипт втулка і запитував варіанти завершення. Дивіться розділ [Динамічне завершення](#dynamic-completion) вище для прикладу. 3. Для налагодження динамічного завершення та файлу `plugin.complete` можна виконати наступне, щоб побачити результати завершення: - `helm __complete `. Наприклад: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/provenance.mdx ================================================ --- title: Підтвердження походження та цілісності в Helm description: Як перевірити цілісність та походження чарту. sidebar_position: 5 --- import Helm4 from "../_v4-in-progress.mdx" Helm має інструменти підтвердження походження, які допомагають користувачам чартів перевіряти цілісність та походження пакета. Використовуючи інструменти на основі PKI, GnuPG та відомих менеджерів пакетів, Helm може генерувати та перевіряти файли підписів. ## Огляд {#overview} Цілісність встановлюється шляхом порівняння чарту з записом про походження. Записи про походження зберігаються у _файлах походження_, які зберігаються поряд з упакованим чартом. Наприклад, якщо чарт називається `myapp-1.2.3.tgz`, то файл походження буде `myapp-1.2.3.tgz.prov`. Файли походження генеруються під час пакування (`helm package --sign ...`) і можуть бути перевірені кількома командами, зокрема `helm install --verify`. ## Робочий процес {#the-workflow} У цьому розділі описано можливий порядок дій для ефективного використання даних про походження. Передумови: - Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі - Інструмент командного рядка `helm` - Інструменти командного рядка GnuPG (необов’язково) - Інструменти командного рядка Keybase (необов’язково) :::note Якщо ваш приватний ключ PGP має парольну фразу, вам буде запропоновано ввести її для будь-яких команд, які підтримують опцію `--sign`. ::: Створення нового чарту виконується так само як і раніше: ```console $ helm create mychart Creating mychart ``` Коли все буде готово до пакування, додайте прапорець `--sign` до `helm package`. Також вкажіть ім'я, за яким відомий ключ підпису, та вʼязку ключів, що містить відповідний приватний ключ: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` :::note Значення аргументу `--key` повинно бути субрядком бажаного `uid` ключа (виведеного командою `gpg --list-keys`), наприклад імʼя або електронна пошта. **Відбиток (fingerprint) _не може_ бути використаний.** ::: :::tip Для користувачів GnuPG ваша секретна вʼязка ключів знаходиться в `~/.gnupg/secring.gpg`. Ви можете використовувати команду `gpg --list-secret-keys`, щоб переглянути наявні ключі. ::: :::warning у GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі `kbx` стандартно у `~/.gnupg/pubring.kbx`. Будь ласка, використовуйте такі команди, щоб перетворити свою вʼязку ключів у старий формат gpg: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` ::: На цьому етапі ви повинні побачити як `mychart-0.1.0.tgz`, так і `mychart-0.1.0.tgz.prov`. Обидва файли зрештою мають бути завантажені у ваш репозиторій чартів. Ви можете перевірити чарт за допомогою команди `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Приклад невдалої перевірки: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Щоб виконати перевірку під час встановлення, використовуйте прапорець `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Якщо вʼязка ключів, що містить публічний ключ, асоційований із підписаним чартом, не знаходиться в стандартному місці, можливо, вам доведеться вказати шлях до вʼязки ключів за допомогою `--keyring PATH`, як у прикладі з `helm package`. Якщо перевірка не вдалася, встановлення буде перервано ще до того, як чарт буде навіть оброблено. ### Використання облікових даних Keybase.io {#using-keybaseio-credentials} Сервіс [Keybase.io](https://keybase.io) дозволяє легко створити ланцюжок довіри для криптографічної ідентифікації. Повноваження Keybase можна використовувати для підписання чартів. Передумови: - Налаштований обліковий запис Keybase.io - Встановлений локально GnuPG - Встановлений локально `keybase` CLI #### Підписання пакетів {#signing-packages} Першим кроком є імпорт ваших ключів Keybase у вашу локальну вʼязку ключів GnuPG: ```console $ keybase pgp export -s | gpg --import ``` Це перетворить ваш ключ Keybase у формат OpenPGP і потім імпортує його локально у файл `~/.gnupg/secring.gpg`. Ви можете перевірити це, виконавши команду `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Зверніть увагу, що ваш секретний ключ матиме рядок ідентифікатора: ``` technosophos (keybase.io/technosophos) ``` Це повне імʼя вашого ключа. Далі, ви можете упакувати та підписати чарт за допомогою `helm package`. Переконайтеся, що ви використовуєте хоча б частину цього рядка назви у `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Як результат, команда `package` має створити як файл `.tgz`, так і файл `.tgz.prov`. #### Перевірка пакетів {#verifying-packages} Ви також можете використовувати аналогічний метод для перевірки чарту, підписаного ключем Keybase іншого користувача. Наприклад, ви хочете перевірити пакет, підписаний `keybase.io/technosophos`. Для цього скористайтесь інструментом `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` Перша команда вище відстежує користувача `technosophos`. Далі `keybase pgp pull` завантажує ключі OpenPGP усіх облікових записів, за якими ви стежите, і розміщує їх у вашій вʼязці ключів GnuPG (`~/.gnupg/pubring.gpg`). На цьому етапі ви можете використовувати `helm verify` або будь-яку з команд із прапорцем `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Причини, через які чарт може не пройти перевірку {#reasons-a-chart-may-not-verify} Це поширені причини невдач. - Файл `.prov` відсутній або пошкоджений. Це вказує на те, що щось налаштовано неправильно або що оригінальний мейнтейнер не створив файл походження. - Ключ, використаний для підписання файлу, відсутній у вашій вʼязці ключів. Це вказує на те, що субʼєкт, який підписав чарт, не є тим, кому ви вже довіряєте. - Перевірка файлу `.prov` не вдалася. Це означає, що щось не так з чартом або даними про походження. - Хеші файлів у файлі походження не збігаються з хешем архівного файлу. Це свідчить про те, що архів було підроблено. Якщо перевірка не пройшла, це є підставою для недовіри до пакета. ## Файл походження {#the-provenance-file} Файл походження містить файл YAML чарту та кілька елементів інформації для перевірки. Файли походження призначені для автоматичного генерування. Додаються наступні частини даних про походження: - Файл чарту (`Chart.yaml`) включається для зручного перегляду вмісту чарту як людьми, так і інструментами. - Підпис (SHA256, аналогічно до Docker) пакету чарту (файл `.tgz`) включається та може бути використаний для перевірки цілісності пакета чарту. - Весь зміст підписується за допомогою алгоритму OpenPGP (див. [Keybase.io](https://keybase.io) для спрощення процесу криптографічного підпису та перевірки). Це надає користувачам такі гарантії: - Пакет не було підроблено (перевірка контрольної суми пакета `.tgz`). - Особа, яка випустила цей пакет, є відомою (через підпис GnuPG/PGP). Формат файлу виглядає приблизно так: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Зверніть увагу, що розділ YAML містить два документи (розділені `...\n`). Перший файл — це вміст `Chart.yaml`. Другий — це контрольні суми, map імен файлів та SHA-256 дайджестів вмісту цього файлу на момент пакування. Блок підпису є стандартним підписом PGP, який забезпечує [стійкість до підробок](https://www.rossde.com/PGP/pgp_signatures.html). ## Репозиторії чартів {#chart-repositories} Репозиторії чартів виконують функцію централізованого сховища чартів Helm. Репозиторії чартів повинні забезпечувати можливість надання файлів походження через HTTP за певним запитом і повинні робити їх доступними за тим же шляхом URI, що й чарт. Наприклад, якщо базовий URL для пакета — `https://example.com/charts/mychart-1.2.3.tgz`, файл походження, якщо він існує, ПОВИНЕН бути доступний за адресою `https://example.com/charts/mychart-1.2.3.tgz.prov`. З погляду кінцевого користувача, команда `helm install --verify myrepo/mychart-1.2.3` повинна призвести до завантаження як чарту, так і файлу походження без додаткових налаштувань або дій користувача. ### Підписи в OCI-реєстрах {#signatures-in-oci-based-registries} Під час публікації чартів в [OCI-реєстрі](/topics/registries.mdx) можна використовувати втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore/) для публікації файлів походження в [sigstore](https://sigstore.dev/). Як описано в [документації](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), процес створення файлів походження та підписання за допомогою ключа GPG є загальним, але команду `helm sigstore upload` можна використовувати для публікації походження в незмінному прозорому лозі. ## Запровадження перевірки повноважень та автентичності{#establishing-authority-and-authenticity} При роботі з системами ланцюжків довіри важливо мати можливість встановити повноваження підписувача. Іншими словами, система, описана вище, базується на тому, що ви довіряєте особі, яка підписала чарт. Це, своєю чергою, означає, що ви повинні довіряти відкритому ключу підписувача. Одним із технічних рішень щодо Helm полягало в тому, що проєкт Helm не буде вставляти себе в ланцюжок довіри як обовʼязкову ланку. Ми не хочемо бути «центром сертифікації» для всіх підписувачів чартів. Натомість ми всіляко підтримуємо децентралізовану модель, що є однією з причин, чому ми обрали OpenPGP нашою базовою технологією. Тому, коли йдеться про встановлення повноважень, ми залишили цей крок більш-менш невизначеним у Helm 2 (рішення, яке було перенесено в Helm 3). Проте, у нас є кілька порад і рекомендацій для тих, хто зацікавлений у використанні системи перевірки походження: - Платформа [Keybase](https://keybase.io) надає публічне централізоване сховище для інформації про довіру. - Ви можете використовувати Keybase для зберігання своїх ключів або отримання публічних ключів інших. - Keybase також має чудову документацію. - Хоча ми не тестували це, функція "захищений вебсайт" Keybase може бути використана для сервісу чартів Helm. - Основна ідея полягає в тому, що офіційний "рецензент чартів" підписує чарти своїм ключем, а отриманий файл походження потім завантажується в репозиторій чартів. - Було проведено деяку роботу стосовно ідеї включення списку дійсних ключів підпису до файлу `index.yaml` репозиторію. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/rbac.md ================================================ --- title: Контроль доступу на основі ролей description: Пояснює, як Helm взаємодіє з контролем доступу на основі ролей Kubernetes. sidebar_position: 11 --- У Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів [в офіційній документації Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). З версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації. З RBAC ви можете: - надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам - обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів) - обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера. Цей посібник призначений для адміністраторів, які хочуть обмежити область доступу користувача до API Kubernetes. ## Управління обліковими записами користувачів {#managing-user-accounts} Усі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі. Передбачається, що управління обліковими записами звичайних користувачів здійснюється зовнішньою незалежною службою. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. Стосовно цього, Kubernetes не має обʼєктів, які представляють облікові записи звичайних користувачів. Звичайних користувачів не можна додати до кластера за допомогою виклику API. На відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. Службові облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes. Запити API привʼязані або до звичайного користувача, або до службового облікового запису, або розглядаються як анонімні запити. Це означає, що кожен процес усередині або поза кластером, від користувача, який вводить `kubectl` на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію під час надсилання запитів до сервера API, або розглядатися як анонімний користувач. ## Roles, ClusterRoles, RoleBindings та ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings} У Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role. На рівні кластера вони називаються ClusterRoles і ClusterRoleBindings. Надання користувачеві ClusterRole надає йому доступ до перегляду та/або редагування ресурсів у всьому кластері. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли). ClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. `admin`, `edit` та `view` стандартні ClusterRoles часто використовуються таким чином. Ось кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (`cluster-admin`) та ролі з більш детальним доступом (`admin`, `edit`, `view`). | Стандартна ClusterRole | Стандартна ClusterRoleBinding | Опис |------------------------|-------------------------------|------------- | `cluster-admin` | Група `system:masters`. | Дозволяє суперкористувачеві виконувати будь-які дії з будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над усіма ресурсами в кластері та в усіх просторах імен. При використанні в RoleBinding надає повний контроль над усіма ресурсами в просторі імен rolebinding, включаючи сам простір імен. | `admin` | Немає | Дозволяє доступ адміністратора, який має бути наданий в межах простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє доступ для читання/запису до більшості ресурсів в просторі імен, включаючи можливість створювати ролі та rolebindings в просторі імен. Не дозволяє доступ для запису до квоти ресурсів або до самого простору імен. | `edit` | Немає | Дозволяє читати/записувати більшість обʼєктів в просторі імен. Не дозволяє переглядати або змінювати ролі чи привʼязки ролей. | `view` | Немає | Дозволяє доступ тільки для читання, щоб бачити більшість обʼєктів в просторі імен. Не дозволяє переглядати ролі або привʼязки ролей. Не дозволяє переглядати секрети, оскільки останні мають підвищений рівень доступу. ## Обмеження доступу облікових записів користувачів за допомогою RBAC {#restricting-a-user-accounts-access-using-rbac} Тепер, коли ми розуміємо основи контролю доступу на основі ролей, розглянемо, як адміністратор може обмежити область доступу користувача. ### Приклад: Надання користувачеві доступу для читання/запису в певному просторі імен {#example-grant-a-user-readwrite-access-to-a-particular-namespace} Щоб обмежити доступ користувача до певного простору імен, можна використовувати роль `edit` або `admin`. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати ClusterRole `admin`. Крім того, ви також можете створити RoleBinding з доступом `cluster-admin`. Надаючи користувачу доступ `cluster-admin` на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен. Для цього прикладу ми створимо користувача з роллю `edit`. Спочатку створіть простір імен: ```shell $ kubectl create namespace foo ``` Тепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль `edit`. ```shell $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Приклад: Надання користувачу доступу для читання/запису на рівні кластера {#example-grant-a-user-readwrite-access-at-the-cluster-scope} Якщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера. Для цього надайте користувачу доступ `admin` або `cluster-admin`. Надання користувачу доступу `cluster-admin` надає їм доступ до всіх ресурсів Kubernetes, включаючи доступ до вузлів з `kubectl drain` та інших адміністративних завдань. Рекомендується розглянути можливість надання користувачу доступу `admin`, або створити власну ClusterRole, адаптовану до їхніх потреб. ```shell $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Приклад: Надання користувачу доступу лише для читання до певного простору імен {#example-grant-a-user-read-only-access-to-a-particular-namespace} Ви, мабуть, помітили, що для перегляду секретів немає ClusterRole. ClusterRole `view` не надає користувачеві права доступу до Secrets через ризик підвищення привілеїв. Helm стандартно зберігає метадані релізів як Secrets. Щоб користувач міг виконати команду `helm list`, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний ClusterRole `secret-reader`. Створіть файл `cluster-role-secret-reader.yaml` і додайте до нього такий вміст: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Потім створіть ClusterRole за допомогою: ```shell $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Як тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів: ```shell $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Приклад: Надання користувачу доступу лише для читання на рівні кластера {#example-grant-a-user-read-only-access-at-the-cluster-scope} В деяких випадках може бути корисно надати користувачу доступ на рівні кластера. Наприклад, якщо користувач хоче виконати команду `helm list --all-namespaces`, API вимагає, щоб користувач мав доступ для читання на рівні кластера. Для цього надайте користувачу як `view`, так і `secret-reader` доступ, як описано вище, але за допомогою ClusterRoleBinding.. ```shell $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Додатково {#additional-thoughts} Вищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю за ресурсами, до яких користувачі мають доступ, ознайомтеся з [документацією Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по створенню власних Roles і ClusterRoles. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/registries.mdx ================================================ --- title: Використання OCI-реєстрів description: Як використовувати OCI для розповсюдження чартів. sidebar_position: 7 --- import Helm4 from "../_v4-in-progress.mdx" Рекомендується використовувати реєстри контейнерів з підтримкою [OCI](https://www.opencontainers.org/) для зберігання та обміну пакетами чартів. ## Використання OCI-реєстрів {#using-an-oci-based-registry} ### Репозиторії Helm в OCI-реєстрах {#helm-repositories-in-oci-based-registries} [Репозиторій Helm](/topics/chart_repository.md) — це спосіб зберігання та розповсюдження пакетів чартів Helm. OCI-реєстр може містити нуль або більше репозиторіїв Helm, а кожен з цих репозиторіїв може містити нуль або більше пакетів чартів Helm. ### Використання послуг реєстрів {#use-hosted-registries} Існує кілька реєстрів контейнерів з підтримкою OCI, які ви можете використовувати для ваших чартів Helm. Наприклад: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Щоб створити та налаштувати реєстр з підтримкою OCI, дотримуйтесь документації постачальника реєстру контейнерів на хостингу. :::note Ви можете використовувати [Docker Registry](https://docs.docker.com/registry/deploying/) або [`zot`](https://github.com/project-zot/zot), які є реєстрами з підтримкою OCI, на вашому компʼютері для розробки. Запуск реєстру з підтримкою OCI на вашому компʼютері, де відбувається розробка, слід використовувати лише для тестування. ::: ### Використання sigstore для підписування чартів з підтримкою OCI{#using-sigstore-to-sign-oci-based-charts} Втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) дозволяє використовувати [Sigstore](https://sigstore.dev/) для підписування чартів Helm тими ж інструментами, що й для підписування образів контейнерів. Це є альтернативою [перевірки походження на основі GPG](/topics/provenance.mdx), що підтримуються класичними [репозиторіями чартів](/topics/chart_repository.md). Детальнішу інформацію про використання втулка `helm sigstore` дивіться в [документації проєкту Sigstore](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Команди для роботи з реєстрами {#commands-for-working-with-registries} ### Команда `registry` {#the-registry-subcommand} #### `login` Вхід до реєстру (зручний варіант з ручним введенням пароля) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` Вихід з реєстру ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Команда `push` {#the-push-subcommand} Завантажити чарт до реєстру на основі OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Команда `push` може використовуватися тільки для `.tgz` файлів, створених заздалегідь за допомогою `helm package`. При використанні `helm push` для завантаження чарту до реєстру OCI, посилання має починатися з `oci://` і не повинно містити базове імʼя або теґ. Базове імʼя посилання на реєстр визначається з імені чарту, а теґ визначається з семантичної версії чарту. Це наразі є строгими вимогами. Деякі реєстри вимагають, щоб репозиторій та/або простір імен (якщо вказано) були створені заздалегідь. В іншому випадку під час операції `helm push` буде згенеровано помилку. Якщо ви створили [файл походження](/topics/provenance.mdx) (`.prov`) і він знаходиться поруч із файлом чарту `.tgz`, він буде автоматично завантажений до реєстру при виконанні команди `push`. Це призведе до створення додаткового шару в [маніфесті чарту Helm](#helm-chart-manifest). Користувачі втулка [helm-push](https://github.com/chartmuseum/helm-push) (для завантаження чартів до [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) можуть зіткнутися з проблемами, оскільки втулок конфліктує з новою вбудованою функцією `push`. Починаючи з версії v0.10.0, втулок було перейменовано на `cm-push`. ### Інші команди {#other-subcommands} Підтримка протоколу `oci://` також доступна в різних інших командах. Ось повний список: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Базова назва (назва чарту) посилання реєстру *включається* для будь-якого типу дії, повʼязаної із завантаженням чарту (на відміну від `helm push`, де вона не вказується). Ось декілька прикладів використання перерахованих вище команд для чартів з підтримкою OCI: ```shell $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Вказання залежностей {#specifying-dependencies} Залежності чарту можна витягнути з реєстру за допомогою команди `dependency update`. Поле `repository` для певного запису в `Chart.yaml` вказується як посилання на реєстр без базового імені: ```yaml dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Це завантажить `oci://localhost:5000/myrepo/mychart:2.7.0`, коли виконується `dependency update`. ## Маніфест Helm чарту {#helm-chart-manifest} Приклад маніфесту Helm чарту, представленого в реєстрі (зверніть увагу на поля `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Наступний приклад містить [файл походження](/topics/provenance.mdx) (зверніть увагу на додатковий шар): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Міграція з репозиторіїв чартів {#migrating-from-chart-repos} Міграція з класичних [репозиторіїв чартів](/topics/chart_repository.md) (репозиторіїв на основі index.yaml) є простим процесом: використовуйте `helm pull`, а потім `helm push`, щоб завантажити отримані файли `.tgz` до реєстру. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current/topics/version_skew.mdx ================================================ --- title: Політика підтримки версій Helm description: Описує політику випуску патчів Helm, а також максимальну підтримувану різницю версій між Helm і Kubernetes. --- Цей документ описує максимальну підтримувану різницю версій між Helm і Kubernetes. ## Підтримувані версії {#supported-versions} Версії Helm виражаються у форматі `x.y.z`, де `x` — це основна версія, `y` — це мінорна версія, а `z` — це версія патчу, відповідно до [семантичного версіювання](https://semver.org/lang/uk/spec/v2.0.0.html). Проєкт Helm підтримує релізну гілку для останнього мінорного випуску. Застосовні виправлення, включаючи виправлення безпеки, додаються в релізну гілку залежно від їх серйозності та можливості впровадження. Більше деталей можна знайти в [політиці випусків Helm](/community/release_policy). ## Підтримувана різниця версій {#supported-version-skew} Коли виходить нова версія Helm, вона компілюється для конкретної мінорної версії Kubernetes. Наприклад, Helm v4.0.0 взаємодіє з Kubernetes за допомогою клієнта Kubernetes 1.34.1, тому він сумісний з Kubernetes 1.34. Починаючи з Helm 4, Helm вважається сумісним з версіями Kubernetes `n-3`, для яких він був скомпільований. Наприклад, якщо ви використовуєте версію Helm 4, яка була скомпільована для клієнтських API Kubernetes v1.35, то її можна безпечно використовувати з Kubernetes v1.35, v1.34, v1.33 та v1.32. Не рекомендується використовувати Helm з версією Kubernetes, яка є новішою за версію, для якої він був скомпільований, оскільки Helm не дає жодних гарантій сумісності з майбутніми версіями. Якщо ви вирішили використовувати Helm з версією Kubernetes, яку він не підтримує, ви використовуєте його на власний ризик. Будь ласка, зверніться до таблиці нижче, щоб визначити, яка версія Helm сумісна з вашим кластером. | Версія Helm | Підтримувані версії Kubernetes | |--------------|-------------------------------| | 4.0.x | 1.34.x - 1.31.x | ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "Використання Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Команди Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Чарти", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "Розробка шаблонів", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Найкращі практики", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: Загальні домовленості description: Загальні домовленості для чартів. sidebar_position: 1 --- Ця частина Посібника з найкращих практик пояснює загальні домовленості. ## Назви чартів {#chart-names} Назви чартів повинні складатися з літер нижнього регістру та цифр. Слова _можуть_ бути розділені дефісами (-): Приклади: ```none drupal nginx-lego aws-cluster-autoscaler ``` У назвах чартів не можна використовувати великі літери та підкреслення. Також не слід використовувати крапки. ## Номери версій {#version-numbers} По можливості, Helm використовує [SemVer 2](https://semver.org) для позначення номерів версій. (Зверніть увагу, що теґи Docker-образів не завжди відповідають SemVer і тому вважаються невдалим винятком з правила.) Коли версії SemVer зберігаються в мітках Kubernetes, ми умовно змінюємо символ `+` на `_`, оскільки мітки не допускають використання знака `+` як значення. ## Форматування YAML {#formatting-yaml} Файли YAML повинні використовувати відступи у _два пробіли_ (і ніколи табуляцією). ## Використання слів Helm і Chart {#usage-of-the-words-helm-and-chart} Існує кілька конвенцій щодо використання слів _Helm_ і _helm_. - _Helm_ відноситься до проєкту в цілому - `helm` відноситься до клієнтської команди - Термін `chart` не потрібно писати з великої літери, оскільки це не власна назва - Однак `Chart.yaml` необхідно писати з великої літери, оскільки назва файлу чутлива до регістру У разі сумніву використовуйте _Helm_ (з великої літери "H"). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: Як створювати та використовувати CRD (Custom Resource Definitions). sidebar_position: 7 --- Цей розділ посібника з найкращих практик розглядає створення та використання обʼєктів Custom Resource Definition (CRD). При роботі з CRD важливо розрізняти два різні аспекти: - Існує декларація CRD. Це YAML файл, який має `kind: CustomResourceDefinition`. - Потім є ресурси, які _використовують_ CRD. Наприклад, якщо CRD визначає `foo.example.com/v1`, будь-який ресурс, який має `apiVersion: example.com/v1` і `kind: Foo`, є ресурсом, що використовує цей CRD. ## Встановлення декларації CRD перед використанням ресурсу {#install-a-crd-declaration-before-using-the-resource} Helm оптимізований для швидкого завантаження якомога більшої кількості ресурсів у Kubernetes. За дизайном Kubernetes може обробити цілий набір маніфестів і активувати їх усі (це називається циклом узгодження). Але є різниця з CRD. Для CRD декларація повинна бути зареєстрована до того, як будь-які ресурси цього типу CRD можуть бути використані. Процес реєстрації іноді займає кілька секунд. ### Метод 1: Нехай `helm` зробить це за вас {#method-1-let-helm-do-it-for-you} З приходом Helm 3 ми видалили старі `crd-install` хуки на користь простішої методології. Тепер існує спеціальна тека `crds`, яку ви можете створити у вашому чарті для зберігання CRD. Ці CRD не підлягають шаблонізації, але будуть стандартно встановлені під час виконання `helm install` для чарту. Якщо CRD вже існує, його буде пропущена з попередженням. Якщо ви бажаєте пропустити крок встановлення CRD, ви можете використовувати прапорець `--skip-crds`. #### Декілька застережень (і пояснень) {#some-caveats-and-explanations} Зараз не підтримується оновлення або видалення CRD за допомогою Helm. Це було зроблено після тривалого обговорення у спільноті через небезпеку випадкової втрати даних. Крім того, наразі немає консенсусу в спільноті щодо того, як управляти CRD та їх життєвим циклом. Як це буде розвиватися, Helm додасть підтримку для цих випадків. Прапорець `--dry-run` для `helm install` і `helm upgrade` наразі не підтримується для CRD. Мета "Dry Run" полягає в перевірці того, що вивід чарту дійсно працюватиме, якщо буде надіслано на сервер. Але CRD є модифікацією поведінки сервера. Helm не може встановити CRD під час сухого запуску, тому клієнт виявлення не дізнається про цей Custom Resource (CR), і перевірка не пройде. Ви можете перемістити CRD до окремого чарту або використовувати `helm template` замість цього. Ще один важливий момент, який слід врахувати в обговоренні підтримки CRD, — це те, як обробляється рендеринг шаблонів. Одним з відмінних недоліків методу `crd-install`, що використовувався в Helm 2, була неспроможність правильно перевіряти чарти через зміну доступності API (CRD фактично додає ще один доступний API до вашого кластера Kubernetes). Якщо чарт встановлював CRD, `helm` більше не мав дійсного набору версій API, з якими можна було працювати. Це також є причиною видалення підтримки шаблонізації для CRD. З новим методом `crds` для встановлення CRD ми тепер забезпечуємо, що `helm` має абсолютно достовірну інформацію про поточний стан кластера. ### Метод 2: Окремі чарти {#method-2-separate-charts} Ще один спосіб зробити це — помістити визначення CRD в один чарт, а потім розмістити будь-які ресурси, які використовують цей CRD, в _іншому_ чарті. В цьому методі кожен чарт потрібно встановлювати окремо. Однак цей робочий процес може бути більш корисним для адміністраторів кластерів, які мають права адміністратора на кластер. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Залежності description: Охоплює найкращі практики для залежностей Charts. sidebar_position: 4 --- Цей розділ посібника охоплює найкращі практики для `залежностей`, оголошених у `Chart.yaml`. ## Версії {#versions} По можливості використовуйте діапазони версій замість привʼязки до точної версії. Рекомендоване стандартне значення — це використання відповідності на рівні патчу: ```yaml version: ~1.2.3 ``` Це буде відповідати версії `1.2.3` та будь-яким патчам для цього випуску. Іншими словами, `~1.2.3` є еквівалентом `>= 1.2.3, < 1.3.0`. Для повної синтаксичної відповідності версій див. [документацію semver](https://github.com/Masterminds/semver#checking-version-constraints). ### Попередні версії {#prereleases-versions} Вищезгадані обмеження версій не будуть відповідати попереднім версіям. Наприклад, `version: ~1.2.3` буде відповідати `version: ~1.2.4`, але не `version: ~1.2.3-1`. Наступне забезпечує відповідність як попередніх версій, так і на рівні патчу: ```yaml version: ~1.2.3-0 ``` ### URL-адреси репозиторіїв {#repository-urls} По можливості використовуйте URL-адреси репозиторіїв `https://`, далі `http://`. Якщо репозиторій був доданий до файлу індексу репозиторіїв, імʼя репозиторію може бути використане як псевдонім URL. Використовуйте `alias:` або `@`, за яким слідують імена репозиторіїв. URL-адреси файлів (`file://...`) вважаються "особливим випадком" для чартів, які збираються фіксованим процесом розгортання. При використанні [втулків завантажувача](/topics/plugins.md#downloader-plugins) схема URL буде специфічною для втулка. Зверніть увагу, що користувачеві чарту буде потрібно мати втулок, що підтримує схему, встановлений для оновлення або побудови залежності. Helm не може виконувати операції управління залежностями для залежності, коли поле `repository` залишено порожнім. У цьому випадку Helm припускатиме, що залежність знаходиться в підтеці теки `charts` з іменем, яке відповідає властивості `name` для залежності. ## Умови та теґи {#conditions-and-tags} Умови або теґи слід додавати до будь-яких залежностей, які _є необовʼязковими_. Бажана форма умови є такою: ```yaml condition: somechart.enabled ``` Де `somechart` є іменем чарту залежності. Коли кілька субчартів (залежностей) разом забезпечують необовʼязкову або замінну функцію, ці чарт можуть мати спільні теґи. Наприклад, якщо як `nginx`, так і `memcached` разом забезпечують оптимізації продуктивності для основного застосунку в чарті та вони потрібні, щоб обидва були присутні, коли ця функція увімкнена, то вони повинні мати розділ теґів як цей: ```yaml tags: - webaccelerator ``` Це дозволяє користувачеві вмикати або вимикати цю функцію за допомогою одного теґу. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: Найкращі практики sidebar: true sidebar_position: 4 --- # Посібник з найкращих практик створення чартів Цей посібник охоплює найкращі практики, рекомендовані командою Helm, для створення чартів. Основна увага приділяється тому, як повинні бути структуровані чарти. Ми зосереджуємось головним чином на найкращих практиках для чартів, які можуть бути опубліковані публічно. Ми розуміємо, що багато чартів використовуються виключно для внутрішніх потреб, і автори таких чартів можуть вважати, що їхні внутрішні інтереси переважають наші рекомендації тут. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: Мітки та Анотації description: Охоплює найкращі практики використання міток та анотацій у вашому Chart. sidebar_position: 5 --- Цей розділ посібника з найкращих практик обговорює найкращі практики для використання міток та анотацій у вашому чарті. ## Це мітка чи анотація? {#is-it-a-label-or-an-annotation} Елемент метаданих слід вважати міткою за таких умов: - Він використовується Kubernetes для ідентифікації цього ресурсу - Він корисний для експонування операторам з метою запиту системи. Наприклад, рекомендується використовувати `helm.sh/chart: NAME-VERSION` як мітку, щоб оператори могли зручно знаходити всі екземпляри конкретного чарту. Якщо елемент метаданих не використовується для запитів, його слід встановити як анотацію. Helm hooks завжди є анотаціями. ## Стандартні Мітки {#standard-labels} Наступна таблиця визначає загальні мітки, які використовуються в Helm чарті. Helm сам по собі ніколи не вимагає наявності конкретної мітки. Мітки, які позначені як REC, є рекомендованими та _повинні_ бути розміщені в чарті для глобальної узгодженості. Ті, що позначені як OPT, є необовʼязковими. Це ідіоматичні або часто використовувані мітки, але не є критично важливими для операційних цілей. | Назва | Статус | Опис | |-------|--------|------| | `app.kubernetes.io/name` | REC | Це повинно бути імʼя застосунку, яке відображає весь застосунок. Зазвичай використовується `{{ template "name" . }}`. Це використовується багатьма маніфестами Kubernetes і не є специфічним для Helm. | | `helm.sh/chart` | REC | Це повинно бути імʼя чарту та версія: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. | | `app.kubernetes.io/managed-by` | REC | Це завжди повинно бути встановлено як `{{ .Release.Service }}`. Це для знаходження всього, що управляється Helm. | | `app.kubernetes.io/instance` | REC | Це повинно бути `{{ .Release.Name }}`. Це допомагає відрізняти різні екземпляри одного й того ж застосунку. | | `app.kubernetes.io/version` | OPT | Версія застосунку і може бути встановлена як `{{ .Chart.AppVersion }}`. | | `app.kubernetes.io/component` | OPT | Це загальна мітка для позначення різних ролей, які елементи можуть відігравати в застосунку. Наприклад, `app.kubernetes.io/component: frontend`. | | `app.kubernetes.io/part-of` | OPT | Коли кілька чартів або програмних частин використовуються разом для створення одного застосунку. Наприклад, програмне забезпечення та база даних для створення вебсайту. Це можна встановити на рівні основного застосунку, що підтримується. | Ви можете знайти більше інформації про мітки Kubernetes, що починаються з `app.kubernetes.io`, в [документації Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods та PodTemplates description: Обговорює форматування частин Pod та PodTemplate у маніфестах Chart. sidebar_position: 6 --- Цей розділ посібника з найкращих практик обговорює форматування частин Pod та PodTemplate у маніфестах чарту. Наступний (неповний) список ресурсів використовує PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Образи {#images} Образи контейнера повинні використовувати фіксовану мітку або SHA образу. Не слід використовувати мітки `latest`, `head`, `canary` або інші мітки, які призначені для "плаваючих" версій. Образи _можуть_ бути визначені у файлі `values.yaml`, щоб спростити заміну образів. ```yaml image: {{ .Values.redisImage | quote }} ``` Образи та мітка _можуть_ бути визначені в `values.yaml` як два окремих поля: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` стандартно встановлює `imagePullPolicy` на `IfNotPresent`, роблячи це у вашому `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` А у `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Аналогічно, Kubernetes стандартно встановлює `imagePullPolicy` на `IfNotPresent`, якщо він зовсім не визначений. Якщо вам потрібне інше значення, просто оновіть його в `values.yaml` на потрібне значення. ## PodTemplates повинні оголошувати селектори Усі секції PodTemplate повинні вказувати селектор. Наприклад: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` Це гарна практика, оскільки вона робить відносини між набором і pod чіткішими. Але це ще важливіше для таких наборів, як Deployment. Без цього, _весь_ набір міток використовується для вибору відповідних pod, і це може зламатися, якщо ви використовуєте мітки, які змінюються, такі як версія або дата релізу. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Role-Based Access Control description: Обговорює створення та форматування RBAC ресурсів у маніфестах чарта. sidebar_position: 8 --- Цей розділ посібника з найкращих практик розглядає створення та форматування ресурсів RBAC у маніфестах чарту. Ресурси RBAC це: - ServiceAccount (обмежений простором імен) - Role (обмежений простором імен) - ClusterRole - RoleBinding (обмежений простором імен) - ClusterRoleBinding ## Конфігурація YAML {#yaml-configuration} Конфігурація RBAC та ServiceAccount повинна здійснюватися під окремими ключами. Це окремі речі. Розділення цих двох концепцій у YAML знімає неоднозначність і робить це ясніше. ```yaml rbac: # Вказує, чи повинні бути створені ресурси RBAC create: true serviceAccount: # Вказує, чи повинен бути створений ServiceAccount create: true # Імʼя ServiceAccount для використання. # Якщо не вказано і create дорівнює true, імʼя генерується за допомогою шаблону fullname name: ``` Цю структуру можна розширити для складніших чартів, які потребують кількох ServiceAccount. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## Ресурси RBAC повинні бути стандартно створені {#rbac-resources-should-be-created-by-default} `rbac.create` має бути булевим значенням, яке контролює, чи створюються ресурси RBAC. Стандартне значення має бути `true`. Користувачі, які бажають самостійно управляти контролем доступу RBAC, можуть встановити це значення в `false` (у цьому випадку дивіться нижче). ## Використання ресурсів RBAC {#using-rbac-resources} `serviceAccount.name` має бути встановлено на імʼя ServiceAccount, яке буде використовуватися доступними ресурсами, створеними чартом. Якщо `serviceAccount.create` дорівнює true, то ServiceAccount з цим імʼям має бути створено. Якщо імʼя не вказано, то імʼя генерується за допомогою шаблону `fullname`. Якщо `serviceAccount.create` дорівнює false, то ServiceAccount не створюється, але він має бути асоційований з тими ж ресурсами, щоб пізніше створені вручну ресурси RBAC, що посилаються на нього, функціонували правильно. Якщо `serviceAccount.create` дорівнює false та імʼя не вказано, то використовується стандартний ServiceAccount. Для ServiceAccount слід використовувати наступний допоміжний шаблон. ```yaml {{/* Створіть імʼя ServiceAccount для використання */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: Шаблони description: Ближче ознайомлення з найкращими практиками щодо шаблонів. sidebar_position: 3 --- Ця частина посібника з найкращих практик фокусується на шаблонах. ## Структура `templates/` {#structure-of-templates} Теку `templates/` слід структурувати наступним чином: - Файли шаблонів повинні мати розширення `.yaml`, якщо вони генерують YAML-вихід. Розширення `.tpl` можна використовувати для файлів шаблонів, які не генерують форматований контент. - Імена файлів шаблонів повинні використовувати дефіси (`my-example-configmap.yaml`), а не camelCase. - Кожне визначення ресурсу повинно бути у власному файлі шаблону. - Імена файлів шаблонів повинні відображати тип ресурсу в імені. Наприклад, `foo-pod.yaml`, `bar-svc.yaml`. ## Імена визначених шаблонів {#names-of-defined-templates} Визначені шаблони (шаблони, створені всередині директиви `{{ define }}`) є глобально доступними. Це означає, що чарт і всі його субчарти матимуть доступ до всіх шаблонів, створених з `{{ define }}`. З цієї причини _усі імена визначених шаблонів повинні бути просторово іменовані_. Правильно: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Неправильно: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` Рекомендується, щоб нові чарти створювалися за допомогою команди `helm create`, оскільки імена шаблонів автоматично визначаються відповідно до цієї найкращої практики. ## Форматування шаблонів {#formatting-templates} Шаблони повинні мати відступи у _два пробіли_ (ніколи не табуляцією). Директиви шаблону повинні мати пробіл після відкриваючих дужок і перед закриваючими дужками: Правильно: ```go {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Неправильно: ```go {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Шаблони повинні обрізати пробіли, де це можливо: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Блоки (такі як контрольні структури) можуть мати відступи для вказівки потоку коду шаблону. ```go {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` Однак, оскільки YAML є мовою, орієнтованою на пробіли, часто неможливо, щоб відступи коду слідували цій конвенції. ## Пробіли у згенерованих шаблонах {#whitespace-in-generated-templates} Бажано мінімізувати кількість пробілів у згенерованих шаблонах. Особливо слід уникати численних порожніх рядків, які йдуть один за одним. Але випадкові порожні рядки (особливо між логічними секціями) допустимі. Це краще: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Це прийнятно: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` Але це слід уникати: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Коментарі (Коментарі YAML vs. Коментарі шаблонів) {#comments-yaml-comments-vs-template-comments} Як YAML, так і шаблони Helm мають маркери коментарів. Коментарі YAML: ```yaml # Це коментар type: sprocket ``` Коментарі шаблонів: ```yaml {{- /* Це коментар. */}} type: frobnitz ``` Коментарі шаблонів слід використовувати для документування функцій шаблону, наприклад, пояснюючи визначений шаблон: ```yaml {{- /* mychart.shortname надає скорочену версію імені релізу до 6 символів. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Всередині шаблонів коментарі YAML можуть використовуватися, коли це корисно для користувачів Helm (можливо) бачити коментарі під час налагодження. ```yaml # Це може спричинити проблеми, якщо значення більше ніж 100Gi memory: {{ .Values.maxMem | quote }} ``` Вищенаведений коментар видимий, коли користувач виконує `helm install --debug`, тоді як коментарі, вказані в секціях `{{- /* */}}`, не видно. Остерігайтеся додавання `#` коментарів YAML у секції шаблону, що містять значення Helm, які можуть бути потрібні для деяких функцій шаблону. Наприклад, якщо функція `required` вводиться у наведеному вище прикладі, і `maxMem` не встановлено, коментар `#` YAML спричинить помилку рендерингу. Правильно: `helm template` не рендерить цей блок ```yaml {{- /* # Це може спричинити проблеми, якщо значення більше ніж 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Неправильно: `helm template` повертає `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # Це може спричинити проблеми, якщо значення більше ніж 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Огляньте [Налагодження шаблонів](/chart_template_guide/debugging.md) для іншого прикладу цієї поведінки того, як коментарі YAML залишаються недоторканими. ## Використання JSON у шаблонах і виході шаблонів {#use-of-json-in-templates-and-template-output} YAML є надмножиною JSON. У деяких випадках використання синтаксису JSON може бути більш читабельним, ніж інші представлення YAML. Наприклад, цей YAML ближчий до звичайного методу представлення списків у YAML: ```yaml arguments: - "--dirname" - "/foo" ``` Але його легше читати, коли його стисло представлено у стилі списку JSON: ```yaml arguments: ["--dirname", "/foo"] ``` Використання JSON для підвищення читабельності є корисним. Однак синтаксис JSON не слід використовувати для представлення cкладніших конструкцій. При роботі з чистим JSON, вбудованим всередині YAML (наприклад, конфігурація контейнера ініціалізації), звичайно, доречно використовувати формат JSON. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Значення description: Орієнтовано на те, як ви повинні структурувати та використовувати значення. sidebar_position: 2 --- Ця частина посібника з найкращих практик охоплює використання значень. Ми надаємо рекомендації щодо структурування та використання значень, зосереджуючись на дизайні файлу `values.yaml` чарту. ## Домовленості щодо назв {#naming-conventions} Назви змінних повинні починатися з малої літери, а слова мають розділятися верблюжим регістром (camelCase): Правильно: ```yaml chicken: true chickenNoodleSoup: true ``` Неправильно: ```yaml Chicken: true # початкова велика літера може конфліктувати з вбудованими змінними chicken-noodle-soup: true # не використовуйте дефіси в назвах ``` Зверніть увагу, що всі вбудовані змінні Helm починаються з великої літери, щоб їх легко було відрізнити від користувацьких значень: `.Release.Name`, `.Capabilities.KubeVersion`. ## Пласкі або вкладені значення {#flat-or-nested-values} YAML — це гнучкий формат, і значення можуть бути вкладеними або пласкими. Вкладені: ```yaml server: name: nginx port: 80 ``` Пласкі: ```yaml serverName: nginx serverPort: 80 ``` У більшості випадків слід віддавати перевагу пласким структурам над вкладеними. Це зумовлено тим, що їх простіше використовувати розробникам шаблонів та користувачам. Для забезпечення максимальної безпеки вкладене значення має перевірятися на кожному рівні: ```go {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` Для кожного шару вкладення необхідно виконувати перевірку на наявність. Однак для пласкої конфігурації такі перевірки можна пропустити, що спрощує читання та використання шаблону. ```go {{ default "none" .Values.serverName }} ``` Коли існує велика кількість пов’язаних змінних і хоча б одна з них є обов’язковою, вкладені значення можуть використовуватися для підвищення зручності читання. ## Чітке визначення типів {#make-types-clear} Правила перетворення типів YAML іноді можуть бути неінтуїтивними. Наприклад, `foo: false` не те саме, що і `foo: "false"`. Великі цілі числа, такі як `foo: 12345678`, у деяких випадках будуть перетворюватися на наукову нотацію. Найпростіший спосіб уникнути помилок перетворення типів — бути явним щодо рядків і неявним щодо всього іншого. Або, коротко кажучи, _беріть всі рядки в лапки_. Часто для уникнення проблем із перетворенням чисел наукової нотації вигідно зберігати ваші цілі числа у вигляді рядків і використовувати `{{ int $value }}` у шаблоні для перетворення з рядкового значення назад на ціле число. У більшості випадків явні типи поважаються, тому `foo: !!string 1234` має обробляти `1234` як рядок. _Проте_ парсер YAML споживає теґи, тому дані про типи втрачаються після одного аналізу. ## Розгляд використання ваших значень користувачами {#consider-your-values-used-by-users} Існує три потенційні джерела значень: - Файл `values.yaml` чарту - Файл значень, переданий за допомогою `helm install -f` або `helm upgrade -f` - Значення, передані з прапорцем `--set` або `--set-string` під час `helm install` або `helm upgrade` При проєктуванні структури ваших значень майте на увазі, що користувачі вашого чарту можуть захотіти перевизначити їх за допомогою прапорця `-f` або опції `--set`. Оскільки `--set` більш обмежений у виразності, перше правило написання файлу `values.yaml` — _зробіть його зручним для перевизначення за допомогою `--set`_. З цієї причини часто краще структурувати файл значень, використовуючи map. Важко використовувати з `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` Вищенаведене не можна виразити за допомогою `--set` у Helm `<=2.4`. У Helm 2.5 доступ до порту на foo здійснюється через `--set servers[0].port=80`. Не тільки це важче зрозуміти для користувача, але це ще й схильне до помилок, якщо пізніше порядок серверів зміниться. Легко використовувати: ```yaml servers: foo: port: 80 bar: port: 81 ``` Отримання доступу до порту foo стає набагато очевиднішим: `--set servers.foo.port=80`. ## Документуйте `values.yaml` {#document-valuesyaml} Кожна визначена властивість у `values.yaml` повинна бути задокументована. Рядок документації повинен починатися з назви властивості, яку він описує, а потім надавати принаймні одне речення опису. Неправильно: ```yaml # назва хосту для веб-сервера serverHost: example serverPort: 9191 ``` Правильно: ```yaml # serverHost - це назва хосту для веб-сервера serverHost: example # serverPort - це порт HTTP-сервера для веб-сервера serverPort: 9191 ``` Початок кожного коментаря з назви параметра, який він документує, дозволяє легко знаходити документацію та дозволяє інструментам документації надійно співвідносити рядки документації з параметрами, які вони описують. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Доступ до файлів всередині шаблонів description: Як отримати доступ до файлів зсередини шаблону. sidebar_position: 10 --- У попередньому розділі ми розглянули кілька способів створення та доступу до іменованих шаблонів. Це полегшує імпорт одного шаблону в інший шаблон. Але іноді корисно імплементувати _файл, який не є шаблоном_ і вбудувати його вміст без використання рендерера шаблонів. Helm надає доступ до файлів через обʼєкт `.Files`. Перш ніж переходити до прикладів шаблонів, є кілька моментів, які слід врахувати: - Можна додавати додаткові файли до вашого Helm чарту. Ці файли будуть упаковані. Але будьте обережні. Чарти мають бути меншими за 1М через обмеження зберігання обʼєктів Kubernetes. - Деякі файли не можна отримати через обʼєкт `.Files`, зазвичай з міркувань безпеки. - Файли в `templates/` не можна отримати. - Файли, виключені за допомогою `.helmignore`, не можна отримати. - Файли поза Helm-застосукном [subchart](/chart_template_guide/subcharts_and_globals.md), включаючи файли батьківського чарту, не можна отримати. - Чарти не зберігають інформацію про режим UNIX, тому дозволи на рівні файлу не вплинуть на доступність файлу в обʼєкті `.Files`. - [Базовий приклад](#basic-example) - [Помічники оброки шляхів](#path-helpers) - [Шаблони Glob](#glob-patterns) - [Утиліти для ConfigMap і Secrets](#configmap-and-secrets-utility-functions) - [Кодування](#encoding) - [Рядки](#lines) ## Базовий приклад {#basic-example} З урахуванням цих застережень, напишемо шаблон, який читає три файли в наш ConfigMap. Для початку додамо три файли до чарту, розміщуючи всі три безпосередньо в теці `mychart/`. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Кожен з цих файлів є простим TOML-файлом (згадайте про старі INI-файли Windows). Ми знаємо імена цих файлів, тому можемо використовувати функцію `range`, щоб перебрати їх і вставити їх вміст у наш ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` Цей ConfigMap використовує кілька технік, обговорених у попередніх розділах. Наприклад, ми створюємо змінну `$files`, щоб зберегти посилання на обʼєкт `.Files`. Ми також використовуємо функцію `tuple`, щоб створити список файлів, які ми перебираємо. Потім ми виводимо кожне імʼя файлу (`{{ . }}: |-`) після чого йде вміст файлу `{{ $files.Get . }}`. Запуск цього шаблону створить один ConfigMap з вмістом усіх трьох файлів: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Помічники оброки шляхів {#path-helpers} При роботі з файлами може бути дуже корисно виконувати деякі стандартні операції з самими шляхами файлів. Для цього Helm імплементує багато функцій з пакета Go [path](https://golang.org/pkg/path/). Вони всі доступні з такими ж іменами, як у пакеті Go, але з маленькою першою літерою. Наприклад, `Base` стає `base` і т.д. Імпортовані функції: - Base - Dir - Ext - IsAbs - Clean ## Шаблони glob {#glob-patterns} Коли ваш чарт зростає, ви можете знайти необхідність організувати ваші файли більше, і тому ми надаємо метод `Files.Glob(pattern string)` для допомоги у витягуванні певних файлів з усією гнучкістю [шаблонів glob](https://godoc.org/github.com/gobwas/glob). `.Glob` повертає тип `Files`, тому ви можете викликати будь-які методи `Files` на повернутому обʼєкті. Наприклад, уявіть структуру директорій: ```none foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` У вас є кілька варіантів з Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Або ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## Утиліти для ConfigMap і Secrets {#configmap-and-secrets-utility-functions} (Доступні з Helm 2.0.2 і пізніше) Дуже часто потрібно помістити вміст файлів як у ConfigMaps, так і в Secrets, для монтування в ваші podʼи під час виконання. Для цього ми надаємо кілька методів утиліт для типу `Files`. Для подальшої організації особливо корисно використовувати ці методи разом з методом `Glob`. Задана структура теки з прикладу [Glob](#glob-patterns): ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Кодування {#encoding} Ви можете імплементувати файл і змусити шаблон закодувати його в base-64, щоб забезпечити успішну передачу: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` Вищенаведене візьме той самий файл `config1.toml`, який ми використовували раніше, і закодує його: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Рядки {#lines} Іноді потрібно отримати доступ до кожного рядка файлу у вашому шаблоні. Ми надаємо зручний метод `Lines` для цього. Ви можете перебрати `Lines`, використовуючи функцію `range`: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Немає можливості передавати файли, що знаходяться поза чартом, під час `helm install`. Тому, якщо ви просите користувачів надати дані, їх потрібно завантажити за допомогою `helm install -f` або `helm install --set`. Це обговорення завершує наше занурення в інструменти та техніки написання шаблонів Helm. У наступному розділі ми побачимо, як можна використовувати один спеціальний файл, `templates/NOTES.txt`, для надсилання інструкцій після установки користувачам вашого чарту. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Вбудовані обʼєкти description: Вбудовані обʼєкти, доступні для шаблонів. sidebar_position: 3 --- Обʼєкти передаються в шаблон з рушія обробки шаблонів. І ваш код може передавати обʼєкти далі (ми побачимо приклади, коли розглянемо оператори `with` та `range`). Є навіть кілька способів створити нові обʼєкти всередині ваших шаблонів, як, наприклад, з функцією `tuple`, яку ми розглянемо пізніше. Обʼєкти можуть бути простими та мати лише одне значення. Або вони можуть містити інші обʼєкти чи функції. Наприклад, обʼєкт `Release` містить кілька обʼєктів (наприклад, `Release.Name`), а обʼєкт `Files` має кілька функцій. У попередньому розділі ми використовували `{{ .Release.Name }}`, щоб вставити імʼя релізу в шаблон. `Release` — один з обʼєктів верхнього рівня, до якого ви можете отримати доступ у своїх шаблонах. - `Release`: Цей обʼєкт описує сам реліз. Він містить кілька обʼєктів: - `Release.Name`: Імʼя релізу - `Release.Namespace`: Простір імен, у який буде здійснено реліз (якщо маніфест не перевизначить) - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. - `Release.Revision`: Номер ревізії для цього релізу. Під час встановлення це 1, і він збільшується з кожним оновленням або відкатом. - `Release.Service`: Сервіс, який обробляє поточний шаблон. У Helm це завжди `Helm`. - `Values`: Значення, передані в шаблон з файлу `values.yaml` і з файлів, наданих користувачем. Стандартно `Values` порожній. - `Chart`: Вміст файлу `Chart.yaml`. Будь-які дані в `Chart.yaml` будуть доступні тут. Наприклад, `{{ .Chart.Name }}-{{ .Chart.Version }}` виведе `mychart-0.1.0`. - Доступні поля перелічені в [довіднику по Chart](/topics/charts.md#the-chart-yaml-file) - `Subcharts`: Надає доступ до області дії (.Values, .Charts, .Releases тощо) субшаблонів з батьківського шаблону. Наприклад, `.Subcharts.mySubChart.myValue`, щоб отримати доступ до `myValue` у шаблоні `mySubChart`. - `Files`: Це надає доступ до всіх не-спеціальних файлів у шаблоні. Ви не можете використовувати його для доступу до шаблонів, але можете використовувати його для доступу до інших файлів у шаблоні. Див. розділ [Доступ до файлів](/chart_template_guide/accessing_files.md) для отримання додаткової інформації. - `Files.Get` — це функція для отримання файлу за іменем (`.Files.Get config.ini`). - `Files.GetBytes` — це функція для отримання вмісту файлу у вигляді масиву байтів, а не рядка. Це корисно для таких речей, як образи. - `Files.Glob` — це функція, яка повертає список файлів, імена яких відповідають заданому шаблону оболонки. - `Files.Lines` — це функція, яка зчитує файл рядок за рядком. Це корисно для ітерації по кожному рядку у файлі. - `Files.AsSecrets` — це функція, яка повертає вміст файлів у вигляді Base64-кодованих рядків. - `Files.AsConfig` — це функція, яка повертає вміст файлів у вигляді YAML map. - `Capabilities`: Надає інформацію про можливості, які підтримує кластер Kubernetes. - `Capabilities.APIVersions` — це набір версій. - `Capabilities.APIVersions.Has $version` вказує на те, чи доступна версія (наприклад, `batch/v1`) або ресурс (наприклад, `apps/v1/Deployment`) у кластері. - `Capabilities.KubeVersion` і `Capabilities.KubeVersion.Version` — це версія Kubernetes. - `Capabilities.KubeVersion.Major` — це основна версія Kubernetes. - `Capabilities.KubeVersion.Minor` — це мінорна версія Kubernetes. - `Capabilities.HelmVersion` — це обʼєкт, який містить деталі версії Helm, це той самий вивід, що і `helm version`. - `Capabilities.HelmVersion.Version` — це поточна версія Helm у форматі semver. - `Capabilities.HelmVersion.GitCommit` — це Git-ідентифікатор SHA1 для Helm. - `Capabilities.HelmVersion.GitTreeState` — це стан дерева git для Helm. - `Capabilities.HelmVersion.GoVersion` — це версія компілятора Go, який використовувався. - `Template`: Містить інформацію про поточний шаблон, який виконується. - `Template.Name`: Іменований шлях до поточного шаблону (наприклад, `mychart/templates/mytemplate.yaml`). - `Template.BasePath`: Іменований шлях до теки шаблонів поточного шаблону (наприклад, `mychart/templates`). Вбудовані значення завжди починаються з великої літери. Це відповідає угоді про найменування у Go. Коли ви створюєте власні імена, ви можете використовувати угоду, яка підходить вашій команді. Деякі команди, як і багато тих, чиї шаблони ви можете бачити на [Artifact Hub](https://artifacthub.io/packages/search?kind=0), обирають використовувати лише початкові малі літери, щоб відрізнити локальні імена від вбудованих. У цьому посібнику ми дотримуємося цієї угоди. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Керування потоком description: Швидкий огляд структури керування потоком в шаблонах. sidebar_position: 7 --- Структури керування (називаються "діями" в термінології шаблонів) надають вам, автору шаблонів, можливість контролювати потік генерації шаблону. Мова шаблонів Helm надає такі структури керування: - `if`/`else` для створення умовних блоків - `with` для визначення області видимості - `range`, який надає цикл "for each" Окрім цих, є кілька дій для оголошення та використання іменованих сегментів шаблону: - `define` оголошує новий іменований шаблон всередині вашого шаблону - `template` імплементує іменований шаблон - `block` оголошує спеціальний тип заповнювальної області шаблону У цьому розділі ми розглянемо `if`, `with` та `range`. Інші дії будуть розглянуті в розділі "Іменовані шаблони" пізніше в цьому посібнику. ## If/Else Перша структура керування, яку ми розглянемо, використовується для умовного включення блоків тексту в шаблоні. Це блоки `if`/`else`. Основна структура блоку з умовою виглядає так: ```none {{ if PIPELINE }} # Щось зробити {{ else if OTHER PIPELINE }} # Зробити щось інше {{ else }} # Стандартне значення {{ end }} ``` Зверніть увагу, що тепер ми говоримо про _пайплайни_ замість значень. Причина в цьому полягає в тому, щоб уточнити, що структури керування можуть виконувати цілий пайплайн, а не лише оцінювати значення. Пайплайн вважається _хибним_, якщо значення є: - булевим хибним - числовим нулем - порожнім рядком - `nil` (порожнім або null) - порожньою колекцією (`map`, `slice`, `tuple`, `dict`, `array`) У всіх інших умовах умова є істинною. Додамо просту умовну конструкцію до нашого ConfigMap. Ми додамо ще одне налаштування, якщо напій встановлений на каву: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Оскільки ми закоментували `drink: coffee` у нашому останньому прикладі, вихідний файл не повинен містити прапорець `mug: "true"`. Але якщо ми додамо цей рядок назад у наш файл `values.yaml`, вихід виглядатиме так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Контроль пробілів {#controlling-whitespace} Під час роботи з умовами варто звернути увагу на те, як контролюється кількість пробілів у шаблонах. Розглянемо попередній приклад і відформатуємо його для зручнішого читання: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Спочатку це має гарний вигляд. Але якщо ми пропустимо його через рушій шаблонів, отримаємо неприємний результат: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` Що сталося? Ми згенерували некоректний YAML через пробіли. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` має невірний відступ. Виправимо це, зменшивши відступ цього рядка, і запустимо знову: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Коли ми запустимо це, отримаємо валідний YAML, але з кількома порожніми рядками: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Помітно, що у нас є кілька пустих рядків у YAML. Чому? Коли рушій шаблонів виконує шаблон, він _видаляє_ вміст всередині `{{` і `}}`, але залишає пробіли без змін. YAML надає значення пробілам, тому управління пробілами стає важливим. На щастя, шаблони Helm мають кілька інструментів у поміч. По-перше, синтаксис фігурних дужок шаблонів можна модифікувати за допомогою спеціальних символів, щоб вказати движку шаблонів обрізати пробіли. `{{- ` (з тире і пробілом) вказує, що пробіли зліва повинні бути видалені, тоді як ` -}}` означає, що пробіли справа повинні бути видалені. _Будьте обережні! Нові рядки — це пробіли!_ > Переконайтеся, що є пробіл між `-` і рештою вашої директиви. `{{- 3 }}` означає "вирізати ліві пробіли та вивести 3", тоді як `{{-3 }}` означає "вивести -3". Використовуючи цей синтаксис, ми можемо змінити наш шаблон, щоб позбутися від тих нових рядків: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Щоб прояснити це, відзначимо кожен пробіл, який буде видалено відповідно до цього правила. `*` в кінці рядка вказує на символ нового рядка, який буде видалений: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Зважаючи на це, ми можемо запустити наш шаблон через Helm і побачити результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Будьте обережні з модифікаторами обрізання пробілів. Легко випадково зробити ось так: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` Це створить `food: "PIZZA"mug: "true"`, оскільки пробіли з обох сторін будуть видалені. > Для деталей про контроль пробілів у шаблонах дивіться [Офіційну документацію Go шаблонів](https://godoc.org/text/template) Нарешті, іноді легше сказати системі шаблонів, як вам потрібно робити відступи, замість того, щоб намагатися освоїти розташування пробілів у директивах шаблону. З цієї причини іноді корисно використовувати функцію `indent` (`{{ indent 2 "mug:true" }}`). ## Модифікація області видимості за допомогою `with` {#modifying-scope-using-with} Наступна структура управління, яку розглянемо, це дія `with`. Вона контролює область видимості змінних. Нагадаємо, що `.` є посиланням на _поточну область видимості_. Отже, `.Values` вказує шаблону знайти обʼєкт `Values` у поточній області видимості. Синтаксис для `with` схожий на простий оператор `if`: ```none {{ with PIPELINE }} # обмежена область видимості {{ end }} ``` Області видимості можуть змінюватися. `with` дозволяє вам встановити поточну область видимості (`.`) на певний обʼєкт. Наприклад, ми працювали з `.Values.favorite`. Перепишемо наш ConfigMap, щоб змінити область видимості `.` на `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Зверніть увагу, що ми видалили умову `if` з попереднього прикладу, оскільки вона тепер непотрібна — блок після `with` виконується лише якщо значення `PIPELINE` не є порожнім. Тепер ми можемо звертатися до `.drink` і `.food` без додаткових уточнень. Це відбувається тому, що оператор `with` встановлює `.` на `.Values.favorite`. `.` скидається до попередньої області видимості після `{{ end }}`. Але є одне застереження! Усередині обмеженої області видимості ви не зможете отримати доступ до інших обʼєктів з батьківської області видимості за допомогою `.`. Наприклад, це не спрацює: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` Це викличе помилку, оскільки `Release.Name` не знаходиться в межах обмеженої області видимості для `.`. Однак, якщо ми поміняємо місцями останні два рядки, все працюватиме як очікувалося, тому що область видимості скидається після `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Або ми можемо використовувати `$` для доступу до обʼєкта `Release.Name` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` Після розгляду `range` ми перейдемо до змінних шаблону, які пропонують одне рішення для проблеми з областю видимості вище. ## Цикли за допомогою дії `range` {#looping-with-the-range-action} Багато мов програмування підтримують цикли за допомогою `for` циклів, `foreach` циклів або подібних функціональних механізмів. У мові шаблонів Helm, для перебору колекції використовується оператор `range`. Спочатку додамо список інгредієнтів для піци до нашого файлу `values.yaml`: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions ``` Тепер у нас є список (в шаблонах він називається `slice`) інгредієнтів для піци. Ми можемо змінити наш шаблон, щоб вивести цей список у наш ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Ми можемо використовувати `$` для доступу до списку `Values.pizzaToppings` з батьківської області видимості. `$` привʼязується до кореневої області видимості на початку виконання шаблону і не змінюється під час виконання шаблону. Ось таке рішення також спрацює: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Розглянемо детальніше список `toppings:`. Функція `range` буде "перебирати" список `pizzaToppings`. Але тепер відбувається щось цікаве. Так само як `with` встановлює область видимості для `.`, так і оператор `range` встановлює область видимості. Кожного разу під час циклу `.` встановлюється на поточний інгредієнт для піци. Тобто, під час першої ітерації `.` буде дорівнювати `mushrooms`. Під час другої ітерації він буде дорівнювати `cheese`, і так далі. Ми можемо безпосередньо передавати значення `.` в конвеєр, тому коли ми використовуємо `{{ . | title | quote }}`, воно передається в `title` (функцію для перетворення на заголовні літери) і потім в `quote`. Якщо ми запустимо цей шаблон, результат буде: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" ``` У цьому прикладі ми зробили дещо хитре. Лінія `toppings: |-` оголошує багаторядковий рядок. Отже, наш список інгредієнтів для піци насправді не є YAML списком. Це великий рядок. Чому ми так робимо? Тому що дані в ConfigMaps `data` складаються з пар ключ/значення, де і ключ, і значення є простими рядками. Щоб зрозуміти, чому це так, ознайомтеся з [документацією Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). Для нас цей нюанс не так важливий. > Маркер `|-` в YAML приймає багаторядковий рядок. Це може бути корисною технікою для вбудовування великих блоків даних у ваші маніфести, як показано тут. Іноді корисно швидко створити список у шаблоні, а потім перебирати цей список. Шаблони Helm мають функцію для спрощення цього завдання: `tuple`. У компʼютерних науках кортеж (tuple) — це список фіксованого розміру, але з довільними типами даних. Це приблизно передає те, як використовується `tuple`. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` Вищезазначене створить: ```yaml sizes: |- - small - medium - large ``` Окрім списків і кортежів, `range` можна використовувати для перебору колекцій, які мають ключ і значення (як `map` або `dict`). Ми розглянемо, як це зробити в наступному розділі, коли введемо змінні шаблону. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Додаток: Типи даних Go та шаблони" description: Короткий огляд змінних у шаблонах. sidebar_position: 16 --- Мова шаблонів Helm реалізована мовою програмування Go, яка має сувору типізацію. З цієї причини змінні в шаблонах мають _типи_. Здебільшого змінні будуть представлені одним із наступних типів: - `string`: Рядок тексту - `bool`: значення `true` або `false` - `int`: Ціле число (існують також 8, 16, 32 і 64-бітні знакові та беззнакові варіанти) - `float64`: 64-бітне число з плаваючою комою (також є 8, 16 та 32-бітні різновиди) - `byte slice` (`[]byte`): Масив байтів, часто використовується для зберігання (можливо) бінарних даних - `struct`: Обʼєкт із властивостями та методами - `slice`: Список з індексами одного з попередніх типів - `map`: Map з ключами-рядками (`map[string]interface{}`), де значенням є один із попередніх типів Існує багато інших типів у Go, і іноді вам доведеться конвертувати між ними в шаблонах. Найпростіший спосіб налагодження типу обʼєкта — передати його через `printf "%T"` у шаблоні, що виведе тип. Також корисно ознайомитись із функціями `typeOf` та `kindOf`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Виправлення помилок у шаблонах description: Виправлення проблем з розгортанням чартів. sidebar_position: 13 --- Виправлення помилок у шаблонах може бути складним, оскільки відрендерені шаблони надсилаються на сервер API Kubernetes, який може відхиляти YAML-файли з інших причин, окрім форматування. Є кілька команд, які можуть допомогти в процесі налагодження: - `helm lint` є вашим основним інструментом для перевірки того, чи ваш чарт відповідає найкращим практикам. - `helm template --debug` дозволяє тестувати рендеринг шаблонів чарту локально. - `helm install --dry-run --debug` також рендерить ваш чарт локально без його встановлення, але також перевіряє, чи конфліктують ресурси вже з запущеними на кластері. Налаштування `--dry-run=server` додатково виконає будь-які `lookup` у вашому чарті на сервері. - `helm get manifest`: Це хороший спосіб побачити, які шаблони встановлені на сервері. Коли ваш YAML не проходить перевірку, але ви хочете побачити, що було згенеровано, простий спосіб отримати YAML — закоментувати проблемний розділ у шаблоні, а потім повторно запустити `helm install --dry-run --debug`: ```yaml apiVersion: v2 # деяка: проблемна секція # {{ .Values.foo | quote }} ``` Вищенаведене буде відрендерене і повернуто з коментарями, що дозволяє швидко переглядати згенерований контент без помилок парсингу YAML: ```yaml apiVersion: v2 # деяка: проблемна секція # "bar" ``` Це забезпечує швидкий спосіб перегляду згенерованого контенту без блокування помилками парсингу YAML. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Список функцій шаблонів description: Список функцій шаблонів, доступних у Helm sidebar_position: 6 --- Helm містить багато функцій шаблонів, якими ви можете скористатися у шаблонах. Вони перераховані тут і розбиті на наступні категорії: * [Криптографія та безпека](#cryptographic-and-security-functions) * [Дата](#date-functions) * [Словники](#dictionaries-and-dict-functions) * [Кодування](#encoding-functions) * [Шлях до файлу](#file-path-functions) * [Kubernetes та чарти](#kubernetes-and-chart-functions) * [Логіка та керування потоком](#logic-and-flow-control-functions) * [Списки](#lists-and-list-functions) * [Математичні функції](#math-functions) * [Математичні обчислення з комою](#float-math-functions) * [Мережа](#network-functions) * [Аналіз](#reflection-functions) * [Регулярні вирази](#regular-expressions) * [Семантичні версії](#semantic-version-functions) * [Рядки](#string-functions) * [Перетворення типів](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## Логічні функції та функції керування потоком {#logic-and-flow-control-functions} Helm містить численні логічні та контрольні функції, включаючи [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), і [required](#required). ### and Повертає логічне AND для двох або більше аргументів (перший пустий аргумент або останній аргумент). ```none and .Arg1 .Arg2 ``` ### or Повертає логічне OR для двох або більше аргументів (перший непустий аргумент або останній аргумент). ```none or .Arg1 .Arg2 ``` ### not Повертає логічне заперечення свого аргументу. ```none not .Arg ``` ### eq Повертає логічну рівність аргументів (наприклад, Arg1 == Arg2). ```none eq .Arg1 .Arg2 ``` ### ne Повертає логічну нерівність аргументів (наприклад, Arg1 != Arg2) ```none ne .Arg1 .Arg2 ``` ### lt Повертає логічне `true`, якщо перший аргумент менший за другий. В іншому випадку повертає `false` (наприклад, Arg1 < Arg2). ```none lt .Arg1 .Arg2 ``` ### le Повертає логічне `true`, якщо перший аргумент менший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 <= Arg2). ```none le .Arg1 .Arg2 ``` ### gt Повертає логічне `true`, якщо перший аргумент більший за другий. В іншому випадку повертає `false` (наприклад, Arg1 > Arg2). ```none gt .Arg1 .Arg2 ``` ### ge Повертає логічне `true`, якщо перший аргумент більший або дорівнює другому. В іншому випадку повертає `false` (наприклад, Arg1 >= Arg2). ```none ge .Arg1 .Arg2 ``` ### default Щоб встановити просте стандартне значення, використовуйте `default`: ```none default "foo" .Bar ``` У наведеному прикладі, якщо `.Bar` має непусте значення, воно буде використане. Якщо ж воно пусте, повернеться `foo`. Визначення "пустого" залежить від типу: * Числові: 0 * Рядок: "" * Списки: `[]` * Словники: `{}` * Логічний: `false` * І завжди `nil` (або null) Для структур немає визначення пустого значення, тому структура ніколи не поверне стандартного значення. ### required Вкажіть значення, які повинні бути встановлені, за допомогою `required`: ```none required "A valid foo is required!" .Bar ``` Якщо `.Bar` є пустим або не визначеним (див. [default](#default) щодо того, як це оцінюється), шаблон не буде згенерований і поверне надане повідомлення про помилку. ### empty Функція `empty` повертає `true`, якщо надане значення вважається пустим, і `false` в іншому випадку. Пусті значення перелічені в розділі `default`. ```none empty .Foo ``` Зверніть увагу, що в умовах шаблонів Go пустота розраховується автоматично. Таким чином, рідко потрібно використовувати `if not empty .Foo`. Замість цього просто використовуйте `if .Foo`. ### fail Безумовно повертає пустий `string` та `error` з зазначеним текстом. Це корисно в ситуаціях, коли інші умови визначили, що рендеринг шаблону повинен зазнати невдачі. ```none fail "Please accept the end user license agreement" ``` ### coalesce Функція `coalesce` приймає список значень і повертає перше непусте. ```none coalesce 0 1 2 ``` У наведеному випадку повертає `1`. Ця функція корисна для перевірки кількох змінних або значень: ```none coalesce .name .parent.name "Matt" ``` Цей приклад спочатку перевірить, чи є `.name` непустим. Якщо це так, буде повернене це значення. Якщо ж воно _пусте_, `coalesce` перевірить `.parent.name` на пустоту. Нарешті, якщо обидва `.name` і `.parent.name` пусті, буде повернене `Matt`. ### ternary Функція `ternary` приймає два значення і тестове значення. Якщо тестове значення є `true`, повернеться перше значення. Якщо тестове значення є пустим, повернеться друге значення. Це подібно до тернарного оператора в C та інших мовах програмування. #### тестове значення true {#true-test-value} ```none ternary "foo" "bar" true ``` або ```none true | ternary "foo" "bar" ``` У цьому випадку повертається `"foo"`. #### тестове значення false {#false-test-value} ```none ternary "foo" "bar" false ``` або ```none false | ternary "foo" "bar" ``` У цьому випадку повертається `"bar"`. ## Функції для роботи з рядками {#string-functions} Helm включає такі функції для рядків: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), і [wrapWith](#wrapwith). ### print Повертає рядок, що є комбінацією його частин. ```none print "Matt has " .Dogs " dogs" ``` Типи, які не є рядками, перетворюються на рядки, якщо це можливо. Зверніть увагу, що коли два аргументи поруч один з одним не є рядками, між ними додається пробіл. ### println Працює так само як [print](#print), але додає новий рядок наприкінці. ### printf Повертає рядок на основі відформатованого рядка та аргументів, що передаються у до нього. ```none printf "%s has %d dogs." .Name .NumberDogs ``` Заповнювач, який слід використовувати, залежить від типу переданого аргументу. Серед них: Загального призначення: * `%v` значення в стандартному форматі * при друку словників, прапорець `+` (%+v) додає імена полів * `%%` літеральний знак відсотка; не використовує значення Логічний: * `%t` слово true або false Цілі числа: * `%b` двійкові, основа 2 * `%c` символ, що відповідає точці Unicode * `%d` десяткові, основа 10 * `%o` вісімкові, основа 8 * `%O` основа 8 з префіксом 0o * `%q` вісімкові, однорядковий літерал символу, безпечно екранований * `%x` шістнадцяткові, основа 16, з малими літерами для a-f * `%X` шістнадцяткові, основа 16, з великими літерами для A-F * `%U` Unicode формат: U+1234; те ж саме, що "U+%04X" Числа з плаваючою комою та складові частини: * `%b` десятковий формат без наукової нотації з показником ступеня двійки, наприклад -123456p-78 * `%e` наукова нотація, наприклад -1.234456e+78 * `%E` наукова нотація, наприклад -1.234456E+78 * `%f` десятковий формат без експоненти, наприклад 123.456 * `%F` синонім для %f * `%g` %e для великих експонент, %f в іншому випадку * `%G` %E для великих експонент, %F в іншому випадку * `%x` шістнадцяткова нотація (з десятковим показником ступеня), наприклад -0x1.23abcp+20 * `%X` шістнадцяткова нотація у верхньому регістрі, наприклад -0X1.23ABCP+20 Рядок та зріз байтів (обробляються однаково з цими діями): * `%s` необроблені байти рядка або зрізу * `%q` рядок в подвійних лапках, безпечно екранований * `%x` основа 16, малий регістр, два символи на байт * `%X` основа 16, великий регістр, два символи на байт Зріз: * `%p` адреса 0-го елемента у шістнадцятковій нотації, з передуючим 0x ### trim Функція `trim` видаляє пробіли з обох сторін рядка: ```none trim " hello " ``` У результаті отримаємо `hello`. ### trimAll Видаляє зазначені символи з початку та кінця рядка: ```none trimAll "$" "$5.00" ``` У результаті отримаємо `5.00` (як рядок). ### trimPrefix Видаляє лише префікс з рядка: ```none trimPrefix "-" "-hello" ``` У результаті отримаємо `hello`. ### trimSuffix Видаляє лише суфікс з рядка: ```none trimSuffix "-" "hello-" ``` У результаті отримаємо `hello`. ### lower Перетворює весь рядок у нижній регістр: ```none lower "HELLO" ``` У результаті отримаємо `hello`. ### upper Перетворює весь рядок у верхній регістр: ```none upper "hello" ``` У результаті отримаємо `HELLO`. ### title Перетворює рядок у титульний регістр: ```none title "hello world" ``` У результаті отримаємо `Hello World`. ### untitle Видаляє титульне оформлення. `untitle "Hello World"` поверне `hello world`. ### repeat Повторює рядок кілька разів: ```none repeat 3 "hello" ``` У результаті отримаємо `hellohellohello`. ### substr Отримує підрядок з рядка. Параметри: * start (int) * end (int) * рядок (string) ```none substr 0 5 "hello world" ``` У результаті отримаємо `hello`. ### nospace Видаляє всі пробіли з рядка: ```none nospace "hello w o r l d" ``` У результаті отримаємо `helloworld`. ### trunc Обрізає рядок: ```none trunc 5 "hello world" ``` У результаті отримаємо `hello`. ```none trunc -5 "hello world" ``` У результаті отримаємо `world`. ### abbrev Обрізає рядок додаючи три крапки (`...`): Параметри: * максимальна довжина * рядок ```none abbrev 5 "hello world" ``` У результаті отримаємо `he...`, оскільки ширина трьох крапок враховується до максимальної довжини. ### abbrevboth Обрізає обидві сторони: ```none abbrevboth 5 10 "1234 5678 9123" ``` У результаті отримаємо `...5678...`. Параметри: * зсув ліворуч * максимальна довжина * рядок ### initials Для кількох слів бере першу літеру кожного слова та обʼєднує їх: ```none initials "First Try" ``` У результаті отримаємо `FT`. ### randAlphaNum, randAlpha, randNumeric та randAscii {#randalphanum-randalpha-randnumeric-and-randascii} Ці чотири функції генерують криптографічно безпечні (використовує ```crypto/rand```) випадкові рядки, але з різними базовими наборами символів: * `randAlphaNum` використовує `0-9a-zA-Z` * `randAlpha` використовує `a-zA-Z` * `randNumeric` використовує `0-9` * `randAscii` використовує всі друковані ASCII символи Кожна з них приймає один параметр: цілу довжину рядка. ```none randNumeric 3 ``` У результаті отримаємо випадковий рядок з трьох цифр. ### wrap Виконує перенесення тексту на вказаній кількості стовпців: ```none wrap 80 $someText ``` У результаті для рядка `$someText` буде виконано перенесення на 80-му стовпці. ### wrapWith `wrapWith` працює так само як і `wrap`, але дозволяє вказати рядок для перенесення. (`wrap` використовує `\n`) ```none wrapWith 5 "\t" "Hello World" ``` У результаті отримаємо `Hello World` (де пробіл є символом ASCII табуляції). ### contains Перевіряє, чи один рядок міститься всередині іншого: ```none contains "cat" "catch" ``` У результаті отримаємо `true`, оскільки `catch` містить `cat`. ### hasPrefix і hasSuffix {#hasprefix-and-hassuffix} Функції `hasPrefix` і `hasSuffix` перевіряють, чи має рядок заданий префікс або суфікс: ```none hasPrefix "cat" "catch" ``` У результаті отримаємо `true`, оскільки `catch` має префікс `cat`. ### quote і squote {#quote-and-squote} Ці функції обгортають рядок у подвійні лапки (`quote`) або одинарні лапки (`squote`). ### cat Функція `cat` обʼєднує кілька рядків в один, розділяючи їх пробілами: ```none cat "hello" "beautiful" "world" ``` У результаті отримаємо `hello beautiful world`. ### indent Функція `indent` додає відступ у кожному рядку вказаного тексту на зазначену кількість символів. Це корисно для вирівнювання багаторядкових текстів: ```none indent 4 $lots_of_text ``` У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу. ### nindent Функція `nindent` є такою ж, як і `indent`, але додає новий рядок на початку рядка. ```none nindent 4 $lots_of_text ``` У результаті кожен рядок тексту буде мати відступ на 4 символи пробілу, а також буде додано новий рядок на початку. ### replace Виконує просту заміну рядків. Вона приймає три аргументи: * рядок для заміни * рядок, на який замінювати * вихідний рядок ```none "I Am Henry VIII" | replace " " "-" ``` У результаті отримаємо `I-Am-Henry-VIII`. ### plural Форма множини. ```none len $fish | plural "one anchovy" "many anchovies" ``` У наведеному випадку, якщо довжина рядка дорівнює 1, буде надруковано перший аргумент (`one anchovy`). В іншому випадку буде надруковано другий аргумент (`many anchovies`). Аргументи: * однина * множина * довжина (ціле число) ПРИМІТКА: Helm наразі не підтримує мови зі складнішими правилами множини. І `0` вважається множиною, оскільки англійська мова ставиться до нього саме так (`zero anchovies`). ### snakecase Перетворює рядок з camelCase в snake_case. ```none snakecase "FirstName" ``` У результаті отримаємо `first_name`. ### camelcase Перетворює рядок з snake_case в CamelCase. ```none camelcase "http_server" ``` У результаті отримаємо `HttpServer`. ### kebabcase Перетворює рядок з camelCase в kebab-case. ```none kebabcase "FirstName" ``` У результаті отримаємо `first-name`. ### swapcase Змінює регістр рядка за допомогою алгоритму на основі слів. Алгоритм перетворення: * Символи у верхньому регістрі перетворюються у нижній регістр * Символи в титульному регістрі перетворюються у нижній регістр * Символи у нижньому регістрі після пробілу або на початку перетворюються у титульний регістр * Інші символи у нижньому регістрі перетворюються у верхній регістр * Пробіли визначаються як unicode.IsSpace(char) ```none swapcase "This Is A.Test" ``` У результаті отримаємо `tHIS iS a.tEST`. ### shuffle Перемішує рядок. ```none shuffle "hello" ``` У результаті отримаємо випадковий порядок літер у `hello`, можливо, `oelhl`. ## Функції перетворення типів {#type-conversion-functions} Helm пропонує такі функції для перетворення типів: * `atoi`: Перетворює рядок на ціле число. * `float64`: Перетворює на `float64`. * `int`: Перетворює на `int` відповідно до ширини системи. * `int64`: Перетворює на `int64`. * `toDecimal`: Перетворює unix octal на `int64`. * `toString`: Перетворює на рядок. * `toStrings`: Перетворює список, зріз або масив на список рядків. * `toJson` (`mustToJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON. * `toPrettyJson` (`mustToPrettyJson`): Перетворює список, зріз, масив, словник або обʼєкт на форматований JSON. * `toRawJson` (`mustToRawJson`): Перетворює список, зріз, масив, словник або обʼєкт на JSON з неекранованими HTML символами. * `fromYaml`: Перетворює YAML рядок на обʼєкт. * `fromJson`: Перетворює JSON рядок на обʼєкт. * `fromJsonArray`: Перетворює JSON масив на список. * `toYaml`: Перетворює список, зріз, масив, словник або обʼєкт на відформатований YAML. * `toToml`: Перетворює список, зріз, масив, словник або обʼєкт на TOML. * `fromYamlArray`: Перетворює YAML масив на список. ### toStrings Перетворює колекцію схожу на список на зріз рядків. ```none list 1 2 3 | toStrings ``` Перетворює `1` на `"1"`, `2` на `"2"` і так далі, а потім повертає їх як список. ### toDecimal Перетворює unix octal на десятковий формат. ```none "0777" | toDecimal ``` Перетворює `0777` на `511` і повертає значення як int64. ### toJson, mustToJson Функція `toJson` кодує елемент у JSON рядок. Якщо елемент не може бути перетворений на JSON, функція поверне порожній рядок. `mustToJson` поверне помилку, якщо елемент не може бути закодований в JSON. ```none toJson .Item ``` Поверне JSON рядкове представлення `.Item`. ### toPrettyJson, mustToPrettyJson Функція `toPrettyJson` кодує елемент у форматований (з відступами) JSON рядок. ```none toPrettyJson .Item ``` Поверне відформатоване JSON рядкове представлення `.Item`. ### toRawJson, mustToRawJson Функція `toRawJson` кодує елемент у JSON рядок з неекранованими HTML символами. ```none toRawJson .Item ``` Поверне неекрановане JSON рядкове представлення `.Item`. ### fromYaml Функція `fromYaml` приймає YAML рядок і повертає обʼєкт, який можна використовувати в шаблонах. Файл `yamls/person.yaml`: ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson Функція `fromJson` приймає JSON рядок і повертає обʼєкт, який можна використовувати в шаблонах. Файл `jsons/person.json`: ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray Функція `fromJsonArray` приймає JSON масив і повертає список, який можна використовувати в шаблонах. Файл `jsons/people.json`: ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### fromYamlArray Функція `fromYamlArray` приймає YAML масив і повертає список, який можна використовувати в шаблонах. Файл `yamls/people.yml`: ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Регулярні Вирази {#regular-expressions} Helm включає такі функції для роботи з регулярними виразами: [regexMatch](#regexmatch-mustregexmatch), [regexFindAll](#regexfindall-mustregexfindall), [regexFind](#regexfind-mustregexfind), [regexReplaceAll](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Повертає `true`, якщо вхідний рядок містить хоча б один збіг для регулярного виразу. ```yaml regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` Поверне `true`. `regexMatch` викликає паніку у разі проблеми, а `mustRegexMatch` поверне помилку у рушії шаблонів у разі проблеми. ### regexFindAll, mustRegexFindAll Повертає зріз усіх збігів регулярного виразу у вхідному рядку. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги. ```yaml regexFindAll "[2,4,6,8]" "123456789" -1 ``` Поверне `[2 4 6 8]`. `regexFindAll` викликає паніку у разі проблеми, а `mustRegexFindAll` поверне помилку у рушії шаблонів у разі проблеми. ### regexFind, mustRegexFind Повертає перший (зліва) збіг регулярного виразу у вхідному рядку. ```yaml regexFind "[a-zA-Z][1-9]" "abcd1234" ``` Поверне `d1`. `regexFind` викликає паніку у разі проблеми, а `mustRegexFind` поверне помилку у рушії шаблонів у разі проблеми. ### regexReplaceAll, mustRegexReplaceAll Повертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. У рядку заміни знаки `$` інтерпретуються як в Expand, тому, наприклад, `$1` представляє текст першого збігу. ```yaml regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` Поверне `-W-xxW-`. `regexReplaceAll` викликає паніку у разі проблеми, а `mustRegexReplaceAll` поверне помилку у рушії шаблонів у разі проблеми. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Повертає копію вхідного рядка, замінюючи збіг регулярного виразу на рядок заміни `replacement`. Рядок заміни підставляється без використання Expand. ```yaml regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` Поверне `-${1}-${1}-`. `regexReplaceAllLiteral` викликає паніку у разі проблеми, а `mustRegexReplaceAllLiteral` поверне помилку у рушії шаблонів у разі проблеми. ### regexSplit, mustRegexSplit Розбиває вхідний рядок на підрядки, розділені виразом, і повертає зріз підрядків між збігами цього виразу. Останній параметр `n` визначає кількість підрядків для повернення, де `-1` означає повернути всі збіги. ```yaml regexSplit "z+" "pizza" -1 ``` Поверне `[pi a]`. `regexSplit` викликає паніку у разі проблеми, а `mustRegexSplit` поверне помилку у рушії шаблонів у разі проблеми. ## Функції криптографії та безпеки {#cryptographic-and-security-functions} Helm надає декілька розширених криптографічних функцій, серед яких: [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [sha1sum](#sha1sum), та [sha256sum](#sha256sum). ### sha1sum Функція `sha1sum` отримує рядок і обчислює його SHA1-дайджест. ```yaml sha1sum "Hello world!" ``` ### sha256sum Функція `sha256sum` отримує рядок і обчислює його SHA256-дайджест. ```yaml sha256sum "Hello world!" ``` Це обчислює SHA 256 контрольну суму у форматі "ASCII armored", який є безпечним для друку. ### adler32sum Функція `adler32sum` отримує рядок і обчислює його контрольну суму Adler-32. ```yaml adler32sum "Hello world!" ``` ### htpasswd Функція `htpasswd` приймає `username` і `password` та генерує `bcrypt` хеш паролю. Результат може бути використаний для базової автентифікації на [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ```yaml htpasswd "myUser" "myPassword" ``` Зверніть увагу, що небезпечно зберігати пароль безпосередньо в шаблоні. ### derivePassword Функція `derivePassword` може бути використана для виведення певного пароля на основі деяких спільних "основних" обмежень пароля. Алгоритм для цього добре [описаний](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ```yaml derivePassword 1 "long" "password" "user" "example.com" ``` Зверніть увагу, що небезпечно зберігати частини безпосередньо в шаблоні. ### genPrivateKey Функція `genPrivateKey` генерує новий приватний ключ, закодований у PEM-блок. Вона приймає одне з наступних значень для свого першого параметра: * `ecdsa`: Генерує ключ еліптичної кривої DSA (P256) * `dsa`: Генерує DSA ключ (L2048N256) * `rsa`: Генерує RSA 4096 ключ ### buildCustomCert Функція `buildCustomCert` дозволяє налаштувати сертифікат. Вона приймає наступні строкові параметри: * Сертифікат у форматі PEM, закодований у base64 * Приватний ключ у форматі PEM, закодований у base64 Функція повертає обʼєкт сертифіката з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```yaml $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. ### genCA Функція `genCA` генерує новий самопідписний сертифікат x509 для центру сертифікацї. Вона приймає наступні параметри: * Загальне імʼя субʼєкта (cn) * Термін дії сертифіката у днях Функція повертає обʼєкт з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```yaml $ca := genCA "foo-ca" 365 ``` Зверніть увагу, що повернутий обʼєкт може бути переданий до функції `genSignedCert` для підписання сертифіката за допомогою цього CA. ### genSelfSignedCert Функція `genSelfSignedCert` генерує новий самопідписаний сертифікат x509. Вона приймає наступні параметри: * Загальне імʼя субʼєкта (cn) * Необовʼязковий список IP-адрес; може бути nil * Необовʼязковий список альтернативних DNS-імен; може бути nil * Термін дії сертифіката у днях Функція повертає обʼєкт з наступними атрибутами: * `Cert`: Сертифікат у форматі PEM * `Key`: Приватний ключ у форматі PEM Приклад: ```yaml $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert Функція `genSignedCert` генерує новий сертифікат x509, підписаний зазначеним CA. Вона приймає наступні параметри: * Спільне імʼя субʼєкта (cn) * Необовʼязковий список IP-адрес; може бути nil * Необовʼязковий список альтернативних DNS-імен; може бути nil * Термін дії сертифіката у днях * CA (див. `genCA`) Приклад: ```yaml $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES Функція `encryptAES` шифрує текст за допомогою AES-256 CBC і повертає рядок, закодований у base64. ```yaml encryptAES "secretkey" "plaintext" ``` ### decryptAES Функція `decryptAES` отримує рядок у форматі base64, закодований за допомогою алгоритму AES-256 CBC, і повертає розкодований текст. ```yaml "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Функції дати {#date-functions} Helm включає наступні функції дати, які ви можете використовувати в шаблонах: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate) та [unixEpoch](#unixepoch). ### now Поточна дата/час. Використовуйте це разом з іншими функціями дати. ### ago Функція `ago` повертає тривалість від часу. Зараз у секундах. ```none ago .CreatedAt ``` повертає у форматі `time.Duration` String() ```none 2h34m7s ``` ### date Функція `date` форматує дату. Формат дати до РІК-МІСЯЦЬ-ДЕНЬ: ```none now | date "2006-01-02" ``` Форматування дати в Go [дещо відрізняється](https://pauladamsmith.com/blog/2011/05/go_time.html). Коротко, візьміть цю базову дату: ```none Mon Jan 2 15:04:05 MST 2006 ``` Запишіть її у потрібному форматі. Вище, `2006-01-02` — це та ж дата, але в потрібному форматі. ### dateInZone Те ж саме, що і `date`, але з часовою зоною. ```none dateInZone "2006-01-02" (now) "UTC" ``` ### duration Форматує задану кількість секунд як `time.Duration`. Це повертає 1m35s ```none duration "95" ``` ### durationRound Округлює задану тривалість до найзначнішої одиниці. Рядки та `time.Duration` аналізуються як тривалість, тоді як `time.Time` обчислюється як тривалість з моменту. Це повертає 2h ```none durationRound "2h10m5s" ``` Це повертає 3mo ```none durationRound "2400h10m5s" ``` ### unixEpoch Повертає кількість секунд з unix-епохи для `time.Time`. ```none now | unixEpoch ``` ### dateModify, mustDateModify Функція `dateModify` приймає модифікацію та дату і повертає часову мітку. Відніміть годину і тридцять хвилин від поточного часу: ```none now | dateModify "-1.5h" ``` Якщо формат модифікації неправильний, `dateModify` поверне дату немодифікованою. `mustDateModify` поверне помилку в іншому випадку. ### htmlDate Функція `htmlDate` форматує дату для вставки в поле введення дати в HTML. ```none now | htmlDate ``` ### htmlDateInZone Те ж саме, що і htmlDate, але з часовою зоною. ```none htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate Функція `toDate` перетворює рядок у дату. Перший аргумент — це макет дати, а другий — рядок дати. Якщо рядок не можна перетворити, він поверне нульове значення. `mustToDate` поверне помилку в разі, якщо рядок не можна перетворити. Це корисно, коли ви хочете перетворити дату-рядок в інший формат (використовуючи конвеєр). Нижче наведений приклад перетворює "2017-12-31" на "31/12/2017". ```none toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Словники та функції словників {#dictionaries-and-dict-functions} Helm надає тип зберігання ключ/значення, який називається `dict` (скорочено від "dictionary" ["словник"], як у Python). `dict` є _невпорядкованим_ типом. Ключ у словнику **має бути рядком**. Однак значення може бути будь-якого типу, навіть іншим `dict` або `list`. На відміну від `list`, `dict` не є незмінним. Функції `set` та `unset` змінюють вміст словника. Helm надає такі функції для роботи зі словниками: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset) та [values](#values). ### dict Створення словників здійснюється шляхом виклику функції `dict` і передачі їй списку пар. Наступний приклад створює словник з трьома елементами: ```none $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get За наявності map і ключа отримає значення з map. ```none get $myDict "name1" ``` Наведений вище приклад поверне `"value1"`. Зверніть увагу, що якщо ключ не знайдено, ця операція просто поверне `""`. Помилка не буде згенерована. ### set Використовуйте `set`, щоб додати нову пару ключ/значення до словника. ```none $_ := set $myDict "name4" "value4" ``` Зверніть увагу, що `set` _повертає словник_ (вимога функцій шаблону Go), тому вам може знадобитися захопити значення, як це зроблено вище за допомогою присвоєння `$_`. ### unset За наявності map і ключа видалить ключ з map. ```none $_ := unset $myDict "name4" ``` Як і у випадку з `set`, це повертає словник. Зверніть увагу, що якщо ключ не знайдено, ця операція просто повернеться. Помилка не буде згенерована. ### hasKey Функція `hasKey` повертає `true`, якщо даний словник містить даний ключ. ```none hasKey $myDict "name1" ``` Якщо ключ не знайдено, це повертає `false`. ### pluck Функція `pluck` дозволяє вказати один ключ і кілька map, і отримати список усіх знайдених збігів: ```none pluck "name1" $myDict $myOtherDict ``` Наведений вище приклад поверне `list`, що містить усі знайдені значення (`[value1 otherValue1]`). Якщо даний ключ _не знайдено_ в map, цей map не буде мати елемента у списку (і довжина повернутого списку буде меншою, ніж кількість словників у виклику `pluck`). Якщо ключ _знайдено_, але значення є порожнім, це значення буде вставлено. Поширеною ідіомою у шаблонах Helm є використання `pluck... | first`, щоб отримати перший відповідний ключ із колекції словників. ### dig Функція `dig` проходить через вкладені набори словників, вибираючи ключі зі списку значень. Вона повертає стандартне значення, якщо будь-який з ключів не знайдено в асоційованому словнику. ```none dig "user" "role" "humanName" "guest" $dict ``` За наявності словника, структурованого таким чином: ```none { user: { role: { humanName: "curator" } } } ``` наведений вище приклад поверне `"curator"`. Якщо у словнику навіть не було поля `user`, результатом буде `"guest"`. `dig` може бути дуже корисним у випадках, коли ви хочете уникнути охоронних конструкцій, особливо тому, що `and` у пакеті шаблонів Go не є скороченим. Наприклад, `and a.maybeNil a.maybeNil.iNeedThis` завжди буде оцінювати `a.maybeNil.iNeedThis` і викличе паніку, якщо у `a` відсутнє поле `maybeNil`. `dig` приймає свій аргумент словника останнім, щоб підтримувати конвеєрну обробку. Наприклад: ```none merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Обʼєднує два або більше словників в один, надаючи перевагу словнику призначення: Наприклад: ```yaml dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом буде: ```yaml newdict: default: default overwrite: me key: true ``` ```none $newdict := merge $dest $source1 $source2 ``` Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, ```none deepCopy $source | merge $dest ``` `mustMerge` поверне помилку в разі невдалого обʼєднання. ### mergeOverwrite, mustMergeOverwrite {#mergeoverwrite-mustmergeoverwrite} Обʼєднує два або більше словників в один, надаючи перевагу з **права наліво**, ефективно перезаписуючи значення в словнику призначення: Наприклад: ```yaml dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` результатом буде: ```yaml newdict: default: default overwrite: overwritten key: false ``` ```none $newdict := mergeOverwrite $dest $source1 $source2 ``` Це операція глибокого обʼєднання, але не глибокого копіювання. Вкладені обʼєкти, що обʼєднуються, є однією і тією ж сутністю в обох словниках. Якщо ви хочете глибоке копіювання разом з обʼєднанням, то використовуйте функцію `deepCopy` разом з обʼєднанням. Наприклад, ```none deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` поверне помилку в разі невдалого обʼєднання. ### keys Функція `keys` повертає `list` усіх ключів одного або декількох типів `dict`. Оскільки словник є _невпорядкованим_, ключі не будуть у передбачуваному порядку. Їх можна відсортувати за допомогою `sortAlpha`. ```none keys $myDict | sortAlpha ``` При поданні кількох словників ключі будуть обʼєднані. Використовуйте функцію `uniq` разом із `sortAlpha`, щоб отримати унікальний, відсортований список ключів. ```none keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick Функція `pick` вибирає тільки зазначені ключі зі словника, створюючи новий `dict`. ```none $new := pick $myDict "name1" "name2" ``` Наведений вище приклад поверне `{name1: value1, name2: value2}`. ### omit Функція `omit` схожа на `pick`, за винятком того, що вона повертає новий `dict` з усіма ключами, які _не_ збігаються з даними ключами. ```none $new := omit $myDict "name1" "name3" ``` Наведений вище приклад поверне `{name2: value2}`. ### values Функція `values` схожа на `keys`, за винятком того, що вона повертає новий `list` з усіма значеннями вихідного `dict` (підтримується тільки один словник). ```none $vals := values $myDict ``` Наведений вище приклад поверне `list["value1", "value2", "value 3"]`. Зверніть увагу, що функція `values` не дає жодних гарантій щодо порядку результатів; якщо це важливо, використовуйте `sortAlpha`. ### deepCopy, mustDeepCopy Функції `deepCopy` і `mustDeepCopy` приймають значення і роблять глибоку копію цього значення. Це включає словники та інші структури. `deepCopy` викликає паніку, коли виникає проблема, тоді як `mustDeepCopy` повертає помилку системі шаблонів, коли виникає помилка. ```none dict "a" 1 "b" 2 | deepCopy ``` ### Примітка про внутрішню структуру Dict {#a-note-on-dict-internals} `dict` реалізовано в Go як `map[string]interface{}`. Розробники Go можуть передавати значення `map[string]interface{}` у контекст, щоб зробити їх доступними для шаблонів як `dict`. ## Функції кодування {#encoding-functions} Helm має такі функції для кодування та декодування: * `b64enc`/`b64dec`: Кодування або декодування з використанням Base64 * `b32enc`/`b32dec`: Кодування або декодування з використанням Base32 ## Списки та функції для роботи зі списками {#lists-and-list-functions} Helm надає простий тип `list`, який може містити довільні послідовні дані. Це схоже на масиви або зрізи, але списки призначені для використання як незмінні типи даних. Створення списку цілих чисел: ```none $myList := list 1 2 3 4 5 ``` Це створить список `[1 2 3 4 5]`. Helm надає наступні функції для роботи зі списками: [append (mustAppend)](#append-mustappend), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep) та [without (mustWithout)](#without-mustwithout). ### first, mustFirst Щоб отримати перший елемент списку, використовуйте `first`. `first $myList` повертає `1`. `first` викликає panic у разі проблеми, тоді як `mustFirst` повертає помилку в рушій шаблонів, якщо виникає проблема. ### rest, mustRest Щоб отримати залишок списку (все, окрім першого елемента), використовуйте `rest`. `rest $myList` повертає `[2 3 4 5]`. `rest` викликає panic у разі проблеми, тоді як `mustRest` повертає помилку в рушій шаблонів, якщо виникає проблема. ### last, mustLast Щоб отримати останній елемент списку, використовуйте `last`: `last $myList` повертає `5`. Це аналогічно до реверсування списку та виклику `first`. ### initial, mustInitial Ця функція доповнює `last`, повертаючи всі елементи, окрім останнього. `initial $myList` повертає `[1 2 3 4]`. `initial` викликає panic у разі проблеми, тоді як `mustInitial` повертає помилку в рушій шаблонів, якщо виникає проблема. ### append, mustAppend Додає новий елемент до існуючого списку, створюючи новий список. ```none $new = append $myList 6 ``` Це встановлює `$new` до `[1 2 3 4 5 6]`. `$myList` залишається незмінним. `append` викликає panic у разі проблеми, тоді як `mustAppend` повертає помилку в рушій шаблонів, якщо виникає проблема. ### prepend, mustPrepend Додає елемент на початок списку, створюючи новий список. ```none prepend $myList 0 ``` Це створить `[0 1 2 3 4 5]`. `$myList` залишається незмінним. `prepend` викликає panic у разі проблеми, тоді як `mustPrepend` повертає помилку в рушій шаблонів, якщо виникає проблема. ### concat Обʼєднує довільну кількість списків в один. ```none concat $myList (list 6 7) (list 8) ``` Це створить `[1 2 3 4 5 6 7 8]`. `$myList` залишається незмінним. ### reverse, mustReverse Створює новий список з елементами у зворотному порядку. ```none reverse $myList ``` Це генерує список `[5 4 3 2 1]`. `reverse` викликає panic у разі проблеми, тоді як `mustReverse` повертає помилку в рушій шаблонів, якщо виникає проблема. ### uniq, mustUniq Створює список без дублікатів. ```none list 1 1 1 2 | uniq ``` Це створить `[1 2]`. `uniq` викликає panic у разі проблеми, тоді як `mustUniq` повертає помилку в рушій шаблонів, якщо виникає проблема. ### without, mustWithout Функція `without` видаляє елементи зі списку. ```none without $myList 3 ``` Це створить `[1 2 4 5]`. `without` може приймати більше одного фільтра: ```none without $myList 1 3 5 ``` Це створить `[2 4]`. `without` викликає panic у разі проблеми, тоді як `mustWithout` повертає помилку в рушій шаблонів, якщо виникає проблема. ### has, mustHas Перевіряє, чи містить список певний елемент. ```none has 4 $myList ``` Це поверне `true`, а `has "hello" $myList` поверне `false`. `has` викликає panic у разі проблеми, тоді як `mustHas` повертає помилку в рушій шаблонів, якщо виникає проблема. ### compact, mustCompact Приймає список та видаляє елементи з пустими значеннями. ```none $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` поверне новий список з видаленим пустим (тобто "") елементом. `compact` викликає panic у разі проблеми, тоді як `mustCompact` повертає помилку в рушій шаблонів, якщо виникає проблема. ### index Щоб отримати n-й елемент списку, використовуйте `index list [n]`. Щоб отримати елемент у багатовимірних списках, використовуйте `index list [n] [m] ...`. * `index $myList 0` повертає `1`. Це те саме, що і `myList[0]`. * `index $myList 0 1` повертає той самий результат, що і `myList[0][1]`. ### slice, mustSlice Щоб отримати часткові елементи списку, використовуйте `slice list [n] [m]`. Це еквівалентно до `list[n:m]`. * `slice $myList` повертає `[1 2 3 4 5]`. Це те саме, що і `myList[:]`. * `slice $myList 3` повертає `[4 5]`. Це те саме, що і `myList[3:]`. * `slice $myList 1 3` повертає `[2 3]`. Це те саме, що і `myList[1:3]`. * `slice $myList 0 3` повертає `[1 2 3]`. Це те саме, що і `myList[:3]`. `slice` викликає panic у разі проблеми, тоді як `mustSlice` повертає помилку в рушій шаблонів, якщо виникає проблема. ### until Функція `until` створює діапазон цілих чисел. ```none until 5 ``` Це генерує список `[0, 1, 2, 3, 4]`. Це корисно для циклів з `range $i, $e := until 5`. ### untilStep Як і `until`, функція `untilStep` створює список рахуючих цілих чисел. Але вона дозволяє визначити початок, кінець та крок: ```none untilStep 3 6 2 ``` Це створить `[3 5]`, починаючи з 3 та додаючи 2, поки не буде досягнуто або перевищено 6. Це схоже на функцію `range` в Python. ### seq Працює як команда `seq` у bash. * 1 параметр (end) — генерує всі рахуючі цілі числа між 1 та `end` включно. * 2 параметри (start, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на 1. * 3 параметри (start, step, end) — генерує всі рахуючі цілі числа між `start` та `end` включно, збільшуючи або зменшуючи на `step`. ```none seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ## Математичні функції {#math-functions} Усі математичні функції працюють із значеннями типу `int64`, якщо не зазначено інше. Доступні наступні математичні функції: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round) та [sub](#sub). ### add Додавайте числа за допомогою `add`. Приймає два або більше аргументів. ```none add 1 2 3 ``` ### add1 Щоб збільшити на 1, використовуйте `add1`. ### sub Щоб відняти, використовуйте `sub`. ### div Виконуйте цілочисельне ділення за допомогою `div`. ### mod Залишок від ділення можна отримати за допомогою `mod`. ### mul Множте за допомогою `mul`. Приймає два або більше аргументів. ```none mul 1 2 3 ``` ### max Повертає найбільше із серії цілих чисел. Це поверне `3`: ```none max 1 2 3 ``` ### min Повертає найменше із серії цілих чисел. `min 1 2 3` поверне `1`. ### len Повертає довжину аргументу у вигляді цілого числа. ```none len .Arg ``` ## Математичні функції з плаваючою комою {#float-math-functions} Усі математичні функції працюють із значеннями типу `float64`. ### addf Додавайте числа за допомогою `addf`. Це поверне `5.5`: ```none addf 1.5 2 2 ``` ### add1f Щоб збільшити на 1, використовуйте `add1f`. ### subf Щоб відняти, використовуйте `subf`. Це еквівалентно `7.5 - 2 - 3` і поверне `2.5`: ```none subf 7.5 2 3 ``` ### divf Виконуйте ділення з плаваючою комою за допомогою `divf`. Це еквівалентно `10 / 2 / 4` і поверне `1.25`: ```none divf 10 2 4 ``` ### mulf Множте за допомогою `mulf`. Це поверне `6`: ```none mulf 1.5 2 2 ``` ### maxf Повертає найбільше із серії чисел з плаваючою комою: Це поверне `3`: ```none maxf 1 2.5 3 ``` ### minf Повертає найменше із серії чисел з плаваючою комою. Це поверне `1.5`: ```none minf 1.5 2 3 ``` ### floor Повертає найбільше число з плаваючою комою, яке менше або рівне вхідному значенню. `floor 123.9999` поверне `123.0`. ### ceil Повертає найбільше число з плаваючою комою, яке більше або рівне вхідному значенню. `ceil 123.001` поверне `124.0`. ### round Повертає число з плаваючою комою з округленим залишком до зазначеної кількості цифр після десяткової крапки. `round 123.555555 3` поверне `123.556`. ## Мережеві функції {#network-functions} Helm має одну мережеву функцію, `getHostByName`. Функція `getHostByName` приймає доменне імʼя і повертає IP-адресу. `getHostByName "www.google.com"` поверне відповідну IP-адресу для `www.google.com`. ## Функції роботи з шляхами до файлів {#file-path-functions} Хоча функції шаблонів Helm не надають доступ до файлової системи, вони забезпечують функції для роботи з рядками, які відповідають конвенціям шляхів до файлів. До них відносяться [base](#base), [clean](#clean), [dir](#dir), [ext](#ext) та [isAbs](#isabs). ### base Повертає останній елемент шляху. ```none base "foo/bar/baz" ``` Вищезазначене поверне "baz". ### dir Повертає теку, видаляючи останню частину шляху. Отже, `dir "foo/bar/baz"` повертає `foo/bar`. ### clean Очищує шлях. ```none clean "foo/bar/../baz" ``` Вищезазначене знаходить `..` і повертає `foo/baz`. ### ext Повертає розширення файлу. ```none ext "foo.bar" ``` Вищезазначене поверне `.bar`. ### isAbs Щоб перевірити, чи є шлях до файлу абсолютним, використовуйте `isAbs`. ## Функції аналізу {#reflection-functions} Helm надає базові інструменти аналізу. Це допомагає розробникам шаблонів зрозуміти основну інформацію про типи Go для конкретного значення. Helm написано на Go і він має строгий типізований підхід. Система типів застосовується всередині шаблонів. Go має кілька примітивів _видів (kind)_, таких як `string`, `slice`, `int64` і `bool`. Go має відкриту систему _типів_, яка дозволяє розробникам створювати власні типи. Helm надає набір функцій для кожного з них через [функції kind](#kind-functions) і [функції type](#type-functions). Також надана функція [deepEqual](#deepequal) для порівняння значень. ### Функції kind {#kind-functions} Є дві функції видів: `kindOf` повертає вид обʼєкта. ```none kindOf "hello" ``` Вищезазначене поверне `string`. Для простих тестів (наприклад, у блоці `if`), функція `kindIs` дозволяє перевірити, що значення має певний вид: ```none kindIs "int" 123 ``` Вищезазначене поверне `true`. ### Функції type {#type-functions} Типи трохи складніше обробляти, тому є три різні функції: * `typeOf` повертає основний тип значення: `typeOf $foo` * `typeIs` подібна до `kindIs`, але для типів: `typeIs "*io.Buffer" $myVal` * `typeIsLike` працює як `typeIs`, але також розіменовує покажчики **Примітка:** Жодна з цих функцій не може перевірити, чи реалізує щось певний інтерфейс, оскільки це вимагало б компіляції інтерфейсу заздалегідь. ### deepEqual `deepEqual` повертає `true`, якщо два значення є ["глибоко рівними"](https://golang.org/pkg/reflect/#DeepEqual). Працює і для типів непримітивів (в порівнянні з вбудованим `eq`). ```none deepEqual (list 1 2 3) (list 1 2 3) ``` Вищезазначене поверне `true`. ## Функції семантичного версіонування {#semantic-version-functions} Деякі схеми версій легко розпізнати та порівнювати. Helm надає функції для роботи з версіями [SemVer 2](http://semver.org). До них відносяться [semver](#semver) і [semverCompare](#semvercompare). Нижче ви також знайдете деталі про використання діапазонів для порівнянь. ### semver Функція `semver` розбирає рядок у семантичну версію: ```none $version := semver "1.2.3-alpha.1+123" ``` _Якщо синтаксичний аналізатор не спрацює, виконання шаблону буде зупинено з помилкою._ На цьому етапі `$version` є покажчиком на обʼєкт `Version` з наступними властивостями: * `$version.Major`: Основний номер (`1` вище) * `$version.Minor`: Мінорний номер (`2` вище) * `$version.Patch`: Номер патчу (`3` вище) * `$version.Prerelease`: Пре-реліз (`alpha.1` вище) * `$version.Metadata`: Метадані збірки (`123` вище) * `$version.Original`: Оригінальна версія у вигляді рядка Крім того, ви можете порівнювати `Version` з іншою версією, використовуючи функцію `Compare`: ```none semver "1.4.3" | (semver "1.2.3").Compare ``` Вищезазначене поверне `-1`. Значення повернення такі: * `-1`, якщо дана версія SemVer більша за версію, метод `Compare` якої був викликаний * `1`, якщо версія, для якої була викликана функція `Compare`, більша * `0`, якщо версії однакові (Зверніть увагу, що в SemVer поле `Metadata` не порівнюється під час операцій порівняння версій.) ### semverCompare Більш надійна функція порівняння надається як `semverCompare`. Ця версія підтримує діапазони версій: * `semverCompare "1.2.3" "1.2.3"` перевіряє на точний збіг * `semverCompare "~1.2.0" "1.2.3"` перевіряє, що основні та мінорні версії збігаються, і що номер патчу другої версії _більший або рівний_ першому параметру. Функції SemVer використовують бібліотеку [Masterminds semver](https://github.com/Masterminds/semver), від творців Sprig. ### Основні порівняння {#basic-comparisons} Є два елементи порівнянь. По-перше, рядок порівняння є списком порівнянь з AND, розділених пробілом або комою. Ці порівняння потім розділяються операцією || (OR). Наприклад, `">= 1.2 < 3.0.0 || >= 4.2.3"` шукає порівняння, яке більше або дорівнює 1.2 і менше 3.0.0 або більше або дорівнює 4.2.3. Основні порівняння: * `=`: рівно (аналогічно відсутності оператора) * `!=`: не рівно * `>`: більше ніж * `<`: менше ніж * `>=`: більше або рівно * `<=`: менше або рівно ### Робота з версіями пре-релізів {#working-with-prerelease-versions} Пре-релізи, для тих, хто не знайомий з ними, використовуються для випусків програмного забезпечення до стабільних або загальнодоступних випусків. Прикладами пре-релізів є розробка, альфа, бета та реліз-кандидат. Пре-реліз може бути версією, наприклад, `1.2.3-beta.1`, в той час як стабільний реліз буде `1.2.3`. За порядком пріоритету пре-релізи йдуть перед їх повʼязаними релізами. У цьому прикладі `1.2.3-beta.1 < 1.2.3`. Згідно з специфікацією Semantic Version, пре-релізи можуть не відповідати API сумісності зі своїм релізом. Вона говорить, > Версія пре-релізу вказує, що версія нестабільна і може не відповідати запланованим вимогам сумісності, як зазначено у відповідній нормальній версії. Порівняння SemVer з використанням обмежень без компаратора пре-релізу пропустять пре-релізи. Наприклад, `>=1.2.3` пропустить пре-релізи при перегляді списку релізів, тоді як `>=1.2.3-0` буде оцінювати і знаходити пре-релізи. Причина для `0` як версії пре-релізу у прикладі порівняння полягає в тому, що пре-релізи можуть містити лише ASCII числа, літери та дефіси (разом з роздільниками `.`), згідно з специфікацією. Сортування відбувається в ASCII порядку сортування, згідно з специфікацією. Найнижчий символ — це `0` в ASCII порядку сортування (див. [ASCII Таблицю](http://www.asciitable.com/)). Розуміння ASCII порядку сортування важливе, оскільки A-Z йде перед a-z. Це означає, що `>=1.2.3-BETA` поверне `1.2.3-alpha`. Те, що ви могли б очікувати від чутливості до регістру, тут не застосовується. Це через ASCII порядок сортування, який зазначено у специфікації. ### Порівняння діапазонів з дефісами {#hyphen-range-comparisons} Є кілька методів обробки діапазонів, і перший — діапазони з дефісами. Вони виглядають так: * `1.2 - 1.4.5`, що еквівалентно `>= 1.2 <= 1.4.5` * `2.3.4 - 4.5`, що еквівалентно `>= 2.3.4 <= 4.5` ### Підстановочні символи в порівняннях {#wildcard-in-comparisons} Символи `x`, `X` та `*` можуть використовуватися як символи заміщення. Це працює для всіх операторів порівняння. Коли використовується з оператором `=`, він переходить до порівняння рівня патчу (див. тильду нижче). Наприклад, * `1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` * `>= 1.2.x` еквівалентно `>= 1.2.0` * `<= 2.x` еквівалентно `< 3` * `*` еквівалентно `>= 0.0.0` ### Порівняння діапазонів з тильдою (patch) {#tilde-range-comparisons-patch} Оператор порівняння тильди (`~`) використовується для діапазонів рівня патчу, коли вказана мінорна версія, і для змін на рівні основної версії, коли мінорний номер відсутній. Наприклад, * `~1.2.3` еквівалентно `>= 1.2.3, < 1.3.0` * `~1` еквівалентно `>= 1, < 2` * `~2.3` еквівалентно `>= 2.3, < 2.4` * `~1.2.x` еквівалентно `>= 1.2.0, < 1.3.0` * `~1.x` еквівалентно `>= 1, < 2` ### Порівняння діапазонів з кареткою (major) {#caret-range-comparisons-major} Оператор порівняння каретки (`^`) використовується для змін на рівні основної версії після випуску стабільної (1.0.0) версії. До випуску 1.0.0 мінорні версії діють як рівень стабільності API. Це корисно при порівнянні версій API, оскільки велика зміна є порушенням API. Наприклад, * `^1.2.3` еквівалентно `>= 1.2.3, < 2.0.0` * `^1.2.x` еквівалентно `>= 1.2.0, < 2.0.0` * `^2.3` еквівалентно `>= 2.3, < 3` * `^2.x` еквівалентно `>= 2.0.0, < 3` * `^0.2.3` еквівалентно `>=0.2.3 <0.3.0` * `^0.2` еквівалентно `>=0.2.0 <0.3.0` * `^0.0.3` еквівалентно `>=0.0.3 <0.0.4` * `^0.0` еквівалентно `>=0.0.0 <0.1.0` * `^0` еквівалентно `>=0.0.0 <1.0.0` ## Функції URL {#url-functions} Helm включає функції [urlParse](#urlparse), [urlJoin](#urljoin) і [urlquery](#urlquery), які дозволяють працювати з частинами URL. ### urlParse Розбирає рядок для URL і створює словник з частинами URL ```none urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` Вищезазначене повертає словник, що містить обʼєкт URL: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` Це реалізовано за допомогою пакетів URL з стандартної бібліотеки Go. Для отримання додаткової інформації перевірте https://golang.org/pkg/net/url/#URL ### urlJoin Обʼєднує словник (створений за допомогою `urlParse`) для створення рядка URL ```none urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` Вищезазначене поверне наступний рядок: ```none http://host:80/path?query#fragment ``` ### urlquery Повертає екрановану версію значення, переданого як аргумент, так що воно підходить для вбудовування в частину запиту URL. ```none $var := urlquery "string for query" ``` ## Функції UUID {#uuid-functions} Helm може генерувати UUID v4, унікальні ідентифікатори. ```none uuidv4 ``` Вищезазначене повертає новий UUID типу v4 (згенерований випадковим чином). ## Функції Kubernetes і Chart {#kubernetes-and-chart-functions} Helm включає функції для роботи з Kubernetes, зокрема [`.Capabilities.APIVersions.Has`](#capabilitiesapiversionshas), [Files](#file-functions) та [lookup](#lookup). ### lookup `lookup` використовується для пошуку ресурсу в працюючому кластері. При використанні з командою `helm template` він завжди повертає порожній результат. Більше деталей можна знайти в [документації по функції lookup](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function). ### .Capabilities.APIVersions.Has Повертає, чи доступна API-версія або ресурс у кластері. ```none .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` Більше інформації доступно в [документації по вбудованих обʼєктах](/chart_template_guide/builtin_objects.md). ### Функції файлів {#file-functions} Є кілька функцій, які дозволяють отримати доступ до не-спеціальних файлів всередині chart. Наприклад, для доступу до конфігураційних файлів програми. Ці функції документовані в [Доступ до файлів всередині шаблонів](/chart_template_guide/accessing_files.md). _Зверніть увагу, що документація для багатьох з цих функцій надходить з [Sprig](https://github.com/Masterminds/sprig). Sprig — це бібліотека функцій шаблонів, доступна для застосунків на Go._ ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Функції шаблонів та конвеєри description: Використання функцій у шаблонах. sidebar_position: 5 --- Дотепер ми бачили, як розміщувати інформацію в шаблоні. Але ця інформація розміщується в шаблоні без змін. Іноді ми хочемо перетворити надані дані таким чином, щоб вони були більш корисними для нас. Почнемо з найкращої практики: коли вставляємо рядки з об’єкта `.Values` у шаблон, ми повинні обов’язково обгорнути ці рядки в лапки. Ми можемо зробити це, викликавши функцію `quote` в директиві шаблону: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Функції шаблонів дотримуються синтаксису `functionName arg1 arg2...`. У наведеному вище фрагменті `quote .Values.favorite.drink` викликає функцію `quote` і передає їй один аргумент. Helm має понад 60 доступних функцій. Деякі з них визначені [мовою шаблонів Go](https://godoc.org/text/template). Більшість інших є частиною [бібліотеки шаблонів Sprig](https://masterminds.github.io/sprig/). Ми побачимо багато з них у міру того, як будемо розглядати приклади. > Хоча ми говоримо про "мову шаблонів Helm", як про щось специфічне для Helm, насправді це комбінація мови шаблонів Go, деяких додаткових функцій і різноманітних обгорток, які дозволяють передавати певні обʼєкти в шаблони. Багато ресурсів про шаблони Go можуть бути корисними, коли ви вивчаєте шаблони. ## Конвеєри {#pipelines} Однією з потужних функцій мови шаблонів є концепція _конвеєрів_. Запозичивши концепцію з UNIX, конвеєри є інструментом для обʼєднання серії команд шаблонів для компактного вираження низки перетворень. Іншими словами, конвеєри — це ефективний спосіб виконання кількох завдань послідовно. Перепишемо наведений вище приклад, використовуючи конвеєр. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` У цьому прикладі замість виклику `quote ARGUMENT` ми інвертували порядок. Ми "надіслали" аргумент функції за допомогою конвеєра (`|`): `.Values.favorite.drink | quote`. Використовуючи конвеєри, ми можемо обʼєднати кілька функцій: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Інверсія порядку є поширеною практикою в шаблонах. Ви частіше побачите `.val | quote`, ніж `quote .val`. Обидві практики є правильними. Під час обробки цей шаблон створить такий результат: ```yaml ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Зверніть увагу, що наша початкова `pizza` тепер перетворилася на `"PIZZA"`. Коли аргументи передаються за допомогою конвеєра, результат першого обчислення (`.Values.favorite.drink`) надсилається як _останній аргумент функції_. Ми можемо змінити приклад із напоєм вище, щоб продемонструвати функцію, яка приймає два аргументи: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` Функція `repeat` буде повторювати даний рядок задану кількість разів, тому ми отримаємо такий вихідний результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Використання функції `default` {#using-the-default-function} Однією з функцій, яку часто використовують у шаблонах, є функція `default`: `default DEFAULT_VALUE GIVEN_VALUE`. Ця функція дозволяє вам вказати стандартне значення в шаблоні, у разі якщо значення відсутнє. Використаємо її, щоб змінити приклад з напоєм вище: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` Якщо ми запустимо це як зазвичай, ми отримаємо наш `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Тепер ми видалимо параметр улюбленого напою з `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Тепер повторний запуск `helm install --dry-run --debug fair-worm ./mychart` створить такий YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` В реальній схемі всі статичні стандартні значення повинні зберігатися у файлі `values.yaml` і не повинні дублюватися за допомогою команди `default` (інакше вони будуть надлишковими). Однак команда `default` ідеально підходить для обчислюваних значень, які не можуть бути оголошені у файлі `values.yaml`. Наприклад: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` У деяких випадках умова `if` може бути кращим рішенням, ніж `default`. Ми побачимо їх у наступному розділі. Функції та конвеєри шаблонів — це потужний спосіб перетворення інформації та її вставки у ваш YAML. Але іноді необхідно додати деяку логіку шаблонів, яка трохи складніша, ніж просто вставка рядка. У наступному розділі ми розглянемо структури керування, які надає мова шаблонів. ## Використання функції `lookup` {#using-the-lookup-function} Функцію `lookup` можна використовувати для _пошуку_ ресурсів у працюючому кластері. Синопсис функції lookup — це `lookup apiVersion, kind, namespace, name -> resource or resource list`. | параметр | тип | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Обидва параметри `name` та `namespace` є необов’язковими та можуть передаватися як порожній рядок (`""`). Можливі такі комбінації параметрів: | Поведінка | Функція пошуку | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | Коли `lookup` повертає обʼєкт, він поверне словник. Цей словник може бути додатково досліджений для отримання конкретних значень. Наступний приклад поверне анотації, присутні для обʼєкта `mynamespace`: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` Коли `lookup` повертає список обʼєктів, можливо отримати доступ до списку обʼєктів через поле `items`: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* робимо щось з кожним сервісом */}} {{ end }} ``` Коли обʼєкт не знайдено, повертається порожнє значення. Це може бути використано для перевірки наявності обʼєкта. Функція `lookup` використовує поточну конфігурацію зʼєднання Kubernetes Helm для запиту до Kubernetes. Якщо при взаємодії з викликом сервера API виникає помилка (наприклад, через відсутність дозволу на доступ до ресурсу), обробка шаблонів Helm зазнає невдачі. Майте на увазі, що Helm не призначений для контакту з Kubernetes API Server під час операцій `helm template|install|upgrade|delete|rollback --dry-run`. Щоб протестувати `lookup` на працюючому кластера, слід використовувати `helm template|install|upgrade|delete|rollback --dry-run=server`, щоб дозволити з’єднання з кластером. ## Оператори як функції {#operators-are-functions} Для шаблонів оператори (`eq`, `ne`, `lt`, `gt`, `and`, `or` і так далі) реалізовані як функції. У конвеєрах операції можуть бути згруповані дужками (`(` і `)`). Тепер ми можемо перейти від функцій і конвеєрів до управління потоком з умовами, циклами та модифікаторами області видимості. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Початок роботи description: Короткий посібник з шаблонів чартів. sidebar_position: 2 --- У цьому розділі посібника ми створимо чарт і додамо перший шаблон. Чарт, який ми створимо тут, буде використовуватися протягом усього цього посібника. Щоб розпочати, давайте коротко ознайомимося з чартом Helm. ## Чарти {#charts} Як описано в [Посібнику з чартів](/topics/charts.md), чарти Helm мають таку структуру: ```none mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` Тека `templates/` призначена для файлів шаблонів. Коли Helm обробляє чарт, він передає всі файли з теки`templates/` до механізму рендерингу шаблонів. Потім збирає результати цих шаблонів і передає їх до Kubernetes. Файл `values.yaml` також важливий для шаблонів. Цей файл містить _стандартні значення_ для чарту. Користувачі можуть перевизначити ці значення під час `helm install` або `helm upgrade`. Файл `Chart.yaml` містить опис чарту. Ви можете отримати до нього доступ із шаблону. Тека `charts/` _може_ містити інші чарти (які ми називаємо _субчартами_). Пізніше в цьому посібнику ми побачимо, як вони працюють під час рендерингу шаблонів. ## Стартовий чарт {#starter-chart} У цьому посібнику ми створимо простий чарт з назвою `mychart`, а потім створимо кілька шаблонів всередині чарту. ```console $ helm create mychart Creating mychart ``` ### Швидкий огляд `mychart/templates/` {#quick-glimpse-of-mychart-templates} Якщо ви поглянете на теку `mychart/templates/`, то помітите кілька файлів, які вже там є. - `NOTES.txt`: Вміст тексту довідки для вашого чарту. Його буде показана користувачам під час виконання `helm install`. - `deployment.yaml`: Основний маніфест для створення [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) у Kubernetes. - `service.yaml`: Основний маніфест для створення [точки доступу сервісу](https://kubernetes.io/docs/concepts/services-networking/service/) для вашого deployment. - `_helpers.tpl`: Місце для розміщення допоміжних шаблонів, які ви можете використовувати повторно по всьому чарту. І що ми збираємося зробити, це… _видалити їх усі!_ Таким чином, ми зможемо працювати з нашим посібником з нуля. Ми фактично створимо власні `NOTES.txt` та `_helpers.tpl` під час роботи. ```console $ rm -rf mychart/templates/* ``` Коли ви пишете чарти для операційної діяльності, мати базові версії цих чартів може бути дійсно корисно. Тож у повсякденному створенні чартів ви, ймовірно, не захочете їх видаляти. ## Перший шаблон {#a-first-template} Перший шаблон, який ми збираємося створити, буде `ConfigMap`. У Kubernetes `ConfigMap` — це обʼєкт для зберігання конфігураційних даних. Інші речі, такі як podʼи, можуть отримувати доступ до даних у `ConfigMap`. Оскільки `ConfigMap` є базовим ресурсом, він стане чудовою відправною точкою для нас. Почнемо зі створення файлу з назвою `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **ПОРАДА:** Імена шаблонів не слідують жорсткому шаблону іменування. Проте ми рекомендуємо використовувати розширення `.yaml` для YAML-файлів та `.tpl` для допоміжних шаблонів. Наведений вище YAML-файл є мінімальною версією `ConfigMap`, що містить лише необхідні поля. Завдяки тому, що цей файл знаходиться в теці `mychart/templates/`, він буде переданий через механізм рендерингу шаблонів. Можна просто помістити звичайний YAML-файл, як цей, у теку `mychart/templates/`. Коли Helm читає цей шаблон, він просто передає його в Kubernetes у такому вигляді. За допомогою цього простого шаблону ми отримали чарт, який можна інсталювати. І ми можемо встановити його ось так: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` За допомогою Helm ми можемо отримати реліз і побачити фактичний шаблон, який був завантажений. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` Команда `helm get manifest` приймає імʼя релізу (`full-coral`) і виводить усі ресурси Kubernetes, які були завантажені на сервер. Кожен файл починається з `---`, що вказує на початок YAML-документа, а потім слідує автоматично згенерований коментар, який повідомляє нам, який файл шаблону згенерував цей YAML-документ. З цього моменту ми можемо побачити, що YAML-дані саме такі, як ми їх розмістили у файлі `configmap.yaml`. Тепер ми можемо видалити наш реліз: `helm uninstall full-coral`. ### Додавання виклику простого шаблону {#adding-a-simple-template-call} Жорстке кодування поля `name:` у ресурсі зазвичай вважається поганою практикою. Імена повинні бути унікальними для кожного релізу. Тому ми можемо захотіти згенерувати поле імені, вставивши назву релізу. **ПОРАДА:** Поле `name:` обмежене 63 символами через обмеження системи DNS. З цієї причини імена релізів обмежені 53 символами. У Kubernetes версії 1.3 та раніше було обмежено лише 24 символами (тобто імена довжиною до 14 символів). Змінимо файл `configmap.yaml` відповідно. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` Основна зміна полягає в значенні поля `name:`, яке тепер має вигляд `{{ .Release.Name }}-configmap`. > Директива шаблону міститься у дужках `{{` та `}}`. Директива шаблону `{{ .Release.Name }}` вставляє назву релізу в шаблон. Значення, які передаються в шаблон, можна вважати _обʼєктами з просторами імен_, де точка (`.`) розділяє кожен елемент простору імен. Точка перед `Release` вказує, що ми починаємо з найвищого простору імен для цієї області застосування (про область ми поговоримо трохи пізніше). Таким чином, ми могли б прочитати `Release.Name` як: "почати з верхнього простору імен, знайти обʼєкт `Release`, а потім шукати всередині нього обʼєкт з назвою `Name`". Обʼєкт `Release` є одним із вбудованих обʼєктів для Helm, і ми розглянемо його більш детально пізніше. Але поки достатньо сказати, що це покаже назву релізу, яку бібліотека присвоює нашому релізу. Тепер, коли ми встановлюємо наш ресурс, ми одразу побачимо результат використання цієї директиви шаблону: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Ви можете запустити `helm get manifest clunky-serval`, щоб побачити весь згенерований YAML. Зверніть увагу, що імʼя ConfigMap всередині Kubernetes тепер є `clunky-serval-configmap`, замість попереднього `mychart-configmap`. На цьому етапі ми бачили шаблони в їх найпростішому вигляді: YAML-файли з вбудованими директивами шаблонів між `{{` та `}}`. У наступній частині ми глибше розглянемо шаблони. Але перед тим, як перейти далі, є один простий трюк, який може зробити створення шаблонів швидшим: коли ви хочете протестувати рендеринг шаблону, але насправді нічого не встановлювати, ви можете використати `helm install --debug --dry-run goodly-guppy ./mychart`. Це опрацює шаблони, але замість того, щоб встановити чарт, він поверне вам опрацьований шаблон, щоб ви могли побачити результат: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Використання `--dry-run` полегшить тестування вашого коду, але це не гарантує, що сам Kubernetes прийме згенеровані вами шаблони. Краще не припускати, що ваш чарт буде встановлений тільки тому, що `--dry-run` працює. У [Посібнику з шаблонів чарту](/chart_template_guide/index.mdx) ми розглянемо базовий чарт, який ми визначили тут, і детально дослідимо мову шаблонів Helm. І ми почнемо з вбудованих обʼєктів. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: Файл .helmignore description: Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт. sidebar_position: 12 --- Файл `.helmignore` використовується для вказівки файлів, які не слід включати у ваш Helm чарт. Якщо цей файл існує, команда `helm package` ігноруватиме всі файли, які відповідають шаблону, зазначеному у файлі `.helmignore`, під час упаковки вашого застосунку. Це може допомогти уникнути додавання непотрібних або конфіденційних файлів або тек у ваш Helm чарт. Файл `.helmignore` підтримує глобальний збіх Unix shell, відносний збіг шляхів та заперечення (з префіксом !). Розглядається лише один шаблон на рядок. Ось приклад файлу `.helmignore`: ```none # коментар # Відповідає будь-якому файлу або шляху з імʼям .helmignore .helmignore # Відповідає будь-якому файлу або шляху з імʼям .git .git # Відповідає будь-якому текстовому файлу *.txt # Відповідає тільки текам з імʼям mydir mydir/ # Відповідає тільки текстовим файлам на верхньому рівні теки /*.txt # Відповідає тільки файлу foo.txt на верхньому рівні теки /foo.txt # Відповідає будь-якому файлу з імʼям ab.txt, ac.txt або ad.txt a[b-d].txt # Відповідає будь-якому файлу у субтеці subdir, що відповідає temp* */temp* */*/temp* temp? ``` Декілька важливих відмінностей від `.gitignore`: - Синтаксис '**' не підтримується. - Бібліотека globbing є Go's `filepath.Match`, а не `fnmatch(3)`. - Пробіли на кінці ігноруються завжди (немає підтримки екранованих послідовностей). - Немає підтримки '\!' як спеціальної початкової послідовності. - Файл `.helmignore` стандартно не виключає себе, потрібно додати явний запис для `.helmignore`. **Ми будемо вдячні за вашу допомогу** у покращенні цього документа. Щоб додати, виправити або видалити інформацію, [відкрийте тікет](https://github.com/helm/helm-www/issues) або надішліть нам запит на внесення змін. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: Шаблони чартів sidebar_position: 5 --- # Посібник розробника шаблонів чартів Цей посібник надає введення в шаблони чартів Helm, з акцентом на мову шаблонів. Шаблони генерують файли маніфестів, які є YAML-форматованими описами ресурсів, які Kubernetes може зрозуміти. Ми розглянемо, як структуровані шаблони, як їх можна використовувати, як писати шаблони на Go і як налагоджувати вашу роботу. Цей посібник зосереджений на наступних концепціях: - Мова шаблонів Helm - Використання значень - Техніки роботи з шаблонами Цей посібник орієнтований на вивчення особливостей мови шаблонів Helm. Інші посібники надають вступні матеріали, приклади та найкращі практики. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Іменовані шаблони description: Як визначити іменовані шаблони. sidebar_position: 9 --- Пора перейти від одного шаблону до створення інших. У цьому розділі ми побачимо, як визначити _іменовані шаблони_ в одному файлі, а потім використовувати їх в інших місцях. _Іменований шаблон_ (іноді його називають _частковим_ або _підшаблоном_) — це просто шаблон, визначений у файлі, якому надали імʼя. Ми розглянемо два способи створення таких шаблонів і кілька способів їх використання. У розділі [Керування потоком](/chart_template_guide/control_structures.md) ми представили три дії для оголошення та управління шаблонами: `define`, `template` і `block`. У цьому розділі ми розглянемо ці три дії, а також введемо спеціальну функцію `include`, яка працює подібно до дії `template`. Важлива деталь, яку слід памʼятати при іменуванні шаблонів: **імена шаблонів є глобальними**. Якщо ви оголосите два шаблони з однаковим імʼям, використовуватиметься той, який був завантажений останнім. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, слід бути обережним при іменуванні шаблонів, використовуючи _імена, специфічні для чарту_. Популярним способом іменування є префіксування кожного визначеного шаблону іменем чарту: `{{ define "mychart.labels" }}`. Використовуючи конкретне імʼя чарту як префікс, ми можемо уникнути будь-яких конфліктів, які можуть виникнути через два різних чарти, що реалізують шаблони з однаковим іменем. Ця поведінка також стосується різних версій чарту. Якщо у вас є `mychart` версії `1.0.0`, яка визначає шаблон одним способом, і `mychart` версії `2.0.0`, яка змінює наявний іменований шаблон, буде використовуватися той, який був завантажений останнім. Ви можете обійти цю проблему, додавши версію в імʼя чарту: `{{ define "mychart.v1.labels" }}` та `{{ define "mychart.v2.labels" }}`. ## Часткові та `_` файли {#partials-and-_files} До цього часу ми використовували один файл, і цей один файл містив один шаблон. Але мова шаблонів Helm дозволяє створювати іменовані вкладені шаблони, до яких можна звертатися за іменем в інших місцях. Перед тим як перейти до деталей написання цих шаблонів, варто згадати про правила іменування файлів: * Більшість файлів у `templates/` обробляються як файли з маніфестами Kubernetes * `NOTES.txt` є винятком * Але файли, імʼя яких починається з підкреслення (`_`), вважаються такими, що _не мають_ маніфесту всередині. Ці файли не перетворюються на обʼєкти Kubernetes, але доступні в інших шаблонах чартів для використання. Ці файли використовуються для зберігання часткових шаблонів і допоміжних функцій. Насправді коли ми вперше створили `mychart`, ми бачили файл з назвою `_helpers.tpl`. Цей файл є стандартним місцем для часткових шаблонів. ## Оголошення та використання шаблонів з `define` та `template` {#declaring-and-using-templates-with-define-and-template} Дія `define` дозволяє створювати іменовані шаблони всередині файлу шаблону. Її синтаксис виглядає так: ```yaml {{- define "MY.NAME" }} # тіло шаблону тут {{- end }} ``` Наприклад, ми можемо визначити шаблон для інкапсуляції блоку міток Kubernetes: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Тепер ми можемо вбудувати цей шаблон всередині нашого наявного ConfigMap і включити його за допомогою дії `template`: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Коли рушій шаблонів читає цей файл, він зберігає посилання на `mychart.labels` до того часу, поки не буде викликано `template "mychart.labels"`. Тоді він рендерить цей шаблон безпосередньо. Результат виглядатиме так: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Примітка: `define` не створює виводу, якщо не буде викликано шаблон, як у цьому прикладі. Зазвичай шаблони Helm розміщують у файлах часткових шаблонів, зазвичай у `_helpers.tpl`. Перенесемо цю функцію туди: ```yaml {{/* Генерація базових міток */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Згідно з домовленостями, функції `define` повинні мати простий блок документації (`{{/* ... */}}`), що описує їх призначення. Навіть якщо це визначення знаходиться в `_helpers.tpl`, його все ще можна використовувати в `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Як уже згадувалося, **імена шаблонів є глобальними**. В результаті, якщо два шаблони оголошені з однаковим імʼям, буде використано останній варіант. Оскільки шаблони в субчартах компілюються разом з шаблонами верхнього рівня, краще давати шаблонам _специфічні для чарту імена_. Популярний спосіб іменування — це префіксувати кожен визначений шаблон іменем чарту: `{{ define "mychart.labels" }}`. ## Встановлення області видимості шаблону {#setting-the-scope-of-a-template} У шаблоні, який ми визначили вище, ми не використовували жодних обʼєктів. Ми просто використовували функції. Змінимо наш визначений шаблон, щоб включити назву чарту та версію чарту: ```yaml {{/* Генерація базових міток */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` Якщо ми його відрендеримо, ми отримаємо помилку, схожу на цю: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` Щоб побачити, що було відрендерено, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. Результат не буде таким, як ми очікували: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` Що сталося з назвою та версією? Вони не були в області видимості для нашого визначеного шаблону. Коли іменований шаблон (створений за допомогою `define`) рендериться, він отримує область видимості, передану через виклик `template`. У нашому прикладі ми включили шаблон ось так: ```yaml {{- template "mychart.labels" }} ``` Область видимості не була передана, тому всередині шаблону ми не можемо звертатися до нічого в `.`. Це досить легко виправити. Ми просто передаємо область видимості до шаблону: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Зверніть увагу, що ми передаємо `.` в кінці виклику `template`. Ми могли б так само легко передати `.Values` або `.Values.favorite`, або будь-яку іншу область видимості, яку хочемо. Але те, що нам потрібно, це область видимості верхнього рівня. Тепер, коли ми виконаємо цей шаблон з `helm install --dry-run --debug plinking-anaco ./mychart`, ми отримаємо таке: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Тепер `{{ .Chart.Name }}` розвʼязується в `mychart`, а `{{ .Chart.Version }}` розвʼязується в `0.1.0`. ## Функція `include` {#the-include-function} Припустимо, ми визначили простий шаблон, який виглядає ось так: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Тепер припустимо, я хочу вставити це як в розділ `labels:`, так і в розділ `data:`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` Якщо ми це відрендеримо, ми отримаємо помилку, схожу на цю: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` Щоб побачити, що було відрендеровано, повторіть команду з `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. Вихідні дані не будуть такими, як ми очікували: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Зверніть увагу, що відступ на `app_version` неправильний в обох місцях. Чому? Тому що шаблон, який вставляється, має текст вирівняний по лівому краю. Оскільки `template` є дією, а не функцією, немає способу передати вихідний результат виклику `template` іншим функціям; дані просто вставляються в рядок. Щоб обійти цю проблему, Helm надає альтернативу `template`, яка імплементує вміст шаблону в поточний конвеєр, де він може бути переданий іншим функціям у конвеєрі. Ось приклад вище, виправлений з використанням `indent`, щоб правильно відступити шаблон `mychart.app`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Тепер створений YAML має вірний відступ для кожного розділу: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > Вважається за краще використовувати `include` замість `template` у шаблонах Helm, щоб краще керувати форматуванням виходу для YAML-документів. Іноді ми хочемо імплементувати вміст, але не як шаблони. Тобто, ми хочемо імплементувати файли без змін. Ми можемо досягти цього, звертаючись до файлів через обʼєкт `.Files`, описаний у наступному розділі. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Створення файлу NOTES.txt description: Як надати інструкції користувачам вашого чарту. sidebar_position: 10 --- У цьому розділі ми розглянемо інструмент Helm для надання інструкцій користувачам вашого чарту. Після виконання `helm install` або `helm upgrade` Helm може вивести блок корисної інформації для користувачів. Цю інформацію можна налаштувати за допомогою шаблонів. Щоб додати нотатки по установці до вашого чарту, просто створіть файл `templates/NOTES.txt`. Цей файл є звичайним текстовим файлом, але обробляється як шаблон і має всі звичайні функції та обʼєкти шаблонів. Створимо простий файл `NOTES.txt`: ```none Дякуємо за встановлення {{ .Chart.Name }}. Ваш реліз називається {{ .Release.Name }}. Щоб дізнатися більше про реліз, спробуйте: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Тепер, якщо ми виконаємо `helm install rude-cardinal ./mychart`, ми побачимо це повідомлення внизу: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Дякуємо за встановлення mychart. Ваш реліз називається rude-cardinal. Щоб дізнатися більше про реліз, спробуйте: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Використання `NOTES.txt` таким чином є чудовим способом надати вашим користувачам детальну інформацію про те, як використовувати новостворений чарт. Створення файлу `NOTES.txt` наполегливо рекомендується, хоча це і не є обовʼязковим. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Субчарти та глобальні значення description: Взаємодія з значеннями субчартів і глобальними значеннями. sidebar_position: 11 --- До цього моменту ми працювали тільки з одним чартом. Але чарти можуть мати залежності, які називаються _субчартами_, що також мають свої власні значення і шаблони. У цьому розділі ми створимо субчарт і розглянемо різні способи доступу до значень зсередини шаблонів. Перед тим, як перейти до коду, є кілька важливих деталей, які слід знати про субчарти: 1. Субчарт вважається "автономним", що означає, що субчарт ніколи не може прямо залежати від батьківського чарту. 2. Тому субчарт не може отримувати доступ до значень свого пращура. 3. Батьківський чарт може перевизначати значення для субчартів. 4. Helm має концепцію _глобальних значень_, які можуть бути доступні всім чартам. > Ці обмеження не завжди застосовуються до [бібліотечних чартів](/topics/library_charts.md), які розроблені для надання стандартної функціональності. Під час роботи з прикладами в цьому розділі ці концепції стануть зрозумілішими. ## Створення субчарту {#creating-a-subchart} Для цих вправ ми почнемо з чарту `mychart/`, який ми створили на початку цього посібника, і додамо новий чарт всередину його. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Зверніть увагу, що ми видалили всі базові шаблони, щоб почати з нуля. У цьому посібнику ми зосереджені на тому, як працюють шаблони, а не на управлінні залежностями. Але [Посібник з Чартів](/topics/charts.md) містить більше інформації про те, як працюють субчарти. ## Додавання значень та шаблону до субчарту {#adding-values-and-a-template-to-the-subchart} Далі створимо простий шаблон і файл значень для чарту `mysubchart`. У `mychart/charts/mysubchart` вже має бути файл `values.yaml`. Налаштуємо його так: ```yaml dessert: cake ``` Далі створимо новий шаблон ConfigMap у `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Оскільки кожен субчарт є _самостіним чартом_, ми можемо протестувати `mysubchart` окремо: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Перевизначення значень з батьківського чарту {#overriding-values-from-a-parent-chart} Наш оригінальний чарт, `mychart`, тепер є _батьківським_ чартом для `mysubchart`. Ці стосунки базується виключно на тому, що `mysubchart` знаходиться в `mychart/charts`. Оскільки `mychart` є батьківським чартом, ми можемо вказати конфігурацію в `mychart` і передати цю конфігурацію в `mysubchart`. Наприклад, ми можемо змінити `mychart/values.yaml` таким чином: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Зверніть увагу на останні два рядки. Будь-які директиви всередині секції `mysubchart` будуть передані в чарт `mysubchart`. Отже, якщо ми виконаємо `helm install --generate-name --dry-run --debug mychart`, однією з речей, які ми побачимо, буде ConfigMap `mysubchart`: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` Значення на верхньому рівні тепер перевизначило значення субчарту. Важливо помітити, що ми не змінили шаблон `mychart/charts/mysubchart/templates/configmap.yaml`, щоб вказати на `.Values.mysubchart.dessert`. З точки зору цього шаблону, значення все ще розташоване в `.Values.dessert`. Оскільки шаблонний движок передає значення далі, він встановлює область видимості. Отже, для шаблонів `mysubchart` тільки значення, специфічні для `mysubchart`, будуть доступні в `.Values`. Іноді, проте, ви хочете, щоб певні значення були доступні всім шаблонам. Це досягається за допомогою глобальних значень чарту. ## Глобальні значення чарту {#global-chart-values} Глобальні значення — це значення, які можуть бути доступні з будь-якого чарту або субчарту під тим самим імʼям. Глобальні значення потребують явного оголошення. Ви не можете використовувати вже наявні неглобальні значення як глобальні. Тип даних Values має зарезервовану секцію `Values.global`, де можна задати глобальні значення. Визначимо одне в нашому файлі `mychart/values.yaml`. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Завдяки способу роботи глобальних значень, як `mychart/templates/configmap.yaml`, так і `mysubchart/templates/configmap.yaml` повинні мати змогу отримати це значення як `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Тепер, якщо ми виконаємо установку в режимі dry run, ми побачимо одне й те ж значення в обох виводах: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Глобальні значення корисні для передачі такої інформації, хоча це вимагає певного планування, щоб переконатися, що правильні шаблони налаштовані для використання глобальних значень. ## Поширення шаблонів з субчартами {#sharing-templates-with-subcharts} Батьківські чарти та субчарти можуть ділитися шаблонами. Будь-який визначений блок у будь-якому чарті доступний іншим чартам. Наприклад, ми можемо визначити простий шаблон таким чином: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Згадайте, як мітки на шаблонах є _глобально спільними_. Отже, шаблон `labels` можна включити з будь-якого іншого чарту. Хоча розробники чартів можуть вибирати між `include` та `template`, однією з переваг використання `include` є те, що `include` може динамічно посилатися на шаблони: ```yaml {{ include $mytemplate }} ``` Вищезазначене призведе до розʼєднання посилань на `$mytemplate`. Функція `template`, навпаки, приймає тільки рядковий літерал. ## Уникнення використання блоків {#avoid-using-blocks} Мова шаблонів Go надає ключове слово `block`, яке дозволяє розробникам надати стандартну реалізацію, яка потім перевизначається. У чарті Helm блоки не є найкращим інструментом для перевизначення, оскільки якщо кілька реалізацій одного блоку надаються, вибір однієї з них є непередбачуваним. Рекомендація — використовувати `include`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Файли значень description: Інструкції щодо використання прапорця --values. sidebar_position: 4 --- У попередньому розділі ми розглянули вбудовані обʼєкти, які пропонують шаблони Helm. Один з вбудованих обʼєктів — це `Values`. Цей обʼєкт надає доступ до значень, переданих у шаблон. Його вміст походить з кількох джерел: - Файл `values.yaml` у шаблоні - Якщо це субшаблон, файл `values.yaml` батьківського шаблону - Файл значень передається в `helm install` або `helm upgrade` з прапорцем `-f` (`helm install -f myvals.yaml ./mychart`) - Окремі параметри передаються з `--set` (наприклад, `helm install --set foo=bar ./mychart`) Наведений вище список розташований у порядку специфічності: `values.yaml` є стандартним, яке може бути перевизначене файлом `values.yaml` батьківського шаблону, який, своєю чергою, може бути перевизначений файлом значень, наданим користувачем, який, своєю чергою, може бути перевизначений параметрами `--set`. Файли значень — це прості YAML-файли. Відредагуємо `mychart/values.yaml`, а потім відредагуємо наш шаблон ConfigMap. Видаливши стандартні значення у `values.yaml`, ми встановимо лише один параметр: ```yaml favoriteDrink: coffee ``` Тепер ми можемо використовувати його всередині шаблону: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Зверніть увагу, що в останньому рядку ми отримуємо доступ до `favoriteDrink` як до атрибута `Values`: `{{ .Values.favoriteDrink }}`. Подивімося, як це відобразиться. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Оскільки `favoriteDrink` встановлено в стандартне значення у файлі `values.yaml` як `coffee`, це значення відображається в шаблоні. Ми можемо легко перевизначити його, додавши прапорець `--set` у наш виклик `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Оскільки `--set` має вищий пріоритет, ніж файл `values.yaml`, наш шаблон генерує `drink: slurm`. Файли значень також можуть містити більш структурований контент. Наприклад, ми могли б створити розділ `favorite` у нашому файлі `values.yaml`, а потім додати туди кілька ключів: ```yaml favorite: drink: coffee food: pizza ``` Тепер нам потрібно трохи змінити шаблон: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` Хоча структурування даних таким чином є можливим, рекомендується тримати дерева значень пласкими, надаючи перевагу рівній структурі. Коли ми розглядатимемо призначення значень субшаблонам, ми побачимо, як значення називаються, використовуючи структуру дерева. ## Видалення стандартного ключа {#deleting-a-default-key} Якщо вам потрібно видалити ключ зі стандартних значень, ви можете перевизначити значення ключа як `null`, у цьому випадку Helm видалить ключ з злиття перевизначених значень. Наприклад, стабільний шаблон Drupal дозволяє налаштовувати перевірку життєздатності (liveness probe) у випадку, якщо ви налаштовуєте власний образ. Ось стандартні значення: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` Якщо ви спробуєте перевизначити обробник livenessProbe на `exec` замість `httpGet`, використовуючи `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm обʼєднає стандартні ключі разом з перевизначеними, що дасть нам наступний YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` Однак Kubernetes тоді видасть помилку, оскільки не можна оголошувати більше одного обробника livenessProbe. Щоб це обійти, ви можете інструктувати Helm видалити `livenessProbe.httpGet`, встановивши його значення в null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` На цьому етапі ми розглянули кілька вбудованих обʼєктів і використали їх для вставки інформації в шаблон. Тепер ми розглянемо інший аспект шаблонного механізму: функції та конвеєри. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: Змінні description: Використання змінних у шаблонах. sidebar_position: 8 --- Маючи функції, конвеєри, обʼєкти та структури управління, ми можемо перейти до однієї з основних ідей у багатьох мовах програмування: змінних. У шаблонах вони використовуються рідше. Але ми побачимо, як їх можна використовувати для спрощення коду та для кращого використання `with` і `range`. У попередньому прикладі ми побачили, що цей код не працює: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` не знаходиться в межах області видимості, обмеженої блоком `with`. Один зі способів обійти проблеми з областю видимості — присвоїти обʼєкти змінним, до яких можна отримати доступ без врахування поточної області видимості. У шаблонах Helm змінна є іменованим посиланням на інший обʼєкт. Вона має формат `$name`. Змінні присвоюються за допомогою спеціального оператора присвоєння: `:=`. Ми можемо переписати вищезазначене, використовуючи змінну для `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Зверніть увагу, що перед тим як почати блок `with`, ми присвоюємо `$relname := .Release.Name`. Тепер всередині блоку `with` змінна `$relname` все ще вказує на імʼя релізу. Запуск цього коду дасть наступний результат: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Змінні особливо корисні в циклах `range`. Їх можна використовувати для спископодібних обʼєктів, щоб захопити як індекс, так і значення: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Зверніть увагу, що `range` йде першим, потім змінні, потім оператор присвоєння, а потім список. Це присвоїть ціле число (починаючи з нуля) змінній `$index` і значення змінній `$topping`. Запуск цього коду дасть: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` Для структур даних, які мають як ключ, так і значення, ми можемо використовувати `range`, щоб отримати обидва. Наприклад, ми можемо перебрати `.Values.favorite` таким чином: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Тепер на першій ітерації `$key` буде `drink`, а `$val` буде `coffee`, а на другій `$key` буде `food`, а `$val` буде `pizza`. Запуск цього коду створить: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Змінні зазвичай не є "глобальними". Вони мають область видимості в межах блоку, в якому вони оголошені. Раніше ми присвоїли `$relname` на верхньому рівні шаблону. Ця змінна буде видима для всього шаблону. Але в нашому останньому прикладі змінні `$key` і `$val` будуть видимі лише всередині блоку `{{ range... }}{{ end }}`. Однак є одна змінна, яка завжди є глобальною — `$`, ця змінна завжди буде вказувати на кореневий контекст. Це може бути дуже корисно, коли ви перебираєте в діапазоні і вам потрібно знати імʼя релізу чарту. Приклад, що ілюструє це: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Багато шаблонів Helm використовували б `.` тут, але це не спрацює, # однак `$` спрацює тут app.kubernetes.io/name: {{ template "fullname" $ }} # Я не можу звертатися до .Chart.Name, але можу використовувати $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Значення з appVersion у Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` До цього часу ми розглянули лише один шаблон, оголошений в одному файлі. Але одна з потужних можливостей мови шаблонів Helm — це можливість оголошувати кілька шаблонів і використовувати їх разом. Ми перейдемо до цього в наступному розділі. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Наступні кроки description: "Підсумок\_— корисні вказівки на іншу документацію, яка може допомогти вам." sidebar_position: 14 --- Цей посібник має на меті надати вам, розробнику чартів, глибоке розуміння того, як використовувати мову шаблонів Helm. Посібник зосереджений на технічних аспектах розробки шаблонів. Але є багато аспектів практичного щоденного розроблення чартів, які цей посібник не охоплює. Ось кілька корисних вказівок на іншу документацію, яка допоможе вам у створенні нових чартів: - CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є незамінним джерелом чартів. - [Документація Kubernetes](https://kubernetes.io/docs/home/) надає детальні приклади різних ресурсів, які ви можете використовувати, від ConfigMaps і Secrets до DaemonSets і Deployments. - Посібник [Чарти Helm](/topics/charts.md) пояснює робочий процес використання чартів. - Посібник [Хуки чартів Helm](/topics/charts_hooks.md) пояснює, як створювати хук для життєвого циклу. - Стаття [Поради та підказки для розробки чартів](/howto/charts_tips_and_tricks.md) надає кілька корисних порад для написання чартів. - Документація [Sprig](https://github.com/Masterminds/sprig) описує більше ніж шістдесят функцій шаблонів. - Документація [Go templates](https://godoc.org/text/template) детально пояснює синтаксис шаблонів. - Інструмент [Schelm](https://github.com/databus23/schelm) є корисною утилітою для налагодження чартів. Іноді легше поставити кілька запитань і отримати відповіді від досвідчених розробників. Найкраще місце для цього — канали Helm у [Slack Kubernetes](https://kubernetes.slack.com): - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Нарешті, якщо ви знайдете помилки або упущення в цьому документі, хочете запропонувати новий контент або хотіли б внести свій внесок, відвідайте [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Додаток: Техніки YAML" description: Ближчий погляд на специфікацію YAML та її застосування до Helm. sidebar_position: 15 --- Більшість цього посібника зосереджена на написанні мови шаблонів. Тут ми розглянемо формат YAML. YAML має кілька корисних функцій, які ми, як автори шаблонів, можемо використовувати для того, щоб зробити наші шаблони менш схильними до помилок і легшими для читання. ## Масиви та Колекції {#scalars-and-collections} Згідно зі [специфікацією YAML](https://yaml.org/spec/1.2/spec.html), існують два типи колекцій та багато типів скалярів. Два типи колекцій — це map та послідовності: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Скалярні значення – це окремі значення (на відміну від колекцій). ### Типи скалярів у YAML {#scalar-types-in-yaml} У діалекті YAML Helm тип даних значення визначається складним набором правил, включаючи схему Kubernetes для ресурсних визначень. Але при визначенні типів, наступні правила зазвичай є правильними. Якщо ціле число або десяткове число є без лапок, це зазвичай трактуватиметься як числовий тип: ```yaml count: 1 size: 2.34 ``` Але якщо вони укладені в лапки, вони трактуються як рядки: ```yaml count: "1" # <-- рядок, не int size: '2.34' # <-- рядок, не float ``` Те ж саме стосується булевих значень: ```yaml isGood: true # bool answer: "true" # рядок ``` Слово для пустого значення — `null` (не `nil`). Зверніть увагу, що `port: "80"` є дійсним YAML і пройде через рушій шаблонів та парсер YAML, але зазнає невдачі, якщо Kubernetes очікує, що `port` буде цілим числом. У деяких випадках ви можете примусово визначити певний тип, використовуючи теґи вузлів YAML: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` У наведеному вище прикладі `!!str` говорить парсеру, що `age` є рядком, навіть якщо він виглядає як int. А `port` трактуватиметься як int, навіть якщо він укладений в лапки. ## Рядки в YAML {#strings-in-yaml} Більшість даних, які ми розміщуємо в документах YAML, є рядками. YAML має кілька способів представлення рядків. Цей розділ пояснює способи та демонструє, як використовувати деякі з них. Існують три "вбудовані" способи оголошення рядка: ```yaml way1: просто слова way2: "рядки в подвійних лапках" way3: 'рядки в одинарних лапках' ``` Всі вбудовані стилі мають бути в одному рядку. - Невкладені слова не мають лапок і не екрановані. Тому потрібно бути обережним із символами, які ви використовуєте. - Рядки в подвійних лапках можуть мати спеціальні символи екрановані за допомогою `\`. Наприклад, `"\"Hello\", she said"`. Можна екранувати розриви рядка за допомогою `\n`. - Рядки в одинарних лапках є "літеральними" рядками та не використовують `\` для екранування символів. Єдине екранування — це `''`, яке декодується як один символ `'`. Окрім рядків в один рядок, можна оголосити багаторядкові рядки: ```yaml coffee: | Latte Cappuccino Espresso ``` Вищенаведене буде трактувати значення `coffee` як один рядок, еквівалентний `Latte\nCappuccino\nEspresso\n`. Зверніть увагу, що перший рядок після `|` повинен мати вірний відступ. Тому ми можемо зламати приклад вище, зробивши це: ```yaml coffee: | Latte Cappuccino Espresso ``` Оскільки `Latte` має неправильний відступ, ми отримаємо помилку на кшталт: ```none Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` У шаблонах іноді безпечніше помістити несправжній "перший рядок" у багаторядковому документі лише для захисту від цієї помилки: ```yaml coffee: | # Коментований перший рядок Latte Cappuccino Espresso ``` Зауважте, що яким би не був цей перший рядок, його буде збережено у виведенні рядка. Тому, якщо ви, наприклад, використовуєте цю техніку для вливання вмісту файлу в ConfigMap, коментар має бути типу, який очікується тим, хто читає цей запис. ### Керування пробілами в багаторядкових рядках {#controlling-spaces-in-multiline-strings} У наведеному вище прикладі ми використовували `|`, щоб позначити багаторядковий рядок. Але зверніть увагу, що вміст нашого рядка завершувався з кінцевим `\n`. Якщо ми хочемо, щоб обробник YAML видалив кінцевий перенос рядка, ми можемо додати `-` після `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Тепер значення `coffee` буде: `Latte\nCappuccino\nEspresso` (без кінцевого `\n`). В інших випадках ми можемо захотіти зберегти весь кінцевий пробіл. Ми можемо зробити це за допомогою позначення `|+`: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Тепер значення `coffee` буде `Latte\nCappuccino\nEspresso\n\n\n`. Відступи всередині текстового блоку зберігаються, що призводить до збереження переносу рядків: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` У наведеному вище випадку значення `coffee` буде `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Відступи та шаблони {#indenting-and-templates} Коли ви пишете шаблони, ви можете захотіти вставити вміст файлу в шаблон. Як ми бачили в попередніх розділах, є два способи зробити це: - Використовуйте `{{ .Files.Get "FILENAME" }}`, щоб отримати вміст файлу в чартах. - Використовуйте `{{ include "TEMPLATE" . }}`, щоб відобразити шаблон, а потім вставити його вміст у чарти. Коли ви вставляєте файли в YAML, корисно розуміти правила багаторядкових рядків. Найчастіше найпростіший спосіб вставити статичний файл — зробити щось на кшталт цього: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Зверніть увагу, як ми виконуємо відступ вище: `indent 2` говорить шаблонному двигуну відступити кожен рядок у "myfile.txt" на два пробіли. Зверніть увагу, що ми не відступаємо сам рядок шаблону. Це тому, що якщо ми це зробимо, вміст файлу першого рядка буде відступлений двічі. ### Згортання багаторядкових рядків {#folded-multi-line-strings} Іноді вам потрібно представити рядок у вашому YAML на кількох рядках, але ви хочете, щоб він трактувався як один довгий рядок під час інтерпретації. Це називається "згортанням". Щоб оголосити згортання блоку, використовуйте `>` замість `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` Значення `coffee` буде `Latte Cappuccino Espresso\n`. Зверніть увагу, що всі, крім останнього переносу рядка, будуть перетворені на пробіли. Ви можете поєднувати контроль пробілів із позначкою згортання тексту, тому `>-` замінить або обрізає всі нові рядки. Зверніть увагу, що в згортанні синтаксису відступ тексту призведе до збереження рядків. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` Наведене вище створить `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Зверніть увагу, що і пробіли, і нові рядки все ще присутні. ## Вбудовування кількох документів в один файл {#embedding-multiple-documents-in-one-file} Можливо розмістити більше одного YAML-документа в одному файлі. Це робиться шляхом префіксації нового документа `---` і закінчення документа `...` ```yaml --- document: 1 ... --- document: 2 ... ``` У багатьох випадках можна опустити `---` або `...`. Деякі файли в Helm не можуть містити більше одного документа. Якщо, наприклад, у файлі `values.yaml` надано більше одного документа, буде використано лише перший. Однак файли шаблонів можуть мати більше одного документа. Коли це трапляється, файл (і всі його документи) обробляється як один обʼєкт під час рендерингу шаблонів. Але потім отриманий YAML розділяється на кілька документів, перш ніж він буде переданий Kubernetes. Ми рекомендуємо використовувати кілька документів у файлі лише в разі крайньої потреби. Наявність кількох документів у файлі може ускладнити налагодження. ## YAML є надмножиною JSON {#yaml-is-a-superset-of-json} Оскільки YAML є надмножиною JSON, будь-який дійсний JSON-документ _повинен_ бути дійсним YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` Вищенаведене є іншим способом представлення цього: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` І їх можна змішувати (з обережністю): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` Усі три повинні перетворюватись в однакове внутрішнє подання. Це означає, що файли, такі як `values.yaml`, можуть містити дані JSON, але Helm не трактує розширення файлу `.json` як дійсний суфікс. ## Якорі YAML {#yaml-anchors} Специфікація YAML надає спосіб зберігати посилання на значення і пізніше посилатися на це значення за допомогою посилання. YAML називає це "якорінням": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` У наведеному вище прикладі `&favoriteCoffee` встановлює посилання на `Cappuccino`. Пізніше це посилання використовується як `*favoriteCoffee`. Таким чином, `coffees` стає `Latte, Cappuccino, Espresso`. Хоча є кілька випадків, коли якорі корисні, існує один аспект їх використання, який може спричинити тонкі помилки: під час першого використання YAML посилання розширюється і потім видаляється. Тому, якщо ми декодуємо і потім повторно кодуємо приклад вище, отриманий YAML буде таким: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Оскільки Helm і Kubernetes часто читають, змінюють і потім переписують файли YAML, якорі будуть втрачені. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Зміни з часів Helm 2 sidebar_position: 1 --- ## Зміни з часів Helm 2 {#changes-since-helm-2} Ось вичерпний список усіх основних змін, введених у Helm 3. ### Видалення Tiller {#removal-of-tiller} Під час циклу розробки Helm 2 ми впровадили Tiller. Tiller відігравав важливу роль для команд, що працюють на спільному кластері — він дозволяв кільком різним операторам взаємодіяти з одним і тим же набором релізів. З увімкненим контролем доступу на основі ролей (RBAC) у Kubernetes 1.6, контроль доступу до Tiller у випадках операційної діяльності став важчим у керуванні. Через велику кількість можливих політик безпеки наше ставлення полягало в тому, щоб забезпечити стандартну дозвільну конфігурацію. Це дозволяло новачкам почати експериментувати з Helm і Kubernetes без необхідності заглиблюватися в керування безпекою. На жаль, ця дозвільна конфігурація могла надавати користувачеві широкий спектр дозволів, які йому не були надані. DevOps і SRE доводилося вивчати додаткові оперативні кроки при встановленні Tiller в мультиорендний кластер. Після того як ми дізналися, як члени спільноти використовують Helm у певних сценаріях, ми виявили, що система управління релізами Tiller не має покладатися на оператора в кластері для підтримки стану або дії як центральний центр інформації про релізи Helm. Натомість ми могли просто отримувати інформацію з сервера API Kubernetes, рендерити чарти на стороні клієнта і зберігати запис про установку в Kubernetes. Основна мета Tiller могла бути досягнута без Tiller, тому одне з перших рішень, яке ми прийняли щодо Helm 3, полягало в повному видаленні Tiller. З відсутністю Tiller модель безпеки Helm радикально спростилася. Helm 3 тепер підтримує всі сучасні функції безпеки, ідентифікації та авторизації сучасного Kubernetes. Дозволи Helm оцінюються за допомогою вашого [файлу kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Адміністратори кластерів можуть обмежити дозволи користувачів на будь-якому рівні деталізації, який вони вважають за потрібний. Релізи все ще записуються в кластері, а решта функціональності Helm залишається. ### Поліпшена стратегія оновлення: 3-сторонні стратегічні зливання патчів {#improved-upgrade-strategy-3-way-strategic-merge-patches} Helm 2 використовував двостороннє стратегічне злиття патчів. Під час оновлення він порівнював маніфест останньої версії чарту з маніфестом запропонованого чарту (той, що надається під час `helm upgrade`). Він порівнював різницю між цими двома чартами, щоб визначити, які зміни потрібно застосувати до ресурсів у Kubernetes. Якщо зміни були внесені до кластера поза планом (наприклад, під час `kubectl edit`), ці зміни не враховувалися. Це призводило до того, що ресурси не могли повернутися до попереднього стану: оскільки Helm розглядав тільки останній застосований маніфест чарту як поточний стан, якщо у стані чарту не було змін, поточний стан залишався незмінним. У Helm 3 тепер використовується тристороннє стратегічне злиття патчів. Helm враховує старий маніфест, його поточний стан і новий маніфест при генерації патчу. #### Приклади {#examples} Розглянемо кілька поширених прикладів того, на що впливають ці зміни. ##### Повернення до попереднього стану, де поточний стан змінився {#rolling-back-where-live-state-has-changed} Ваша команда щойно розгорнула свій застосунок для операційної діяльності на Kubernetes за допомогою Helm. Чарт містить обʼєкт Deployment, де кількість реплік встановлено на три: ```console $ helm install myapp ./myapp ``` Новий розробник приєднується до команди. В перший день, спостерігаючи за операційним кластером, трапляється жахлива аварія, коли кава проливається на клавіатуру, в наслідок чого `kubectl scale` згортає deployment з трьох реплік до нуля. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Ще один розробник у вашій команді помічає, що операційний сайт не працює, і вирішує повернути реліз до попереднього стану: ```console $ helm rollback myapp ``` Що відбувається? У Helm 2 буде згенеровано патч, порівнюючи старий маніфест з новим маніфестом. Оскільки це повернення, це той самий маніфест. Helm визначає, що немає нічого для зміни, оскільки немає різниці між старим і новим маніфестом. Кількість реплік продовжує залишатися на нулі. Паніка зростає. У Helm 3 патч генерується з використанням старого маніфесту, поточного стану і нового маніфесту. Helm визнає, що старий стан був на трьох, поточний стан — на нулі, а новий маніфест хоче змінити його назад на три, тому він генерує патч, щоб змінити стан назад на три екземпляри. ##### Оновлення, де поточний стан змінився {#updating-where-live-state-has-changed} Багато сервісних мереж та інших застосунків на основі контролерів вбудовують дані в обʼєкти Kubernetes. Це може бути щось на кшталт sidecar, міток або іншої інформації. Раніше, якщо у вас був даний маніфест, створений з чарту: ```yaml containers: - name: server image: nginx:2.0.0 ``` А поточний стан був змінений іншим застосунком на ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Тепер ви хочете оновити теґ образу `nginx` до `2.1.0`. Отже, ви оновлюєте чарт до маніфесту: ```yaml containers: - name: server image: nginx:2.1.0 ``` Що відбувається? У Helm 2 Helm генерує патч обʼєкта `containers` між старим маніфестом і новим маніфестом. Поточний стан кластера не враховується під час генерації патчу. Поточний стан кластера модифікується, щоб виглядати наступним чином: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Виникає більше паніки. У Helm 3 Helm генерує патч обʼєкта `containers` між старим маніфестом, поточним станом і новим маніфестом. Він помічає, що новий маніфест змінює теґ образу на `2.1.0`, але поточний стан містить контейнер sidecar. Поточний стан кластера модифікується, щоб виглядати наступним чином: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Імена релізів тепер обмежені простором імен {#release-names-are-now-scoped-to-the-namespace} З видаленням Tiller інформація про кожен реліз повинна була десь зберігатися. У Helm 2 вона зберігалась в тому ж просторі імен, що й Tiller. Це означало, що після використання імені для одного релізу жоден інший реліз не міг використовувати те ж саме імʼя, навіть якщо він був розгорнутий в іншому просторі імен. У Helm 3 інформація про конкретний реліз тепер зберігається в тому ж просторі імен, що і сам реліз. Це означає, що користувачі тепер можуть робити `helm install wordpress stable/wordpress` у двох окремих просторах імен, і кожен з них можна буде переглядати за допомогою `helm list`, змінивши контекст простору імен (наприклад, `helm list --namespace foo`). З цим більшим узгодженням з нативними просторами імен кластера команда `helm list` більше не стандартно виводить перелік всіх релізів. Натомість вона буде виводити лише релізи в просторі імен вашого поточного контексту Kubernetes (тобто простір імен, що відображається, коли ви виконуєте `kubectl config view --minify`). Це також означає, що ви повинні вказати прапорець `--all-namespaces` для `helm list`, щоб отримати поведінку, подібну до Helm 2. ### Secrets як стандартний драйвер зберігання {#secrets-as-the-default-storage-driver} У Helm 3 Secrets тепер використовуються як [стандартний драйвер зберігання](/topics/advanced.md#storage-backends). Helm 2 стандартно використовував ConfigMaps для зберігання інформації про релізи. У Helm 2.7.0 було впроваджено новий бекенд зберігання, що використовує Secrets для зберігання інформації про релізи, і тепер це є стандартним починаючи з Helm 3. Перехід на Secrets як стандарт для Helm 3 забезпечує додаткову безпеку у захисті чарту разом з випуском шифрування Secrets у Kubernetes. [Шифрування секретів в спокої](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) стало доступним як альфа функція в Kubernetes 1.7 і стало стабільним починаючи з Kubernetes 1.13. Це дозволяє користувачам шифрувати метадані релізів Helm в спокої, і це є хорошою відправною точкою, яку можна пізніше розширити на використання чогось на кшталт Vault. ### Зміни в шляху Go import {#go-import-path-changes} У Helm 3 шлях імпорту Go був змінений з `k8s.io/helm` на `helm.sh/helm/v3`. Якщо ви плануєте оновити бібліотеки клієнтів Go для Helm 3, переконайтеся, що змінюєте свої шляхи імпорту. ### Можливості {#capabilities} Вбудований обʼєкт `.Capabilities`, доступний під час етапу рендерингу, був спрощений. [Вбудовані Обʼєкти](/chart_template_guide/builtin_objects.md) ### Перевірка значень чарту з JSONSchema {#validating-chart-values-with-jsonschema} Тепер можна накласти JSON Schema на значення чарту. Це забезпечує, що значення, надані користувачем, відповідають схемі, визначеній автором чарту, що забезпечує кращу звітність про помилки, коли користувач надає неправильний набір значень для чарту. Перевірка відбувається при виконанні будь-якої з наступних команд: * `helm install` * `helm upgrade` * `helm template` * `helm lint` Дивіться документацію про [Файли схем](/topics/charts.md#schema-files) для додаткової інформації. ### Консолідація `requirements.yaml` в `Chart.yaml` {#consolidation-of-requirementsyaml-into-chartyaml} Система управління залежностями чартів перейшла з `requirements.yaml` та `requirements.lock` у `Chart.yaml` та `Chart.lock`. Рекомендується, щоб нові чарти для Helm 3 використовували новий формат. Тим не менш, Helm 3 все ще розуміє API версію 1 (`v1`) і буде завантажувати наявні файли `requirements.yaml`. У Helm 2 файл `requirements.yaml` виглядав так: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` У Helm 3 залежність виражена так само, але тепер у вашому `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Чарти все ще завантажуються і розміщуються в теці `charts/`, тому субчарти, які знаходяться в теці `charts/`, будуть продовжувати працювати без змін. ### Імʼя (або `--generate-name`) тепер необхідне при встановленні {#name-or---generate-name-is-now-required-on-install} У Helm 2, якщо імʼя не було надане, імʼя автоматично генерувалося. В операційній експлуатації це виявилося більше проблемою, ніж корисною функцією. У Helm 3 Helm видасть помилку, якщо імʼя не буде надано при `helm install`. Для тих, хто все ще бажає автоматичне генерування імені, можна використовувати прапорець `--generate-name`, щоб створити його. ### Публікація чартів в OCI реєстрах {#publishing-charts-to-oci-registries} Це експериментальна функція, введена в Helm 3. Щоб використовувати, встановіть змінну середовища `HELM_EXPERIMENTAL_OCI=1`. На високому рівні, репозиторій чартів — це місце, де чарти можуть зберігатися та ними можна обмінюватися. Клієнт Helm пакує і відправляє чарт в репозиторій чартів. Простими словами, репозиторій чартів — це базовий HTTP сервер, який містить файл `index.yaml` і деякі упаковані чарти. Хоча є кілька переваг в API репозиторію чартів, що відповідає найосновнішим вимогам зберігання, деякі недоліки почали виявлятися: * Репозиторії чартів мають великі труднощі з абстрагуванням більшості реалізацій безпеки, необхідних у виробничому середовищі. Наявність стандартного API для автентифікації та авторизації є дуже важливим в операційних сценаріях. * Інструменти перевірки походження чартів Helm, що використовуються для підписання та перевірки цілісності та походження чарту, є необовʼязковою частиною процесу публікації чарту. * У багатокористувацьких сценаріях один і той же чарт може бути завантажений іншим користувачем, що призводить до двократних витрат на зберігання того ж контенту. Розумніші репозиторії чартів були спроєктовані для обробки цього, але це не є частиною офіційної специфікації. * Використання одного індексного файлу для пошуку, інформації про метадані та отримання чартів ускладнило проєктування у безпечних багатокористувацьких реалізаціях. Проєкт Docker Distribution (також відомий як Docker Registry v2) є спадкоємцем проєкту Docker Registry. Багато великих хмарних постачальників мають промислову пропозицію проєкту Distribution, і з такою кількістю постачальників, які пропонують один і той же продукт, проєкт Distribution отримав багато років удосконалення, кращих практик безпеки та випробувань у бою. Будь ласка, ознайомтеся з `helm help chart` та `helm help registry` для отримання додаткової інформації про те, як упакувати чарт і опублікувати його в Docker реєстрі. Більше інформації можна знайти на [цій сторінці](/topics/registries.md). ### Видалення `helm serve` {#removal-of-helm-serve} `helm serve` запускав локальний репозиторій чартів на вашій машині для цілей розробки. Проте, він не отримав великого визнання як інструмент для розробки та мав численні проблеми з його дизайном. Зрештою, ми вирішили видалити його та винести у втулок. Для досвіду подібного до `helm serve`, подивіться на локальний файловий системний варіант у [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) та втулок [servecm](https://github.com/jdolitsky/helm-servecm). ### Підтримка бібліотечних чартів {#library-chart-support} Helm 3 підтримує клас чартів, що називається “бібліотечний чарт”. Це чарт, який використовується іншими чартами, але не створює жодних артефактів релізів самостійно. Шаблони бібліотечного чарту можуть лише оголошувати елементи `define`. Глобально скопійовані не-`define` вмісти просто ігноруються. Це дозволяє користувачам повторно використовувати та ділитися фрагментами коду, які можна використовувати в багатьох чартах, уникати повторюваності та зберігати чарт [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Бібліотечні чарти оголошуються в директиві залежностей у Chart.yaml, і їх можна встановлювати та керувати як будь-яким іншим чартом. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` Ми дуже раді бачити сценарії використання цієї функції для розробників чартів, а також будь-які найкращі практики, які виникають від споживання бібліотечних чартів. ### Зміна apiVersion Chart.yaml {#chartyaml-apiversion-bump} З впровадженням підтримки бібліотечних чартів та консолідацією `requirements.yaml` в `Chart.yaml`, клієнти, які розуміли формат пакетів Helm 2, не зможуть зрозуміти ці нові функції. Тому, ми підняли версію apiVersion у Chart.yaml з `v1` на `v2`. `helm create` тепер створює чарт з використанням цього нового формату, тому стандартний apiVersion був піднятий там також. Клієнти, які бажають підтримувати обидві версії чартів Helm, повинні перевіряти поле `apiVersion` у Chart.yaml, щоб зрозуміти, як розібрати формат пакету. ### Підтримка XDG Base Directory {#xdg-base-directory-support} [Специфікація XDG Base Directory](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) є портативним стандартом, що визначає, де слід зберігати конфігурації, дані та кешовані файли у файловій системі. У Helm 2 Helm зберігав всю цю інформацію в `~/.helm` (відомій як `helm home`), що можна було змінити, встановивши змінну середовища `$HELM_HOME`, або використовуючи глобальний прапорець `--home`. У Helm 3 тепер Helm поважає наступні змінні середовища відповідно до специфікації XDG Base Directory: * `$XDG_CACHE_HOME` * `$XDG_CONFIG_HOME` * `$XDG_DATA_HOME` Втулки Helm все ще отримують `$HELM_HOME` як псевдонім до `$XDG_DATA_HOME` для зворотної сумісності з втулками, які використовують `$HELM_HOME` як середовище для тимчасових даних. Також кілька нових змінних середовища передаються в середовище втулка для врахування цієї зміни: * `$HELM_PATH_CACHE` для кешованого шляху * `$HELM_PATH_CONFIG` для конфігураційного шляху * `$HELM_PATH_DATA` для шляхів даних Втулки Helm, які прагнуть підтримувати Helm 3, повинні розглянути можливість використання цих нових змінних середовища замість старих. ### Перейменування команд CLI {#cli-command-renames} Щоб краще узгодити термінологію з іншими менеджерами пакетів, `helm delete` було перейменовано на `helm uninstall`. `helm delete` все ще зберігається як псевдонім до `helm uninstall`, тож можна використовувати будь-яку форму. У Helm 2, щоб очистити лог релізів, потрібно було вказати прапорець `--purge`. Ця функціональність тепер є стандартно увімкненою. Щоб зберегти попередню поведінку, використовуйте `helm uninstall --keep-history`. Крім того, кілька інших команд були перейменовані для узгодження з тією ж термінологією: * `helm inspect` -> `helm show` * `helm fetch` -> `helm pull` Ці команди також зберегли старі дієслова як псевдоніми, тому ви можете продовжувати використовувати їх у будь-якому вигляді. ### Автоматичне створення просторів імен {#automatically-creating-namespaces} При створенні релізу в просторі імен, який не існує, Helm 2 створював простір імен. Helm 3 дотримується поведінки іншого інструменту Kubernetes і повертає помилку, якщо простір імен не існує. Helm 3 створить простір імен, якщо ви явно вкажете прапорець `--create-namespace`. ### Що сталося з .Chart.ApiVersion? {#what-happened-to-chartapiversion} Helm дотримується звичайної домовленості CamelCasing, яка передбачає використання великої літери для абревіатури. Ми зробили це і в іншому коді, наприклад, у `.Capabilities.APIVersions.Has`. У Helm v3 ми виправили `.Chart.ApiVersion`, перейменувавши його на `.Chart.APIVersion`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: Часті питання sidebar_position: 9 --- # Часті питання > Цей розділ надає допомогу з найпоширенішими питаннями. **Ми будемо вдячні за вашу допомогу** у покращенні цього документу. Щоб додати, виправити або видалити інформацію, [створіть тікет](https://github.com/helm/helm-www/issues) або надішліть нам пул-реквест. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: Встановлення sidebar_position: 2 --- ## Встановлення {#installing} ### Чому немає рідних пакетів Helm для Fedora та інших дистрибутивів Linux? {#why-aren-t-there-native-packages-of-helm-for-fedora-and-other-linux-distros} Проєкт Helm не підтримує пакети для операційних систем та середовищ. Спільнота Helm може надати рідні пакети, і якщо проєкт Helm дізнається про них, вони будуть вказані. Саме так почалася та була вказана формула Homebrew. Якщо ви зацікавлені в підтримці пакета, ми будемо раді цьому. ### Чому ви надаєте скрипт `curl ...|bash`? {#why-do-you-provide-a-curl-bash-script} У нашому репозиторії є скрипт (`scripts/get-helm-3`), який можна виконати як `curl ..|bash` скрипт. Передача захищена HTTPS, а скрипт проводить деякий аудит пакетів, які він завантажує. Проте скрипт має всі звичайні небезпеки будь-якого скрипта оболонки. Ми надаємо його, тому що це корисно, але ми радимо користувачам ретельно ознайомитися зі скриптом перед виконанням. Те, що ми насправді хотіли б, — це кращі упаковані релізи Helm. ### Як мені помістити файли клієнта Helm в інше місце, не стандартне місце? {#how-do-i-put-the-helm-client-files-somewhere-other-than-their-defaults} Helm використовує структуру XDG для зберігання файлів. Існують змінні середовища, які ви можете використовувати для зміни цих місць: - `$XDG_CACHE_HOME`: встановіть альтернативне місце для зберігання кешованих файлів. - `$XDG_CONFIG_HOME`: встановіть альтернативне місце для зберігання конфігурацій Helm. - `$XDG_DATA_HOME`: встановіть альтернативне місце для зберігання даних Helm. Зверніть увагу, що якщо у вас є наявні репозиторії, вам доведеться повторно їх додати за допомогою `helm repo add...`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: Усунення несправностей sidebar_position: 4 --- ## Усунення несправностей {#troubleshooting} ### Я отримую попередження про "Не вдалося отримати оновлення з репозиторію чартів 'stable'" {#i-am-getting-a-warning-about-unable-to-get-an-update-from-the-stable-chart-repository} Запустіть `helm repo list`. Якщо він показує ваш репозиторій `stable`, який вказує на URL `storage.googleapis.com`, вам потрібно оновити цей репозиторій. 13 листопада 2020 року репозиторій Helm Charts [перестав підтримуватися](https://github.com/helm/charts#deprecation-timeline) після річного періоду відмови від обслуговування. Архів доступний за адресою `https://charts.helm.sh/stable`, але більше не отримуватиме оновлень. Ви можете виконати наступну команду для виправлення репозиторію: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Те ж саме стосується репозиторію `incubator`, для якого є архів за адресою https://charts.helm.sh/incubator. Ви можете виконати наступну команду для його відновлення: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Я отримую попередження 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' {#i-am-getting-the-warning-warning-kubernetes-chartsstoragegoogleapiscom-is-deprecated-for-stable-and-will-be-deleted-nov-13-2020} Старий репозиторій чартів Google було замінено новим репозиторієм Helm чартів. Запустіть наступну команду для остаточного виправлення цього: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` Якщо ви отримуєте подібну помилку для `incubator`, виконайте цю команду: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### Коли я додаю репозиторій Helm, я отримую помилку 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' {#when-i-add-a-helm-repo-i-get-the-error-error-repo-httpskubernetes-chartsstoragegoogleapiscom-is-no-longer-available} Репозиторії чартів Helm більше не підтримуються після [річного періоду відмови від обслуговування](https://github.com/helm/charts#deprecation-timeline). Архіви цих репозиторіїв доступні за адресами `https://charts.helm.sh/stable` та `https://charts.helm.sh/incubator`, але більше не отримуватимуть оновлень. Команда `helm repo add` не дозволяє додати старі URL-адреси, якщо не вказати `--use-deprecated-repos`. ### На GKE (Google Container Engine) я отримую "No SSH tunnels currently open" {#on-gke-google-container-engine-i-get-no-ssh-tunnels-currently-open} ```none Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Ще одна версія повідомлення про помилку: ```none Unable to connect to the server: x509: certificate signed by unknown authority ``` Проблема в тому, що ваш локальний файл конфігурації Kubernetes повинен містити правильні облікові дані. Коли ви створюєте кластер на GKE, він надає вам облікові дані, включаючи SSL сертифікати та центри сертифікації. Їх потрібно зберігати у файлі конфігурації Kubernetes (стандартно: `~/.kube/config`), щоб `kubectl` та `helm` могли їх використовувати. ### Після міграції з Helm 2 команда `helm list` показує лише деякі (або жодного) мої релізи {#after-migration-from-helm-2-helm-list-shows-only-some-or-none-of-my-releases} Можливо, ви пропустили те, що Helm 3 тепер використовує простори імен кластера для визначення релізів. Це означає, що для всіх команд, що посилаються на реліз, ви повинні або: * покластися на поточний простір імен в активному контексті kubernetes (як описано командою `kubectl config view --minify`), * вказати правильний простір імен, використовуючи прапорець `--namespace`/`-n`, або * для команди `helm list`, вказати прапорець `--all-namespaces`/`-A`. Це стосується `helm ls`, `helm uninstall` та всіх інших команд `helm`, що посилаються на реліз. ### На macOS звертається до файлу `/etc/.mdns_debug`. Чому? {#on-macos-the-file-etcmdns_debug-is-accessed-why} Ми знаємо про випадок на macOS, коли Helm намагається звернутися до файлу з назвою `/etc/.mdns_debug`. Якщо файл існує, Helm тримає дескриптор файлу відкритим під час виконання. Це викликано бібліотекою MDNS macOS. Вона намагається завантажити цей файл для читання налаштувань відладки (якщо увімкнено). Дескриптор файлу, ймовірно, не повинен залишатися відкритим, і ця проблема була передана Apple. Однак це macOS, а не Helm, викликає цю поведінку. Якщо ви не хочете, щоб Helm завантажував цей файл, ви можете спробувати скомпілювати Helm як статичну бібліотеку, яка не використовує стек мережі хосту. Це збільшить розмір бінарного файлу Helm, але завадить відкриттю файлу. Цю проблему спочатку було позначено як потенційну проблему безпеки. Але з того часу було визначено, що ця поведінка не має жодних недоліків або вразливостей. ### helm repo add не вдається, хоча раніше працювало {#helm-repo-add-fails-when-it-used-to-work} У helm 3.3.1 та раніше команда `helm repo add ` не видає жодного виходу, якщо ви намагаєтеся додати репозиторій, який вже існує. Прапорець `--no-update` викликав помилку, якщо репозиторій вже був зареєстрований. У helm 3.3.2 та пізніших версіях спроба додати наявний репозиторій викличе помилку: `Error: repository name (reponame) already exists, please specify a different name` Тепер стандартна поведінка змінилася. Прапорець `--no-update` тепер ігнорується, а якщо ви хочете замінити (перезаписати) наявний репозиторій, ви можете використовувати `--force-update`. Це повʼязано з переломною зміною для виправлення проблеми безпеки, як пояснено в [замітках про реліз Helm 3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2). ### Увімкнення ведення логів клієнта Kubernetes {#enabling-kubernetes-client-logging} Друк повідомлень логу для відладки клієнта Kubernetes можна увімкнути за допомогою прапорців [klog](https://pkg.go.dev/k8s.io/klog). Використання прапорця `-v` для налаштування рівня деталізації буде достатнім для більшості випадків. Наприклад: ```shell helm list -v 6 ``` ### Встановлення Tiller припинило працювати і доступ заборонено {#installing-tiller-stopped-working-and-access-is-denied} Релізи Helm раніше були доступні за адресою . Як пояснюється в ["Announcing get.helm.sh"](/blog/get-helm-sh/), офіційне місце розташування змінилося у червні 2019 року. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) робить всі старі образи Tiller доступними. Якщо ви намагаєтеся завантажити старі версії Helm з кошику зберігання, який ви використовували раніше, ви можете виявити, що вони відсутні: ```none AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [Місце розташування старих образів Tiller](https://gcr.io/kubernetes-helm/tiller) розпочало видалення образів у серпні 2021 року. Ми зробили ці образи доступними за адресою [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller). Наприклад, щоб завантажити версію v2.17.0, замініть: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` на: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` Щоб ініціалізувати Helm v2.17.0: `helm init —upgrade` Або, якщо потрібна інша версія, використовуйте прапорець `--tiller-image`, щоб перевизначити стандартне місце розташування та встановити конкретну версію Helm v2: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Примітка:** Розробники Helm рекомендують міграцію на підтримувану версію Helm. Helm v2.17.0 був останнім випуском Helm v2; Helm v2 більше не підтримується з листопада 2020 року, як детально описано в [Helm 2 та проєкт Charts більше не підтримуються](/blog/helm-2-becomes-unsupported/). Багато CVE було виявлено в Helm з того часу, і ці експлойти виправлені в Helm v3, але ніколи не будуть виправлені в Helm v2. Перегляньте [актуальний список опублікованих сповіщень Helm](https://github.com/helm/helm/security/advisories?state=published) і складіть план [міграції на Helm v3](/topics/v2_v3_migration.md) сьогодні. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: Видалення sidebar_position: 3 --- ## Видалення {#uninstalling} ### Я хочу видалити свій локальний Helm. Де зберігаються всі його файли? {#i-want-to-uninstall-my-local-helm-where-are-all-of-its-files} Разом з бінарним файлом `helm`, Helm зберігає деякі файли в наступних розташуваннях: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME Наступна таблиця показує стандартні теки для кожного з цих розташувань, за операційними системами: | Операційна система | Шлях до кешу | Шлях до конфігурацій | Шлях до даних | |--------------------|-----------------------------|----------------------------------|-----------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: Глосарій description: Терміни, що використовуються для опису компонентів архітектури Helm. sidebar_position: 10 --- # Глосарій {#glossary} ## Чарт {#chart} Пакет Helm, що містить інформацію, достатню для встановлення набору ресурсів Kubernetes у кластер Kubernetes. Чарти містять файл `Chart.yaml`, а також шаблони, стандартні значення (`values.yaml`) та залежності. Чарти розробляються у чітко визначеній структурі тек, а потім упаковуються у формат архіву, що називається _чарт-архівом_. ## Чарт-архів {#chart-archive} _Чарт-архів_ — це архів, що містить tar і gzipped (і, за бажанням, підписаний) чарт. ## Залежність чарту (субчарти) {#chart-dependency-subcharts} Чарти можуть залежати від інших чартів. Залежність може бути здійснена двома способами: - М’яка залежність: Чарт може просто не функціонувати без іншого чарту, встановленого в кластері. Helm не надає інструментів для цього випадку. У цьому випадку залежності можуть управлятися окремо. - Жорстка залежність: Чарт може містити (всередині теки `charts/`) інший чарт, від якого він залежить. У цьому випадку, встановлення чарту також встановить усі його залежності. У цьому випадку чарт і його залежності управляються як колекція. Коли чарт упаковується (через `helm package`), всі його жорсткі залежності упаковуються разом з ним. ## Версія чарту {#chart-version} Чарти версіонуються відповідно до [специфікації SemVer 2](https://semver.org). Номер версії є обов’язковим для кожного чарта. ## Chart.yaml Інформація про чарт зберігається в спеціальному файлі з назвою `Chart.yaml`. Кожен чарт повинен мати цей файл. ## Helm (та helm) {#helm-and-helm} Helm — це менеджер пакетів для Kubernetes. Як менеджер пакетів для операційних систем полегшує встановлення інструментів на ОС, так Helm полегшує встановлення застосунків та ресурсів у кластери Kubernetes. Хоча _Helm_ — це назва проєкту, клієнт командного рядка також називається `helm`. Зазвичай, коли йдеться про проєкт, _Helm_ пишеться з великої літери. Коли йдеться про клієнт, _helm_ пишеться з маленької літери. ## Конфігураційні файли Helm (XDG) {#helm-configuration-files-xdg} Helm зберігає свої конфігураційні файли в теках XDG. Ці теки створюються при першому запуску `helm`. ## Kube Config (KUBECONFIG) Клієнт Helm дізнається про кластери Kubernetes, використовуючи файли у форматі _Kube config_. Стандартно, Helm намагається знайти цей файл у місці, де його створює `kubectl` (`$HOME/.kube/config`). ## Лінтинг (Linting) {#lint-linting} Лінтинг чарта — це перевірка того, що він відповідає домовленостям і вимогам стандарту чарту Helm. Helm надає інструменти для цього, зокрема команду `helm lint`. ## Provenance (Файл provenance) {#provenance-provenance-file} Чарти Helm можуть супроводжуватися _файлом provenance_, який надає інформацію про те, звідки походить чарт і що він містить. Файли provenance є частиною історії безпеки Helm. Файл provenance містить криптографічний хеш файлу чарт-архіву, дані Chart.yaml і блок підпису (блок OpenPGP "clearsign"). У поєднанні з вʼязкою ключів він надає користувачам чартів можливість: - Перевірити, що чарт був підписаний довіреною стороною - Перевірити, що файл чарту не був змінений - Перевірити вміст метаданих чарту (`Chart.yaml`) - Швидко зіставити чарт з даними provenance Файли provenance мають розширення `.prov` і можуть бути надані з сервера репозиторію чартів або будь-якого іншого HTTP-сервера. ## Реліз {#release} Коли чарт встановлюється, бібліотека Helm створює _реліз_, щоб відстежувати це встановлення. Один і той же чарт може бути встановлений кілька разів в одному кластері, створюючи багато різних релізів. Наприклад, можна встановити три бази даних PostgreSQL, запустивши `helm install` три рази з різними іменами релізів. ## Номер релізу (Версія релізу) {#release-number-release-version} Один реліз може бути оновлений кілька разів. Для відстеження релізів, коли вони змінюються, використовується послідовний лічильник. Після першого `helm install` реліз матиме _номер релізу_ 1. Кожного разу, коли реліз оновлюється або скасовується, номер релізу буде збільшений. ## Відкат {#rollback} Реліз можна оновити до новішого чарту або конфігурації. Але оскільки історія релізів зберігається, реліз також може бути _відкочений_ до попереднього номера релізу. Це робиться за допомогою команди `helm rollback`. Важливо, що реліз, що відкочується, отримає новий номер релізу. | Операція | Номер релізу | |-----------|----------------------------------------------------| | встановлення | реліз 1 | | оновлення | реліз 2 | | оновлення | реліз 3 | | відкат 1 | реліз 4 (але виконує ту ж конфігурацію, що й реліз 1) | Вищенаведена таблиця ілюструє, як номери релізів збільшуються під час встановлення, оновлення та відкату. ## Бібліотека Helm (або SDK) {#helm-library-or-sdk} Бібліотека Helm (або SDK) належить до коду Go, який безпосередньо взаємодіє з сервером API Kubernetes для встановлення, оновлення, запиту та видалення ресурсів Kubernetes. Її можна імплементувати у проєкт для використання Helm як бібліотеки клієнта замість CLI. ## Репозиторій (Repo, Репозиторій чартів) {#repository-repo-chart-repository} Чарти Helm можуть зберігатися на спеціалізованих HTTP-серверах, які називаються _репозиторіями чартів_ (_репозиторіями_, або просто _repo_). Сервер репозиторію чартів є простим HTTP-сервером, який може надавати файл `index.yaml`, який описує групу чартів, і надає інформацію про те, звідки можна завантажити кожен чарт. (Багато серверів репозиторіїв чартів надають як чарт, так і файл `index.yaml`.) Клієнт Helm може вказати нуль або більше репозиторіїв чартів. Стандартно клієнти Helm не налаштовані на жодні репозиторії чартів. Репозиторії чартів можна додати в будь-який час за допомогою команди `helm repo add`. ## Реєстр чартів (OCI реєстр) {#chart-registry-oci-based-registry} Реєстр чартів Helm є системою зберігання та розподілу на основі [OCI](https://opencontainers.org/about/overview/), яка використовується для розміщення та обміну пакетами чартів Helm. Для отримання додаткової інформації див. [документацію Helm про реєстри](/topics/registries.md). ## Значення (Файли значень, values.yaml) {#values-values-files-valuesyaml} Значення надають спосіб перевизначити стандартні значення шаблонів вашою інформацією. Чарти Helm є "параметризованими", що означає, що розробник чарта може експонувати конфігурацію, яку можна перевизначити під час установки. Наприклад, чарт може експонувати поле `username`, яке дозволяє встановити імʼя користувача для сервісу. Ці експоновані змінні називаються _значеннями_ в термінах Helm. Значення можна встановити під час операцій `helm install` та `helm upgrade`, або безпосередньо передаючи їх, або використовуючи файл `values.yaml`. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- Менеджер пакетів Helm для Kubernetes. ### Опис {#synopsis} Менеджер пакетів для Kubernetes Загальні дії для Helm: - helm search: пошук чартів - helm pull: завантаження чарту у вашу локальну теку для перегляду - helm install: завантаження чарту в Kubernetes - helm list: перегляд списку релізів чартів Змінні середовища: | Імʼя | Опис | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | вказує альтернативне місце для зберігання кешованих файлів. | | $HELM_CONFIG_HOME | вказує альтернативне місце для зберігання конфігурації Helm. | | $HELM_DATA_HOME | вказує альтернативне місце для зберігання даних Helm. | | $HELM_DEBUG | вказує, чи працює Helm в режимі налагодження | | $HELM_DRIVER | вказує драйвер бекенду для зберігання. Значення: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | вказує рядок підключення, який повинен використовувати SQL-драйвер для зберігання. | | $HELM_MAX_HISTORY | вказує максимальну кількість історії релізів Helm. | | $HELM_NAMESPACE | вказує простір імен, що використовується для операцій Helm. | | $HELM_NO_PLUGINS | відключає втулки. Встановіть HELM_NO_PLUGINS=1, щоб відключити втулки. | | $HELM_PLUGINS | вказує шлях до теки плагінів | | $HELM_REGISTRY_CONFIG | вказує шлях до файлу конфігурації реєстру. | | $HELM_REPOSITORY_CACHE | вказує шлях до теки кешу репозиторіїв | | $HELM_REPOSITORY_CONFIG | вказує шлях до файлу репозиторіїв | | $KUBECONFIG | вказує альтернативний файл конфігурації Kubernetes (стандартно "~/.kube/config") | | $HELM_KUBEAPISERVER | вказує точку доступу сервера API Kubernetes для автентифікації | | $HELM_KUBECAFILE | вказує файл центру сертифікації для Kubernetes. | | $HELM_KUBEASGROUPS | вказує групи для використання імперсонації, використовуючи список, розділений комами. | | $HELM_KUBEASUSER | вказує імʼя користувача для імперсонації під час операції. | | $HELM_KUBECONTEXT | вказує імʼя контексту kubeconfig. | | $HELM_KUBETOKEN | вказує токен Bearer KubeToken для автентифікації. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | вказує, чи слід пропустити перевірку сертифіката сервера API Kubernetes (небезпечний режим) | | $HELM_KUBETLS_SERVER_NAME | вказує імʼя сервера для перевірки сертифіката сервера API Kubernetes | | $HELM_BURST_LIMIT | вказує стандартне обмеження на кількість викликів у випадку великої кількості CRD (стандартно — 100, -1 для відключення) | | $HELM_QPS | вказує кількість запитів в секунду у випадках, коли велика кількість викликів перевищує параметр для більш високих значень | Helm зберігає кеш, конфігурацію та дані на основі наступного порядку конфігурації: - Якщо встановлена змінна середовища HELM_*_HOME, вона буде використана - В іншому випадку на системах, що підтримують специфікацію базової теки XDG, будуть використані змінні XDG - Якщо не встановлено інше місце, буде використане стандартне місце залежно від операційної системи Типово, стандартні теки залежать від операційної системи. Нижче наведені їх значення: | Операційна система | Шлях до кешу | Шлях до конфігурації | Шлях до даних | |--------------------|---------------------------|------------------------------|--------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Параметри {#options} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug вмикає розширений вивід -h, --help довідка helm --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} - [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell - [helm create](/helm/helm_create.md) — створити новий чарт з вказаною назвою - [helm dependency](/helm/helm_dependency.md) — керування залежностями чарту - [helm env](/helm/helm_env.md) — інформація про середовище клієнта helm - [helm get](/helm/helm_get.md) — завантажити розширену інформацію про зазначений реліз - [helm history](/helm/helm_history.md) — отримати історію релізу - [helm install](/helm/helm_install.md) — встановити чарт - [helm lint](/helm/helm_lint.md) — перевірити чарт на можливі проблеми - [helm list](/helm/helm_list.md) — переглянути список релізів - [helm package](/helm/helm_package.md) — упакувати теку чарту в архів чарту - [helm plugin](/helm/helm_plugin.md) — встановити, переглянути або видалити втулки Helm - [helm pull](/helm/helm_pull.md) — завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальній теці - [helm push](/helm/helm_push.md) — завантажити чарт до віддаленого сервера - [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру - [helm repo](/helm/helm_repo.md) — додати, переглянути, видалити, оновити та індексувати репозиторії чартів - [helm rollback](/helm/helm_rollback.md) — відкотити реліз до попередньої версії - [helm search](/helm/helm_search.md) — шукати ключове слово в чартах - [helm show](/helm/helm_show.md) — показати інформацію про чарт - [helm status](/helm/helm_status.md) — відобразити статус зазначеного релізу - [helm template](/helm/helm_template.md) — локально рендерити шаблони - [helm test](/helm/helm_test.md) — запустити тести для релізу - [helm uninstall](/helm/helm_uninstall.md) — видалити реліз - [helm upgrade](/helm/helm_upgrade.md) — оновити реліз - [helm verify](/helm/helm_verify.md) — перевірити, чи підписаний та, чи є дійсним чарт за вказаним шляхом - [helm version](/helm/helm_version.md) — відобразити інформацію про версію клієнта ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- Генерація скриптів автодоповнення для вказаної оболонки ### Опис {#synopsis} Генерація скриптів автодоповнення Helm для вказаної оболонки. ### Параметри {#options} ```none -h, --help довідка для completion ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug включити розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) — генерувати скрипт автодоповнення для bash * [helm completion fish](/helm/helm_completion_fish.md) — генерувати скрипт автодоповнення для fish * [helm completion powershell](/helm/helm_completion_powershell.md) — генерувати скрипт автодоповнення для powershell * [helm completion zsh](/helm/helm_completion_zsh.md) — генерувати скрипт автодоповнення для zsh ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- Генерація скрипта автодоповнення для bash ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для shell bash. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell source <(helm completion bash) ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: - Linux: ```shell helm completion bash > /etc/bash_completion.d/helm ``` - MacOS: ```shell helm completion bash > /usr/local/etc/bash_completion.d/helm ``` ```shell helm completion bash [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка для bash --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ``` --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug вмикає розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапорець може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} - [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- Генерація скрипта автодоповнення для fish ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для shell fish. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell helm completion fish | source ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: ```shell helm completion fish > ~/.config/fish/completions/helm.fish ``` Потрібно запустити нову shell-сесію, щоб ці налаштування набули чинності. ```shell helm completion fish [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка для fish --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug включити розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- Генерація скрипта автодоповнення для PowerShell ### Опис {#synopsis} Генерація скрипта автодоповнення для PowerShell. Для завантаження автодоповнень у вашій поточній shell-сесії: ```powershell PS C:\> helm completion powershell | Out-String | Invoke-Expression ``` Для завантаження автодоповнень для кожної нової сесії, додайте вивід вищенаведеної команди до вашого профілю PowerShell. ```shell helm completion powershell [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка для PowerShell --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug включити розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- Генерація скрипта автодоповнення для zsh ### Опис {#synopsis} Генерація скрипта автодоповнення Helm для оболонки zsh. Для завантаження автодоповнень у вашій поточній shell-сесії: ```shell source <(helm completion zsh) ``` Для завантаження автодоповнень для кожної нової сесії, виконайте один раз: ```shell helm completion zsh > "${fpath[1]}/_helm" ``` ```shell helm completion zsh [прапорці] ``` ### Параметри {#options} ```none -h, --help довідка для zsh --no-descriptions вимкнути описи автодоповнення ``` ### Параметри, успадковані від батьківських команд ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug включити розширений вивід --kube-apiserver string адреса і порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВИТИСЯ ТАКОЖ {#see-also} * [helm completion](/helm/helm_completion.md) — генерувати скрипти автодоповнення для вказаного shell ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- створити новий чарт із вказаним імʼям ### Опис {#synopsis} Ця команда створює теку чарта разом із загальними файлами та теками, що використовуються в чартах. Наприклад, `helm create foo` створить структуру тек, що виглядає приблизно так: ```none foo/ ├── .helmignore # Містить шаблони для ігнорування при упаковці Helm-чартів. ├── Chart.yaml # Інформація про ваш чарт ├── values.yaml # Стандартні значення для ваших шаблонів ├── charts/ # Чарти, від яких залежить цей чарт └── templates/ # Файли шаблонів └── tests/ # Файли тестів ``` `helm create` приймає шлях як аргумент. Якщо теки у вказаному шляху не існують, Helm спробує створити їх по ходу. Якщо вказане призначення існує і там є файли, конфліктуючі файли будуть перезаписані, але інші файли залишаться незмінними. ```none helm create NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка для create -p, --starter string імʼя або абсолютний шлях до стартового шаблону Helm ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- керування залежностями чарту ### Опис {#synopsis} Керуйте залежностями чарту. Чарти Helm зберігають свої залежності в теці `charts/`. Для розробників чарту часто простіше керувати залежностями у файлі `Chart.yaml`, який декларує всі залежності. Команди залежностей працюють з цим файлом, полегшуючи синхронізацію між бажаними залежностями та фактичними залежностями, збереженими в теці `charts/`. Наприклад, цей файл Chart.yaml декларує дві залежності: ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" ``` Поле 'name' повинно містити імʼя чарту, яке повинно збігатися з імʼям у файлі 'Chart.yaml' цього чарту. Поле 'version' повинно містити семантичну версію або діапазон версій. URL-адреса 'repository' повинна вказувати на репозиторій чарту. Helm очікує, що додавання '/index.yaml' до URL-адреси дозволить отримати індекс репозиторію чарту. Примітка: 'repository' може бути псевдонімом, який повинен починатися з 'alias:' або '@'. Починаючи з версії 2.2.0, репозиторій може бути визначений як шлях до теки залежних чартів, збережених локально. Шлях повинен починатися з префіксу "file://". Наприклад, ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" ``` Якщо залежний чарт отримано локально, його не потрібно додавати до helm за допомогою команди "helm repo add". Підтримується також відповідність версій для цього випадку. ### Параметри {#options} ```none -h, --help довідка для dependency ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації підучас операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для викорисуання --kube-insecure-skip-tls-verify якщо встановлено truу, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить вашу HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифікату сервера API Kubernetes. Якщо уе вказано, використовується імʼя хоста, що використовуєтуся для пудключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconуig -n, --namespace string простір імен для цього запиту --qps float32 у кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) — відновлення теки charts/ на основі файлу Chart.lock * [helm dependency list](/helm/helm_dependency_list.md) — перелік залежностей для даного чарта * [helm dependency update](/helm/helm_dependency_update.md) — оновлення charts/ на основі вмісту Chart.yaml ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- перебудувати теку charts/ на основі файлу Chart.lock ### Опис {#synopsis} Ця команда будує теку `charts/` на основі файлу `Chart.lock`. Команда `build` використовується для відновлення залежностей чарту до стану, зазначеного у файлі блокування. Вона не переузгоджуватиме залежності, як це робить `helm dependency update`. Якщо файл блокування не знайдено, `helm dependency build` дзеркально повторюватиме поведінку команди `helm dependency update`. ```none helm dependency build CHART [flags] ``` ### Параметри {#options} ```none -h, --help довідка для build --keyring string вʼязка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") --skip-refresh не оновлювати кеш локального репозиторію --verify перевіряти пакети за підписами ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- список залежностей для заданого чарту ### Опис {#synopsis} Перелічує всі залежності, зазначені в чарті. Ця команда приймає на вхід як архіви чарту, так і теки чарту. Вона не змінює вміст чарту. Викликається помилка, якщо чарт не може бути завантажений. ```none helm dependency list CHART [flags] ``` ### Параметри {#options} ```none -h, --help довідка для list --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 80) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- оновлення charts/ на основі вмісту Chart.yaml ### Опис {#synopsis} Оновлює залежності на диску, щоб відобразити стан, зазначений у Chart.yaml. Ця команда перевіряє, що необхідні чарти, зазначені в `Chart.yaml`, присутні в `charts/` і відповідають прийнятній версії. Вона завантажує найновіші чарти, що задовольняють залежності, та очищає застарілі залежності. У разі успішного оновлення буде згенеровано файл блокування, який можна використовувати для відновлення залежностей до точної версії. Залежності не обовʼязково повинні бути представлені в `Chart.yaml`. З цієї причини команда оновлення не видалить чарти, якщо вони (а) присутні у файлі `Chart.yaml`, але (б) мають неправильну версію. ```none helm dependency update CHART [flags] ``` ### Параметри {#options} ```none -h, --help довідка для update --keyring string вʼязка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") --skip-refresh не оновлювати локальний кеш репозиторіїв --verify перевірити пакети на відповідність підписам ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm dependency](/helm/helm_dependency.md) — керувати залежностями чарту ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- інформація про середовище клієнта Helm ### Опис {#synopsis} Команда `helm env` виводить усю інформацію про середовище, яке використовується Helm. ```shell helm env [flags] ``` ### Параметри {#options} ```none -h, --help довідка для env ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ``` --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- завантажити розширену інформацію про вказаний реліз ### Опис {#synopsis} Ця команда складається з кількох підкоманд, які можна використовувати для отримання розширеної інформації про реліз, включаючи: - Значення, що використовувалися для генерації релізу - Сформований файл маніфесту - Примітки, надані чартом релізу - Хуки, асоційовані з релізом - Метадані релізу ### Параметри {#options} ```none -h, --help довідка для get ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} - [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. - [helm get all](/helm/helm_get_all.md) — завантажити всю інформацію про вказаний реліз - [helm get hooks](/helm/helm_get_hooks.md) — завантажити всі хуки для вказаного релізу - [helm get manifest](/helm/helm_get_manifest.md) — завантажити маніфест для вказаного релізу - [helm get metadata](/helm/helm_get_metadata.md) — отримати метадані для вказаного релізу - [helm get notes](/helm/helm_get_notes.md) — завантажити примітки для вказаного релізу - [helm get values](/helm/helm_get_values.md) — завантажити файл значень для вказаного релізу ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- завантажити всю інформацію про вказаний реліз ### Опис {#synopsis} Ця команда виводить зрозумілий для людини набір інформації про нотатки, хуки, надані значення та згенерований маніфест для вказаного релізу. ```shell helm get all RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка для all --revision int отримати вказаний реліз з версією --template string шаблон Go для форматування виводу, напр: {{.Release.Name}} ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- завантажити всі хуки для вказаного релізу ### Опис {#synopsis} Ця команда завантажує хуки для вказаного релізу. Хуки форматуються у YAML і розділені роздільником YAML '---\n'. ```shell helm get hooks RELEASE_NAME [flags] ``` ### Параметри ```none -h, --help довідка для hooks --revision int отримати вказаний реліз з версією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (станлартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (станлартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (станлартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- завантажити маніфест для вказаного релізу ### Опис {#synopsis} Ця команда завантажує згенерований маніфест для вказаного релізу. Маніфест є YAML-кодованим представленням ресурсів Kubernetes, які були згенеровані з чарту(ів) цього релізу. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест. ```shell helm get manifest RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка для manifest --revision int отримати вказаний реліз з версією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- Ця команда завантажує метадані для вказаного релізу ```shell helm get metadata RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка для metadata -o, --output format виводить результати у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int вказати версію релізу ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- завантажити нотатки для вказаного релізу ### Опис {#synopsis} Ця команда відображає нотатки, надані чартом для вказаного релізу. ```shell helm get notes RELEASE_NAME [flags] ``` ### Параметри ```none -h, --help довідка для notes --revision int отримати реліз з вказаною версією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- завантажити файл значень для вказаного релізу ### Опис {#synopsis} Ця команда завантажує файл значень для вказаного релізу. ```shell helm get values RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -a, --all вивести всі (обчислені) значення -h, --help довідка для values -o, --output format друкує вихід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int отримати реліз з вказаною версією ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm get](/helm/helm_get.md) — завантажити розширену інформацію про вказаний реліз ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- отримати історію релізу ### Опис {#synopsis} History виводить історичні ревізії для вказаного релізу. Стандартна максимальна кількість ревізій, що повертається — 256. Встановлення '--max' налаштовує максимальну довжину списку ревізій, що повертаються. Історичний набір релізів виводиться у вигляді відформатованої таблиці, наприклад: ```console $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` ```shell helm history RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка для history --max int максимальна кількість ревізій, включених в історію (стандартно 256) -o, --output format виводити результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### Дивіться також {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- Встановлює чарт ### Опис {#synopsis} Ця команда встановлює архів чарту. Аргумент для `install` має бути посиланням на чарт, шляхом до запакованого чарту, шляхом до розпакованої теки чарту або URL. Щоб перезаписати значення в чартах, використовуйте прапорець `--values` та передайте файл або прапорець `--set`, щоб передати конфігурацію з командного рядка. Щоб примусово встановити значення рядка, використовуйте `--set-string`. Ви також можете використовувати `--set-file`, щоб задати окремі значення з файлу, якщо значення занадто велике для командного рядка або є динамічно згенерованим. Ви також можете використовувати `--set-json`, щоб встановити значення JSON (скаляри/обʼєкти/масиви) з командного рядка. ```shell $ helm install -f myvalues.yaml myredis ./redis ``` або ```shell $ helm install --set name=prod myredis ./redis ``` або ```shell $ helm install --set-string long_int=1234567890 myredis ./redis ``` або ```shell $ helm install --set-file my_script=dothings.sh myredis ./redis ``` або ```shell $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis ``` Ви можете вказати прапорець `--values`/'-f' кілька разів. Пріоритет буде наданий останньому (правому) файлу, що вказаний. Наприклад, якщо як `myvalues.yaml`, так і `override.yaml` містять ключ `Test`, значення, встановлене в `override.yaml`, матиме пріоритет: ```shell $ helm install -f myvalues.yaml -f override.yaml myredis ./redis ``` Ви можете вказати прапорець `--set` кілька разів. Пріоритет буде наданий останньому (правому) встановленому значенню. Наприклад, якщо для ключа `foo` встановлені значення `bar` і `newbar`, значення `newbar` матиме пріоритет: ```shell $ helm install --set foo=bar --set foo=newbar myredis ./redis ``` Аналогічно, у наступному прикладі `foo` встановлено в `["four"]`: ```shell $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis ``` А в наступному прикладі `foo` встановлено в `{"key1":"value1","key2":"bar"}`: ```shell $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis ``` Щоб перевірити згенеровані маніфести релізу без встановлення чарту, можна поєднати прапорці `--debug` і `--dry-run`. Прапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з Secrets які можуть містити конфіденційні значення. Щоб приховати секрети Kubernetes, скористайтеся прапорцем `--hide-secret`. Будь ласка, уважно вивчіть, як і коли використовувати ці прапорці. Якщо встановлено прапорець `--verify`, чарт ПОВИНЕН мати файл автентифікації, і цей файл ПОВИНЕН пройти всі кроки перевірки. Є шість різних способів казати чарт, який ви хочете встановити: 1. З посиланням на чарт: `helm install mymaria example/mariadb` 2. З шляхом до запакованого чарту: `helm install mynginx ./nginx-1.2.3.tgz` 3. З шляхом до розпакованої теки чарту: `helm install mynginx ./nginx` 4. З абсолютним URL: `helm install mynginx https://example.com/charts/nginx-1.2.3.tgz` 5. З посиланням на чарт і URL репозиторію: `helm install --repo https://example.com/charts/ mynginx nginx` 6. З OCI реєстрами: `helm install mynginx --version 1.2.3 oci://example.com/charts/nginx` ПОСИЛАННЯ НА ЧАРТ Посилання на чарт — це зручний спосіб посилатися на чарт у репозиторії чарту. Коли ви використовуєте посилання на чарт з префіксом репозиторію (`example/mariadb`), Helm шукатиме в локальній конфігурації репозиторій чарту з імʼям `example`, а потім шукатиме чарт у цьому репозиторії, чия назва є `mariadb`. Він встановить останню стабільну версію цього чарту, поки ви не вкажете прапорець `--devel`, щоб також включити версії розробки (альфа, бета та реліз-кандидати), або не надасте номер версії за допомогою прапорця `--version`. Щоб переглянути список репозиторіїв чартів, використовуйте `helm repo list`. Щоб шукати чарти в репозиторії, використовуйте `helm search`. ```shell helm install [NAME] [CHART] [flags] ``` ### Параметри {#options} ```none --atomic якщо вказано, процес встановлення видалить всnановлення у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --create-namespace створити простір імен релізу, якщо його не існує --description string додати власний опис --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти відрендерені шаблони за схемою OpenAPI Kubernetes --dry-run string[="client"] імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера. --enable-dns увімкнути DNS запити при рендерингу шаблонів --force примусово оновлювати ресурси через стратегію заміни -g, --generate-name згенерувати імʼя (та опустити параметр NAME) -h, --help довідка install --hide-notes якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту --hide-secret приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати клієнта HTTPS за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) --name-template string вказати шаблон для назви релізу --no-hooks запобігти виконанню хуків під час встановлення -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pass-credentials передати облікові дані всім доменам --password string пароль до репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --post-renderer postRendererString шлях до виконуваного файлу, що використовується для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, в іншому випадку буде намагатися знайти виконуваний файл за вказаним шляхом --post-renderer-args postRendererArgsSlice аргумент до пост-рендерера (можна вказати кілька) (стандартно []) --render-subchart-notes якщо вказано, рендерити нотатки субчартів разом з батьківським --replace повторно використовувати дане імʼя, тільки якщо це імʼя є вилученим релізом, який залишається в і єсторії. Це є небезпечним в операційному середовищі --repo string URL репозиторію чартів, де розташований запитуваний чарт --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, що вказані через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=pshellath2) --set-json stringArray встановити значення JSON в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) --set-literal stringArray встановити літеральне значення STRING в командному рядку --set-string stringArray встановити значення STRING на командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-crds якщо вказано, CRD не буде встановлено. Стандартно CRD встановлюються, якщо їх ще немає --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарта, яку слід використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія --wait якщо вказано, буде чекати, поки всі Pods, PVCs, Сервіси і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть готові перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout --wait-for-jobs якщо вказано і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед позначенням релізу як успішного. Чекати буде стільки, скільки встановлено --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- перевіряє чарт на можливі проблеми ### Опис {#synopsis} Ця команда приймає шлях до чарту і виконує ряд тестів, щоб перевірити, чи чарт добре сформований. Якщо лінтер знайде речі, які можуть призвести до помилки при встановленні чарту, він видасть повідомлення [ERROR]. Якщо він знайде проблеми, які порушують конвенції або рекомендації, він видасть повідомлення [WARNING]. ```shell helm lint PATH [flags] ``` ### Параметри {#options} ```none -h, --help довідка lint --kube-version string версія Kubernetes, що використовується для перевірки можливостей і застарілостей --quiet виводити лише попередження та помилки --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити JSON-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) --set-literal stringArray встановити літеральне STRING-значення в командному рядку --set-string stringArray встановити STRING-значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --strict видавати стан помилки на попередженнях lint -f, --values strings вказати значення в YAML-файлі або URL (можна вказати кілька) --with-subcharts перевірити залежні чарти ``` ### Опції, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- Перегляд релізів ### Опис {#synopsis} Ця команда виводить список усіх релізів для вказаного простору імен (використовується поточний контекст простору імен, якщо не вказано). Стандартно вона перераховує тільки ті релізи, які розгорнуті або зазнали невдачі. Прапорці, такі як `--uninstalled` і `--all`, змінюють цю поведінку. Такі прапорці можна комбінувати: `--uninstalled --failed`. Як правило елементи сортуються в алфавітному порядку. Використовуйте прапорець `-d`, щоб сортувати за датою релізу. Якщо надано прапорець `--filter`, він буде використовуватися як фільтр. Фільтри є регулярними виразами (сумісними з Perl), які застосовуються до списку релізів. Будуть повернуті тільки ті елементи, які відповідають фільтру. ```console $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 ``` Якщо результати не знайдені, команда `helm list` завершиться з кодом 0, але без виводу (або, у випадку без прапорця `-q`, тільки заголовки). Стандартно повертається до 256 елементів. Щоб обмежити це, використовуйте прапорець `--max`. Встановлення `--max` в 0 не поверне всі результати. Замість цього повернеться стандартне значення сервера, яке може бути значно більше ніж 256. Поєднання прапорців `--max` та `--offset` дозволяє переглядати результати посторінково. ```shell helm list [flags] ``` ### Параметри {#options} ```none -a, --all показати всі релізи без жодного фільтра -A, --all-namespaces список релізів по всіх просторах імен -d, --date сортувати за датою релізу --deployed показати розгорнуті релізи. Якщо нічого іншого не вказано, це буде автоматично увімкнено --failed показати релізи з помилками -f, --filter string регулярний вираз (сумісний з Perl). Будь-які релізи, що відповідають виразу, будуть включені в результати -h, --help довідка list -m, --max int максимальна кількість релізів для отримання (стандартно 256) --no-headers не друкувати заголовки при використанні стандартного формату виводу --offset int наступний індекс релізу у списку, використовується для зсуву від початкового значення -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pending показати невирішені релізи -r, --reverse змінити порядок сортування на зворотний -l, --selector string Селектор (запит за міткою) для фільтрації, підтримує '=', '==' і '!=' (наприклад, -l key1=value1,key2=value2). Працює тільки для сховищ secret (стандартно) та configmap. -q, --short короткий (тихий) формат виводу --superseded показати замінені релізи --time-format string форматувати час, використовуючи форматувальник часу golang. Приклад: --time-format "2006-01-02 15:04:05Z0700" --uninstalled показати видалені релізи (якщо використовувався `helm uninstall --keep-history`) --uninstalling показати релізи, які в даний час видаляються ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- упакувати теку чарту в архів чартів ### Опис {#synopsis} Ця команда упаковує чарт в архів чартів з версією. Якщо вказано шлях, команда перевіряє цей шлях на наявність чарту (який повинен містити файл `Chart.yaml`) і потім упаковує цю теку. Архіви чартів з версією використовуються репозиторіями пакетів Helm. Щоб підписати чарт, використовуйте прапорець `--sign`. У більшості випадків вам також слід вказати `--keyring path/to/secret/keys` та `--key keyname`. ```shell helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg ``` Якщо `--keyring` не вказано, Helm зазвичай використовує публічний ключ, якщо тільки ваше середовище не налаштоване інакше. ```shell helm package [CHART_PATH] [...] [flags] ``` ### Параметри {#options} ```none --app-version string встановити appVersion в чарті на цю версію -u, --dependency-update оновити залежності з "Chart.yaml" в теці "charts/" перед упаковкою -d, --destination string місце для запису чарту. (стандатно ".") -h, --help довідка package --key string імʼя ключа для використання під час підписання. Використовується, якщо `--sign` є true --keyring string місце для публічного ключа (стандартно "~/.gnupg/pubring.gpg") --passphrase-file string місце розташування файлу, що містить пароль для ключа підпису. Використовуйте "-" для читання з stdin. --sign використовувати приватний ключ PGP для підписання цього пакету --version string встановити версію чарту на цю версію semver ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- встановлення, перегляд списку або видалення втулків Helm ### Опис {#synopsis} Керування втулками Helm на стороні клієнта. ### Параметри {#options} ```none -h, --help довідка plugin ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) — встановити втулок Helm * [helm plugin list](/helm/helm_plugin_list.md) — переглянути встановлені втулки Helm * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) — видалити один або кілька втулків Helm * [helm plugin update](/helm/helm_plugin_update.md) — оновити один або кілька втулків Helm ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- встановити втулок Helm ### Опис {#synopsis} Ця команда дозволяє встановити втулок з URL до VCS репозиторію або з локального шляху. ```shell helm plugin install [options] [flags] ``` ### Параметри {#options} ```none -h, --help довідка install --version string вказати обмеження версії. Якщо це не вказано, буде встановлена остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- вивести перелік встановлених втулків Helm ```shell helm plugin list [flags] ``` ### Параметри {#options} ```none -h, --help довідка list ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- видалити один або кілька втулків Helm ```shell helm plugin uninstall ... [flags] ``` ### Параметри {#options} ```none -h, --help довідка uninstall ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- оновити один або кілька втулків Helm ```shell helm plugin update ... [flags] ``` ### Параметри {#options} ```none -h, --help довідка update ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm plugin](/helm/helm_plugin.md) — встановити, вивести перелік або видалити втулки Helm ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- завантажити чарт з репозиторію та (за бажанням) розпакувати його в локальну теку ### Опис {#synopsis} Отримати пакет із репозиторію пакетів та завантажити його локально. Це корисно для отримання пакетів для інспекції, модифікації або перепакування. Також це можна використовувати для криптографічної перевірки чарту без його встановлення. Існують параметри для розпакування чарту після завантаження. Це створить теку для чарту та розпакує в неї файли. Якщо вказано прапорець `--verify`, запитуваний чарт ПОВИНЕН мати файл підтвердження автентичності та ПОВИНЕН пройти процес перевірки. Будь-яка помилка призведе до помилки, і чарт не буде збережено локально. ```shell helm pull [URL чарта | репозиторій/назвачартa] [...] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату -d, --destination string місце для збереження чарту. Якщо вказано разом із untardir, то untardir буде додано до нього (стандартно ".") --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка pull --insecure-skip-tls-verify пропустити перевірку TLS-сертифікатів для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL-ключа --keyring string місце розташування публічних ключів для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передавати облікові дані всім доменам --password string пароль для репозиторію чарта, де знаходиться запитуваний чарт --plain-http використовувати незахищені HTTP-зʼєднання для завантаження чарта --prov завантажити файл підтвердження автентичності, але не виконувати перевірку --repo string URL репозиторію чарта, де знаходиться запитуваний чарт --untar якщо встановлено, чарт буде розпаковано після завантаження --untardir string якщо вказано untar, цей прапорець вказує назву теки, в яку буде розпаковано чарт (стандартно ".") --username string імʼя користувача для репозиторію чарта, де знаходиться запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження на версію чарта для використання. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або посилатися на допустимий діапазон (наприклад, ^2.0.0). Якщо не вказано, використовується остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- завантажити чарт на віддалений сервер ### Опис {#synopsis} Завантаження чарту до реєстру. Якщо чарт має повʼязаний файл підтвердження автентичності, він також буде завантажений. ```shell helm push [chart] [remote] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату -h, --help довідка push --insecure-skip-tls-verify пропустити перевірку tls-сертифікатів під час завантаження чарту --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL --plain-http використовувати небезпечні HTTP-зʼєднання для завантаження чарту ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- вхід до або вихід з реєстру ### Опис {#synopsis} Ця команда містить декілька субкоманд для взаємодії з реєстрами. ### Параметри {#options} ```none -h, --help довідка registry ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — Менеджер пакетів Helm для Kubernetes. * [helm registry login](/helm/helm_registry_login.md) — вхід до реєстру * [helm registry logout](/helm/helm_registry_logout.md) — вихід з реєстру ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- вхід до реєстру ### Опис {#synopsis} Автентифікація на віддаленому реєстрі. ```shell helm registry login [host] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату -h, --help довідка login --insecure дозволити зʼєднання з TLS-реєстром без сертифікатів --key-file string ідентифікувати клієнта реєстру за допомогою цього файлу ключа SSL -p, --password string пароль для реєстру або токен ідентифікації --password-stdin зчитати пароль або токен ідентифікації з stdin -u, --username string імʼя користувача реєстру ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- вихід з реєстру ### Опис {#synopsis} Видалення збережених облікових даних для віддаленого реєстру. ```shell helm registry logout [host] [flags] ``` ### Параметри {#options} ```none -h, --help довідка logout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm registry](/helm/helm_registry.md) — увійти або вийти з реєстру. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- додати, вивести перелік, видалити, оновити та індексувати репозиторії чартів ### Опис {#synopsis} Ця команда містить кілька субкоманд для взаємодії з репозиторіями чартів. Вона може використовуватися для додавання, видалення, виводу переліку та індексування репозиторіїв чартів. ### Параметри {#options} ```none -h, --help довідка repo ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. * [helm repo add](/helm/helm_repo_add.md) — додати репозиторій чартів * [helm repo index](/helm/helm_repo_index.md) — згенерувати файл індексу для теки, що містить упаковані чарти * [helm repo list](/helm/helm_repo_list.md) — вивести перелік репозиторіїв чартів * [helm repo remove](/helm/helm_repo_remove.md) — видалити один або кілька репозиторіїв чартів * [helm repo update](/helm/helm_repo_update.md) — оновити інформацію про доступні чарти локально з репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- додати репозиторій чартів ```shell helm repo add [NAME] [URL] [flags] ``` ### Параметри {#options} ```none --allow-deprecated-repos стандартно ця команда не дозволяє додавати офіційні репозиторії, які були назавжди видалені. Ця опція вимикає таку поведінку --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --force-update замінити (перезаписати) репозиторій, якщо він уже існує -h, --help довідка add --insecure-skip-tls-verify пропустити перевірку tls-сертифікатів для репозиторію --key-file string ідентифікувати HTTPS-клієнта за допомогою цього файлу ключа SSL --no-update Ігнорується. Раніше ця опція відключала примусові оновлення. Застаріла через force-update. --pass-credentials передавати облікові дані всім доменам --password string пароль до репозиторію чартів --password-stdin зчитати пароль до репозиторію чартів з stdin --username string імʼя користувача репозиторію чартів ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- згенерувати файл індексу для теки, що містить упаковані чарти ### Опис {#synopsis} Прочитати поточну теку і згенерувати файл індексу на основі знайдених чартів. Цей інструмент використовується для створення файлу 'index.yaml' для репозиторію чартів. Щоб встановити абсолютну URL-адресу для чартів, використовуйте прапорець '--url'. Щоб обʼєднати згенерований індекс із наявним файлом індексу, використовуйте прапорець '--merge'. У цьому випадку чарти, знайдені в поточній теці, будуть обʼєднані з наявним індексом, причому локальні чарти матимуть пріоритет над теперішніми. ```shell helm repo index [DIR] [flags] ``` ### Параметри {#options} ```none -h, --help довідка index --json вивід у форматі JSON --merge string обʼєднати згенерований індекс із вказаним індексом --url string URL репозиторію чартів ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- вивести перелік репозиторії чартів ```shell helm repo list [flags] ``` ### Параметри {#options} ```none -h, --help довідка list -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- видалити один або кілька репозиторіїв чартів ```shell helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Параметри {#options} ```none -h, --help довідка remove ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- оновити інформацію про доступні чарти локально з репозиторіїв чартів ### Опис {#synopsis} Команда update отримує останню інформацію про чарти з відповідних репозиторіїв чартів. Інформація кешується локально, де її використовують такі команди, як 'helm search'. Ви можете опційно вказати список репозиторіїв, які ви хочете оновити. ```shell helm repo update ... ``` Щоб оновити всі репозиторії, використовуйте 'helm repo update'. ```shell helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Параметри {#options} ```none --fail-on-repo-update-fail оновлення не буде завершене, якщо будь-яке з оновлень репозиторіїв зазнає невдачі -h, --help довідка update ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm repo](/helm/helm_repo.md) — додавання, створення списку, видалення, оновлення та індексація репозиторіїв чартів ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- відкотити реліз до попередньої версії ### Опис {#synopsis} Ця команда відкотить реліз до попередньої версії. Перший аргумент команди rollback — це імʼя релізу, а другий — номер версії (revision). Якщо цей аргумент пропущений або встановлений на 0, реліз буде повернено до попередньої версії. Щоб побачити номери версій, виконайте команду 'helm history RELEASE'. ```shell helm rollback [REVISION] [flags] ``` ### Параметри {#options} ```none --cleanup-on-fail дозволити видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдається --dry-run імітувати відкат --force примусово оновити ресурси через видалення/пересворення, якщо потрібно -h, --help довдідка rollback --history-max int обмежити максимальну кількість збережених версій для кожного релізу. Використовуйте 0 для безмежної кількості (стандартно 10) --no-hooks запобігти виконанню хуків під час відкату --recreate-pods перезапускати podʼи для ресурсу, якщо це застосовується --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5m0s) --wait якщо встановлено, буде чекати, поки всі Pods, PVCs, Services і мінімальна кількість Pods у Deployment, StatefulSet або ReplicaSet не перейдуть у стан готовності, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout --wait-for-jobs якщо встановлено і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені, перш ніж позначити реліз як успішний. Чекатиме стільки, скільки вказано у --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- шукати ключове слово у чартах ### Опис {#synopsis} Команда search надає можливість шукати Helm чарти в різних місцях, де вони можуть зберігатися, включаючи Artifact Hub і репозиторії, які ви додали. Використовуйте субкоманди search для пошуку в різних місцях для чартів. ### Параметри {#options} ```none -h, --help довідка search ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. * [helm search hub](/helm/helm_search_hub.md) — шукати чарти в Artifact Hub або у власному екземплярі хабу * [helm search repo](/helm/helm_search_repo.md) — шукати репозиторії за ключовим словом у чартах ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- шукати чарти в Artifact Hub або у власному екземплярі хабу ### Опис {#synopsis} Шукайте Helm чарти в Artifact Hub або у власному екземплярі хабу. Artifact Hub — це вебзастосунок, що дозволяє знаходити, встановлювати та публікувати пакети та конфігурації для проєктів CNCF, включаючи публічно доступні розподілені Helm чарти. Це проєкт Sandbox Cloud Native Computing Foundation. Ви можете переглянути хаб за адресою https://artifacthub.io/ Аргумент [KEYWORD] приймає як ключове слово, так і рядок з параметрами розширеного запиту. Документацію з параметрів розширеного запиту дивіться на https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Попередні версії Helm використовували екземпляр Monocular як стандартне значення для 'endpoint', тому для зворотної сумісності Artifact Hub сумісний з API пошуку Monocular. Аналогічно, при встановленні прапорця 'endpoint' зазначена точка доступу також має реалізовувати API пошуку, сумісний з Monocular. Зверніть увагу, що при вказівці екземпляра Monocular як 'endpoint', розширені запити не підтримуються. Для деталей API дивіться https://github.com/helm/monocular ```shell helm search hub [KEYWORD] [flags] ``` ### Параметри {#options} ```none --endpoint string Екземпляр хаба для запитів чартів (стандартно "https://hub.helm.sh") --fail-on-no-result пошук не вдається, якщо результати не знайдені -h, --help довідка hub --list-repo-url вивести URL репозиторію чартів --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm search](/helm/helm_search.md) — пошук ключового слова в чартах ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- шукати репозиторії за ключовим словом у чартах ### Опис {#synopsis} Команда search проходить через всі репозиторії, налаштовані в системі, і шукає збіги. Пошук цих репозиторіїв використовує метадані, збережені в системі. Вона відобразить останні стабільні версії знайдених чартів. Якщо ви вказуєте прапорець --devel, у виводі будуть включені передрелізні версії. Якщо ви хочете шукати за допомогою обмеження версії, використовуйте --version. Приклади: ```console # Шукати стабільні версії релізів, що відповідають ключовому слову "nginx" $ helm search repo nginx # Шукати версії релізів, що відповідають ключовому слову "nginx", включаючи версії передрелізні $ helm search repo nginx --devel # Шукати останній стабільний реліз для nginx-ingress з основною версією 1 $ helm search repo nginx-ingress --version ^1.0.0 ``` Репозиторії управляються командами 'helm repo'. ```shell helm search repo [keyword] [flags] ``` ### Параметри {#options} ```none --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --fail-on-no-result повертає помилку, якщо результати не знайдені -h, --help довідка repo --max-col-width uint максимальна ширина стовпця для таблиці виводу (стандартно 50) -o, --output format вивести результат у вказаному форматі. Доступні значення: table, json, yaml (стандартно table) -r, --regexp використовувати регулярні вирази для пошуку в репозиторіях, які ви додали --version string шукати, використовуючи обмеження семантичного версіонування в репозиторіях, які ви додали -l, --versions показати довгий список, з кожною версією кожного чарту на окремому рядку, для репозиторіїв, які ви додали ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm search](/helm/helm_search.md) — пошук ключового слова в чартах ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- показати інформацію про чарт ### Опис {#synopsis} Ця команда складається з кількох підкоманд для відображення інформації про чарт ### Параметри {#options} ```none -h, --help довідка show ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. * [helm show all](/helm/helm_show_all.md) — показати всю інформацію про чарт * [helm show chart](/helm/helm_show_chart.md) — показати визначення чарту * [helm show crds](/helm/helm_show_crds.md) — показати CRD чарту * [helm show readme](/helm/helm_show_readme.md) — показати README чарту * [helm show values](/helm/helm_show_values.md) — показати значення чарту ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- показати всю інформацію про чарт ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує весь його вміст (values.yaml, Chart.yaml, README). ```shell helm show all [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --devel використовувати версії в розробці також. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це ігнорується -h, --help довідка all --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним теґом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- показати визначення чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) і показує вміст файлу Chart.yaml. ```shell helm show chart [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка chart --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP з'єднання для завантаження чарту --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- показати CRD чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлів CustomResourceDefinition (CRD). ```shell helm show crds [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка crds --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- показати README файл чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу README ```shell helm show readme [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка readme --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- показати значення чарту ### Опис {#synopsis} Ця команда перевіряє чарт (теку, файл або URL) та показує вміст файлу values.yaml ```shell helm show values [CHART] [flags] ``` ### Параметри {#options} ```none --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. -h, --help довідка values --insecure-skip-tls-verify пропустити перевірку сертифікатів TLS для завантаження чарту --key-file string ідентифікувати HTTPS-клієнта за допомогою цього SSL ключового файлу --keyring string розташування публічних ключів, які використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чартів, де розташований запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --repo string URL репозиторію чартів, де розташований запитуваний чарт --username string імʼя користувача репозиторію чартів, де розташований запитуваний чарт --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, буде використовуватися остання версія ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} * [helm show](/helm/helm_show.md) — показати інформацію про чарт ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- показати статус вказаного релізу ### Опис {#synopsis} Ця команда показує статус вказаного релізу. Статус складається з: - часу останнього розгортання - простору імен k8s, в якому знаходиться реліз - стану релізу (може бути: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade або pending-rollback) - ревізії релізу - опису релізу (може бути повідомленням про завершення або помилкою, потрібно увімкнути --show-desc) - списку ресурсів, які входять до складу цього релізу (потрібно увімкнути --show-resources) - деталей останнього запуску тестового набору, якщо застосовується - додаткових приміток, наданих чартом ```shell helm status RELEASE_NAME [flags] ``` ### Параметри {#options} ```none -h, --help довідка status -o, --output format виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --revision int якщо вказано, показати статус вказаного релізу з ревізією --show-desc якщо вказано, показати описове повідомлення вказаного релізу --show-resources якщо вказано, показати ресурси вказаного релізу ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- локальний рендеринг шаблонів ### Опис {#synopsis} Рендерить шаблони чарту локально та показує результат. Будь-які значення, які зазвичай шукалися або отримувалися в кластері, будуть імітуватися локально. Крім того, жодна з перевірок валідності чарту на сервері (наприклад, перевірка підтримки API) не проводиться. ```shell helm template [NAME] [CHART] [flags] ``` ### Параметри ```none -a, --api-versions strings версії API Kubernetes, які використовуються для Capabilities.APIVersions --atomic якщо вказано, процес встановлення видалить інсталяцію у разі невдачі. Прапорець --wait буде встановлено автоматично, якщо використовується --atomic --ca-file string перевірити сертифікати HTTPS-серверів за допомогою цього CA пакету --cert-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL сертифікату --create-namespace створити простір імен релізу, якщо його не існує --dependency-update оновити залежності, якщо вони відсутні перед установкою чарту --description string додати власний опис --devel використовувати також версії в розробці. Еквівалент версії '>0.0.0-0'. Якщо вказано --version, цей параметр ігнорується. --disable-openapi-validation якщо вказано, процес встановлення не буде перевіряти шаблони за схемою OpenAPI Kubernetes --dry-run string[="client"] імітувати встановлення. Якщо --dry-run вказано без жодної опції або як '--dry-run=client', він не буде намагатися підключитися до кластера. Встановлення '--dry-run=server' дозволяє намагатися підключитися до кластера. --enable-dns увімкнути DNS запити при рендерингу шаблонів --force примусово оновлювати ресурси через стратегію заміни -g, --generate-name згенерувати імʼя (та опустити параметр NAME) -h, --help довідка по template --hide-notes якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту --include-crds включити CRD у вивід шаблонів --insecure-skip-tls-verify пропустити перевірки TLS сертифікатів для завантаження чарту --is-upgrade встановити .Release.IsUpgrade замість .Release.IsInstall --key-file string ідентифікувати клієнта HTTPS, використовуючи цей файл SSL ключа --keyring string розташування публічних ключів, використовуваних для перевірки (стандартно "~/.gnupg/pubring.gpg") --kube-version string версія Kubernetes, яка використовується для Capabilities.KubeVersion -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комами. (стандартно []) --name-template string вказати шаблон, використаний для іменування релізу --no-hooks запобігти виконанню хуків у процесі установки --output-dir string записувати виконані шаблони у файли в output-dir замість stdout --pass-credentials передати облікові дані всім доменам --password string пароль до репозиторію чартів, де знайти запитуваний чарт --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --post-renderer postRendererString шлях до виконуваного файлу, який буде використаний для пост-рендерингу. Якщо він існує в $PATH, буде використано цей бінарний файл, інакше спробує знайти виконуваний файл за вказаним шляхом --post-renderer-args postRendererArgsSlice аргумент для пост-рендерера (можна вказати кілька) (стандартно []) --release-name використовувати імʼя релізу в шляху output-dir --render-subchart-notes якщо вказано, рендерити нотатки субчарту разом з батьківським --replace повторно використовувати дане імʼя, тільки якщо це імʼя є видаленим релізом, який залишається в історії. Це небезпечно в операційному середовищі --repo string URL репозиторію чартів, де знайти запитуваний чарт --set stringArray встановити значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити JSON значення в командному рядку (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) --set-literal stringArray встановити літеральне STRING значення на командному рядку --set-string stringArray встановити STRING значення в командному рядку (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) -s, --show-only stringArray показати тільки маніфести, відрендерені з вказаних шаблонів --skip-crds якщо вказано, CRD не будуть встановлені. Ствндартно CRD встановлюються, якщо ще не присутні --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --skip-tests пропустити тести з виводу шаблонів --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хук) (стандартно 5м0с) --username string імʼя користувача репозиторію чартів, де знайти запитуваний чарт --validate перевірити ваші маніфести на відповідність кластеру Kubernetes, до якого ви в даний час звертаєтеся. Це така ж перевірка, яка виконується при установці -f, --values strings вказати значення в YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед його використанням --version string вказати обмеження версії для версії чарту, яку потрібно використовувати. Це обмеження може бути конкретним тегом (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо це не вказано, використовується остання версія --wait якщо вказано, буде чекати, поки всі Pods, PVCs, Services та мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не будуть у стані готовності, перш ніж позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout --wait-for-jobs якщо вказано і --wait увімкнено, буде чекати, поки всі Jobs не будуть завершені перед тим, як позначити реліз як успішний. Це буде чекати стільки, скільки вказано у --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- запустити тести для релізу ### Опис {#synopsis} Команда test запускає тести для релізу. Аргументом цієї команди є імʼя розгорнутого релізу. Тести, що будуть виконані, визначені у чарті, який був встановлений. ```shell helm test [RELEASE] [flags] ``` ### Параметри {#options} ```none --filter strings вказати тести за атрибутом (в даний час "name") використовуючи синтаксис attribute=value або '!attribute=value', щоб виключити тест (можна вказати кілька або розділити значення комами: name=test1,name=test2) -h, --help довідка test --hide-notes якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту --logs отримати логи з тестових podʼів (це виконується після завершення всіх тестів, але перед будь-яким очищенням) --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- видалити реліз ### Опис {#synopsis} Ця команда приймає імʼя релізу і видаляє його. Вона видаляє всі ресурси, асоційовані з останнім релізом чарту, а також історію релізу, звільняючи його для подальшого використання. Використовуйте прапор '--dry-run', щоб побачити, які релізи будуть видалені без фактичного видалення. ```shell helm uninstall RELEASE_NAME [...] [flags] ``` ### Параметри {#options} ```none --cascade string Має бути "background", "orphan" або "foreground". Вибирає стратегію каскадного видалення для залежних ресурсів. Стандартно background. (стандартно "background") --description string додати власний опис --dry-run симулювати видалення -h, --help довідка uninstall --ignore-not-found Вважати "release not found" як успішне видалення --keep-history видалити всі асоційовані ресурси і помітити реліз як видалений, але зберегти історію релізу --no-hooks запобігти виконанню хуків під час видалення --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) --wait якщо вказано, буде чекати, поки всі ресурси не будуть видалені перед поверненням. Буде чекати стільки, скільки вказано у --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- оновити реліз ### Опис {#synopsis} Ця команда оновлює реліз до нової версії чарту. Аргументи для оновлення повинні містити реліз і чарт. Аргумент чарту може бути або: посилання на чарт ('example/mariadb'), шлях до теки з чартом, упакований чарт або повністю кваліфікований URL. Для посилань на чарт буде вказана остання версія, якщо не встановлено прапорець '--version'. Щоб перевизначити значення в чарті, використовуйте або прапорець '--values' та передайте файл, або прапорець '--set' і передайте конфігурацію з командного рядка. Для примусового використання рядкових значень використовуйте '--set-string'. Можна також використовувати '--set-file', щоб задати окремі значення з файлу, коли значення занадто довге для командного рядка або генерується динамічно. Ви також можете використовувати '--set-json', щоб задати json-значення (скаляри/обʼєкти/масиви) з командного рядка. Ви можете вказати прапорець '--values'/'-f' кілька разів. Пріоритет буде надано останньому (правому) файлу. Наприклад, якщо і myvalues.yaml, і override.yaml містять ключ 'Test', значення, задане в override.yaml, матиме пріоритет: ```shell $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis ``` Ви можете вказати прапорець '--set' кілька разів. Пріоритет буде надано останньому (правому) заданому значенню. Наприклад, якщо значення 'bar' і 'newbar' встановлені для ключа 'foo', значення 'newbar' матиме пріоритет: ```shell $ helm upgrade --set foo=bar --set foo=newbar redis ./redis ``` Ви також можете оновити значення для поточного релізу за допомогою цієї команди з прапорцем '--reuse-values'. Аргументи 'RELEASE' і 'CHART' повинні бути встановлені на оригінальні параметри, поточні значення будуть обʼєднані з будь-якими значеннями, заданими через прапорці '--values'/'-f' або '--set'. Пріоритет надається новим значенням. ```shell $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis ``` Прапорець `--dry-run` виведе усі згенеровані маніфести чартів, включно з секретами, які можуть містити конфіденційні значення. Для приховування секретів Kubernetes використовуйте прапорець `--hide-secret`. Будь ласка, уважно вивчіть, як і коли використовувати ці прапорці. ```shell helm upgrade [RELEASE] [CHART] [flags] ``` ### Параметри ```none --atomic якщо встановлено, процес оновлення скасовує зміни у разі невдалого оновлення. Прапорець --wait буде автоматично встановлено, якщо використовується --atomic --ca-file string перевіряти сертифікати HTTPS-серверів, використовуючи цей CA пакет --cert-file string ідентифікувати HTTPS-клієнта, використовуючи цей SSL сертифікат --cleanup-on-fail дозволити видалення нових ресурсів, створених в цьому оновленні, коли оновлення не вдалося --create-namespace якщо встановлено --install, створити простір імен релізу, якщо він не присутній --dependency-update оновити залежності, якщо вони відсутні, перед встановленням чарту --description string додати власний опис --devel використовувати також версії в розробці. Еквівалентно версії '>0.0.0-0'. Якщо вказано --version, це буде проігноровано --disable-openapi-validation якщо встановлено, процес оновлення не буде перевіряти відрендерені шаблони на відповідність Kubernetes OpenAPI Schema --dry-run string[="client"] симулювати установку. Якщо --dry-run встановлено без вказання опції або як '--dry-run=client', не буде спроб зʼєднання з кластером. Встановлення '--dry-run=server' дозволяє спробувати зʼєднання з кластером. --enable-dns увімкнути DNS запити під час рендерингу шаблонів --force примусове оновлення ресурсів через стратегію заміни -h, --help довідка upgrade --hide-notes якщо встановлено, не показувати примітки у виводі встановлення. Не впливає на присутність у метаданих чарту --hide-secret приховати Kubernetes Secrets, якщо також використовується прапорець --dry-run --history-max int обмежити максимальну кількість ревізій, збережених для релізу. Використовуйте 0 для відсутності обмежень (стандартно 10) --insecure-skip-tls-verify пропустити перевірки сертифікатів TLS для завантаження чарту -i, --install якщо реліз з цим імʼям ще не існує, виконується установка --key-file string ідентифікувати HTTPS-клієнта, використовуючи цей файл SSL ключа --keyring string розташування публічних ключів, що використовуються для перевірки (стандартно "~/.gnupg/pubring.gpg") -l, --labels stringToString Мітки, які будуть додані до метаданих релізу. Мають бути розділені комою. Оригінальні мітки релізу будуть обʼєднані з мітками оновлення. Ви можете скинути мітку, використовуючи null. (стандартно []) --no-hooks вимкнути хуки перед/після оновлення -o, --output format друкує вивід у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table) --pass-credentials передати облікові дані всім доменам --password string пароль репозиторію чарту для розташування запитуваного чарту --plain-http використовувати небезпечні HTTP зʼєднання для завантаження чарту --post-renderer postRendererString шлях до виконуваного файлу, що буде використано для пост-рендерингу. Якщо він існує в $PATH, буде використано двійковий файл, інакше буде спробовано знайти виконуваний файл за вказаним шляхом --post-renderer-args postRendererArgsSlice аргумент для пост-рендерера (можна вказати кілька) (стандартно []) --render-subchart-notes якщо встановлено, рендерити нотатки субчарту разом з батьківським чартом --repo string URL репозиторію чарту для розташування запитуваного чарту --reset-then-reuse-values при оновленні, скинути значення до вбудованих у чарт значень, застосувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values' або '--reuse-values', це буде проігноровано --reset-values при оновленні, скинути значення до вбудованих у чарт значень --reuse-values при оновленні, повторно використовувати значення останнього релізу та обʼєднати будь-які перекриття з командного рядка через --set і -f. Якщо вказано '--reset-values', це буде проігноровано --set stringArray встановити значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --set-file stringArray встановити значення з відповідних файлів, зазначених через командний рядок (можна вказати кілька або розділити значення комами: key1=path1,key2=path2) --set-json stringArray встановити JSON значення з командного рядка (можна вказати кілька або розділити значення комами: key1=jsonval1,key2=jsonval2) --set-literal stringArray встановити літеральне STRING значення з командного рядка --set-string stringArray встановити STRING значення з командного рядка (можна вказати кілька або розділити значення комами: key1=val1,key2=val2) --skip-crds якщо встановлено, CRD не будуть встановлені під час виконання оновлення з увімкненим прапорцем install. Стандартно, CRD встановлюються, якщо ще не присутні, під час виконання оновлення з увімкненим прапорцем install --skip-schema-validation якщо встановлено, вимикає перевірку схеми JSON --timeout duration час очікування для будь-якої окремої операції Kubernetes (наприклад, Jobs для хуків) (стандартно 5м0с) --username string імʼя користувача репозиторію чарту для розташування запитуваного чарту -f, --values strings вказати значення у YAML файлі або URL (можна вказати кілька) --verify перевірити пакет перед використанням --version string вказати обмеження версії для версії чарту, яку слід використовувати. Це обмеження може бути конкретною міткою (наприклад, 1.1.1) або може посилатися на дійсний діапазон (наприклад, ^2.0.0). Якщо не вказано, буде використана остання версія --wait якщо встановлено, чекатиме, поки всі Pods, PVC, Services і мінімальна кількість Pods Deployment, StatefulSet або ReplicaSet не перебуватимуть у стані готовності перед поміткою релізу як успішного. Буде чекати стільки, скільки вказано у --timeout --wait-for-jobs якщо встановлено і --wait увімкнено, чекатиме, поки всі Jobs не будуть завершені перед поміткою релізу як успішного. Це буде чекати стільки, скільки вказано у --timeout ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- перевірити, що чарт за вказаним шляхом підписаний і є дійсним ### Опис {#synopsis} Перевірте, чи має вказаний чарт дійсний файл автентичності. Файли автентичності забезпечують криптографічну перевірку того, що чарт не був зміненим і був упакований надійним постачальником. Цю команду можна використовувати для перевірки локального чарту. Декілька інших команд надають прапорці '--verify', які виконують ту ж саму валідацію. Щоб згенерувати підписаний пакет, використовуйте команду 'helm package --sign'. ```shell helm verify PATH [flags] ``` ### Параметри {#options} ```none -h, --help довідка verify --keyring string вєящка ключів, що містить публічні ключі (стандартно "~/.gnupg/pubring.gpg") ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- друкує інформацію про версію клієнта ### Опис {#synopsis} Показує версію для Helm. Команда надрукує представлення версії Helm. Вивід виглядатиме приблизно так: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version — семантична версія релізу. - GitCommit — SHA коміту, з якого була збудована ця версія. - GitTreeState — "clean", якщо при створенні цього бінарного файлу не було локальних змін у коді, і "dirty", якщо бінарний файл був збудований з локально зміненого коду. - GoVersion — версія Go, яка була використана для компіляції Helm. При використанні прапорця --template доступні такі властивості для використання в шаблоні: - .Version містить семантичну версію Helm - .GitCommit — git коміт - .GitTreeState — стан git дерева, коли був збудований Helm - .GoVersion містить версію Go, з якою був зібраний Helm Наприклад, --template='Version: {{.Version}}' надрукує 'Version: v3.2.1'. ```shell helm version [flags] ``` ### Параметри {#options} ```none -h, --help довідка version --short надрукувати номер версії --template string шаблон для формату рядка версії ``` ### Параметри, успадковані від батьківських команд {#options-inherited-from-parent-commands} ```none --burst-limit int стандартні обмеження на стороні клієнта (стандартно 100) --debug увімкнути розширений вивід --kube-apiserver string адреса та порт сервера API Kubernetes --kube-as-group stringArray група для імперсонації під час операції, цей прапор може бути повторений для вказання кількох груп. --kube-as-user string імʼя користувача для імперсонації під час операції --kube-ca-file string файл центру сертифікаці СА для підключення до сервера API Kubernetes --kube-context string імʼя контексту kubeconfig для використання --kube-insecure-skip-tls-verify якщо встановлено true, сертифікат сервера API Kubernetes не буде перевірятися на дійсність. Це робить ваші HTTPS-зʼєднання небезпечними --kube-tls-server-name string імʼя сервера для перевірки сертифіката сервера API Kubernetes. Якщо не вказано, використовується імʼя хоста, що використовується для підключення до сервера --kube-token string токен на предʼявника, який використовується для автентифікації --kubeconfig string шлях до файлу kubeconfig -n, --namespace string простір імен для цього запиту --qps float32 кількість запитів в секунду під час взаємодії з API Kubernetes, не включаючи сплески --registry-config string шлях до файлу конфігурації реєстру (стандартно "~/.config/helm/registry/config.json") --repository-cache string шлях до теки, що містить кешовані індекси репозиторіїв (стандартно "~/.cache/helm/repository") --repository-config string шлях до файлу, що містить імена та URL репозиторіїв (стандартно "~/.config/helm/repositories.yaml") ``` ### ДИВІТЬСЯ ТАКОЖ {#see-also} - [helm](/helm/helm.md) — менеджер пакетів Helm для Kubernetes. ###### Автоматично згенеровано spf13/cobra 11 вересня 2024 ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Команди Helm description: Документація для повного списку команд CLI для Helm. sidebar_position: 6 id: helm-category --- # Команди Helm {#helm-commands} Тут ви знайдете список команд CLI для Helm з інформацією щодо їх використання. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action для автоматизації випуску чартів на GitHub Pages description: Описує, як використовувати Chart Releaser Action для автоматизації випуску чартів через GitHub Pages. sidebar_position: 3 --- Цей посібник описує, як використовувати [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) для автоматизації випуску чартів через GitHub Pages. Chart Releaser Action — це GitHub Action workflow, який перетворює GitHub проєкт на репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). ## Зміни в репозиторії {#repository-changes} Створіть Git-репозиторій у вашій організації на GitHub. Ви можете назвати репозиторій `helm-charts`, хоча також прийнятні інші назви. Джерела всіх чартів можуть бути розміщені на гілці `main`. Чарти повинні бути розміщені в теці `/charts` на верхньому рівні дерева тек. Також має бути інша гілка з назвою `gh-pages`, щоб публікувати чарти. Зміни в цій гілці будуть автоматично створюватися за допомогою Chart Releaser Action, описаного тут. Крім створення гілку `gh-pages` ви можете додати файл `README.md` до неї, який буде видимим користувачам, що відвідують сторінку. Ви можете додати інструкції в `README.md` щодо встановлення чартів, як показано нижче (замініть ``, ``, і ``): ```md ## Використання Щоб використовувати чарти, необхідно встановити [Helm](https://helm.sh/uk). Будь ласка, ознайомтеся з [документацією Helm](https://helm.sh/uk/docs), щоб розпочати. Як тільки Helm буде налаштовано правильно, додайте репозиторій наступним чином: helm repo add https://.github.io/helm-charts Якщо ви вже додавали цей репозиторій раніше, виконайте команду `helm repo update`, щоб отримати останні версії пакетів. Потім ви можете виконати `helm search repo `, щоб побачити чарти. Щоб встановити чарт ``: helm install my- / Щоб видалити чарт: helm uninstall my- ``` Чарти будуть опубліковані на вебсайті з URL-адресою типу: https://.github.io/helm-charts ## GitHub Actions Workflow {#github-actions-workflow} Створіть файл GitHub Actions workflow в гілці `main` за адресою `.github/workflows/release.yml`: ```yaml name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` Наведена конфігурація використовує [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action), щоб перетворити ваш GitHub проєкт на самостійний репозиторій чартів Helm. Вона виконує це під час кожної операції push в гілку `main` шляхом перевірки кожного чарту у вашому проєкті, і коли знаходить нову версію чарту, створює відповідний реліз GitHub, додає артефакти Helm чарту до релізу і створює або оновлює файл `index.yaml` з метаданими про ці релізи, який потім хоститься на GitHub Pages. Версія Chart Releaser Action, використана в наведеному прикладі, — `v1.6.0`. Ви можете змінити її на [останню доступну версію](https://github.com/helm/chart-releaser-action/releases). Примітка: Chart Releaser Action майже завжди використовується в парі з [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) та [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Синхронізація вашого репозиторію чартів description: Описує, як синхронізувати ваші локальні та віддалені репозиторії чартів. sidebar_position: 2 --- *Примітка: Цей приклад для хмарного сховища Google (GCS), яке обслуговує репозиторій чартів.* ## Попередні умови {#prerequisites} * Встановіть інструмент [gsutil](https://cloud.google.com/storage/docs/gsutil). *Ми значною мірою покладаємося на функціональність gsutil rsync.* * Переконайтеся, що у вас є доступ до бінарного файлу Helm. * *Необовʼязково: Ми рекомендуємо встановити [версіювання обʼєктів](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) у вашому сховищі GCS, на випадок, якщо ви випадково щось видалите.* ## Налаштування теки локального репозиторію чартів {#set-up-a-local-chart-repository-directory} Створіть локальну теку, як ми це робили в [керівництві з репозиторію чартів](/topics/chart_repository.md), і помістіть ваші упаковані чарти в цю теку. Наприклад: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Генерація оновленого файлу index.yaml {#generate-an-updated-index.yaml} Використовуйте Helm для генерації оновленого файлу index.yaml, передавши шлях до теки та URL-адресу віддаленого репозиторію команді `helm repo index`, як показано нижче: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` Це згенерує оновлений файл index.yaml і помістить його в теку `fantastic-charts/`. ## Синхронізація ваших локальних та віддалених репозиторіїв чартів {#sync-your-local-and-remote-chart-repositories} Завантажте вміст теки у ваше сховище GCS, запустивши `scripts/sync-repo.sh` та передавши назву локальної теки та назву сховища GCS. Наприклад: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Оновлення вашого репозиторію чартів {#updating-your-chart-repository} Ви захочете зберегти локальну копію вмісту вашого репозиторію чартів або використати `gsutil rsync` для копіювання вмісту вашого віддаленого репозиторію чартів до локальної теки. Наприклад: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # прапорець -n виконує пробний запуск Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # виконує дії копіювання Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Корисні посилання: * Документація щодо [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Керівництво репозиторію чартів](/topics/chart_repository.md) * Документація щодо [версіювання обʼєктів та керування паралельністю](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) у хмарному сховищі Google ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Поради та підказки для розробки чартів description: >- Містить деякі поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості. sidebar_position: 1 --- Цей посібник містить поради та підказки, про які розробники чартів Helm дізнались під час створення чартів промислової якості. ## Знайомство з функціями шаблону {#know-your-template-functions} Helm використовує [шаблони Go](https://godoc.org/text/template) для шаблонування ваших ресурсних файлів. Хоча Go поставляється з кількома вбудованими функціями, ми додали багато інших. По-перше, ми додали всі функції з [бібліотеки Sprig](https://masterminds.github.io/sprig/), за винятком `env` і `expandenv`, з міркувань безпеки. Ми також додали дві спеціальні функції шаблонів: `include` і `required`. Функція `include` дозволяє додавати інший шаблон і передавати результати іншим функціям шаблонів. Наприклад, цей фрагмент шаблону включає шаблон з назвою `mytpl`, потім приводить результат у нижньому регістрі та обертає його в подвійні лапки. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` Функція `required` дозволяє оголосити певний запис значення обовʼязковим для рендерингу шаблону. Якщо значення порожнє, рендеринг шаблону завершиться з повідомленням про помилку, наданим користувачем. Наступний приклад використання функції `required` оголошує запис для `.Values.who` обовʼязковим і виводить повідомлення про помилку, якщо цього запису не вистачає: ```yaml value: {{ required "Потрібен дійсний запис .Values.who!" .Values.who }} ``` ## Використовуйте лапки для рядків, не використовуйте лапки для цілих чисел {#quote-strings-don-t-quote-integers} Коли ви працюєте з рядковими даними, завжди безпечніше використовувати лапки для рядків, ніж залишати їх без лапок: ```yaml name: {{ .Values.MyName | quote }} ``` Але при роботі з цілими числами _не беріть значення в лапки._ Це може викликати помилки парсингу всередині Kubernetes. ```yaml port: {{ .Values.Port }} ``` Це зауваження не стосується значень змінних середовища, які повинні бути рядками, навіть якщо вони представляють цілі числа: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Використання функції `include` {#using-the-include-function} Go надає спосіб включати один шаблон в інший за допомогою вбудованої директиви `template`. Однак вбудована функція не може використовуватися в конвеєрах шаблонів Go. Щоб включити шаблон і виконати операцію з його результатом, Helm має спеціальну функцію `include`: ```yaml {{ include "toYaml" $value | indent 2 }} ``` Вищезазначене включає шаблон з назвою `toYaml`, передає йому `$value`, а потім передає результат з цього шаблону у функцію `indent`. Оскільки в YAML важливі відступи, це чудовий спосіб включати фрагменти коду, зберігаючи відступи в релевантному контексті. ## Використання функції `required` {#using-the-required-function} Go надає спосіб налаштувати опції шаблону для керування поведінкою при зверненні до ключа, якого немає в map. Це зазвичай налаштовується за допомогою `template.Options("missingkey=option")`, де `option` може бути `default`, `zero` або `error`. Якщо встановити цю опцію з помилкою, виконання зупиниться з помилкою, але це стосуватиметься кожного відсутнього ключа в map. Можуть бути ситуації, коли розробник чарту захоче застосувати цю поведінку лише для певних значень у файлі `values.yaml`. Функція `required` дає розробникам можливість оголосити значення обовʼязковим для роботи в шаблоні. Якщо значення відсутнє в `values.yaml`, шаблон повертає повідомлення про помилку, надане розробником. Наприклад: ```yaml {{ required "Потрібен дійсний foo!" .Values.foo }} ``` Наведена вище конструкція використає шаблон, коли `.Values.foo` визначено, але не зможе це зробити та вийде з помилкою, коли `.Values.foo` не визначено. ## Використання функції `tpl` {#using-the-tpl-function} Функція `tpl` дозволяє розробникам оцінювати рядки як шаблони всередині іншого шаблону. Це корисно для передачі рядка шаблону як значення до чарту або використання зовнішніх конфігураційних файлів. Синтаксис: `{{ tpl TEMPLATE_STRING VALUES }}`. Приклади: ```yaml # значення template: "{{ .Values.name }}" name: "Tom" # шаблон {{ tpl .Values.template . }} # результат Tom ``` Використання зовнішнього конфігураційного файлу: ```yaml # зовнішній конфігураційний файл conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # значення firstName: Peter lastName: Parker # шаблон {{ tpl (.Files.Get "conf/app.conf") . }} # результат firstName=Peter lastName=Parker ``` ## Створення секретів для отримання образів {#creating-image-pull-secrets} Секрети для отримання образів по суті є комбінацією _registry_, _username_ та _password_. Вони можуть знадобитися у застосунку, який ви розгортаєте, але для їх створення потрібно кілька разів запустити `base64`. Ми можемо написати допоміжний шаблон, щоб скласти файл конфігурації Docker для використання у вигляді даних для секрету. Ось приклад: По-перше, припустимо, що облікові дані визначені у файлі `values.yaml` наступним чином: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` Ми визначаємо наш допоміжний шаблон наступним чином: ```go {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Нарешті, ми використовуємо допоміжний шаблон у більшому шаблоні для створення маніфесту секрету: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Автоматичне викатування розгортань {#automatically-roll-deployments} Часто ConfigMaps або Secrets підключаютсья як конфігураційні файли в контейнери або є інші зовнішні зміни залежностей, які вимагають перезапуску podʼів. Залежно від застосунку, перезапуск може знадобитися, якщо вони оновлюються при наступному `helm upgrade`, але якщо самі специфікації deployment не змінюються, застосунок продовжує працювати зі старою конфігурацією, що призводить до неконсистентного deployment. Функція `sha256sum` може бути використана для забезпечення оновлення секції анотацій розгортання, якщо змінюється інший файл: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` ПРИМІТКА: Якщо ви додаєте це до бібліотечного чарту, ви не зможете отримати доступ до вашого файлу в `$.Template.BasePath`. Замість цього можна посилатися на ваше визначення за допомогою `{{ include ("mylibchart.configmap") . | sha256sum }}`. У випадку, коли ви завжди хочете перезапустити свій deployment, ви можете використати аналогічний крок з анотацією, як вище, замінивши його випадковим рядком, щоб він завжди змінювався і викликав перезапуск deployment: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Кожен виклик функції шаблону генеруватиме унікальний випадковий рядок. Це означає, що якщо необхідно синхронізувати випадкові рядки, що використовуються декількома ресурсами, всі відповідні ресурси повинні бути в одному файлі шаблону. Обидва ці методи дозволяють вашому deployment використовувати вбудовану логіку стратегії оновлення, щоб уникнути простоїв. ПРИМІТКА: Раніше ми рекомендували використовувати прапорець `--recreate-pods` як інший варіант. Цей прапорець було позначено застарілим у Helm 3 на користь більш декларативного методу, описаного вище. ## Скажіть Helm не видаляти ресурс {#tell-helm-not-to-uninstall-a-resource} Іноді є ресурси, які не слід видаляти під час виконання команди `helm uninstall`. Розробники чартів можуть додати анотацію до ресурсу, щоб запобігти його видаленню. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` Анотація `helm.sh/resource-policy: keep` говорить Helm не видаляти цей ресурс, коли операція Helm (така як `helm uninstall`, `helm upgrade` або `helm rollback`) призвела б до його видалення. _Однак_, цей ресурс стає сиротою. Helm більше не керує ним у будь-який спосіб. Це може призвести до проблем, якщо використовувати `helm install --replace` для релізу, який вже був видалений, але зберіг ресурси. ## Використання "Partials" та включень шаблонів {#using-partials-and-template-includes} Іноді ви хочете створити деякі багаторазові частини у вашому чарті, незалежно від того, чи це блоки або часткові шаблони. І часто, чистіше зберігати їх у власних файлах. У теці `templates/`, будь-який файл, що починається з підкреслення (`_`), не призначений для виведення файлу маніфесту Kubernetes. Таким чином, за домовленістю, допоміжні шаблони та часткові шаблони розміщуються у файлі `_helpers.tpl`. ## Складні чарти з багатьма залежностями {#complex-charts-with-many-dependencies} Багато чартів у CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) є "будівельними блоками" для створення складніших застосунків. Але чарти можуть бути використані для створення екземплярів великомасштабних застосунків. У таких випадках один основний чарт може мати декілька вкладених субчартів, кожен з яких функціонує як частина цілого. Найкращою практикою для збирання складного застосунку з окремих частин є створення основного чарту, який надає глобальні конфігурації, а потім використання підтеки `charts/` для вбудовування кожного з компонентів. ## YAML — це надмножина JSON {#yaml-is-a-superset-of-json} Згідно зі специфікацією YAML, YAML є надмножиною JSON. Це означає, що будь-яка допустима структура JSON має бути дійсною в YAML. Це має перевагу: іноді розробникам шаблонів може бути простіше виразити структуру даних з синтаксисом, схожим на JSON, ніж мати справу з чутливістю YAML до пробілів. Як правило, шаблони повинні відповідати синтаксису, схожому на YAML, _якщо_ синтаксис JSON суттєво не знижує ризик виникнення проблем з форматуванням. ## Будьте обережні з генерацією випадкових значень {#be-careful-with-generating-random-values} У Helm є функції, які дозволяють генерувати випадкові дані, криптографічні ключі тощо. Вони цілком придатні для використання. Але майте на увазі, що під час оновлень шаблони виконуються знову. Коли виконання шаблону генерує дані, що відрізняються від останнього виконання, це викликає оновлення цього ресурсу. ## Встановлення або оновлення релізу однією командою Helm надає можливість виконати встановлення або оновлення як одну команду. Використовуйте `helm upgrade` з командою `--install`. Це змусить Helm перевірити, чи реліз вже встановлено. Якщо ні, буде виконано встановлення. Якщо так, то наявний реліз буде оновлено. ```console $ helm upgrade --install <назва релізу> --values <файл значень> <тека чарту> ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: Поради sidebar_position: 2 --- --- ### Поради {#how-to-guides} Тут ви знайдете короткі відповіді на питання типу «Як я можу….?» Ці посібники не охоплюють теми в деталях — ви знайдете такі матеріали в [Тематичних посібниках](/topics/index.mdx). Однак ці посібники допоможуть вам швидко виконати поширені завдання. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "Документація" description: "Все, що вам потрібно знати про те, як організована документація." --- # Ласкаво просимо {#welcome} Ласкаво просимо до документації [Helm](https://helm.sh/). Helm — це менеджер пакунків для Kubernetes, і ви можете прочитати детальну довідкову інформацію у [звіті CNCF Helm Project Journey](https://www.cncf.io/cncf-helm-project-journey/). # Як організована документація {#how-the-documentation-is-organized} Helm має багато документації. Загальний огляд того, як все організовано допоможе вам зрозуміти, де шукати певні речі: - [Підручники](/chart_template_guide/getting_started.md) проведуть вас через низку кроків для створення вашого першого чарту Helm. Почніть тут, якщо ви новачок у Helm. - [Тематичні посібники](/topics/index.mdx) обговорюють ключові теми та концепції на досить високому рівні та надають корисну довідкову інформацію та пояснення. - [Настанови для спільноти](/community) обговорюють теми, повʼязані зі спільнотою Helm. Почніть тут, якщо ви хочете дізнатися більше про процес розробки Helm і про те, як ви можете до нього долучитися. - [Посібники](/howto/index.mdx) — це рецепти. Вони проведуть вас через кроки, повʼязані з розвʼязанням ключових проблем та варіантів використання. Вони більш докладні, ніж підручників і передбачають певні знання про те, як працює Helm. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: Шпаргалка description: Шпаргалка Helm sidebar_position: 4 --- Підказка Helm з усіма необхідними командами для керування програмою через Helm. --- ### Основні інтерпретації/контекст {#basic-interpretations-context} **Chart (Чарт):** - Це назва вашого чарту у випадку, якщо його було завантаженла та розпаковано. - Це `/`, якщо репозиторій був доданий, але чарт не завантажений. - Це URL/Абсолютний шлях до чарту. **Name (Назва):** - Це назва, яку ви хочете надати вашій поточній установці Helm-чарту. **Release (Реліз):** - Це назва, яку ви присвоїли екземпляру установки. **Revision (Версія):** - Це значення з команди Helm history. **Repo-name (Назва репозиторію):** - Назва репозиторію. **DIR (Тека):** - Назва/шлях теки. --- ### Управління чартами {#chart-management} ```bash helm create # Створює теку чарту разом з загальними файлами та теками, які використовуються в чарті. helm package # Упаковує чарт у файл архіву з версією. helm lint # Запускає тести для перевірки чарту та виявлення можливих проблем. helm show all # Переглядає чарт та виводить його вміст. helm show values # Показує вміст файлу values.yaml. helm pull # Завантажує/витягує чарт. helm pull --untar=true # Якщо встановлено в true, розпаковує чарт після завантаження. helm pull --verify # Перевіряє пакет перед використанням. helm pull --version # СТандартно використовується остання версія, вкажіть обмеження версії для використання чарту. helm dependency list # Відображає список залежностей чарту. ``` --- ### Встановлення та видалення застосунків {#install-and-uninstall-apps} ```bash helm install # Встановлює чарт з зазначеною назвою. helm install --namespace # Встановлює чарт у певному просторі імен. helm install --set key1=val1,key2=val2 # Встановлює значення в командному рядку (можна вказати кілька значень, розділених комами). helm install --values # Встановлює чарт з вказаними вами значеннями. helm install --dry-run --debug # Запускає тестове встановлення для перевірки чарту. helm install --verify # Перевіряє пакет перед використанням. helm install --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. helm uninstall # Видаляє реліз. ``` --- ### Оновлення застосунків та відкат {#perform-app-upgrade-and-rollback} ```bash helm upgrade # Оновлює реліз. helm upgrade --atomic # Якщо встановлено, процес оновлення поверне зміни в разі невдалого оновлення. helm upgrade --dependency-update # Оновлює залежності, якщо вони відсутні, перед встановленням чарту. helm upgrade --version # Вказує обмеження версії для використання чарту. helm upgrade --values # Вказує значення у YAML файлі або URL (можна вказати кілька). helm upgrade --set key1=val1,key2=val2 # Встановлює значення d командному рядку (можна вказати кілька значень). helm upgrade --force # Примусове оновлення ресурсів через стратегію заміни. helm rollback # Повертає реліз до певної версії. helm rollback --cleanup-on-fail # Дозволяє видалення нових ресурсів, створених під час цього відкату, якщо відкат не вдалося здійснити. ``` --- ### Вивід списку, додавання, видалення та оновлення репозиторіїв {#list-add-remove-and-update-repositories} ```bash helm repo add # Додає репозиторій з Інтернету. helm repo list # Переглядає список доданих репозиторіїв чартів. helm repo update # Оновлює інформацію про доступні чарти локально з репозиторіїв чартів. helm repo remove # Видаляє один або кілька репозиторіїв чартів. helm repo index # Читає поточну теку та генерує файл індексу на основі знайдених чартів. helm repo index --merge # Зливає згенерований індекс з існуючим файлом індексу. helm search repo # Шукає в репозиторіях за ключовим словом в чарті. helm search hub # Шукає чарт в Artifact Hub або у вашому власному хабі. ``` --- ### Моніторинг релізів Helm {#helm-release-monitoring} ```bash helm list # Переглядає всі релізи для вказаного простору імен, використовує поточний контекст простору імен, якщо простір не вказано. helm list --all # Показує всі релізи без жодних фільтрів, можна використовувати -a. helm list --all-namespaces # Переглядає релізи по всіх просторах імен, можна використовувати -A. helm list -l key1=value1,key2=value2 # Селектор (запит за мітками) для фільтрації, підтримує '=', '==' і '!='. helm list --date # Сортує за датою релізу. helm list --deployed # Показує розгорнуті релізи. Якщо не вказано інше, це буде автоматично увімкнено. helm list --pending # Показує очікуючі релізи. helm list --failed # Показує невдалі релізи. helm list --uninstalled # Показує видалені релізи (якщо використовувався 'helm uninstall --keep-history'). helm list --superseded # Показує замінені релізи. helm list -o yaml # Виводить результат у вказаному форматі. Дозволені значення: table, json, yaml (стандартно table). helm status # Ця команда показує статус зазначеного релізу. helm status --revision # Якщо встановлено, відображає статус зазначеного релізу з версією. helm history # Історичні версії для даного релізу. helm env # Env виводить всю інформацію про середовище, що використовується Helm. ``` --- ### Завантаження інформації про реліз {#download-release-information} ```bash helm get all # Колекція інформації про нотатки, хуки, надані значення та згенерований маніфест файлу для вказаного релізу. helm get hooks # Завантажує хуки для вказаного релізу. Хуки форматує у YAML і розділяє за допомогою роздільника YAML '---\n'. helm get manifest # Маніфест є YAML-кодованим поданням ресурсів Kubernetes, що були згенеровані з цього релізу чарту. Якщо чарт залежить від інших чартів, ці ресурси також будуть включені в маніфест. helm get notes # Показує нотатки, надані чартом для зазначеного релізу. helm get values # Завантажує файл значень для даного релізу. Використовуйте -o для форматування виходу. ``` --- ### Управління втулками {#plugin-management} ```bash helm plugin install # Встановлення втулків. helm plugin list # Перегляд списку всіх встановлених втулків. helm plugin update # Оновлення втулків. helm plugin uninstall # Видалення втулка. ``` --- ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: Вступ sidebar_position: 1 --- # Введення в Helm {#introduction-to-helm} Ви новачок у Helm? Це місце, з якого варто почати! import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: Встановлення Helm description: Дізнайтеся, як встановити та розпочати роботу з Helm. sidebar_position: 2 --- Цей посібник показує, як встановити Helm CLI. Helm можна встановити або з джерела, або з попередньо зібраних бінарних релізів. ## Від проєкту Helm {#from-the-helm-project} Проєкт Helm надає два способи отримання та встановлення Helm. Це офіційні методи отримання релізів Helm. Крім того, спільнота Helm пропонує методи встановлення Helm через різні менеджери пакетів. Встановлення через ці методи можна знайти нижче офіційних методів. ### З бінарних релізів {#from-the-binary-releases} Кожен [реліз](https://github.com/helm/helm/releases) Helm надає бінарні релізи для різних операційних систем. Ці бінарні версії можна завантажити та встановити вручну. 1. Завантажте [бажану версію](https://github.com/helm/helm/releases) 2. Розпакуйте її (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Знайдіть бінарний файл `helm` у розпакованій директорії та перемістіть його в потрібне місце (`mv linux-amd64/helm /usr/local/bin/helm`) Після цього ви повинні мати можливість запускати клієнт і [додати стабільний репозиторій чарту](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Примітка:** Автоматизовані тести Helm виконуються лише для Linux AMD64 під час GitHub Actions збірок та релізів. Тестування інших операційних систем є відповідальністю спільноти, якій потрібен Helm для цієї операційної системи. ### Зі сценарію {#from-script} Тепер Helm має скрипт інсталятора, який автоматично завантажує останню версію Helm і [встановлює її локально](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). Ви можете завантажити цей скрипт, а потім виконати його локально. Він добре задокументований, щоб ви могли ознайомитися з ним і зрозуміти, що він робить перед його запуском. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Так, ви можете виконати `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`, якщо хочете жити на межі. ## Через менеджери пакетів {#through-package-managers} Спільнота Helm надає можливість встановити Helm через менеджери пакетів операційних систем. Ці методи не підтримуються проєктом Helm і не вважаються надійними третіми сторонами. ### Через Homebrew (macOS) {#from-homebrew-macos} Члени спільноти Helm додали формулу Helm до Homebrew. Ця формула зазвичай оновлюється. ```console brew install helm ``` (Примітка: Також існує формула для emacs-helm, яка є іншим проєктом.) ### Через Chocolatey (Windows) {#from-chocolatey-windows} Члени спільноти Helm додали [пакет Helm](https://chocolatey.org/packages/kubernetes-helm) до [Chocolatey](https://chocolatey.org/). Цей пакет зазвичай оновлюється. ```console choco install kubernetes-helm ``` ### Через Scoop (Windows) {#from-scoop-windows} Члени спільноти Helm додали [пакет Helm](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) до [Scoop](https://scoop.sh). Цей пакет зазвичай оновлюється. ```console scoop install helm ``` ### Через Winget (Windows) {#from-winget-windows} Члени спільноти Helm додали [пакет Helm](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) до [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). Цей пакет зазвичай оновлюється. ```console winget install Helm.Helm ``` ### Через Apt (Debian/Ubuntu) {#from-apt-debian-ubuntu} Члени спільноти Helm додали [пакет Helm](https://helm.baltorepo.com/stable/debian/) для Apt. Цей пакет зазвичай оновлюється. ```console curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null sudo apt-get install apt-transport-https --yes echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### Через dnf/yum (fedora) {#from-dnf-yum-fedora} Починаючи з Fedora 35, helm доступний в офіційному репозиторії. Ви можете встановити helm, виконавши: ```console sudo dnf install helm ``` ### Через Snap {#from-snap} Спільнота [Snapcrafters](https://github.com/snapcrafters) підтримує версію Snap пакету [Helm](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### Через pkg (FreeBSD) {#from-pkg-freebsd} Члени спільноти FreeBSD додали [пакет Helm](https://www.freshports.org/sysutils/helm) до [Колекції портів FreeBSD](https://man.freebsd.org/ports). Цей пакет зазвичай оновлюється. ```console pkg install helm ``` ### Збірки для розробників {#development-builds} Окрім релізів, ви можете завантажити або встановити розробницькі версії Helm. ### З Canary збірок {#from-canary-builds} "Canary" збірки — це версії програмного забезпечення Helm, які створюються з останньої гілки `main`. Вони не є офіційними релізами та можуть бути нестабільними. Однак, вони надають можливість тестувати найновіші функції. Canary бінарні файли Helm зберігаються на [get.helm.sh](https://get.helm.sh). Ось посилання на основні збірки: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Експериментальний Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### З сирців (Linux, macOS) {#from-source} Збірка Helm з сирців є дещо більш трудомісткою, але це найкращий спосіб, якщо ви хочете тестувати найновішу (передрелізну) версію Helm. У вас повинно бути налаштоване середовище Go. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` За необхідності, будуть завантажені залежності та збережені в кеші, а також перевірено конфігурацію. Після цього `helm` буде скомпільований і розміщений у `bin/helm`. ## Підсумки {#conclusion} У більшості випадків, встановлення настільки просте, як отримання попередньо зібраного бінарного файлу `helm`. Цей документ охоплює додаткові випадки для тих, хто хоче робити складніші речі з Helm. Після успішного встановлення клієнта Helm, ви можете перейти до використання Helm для керування чартами та [додавання стабільного репозиторію чартів](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: Швидкий старт description: Як встановити та почати роботу з Helm, включаючи інструкції для дистрибутивів, поширені запитання та втулки. sidebar_position: 1 --- У цьому посібнику ви дізнаєтеся, як швидко почати користуватися Helm. ## Попередні умови {#prerequisites} Для успішного та належного використання Helm потрібні наступні умови. 1. Кластер Kubernetes 2. Визначення, які конфігурації безпеки застосувати до вашої інсталяції, якщо такі є 3. Встановлення та налаштування Helm. ### Встановлення Kubernetes або доступ до кластера {#install-kubernetes-or-have-access-to-a-cluster} - У вас повинен бути встановлений Kubernetes. Для останньої версії Helm ми рекомендуємо використовувати останню стабільну версію Kubernetes, що в більшості випадків є передостанньою мінорною версією. - У вас також має бути локально налаштована копія `kubectl`. Дивіться [Політику підтримки версій Helm](/topics/version_skew.md) щодо максимальної підтримуваної різниці версій між Helm і Kubernetes. ## Встановлення Helm {#install-helm} Завантажте бінарний реліз клієнта Helm. Ви можете використовувати такі інструменти, як `homebrew`, або перегляньте [сторінку офіційних релізів](https://github.com/helm/helm/releases). Для отримання більш детальної інформації або інших варіантів, дивіться [посібник з встановлення](/intro/install.md). ## Ініціалізація репозиторію Helm Chart {#initialize-a-helm-chart-repository} Як тільки Helm буде готовий, ви можете додати репозиторій чартів. Перевірте [Artifact Hub](https://artifacthub.io/packages/search?kind=0) для доступних репозиторіїв чартів Helm. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Після цього ви зможете переглянути доступні для встановлення чарти: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... і багато інших ``` ## Встановлення прикладу чарту {#install-an-example-chart} Для встановлення чарту можна використати команду `helm install`. Helm пропонує кілька способів знаходження та встановлення чарту, але найпростіший — це використання чартів від `bitnami`. ```console $ helm repo update # Переконайтеся, що ви отримали останній список чартів $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` У наведеному вище прикладі чарт `bitnami/mysql` було розгорнуто, а імʼя нашого нового релізу — `mysql-1612624192`. Ви можете отримати уявлення про можливості цього чарту MySQL, виконавши команду `helm show chart bitnami/mysql`. Або ви можете виконати `helm show all bitnami/mysql`, щоб отримати всю інформацію про чарт. Кожного разу, коли ви встановлюєте чарт, створюється новий реліз. Отже, один чарт може бути встановлений кілька разів у тому ж кластері. І кожен може керуватися та оновлюватися незалежно. Команда `helm install` є дуже потужною з багатьма можливостями. Щоб дізнатися більше про неї, перегляньте [Посібник з використання Helm](/intro/using_helm.md). ## Дізнайтеся про релізи {#learn-about-releases} Дуже просто побачити, що було розгорнуто за допомогою Helm: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` Функція `helm list` (або `helm ls`) покаже вам список усіх розгорнутих релізів. ## Видалення релізу {#uninstall-a-release} Щоб видалити реліз, скористайтеся командою `helm uninstall`: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` Це видалить `mysql-1612624192` з Kubernetes, що видалить всі ресурси, повʼязані з релізом, а також історію релізу. Якщо буде надано прапорець `--keep-history`, історія релізу буде збережена. Ви зможете запитувати інформацію про цей реліз: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Оскільки Helm відстежує ваші релізи навіть після того, як ви їх видалили, ви можете переглядати історію кластера і навіть відновити реліз (за допомогою `helm rollback`). ## Ознайомлення з довідкою {#reading-the-help-text} Щоб дізнатися більше про доступні команди Helm, використовуйте `helm help` або введіть команду з прапорцем `-h`: ```console $ helm get -h ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: Використання Helm description: Описує основи роботи з Helm. sidebar_position: 3 --- Цей посібник пояснює основи використання Helm для керування пакетами у вашому кластері Kubernetes. Передбачається, що ви вже [встановили](/intro/install.md) клієнт Helm. Якщо вас цікавить лише виконання кількох швидких команд, можливо, ви захочете почати з [Посібника зі швидкого старту](/intro/quickstart.md). У цьому розділі розглядаються особливості команд Helm та пояснюється, як використовувати Helm. ## Три головні концепції {#three-big-concepts} *Chart* — це пакет Helm. Він містить усі необхідні визначення ресурсів для запуску застосунку, інструменту або сервісу всередині кластера Kubernetes. Думайте про це як про еквівалент формули Homebrew, пакету Apt dpkg або файлу Yum RPM для Kubernetes. *Repository* — це місце, де можна зібрати та поділитися чартами. Це як [архів CPAN](https://www.cpan.org) для Perl або [база пакетів Fedora](https://src.fedoraproject.org/), але для пакетів Kubernetes. *Release* — це екземпляр чарту, що працює в кластері Kubernetes. Один чарт можна встановити в кластер кілька разів. І кожного разу при встановленні створюється новий *реліз*. Наприклад, чарт MySQL. Якщо ви хочете, щоб у вашому кластері працювали дві бази даних, ви можете встановити цей чарт двічі. Кожен екземпляр матиме свій *реліз*, а також своє *імʼя релізу*. Маючи ці концепції на увазі, можна пояснити Helm так: Helm встановлює *чарти* у Kubernetes, створюючи новий *реліз* для кожного встановлення. А щоб знайти нові чарти, ви можете шукати їх у *репозиторіях чартів* Helm. ## 'helm search': Пошук чартів {#helm-search-finding-charts} Helm постачається з потужною командою пошуку. Її можна використовувати для пошуку двох типів джерел: - `helm search hub` здійснює пошук у [Artifact Hub](https://artifacthub.io), який містить чарти helm із десятків різних репозиторіїв. - `helm search repo` здійснює пошук у репозиторіях, які ви додали до свого локального клієнта helm (за допомогою `helm repo add`). Цей пошук здійснюється за локальними даними, і підключення до публічної мережі не потрібно. Ви можете знайти загальнодоступні чарти, виконавши команду `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Платформа для веб-публікацій для створення блогів і ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Чарт Helm для розгортання сайту WordPress на ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 Оператор WordPress для Helm ``` Вищенаведений пошук знаходить усі чарти `wordpress` в Artifact Hub. Без фільтрації `helm search hub` показує всі доступні чарти. `helm search hub` показує URL-адресу розташування на [artifacthub.io](https://artifacthub.io/), але не власне репозиторій Helm. `helm search hub --list-repo-url` показує фактичну URL-адресу репозиторію Helm, що може бути корисним, коли ви хочете додати новий репозиторій: `helm repo add [NAME] [URL]`. За допомогою `helm search repo` ви можете знайти імена чартів у репозиторіях, які ви вже додали: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search використовує алгоритм нечіткого порівняння рядків, тому можна вводити частини слів або фраз: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Пошук — це чудовий спосіб знайти доступні пакети. Коли ви знайшли потрібний пакет, можете використовувати `helm install`, щоб встановити його. ## 'helm install': Встановлення пакета {#helm-install-installing-a-package} Щоб встановити новий пакет, скористайтеся командою `helm install`. У найпростішому випадку вона приймає два аргументи: Імʼя релізу, яке ви вибираєте, та імʼя чарту, який ви хочете встановити. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Вт Січ 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Будь ласка, будьте терплячими, поки чарт розгортається ** Ваш сайт WordPress можна відкрити за наступною DNS-адресою зсередини вашого кластера: happy-panda-wordpress.default.svc.cluster.local (порт 80) Щоб отримати доступ до вашого сайту WordPress з-за меж кластера, дотримуйтесь наступних кроків: 1. Отримайте URL WordPress, виконавши наступні команди: ПРИМІТКА: Може знадобитися кілька хвилин для отримання IP-адреси LoadBalancer. Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "URL WordPress: http://$SERVICE_IP/" echo "Адмінка WordPress: http://$SERVICE_IP/admin" 2. Відкрийте оглядач та отримайте доступ до WordPress, використовуючи отриманий URL. 3. Увійдіть за допомогою наступних облікових даних: echo Логін: user echo Пароль: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Тепер чарт `wordpress` встановлено. Зверніть увагу, що встановлення чарту створює новий *реліз* обʼєкта. Реліз вище називається `happy-panda`. (Якщо ви хочете, щоб Helm згенерував імʼя для вас, не вказуйте імʼя релізу і використовуйте `--generate-name`.) Під час встановлення клієнт `helm` надасть корисну інформацію про те, які ресурси були створені, який стан релізу, і чи є додаткові кроки конфігурації, які ви можете або повинні виконати. Helm встановлює ресурси в наступному порядку: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService Helm не чекає, поки всі ресурси будуть запущені, перш ніж завершити роботу. Багато чартів потребують Docker-образів розміром понад 600MB, і їхнє встановлення в кластер може тривати певний час. Щоб відстежувати стан релізу або повторно прочитати конфігураційну інформацію, ви можете використати команду `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Будь ласка, будьте терплячими, поки чарт розгортається ** Ваш сайт WordPress можна відкрити за наступною DNS-адресою в межах вашого кластера: happy-panda-wordpress.default.svc.cluster.local (порт 80) Щоб отримати доступ до вашого сайту WordPress ззовні кластера, виконайте наступні дії: 1. Отримайте URL WordPress, виконавши ці команди: ЗАУВАЖЕННЯ: Для появи IP LoadBalancer може знадобитися кілька хвилин. Слідкуйте за статусом за допомогою: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Відкрийте оглядач і перейдіть на WordPress, використовуючи отриманий URL. 3. Увійдіть за допомогою наведених нижче облікових даних, щоб побачити ваш блог: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Вищенаведене показує поточний стан вашого релізу. ### Налаштування чарту перед встановленням {#customizing-the-chart-before-installing} Встановлення у спосіб, який ми розглянули, використовуватиме лише стандартні параметри конфігурації для цього чарту. У багатьох випадках вам захочеться налаштувати чарт для використання ваші налаштування. Щоб побачити, які параметри можна налаштувати в чарті, використовуйте команду `helm show values`: ```console $ helm show values bitnami/wordpress ## Параметри глобального Docker-образу ## Зверніть увагу, що це перевизначить параметри образу, включаючи залежності, налаштовані на використання глобального значення ## Наявні глобальні параметри Docker-образу: imageRegistry та imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Версія образу Bitnami WordPress ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` Ви можете перевизначити будь-які з цих налаштувань у файлі у форматі YAML, а потім передати цей файл під час встановлення. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` Вищенаведене створить стандартного користувача MariaDB з імʼям `user0` і надасть цьому користувачеві доступ до новоствореної бази даних `user0db`, але всі інші параметри цього чарту залишаться стандартними. Існує два способи передати дані конфігурації під час встановлення: - `--values` (або `-f`): Вказати YAML-файл із перевизначеннями. Їх можна вказувати кілька разів, причому файл, що стоїть праворуч, матиме пріоритет - `--set`: Вказати перевизначення в командному рядку. Якщо обидва варіанти використовуються, значення `--set` зливаються з `--values` з вищим пріоритетом. Перевизначення, зазначені за допомогою `--set`, зберігаються у Secret. Значення, що були встановлені через `--set`, можна переглянути для конкретного релізу за допомогою команди `helm get values `. Значення, встановлені за допомогою `--set`, можна скинути, виконавши `helm upgrade` з параметром `--reset-values`. #### Формат і обмеження параметра `--set` {#the-format-and-limitations-of-set} Опція `--set` приймає нуль або більше пар імʼя/значення. У найпростішому випадку вона використовується так: `--set name=value`. Еквівалент у YAML виглядає так: ```yaml name: value ``` Кілька значень розділяються символами `,`. Отже, `--set a=b,c=d` стає: ```yaml a: b c: d ``` Підтримуються складніші вирази. Наприклад, `--set outer.inner=value` перетворюється на наступне: ```yaml outer: inner: value ``` Списки можна записати, включивши значення в `{` і `}`. Наприклад, `--set name={a, b, c}` перетворюється на: ```yaml name: - a - b - c ``` Деякі пари імʼя/ключ можна встановити як `null` або як порожній масив `[]`. Наприклад, `--set name=[],a=null` перетворюється на: ```yaml name: [] a: null ``` Починаючи з Helm 2.5.0, можна отримувати доступ до елементів списку, використовуючи синтаксис індексу масиву. Наприклад, `--set servers[0].port=80` стає: ```yaml servers: - port: 80 ``` Кілька значень можна встановити таким чином. Наприклад, рядок `--set servers[0].port=80,servers[0].host=example` перетворюється на: ```yaml servers: - port: 80 host: example ``` Іноді вам потрібно використовувати спеціальні символи у ваших рядках `--set`. Ви можете використовувати зворотний слеш для екранування символів; `--set name=value1\,value2` перетвориться на: ```yaml name: "value1,value2" ``` Аналогічно, можна екранувати послідовності крапок, що може знадобитися, коли чарти використовують функцію `toYaml` для аналізу анотацій, міток і вибору вузлів. Синтаксис для `--set nodeSelector."kubernetes\.io/role"=master` виглядає так: ```yaml nodeSelector: kubernetes.io/role: master ``` Глибоко вкладені структури даних можуть бути складними для виразу через `--set`. Розробникам чартів рекомендується враховувати використання `--set` при розробці формату файлу `values.yaml` (докладніше про [Файли значень](/chart_template_guide/values_files.md)). ### Інші методи встановлення {#more-installation-methods} Команда `helm install` може встановлювати чарт із кількох джерел: - Репозиторій чартів (як ми бачили вище) - Локальний архів чарту (`helm install foo foo-0.1.1.tgz`) - Тека із розпакованим чартом (`helm install foo path/to/foo`) - Повний URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' і 'helm rollback': Оновлення релізу та відновлення у разі невдачі {#helm-upgrade-and-helm-rollback-updating-a-release-and-reverting-on-failure} Коли виходить нова версія чарту або коли ви хочете змінити конфігурацію вашого релізу, ви можете скористатися командою `helm upgrade`. Оновлення бере поточний реліз і оновлює його відповідно до інформації, що міститься в чарті. Ви можете оновити чарт, який було встановлено зі сховища, або чарт, який знаходиться на вашому локальному диску. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` У наведеному випадку реліз `happy-panda` оновлюється з використанням того ж чарту, але з новим YAML файлом: ```yaml mariadb.auth.username: user1 ``` Ми можемо використати команду `helm get values`, щоб переконатися, що нові налаштування набрали чинності. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` Команда `helm get` є корисним інструментом для перегляду релізу в кластері. І як ми бачили вище, вона показує, що наші нові значення з `panda.yaml` були розгорнуті в кластері. Тепер, якщо під час релізу щось піде не так, можна легко повернутися до попереднього релізу, використовуючи команду `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` Ця команда повертає наш реліз `happy-panda` до його першої версії. Версія релізу є інкрементним переглядом. Кожного разу, коли відбувається встановлення, оновлення або відкат, номер версії збільшується на 1. Перша версія завжди має номер 1. І ми можемо використовувати команду `helm history [RELEASE]`, щоб побачити номери версій для певного релізу. ## Корисні опції для Install/Upgrade/Rollback {#useful-options-for-install-upgrade-rollback} Є кілька інших корисних опцій, які можна вказати для налаштування поведінки Helm під час встановлення/оновлення/відкату. Зауважте, що це не повний список CLI-прапорців. Щоб побачити опис усіх прапорців, просто запустіть `helm --help`. - `--timeout`: Значення [Go duration](https://golang.org/pkg/time/#ParseDuration), яке визначає, скільки чекати на завершення команд Kubernetes. Стандартно `5m0s`. - `--wait`: Очікує, доки всі Podʼи не перейдуть у стан готовності, PVC не будуть повʼязані, а Deployment не матиме мінімальну кількість Podʼів у стані готовності (`Desired` мінус `maxUnavailable`), а також не отримає IP-адресу (і Ingress, якщо це `LoadBalancer`) перед тим, як визнати реліз успішним. Чекання триватиме стільки часу, скільки вказано в опції `--timeout`. Якщо тайм-аут досягнуто, реліз буде позначено як `FAILED`. Примітка: У ситуаціях, коли Deployment має `replicas` значення 1, а `maxUnavailable` не встановлено в 0 як частина стратегії rolling update, `--wait` поверне готовність, коли задоволено мінімальну кількість Podʼів у готовому стані. - `--no-hooks`: Пропускає запуск хук для команди. - `--recreate-pods` (доступно лише для `upgrade` та `rollback`): Цей прапорець викличе повторне створення всіх Podʼів (за винятком Podʼів, що належать до Deployment). (Застаріле в Helm 3) ## `helm uninstall`: Видалення релізу {#helm-uninstall-uninstalling-a-release} Коли настає час видалити реліз з кластера, використовуйте команду `helm uninstall`: ```console $ helm uninstall happy-panda ``` Це видалить реліз з кластера. Ви можете переглянути всі ваші поточні розгорнуті релізи за допомогою команди `helm list`: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` З виводу вище ми можемо побачити, що реліз `happy-panda` було видалено. У попередніх версіях Helm, коли реліз видалявся, запис про його видалення залишався. У Helm 3 видалення також видаляє запис про реліз. Якщо ви хочете зберегти запис про видалений реліз, використовуйте `helm uninstall --keep-history`. Використання `helm list --uninstalled` покаже лише ті релізи, які були видалені з прапорцем `--keep-history`. Прапорець `helm list --all` покаже вам всі записи релізів, які зберіг Helm, включаючи записи для невдалих або видалених елементів (якщо було вказано `--keep-history`): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Зверніть увагу, що через те, що релізи тепер стандартно видаляються, більше неможливо зробити відкат до видаленого ресурсу. ## `helm repo`: Робота з репозиторіями {#helm-repo-working-with-repositories} Helm 3 більше не постачається зі стандартним репозиторієм чартів. Група команд `helm repo` надає команди для додавання, перегляду та видалення репозиторіїв. Ви можете переглянути, які репозиторії налаштовані, використовуючи `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` Нові репозиторії можна додати за допомогою `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Оскільки репозиторії чартів часто змінюються, у будь-який момент ви можете переконатися, що ваш клієнт Helm актуальний, запустивши `helm repo update`. Репозиторії можна видалити за допомогою `helm repo remove`. ## Створення власних чартів {#creating-your-own-charts} [Посібник з розробки чартів](/topics/charts.md) пояснює, як розробляти власні чарти. Але ви можете швидко розпочати, використовуючи команду `helm create`: ```console $ helm create deis-workflow Creating deis-workflow ``` Тепер у вас є чарт в теці `./deis-workflow`. Ви можете редагувати його та створювати власні шаблони. Коли ви редагуєте свій чарт, ви можете перевірити, чи він добре сформований, запустивши команду `helm lint`. Коли настане час упакувати чарт для розповсюдження, ви можете скористатися командою `helm package`: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` І цей чарт тепер може бути легко встановлена за допомогою `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Упаковані чарти можуть бути завантажені в репозиторії чартів. Для отримання додаткової інформації дивіться документацію про [репозиторії чартів Helm](/topics/chart_repository.md). ## Висновки {#conclusion} У цьому розділі було розглянуто основні шаблони використання клієнта `helm`, включаючи пошук, встановлення, оновлення та видалення. Також було розглянуто корисні утиліти, такі як `helm status`, `helm get` і `helm repo`. Для отримання додаткової інформації про ці команди перегляньте вбудовану довідку Helm: `helm help`. У [наступному розділі](/howto/charts_tips_and_tricks.md) ми розглянемо процес створення чартів. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunOption = "none" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) chart, err := loader.Load(chartPath) if err != nil { return err } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil { if err := action.CheckDependencies(chart, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := installClient.RunWithContext(ctx, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created:\n%+v", *release) return nil } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx ================================================ ```go package main import ( "bufio" "context" "fmt" "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver, logger.Printf); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, err } return registryClient, nil } func newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) { if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSverify { registryClient, err := registry.NewRegistryClientWithTLS( logger.Writer(), certFile, keyFile, caFile, insecureSkipTLSverify, settings.RegistryConfig, settings.Debug) if err != nil { return nil, err } return registryClient, nil } registryClient, err := newRegistryClient(settings, plainHTTP) if err != nil { return nil, err } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } registryClient, err := newRegistryClient(settings, false) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient pullClient := action.NewPullWithOpts( action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", *result.Release) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunOption = "none" upgradeClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts chart, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } if req := chart.Metadata.Dependencies; req != nil { if err := action.CheckDependencies(chart, req); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx ================================================ --- title: Приклади description: Приклади різних функцій Helm SDK sidebar_position: 2 --- import Install from './_install.mdx' import List from './_list.mdx' import Main from './_main.mdx' import Pull from './_pull.mdx' import Uninstall from './_uninstall.mdx' import Upgrade from './_upgrade.mdx' Цей документ містить серію прикладів використання Helm SDK. Призначений для документування різних функціональних можливостей SDK. Останній приклад показує драйвер `main.go` ([посилання](#driver)). Він виконує наведені нижче дії та включає необхідні допоміжні функції. Код для прикладів знаходиться в директорії [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples). І він повністю функціональний. ## Дії {#actions} ### Встановлення (Install) {#install-action} Цей приклад встановлює вказаний чарт/реліз для вказаної версії та значень: ### Оновлення (Upgrade) {#upgrade-action} Цей приклад оновлює вказаний реліз з вказаним чартом, версією та значеннями: ### Видалення (Uninstall) {#uninstall-action} Цей приклад видаляє вказаний реліз ### Виводу списку чартів (List) {#list-action} Цей приклад показує всі чарти (в поточному налаштованому просторі імен) ### Завантаження чартів (Pull) {#pull-action} Цей приклад завантажує чарт з OCI репозиторію ## Драйвер {#driver} Тут драйвер показує необхідні допоміжні функції, потрібні для роботи дій Helm SDK. І показує наведені вище приклади в дії, щоб завантажити, встановити, оновити та видалити чарт 'podinfo' з OCI репозиторію.
================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: Вступ description: Представляємо Helm Go SDK aliases: - /docs/gosdk sidebar_position: 1 --- Go SDK Helm дозволяє програмному забезпеченню користувача використовувати чарти Helm та функціональність Helm для керування розгортанням програмного забезпечення Kubernetes (Насправді, інтерфейс командного рядка Helm — це просто один з таких інструментів!) Зараз SDK функціонально відокремлений від CLI Helm. І SDK може використовуватися (і використовується) окремими інструментами. Проєкт Helm зобовʼязується зберігати стабільність API для SDK. Варто зауважити, що SDK все ще має деякі шорсткості, що залишилися від початкової роботи з відокремлення CLI та SDK. Проєкт Helm має на меті покращити це з часом. Повну документацію API можна знайти за посиланням [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). Нижче наведено короткий огляд основних типів пакетів та простий приклад. Дивіться розділ [Приклади](/sdk/examples.mdx) для більшої кількості прикладів та більш повнофункціонального 'драйвера'. ## Огляд основних пакетів {#main-package-overview} - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Містить основний "клієнт" для виконання дій Helm. Це той самий пакет, який використовує CLI під капотом. Якщо вам потрібно виконувати базові команди Helm з іншої Go програми, цей пакет для вас - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Методи та допоміжні функції для завантаження та маніпулювання чартами - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) та його підпакети: Містить усі обробники для стандартних змінних середовища Helm, а його підпакети містять обробку виводу та файлів значень - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Визначає обʼєкт `Release` та статуси Окрім цих є ще багато інших пакетів, тож перегляньте документацію для отримання додаткової інформації! ### Простий приклад {#simple-example} Це простий приклад виконання команди `helm list` за допомогою Go SDK. Дивіться розділ [Приклади](/sdk/examples.mdx) для більш повнофункціональних прикладів. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // Ви можете передати порожній рядок замість settings.Namespace(), щоб // перелічити всі простори імен if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Вивести перелік тільки розгорнутих client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Сумісність {#compatibility} Helm SDK чітко дотримується гарантій зворотної сумісності Helm: Тобто, значні зміни буде внесено лише в основних (major) версіях. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Розширені техніки Helm description: Описує різні розширені функції для досвдічених користувачів Helm sidebar_position: 9 --- Цей розділ пояснює різні розширені функції та техніки використання Helm. Інформація в цьому розділі призначена для "досвідчених користувачів" Helm, які бажають здійснювати докладні налаштування та маніпуляції з їх чартами та випусками. Кожна з цих розширених функцій має свої переваги та обмеження, тому кожну з них потрібно використовувати обережно і з глибокими знаннями Helm. Іншими словами, памʼятайте про [принцип Пітера Паркера](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility). ## Пост-рендеринг {#post-rendering} Пост-рендеринг дає можливість встановлювачу чартів вручну маніпулювати, налаштовувати та/або перевіряти створені маніфести перед їх встановленням через Helm. Це дозволяє користувачам з додатковими потребами у налаштуванні використовувати інструменти, такі як [`kustomize`](https://kustomize.io), для застосування змін конфігурації без необхідності створювати форк публічного чарту або вимагати від супроводжувачів чартів вказувати всі можливі опції конфігурації для програмного забезпечення. Є також випадки для впровадження загальних інструментів та контейнерів sidecar у корпоративних середовищах або для аналізу маніфестів перед розгортанням. ### Передумови {#prerequisites} - Helm 3.1+ ### Використання {#usage} Пост-рендерер може бути будь-яким виконуваним файлом, який приймає створені маніфести Kubernetes через STDIN та повертає дійсні маніфести Kubernetes через STDOUT. Він повинен повертати ненульовий код завершення у випадку помилки. Це єдиний "API" між двома компонентами. Це дозволяє значну гнучкість у тому, що ви можете робити з вашим процесом пост-рендерингу. Пост-рендерер можна використовувати з `install`, `upgrade` і `template`. Щоб використовувати пост-рендерер, використовуйте прапорець `--post-renderer` з шляхом до виконуваного файлу рендерера, який ви бажаєте використовувати: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` Якщо шлях не містить жодних роздільників, пошук буде здійснюватись в $PATH, в іншому випадку буде створено будь-які відносні шляхи до повністю кваліфікованого шляху. Якщо ви бажаєте використовувати кілька пост-рендерерів, викликайте їх усіх у скрипті або разом у будь-якому бінарному інструменті, який ви створили. У bash це буде так просто, як `renderer1 | renderer2 | renderer3`. Приклад використання `kustomize` як пост-рендерера можна побачити [тут](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Обмеження {#caveats} При використанні пост-рендерерів є кілька важливих моментів, які слід враховувати. Найважливіше з них полягає в тому, що при використанні пост-рендерера всі особи, які модифікують цей випуск, **МУСЯТЬ** використовувати той же рендерер для забезпечення повторюваних збірок. Ця функція спеціально створена для того, щоб дозволити будь-якому користувачеві змінювати рендерер або перестати використовувати рендерер, але це слід робити обережно, щоб уникнути випадкових змін або втрати даних. Ще одне важливе зауваження стосується безпеки. Якщо ви використовуєте пост-рендерер, ви повинні впевнитися, що він надходить з надійного джерела (так само як і будь-яке інше програмне забезпечення). Використання ненадійних або неперевірених рендерерів НЕ рекомендовано, оскільки вони мають повний доступ до створених шаблонів, які часто містять секретні дані. ### Власні пост-рендерери {#custom-post-renderers} Крок пост-рендерингу пропонує ще більше гнучкості при використанні в Go SDK. Будь-який пост-рендерер повинен реалізувати наступний Go інтерфейс: ```go type PostRenderer interface { // Run очікує один буфер, заповнений відрендереними маніфестами Helm. Він // очікує, що модифіковані результати будуть повернені в окремому буфері або // помилку, якщо виникла проблема або збій під час виконання кроку пост-рендерингу Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` Більше інформації про використання Go SDK можна знайти в [розділі Go SDK](#go-sdk). ## Go SDK {#go-sdk} Helm 3 представив повністю переписаний Go SDK для кращого досвіду при розробці програмного забезпечення та інструментів, які використовують Helm. Повну документацію можна знайти в [розділі Go SDK](/sdk/gosdk.md). ## Сховища даних {#storage-backends} Helm 3 змінив стандартне зберігання інформації про випуски на Secrets у просторі імен випуску. Helm 2 стандартно зберігає інформацію про випуски як ConfigMaps у просторі імен екземпляра Tiller. Підрозділи, що йдуть далі, показують, як налаштувати різні бекенди. Це налаштування базується на змінній середовища `HELM_DRIVER`. Вона може бути встановлена на одне зі значень: `[configmap, secret, sql]`. ### Бекенд зберігання ConfigMap {#configmap-storage-backend} Щоб активувати бекенд ConfigMap, потрібно встановити змінну середовища `HELM_DRIVER` на `configmap`. Ви можете встановити її в оболонці наступним чином: ```shell export HELM_DRIVER=configmap ``` Якщо ви хочете перемикнутися зі стандартного бекенду на бекенд ConfigMap, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **Примітки щодо операційної діяльності**: Інформація про випуски включає вміст чартів та файлів значень і тому може містити чутливі дані (наприклад, паролі, приватні ключі та інші облікові дані), які потрібно захищати від несанкціонованого доступу. При керуванні авторизацією Kubernetes, наприклад, з [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), можливо надати ширший доступ до ресурсів ConfigMap, одночасно обмежуючи доступ до ресурсів Secret. Наприклад, стандартна роль [користувача](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" надає доступ до більшості ресурсів, але не до Secrets. Крім того, дані секретів можуть бути налаштовані для [шифрування](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Будь ласка, врахуйте це, якщо ви вирішите перейти на бекенд ConfigMap, оскільки це може розкрити чутливі дані вашого застосунку. ### Бекенд зберігання SQL {#sql-storage-backend} Існує ***бета*** бекенд зберігання SQL, який зберігає інформацію про випуски в SQL базі даних. Використання такого бекенду зберігання є особливо корисним, якщо інформація про ваші випуски перевищує 1 МБ (у цьому випадку її не можна зберігати в ConfigMaps/Secrets через внутрішні обмеження сховища ключ-значення etcd у Kubernetes). Щоб активувати SQL бекенд, потрібно розгорнути SQL базу даних і встановити змінну середовища `HELM_DRIVER` на `sql`. Деталі бази даних задаються змінною середовища `HELM_DRIVER_SQL_CONNECTION_STRING`. Ви можете встановити її в оболонці наступним чином: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Примітка: Зараз підтримується лише PostgreSQL. **Примітки щодо операційної діяльності**: Рекомендується: - Підготувати вашу базу даних для операційної діяльності. Для PostgreSQL перегляньте [документацію з адміністрування сервера](https://www.postgresql.org/docs/12/admin.html) для отримання додаткової інформації. - Увімкнути [управління дозволами](/topics/permissions_sql_storage_backend.md) для дзеркального відображення Kubernetes RBAC для інформації про випуски. Якщо ви хочете перемикнутися зі стандартного бекенду на SQL бекенд, вам потрібно буде виконати міграцію самостійно. Ви можете отримати інформацію про випуски за допомогою наступної команди: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Архітектура Helm description: Описує архітектуру Helm на високому рівні. sidebar_position: 8 --- # Архітектура Helm {#helm-architecture} Цей документ описує архітектуру Helm на високому рівні. ## Призначення Helm {#the-purpose-of-helm} Helm — це інструмент для керування пакетами Kubernetes, що називаються _чартами_. Helm може: - Створювати нові чарти з нуля - Упаковувати чарт в архіви чартів (tgz) - Взаємодіяти з репозиторіями чартів, де зберігаються чарти - Встановлювати та видаляти чарти в наявному кластері Kubernetes - Керувати циклом випуску чартів, які були встановлені за допомогою Helm Для Helm є три важливі концепції: 1. _Chart_ — це пакет інформації, необхідної для створення екземпляра застосунку Kubernetes. 2. _Config_ містить конфігураційну інформацію, яку можна обʼєднати з упакованим чартом для створення обʼєкта, що підлягає випуску. 3. _Release_ — це запущений екземпляр _чарту_, поєднаний з конкретним _конфігом_. ## Компоненти {#components} Helm є виконуваним файлом, який реалізовано в двох окремих частинах: **Клієнт Helm** — це клієнт командного рядка для кінцевих користувачів. Клієнт відповідає за: - Розробку локальних чартів - Керування репозиторіями - Керування випусками - Взаємодію з бібліотекою Helm - Надсилання чартів для встановлення - Запит на оновлення або видалення наявних випусків **Бібліотека Helm** надає логіку для виконання всіх операцій Helm. Вона взаємодіє з API-сервером Kubernetes і забезпечує такі можливості: - Обʼєднання чарту і конфігурації для створення випуску - Встановлення чартів у Kubernetes і надання наступного обʼєкта випуску - Оновлення та видалення чартів шляхом взаємодії з Kubernetes Окрема бібліотека Helm інкапсулює логіку Helm, щоб її можна було використовувати різними клієнтами. ## Реалізація {#implementation} Клієнт та бібліотека Helm написані мовою програмування Go. Бібліотека використовує клієнтську бібліотеку Kubernetes для комунікації з Kubernetes.Зараз ця бібліотека використовує REST+JSON. Інформація зберігається у Secrets, розташованих всередині Kubernetes. Вона не потребує власної бази даних. Конфігураційні файли, коли це можливо, написані у YAML. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Репозиторій чартів description: Як створити та працювати з репозиторіями чартів Helm. sidebar_position: 6 --- Цей розділ пояснює, як створювати та працювати з репозиторіями чартів Helm. На високому рівні, репозиторій чартів — це місце, де можуть зберігатися та розповсюджуватися упаковані чарти. Розподілений репозиторій спільноти чартів Helm знаходиться на [Artifact Hub](https://artifacthub.io/packages/search?kind=0) та запрошує вас долучитися. Однак Helm також дозволяє вам створювати власні репозиторії чартів. Цей посібник пояснює, як це зробити. ### Передумови {#prerequisites} - Пройдіть [Керівництво з швидкого старту](/intro/quickstart.md) - Ознайомтеся з документом [Чарти](/topics/charts.md) ### Створення репозиторію чартів {#create-a-chart-repository} _Репозиторій чартів_ — це HTTP-сервер, який містить файл `index.yaml` і, за бажанням, деякі упаковані чарти. Коли ви готові поділитися своїми чартами, найкращий спосіб зробити це — завантажити їх до репозиторію чартів. З версії Helm 2.2.0 підтримується SSL-автентифікація клієнта для репозиторіїв. Інші протоколи автентифікації можуть бути доступні як втулки. Оскільки репозиторій чартів може бути будь-яким HTTP-сервером, який може обслуговувати YAML і tar файли та відповідати на GET-запити, у вас є безліч варіантів для хостингу власного репозиторію чартів. Наприклад, ви можете використовувати Google Cloud Storage (GCS), Amazon S3, GitHub Pages або навіть розгорнути власний вебсервер. ### Структура репозиторію чартів {#the-chart-repository-structure} Репозиторій чартів складається з упакованих чартів і спеціального файлу з назвою `index.yaml`, який містить індекс усіх чартів у репозиторії. Зазвичай чарти, описані в `index.yaml`, також розміщуються на тому ж сервері, як і [файли походження](/topics/provenance.md). Наприклад, структура репозиторію `https://example.com/charts` може виглядати так: ```none charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` У цьому випадку файл індексу міститиме інформацію про один чарт, Alpine, і надаватиме URL для завантаження `https://example.com/charts/alpine-0.1.2.tgz` для цього чарту. Не обовʼязково, щоб пакет чарту розміщувався на тому ж сервері, що й файл `index.yaml`. Однак, це часто є найпростішим варіантом. ### Файл індексу {#the-index-file} Файл індексу — це YAML-файл з назвою `index.yaml`. Він містить деякі метадані про пакети, включаючи вміст файлу `Chart.yaml` чарту. Дійсний репозиторій чартів повинен мати файл індексу. Файл індексу містить інформацію про кожен чарт у репозиторії чартів. Команда `helm repo index` створить файл індексу на основі заданої локальної теки, яка містить упаковані чарти. Приклад файлу індексу: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Хостинг репозиторіїв чартів {#hosting-chart-repositories} У цьому розділі показано кілька способів хостингу репозиторію чартів. ### Google Cloud Storage (GCS) Першим кроком є **створення кошика GCS**. Назвемо його `fantastic-charts`. ![Створення кошика GCS](/img/helm2/create-a-bucket.png) Далі, зробіть свій кошик публічним, **редагувавши дозволи кошику**. ![Редагування дозволів](/img/helm2/edit-permissions.png) Додайте цей пункт, щоб **зробити кошик публічним**: ![Зробити кошик публічним](/img/helm2/make-bucket-public.png) Вітаємо, тепер у вас є порожній кошик GCS, готовий для обслуговування чартів! Ви можете завантажити свій репозиторій чартів за допомогою командного рядка Google Cloud Storage або через вебінтерфейс GCS. Доступ до публічного кошика GCS можна отримати через простий HTTPS за цією адресою: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith {#cloudsmith} Ви також можете налаштувати репозиторії чартів за допомогою Cloudsmith. Дізнайтеся більше про репозиторії чартів з Cloudsmith [тут](https://help.cloudsmith.io/docs/helm-chart-repository). ### JFrog Artifactory {#jfrog-artifactory} Аналогічно, ви можете налаштувати репозиторії чартів за допомогою JFrog Artifactory. Дізнайтеся більше про репозиторії чартів з JFrog Artifactory [тут](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories). ### Приклад GitHub Pages {#github-pages-example} Подібним чином ви можете створити репозиторій чартів за допомогою GitHub Pages. GitHub дозволяє обслуговувати статичні вебсторінки двома різними способами: - Налаштувавши проєкт на обслуговування вмісту його теки `docs/` - Налаштувавши проєкт на обслуговування певної гілки Ми скористаємося другим підходом, хоча перший також простий. Перший крок — **створити гілку gh-pages**. Ви можете зробити це локально: ```console $ git checkout -b gh-pages ``` Або через веббраузер, використовуючи кнопку **Branch** у вашому репозиторії GitHub: ![Створення гілки GitHub Pages](/img/helm2/create-a-gh-page-button.png) Далі потрібно переконатися, що ваша **гілка gh-pages** налаштована як GitHub Pages. Для цього натисніть у вашому репо кнопку **Settings** і прокрутіть до розділу **GitHub pages** і налаштуйте його, як показано нижче: ![Налаштування гілки GitHub Pages](/img/helm2/set-a-gh-page.png) Стандартно **Source** зазвичай встановлюється на **gh-pages branch**. Якщо це не встановлено, виберіть його. Ви можете використовувати **власний домен**, якщо бажаєте. І переконайтеся, що **Enforce HTTPS** відмічено, щоб **HTTPS** використовувався під час обслуговування чартів. У такому налаштуванні ви можете використовувати основну гілку для зберігання коду чартів, а **гілку gh-pages** як репозиторій чартів, наприклад: `https://USERNAME.github.io/REPONAME`. Демонстраційний репозиторій [TS Charts](https://github.com/technosophos/tscharts) доступний за адресою `https://technosophos.github.io/tscharts/`. Якщо ви вирішили використовувати GitHub Pages для хостингу репозиторію чартів, ознайомтеся з [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action — це робочий процес GitHub Action, який перетворює проєкт GitHub у репозиторій чартів Helm, використовуючи CLI-інструмент [helm/chart-releaser](https://github.com/helm/chart-releaser). ### Звичайні вебсервери {#ordinary-web-servers} Щоб налаштувати звичайний вебсервер для обслуговування чартів Helm, вам просто потрібно зробити наступне: - Помістіть ваш індекс і чарти в теку, яку сервер може обслуговувати - Переконайтеся, що файл `index.yaml` доступний без необхідності автентифікації - Переконайтеся, що файли `yaml` обслуговуються з правильним типом вмісту (`text/yaml` або `text/x-yaml`) Наприклад, якщо ви хочете обслуговувати свої чарти з теки `$WEBROOT/charts`, переконайтеся, що у вашому вебкорені є тека `charts/`, і помістіть туди файл індексу та чарти. ### Сервер репозиторію ChartMuseum {#chartmuseum-repository-server} ChartMuseum — це сервер репозиторію чартів Helm з відкритим кодом, написаний на Go (Golang), з підтримкою хмарних сховищ, включаючи [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/) та [etcd](https://etcd.io/). Ви також можете використовувати сервер [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) для хостингу репозиторію чартів з локальної файлової системи. ### Реєстр пакетів GitLab {#gitlab-package-registry} З GitLab ви можете публікувати чарти Helm у реєстрі пакетів вашого проєкту. Дізнайтеся більше про налаштування репозиторію пакетів Helm за допомогою GitLab [тут](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Управління репозиторіями чартів {#managing-chart-repositories} Тепер, коли у вас є репозиторій чартів, остання частина цього посібника пояснює, як підтримувати чарти в цьому репозиторії. ### Зберігання чартів у вашому репозиторії чартів {#storing-charts-in-your-chart-repository} Тепер, коли у вас є репозиторій чартів, завантажимо чарти та файл індексу до репозиторію. Чарти в репозиторії мають бути запаковані (`helm package chart-name/`) та правильно версійовані (відповідно до рекомендацій [SemVer 2](https://semver.org/)). Наступні кроки складають приклад робочого процесу, але ви можете використовувати будь-який зручний вам процес для зберігання та оновлення чартів у вашому репозиторії. Як тільки у вас є готовий запакований чарт, створіть нову теку і перемістіть туди ваш запакований чарт. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` Остання команда бере шлях до щойно створеної локальної теки та URL вашого віддаленого репозиторію чартів і створює файл `index.yaml` у вказаній теці. Тепер ви можете завантажити чарт і файл індексу у ваш репозиторій чартів, використовуючи інструмент синхронізації або вручну. Якщо ви використовуєте Google Cloud Storage, ознайомтеся з цим [прикладом робочого процесу](/howto/chart_repository_sync_example.md), що використовує клієнт gsutil. Для GitHub ви можете просто помістити чарти у відповідну гілку призначення. ### Додавання нових чартів до наявного репозиторію {#adding-new-charts-to-an-existing-repository} Щоразу, коли ви хочете додати новий чарт у ваш репозиторій, потрібно перестворити індекс. Команда `helm repo index` повністю перебудовує файл `index.yaml` з нуля, включаючи лише ті чарти, які вона знаходить локально. Однак, ви можете використовувати прапорець `--merge` для поступового додавання нових чартів до наявного файлу `index.yaml` (чудовий варіант під час роботи з віддаленим репозиторієм, як-от GCS). Виконайте команду `helm repo index --help`, щоб дізнатися більше. Переконайтеся, що ви завантажили як оновлений файл `index.yaml`, так і чарт. Якщо ви згенерували файл підтвердження цілісності, завантажте і його. ### Поділитися чартами з іншими {#share-your-charts-with-others} Коли ви готові поділитися чартами, просто повідомте комусь URL вашого репозиторію. Після цього вони додадуть репозиторій до свого клієнта helm через команду `helm repo add [NAME] [URL]` з будь-яким імʼям, яке вони хочуть використовувати для позначення репозиторію. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` Якщо чарти захищені за допомогою базової автентифікації HTTP, ви також можете вказати імʼя користувача та пароль тут: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Примітка:** Репозиторій не буде додано, якщо він не містить дійсний файл `index.yaml`. **Примітка:** Якщо ваш репозиторій helm, наприклад, використовує самопідписний сертифікат, ви можете використовувати `helm repo add --insecure-skip-tls-verify ...`, щоб пропустити перевірку CA. Після цього ваші користувачі зможуть шукати серед ваших чартів. Після того, як ви оновите репозиторій, вони можуть використовувати команду `helm repo update`, щоб отримати найновішу інформацію про чарт. _Під капотом команди `helm repo add` і `helm repo update` завантажують файл index.yaml і зберігають його в теці `$XDG_CACHE_HOME/helm/repository/cache/`. Саме тут функція `helm search` знаходить інформацію про чарти._ ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Тести чартів description: Опис того, як запускати та тестувати ваші чарти. sidebar_position: 3 --- Чарт містить ряд ресурсів та компонентів Kubernetes, які працюють разом. Як автор чарту, ви можете захотіти написати деякі тести, щоб перевірити, чи ваш чарт працює відповідно до очікувань після його встановлення. Ці тести також допомагають споживачеві чарту зрозуміти, що саме повинен робити ваш чарт. **Тест** у Helm чарті розміщується в теці `templates/` і є визначенням Job, яке вказує контейнер з певною командою для виконання. Контейнер повинен успішно завершити роботу (exit 0), щоб тест вважався успішним. Визначення Job повинно містити анотацію хука Helm: `helm.sh/hook: test`. Зверніть увагу, що до Helm v3, визначення Job повинно було містити одну з цих анотацій хука Helm: `helm.sh/hook: test-success` або `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` все ще приймається як зворотно сумісна альтернатива `helm.sh/hook: test`. Приклади тестів: - Перевірте, що ваша конфігурація з файлу values.yaml була правильно вбудована. - Переконайтеся, що ваше імʼя користувача та пароль працюють правильно. - Переконайтеся, що неправильне імʼя користувача та пароль не працюють. - Перевірте, що ваші сервіси працюють та правильно здійснюють балансування навантаження. - тощо. Ви можете запустити заздалегідь визначені тести у Helm для релізу за допомогою команди `helm test `. Для споживача чарту це чудовий спосіб перевірити, чи їх реліз чарту (або програми) працює відповідно до очікувань. ## Приклад тесту {#example-test} Команда [helm create](/helm/helm_create.md) автоматично створює кілька тек і файлів. Щоб спробувати функціональність тестів Helm, спочатку створіть демонстраційний Helm чарт. ```console $ helm create demo ``` Тепер ви побачите таку структуру у вашому демонстраційному Helm чарті. ```none demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` У `demo/templates/tests/test-connection.yaml` ви побачите тест, який ви можете спробувати. Ось визначення Pod для тесту: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Кроки для запуску тестового набору на релізі По-перше, встановіть чарт у ваш кластер, щоб створити реліз. Можливо, вам доведеться почекати, поки всі podʼи стануть активними; якщо ви запустите тест одразу після цього встановлення, це може показати транзитивну помилку, і вам доведеться повторити тестування. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Примітки {#notes} - Ви можете визначити стільки тестів, скільки бажаєте, в одному yaml файлі або розподілити їх по кількох yaml файлах у теці `templates/`. - Ви можете організувати ваші тести у теці `tests/`, наприклад, `/templates/tests/` для більшої ізоляції. - Тест є [Helm хуком](/topics/charts_hooks.md), тому анотації, такі як `helm.sh/hook-weight` і `helm.sh/hook-delete-policy`, можуть використовуватися з ресурсами тестів. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Чарти description: Пояснює формат чартів та надає основні рекомендації щодо створення чартів з використанням Helm. sidebar_position: 1 --- Helm використовує формат пакування, який називається _чарти_. Чарт — це набір файлів, які описують повʼязаний набір ресурсів Kubernetes. Один чарт може бути використаний для розгортання чогось простого, як, наприклад, pod з memcached, або чогось складного, як повний вебстек з HTTP серверами, базами даних, кешами й так далі. Чарти створюються як файли, розташовані в певній структурі тек. Вони можуть бути упаковані у версійні архіви для розгортання. Якщо ви хочете завантажити та переглянути файли опублікованого чарту без його встановлення, ви можете зробити це за допомогою команди `helm pull chartrepo/chartname`. Цей документ пояснює формат чарту та надає основні рекомендації щодо створення чартів з використанням Helm. ## Структура файлів чарту {#chart-file-structure} Чарт організовано як набір файлів всередині теки. Назва теки відповідає назві чарту (без інформації про версію). Наприклад, чарт, який описує WordPress, буде зберігатися в теці `wordpress/`. Всередині цієї теки Helm очікує структуру, яка відповідає наступному: ```text wordpress/ Chart.yaml # YAML файл, що містить інформацію про чарт LICENSE # НЕОБОВʼЯЗКОВО: Текстовий файл, що містить ліцензію для чарту README.md # НЕОБОВʼЯЗКОВО: Файл README values.yaml # Файл стандартної конфігурації для цього чарту values.schema.json # НЕОБОВʼЯЗКОВО: JSON-схема для накладання структури на файл values.yaml charts/ # Тека, що містить чарти, від яких залежить цей чарт. crds/ # Custom Resource Definitions templates/ # Тека шаблонів, які в поєднанні з values # генерують валідні файли маніфестів Kubernetes. templates/NOTES.txt # НЕОБОВʼЯЗКОВО: Текстовий файл з короткими інструкціями ``` Helm резервує використання тек `charts/`, `crds/` і `templates/`, а також перелічених назв файлів. Інші файли буде залишено без змін. ## Файл Chart.yaml {#the-chart-yaml-file} Файл `Chart.yaml` є обовʼязковим для чарту. Він містить наступні поля: ```yaml apiVersion: Версія API чарту (обовʼязкове) name: Назва чарту (обовʼязкове) version: Версія SemVer 2 (обовʼязкове) kubeVersion: Діапазон сумісних версій Kubernetes (необовʼязкове) description: Короткий опис цього проєкту (необовʼязкове) type: Тип чарту (необовʼязкове) keywords: - Список ключових слів про цей проєкт (необовʼязкове) home: URL головної сторінки проєкту (необовʼязкове) sources: - Список URL-адрес з вихідним кодом проєкту (необовʼязкове) dependencies: # Список залежностей чарту (необовʼязкове) - name: Назва чарту (nginx) version: Версія чарту ("1.2.3") repository: (необовʼязкове) URL репозиторію ("https://example.com/charts") або псевдонім ("@repo-name") condition: (необовʼязкове) YAML шлях, який відповідає за логічне значення, використовується для увімкнення/вимкнення чартів (наприклад, subchart1.enabled ) tags: # (необовʼязкове) - Теґи можуть бути використані для групування чартів для одночасного увімкнення/вимкнення import-values: # (необовʼязкове) - ImportValues містить зіставлення вихідних значень з ключем батьківського елемента для імпорту. Кожен елемент може бути рядком або парою дочірніх/батьківських субсписків. alias: (необовʼязкове) Псевдонім для чарту. Корисно, коли вам потрібно додати той самий чарт кілька разів maintainers: # (необовʼязкове) - name: Імʼя мейнтейнера (обовʼязкове для кожного мейнтейнера) email: Електронна пошта мейнтейнера (необовʼязкове для кожного мейнтейнера) url: URL для мейнтейнера (необовʼязкове для кожного мейнтейнера) icon: URL до SVG або PNG зображення для використання як іконки (необовʼязкове). appVersion: Версія програми, яку містить цей чарт (необовʼязкове). Не обовʼязково має бути SemVer. Рекомендується використовувати лапки. deprecated: Чи цей чарт застарілий (необовʼязкове, булеве значення) annotations: example: Список анотацій, згрупованих за іменами (необовʼязкове). ``` Починаючи з [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), додаткові поля не дозволені. Рекомендований підхід — додавати власні метадані в `annotations`. ### Чарти та версіювання {#charts-and-versioning} Кожен чарт повинен мати номер версії. Версія повинна відповідати стандарту [SemVer 2](https://semver.org/spec/v2.0.0.html). На відміну від Helm Classic, Helm версії 2 та новіші використовують номери версій як маркери випуску. Пакети в репозиторіях ідентифікуються за назвою та версією. Наприклад, чарт `nginx`, у якого в полі версії вказано `version: 1.2.3`, буде мати таку назву: ```text nginx-1.2.3.tgz ``` Підтримуються також складніші імена SemVer 2, такі як `version: 1.2.3-alpha.1+ef365`. Але імена, які не відповідають стандарту SemVer, системою не допускаються. **Примітка:** Якщо Helm Classic та Deployment Manager були тісно повʼязані з GitHub у контексті чартів, то Helm версії 2 та новіші не залежать від GitHub або навіть Git. Відповідно, він не використовує Git SHAs для версіювання. Поле `version` у файлі `Chart.yaml` використовується багатьма інструментами Helm, включаючи CLI. При генерації пакета, команда `helm package` використовує версію, яку знаходить у `Chart.yaml`, як частину назви пакета. Система припускає, що номер версії в назві пакета чарту збігається з номером версії у `Chart.yaml`. Невідповідність цього припущення викличе помилку. ### Поле `apiVersion` {#the-apiversion-field} Поле `apiVersion` має бути `v2` для чартів Helm, які вимагають Helm версії 3 або новішої. Чарти, які підтримують попередні версії Helm, мають `apiVersion`, встановлену на `v1`, і все ще можуть бути встановлені за допомогою Helm 3. Зміни з `v1` на `v2`: - Поле `dependencies`, що визначає залежності чарту, яке в чартах `v1` знаходилося в окремому файлі `requirements.yaml` (див. [Залежності чарту](#chart-dependencies)). - Поле `type`, що дозволяє відрізняти чарт-застосунок від бібліотеки (див. [Типи чартів](#chart-types)). ### Поле `appVersion` {#the-appversion-field} Зверніть увагу, що поле `appVersion` не повʼязане з полем `version`. Це спосіб вказати версію застосунку. Наприклад, чарт `drupal` може мати `appVersion: "8.2.1"`, що вказує на версію Drupal, включену в чарт (стандартно), і це буде версія `8.2.1`. Це поле є інформаційним і не впливає на розрахунки версії чарту. Наполегливо рекомендується використовувати лапки навколо значення версії. Це змушує YAML-парсер сприймати номер версії як рядок. Якщо залишити його без лапок, це може призвести до проблем із парсингом у деяких випадках. Наприклад, YAML інтерпретує `1.0` як число з плаваючою точкою, а git-коміт SHA, як `1234e10`, як наукову нотацію. З версії Helm v3.5.0 команда `helm create` автоматично обгортає поле `appVersion` у лапки. ### Поле `kubeVersion` {#the-kubeversion-field} Необовʼязкове поле `kubeVersion` може визначати обмеження версій semver для підтримуваної версії Kubernetes. Helm перевірить обмеження версії під час встановлення чарту та відхилить дію, якщо кластер працює на непідтримуваній версії Kubernetes. Обмеження версій можуть складатися з розділених пробілами AND-порівнянь, таких як: ```yaml >= 1.13.0 < 1.15.0 ``` які можуть бути обʼєднані за допомогою оператора OR `||`, як у наступному прикладі: ```yaml >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` У цьому прикладі версія `1.14.0` виключена, що може мати сенс, якщо відомо про помилку в певних версіях, яка не дозволяє чарту працювати правильно. Окрім обмежень версій з використанням операторів `=` `!=` `>` `<` `>=` `<=`, підтримуються такі скорочені нотації: - діапазони для закритих інтервалів, де `1.1 - 2.3.4` еквівалентно `>= 1.1 <= 2.3.4`. - підстановки `x`, `X` і `*`, де `1.2.x` еквівалентно `>= 1.2.0 < 1.3.0`. - діапазони з тильдою (допускаються зміни патч-версії), де `~1.2.3` еквівалентно `>= 1.2.3 < 1.3.0`. - діапазони з `^` (допускаються зміни мінорної версії), де `^1.2.3` еквівалентно `>= 1.2.3 < 2.0.0`. Для детального пояснення підтримуваних обмежень версій semver див. [Masterminds/semver](https://github.com/Masterminds/semver). ### Застарівання чартів {#deprecating-charts} Під час керування чартами в репозиторії чартів іноді виникає необхідність зняти чарт з підтримки, визнати його застарілим (deprecated). Для цього можна використовувати необовʼязкове поле `deprecated` у файлі `Chart.yaml`. Якщо **остання** версія чарту в репозиторії позначена як знята з підтримки, тоді весь чарт вважається застарілим. Назву чарту можна пізніше використовувати повторно, опублікувавши нову версію, яка не позначена як знята з підтримки. Процедура зняття чартів з підтримки включає такі кроки: 1. Оновіть файл `Chart.yaml` чарту, позначивши його як знятий з підтримки, і збільште номер версії. 2. Опублікуйте нову версію чарту в репозиторії чартів. 3. Видаліть чарт із репозиторію коду (наприклад, з git). ### Типи чартів {#chart-types} Поле `type` визначає тип чарту. Є два типи: `application` та `library`. Стандартний тип — `application`, і це стандартний чарт, з яким можна повністю працювати. [Чарт-бібліотека](/topics/library_charts.md) надає утиліти або функції для розробників чарту. Чарт-бібліотека відрізняється від чарту-застосунку тим, що він не встановлюється і зазвичай не містить жодних обʼєктів ресурсу. **Примітка:** Чарт-застосунок можна використовувати як чарт-бібліотеку. Це активується шляхом встановлення типу `library`. Чарт тоді буде оброблятися як чарт-бібліотека, де всі утиліти та функції можуть бути використані. Усі обʼєкти ресурсів чарту не будуть оброблені. ## Ліцензії, README та ПРИМІТКИ до чарту {#chart-license-readme-and-notes} Чарти також можуть містити файли, які описують встановлення, конфігурацію, використання та ліцензію чарту. Файл LICENSE є простим текстовим файлом, який містить [ліцензію](https://en.wikipedia.org/wiki/Software_license) для чарту. Чарт може містити ліцензію, оскільки він може містити програмну логіку в шаблонах і, отже, не буде лише конфігураційним. Також можуть бути окремі ліцензії для застосунку, який встановлюється чартом, якщо це необхідно. README для чарту повинен бути відформатований у Markdown (README.md) і, як правило, містити: - Опис застосунку або служби, яку надає чарт - Будь-які передумови або вимоги для запуску чарту - Опис опцій у `values.yaml` та стандартні значення - Будь-яку іншу інформацію, яка може бути релевантною для встановлення або конфігурації чарту Коли хаби та інші інтерфейси користувача відображають деталі про чарт, ці дані витягуються з вмісту файлу `README.md`. Чарт також може містити короткий текстовий файл `templates/NOTES.txt`, який буде надрукований після встановлення і під час перегляду статусу релізу. Цей файл обробляється як [шаблон](#templates-and-values) і може використовуватися для відображення заміток щодо використання, наступних кроків або будь-якої іншої інформації, яка стосується релізу чарту. Наприклад, можна надати інструкції щодо підключення до бази даних або доступу до вебінтерфейсу. Оскільки цей файл друкується в STDOUT під час виконання команд `helm install` або `helm status`, рекомендується зберігати вміст коротким та вказувати на README для детальнішої інформації. ## Залежності чартів {#chart-dependencies} У Helm один чарт може залежати від будь-якої кількості інших чартів. Ці залежності можна динамічно звʼязувати за допомогою поля `dependencies` у файлі `Chart.yaml` або вручну керувати ними в теці `charts/`. ### Керування залежностями за допомогою поля `dependencies` {#managing-dependencies-with-the-dependencies-field} Чарти, від яких залежить поточний чарт, визначаються як список у полі `dependencies`. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - Поле `name` містить імʼя потрібного чарту. - Поле `version` містить версію потрібного чарту. - Поле `repository` містить повну URL-адресу репозиторію чартів. Зверніть увагу, що ви також повинні використовувати команду `helm repo add`, щоб додати цей репозиторій локально. - Ви можете використовувати імʼя репозиторію замість URL-адреси. ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Після того як ви визначили залежності, ви можете виконати команду `helm dependency update`, і вона використає ваш файл залежностей для завантаження всіх вказаних чартів у вашу теку `charts/`. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` Коли `helm dependency update` отримує чарти, вона зберігає їх як архіви чартів у теці `charts/`. Тому в наведеному вище прикладі очікується, що в теці charts будуть такі файли: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Поле `alias` у залежностях {#alias-field-in-dependencies} Крім інших полів, кожен запис у вимогах може містити необовʼязкове поле `alias`. Додавання псевдоніма для чарту-залежності дозволяє додати чарт у залежності, використовуючи псевдонім як назву нової залежності. Псевдонім може бути корисним, коли вам потрібно отримати доступ до чарту під іншим імʼям (іменами). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` У наведеному вище прикладі для `parentchart` буде три залежності: ```text subchart new-subchart-1 new-subchart-2 ``` Ручний спосіб досягнення цього — копіювання/вставка одного й того ж чарту в теку `charts/` кілька разів під різними іменами. #### Поля `tags` та `condition` у залежностях {#tags-and-condition-fields-in-dependencies} Крім інших полів, кожен запис у вимогах може містити необовʼязкові поля `tags` та `condition`. Всі чарти будуть стандартно завантажені. Якщо присутні поля `tags` або `condition`, вони будуть оцінені та використані для керування завантаженням чартів, до яких вони застосовуються. **Condition** — поле condition містить один або кілька шляхів YAML (розділених комами). Якщо цей шлях існує у значеннях основного чарту та оцінюється як булеве значення, чарт буде включений або виключений залежно від цього булевого значення. Оцінюється лише перший дійсний шлях у списку, і якщо шляхи не існують, то condition не має жодного ефекту. **Tags** — поле tags є списком міток YAML, повʼязаних із цим чартом. У значеннях основного чарту всі чарти з мітками можуть бути включені або виключені шляхом вказання мітки та булевого значення. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` У наведеному вище прикладі всі чарти з міткою `front-end` будуть вимкнені, але оскільки шлях `subchart1.enabled` у значеннях основного чарту має значення `true`, умова переважає мітку `front-end`, і `subchart1` буде включений. Оскільки `subchart2` має мітку `back-end`, і ця мітка має значення `true`, `subchart2` буде включений. Також зверніть увагу, що хоча `subchart2` має зазначену умову, у значеннях основного чарту немає відповідного шляху та значення, тому ця умова не має ефекту. ##### Використання CLI з Tags та Conditions {#using-the-cli-with-tags-and-conditions} Параметр `--set` можна використовувати як зазвичай для зміни значень міток та умов. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Опрацювання Tags та Conditions {#tags-and-conditions-resolution} - **Умови (коли вони встановлені в значеннях) завжди переважають мітки.** Перемагає перший існуючий шлях умови, а наступні для цього чарту ігноруються. - Мітки оцінюються так: "якщо будь-яка з міток чарту має значення true, тоді увімкніть чарт". - Значення міток та умов повинні бути встановлені у значеннях основного чарту. - Ключ `tags:` у значеннях має бути ключем верхнього рівня. Глобальні та вкладені таблиці `tags:` наразі не підтримуються. #### Імпорт значень дочірніх чартів через залежності {#importing-values-from-child-charts-via-dependencies} У деяких випадках корисно, щоб значення дочірнього чарту передавалися до батьківського чарту та використовувалися як стандартні загальні значення. Додаткова перевага використання формату `exports` полягає в тому, що це дозволяє майбутнім інструментам інспектувати значення, які може налаштувати користувач. Ключі, що містять значення для імпорту, можуть бути вказані у полі `dependencies` батьківського чарту в полі `import-values`, використовуючи список YAML. Кожен елемент у списку — це ключ, який імпортується з поля `exports` дочірнього чарту. Для імпорту значень, які не містяться в ключі `exports`, використовуйте [формат child-parent](#using-the-child-parent-format). Приклади обох форматів описані нижче. ##### Використання формату `exports` {#using-the-exports-format} Якщо файл `values.yaml` дочірнього чарту містить поле `exports` на рівні кореня, його вміст може бути імпортований безпосередньо у значення батьківського чарту, через вказання ключів для імпорту, як у прикладі нижче: ```yaml # файл Chart.yaml батьківського чарту dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # файл values.yaml дочірнього чарту exports: data: myint: 99 ``` Оскільки ми вказуємо ключ `data` у нашому списку імпорту, Helm шукає цей ключ у полі `exports` дочірнього чарту та імпортує його вміст. Фінальні значення батьківського чарту міститимуть наше експортоване поле: ```yaml # значення батьківського чарту myint: 99 ``` Зверніть увагу, що ключ `data` не міститься у фінальних значеннях батьківського чарту. Якщо вам потрібно вказати ключ батьківського чарту, використовуйте формат "child-parent". ##### Використання формату `child-parent` {#using-the-child-parent-format} Щоб отримати доступ до значень, які не містяться у ключі `exports` значень дочірнього чарту, вам потрібно вказати шлях до джерела значень для імпорту (`child`) та шлях до місця призначення у значеннях батьківського чарту (`parent`). У прикладі нижче `import-values` інструктує Helm взяти будь-які значення, знайдені в шляху `child:`, та скопіювати їх у значення батьківського чарту в шлях, вказаний у `parent:`. ```yaml # файл Chart.yaml батьківського чарту dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` У наведеному вище прикладі значення, знайдені у шляху `default.data` у значеннях subchart1, будуть імпортовані до ключа `myimports` у значеннях батьківського чарту, як показано нижче: ```yaml # файл values.yaml батьківського чарту myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # файл values.yaml subchart1 default: data: myint: 999 mybool: true ``` Фінальні значення батьківського чарту будуть такими: ```yaml # фінальні значення батьківського чарту myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` Фінальні значення батьківського чарту тепер містять поля `myint` та `mybool`, імпортовані з subchart1. ### Керування залежностями вручну через теку `charts/` {#managing-dependencies-manually-via-the-charts-directory} Якщо потрібен більший контроль над залежностями, їх можна визначити явно, скопіювавши залежні чарти в теку `charts/`. Залежність повинна бути розпакованою текою чарту, але її імʼя не може починатися з `_` або `.`. Такі файли ігноруються завантажувачем чартів. Наприклад, якщо чарт WordPress залежить від чарту Apache, то чарт Apache (відповідної версії) розміщується в теці `charts/` чарту WordPress: ```yaml wordpress/ Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` Наведений вище приклад показує, як чарт WordPress виражає свою залежність від Apache та MySQL, включаючи ці чарти всередині своєї текиу `charts/`. **ПОРАДА:** _Щоб завантажити залежність у вашу теку `charts/`, використовуйте команду `helm pull`._ ### Операційні аспекти використання залежностей {#operational-aspects-of-using-dependencies} Попередні розділи пояснюють, як визначати залежності чартів, але як це впливає на встановлення чарту за допомогою `helm install` і `helm upgrade`? Припустимо, що чарт з назвою "A" створює такі обʼєкти Kubernetes: - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Крім того, A залежить від чарту B, який створює обʼєкти: - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" Після встановлення/оновлення чарту A створюється або змінюється єдиний реліз Helm. Цей реліз створить або оновить усі вищевказані обʼєкти Kubernetes у такому порядку: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet Це відбувається тому, що під час встановлення/оновлення чартів Helm агрегує обʼєкти Kubernetes з чарту та всіх його залежностей в єдиний набір, який потім сортується за типом, а потім за іменем, і створюється або оновлюється в такому порядку. Таким чином, створюється єдиний реліз, який містить усі обʼєкти для чарту та його залежностей. Порядок встановлення типів Kubernetes визначається переліком InstallOrder у файлі kind_sorter.go (див. [вихідний файл Helm](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ### Шаблони та Значення {#templates-and-values} Шаблони Helm Chart написані на [Go template](https://golang.org/pkg/text/template/), з додатковими функціями з бібліотеки [Sprig](https://github.com/Masterminds/sprig) та кількома іншими [спеціалізованими функціями](/howto/charts_tips_and_tricks.md). Всі файли шаблонів зберігаються у теці `templates/` чарту. Коли Helm обробляє чарти, він пропускає кожен файл у цій теці через механізм шаблонів. Значення для шаблонів надаються двома способами: - Розробники чартів можуть надати файл з назвою `values.yaml` всередині чарту. Цей файл може містити стандартні значення. - Користувачі чартів можуть надати YAML файл, який містить значення. Це можна зробити за допомогою команди `helm install`. Коли користувач надає власні значення, ці значення перезаписують значення у файлі `values.yaml` чарту. ### Файли шаблонів {#template-files} Файли шаблонів дотримуються стандартних конвенцій написання Go шаблонів (див. [документацію пакету text/template Go](https://golang.org/pkg/text/template/) для деталей). Приклад файлу шаблону може виглядати так: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` Вищенаведений приклад, заснований на [https://github.com/deis/charts](https://github.com/deis/charts), є шаблоном для контролера реплікацій Kubernetes. Він може використовувати наступні чотири значення шаблону (зазвичай визначені у файлі `values.yaml`): - `imageRegistry`: Джерело реєстру для Docker образу. - `dockerTag`: Теґ для образу Docker. - `pullPolicy`: Політика отримання образу Docker в Kubernetes. - `storage`: Сховище, стандартне значення для якого є `"minio"` Всі ці значення визначені автором шаблону. Helm не вимагає або не диктує параметри. Щоб побачити багато робочих чартів, перегляньте CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Попередньо визначені значення {#predefined-values} Значення, які постачаються через файл `values.yaml` (або за допомогою прапорця `--set`), доступні з обʼєкта `.Values` у шаблоні. Але є й інші попередньо визначені дані, які можна використовувати у ваших шаблонах. Наступні значення є попередньо визначеними, доступні кожному шаблону і не можуть бути перевизначені. Як і всі значення, імена є _чутливими до регістру_: - `Release.Name`: Назва релізу (не чарту) - `Release.Namespace`: Простір імен, в який був розгорнутий чарт. - `Release.Service`: Сервіс, який здійснив реліз. - `Release.IsUpgrade`: Це значення буде `true`, якщо поточна операція є оновленням або відкатом. - `Release.IsInstall`: Це значення буде `true`, якщо поточна операція є встановленням. - `Chart`: Зміст `Chart.yaml`. Таким чином, версію чарту можна отримати як `Chart.Version`, а авторів — з `Chart.Maintainers`. - `Files`: Обʼєкт, схожий на map, який містить всі неспеціальні файли в чарті. Це не дає вам доступ до шаблонів, але надає доступ до додаткових файлів, які присутні (якщо вони не виключені за допомогою `.helmignore`). До файлів можна отримати доступ, використовуючи `{{ index .Files "file.name" }}` або функцію `{{.Files.Get name }}`. Також можна отримати вміст файлу як `[]byte`, використовуючи `{{ .Files.GetBytes }}` - `Capabilities`: Обʼєкт, схожий на map, який містить інформацію про версії Kubernetes (`{{ .Capabilities.KubeVersion }}`) та підтримувані версії API Kubernetes (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **ПРИМІТКА:** Будь-які невідомі поля `Chart.yaml` будуть відкинуті. Вони не будуть доступні всередині обʼєкта `Chart`. Таким чином, `Chart.yaml` не можна використовувати для передачі довільно структурованих даних у шаблон. Проте для цього можна використовувати файл значень. ### Файли значень {#values-files} Беручи до уваги шаблон у попередньому розділі, файл `values.yaml`, який постачає необхідні значення, виглядатиме так: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` Файл значень має формат YAML. Чарт може містити файл стандартних значень `values.yaml`. Команда Helm install дозволяє користувачеві перевизначити значення, надавши додаткові YAML значення: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` Коли значення передаються таким чином, вони зливаються з файлом стандартних значень. Наприклад, розглянемо файл `myvals.yaml`, який виглядає так: ```yaml storage: "gcs" ``` При злитті з `values.yaml` у чарті, результат буде: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Зверніть увагу, що тільки останнє поле було перевизначене. **ПРИМІТКА:** Файл стандартних значень, що включений всередині чарту, _повинен_ називатися `values.yaml`. Але файли, вказані в командному рядку, можуть мати будь-яке імʼя. **ПРИМІТКА:** Якщо прапорець `--set` використовується з `helm install` або `helm upgrade`, ці значення просто перетворюються в YAML на клієнтському боці. **ПРИМІТКА:** Якщо будь-які необхідні записи у файлі значень існують, їх можна оголосити як обовʼязкові в шаблоні чарту, використовуючи функцію [ʼrequiredʼ](/howto/charts_tips_and_tricks.md). Будь-які з цих значень доступні всередині шаблонів, використовуючи обʼєкт `.Values`: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Область видимості, залежності та значення {#scope-dependencies-and-values} Файли значень можуть оголошувати значення як для верхнього рівня чарту, так і для будь-яких чартів, які включені у теку `charts/` цього чарту. Інакше кажучи, файл значень може надавати значення чарту та його залежностям. Наприклад, чарт WordPress, що демонструється вище, має як `mysql`, так і `apache` як залежності. Файл значень може надавати значення всім цим компонентам: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress mysql: max_connections: 100 # Надсилається до MySQL password: "secret" apache: port: 8080 # Передається Apache ``` Чарти вищого рівня мають доступ до всіх змінних, визначених нижче. Отже, чарт WordPress може отримати пароль MySQL як `.Values.mysql.password`. Але чарт нижчого рівня не може отримати доступ до елементів в батьківських чартах, тому MySQL не зможе отримати доступ до властивості `title`. Так само він не може отримати доступ до `apache.port`. Значення обмежені просторами імен, але префікси просторів імен обрізаються. Тобто для чарту WordPress, він може отримати доступ до поля пароля MySQL як `.Values.mysql.password`. Але для чарту MySQL область значень зменшена і префікс простору видалено, тому він буде бачити поле пароля просто як `.Values.password`. #### Глобальні значення {#global-values} З версії 2.0.0-Alpha.2, Helm підтримує спеціальне "глобальне" значення. Розгляньте цю змінену версію попереднього прикладу: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress global: app: MyWordPress mysql: max_connections: 100 # Надсилається до MySQL password: "secret" apache: port: 8080 # Передається Apache ``` Вищенаведене додає розділ `global` зі значенням `app: MyWordPress`. Це значення доступне _всім_ чартам як `.Values.global.app`. Наприклад, шаблони `mysql` можуть отримати доступ до `app` як `{{ .Values.global.app }}`, так само і чарт `apache`. Фактично, файл значень вище перегенерується таким чином: ```yaml title: "My WordPress Site" # Надсилається до шаблону WordPress global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Надсилається до MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Передається Apache ``` Це забезпечує спосіб поділитися однією змінною верхнього рівня з усіма субчартами, що корисно для таких речей, як встановлення властивостей `metadata`, наприклад, міток. Якщо субчарт оголошує глобальну змінну, ця глобальна змінна буде передана _далі вниз_ (в субчарти субчартів), але не _вгору_ до батьківського чарту. Немає способу, щоб субдчарт впливав на значення батьківського чарту. Також, глобальні змінні батьківських чартів мають перевагу над глобальними змінними з субчартів. ### Файли схем {#schema-files} Іноді розробник чарту може захотіти визначити структуру для своїх значень. Це можна зробити, визначивши схему у файлі `values.schema.json`. Схема представляється як [JSON Schema](https://json-schema.org/). Вона може виглядати приблизно так: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` Ця схема буде застосовуватися до значень для їх перевірки. Перевірка відбувається при виконанні будь-якої з наступних команд: - `helm install` - `helm upgrade` - `helm lint` - `helm template` Приклад файлу `values.yaml`, який відповідає вимогам цієї схеми, може виглядати так: ```yaml name: frontend protocol: https port: 443 ``` Зверніть увагу, що схема застосовується до фінального обʼєкта `.Values`, а не тільки до файлу `values.yaml`. Це означає, що наступний `yaml` файл є дійсним, за умови що чарт встановлюється з відповідним параметром `--set`, як показано нижче: ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Крім того, фінальний обʼєкт `.Values` перевіряється на відповідність _усім_ схемам субчартів. Це означає, що обмеження на субчарт не можуть бути обійдені батьківським чартом. Це також працює в зворотному напрямку — якщо субчарт має вимогу, яка не виконується у файлі `values.yaml` субчарту, батьківський чарт _повинен_ задовольняти ці вимоги, щоб бути дійсним. ### Посилання {#references} При написанні шаблонів, файлів значень і схем є кілька стандартних посилань, які можуть бути корисними: - [Go шаблони](https://godoc.org/text/template) - [Додаткові функції шаблонів](https://godoc.org/github.com/Masterminds/sprig) - [Формат YAML](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRD) {#custom-resource-definitions-crd} Kubernetes надає механізм для оголошення нових типів обʼєктів Kubernetes. Використовуючи CustomResourceDefinitions (CRD), розробники Kubernetes можуть оголошувати власні типи ресурсів. У Helm 3, CRD розглядаються як особливий вид обʼєктів. Вони встановлюються перед рештою чарту і мають певні обмеження. Файли CRD YAML повинні бути поміщені в теку `crds/` всередині чарту. Можна помістити кілька CRD (розділених маркерами початку та кінця YAML) в один файл. Helm спробує завантажити _всі_ файли в теці CRD в Kubernetes. Файли CRD _не можуть бути шаблонізовані_. Вони повинні бути звичайними YAML документами. Коли Helm встановлює новий чарт, він завантажує CRD, призупиняється, поки CRD не будуть доступні через API сервер, а потім запускає механізм шаблонів, рендерить решту чарту та завантажує її в Kubernetes. Завдяки цьому CRD інформація доступна в обʼєкті `.Capabilities` в шаблонах Helm, і шаблони Helm можуть створювати нові екземпляри обʼєктів, які були оголошені в CRD. Наприклад, якщо у вашому чарті є CRD для `CronTab` в теці `crds/`, ви можете створити екземпляри типу `CronTab` в теці `templates/`: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` Файл `crontab.yaml` повинен містити CRD без директив шаблона: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Тоді шаблон `mycrontab.yaml` може створити новий `CronTab` (використовуючи шаблони як звичайно): ```yaml apiVersion: stable.example.com/v1 kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm забезпечить, що тип обʼєкта `CronTab` був встановлений і доступний з API сервера Kubernetes, перш ніж продовжити встановлення обʼєктів в `templates/`. ### Обмеження на CRD {#limitations-on-crds} На відміну від більшості обʼєктів у Kubernetes, CRD (Custom Resource Definitions) встановлюються глобально. Тому Helm вживає дуже обережний підхід до управління CRD. CRD підлягають таким обмеженням: - CRD ніколи не перевстановлюються. Якщо Helm визначає, що CRD у теці `crds/` вже присутні (незалежно від версії), Helm не намагатиметься їх встановити чи оновити. - CRD ніколи не встановлюються під час оновлення або відкату. Helm створює CRD тільки під час операцій встановлення. - CRD ніколи не видаляються. Видалення CRD автоматично видаляє весь вміст CRD у всіх просторах імен у кластері. Тому Helm не видалятиме CRD. Операторам, які хочуть оновити або видалити CRD, рекомендується робити це вручну і з великою обережністю. ## Використання Helm для управління чартами {#using-helm-to-manage-charts} Інструмент `helm` має кілька команд для роботи з чартами. Він може створити новий чарт для вас: ```console $ helm create mychart Created mychart/ ``` Після редагування чарта, `helm` може упакувати його в архів чартів для вас: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` Ви також можете використовувати `helm`, щоб знайти проблеми з форматуванням або інформацією вашого чарта: ```console $ helm lint mychart No issues found ``` ## Репозиторії чартів {#chart-repositories} Репозиторій чартів — це HTTP-сервер, який містить один або більше упакованих чартів. Хоча `helm` можна використовувати для управління локальними теками чартів, для обміну чартами переважно використовують репозиторій чартів. Будь-який HTTP-сервер, який може надавати YAML файли та tar файли та може відповідати на GET запити, можна використовувати як сервер репозиторіїв. Команда Helm тестувала деякі сервери, включаючи Google Cloud Storage з увімкненим режимом веб-сайту та S3 з увімкненим режимом веб-сайту. Репозиторій характеризується наявністю спеціального файлу з назвою `index.yaml`, який містить список всіх пакетів, наданих репозиторієм, разом із метаданими, які дозволяють отримувати та перевіряти ці пакети. На стороні клієнта репозиторії управляються командами `helm repo`. Однак Helm не надає інструменти для завантаження чартів на віддалені сервери репозиторіїв. Це повʼязано з тим, що така функціональність вимагала б значних вимог до сервера, що реалізує репозиторій, і підвищувала б барʼєр для налаштування репозиторію. ## Стартер-паки чартів {#chart-starter-packs} Команда `helm create` має необовʼязковий параметр `--starter`, який дозволяє вказати "стартовий чарт". Також параметр стартера має короткий псевдонім `-p`. Приклади використання: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Стартери — це звичайні чарти, але вони розташовані в `$XDG_DATA_HOME/helm/starters`. Як розробник чартів, ви можете створювати чарти, які спеціально призначені для використання як стартери. Такі чарти повинні бути спроєктовані з урахуванням наступних міркувань: - Файл `Chart.yaml` буде перезаписаний генератором. - Користувачі очікують, що зміст такого чарта буде змінений, тому документація повинна вказувати, як користувачі можуть це зробити. - Всі входження `` будуть замінені на вказане імʼя чарту, щоб стартові чарти можна було використовувати як шаблони, за винятком деяких змінних файлів. Наприклад, якщо ви використовуєте власні файли в теці `vars` або певні файли `README.md`, `` НЕ буде переважати всередині них. Крім того, опис чарту не успадковується. На даний момент єдиний спосіб додати чарт до `$XDG_DATA_HOME/helm/starters` — це вручну скопіювати його туди. У документації вашого чарту ви можете пояснити цей процес. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Хуки чартів description: Опис, як працювати з хуками чартів. sidebar_position: 2 --- Helm надає механізм _хуків_, що дозволяє розробникам чартів втручатися на певних етапах життєвого циклу релізу. Наприклад, ви можете використовувати хуки для: - Завантаження ConfigMap або Secret під час встановлення до завантаження будь-яких інших чартів. - Виконання Job для резервного копіювання бази даних перед встановленням нового чарту, а потім виконання другого Job після оновлення для відновлення даних. - Запуску Job перед видаленням релізу для мʼякого виведення сервісу з обігу перед його видаленням. Хуки працюють як звичайні шаблони, але мають спеціальні анотації, які змушують Helm використовувати їх по-іншому. У цьому розділі ми розглянемо базовий шаблон використання хуків. ## Доступні хуки {#available-hooks} Ось які хуки визначені: | Значення анотації | Опис | | ----------------- | -------------------------------------------------------------------------------------------------------- | | `pre-install` | Виконується після рендерингу шаблонів, але до створення будь-яких ресурсів у Kubernetes | | `post-install` | Виконується після завантаження всіх ресурсів у Kubernetes | | `pre-delete` | Виконується під час запиту на видалення перед видаленням будь-яких ресурсів з Kubernetes | | `post-delete` | Виконується під час запиту на видалення після видалення всіх ресурсів релізу | | `pre-upgrade` | Виконується під час запиту на оновлення після рендерингу шаблонів, але до оновлення будь-яких ресурсів | | `post-upgrade` | Виконується під час запиту на оновлення після оновлення всіх ресурсів | | `pre-rollback` | Виконується під час запиту на відкат після рендерингу шаблонів, але до відкату будь-яких ресурсів | | `post-rollback` | Виконується під час запиту на відкат після модифікації всіх ресурсів | | `test` | Виконується, коли викликано підкоманду Helm test ([переглянути документацію тестів](/topics/chart_tests.md)) | _Зверніть увагу, що хук `crd-install` був видалений на користь теки `crds/` у Helm 3._ ## Хуки та життєвий цикл релізу {#hooks-and-the-release-lifecycle} Хуки дозволяють вам, як розробнику чартів, виконувати операції на стратегічних етапах життєвого циклу релізу. Наприклад, розглянемо життєвий цикл для `helm install`. Стандартно життєвий цикл виглядає так: 1. Користувач виконує `helm install foo`. 2. Викликається API бібліотеки Helm для встановлення. 3. Після деякої перевірки бібліотека рендерить шаблони `foo`. 4. Бібліотека завантажує результуючі ресурси у Kubernetes. 5. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. 6. Клієнт виходить. Helm визначає два хуки для життєвого циклу `install`: `pre-install` і `post-install`. Якщо розробник чарту `foo` реалізує обидва хуки, життєвий цикл змінюється таким чином: 1. Користувач виконує `helm install foo`. 2. Викликається API бібліотеки Helm для встановлення. 3. CRD у теці `crds/` встановлюються. 4. Після деякої перевірки бібліотека рендерить шаблони `foo`. 5. Бібліотека готується виконати хуки `pre-install` (завантаження ресурсів хука у Kubernetes). 6. Бібліотека сортує хуки за вагою (стандартно вага дорівнює 0), за типом ресурсу та нарешті за імʼям за зростанням. 7. Бібліотека завантажує хук з найменшою вагою спочатку (від негативної до позитивної) 8. Бібліотека чекає, поки хук стане "Ready" (крім CRD) 9. Бібліотека завантажує результуючі ресурси у Kubernetes. Зверніть увагу, що якщо встановлено прапорець `--wait`, бібліотека чекатиме, поки всі ресурси не стануть готовими, і не запустить хук `post-install`, поки вони не будуть готові. 10. Бібліотека виконує хук `post-install` (завантаження ресурсів хука). 11. Бібліотека чекає, поки хук стане "Ready". 12. Бібліотека повертає обʼєкт релізу (та інші дані) клієнту. 13. Клієнт виходить. Що означає чекати, поки хук стане готовим? Це залежить від ресурсу, оголошеного в хуку. Якщо ресурс є типу `Job` або `Pod`, Helm чекатиме, поки він успішно виконається. І якщо хук не вдається, реліз зазнає невдачі. Це _блокуюча операція_, тому клієнт Helm призупиниться, поки Job виконується. Для всіх інших типів, як тільки Kubernetes позначає ресурс як завантажений (доданий або оновлений), ресурс вважається "Ready". Коли оголошено багато ресурсів у хуку, ресурси виконуються послідовно. Якщо у них є ваги хуків (див. нижче), вони виконуються в порядку ваг. Починаючи з Helm 3.2.0, ресурси хуків з однаковою вагою встановлюються в тому ж порядку, що і звичайні не-хукові ресурси. В іншому випадку, порядок не гарантується. (У Helm 2.3.0 і пізніше вони сортуються в алфавітному порядку. Це поведінка не є обовʼязковою і може змінитися в майбутньому.) Вважається гарною практикою додати вагу хуку та встановити її на `0`, якщо вага не є важливою. ### Ресурси хуків не управляються відповідними релізами {#hook-resources-are-not-managed-by-releases} Ресурси, які створює хук, наразі не відстежуються та не управляються як частина релізу. Як тільки Helm перевіряє, що хук досяг свого готового стану, він залишає ресурс хука без змін. Збір сміття ресурсів хуків при видаленні відповідного релізу може бути додано до Helm 3 у майбутньому, тому будь-які ресурси хуків, які ніколи не повинні бути видалені, повинні бути анотовані як `helm.sh/resource-policy: keep`. Практично це означає, що якщо ви створюєте ресурси в хуку, ви не можете покладатися на `helm uninstall`, щоб видалити ресурси. Щоб знищити такі ресурси, вам потрібно або [додати власну анотацію `helm.sh/hook-delete-policy`](#hook-deletion-policies) до файлу шаблону хука, або [встановити поле часу життя (TTL) ресурсу Job](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Написання хуку {#writing-a-hook} Хуки — це просто манифести Kubernetes з особливими анотаціями в секції `metadata`. Оскільки це шаблони, ви можете використовувати всі звичайні можливості шаблонів, включаючи читання `.Values`, `.Release` та `.Template`. Наприклад, цей шаблон, збережений у `templates/post-install-job.yaml`, оголошує Job, який буде виконаний при `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # Це те, що визначає цей ресурс як хук. Без цього рядка # job вважається частиною релізу. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` Що робить цей шаблон хуком, так це анотація: ```yaml annotations: "helm.sh/hook": post-install ``` Один ресурс може реалізовувати кілька хуків: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Аналогічно, немає обмежень на кількість різних ресурсів, які можуть реалізувати даний хук. Наприклад, можна оголосити як secret, так і config map як pre-install хук. Коли субчарти оголошують хуки, вони також оцінюються. Немає способу для основного чарту відключити хуки, оголошені субчартами. Можливо визначити вагу для хука, що допоможе створити детерміністичний порядок виконання. Ваги визначаються за допомогою наступної анотації: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Ваги хуків можуть бути позитивними або негативними числами, але повинні бути представлені як рядки. Коли Helm починає цикл виконання хуків певного типу, він сортує ці хуки у висхідному порядку. ### Політики видалення хуків {#hook-deletion-policies} Можливо визначити політики, які визначають, коли видаляти відповідні ресурси хуків. Політики видалення хуків визначаються за допомогою наступної анотації: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` Ви можете вибрати одне або кілька визначених значень анотацій: | Значення анотації | Опис | | ----------------------- | ---------------------------------------------------------------- | | `before-hook-creation` | Видалити попередній ресурс перед запуском нового хуку (стандартно) | | `hook-succeeded` | Видалити ресурс після успішного виконання хука | | `hook-failed` | Видалити ресурс, якщо хук зазнав невдачі під час виконання | Якщо анотація політики видалення хука не вказана, стандартно застосовується поведінка `before-hook-creation`. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: Посібники sidebar_position: 3 --- # Тематичні посібники Тут ви знайдете вступ до всіх ключових частин Helm, які вам знадобляться або які ви хочете знати. import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: Застарілі API Kubernetes description: Пояснення щодо застарілих API Kubernetes у Helm sidebar_position: 14 --- Kubernetes є системою, що керується API, і API еволюціонує з часом, відображаючи зміну розуміння проблемного простору. Це загальноприйнята практика для систем та їх API. Важливою частиною еволюції API є наявність чіткої політики застарівання та процесу, який інформує користувачів про те, як впроваджуються зміни до API. Іншими словами, споживачі вашого API повинні знати заздалегідь, коли та в якій версії API буде видалено або змінено. Це дозволяє уникнути неприємних сюрпризів та руйнівних змін для споживачів. [Політика застарівання Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) документує, як Kubernetes обробляє зміни версій API. Політика щодо застарівання визначає часові рамки підтримки версій API після оголошення про їх застарівання. Тому важливо бути в курсі оголошень про застарівання та знати, коли версії API будуть видалені, щоб мінімізувати вплив. Прикладом такого оголошення є [оголошення про видалення застарілих версій API у Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/), яке було опубліковано за кілька місяців до релізу. Ці версії API були оголошені застарілими ще раніше. Це свідчить про наявність чіткої політики, яка інформує споживачів про підтримку версій API. Шаблони Helm вказують [групу API Kubernetes](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) при визначенні обʼєкта Kubernetes, аналогічно до маніфесту Kubernetes. Це вказується в полі `apiVersion` шаблону і визначає версію API обʼєкта Kubernetes. Це означає, що користувачі Helm та підтримувачі чартів повинні знати, коли версії API Kubernetes були оголошені застарілими та в якій версії Kubernetes вони будуть видалені. ## Підтримувачі чартів {#chart-maintainers} Вам слід перевіряти свої чарти на наявність версій API Kubernetes, які оголошені застарілими або видаленими у певній версії Kubernetes. Виявлені версії API, які скоро перестануть підтримуватися або вже не підтримуються, слід оновити до підтримуваних версій і випустити нову версію чарту. Версія API визначається полями `kind` і `apiVersion`. Наприклад, ось версія API обʼєкта `Deployment`, яка була видалена в Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Користувачі Helm {#helm-users} Вам слід перевірити чарти, які ви використовуєте (аналогічно до [підтримувачів чартів](#chart-maintainers)), і визначити будь-які чарти, у яких версії API застарілі або видалені у певній версії Kubernetes. Для виявлених чартів вам потрібно знайти останню версію чарту (яка містить підтримувані версії API) або оновити чарт самостійно. Крім того, вам також потрібно перевірити будь-які розгорнуті чарти (тобто релізи Helm) на наявність застарілих або видалених версій API. Це можна зробити, отримавши деталі релізу за допомогою команди `helm get manifest`. Метод оновлення релізу Helm до підтримуваних API залежить від ваших знахідок, як описано нижче: 1. Якщо ви знайшли лише застарілі версії API, то: - Виконайте `helm upgrade` з версією чарту, яка підтримує версії API Kubernetes. - Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". 2. Якщо ви знайшли будь-яку версію API, яка була видалена у версії Kubernetes, то: - Якщо ви використовуєте версію Kubernetes, де ці версії API все ще доступні (наприклад, ви використовуєте Kubernetes 1.15 і виявили, що використовуєте API, які будуть видалені у Kubernetes 1.16): - Дотримуйтесь процедури, описаної у пункті 1. - Інакше (наприклад, ви вже використовуєте версію Kubernetes, де деякі версії API, зазначені у `helm get manifest`, більше не доступні): - Вам потрібно відредагувати маніфест релізу, який зберігається в кластері, щоб оновити версії API до підтримуваних. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації. > Примітка: У всіх випадках оновлення релізу Helm до підтримуваних API ніколи не слід виконувати відкат релізу до версії, яка передує версії релізу з підтримуваними API. > Рекомендація: Найкраща практика — оновлювати релізи, використовуючи застарілі версії API, до підтримуваних версій API до того, як виконати оновлення кластера Kubernetes, який видаляє ці версії API. Якщо ви не оновите реліз, як запропоновано вище, ви отримаєте помилку, схожу на наступну, при спробі оновити реліз у версії Kubernetes, де його версія API була видалена: ```log Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm не вдається виконати оновлення в такому випадку, оскільки він намагається створити патч відмінностей між поточним розгорнутим релізом (який містить версії API Kubernetes, що були видалені в цій версії Kubernetes) та чартом, який ви передаєте з оновленими/підтримуваними версіями API. Основна причина невдачі полягає в тому, що коли Kubernetes видаляє версію API, клієнтська бібліотека Go для Kubernetes більше не може аналізувати застарілі обʼєкти, і тому Helm зазнає невдачі при виклику бібліотеки. На жаль, Helm не в змозі відновитися з такої ситуації та більше не може керувати таким релізом. Див. [Оновлення версій API маніфесту релізу](#updating-api-versions-of-a-release-manifest) для отримання додаткової інформації про те, як відновитися з такої ситуації. ## Оновлення версій API маніфесту релізу {#updating-api-versions-of-a-release-manifest} Маніфест є властивістю обʼєкта релізу Helm, який зберігається в полі `data` в Secret (стандартно) або ConfigMap у кластері. Поле `data` містить обʼєкт у стиснутому вигляді, закодований у base64 (існує додаткове кодування base64 для Secret). Для кожної версії/ревізії релізу існує свій Secret/ConfigMap у просторі імен релізу. Ви можете використовувати втулок Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) для оновлення релізу до підтримуваних API. Ознайомтеся з readme для отримання додаткової інформації. Альтернативно, ви можете дотримуватися цих ручних кроків для оновлення версій API маніфесту релізу. Залежно від вашої конфігурації, дотримуйтесь кроків для Secret або ConfigMap. - Отримайте імʼя Secret або ConfigMap, повʼязане з останнім розгорнутим релізом: - Secret: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk ʼ{print $1}ʼ | grep -v NAME` - ConfigMap: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk ʼ{print $1}ʼ | grep -v NAME` - Отримайте деталі останнього розгорнутого релізу: - Secret: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap: `kubectl get configmap -n -o yaml > release.yaml` - Зробіть резервну копію релізу на випадок, якщо вам знадобиться відновлення у разі помилки: - `cp release.yaml release.bak` - У разі необхідності, відновіть: `kubectl apply -f release.bak -n ` - Розкодуйте обʼєкт релізу: - Secret: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap: `cat release.yaml | grep -oP ʼ(?<=release: ).*ʼ | base64 -d | gzip -d > release.data.decoded` - Змініть версії API маніфестів. Ви можете використовувати будь-який інструмент (наприклад, редактор) для внесення змін. Це знаходиться у полі `manifest` вашого розкодованого обʼєкта релізу (`release.data.decoded`). - Закодуйте обʼєкт релізу: - Secret: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap: `cat release.data.decoded | gzip | base64` - Замість значення властивості `data.release` у файлі розгорнутого релізу (`release.yaml`) вставте новий закодований обʼєкт релізу. - Застосуйте файл до простору імен: `kubectl apply -f release.yaml -n ` - Виконайте `helm upgrade` з версією чарта, яка підтримує версії API Kubernetes. - Додайте опис до оновлення, щось на зразок "не виконувати відкат до версії Helm, що передує цій поточній версії". ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Дистрибутиви Kubernetes description: Містить інформацію про використання Helm у специфічних середовищах Kubernetes. sidebar_position: 10 --- Helm повинен працювати з будь-якою [відповідною версією Kubernetes](https://github.com/cncf/k8s-conformance) (сертифікованою чи ні). Цей документ містить інформацію про використання Helm у специфічних середовищах Kubernetes. Будь ласка, додайте більше деталей про будь-які дистрибутиви (відсортовано за алфавітом), якщо це потрібно. ## AKS Helm працює з [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm було протестовано і він працює на платформі Kubernetes Mesosphere DC/OS 1.11, і не вимагає додаткової конфігурації. ## EKS Helm працює з Amazon Elastic Kubernetes Service (Amazon EKS): [Використання Helm з Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Хостингова платформа Kubernetes Google GKE відома своєю сумісністю з Helm і не потребує додаткової конфігурації. ## `scripts/local-cluster` та Hyperkube {#scripts-local-cluster-and-hyperkube} Hyperkube, налаштований через `scripts/local-cluster.sh`, відомий своєю сумісністю. Для чистого Hyperkube можливо, що знадобиться деяка ручна конфігурація. ## IKS Helm працює з [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm регулярно тестується з [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm працює у кластерах, які налаштовані за допомогою KubeOne без обмежень. ## Kubermatic Helm працює у кластерах користувачів, створених Kubermatic без обмежень. Оскільки кластер seed може бути налаштований по-різному, підтримка Helm залежить від їх конфігурації. ## MicroK8s Helm можна активувати в [MicroK8s](https://microk8s.io) за допомогою команди: `microk8s.enable helm3` ## Minikube Helm протестований і відомий своєю сумісністю з [Minikube](https://github.com/kubernetes/minikube). Додаткової конфігурації не потребує. ## Openshift Helm працює без проблем на OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (версія >= 3.6) або OpenShift Origin (версія >= 3.6). Щоб дізнатися більше, прочитайте [цей блог](https://blog.openshift.com/getting-started-helm-openshift/). ## Platform9 Helm попередньо встановлений в [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 надає доступ до всіх офіційних чартів Helm через інтерфейс App Catalog і нативний Kubernetes CLI. Додаткові репозиторії можна додати вручну. Додаткові відомості можна знайти в [статті Platform9 App Catalog](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu з `kubeadm` {#ubuntu-with-kubeadm} Kubernetes, налаштований за допомогою `kubeadm`, відомий своєю сумісністю з наступними дистрибутивами Linux: - Ubuntu 16.04 - Fedora release 25 Деякі версії Helm (v2.0.0-beta2) вимагають від вас `export KUBECONFIG=/etc/kubernetes/admin.conf` або створення `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm працює на VMware Tanzu Kubernetes Grid, TKG, без необхідності змінювати конфігурацію. Tanzu CLI може управляти встановленням пакетів для [helm-controller](https://fluxcd.io/flux/components/helm/), що дозволяє декларативно управляти релізами чартів Helm. Додаткові відомості доступні в документації TKG для [CLI-управлінських пакетів](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: Бібліотечні чарти description: Описує бібліотечні чарти та приклади їх використання sidebar_position: 4 --- Бібліотечний чарт — це тип [Helm чарту](/topics/charts.md), який визначає примітиви або визначення, що можуть бути спільно використані шаблонами Helm в інших чартах. Це дозволяє користувачам ділитися фрагментами коду, які можна повторно використовувати у різних чартах, уникаючи повторень та підтримуючи чарти [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Don't Repeat Yourself). Бібліотечний чарт було представлено у Helm 3 для формального визнання загальних або допоміжних чартів, які використовувалися авторами чартів ще з Helm 2. Додавши його як тип чарту, він надає: - Спосіб чітко розрізняти загальні та чарти застосунків - Логіку, що запобігає встановленню загального чарту - Відсутність рендерингу шаблонів у загальному чарті, які можуть містити артефакти релізу - Дозвіл залежним чартам використовувати контекст імпортера Автор чарту може визначити загальний чарт як бібліотечний чарт та бути впевненим, що Helm обробить чарт стандартним узгодженим способом. Це також означає, що визначення у прикладному чарті можуть бути спільно використані шляхом зміни типу чарту. ## Створення простого бібліотечного чарту {#creating-a-simple-library-chart} Як вже згадувалося раніше, бібліотечний чарт — це тип [Helm чарту](/topics/charts.md). Це означає, що ви можете почати зі створення шаблонного чарту: ```console $ helm create mylibchart Creating mylibchart ``` Спочатку видаліть усі файли в теці `templates`, оскільки ми будемо створювати власні визначення шаблонів у цьому прикладі. ```console $ rm -rf mylibchart/templates/* ``` Файл значень (values.yaml) також не буде потрібен. ```console $ rm -f mylibchart/values.yaml ``` Перш ніж перейти до створення загального коду, давайте швидко переглянемо деякі відповідні концепції Helm. [іменований шаблон](/chart_template_guide/named_templates.md) (іноді називають частковим або субшаблоном) — це просто шаблон, визначений у файлі та який має назву. У теці `templates/` будь-який файл, який починається з підкреслення (_), не призначений для виводу маніфесту Kubernetes. Тому зазвичай допоміжні шаблони та часткові шаблони розміщуються у файлах `_*.tpl` або `_*.yaml`. У цьому прикладі ми створимо загальний ConfigMap, який створює пустий ресурс ConfigMap. Ми визначимо загальний ConfigMap у файлі `mylibchart/templates/_configmap.yaml` наступним чином: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` Конструкція ConfigMap визначена у шаблоні з назвою `mylibchart.configmap.tpl`. Це простий ConfigMap з пустим ресурсом `data`. У цьому файлі є ще один іменований шаблон назвою, назва якого `mylibchart.configmap`. Цей іменований шаблон включає інший іменований шаблон `mylibchart.util.merge`, який приймає 2 іменовані шаблони як аргументи: шаблон, що викликає `mylibchart.configmap` та `mylibchart.configmap.tpl`. Допоміжна функція `mylibchart.util.merge` є іменованим шаблоном у `mylibchart/templates/_util.yaml`. Це зручний інструмент з [Загального допоміжного чарту Helm](#the-common-helm-helper-chart), оскільки він обʼєднує 2 шаблони та перевизначає будь-які спільні частини в обох: ```yaml {{- /* mylibchart.util.merge зʼєднує два YAML-шаблони та виводить результат. Він приймає масив із трьох значень: - контекст верхнього рівня - ім'я шаблону перевизначення (призначення) - ім'я шаблону бази (джерело) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` Це важливо, коли чарт хоче використовувати загальний код, який йому потрібно налаштувати за допомогою своєї конфігурації. Нарешті, змініть тип чарту на `library`. Це вимагає редагування файлу `mylibchart/Chart.yaml` наступним чином: ```yaml apiVersion: v2 name: mylibchart description: Helm чарт для Kubernetes # Чарт може бути або 'application', або 'library'. # # Чарти застосунків є колекцією шаблонів, які можуть бути упаковані # у версійні архіви для розгортання. # # Бібліотечні чарти надають корисні утиліти або функції для розробника # чартів. Вони включаються як залежність прикладних чартів для вбудування # цих утиліт та функцій у процес рендерингу. Бібліотечні чарти не визначають # жодних шаблонів і тому не можуть бути розгорнуті. # type: application type: library # Це версія чарту. Це номер версії повинен збільшуватися кожного разу, # коли ви вносите зміни в чарт і його шаблони, включаючи версію програми. version: 0.1.0 # Це номер версії програми, що розгортається. Цей номер версії повинен # збільшуватися кожного разу, коли ви вносите зміни в програму, і # рекомендується використовувати з лапками. appVersion: "1.16.0" ``` Тепер бібліотечний чарт готовий до спільного використання, а його визначення ConfigMap — до повторного використання. Перш ніж продовжити, варто перевірити, чи розпізнає Helm чарт як бібліотечний: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Використання простого бібліотечного чарту {#use-a-simple-library-chart} Настав час використати бібліотечний чарт. Для цього створимо знову шаблонний чарт: ```console $ helm create mychart Creating mychart ``` Знову очистимо файли шаблонів, оскільки ми хочемо створити лише ConfigMap: ```console $ rm -rf mychart/templates/* ``` Якщо ми хочемо створити простий ConfigMap у шаблоні Helm, він може виглядати приблизно так: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` Однак, ми будемо повторно використовувати загальний код, створений у `mylibchart`. ConfigMap можна створити у файлі `mychart/templates/configmap.yaml` наступним чином: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` Ви бачите, що це спрощує нашу роботу, успадковуючи загальне визначення ConfigMap, яке додає стандартні властивості для ConfigMap. У нашому шаблоні ми додаємо конфігурацію, у цьому випадку ключ даних `myvalue` та його значення. Конфігурація перекриває пустий ресурс загального ConfigMap. Це можливо завдяки допоміжній функції `mylibchart.util.merge`, яку ми згадували у попередньому розділі. Щоб мати можливість використовувати загальний код, нам потрібно додати `mylibchart` як залежність. Додайте наступний код в кінець файлу `mychart/Chart.yaml`: ```yaml # Мій загальний код у бібліотечному чарті dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` Це включає бібліотечний чарт як динамічну залежність із файлової системи, яка знаходиться на тому самому рівні, що і наш прикладний чарт. Оскільки ми включаємо бібліотечний чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює бібліотечний чарт у вашу теку `charts/`. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` Тепер ми готові розгорнути наш чарт. Перш ніж встановлювати, варто перевірити спочатку рендеринг шаблону. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` Це виглядає як ConfigMap, який ми хочемо, з перезаписуванням даних `myvalue: Hello World`. Встановімо його: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` Ми можемо отримати реліз і побачити, що фактичний шаблон був завантажений. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Переваги бібліотечних чартів {#library-chart-benefits} З огляду на те, що бібліотечні чарти не можуть працювати як самостійні чарти, вони можуть використовувати такі функції: - Об’єкт `.Files` посилається на шляхи файлів у головному чарті, а не на локальний шлях до бібліотечного чарту. - Об’єкт `.Values` є таким самим, як і в головному чарті, на відміну від [субчартів](/chart_template_guide/subcharts_and_globals.md) застосунків, які отримують розділ значень, налаштованих під їхнім заголовком у головному чарті. ## Common Helm Helper Chart {#the-common-helm-helper-chart} ```markdown Примітка: Репозиторій Common Helm Helper Chart на Github більше не підтримується, і репозиторій було визнано застарілим та зархівовано. ``` Цей [чарт](https://github.com/helm/charts/tree/master/incubator/common) був початковим зразком для спільних чартів. Він надає утиліти, які відображають найкращі практики розробки чартів Kubernetes. Найкраще, що ви можете використати його одразу, коли розробляєте свої чарти, щоб отримати корисний загальний код. Ось короткий спосіб його використання. Для отримання додаткових деталей перегляньте [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Створіть знову шаблонний чарт: ```console $ helm create demo Creating demo ``` Використаймо загальний код з helper chart. Спочатку відредагуйте файл deployment `demo/templates/deployment.yaml` наступним чином: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Вкажіть перевизначення для вашого ресурсу Deployment тут, наприклад apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` І тепер файл сервісу, `demo/templates/service.yaml`, наступним чином: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Вкажіть перевизначення для вашого ресурсу Service тут, наприклад # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` Ці шаблони демонструють, як використання загального коду з helper chart спрощує ваше кодування до налаштування чи конфігурації ресурсів. Щоб мати можливість використовувати загальний код, нам потрібно додати `common` як залежність. Додайте наступне в кінець файлу `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Примітка: вам потрібно буде додати `incubator` до списку репозиторіїв Helm (`helm repo add`). Оскільки ми включаємо чарт як динамічну залежність, нам потрібно виконати `helm dependency update`. Це скопіює helper chart у вашу теку `charts/`. Оскільки helper chart використовує деякі конструкції Helm 2, вам потрібно буде додати наступне до `demo/values.yaml`, щоб дозволити завантаження образу `nginx`, оскільки це було оновлено в шаблонному чарті Helm 3: ```yaml image: tag: 1.16.0 ``` Ви можете перевірити, чи правильні шаблони чарту, перед розгортанням, використовуючи команди `helm lint` і `helm template`. Якщо все добре, розгорніть чарт, використовуючи `helm install`! ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Управління правами доступу для SQL-сховища description: Дізнайтеся, як налаштувати права доступу при використанні SQL-сховища. sidebar_position: 16 --- Цей документ надає рекомендації користувачам щодо налаштування та управління правами доступу при використанні SQL-сховища. ## Вступ {#introduction} Для керування правами доступу Helm використовує функцію RBAC (Role-Based Access Control) Kubernetes. Проте, коли використовується SQL-сховище, ролі Kubernetes не можуть бути використані для визначення, чи може користувач отримати доступ до певного ресурсу. У цьому документі описано, як створювати та керувати такими правами доступу. ## Ініціалізація {#initialization} При першому підключенні CLI Helm до вашої бази даних клієнт перевірить, чи було її попередньо ініціалізовано. Якщо ні, клієнт автоматично подбає про необхідне налаштування. Для цього ініціалізація потребує адміністративних привілеїв у схемі public або принаймні можливості: * створення таблиці; * надання привілеїв на схему public. Після виконання міграції в базі даних всі інші ролі зможуть використовувати клієнт. ## Надання привілеїв неадміністративному користувачеві в PostgreSQL {#grant-privileges-to-a-non-admin-user-in-postgresql} Для керування правами доступу драйвер SQL-сховища використовує функцію [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html) (Row-Level Security) PostgreSQL. RLS дозволяє всім користувачам читати/записувати в одну й ту ж таблицю, але без можливості маніпулювати однаковими рядками, якщо їм це не було явно дозволено. Стандартно будь-яка роль, яка не отримала відповідних привілеїв, завжди отримуватиме порожній список при виконанні команди `helm list` і не матиме змоги отримати або змінити будь-який ресурс у кластері. Розглянемо, як надати певній ролі доступ до конкретних просторів імен: ```sql CREATE POLICY <назва> ON releases_v1 FOR ALL TO <роль> USING (namespace = 'default'); ``` Ця команда надасть дозволи на читання та запис всіх ресурсів, які відповідають умові `namespace = 'default'`, для ролі `role`. Після створення цієї політики користувач, підключений до бази даних від імені ролі `role`, зможе бачити всі випуски в просторі імен `default` при виконанні команди `helm list`, а також змінювати та видаляти їх. Привілеї можна керувати детально за допомогою RLS, і можливо буде корисним обмежити доступ, залежно від різних стовпців таблиці: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Втулки Helm description: Описує, як використовувати та створювати втулки для розширення функціональності Helm. sidebar_position: 12 --- Втулок Helm — це інструмент, до якого можна отримати доступ через CLI `helm`, але який не є частиною основного коду Helm. Наявні втулки можна знайти у [відповідному](/community/related#helm-plugins) розділі або шукаючи на [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). Цей посібник пояснює, як використовувати та створювати втулки. ## Огляд {#an-overview} Втулки Helm є додатковими інструментами, які безперешкодно інтегруються з Helm. Вони надають спосіб розширення основного набору функцій Helm без потреби написання кожної нової функції на Go і додавання її до основного інструменту. Втулки Helm мають такі особливості: - Їх можна додавати та видаляти з установки Helm без впливу на основний інструмент Helm. - Вони можуть бути написані будь-якою мовою програмування. - Вони інтегруються з Helm і будуть відображатися в `helm help` та інших місцях. Втулки Helm знаходяться в `$HELM_PLUGINS`. Ви можете дізнатися поточне значення цієї змінної, включаючи стандартні значення, коли не задано в середовищі, за допомогою команди `helm env`. Модель втулків Helm частково моделюється на основі моделі втулків Git. Відповідно, іноді ви можете чути, що `helm` називають _porcelain_ шаром, а втулки — _plumbing_. Це скорочений спосіб зазначити, що Helm забезпечує користувацький досвід і верхній рівень обробки логіки, тоді як втулки виконують "детальну роботу" для виконання бажаної дії. ## Встановлення втулка {#installing-a-plugin} Втулки встановлюються за допомогою команди `$ helm plugin install `. Ви можете передати шлях до втулка у вашій локальній файловій системі або URL віддаленого репозиторію VCS. Команда `helm plugin install` клонуватиме або копіюватиме втулок за вказаним шляхом/URL у `$HELM_PLUGINS`. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` Якщо у вас є дистрибутив втулка у форматі tar, просто розпакуйте втулок у теку `$HELM_PLUGINS`. Ви також можете встановлювати втулки tarball безпосередньо з URL, використовуючи `helm plugin install https://domain/path/to/plugin.tar.gz`. ## Тестування локально створеного втулка {#testing-a-locally-built-plugin} Спочатку вам потрібно знайти шлях до `HELM_PLUGINS`, для цього виконайте наступну команду: ```bash helm env ``` Змініть поточну теку на теку, в яку встановлено `HELM_PLUGINS`. Тепер ви можете додати символічне посилання на збірку вашого втулка, у цьому прикладі ми зробили це для `mapkubeapis`. ```bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Створення втулків {#building-a-plugin} З усіх боків втулок схожий на чарт. Кожен втулок має теку верхнього рівня, а також файл `plugin.yaml`. ```none $HELM_PLUGINS/ |- last/ | |- plugin.yaml |- last.sh ``` У наведеному прикладі втулок `last` міститься у теці, що називається `last`. Він має два файли: `plugin.yaml` (обовʼязковий) та виконуваний скрипт, `last.sh` (необовʼязковий). Ядро втулка — це простий YAML файл, названий `plugin.yaml`. Ось YAML для втулка, який допомагає отримати останню назву релізу: ```yaml name: "last" version: "0.1.0" usage: "отримати останню назву релізу" description: "отримати останню назву релізу" ignoreFlags: false command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r" platformCommand: - os: linux arch: i386 command: "$HELM_BIN list --short --max 1 --date -r" - os: linux arch: amd64 command: "$HELM_BIN list --short --max 1 --date -r" - os: windows arch: amd64 command: "$HELM_BIN list --short --max 1 --date -r" ``` `name` — це імʼя втулка. Коли Helm виконує цей втулок, це імʼя буде використовуватися (наприклад, `helm NAME` викликає цей втулок). _`name` повинно відповідати імені теки._ У нашому прикладі втулок з `name: last` має бути поміщений у теку з назвою `last`. Обмеження для `name`: - `name` не може дублювати одну з наявних команд на верхньому рівні `helm`. - `name` має бути обмежено символами ASCII a-z, A-Z, 0-9, `_` та `-`. `version` — це версія втулка за SemVer 2. `usage` і `description` використовуються для створення тексту довідки команди. Перемикач `ignoreFlags` вказує Helm, що _не_ слід передавати прапорці втулку. Якщо втулок викликаний з `helm myplugin --foo` і `ignoreFlags: true`, тоді `--foo` буде мовчки відкинуто. Нарешті, і найголовніше, `platformCommand` або `command` — це команда, яку цей втулок виконає, коли його викликають. Розділ `platformCommand` визначає специфічні для ОС/Архітектури варіації команди. Наступні правила застосовуються при визначенні, яку команду використовувати: - Якщо `platformCommand` присутній, він буде перевірений першим. - Якщо `os` та `arch` відповідають поточній платформі, пошук зупиниться, і команда буде використана. - Якщо `os` відповідає і немає більш специфічного `arch` відповідності, команда буде використана. - Якщо жодної відповідності `platformCommand` не знайдено, буде використана стандартна команда `command`. - Якщо жодної відповідності не знайдено в `platformCommand` і `command` не присутній, Helm завершить виконання з помилкою. Змінні середовища підставляються перед виконанням втулка. Шаблон вище ілюструє рекомендований спосіб вказівки, де знаходиться програма втулка. Є кілька стратегій для роботи з командами втулків: - Якщо втулок включає виконуваний файл, виконуваний файл для `platformCommand:` або `command:` має бути упакований у теку втулка. - Рядок `platformCommand:` або `command:` буде мати розширені змінні середовища перед виконанням. `$HELM_PLUGIN_DIR` вказуватиме на теку втулка. - Команда сама по собі не виконується в оболонці. Тому ви не можете використовувати однорядковий скрипт оболонки. - Helm вбудовує багато конфігурацій у змінні середовища. Ознайомтеся з середовищем, щоб дізнатися, яка інформація доступна. - Helm не робить припущень щодо мови втулка. Ви можете написати його будь-якою мовою, яка вам подобається. - Команди відповідають за реалізацію специфічного тексту допомоги для `-h` та `--help`. Helm використовуватиме `usage` та `description` для `helm help` та `helm help myplugin`, але не обробляє `helm myplugin --help`. ## Завантажувач втулків {#downloader-plugins} Стандартно Helm здатен завантажувати чарти за допомогою HTTP/S. Починаючи з версії Helm 2.4.0, втулки можуть мати спеціальну можливість завантажувати чарти з довільних джерел. Втулки повинні оголосити цю спеціальну можливість у файлі `plugin.yaml` (на верхньому рівні): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` Якщо такий втулок встановлений, Helm може взаємодіяти з репозиторієм, використовуючи вказану схему протоколу, викликавши `command`. Спеціальний репозиторій слід додати так само як і звичайні: `helm repo add favorite myprotocol://example.com/`. Правила для спеціальних репозиторіїв такі ж, як і для звичайних: Helm повинен бути здатен завантажити файл `index.yaml`, щоб виявити та зберегти список доступних чартів. Визначена команда буде викликана за схемою: `command certFile keyFile caFile full-URL`. Облікові відомості SSL беруться з визначення репозиторію, що зберігається в `$HELM_REPOSITORY_CONFIG` (тобто `$HELM_CONFIG_HOME/repositories.yaml`). Очікується, що команда завантажувача виведе сирий контент на stdout і повідомить про помилки на stderr. Команда завантажувача також підтримує підкоманди або аргументи, що дозволяє, наприклад, вказати `bin/mydownloader subcommand -d` у `plugin.yaml`. Це корисно, якщо ви хочете використовувати один і той же виконуваний файл для основної команди втулка та команди завантажувача, але з різною підкомандою для кожної. ## Змінні середовища {#environment-variables} Коли Helm виконує втулок, він передає зовнішнє середовище втулку та також вбудовує деякі додаткові змінні середовища. Змінні, такі як `KUBECONFIG`, встановлюються для втулка, якщо вони встановлені у зовнішньому середовищі. Гарантовано будуть встановлені такі змінні: - `HELM_PLUGINS`: Шлях до теки втулків. - `HELM_PLUGIN_NAME`: Імʼя втулка, яке використовується при виклику через `helm`. Тобто `helm myplug` матиме коротке імʼя `myplug`. - `HELM_PLUGIN_DIR`: Тека, що містить втулок. - `HELM_BIN`: Шлях до команди `helm` (як виконана користувачем). - `HELM_DEBUG`: Вказує, чи був встановлений прапорець налагодження. - `HELM_REGISTRY_CONFIG`: Місце для конфігурації реєстру (якщо використовується). Зазначте, що використання Helm з реєстрами є експериментальною функцією. - `HELM_REPOSITORY_CACHE`: Шлях до кеш-файлів репозиторіїв. - `HELM_REPOSITORY_CONFIG`: Шлях до файлу конфігурації репозиторію. - `HELM_NAMESPACE`: Простір імен, вказаний команді `helm` (зазвичай за допомогою прапорця `-n`). - `HELM_KUBECONTEXT`: Назва контексту конфігурації Kubernetes, наданого команді `helm`. Крім того, якщо конфігураційний файл Kubernetes був явно вказаний, він буде встановлений як змінна `KUBECONFIG`. ## Примітка про парсинг прапорців {#note-on-flag-parsing} При виконанні втулка Helm буде розбирати глобальні прапорці для власного використання. Жоден з цих пропорців не передається втулку. - `--burst-limit`: Це перетворюється в `$HELM_BURST_LIMIT`. - `--debug`: Якщо цей прапорець вказаний, `$HELM_DEBUG` встановлюється в `1`. - `--kube-apiserver`: Це перетворюється в `$HELM_KUBEAPISERVER`. - `--kube-as-group`: Ці перетворюються в `$HELM_KUBEASGROUPS`. - `--kube-as-user`: Це перетворюється в `$HELM_KUBEASUSER`. - `--kube-ca-file`: Це перетворюється в `$HELM_KUBECAFILE`. - `--kube-context`: Це перетворюється в `$HELM_KUBECONTEXT`. - `--kube-insecure-skip-tls-verify`: Це перетворюється в `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY`. - `--kube-tls-server-name`: Це перетворюється в `$HELM_KUBETLS_SERVER_NAME`. - `--kube-token`: Це перетворюється в `$HELM_KUBETOKEN`. - `--kubeconfig`: Це перетворюється в `$KUBECONFIG`. - `--namespace` and `-n`: Це перетворюється в `$HELM_NAMESPACE`. - `--qps`: Це перетворюється в `$HELM_QPS`. - `--registry-config`: Це перетворюється в `$HELM_REGISTRY_CONFIG`. - `--repository-cache`: Це перетворюється в `$HELM_REPOSITORY_CACHE`. - `--repository-config`: Це перетворюється в `$HELM_REPOSITORY_CONFIG`. Втулки _повинні_ відображати текст довідки та виходити для `-h` та `--help`. У всіх інших випадках втулки можуть використовувати прапорці за потреби. ## Надання автозавершення оболонки {#providing-shell-auto-completion} Починаючи з Helm 3.2, втулок може додатково підтримувати автозавершення оболонки як частину наявного механізму автозавершення Helm. ### Статичне автозавершення {#static-auto-completion} Якщо втулок надає свої власні прапорці та/або підкоманди, він може сповістити Helm про них, маючи файл `completion.yaml`, розташований у кореневій теці втулка. Файл `completion.yaml` має форму: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Примітки: 1. Усі секції є необовʼязковими, але їх слід надати, якщо треба. 1. Прапорці не повинні включати префікс `-` або `--`. 1. Як короткі, так і довгі прапорці можуть і повинні бути вказані. Короткий прапорець не потребує асоціації з відповідною довгою формою, але обидві форми слід перерахувати. 1. Прапорці не потрібно упорядковувати будь-яким чином, але їх слід перераховувати в правильному місці в ієрархії підкоманд файлу. 1. Глобальні прапорці Helm вже обробляються механізмом автозавершення Helm, тому втулкам не потрібно вказувати наступні прапорці `--debug`, `--namespace` або `-n`, `--kube-context`, і `--kubeconfig`, або будь-які інші глобальні прапорці. 1. Список `validArgs` надає статичний список можливих завершень для першого параметра після підкоманди. Можливо не завжди надати такий список заздалегідь (див. розділ [Динамічне завершення](#dynamic-completion) нижче), у цьому випадку розділ `validArgs` можна пропустити. Файл `completion.yaml` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати автозавершення оболонки для втулка (якщо не підтримується [Динамічне завершення](#dynamic-completion) втулком). Крім того, додавання файлу `completion.yaml` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. Як приклад, для втулка [`fullstatus`](https://github.com/marckhouzam/helm-fullstatus), який не має підкоманд, але приймає ті ж прапорці, що й команда `helm status`, файл `completion.yaml` виглядає так: ```yaml name: fullstatus flags: - o - output - revision ``` Складніший приклад для втулка [`2to3`](https://github.com/helm/helm-2to3), має файл `completion.yaml` наступного вигляду: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Динамічне автозавершення {#dynamic-completion} Починаючи з Helm 3.2, втулки можуть надавати динамічне автозавершення оболонки. Динамічне автозавершення забезпечує завершення значень параметрів або прапорців, які не можуть бути визначені заздалегідь. Наприклад, завершення імен Helm релізів, які наразі доступні в кластері. Щоб втулок підтримував динамічне автозавершення, він повинен надати **виконуваний** файл з назвою `plugin.complete` у своїй кореневій теці. Коли скрипт автозавершення Helm потребує динамічного завершення для втулка, він виконає файл `plugin.complete`, передаючи йому командний рядок, який потрібно завершити. Виконуваний файл `plugin.complete` повинен містити логіку для визначення правильних варіантів завершення та виводити їх на стандартний вихід, щоб їх можна було спожити скриптом автозавершення Helm. Файл `plugin.complete` є повністю необовʼязковим. Якщо він не надається, Helm просто не буде надавати динамічне автозавершення для втулка. Крім того, додавання файлу `plugin.complete` є сумісним з попередніми версіями та не вплине на поведінку втулка при використанні старіших версій Helm. Вихідний результат скрипту `plugin.complete` повинен бути списком, розділеним новими рядками, наприклад: ```none rel1 rel2 rel3 ``` Коли `plugin.complete` викликаний, середовище втулка встановлено так само, як і при виклику основного скрипту втулка. Отже, змінні `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT` та всі інші змінні втулка вже будуть встановлені, а відповідні глобальні прапорці будуть видалені. Файл `plugin.complete` може бути будь-якої виконуваної форми; це може бути shell-скрипт, програма на Go або будь-яка інша програма, яку Helm може виконати. Файл `plugin.complete` _**повинен**_ мати права на виконання для користувача. Файл `plugin.complete` _**повинен**_ завершитися з кодом успіху (значення 0). У деяких випадках динамічне завершення вимагатиме отримання інформації з кластера Kubernetes. Наприклад, втулок `helm fullstatus` потребує імені релізу як вводу. У втулку `fullstatus`, щоб скрипт `plugin.complete` надав завершення для поточних імен релізів, він може просто виконати `helm list -q` і вивести результат. Якщо ви бажаєте використовувати один і той же виконуваний файл для виконання втулка та для завершення втулка, скрипт `plugin.complete` може викликати основний виконуваний файл втулка з певним спеціальним параметром або прапорцем; коли основний виконуваний файл втулка виявляє спеціальний параметр або прапорець, він буде знати, що потрібно виконати завершення. У нашому прикладі `plugin.complete` може бути реалізований так: ```sh #!/usr/bin/env sh # "$@" є всім командним рядком, який потребує завершення. # Важливо використовувати подвійні лапки в змінній "$@", щоб зберегти можливий пустий останній параметр. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` Справжній скрипт втулка `fullstatus` (`status.sh`) повинен тоді шукати прапорець `--complete` і, якщо знайде його, вивести правильні завершення. ### Поради та підказки {#tips-and-tricks} 1. Оболонка автоматично відфільтровує варіанти завершення, які не відповідають введенню користувача. Отже, втулок може повернути всі відповідні завершення без видалення тих, які не відповідають введенню користувача. Наприклад, якщо командний рядок `helm fullstatus ngin`, скрипт `plugin.complete` може вивести _всі_ імена релізів (з простору імен `default`), а не лише ті, що починаються з `ngin`; оболонка зберігає лише ті, що починаються з `ngin`. 2. Щоб спростити підтримку динамічного завершення, особливо якщо у вас складний втулок, ви можете налаштувати скрипт `plugin.complete`, щоб він викликав основний скрипт втулка і запитував варіанти завершення. Дивіться розділ [Динамічне завершення](#dynamic-completion) вище для прикладу. 3. Для налагодження динамічного завершення та файлу `plugin.complete` можна виконати наступне, щоб побачити результати завершення: - `helm __complete `. Наприклад: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Підтвердження походження та цілісності в Helm description: Описує, як перевірити цілісність та походження чарту. sidebar_position: 5 --- Helm має інструменти підтвердження походження, які допомагають користувачам чартів перевіряти цілісність та походження пакета. Використовуючи інструменти на основі PKI, GnuPG та відомих менеджерів пакетів, Helm може створювати та перевіряти підписані файли. ## Огляд {#overview} Цілісність встановлюється шляхом порівняння чарту з записом про походження. Записи про походження зберігаються у _файлах походження_, які зберігаються поряд з упакованим чартом. Наприклад, якщо чарти називаються `myapp-1.2.3.tgz`, то файл походження буде `myapp-1.2.3.tgz.prov`. Файли походження генеруються під час пакування (`helm package --sign ...`) і можуть бути перевірені кількома командами, зокрема `helm install --verify`. ## Робочий процес {#the-workflow} Цей розділ описує можливий робочий процес ефективного використання даних походження. Передумови: - Дійсна пара ключів PGP у бінарному (не ASCII-зашифрованому) форматі - Інструмент командного рядка `helm` - Інструменти командного рядка GnuPG (необов’язково) - Інструменти командного рядка Keybase (необов’язково) **ПРИМІТКА:** Якщо ваш приватний ключ PGP має парольну фразу, вам буде запропоновано ввести її для будь-яких команд, які підтримують опцію `--sign`. Створення нового чарту виконується так само як і раніше: ```console $ helm create mychart Creating mychart ``` Коли ви готові до пакування, додайте прапорець `--sign` до команди `helm package`. Також вкажіть ім’я, під яким відомий ключ підпису, і вʼязку ключів, що містить відповідний приватний ключ: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Примітка:** Значення аргументу `--key` повинно бути субрядком бажаного `uid` ключа (виведеного командою `gpg --list-keys`), наприклад імʼя або електронна пошта. **Відбиток _не може_ бути використаний.** **ПОРАДА:** Для користувачів GnuPG ваша секретна вʼязка ключів знаходиться в `~/.gnupg/secring.gpg`. Ви можете використовувати команду `gpg --list-secret-keys`, щоб переглянути наявні ключі. **Попередження:** у GnuPG версії 2 ваша секретна вʼязка ключів зберігається у новому форматі `kbx` стандартно у `~/.gnupg/pubring.kbx`. Будь ласка, використовуйте такі команди, щоб перетворити свою вʼязку ключів у старий формат gpg: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` На цьому етапі ви повинні побачити як `mychart-0.1.0.tgz`, так і `mychart-0.1.0.tgz.prov`. Обидва файли зрештою мають бути завантажені у ваш бажаний репозиторій чартів. Ви можете перевірити чарт за допомогою команди `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` Приклад невдалої перевірки: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 сума не співпадає для topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` Щоб перевірити під час встановлення, використовуйте прапорець `--verify`. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` Якщо вʼязка ключів, що містить публічний ключ, асоційований із підписаним чартом, не знаходиться в стандартному місці, можливо, вам доведеться вказати шлях до вʼязки ключів за допомогою `--keyring PATH`, як у прикладі з `helm package`. Якщо перевірка не вдалася, встановлення буде перервано ще до того, як чарт буде навіть оброблено. ### Використання облікових даних Keybase.io {#using-keybase-io-credentials} Сервіс [Keybase.io](https://keybase.io) спрощує створення ланцюга довіри для криптографічної ідентичності. Облікові дані Keybase можуть бути використані для підписання чартів. Передумови: - Налаштований обліковий запис Keybase.io - Встановлений локально GnuPG - Встановлений локально CLI для Keybase #### Підписання пакетів {#signing-packages} Першим кроком є імпорт ваших ключів Keybase у вашу локальну вʼязку ключів GnuPG: ```console $ keybase pgp export -s | gpg --import ``` Це перетворить ваш ключ Keybase у формат OpenPGP і потім імпортує його локально у файл `~/.gnupg/secring.gpg`. Ви можете перевірити це, виконавши команду `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uidtechnosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Зверніть увагу, що ваш секретний ключ матиме рядок ідентифікатора: ```none technosophos (keybase.io/technosophos) ``` Це повне імʼя вашого ключа. Далі, ви можете упакувати та підписати чарт за допомогою `helm package`. Переконайтеся, що ви використовуєте хоча б частину цього рядка назви у `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` Як результат, команда `package` має створити як файл `.tgz`, так і файл `.tgz.prov`. #### Перевірка пакетів {#verifying-packages} Ви також можете використовувати аналогічний метод для перевірки чарту, підписаного ключем Keybase іншого користувача. Наприклад, ви хочете перевірити пакет, підписаний `keybase.io/technosophos`. Для цього скористайтесь інструментом `keybase`: ```console $ keybase follow technosophos $ keybase pgp pull ``` Перша команда відстежує користувача `technosophos`. Далі, команда `keybase pgp pull` завантажує ключі OpenPGP всіх облікових записів, які ви відстежуєте, розміщуючи їх у вашій вʼязці ключів GnuPG (`~/.gnupg/pubring.gpg`). На цьому етапі ви можете використовувати `helm verify` або будь-які команди з прапорцем `--verify`: ```console $ helm verify somechart-1.2.3.tgz ``` ### Причини, через які чарт може не пройти перевірку {#reasons-a-chart-may-not-verify} Це поширені причини невдач. - Файл `.prov` відсутній або пошкоджений. Це вказує на те, що щось неправильно налаштовано або що початковий підтримувач не створив файл походження. - Ключ, використаний для підписання файлу, не знаходиться у вашій вʼязці ключів. Це означає, що особа, яка підписала чарт, не є тією, кому ви вже довіряєте. - Перевірка файлу `.prov` не пройшла. Це вказує на те, що щось не так із чартом або даними походження. - Хеші файлів у файлі походження не збігаються з хешем архівного файлу. Це свідчить про те, що архів було підроблено. Якщо перевірка не пройшла, це є підставою для недовіри до пакета. ## Файл походження {#the-provenance-file} Файл походження містить YAML файл чарту та кілька елементів верифікаційної інформації. Файли походження розроблені для автоматичної генерації. Додаються наступні частини даних походження: - Файл чарту (`Chart.yaml`) включається для зручного перегляду вмісту чарту як людьми, так і інструментами. - Підпис (SHA256, аналогічно до Docker) пакету чарту (файл `.tgz`) включається та може бути використаний для перевірки цілісності пакета чарту. - Весь зміст підписується за допомогою алгоритму OpenPGP (див. [Keybase.io](https://keybase.io) для спрощення процесу криптографічного підпису та перевірки). Це надає користувачам такі гарантії: - Пакет не було підроблено (перевірка контрольної суми пакета `.tgz`). - Особа, яка випустила цей пакет, є відомою (через підпис GnuPG/PGP). Формат файлу виглядає приблизно так: ```none Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Зверніть увагу, що розділ YAML містить два документи (розділені `...\n`). Перший файл — це вміст `Chart.yaml`. Другий — це контрольні суми, map імен файлів та SHA-256 дайджестів вмісту цього файлу на момент пакування. Блок підпису є стандартним підписом PGP, який забезпечує [стійкість до підробок](https://www.rossde.com/PGP/pgp_signatures.html). ## Репозиторії чартів {#chart-repositories} Репозиторії чартів слугують як централізоване зібрання чартів Helm. Репозиторії чартів повинні забезпечувати можливість надання файлів походження через HTTP за певним запитом і повинні робити їх доступними за тим же шляхом URI, що й чарт. Наприклад, якщо базовий URL для пакета — `https://example.com/charts/mychart-1.2.3.tgz`, файл походження, якщо він існує, ПОВИНЕН бути доступний за адресою `https://example.com/charts/mychart-1.2.3.tgz.prov`. З погляду кінцевого користувача, команда `helm install --verify myrepo/mychart-1.2.3` повинна призвести до завантаження як чарту, так і файлу походження без додаткових налаштувань або дій користувача. ### Підписи в OCI-реєстрах {#signatures-in-oci-based-registries} При публікації чартів до [реєстру на основі OCI](/topics/registries.md), втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore/) може бути використаний для публікації файлів походження у [sigstore](https://sigstore.dev/). Як описано у [документації](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), процес створення файлів походження та підписання за допомогою ключа GPG є загальним, але команда `helm sigstore upload` може бути використана для публікації файлів походження до незмінного прозорого логу. ## Встановлення авторитету та автентичності {#establishing-authority-and-authenticity} У системах ланцюга довіри важливо мати можливість встановити авторитет підписувача. Іншими словами, система залежить від того, що ви довіряєте особі, яка підписала чарт. Це означає, що вам потрібно довіряти публічному ключу підписувача. Одне з проєктних рішень щодо Helm полягало в тому, що проєкт Helm не буде вставляти себе в ланцюжок довіри як обовʼязкову сторону. Ми не хочемо бути "центром сертифікації" для всіх підписувачів чартів. Замість цього ми дуже підтримуємо децентралізовану модель, що є частиною причини, чому ми вибрали OpenPGP як нашу основну технологію. Тому, коли йдеться про встановлення авторитету, ми залишили цей крок більш-менш невизначеним у Helm 2 (рішення було перенесене у Helm 3). Проте, у нас є кілька порад і рекомендацій для тих, хто зацікавлений у використанні системи походження: - Платформа [Keybase](https://keybase.io) надає публічне централізоване сховище для інформації про довіру. - Ви можете використовувати Keybase для зберігання своїх ключів або отримання публічних ключів інших. - Keybase також має чудову документацію. - Хоча ми не тестували це, функція "захищений вебсайт" Keybase може бути використана для сервісу чартів Helm. - Основна ідея полягає в тому, що офіційний "рецензент чартів" підписує чарти своїм ключем, а отриманий файл походження потім завантажується в репозиторій чартів. - Було зроблено деякі роботи над ідеєю, що список дійсних підписуючих ключів може бути включений у файл `index.yaml` репозиторію. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: Контроль доступу на основі ролей description: Пояснює, як Helm взаємодіє з контролем доступу на основі ролей Kubernetes. sidebar_position: 11 --- У Kubernetes надання ролей користувачу або службовому обліковому запису, специфічному для застосунку, є найкращою практикою для забезпечення роботи вашого застосунку в межах, які ви визначили. Дізнайтеся більше про дозволи службових облікових записів [в офіційній документації Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). З версії Kubernetes 1.6 контроль доступу на основі ролей (RBAC) стандартно увімкнено. RBAC дозволяє вам визначати, які типи дій дозволені залежно від користувача та його ролі у вашій організації. З RBAC ви можете: - надавати привілейовані операції (створення ресурсів на рівні кластеру, таких як нові ролі) адміністраторам - обмежити можливість користувача створювати ресурси (pods, persistent volumes, deployments) до певних просторів імен або в межах кластера (квоти ресурсів, ролі, визначення власних ресурсів) - обмежити можливість користувача переглядати ресурси або в певних просторах імен, або в межах кластера. Цей посібник призначений для адміністраторів, які хочуть обмежити область доступу користувача до API Kubernetes. ## Управління обліковими записами користувачів {#managing-user-accounts} Усі кластери Kubernetes мають дві категорії користувачів: службові облікові записи, керовані Kubernetes, та звичайні користувачі. Передбачається що звичайними користувачами керує зовнішній незалежний сервіс. Це може бути адміністратор, який розподіляє приватні ключі, сховище користувачів, таке як Keystone або Google Accounts, або навіть файл зі списком імен користувачів та паролів. У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайних користувачів не можна додати до кластера через API-запит. На відміну від цього, службові облікові записи є користувачами, керованими API Kubernetes. Вони привʼязані до певних просторів імен і створюються автоматично API сервером або вручну через API-запити. службові Облікові записи привʼязані до набору облікових даних, які зберігаються як Secrets і монтуються в podʼи, що дозволяє процесам всередині кластера спілкуватися з API Kubernetes. API-запити привʼязані або до звичайного користувача, або до облікового запису служби, або розглядаються як анонімні запити. Це означає, що кожен процес всередині або зовні кластера, від людини, що набирає `kubectl` на робочій станції, до kubelets на вузлах, до членів панелі управління, повинен пройти автентифікацію при здійсненні запитів до API сервера або бути розглянутим як анонімний користувач. ## Roles, ClusterRoles, RoleBindings та ClusterRoleBindings {#roles-clusterroles-rolebindings-and-clusterrolebindings} У Kubernetes облікові записи користувачів і службові облікові записи можуть переглядати та редагувати лише ресурси, до яких їм надано доступ. Цей доступ надається за допомогою Roles і RoleBindings. Ролі та RoleBindings привʼязані до певного простору імен, надаючи користувачам можливість переглядати та/або редагувати ресурси в цьому просторі імен, до яких надає доступ Role. На рівні кластера ці обʼєкти називаються ClusterRoles і ClusterRoleBindings. Надаючи користувачу ClusterRole, ви надаєте їм доступ до перегляду та/або редагування ресурсів по всьому кластеру. Це також необхідно для перегляду та/або редагування ресурсів на рівні кластера (простори імен, квоти ресурсів, вузли). ClusterRoles можна привʼязати до певного простору імен через посилання в RoleBinding. `admin`, `edit` та `view` стандартні ClusterRoles часто використовуються таким чином. Ось кілька ClusterRoles, стандартно доступних у Kubernetes. Вони призначені для користувачів. До них відносяться суперкористувацькі ролі (`cluster-admin`) та ролі з більш детальним доступом (`admin`, `edit`, `view`). | Стандартна ClusterRole | Стандартна ClusterRoleBinding | Опис |-------------------------|--------------------------------|------------- | `cluster-admin` | Група `system:masters` | Дозволяє суперкористувацький доступ для виконання будь-якої дії над будь-яким ресурсом. При використанні в ClusterRoleBinding надає повний контроль над кожним ресурсом в кластері та у всіх просторах імен. При використанні в RoleBinding надає повний контроль над кожним ресурсом в просторі імен, що привʼязується до RoleBinding, включаючи сам простір імен. | `admin` | Немає | Дозволяє адміністративний доступ, призначений для надання всередині простору імен за допомогою RoleBinding. Якщо використовується в RoleBinding, дозволяє читання/запис доступу до більшості ресурсів у просторі імен, включаючи можливість створювати ролі та RoleBindings всередині простору імен. Не дозволяє записувати доступ до квоти ресурсів або до самого простору імен. | `edit` | Немає | Дозволяє читання/запис доступу до більшості обʼєктів у просторі імен. Не дозволяє переглядати або модифікувати ролі або RoleBindings. | `view` | Немає | Дозволяє доступ лише для читання, щоб побачити більшість обʼєктів у просторі імен. Не дозволяє переглядати ролі або RoleBindings. Не дозволяє переглядати secrets, оскільки це є ескалацією доступу. ## Обмеження доступу облікових записів користувачів за допомогою RBAC {#restricting-a-users-accont-s-access-using-rbac} Тепер, коли ми розуміємо основи контролю доступу на основі ролей, розглянемо, як адміністратор може обмежити область доступу користувача. ### Приклад: Надання користувачу доступу для читання/запису в певного простору імен {#example-grnt-a-user-read-write-access-to-a-particular-namespace} Щоб обмежити доступ користувача до певного простору імен, можна використовувати роль `edit` або `admin`. Якщо ваші чарти створюють або взаємодіють з Roles і RoleBindings, ви захочете використовувати `admin` ClusterRole. Крім того, ви також можете створити RoleBinding з доступом `cluster-admin`. Надаючи користувачу доступ `cluster-admin` на рівні простору імен, ви надаєте повний контроль над кожним ресурсом у просторі імен, включаючи сам простір імен. Для цього прикладу ми створимо користувача з роллю `edit`. Спочатку створіть простір імен: ```shell $ kubectl create namespace foo ``` Тепер створіть RoleBinding у цьому просторі імен, надаючи користувачу роль `edit`. ```shell $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Приклад: Надання користувачу доступу для читання/запису на рівні кластера {#example-grant-a-user-read-write-access-at-the-cluster-scope} Якщо користувач хоче встановити чарт, який встановлює ресурси на рівні кластера (простори імен, ролі, визначення власних ресурсів тощо), їм знадобиться доступ для запису на рівні кластера. Для цього надайте користувачу доступ `admin` або `cluster-admin`. Надання користувачу доступу `cluster-admin` надає їм доступ до всіх ресурсів Kubernetes, включаючи доступ до вузлів з `kubectl drain` та інші адміністративні завдання. Рекомендується розглянути можливість надання користувачу доступу `admin`, або створити власну ClusterRole, адаптовану до їхніх потреб. ```shell $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Приклад: Надання користувачу доступу лише для читання до певного простору імен {#example-grant-a-user-read-only-access-to-a-particular-namespace} Ви могли помітити, що не існує ClusterRole, доступної для перегляду secrets. Роль `view` не надає користувачу доступ до Secrets через проблеми з ескалацією. Helm стандартно зберігає метадані релізів як Secrets. Щоб користувач міг виконати команду `helm list`, їм потрібно мати можливість читати ці секрети. Для цього ми створимо спеціальний `secret-reader` ClusterRole. Створіть файл `cluster-role-secret-reader.yaml` і напишіть наступний вміст у файл: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Потім створіть ClusterRole за допомогою: ```shell $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Як тільки це буде зроблено, ми можемо надати користувачу доступ для читання до більшості ресурсів, а потім надати їм доступ до секретів: ```shell $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Приклад: Надання користувачу доступу лише для читання на рівні кластера {#example-grant-a-user-read-only-access-at-the-cluster-scope} В деяких випадках може бути корисно надати користувачу доступ на рівні кластера. Наприклад, якщо користувач хоче виконати команду `helm list --all-namespaces`, API вимагає, щоб користувач мав доступ для читання на рівні кластера. Для цього надайте користувачу як `view`, так і `secret-reader` доступ, як описано вище, але за допомогою ClusterRoleBinding. ```shell $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Додатково {#additional-thoughts} Вищезазначені приклади використовують стандартні ClusterRoles, надані Kubernetes. Для більш детального контролю над ресурсами, до яких користувачі мають доступ, ознайомтеся з [документацією Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) по створенню власних Roles і ClusterRoles. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: Використання реєстрів на основі OCI description: Описує, як використовувати OCI для розповсюдження чартів. sidebar_position: 7 --- Починаючи з Helm 3, ви можете використовувати реєстри контейнерів з підтримкою [OCI](https://www.opencontainers.org/) для зберігання та обміну пакетами чартів. Починаючи з Helm v3.8.0, підтримка OCI є стандартно увімкнено. ## Підтримка OCI до v3.8.0 {#oci-support-prior-to-v3.8.0} Підтримка OCI перейшла з експериментального статусу в загальну доступність з Helm v3.8.0. У попередніх версіях Helm підтримка OCI працювала інакше. Якщо ви використовували підтримку OCI до Helm v3.8.0, важливо зрозуміти, що змінилося в Helm. ### Увімкнення підтримки OCI до v3.8.0 {#enabling-oci-support-prior-to-v3.8.0} До Helm v3.8.0 підтримка OCI є *експериментальною* і має бути увімкнена вручну. Щоб увімкнути експериментальну підтримку OCI для версій Helm до v3.8.0, задайте `HELM_EXPERIMENTAL_OCI` у вашому середовищі. Наприклад: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### Визнання застарілою функції OCI та зміни поведінки з v3.8.0 {#oci-deprecation-and-behavior-changes-with-v3.8.0} З виходом [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) наступні функції та поведінка відрізняються від попередніх версій Helm: - При встановленні chart у залежностях як OCI, версію можна задати у вигляді діапазону, як і для інших залежностей. - Теги SemVer, які містять інформацію про збірку, можна публікувати та використовувати. Реєстри OCI не підтримують `+` як символ теґу. Helm перетворює `+` на `_`, коли він зберігається як теґ. - Команда `helm registry login` тепер дотримується тієї ж структури, що й Docker CLI для зберігання облікових даних. Те ж місце для конфігурації реєстру може бути передане як Helm, так і Docker CLI. ### Визнання застарілою функції OCI та зміни поведінки з v3.7.0 Випуск [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) включав реалізацію [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) для підтримки OCI. Як результат, наступні функції та поведінка відрізняються від попередніх версій Helm: - Субкоманда `helm chart` була видалена. - Кеш chart був видалений (немає `helm chart list` тощо). - Посилання на реєстри OCI тепер завжди починаються з `oci://`. - Базове імʼя посилання на реєстр має *завжди* відповідати імені chart. - Тег посилання на реєстр має *завжди* відповідати семантичній версії chart (тобто без тегів `latest`). - Тип медіа шару chart був змінений з `application/tar+gzip` на `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Використання реєстру на основі OCI {#using-an-oci-based-registry} ### Репозиторії Helm у реєстрах на основі OCI {#helm-repositories-in-oci-based-registries} [Репозиторій Helm](/topics/chart_repository.md) — це спосіб зберігання та розподілу упакованих Helm chart. Реєстр на основі OCI може містити нуль або більше репозиторіїв Helm, і кожен з цих репозиторіїв може містити нуль або більше упакованих Helm chart. ### Використання послуг реєстрів {#use-hosted-registries} Існує кілька реєстрів контейнерів з підтримкою OCI, які ви можете використовувати для ваших Helm chart. Наприклад: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) Щоб створити та налаштувати реєстр з підтримкою OCI, дотримуйтесь документації постачальника реєстру контейнерів на хостингу. **Примітка:** Ви можете запускати [Docker Registry](https://docs.docker.com/registry/deploying/) або [`zot`](https://github.com/project-zot/zot), які є реєстрами на основі OCI, на вашому компʼютері для розробки. Запуск реєстру на основі OCI на вашому компʼютері, де відбувається розробка, слід використовувати лише для тестування. ### Використання sigstore для підписування чартів на основі OCI {#using-sigstore-to-sign-oci-charts} Втулок [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) дозволяє використовувати [Sigstore](https://sigstore.dev/) для підписування Helm чартів тими ж інструментами, які використовуються для підписування контейнерних образів. Це є альтернативою [перевірки походження](/topics/provenance.md), що використовує GPD, яке підтримується класичними [репозиторіями чартів](/topics/chart_repository.md). Для отримання додаткової інформації про використання втулка `helm sigstore`, дивіться [документацію цього проєкту](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Команди для роботи з реєстрами {#commands-for-working-with-registries} ### Команда `registry` {#the-registry-subcommand} #### `login` Вхід до реєстру (зручний варіант з ручним введенням пароля) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` Вийти з реєстру ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### Команда `push` {#the-push-subcommand} Завантажити чарт до реєстру на основі OCI: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` Команда `push` може використовуватися тільки для `.tgz` файлів, створених заздалегідь за допомогою `helm package`. При використанні `helm push` для завантаження чарту до реєстру OCI, посилання має починатися з `oci://` і не повинно містити базове імʼя або теґ. Базове імʼя посилання на реєстр визначається з імені чарту, а теґ визначається з семантичної версії чарту. Це наразі є строгими вимогами. Деякі реєстри вимагають, щоб репозиторій та/або простір імен (якщо вказано) були створені заздалегідь. В іншому випадку під час операції `helm push` буде згенеровано помилку. Якщо ви створили [файл походження](/topics/provenance.md) (`.prov`), і він присутній поруч з файлом чарту `.tgz`, він автоматично буде завантажено до реєстру при виконанні `push`. Це призводить до появи додаткового шару у [маніфесті Helm chart](#helm-chart-manifest). Користувачі втулка [helm-push](https://github.com/chartmuseum/helm-push) (для завантаження chart до [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) можуть стикатися з проблемами, оскільки втулок конфліктує з новою вбудованою командою `push`. З версії v0.10.0 втулок був перейменований на `cm-push`. ### Інші підкоманди {#other-subcommands} Підтримка протоколу `oci://` також доступна в різних інших підкомандах. Ось повний список: - `helm pull` - `helm show ` - `helm template` - `helm install` - `helm upgrade` Базове імʼя (імʼя chart) посилання на реєстр *включено* для будь-якого типу дії, що стосується завантаження chart (на відміну від `helm push`, де воно пропущене). Ось кілька прикладів використання наведених вище підкоманд для chart на основі OCI: ```shell $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Вказання залежностей {#specifying-dependencies} Залежності chart можна завантажити з реєстру за допомогою підкоманди `dependency update`. `repository` для певного запису в `Chart.yaml` вказується як посилання на реєстр без базового імені: ```yaml dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` Це завантажить `oci://localhost:5000/myrepo/mychart:2.7.0`, коли виконується `dependency update`. ## Маніфест Helm чарту {#helm-chart-manifest} Приклад маніфесту Helm чарту, представленого в реєстрі (зверніть увагу на поля `mediaType`): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` Наступний приклад містить [файл походження](/topics/provenance.md) (зверніть увагу на додатковий шар): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Міграція з репозиторіїв чартів Міграція з класичних [репозиторіїв чартів](/topics/chart_repository.md) (репозиторії на основі index.yaml) є простою: використовуйте `helm pull`, а потім `helm push`, щоб завантажити отримані файли `.tgz` до реєстру. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Міграція з Helm v2 на Helm v3 description: Дізнайтеся, як мігрувати з Helm v2 на v3. sidebar_position: 13 --- Цей посібник показує, як мігрувати з Helm v2 на Helm v3. Для цього необхідно мати встановлений Helm v2, який управляє релізами в одному або кількох кластерах. ## Огляд змін у Helm 3 {#overview-of-helm-3-changes} Повний список змін між Helm 2 і 3 задокументований у [розділі FAQ](/faq/changes_since_helm2.md). Ось деякі з основних змін, про які слід знати перед і під час міграції: 1. Видалення Tiller: - Заміна архітектури клієнт/сервер на клієнт/бібліотека (тільки бінарний файл `helm`) - Безпека тепер залежить від користувача (делеговано безпеці кластера Kubernetes) - Релізи тепер зберігаються як секрети в кластері, а метадані обʼєкта релізу змінилися - Релізи зберігаються на основі простору імен релізу, а не в просторі імен Tiller 2. Оновлено репозиторій чартів: - `helm search` тепер підтримує як локальні запити в репозиторії, так і запити до Artifact Hub 3. Зміни у `apiVersion` чарту: - Динамічно підключені залежності чартів переміщені до `Chart.yaml` (`requirements.yaml` видалено і requirements --> dependencies) - Тепер можна додавати бібліотечні чарти (helper/common charts) як динамічно підключені залежності - Чарти мають поле метаданих `type`, яке визначає, чи є чарт `application` чи `library`. Стандартно це `application`, що означає, що його можна рендерити та інсталювати - Чарти Helm 2 (apiVersion=v1) все ще можна встановлювати 4. Додано специфікацію теки XDG: - Домівка Helm видалена і замінена специфікацією теки XDG для зберігання конфігураційних файлів - Більше не потрібно ініціалізувати Helm - `helm init` і `helm home` видалені 5. Додаткові зміни: - Установка/налаштування Helm спрощено: - Тільки клієнт Helm (бінарний файл helm) (без Tiller) - Парадигма "run-as-is" - `local` або `stable` репозиторії стандартно не налаштовані - Хук `crd-install` видалено і замінено на теку `crds` у чарті, де всі CRD, визначені в ній, будуть встановлені перед будь-яким рендерингом чарту - Значення анотації хука `test-failure` видалене, а `test-success` застаріле. Використовуйте `test` замість - Команди видалені/замінені/додані: - delete --> uninstall : стандартно видаляє всю історію релізів за (раніше потрібно було `--purge`) - fetch --> pull - home (видалено) - init (видалено) - install: вимагає імʼя релізу або аргумент `--generate-name` - inspect --> show - reset (видалено) - serve (видалено) - template: аргумент `-x`/`--execute` перейменовано на `-s`/`--show-only` - upgrade: Додано аргумент `--history-max`, який обмежує максимальну кількість збережених ревізій на реліз (0 - без обмежень) - Бібліотека Helm 3 на Go зазнала значних змін і несумісна з бібліотекою Helm 2 - Бінарники Helm тепер розміщені на `get.helm.sh` ## Сценарії міграції {#migration-use-cases} Сценарії міграції такі: 1. Helm v2 і v3 управляють одним кластером: - Цей сценарій рекомендується тільки якщо ви плануєте поступове видалення Helm v2 і не потребуєте v3 для управління жодними релізами, розгорнутими v2. Усі нові релізи, що розгортаються, повинні виконуватися v3, а наявні релізи, розгорнуті v2, оновлюються/видаляються тільки v2 - Helm v2 і v3 можуть без проблем управляти одним кластером. Версії Helm можуть бути встановлені на одній або окремих системах - Якщо ви встановлюєте Helm v3 на тій же системі, вам потрібно виконати додатковий крок, щоб обидві версії клієнтів могли співіснувати до того часу, поки ви не будете готові видалити клієнта Helm v2. Перейменуйте або помістіть бінарний файл Helm v3 в іншу теку, щоб уникнути конфліктів - Інакше немає конфліктів між обома версіями через наступні відмінності: - зберігання релізів (історії) v2 і v3 є незалежним один від одного. Зміни включають ресурс Kubernetes для зберігання та метадані обʼєкта релізу, що містяться в ресурсі. Релізи також будуть в просторі імен користувача, а не в просторі імен Tiller (наприклад, простір імен Tiller стандартно kube-system v2). v2 використовує "ConfigMaps" або "Secrets" у просторі імен Tiller і `TILLER` ownership. v3 використовує "Secrets" у просторі імен користувача і `helm` ownership. Релізи є інкрементальними в обох версіях v2 і v3 - Єдина проблема може бути, якщо ресурси кластера Kubernetes (наприклад, `clusterroles.rbac`) визначені в чарті. Розгортання v3 тоді буде невдалим, навіть якщо унікальне в просторі імен, оскільки ресурси будуть конфліктувати - Конфігурація v3 більше не використовує `$HELM_HOME` і використовує специфікацію теки XDG замість цього. Вона також створюється на льоту за необхідності. Тому вона є незалежною від конфігурації v2. Це стосується тільки випадків, коли обидві версії встановлені на одній системі 2. Міграція з Helm v2 на Helm v3: - Цей сценарій застосовується, коли ви хочете, щоб Helm v3 управляв наявними релізами Helm v2 - Слід зазначити, що клієнт Helm v2: - може управляти одним або кількома кластерами Kubernetes - може підключатися до одного або кількох екземплярів Tiller для кластера - Це означає, що ви повинні бути обізнані про це під час міграції, оскільки релізи розгортаються в кластери Tiller і його простір імен. Тому ви повинні бути обізнані про міграцію для кожного кластера та кожного екземпляра Tiller, який управляється екземпляром клієнта Helm v2 - Рекомендований шлях міграції даних такий: 1. Резервне копіювання даних v2 2. Міграція конфігурації Helm v2 3. Міграція релізів Helm v2 4. Коли ви впевнені, що Helm v3 управляє всіма даними Helm v2 (для всіх кластерів і екземплярів Tiller клієнта Helm v2) як очікується, очистіть дані Helm v2 - Процес міграції автоматизований втулком Helm v3 [2to3](https://github.com/helm/helm-2to3) ## Посилання {#references} - Втулок Helm v3 [2to3](https://github.com/helm/helm-2to3) - [Блог пост](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) з поясненням використання втулка `2to3` з прикладами ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: Політика підтримки версій Helm description: Описує політику випуску патчів Helm, а також максимальну підтримувану різницю версій між Helm і Kubernetes. sidebar_position: 15 --- Цей документ описує максимальну підтримувану різницю версій між Helm і Kubernetes. ## Підтримувані версії {#supported-versions} Версії Helm виражаються у форматі `x.y.z`, де `x` — це основна версія, `y` — це мінорна версія, а `z` — це версія патчу, відповідно до [семантичного версіювання](https://semver.org/spec/v2.0.0.html). Проєкт Helm підтримує релізну гілку для останнього мінорного випуску. Застосовні виправлення, включаючи виправлення безпеки, додаються в релізну гілку залежно від їх серйозності та можливості впровадження. Більше деталей можна знайти в [політиці випусків Helm](/community/release_policy). ## Підтримувана різниця версій {#supported-version-skew} Коли випускається нова версія Helm, вона компілюється з певною мінорною версією Kubernetes. Наприклад, Helm 3.0.0 взаємодіє з Kubernetes, використовуючи клієнт Kubernetes версії 1.16.2, тому він сумісний з Kubernetes 1.16. Починаючи з Helm 3, вважається, що Helm сумісний з версіями Kubernetes до `n-3` відносно версії, з якою він був скомпільований. Через зміни в Kubernetes між мінорними версіями, політика підтримки Helm 2 є трохи більш суворою і передбачає сумісність з версіями Kubernetes до `n-1`. Наприклад, якщо ви використовуєте версію Helm 3, яка була скомпільована з клієнтськими API Kubernetes версії 1.17, тоді її можна безпечно використовувати з Kubernetes 1.17, 1.16, 1.15 і 1.14. Якщо ж ви використовуєте версію Helm 2, скомпільовану з клієнтськими API Kubernetes версії 1.16, то її можна безпечно використовувати з Kubernetes 1.16 і 1.15. Не рекомендується використовувати Helm з версією Kubernetes, яка є новішою за ту, з якою він був скомпільований, оскільки Helm не гарантує зворотної сумісності. Якщо ви вирішите використовувати Helm з версією Kubernetes, яку він не підтримує, ви робите це на свій ризик. Будь ласка, зверніться до таблиці нижче, щоб визначити, яка версія Helm сумісна з вашим кластером. | Версія Helm | Підтримувані версії Kubernetes | |--------------|-------------------------------| | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "Вступ", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "Як робити", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "Теми", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "Найкращі практики", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Посібник з шаблонів чартів", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Команди Helm", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "Спільнота", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "Часті питання", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/MAINTAINERS.md ================================================ --- title: Мейнтейнери Helm Org --- * [Karen Chu](https://github.com/karenhchu) * [Matt Butcher](https://github.com/technosophos) (голова) * [Matt Farina](https://github.com/mattfarina) * [Reinhard Nägele](https://github.com/unguiculus) * [Scott Rigby](https://github.com/scottrigby) ## Почесні {#emeritus} * [Adam Reese](https://github.com/adamreese) * [Adnan Abdulhussein](https://github.com/prydonius) * [Josh Dolitsky](https://github.com/jdolitsky) * [Martin Hickey](https://github.com/hickeyma) * [Matt Fisher](https://github.com/bacongobbler) * [Vic Iglesias](https://github.com/viglesiasce) ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/README.md ================================================ --- sidebar_position: 1 title: Спільнота Helm --- Ласкаво просимо до спільноти Helm! Це відправна точка для того, щоб стати учасником проєкту Helm — вдосконалювати документацію, покращувати код, виступати з доповідями тощо. ## Комунікація {#communicating} На сторінці [комунікація](communication.md) перелічено канали комунікації, такі як чат, тікети, списки розсилки, зустрічі, конференції тощо. ## Ресурси {#assets} - Логотипи Helm знаходяться за адресою [cncf/artwork](https://github.com/cncf/artwork/blob/master/examples/graduated.md#helm-logos) - Веб-сайт та документація Helm знаходяться за адресою [helm/helm-www](https://github.com/helm/helm-www) - Приклади та рекомендації щодо використання бренду Helm: [art](/community/art) - Шаблон презентації на тему Helm: [slides](https://github.com/helm/community/tree/main/slides) ## Як я можу допомогти? {#how-can-i-help} #### Спочатку вам слід приєднатися до наших комунікаційних форумів: {#first-you-should-join-our-communication-forums} - Слідкуйте за нами на [Twitter](communication.md#social-media) - Приєднуйтесь до нас в [Slack](communication.md#slack) - Підпишіться на наші [списки розсилки](communication.md#mailing-lists) - Приєднуйтесь до [щотижневих зустрічей](communication.md#meetings) #### Далі, налаштуйте основи (якщо ви цього ще не зробили): {#next-get-set-up-with-the-basics-if-not-already-done-so} - [Документація](/docs/) - [Тікети](https://github.com/helm/helm/issues) - [PR](https://github.com/helm/helm/pulls) - [Як розпочати](/docs/intro/quickstart/) - [Посібник для розробників](./developers.md) Тепер ви можете приступити до справи! Хороший спосіб навчитися: - Перегляньте код і ознайомтеся з рецензіями коду. Документація та тести є частиною кодової бази. - Спробуйте відтворити проблеми та отримайте загальне уявлення про проблеми користувачів. - Поспілкуйтеся з людьми в Slack і поставте питання. Області, з яких можна почати роботу: - Документація (така як текст, який ви зараз читаєте) завжди може бути покращена! - Ми завжди можемо розширити тестове покриття. - Перегляньте відкриті PR. Додайте коментарі, відгуки або дайте LGTM! - Спробуйте виправити деякі прості баги, які можуть бути позначені теґом [good first issue][] - Просто попросіть [власників][owner] про пропозиції. #### І наостанок, ми дуже хотіли б дізнатися, що ви хочете бачити на [блозі Helm](/blog/). {#last-but-not-least-wed-love-to-know-what-you-want-to-see-on-the-helm-blog} Не соромтеся надсилати теми для блогу [тут](blog-topics.md). ## Ваш перший внесок {#your-first-contribution} Ми рекомендуємо вам попрацювати над наявними [проблемами][issues], перш ніж намагатися розробити нову функцію. Знайдіть наявну проблему (наприклад, позначену як [good first issue], або просто попросіть [власників][owner] про пропозиції) і дайте відповідь у темі проблеми, висловивши зацікавленість у роботі над нею. Це допоможе іншим людям дізнатися, що проблема є актуальною, і, сподіваємося, запобіжить дублюванню зусиль. Кожен комміт повинен бути підписаний в git, як описано в [статті](/blog/helm-dco/), що описує перехід Helm на DCO. Якщо ви хочете працювати з новою ідеєю відносно невеликого обсягу: 1. Подайте запит із описом запропонованих змін до відповідного репозиторію. 2. Власники репозиторію оперативно відреагують на ваш запит. 3. Якщо запропоновані зміни будуть прийняті, почніть роботу у своєму форку, підписуючи кожен комміт, як описано вище. 4. Надішліть [pull request][], що містить перевірені зміни. [good first issue]: https://github.com/helm/helm/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3A%22good+first+issue%22 [issues]: https://github.com/helm/helm/issues [pull request]: https://github.com/helm/helm/blob/main/CONTRIBUTING.md#pull-requests [owner]: https://github.com/kubernetes/helm/blob/main/OWNERS ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/code-of-conduct.md ================================================ --- title: Кодекс поведінки спільноти --- Helm дотримується [Кодексу поведінки CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/communication.md ================================================ --- title: Комунікація --- Спільнота Helm дотримується [Кодексу поведінки CNCF][CNCF code of conduct]. Ось витяг з нього: > _Як учасники та мейнтейнери цього проєкту, а також з метою сприяння розвитку відкритої та дружньої спільноти, ми зобовʼязуємося поважати всіх людей, які роблять свій внесок, повідомляючи про проблеми, публікуючи запити на нові функції, оновлюючи документацію, надсилаючи запити на виправлення або патчі, а також здійснюючи інші дії._ ## Соціальні мережі {#social-media} * [Twitter] * Ставте питання та допомагайте відповідати на них у [Slack] або [Stack Overflow]. ## Slack Ви можете [запросити запрошення до Kubernetes Slack](https://slack.kubernetes.io/). Більшість дискусій у реальному часі відбувається в [#helm-users](https://kubernetes.slack.com/messages/C0NH30761) та [#charts](https://kubernetes.slack.com/messages/C6E3XH1ED). Також є канал [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) для обговорення розвитку Helm. ## Тікети {#issues} Тікети використовуються як основний метод відстеження всього, що стосується проєкту Helm. Дивіться [посібник для учасників](https://github.com/kubernetes/helm/blob/main/CONTRIBUTING.md#issues) для отримання інформації про те, як [створити тікет][file an issue], якщо ви вважаєте, що знайшли помилку або маєте пропозицію щодо нової функції. ## Списки розсилки {#mailing-lists} Оголошення про розробку та обговорення зʼявляються у списку розсилки Helm [cncf-helm] (надсилайте листи на адресу `cncf-helm@lists.cncf.io`). ## Зустрічі {#meetings} Спільнота Helm регулярно проводить публічні зустрічі, зокрема з питань підтримки розробки клієнтів Helm та чартів. Ви можете [переглянути календар зустрічей](https://calendar.google.com/calendar/embed?src=s5anaqbm9kda435dnh5r8lj1l8%40group. calendar.google.com&ctz=America%2FLos_Angeles) та [підписатися через ical](https://calendar.google.com/calendar/ical/s5anaqbm9kda435dnh5r8lj1l8%40group.calendar.google.com/public/basic.ics). Кожен четвер о 9:30 за тихоокеанським часом США ми проводимо [щотижневу нараду з питань розвитку], на яку запрошуються всі бажаючі. Переведіть це на ваш місцевий час за допомогою цієї [таблиці часових поясів][timezone table]. Ми ведемо нотатки з кожної зустрічі в цьому [документі](https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc/edit?usp=sharing), де містяться підсумки нарад, обговорень та заходів, що необхідно вжити. Відео доступні в [плейлисті зустрічей спільноти Helm][Helm Community Meetings playlist]. ## Конференції {#conferences} Helm є одним із проектів, представлених на CloudNativeCon/KubeCon, що проводиться тричі на рік в Європі, Азії та Північній Америці. Інформація про ці та інші події спільноти доступна на сторінках [подій][events] CNCF. Крім того, спільнота Helm організовує захід, присвячений Helm, — [Helm Summit], перший з яких відбувся в Портленді, штат Орегон, у лютому 2018 року, [другий](https://events19.linuxfoundation.org/events/helm-summit-2019/) — в Європі (Амстердам, Нідерланди) 11-12 вересня 2019 року. [CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md [cncf-helm]: https://lists.cncf.io/g/cncf-helm/topics [events]: https://www.cncf.io/events/ [file an issue]: https://github.com/helm/helm/issues/new [kubernetes-sig-apps]: https://groups.google.com/forum/#!forum/kubernetes-sig-apps [Slack]: https://kubernetes.slack.com [Helm Summit]: https://helmsummitpdx-feb2018.splashthat.com/ [Stack Overflow]: https://stackoverflow.com/questions/tagged/kubernetes-helm [timezone table]: https://www.google.com/search?q=0930+am+in+pst [Twitter]: https://twitter.com/helmpack [weekly development meeting]: https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09 [Helm Community Meetings playlist]: https://www.youtube.com/playlist?list=PLVt9l4b66d5EY5Xs9OVJgvO5ss9WzrSY0 [SIGs]: https://github.com/kubernetes/community/blob/master/sig-list.md [SIG-Apps]: https://github.com/kubernetes/community/tree/master/sig-apps ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/developers.md ================================================ --- title: Посібник для розробників description: Інструкції щодо налаштування середовища для розробки Helm. sidebar_position: 2 --- Цей посібник пояснює, як налаштувати ваше середовище для розробки на Helm. ## Попередні умови {#prerequisites} - Остання версія Go - Кластер Kubernetes з kubectl (необовʼязково) - Git ## Збирання Helm {#building-helm} Ми використовуємо Make для компіляції наших програм. Найпростіший спосіб почати: ```console $ make ``` Якщо потрібно, спочатку будуть встановлені залежності та перевірена конфігурація. Потім буде скомпільовано `helm` і розміщено у `bin/helm`. Щоб запустити Helm локально, ви можете запустити `bin/helm`. - Helm відомий тим, що працює на macOS та більшості дистрибутивів Linux, включаючи Alpine. ## Запуск тестів {#running-tests} Щоб запустити всі тести, виконайте `make test`. Перед цим вам потрібно мати встановлений [golangci-lint](https://golangci-lint.run). ## Запуск локально {#running-locally} Ви можете оновити ваш шлях і додати шлях до локального виконуваного файлу Helm. В редакторі відкрийте файл конфігурації вашої оболонки. Додайте наступний рядок, замінивши `` на шлях до вашої локальної теки `bin`. ``` bash export PATH=":$PATH" ``` Це дозволить вам запускати локально створену версію Helm з вашого термінала. ## Настанови щодо участі {#contribution-guidelines} Ми раді вашій участі. Цей проєкт має деякі настанови, щоб забезпечити (а) високу якість коду, (б) послідовність проєкту, і (в) відповідність юридичним вимогам проєктів з відкритими сирцями. Наша мета не обтяжувати учасників, а побудувати елегантний та якісний відкритий код, щоб наші користувачі отримали користь. Переконайтеся, що ви прочитали та зрозуміли основний посібник щодо участі: ### Структура коду {#structure-of-the-code} Код проєкту Helm організовано наступним чином: - Окремі програми знаходяться в `cmd/`. Код всередині `cmd/` не призначений для повторного використання у вигляді бібліотек. - Спільні бібліотеки зберігаються в `pkg/`. - Тека `scripts/` містить кілька скриптів утиліт. Більшість з них використовується конвеєром CI/CD. Управління залежностями Go змінюється, і, ймовірно, змінюватиметься протягом життєвого циклу Helm. Ми рекомендуємо розробникам _не_ намагатися вручну управляти залежностями. Натомість ми радимо покладатися на `Makefile` проєкту для цього. З Helm 3 рекомендується використовувати версію Go 1.13 або новішу. ### Написання документації {#writing-documentation} З Helm 3 документація була перенесена в окремий репозиторій. При створені нових функцій, будь ласка, зробіть супутню документацію та надішліть її до репозиторію [helm-www](https://github.com/helm/helm-www). Єдине виключення: [вивід CLI Helm (англійською)](/docs/helm) генерується безпосередньо з бінарного файлу `helm`. Дивіться [Оновлення довідкових документів CLI Helm](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) для інструкцій, як згенерувати цей вивід. Після перекладу, вивід CLI не генерується і може бути знайдений у `/content//docs/helm`. ### Домовленості Git {#git-conventions} Ми використовуємо Git як нашу систему контролю версій. Гілка `main` є домом для поточного кандидата в розробці. Релізи позначаються теґами. Ми приймаємо зміни до коду через Pull Requests (PRs) на GitHub. Робочий процес виглядає наступним чином: 1. Зробіть форк репозиторія `github.com/helm/helm` у ваш обліковий запис GitHub 2. Зробіть `git clone` цього форку у бажану локальну теку 3. Створіть нову робочу гілку (`git checkout -b feat/my-feature`) і працюйте з цією гілкою. 4. Коли ви будете готові до рецензування, залийте вашу гілку на GitHub, а потім відкрийте новий pull request в нашому репо. Для опису змін в комітах Git ми дотримуємося [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html): ```commit fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` Звичайні типи комітів: - fix: Fix a bug or error - feat: Add a new feature - docs: Change documentation - test: Improve testing - ref: refactor existing code Звичайні області: - helm: CLI Helm - pkg/lint: Пакет lint. Дотримуйтеся аналогічної конвенції для будь-якого пакету - `*`: дві або більше областей Дізнатись більше: - [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) були прикладом для цього розділу. - Karma Runner [визначає](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) ідею семантичного повідомлення коміту. ### Домовленості Go {#go-conventions} Ми дуже уважно дотримуємося стандартів стилю кодування Go. Зазвичай запуск `go fmt` зробить ваш код красивим для вас. Ми також зазвичай дотримуємося рекомендацій `go lint` та `gometalinter`. Запустіть `make test-style`, щоб переконатися у відповідності стилю. Дізнатись більше: - Effective Go [представляє форматування](https://golang.org/doc/effective_go.html#formatting). - Wiki Go має чудову статтю про [форматування](https://github.com/golang/go/wiki/CodeReviewComments). Якщо ви запускаєте `make test`, будуть виконані не тільки юніт-тести, а й тести стилю. Якщо `make test` не пройде, навіть з причин стилю, ваш PR не буде вважатися готовим до злиття. ## Усунення несправностей {#troubleshooting} Щоб усунути несправності та отримати допомогу від спільноти, знайдіть своє запитання у списку питань із позначкою [`question/support`](https://github.com/helm/helm/issues?q=is%3Aissue%20state%3Aopen%20label%3Aquestion%2Fsupport) у репозиторії Helm. Якщо ви не можете знайти тікет, який відповідає вашому запитанню, створіть новий тікет або додайте коментар до відповідного тікету, щоб поділитися своїм досвідом. Для отримання додаткової інформації про участь та пошук тікетів у репозиторії helm див. розділ [Issues](https://github.com/helm/helm/blob/main/CONTRIBUTING.md#issues) у _Настановах щодо участі_. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/history.mdx ================================================ --- title: Історія Проєкту description: Надає загальний огляд історії проєкту. sidebar_position: 5 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm є [проєктом](https://www.cncf.io/projects/) під [єгідою CNCF](/blog/celebrating-helms-cncf-graduation/). Helm почався як те, що тепер відоме як [Helm Classic](https://github.com/helm/helm-classic), проєкт Deis, розпочатий у 2015 році та представлений на перших KubeCon. У січні 2016 року проєкт обʼєднався з інструментом GCS під назвою Kubernetes Deployment Manager, і проєкт було переведено під [Kubernetes](https://kubernetes.io). В результаті злиття кодових баз, Helm 2.0 був випущений пізніше того ж року. Ключова особливість Deployment Manager, яка збереглася в Helm 2, — це серверна компонента, перейменована з DM на Tiller для фінального релізу Helm 2.0. Helm був піднятий з підпроєкту Kubernetes до повноцінного проєкту CNCF у червні 2018 року. Helm сформував орган управління на вищому рівні, і кілька проєктів були інтегровані під парасолею проєкту Helm, включаючи Monocular, Helm Chart Repo, Chart Museum і пізніше Helm Hub. Коли розпочався цикл розробки Helm 3, Tiller було видалено, що наблизило Helm до його первісного бачення як клієнтського інструменту. Але Helm 3 продовжує відслідковувати релізи всередині кластеру Kubernetes, що дозволяє командам працювати разом над спільним набором релізів Helm. Helm 3 був випущений у листопаді 2019 року. Helm [випустився як проєкт CNCF у квітні 2020 року](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/). [CNCF Artifact Hub](https://artifacthub.io) замінив [Helm Hub](https://hub.helm.sh) у жовтні 2020 року. ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/localization.md ================================================ --- title: Локалізація документації Helm description: Інструкції для локалізації документації Helm. sidebar_position: 6 --- Цей посібник пояснює, як локалізувати документацію Helm. ## Початок роботи {#getting-started} Внесення змін у переклади використовує той самий процес, що й внесення змін у документацію. Переклади подаються через [пул-реквести](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) до репозиторію [helm-www](https://github.com/helm/helm-www), і пул-реквести перевіряються командою, яка управляє вебсайтом. ### Дволітерний код мови {#two-letter-language-code} Документація організована відповідно до стандарту [ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php) для мовних кодів. Наприклад, дволітерний код для корейської мови — `ko`, української — `uk`. У контенті та конфігураціях ви знайдете використовувані мовні коди. Ось 3 приклади: - У теці `i18n` є підтеки для кожного коду мови. Локалізований вміст для мови знаходиться в кожній підтеці. - Локалізований вміст у кожній - Для кожної мови існує файл `code.json` з фразами, що використовуються на веб-сайті. Англійська мова з кодом мови `en` є основною мовою та джерелом для перекладів. ### Форк, Гілка, Зміна, Пул-Реквест {#fork-branch-change-pull-request} Щоб зробити переклад, почніть зі [створення форку](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) репозиторію [helm-www](https://github.com/helm/helm-www) на GitHub. Ви почнете з внесення змін у вашому форку. Стандартно ваш форк буде налаштовано на роботу з основною гілкою, відомою як `main`. Будь ласка, використовуйте гілки для розробки ваших змін та створення пул-реквестів. Якщо ви не знайомі з гілками, ви можете [прочитати про них у документації GitHub](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches). Коли у вас зʼявиться гілка, внесіть зміни для додавання перекладів та локалізації контенту потрібною мовою. Зверніть увагу, що Helm використовує [Developers Certificate of Origin](https://developercertificate.org/). Всі коміти повинні мати підпис. При виконанні коміту ви можете використовувати прапорець `-s` або `--signoff`, щоб використовувати ваше налаштоване імʼя та адресу електронної пошти для підпису коміту. Більше деталей можна знайти у файлі [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work). Коли ви будете готові, створіть [пул-реквест](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) з перекладом назад до репозиторію helm-www. Після створення пул-реквесту один з підтримувачів перевірить його. Деталі цього процесу можна знайти у файлі [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md). ## Переклад Контенту {#translating-content} Локалізація всього вмісту Helm — це велике завдання. Можна почати з малого. Згодом переклади можна розширювати. Нижче описано файли/теки, які використовуються для перекладу вмісту документів, вмісту блогу та елементів сайту в документації Helm: - `i18n/` тека: - `code.json` використовується для перекладу коду React на сайті (включно з лендінгом) - `i18n//docusaurus-plugin-content-blog` тека з перекладами блогу - `i18n//docusaurus-plugin-content-docs` тека з: - Теки версій для перекладів вмісту документації (наприклад, `i18n/<код мови>/docusaurus-plugin-content-docs/version-3/`) - JSON-файли для кожної версії документації з перекладами категорій у бічній панелі (наприклад, `current.json`, `version-3.json` тощо) - Тека `i18n/docusaurus-theme-classic` з файлами `footer.json` та `navbar.json` для перекладу тексту в навігаційній панелі та нижньому колонтитулі сайту - Ключі `i18n` у файлі `docusaurus.config.js` містять перелік усіх локалей та опції конфігурації для меню локалей у навігаційній панелі сайту Для отримання додаткової інформації див. [i18n - Вступ](https://docusaurus.io/docs/i18n/introduction) у документації Docusaurus. ### Початок роботи з новою мовою {#starting-a-new-language} Посібник, який допоможе вам перекласти вміст сайту, див. [i18n - Tutorial](https://docusaurus.io/docs/i18n/tutorial) у документації Docusaurus. Щоб почати роботу з новою мовою: 1. Якщо ви ще цього не зробили, встановіть залежності: ```sh yarn install --frozen-lockfile ``` 1. Запустіть команду Docusaurus `write-translations`. Наприклад, щоб додати локаль `fr` (французька): `yarn write-translations -- --locale fr`. Це створить необхідну структуру текстових файлів для мови та ініціалізує файли перекладу JSON, необхідні для перекладу елементів сайту, таких як навігаційна панель, нижній колонтитул, цільова сторінка та бічна панель. ```sh yarn write-translations --locale ``` 1. Виконайте мінімальні переклади для нової мови: 1. Перекладіть файл `code.json`. 1. У теці `i18n/docusaurus-theme-classic` перекладіть файли `footer.json` та `navbar.json`. 1. У файлі `docusaurus-plugin-content-blog/options.json` перекладіть елементи блогу у файлі `options.json`. 1. Додайте мову до ключа `i18n` файлу `docusaurus.config.js`, щоб вона зʼявилася у меню навігаційної панелі: ```yaml i18n: { defaultLocale: 'en', # додайте нову мову до цього списку локалей locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'], localeConfigs: { en: { htmlLang: 'en-us', label: 'English', }, de: { label: 'Deutsch', }, # new_lang { # label: 'Navbar label', # } }, }, ``` 1. (Опціонально) Перекладіть документи або вміст блогу. Див. розділ «Переклад» нижче. 1. Перевірте зміни, запустивши локалізований сайт у режимі розробки, вказавши локаль: ```sh yarn start --locale fr ``` :::note Кожна локаль є окремою самостійним односторінковим застосунком. Ви можете переглянути лише одну локаль за раз. Неможливо переглянути всі локалі одночасно. ::: ### Переклад {#translating} Перш ніж перекладати вміст документів, ознайомтеся з наступними рекомендаціями та вказівками: * У процесі перекладу можуть допомогти інструменти перекладу. До них належать і машинні переклади. Машинні переклади перед публікацією повинні бути відредаговані або перевірені носієм мови на предмет граматики та змісту. * Не додавайте неперекладену копію англійського файлу до `i18n/[LANG]/plugin-content-docs` або `i18n/[LANG]/plugin-content-blog`. Після того, як мова зʼявиться на сайті, будь-які неперекладені сторінки автоматично перенаправлятимуться на англійську. Переклад займає час, і ви завжди варто перекладати найактуальнішу версію документів, а не застарілу гілку. * Переконайтеся, що ви видалили всі рядки `aliases` із розділу заголовка. Рядок на зразок `aliases: ["/docs/using_helm/"]` не належить до перекладів. Це перенаправлення для старих посилань, які не існують для нових сторінок. * Додайте ідентифікатори анкорів до будь-яких заголовків, використовуючи формат `## Приклад заголовка {#example-anchor-id}`. Ідентифікатори анкорів повинні бути англійською мовою і відповідати ідентифікаторам анкорів відповідного заголовка на англійській сторінці документації. Наприклад, `## 后端存储 {#storage-backends}` відповідає `## Storage backends {#storage-backends}`. Це гарантує, що будь-які анкорні посилання на заголовки все ще працюють у перекладеній версії сторінки. Для отримання додаткової інформації див. [Anchor links to headings](https://github.com/helm/helm-www/blob/main/ARCHITECTURAL_DECISIONS.md#anchor-links-to-headings) у `ARCHITECTURAL_DECISIONS.md`. Щоб перекласти документи та вміст блогу: 1. Переконайтеся, що цільова локаль існує в теці `i18n`. Якщо її немає, див. розділ «Початок роботи з новою мовою» вище. 1. Скопіюйте один або кілька файлів markdown, які ви хочете перекласти, з `/docs` або `/versioned_docs` до відповідної папки версії в `i18n//docusaurus-plugin-content-docs`. Наприклад, щоб перекласти `versioned_docs/version-3/example.md` корейською мовою: ```sh cp versioned_docs/version-3/topics/example.md i18n/ko/docusaurus-plugin-content-docs/version-3/topics/example.md ``` 1. Скопіюйте один або кілька файлів markdown, які ви хочете перекласти, з `/blog` до `i18n/<код мови>/docusaurus-plugin-content-blog`. Наприклад, щоб перекласти `blog/2025-09-09-path-to-helm-v4.md` корейською мовою: ```sh cp blog/2025-09-09-path-to-helm-v4.md i18n/ko/docusaurus-plugin-content-blog/2025-09-09-path-to-helm-v4.md ``` 1. Якщо ви ще цього не зробили, встановіть залежності: ```sh yarn install --frozen-lockfile ``` 1. Перевірте зміни, запустивши локалізований сайт у режимі розробки, вказавши локаль: ```sh yarn start --locale ko ``` :::note Кожна локаль є окремим самостійним односторінковим застосунком. Одночасно можна переглянути лише одну локаль. Неможливо переглянути всі локалі одночасно. ::: ## Перехід між мовами {#navigating-between-languages} Користувачі переходять між мовами за допомогою випадаючого меню локалі в навігаційній панелі сайту. Ключ `i18n` у глобальному файлі сайту `docusaurus.config.js` — це місце, де налаштовується навігація між мовами. Щоб додати нову мову, додайте локаль, використовуючи [дволітерний код мови](./localization/#two-letter-language-code), визначений вище. Приклад: ```yaml i18n: { defaultLocale: 'en', # додайте нову мову до цього списку локалей locales: ['en', 'de', 'es', 'fr', 'gr', 'ja', 'ko', 'pt', 'ru', 'uk', 'zh'], localeConfigs: { en: { htmlLang: 'en-us', label: 'English', }, de: { label: 'Deutsch', }, # new_lang { # label: 'Navbar label', # } }, }, ``` ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/related.md ================================================ --- title: Повʼязані проєкти та документація description: сторонні інструменти, втулки та документація, надані спільнотою! sidebar_position: 4 --- Спільнота Helm розробила безліч додаткових інструментів, втулків та документації про Helm. Нам завжди цікаво дізнатися про ці проєкти. Якщо у вас є щось, що ви хочете додати до цього списку, будь ласка, відкрийте [issue](https://github.com/helm/helm-www/issues) або [pull request](https://github.com/helm/helm-www/pulls). ## Втулки Helm {#helm-plugins} - [helm-adopt](https://github.com/HamzaZo/helm-adopt) — Втулок Helm v3 для включення поточних ресурсів k8s у нові згенеровані Helm чарти. - [helm-cel](https://github.com/idsulik/helm-cel) — Втулок, який використовує Common Expression Language (CEL) для перевірки значень. - [helm-chartsnap](https://github.com/jlandowner/helm-chartsnap) — Втулок для тестування знімків для Helm чартів. - [Helm Diff](https://github.com/databus23/helm-diff) — Попередній перегляд `helm upgrade` у вигляді кольорового diff. - [Helm Dt](https://github.com/vmware-labs/distribution-tooling-for-helm) — Втулок, який допомагає розподілити Helm чарти між OCI реєстрами та в середовищах Air gap. - [Helm Dashboard](https://github.com/komodorio/helm-dashboard) — GUI для Helm, візуалізація релізів та репозиторіїв, відмінності у маніфестах. - [helm-gcs](https://github.com/hayorov/helm-gcs) — Втулок для керування репозиторіями на Google Cloud Storage. - [helm-git](https://github.com/aslafy-z/helm-git) — Встановлює чарти та отримує файли значень з ваших Git репозиторіїв. - [helm-k8comp](https://github.com/cststack/k8comp) — Втулок для створення Helm чартів з hiera за допомогою k8comp. - [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) — Оновлює метадані релізу Helm для заміни застарілих або видалених API Kubernetes. - [helm-migrate-values](https://github.com/OctopusDeployLabs/helm-migrate-values) — Втулок для перенесення вказаних користувачем значень між версіями чартів Helm, щоб впоратися зі змінами схеми у файлі `values.yaml`. - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) — Втулок для моніторингу релізу та відкату на основі запиту Prometheus/ElasticSearch. - [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) — Втулок для управління релізами, оновлення значень релізу, витягує (перестворює) Helm чарти з розгорнутих релізів, встановлює TTL релізу Helm. - [helm-s3](https://github.com/hypnoglow/helm-s3) — Втулок Helm, який дозволяє використовувати AWS S3 як [приватний] репозиторій чартів. - [helm-secrets](https://github.com/jkroepke/helm-secrets) — Втулок для безпечного керування та зберігання секретів (на основі [sops](https://github.com/mozilla/sops)). - [helm-sigstore](https://github.com/sigstore/helm-sigstore) — Втулок для Helm для інтеграції з екосистемою [sigstore](https://sigstore.dev/). Пошук, завантаження та перевірка підписаних Helm чартів. - [helm-tanka](https://github.com/Duologic/helm-tanka) — Втулок Helm для рендерингу Tanka/Jsonnet всередині Helm чартів. - [hc-unit](https://github.com/xchapter7x/hcunit) — Втулок для юніт-тестування чартів локально за допомогою OPA (Open Policy Agent) & Rego. - [helm-unittest](https://github.com/helm-unittest/helm-unittest)— Втулок для юніт-тестування чартів локально з YAML. - [helm-val](https://github.com/HamzaZo/helm-val) — Втулок для отримання значень з попереднього релізу. - [helm-external-val](https://github.com/kuuji/helm-external-val) — Втулок, який отримує значення helm з зовнішніх джерел (configMaps, Secrets тощо). - [helm-images](https://github.com/nikhilsbhat/helm-images) — Втулок Helm для отримання всіх можливих зображень з чарту перед розгортанням або з розгорнутого релізу. - [helm-drift](https://github.com/nikhilsbhat/helm-drift) — Втулок Helm, який виявляє конфігурацію, яка відрізняється від Helm чарту. - [helm-tui](https://github.com/pidanou/helm-tui) — Легкий інтерфейс для управління вашими ресурсами Helm без виходу з терміналу Ми також заохочуємо авторів на GitHub використовувати теґ [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) у своїх репозиторіях втулків. ## Додаткові інструменти {#additional-tools} Інструменти, які використовуються поверх Helm. - [Aptakube](https://aptakube.com) — Графічний інтерфейс для керування релізами Helm та Kubernetes. - [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) — Керування префіксованими релізами через різні Kubernetes простори імен, а також видалення завершених завдань для складних розгортань. - [avionix](https://github.com/zbrookle/avionix) — Інтерфейс Python для генерації Helm чартів та Kubernetes yaml, що дозволяє успадкування та зменшення дублювання коду. - [Botkube](https://botkube.io) — Виконання Helm команд безпосередньо з Slack, Discord, Microsoft Teams та Mattermost. - [Captain](https://github.com/alauda/captain) — Контролер Helm3, що використовує HelmRequest та Release CRD. - [Chartify](https://github.com/appscode/chartify) — Генерація Helm чартів з наявних ресурсів Kubernetes. - [ChartMuseum](https://github.com/helm/chartmuseum) — Репозиторій Helm Chart з підтримкою Amazon S3 та Google Cloud Storage. - [chart-registry](https://github.com/hangyan/chart-registry) — Хостинг Helm чартів на OCI Registry. - [Codefresh](https://codefresh.io) — Кластерна CI/CD платформа з UI панелями для управління Helm чартами та релізами. - ⁠[Cyclops](https://cyclops-ui.com) — Динамічний UI для Kubernetes на основі Helm чартів. - [Flux](https://fluxcd.io/docs/components/helm/) — Безперервна та прогресивна доставка з Git до Kubernetes. - [Helmfile](https://github.com/helmfile/helmfile) — Helmfile - це декларативна специфікація для розгортання Helm чартів. - [Helmper](https://github.com/ChristofferNissen/helmper) — Helmper допомагає імплементувати Helm чарти, включаючи всі OCI артефакти (образи) у ваші OCI реєстри. Helmper також полегшує сканування безпеки та застосування патчів до OCI образів. Helmper використовує Helm, Oras, Trivy, Copacetic та Buildkitd. - [Helmsman](https://github.com/Praqma/helmsman) — Helmsman, це інструмент helm-charts-as-code, який дозволяє встановлювати/оновлювати/захищати/переміщувати/видаляти релізи з версійно контрольованих файлів стану (описаних у простому форматі TOML). - [HULL](https://github.com/vidispine/hull) — Ця бібліотека чартів надає готовий інтерфейс для специфікації всіх обʼєктів Kubernetes безпосередньо у `values.yaml`. Вона усуває необхідність писати будь-які шаблони для ваших чартів і має багато додаткових функцій для спрощення створення та використання Helm чартів. - [K8Studio](https://k8studio.io) — Інтерфейс користувача для десктопів для управління кластерами Kubernetes з інтегрованим менеджером Helm. - [Konveyor Move2Kube](https://konveyor.io/move2kube/) — Генерація Helm чартів для ваших поточних проєктів. - [Landscaper](https://github.com/Eneco/landscaper/) — "Landscaper бере набір посилань на Helm Chart зі значеннями (бажаний стан) і реалізує їх в кластері Kubernetes." - [Monocular](https://github.com/helm/monocular) — Веб UI для репозиторіїв Helm Chart. - [Monokle](https://monokle.io) — Десктопний інструмент для створення, налагодження та розгортання ресурсів Kubernetes та Helm чартів. - [Orkestra](https://azure.github.io/orkestra/) — Хмарна платформа оркестрування релізів та управління життєвим циклом (LCM) для повʼязаних груп Helm релізів та їх субчартів. - [Tanka](https://tanka.dev/helm) — Grafana Tanka налаштовує ресурси Kubernetes через Jsonnet з можливістю споживання Helm чартів. - [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) — Провайдер Helm для HashiCorp Terraform дозволяє управління життєвим циклом Helm чартів з декларативним синтаксисом інфраструктури як коду. Провайдер Helm часто поєднується з іншими провайдерами Terraform, такими як провайдер Kubernetes, для створення спільного робочого процесу серед усіх інфраструктурних послуг. - [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) — Втулок VIM для Kubernetes та Helm. ## Мають Helm {#helm-included} Платформи, дистрибутиви та сервіси, що включають підтримку Helm. - [Kubernetic](https://kubernetic.com/) — Десктопний клієнт Kubernetes. - [Jenkins X](https://jenkins-x.io/) — Відкритий автоматизований CI/CD для Kubernetes, який використовує Helm для [просування](https://jenkins-x.io/docs/getting-started/promotion/) застосунків через середовища за допомогою GitOps. ## Різне {#misc} Корисні речі для авторів чартів та користувачів Helm. - [Await](https://github.com/saltside/await) — Docker образ для "очікування" різних умов, особливо корисний для init контейнерів. [Детальніше](https://blog.slashdeploy.com/2017/02/16/introducing-await/). ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/release_checklist.md ================================================ --- title: Перевірка випуску description: Чеклист для супровідників при випуску нової версії Helm. sidebar_position: 3 --- # Посібник для супровідників щодо випуску Helm Час для нового випуску Helm! Як супровідник Helm, який випускає нову версію, ви є найкращою людиною, щоб оновити цей чеклист випуску у разі, якщо ваш досвід відрізняється від задокументованого тут. Усі випуски матимуть формат vX.Y.Z, де X — це основний номер версії, Y — це номер мінорної версії, а Z — це номер патч-релізу. Цей проєкт суворо дотримується [семантичного версіювання](https://semver.org/lang/uk/), тому дотримання цього етапу є критично важливим. Helm заздалегідь оголошує дату свого наступного мінорного випуску. Всі зусилля мають бути спрямовані на дотримання оголошеної дати. Крім того, під час запуску процесу випуску дату наступного випуску має бути обрано, оскільки вона буде використана в процесі випуску. Ці інструкції охоплюють початкову конфігурацію, а потім процес випуску для трьох різних типів випусків: * Основні випуски — випускаються рідше, містять кардинальні зміни * Мінорні випуски — випускаються кожні 3-4 місяці, не містять кардинальних змін * Патч-релізи — випускаються щомісяця, не потребують виконання всіх кроків цього посібника [Початкова конфігурація](#initial-configuration) 1. [Створення гілки випуску](#1-create-the-release-branch) 2. [Основні/Мінорні випуски: змініть номер версії в Git](#2-majorminor-releases-change-the-version-number-in-git) 3. [Основні/Мінорні випуски: зафіксуйте і надішліть гілку випуску](#3-majorminor-releases-commit-and-push-the-release-branch) 4. [Основні/Мінорні випуски: створіть кандидат у випуск](#4-majorminor-releases-create-a-release-candidate) 5. [Основні/Мінорні випуски: повторіть на наступних кандидатах у випуск](#5-majorminor-releases-iterate-on-successive-release-candidates) 6. [Завершення випуску](#6-finalize-the-release) 7. [Написання приміток до випуску](#7-write-the-release-notes) 8. [PGP-підписання завантажень](#8-pgp-sign-the-downloads) 9. [Публікація випуску](#9-publish-release) 10. [Оновлення документації](#10-update-docs) 11. [Оповіщення спільноти](#11-tell-the-community) ## Початкова конфігурація {#initial-configuration} ### Налаштування віддаленого репозиторію Git {#set-up-git-remote} Важливо зазначити, що цей документ передбачає, що віддалений репозиторій у вашій копії, який відповідає , називається "upstream". Якщо це не так (наприклад, якщо ви вирішили назвати його "origin" або щось подібне), обовʼязково змініть наведену інформацію відповідно до вашого локального середовища. Якщо ви не впевнені, як називається ваш upstream, використовуйте команду `git remote -v`, щоб дізнатися. Якщо у вас немає [upstream remote](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork), ви можете додати його, використовуючи таку команду: ```shell git remote add upstream git@github.com:helm/helm.git ``` ### Налаштування змінних середовища {#set-up-environment-variables} У цьому документі також буде використано кілька змінних середовища, які ви можете налаштувати для зручності. Для основних/мінорних випусків використовуйте наступне: ```shell export RELEASE_NAME=vX.Y.0 export RELEASE_BRANCH_NAME="release-X.Y" export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" ``` Якщо ви створюєте патч-реліз, використовуйте наступне: ```shell export PREVIOUS_PATCH_RELEASE=vX.Y.Z export RELEASE_NAME=vX.Y.Z+1 export RELEASE_BRANCH_NAME="release-X.Y" ``` ### Налаштування ключа підпису {#set-up-signing-key} Ми також додамо безпеку та перевірку процесу випуску шляхом хешування бінарних файлів і надання файлів підпису. Ми виконуємо це, використовуючи [GitHub та GPG](https://help.github.com/en/articles/about-commit-signature-verification). Якщо у вас ще не налаштовано GPG, ви можете виконати такі кроки: 1. [Встановіть GPG](https://gnupg.org/index.html) 2. [Згенеруйте GPG ключ](https://help.github.com/en/articles/generating-a-new-gpg-key) 3. [Додайте ключ до облікового запису GitHub](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) 4. [Налаштуйте ключ підпису в Git](https://help.github.com/en/articles/telling-git-about-your-signing-key) Після того, як у вас буде ключ підпису, вам потрібно додати його до файлу KEYS у кореневій теці репозиторію. Інструкції щодо додавання його до файлу KEYS містяться у файлі. Якщо ви ще не зробили цього, вам потрібно додати ваш публічний ключ до мережі keyserver. Якщо ви використовуєте GnuPG, ви можете дотримуватися [інструкцій, наданих Debian](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver). ## 1. Створення гілки випуску {#1-create-the-release-branch} ### Основні/Мінорні випуски {#majorminor-releases} Основні випуски включають нові функції та зміни в поведінці, *які порушують зворотну сумісність*. Мінорні випуски містять нові функції, які не порушують зворотну сумісність. Для створення основного або мінорного випуску почніть зі створення гілки `release-X.Y` від основної гілки (main). ```shell git fetch upstream git checkout upstream/main git checkout -b $RELEASE_BRANCH_NAME ``` Ця нова гілка буде основою для випуску, в якій ми будемо надалі працювати. Переконайтеся, що на GitHub існує [віха в helm/helm](https://github.com/helm/helm/milestones) для цього випуску (створіть її, за потреби). Переконайтеся, що PR та issues для цього випуску входять до цього етапу. Для основних і мінорних випусків переходьте до кроку 2: [Основні/Мінорні випуски: зміна номеру версії в Git](#2-majorminor-releases-change-the-version-number-in-git). ### Патч-релізи {#patch-releases} Патч-релізи включають кілька критичних виправлень для поточних випусків. Почніть зі створення гілки `release-X.Y`: ```shell git fetch upstream git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME ``` Звідси ми можемо вибрати коміти, які хочемо включити до патч-релізу: ```shell # отримуємо ідентифікатори комітів, які хочемо вибрати git log --oneline # вибираємо коміти, починаючи з найстарішого, без включення комітів злиття git cherry-pick -x ``` Після вибору комітів гілку випуску потрібно надіслати у віддалений репозиторій. ```shell git push upstream $RELEASE_BRANCH_NAME ``` Надсилання гілки викличе запуск тестів. Переконайтеся, що вони проходять перед створенням теґу. Цей новий теґ стане основою для патч-релізу. Створення [віхи в helm/helm](https://github.com/helm/helm/milestones) є необов’язковим для патч-релізів. Обов’язково перевірте [GitHub Actions](https://github.com/helm/helm/actions), щоб переконатися, що випуск пройшов CI, перш ніж продовжити. Патч-релізи можуть пропустити кроки 2-5 і перейти до кроку 6 для [Завершення випуску](#6-finalize-the-release). ## 2. Основні/Мінорні випуски: Зміна номера версії в Git {#2-majorminor-releases-change-the-version-number-in-git} При виконанні основного або мінорного випуску переконайтеся, що оновили файл `internal/version/version.go` з новою версією випуску. ```shell $ git diff internal/version/version.go diff --git a/internal/version/version.go b/internal/version/version.go index 712aae64..c1ed191e 100644 --- a/internal/version/version.go +++ b/internal/version/version.go @@ -30,7 +30,7 @@ var ( // Збільшіть основний номер для додавання нових функцій та змін в поведінці. // Збільшіть мінорний номер для виправлення помилок та підвищення продуктивності. // Збільшіть номер патча для критичних виправлень в поточних версіях. - version = "v3.3" + version = "v3.4" // metadata — це додаткові дані часу побудови metadata = "" ``` Окрім оновлення версії у файлі `version.go`, вам також потрібно оновити відповідні тести, що використовують цей номер версії. * `cmd/helm/testdata/output/version.txt` * `cmd/helm/testdata/output/version-client.txt` * `cmd/helm/testdata/output/version-client-shorthand.txt` * `cmd/helm/testdata/output/version-short.txt` * `cmd/helm/testdata/output/version-template.txt` * `pkg/chartutil/capabilities_test.go` ```shell git add . git commit -m "bump version to $RELEASE_NAME" ``` Це оновить версію лише для гілки $RELEASE_BRANCH_NAME. Вам також потрібно буде інтегрувати ці зміни в основну гілку, щоб підготувати її до наступного випуску, як у [цьому прикладі з 3.2 до 3.3](https://github.com/helm/helm/pull/8411/files), та додати його до віхи наступного випуску. ```shell # отримуємо ідентифікатор останнього коміта, тобто коміт для підвищення версії git log --format="%H" -n 1 # створюємо нову гілку від основної гілки git checkout main git checkout -b bump-version- # вибираємо коміт за допомогою ідентифікатора з першої команди git cherry-pick -x # комітимо зміни git push origin bump-version- ``` ## 3. Основні/Мінорні випуски: Коміт та збереження гілки релізу {#3-majorminor-releases-commit-and-push-the-release-branch} Щоб інші могли почати тестування, тепер можна надіслати гілку релізу в upstream і розпочати процес тестування. ```shell git push upstream $RELEASE_BRANCH_NAME ``` Переконайтеся, що перевірили [GitHub Actions](https://github.com/helm/helm/actions), щоб побачити, що реліз пройшов CI перед тим, як продовжити. Якщо є можливість, дайте іншим перевірити гілку, перш ніж продовжувати, щоб переконатися, що всі необхідні зміни внесені та всі коміти для релізу присутні. ## 4. Основні/Мінорні випуски: Створення реліз-кандидата {#4-majorminor-releases-create-a-release-candidate} Тепер, коли гілку релізу створено та підготовлено, настав час почати створення та ітерацію реліз-кандидатів. ```shell git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` GitHub Actions автоматично створить образ з теґом релізу та клієнтський бінарний файл для тестування. Для тестувальників процес початку тестування після завершення побудови артефактів GitHub Actions включає наступні кроки для отримання клієнта: Linux/amd64, використовуючи /bin/bash: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz ``` Darwin/amd64, використовуючи Terminal.app: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz ``` Windows/amd64, використовуючи PowerShell: ```shell PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" ``` Потім розпакуйте та перемістіть бінарний файл в теку, що знаходиться в $PATH, або перемістіть його в інше місце та додайте його до $PATH (наприклад, /usr/local/bin/helm для Linux/macOS, C:\Program Files\helm\helm.exe для Windows). ## 5. Основні/Мінорні випуски: Ітерація на наступних реліз-кандидатах {#5-majorminor-releases-iterate-on-successive-release-candidates} Протягом кількох днів активно інвестуйте час та ресурси, щоб спробувати виявити будь-які проблеми з Helm, документуючи всі важливі висновки для релізу. Цей час слід витратити на тестування та пошук способів, у яких реліз міг би викликати проблеми з різними функціями або середовищами оновлення, а не на написання коду. У цей період реліз перебуває в стані заморожування коду, і будь-які додаткові зміни коду будуть перенесені на наступний реліз. Протягом цієї фази гілка $RELEASE_BRANCH_NAME буде продовжувати розвиватися, оскільки ви будете створювати нові реліз-кандидати. Частота появи нових кандидатів залежить від менеджера релізу: використовуйте здоровий глузд, враховуючи серйозність виявлених проблем, доступність тестувальників та дату завершення релізу. Загалом, краще перенести реліз на пізніший термін, ніж випустити зламаний реліз. Кожен раз, коли ви хочете створити нового реліз-кандидата, починайте з додавання комітів до гілки, використовуючи cherry-pick з main: ```shell git cherry-pick -x ``` Також не забудьте надіслати гілку на GitHub та переконатися, що вона пройшла CI. Після цього додайте теґ та повідомте користувачів про нового реліз-кандидата: ```shell export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` Після того як теґ надіслано на GitHub, перевірте, чи успішно збирається гілка з цим тегом в CI. Далі просто повторюйте цей процес, постійно тестуючи, поки не будете задоволені реліз-кандидатом. Для реліз-кандидата повноцінні нотатки до релізу ще не пишуться, але можна підготувати [чернетку реліз-нотаток](#7-write-the-release-notes). ## 6. Завершення релізу {#6-finalize-the-release} Коли ви нарешті задоволені якістю реліз-кандидата, можна переходити до створення остаточного релізу. Перевірте ще раз, чи все в порядку, а потім надішліть теґ релізу. ```shell git checkout $RELEASE_BRANCH_NAME git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" git push upstream $RELEASE_NAME ``` Переконайтеся, що реліз успішно пройшов на [GitHub Actions](https://github.com/helm/helm/actions). Якщо ні, вам доведеться виправити помилки та знову надіслати реліз. Оскільки CI-завдання займе деякий час для виконання, ви можете перейти до написання реліз-нотаток, поки процес триває. ## 7. Написання реліз-нотаток {#7-write-the-release-notes} Ми автоматично створимо лог змін на основі комітів, які відбулися протягом циклу випуску, але для кінцевого користувача зазвичай корисніше, якщо реліз-нотатки будуть написані вручну людиною або командою маркетингу. Якщо ви випускаєте мажорний або мінорний реліз, достатньо перерахувати помітні зміни, що впливають на користувачів. Для патч-релізів зробіть те саме, але також зазначте симптоми та на кого вони впливають. Реліз-нотатки повинні містити версію та заплановану дату наступного релізу. Приклад реліз-нотаток для мінорного релізу (переклад дано для наочності): ```markdown ## vX.Y.Z Helm vX.Y.Z — це реліз з новими функціями. Цього разу ми зосередилися на <вставте ключову тезу>. Користувачам рекомендується оновитися щоб мати найкращий досвід. Спільнота продовжує зростати, і ми були б раді бачити вас серед нас! - Приєднуйтеся до обговорення в [Kubernetes Slack](https://kubernetes.slack.com): - `#helm-users` для запитань і просто для спілкування - `#helm-dev` для обговорення PR, коду та багів - Відвідайте публічну зустріч розробників: щочетверга, 9:30 за тихоокеанським часом в [Zoom](https://zoom.us/j/696660622) - Тестуйте, налагоджуйте та робіть свій внесок у чарти: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0) ## Важливі зміни - Додано підтримку Kubernetes 1.16, включаючи нові apiVersions для маніфестів. - Оновлено Sprig до версії 2.22. ## Встановлення та оновлення Завантажте Helm X.Y.Z. Бінарні файли для загальних платформ тут: - [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) - [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) - [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) - [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) [Короткий посібник з налаштування](/intro/quickstart.md) допоможе вам розпочати роботу. Для інструкцій з оновлення або детальних нотаток з встановлення перегляньте [посібник з встановлення](/intro/install.md). Ви також можете використовувати [скрипт для встановлення](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) на будь-якій системі з `bash`. ## Що далі - vX.Y.Z+1 міститиме лише виправлення багів і планується на <вставте ДАТУ>. - vX.Y+1.0 — це наступний реліз з новими функціями, який планується на <вставте ДАТУ>. Цей реліз буде зосереджений на ... ## Лог змін - chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) - fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) ``` Частково заповнений набір реліз-нотаток, включаючи лог змін, можна створити за допомогою наступної команди: ```shell export VERSION="$RELEASE_NAME" export PREVIOUS_RELEASE=vX.Y.Z make clean make fetch-dist make release-notes ``` Це створить гарну базову версію реліз-нотаток, до яких вам потрібно буде лише додати розділи **Важливі зміни** та **Що далі**. Не соромтеся додавати свій стиль до реліз-нотаток; людям приємно думати, що ми не всі тут роботи. Ви також повинні переконатися, що URL-адреси та контрольні суми правильні в автоматично згенерованих реліз-нотатках. Після завершення перейдіть до [helm/helm releases](https://github.com/helm/helm/releases) на GitHub і відредагуйте реліз-нотатки для теґу релізу за допомогою написаних тут нотаток. Для цільової гілки встановіть $RELEASE_BRANCH_NAME. На цьому етапі варто залучити інших людей для перегляду реліз-нотаток перед публікацією релізу. Надішліть запит у [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG) для перегляду. Це завжди корисно, оскільки легко щось пропустити. ## 8. PGP Підпис файлів для завантаження {#8-pgp-sign-the-downloads} Хоча хеші забезпечують підпис, що вміст завантажуваних файлів відповідає тому, що було згенеровано, підписані пакунки забезпечують простежуваність походження пакунка. Щоб це зробити, виконайте наступні команди `make`: ```shell export VERSION="$RELEASE_NAME" make clean # якщо ще не виконано make fetch-dist # якщо ще не виконано make sign ``` Це створить файли підписів у форматі ascii armored для кожного з файлів, завантажених CI. Усі файли підписів (`*.asc`) необхідно завантажити до релізу на GitHub (додати до бінарних файлів). ## 9. Оприлюднення релізу {#9-publish-release} Час зробити реліз офіційним! Після того, як реліз-нотатки збережено на GitHub, завершено збірку CI та додано файли підписів до релізу, можна натиснути "Publish" на сторінці релізу. Це опублікує реліз, позначивши його як "latest" (останній) та покаже його на головній сторінці репозиторію [helm/helm](https://github.com/helm/helm). ## 10. Оновлення документації {#10-update-docs} Розділ документації на сайті [Helm](/docs) містить версії Helm. Необхідно оновити на сайті версії для major, minor і patch. Також потрібно оновити дату наступного minor релізу. :::note До версії 4.00… Щоб це зробити, створіть pull request в репозиторії [helm-www](https://github.com/helm/helm-www). У файлі `config.toml` знайдіть відповідний розділ `params.versions` та оновіть версію Helm, як у цьому прикладі [оновлення поточної версії](https://github.com/helm/helm-www/pull/676/files). У тому ж файлі `config.toml` оновіть розділ `params.nextversion`. ::: Закрийте [milestone](https://github.com/helm/helm/milestones) для релізу, якщо це прийнятно. Оновіть [version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md) для major і minor релізів. Оновіть календар релізів [тут](https://helm.sh/calendar/release): * створіть запис для наступного minor релізу з нагадуванням на цей день о 17:00 GMT * створіть запис для RC1 наступного minor релізу в понеділок тижня перед запланованим релізом, з нагадуванням на цей день о 17:00 GMT ## 11. Сповістіть спільноту {#11-tell-the-community} Вітаємо! Ви закінчили. Візьміть собі $DRINK_OF_CHOICE. Ви цього заслуговуєте. Після того, як насолодитеся своїм $DRINK_OF_CHOICE, повідомте про новий реліз у Slack та Twitter з посиланням на [реліз на GitHub](https://github.com/helm/helm/releases). Опційно, напишіть блог пост про новий реліз і покажіть деякі з нових функцій там! ================================================ FILE: i18n/uk/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: Політика графіку нових випусків description: Описує політику графіку випусків Helm --- Для зручності користувачів Helm визначає та оголошує дати випусків заздалегідь. Цей документ описує політику, що регулює графік випусків Helm. ## Календар випусків {#release-calendar} Публічний календар із запланованими випусками Helm можна знайти [тут](https://helm.sh/calendar/release). ## Семантичне версіювання {#semantic-versioning} Версії Helm виражаються як `x.y.z`, де `x` — це основна версія, `y` — мінорна версія, а `z` — випуск патча, відповідно до термінології [семантичного версіювання](https://semver.org/lang/uk/spec/v2.0.0.html). ## Випуски патчів {#patch-releases} Випуски патчів надають користувачам виправлення помилок і виправлення з безпеки. Вони не містять нових функцій. Новий випуск патча, що стосується останньої мінорної/основної версії, зазвичай здійснюється один раз на місяць, у другу середу кожного місяця. Випуск патча для виправлення пріоритетної регресії або проблеми безпеки може бути здійснений за потребою. Випуск патча буде скасовано з будь-якої з наступних причин: - якщо з моменту попереднього випуску не було додано нового вмісту; - якщо дата випуску патча припадає на тиждень до першого реліз-кандидата (RC1) майбутнього мінорного випуску; - якщо дата випуску патча припадає на чотири тижні після мінорного випуску. ## Мінорні випуски {#minor-releases} Мінорні випуски містять виправлення безпеки та помилок, а також нові функції. Вони є зворотно сумісними з API та використанням CLI. Щоб узгодитися з випусками Kubernetes, мінорний випуск Helm здійснюється кожні 4 місяці (3 випуски на рік). Додаткові мінорні випуски можуть здійснюватися за потреби, але це не вплине на графік оголошеного майбутнього випуску, якщо до нього не залишилося менше 7 днів. Одночасно з публікацією випуску буде оголошено дату наступного мінорного випуску, яка буде опублікована на головній вебсторінці Helm. ## Основні випуски {#major-releases} Основні випуски містять зміни, що порушують сумісність. Такі випуски є рідкісними, але іноді необхідні для подальшого важливого розвитку Helm. Основні випуски можуть бути складними для планування. З огляду на це, остаточна дата випуску буде вибрана та оголошена лише після того, як буде доступна перша бета-версія такого випуску. ================================================ FILE: i18n/uk/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Проєкт Helm", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Чарти", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "Розробка", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "Спільнота", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "Вихідний код", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "Блог", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "Події", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "Кодекс поведінки", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "Вступ", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Поради та хитрощі для чартів", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "Розробка чартів", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "Пошук 800+ чартів", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "Як взяти участь", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "Мейнтейнери", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "Щотижневі зустрічі", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "Спільнота на GitHub", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "Ми є дипломованим проєктом Cloud Native Computing Foundation.
© Автори Helm 2025. Документація поширюється на умовах ліцензії CC-BY-4.0.
© 2025 The Linux Foundation. Усі права застережено. The Linux Foundation має та використовує зареєстровані торгові марки. Для ознайомлення з переліком торгових марок The Linux Foundation, відвідайте сторінку використання торгових марок.", "description": "The footer copyright" }, "logo.alt": { "message": "Логотип CNCF", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/uk/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Логотип Helm", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "Документація", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Чарти", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "Блог", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "Спільнота", "description": "Navbar item with label Community" } } ================================================ FILE: i18n/zh/code.json ================================================ { "home.community.nextFeatureRelease": { "message": "下一个功能版本", "description": "Next Feature Release section title" }, "home.community.nextFeatureRelease.version": { "message": "版本：", "description": "Version label" }, "home.community.nextFeatureRelease.date": { "message": "日期：", "description": "Date label" }, "home.community.nextFeatureRelease.calendar": { "message": "发布日历", "description": "Release Calendar link" }, "home.community.upcomingEvents": { "message": "即将举行的活动", "description": "Upcoming Events section title" }, "home.community.upcomingEventsSubtitle": { "message": "即将举行的活动", "description": "Upcoming Events subtitle" }, "home.community.pastEventsSubtitle": { "message": "过往活动", "description": "Past Events subtitle" }, "home.community.sigApps": { "message": "SIG Apps", "description": "SIG Apps section title" }, "home.community.sigApps.description": { "message": "他们{meetLink}来演示和讨论工具和项目。社区会议会被记录并{youtubeLink}。", "description": "SIG Apps meeting description" }, "home.community.sigApps.meetLink": { "message": "每周聚会", "description": "Link to SIG Apps meetings" }, "home.community.sigApps.youtubeLink": { "message": "分享到 YouTube", "description": "Link to YouTube recordings" }, "home.community.developerStandups": { "message": "开发者站会" }, "home.community.developerStandups.time": { "message": "星期四 9:30-10am (PT)", "description": "Developer Standups day and time" }, "home.community.developerStandups.description": { "message": "这些会议向所有人开放。查看{communityRepoLink}了解笔记和详情。", "description": "Developer Standups description with community repo link" }, "home.community.developerStandups.communityRepoLink": { "message": "社区仓库", "description": "Community repo link" }, "home.community.slack.helmUsers.description": { "message": "讨论使用 Helm、使用图表以及解决常见错误。", "description": "helm-users slack channel description" }, "home.community.slack.helmDevelopment.description": { "message": "关于 Helm 开发、正在进行的 PR、发布等主题。", "description": "helm-dev slack channel description" }, "home.community.slack.charts.description": { "message": "为 Helm Charts 用户和贡献者的讨论。", "description": "charts slack channel description" }, "home.community.slack.join": { "message": "{slackLink}加入 Kubernetes Slack 团队。", "description": "How to join the Kubernetes Slack team with slack link" }, "home.community.slack.join.slackLink": { "message": "在此请求访问权限", "description": "Request access to slack link" }, "home.community.contributing": { "message": "贡献", "description": "Contributing section title" }, "home.community.contributing.description": { "message": "Helm 始终欢迎对项目的新贡献！", "description": "Contributing section description" }, "home.community.contributing.whereToBegin": { "message": "从哪里开始？", "description": "Where to begin? section title" }, "home.community.contributing.whereToBegin.description": { "message": "Helm 是一个拥有众多用户和贡献者的大型项目。可能会有很多需要了解的内容！", "description": "Where to begin? section description" }, "home.community.contributing.whereToBegin.goodFirstIssues": { "message": "如果你想提供帮助但不知道从哪里开始，我们有一个{goodFirstIssuesLink}列表。", "description": "Good first issues sentence with link" }, "home.community.contributing.whereToBegin.goodFirstIssuesLink": { "message": "新手友好的问题", "description": "Good first issues link" }, "home.community.contributing.whatDoIDo": { "message": "我该做什么？", "description": "What do I do? section title" }, "home.community.contributing.whatDoIDo.contributionGuide": { "message": "在贡献代码之前，请阅读我们的{contributionGuideLink}。它涵盖了创建和审查拉取请求的流程。", "description": "What do I do? contribution guide description" }, "home.community.contributing.whatDoIDo.contributionGuideLink": { "message": "贡献指南", "description": "Contribution Guide link" }, "home.community.contributing.whatDoIDo.signYourCommits": { "message": "在编写一些代码后，请{signYourCommitsLink}以确保 Helm 遵守 {cncfLink} 使用的 {dcoLink} 协议。", "description": "What do I do? sign your commits description" }, "home.community.contributing.whatDoIDo.signYourCommitsLink": { "message": "签署你的提交", "description": "Sign your commits link" }, "home.community.title": { "message": "加入社区", "description": "Join the Community title" }, "home.community.subtitle": { "message": "关于 Helm 项目的更多信息以及如何贡献。", "description": "Join the Community subtitle" }, "home.about.whatIsHelm": { "message": "Helm 帮助你管理 Kubernetes 应用程序 — Helm Charts 帮助你定义、安装和升级即使是最复杂的 Kubernetes 应用程序。", "description": "What is Helm? first paragraph" }, "home.about.chartsDescription": { "message": "Charts 易于创建、版本控制、共享和发布 — 所以开始使用 Helm，停止复制粘贴。", "description": "What is Helm? charts paragraph" }, "home.about.cncf": { "message": "Helm 是 {cncfLink} 的毕业项目，由 {helmCommunityLink} 维护。", "description": "What is Helm? CNCF Graduated Project paragraph" }, "home.about.cncf.helmCommunityLink": { "message": "Helm 社区", "description": "Helm community link" }, "home.about.learnMore": { "message": "了解更多：", "description": "Learn more label" }, "home.about.learnMore.helmArchitectureLink": { "message": "Helm 架构", "description": "Helm Architecture link" }, "home.about.learnMore.quickStartGuideLink": { "message": "快速入门指南", "description": "Quick Start Guide link" }, "home.about.learnMore.videoLink": { "message": "视频：Helm 简介", "description": "Video: An Introduction to Helm link" }, "home.about.title": { "message": "什么是 Helm？", "description": "What is Helm? title" }, "home.gettingStarted.title": { "message": "开始使用", "description": "Getting started section title" }, "home.gettingStarted.getHelmTitle": { "message": "获取 Helm！", "description": "Get Helm section title" }, "home.gettingStarted.installHelm": { "message": "使用包管理器安装 Helm，或{downloadLink}。", "description": "Getting started install with package manager sentence with download link" }, "home.gettingStarted.installHelm.downloadLink": { "message": "下载二进制文件", "description": "Download a binary link" }, "home.gettingStarted.postInstall.instructions": { "message": "安装后，解压 helm 二进制文件并将其添加到你的 PATH，然后就可以开始了！查看{docsLink}了解更多{installationLink}和{usageLink}。", "description": "Instructions after installing Helm" }, "home.gettingStarted.postInstall.docsLink": { "message": "文档", "description": "Link to installation docs" }, "home.gettingStarted.postInstall.installationLink": { "message": "安装", "description": "Link to installation instructions" }, "home.gettingStarted.postInstall.usageLink": { "message": "使用说明", "description": "Link to usage instructions" }, "home.gettingStarted.getChartsTitle": { "message": "获取 Chart", "description": "Getting started get charts title" }, "home.gettingStarted.artifactHub": { "message": "访问 {artifactHubLink} 来探索来自众多公共仓库的 {helmChartsLink}。", "description": "Artifact Hub link" }, "home.gettingStarted.artifactHub.helmChartsLink": { "message": "Helm 图表", "description": "Helm charts link" }, "home.features.manageComplexity": { "message": "管理复杂性", "description": "Manage Complexity section title" }, "home.features.manageComplexity.description": { "message": "Charts 描述了即使是最复杂的应用程序，提供可重复的应用程序安装，并充当单一权威来源。", "description": "Manage Complexity section description" }, "home.features.easyUpdates": { "message": "轻松更新", "description": "Easy Updates section title" }, "home.features.easyUpdates.description": { "message": "通过原地升级和自定义钩子，消除更新的痛苦。", "description": "Easy Updates section description" }, "home.features.simpleSharing": { "message": "简单共享", "description": "Simple Sharing section title" }, "home.features.simpleSharing.description": { "message": "Charts 易于版本控制、共享和托管在公共或私有服务器上。", "description": "Simple Sharing section description" }, "home.features.rollbacks": { "message": "回滚", "description": "Rollbacks section title" }, "home.features.rollbacks.description": { "message": "使用 {helmRollback} 可以轻松回滚到发布的旧版本。", "description": "Rollbacks section description" }, "home.features.title": { "message": "功能特性", "description": "Features section title" }, "home.header.tagline": { "message": "Kubernetes 的包管理器", "description": "Helm tagline" }, "home.header.subtitle": { "message": "Helm 是查找、共享和使用为 Kubernetes 构建的软件的最佳方式", "description": "Home page header subtitle" }, "theme.ErrorPageContent.title": { "message": "页面已崩溃。", "description": "The title of the fallback page when the page crashed" }, "theme.BackToTopButton.buttonAriaLabel": { "message": "回到顶部", "description": "The ARIA label for the back to top button" }, "theme.blog.archive.title": { "message": "历史博文", "description": "The page & hero title of the blog archive page" }, "theme.blog.archive.description": { "message": "历史博文", "description": "The page & hero description of the blog archive page" }, "theme.blog.paginator.navAriaLabel": { "message": "博文列表分页导航", "description": "The ARIA label for the blog pagination" }, "theme.blog.paginator.newerEntries": { "message": "较新的博文", "description": "The label used to navigate to the newer blog posts page (previous page)" }, "theme.blog.paginator.olderEntries": { "message": "较旧的博文", "description": "The label used to navigate to the older blog posts page (next page)" }, "theme.blog.post.paginator.navAriaLabel": { "message": "博文分页导航", "description": "The ARIA label for the blog posts pagination" }, "theme.blog.post.paginator.newerPost": { "message": "较新一篇", "description": "The blog post button label to navigate to the newer/previous post" }, "theme.blog.post.paginator.olderPost": { "message": "较旧一篇", "description": "The blog post button label to navigate to the older/next post" }, "theme.tags.tagsPageLink": { "message": "查看所有标签", "description": "The label of the link targeting the tag list page" }, "theme.colorToggle.ariaLabel.mode.system": { "message": "系统模式", "description": "The name for the system color mode" }, "theme.colorToggle.ariaLabel.mode.light": { "message": "浅色模式", "description": "The name for the light color mode" }, "theme.colorToggle.ariaLabel.mode.dark": { "message": "暗黑模式", "description": "The name for the dark color mode" }, "theme.colorToggle.ariaLabel": { "message": "切换浅色/暗黑模式（当前为{mode}）", "description": "The ARIA label for the color mode toggle" }, "theme.docs.breadcrumbs.navAriaLabel": { "message": "页面路径", "description": "The ARIA label for the breadcrumbs" }, "theme.docs.DocCard.categoryDescription.plurals": { "message": "{count} 个项目", "description": "The default description for a category card in the generated index about how many items this category includes" }, "theme.docs.paginator.navAriaLabel": { "message": "文件选项卡", "description": "The ARIA label for the docs pagination" }, "theme.docs.paginator.previous": { "message": "上一页", "description": "The label used to navigate to the previous doc" }, "theme.docs.paginator.next": { "message": "下一页", "description": "The label used to navigate to the next doc" }, "theme.docs.tagDocListPageTitle.nDocsTagged": { "message": "{count} 篇文档带有标签", "description": "Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.docs.tagDocListPageTitle": { "message": "{nDocsTagged}「{tagName}」", "description": "The title of the page for a docs tag" }, "theme.docs.versions.unreleasedVersionLabel": { "message": "此为 {siteTitle} {versionLabel} 版尚未发行的文档。", "description": "The label used to tell the user that he's browsing an unreleased doc version" }, "theme.docs.versions.unmaintainedVersionLabel": { "message": "此为 {siteTitle} {versionLabel} 版的文档，现已不再积极维护。", "description": "The label used to tell the user that he's browsing an unmaintained doc version" }, "theme.docs.versions.latestVersionSuggestionLabel": { "message": "最新的文档请参阅 {latestVersionLink} ({versionLabel})。", "description": "The label used to tell the user to check the latest version" }, "theme.docs.versions.latestVersionLinkLabel": { "message": "最新版本", "description": "The label used for the latest version suggestion link label" }, "theme.docs.versionBadge.label": { "message": "版本：{versionLabel}" }, "theme.common.editThisPage": { "message": "编辑此页", "description": "The link label to edit the current page" }, "theme.lastUpdated.atDate": { "message": "于 {date} ", "description": "The words used to describe on which date a page has been last updated" }, "theme.lastUpdated.byUser": { "message": "由 {user} ", "description": "The words used to describe by who the page has been last updated" }, "theme.lastUpdated.lastUpdatedAtBy": { "message": "最后{byUser}{atDate}更新", "description": "The sentence used to display when a page has been last updated, and by who" }, "theme.common.headingLinkTitle": { "message": "{heading}的直接链接", "description": "Title for link to heading" }, "theme.NotFound.title": { "message": "找不到页面", "description": "The title of the 404 page" }, "theme.navbar.mobileVersionsDropdown.label": { "message": "选择版本", "description": "The label for the navbar versions dropdown on mobile view" }, "theme.tags.tagsListLabel": { "message": "标签：", "description": "The label alongside a tag list" }, "theme.AnnouncementBar.closeButtonAriaLabel": { "message": "关闭", "description": "The ARIA label for close button of announcement bar" }, "theme.admonition.caution": { "message": "警告", "description": "The default label used for the Caution admonition (:::caution)" }, "theme.admonition.danger": { "message": "危险", "description": "The default label used for the Danger admonition (:::danger)" }, "theme.admonition.info": { "message": "信息", "description": "The default label used for the Info admonition (:::info)" }, "theme.admonition.note": { "message": "备注", "description": "The default label used for the Note admonition (:::note)" }, "theme.admonition.tip": { "message": "提示", "description": "The default label used for the Tip admonition (:::tip)" }, "theme.admonition.warning": { "message": "注意", "description": "The default label used for the Warning admonition (:::warning)" }, "theme.blog.sidebar.navAriaLabel": { "message": "最近博文导航", "description": "The ARIA label for recent posts in the blog sidebar" }, "theme.DocSidebarItem.expandCategoryAriaLabel": { "message": "展开侧边栏分类 '{label}'", "description": "The ARIA label to expand the sidebar category" }, "theme.DocSidebarItem.collapseCategoryAriaLabel": { "message": "折叠侧边栏分类 '{label}'", "description": "The ARIA label to collapse the sidebar category" }, "theme.IconExternalLink.ariaLabel": { "message": "(opens in new tab)", "description": "The ARIA label for the external link icon" }, "theme.NavBar.navAriaLabel": { "message": "主导航", "description": "The ARIA label for the main navigation" }, "theme.NotFound.p1": { "message": "我们找不到您要找的页面。", "description": "The first paragraph of the 404 page" }, "theme.NotFound.p2": { "message": "请联系原始链接来源网站的所有者，并告知他们链接已损坏。", "description": "The 2nd paragraph of the 404 page" }, "theme.navbar.mobileLanguageDropdown.label": { "message": "选择语言", "description": "The label for the mobile language switcher dropdown" }, "theme.TOCCollapsible.toggleButtonLabel": { "message": "本页总览", "description": "The label used by the button on the collapsible TOC component" }, "theme.blog.post.readMore": { "message": "阅读更多", "description": "The label used in blog post item excerpts to link to full blog posts" }, "theme.blog.post.readMoreLabel": { "message": "阅读 {title} 的全文", "description": "The ARIA label for the link to full blog posts from excerpts" }, "theme.blog.post.readingTime.plurals": { "message": "阅读需 {readingTime} 分钟", "description": "Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.CodeBlock.wordWrapToggle": { "message": "切换自动换行", "description": "The title attribute for toggle word wrapping button of code block lines" }, "theme.CodeBlock.copy": { "message": "复制", "description": "The copy button label on code blocks" }, "theme.CodeBlock.copied": { "message": "复制成功", "description": "The copied button label on code blocks" }, "theme.CodeBlock.copyButtonAriaLabel": { "message": "复制代码到剪贴板", "description": "The ARIA label for copy code blocks button" }, "theme.docs.breadcrumbs.home": { "message": "主页面", "description": "The ARIA label for the home page in the breadcrumbs" }, "theme.docs.sidebar.navAriaLabel": { "message": "文档侧边栏", "description": "The ARIA label for the sidebar navigation" }, "theme.docs.sidebar.collapseButtonTitle": { "message": "收起侧边栏", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.collapseButtonAriaLabel": { "message": "收起侧边栏", "description": "The title attribute for collapse button of doc sidebar" }, "theme.docs.sidebar.closeSidebarButtonAriaLabel": { "message": "关闭导航栏", "description": "The ARIA label for close button of mobile sidebar" }, "theme.navbar.mobileSidebarSecondaryMenu.backButtonLabel": { "message": "← 回到主菜单", "description": "The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)" }, "theme.docs.sidebar.toggleSidebarButtonAriaLabel": { "message": "切换导航栏", "description": "The ARIA label for hamburger menu button of mobile navigation" }, "theme.docs.sidebar.expandButtonTitle": { "message": "展开侧边栏", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.docs.sidebar.expandButtonAriaLabel": { "message": "展开侧边栏", "description": "The ARIA label and title attribute for expand button of doc sidebar" }, "theme.navbar.mobileDropdown.collapseButton.expandAriaLabel": { "message": "展开下拉菜单", "description": "The ARIA label of the button to expand the mobile dropdown navbar item" }, "theme.navbar.mobileDropdown.collapseButton.collapseAriaLabel": { "message": "折叠下拉菜单", "description": "The ARIA label of the button to collapse the mobile dropdown navbar item" }, "theme.blog.post.plurals": { "message": "{count} 篇博文", "description": "Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)" }, "theme.blog.tagTitle": { "message": "{nPosts} 含有标签「{tagName}」", "description": "The title of the page for a blog tag" }, "theme.blog.author.pageTitle": { "message": "{authorName} - {nPosts}", "description": "The title of the page for a blog author" }, "theme.blog.authorsList.pageTitle": { "message": "作者", "description": "The title of the authors page" }, "theme.blog.authorsList.viewAll": { "message": "查看所有作者", "description": "The label of the link targeting the blog authors page" }, "theme.blog.author.noPosts": { "message": "该作者尚未撰写任何文章。", "description": "The text for authors with 0 blog post" }, "theme.contentVisibility.unlistedBanner.title": { "message": "未列出页", "description": "The unlisted content banner title" }, "theme.contentVisibility.unlistedBanner.message": { "message": "此页面未列出。搜索引擎不会对其索引，只有拥有直接链接的用户才能访问。", "description": "The unlisted content banner message" }, "theme.contentVisibility.draftBanner.title": { "message": "草稿页", "description": "The draft content banner title" }, "theme.contentVisibility.draftBanner.message": { "message": "此页面是草稿，仅在开发环境中可见，不会包含在正式版本中。", "description": "The draft content banner message" }, "theme.ErrorPageContent.tryAgain": { "message": "重试", "description": "The label of the button to try again rendering when the React error boundary captures an error" }, "theme.common.skipToMainContent": { "message": "跳到主要内容", "description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation" }, "theme.tags.tagsPageTitle": { "message": "标签", "description": "The title of the tag list page" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-blog/options.json ================================================ { "title": { "message": "博客", "description": "The title for the blog used in SEO" }, "description": { "message": "博客", "description": "The description for the blog used in SEO" }, "sidebar.title": { "message": "所有文章", "description": "The label for the left sidebar" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/current.json ================================================ { "version.label": { "message": "4.0.0", "description": "The label for version current" }, "sidebar.tutorialSidebar.category.Tutorial - Basics": { "message": "Tutorial - Basics", "description": "The label for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Basics.link.generated-index.description": { "message": "5 minutes to learn the most important Docusaurus concepts.", "description": "The generated-index page description for category Tutorial - Basics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Tutorial - Extras": { "message": "Tutorial - Extras", "description": "The label for category Tutorial - Extras in sidebar tutorialSidebar" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-2.json ================================================ { "version.label": { "message": "2.17.0", "description": "The label for version 2" }, "sidebar.tutorialSidebar.category.Using Helm": { "message": "使用 Helm", "description": "The label for category Using Helm in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm 命令", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Charts": { "message": "Charts", "description": "The label for category Charts in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Developing Templates": { "message": "开发模板", "description": "The label for category Developing Templates in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "最佳实践", "description": "The label for category Best Practices in sidebar tutorialSidebar" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/conventions.md ================================================ --- title: 一般惯例 description: chart 的一般惯例。 sidebar_position: 1 --- 最佳实践指南的这部分介绍 chart 的一般惯例。 ## Chart 名称 chart 名称必须是小写字母和数字。单词之间 _可以_ 使用横杠（`-`）分隔： 示例： ``` drupal nginx-lego aws-cluster-autoscaler ``` chart 名称中不能使用大写字母或下划线，也不能使用点号。 ## 版本号 Helm 尽可能使用 [SemVer 2](https://semver.org) 来表示版本号。（注意 Docker 镜像的 tag 不一定遵循 SemVer，因此被视为该规则的例外。） 当 SemVer 版本存储在 Kubernetes 标签中时，我们通常把 `+` 字符改成 `_`，因为标签不允许使用 `+` 作为值。 ## 格式化 YAML YAML 文件应该使用 _两个空格_ 缩进（绝不要使用 tab 键）。 ## Helm 和 Chart 的用法 以下是 _Helm_ 和 _helm_ 的几个惯用方法： - _Helm_ 是指整个项目 - `helm` 是指客户端命令 - `chart` 不是专有名词，不需要首字母大写 - 但 `Chart.yaml` 需要首字母大写，因为文件名区分大小写 若有疑问，使用 _Helm_（大写 'H'）。 ## Chart 模板和 namespace 避免在 chart 模板的 `metadata` 部分定义 `namespace` 属性。渲染后的模板应该在调用 Kubernetes 客户端时通过 `--namespace` 参数指定要部署到的 namespace。Helm 会原样渲染模板并发送给 Kubernetes 客户端，无论是 Helm 本身还是其他程序（如 kubectl、flux、spinnaker 等）。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: 自定义资源定义 description: 如何创建和使用 CRD。 sidebar_position: 7 --- 最佳实践指南的这部分介绍如何创建和使用自定义资源定义（CRD）对象。 使用自定义资源定义（CRD）时，需要区分两个不同的部分： - CRD 的声明。这是一个 kind 为 `CustomResourceDefinition` 的 YAML 文件。 - 使用 CRD 的资源。假设 CRD 定义了 `foo.example.com/v1`，那么任何 `apiVersion: example.com/v1` 且 kind 为 `Foo` 的资源都是使用该 CRD 的资源。 ## 在使用资源之前安装 CRD 声明 Helm 被优化为尽可能快地将尽可能多的资源加载到 Kubernetes 中。按照设计，Kubernetes 可以获取一整套清单并将其全部上线（这称为协调循环）。 但 CRD 有所不同。 对于 CRD，声明必须在使用该 CRD 类型的任何资源之前完成注册。而注册过程有时需要几秒钟。 ### 方法1：让 `helm` 帮你完成 随着 Helm 3 的到来，我们移除了旧的 `crd-install` 钩子，采用了更简单的方法。现在可以在 chart 中创建一个名为 `crds` 的特殊目录来存放 CRD。这些 CRD 不会被模板化，但在运行 `helm install` 时会默认安装。如果 CRD 已存在，会显示警告并跳过。如果希望跳过 CRD 安装步骤，可以使用 `--skip-crds` 参数。 #### 注意事项（和说明） 目前不支持使用 Helm 升级或删除 CRD。由于存在意外数据丢失的风险，这是经过多次社区讨论后做出的明确决定。目前社区对于如何处理 CRD 及其生命周期还没有达成共识。随着这一过程的演进，Helm 将逐步支持这些用例。 `helm install` 和 `helm upgrade` 的 `--dry-run` 参数目前不支持 CRD。"模拟运行"的目的是验证 chart 输出在发送到服务器时是否真正有效。但 CRD 会修改服务器的行为。Helm 无法在模拟运行时安装 CRD，因此 discovery 客户端无法识别该自定义资源（CR），导致验证失败。你可以将 CRD 移动到单独的 chart 中，或者使用 `helm template` 代替。 在讨论 CRD 支持时，另一个需要考虑的重要问题是模板渲染的处理方式。Helm 2 中使用 `crd-install` 方法的一个明显缺点是，由于 API 可用性的变化，无法正确验证 chart（CRD 实际上是向 Kubernetes 集群添加了另一个可用的 API）。如果 chart 安装了 CRD，`helm` 就不再拥有一组有效的 API 版本可供使用。这也是从 CRD 移除模板支持的原因。通过新的 `crds` 目录安装 CRD 的方法，我们现在可以确保 `helm` 拥有关于集群当前状态的完全有效的信息。 ### 方法2：独立 chart 另一种方法是将 CRD 定义放在一个 chart 中，然后将使用该 CRD 的所有资源放在 _另一个_ chart 中。 这种方法需要分别安装每个 chart。但是，对于拥有集群管理员访问权限的集群运维人员来说，这种工作流可能更有用。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: 依赖 description: 涵盖 chart 依赖的最佳实践 sidebar_position: 4 --- 本节介绍在 `Chart.yaml` 中声明 `dependencies` 的最佳实践。 ## 版本 尽可能使用版本范围而不是固定版本。建议默认使用补丁级别的版本匹配： ```yaml version: ~1.2.3 ``` 这会匹配 `1.2.3` 以及该版本的任何补丁。也就是说，`~1.2.3` 相当于 `>= 1.2.3, < 1.3.0`。 完整的版本匹配语法请参阅 [semver 文档](https://github.com/Masterminds/semver#checking-version-constraints)。 ### 预发布版本 上述版本约束不会匹配预发布版本。例如，`version: ~1.2.3` 会匹配 `version: ~1.2.4`，但不会匹配 `version: ~1.2.3-1`。 以下写法可同时匹配预发布版本和补丁版本： ```yaml version: ~1.2.3-0 ``` ### 仓库 URL 尽可能使用 `https://` 仓库 URL，其次是 `http://` URL。 如果仓库已添加到仓库索引文件中，可以使用仓库名称作为 URL 的别名。使用 `alias:` 或 `@` 后跟仓库名称。 文件 URL（`file://...`）被视为一种"特例"，用于通过固定部署流水线组装的 chart。 使用[下载器插件](../topics/plugins.md#downloader-plugins)时，URL 方案将特定于该插件。注意，chart 的用户需要安装支持该方案的插件才能更新或构建依赖。 当 `repository` 字段为空时，Helm 无法执行依赖管理操作。此时 Helm 会假定依赖位于 `charts` 文件夹的子目录中，目录名称与依赖的 `name` 属性相同。 ## 条件和标签 条件或标签应添加到任何**可选**的依赖中。注意，`condition` 的默认值为 `true`。 条件的首选格式是： ```yaml condition: somechart.enabled ``` 其中 `somechart` 是依赖 chart 的名称。 当多个子 chart（依赖）共同提供可选或可替换的功能时，这些 chart 应共享相同的标签。 例如，如果 `nginx` 和 `memcached` 共同为主应用提供性能优化功能，且启用该功能时需要两者同时存在，则它们都应包含如下标签： ```yaml tags: - webaccelerator ``` 这样用户就可以通过一个标签来启用或禁用该功能。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/index.mdx ================================================ --- title: 最佳实践 sidebar: true sidebar_position: 4 --- # Chart 最佳实践指南 该指南覆盖了 Helm 团队能考虑到的创建 Chart 的最佳实践。 聚焦于 Chart 应该如何构造。 我们首要关注 Chart 公开部署的最佳实践。 我们知道很多 Chart 只用于内部使用，而且这些 Chart 作者会越过这些建议使用他们的内部优化。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/labels.md ================================================ --- title: 标签和注释 description: 介绍在 chart 中使用标签和注释的最佳实践。 sidebar_position: 5 --- 最佳实践指南的这部分介绍在 chart 中使用标签和注释的最佳实践。 ## 是标签还是注释？ 满足以下条件时，元数据项应该使用标签： - Kubernetes 用它来识别资源 - 便于运维人员查询系统 例如，建议使用 `helm.sh/chart: NAME-VERSION` 作为标签，这样运维人员可以方便地找到特定 chart 的所有实例。 如果元数据不用于查询，应该设置为注释。 Helm hook 始终是注释。 ## 标准标签 下表定义了 Helm chart 使用的通用标签。Helm 本身不强制要求任何特定标签。标记为 REC 的是推荐标签，**应该** 添加到 chart 中以保持全局一致性。标记为 OPT 的是可选标签，虽然常用且符合惯例，但在实际操作中并不经常依赖。 名称|状态|描述 ----|----|---- `app.kubernetes.io/name` | REC | 应用名称，反映整个应用。通常使用 `{{ template "name" . }}`。许多 Kubernetes 清单会使用这个标签，它不是 Helm 特有的。 `helm.sh/chart` | REC | chart 的名称和版本：`{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`。 `app.kubernetes.io/managed-by` | REC | 应始终设置为 `{{ .Release.Service }}`。用于查找所有由 Helm 管理的资源。 `app.kubernetes.io/instance` | REC | 应设置为 `{{ .Release.Name }}`。有助于区分同一应用的不同实例。 `app.kubernetes.io/version` | OPT | 应用版本，可设置为 `{{ .Chart.AppVersion }}`。 `app.kubernetes.io/component` | OPT | 用于标记组件在应用中扮演的角色。例如 `app.kubernetes.io/component: frontend`。 `app.kubernetes.io/part-of` | OPT | 当多个 chart 或软件组合成一个应用时使用。例如，应用程序和数据库共同构建一个网站。可设置为顶层支撑应用。 关于以 `app.kubernetes.io` 为前缀的 Kubernetes 标签的更多信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pod 和 PodTemplate description: 讨论在 chart 清单中格式化 Pod 和 PodTemplate 部分。 sidebar_position: 6 --- 最佳实践指南的这部分讨论在 chart 清单中格式化 Pod 和 PodTemplate 部分。 以下（非详尽的）资源列表使用 PodTemplate： - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## 镜像 容器镜像应该使用固定的 tag 或镜像的 SHA。不应该使用 `latest`、`head`、`canary` 等标签或其他被设计为"浮动的"标签。 镜像**可以**定义在 `values.yaml` 文件中，便于切换镜像。 ```yaml image: {{ .Values.redisImage | quote }} ``` 镜像和 tag **可以**在 `values.yaml` 中定义为两个独立的字段： ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## 镜像拉取策略 `helm create` 通过以下方式在 `deployment.yaml` 中将 `imagePullPolicy` 默认设置为 `IfNotPresent`： ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` 以及 `values.yaml`： ```yaml image: pullPolicy: IfNotPresent ``` 类似地，如果 Kubernetes 根本没有定义，默认会将 `imagePullPolicy` 设置为 `IfNotPresent`。如果想设置一个值而不是 `IfNotPresent`，只需在 `values.yaml` 中更新为需要的值即可。 ## PodTemplate 应该声明选择器 所有的 PodTemplate 部分应该指定一个 selector。例如： ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` 这是一个很好的实践，因为它建立了资源集合和 Pod 之间的关系。 但这一点对于 Deployment 等资源来说更加重要。如果没有指定选择器，系统会使用**所有**标签来匹配 Pod，当你使用了会变化的标签（比如版本或发布日期）时，这会导致匹配失败。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/rbac.md ================================================ --- title: 基于角色的访问控制 description: 讨论在 chart 清单中创建和格式化 RBAC 资源。 sidebar_position: 8 --- 最佳实践指南的这部分讨论在 chart 清单中创建和格式化 RBAC 资源。 RBAC 资源有： - ServiceAccount（namespaced） - Role（namespaced） - ClusterRole - RoleBinding（namespaced） - ClusterRoleBinding ## YAML 配置 RBAC 和 ServiceAccount 配置应该使用独立的 key。它们是独立的内容。在 YAML 中将这两个概念分开可以消除歧义，使其更加清晰。 ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` 这个结构可以在更复杂的、需要多个 ServiceAccount 的 chart 中扩展。 ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC 资源应该默认创建 `rbac.create` 应该是布尔值，用于控制 RBAC 资源是否被创建。默认是 `true`。用户想自己管理 RBAC 访问控制时可以设置为 `false`（这种情况请参阅下文）。 ## 使用 RBAC 资源 `serviceAccount.name` 要设置为由 chart 创建的访问控制资源的 ServiceAccount 的名称。如果 `serviceAccount.create` 是 true，则使用该名称的 ServiceAccount 会被创建。如果没有设置名称，则会使用 `fullname` 模板生成一个名称。如果 `serviceAccount.create` 是 false，则不会被创建，但仍然会与相同的资源关联，以便后续手动创建的引用它的 RBAC 资源可以正常工作。如果 `serviceAccount.create` 是 false 且没有指定名称，会使用默认的 ServiceAccount。 以下辅助模板可用于 ServiceAccount。 ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/templates.md ================================================ --- title: 模板 description: 进一步了解围绕模板的最佳实践。 sidebar_position: 3 --- 最佳实践指南的这部分聚焦于模板。 ## `templates/` 结构 `templates/` 目录结构应该如下： - 如果生成 YAML 输出，模板文件应该有扩展名`.yaml`。 `.tpl` 扩展名可用于不生成格式化内容的模板文件。 - 模板文件名称应该使用横杠符号(`my-example-configmap.yaml`)，不用驼峰记法。 - 每个资源的定义应该在它自己的模板文件中。 - 模板文件的名称应该反映名称中的资源类型。比如：`foo-pod.yaml`， `bar-svc.yaml` ## 定义模板的名称 定义的模板（在 `{{ define }}` 命令中定义的模板）是可全局访问的。这就意味着 chart 和所有的子 chart 都可以访问用 `{{ define }}` 创建的所有模板。 因此， _所有定义的模板名称应该被命名空间化。_ 正确的： ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` 不正确的： ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` 强烈建议通过 `helm create` 命令创建新 chart，因为模板名称是根据此最佳实践自动定义的。 ## 格式化模板 模板应该使用两个 _空格_ 缩进（永远不要用tab）。 模板命令的大括号前后应该使用空格： 正确的： ```yaml {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` 不正确的： ```yaml {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` 模板应尽可能裁剪空格： ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` 块（例如控制结构）可以缩进表示模板代码流。 ```yaml {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` 然而，因为 YAML 是面向空格的语言，代码缩进通常不可能遵守规范。 ## 生成模板中的空格 最好在生成的模板中将空格量保持在最小值。尤其是大量的空行不应该相邻出现。但偶尔有空行（尤其在逻辑块之间）是没问题的。 这样是最好的： ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 这样也OK： ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` 但避免这样： ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## 注释 (YAML 注释 vs. 模板注释) YAML 和 Helm 模板都有注释标记符。 YAML 注释： ```yaml # This is a comment type: sprocket ``` 模板注释： ```yaml {{- /* This is a comment. */}} type: frobnitz ``` 描述模板的特性时应当使用模板注释，比如解释一个定义的模板： ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` 在模板中，当有益于 Helm 用户（可能）在调试时查看注释，可以使用 YAML 注释。 ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` 以上注释在用户执行`helm install --debug`时是可见的，而在`{{- /* */}}`部分指定注释不会显示。 注意不要在包含某些模板函数可能需要的 Helm 值的模板部分添加 `#` YAML 注释。 例如，如果在上面的示例中引入了 `required` 函数，并且 `maxMem` 未设置，那么 `#` YAML 注释将导致渲染错误。 正确做法：`helm template` 不会渲染此代码块 ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` 错误做法：`helm template` 返回 `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` 查看[调试模板](/chart_template_guide/debugging.md)了解更多关于 YAML 注释如何被保留的示例。 ## 在模板和模板输出中使用JSON YAML 是 JSON 的超集。在某些情况下，使用 JSON 语法比其他 YAML 表示更具可读性。 比如，这个 YAML 更接近表示列表的普通 YAML 方法： ```yaml arguments: - "--dirname" - "/foo" ``` 但是折叠成JSON列表样式时会更易阅读: ```yaml arguments: ["--dirname", "/foo"] ``` 使用 JSON 可以很好地提高易读性。然而，JSON 语法不应用于表示更复杂的结构。 在处理嵌入到 YAML 中的纯 JSON 时（比如初始化容器配置），使用 JSON 格式当然是最合适的。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: 聚焦于如何构建和使用你的 values。 sidebar_position: 2 --- 最佳实践指南的这部分介绍 values 的使用。本节提供关于如何构建和使用 values 的建议，重点讨论 chart 的 `values.yaml` 文件设计。 ## 命名规范 变量名称应以小写字母开头，单词之间使用驼峰命名法： 正确： ```yaml chicken: true chickenNoodleSoup: true ``` 错误： ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` 注意 Helm 的所有内置变量都以大写字母开头，以便与用户定义的 values 区分：`.Release.Name`、`.Capabilities.KubeVersion`。 ## 扁平或嵌套的 Values YAML 是一种灵活的格式，值可以嵌套很深，也可以是扁平的。 嵌套： ```yaml server: name: nginx port: 80 ``` 扁平： ```yaml serverName: nginx serverPort: 80 ``` 大多数情况下，扁平结构优于嵌套结构。原因是对模板开发者和用户来说更简单。 为了保证安全性，嵌套值的每一层都必须检查： ```yaml {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` 每一层嵌套都必须进行存在性检查。但扁平配置可以跳过这些检查，使模板更易于阅读和使用。 ```yaml {{ default "none" .Values.serverName }} ``` 当存在大量相关变量，且其中至少有一个是必填的时，可以使用嵌套值来提高可读性。 ## 明确类型 YAML 的类型强制转换规则有时不太直观。例如，`foo: false` 和 `foo: "false"` 是不同的。大整数如 `foo: 12345678` 在某些情况下会被转换成科学计数法。 避免类型转换错误最简单的方法是：字符串显式声明，其他类型隐式声明。简而言之，_给所有字符串加引号_。 通常，为了避免整数转换问题，将整数也存储为字符串是个好做法，然后在模板中使用 `{{ int $value }}` 将字符串转回整数。 大多数情况下，显式类型标记会被正确识别，因此 `foo: !!string 1234` 会将 `1234` 当作字符串处理。_但是_，YAML 解析器会消耗这些标记，因此类型数据在一次解析后会丢失。 ## 考虑用户如何使用 Values values 有三种潜在来源： - chart 的 `values.yaml` 文件 - 由 `helm install -f` 或 `helm upgrade -f` 提供的 values 文件 - 执行 `helm install` 或 `helm upgrade` 时通过 `--set` 或 `--set-string` 参数传递的值 设计 values 结构时，要记住 chart 用户可能会通过 `-f` 参数或 `--set` 选项覆盖它们。 由于 `--set` 的表达能力更有限，编写 `values.yaml` 文件的第一条准则是 _确保它易于被 `--set` 覆盖_。 因此，使用 map 来构建 values 文件通常更好。 难以配合 `--set` 使用： ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` 上述结构在 Helm `<=2.4` 中无法配合 `--set` 表达。在 Helm 2.5 中，访问 foo 的端口是 `--set servers[0].port=80`。这不仅让用户更难理解，而且如果以后 `servers` 的顺序发生变化，很容易出错。 易于使用： ```yaml servers: foo: port: 80 bar: port: 81 ``` 这样访问 foo 的端口就很明显：`--set servers.foo.port=80`。 ## 给 `values.yaml` 写文档 `values.yaml` 中定义的每个属性都应该有文档说明。文档字符串应该以它描述的属性名称开头，然后至少给出一句描述。 错误： ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` 正确： ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` 在注释开头写上参数名称，便于整理文档，也能让文档工具可靠地将文档字符串与其描述的参数关联起来。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: 在模板内部访问文件 description: 如何从模板中访问文件 sidebar_position: 10 --- 在上一节中，我们介绍了创建和访问命名模板的几种方法。这使得在模板之间相互导入变得很容易。但有时你需要导入的是一个**非模板文件**，并直接注入其内容，而不经过模板渲染引擎处理。 Helm 通过 `.Files` 对象提供对文件的访问。不过在使用模板示例之前，有几点需要注意： - 可以在 chart 中添加额外的文件，这些文件会被一起打包。但要注意，由于 Kubernetes 对象的存储限制，chart 大小必须小于 1M。 - 出于安全考虑，某些文件无法通过 `.Files` 对象访问： - 无法访问 `templates/` 目录中的文件。 - 无法访问被 `.helmignore` 排除的文件。 - 无法访问 Helm 应用 [子 chart](./subcharts_and_globals.md) 之外的文件，包括父 chart 中的文件。 - chart 不保留 UNIX 模式信息，因此文件级权限不会影响 `.Files` 对象对文件的可用性。 - [基本示例](#基本示例) - [路径辅助函数](#路径辅助函数) - [Glob 模式](#glob-模式) - [ConfigMap 和 Secret 实用函数](#configmap-和-secret-实用函数) - [编码](#编码) - [逐行读取](#逐行读取) ## 基本示例 了解了这些注意事项后，让我们编写一个模板，将三个文件读取到 ConfigMap 中。首先，在 chart 中添加三个文件，直接放在 `mychart/` 目录下。 `config1.toml`： ```toml message = "Hello from config 1" ``` `config2.toml`： ```toml message = "This is config 2" ``` `config3.toml`： ```toml message = "Goodbye from config 3" ``` 每个文件都是简单的 TOML 文件（类似于早期 Windows 的 INI 文件）。我们知道这些文件的名称，因此可以使用 `range` 函数遍历它们，并将内容注入到 ConfigMap 中。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` 这个 ConfigMap 使用了前面章节讨论过的技术。例如，我们创建了一个 `$files` 变量来保存对 `.Files` 对象的引用，并使用 `tuple` 函数创建了要遍历的文件列表。然后打印每个文件名（`{{ . }}: |-`），接着通过 `{{ $files.Get . }}` 打印文件内容。 执行这个模板会生成一个包含所有三个文件内容的 ConfigMap： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## 路径辅助函数 处理文件时，对文件路径执行一些标准操作会很有用。为此，Helm 从 Go 的 [path](https://golang.org/pkg/path/) 包中导入了一些函数供你使用。这些函数使用与 Go 包相同的名称，但首字母小写。例如 `Base` 变成 `base`，以此类推。 导入的函数包括： - Base - Dir - Ext - IsAbs - Clean ## Glob 模式 随着 chart 规模增长，你可能需要更好地组织文件。为此我们提供了 `Files.Glob(pattern string)` 方法，它支持使用 [glob 模式](https://godoc.org/github.com/gobwas/glob) 灵活地提取特定文件。 `.Glob` 返回一个 `Files` 类型，因此你可以在返回的对象上调用任何 `Files` 方法。 例如，假设有以下目录结构： ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` 使用 Glob 有多种方式： ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` 或者 ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap 和 Secret 实用函数 （Helm 2.0.2 及更高版本可用） 将文件内容放入 ConfigMap 和 Secret 以便在运行时挂载到 Pod 是很常见的需求。为此，我们在 `Files` 类型上提供了一些实用方法。 结合 `Glob` 方法使用这些方法可以更好地组织文件。 使用上面 [Glob 模式](#glob-模式) 示例中的目录结构： ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## 编码 你可以导入文件并使用 base64 编码，以确保传输成功： ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` 上面的模板使用之前的 `config1.toml` 文件并对其进行编码： ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## 逐行读取 有时需要在模板中逐行访问文件内容。我们为此提供了便捷的 `Lines` 方法。 你可以使用 `range` 函数遍历 `Lines`： ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` 在 `helm install` 过程中无法将 chart 外部的文件传入。因此，如果需要用户提供数据，必须使用 `helm install -f` 或 `helm install --set` 加载。 本节总结了编写 Helm 模板所需工具和技术的深入讨论。下一节我们将介绍如何使用特殊文件 `templates/NOTES.txt` 向 chart 用户发送安装后说明。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: 内置对象 description: 模板可用的内置对象 sidebar_position: 3 --- 对象可以通过模板引擎传递到模板中，你的代码也可以传递对象（使用 `with` 和 `range` 语句时会看到示例）。还有几种方式可以在模板中创建新对象，比如后面会介绍的 `tuple` 函数。 对象可以是非常简单的，仅有一个值；也可以包含其他对象或方法。比如，`Release` 对象包含多个子对象（如 `Release.Name`），而 `Files` 对象则有一组方法。 在上一节中，我们用 `{{ .Release.Name }}` 在模板中插入 release 名称。`Release` 是你可以在模板中访问的顶层对象之一。 - `Release`：该对象描述 release 本身，包含以下子对象： - `Release.Name`：release 名称 - `Release.Namespace`：release 的命名空间（如果 manifest 没有覆盖的话） - `Release.IsUpgrade`：如果当前操作是升级或回滚，该值为 `true` - `Release.IsInstall`：如果当前操作是安装，该值为 `true` - `Release.Revision`：此次修订的版本号。安装时为 1，每次升级或回滚都会自增 - `Release.Service`：渲染当前模板的服务名称，在 Helm 中始终是 `Helm` - `Values`：从 `values.yaml` 文件和用户提供的文件传入模板的值，默认为空。 - `Chart`：`Chart.yaml` 文件的内容。该文件中的所有数据都可以访问。例如 `{{ .Chart.Name }}-{{ .Chart.Version }}` 会输出 `mychart-0.1.0` - 在 [Chart 指南](/topics/charts.md#the-chartyaml-file) 中列出了可用属性 - `Subcharts`：提供对子 chart 作用域（.Values、.Charts、.Releases 等）的访问。例如 `.Subcharts.mySubChart.myValue` 可以访问 `mySubChart` chart 中的 `myValue`。 - `Files`：在 chart 中提供访问所有非特殊文件的对象。你不能使用它访问模板，只能访问其他文件。请查看 [文件访问](./accessing_files.md) 部分了解更多信息。 - `Files.Get` 通过文件名获取文件的方法（`.Files.Get config.ini`） - `Files.GetBytes` 以字节数组而非字符串形式获取文件内容的方法，对图片之类的文件很有用 - `Files.Glob` 用给定的 shell glob 模式匹配文件名并返回文件列表的方法 - `Files.Lines` 逐行读取文件内容的方法，迭代文件中每一行时很有用 - `Files.AsSecrets` 以 Base64 编码字符串形式返回文件内容的方法 - `Files.AsConfig` 以 YAML 格式返回文件内容的方法 - `Capabilities`：提供关于 Kubernetes 集群支持功能的信息 - `Capabilities.APIVersions` 是一个版本集合 - `Capabilities.APIVersions.Has $version` 表示集群中某个版本（如 `batch/v1`）或资源（如 `apps/v1/Deployment`）是否可用 - `Capabilities.KubeVersion` 和 `Capabilities.KubeVersion.Version` 是 Kubernetes 版本号 - `Capabilities.KubeVersion.Major` Kubernetes 主版本号 - `Capabilities.KubeVersion.Minor` Kubernetes 次版本号 - `Capabilities.HelmVersion` 包含 Helm 版本详细信息的对象，与 `helm version` 的输出一致 - `Capabilities.HelmVersion.Version` 当前 Helm 版本（语义化版本格式） - `Capabilities.HelmVersion.GitCommit` Helm 的 git sha1 值 - `Capabilities.HelmVersion.GitTreeState` Helm git 树的状态 - `Capabilities.HelmVersion.GoVersion` 使用的 Go 编译器版本 - `Template`：包含当前正在执行的模板信息 - `Template.Name`：当前模板的命名空间文件路径（例如 `mychart/templates/mytemplate.yaml`） - `Template.BasePath`：当前 chart 模板目录的路径（例如 `mychart/templates`） 内置对象的名称都以大写字母开头，这符合 Go 的命名惯例。当你创建自己的名称时，可以按照团队约定自由设置。就像很多你在 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中看到的 chart，其团队选择使用首字母小写将本地名称与内置对象区分开，本指南中我们也遵循该惯例。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: 流控制 description: 模板中流结构的快速概述 sidebar_position: 7 --- 控制结构（在模板语言中称为"actions"）为模板作者提供了控制模板生成流程的能力。 Helm的模板语言提供了以下控制结构： - `if`/`else`， 用来创建条件语句 - `with`， 用来指定范围 - `range`， 提供"for each"类型的循环 除了这些之外，还提供了一些声明和使用命名模板的关键字： - `define` 在模板中声明一个新的命名模板 - `template` 导入一个命名模板 - `block` 声明一种特殊的可填充的模板块 本节我们会讨论 `if`、`with` 和 `range`。其他内容会在本指南的“命名模板”部分说明。 ## If/Else 第一个控制结构是在按照条件在一个模板中包含一个块文本。即`if`/`else`块。 基本的条件结构看起来像这样： ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` 注意我们讨论的是 _管道_ 而不是值。这样做的原因是要清楚地说明控制结构可以执行整个管道，而不仅仅是计算一个值。 如果是以下值时，管道会被设置为 _false_： - 布尔false - 数字0 - 空字符串 - `nil` (空或null) - 空集合(`map`, `slice`, `tuple`, `dict`, `array`) 在所有其他条件下，条件都为true。 让我们先在ConfigMap 中添加一个简单的条件。如果饮品是coffee会添加另一个配置： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` 由于我们在最后一个例子中注释了`drink: coffee`，输出中就不会包含`mug: "true"`标识。但如果将这行添加到`values.yaml` 文件中，输入就会是这样： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## 控制空格 查看条件时，我们需要快速了解一下模板中控制空白的方式，格式化之前的例子，使其更易于阅读： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` 初始情况下，看起来没问题。但是如果通过模板引擎运行时，我们将得到一个不幸的结果： ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` 发生了啥？因为空格导致生成了错误的YAML。 ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug`的缩进是不对的。取消缩进重新执行一下： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` 这个就得到了合法的YAML，但是看起来还是有点滑稽： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` 注意在YAML中有一个空行，为什么？当模板引擎运行时，它 _移除了_ `{{` 和 `}}` 里面的内容，但是留下的空白完全保持原样。 YAML认为空白是有意义的，因此管理空白变得很重要。幸运的是，Helm模板有些工具可以处理此类问题。 首先，模板声明的大括号语法可以通过特殊的字符修改，并通知模板引擎取消空白。`{{- `(包括添加的横杠和空格)表示向左删除空白， 而` -}}`表示右边的空格应该被去掉。 _注意！换行符也是空白字符！_ > 要确保`-`和其他命令之间有一个空格。 > `{{- 3 }}` 表示“删除左边空格并打印3”，而`{{-3 }}`表示“打印-3”。 使用这个语法，我们就可修改我们的模板，去掉新加的空白行： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` 只是为了把这一点搞清楚，我们来调整上述内容，用一个`*`来代替每个遵循此规则被删除的空白， 在行尾的`*`表示删除新行的字符： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` 记住这一点，我们可以通过Helm运行模板并查看结果： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` 要注意这个删除字符的更改，很容易意外地出现情况： ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` 这样会变成`food: "PIZZA"mug:"true"`，因为这把两边的新行都删除了。 > 关于模板中的空白控制，请查看[官方Go模板文档](https://godoc.org/text/template) 最终，有时候告诉模板系统如何缩进会更容易，而不是试图控制模板指令间的间距。因此，你有时会发现使用 `indent` 函数（`{{ indent 2 "mug:true" }}`）会很有用。 ## 使用 `with` 修改作用域 下一个控制结构是`with`操作。这个用来控制变量范围。回想一下，`.`是对 _当前作用域_ 的引用。因此 `.Values`就是告诉模板在当前作用域查找`Values`对象。 `with`的语法与`if`语句类似： ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` 作用域可以被改变。`with`允许你为特定对象设定当前作用域(`.`)。比如，我们已经在使用`.Values.favorite`。 修改ConfigMap 中的`.`的作用域指向`.Values.favorite`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` 注意我们从之前的练习中移除了`if`条件，因为现在不需要了——`with`后面的块只有在 `PIPELINE` 的值不为空时才会执行。 注意现在我们可以引用`.drink`和`.food`了，而不必限定他们。因为`with`语句设置了`.`指向`.Values.favorite`。 `.`被重置为`{{ end }}`之后的上一个作用域。 但是这里有个注意事项，在限定的作用域内，无法使用`.`访问父作用域的对象。错误示例如下： ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` 这样会报错因为`Release.Name`不在`.`限定的作用域内。但是如果对调最后两行就是正常的， 因为在`{{ end }}`之后作用域被重置了。 ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` 或者，我们可以使用`$`从父作用域中访问`Release.Name`对象。当模板开始执行后`$`会被映射到根作用域，且执行过程中不会更改。 下面这种方式也可以正常工作： ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` 在介绍了`range`之后，我们会看看模板变量，提供了上述作用域问题的另一种解决方案。 ## 使用`range`操作循环 很多编程语言支持使用`for`循环，`foreach`循环，或者类似的方法机制。 在Helm的模板语言中，在一个集合中迭代的方式是使用`range`操作符。 开始之前，我们先在`values.yaml`文件添加一个披萨的配料列表： ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` 现在我们有了一个 `pizzaToppings` 列表（模板中称为切片）。修改模板把这个列表打印到 ConfigMap 中： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` 我们可以使用`$`从父作用域访问`Values.pizzaToppings`列表。当模板开始执行后`$`会被映射到根作用域， 且执行过程中不会更改。下面这种方式也可以正常工作： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` 让我们仔细看看`toppings:`列表。`range`方法“涵盖”（迭代）`pizzaToppings`列表。但现在发生了有意思的事情。 就像`with`设置了`.`的作用域，`range`操作符也做了同样的事。每一次循环，`.`都会设置为当前的披萨配料。 也就是说，第一次`.`设置成了`mushrooms`，第二次迭代设置成了`cheese`，等等。 我们可以直接发送`.`的值给管道，因此当我们执行`{{ . | title | quote }}`时，它会发送`.`到`title`然后发送到`quote`。 如果执行这个模板，输出是这样的： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` 现在，我们已经处理了一些棘手的事情。`toppings: |-`行是声明的多行字符串。所以这个配料列表实际上不是YAML列表， 而是一个大字符串。为什么要这样做？因为 ConfigMap 的 `data` 中的数据是由键值对组成，key 和 value 都是简单的字符串。 要理解这个示例，请查看 [Kubernetes ConfigMap 文档](https://kubernetes.io/docs/concepts/configuration/configmap/)。 但对于我们来说，这个细节并不重要。 > 正如例子中所示，`|-`标识在YAML中是指多行字符串。这在清单列表中嵌入大块数据是很有用的技术。 有时能在模板中快速创建列表然后迭代很有用，Helm模板的`tuple`可以很容易实现该功能。在计算机科学中， 元组表示一个有固定大小的类似列表的集合，但可以是任意数据类型。这大致表达了`tuple`的用法。 ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` 上述模板会生成以下内容： ```yaml sizes: |- - small - medium - large ``` 除了列表和元组，`range`可被用于迭代有键值对的集合（像`map`或`dict`）。我们会在下一部分介绍模板变量是看到它是如何应用的。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/data_types.md ================================================ --- title: 附录：Go 数据类型和模板 description: 模板中变量的简单概述。 sidebar_position: 16 --- Helm 模板语言是用强类型 Go 编程语言实现的。因此，模板中的变量是 _有类型的_。大多数情况下，变量将作为以下类型之一显示： - string：文本字符串 - bool：`true` 或 `false` - int：整型值（包含 8 位、16 位、32 位和 64 位有符号及无符号整数） - float64：64 位浮点数（也有 8 位、16 位、32 位类型） - 字节切片（`[]byte`），常用于保存（可能的）二进制数据 - struct：有属性和方法的对象 - 上述某种类型的切片（索引列表） - 字符串键的 map（`map[string]interface{}`），值是上述某种类型 Go 里面有很多其他类型，有时你需要在模板里进行转换。调试对象类型最简便的方式是在模板中传递给 `printf "%T"`，这样会打印类型。也可以使用 `typeOf` 和 `kindOf` 函数。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/debugging.md ================================================ --- title: 调试模板 description: 对部署失败的 chart 进行故障排除。 sidebar_position: 13 --- 调试模板可能很棘手，因为渲染后的模板会发送给 Kubernetes API server，可能会因格式以外的原因拒绝 YAML 文件。 以下命令有助于调试： - `helm lint` 是验证 chart 是否遵循最佳实践的首选工具。 - `helm template --debug` 可在本地测试 chart 模板的渲染。 - `helm install --dry-run --debug` 同样会在本地渲染 chart 而不实际安装，同时还会检查集群上是否存在冲突的资源。设置 `--dry-run=server` 会将 chart 中的任何 `lookup` 发送到服务器执行。 - `helm get manifest`：这是查看服务器上已安装模板的好方法。 当你的 YAML 文件解析失败，但你想知道生成了什么，一个简单的方式是注释掉模板中有问题的部分，然后重新运行 `helm install --dry-run --debug`： ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` 以上内容会被渲染，同时返回完整的注释： ```yaml apiVersion: v2 # some: problem section # "bar" ``` 这样可以快速查看生成的内容，而不会被 YAML 解析错误阻塞。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/function_list.md ================================================ --- title: 模板函数列表 description: Helm中模板函数变量的列表 sidebar_position: 6 --- Helm 包含了很多可以在模板中利用的模板函数。以下列出了具体分类： * [Cryptographic and Security](#cryptographic-and-security-functions) * [Date](#date-functions) * [Dictionaries](#dictionaries-and-dict-functions) * [Encoding](#encoding-functions) * [File Path](#file-path-functions) * [Kubernetes and Chart](#kubernetes-and-chart-functions) * [Logic and Flow Control](#logic-and-flow-control-functions) * [Lists](#lists-and-list-functions) * [Math](#math-functions) * [Float Math](#float-math-functions) * [Network](#network-functions) * [Reflection](#reflection-functions) * [Regular Expressions](#regular-expressions) * [Semantic Versions](#semantic-version-functions) * [String](#string-functions) * [Type Conversion](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## Logic and Flow Control Functions Helm 包括了许多逻辑和流控制函数，包括[and](#and)、[coalesce](#coalesce)、[default](#default)、 [empty](#empty)、[eq](#eq)、[fail](#fail)、[ge](#ge)、[gt](#gt)、[le](#le)、[lt](#lt)、 [ne](#ne)、[not](#not)、[or](#or)和[required](#required)。 ### and 返回两个或多个参数的布尔AND值（返回第一个空参数，或最后一个参数）。 ```yaml and .Arg1 .Arg2 ``` ### or 返回两个参数的or布尔值。会返回第一个非空参数或最后一个参数。 ```yaml or .Arg1 .Arg2 ``` ### not 返回参数的布尔求反。 ```yaml not .Arg ``` ### eq 返回参数的布尔等式（比如， Arg1 == Arg2）。 ```yaml eq .Arg1 .Arg2 ``` ### ne 返回参数的布尔非等式（比如 Arg1 != Arg2）。 ```yaml ne .Arg1 .Arg2 ``` ### lt 如果第一参数小于第二参数，返回布尔真。否则返回假（比如， Arg1 < Arg2）。 ```yaml lt .Arg1 .Arg2 ``` ### le 如果第一参数小于等于第二参数，返回布尔真，否则返回假（比如， Arg1 <= Arg2）。 ```yaml le .Arg1 .Arg2 ``` ### gt 如果第一参数大于第二参数，返回布尔真，否则返回假（比如， Arg1 > Arg2）。 ```yaml gt .Arg1 .Arg2 ``` ### ge 如果第一参数大于等于第二参数，返回布尔真，否则返回假。（比如， Arg1 >= Arg2）。 ```yaml ge .Arg1 .Arg2 ``` ### default 使用`default`设置一个简单的默认值。 ```yaml default "foo" .Bar ``` 上述示例中，如果`.Bar`是非空值，则使用它，否则会返回`foo`。 "空"定义取决于以下类型： * 整型: 0 * 字符串: "" * 列表: `[]` * 字典: `{}` * 布尔: `false` * 以及所有的`nil` (或 null) 对于结构体，没有空的定义，所以结构体从来不会返回默认值。 ### required 使用 `required` 指定必须设置的值： ``` required "A valid foo is required!" .Bar ``` 如果 `.Bar` 为空或未定义（参阅 [default](#default) 了解如何判断空值），模板将不会渲染，而是返回所提供的错误信息。 ### empty 如果给定的值被认为是空的，则`empty`函数返回`true`，否则返回`false`。空值列举在`default`部分。 ```yaml empty .Foo ``` 注意在Go模板条件中，空值是为你计算出来的。这样你很少需要 `if not empty .Foo` ，仅使用 `if .Foo` 即可。 ### fail 无条件地返回带有指定文本的空 `string` 或者 `error`。这在其他条件已经确定而模板渲染应该失败的情况下很有用。 ```yaml fail "Please accept the end user license agreement" ``` ### coalesce `coalesce`函数获取一个列表并返回第一个非空值。 ```yaml coalesce 0 1 2 ``` 上述会返回`1`。 此函数用于扫描多个变量或值： ```yaml coalesce .name .parent.name "Matt" ``` 上述示例会优先检查 `.name` 是否为空。如果不是，就返回值。如果 _是_ 空, 继续检查`.parent.name`。 最终，如果 `.name` 和 `.parent.name` 都是空，就会返回 `Matt`。 ### ternary `ternary`函数获取两个值和一个test值。如果test值是true，则返回第一个值。如果test值是空，则返回第二个值。 这和C或其他编程语言中的的ternary运算符类似。 #### true test value ```yaml ternary "foo" "bar" true ``` 或者 ```yaml true | ternary "foo" "bar" ``` 上述返回 `"foo"`。 #### false test value ```yaml ternary "foo" "bar" false ``` 或者 ```yaml false | ternary "foo" "bar" ``` 上述返回 `"bar"`. ## String Functions Helm 包含了以下字符串函数： [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), 和 [wrapWith](#wrapwith) ### print 返回各部分组合的字符串。 ```yaml print "Matt has " .Dogs " dogs" ``` 如果可能，非字符串类型会被转换成字符串。 注意，当相邻两个参数不是字符串时会在它们之间添加一个空格。 ### println 和[print](#print)效果一样，但会在末尾新添加一行。 ### printf 返回参数按顺序传递的格式化字符串。 ```yaml printf "%s has %d dogs." .Name .NumberDogs ``` 占位符取决于传入的参数类型。这包括： 一般用途： * `%v` 默认格式的值 * 当打印字典时，加号参数(`%+v`)可以添加字段名称 * `%%` 字符百分号，不使用值 布尔值： * `%t` true或false 整型： * `%b` 二进制 * `%c` the character represented by the corresponding Unicode code point * `%d` 十进制 * `%o` 8进制 * `%O` 带0o前缀的8进制 * `%q` 安全转义的单引号字符 * `%x` 16进制，使用小写字符a-f * `%X` 16进制，使用小写字符A-F * `%U` Unicode格式： U+1234; 和"U+%04X"相同 浮点数和复杂成分 * `%b` 指数二次幂的无小数科学计数法，比如 -123456p-78 * `%e` 科学计数法，比如： -1.234456e+78 * `%E` 科学计数法，比如： -1.234456E+78 * `%f` 无指数的小数，比如： 123.456 * `%F` 与%f同义 * `%g` %e的大指数，否则是%f * `%G` %E的大指数，否则是%F * `%x` 十六进制计数法(和两个指数的十进制幂)，比如： -0x1.23abcp+20 * `%X` 大写的十六进制计数法，比如： -0X1.23ABCP+20 字符串和字节切片： * `%s` 未解析的二进制字符串或切片 * `%q` 安全转义的双引号字符串 * `%x` 十六进制，小写，每个字节两个字符 * `%X` 十六进制，大写，每个字节两个字符 切片： * `%p` 16进制的第0个元素的地址，以0x开头 ### trim `trim`函数移除字符串两边的空格： ```yaml trim " hello " ``` 上述结果为： `hello` ### trimAll 从字符串中移除给定的字符： ```yaml trimAll "$" "$5.00" ``` 上述结果为：`5.00` (作为一个字符串)。 ### trimPrefix 从字符串中移除前缀： ```yaml trimPrefix "-" "-hello" ``` 上述结果为：`hello` ### trimSuffix 从字符串中移除后缀： ```yaml trimSuffix "-" "hello-" ``` 上述结果为： `hello` ### lower 将整个字符串转换成小写： ```yaml lower "HELLO" ``` 上述结果为： `hello` ### upper 将整个字符串转换成大写： ```yaml upper "hello" ``` 上述结果为： `HELLO` ### title 首字母转换成大写： ```yaml title "hello world" ``` 上述结果为： `Hello World` ### untitle 移除首字母大写：`untitle "Hello World"` 会得到 `hello world`. ### repeat 重复字符串多次： ```yaml repeat 3 "hello" ``` 上述结果为： `hellohellohello` ### substr 获取字符串的子串，有三个参数： * start (int) * end (int) * string (string) ```yaml substr 0 5 "hello world" ``` 上述结果为： `hello` ### nospace 去掉字符串中的所有空格： ```yaml nospace "hello w o r l d" ``` 上述结果为： `helloworld` ### trunc 截断字符串。 ```yaml trunc 5 "hello world" ``` 上述结果为： `hello`. ```yaml trunc -5 "hello world" ``` 上述结果为： `world`. ### abbrev 用省略号截断字符串 (`...`) 参数： * 最大长度 * 字符串 ```yaml abbrev 5 "hello world" ``` 上述结果为： `he...`， 因为将省略号算进了长度中。 ### abbrevboth 两边都省略 ```yaml abbrevboth 5 10 "1234 5678 9123" ``` 上述结果为： `...5678...` It takes: * 左侧偏移值 * 最大长度 * 字符串 ### initials 截取给定字符串每个单词的首字母，并组合在一起。 ```yaml initials "First Try" ``` 上述结果为： `FT` ### randAlphaNum, randAlpha, randNumeric, and randAscii 这四个字符串生成加密安全的(使用 ```crypto/rand```)的随机字符串，但是字符集合不同： * `randAlphaNum` 使用 `0-9a-zA-Z` * `randAlpha` 使用 `a-zA-Z` * `randNumeric` 使用 `0-9` * `randAscii` 使用所有的可打印ASCII字符 每个函数都需要一个参数：字符串的整型长度 ```yaml randNumeric 3 ``` 上述会生成三个数字的字符串。 ### wrap 以给定列数给文字换行。 ```yaml wrap 80 $someText ``` 上述结果会以`$someText`在80列处换行。 ### wrapWith `wrapWith` 和 `wrap` 类似，但可以以指定字符串换行。(`wrap` 使用的是 `\n`) ```yaml wrapWith 5 "\t" "Hello World" ``` 上述结果为： `hello world` (其中空格是ASCII tab字符) ### contains 测试字符串是否包含在另一个字符串中： ```yaml contains "cat" "catch" ``` 上述结果为： `true` 因为 `catch` 包含了 `cat`. ### hasPrefix and hasSuffix `hasPrefix` 和 `hasSuffix` 函数测试字符串是否有给定的前缀或后缀： ```yaml hasPrefix "cat" "catch" ``` 上述结果为： `true` 因为 `catch` 有 `cat`. ### quote and squote 该函数将字符串用双引号(`quote`) 或者单引号(`squote`)括起来。 ### cat `cat` 函数将多个字符串合并成一个，用空格分隔： ```yaml cat "hello" "beautiful" "world" ``` 上述结果为： `hello beautiful world` ### indent `indent` 以指定长度缩进给定字符串所在行，在对齐多行字符串时很有用： ```yaml indent 4 $lots_of_text ``` 上述结果会将每行缩进4个空格。 ### nindent `nindent` 函数和indent函数一样，但可以在字符串开头添加新行。 ```yaml nindent 4 $lots_of_text ``` 上述结果会在字符串所在行缩进4个字符，并且在开头新添加一行。 ### replace 执行简单的字符串替换。 需要三个参数 * 待替换字符串 * 要替换字符串 * 源字符串 ```yaml "I Am Henry VIII" | replace " " "-" ``` 上述结果为： `I-Am-Henry-VIII` ### plural 字符串复数化。 ```yaml len $fish | plural "one anchovy" "many anchovies" ``` 如上，如果字符串长度为1，则第一个参数会被打印(`one anchovy`）。否则，会打印第二个参数(`many anchovies`）。 参数包括： * 单数字符串 * 复数字符串 * 整型长度 注意： Helm 现在不支持多语言复杂的复数规则。`0`被认为是复数的因为英文中作为(`zero anchovies`) 对待。 ### snakecase 将驼峰写法转换成蛇形写法。 ```yaml snakecase "FirstName" ``` 上述结果为： `first_name`. ### camelcase 将字符串从蛇形写法转换成驼峰写法。 ```yaml camelcase "http_server" ``` 上述结果为： `HttpServer`。 ### kebabcase 将驼峰写法转换成烤串写法。 ```yaml kebabcase "FirstName" ``` 上述结果为： `first-name`. ### swapcase 基于单词的算法切换字符串的大小写。 转换算法： * 大写字符变成小写字母 * 首字母变成小写字母 * 空格后或开头的小写字母转换成大写字母 * 其他小写字母转换成大写字母 * 通过unicode.IsSpace(char)定义空格 ```yaml swapcase "This Is A.Test" ``` 上述结果为： `tHIS iS a.tEST`. ### shuffle 对字符串进行洗牌。 ```yaml shuffle "hello" ``` 上述`hello`的随机字符串可能会是`oelhl`。 ## Type Conversion Functions Helm提供了以下类型转换函数： * `atoi`: 字符串转换成整型。 * `float64`: 转换成 `float64`。 * `int`: 按系统整型宽度转换成`int`。 * `int64`: 转换成 `int64`。 * `toDecimal`: 将unix八进制转换成`int64`。 * `toString`: 转换成字符串。 * `toStrings`: 将列表、切片或数组转换成字符串列表。 * `toJson` (`mustToJson`): 将列表、切片、数组、字典或对象转换成JSON。 * `toPrettyJson` (`mustToPrettyJson`): 将列表、切片、数组、字典或对象转换成格式化JSON。 * `toRawJson` (`mustToRawJson`): 将列表、切片、数组、字典或对象转换成HTML字符未转义的JSON。 * `fromYaml`：将YAML字符串转化成对象。 * `fromJson`: 将JSON字符串转化成对象。 * `toYaml`: 将列表，切片，数组，字典或对象转换成已缩进的yaml，可以从任意源拷贝yaml块。该功能和Go的yaml.Marshal函数一样，文档详见：https://pkg.go.dev/gopkg.in/yaml.v2#Marshal 只有`atoi`需要输入一个特定的类型。其他的会尝试将任何类型转换成目标类型。比如，`int64`可以把浮点数转换成整型，也可以把字符串转换成整型。 ### toStrings 给定一个类列表集合，输出字符串切片。 ```yaml list 1 2 3 | toStrings ``` 上述会将`1`转成`"1"`，`2`转成`"2"`，等等，然后将其作为列表返回。 ### toDecimal 给定一个unix八进制权限，转换成十进制。 ```yaml "0777" | toDecimal ``` 上述会将 `0777` 转换成 `511` 并返回int64的值。 ### toJson, mustToJson `toJson`函数将内容编码为JSON字符串。如果内容无法被转换成JSON会返回空字符串。`mustToJson`会返回错误以防无法编码成JSON。 ```yaml toJson .Item ``` 上述结果为： `.Item`的JSON字符串表示。 ### toPrettyJson, mustToPrettyJson `toPrettyJson`函数将内容编码为好看的（缩进的）JSON字符串。 ```yaml toPrettyJson .Item ``` 上述结果为： `.Item`的已缩进的JSON字符串表示。 ### toRawJson, mustToRawJson `toRawJson` 函数将内容编码成包含非转义HTML字符的JSON字符串。 ```yaml toRawJson .Item ``` 上述结果为： `.Item`的非转义的JSON字符串表示。 ### fromYaml `fromYaml` 函数将YAML字符串转换成模板可用的对象。 `文件位置: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson `fromJson` 函数将JSON字符串转换成模板可用的对象。 `文件位置: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray `fromJsonArray` 函数接受一个 JSON 数组并返回一个可在模板中使用的列表。 `文件位置: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty `toYaml` 和 `toYamlPretty` 函数将对象（列表、切片、数组、字典或对象）编码为缩进的 YAML 字符串。 > 注意：`toYamlPretty` 功能相同，但会为列表元素添加额外的缩进 ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray `fromYamlArray` 函数接受一个 YAML 数组并返回一个可在模板中使用的列表。 `文件位置: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Regular Expressions Helm 包含以下正则表达式函数 [regexFind(mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll(mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral(mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit)。 ### regexMatch, mustRegexMatch 如果输入字符串包含可匹配正则表达式任意字符串，则返回true。 ```yaml regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` 上述结果为： `true` `regexMatch`有问题时会出错， `mustRegexMatch`有问题时会向模板引擎返回错误。 ### regexFindAll, mustRegexFindAll 返回输入字符串匹配正则表达式的所有切片。最后一个参数表示要返回的子字符串的数量，-1表示返回所有。 ```yaml regexFindAll "[2,4,6,8]" "123456789" -1 ``` 上述结果为： `[2 4 6 8]` `regexFindAll` 有问题时会出错， `mustRegexFindAll` 有问题时会向模板引擎返回错误。 ### regexFind, mustRegexFind 返回输入字符串的第一个 (最左边的) 正则匹配。 ```yaml regexFind "[a-zA-Z][1-9]" "abcd1234" ``` 上述结果为： `d1` `regexFind` 有问题时会出错， `mustRegexFind` 有问题时会向模板引擎返回错误。 ### regexReplaceAll, mustRegexReplaceAll 返回输入字符串的拷贝，用替换字符串替换Regexp的匹配项。在替换字符串里面，$ 标志被解释为扩展，因此对于实例来说 $1 表示第一个子匹配的文本。第一个参数是``，第二个是``，第三个是``。 ```yaml regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` 上述结果为： `-W-xxW-` `regexReplaceAll` 有问题时会出错， `mustRegexReplaceAll` 有问题时会向模板引擎返回错误。 ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral 返回输入字符串的拷贝，用替换字符串替换Regexp的匹配项。匹配字符串直接替换而不是扩展。第一个参数是``，第二个是``，第三个是``。 ```yaml regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` 上述结果为： `-${1}-${1}-` `regexReplaceAllLiteral` 有问题时会出错，`mustRegexReplaceAllLiteral` 有问题时会向模板引擎返回错误。 ### regexSplit, mustRegexSplit 将输入字符串切成有表达式分隔的子字符串，并返回表达式匹配项之间的切片。最后一个参数`n`确定要返回的子字符串数量，`-1`表示返回所有匹配。 ```yaml regexSplit "z+" "pizza" -1 ``` 上述结果为： `[pi a]` `regexSplit` 有问题时会出错，`mustRegexSplit` 有问题时会向模板引擎返回错误。 ## Cryptographic and Security Functions Helm提供了一些高级的加密函数。包括了 [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword),[encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum)，以及 [sha256sum](#sha256sum)。 ### sha1sum `sha1sum`函数接收一个字符串，并计算它的SHA1摘要。 ```yaml sha1sum "Hello world!" ``` ### sha256sum `sha256sum` 函数接收一个字符串，并计算它的SHA256摘要。 ```yaml sha256sum "Hello world!" ``` 上述语句会以“ASCII包装”格式计算SHA 256 校验和，并安全打印出来。 ### adler32sum `adler32sum`函数接收一个字符串，并计算它的Adler-32校验和。 ```yaml adler32sum "Hello world!" ``` ### htpasswd `htpasswd` 函数使用`username` 和 `password` 生成一个密码的`bcrypt`哈希值。该结果可用于[Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic) 的基础认证。 ```yaml htpasswd "myUser" "myPassword" ``` 注意，将密码直接存储在模板中并不安全。 ### randBytes `randBytes` 函数接受一个数量 N，生成一个加密安全的（使用 crypto/rand）N 字节随机序列。返回值为 base64 编码的字符串。 ``` randBytes 24 ``` ### derivePassword `derivePassword` 函数可用于基于某些共享的“主密码”约束得到特定密码。这方面的算法有[详细说明](https://spectre.app/spectre-algorithm.pdf)。 ```yaml derivePassword 1 "long" "password" "user" "example.com" ``` 注意，将这部分直接存储在模板中并不安全。 ### genPrivateKey `genPrivateKey` 函数生成一个编码成PEM块的新私钥。 第一个参数会采用以下某个值： * `ecdsa`: 生成椭圆曲线 DSA key (P256) * `dsa`: 生成 DSA key (L2048N256) * `rsa`: 生成 RSA 4096 key ### buildCustomCert `buildCustomCert` 函数允许自定义证书。 会采用以下字符串参数： * base64 编码PEM格式证书 * base64 编码PEM格式私钥 返回包含以下属性的整数对象： * `Cert`:PEM编码证书 * `Key`: PEM编码私钥 示例： ```yaml $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` 注意返回的对象可以使用这个CA传递给`genSignedCert`函数进行签名。 ### genCA `genCA` 函数生成一个新的，自签名的x509 证书机构。 会采用以下参数： * 主体通用名 (cn) * 证书有效期（天） 会返回一个包含以下属性的对象： * `Cert`: PEM编码证书 * `Key`: PEM编码私钥 示例： ```yaml $ca := genCA "foo-ca" 365 ``` 注意返回的对象可以使用这个CA传递给`genSignedCert`函数进行签名。 ### genSelfSignedCert The `genSelfSignedCert` 函数生成一个新的，自签名的x509 证书。 会采用下列参数： * 主体通用名 (cn) * 可选IP列表；可以为空 * 可选备用DNS名称列表；可以为空 * 证书有效期（天） 会返回一个包含以下属性的对象： * `Cert`: PEM编码证书 * `Key`: PEM编码私钥 示例： ```yaml $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert `genSignedCert` 通过指定的CA签名生成一个新的， x509证书 会采用以下参数： * 主体通用名 (cn) * 可选IP列表；可以为空 * 可选备用DNS名称列表；可以为空 * 证书有效期（天） * CA (查看 `genCA`) 示例： ```yaml $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES `encryptAES` 函数使用AES-256 CBC 加密文本并返回一个base64编码字符串。 ```yaml encryptAES "secretkey" "plaintext" ``` ### decryptAES `decryptAES`函数接收一个AES-256 CBC编码的字符串并返回解密文本。 ```yaml "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Date Functions Helm 包含以下可以在模板中使用的函数：[ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify(mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate(mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch)。 ### now 当前日期/时间。和其他日期函数一起使用。 ### ago `ago` 函数返回距time.Now的以秒为单位的间隔时间。 ```yaml ago .CreatedAt ``` 返回`time.Duration`的字符串格式 ```yaml 2h34m7s ``` ### date `date`函数格式化日期 日期格式化为YEAR-MONTH-DAY： ```yaml now | date "2006-01-02" ``` 日期格式化在Go中有[一些不同](https://pauladamsmith.com/blog/2011/05/go_time.html)。 简言之，以此为基准日期： ```yaml Mon Jan 2 15:04:05 MST 2006 ``` 将其写成你想要的格式，上面的例子中，`2006-01-02` 是同一个日期，却是我们需要的格式。 ### dateInZone 和 `date` 一样，但是和时区一起。 ```yaml dateInZone "2006-01-02" (now) "UTC" ``` ### duration 将给定的秒数格式化为`time.Duration`。 这会返回 1m35s。 ```yaml duration 95 ``` ### durationRound 将给定时间舍入到最重要的单位。当`time.Time`计算为一个自某个时刻以来的时间，字符串和`time.Duration`被解析为一个时间段。 这会返回2h ```yaml durationRound "2h10m5s" ``` 这会返回3mo ```yaml durationRound "2400h10m5s" ``` ### unixEpoch 返回`time.Time`的unix时间戳。 ```yaml now | unixEpoch ``` ### dateModify, mustDateModify `dateModify` 给定一个修改日期并返回时间戳。 从当前时间减去一个小时三十分钟： ```yaml now | date_modify "-1.5h" ``` 如果修改格式错误， `dateModify`会返回日期未定义。而`mustDateModify`会返回错误。 ### htmlDate `htmlDate`函数用于格式化插入到HTML日期选择器输入字段的日期。 ```yaml now | htmlDate ``` ### htmlDateInZone 和htmlDate一样，但多了个时区。 ```yaml htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` 将字符串转换成日期。第一个参数是日期格式，第二个参数是日期字符串。 如果字符串无法转换就会返回0值。`mustToDate`以防无法转换会返回错误。 这在你将日期字符串转换成其他格式时很有用（使用pipe）。下面的例子会将"2017-12-31" 转换成 "31/12/2017"。 ```yaml toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Dictionaries and Dict Functions Helm 提供了一个key/value存储类型称为`dict`（"dictionary"的简称，Python中也有）。`dict`是无序类型。 字典的key **必须是字符串**。但值可以是任意类型，甚至是另一个`dict` 或 `list`。 不像`list`， `dict`不是不可变的。`set`和`unset`函数会修改字典的内容。 Helm 提供了以下函数支持使用字典：[deepCopy(mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get),[hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset),和[values](#values)。 ### dict 通过调用`dict`函数并传递一个键值对列表创建字典。 下面是创建三个键值对的字典： ```yaml $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get 给定一个映射和一个键，从映射中获取值。 ```yaml get $myDict "name1" ``` 上述结果为： `"value1"` 注意如果没有找到，会简单返回`""`。不会生成error。 ### set 使用`set`给字典添加一个键值对。 ```yaml $_ := set $myDict "name4" "value4" ``` 注意`set` _返回字典_ (Go模板函数的一个要求)，因此你可能需要像上面那样使用使用`$_`赋值来获取值。 ### unset 给定一个映射和key，从映射中删除这个key。 ```yaml $_ := unset $myDict "name4" ``` 和`set`一样，需要返回字典。 注意，如果key没有找到，这个操作会简单返回，不会生成错误。 ### hasKey `hasKey`函数会在给定字典中包含了给定key时返回`true`。 ```yaml hasKey $myDict "name1" ``` 如果key没找到，会返回`false`。 ### pluck `pluck` 函数给定一个键和多个映射，并获得所有匹配项的列表： ```yaml pluck "name1" $myDict $myOtherDict ``` 上述会返回的`list`包含了每个找到的值(`[value1 otherValue1]`)。 如果key在映射中 _没有找到_ ，列表中的映射就不会有内容（并且返回列表的长度也会小于调用`pluck`的字典）。 如果key是 _存在的_， 但是值是空值，会插入一个值。 Helm模板中的一个常见用法是使用`pluck... | first` 从字典集合中获取第一个匹配的键。 ### dig `dig` 函数遍历嵌套的字典，从值列表中选择键。如果在关联的字典中找不到键，会返回默认值。 ```yaml dig "user" "role" "humanName" "guest" $dict ``` 给一个结构化的字典如下： ```yaml { user: { role: { humanName: "curator" } } } ``` 那上述命令就会返回`"curator"`。 如果字典连`user`都没有，就会返回`"guest"`。 如果你想避开保护规则，dig就很有用，特别是Go模板包的`and`没有快捷方式。譬如 `and a.maybeNil a.maybeNil.iNeedThis` 总是会描述为`a.maybeNil.iNeedThis`，如果 `maybeNil` 字段缺少 `a` 就会报错。 `dig` 为了支持管道符会接受字典参数，比如： ```yaml merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge 将两个或多个字典合并为一个， 目标字典优先： 给出： ```yaml dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` 会得到结果： ```yaml newdict: default: default overwrite: me key: true ``` ```yaml $newdict := merge $dest $source1 $source2 ``` 这是个深度合并操作，但不是深度拷贝操作。合并的嵌套对象是两个字典上的同一实例。如果想深度合并的同时进行深度拷贝， 合并的时候同时使用`deepCopy`函数，比如： ```yaml deepCopy $source | merge $dest ``` `mustMerge` 会返回错误，以防出现不成功的合并。 ### mergeOverwrite, mustMergeOverwrite 合并两个或多个字典，优先按照 **从右到左**，在目标字典中有效地覆盖值： 给定的： ```yaml dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` 会生成： ```yaml newdict: default: default overwrite: overwritten key: false ``` ```yaml $newdict := mergeOverwrite $dest $source1 $source2 ``` 这是一个深度合并操作但不是深度拷贝操作。两个字典上嵌入的对象被合并到了同一个实例中。如果你想在合并的同时进行深度拷贝， 使用`deepCopy`函数，比如： ```yaml deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` 会返回错误，以防出现不成功的合并。 ### keys `keys`函数会返回一个或多个`dict`类型中所有的key的`list`。由于字典是 _无序的_，key不会有可预料的顺序。 可以使用`sortAlpha`存储。 ```yaml keys $myDict | sortAlpha ``` 当提供了多个词典时，key会被串联起来。使用`uniq`函数和`sortAlpha`获取一个唯一有序的键列表。 ```yaml keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick `pick`函数只从字典中选择给定的键，并创建一个新的`dict`。 ```yaml $new := pick $myDict "name1" "name2" ``` 上述结果为： `{name1: value1, name2: value2}` ### omit `omit`函数类似于`pick`，除它之外返回一个新的`dict`，所有的key _不_ 匹配给定的key。 ```yaml $new := omit $myDict "name1" "name3" ``` 上述结果为： `{name2: value2}` ### values `values`函数类似于`keys`，返回一个新的`list`包含源字典中所有的value(只支持一个字典)。 ```yaml $vals := values $myDict ``` 上述结果为： `list["value1", "value2", "value 3"]`。注意 `values`不能保证结果的顺序；如果你需要顺序， 请使用`sortAlpha`。 ### deepCopy, mustDeepCopy `deepCopy` 和 `mustDeepCopy` 函数给定一个值并深度拷贝这个值。包括字典和其他结构体。 `deepCopy`有问题时会出错， 而`mustDeepCopy`会返回一个错误给模板系统。 ```yaml dict "a" 1 "b" 2 | deepCopy ``` ### 字典的内部说明 `dict` 在Go里是作为`map[string]interface{}`执行的。Go开发者可以传`map[string]interface{}`值给上下文， 将其作为 `dict` 提供给模板。 ## Encoding functions Helm有以下编码和解码函数： * `b64enc`/`b64dec`: 编码或解码 Base64 * `b32enc`/`b32dec`: 编码或解码 Base32 ## Lists and List Functions Helm 提供了一个简单的`list`类型，包含任意顺序的列表。类似于数组或切片，但列表是被设计用于不可变数据类型。 创建一个整型列表： ```yaml $myList := list 1 2 3 4 5 ``` 上述会生成一个列表 `[1 2 3 4 5]`。 Helm 提供了以下列表函数： [append(mustAppend)](#append-mustappend), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first(mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), 和 [without (mustWithout)](#without-mustwithout)。 ### first, mustFirst 获取列表中的第一项，使用 `first`。 `first $myList` 返回 `1` `first` 有问题时会出错，`mustFirst` 有问题时会向模板引擎返回错误。 ### rest, mustRest 获取列表的尾部内容(除了第一项外的所有内容)，使用`rest`。 `rest $myList` returns `[2 3 4 5]` `rest`有问题时会出错，`mustRest` 有问题时会向模板引擎返回错误。 ### last, mustLast 使用`last`获取列表的最后一项： `last $myList` 返回 `5`。这大致类似于反转列表然后调用`first`。 ### initial, mustInitial 通过返回所有元素 _但_ 除了最后一个元素来赞赏`last`。 `initial $myList` 返回 `[1 2 3 4]`。 `initial`有问题时会出错，但是 `mustInitial` 有问题时会向模板引擎返回错误。 ### append, mustAppend 在已有列表中追加一项，创建一个新的列表。 ```yaml $new = append $myList 6 ``` 上述语句会设置 `$new` 为 `[1 2 3 4 5 6]`。 `$myList`会保持不变。 `append` 有问题时会出错，但 `mustAppend` 有问题时会向模板引擎返回错误。 ### prepend, mustPrepend 将元素添加到列表的前面，生成一个新的列表。 ```yaml prepend $myList 0 ``` 上述语句会生成 `[0 1 2 3 4 5]`。 `$myList`会保持不变。 `prepend` 有问题时会出错，但 `mustPrepend` 有问题时会向模板引擎返回错误。 ### concat 将任意数量的列表串联成一个。 ```yaml concat $myList ( list 6 7 ) ( list 8 ) ``` 上述语句会生成 `[1 2 3 4 5 6 7 8]`。 `$myList` 会保持不变。 ### reverse, mustReverse 反转给定的列表生成一个新列表。 ```yaml reverse $myList ``` 上述语句会生成一个列表： `[5 4 3 2 1]`。 `reverse` 有问题时会出错，但 `mustReverse` 有问题时会向模板引擎返回错误。 ### uniq, mustUniq 生成一个移除重复项的列表。 ```yaml list 1 1 1 2 | uniq ``` 上述语句会生成 `[1 2]` `uniq` 有问题时会出错，但 `mustUniq` 有问题时会向模板引擎返回错误。 ### without, mustWithout `without` 函数从列表中过滤内容。 ```yaml without $myList 3 ``` 上述语句会生成 `[1 2 4 5]` 一个过滤器可以过滤多个元素： ```yaml without $myList 1 3 5 ``` 这样会得到： `[2 4]` `without` 有问题时会出错，但 `mustWithout` 有问题时会向模板引擎返回错误。 ### has, mustHas 验证列表是否有特定元素。 ```yaml has 4 $myList ``` 上述语句会返回 `true`, 但 `has "hello" $myList` 就会返回false。 `has` 有问题时会出错，但 `mustHas` 有问题时会向模板引擎返回错误。 ### compact, mustCompact 接收一个列表并删除空值项。 ```yaml $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` 会返回一个移除了空值(比如， "")的新列表。 `compact` 有问题时会出错，但 `mustCompact` 有问题时会向模板引擎返回错误。 ### index 使用`index list [n]`获取列表的第n个元素。使用`index list [n] [m] ...`获取多位列表元素。 * `index $myList 0` 返回 `1`，同 `myList[0]` * `index $myList 0 1` 同 `myList[0][1]` ### slice, mustSlice 从列表中获取部分元素，使用 `slice list [n] [m]`。等同于 `list[n:m]`. * `slice $myList` 返回 `[1 2 3 4 5]`。 等同于 `myList[:]`。 * `slice $myList 3` 返回 `[4 5]`等同于 `myList[3:]`。 * `slice $myList 1 3` 返回 `[2 3]`等同于 `myList[1:3]`。 * `slice $myList 0 3` 返回 `[1 2 3]`等同于 `myList[:3]`。 `slice` 有问题时会出错，但 `mustSlice` 有问题时会向模板引擎返回错误。 ### until `until` 函数构建一个整数范围。 ```yaml until 5 ``` 上述语句会生成一个列表： `[0, 1, 2, 3, 4]`。 对循环语句很有用： `range $i, $e := until 5`。 ### untilStep 类似`until`， `untilStep` 生成一个可计数的整型列表。但允许你定义开始，结束和步长： ```yaml untilStep 3 6 2 ``` 上述语句会生成 `[3 5]`，从3开始，每次加2，直到大于等于6。类似于Python的 `range` 函数。 ### seq 原理和bash的 `seq` 命令类似。 * 1 单个参数 (结束位置) - 会生成所有从1到包含 `end` 的整数。 * 2 多个参数 (开始， 结束) - 会生成所有包含`start` 和 `end` 的整数，递增或者递减。 * 3 多个参数 (开始， 步长， 结束) - 会生成所有包含 `start` 和 `end` 按 `step`递增或递减的整数。 ```yaml seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk 使用 `chunk size list` 将列表拆分为指定大小的块。这对于分页很有用。 ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` 上述语句会生成一个列表的列表 `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`。 ## Math Functions 除非另外指定，否则所有的math函数都是操作 `int64` 的值。 有以下math函数可用： [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub）。 ### add 使用`add`求和。接受两个或多个输入。 ```yaml add 1 2 3 ``` ### add1 自增加1，使用 `add1`。 ### sub 相减使用 `sub`。 ### div 整除使用 `div`。 ### mod 取模使用`mod`。 ### mul 相乘使用`mul`。接受两个或多个输入。 ```yaml mul 1 2 3 ``` ### max 返回一组整数中最大的整数。 下列会返回`3`: ```yaml max 1 2 3 ``` ### min 返回一组数中最小的数。 `min 1 2 3` 会返回 `1`。 ### len 返回参数的长度。 ```yaml len .Arg ``` ## Float Math Functions 所有的数学函数使用`float64`格式。 ### addf 使用`addf`求和 下面的例子会返回`5.5`: ```yaml addf 1.5 2 2 ``` ### add1f 使用`add1f`递增1 ### subf 相减使用`subf` 下面例子相当于`7.5 - 2 - 3` 并返回 `2.5`: ```yaml subf 7.5 2 3 ``` ### divf 使用`divf`实现整数除法 以下相当于`10 / 2 / 4` 并返回 `1.25`: ```yaml divf 10 2 4 ``` ### mulf 使用`mulf`做乘法 以下会返回`6`: ```yaml mulf 1.5 2 2 ``` ### maxf 返回最大浮点数 以下会返回`3`: ```yaml maxf 1 2.5 3 ``` ### minf 返回最小浮点数 以下会返回 `1.5`: ```yaml minf 1.5 2 3 ``` ### floor 返回小于等于输入值的最大浮点整数。 `floor 123.9999` will return `123.0`。 ### ceil 返回大于等于输入值的最小浮点整数。 `ceil 123.001` will return `124.0`。 ### round 返回一个四舍五入到给定小数位的数。 `round 123.555555 3` will return `123.556`。 ## Network Functions Helm提供了一个网络函数： `getHostByName`. `getHostByName`接收一个域名返回IP地址。 `getHostByName "www.google.com"`会返回对应的`www.google.com`的地址。 ## File Path Functions Helm模板函数没有访问文件系统的权限，提供了遵循文件路径规范的函数。包括[base](#base), [clean](#clean), [dir](#dir), [ext](#ext), 和 [isAbs](#isabs) 。 ### base 返回最后一个元素路径。 ```yaml base "foo/bar/baz" ``` 返回 "baz"。 ### dir 返回目录， 去掉路径的最后一部分。因此 `dir "foo/bar/baz"` 返回 `foo/bar`。 ### clean 清除路径 ```yaml clean "foo/bar/../baz" ``` 上述语句会清理 `..` 并返回`foo/baz`。 ### ext 返回文件扩展。 ```yaml ext "foo.bar" ``` 上述结果为： `.bar`. ### isAbs 检查文件路径是否为绝对路径，使用 `isAbs`。 ## Reflection Functions Helm 提供了基本的反射工具。这有助于高级模板开发者理解特定值的基本Go类型信息。Helm是由Go编写的且是强类型的。 类型系统应用于模板中。 Go 有一些原始 _类型_，比如 `string`, `slice`, `int64`, 和 `bool`。 Go 有一个开放的 _类型_ 系统，允许开发者创建自己的类型。 Helm 通过[kind functions](#kind-functions) 和 [type functions](#type-functions) 提供了一组函数。[deepEqual](#deepequal) 也可以用来比较值。 ### Kind Functions 有两个类型函数： `kindOf` 返回对象类型。 ```yaml kindOf "hello" ``` 上述语句返回 `string`。对于简单测试(比如在`if`块中)，`Kindis`函数可以验证值是否为特定类型： ```yaml kindIs "int" 123 ``` 上述返回 `true`。 ### Type Functions 类型处理起来稍微有点复杂，所以有三个不同的函数： * `typeOf` 返回值的基础类型： `typeOf $foo` * `typeIs` 类似 `kindIs`， 但针对type： `typeIs "*io.Buffer" $myVal` * `typeIsLike` 类似 `typeIs`，除非取消指针引用 **注意：** 这些都不能测试是否实现了给定的接口，因为在这之前需要提前编译接口。 ### deepEqual 如果两个值相比是["deeply equal"](https://golang.org/pkg/reflect/#DeepEqual)，`deepEqual`返回true。 也适用于非基本类型 (相较于内置的 `eq`）。 ```yaml deepEqual (list 1 2 3) (list 1 2 3) ``` 上述会返回 `true`。 ## Semantic Version Functions 有些版本结构易于分析和比较。Helm提供了适用于[SemVer 2](http://semver.org) 版本的函数。包括[semver](#semver)和 [semverCompare](#semvercompare)。下面你也能看到使用范围和比较的细节。 ### semver `semver`函数将字符串解析为语义版本： ```yaml $version := semver "1.2.3-alpha.1+123" ``` _如果解析失败，会由一个错误引起模板执行中断。_ `$version`是一个指向`Version`对象的指针，包含了一下属性： * `$version.Major`: 主版本号 (上面的`1`) * `$version.Minor`: 次版本号 (上面的`2`) * `$version.Patch`: 补丁版本号 (上面的`3`) * `$version.Prerelease`: 预发布版本号 (上面的`alpha.1`) * `$version.Metadata`: 构建元数据 (上面的`123`) * `$version.Original`: 原始版本字符串 另外，你可以使用`Compare`函数比较一个`Version`和另一个`version`： ```yaml semver "1.4.3" | (semver "1.2.3").Compare ``` 上面会返回 `-1`。 返回值可以是： * `-1` 如果给定的版本大于`Compare`方法调用的版本 * `1` 如果`Compare`调用的版本更大 * `0` 如果版本相同 (注意在语义版本中，`Metadata` 字段在版本比较时不比较) ### semverCompare 一个更健壮的比较函数是`semverCompare`。 这个版本支持版本范围： * `semverCompare "1.2.3" "1.2.3"` 检查精确匹配 * `semverCompare "~1.2.0" "1.2.3"` 检查主要版本和次要版本，且补丁版本第二个版本是 _大于等于_ 第一个。 SemVer函数使用[semver规划库](https://github.com/Masterminds/semver)，由Sprig作者创建。 ### 基本比较 两个元素的比较。首先，比较字符串是以空格或逗号分隔的。然后以|| (OR)分隔。比如：`">= 1.2 < 3.0.0 || >= 4.2.3"` 是要比较大于等于1.2且小于等于3.0.0 或者大于等于4.2.3的。 基本比较符有： * `=`: 相等 * `!=`: 不相等 * `>`: 大于 * `<`: 小于 * `>=`: 大于等于 * `<=`: 小于等于 ### 使用预发布版本 预发布版本，对于那些不熟悉它们的人，是用于稳定版本或一般可用版本之前的软件版本。预发布版本的例子包括开发版、 alpha版、beta版，和rc版本。稳定版`1.2.3`的预发布版本可能是`1.2.3-beta.1`，按照优先顺序，预发布版本在相关版本之前发布。 比如：`1.2.3-beta.1 < 1.2.3` 。 根据语义版本指定的预发布版本可能不与对应的发行版本兼容。 > 预发布版本表示版本不稳定且可能不满足其相关正常版本所表示的预期兼容性要求。 使用不带预发布版本比较器约束的语义版本的比较会跳过预发布版本。比如 `>=1.2.3` 会跳过预发布而`>=1.2.3-0`会计算并查找预发布版本。 按照规范，上例中的`0`作为预发布的版本是因为预发布版本只能包含ASCII字母数字和连字符（以及`.`分隔符），并且排序按照ASCII排序顺序。在ASCII排序中，最小的字符是`0`(查看[ASCII表](http://www.asciitable.com/))。 理解ASCII排序顺序很重要因为A-Z是在a-z之前，这意味着`>=1.2.3-BETA` 会返回 `1.2.3-alpha`。这里并不适合大小写敏感，因为是按照ASCII排序规范指定顺序。 ### 连字符范围比较 有多个方法处理范围，首先是连字符范围。像这样： * `1.2 - 1.4.5` 等同于 `>= 1.2 <= 1.4.5` * `2.3.4 - 4.5` 等同于 `>= 2.3.4 <= 4.5` ### 比较中通配符 `x`, `X`, 和 `*` 可用于通配符。适用于所有比较运算符。当使用`=`运算符时，会返回补丁级别的比较。比如： * `1.2.x` 相当于 `>= 1.2.0, < 1.3.0` * `>= 1.2.x` 相当于 `>= 1.2.0` * `<= 2.x` 相当于 `< 3` * `*` 相当于 `>= 0.0.0` ### 波浪符号范围比较 (补丁版本) 波浪 (`~`) 比较运算符是补丁级别范围的比较，在指定次要版本和主要版本变化且没有次要版本时使，比如： * `~1.2.3` 相当于 `>= 1.2.3, < 1.3.0` * `~1` 相当于 `>= 1, < 2` * `~2.3` 相当于 `>= 2.3, < 2.4` * `~1.2.x` 相当于 `>= 1.2.0, < 1.3.0` * `~1.x` 相当于 `>= 1, < 2` ### 插入符号比较 (主要版本) 插入符(`^`)比较运算是主版本级别改变时使用。在1.0.0 发布之前，次要版本充当API稳定级别版本。 当比较主要的API版本更改时，这很有用，比如： * `^1.2.3` 相当于 `>= 1.2.3, < 2.0.0` * `^1.2.x` 相当于 `>= 1.2.0, < 2.0.0` * `^2.3` 相当于 `>= 2.3, < 3` * `^2.x` 相当于 `>= 2.0.0, < 3` * `^0.2.3` 相当于 `>=0.2.3 <0.3.0` * `^0.2` 相当于 `>=0.2.0 <0.3.0` * `^0.0.3` 相当于 `>=0.0.3 <0.0.4` * `^0.0` 相当于 `>=0.0.0 <0.1.0` * `^0` 相当于 `>=0.0.0 <1.0.0` ## URL Functions Helm 包含 [urlParse](#urlparse), [urlJoin](#urljoin), 和[urlquery](#urlquery) 函数可以用做处理URL。 ### urlParse 解析URL的字符串并生成包含URL部分的字典。 ```yaml urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` 上述结果为： 包含URL对象的字典： ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` 这是使用Go标准库中的URL包实现的。更多信息，请查看 https://golang.org/pkg/net/url/#URL。 ### urlJoin 将一个映射(由`urlParse`生成的)连接成URL字符串 ```yaml urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` 上述结果会生成以下字符串： ```yaml http://host:80/path?query#fragment ``` ### urlquery 返回作为参数传入的值的转义版本，这样就可以嵌入到URL的查询部分。 ```yaml $var := urlquery "string for query" ``` ## UUID Functions Helm 可以生成UUID v4 通用唯一ID。 ```yaml uuidv4 ``` 上述结果为： 一个新的v4类型的UUID（随机生成）。 ## Kubernetes and Chart Functions Helm 包含了用于 Kubernetes的函数，包括[.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#file-functions), 和 [lookup](#lookup)。 ### lookup `lookup` 用于在正在运行的集群中查找资源。当和`helm template`命令一起使用时会返回一个空响应。 可以在 [lookup函数文档](./functions_and_pipelines.md#using-the-lookup-function)查看更多细节。 ### .Capabilities.APIVersions.Has 返回API版本或资源是否在集群中可用。 ```yaml .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` 更多信息可查看 [内置对象文档](./builtin_objects.md)。 ### File Functions 有几个函数能使您能够访问chart中的非特殊文件。比如访问应用配置文件。请查看[模板中访问文件](./accessing_files.md)。 _注意，这里很多函数的文档是来自[Sprig](https://github.com/Masterminds/sprig)。Sprig是一个适用于Go应用的函数模板库。_ ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: 模板函数和流水线 description: 使用函数和管道 sidebar_position: 5 --- 到目前为止，我们已经知道了如何将信息传到模板中。 但这些信息会原样放入模板中。 有时我们希望以一种更有用的方式来转换所提供的数据。 让我们从一个最佳实践开始：当把 `.Values` 对象中的字符串注入到模板时，我们应该给这些字符串加上引号。可以通过在模板指令中调用 `quote` 函数来实现： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` 模板函数的语法是 `functionName arg1 arg2...`。在上面的代码片段中，`quote .Values.favorite.drink`调用了`quote`函数并传递了一个参数(`.Values.favorite.drink`)。 Helm 有超过60个可用函数。其中有些通过[Go模板语言](https://godoc.org/text/template)本身定义。其他大部分都是[Sprig 模板库](https://masterminds.github.io/sprig/)。我们可以在示例看到其中很多函数。 > 当我们讨论"Helm模板语言"时，感觉它是Helm专属的，实际上它是Go模板语言、一些额外的函数和用于向模板暴露某些对象的装饰器组合而成的。很多Go模板的资料也有助于你学习模板。 ## 管道符 模板语言的一个强大功能是**管道**概念。借鉴 UNIX 的设计理念，管道是一种将多个模板命令紧凑串联起来的工具，用于表达一系列转换操作。换句话说，管道是按顺序完成一系列任务的高效方式。 现在用管道符重写上述示例： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` 在这个示例中，并不是调用`quote 参数`，而是倒置了命令。使用管道符(`|`)将参数“发送”给函数： `.Values.favorite.drink | quote`。使用管道符可以将很多函数链接在一起： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > 倒置命令是模板中的常见做法。可以经常看到 `.val | quote` 而不是 `quote .val`。实际上两种操作都是可以的。 模板会生成以下内容： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 注意原有的`pizza`现在已经被转换成了`"PIZZA"`。 当使用管道符传递参数时，第一个求值结果（`.Values.favorite.drink`）会作为函数的 _最后一个参数_ 传入。我们可以用一个接收两个参数的函数 `repeat COUNT STRING` 来修改上面的 drink 示例： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` `repeat` 函数会将给定字符串重复指定次数，因此输出如下： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## 使用`default`函数 模板中频繁使用的一个函数是`default`： `default DEFAULT_VALUE GIVEN_VALUE`。 这个函数允许你在模板中指定一个默认值，以防这个值被忽略。现在使用它修改上述示例： ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` 如果运行，会得到 `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` 现在，从`values.yaml`中移除设置： ```yaml favorite: #drink: coffee food: pizza ``` 现在重新运行 `helm install --dry-run --debug fair-worm ./mychart` 会生成如下内容： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` 在实际的chart中，所有的静态默认值应该设置在 `values.yaml` 文件中，且不应该重复使用 `default` 命令 (否则会出现冗余)。然而这个`default` 命令很适合计算值，其不能声明在`values.yaml`文件中，比如： ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` 有些场景，`if`条件比`default`更加适合。在下一章节我们就会看到。 模板函数和管道符是转换信息然后将其插入到YAML中的强有力方式。但是有些时候我们需要插入一些内容之前进行一些逻辑判断，而不仅仅是插入一个字符串。 下一章节，我们会看到模板语言提供的控制结构。 ## 使用`lookup`函数 `lookup` 函数可以用于在运行的集群中 _查找_ 资源。lookup函数简述为查找 `apiVersion, kind, namespace,name -> 资源或者资源列表`。 | parameter | type | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | `name` 和 `namespace` 都是选填的，且可以传空字符串(`""`)作为空。但如果你操作的是 namespace 作用域的资源，则 `name` 和 `namespace` 必须同时指定。 以下是可能的参数组合： | 命令 | Lookup 函数 | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | 当 `lookup` 返回一个对象时，它会返回一个字典。可以进一步导航这个字典来提取特定值。 下面的例子将返回`mynamespace`对象的annotations属性： ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` 当`lookup`返回一个对象列表时，可以通过`items`字段访问对象列表： ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` 当对象未找到时，会返回空值。可以用来检测对象是否存在。 `lookup` 函数使用 Helm 已有的 Kubernetes 连接配置查询 Kubernetes。当与 API 服务器交互时返回错误 （比如缺少资源访问权限），Helm 的模板操作会失败。 请记住，在执行 `helm template|install|upgrade|delete|rollback --dry-run` 操作时，Helm 不会连接 Kubernetes API 服务器。如果需要针对运行中的集群测试 `lookup`，应使用 `helm template|install|upgrade|delete|rollback --dry-run=server` 来允许集群连接。 ## 运算符也是函数 对于模板来说，运算符(`eq`, `ne`, `lt`, `gt`, `and`, `or`等等) 都是作为函数来实现的。 在管道符中，操作可以按照圆括号分组。 现在我们可以从函数和管道符返回到条件控制流，循环和范围修饰符。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: 入门 description: Chart 模板的快速指南。 sidebar_position: 2 --- 本节我们会创建一个 chart 并添加第一个模板。这里创建的 chart 会在后续指南中用到。 接下来，让我们简单看一下 Helm chart。 ## Charts 如 [Charts 指南](/topics/charts.md)所述，Helm chart 的结构如下： ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` `templates/` 目录用于存放模板文件。当 Helm 处理 chart 时，会将 `templates/` 目录中的所有文件传递给模板渲染引擎，然后收集渲染结果并发送到 Kubernetes。 `values.yaml` 文件对模板也很重要。这个文件包含 chart 的**默认值**。用户可以在执行 `helm install` 或 `helm upgrade` 时覆盖这些值。 `Chart.yaml` 文件包含 chart 的描述信息，可以在模板中访问它。 `charts/` 目录**可以**包含其他 chart（称为**子 chart**）。稍后我们会介绍它们在模板渲染时的工作方式。 ## 入门 Chart 在本指南中我们会创建一个名为 `mychart` 的 chart，然后在其中创建一些模板。 ```console $ helm create mychart Creating mychart ``` ### 快速查看 `mychart/templates/` 查看 `mychart/templates/` 目录，你会发现一些已有的文件： - `NOTES.txt`：chart 的"帮助文本"，用户执行 `helm install` 时会显示。 - `deployment.yaml`：创建 Kubernetes [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 的基础清单 - `service.yaml`：为 Deployment 创建 [Service](https://kubernetes.io/docs/concepts/services-networking/service/) 端点的基础清单 - `_helpers.tpl`：存放可在整个 chart 中复用的模板辅助函数 接下来我们要做的是……**把它们全部删掉！** 这样我们就可以从头开始学习。我们会在后续教程中创建自己的 `NOTES.txt` 和 `_helpers.tpl`。 ```console $ rm -rf mychart/templates/* ``` 编写生产级别的 chart 时，保留这些基础文件会很有用。因此在日常开发中，你可能不会删除它们。 ## 第一个模板 我们要创建的第一个模板是 ConfigMap。在 Kubernetes 中，ConfigMap 是一个用于存储配置数据的对象。其他组件（如 Pod）可以访问 ConfigMap 中的数据。 因为 ConfigMap 是基础资源，很适合作为我们的起点。 首先创建文件 `mychart/templates/configmap.yaml`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **提示：** 模板名称没有严格的命名规范。不过建议 YAML 文件使用 `.yaml` 扩展名，辅助模板使用 `.tpl` 扩展名。 上面的 YAML 文件是一个简单的 ConfigMap，包含了最基本的必需字段。由于该文件位于 `mychart/templates/` 目录中，它会经过模板引擎处理。 将这样的普通 YAML 文件放在 `mychart/templates/` 目录中是完全可以的。当 Helm 读取这个模板时，会原样发送给 Kubernetes。 有了这个简单的模板，现在我们有了一个可安装的 chart。安装方式如下： ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` 使用 Helm，我们可以检索 release 并查看实际加载的模板。 ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` `helm get manifest` 命令接受一个 release 名称（`full-coral`），然后输出所有上传到服务器的 Kubernetes 资源。每个文件以 `---` 开头（表示 YAML 文档的开始），后面跟着自动生成的注释行，说明该 YAML 文档由哪个模板文件生成。 从输出可以看到，YAML 数据正是我们在 `configmap.yaml` 文件中定义的内容。 现在卸载 release：`helm uninstall full-coral`。 ### 添加简单的模板调用 将 `name:` 硬编码到资源中不是好的做法。名称应该是唯一的，因此我们可能希望通过插入 release 名称来生成名称字段。 **提示：** 由于 DNS 系统的限制，`name:` 字段长度限制为 63 个字符。因此 release 名称限制为 53 个字符。Kubernetes 1.3 及更早版本限制为 24 个字符（即名称为 14 个字符）。 修改 `configmap.yaml`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` 主要变化是 `name:` 字段的值，现在是 `{{ .Release.Name }}-configmap`。 > 模板指令用 `{{` 和 `}}` 括起来。 模板指令 `{{ .Release.Name }}` 会将 release 名称注入模板。传递给模板的值可以理解为**命名空间对象**，用点（`.`）分隔各个命名空间元素。 `Release` 前面的点表示从当前作用域的顶层命名空间开始（稍后会讨论作用域）。因此 `.Release.Name` 可以理解为"从顶层命名空间开始，找到 `Release` 对象，然后在其中查找名为 `Name` 的对象"。 `Release` 是 Helm 的内置对象之一，稍后会深入讨论。现在只需要知道它可以显示分配给 release 的名称。 现在安装资源，可以立即看到模板指令的效果： ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` 可以运行 `helm get manifest clunky-serval` 查看生成的完整 YAML。 注意 Kubernetes 中的 ConfigMap 名称现在是 `clunky-serval-configmap`，而不是之前的 `mychart-configmap`。 至此我们已经了解了最基本的模板：嵌入了 `{{` 和 `}}` 模板指令的 YAML 文件。下一部分我们会深入了解模板。但在继续之前，有一个小技巧可以加快模板开发速度：如果你想测试模板渲染结果但不实际安装，可以使用 `helm install --debug --dry-run goodly-guppy ./mychart`。这会渲染模板但不安装 chart，而是将渲染后的模板输出到控制台： ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` 使用 `--dry-run` 可以更方便地测试代码，但无法保证 Kubernetes 会接受你生成的模板。不要仅因为 `--dry-run` 正常运行就认为 chart 可以成功安装。 在 [Chart 模板指南](/docs/chart_template_guide/index.mdx)中，我们会以这里定义的基础 chart 为例，详细介绍 Helm 模板语言。接下来从内置对象开始。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: .helmignore 文件 description: "`.helmignore` 文件用于指定不想包含在 Helm chart 中的文件。" sidebar_position: 12 --- `.helmignore` 文件用于指定不想包含在 Helm chart 中的文件。 如果该文件存在，`helm package` 命令会在打包应用时忽略所有匹配 `.helmignore` 文件中指定模式的文件。 这有助于避免将不必要或敏感的文件及目录添加到 Helm chart 中。 `.helmignore` 文件支持 Unix shell 通配符匹配、相对路径匹配以及取反匹配（以 ! 作为前缀）。每行只能指定一种模式。 以下是一个 `.helmignore` 文件示例： ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` 与 `.gitignore` 的一些显著差异： - 不支持 `**` 语法。 - globbing 库使用的是 Go 的 `filepath.Match`，而非 fnmatch(3) - 末尾空格总会被忽略（不支持转义序列） - 不支持 `\!` 作为特殊的前导序列。 - 默认不会排除自身，需要显式添加 `.helmignore` 条目 **我们需要你的帮助**，让这篇文档更加完善。如需添加、修正或删除信息，请[提交 issue](https://github.com/helm/helm-www/issues) 或发起 pull request。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/index.mdx ================================================ --- title: Chart 模板指南 sidebar_position: 5 --- # Chart模板开发者指南 该指南提供 Helm Chart 模板的介绍，重点强调模板语言。 模板会生成 manifest 文件，使用 Kubernetes 可以识别的 YAML 格式描述。我们会看到模板是如何结构化的， 它们如何被使用，如何编写 Go 模板，以及如何调试你们的工作内容。 该指南聚焦于以下概念： - Helm 模板语言 - values 值的使用 - 使用模板工作的技术点 该指南面向学习 Helm 模板语言的来龙去脉。其他指南提供介绍性资料，示例和最佳实践。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: 命名模板 description: 如何定义命名模板 sidebar_position: 9 --- 此时需要越过模板，开始创建其他内容了。该部分我们会看到如何在一个文件中定义 _命名模板_，并在其他地方使用。_命名模板_ (有时称作一个 _部分_ 或一个 _子模板_)仅仅是在文件内部定义的模板，并使用了一个名字。有两种创建方式和几种不同的使用方法。 在[流控制](./control_structures.md)部分， 我们介绍了三种声明和管理模板的方法：`define`，`template`，和`block`。在这部分，我们将使用这三种操作并介绍一种特殊用途的 `include`方法，类似于`template`操作。 命名模板时要记住一个重要细节：**模板名称是全局的**。如果你声明了两个相同名称的模板，哪个最后加载就使用哪个。 因为在子chart中的模板和顶层模板一起编译，命名时要注意 _chart特定名称_。 一个常见的命名惯例是用chart名称作为模板前缀：`{{ define "mychart.labels" }}`。使用特定chart名称作为前缀可以避免可能因为 两个不同chart使用了相同名称的模板而引起的冲突。 这个规则同样适用于chart的不同版本。如果有 `mychart` 的 `1.0.0`版本以一种方式定义了模板， `mychart` 的 `2.0.0` 版本修改了已有的命名模板，那就会使用最后加载的版本。也可以在chart名称中添加版本来解决这个问题： `{{ define "mychart.v1.labels" }}` 和 `{{ define "mychart.v2.labels" }}`。 ## 局部的和`_`文件 目前为止，我们已经使用了单个文件，且单个文件中包含了单个模板。但Helm的模板语言允许你创建命名的嵌入式模板， 这样就可以在其他位置按名称访问。 在编写模板细节之前，文件的命名惯例需要注意： * `templates/`中的大多数文件被视为包含Kubernetes清单 * `NOTES.txt`是个例外 * 命名以下划线(`_`)开始的文件则假定 _没有_ 包含清单内容。这些文件不会渲染为Kubernetes对象定义，但在其他chart模板中都可用。 这些文件用来存储局部和辅助对象，实际上当我们第一次创建`mychart`时，会看到一个名为`_helpers.tpl`的文件，这个文件是模板局部的默认位置。 ## 用`define`和`template`声明和使用模板 `define`操作允许我们在模板文件中创建一个命名模板，语法如下： ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` 比如我们可以定义一个模板封装Kubernetes的标签： ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` 现在我们将模板嵌入到了已有的配置映射中，然后使用`template`包含进来： ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 当模板引擎读取该文件时，它会存储`mychart.labels`的引用直到`template "mychart.labels"`被调用。 然后会按行渲染模板，因此结果类似这样： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 注意：`define`不会有输出，除非像本示例一样用模板调用它。 按照惯例，Helm chart将这些模板放置在局部文件中，一般是`_helpers.tpl`。把这个方法移到那里： ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` 按照惯例`define`方法会有个简单的文档块(`{{/* ... */}}`)来描述要做的事。 尽管这个定义是在`_helpers.tpl`中，但它仍能访问`configmap.yaml`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 如上所述，**模板名称是全局的**。因此，如果两个模板使用相同名字声明，会使用最后出现的那个。由于子chart中的模板和顶层模板一起编译， 最好用 _chart特定名称_ 命名你的模板。常用的命名规则是用chart的名字作为模板的前缀： `{{ define "mychart.labels" }}`。 ## 设置模板范围 在上面定义的模板中，我们没有使用任何对象，仅仅使用了方法。修改定义好的模板让其包含chart名称和版本号： ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` 如果渲染这个，会得到以下错误： ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` 要查看渲染了什么，可以用`--disable-openapi-validation`参数重新执行： `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`。 结果并不是我们想要的： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` 名字和版本号怎么了？没有出现在我们定义的模板中。当一个（使用`define`创建的）命名模板被渲染时，会接收被`template`调用传入的内容。 在我们的示例中，包含模板如下： ```yaml {{- template "mychart.labels" }} ``` 没有内容传入，所以模板中无法用`.`访问任何内容。但这个很容易解决，只需要传递一个范围给模板： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` 注意这个在`template`调用末尾传入的`.`，我们可以简单传入`.Values`或`.Values.favorite`或其他需要的范围。但我们需要的是顶层范围。在命名模板的上下文中，`$` 会引用你传入的范围，而不是某个全局范围。 现在我们可以用`helm install --dry-run --debug plinking-anaco ./mychart`执行模板，然后得到： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` 现在`{{ .Chart.Name }}`解析为`mychart`，`{{ .Chart.Version }}`解析为`0.1.0`。 ## `include`方法 假设定义了一个简单模板如下： ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` 现在假设我想把这个插入到模板的`labels:`部分和`data:`部分： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` 如果渲染这个，会得到以下错误： ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` 要查看渲染了什么，可以用`--disable-openapi-validation`参数重新执行： `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`。 输出不是我们想要的： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` 注意两处的`app_version`缩进都不对，为啥？因为被替换的模板中文本是左对齐的。由于`template`是一个行为，不是方法，无法将 `template`调用的输出传给其他方法，数据只是简单地按行插入。 为了处理这个问题，Helm提供了一个`template`的可选项，可以将模板内容导入当前管道，然后传递给管道中的其他方法。 下面这个示例，使用`indent`正确地缩进了`mychart.app`模板： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` 现在生成的YAML每一部分都可以正确缩进了： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > 相较于使用`template`，在 Helm 中使用`include`被认为是更好的方式， > 只是为了更好地处理YAML文档的输出格式 有时我们需要导入内容，但不是作为模板，也就是按字面意义导入文件内容，可以通过使用`.Files`对象访问文件来实现， 这将在下一部分展开描述。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: 创建 NOTES.txt 文件 description: 如何向 chart 用户提供说明。 sidebar_position: 10 --- 本节介绍 Helm 为 chart 用户提供操作说明的工具。`helm install` 或 `helm upgrade` 完成后，Helm 可以打印一段对用户有帮助的信息，这些信息可以通过模板灵活自定义。 要为 chart 添加安装说明，只需创建 `templates/NOTES.txt` 文件。这个文件是纯文本，但会像模板一样被处理，所有常规的模板函数和对象都可以使用。 下面创建一个简单的 `NOTES.txt` 文件： ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` 现在运行 `helm install rude-cardinal ./mychart`，会在底部看到如下信息： ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` 通过 `NOTES.txt` 可以方便地向用户展示新安装 chart 的使用说明。虽然不是必须的，但强烈建议创建 `NOTES.txt` 文件。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: 子 chart 和全局值 description: 与子 chart 以及全局值进行交互。 sidebar_position: 11 --- 到目前为止，我们只使用了一个 chart。但 chart 可以拥有依赖项，称为 _子 chart_，它们拥有自己的值和模板。本节我们会创建一个子 chart，并了解从模板中访问值的不同方式。 在深入代码之前，需要了解一些关于子 chart 的重要细节： 1. 子 chart 被认为是"独立的"，这意味着子 chart 永远不会显式依赖其父 chart。 2. 因此，子 chart 无法访问父 chart 的值。 3. 父 chart 可以覆盖子 chart 的值。 4. Helm 有一个 _全局值_ 的概念，所有的 chart 都可以访问。 > 这些限制不一定都适用于[库类型 chart（library charts）](/topics/library_charts.md)，它们专门用于提供标准化的辅助功能。 浏览本节的示例之后，这些概念会变得更加清晰。 ## 创建子 chart 在本练习中，我们从本指南开头创建的 `mychart/` 开始，在其中添加一个新 chart。 ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` 注意，和之前一样，我们删除了所有基础模板，从头开始。本指南专注于模板的工作原理，而不是依赖管理。[Chart 指南](/topics/charts.md)提供了更多关于子 chart 运行机制的信息。 ## 在子 chart 中添加值和模板 接下来，为 `mysubchart` 创建一个简单的模板和 values 文件。`mychart/charts/mysubchart` 中应该已经有一个 `values.yaml`，将其内容设置如下： ```yaml dessert: cake ``` 然后，在 `mychart/charts/mysubchart/templates/configmap.yaml` 中创建一个新的 ConfigMap 模板： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` 因为每个子 chart 都是 _独立的 chart_，可以单独测试 `mysubchart`： ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## 用父 chart 的值来覆盖 原来的 chart `mychart` 现在成为了 `mysubchart` 的 _父 chart_。这种关系完全基于 `mysubchart` 位于 `mychart/charts` 目录中这一事实。 因为 `mychart` 是父 chart，我们可以在 `mychart` 中指定配置，并将其推送到 `mysubchart`。例如，可以像这样修改 `mychart/values.yaml`： ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` 注意最后两行。`mysubchart` 部分内的所有指令都会发送到 `mysubchart` chart。因此，如果运行 `helm install --generate-name --dry-run --debug mychart`，会看到 `mysubchart` 的 ConfigMap： ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` 现在，顶层的值已经覆盖了子 chart 的值。 这里有一个重要细节需要注意：我们并没有将 `mychart/charts/mysubchart/templates/configmap.yaml` 模板改为指向 `.Values.mysubchart.dessert`。从该模板的角度来看，值仍然位于 `.Values.dessert`。模板引擎传递值时会设置作用域，因此对于 `mysubchart` 的模板，`.Values` 中只会包含专门针对 `mysubchart` 的值。 但有时你确实希望某些值能对所有模板可用。这可以通过全局 chart 值来实现。 ## 全局 Chart 值 全局值是可以在任何 chart 或子 chart 中以完全相同的名字访问的值。全局值需要显式声明，不能把已有的非全局值当作全局值使用。 Values 数据类型有一个保留部分叫 `Values.global`，可用于设置全局值。我们在 `mychart/values.yaml` 文件中设置一个全局值： ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` 由于全局值的工作方式，`mychart/templates/configmap.yaml` 和 `mysubchart/templates/configmap.yaml` 都可以通过 `{{ .Values.global.salad }}` 来访问该值。 `mychart/templates/configmap.yaml`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` 现在如果执行 dry run 安装，两个输出中会看到相同的值： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` 全局值在这种需要传递信息的场景下很有用，不过确实需要一些规划来确保配置了正确的模板使用全局值。 ## 与子 chart 共享模板 父 chart 和子 chart 可以共享模板。在任意 chart 中定义的块在其他 chart 中也是可用的。 例如，我们可以这样定义一个简单的模板： ```yaml {{- define "labels" }}from: mychart{{ end }} ``` 回想一下，模板中的标签是 _全局共享的_。因此，`labels` 模板可以从任何其他 chart 中引入。 当 chart 开发者需要在 `include` 和 `template` 之间做选择时，使用 `include` 的一个优势是它可以动态引用模板： ```yaml {{ include $mytemplate }} ``` 上述代码会解引用 `$mytemplate`。而 `template` 函数只接受字符串字面量。 ## 避免使用块 Go 模板语言提供了一个 `block` 关键字，允许开发者提供一个默认实现，之后可以被覆盖。在 Helm chart 中，块并不是最佳的覆盖工具，因为如果提供了同一个块的多个实现，无法预测哪个会被选中。 建议改为使用 `include`。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Values 文件 description: "如何使用 --values 参数的说明" sidebar_position: 4 --- 在上一节中，我们了解了 Helm 模板提供的内置对象。其中一个是 `Values` 对象。该对象提供了访问传入 chart 的值的方式。其内容来自多个位置： - chart 中的 `values.yaml` 文件 - 如果是子 chart，则是父 chart 中的 `values.yaml` 文件 - 使用 `-f` 参数（`helm install -f myvals.yaml ./mychart`）传递给 `helm install` 或 `helm upgrade` 的 values 文件 - 使用 `--set` 传递的单个参数（比如 `helm install --set foo=bar ./mychart`） 以上列表按优先级排列：`values.yaml` 是默认值，可以被父 chart 的 `values.yaml` 覆盖，继而被用户提供的 values 文件覆盖，最后被 `--set` 参数覆盖。 Values 文件是普通的 YAML 文件。接下来编辑 `mychart/values.yaml`，然后编辑我们的 ConfigMap 模板。 删除 `values.yaml` 中的默认内容，仅设置一个参数： ```yaml favoriteDrink: coffee ``` 现在可以在模板中使用它： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` 注意最后一行，我们将 `favoriteDrink` 作为 `Values` 的属性进行访问：`{{ .Values.favoriteDrink }}`。 看看渲染结果： ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` 由于默认的 `values.yaml` 文件中将 `favoriteDrink` 的值设置为 `coffee`，这个值就显示在了模板中。我们可以在调用 `helm install` 时添加 `--set` 参数来轻松覆盖这个值： ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` 由于 `--set` 比默认的 `values.yaml` 文件优先级更高，模板就生成了 `drink: slurm`。 Values 文件也可以包含更多结构化的内容。比如，我们可以在 `values.yaml` 文件中创建一个 `favorite` 部分，然后添加多个键： ```yaml favorite: drink: coffee food: pizza ``` 现在需要稍微修改一下模板： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` 虽然可以这样构造数据，但建议保持 values 树的浅层结构，尽量扁平化。当我们后续介绍如何给子 chart 赋值时，你会看到如何使用树结构为值命名。 ## 删除默认的键 如果需要从默认值中删除某个键，可以将该键的值设置为 `null`，这样 Helm 会在合并覆盖值时移除这个键。 比如，稳定版的 Drupal chart 允许在配置自定义镜像时配置活动探针。以下是默认值： ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` 如果你尝试使用 `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]` 将 livenessProbe 处理器从 `httpGet` 覆盖为 `exec`，Helm 会将默认键和覆盖键合并在一起，生成以下 YAML： ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` 但 Kubernetes 不允许声明多个 livenessProbe 处理器，这会导致部署失败。为了解决这个问题，可以通过将 `livenessProbe.httpGet` 设置为 null 来让 Helm 删除它： ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` 至此，我们已经了解了几个内置对象，并使用它们将信息注入到模板中。接下来我们将了解模板引擎的另一方面：函数和管道。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/variables.md ================================================ --- title: 变量 description: 在模板中使用变量。 sidebar_position: 8 --- 掌握了函数、管道符、对象和控制结构之后，我们来看看许多编程语言中更基本的概念之一：变量。在模板中，变量的使用频率较低，但我们会看到如何用它来简化代码，以及更好地配合 `with` 和 `range` 使用。 在之前的例子中，我们看到下面的代码会失败： ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` 不在 `with` 块限制的作用域内。解决作用域问题的一种方法是：将对象赋值给一个变量，这样就可以在任何作用域中访问它。 在 Helm 模板中，变量是对另一个对象的命名引用，格式为 `$name`。变量使用特殊的赋值运算符 `:=` 进行赋值。我们可以用一个变量来保存 `Release.Name`，重写上面的例子： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` 注意，在 `with` 块开始之前，我们先赋值 `$relname := .Release.Name`。这样在 `with` 块内部，`$relname` 变量仍然指向 release 名称。 运行后会生成： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` 变量在 `range` 循环中特别有用。可以用于类似列表的对象，同时捕获索引和值： ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` 注意语法顺序：先是 `range`，然后是变量，然后是赋值运算符，最后是列表。这会将整数索引（从 0 开始）赋值给 `$index`，将值赋值给 `$topping`。运行后会生成： ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` 对于同时具有键和值的数据结构，可以使用 `range` 获取两者。例如，可以这样遍历 `.Values.favorite`： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` 第一次迭代时，`$key` 是 `drink`，`$val` 是 `coffee`；第二次迭代时，`$key` 是 `food`，`$val` 是 `pizza`。运行后会生成： ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` 变量通常不是"全局的"，它们的作用域限定在声明所在的块内。前面我们在模板顶层赋值了 `$relname`，因此该变量在整个模板中都有效。但在最后一个例子中，`$key` 和 `$val` 只在 `{{ range... }}{{ end }}` 块内有效。 不过，有一个变量始终指向根上下文：`$`。当你在 `range` 循环中需要获取 chart 的 release 名称时，这会非常有用。 示例如下： ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` 到目前为止，我们只看了在单个文件中声明的单个模板。但 Helm 模板语言的一个强大特性是能够声明多个模板并组合使用。我们将在下一节讨论这个内容。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: 下一步 description: 收尾——帮助你继续学习的相关文档资源。 sidebar_position: 14 --- 本指南帮助 chart 开发者深入理解 Helm 的模板语言，聚焦于模板开发的技术层面。 不过，涉及 chart 日常开发实践的内容，本指南并未完全覆盖。以下是一些有用的文档资源，可以帮助你创建新的 chart： - CNCF 的 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 是查找 chart 的首选资源。 - Kubernetes [文档](https://kubernetes.io/docs/home/)提供了各种资源类型的详细示例， 从 ConfigMaps 和 Secrets 到 DaemonSets 和 Deployments。 - Helm [Charts 指南](/topics/charts.md)介绍了使用 chart 的工作流。 - Helm [Chart 钩子指南](/topics/charts_hooks.md)说明了如何创建生命周期钩子。 - Helm [Chart 提示与技巧](/howto/charts_tips_and_tricks.md)提供了编写 chart 时的实用技巧。 - [Sprig 文档](https://github.com/Masterminds/sprig)介绍了超过 60 个模板函数。 - [Go 模板文档](https://godoc.org/text/template)详细说明了模板语法。 - [Schelm 工具](https://github.com/databus23/schelm)是调试 chart 的实用工具。 有时直接请教有经验的开发者会更高效。最好的途径是加入 [Kubernetes Slack](https://kubernetes.slack.com) 的 Helm 相关频道： - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) 最后，如果你发现本文档有错误或遗漏，想要推荐新内容，或者想做出贡献，欢迎访问 [Helm 项目](https://github.com/helm/helm-www)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "附录：YAML 技术" description: 深入了解 YAML 规范及其在 Helm 中的应用。 sidebar_position: 15 --- 本指南大部分内容聚焦于模板语言的编写。这里我们来看看 YAML 格式。YAML 有一些实用的特性，作为模板作者，可以利用这些特性让模板更不易出错、更易阅读。 ## 标量和集合 根据 [YAML 规范](https://yaml.org/spec/1.2/spec.html)，有两种集合类型和多种标量类型。 两种集合类型分别是映射（map）和序列（sequence）： ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` 标量值是单个值（与集合相对）。 ### YAML 中的标量类型 在 Helm 使用的 YAML 方言中，值的标量数据类型由一组复杂规则决定，包括 Kubernetes 资源定义的 schema。但在类型推断时，以下规则通常成立。 如果整数或浮点数是不带引号的裸字，通常会被视为数字类型： ```yaml count: 1 size: 2.34 ``` 但如果用引号括起来，则会被视为字符串： ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` 布尔值也是如此： ```yaml isGood: true # bool answer: "true" # string ``` 空值的关键字是 `null`（不是 `nil`）。 注意 `port: "80"` 是合法的 YAML，可以通过模板引擎和 YAML 解析器，但如果 Kubernetes 期望 `port` 是整数，则会失败。 在某些场景中，可以使用 YAML 节点标签强制指定类型： ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` 上例中，`!!str` 告诉解析器 `age` 是字符串，即使它看起来像整数。而 `port` 虽然用引号括起来，也会被视为整数。 ## YAML 中的字符串 YAML 文档中的大部分数据都是字符串。YAML 有多种表示字符串的方式。本节介绍这些方式并演示其中一些的用法。 有三种"内联"方式声明字符串： ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` 所有内联样式必须在一行内。 - 裸字不带引号，也不进行转义。因此，使用时需要注意字符的选择。 - 双引号字符串可以使用 `\` 转义特定字符。例如 `"\"Hello\", she said"`。可以用 `\n` 转义换行。 - 单引号字符串是"字面"字符串，不使用 `\` 转义字符。唯一的转义序列是 `''`，表示单个 `'`。 除了单行字符串，还可以声明多行字符串： ```yaml coffee: | Latte Cappuccino Espresso ``` 上例会将 `coffee` 的值视为单个字符串，等同于 `Latte\nCappuccino\nEspresso\n`。 注意 `|` 后的第一行必须正确缩进。如果这样写就会破坏上面的示例： ```yaml coffee: | Latte Cappuccino Espresso ``` 由于 `Latte` 缩进不正确，会遇到这样的错误： ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` 在模板中，为了避免上述错误，在多行文档中添加一个虚拟的"第一行"内容会更安全： ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` 注意无论第一行是什么，都会保留在字符串输出中。因此，如果你用这种技术将文件内容注入到 ConfigMap 中，注释应该是读取该条目的程序所期望的类型。 ### 控制多行字符串中的空格 在上面的示例中，我们用 `|` 表示多行字符串。但注意字符串内容后面有一个尾随的 `\n`。如果希望 YAML 处理器去掉尾随换行符，可以在 `|` 后添加 `-`： ```yaml coffee: |- Latte Cappuccino Espresso ``` 现在 `coffee` 的值是：`Latte\nCappuccino\nEspresso`（没有尾随的 `\n`）。 有时我们希望保留所有尾随空白。可以使用 `|+` 符号： ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` 现在 `coffee` 的值是 `Latte\nCappuccino\nEspresso\n\n\n`。 文本块内的缩进会被保留，换行符也会保留： ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` 上例中，`coffee` 的值是 `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`。 ### 缩进和模板 编写模板时，你可能想将文件内容注入到模板中。如前面章节所述，有两种方法： - 使用 `{{ .Files.Get "FILENAME" }}` 获取 chart 中的文件内容。 - 使用 `{{ include "TEMPLATE" . }}` 渲染模板并将其内容放入 chart。 将文件插入 YAML 时，理解上面的多行规则很重要。通常，插入静态文件最简单的方式是这样： ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` 注意上面的缩进方式：`indent 2` 告诉模板引擎将 "myfile.txt" 的每一行缩进两个空格。注意模板行本身没有缩进。因为如果缩进了，文件内容的第一行会被缩进两次。 ### 折叠多行字符串 有时你想在 YAML 中用多行表示一个字符串，但希望解析时将其视为一个长行。这称为"折叠"。要声明折叠块，使用 `>` 代替 `|`： ```yaml coffee: > Latte Cappuccino Espresso ``` 上例中 `coffee` 的值是：`Latte Cappuccino Espresso\n`。注意除了最后一个换行符外，所有换行符都会转换为空格。可以将空白控制符与折叠文本标记组合使用，`>-` 会替换或去除所有换行符。 注意在折叠语法中，缩进的文本会保留行。 ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` 上例的结果是 `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`。注意空格和换行符都保留了。 ## 在一个文件中嵌入多个文档 可以将多个 YAML 文档放在单个文件中。方法是在新文档前加 `---`，在文档结尾加 `...`： ```yaml --- document: 1 ... --- document: 2 ... ``` 很多情况下，`---` 或 `...` 可以省略。 Helm 中有些文件不能包含多个文档。例如，如果 `values.yaml` 文件中提供了多个文档，只会使用第一个。 但模板文件可以有多个文档。这种情况下，文件（及其所有文档）在模板渲染时被视为一个对象。但生成的 YAML 在传给 Kubernetes 之前会被拆分成多个文档。 我们建议只在确实需要时才在单个文件中使用多个文档。单个文件中有多个文档会难以调试。 ## YAML 是 JSON 的超集 由于 YAML 是 JSON 的超集，任何合法的 JSON 文档 _都应该_ 是合法的 YAML。 ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` 上面是以下内容的另一种表示方式： ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` 两者也可以混合使用（但要小心）： ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` 这三种写法都会解析为相同的内部表示。 虽然这意味着 `values.yaml` 等文件可以包含 JSON 数据，但 Helm 不会将 `.json` 后缀的文件视为有效文件。 ## YAML 锚点 YAML 规范提供了一种存储值引用、然后通过引用使用该值的方式。YAML 将此称为"锚定"： ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` 上例中，`&favoriteCoffee` 设置了对 `Cappuccino` 的引用。之后通过 `*favoriteCoffee` 使用该引用。这样 `coffees` 就变成了 `Latte, Cappuccino, Espresso`。 锚点在某些场景中很有用，但有一个方面可能会导致微妙的 bug：第一次解析 YAML 时，引用会被展开然后丢弃。 因此，如果我们解码再重新编码上面的示例，生成的 YAML 会是这样： ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` 由于 Helm 和 Kubernetes 经常读取、修改然后重写 YAML 文件，锚点会丢失。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/example/golang.md ================================================ # 基于GO语言的集成开发示例 ## 环境 - go version 1.20.x - helm v3 - kubernetes 1.24.x ## 示例 ### 增加仓库 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/getter" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 添加一个仓库地址 // Helm 的添加仓库地就是将【仓库名+仓库地址】写到一个本地的repositories.yaml文件中 func add(entry *repo.Entry) error { settings := cli.New() repoFile := settings.RepositoryConfig // 加载仓库配置文件 repositories, err := repo.LoadFile(repoFile) // 如果文件不存在 if err != nil { // 创建一个新的仓库配置对象 repositories = repo.NewFile() } // 检查要添加的仓库是否已存在 if repositories.Has(entry.Name) { return fmt.Errorf("仓库 %s 已存在", entry.Name) } // 添加仓库信息到仓库配置 repositories.Add(entry) // 保存更新后的仓库配置到文件 if err = repositories.WriteFile(repoFile, 0644); err != nil { return fmt.Errorf("无法保存仓库配置文件：%s", err) } logger.Debugf("成功添加仓库地址：%s。", entry.Name) return nil } ``` - > 此功能相当于: helm repo add 仓库名 https://xxx.com ### 检索仓库 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/getter" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 查看仓库信息 func list() ([]*repo.Entry, error) { settings := cli.New() // 加载仓库配置文件 repositories, err := repo.LoadFile(settings.RepositoryConfig) if err != nil { return nil, fmt.Errorf("无法保存仓库配置文件：%s", err) } return repositories.Repositories, nil } ``` - > 此功能相当于: helm repo list ### 删除仓库 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/getter" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 删除一个仓库地址 // repoName 仓库名 func remove(repoName string) error { settings := cli.New() repoFile := settings.RepositoryConfig // 加载仓库配置文件 repositories, err := repo.LoadFile(repoFile) if err != nil { return fmt.Errorf("无法加载仓库配置文件：%s", err) } // 检查要删除的仓库是否存在 if !repositories.Has(repoName) { return fmt.Errorf("仓库 %s 不存在", repoName) } // 从仓库配置中删除仓库 result := repositories.Remove(repoName) // 保存更新后的仓库配置到文件 if err = repositories.WriteFile(repoFile, 0644); err != nil || !result { return fmt.Errorf("无法保存仓库配置文件：%s", err) } logger.Debugf("成功删除仓库地址: %s。", repoName) return nil } ``` - > 此功能相当于: helm repo remove 仓库名 ### 更新仓库 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/getter" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 更新仓库的Helm Chart仓库 func update() (string, error) { settings := cli.New() // 加载仓库配置文件 repositories, err := repo.LoadFile(settings.RepositoryConfig) if err != nil { return "", fmt.Errorf("无法加载仓库配置文件：%s", err) } // 遍历每个仓库 for _, repoEntry := range repositories.Repositories { // 添加要检索的仓库 chartRepository, err := repo.NewChartRepository(repoEntry, getter.All(settings)) if err != nil { return "", fmt.Errorf("无法添加仓库：%s\n", err) } // 更新仓库索引信息 if _, err := chartRepository.DownloadIndexFile(); err != nil { return "", fmt.Errorf("无法下载仓库索引：%s\n", err) } logger.Debugf("...Successfully got an update from the %s chart repository", repoEntry.Name) } return "Update Complete. ⎈Happy Helming!⎈", nil } ``` - > 此功能相当于: helm repo update ### 检索指定仓库中的Chart信息 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 查看指定仓库中最新的Chart信息 // search(仓库名) func search(repoName string) ([]*ChartListResponse, error) { settings := cli.New() path := fmt.Sprintf("%s/%s-index.yaml", settings.RepositoryCache, repoName) // 加载 xxx-index.yaml 文件 indexFile, err := repo.LoadIndexFile(path) if err != nil { return nil, fmt.Errorf("仓库 %s 不存在", repoName) } var chartList []*ChartListResponse // 遍历指定仓库的 Chart 信息 for _, entry := range indexFile.Entries { // 将每个 Chart 的最新信息提取出来 chart := &ChartListResponse{ ChartName: entry[0].Name, ChartVersion: entry[0].Version, AppVersion: entry[0].AppVersion, Description: entry[0].Description, } chartList = append(chartList, chart) } // 指定仓库的Chart信息 logger.Debugf("%s", chartList) return chartList, nil } ``` - > 此功能相当于: helm search repo 仓库名 ### 检索指定仓库中Chart的所有版本信息 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/repo" "kube-store-operator/commons/logger" ) // 查看指定仓库的Chart所有版本信息 // searchAll(仓库名, Chart名) func searchAll(repoName, chartName string) ([]*ChartListResponse, error) { settings := cli.New() path := fmt.Sprintf("%s/%s-index.yaml", settings.RepositoryCache, repoName) // 加载 xxx-index.yaml 文件 indexFile, err := repo.LoadIndexFile(path) if err != nil { return nil, fmt.Errorf("仓库 %s 不存在", repoName) } var chartList []*ChartListResponse // 遍历指定仓库的 Chart 信息 for _, entry := range indexFile.Entries[chartName] { // 将每个 Chart 的主要信息提取出来 chart := &ChartListResponse{ ChartName: entry.Name, ChartVersion: entry.Version, AppVersion: entry.AppVersion, Description: entry.Description, } chartList = append(chartList, chart) } // 指定仓库的Chart信息 logger.Debugf("%s", chartList) return chartList, nil } ``` - > 此功能相当于: helm search repo 仓库名 -l ### 将Chart安装部署到kubernetes - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "kube-store-operator/commons/logger" "os" ) // 安装Helm Chart func installChart(deployRequest *DeployRequest) error { settings := cli.New() actionConfig := new(action.Configuration) if err := actionConfig.Init(settings.RESTClientGetter(), deployRequest.Namespace, os.Getenv("HELM_DRIVER"), logger.Debugf); err != nil { return fmt.Errorf("初始化 action 失败\n%s", err) } install := action.NewInstall(actionConfig) install.RepoURL = deployRequest.RepoURL install.Version = deployRequest.ChartVersion install.Timeout = 30e9 install.CreateNamespace = true install.Wait = true // kubernetes 中的配置 install.Namespace = deployRequest.Namespace install.ReleaseName = deployRequest.ReleaseName chartRequested, err := install.ChartPathOptions.LocateChart(deployRequest.ChartName, settings) if err != nil { return fmt.Errorf("下载失败\n%s", err) } chart, err := loader.Load(chartRequested) if err != nil { return fmt.Errorf("加载失败\n%s", err) } _, err = install.Run(chart, nil) if err != nil { return fmt.Errorf("执行失败\n%s", err) } return nil } ``` - > 此功能相当于: helm install ### 将Chart从kubernetes中卸载 - ``` go package kubestore import ( "fmt" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "kube-store-operator/commons/logger" "os" ) // 卸载Helm Chart func uninstallChart(namespace, releaseName string) error { settings := cli.New() actionConfig := new(action.Configuration) if err := actionConfig.Init(settings.RESTClientGetter(), namespace, os.Getenv("HELM_DRIVER"), logger.Debugf); err != nil { return fmt.Errorf("初始化 action 失败\n%s", err) } uninstall := action.NewUninstall(actionConfig) uninstall.Timeout = 30e9 // 设置超时时间300秒 uninstall.KeepHistory = false resp, err := uninstall.Run(releaseName) if err != nil { return fmt.Errorf("卸载失败\n%s", err) } logger.Infof("%s 成功卸载\n", resp.Release.Name) return nil } ``` - > 此功能相当于: helm uninstall ### 代码中用到的实体对象 - ``` go package kubestore // DeployRequest /** * 部署时用到的结构体 */ type DeployRequest struct { RepoURL string // 仓库地址 ChartName string // Chart名称 ChartVersion string // Chart版本 Namespace string // 命名空间 ReleaseName string // 在kubernetes中的程序名 Values map[string]interface{} // values.yaml 配置文件 } // --------------------------------------------------------------- // ChartListResponse /** * 返回指定仓库中的所有Chart信息 */ type ChartListResponse struct { ChartName string // Chart名称 ChartVersion string // Chart版本 AppVersion string // 应用版本 Description string // 描述 } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/example/index.mdx ================================================ --- title: 集成开发 sidebar_position: 10 --- # 集成开发 此文档的需要对于`helm cli`的使用有一定的了解 文档的目的是为了降低集成开发初学者的学习门槛，并提供有关开发Operator的指导。 对于那些计划自己开发一个Operator的开发者，这份文档可能会提供宝贵的帮助和指引。 它包含了关于如何集成SDK的实际案例，以及如何在开发Operator时有效地利用集成开发环境。 通过这份文档，读者可以更轻松地理解和应用SDK集成封装案例，同时也能够掌握开发Operator的关键步骤和技巧。 SDK集成开发案例： - [Golang](/example/golang.md) import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Helm 2 以来的变化 sidebar_position: 1 --- ## Helm 2 以来的变化 本文详细列出了 Helm 3 引入的所有主要变化。 ### 移除 Tiller 在 Helm 2 的开发周期中，我们引入了 Tiller。Tiller 在团队共享集群时发挥了重要作用——它使多个不同的操作人员能够与同一组 release 交互。 随着 Kubernetes 1.6 默认启用基于角色的访问控制（RBAC），在生产环境中锁定 Tiller 的使用变得更加困难。由于可能存在大量的安全策略配置，我们的立场是提供一个宽松的默认配置。这使得新用户无需深入了解安全控制就能开始尝试 Helm 和 Kubernetes。但遗憾的是，这种宽松的配置可能会赋予用户超出预期的广泛权限。DevOps 和 SRE 在多租户集群中安装 Tiller 时需要学习额外的操作步骤。 在了解了社区成员在某些场景中如何使用 Helm 之后，我们发现 Tiller 的 release 管理系统不需要依赖集群内的操作器来维护状态或充当 Helm release 信息的中心枢纽。相反，我们可以直接从 Kubernetes API server 获取信息，在客户端渲染 chart，并在 Kubernetes 中存储安装记录。 Tiller 的主要功能可以在没有 Tiller 的情况下实现，因此我们在 Helm 3 中做出的首要决定之一就是完全移除 Tiller。 移除 Tiller 后，Helm 的安全模型得到了根本简化。Helm 3 现在支持现代 Kubernetes 的所有安全、身份认证和授权功能。Helm 的权限通过 [kubeconfig 文件](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 进行评估。集群管理员可以根据需要在任意粒度上限制用户权限。release 仍然记录在集群内，Helm 的其余功能保持不变。 ### 改进的升级策略：三方战略合并补丁 Helm 2 使用两方战略合并补丁。在升级过程中，它会比较最近一次 chart 的 manifest 与新 chart 的 manifest（即 `helm upgrade` 时提供的 manifest）。它通过比较这两个 chart 的差异来确定需要对 Kubernetes 中的资源进行哪些更改。如果通过带外方式对集群进行了更改（例如通过 `kubectl edit`），这些更改不会被考虑。这导致资源无法回滚到之前的状态：因为 Helm 只将最后应用的 chart manifest 视为当前状态，如果 chart 状态没有变化，实际运行状态也不会被修改。 在 Helm 3 中，我们现在使用三方战略合并补丁。Helm 在生成补丁时会同时考虑旧的 manifest、实际运行状态和新的 manifest。 #### 示例 让我们通过几个常见示例来说明这一变化的影响。 ##### 实际运行状态已更改时的回滚 你的团队刚刚使用 Helm 在 Kubernetes 上将应用部署到生产环境。chart 中的 Deployment 对象的副本数设置为三个： ```console $ helm install myapp ./myapp ``` 一位新开发人员加入了团队。在他们入职第一天观察生产集群时，发生了一起可怕的咖啡洒在键盘上的事故，他们不小心将生产 deployment 的副本数从三个 `kubectl scale` 到了零： ```console $ kubectl scale --replicas=0 deployment/myapp ``` 团队中的另一位开发人员注意到生产站点宕机了，决定将 release 回滚到之前的状态： ```console $ helm rollback myapp ``` 会发生什么？ 在 Helm 2 中，它会比较旧 manifest 和新 manifest 来生成补丁。由于这是回滚，所以是同一个 manifest。Helm 会认为旧 manifest 和新 manifest 没有区别，因此无需更改。副本数继续保持为零。问题来了。 在 Helm 3 中，补丁是使用旧 manifest、实际运行状态和新 manifest 生成的。Helm 识别出旧状态是三个副本，实际运行状态是零，而新 manifest 希望将其改回三个，因此它会生成一个补丁将状态改回三个副本。 ##### 实际运行状态已更改时的升级 许多服务网格和其他基于控制器的应用会向 Kubernetes 对象注入数据。这可能是 sidecar、标签或其他信息。假设你有一个从 chart 渲染的 manifest： ```yaml containers: - name: server image: nginx:2.0.0 ``` 而实际运行状态已被另一个应用修改为： ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` 现在，你想将 `nginx` 镜像标签升级到 `2.1.0`。于是你升级到一个包含以下 manifest 的 chart： ```yaml containers: - name: server image: nginx:2.1.0 ``` 会发生什么？ 在 Helm 2 中，Helm 会根据旧 manifest 和新 manifest 生成 `containers` 对象的补丁。在生成补丁时不会考虑集群的实际运行状态。 集群的实际运行状态会被修改为： ```yaml containers: - name: server image: nginx:2.1.0 ``` sidecar 容器从实际运行状态中被移除。麻烦大了。 在 Helm 3 中，Helm 会根据旧 manifest、实际运行状态和新 manifest 生成 `containers` 对象的补丁。它注意到新 manifest 将镜像标签更改为 `2.1.0`，同时实际运行状态包含一个 sidecar 容器。 集群的实际运行状态会被修改为： ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Release 名称现在限定在 namespace 范围内 随着 Tiller 的移除，每个 release 的信息需要存储在某个地方。在 Helm 2 中，这些信息存储在与 Tiller 相同的 namespace 中。实际上，这意味着一旦某个名称被某个 release 使用，其他 release 就无法使用该名称，即使它部署在不同的 namespace 中。 在 Helm 3 中，特定 release 的信息现在存储在与 release 本身相同的 namespace 中。这意味着用户现在可以在两个不同的 namespace 中分别 `helm install wordpress stable/wordpress`，并且可以通过切换当前 namespace 上下文来使用 `helm list` 查看各自的 release（例如 `helm list --namespace foo`）。 由于与原生集群 namespace 更好地对齐，`helm list` 命令默认不再列出所有 release。相反，它只会列出当前 Kubernetes 上下文所在 namespace 中的 release（即运行 `kubectl config view --minify` 时显示的 namespace）。这也意味着你必须在 `helm list` 中提供 `--all-namespaces` 参数才能获得与 Helm 2 类似的行为。 ### Secrets 作为默认存储驱动 在 Helm 3 中，Secrets 现在被用作[默认存储驱动](/topics/advanced.md#storage-backends)。Helm 2 默认使用 ConfigMaps 来存储 release 信息。在 Helm 2.7.0 中，实现了一个使用 Secrets 存储 release 信息的新存储后端，这在 Helm 3 中成为了默认设置。 将 Secrets 作为 Helm 3 的默认设置，结合 Kubernetes 中 Secret 加密的发布，可以为保护 chart 提供额外的安全性。 [静态加密 Secrets](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) 在 Kubernetes 1.7 中作为 Alpha 功能提供，并在 Kubernetes 1.13 中成为稳定版。这允许用户对 Helm release 元数据进行静态加密，因此这是一个很好的起点，以后可以扩展到使用 Vault 等工具。 ### Go 导入路径变更 在 Helm 3 中，Helm 将 Go 导入路径从 `k8s.io/helm` 更改为 `helm.sh/helm/v3`。如果你打算升级到 Helm 3 Go 客户端库，请确保更改你的导入路径。 ### Capabilities 在渲染阶段可用的 `.Capabilities` 内置对象已被简化。 [内置对象](/chart_template_guide/builtin_objects.md) ### 使用 JSONSchema 验证 Chart Values 现在可以对 chart values 施加 JSON Schema。这确保用户提供的 values 符合 chart 维护者制定的 schema，在用户为 chart 提供不正确的 values 时提供更好的错误报告。 当调用以下任何命令时会进行验证： * `helm install` * `helm upgrade` * `helm template` * `helm lint` 有关更多信息，请参阅 [Schema 文件](/topics/charts.md#schema-files) 文档。 ### 将 `requirements.yaml` 合并到 `Chart.yaml` chart 依赖管理系统从 requirements.yaml 和 requirements.lock 迁移到了 Chart.yaml 和 Chart.lock。我们建议用于 Helm 3 的新 chart 使用新格式。但是，Helm 3 仍然可以理解 Chart API 版本 1（`v1`），并会加载现有的 `requirements.yaml` 文件。 在 Helm 2 中，`requirements.yaml` 如下所示： ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` 在 Helm 3 中，依赖项以相同的方式表达，但现在位于 `Chart.yaml` 中： ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` chart 仍然会被下载并放置在 `charts/` 目录中，因此已经放入 `charts/` 目录的子 chart 将继续正常工作，无需修改。 ### 安装时现在必须提供名称（或 --generate-name） 在 Helm 2 中，如果未提供名称，则会生成一个自动名称。在生产环境中，这被证明更多是一个麻烦而不是有用的功能。在 Helm 3 中，如果 `helm install` 未提供名称，Helm 将抛出错误。 对于仍然希望自动生成名称的用户，可以使用 `--generate-name` 参数。 ### 推送 Chart 到 OCI 注册中心 这是 Helm 3 中引入的实验性功能。要使用此功能，请设置环境变量 `HELM_EXPERIMENTAL_OCI=1`。 从宏观角度来看，chart 仓库是存储和共享 chart 的地方。Helm 客户端将 Helm chart 打包并发布到 chart 仓库。简单来说，chart 仓库是一个托管了 index.yaml 文件和一些打包 chart 的基本 HTTP 服务器。 虽然 chart 仓库 API 在满足最基本的存储需求方面有几个优点，但一些缺点已经开始显现： - chart 仓库很难抽象出生产环境中所需的大多数安全实现。在生产场景中，拥有一个标准的认证和授权 API 非常重要。 - Helm 用于签名和验证 chart 完整性和来源的 chart 来源工具是 chart 发布流程中的可选部分。 - 在多租户场景中，同一个 chart 可能被另一个租户上传，导致存储相同内容需要两倍的存储成本。更智能的 chart 仓库已经被设计来处理这个问题，但这不是正式规范的一部分。 - 使用单个索引文件进行搜索、元数据信息和获取 chart，使得在安全的多租户实现中设计起来变得困难或笨拙。 Docker 的 Distribution 项目（也称为 Docker Registry v2）是 Docker Registry 项目的继任者。许多主要云厂商都提供 Distribution 项目的产品，随着如此多的厂商提供相同的产品，Distribution 项目受益于多年的加固、安全最佳实践和实战测试。 请查看 `helm help chart` 和 `helm help registry` 了解有关如何打包 chart 并推送到 Docker 注册中心的更多信息。 有关更多信息，请参阅[此页面](/topics/registries.md)。 ### 移除 `helm serve` `helm serve` 在你的机器上运行一个本地 chart 仓库用于开发目的。然而，它作为开发工具并未获得太多采用，而且在设计上存在诸多问题。最终，我们决定移除它并将其拆分为一个插件。 如需获得类似 `helm serve` 的体验，请查看 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 中的本地文件系统存储选项和 [servecm 插件](https://github.com/jdolitsky/helm-servecm)。 ### Library chart 支持 Helm 3 支持一类称为"library chart"的 chart。这是一种被其他 chart 共享但本身不创建任何 release 产物的 chart。library chart 的模板只能声明 `define` 元素。全局作用域的非 `define` 内容会被忽略。这允许用户复用和共享可在多个 chart 中使用的代码片段，避免冗余并保持 chart 的 [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 原则。 library chart 在 Chart.yaml 的 dependencies 指令中声明，并像任何其他 chart 一样进行安装和管理。 ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` 我们非常期待看到此功能为 chart 开发者带来的用例，以及使用 library chart 时产生的最佳实践。 ### Chart.yaml apiVersion 升级 随着 library chart 支持的引入以及 requirements.yaml 合并到 Chart.yaml，理解 Helm 2 包格式的客户端将无法理解这些新功能。因此，我们将 Chart.yaml 中的 apiVersion 从 `v1` 升级到 `v2`。 `helm create` 现在会使用这种新格式创建 chart，因此默认的 apiVersion 也相应升级。 希望支持两个版本 Helm chart 的客户端应该检查 Chart.yaml 中的 `apiVersion` 字段来了解如何解析包格式。 ### XDG 基础目录支持 [XDG 基础目录规范](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) 是一个可移植的标准，定义了配置、数据和缓存文件应该存储在文件系统的哪个位置。 在 Helm 2 中，Helm 将所有这些信息存储在 `~/.helm`（亲切地称为 `helm home`），可以通过设置 `$HELM_HOME` 环境变量或使用全局参数 `--home` 来更改。 在 Helm 3 中，Helm 现在按照 XDG 基础目录规范遵循以下环境变量： - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Helm 插件仍然会收到 `$HELM_HOME` 作为 `$XDG_DATA_HOME` 的别名，以便向后兼容那些将 `$HELM_HOME` 用作临时环境的插件。 为了适应这一变化，还有几个新的环境变量被传递到插件环境中： - `$HELM_PATH_CACHE` 用于缓存路径 - `$HELM_PATH_CONFIG` 用于配置路径 - `$HELM_PATH_DATA` 用于数据路径 希望支持 Helm 3 的 Helm 插件应该考虑使用这些新的环境变量。 ### CLI 命令重命名 为了更好地与其他包管理器的用语保持一致，`helm delete` 被重命名为 `helm uninstall`。`helm delete` 仍然保留为 `helm uninstall` 的别名，因此两种形式都可以使用。 在 Helm 2 中，要清除 release 记录，需要提供 `--purge` 参数。此功能现在默认启用。要保留之前的行为，请使用 `helm uninstall --keep-history`。 此外，还有其他几个命令被重命名以适应相同的约定： - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` 这些命令也保留了旧名称作为别名，因此你可以继续使用任一形式。 ### 自动创建 namespace 当在不存在的 namespace 中创建 release 时，Helm 2 会创建该 namespace。Helm 3 遵循其他 Kubernetes 工具的行为，如果 namespace 不存在则返回错误。如果你明确指定 `--create-namespace` 参数，Helm 3 会创建该 namespace。 ### .Chart.ApiVersion 发生了什么变化？ Helm 遵循驼峰命名的典型约定，即将首字母缩写词大写。我们在代码的其他地方也这样做了，例如 `.Capabilities.APIVersions.Has`。在 Helm v3 中，我们纠正了 `.Chart.ApiVersion` 以遵循这一模式，将其重命名为 `.Chart.APIVersion`。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/faq/index.mdx ================================================ --- title: 常见问答(FAQ) sidebar_position: 8 --- # 常见问答 > Helm 2和Helm 3的主要区别是什么? > 该页面为最常见的问题提供帮助。 **我们喜欢您的帮助** 使得该文档变得更好。添加、修改或移除信息, [提问题](https://github.com/helm/helm-www/issues)或者向我们提交pull request。 ## 从Helm 2发生的变化 这里会展示一个对Helm3主要引入的变化的详尽列表。 ### 移除了Tiller 在Helm 2的开发周期中，我们引入了Tiller。Tiller在团队协作中共享集群时扮演了重要角色。 它使得不同的操作员与相同的版本进行交互称为了可能。 Kubernetes 1.6默认使用了基于角色的访问控制（RBAC），在生产环境对Tiller的锁定使用变得难于管理。 由于大量可能的安全策略，我们的立场是提供一个自由的默认配置。这样可以允许新手用户可以乐于尝试Helm 和Kubernetes而不需要深挖安全控制。 不幸的是这种自由的配置会授予用户他们不该有的权限。DevOps和SRE 在安装多用户集群时不得不去学习额外的操作步骤。 在听取了社区成员在特定场景使用Helm之后，我们发现Tiller的版本管理系统不需要依赖于集群内部用户去维护 状态或者作为一个Helm版本信息的中心hub。取而代之的是，我们可以简单地从Kubernetes API server获取信息， 在Chart客户端处理并在Kubernetes中存储安装记录。 Tiller的首要目标可以在没有Tiller的情况下实现，因此针对于 Helm 3 我们做的首要决定之一就是完全移除Tiller。 随着Tiller的消失，Helm的安全模块从根本上被简化。Helm 3 现在支持所有Kubernetes流行的安全、 身份和授权特性。Helm的权限通过你的 [kubeconfig文件](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)进行评估。 集群管理员可以限制用户权限，只要他们觉得合适， 无论什么粒度都可以做到。版本发布记录和Helm的剩余保留功能仍然会被记录在集群中。 ### 改进升级策略: 三路策略合并补丁 Helm 2 使用了一种双路策略合并补丁。在升级过程中，会对比最近一次的chart manifest和提出的 chart manifest(通过`helm upgrade`提供)。升级会对比两个chart的不同来决定哪些更改会应用到Kubernetes资源中。 如果更改是集群外带的（比如通过`kubectl edit`），则不会被考虑。结果就是资源不会回滚到之前的状态： 因为Helm只考虑最后一次应用的chart manifest作为它的当前状态，如果chart状态没有更改，则资源的活动状态不会更改。 现在Helm 3中，我们使用一种三路策略来合并补丁。Helm在生成一个补丁时会考虑之前老的manifest的活动状态。 #### 示例 让我们通过一些常见的例子来看看变化带来的影响。 ##### 回滚已经改变的活动状态 你的团队正好在Kubernetes上使用Helm部署了生产环境应用。chart包含了一个部署对象使用了三套副本： ```console $ helm install myapp ./myapp ``` 一个开发新人加入了团队。当他们第一点观察生产环境集群时，发生了一个像是咖啡洒在了键盘上一样的严重事故， 他们使用 `kubectl scale` 对生产环境部署进行缩容，将副本数从3降到了0 。 ```console $ kubectl scale --replicas=0 deployment/myapp ``` 团队里面的另一个人看到线上环境已经挂了就决定回滚这个版本到之前的状态： ```console $ helm rollback myapp ``` 发生了什么？ 在Helm 2中，会生成一个补丁并对比老的manifest和新的manifest。因为这是一个回滚，manifest是一样的。 Helm会认为新老manifest没有区别，因此没有需要更改的内容。副本统计数量继续保持为0。恐慌就接踵而至。 在Helm 3中，是用老的manifest生成新的补丁，活动状态和新的manifest。 Helm 意识到老的状态是3，而现有活动状态是0，并且新的manifest希望改回3，因此会生成一个补丁将状态改回3。 ##### 活动状态已更改的情况下升级 很多服务网格和其他基于controller的应用向Kubernetes对象中注入数据。比如sidecar、label和其他信息。 之前如果你从Chart渲染给定的manifest如下: ```yaml containers: - name: server image: nginx:2.0.0 ``` 并且另一个应用修改活动状态如下： ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` 现在你想升级`nginx`镜像到`2.1.0`。因此用指定的manifest升级chart： ```yaml containers: - name: server image: nginx:2.1.0 ``` 发生了什么？ 在Helm 2中，Helm 在新老manifest之间生成了一个`containers`对象的补丁。 生成补丁的过程中不考虑集群的活动状态。 集群的活动状态被修改成了这样: ```yaml containers: - name: server image: nginx:2.1.0 ``` sidecar pod从活动状态中移除了。更多的恐慌袭来。 在Helm 3中，Helm 在新的manifest、活动状态和老manifest之间生成了一个`containers`对象的补丁。 会注意到新的manifest将镜像tag更新为`2.1.0`, 但是活动状态中包含了一个sidecar容器。 集群的活动状态被修改成了下面这样： ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### 发布名称现在限制在namespace范围内 随着Tiller的移除， 每个版本的信息需要保存在某个地方。 在Helm 2中，是存储在Tiller相同的命名空间中。 实际上这意味着一个发布版本使用一个名称，其他发布不能使用相同的名称， 即使在不同的命名空间中也不行。 在Helm 3中，特定的版本信息作为发布本身存储在相同的命名空间中。 意味着用户现在可以在两个分开的命名空间中使用`helm install wordpress stable/wordpress`， 并且每个都能使用 `helm list` 改变当前命名空间。 (例如 `helm list --namespace foo`)。 与本地集群命名空间更好的一致性，使得 `helm list` 命令不再需要默认列出所有发布版本的列表。 取而代之的是，仅仅会在命名空间中列出当前kubernetes上下文的版本。 (也就是说运行`kubectl config view --minify`时会显示命名空间). 也就意味着您在执行`helm list`时必须提供 `--all-namespaces` 标识才能获得和Helm 2同样的结果。 ### 作为默认存储器的密钥 在 Helm 3中, 密钥被作为[默认存储驱动](/topics/advanced.md)使用。 Helm 2默认使用ConfigMaps记录版本信息。在Helm 2.7.0中，新的存储后台使用密钥来存储版本信息， 现在是Helm 3的默认设置。 Helm 3默认允许更改密钥作为额外的安全措施在Kubernetes中和密钥加密一起保护chart。 [静态加密密钥](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) 在Kubernetes 1.7中作为alpha特性可以使用了，在Kubernetes 1.13中变成了稳定特性。 这允许用户静态加密Helm的发布元数据，同时也是一个类似Vault的以后可扩展的良好起点。 ### 更改了Go的path导入 在Helm 3中，Helm将Go的import路径从`k8s.io/helm`切换到了`helm.sh/helm/v3`。如果你打算 升级到Helm 3的Go客户端库，确保你已经更改了import路径。 ### Capabilities `.Capabilities`内置对象会在已经简化的渲染阶段生效。 [内置对象](/chart_template_guide/builtin_objects.md) ### 使用Json格式验证Chart Values chart values现在可以使用JSON结构了。这保证用户提供value可以按照chart维护人员设置的结构排列， 并且当用户提供了错误的chart value时会有更好错误提示。 当调用以下命令时会进行JSON格式验证： * `helm install` * `helm upgrade` * `helm template` * `helm lint` 查看 [格式文档](/topics/charts.md) 了解更多信息。 ### 将 `requirements.yaml` 合并到了 `Chart.yaml` Chart依赖体系从 requirements.yaml 和 requirements.lock 移动到 Chart.yaml 和 Chart.lock。我们推荐在Helm 3的新chart中使用新格式。不过Helm 3 依然可以识别 Chart API 版本1 (`v1`) 并且会加载已有的 `requirements.yaml` 文件。 Helm 2中，`requirements.yaml` 看起来是这样的: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Helm 3中， 依赖使用了同样的表达方式，现在`Chart.yaml`是这样的： ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Chart会依然下载和放置在 `charts/` 目录， 因此 `charts/` 目录中的子chart不作修改即可继续工作。 ### Name (或者 --generate-name) 安装时是必需的 Helm 2中，如果没有提供名称， 会自动生成一个名称。在生产环境，这被证明是一个麻烦事而不是一个有用的特性。 而在Helm 3中，如果 `helm install` 没有提供name，会抛异常。 如果仍然需要一个自动生成的名称，您可以使用 `--generate-name` 创建。 ### 推送Chart到OCI注册中心 这是一个Helm 3 中的实验性特性。使用时需要设置环境变量 `HELM_EXPERIMENTAL_OCI=1`。 Chart仓库在较高层次上是一个存储和分发Chart的地址。Helm客户端打包并将Chart推送到Chart仓库中。 简单来说，Chart仓库就是一个基本的HTTP服务器用来存放index.yaml文件和打包的chart。 Chart 仓库API满足最基本的需求有一些好处，但是有些缺点开始显现出来： * Chart 仓库很难在生产环境抽象出大部分的安全性实现。在生产环境有一个认证和授权的标准API就显得格外重要。 * Helm Chart的初始化工具用来签名和验证chart的完整性和来源，在chart的发布过程中是可选的。 * 在多客户场景中，同一个chart可以被其他客户上传，同样的内容会被存储两次。chart仓库可以更加智能地处理 这个问题，但并不是正式规范的一部分。 * 在安全的多客户实现中使用单一的索引文件进行搜索、元数据信息存放和获取chart会变得困难和笨拙。 Docker的分发项目（也称作Docker注册中心 v2）是Docker 注册项目的继承者。 很多主要的云供应商都提供项目 分发，很多供应商都提供相同的产品， 这个分发项目得益于多年的强化、安全性实践和对抗测试。 请查看 `helm help chart` 和 `helm help registry` 了解如何打包chart并推送到Docker注册中心的更多信息。 更多信息请查看 [注册中心](https://docs.helm.sh/zh/docs/topics/registries/)页面。 ### 移除了`helm serve` `helm serve` 命令可以在你本地机器运行一个Chart仓库用于开发目的。 然而作为一个开发工具并没有受到太多利用，并且设计上有很多问题。最终我们决定移除它， 拆分成了一个插件。 对于 `helm serve` 的类似经历，可以查看本地文件系统存储选项在 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 和 [servecm plugin](https://github.com/jdolitsky/helm-servecm). ### Library chart支持 Helm 3 支持的一类chart称为 “library chart”。 这是一个被其他chart共享的chart， 但是它自己不能创建发布组件。library chart的模板只能声明 `define` 元素。 全局范围 内的非`define`内容会被简单忽略。这允许用户复用和共享可在多个chart中重复使用的代码片段。 避免冗余和保留chart [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)。 Library chart在 Chart.yaml的依赖指令中声明，安装和管理与其他chart一致。 ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` 我们很高兴对开发者开放了这个特性的使用案例，以及library charts使用的最佳实践。 ### Chart.yaml api版本切换 随着对library chart的支持以及requirements.yaml合并到Chart.yaml，客户端可以识别Helm 2的包格式而不理解 这些新特性。因此我们将Chart.yaml的apiVersion从 `v1` 切换到了 `v2`。 `helm create` 现在使用使用新格式创建chart，默认的apiVersion也切换到了这里。 客户端希望同时支持两个版本，进而能够检查Chart.yaml的`apiVersion`字段去理解如何解析包格式。 ### XDG 基本目录支持 [XDG 基本目录规范](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) 是一个定义了配置、数据和缓存文件应该存储在文件系统什么位置的可移植标准。 Helm 2中，Helm 将所有的信息存储在 `~/.helm` (被亲切地称为`helm home`)，可以通过设置 `$HELM_HOME` 环境变量修改，或者使用全局参数 `--home`。 Helm 3中，Helm现在遵守XDG 基本目录规范使用以下环境变量： * `$XDG_CACHE_HOME` * `$XDG_CONFIG_HOME` * `$XDG_DATA_HOME` Helm 插件仍然使用 `$HELM_HOME` 作为 `$XDG_DATA_HOME` 的别名，以便希望将`$HELM_HOME`作为过渡环境的变量来保证向后兼容性。 一些新的环境变量也通过插件环境变量来兼容以下更改： * `$HELM_PATH_CACHE` 针对缓存路径 * `$HELM_PATH_CONFIG` 针对配置路径 * `$HELM_PATH_DATA` 针对data路径 如果Helm插件期望支持Helm 3，建议使用新的环境变量。 ### CLI 命令重新命名 为了更好地从包管理器中调整不当措辞，`helm delete`被重命名为`helm uninstall`。 `helm delete` 依然作为 `helm uninstall` 的别名保留， 因此其他格式也能使用。 Helm 2 中为了清除版本清单，必须提供`--purge`参数。这个功能现在是默认使用的。 为保留之前的操作行为，要使用 `helm uninstall --keep-history`。 另外，其他一些重命名的命令提供了以下约定： * `helm inspect` -> `helm show` * `helm fetch` -> `helm pull` 这些命令都保留了老的动词作为别名，因此您能够使用任意一种格式。 ### 自动创建namespace 当用命名空间创建版本时，命名空间不存在，Helm 2会创建一个命名空间。 Helm 3中沿用了其他Kubernetes 工具的形式，如果命名空间不存在，就返回错误。 如果您明确指定 `--create-namespace` 参数，Helm 3 会创建一个命名空间。 ### .Chart.ApiVersion是怎么回事? Helm针对缩略语遵循驼峰命名的典型惯例。我们已经在代码的其他位置做了处理，比如 `.Capabilities.APIVersions.Has`。Helm v3中，我们将 `.Chart.ApiVersion` 更正成了`.Chart.APIVersion`。 ## 安装 ### 为什么没有针对Fedora和其他Linux发行版的Helm原生包? Helm 项目不维护针对操作系统和环境的包。Helm 社区如果觉得需要提供原生包时，可以提供原生包。 这是Homebrew 开始列出的方案。如果您有兴趣维护一个包，我们会很高兴的。 ### 为什么会提供 `curl ...|bash` 脚本? 我们的仓库(`scripts/get-helm-3`)中有个脚本可以作为 `curl ..|bash` 脚本执行。 使用HTTPS传输，The transfers are all protected by HTTPS, 并且这个脚本对它获取到包做一些审核。 然而这个脚本有任何shell脚本的所有常见危险。 我们提供这个脚本因为它很好用，但是我们建议用户先仔细阅读这个脚本。不过我们真正想要的是更好的Helm打包版本。 ### 我如何将Helm客户端文件放置在其他位置而不是默认位置? Helm 使用XDG结构存储文件。这些环境变量可以用来覆盖默认位置: * `$XDG_CACHE_HOME`: 设置另一个存储缓存文件的位置。 * `$XDG_CONFIG_HOME`: 设置另一个存储Helm配置的位置。 * `$XDG_DATA_HOME`: 设置另一个存储Helm数据的位置。 注意，如果有已经存在的仓库，您需要使用 `helm repo add...` 重新添加。 ## 卸载 ### 我想删除我本地Helm. 全部文件在什么位置？ 连同 `helm` 二进制文件一起，Helm将文件存储在以下位置： * $XDG_CACHE_HOME * $XDG_CONFIG_HOME * $XDG_DATA_HOME 下面这个表格按照操作系统给出了对应的默认文件夹位置： | Operating System | Cache Path | Configuration Path | Data Path | |------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ## 故障排除 ### 在 GKE (Google Container Engine) 我遇到了 "No SSH tunnels currently open" ```consol Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` 另一个错误消息的形式： ```consol Unable to connect to the server: x509: certificate signed by unknown authority ``` 这个问题是说您本地的Kubernetes 配置文件需要有正确的证书。 当你在GKE上创建集群时，它会为您提供一个证书，包括SSL证书和证书颁发机构。 这些需要放在Kubernetes配置文件中（默认位置: `~/.kube/config`），保证 `kubectl` 和 `helm` 可以访问他们。 ### 从Helm 2迁移后， `helm list` 仅显示部分（或者不显示）我的发布版本 您很可能忽略了一个事实：Helm 3 现在使用集群的命名空间来确定版本范围。 这意味着所有涉及版本的命令您都必须： * 在活动的kubernetes上下文中需要依赖当前的命名空间 (如 `kubectl config view --minify` 命令所述)， * 使用 `--namespace`/`-n` 参数指定正确命名空间，或者 * 对于 `helm list` 命令，指定 `--all-namespaces`/`-A` 参数 这适用于 `helm ls`、 `helm uninstall` 以及其他所有涉及版本的 `helm` 命令。 ### 为什么在macOS上`/etc/.mdns_debug`文件可以访问？ 我们了解到macOS上的一个案例是Helm会试图访问`/etc/.mdns_debug`文件。 如果文件存在，Helm会在文件句柄执行的时候保持打开状态。 这是因为macOS的 MDNS 库。它尝试去加载这个文件读取debug设置（如果已经启用）。 这个文件句柄可能不会保持打开，且这个问题已经报告给了苹果。 然而这种行为是macOS导致的，并不是Helm。 如果你不想让Helm加载这个文件，你可以将Helm编译成一个静态库而不使用主机网络堆栈。 这样做会导致Helm的二进制文件大小膨胀，但是会阻止这个文件打开。 这个问题最初被标记为潜在的安全问题。但后来已经确定，这种行为不存在任何缺陷或漏洞。 ### helm 仓库使用时添加仓库失败 在Helm 3.3.1及之前版本，`helm repo add `在你添加已经存在的仓库时不会输入内容。 如果仓库已经存在，`--no-update` 参数会报错。 在Helm3.3.2及之后版本，试图添加一个已存在的仓库时会报以下错误： `Error: repository name (reponame) already exists, please specify a different name` 现在这个默认行为是相反的。`--no-update` 现在被忽略。当您想替换（覆盖）已有仓库时，您可以使用 `--force-update`。 这是由于一个安全修复做出的重大更改，详情见[Helm 3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2)。 ### 开启 Kubernetes 客户端日志 调试Kubernetes客户端打印日志时，可以使用[klog](https://pkg.go.dev/k8s.io/klog) 参数。使用`-v`可以设置日志级别应用于大多数场景。 例如： ```consol helm list -v 6 ``` ### Tiller停止安装且无法访问 Helm 发布之前可以从 [https://storage.googleapis.com/kubernetes-helm/](https://storage.googleapis.com/kubernetes-helm/) 获取。如["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/)中所述，官方地址2019年6月已变更。 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) 可以获取所有旧的Tiller镜像。 如果你想从原来的存储位置下载Helm旧版本，你会发现找不到了： ```console AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [原有Tiller镜像地址](https://gcr.io/kubernetes-helm/tiller) 会在2021年8月开始删除镜像。我们已经增加了可用地址在 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)。 比如下载v2.17.0，用 `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` 替换 `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` 使用Helm v2.17.0初始化： `helm init —upgrade` 或者如果需要另一个版本，使用 --tiller-image 替换默认位置安装特定的Helm v2 版本： `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **注意** Helm维护人员建议迁移到当前支持的Helm版本。Helm v2.17.0 是Helm 2的最终版本；Helm v2自2020年11月起便不再支持，具体细节请查看[Helm 2 和 Charts Project 已不再支持](https://helm.sh/blog/helm-2-becomes-unsupported/)。 自那以后，Helm已经被发现很多的CVE，这些漏洞已经在Helm v3修复，但不会再给Helm v2打补丁。现在查看 [Helm当前已发布的建议列表](https://github.com/helm/helm/security/advisories?state=published)并计划 [迁移到 Helm v3](https://helm.sh/docs/topics/v2_v3_migration/#helm)吧。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/faq/installing.md ================================================ --- title: 安装 sidebar_position: 2 --- ## 安装 ### 为什么 Fedora 和其他 Linux 发行版没有 Helm 的原生软件包？ Helm 项目不维护各操作系统和环境的软件包。Helm 社区可能会提供原生包，如果 Helm 项目得知这些包的存在，会将其列出。Homebrew formula 最初就是这样被创建并列出的。如果你有兴趣维护一个软件包，我们非常欢迎。 ### 为什么提供 `curl ...|bash` 脚本？ 我们的仓库中有一个脚本（`scripts/get-helm-3`）可以通过 `curl ..|bash` 方式执行。所有传输都受 HTTPS 保护，脚本会对获取的软件包进行一些审计。但是，该脚本与任何 shell 脚本一样存在常见风险。 我们提供这个脚本是因为它很实用，但建议用户先仔细阅读脚本内容。不过，我们更希望能有更完善的 Helm 打包发行版。 ### 如何将 Helm 客户端文件存放在默认位置以外的地方？ Helm 使用 XDG 结构存储文件。你可以使用以下环境变量覆盖这些位置： - `$XDG_CACHE_HOME`：设置缓存文件的替代存储位置。 - `$XDG_CONFIG_HOME`：设置 Helm 配置的替代存储位置。 - `$XDG_DATA_HOME`：设置 Helm 数据的替代存储位置。 注意，如果你已有仓库，需要使用 `helm repo add...` 重新添加。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/faq/troubleshooting.md ================================================ --- title: 故障排查 sidebar_position: 4 --- ## 故障排查 ### 我收到"Unable to get an update from the "stable" chart repository"警告 运行 `helm repo list`。如果显示你的 `stable` 仓库指向 `storage.googleapis.com` URL，则需要更新该仓库。2020 年 11 月 13 日，Helm Charts 仓库经过一年的弃用期后[已停止支持](https://github.com/helm/charts#deprecation-timeline)。归档版本已在 `https://charts.helm.sh/stable` 提供，但不再接收更新。 你可以运行以下命令修复仓库： ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` `incubator` 仓库也是同样的情况，其归档版本在 https://charts.helm.sh/incubator。你可以运行以下命令修复： ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 我收到警告 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' 旧的 Google Helm chart 仓库已被新的 Helm chart 仓库替代。 运行以下命令可永久解决此问题： ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` 如果 `incubator` 出现类似错误，运行以下命令： ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### 添加 Helm 仓库时收到错误 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' Helm Chart 仓库经过[一年的弃用期](https://github.com/helm/charts#deprecation-timeline)后已停止支持。这些仓库的归档版本在 `https://charts.helm.sh/stable` 和 `https://charts.helm.sh/incubator`，但不再接收更新。除非指定 `--use-deprecated-repos`，否则 `helm repo add` 命令不允许添加旧的 URL。 ### 在 GKE（Google Container Engine）上收到 "No SSH tunnels currently open" 错误 ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` 错误信息的另一种形式是： ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` 原因是本地 Kubernetes 配置文件必须具有正确的凭据。 在 GKE 上创建集群时，会提供凭据（包括 SSL 证书和证书颁发机构）。这些信息需要存储在 Kubernetes 配置文件中（默认位置：`~/.kube/config`），以便 `kubectl` 和 `helm` 能够访问。 ### 从 Helm 2 迁移后，`helm list` 只显示部分（或不显示）release 这很可能是因为 Helm 3 现在使用集群 namespace 来区分 release 的作用域。这意味着所有涉及 release 的命令必须满足以下条件之一： * 依赖当前 Kubernetes 上下文中的活动 namespace（使用 `kubectl config view --minify` 命令可查看） * 使用 `--namespace`/`-n` 参数指定正确的 namespace * 对于 `helm list` 命令，指定 `--all-namespaces`/`-A` 参数 这适用于 `helm ls`、`helm uninstall` 以及所有涉及 release 的 `helm` 命令。 ### 在 macOS 上访问了文件 `/etc/.mdns_debug`，这是为什么？ 在 macOS 上存在一种情况：Helm 会尝试访问名为 `/etc/.mdns_debug` 的文件。如果该文件存在，Helm 会在执行期间保持文件句柄处于打开状态。 这是由 macOS 的 MDNS 库导致的。该库会尝试加载此文件以读取调试设置（如果已启用）。文件句柄可能不应该保持打开状态，此问题已报告给 Apple。但这是 macOS 的行为，而非 Helm 导致的。 如果你不希望 Helm 加载此文件，可以将 Helm 编译为不使用主机网络栈的静态库。这样做会增加 Helm 的二进制文件大小，但可以防止打开该文件。 此问题最初被标记为潜在的安全问题，但后来确定此行为不会导致任何缺陷或漏洞。 ### helm repo add 失败，但以前可以正常使用 在 Helm 3.3.1 及更早版本中，如果尝试添加已存在的仓库，`helm repo add ` 命令不会有任何输出。使用 `--no-update` 参数时，如果仓库已注册则会报错。 在 Helm 3.3.2 及更高版本中，尝试添加已存在的仓库会报错： `Error: repository name (reponame) already exists, please specify a different name` 现在默认行为已更改。`--no-update` 现在被忽略，如果要替换（覆盖）已存在的仓库，可以使用 `--force-update`。 这是一项安全修复导致的破坏性更改，详见 [Helm 3.3.2 发布说明](https://github.com/helm/helm/releases/tag/v3.3.2)。 ### 启用 Kubernetes 客户端日志 可以使用 [klog](https://pkg.go.dev/k8s.io/klog) 参数来启用 Kubernetes 客户端的调试日志消息输出。在大多数情况下，使用 `-v` 参数设置详细级别即可。 例如： ``` helm list -v 6 ``` ### Tiller 安装停止工作并且访问被拒绝 以前可以从 获取 Helm 发布版本。正如 ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/) 中所述，官方地址已于 2019 年 6 月更改。[GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) 提供了所有旧的 Tiller 镜像。 如果你尝试从过去使用的存储桶下载旧版本的 Helm，可能会发现它们已被移除： ``` AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
 ``` [旧版 Tiller 镜像位置](https://gcr.io/kubernetes-helm/tiller)从 2021 年 8 月开始移除镜像。我们已将这些镜像托管到 [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller)。例如，要下载 v2.17.0 版本，将： `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` 替换为： `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` 使用 Helm v2.17.0 初始化： `helm init —upgrade` 或者如果需要其他版本，使用 --tiller-image 参数覆盖默认位置并安装特定的 Helm v2 版本： `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **注意：** Helm 维护者建议迁移到当前支持的 Helm 版本。Helm v2.17.0 是 Helm v2 的最终版本；Helm v2 自 2020 年 11 月起不再受支持，详见 [Helm 2 和 Charts 项目不再受支持](https://helm.sh/blog/helm-2-becomes-unsupported/)。此后已标记了多个针对 Helm 的 CVE，这些漏洞已在 Helm v3 中修补，但永远不会在 Helm v2 中修补。请参阅[当前已发布的 Helm 安全公告列表](https://github.com/helm/helm/security/advisories?state=published)，并制定[迁移到 Helm v3](/topics/v2_v3_migration.md)的计划。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/faq/uninstalling.md ================================================ --- title: 卸载 sidebar_position: 3 --- ## 卸载 ### 我想删除本地的 Helm，它的文件存放在哪里？ 除了 `helm` 二进制文件之外，Helm 还将一些文件存储在以下位置： - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME 下表列出了各操作系统上这些目录的默认路径： | 操作系统 | 缓存路径 | 配置路径 | 数据路径 | |----------|-----------------------------|---------------------------------|---------------------------| | Linux | `$HOME/.cache/helm` | `$HOME/.config/helm` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm` | | Windows | `%TEMP%\helm` | `%APPDATA%\helm` | `%APPDATA%\helm` | ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/glossary/index.mdx ================================================ --- title: 术语表 description: 用于描述Helm体系结构的组件。 sidebar_position: 9 --- # 术语表 ## Chart Helm包涵盖了将Kubernetes资源安装到Kubernetes集群所需要的足够多的信息。 Charts包含`Chart.yaml`文件和模板，默认值(`values.yaml`)，以及相关依赖。 Charts开发设计了良好定义的目录结构，并且打包成了一种称为 _chart archive_ 文件格式。 ## Chart包 Chart包(_chart archive_)是被tar和gzip压缩(并且可选签名)的chart. ## Chart依赖 (子chart) Chart可以依赖于其他的chart。 依赖可能会以以下两种方式出现: - 软依赖： 如果另一个chart没有在集群中安装，chart可能会无法使用。Helm未对这个案例提供工具。 这个案例中，依赖会被分别管理。 - 硬依赖： 一个chart可以包含 (在它的`charts/`目录中) 另一个它所依赖的chart。这个案例中， 安装chart的同时会安装所有依赖。chart和它的依赖会作为一个集合进行管理。 当一个chart(通过`helm package`)打包时所有的依赖都会和它绑定。 ## Chart版本 Chart版本根据 [语义化版本2.0 细则](https://semver.org) 发布。每个chart都需要版本号。 ## Chart.yaml chart的信息说明被存储在一个特定文件`Chart.yaml`。每个chart都必须有这个文件。 ## Helm (以及helm) Helm 是Kubernetes的包管理器。作为一个操作系统包管理器，使其很容易在操作系统中安装工具。 Helm使得Kubernetes集群中安装应用和资源变得异常简单。 当 _Helm_ 是项目名称时, 命令行客户端也可以使用 `helm`。按照惯例，当指项目时，_Helm_ 使用大写。当指命令行时, _helm_ 使用小写。 ## Helm配置文件 (XDG) Helm将配置文件存储在XDG目录中。`helm`第一次运行时这些目录会自动生成。 ## Kube 配置 (KUBECONFIG) Helm客户端会通过使用 _Kube config_ 文件格式来理解Kubernetes集群。 默认情况下，Helm会尝试在 `kubectl` 创建的 (`$HOME/.kube/config`) 目录中查找这些文件。 ## 代码规范 (进行中) 规范(_lint_) 一个chart是去验证其遵照Helm chart的标准规范和要求。 Helm提供了工具来处理，尤其是`helm lint`命令。 ## 来源 (来源文件) Helm chart可以由来源文件(_provenance file_)提供chart的出处及它所包含的内容。 来源文件是Helm安全故事的一部分。一个来源包含chart包文件的加密哈希值，Chart.yaml数据， 和一个签名块（一个OpenPGP "clearsign" 块）。当再加上一个钥匙链时，可以为chart用户提供 以下能力： - 验证chart被可信第三方签名 - 验证chart文件没有被篡改 - 验证chart的元数据内容(`Chart.yaml`) - 快速匹配chart的数据来源 来源文件有`.prov`扩展名，可以由chart仓库服务器或其他HTTP服务器提供。 ## 发布版本 chart安装之后，Helm库会创建一个 _release_ 来跟踪这个安装。 单个chart可以在同一个集群中安装多次，并能创建多个不同的版本。例如，可以使用 `helm install` 命令以不同的版本安装三个PostgreSQL 数据库三次。 ## 版本号 单个版本号可以被升级多次。通过连续技术来跟踪升级发布版本。在第一次`helm install`之后，一个版本 会有 _release number_ 1，每一次版本升级或回滚，版本号都会升级。 ## 回滚 每一次发布会更新chart或者配置。当生成发布历史后，一次发布也可以被 _rolled back_ 之前的发布版本号。 回滚使用 `helm rollback` 命令实现。 重要的是, 每一次回滚版本会生成一个新的发布版本号。 | 操作 | 版本号 | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (但使用release 1的配置) | 上面的列表阐明了发布版本号是怎样通过安装，升级和回滚递增的。 ## Helm库 (或SDK) Helm库（或SDK）涉及到go代码，可以直接与Kubernetes API服务交互进行安装、升级、查询 以及移除Kubernetes资源。可以被导入到项目中作为客户端库使用而不是用作CLI命令。 ## 仓库 (Repo, Chart Repository) Helm图标chart可以被存储在专用的HTTP服务器上，称之为 _chart 仓库_（_repositories_，或者就叫 _repos_）。 chart仓库服务器就是一个简单的HTTP服务器，提供一个`index.yaml` 文件来描述一批chart， 并且提供每个chart的下载位置信息。(很多chart仓库同时提供chart和 `index.yaml`文件。) Helm客户端可以指向0个或多个chart仓库。默认没有配置仓库。Chart仓库可以随时使用`helm repo add`命令添加。 ## Values (Values文件, values.yaml) Values 提供了一种使用您自己的信息覆盖模板默认值的方式。 Helm Chart是"参数化的", 这意味着chart开发者可以在安装时显式配置。比如说，chart可以暴露`username`字段， 允许为服务设置一个用户名。 这些可暴露的变量在Helm用语中称为 _values_。 Values可以在 `helm install`时和`helm upgrade`时设置，直接把它们传值进来，也可以使用`values.yaml`文件设置。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- 针对 Kubernetes 的 Helm 包管理器。 ### 简介 Kubernetes 包管理器 Helm 常用操作： - helm search: 搜索 chart - helm pull: 下载 chart 到本地目录查看 - helm install: 安装 chart 到 Kubernetes - helm list: 列出 release 环境变量： | 名称 | 描述 | |------------------------------------|---------------------------------------------------------------------------------| | $HELM_CACHE_HOME | 设置一个存储缓存文件的可选位置 | | $HELM_CONFIG_HOME | 设置一个存储Helm配置的可选位置 | | $HELM_DATA_HOME | 设置一个存储Helm数据的可选位置 | | $HELM_DEBUG | 表示Helm是否在Debug模式下运行 | | $HELM_DRIVER | 设置后台存储驱动，可选值包括：configmap、secret、memory、sql | | $HELM_DRIVER_SQL_CONNECTION_STRING | 设置 SQL 存储驱动使用的连接字符串 | | $HELM_MAX_HISTORY | 设置 release 历史记录的最大数量 | | $HELM_NAMESPACE | 设置用于helm操作的命名空间 | | $HELM_NO_PLUGINS | 禁用插件，HELM_NO_PLUGINS=1 表示禁用插件 | | $HELM_PLUGINS | 设置插件目录路径 | | $HELM_REGISTRY_CONFIG | 设置注册配置文件的路径 | | $HELM_REPOSITORY_CACHE | 设置仓库缓存目录路径 | | $HELM_REPOSITORY_CONFIG | 设置仓库文件的路径 | | $KUBECONFIG | 设置 Kubernetes 的备用配置文件（默认 "~/.kube/config"） | | $HELM_KUBEAPISERVER | 设置用于身份认证的Kubernetes API服务端 | | $HELM_KUBECAFILE | 设置Kubernetes证书机构文件 | | $HELM_KUBEASGROUPS | 使用逗号分隔的列表设置用于模拟的组 | | $HELM_KUBEASUSER | 为操作设置要模拟的用户名 | | $HELM_KUBECONTEXT | 设置kubeconfig上下文的名称 | | $HELM_KUBETOKEN | 设置用于身份验证的 Bearer KubeToken | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | 设置 Kubernetes API 服务的证书验证是否跳过（不安全） | | $HELM_KUBETLS_SERVER_NAME | 设置用于验证 Kubernetes API 服务器证书的服务器名称 | | $HELM_BURST_LIMIT | 设置当 Kubernetes 服务包含大量 CRD 时的默认突发上限值（默认 100，-1 表示禁用） | | $HELM_QPS | 设置当高频调用超出较高突发限制时的每秒查询数 | Helm 基于以下配置顺序存储缓存，配置和添加数据： - 如果设置了 HELM_*_HOME 环境变量，则使用该变量 - 否则，在支持XDG基本目录规范的系统上，会使用XDG变量 - 当没有设置其他位置时，将根据操作系统使用默认位置 默认情况下，默认目录取决于操作系统，默认值如下： | 操作系统 | 缓存路径 | 配置路径 | 数据路径 | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### 可选项 ```shell --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 另请参阅 - [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本 - [helm create](/helm/helm_create.md) - 使用给定的名称创建 chart - [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖 - [helm env](/helm/helm_env.md) - Helm 客户端环境信息 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 - [helm history](/helm/helm_history.md) - 获取 release 历史 - [helm install](/helm/helm_install.md) - 安装 chart - [helm lint](/helm/helm_lint.md) - 验证 chart 是否存在问题 - [helm list](/helm/helm_list.md) - 列出 release - [helm package](/helm/helm_package.md) - 将 chart 目录打包 - [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件 - [helm pull](/helm/helm_pull.md) - 从仓库下载 chart 并（可选）在本地目录中打开 - [helm push](/helm/helm_push.md) - 推送 chart 到远程 - [helm registry](/helm/helm_registry.md) - 登录或登出 registry - [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 - [helm rollback](/helm/helm_rollback.md) - 将 release 回滚到上一个版本 - [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字 - [helm show](/helm/helm_show.md) - 显示 chart 信息 - [helm status](/helm/helm_status.md) - 显示指定 release 的状态 - [helm template](/helm/helm_template.md) - 本地渲染模板 - [helm test](/helm/helm_test.md) - 运行 release 的测试 - [helm uninstall](/helm/helm_uninstall.md) - 卸载 release - [helm upgrade](/helm/helm_upgrade.md) - 升级 release - [helm verify](/helm/helm_verify.md) - 验证给定路径的 chart 已经被签名且是合法的 - [helm version](/helm/helm_version.md) - 打印客户端版本信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- 为指定的 shell 生成自动补全脚本 ### 简介 为 Helm 生成针对指定 shell 的自动补全脚本。 ### 可选项 ```shell -h, --help completion 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 * [helm completion bash](/helm/helm_completion_bash.md) - 为 bash 生成自动补全脚本 * [helm completion fish](/helm/helm_completion_fish.md) - 为 fish 生成自动补全脚本 * [helm completion powershell](/helm/helm_completion_powershell.md) - 为 powershell 生成自动补全脚本 * [helm completion zsh](/helm/helm_completion_zsh.md) - 为 zsh 生成自动补全脚本 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- 为 bash 生成自动补全脚本 ### 简介 为 Helm 生成针对 bash shell 的自动补全脚本。 在当前 shell 会话中加载自动补全： source <(helm completion bash) 为每个新的会话加载自动补全，执行一次： - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ```shell helm completion bash [flags] ``` ### 可选项 ```shell -h, --help bash 命令帮助 --no-descriptions 禁用补全描述 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- 为 fish 生成自动补全脚本 ### 简介 为 Helm 生成针对 fish shell 的自动补全脚本。 在当前 shell 会话中加载自动补全： helm completion fish | source 为每个新的会话加载自动补全，执行一次： helm completion fish > ~/.config/fish/completions/helm.fish 你需要启动一个新的 shell 使其生效。 ``` helm completion fish [flags] ``` ### 可选项 ``` -h, --help fish 命令帮助 --no-descriptions 禁用补全描述 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- 为 powershell 生成自动补全脚本 ### 简介 为 powershell 生成自动补全脚本。 在当前 shell 会话中加载补全项： PS C:\> helm completion powershell | Out-String | Invoke-Expression 为每个新会话加载补全项，将上述命令的输出添加到你的 powershell profile 中。 ```shell helm completion powershell [flags] ``` ### 可选项 ```shell -h, --help powershell 命令帮助 --no-descriptions 禁用补全描述 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- 为 zsh 生成自动补全脚本 ### 简介 为 Helm 生成针对 zsh shell 的自动补全脚本。 在当前 shell 会话中加载自动补全： source <(helm completion zsh) 为每个新的会话加载自动补全，执行一次： helm completion zsh > "${fpath[1]}/_helm" ```shell helm completion zsh [flags] ``` ### 可选项 ```shell -h, --help zsh 命令帮助 --no-descriptions 禁用补全描述 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm completion](/helm/helm_completion.md) - 为指定的 shell 生成自动补全脚本 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- 使用给定名称创建新的 chart ### 简介 该命令创建 chart 目录和 chart 中常用的文件及目录。 例如，`helm create foo` 会创建如下目录结构： ``` foo/ ├── .helmignore # 打包 Helm chart 时要忽略的文件模式 ├── Chart.yaml # chart 的信息 ├── values.yaml # 模板的默认值 ├── charts/ # 该 chart 依赖的 chart └── templates/ # 模板文件 └── tests/ # 测试文件 ``` `helm create` 使用路径作为参数。如果给定路径中的目录不存在，Helm 会自动创建。如果给定目录已存在且其中有文件，冲突文件会被覆盖，其他文件保持不变。 ```shell helm create NAME [flags] ``` ### 可选项 ```shell -h, --help create 命令帮助 -p, --starter string Helm starter scaffold 的名称或绝对路径 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_delete.md ================================================ --- section: 弃用 title: helm delete --- 该命令被重命名。 请参考[helm uninstall](/helm/helm_uninstall.md). ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- 管理 chart 依赖 ### 简介 管理 chart 依赖。 Helm chart 将依赖存储在 'charts/' 目录中。对于 chart 开发者，在 'Chart.yaml' 中声明所有依赖通常更方便管理。 依赖命令针对该文件进行操作，使得 'charts/' 目录中声明的依赖和实际存储的依赖之间轻松保持同步。 例如，以下 Chart.yaml 声明了两个依赖： ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" ``` 'name' 是 chart 名称，必须与该 chart 的 'Chart.yaml' 文件中的名称相匹配。 'version' 字段应包含语义化版本号或版本范围。 'repository' URL 应指向 Chart 仓库。Helm 会在 URL 后附加 '/index.yaml' 来获取 chart 仓库索引。注意：'repository' 可以是别名。别名必须以 'alias:' 或 '@' 开头。 从 2.2.0 开始，仓库可以定义为本地存储的依赖 chart 的目录路径。路径需以 "file://" 开头，例如： ```yaml # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" ``` 如果依赖 chart 从本地获取，则不需要通过 "helm add repo" 将仓库添加到 helm 中。此场景也支持版本匹配。 ### 可选项 ```shell -h, --help dependency 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 * [helm dependency build](/helm/helm_dependency_build.md) - 根据 Chart.lock 文件重新构建 charts/ 目录 * [helm dependency list](/helm/helm_dependency_list.md) - 列出指定 chart 的依赖 * [helm dependency update](/helm/helm_dependency_update.md) - 根据 Chart.yaml 内容更新 charts/ 目录 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- 基于 Chart.lock 文件重新构建 charts/ 目录 ### 简介 从 Chart.lock 文件构建输出到 charts/ 目录。 该命令用于将 chart 的依赖项重建为锁定文件中的指定状态。它不会像 'helm dependency update' 那样重新协商依赖。 如果未找到锁定文件，'helm dependency build' 的行为将与 'helm dependency update' 相同。 ```shell helm dependency build CHART [flags] ``` ### 可选项 ```shell --ca-file string 使用此 CA 证书包验证启用 HTTPS 的服务器证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 -h, --help build 命令帮助 --insecure-skip-tls-verify 跳过 chart 下载时的 TLS 证书验证 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 包含公钥的密钥环（默认 "~/.gnupg/pubring.gpg"） --password string chart 仓库密码，用于定位请求的 chart --plain-http 对 chart 下载使用不安全的 HTTP 连接 --skip-refresh 不刷新本地仓库缓存 --username string chart 仓库用户名，用于定位请求的 chart --verify 对下载的包进行签名验证 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- 列举指定 chart 的依赖 ### 简介 列举 chart 中声明的所有依赖。 此命令可以将 chart 包或 chart 目录作为输入，不会修改 chart 的内容。 如果 chart 无法加载，会产生错误。 ```shell helm dependency list CHART [flags] ``` ### 可选项 ```shell -h, --help list 命令帮助 --max-col-width uint 输出表格的最大列宽（默认 80） ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- 根据 Chart.yaml 更新 charts/ 目录 ### 简介 将磁盘上的依赖更新为 Chart.yaml 指定的状态。 此命令验证 'Chart.yaml' 中指定的所需 chart 是否存在于 'charts/' 目录中且版本满足要求。它会拉取满足依赖的最新 chart，并清理旧依赖。 成功更新后，会生成一个锁定文件，可用于将依赖重新构建到精确版本。 依赖不一定需要在 'Chart.yaml' 中声明。因此，更新命令不会删除 chart，除非该 chart 在 Chart.yaml 中声明但版本不符。 ```shell helm dependency update CHART [flags] ``` ### 可选项 ```shell --ca-file string 使用此 CA 证书包验证启用 HTTPS 的服务器证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 -h, --help update 命令帮助 --insecure-skip-tls-verify 跳过 chart 下载时的 TLS 证书验证 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 包含公钥的密钥环（默认 "~/.gnupg/pubring.gpg"） --password string chart 仓库密码，用于定位请求的 chart --plain-http 对 chart 下载使用不安全的 HTTP 连接 --skip-refresh 不刷新本地仓库缓存 --username string chart 仓库用户名，用于定位请求的 chart --verify 对下载的包进行签名验证 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm dependency](/helm/helm_dependency.md) - 管理 chart 依赖 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- 显示 Helm 客户端的环境信息 ### 简介 该命令打印 Helm 使用的所有环境信息。 ``` helm env [flags] ``` ### 可选项 ``` -h, --help env 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- 下载指定 release 的扩展信息 ### 简介 该命令由多个子命令组成，用于获取 release 的扩展信息，包括： - 用于生成该 release 的 values - 生成的清单文件 - chart 提供的 NOTES - 与该 release 关联的 hook - 该 release 的元数据 ### 可选项 ``` -h, --help get 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 - [helm get all](/helm/helm_get_all.md) - 下载指定 release 的所有信息 - [helm get hooks](/helm/helm_get_hooks.md) - 下载指定 release 的所有 hook - [helm get manifest](/helm/helm_get_manifest.md) - 下载指定 release 的清单 - [helm get metadata](/helm/helm_get_metadata.md) - 获取指定 release 的元数据 - [helm get notes](/helm/helm_get_notes.md) - 下载指定 release 的 NOTES - [helm get values](/helm/helm_get_values.md) - 下载指定 release 的 values 文件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- 下载指定 release 的所有信息 ### 简介 该命令打印指定 release 的可读信息集合，包括说明信息、hook、提供的 values 以及生成的清单文件。 ``` helm get all RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help all 的帮助信息 --revision int 获取指定 release 的某个修订版本 --template string 用于格式化输出的 Go 模板，例如：{{.Release.Name}} ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- 下载指定 release 的所有钩子 ### 简介 该命令用于下载指定 release 的钩子。 钩子被格式化为 YAML，并以 YAML 的 '---\n' 分隔符分隔。 ``` helm get hooks RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help hooks 的帮助信息 --revision int 获取指定 release 的某个修订版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- 下载指定 release 的清单 ### 简介 该命令用于获取指定 release 的生成清单。 清单是由该 release 的 chart 生成的 Kubernetes 资源的 YAML 编码表示。如果 chart 依赖其他 chart，这些资源也会包含在清单中。 ``` helm get manifest RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help manifest 的帮助信息 --revision int 获取指定 release 的某个修订版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- 获取指定 release 的元数据 ### 简介 该命令用于获取指定 release 的元数据信息。 ``` helm get metadata RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help metadata 的帮助信息 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） --revision int 指定 release 的修订版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- 下载指定 release 的说明信息 ### 简介 该命令显示指定 release 的 chart 所提供的说明信息。 ``` helm get notes RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help notes 的帮助信息 --revision int 获取指定 release 的某个修订版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- 下载指定 release 的 values 文件 ### 简介 该命令下载指定 release 的 values 文件。 ``` helm get values RELEASE_NAME [flags] ``` ### 可选项 ``` -a, --all 输出所有（计算后的）values -h, --help values 的帮助信息 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） --revision int 获取指定修订版本的 release ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm get](/helm/helm_get.md) - 下载指定 release 的扩展信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- 检索 release 历史 ### 简介 该命令打印指定 release 的历史修订记录。 默认最多返回 256 个修订版本。设置 `--max` 可配置返回的修订列表最大长度。 历史记录会以格式化表格形式打印，例如： $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help history 的帮助信息 --max int 包含在历史记录中的最大修订版本数（默认 256） -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_init.md ================================================ --- section: 弃用 title: helm init --- 该命令不会出现在Helm 3中，遵循[移除的Tiller](https://helm.sh/zh/docs/faq/#移除了Tiller)。不再需要为使用helm而安装Tiller。 如果您在使用Helm 2， 前往[v2.helm.sh](https://v2.helm.sh/docs/helm/#helm-init) 查看[Helm初始化文档](https://v2.helm.sh/docs/helm/#helm-init)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_inspect.md ================================================ --- section: 弃用 title: helm inspect --- 该命令已被重命名，请参考[helm show](/helm/helm_show.md)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- 安装 chart ### 简介 该命令用于安装 chart 包。 安装参数必须是 chart 的引用，一个打包后的 chart 路径，未打包的 chart 目录或者是一个 URL。 要重写 chart 中的值，使用 '--values' 参数传递一个文件或者使用 '--set' 参数在命令行传递配置，强制使用字符串要用 '--set-string'。当值本身对于命令行太长或者是动态生成的时候，可以使用 '--set-file' 设置独立的值。也可以在命令行使用 '--set-json' 参数设置 JSON 值（标量/对象/数组）。 $ helm install -f myvalues.yaml myredis ./redis 或者 $ helm install --set name=prod myredis ./redis 或者 $ helm install --set-string long_int=1234567890 myredis ./redis 或者 $ helm install --set-file my_script=dothings.sh myredis ./redis 或者 $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis 你可以多次指定 '--values'/'-f' 参数。最右侧指定的文件优先级最高。比如，如果两个文件 myvalues.yaml 和 override.yaml 都包含名为 'Test' 的键，override.yaml 中的值优先： $ helm install -f myvalues.yaml -f override.yaml myredis ./redis 可以多次指定 '--set' 参数，最右边的参数优先级最高。比如，'bar' 和 'newbar' 都设置了一个名为 'foo' 的键，'newbar' 的值优先： $ helm install --set foo=bar --set foo=newbar myredis ./redis 类似地，下面的示例中 'foo' 被设置成了 '["four"]'： $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis 下面的示例中，'foo' 被设置成了 '{"key1":"value1","key2":"bar"}'： $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis 为了检测生成的清单，但并不安装 chart，可以将 '--debug' 和 '--dry-run' 组合使用。 '--dry-run' 参数会输出所有生成的 chart 清单，包括可能包含敏感值的 Secret。如需隐藏 Kubernetes Secret，请使用 '--hide-secret' 参数。请谨慎考虑何时及如何使用这些参数。 如果设置了 '--verify'，chart **必须**有出处文件，且出处文件**必须**通过所有的验证步骤。 有六种不同的方式来标识需要安装的 chart： 1. 通过 chart 引用：helm install mymaria example/mariadb 2. 通过 chart 包路径：helm install mynginx ./nginx-1.2.3.tgz 3. 通过未打包 chart 目录的路径：helm install mynginx ./nginx 4. 通过 URL 绝对路径：helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. 通过 chart 引用和仓库 URL：helm install --repo https://example.com/charts/ mynginx nginx 6. 通过 OCI 注册中心：helm install mynginx --version 1.2.3 oci://example.com/charts/nginx CHART 引用 chart 引用是在 chart 仓库中引用 chart 的一种方便方式。 当你用仓库前缀（'example/mariadb'）引用 chart 时，Helm 会在本地配置查找名为 'example' 的 chart 仓库，然后会在仓库中查找名为 'mariadb' 的 chart，然后会安装这个 chart 最新的稳定版本，除非指定了 '--devel' 参数且包含了开发版本（alpha、beta 和候选发布版本），或者使用 '--version' 参数提供一个版本号。 要查看仓库列表，使用 'helm repo list'。要在仓库中搜索 chart，使用 'helm search'。 ``` helm install [NAME] [CHART] [flags] ``` ### 可选项 ``` --atomic if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### 从父命令继承的选项 ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 请参阅 * [helm](./helm.md) - Kubernetes 的 Helm 包管理器 ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- 检查 chart 是否存在问题 ### 简介 该命令使用一个 chart 路径并运行一系列测试来验证 chart 的格式是否正确。 如果 linter 遇到会导致 chart 安装失败的情况，会输出 [ERROR] 信息。如果遇到违反惯例或建议的问题，会输出 [WARNING] 信息。 ``` helm lint PATH [flags] ``` ### 可选项 ``` -h, --help lint 的帮助信息 --kube-version string 用于能力检测和弃用检查的 Kubernetes 版本 --quiet 仅打印警告和错误 --set stringArray 在命令行上设置值（可以指定多个或用逗号分隔值：key1=val1,key2=val2） --set-file stringArray 通过命令行从相应文件设置值（可以指定多个或用逗号分隔值：key1=path1,key2=path2） --set-json stringArray 在命令行上设置 JSON 值（可以指定多个或用逗号分隔值：key1=jsonval1,key2=jsonval2） --set-literal stringArray 在命令行上设置字面 STRING 值 --set-string stringArray 在命令行上设置 STRING 值（可以指定多个或用逗号分隔值：key1=val1,key2=val2） --skip-schema-validation 如果设置，禁用 JSON schema 验证 --strict 将 lint 警告视为失败 -f, --values strings 指定 YAML 文件或 URL 中的值（可以指定多个） --with-subcharts 对依赖的 chart 进行 lint ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- 列举 release ### 简介 该命令列举指定 namespace 的所有 release（如果未指定 namespace，则使用当前 namespace 上下文）。 默认情况下，只列举已部署或失败的 release。使用 `--uninstalled` 和 `--all` 等参数可以更改此行为。这些参数可以组合使用：`--uninstalled --failed`。 默认情况下，列表按字母顺序排序。使用 `-d` 参数按发布日期排序。 如果使用 `--filter` 参数，它将被作为过滤器使用。过滤器是应用于 release 列表的正则表达式（Perl 兼容）。只有匹配过滤器的项目会被返回。 $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 如果未找到结果，`helm list` 将返回退出码 0，但没有输出（或者在没有使用 `-q` 参数的情况下，只显示表头）。 默认情况下，最多返回 256 项。使用 `--max` 参数限制数量。将 `--max` 设置为 0 不会返回所有结果，而是返回服务器默认值，可能比 256 更多。配合使用 `--max` 和 `--offset` 参数可以翻页显示结果。 ``` helm list [flags] ``` ### 可选项 ``` -a, --all 显示所有 release，不应用任何过滤器 -A, --all-namespaces 列举所有 namespace 中的 release -d, --date 按发布日期排序 --deployed 显示已部署的 release。如果未指定其他参数，此选项会自动启用 --failed 显示失败的 release -f, --filter string 正则表达式（Perl 兼容）。匹配该表达式的 release 将包含在结果中 -h, --help list 的帮助信息 -m, --max int 获取的最大 release 数量（默认 256） --no-headers 使用默认输出格式时不打印表头 --offset int 列表中下一个 release 的索引，用于从起始值偏移 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） --pending 显示待处理的 release -r, --reverse 反转排序顺序 -l, --selector string 用于过滤的选择器（标签查询），支持 '='、'==' 和 '!='（例如 -l key1=value1,key2=value2）。仅适用于 secret（默认）和 configmap 存储后端 -q, --short 输出简短（静默）列表格式 --superseded 显示已被取代的 release --time-format string 使用 golang 时间格式化程序格式化时间。示例：--time-format "2006-01-02 15:04:05Z0700" --uninstalled 显示已卸载的 release（如果使用了 'helm uninstall --keep-history'） --uninstalling 显示正在卸载中的 release ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- 将 chart 目录打包成 chart 归档文件 ### 简介 该命令将 chart 打包成一个版本化的 chart 归档文件。如果给定路径，将会在该路径中查找 chart（必须包含 Chart.yaml 文件）然后将该目录打包。 版本化的 chart 归档文件用于 Helm 包仓库。 要签名一个 chart，使用 `--sign` 参数。在大多数场景中，还需要提供 `--keyring path/to/secret/keys` 和 `--key keyname`。 $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg 如果未指定 `--keyring`，除非环境有其他配置，否则 Helm 通常会使用公共密钥环。 ``` helm package [CHART_PATH] [...] [flags] ``` ### 可选项 ``` --app-version string 设置 chart 的 appVersion 为此版本 --ca-file string 使用此 CA 证书包验证启用 HTTPS 的服务器证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 -u, --dependency-update 打包前从 "Chart.yaml" 更新依赖到 "charts/" 目录 -d, --destination string chart 写入位置（默认 "."） -h, --help package 命令帮助 --insecure-skip-tls-verify 跳过 chart 下载时的 TLS 证书检查 --key string 签名时使用的密钥名称，在 --sign 为 true 时使用 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 公共密钥环位置（默认 "~/.gnupg/pubring.gpg"） --passphrase-file string 包含签名密钥密码短语的文件位置，使用 "-" 从标准输入读取 --password string 定位所请求 chart 的仓库密码 --plain-http chart 下载时使用不安全的 HTTP 连接 --sign 使用 PGP 私钥签名此包 --username string 定位所请求 chart 的仓库用户名 --version string 设置 chart 的版本为此 semver 版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- 安装、列举或卸载 Helm 插件 ### 简介 管理客户端 Helm 插件。 ### 可选项 ```shell -h, --help plugin 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 * [helm plugin install](/helm/helm_plugin_install.md) - 安装一个或多个 Helm 插件 * [helm plugin list](/helm/helm_plugin_list.md) - 列举已安装的 Helm 插件 * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - 卸载一个或多个 Helm 插件 * [helm plugin update](/helm/helm_plugin_update.md) - 升级一个或多个 Helm 插件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- 安装 Helm 插件 ### 简介 该命令允许您从 VCS 仓库 URL 或本地路径安装插件。 ```shell helm plugin install [options] [flags] ``` ### 可选项 ```shell -h, --help install 命令帮助 --version string 指定版本约束。如果未指定，将安装最新版本 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- 列举已安装的 Helm 插件 ```shell helm plugin list [flags] ``` ### 可选项 ```shell -h, --help list 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- 卸载一个或多个 Helm 插件 ```shell helm plugin uninstall ... [flags] ``` ### 可选项 ```shell -h, --help uninstall 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- 升级一个或多个 Helm 插件 ```shell helm plugin update ... [flags] ``` ### 可选项 ```shell -h, --help update 命令帮助 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm plugin](/helm/helm_plugin.md) - 安装、列举或卸载 Helm 插件 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- 从仓库下载 chart 并（可选）在本地目录解压 ### 简介 从包仓库中检索包并下载到本地。 此命令用于获取包以便检查、修改或重新打包。还可以用于在不安装 chart 的情况下对 chart 进行加密验证。 下载 chart 后有解压选项，会为 chart 创建一个目录并解压到该目录中。 如果指定了 `--verify` 参数，请求的 chart 必须有出处文件，且必须通过验证。任意部分的失败都会导致错误，且 chart 不会在本地保存。 ```shell helm pull [chart URL | repo/chartname] [...] [flags] ``` ### 可选项 ```shell --ca-file string 使用此 CA 证书包验证启用 HTTPS 的服务器证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 -d, --destination string chart 写入位置。如果同时指定了 untardir，则 untardir 会附加到此路径（默认 "."） --devel 同时使用开发版本。等价于版本 '>0.0.0-0'。如果设置了 --version，则忽略此参数 -h, --help pull 命令帮助 --insecure-skip-tls-verify 跳过 chart 下载时的 TLS 证书验证 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --prov 获取出处文件，但不执行验证 --repo string chart 仓库 URL --untar 如果设置为 true，下载后解压 chart --untardir string 如果指定了 untar，此参数指定 chart 解压到的目录名称（默认 "."） --username string chart 仓库用户名 --verify 使用前验证包 --version string 指定 chart 版本约束。可以是特定标签（如 1.1.1）或有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器。 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- 将 chart 推送到远程 ### 简介 上传 chart 到注册表。 如果 chart 有关联的出处文件（provenance file），也会一起上传。 ```shell helm push [chart] [remote] [flags] ``` ### 可选项 ```shell --ca-file string 使用此 CA 证书包验证启用 HTTPS 的服务器证书 --cert-file string 使用此 SSL 证书文件标识 registry 客户端 -h, --help push 命令帮助 --insecure-skip-tls-verify 跳过 chart 上传时的 TLS 证书验证 --key-file string 使用此 SSL 密钥文件标识 registry 客户端 --password string chart 仓库密码 --plain-http 对 chart 上传使用不安全的 HTTP 连接 --username string chart 仓库用户名 ``` ### 从父命令继承的选项 ```shell --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的用户组，可重复使用此参数指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接使用的证书颁发机构文件 --kube-context string 使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不会验证 Kubernetes API 服务器的证书有效性，这会使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称，如果未提供，则使用连接服务器时的主机名 --kube-token string 用于身份验证的 bearer 令牌 --kubeconfig string kubeconfig 文件路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发请求 --registry-config string registry 配置文件路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器。 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- 登录或登出注册表 ### 简介 该命令由多个子命令组成，用于与注册表交互。 ### 可选项 ``` -h, --help registry 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 * [helm registry login](/helm/helm_registry_login.md) - 登录注册表 * [helm registry logout](/helm/helm_registry_logout.md) - 登出注册表 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- 登录注册表 ### 简介 向远程注册表进行身份验证。 ``` helm registry login [host] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识注册表客户端 -h, --help login 的帮助信息 --insecure 允许在没有证书的情况下连接 TLS 注册表 --key-file string 使用此 SSL 密钥文件标识注册表客户端 -p, --password string 注册表密码或身份令牌 --password-stdin 从标准输入读取密码或身份令牌 --plain-http 对 chart 上传使用不安全的 HTTP 连接 -u, --username string 注册表用户名 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm registry](/helm/helm_registry.md) - 登录或登出注册表 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- 从注册表登出 ### 简介 从远程注册表移除认证信息。 ```shell helm registry logout [host] [flags] ``` ### 可选项 ```shell -h, --help help for logout ``` ### 从父命令继承的可选项 ```shell --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 请参阅 * [helm registry](/helm/helm_registry.md) - 登录或登出注册表 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- 添加、列出、删除、更新和索引 chart 仓库 ### 简介 该命令包含多个子命令，用于与 chart 仓库交互。 可用于添加、删除、列举和索引 chart 仓库。 ### 可选项 ``` -h, --help repo 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 * [helm repo add](/helm/helm_repo_add.md) - 添加 chart 仓库 * [helm repo index](/helm/helm_repo_index.md) - 基于包含打包 chart 的目录，生成索引文件 * [helm repo list](/helm/helm_repo_list.md) - 列举 chart 仓库 * [helm repo remove](/helm/helm_repo_remove.md) - 删除一个或多个仓库 * [helm repo update](/helm/helm_repo_update.md) - 从 chart 仓库中更新本地可用 chart 的信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- 添加 chart 仓库 ``` helm repo add [NAME] [URL] [flags] ``` ### 可选项 ``` --allow-deprecated-repos 默认情况下，此命令不允许添加已被永久删除的官方仓库。此选项可禁用该行为 --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --force-update 如果仓库已存在则替换（覆盖） -h, --help add 的帮助信息 --insecure-skip-tls-verify 跳过仓库的 TLS 证书检查 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --no-update 已忽略。以前用于禁用强制更新，现已被 force-update 取代 --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --password-stdin 从标准输入读取 chart 仓库密码 --timeout duration 等待索引文件下载完成的时间（默认 2m0s） --username string chart 仓库用户名 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- 基于包含打包 chart 的目录生成索引文件 ### 简介 读取当前目录，根据找到的 chart 生成索引文件，并将结果写入当前目录下的 'index.yaml' 文件。 这个工具用于为 chart 仓库创建 'index.yaml' 文件。使用 `--url` 参数可设置 chart 的绝对 URL。 要将生成的索引与已有索引文件合并，使用 `--merge` 参数。此时，当前目录中找到的 chart 会合并到 `--merge` 指定的索引文件中，本地 chart 优先于已有 chart。 ``` helm repo index [DIR] [flags] ``` ### 可选项 ``` -h, --help index 的帮助信息 --json 以 JSON 格式输出 --merge string 将生成的索引合并到指定的索引文件 --url string chart 仓库的 URL ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- 列举 chart 仓库 ``` helm repo list [flags] ``` ### 可选项 ``` -h, --help list 的帮助信息 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- 删除一个或多个 chart 仓库 ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### 可选项 ``` -h, --help remove 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- 从 chart 仓库中更新本地可用 chart 的信息 ### 简介 此命令从各个 chart 仓库获取 chart 的最新信息。信息会缓存在本地，供 `helm search` 等命令使用。 你可以指定需要更新的仓库列表。 $ helm repo update ... 使用 `helm repo update` 更新所有仓库。 ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### 可选项 ``` --fail-on-repo-update-fail 任一仓库更新失败则整体失败 -h, --help update 的帮助信息 --timeout duration 等待索引文件下载完成的时间（默认 2m0s） ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm repo](/helm/helm_repo.md) - 添加、列出、删除、更新和索引 chart 仓库 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- 将 release 回滚到之前的修订版本 ### 简介 该命令将 release 回滚到之前的修订版本。 回滚命令的第一个参数是 release 的名称，第二个参数是修订（版本）号。如果省略此参数或设置为 0，将回滚到上一个修订版本。 要查看修订号，运行 'helm history RELEASE'。 ``` helm rollback [REVISION] [flags] ``` ### 可选项 ``` --cleanup-on-fail 允许在回滚失败时删除此次回滚中创建的新资源 --dry-run 模拟回滚 --force 如有需要，通过删除/重建策略强制更新资源 -h, --help rollback 的帮助信息 --history-max int 限制每个 release 保存的最大修订版本数。使用 0 表示无限制（默认 10） --no-hooks 阻止回滚期间运行钩子 --recreate-pods 如果适用，对资源执行 Pod 重启 --timeout duration 等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s） --wait 如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态后才将 release 标记为成功。等待时间与 --timeout 一致 --wait-for-jobs 如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 一致 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发流量 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存的仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- 使用关键字搜索 chart ### 简介 该命令可以在多个位置搜索 Helm chart，包括 Artifact Hub 和你已添加的仓库。可以使用搜索子命令在不同位置搜索 chart。 ### 可选项 ``` -h, --help search 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含已缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 * [helm search hub](/helm/helm_search_hub.md) - 在 Artifact Hub 或你自己的 hub 实例中搜索 chart * [helm search repo](/helm/helm_search_repo.md) - 使用关键字搜索仓库中的 chart ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- 在 Artifact Hub 或自定义 hub 实例中搜索 chart ### 简介 在 Artifact Hub 或自定义 hub 实例中搜索 Helm chart。 Artifact Hub 是一个基于 Web 的应用，支持查找、安装和发布 CNCF 项目的包和配置，包括公开发布的 Helm chart。它是 CNCF 的沙盒项目。可以访问 https://artifacthub.io/ 浏览。 [KEYWORD] 参数接受关键字字符串或带引号的富查询字符串。富查询选项的文档，请参阅 https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search 之前的 Helm 版本使用 Monocular 实例作为默认 `endpoint`，因此为了向后兼容，Artifact Hub 兼容 Monocular 搜索 API。类似地，设置 `endpoint` 参数时，指定的 endpoint 也必须实现兼容 Monocular 的搜索 API。 注意，指定 Monocular 实例作为 `endpoint` 时，不支持富查询。更多 API 细节，请参阅 https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### 可选项 ``` --endpoint string 要查询 chart 的 hub 实例（默认 "https://hub.helm.sh"） --fail-on-no-result 如果没有搜索结果则返回失败 -h, --help hub 的帮助信息 --list-repo-url 输出 chart 仓库的 URL --max-col-width uint 输出表格的最大列宽（默认 50） -o, --output format 以指定格式输出。允许的值：table、json、yaml（默认 table） ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- 使用关键字搜索仓库中的 chart ### 简介 该命令会读取系统上配置的所有仓库，并查找匹配项。搜索基于系统中存储的仓库元数据。 该命令会显示找到的 chart 的最新稳定版本。如果指定了 `--devel` 参数，输出会包含预发布版本。如果要使用版本约束进行搜索，请使用 `--version`。 示例： # 搜索与关键字 "nginx" 匹配的稳定发布版本 $ helm search repo nginx # 搜索与关键字 "nginx" 匹配的发布版本，包括预发布版本 $ helm search repo nginx --devel # 搜索 nginx-ingress 主版本号为 1 的最新稳定版本 $ helm search repo nginx-ingress --version ^1.0.0 仓库使用 `helm repo` 命令管理。 ``` helm search repo [keyword] [flags] ``` ### 可选项 ``` --devel 同时使用开发版本（alpha、beta 和候选发布版本）。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 --fail-on-no-result 如果没有搜索结果则返回失败 -h, --help repo 的帮助信息 --max-col-width uint 输出表格的最大列宽（默认 50） -o, --output format 以指定格式输出。允许的值：table、json、yaml（默认 table） -r, --regexp 使用正则表达式搜索已添加的仓库 --version string 在已添加的仓库中使用语义化版本约束进行搜索 -l, --versions 在已添加的仓库中显示详细列表，每个 chart 的每个版本单独一行 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm search](/helm/helm_search.md) - 在 chart 中搜索关键字 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- 显示 chart 信息 ### 简介 此命令包含多个子命令，用于查看 chart 信息 ### 可选项 ``` -h, --help show 的帮助信息 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - Kubernetes 的 Helm 包管理器 - [helm show all](/helm/helm_show_all.md) - 显示 chart 的所有信息 - [helm show chart](/helm/helm_show_chart.md) - 显示 chart 的定义 - [helm show crds](/helm/helm_show_crds.md) - 显示 chart 的 CRD - [helm show readme](/helm/helm_show_readme.md) - 显示 chart 的 README - [helm show values](/helm/helm_show_values.md) - 显示 chart 的 values ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- 显示 chart 的所有信息 ### 简介 该命令检查 chart（目录、文件或 URL）并显示所有内容 （values.yaml、Chart.yaml、README） ``` helm show all [CHART] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 -h, --help all 的帮助信息 --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --repo string chart 仓库 URL --username string chart 仓库用户名 --verify 使用前验证此包 --version string 指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm show](/helm/helm_show.md) - 显示 chart 信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- 显示 chart 的定义 ### 简介 该命令检查 chart（目录、文件或 URL）并显示 Chart.yaml 文件的内容 ``` helm show chart [CHART] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 -h, --help chart 的帮助信息 --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --repo string chart 仓库 URL --username string chart 仓库用户名 --verify 使用前验证此包 --version string 指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm show](/helm/helm_show.md) - 显示 chart 信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- 显示 chart 的 CRD ### 简介 该命令检查 chart（目录、文件或 URL）并显示 CustomResourceDefinition 文件的内容 ``` helm show crds [CHART] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 -h, --help crds 的帮助信息 --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --repo string chart 仓库 URL --username string chart 仓库用户名 --verify 使用前验证此包 --version string 指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm show](/helm/helm_show.md) - 显示 chart 信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- 显示 chart 的 README ### 简介 该命令检查 chart（目录、文件或 URL）并显示 README 文件的内容 ``` helm show readme [CHART] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 -h, --help readme 的帮助信息 --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --repo string chart 仓库 URL --username string chart 仓库用户名 --verify 使用前验证此包 --version string 指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm show](/helm/helm_show.md) - 显示 chart 信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- 显示 chart 的 values ### 简介 该命令检查 chart（目录、文件或 URL）并显示 values.yaml 文件的内容 ``` helm show values [CHART] [flags] ``` ### 可选项 ``` --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 -h, --help values 的帮助信息 --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --jsonpath string 提供 JSONPath 表达式来过滤输出 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --repo string chart 仓库 URL --username string chart 仓库用户名 --verify 使用前验证此包 --version string 指定 chart 版本约束。可以是特定 tag（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，使用最新版本 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 操作时模拟的组，此参数可重复指定多个组 --kube-as-user string 操作时模拟的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果设置为 true，将不会验证 Kubernetes API 服务器的证书。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器时的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm show](/helm/helm_show.md) - 显示 chart 信息 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- 显示指定 release 的状态 ### 简介 该命令显示指定 release 的状态。 状态包括： - 最后部署时间 - release 所在的 Kubernetes namespace - release 状态（可以是：unknown、deployed、uninstalled、superseded、failed、uninstalling、pending-install、pending-upgrade 或 pending-rollback） - release 的修订版本号 - release 的描述（可以是完成信息或错误信息，需要启用 --show-desc） - release 包含的资源列表（需要启用 --show-resources） - 最后一次测试套件运行的详细信息（如适用） - chart 提供的附加说明 ``` helm status RELEASE_NAME [flags] ``` ### 可选项 ``` -h, --help status 的帮助信息 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） --revision int 如果设置，显示指定 release 对应修订版本的状态 --show-desc 如果设置，显示指定 release 的描述信息 --show-resources 如果设置，显示指定 release 的资源 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- 本地渲染模板 ### 简介 本地渲染 chart 模板并显示输出。 通常在集群中查找或检索到的任何值都会在本地模拟。另外，不会执行任何服务端对 chart 的有效性验证（例如检查某个 API 是否支持）。 ``` helm template [NAME] [CHART] [flags] ``` ### 可选项 ``` -a, --api-versions strings 用于 Capabilities.APIVersions 的 Kubernetes api 版本 --atomic 如果设置，安装过程在失败时删除已安装的内容。使用 --atomic 时会自动设置 --wait 参数 --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --create-namespace 如果 release namespace 不存在则创建 --dependency-update 如果缺少依赖项，在安装 chart 之前更新依赖项 --description string 添加自定义描述 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 --disable-openapi-validation 如果设置，安装过程不会根据 Kubernetes OpenAPI Schema 验证渲染的模板 --dry-run string[="client"] 模拟安装。如果设置 --dry-run 时未指定选项或指定为 '--dry-run=client'，则不会尝试连接集群。设置 '--dry-run=server' 允许尝试连接集群。 --enable-dns 在渲染模板时启用 DNS 查询 --force 通过替换策略强制更新资源 -g, --generate-name 生成名称（并省略 NAME 参数） -h, --help template 的帮助信息 --hide-notes 如果设置，不在安装输出中显示 notes。不影响 chart 元数据中的存在 --include-crds 在模板输出中包含 CRD --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 --is-upgrade 设置 .Release.IsUpgrade 而不是 .Release.IsInstall --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） --kube-version string 用于 Capabilities.KubeVersion 的 Kubernetes 版本 -l, --labels stringToString 将添加到 release 元数据的标签。应以逗号分隔。（默认 []） --name-template string 指定用于命名 release 的模板 --no-hooks 阻止在安装过程中运行 hook --output-dir string 将执行的模板写入 output-dir 中的文件，而不是 stdout --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 使用不安全的 HTTP 连接下载 chart --post-renderer postRendererString 用于后渲染的可执行文件路径。如果存在于 $PATH 中，将使用该二进制文件，否则将尝试在给定路径查找可执行文件 --post-renderer-args postRendererArgsSlice 后渲染器的参数（可多次指定）（默认 []） --release-name 在 output-dir 路径中使用 release 名称 --render-subchart-notes 如果设置，与父级一起渲染子 chart 的 notes --replace 重复使用给定名称，仅当该名称是仍保留在历史记录中的已删除 release 时。这在生产环境中不安全 --repo string chart 仓库 URL --set stringArray 在命令行上设置值（可以多次指定或用逗号分隔值：key1=val1,key2=val2） --set-file stringArray 通过命令行从相应文件设置值（可以多次指定或用逗号分隔值：key1=path1,key2=path2） --set-json stringArray 在命令行上设置 JSON 值（可以多次指定或用逗号分隔值：key1=jsonval1,key2=jsonval2） --set-literal stringArray 在命令行上设置字面 STRING 值 --set-string stringArray 在命令行上设置 STRING 值（可以多次指定或用逗号分隔值：key1=val1,key2=val2） -s, --show-only stringArray 仅显示从给定模板渲染的清单 --skip-crds 如果设置，不会安装 CRD。默认情况下，如果 CRD 不存在则会安装 --skip-schema-validation 如果设置，禁用 JSON schema 验证 --skip-tests 从模板输出中跳过测试 --take-ownership 如果设置，安装将忽略 helm 注解检查并接管现有资源的所有权 --timeout duration 等待任何单个 Kubernetes 操作（如 hook 的 Job）的时间（默认 5m0s） --username string chart 仓库用户名 --validate 根据当前指向的 Kubernetes 集群验证清单。这与安装时执行的验证相同 -f, --values strings 在 YAML 文件或 URL 中指定值（可多次指定） --verify 使用前验证包 --version string 指定要使用的 chart 版本约束。可以是特定标签（如 1.1.1）或有效范围（如 ^2.0.0）。如果未指定，使用最新版本 --wait 如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态，然后才将 release 标记为成功。等待时间与 --timeout 相同 --wait-for-jobs 如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 相同 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认节流限制（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，则不会验证 Kubernetes API 服务器的证书有效性。这将使 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](./helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- 执行 release 的测试 ### 简介 test 命令执行 release 的测试。 该命令的参数是已部署 release 的名称。要运行的测试在已安装的 chart 中定义。 ``` helm test [RELEASE] [flags] ``` ### 可选项 ``` --filter strings 通过属性（当前为 "name"）使用 attribute=value 语法指定测试，或使用 '!attribute=value' 排除测试（可指定多个或用逗号分隔值：name=test1,name=test2） -h, --help test 的帮助信息 --hide-notes 如果设置，不在测试输出中显示 notes。不影响 chart 元数据中的存在 --logs 转储测试 Pod 的日志（在所有测试完成后、清理之前运行） --timeout duration 等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s） ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- 卸载 release ### 简介 该命令使用 release 名称卸载 release。 会删除与该 release 最后一次部署的 chart 相关的所有资源，以及发布历史，释放以供将来使用。 使用 `--dry-run` 参数查看哪些 release 将被卸载，而不实际执行卸载操作。 ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### 可选项 ``` --cascade string 必须是 "background"、"orphan" 或 "foreground"。选择依赖资源的级联删除策略。默认是 background。 --description string 添加自定义描述 --dry-run 模拟卸载 -h, --help uninstall 的帮助信息 --ignore-not-found 将 "release not found" 视为卸载成功 --keep-history 删除所有关联资源并将 release 标记为已删除，但保留发布历史 --no-hooks 卸载时禁止钩子运行 --timeout duration 等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s） --wait 如果设置，将等待所有资源删除后再返回。等待时间与 --timeout 一致 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的命名空间范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 * [helm](./helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- 升级 release 版本 ### 简介 该命令将 release 升级到新版本的 chart。 升级参数必须是 release 和 chart。chart 参数可以是：chart 引用（'example/mariadb'）、chart 目录路径、打包的 chart 或者完整的 URL。对于 chart 引用，除非使用 '--version' 参数指定，否则会使用最新版本。 要覆盖 chart 中的 values，使用 '--values' 参数传递一个文件，或者使用 '--set' 参数从命令行传递配置，要强制使用字符串值，使用 '--set-string'。当值本身对于命令行太长或者是动态生成的时候，可以使用 '--set-file' 设置单独的值。也可以在命令行使用 '--set-json' 参数设置 JSON 值（scalars/objects/arrays）。 可以多次指定 '--values'/'-f' 参数。最后（最右边）指定的文件优先级最高。例如，如果 myvalues.yaml 和 override.yaml 同时包含了名为 'Test' 的 key，override.yaml 中的值会优先使用： $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis 可以多次指定 '--set' 参数。最后（最右边）指定的优先级最高。例如，如果 'bar' 和 'newbar' 都设置了名为 'foo' 的 key，'newbar' 的值会优先使用： $ helm upgrade --set foo=bar --set foo=newbar redis ./redis 你也可以使用此命令通过 '--reuse-values' 参数更新现有 release 的 values。'RELEASE' 和 'CHART' 参数应设置为原始参数，现有的 values 会与通过 '--values'/'-f' 或 '--set' 参数设置的任何值合并。新值优先。 $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis --dry-run 参数会输出所有生成的 chart 清单，包括可能包含敏感值的 Secret。要隐藏 Kubernetes Secret，请使用 --hide-secret 参数。请仔细考虑如何以及何时使用这些参数。 ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### 可选项 ``` --atomic 如果设置，升级过程在失败时回滚所做的更改。使用 --atomic 时会自动设置 --wait 参数 --ca-file string 使用此 CA 包验证启用 HTTPS 的服务器的证书 --cert-file string 使用此 SSL 证书文件标识 HTTPS 客户端 --cleanup-on-fail 允许在升级失败时删除此次升级中创建的新资源 --create-namespace 如果设置了 --install，当 release namespace 不存在时创建它 --dependency-update 如果缺少依赖项，在安装 chart 之前更新依赖项 --description string 添加自定义描述 --devel 同时使用开发版本。等同于 version '>0.0.0-0'。如果设置了 --version，则忽略此项 --disable-openapi-validation 如果设置，升级过程不会根据 Kubernetes OpenAPI Schema 验证渲染的模板 --dry-run string[="client"] 模拟升级。如果设置 --dry-run 时未指定选项或指定为 '--dry-run=client'，则不会尝试连接集群。设置 '--dry-run=server' 允许尝试连接集群。 --enable-dns 在渲染模板时启用 DNS 查询 --force 通过替换策略强制更新资源 -h, --help upgrade 的帮助信息 --hide-notes 如果设置，不在升级输出中显示 notes。不影响 chart 元数据中的存在 --hide-secret 同时使用 --dry-run 参数时隐藏 Kubernetes Secret --history-max int 限制每个 release 保存的最大修订版本数。使用 0 表示无限制（默认 10） --insecure-skip-tls-verify 跳过 chart 下载的 TLS 证书检查 -i, --install 如果不存在同名的 release，则运行安装 --key-file string 使用此 SSL 密钥文件标识 HTTPS 客户端 --keyring string 用于验证的公钥位置（默认 "~/.gnupg/pubring.gpg"） -l, --labels stringToString 将添加到 release 元数据的标签。应以逗号分隔。原始 release 标签将与升级标签合并。可以使用 null 取消标签设置。（默认 []） --no-hooks 禁用升级前/后的钩子 -o, --output format 以指定格式打印输出。允许的值：table、json、yaml（默认 table） --pass-credentials 将凭据传递给所有域 --password string chart 仓库密码 --plain-http 对 chart 下载使用不安全的 HTTP 连接 --post-renderer postRendererString 用于后渲染的可执行文件路径。如果它存在于 $PATH 中，将使用该二进制文件，否则将尝试在给定路径查找可执行文件 --post-renderer-args postRendererArgsSlice 传递给后渲染器的参数（可指定多个）（默认 []） --render-subchart-notes 如果设置，与父 chart 一起渲染子 chart 的 notes --repo string chart 仓库 URL --reset-then-reuse-values 升级时，将 values 重置为 chart 内置的值，应用上一次 release 的值，并通过命令行的 --set 和 -f 合并任何覆盖值。如果指定了 '--reset-values' 或 '--reuse-values'，则忽略此项 --reset-values 升级时，将 values 重置为 chart 内置的值 --reuse-values 升级时，重用上一次 release 的 values，并通过命令行的 --set 和 -f 合并任何覆盖值。如果指定了 '--reset-values'，则忽略此项 --set stringArray 在命令行设置 values（可以指定多个或用逗号分隔值：key1=val1,key2=val2） --set-file stringArray 通过命令行从相应文件设置 values（可以指定多个或用逗号分隔值：key1=path1,key2=path2） --set-json stringArray 在命令行设置 JSON values（可以指定多个或用逗号分隔值：key1=jsonval1,key2=jsonval2） --set-literal stringArray 在命令行设置字面 STRING 值 --set-string stringArray 在命令行设置 STRING values（可以指定多个或用逗号分隔值：key1=val1,key2=val2） --skip-crds 如果设置，当启用 install 参数执行升级时不会安装 CRD。默认情况下，当启用 install 参数执行升级时，如果 CRD 不存在则会安装 --skip-schema-validation 如果设置，禁用 JSON schema 验证 --take-ownership 如果设置，升级将忽略 helm 注解检查并接管现有资源的所有权 --timeout duration 等待任何单个 Kubernetes 操作的时间（如钩子的 Jobs）（默认 5m0s） --username string chart 仓库用户名 -f, --values strings 在 YAML 文件或 URL 中指定 values（可指定多个） --verify 使用前验证包 --version string 指定要使用的 chart 版本约束。此约束可以是特定标签（如 1.1.1）或引用有效范围（如 ^2.0.0）。如果未指定，则使用最新版本 --wait 如果设置，将等待所有 Pod、PVC、Service 以及 Deployment、StatefulSet 或 ReplicaSet 的最小 Pod 数处于就绪状态后才将 release 标记为成功。等待时间与 --timeout 一致 --wait-for-jobs 如果设置且启用了 --wait，将等待所有 Job 完成后才将 release 标记为成功。等待时间与 --timeout 一致 ``` ### 从父命令继承的选项 ``` --burst-limit int 客户端默认限流值（默认 100） --debug 启用详细输出 --kube-apiserver string Kubernetes API 服务器的地址和端口 --kube-as-group stringArray 模拟操作的组，此参数可以重复指定多个组 --kube-as-user string 模拟操作的用户名 --kube-ca-file string Kubernetes API 服务器连接的证书颁发机构文件 --kube-context string 要使用的 kubeconfig 上下文名称 --kube-insecure-skip-tls-verify 如果为 true，将不检查 Kubernetes API 服务器证书的有效性。这会使你的 HTTPS 连接不安全 --kube-tls-server-name string 用于 Kubernetes API 服务器证书验证的服务器名称。如果未提供，则使用联系服务器的主机名 --kube-token string 用于身份验证的 bearer token --kubeconfig string kubeconfig 文件的路径 -n, --namespace string 此请求的 namespace 范围 --qps float32 与 Kubernetes API 通信时使用的每秒查询数，不包括突发 --registry-config string registry 配置文件的路径（默认 "~/.config/helm/registry/config.json"） --repository-cache string 包含缓存仓库索引的目录路径（默认 "~/.cache/helm/repository"） --repository-config string 包含仓库名称和 URL 的文件路径（默认 "~/.config/helm/repositories.yaml"） ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- 验证给定路径的 chart 已经被签名且有效 ### 简介 验证指定的 chart 有合法的来源文件。 来源文件提供了加密验证，保证 chart 未被篡改，且由可信提供商打包。 该命令用于验证本地 chart，其他一些命令提供 `--verify` 参数执行同样的验证。要生成一个签名包，使用 `helm package --sign` 命令。 ```shell helm verify PATH [flags] ``` ### 可选项 ```shell -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### 从父命令继承的选项 ```shell --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 请参阅 - [helm](/helm/helm.md) - 针对 Kubernetes 的 Helm 包管理器 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- 打印客户端版本信息 ### 简介 显示Helm的版本。 该命令会打印Helm的版本描述，输出如下： version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version 是 release 的语义化版本。 - GitCommit 是构建此版本时的提交 SHA。 - 如果构建二进制包时没有本地代码修改，GitTreeState 为 "clean"；否则为 "dirty"。 - GoVersion 是编译 Helm 所用的 Go 版本。 当使用 `--template` 参数时，下列属性在模板中可用： - `.Version` 包含 Helm 的语义化版本 - `.GitCommit` 是 git 提交哈希 - `.GitTreeState` 是 Helm 构建时的 git 树状态 - `.GoVersion` 包含编译 Helm 所用的 Go 版本 例如，`--template='Version: {{.Version}}'` 输出 `Version: v3.2.1`。 ```shell helm version [flags] ``` ### 可选项 ```shell -h, --help help for version --short print the version number --template string template for version string format ``` ### 从父命令继承的命令 ```shell --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### 请参阅 - [helm](./helm.md) - Kubernetes 的 Helm 包管理器 ###### 由 spf13/cobra 于 2026-01-14 自动生成 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/helm/index.mdx ================================================ --- title: Helm 命令行 description: helm CLI 命令行的全部文档内容。 sidebar_position: 6 id: helm-category --- # Helm 命令行 这里可以看到 Helm 命令行列表和使用帮助。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/howto/chart_releaser_action.md ================================================ --- title: 使用 Chart Releaser Action 自动发布 GitHub Pages Chart description: 介绍如何使用 Chart Releaser Action 通过 GitHub Pages 自动发布 chart。 sidebar_position: 3 --- 本指南介绍如何使用 [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) 通过 GitHub Pages 自动发布 chart。Chart Releaser Action 是一个 GitHub Action 工作流，可将 GitHub 项目转换为自托管的 Helm chart 仓库，基于 [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI 工具。 ## 仓库配置 在你的 GitHub 组织下创建一个 Git 仓库。可以将仓库命名为 `helm-charts`，当然其他名称也可以。所有 chart 的源代码都放在 `main` 分支，chart 应该位于根目录下的 `/charts` 目录中。 还需要另一个名为 `gh-pages` 的分支来发布 chart。该分支的内容会由 Chart Releaser Action 自动创建和更新。你也可以手动创建 `gh-pages` 分支并添加 `README.md` 文件，该文件会对访问页面的用户可见。 你可以在 `README.md` 中添加 chart 的安装说明，例如（将 ``、`` 和 `` 替换为实际值）： ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` 发布后的 chart 会托管在如下 URL： https://.github.io/helm-charts ## GitHub Actions 工作流 在 `main` 分支创建 GitHub Actions 工作流文件 `.github/workflows/release.yml`： ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` 上述配置使用 [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) 将 GitHub 项目转换为自托管的 Helm chart 仓库。每次向 `main` 分支推送时，它会检查项目中的每个 chart，当发现新的 chart 版本时，会创建一个以该版本命名的 GitHub Release，将 Helm chart 制品添加到该 Release 中，并创建或更新 `index.yaml` 文件（包含这些 Release 的元数据），然后托管在 GitHub Pages 上。 上述示例使用的 Chart Releaser Action 版本号是 `v1.6.0`。你可以将其更改为[最新可用版本](https://github.com/helm/chart-releaser-action/releases)。 注意：Chart Releaser Action 几乎总是与 [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) 和 [Kind Action](https://github.com/marketplace/actions/kind-cluster) 配合使用。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: 同步你的 Chart 仓库 description: 介绍如何同步本地和远程 chart 仓库。 sidebar_position: 2 --- *注意：该示例演示如何使用 Google Cloud Storage (GCS) bucket 托管 chart 仓库。* ## 先决条件 * 安装 [gsutil](https://cloud.google.com/storage/docs/gsutil) 工具。*我们非常依赖 gsutil rsync 功能* * 确保可以使用 Helm * _可选：建议为 GCS bucket 启用[对象版本控制](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page)，以防不小心删除了文件。_ ## 设置本地 chart 仓库目录 参考 [chart 仓库指南](/zh/docs/topics/chart_repository)创建本地目录，并将打包好的 chart 放在该目录中。 例如： ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## 生成更新的 index.yaml 使用 Helm 生成更新的 index.yaml 文件，将目录路径和远程仓库 URL 传递给 `helm repo index` 命令： ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` 这会生成更新的 index.yaml 文件并放在 `fantastic-charts/` 目录中。 ## 同步本地和远程仓库 运行 `scripts/sync-repo.sh` 脚本将目录内容上传到 GCS bucket，传入本地目录名和 bucket 名称作为参数。 例如： ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## 更新你的 chart 仓库 保留 chart 仓库的本地副本，或使用 `gsutil rsync` 将远程内容同步到本地目录。 例如： ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` 相关链接： * [gsutil rsync 文档](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [Chart 仓库指南](/zh/docs/topics/chart_repository) * Google Cloud Storage 的[对象版本控制和并发控制](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Chart 开发提示和技巧 description: 介绍 Helm chart 开发者在构建生产级 chart 时积累的一些提示和技巧。 sidebar_position: 1 --- 本指南介绍 Helm chart 开发者在构建生产级 chart 时积累的一些提示和技巧。 ## 了解模板函数 Helm 使用 [Go 模板](https://godoc.org/text/template) 来渲染资源文件。Go 自带了一些内置函数，我们还额外添加了许多其他函数。 首先，我们添加了 [Sprig 库](https://masterminds.github.io/sprig/) 中的所有函数，出于安全原因，`env` 和 `expandenv` 除外。 我们还添加了两个特殊的模板函数：`include` 和 `required`。`include` 函数允许你引入另一个模板，并将结果传递给其他模板函数。 例如，以下模板片段引入了名为 `mytpl` 的模板，然后将结果转为小写，并用双引号括起来： ```yaml value: {{ include "mytpl" . | lower | quote }} ``` `required` 函数允许你声明模板渲染所需的特定值。如果该值为空，模板渲染将失败并显示用户指定的错误信息。 以下 `required` 函数示例声明 `.Values.who` 条目是必需的，如果缺少该条目将打印错误信息： ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## 字符串要加引号，整数不要 处理字符串数据时，用引号括起来总是更安全： ```yaml name: {{ .Values.MyName | quote }} ``` 但处理整数时，_不要加引号_。这在很多情况下会导致 Kubernetes 解析错误。 ```yaml port: {{ .Values.Port }} ``` 这条规则不适用于环境变量值——即使表示整数，环境变量也应该是字符串： ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## 使用 'include' 函数 Go 提供了一种使用内置 `template` 指令在模板中包含另一个模板的方法。但是，内置函数无法在 Go 模板管道中使用。 为了包含模板并处理其输出，Helm 提供了特殊的 `include` 函数： ``` {{ include "toYaml" $value | indent 2 }} ``` 上面的代码引入了名为 `toYaml` 的模板，将 `$value` 传递给它，然后将该模板的输出传递给 `indent` 函数。 由于 YAML 对缩进级别和空白敏感，这是一种很好的方式来包含代码片段，同时在相关上下文中处理缩进。 ## 使用 'required' 函数 Go 提供了一种设置模板选项的方法，用于控制当使用不存在的键索引 map 时的行为。通常使用 `template.Options("missingkey=option")` 来设置，其中 `option` 可以是 `default`、`zero` 或 `error`。虽然将此选项设置为 error 会在遇到缺失键时停止执行并报错，但这会应用于 map 中的每个缺失键。在某些情况下，chart 开发者可能希望对 `values.yaml` 文件中的特定值强制执行此行为。 `required` 函数允许开发者声明模板渲染必需的值条目。如果该条目在 `values.yaml` 中为空，模板将不会渲染，并返回开发者指定的错误信息。 例如： ``` {{ required "A valid foo is required!" .Values.foo }} ``` 上面的代码在 `.Values.foo` 有定义时会正常渲染模板，但如果 `.Values.foo` 未定义则会渲染失败并退出。 ## 使用 'tpl' 函数 `tpl` 函数允许开发者在模板内部将字符串作为模板进行求值。这在将模板字符串作为值传递给 chart 或渲染外部配置文件时非常有用。语法：`{{ tpl TEMPLATE_STRING VALUES }}` 示例： ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` 渲染外部配置文件： ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## 创建镜像拉取 Secret 镜像拉取 Secret 本质上是 _registry_、_username_ 和 _password_ 的组合。在部署应用时可能需要它，但创建时需要多次运行 `base64`。我们可以编写一个辅助模板来生成 Docker 配置文件，作为 Secret 的数据载荷。示例如下： 首先，假设凭据在 `values.yaml` 文件中定义如下： ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` 然后定义辅助模板： ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` 最后，在更大的模板中使用辅助模板来创建 Secret 清单： ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## 自动滚动更新 Deployment ConfigMap 或 Secret 经常作为配置文件注入容器，或者存在其他外部依赖变更需要滚动更新 Pod。根据应用的不同，如果这些内容在后续 `helm upgrade` 时更新了，可能需要重启应用。但如果 Deployment spec 本身没有变化，应用会继续使用旧配置运行，导致部署不一致。 可以使用 `sha256sum` 函数确保当其他文件发生变化时，Deployment 的注解部分会被更新： ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` 注意：如果要将此添加到库 chart 中，你将无法使用 `$.Template.BasePath` 访问你的文件。作为替代，可以使用 `{{ include ("mylibchart.configmap") . | sha256sum }}` 引用你的定义。 如果你希望始终触发 Deployment 滚动更新，可以使用类似的注解方式，但用随机字符串替换，这样每次都会变化并触发滚动更新： ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` 每次调用模板函数都会生成唯一的随机字符串。这意味着如果需要同步多个资源使用的随机字符串，所有相关资源都需要放在同一个模板文件中。 这两种方法都允许你的 Deployment 利用内置的更新策略逻辑来避免停机。 注意：过去我们推荐使用 `--recreate-pods` 参数作为另一种选择。该参数在 Helm 3 中已被标记为弃用，请使用上面更具声明性的方法。 ## 告诉 Helm 不要卸载资源 有时某些资源在 Helm 执行 `helm uninstall` 时不应该被卸载。chart 开发者可以在资源上添加注解来防止其被卸载。 ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` 注解 `helm.sh/resource-policy: keep` 指示 Helm 在执行会导致资源删除的操作（如 `helm uninstall`、`helm upgrade` 或 `helm rollback`）时跳过该资源。_但是_，该资源会变成孤立状态。Helm 将不再以任何方式管理它。如果在已卸载但保留了资源的 release 上使用 `helm install --replace`，可能会导致问题。 ## 使用 Partial 和模板引用 有时你想在 chart 中创建一些可复用的部分，无论是代码块还是模板片段。通常，将这些内容放在单独的文件中会更清晰。 在 `templates/` 目录中，任何以下划线（`_`）开头的文件都不会输出 Kubernetes 清单文件。因此按照惯例，辅助模板和 partial 会放在 `_helpers.tpl` 文件中。 ## 包含多个依赖的复杂 Chart CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中的许多 chart 是创建更高级应用的"构建块"。但 chart 也可能用于创建大规模应用的实例。在这种情况下，一个总体 chart 可能有多个子 chart，每个子 chart 都是整体的一部分。 目前从离散组件组合复杂应用的最佳实践是：创建一个顶层总体 chart 来暴露全局配置，然后使用 `charts/` 子目录来嵌入各个组件。 ## YAML 是 JSON 的超集 根据 YAML 规范，YAML 是 JSON 的超集。这意味着任何有效的 JSON 结构在 YAML 中也应该是有效的。 好处是：有时模板开发者可能发现使用类 JSON 语法来表达数据结构比处理 YAML 的空白敏感性更容易。 作为最佳实践，模板应遵循类 YAML 语法，_除非_ JSON 语法能显著降低格式问题的风险。 ## 生成随机值时要小心 Helm 中有一些函数允许你生成随机数据、加密密钥等。这些函数用起来很方便。但要注意，在升级过程中模板会重新执行。当模板运行生成的数据与上次运行不同时，会触发该资源的更新。 ## 一条命令安装或升级 Release Helm 提供了将安装或升级合并为单个命令的方式。使用 `helm upgrade` 加上 `--install` 参数。这会让 Helm 检查该 release 是否已安装。如果没有，则执行安装。如果已存在，则升级现有 release。 ```console $ helm upgrade --install --values ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/howto/index.mdx ================================================ --- title: 如何使用 sidebar_position: 2 --- # 使用指引 这里您可以找到简单的“我如何做...”类型问题的简短答案。这些使用指引不能覆盖主题的深度，你可以在 [主题指引](/topics/index.mdx) 中获得更多内容。然而这些指引可以帮助您快速完成一般任务。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/index.mdx ================================================ --- title: "文档首页" description: "您需要知道的关于文档如何组织的所有内容。" --- # 欢迎 欢迎使用 [Helm](https://helm.sh/zh/) 文档。 Helm 是 Kubernetes 的包管理器，您也可以在 [CNCF Helm 项目过程报告](https://www.cncf.io/cncf-helm-project-journey/)阅读详细的背景信息。 # 文档构成 Helm 有大量的文档。高级组织概述会让您知道在哪里查找特定内容。 - [教程](/intro/index.mdx) 如果您是新手，从这里开始，手把手带您通过一系列的步骤创建您的第一个 Helm chart。 - [主题引导](/topics/index.mdx) 以相当高的水平讨论关键主题和概念并提供有用的背景信息和解释。 - [社区引导](/community) 讨论围绕社区的相关话题。如果您想了解更多关于 Helm 本身的开发过程以及如何参与开发，从这里开始。 - [如何做](/howto/index.mdx) 操作方法。 指引您按照步骤参与定位关键问题和使用案例。假定您对 Helm 工作原理有所了解的情况下，这些内容会比教程更加高级。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/intro/CheatSheet.md ================================================ --- title: 速查表 description: Helm 速查表 sidebar_position: 4 --- Helm 速查表包含了通过 Helm 管理应用所需的所有命令。 ----------------------------------------------------------------------------------------------------------------------------------------------- ### 基本概念说明 Chart： - 如果 chart 已被拉取并解压，则为 chart 目录名称。 - 如果仓库已添加但 chart 未被拉取，则为 /。 - 也可以是指向 chart 的 URL 或绝对路径。 Name： - 为本次 chart 安装指定的名称。 Release： - 分配给某次安装实例的名称。 Revision： - Helm history 命令返回的版本号。 Repo-name： - 仓库名称。 DIR： - 目录名称或路径。 ------------------------------------------------------------------------------------------------------------------------------------------------ ### Chart 管理 ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart's dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### 安装和卸载应用 ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### 应用升级和回滚 ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### 列出、添加、移除和更新仓库 ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm Release 监控 ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### 下载 Release 信息 ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### 插件管理 ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/intro/index.mdx ================================================ --- title: 介绍 sidebar_position: 1 --- # Helm 介绍 Helm 新手从这里开始。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/intro/install.md ================================================ --- title: 安装 Helm description: 了解如何安装并运行 Helm。 sidebar_position: 2 --- 本指南介绍如何安装 Helm CLI。Helm 可以通过源码或预构建的二进制版本安装。 ## 通过 Helm 项目安装 Helm 项目提供了两种获取和安装 Helm 的方式，这是官方提供的获取 Helm 发布版本的方法。此外，Helm 社区提供了通过不同包管理器安装 Helm 的方法，这些方法可以在下面的官方方法之后看到。 ### 通过二进制版本安装 每个 Helm [版本](https://github.com/helm/helm/releases)都提供了各种操作系统的二进制版本，这些版本可以手动下载和安装。 1. 下载[需要的版本](https://github.com/helm/helm/releases) 2. 解压（`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`） 3. 在解压目录中找到 `helm` 程序，移动到需要的目录中（`mv linux-amd64/helm /usr/local/bin/helm`） 完成后，你可以运行客户端程序并[添加稳定仓库](./quickstart.md#初始化-helm-chart-仓库)：`helm help`。 **注意：** Helm 的自动化测试仅在 GitHub Actions 构建和发布时针对 Linux AMD64 执行。其他操作系统的测试由对应平台的社区负责。 ### 使用脚本安装 Helm 提供了一个安装脚本，可以自动拉取最新版本并[在本地安装](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3)。 你可以下载这个脚本并在本地执行。脚本有详细的注释，建议在运行前阅读了解其功能。 ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` 如果想直接执行安装，运行 `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash`。 ## 通过包管理器安装 Helm 社区提供了通过操作系统包管理器安装 Helm 的方式。但 Helm 项目不支持这些方式，且不认为是可信的第三方。 ### 使用 Homebrew (macOS) Helm 社区成员贡献了一种在 Homebrew 构建 Helm 的方案，这个方案通常是最新的。 ```console brew install helm ``` （注意：还有一个 emacs-helm 的方案，当然这是另一个项目了。） ### 使用 Chocolatey (Windows) Helm 社区成员贡献了一个 [Helm 包](https://chocolatey.org/packages/kubernetes-helm)在 [Chocolatey](https://chocolatey.org/) 中构建，该包通常是最新的。 ```console choco install kubernetes-helm ``` ### 使用 Scoop (Windows) Helm 社区成员贡献了一个针对 [Scoop](https://scoop.sh) 的 [Helm 包](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json)，该包通常是最新的。 ```console scoop install helm ``` ### 使用 Winget (Windows) Helm 社区成员贡献了一个针对 [Winget](https://learn.microsoft.com/en-us/windows/package-manager/) 的 [Helm 包](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm)，该包通常是最新的。 ```console winget install Helm.Helm ``` ### 使用 Apt (Debian/Ubuntu) Helm 社区成员贡献了 Debian/Ubuntu 的 Apt 包，通常会保持最新。感谢 [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) 托管此仓库。 ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### 使用 dnf/yum (Fedora) 从 Fedora 35 开始，官方仓库可以使用 Helm 了，可以调用以下命令安装 Helm： ```console sudo dnf install helm ``` ### 使用 Snap [Snapcrafters](https://github.com/snapcrafters) 社区维护了 [Helm 包](https://snapcraft.io/helm)的 Snap 版本： ```console sudo snap install helm --classic ``` ### 使用 pkg (FreeBSD) FreeBSD 社区成员贡献了一个 [Helm 包](https://www.freshports.org/sysutils/helm)来构建 [FreeBSD 端口集](https://man.freebsd.org/ports)。该包通常是最新的。 ```console pkg install helm ``` ### 开发版本构建 除了正式版本，你还可以下载和安装 Helm 的开发版本。 ### 使用 Canary 构建 "Canary" 版本是从 Helm 最新的 `main` 分支构建的。这些不是官方版本，可能不稳定，但可以用于测试最新特性。 Canary Helm 二进制包存储在 [get.helm.sh](https://get.helm.sh)。以下是常用构建的链接： - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [实验性 Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### 使用源码构建 (Linux, macOS) 从源码构建 Helm 的工作要稍微多一点，但如果你想测试最新（预发布）的 Helm 版本，这是最好的方式。 你必须有可用的 Go 环境。 ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` 如果需要，会拉取依赖并缓存，然后验证配置。然后会编译 `helm` 并放在 `bin/helm`。 ## 总结 大多数情况下，安装只需获取一个构建好的 `helm` 二进制包。本文档涵盖了一些进阶安装场景。 一旦你成功安装了 Helm 客户端，就可以继续使用 Helm 管理 chart 和[添加稳定的仓库](./quickstart.md#初始化-helm-chart-仓库)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/intro/quickstart.md ================================================ --- title: 快速入门指南 description: 如何安装 Helm 并快速上手，包括发行版说明、常见问题和插件。 sidebar_position: 1 --- 本指南介绍如何快速开始使用 Helm。 ## 先决条件 想要成功且安全地使用 Helm，需要以下前置条件： 1. 一个 Kubernetes 集群 2. 确定安装时需要应用的安全配置（如有） 3. 安装和配置 Helm ### 安装或者使用现有的 Kubernetes 集群 - 使用 Helm，需要一个 Kubernetes 集群。对于 Helm 的最新版本，我们建议使用 Kubernetes 的最新稳定版， 通常是次新的 minor 版本。 - 你还需要有一个本地已配置好的 `kubectl`。 查看 Helm 和对应支持的 Kubernetes 版本，可以参考 [Helm 版本支持策略](../topics/version_skew.md)。 ## 安装 Helm 你可以通过 `homebrew` 下载二进制 Helm client 安装包，也可以通过 [GitHub 官方发布页面](https://github.com/helm/helm/releases) 下载。 更多安装方式请参阅 [安装指南](./install.md)。 ## 初始化 Helm Chart 仓库 安装好 Helm 之后，你可以添加一个 chart 仓库。从 [Artifact Hub](https://artifacthub.io/packages/search?kind=0) 中查找可用的 Helm chart 仓库。 ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` 添加完成后，你可以列出可安装的 chart： ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## 安装示例 Chart 你可以通过 `helm install` 命令安装 chart。 Helm 可以通过多种途径查找和安装 chart， 但最简单的是安装官方的 `bitnami` chart。 ```console $ helm repo update # 确保获取最新的 chart 列表 $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` 在上面的例子中，`bitnami/mysql` 这个 chart 被发布，名字是 `mysql-1612624192` 运行 `helm show chart bitnami/mysql` 可以快速了解该 chart 的基本信息。 运行 `helm show all bitnami/mysql` 可以获取该 chart 的所有信息。 每当你执行 `helm install` 的时候，都会创建一个新的 release。 所以一个 chart 可以在同一个集群里被安装多次，每一个都可以独立管理和升级。 `helm install` 是一个拥有很多能力的强大的命令，更多信息详见 [使用 Helm](./using_helm.md)。 ## 关于 Release 通过 Helm 你可以很容易看到哪些 chart 被发布了： ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` `helm list`（或 `helm ls`）命令会列出所有已部署的 release。 ## 卸载 Release 你可以使用 `helm uninstall` 命令卸载 release： ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` 该命令会从 Kubernetes 卸载 `mysql-1612624192`，删除该 release 相关的所有资源以及 release 历史。 如果你在执行 `helm uninstall` 的时候提供 `--keep-history` 选项，Helm 将会保存 release 历史。 你可以通过命令查看该 release 的信息： ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` 因为 `--keep-history` 选项会让 Helm 跟踪你的 release（即使你卸载了它们），所以你可以审计集群历史，甚至使用 `helm rollback` 回滚 release。 ## 查看帮助信息 如果你想了解更多可用的 Helm 命令，请使用 `helm help` 命令，或者在任意命令后添加 `-h` 选项： ```console $ helm get -h ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/intro/using_helm.md ================================================ --- title: 使用Helm description: 解释 Helm 的基础知识。 sidebar_position: 3 --- 本指南介绍了使用 Helm 来管理 Kubernetes 集群上的软件包的基础知识。本指南假定你已经[安装](./install.md)了 Helm 客户端。 如果你仅对运行一些快速命令感兴趣，则不妨从[快速入门指南](./quickstart.md)开始。本章包含了 Helm 命令的详细说明，并解释如何使用 Helm。 ## 三大概念 *Chart* 代表着 Helm 包。它包含在 Kubernetes 集群内部运行应用程序，工具或服务所需的所有资源定义。你可以把它看作是 Homebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等价物。 *Repository（仓库）* 是用来存放和共享 charts 的地方。它就像 Perl 的 [CPAN 档案库网络](https://www.cpan.org) 或是 Fedora 的[软件包仓库](https://src.fedoraproject.org/)，只不过它是供 Kubernetes 包所使用的。 *Release* 是运行在 Kubernetes 集群中的 chart 的实例。一个 chart 通常可以在同一个集群中安装多次。每一次安装都会创建一个新的 _release_。以 MySQL chart为例，如果你想在你的集群中运行两个数据库，你可以安装该chart两次。每一个数据库都会拥有它自己的 _release_ 和 _release name_。 在了解了上述这些概念以后，我们就可以这样来解释 Helm： Helm 安装 _charts_ 到 Kubernetes 集群中，每次安装都会创建一个新的 _release_。你可以在 Helm 的 chart _repositories_ 中寻找新的 chart。 ## 'helm search'：查找 Charts Helm 自带一个强大的搜索命令，可以用来从两种来源中进行搜索： - `helm search hub` 从 [Artifact Hub](https://artifacthub.io) 中查找并列出 helm charts。 Artifact Hub中存放了大量不同的仓库。 - `helm search repo` 从你添加（使用 `helm repo add`）到本地 helm 客户端中的仓库中进行查找。该命令基于本地数据进行搜索，无需连接互联网。 你可以通过运行 `helm search hub` 命令找到公开可用的charts： ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` 上述命令从 Artifact Hub 中搜索所有的 `wordpress` charts。 如果不进行过滤，`helm search hub` 命令会展示所有可用的 charts。 `helm search hub` 命令输出的 URL 指向 [artifacthub.io](https://artifacthub.io/) 上的页面位置，而非实际的 Helm 仓库地址。使用 `helm search hub --list-repo-url` 可以获取实际的 Helm 仓库 URL，这在你需要添加新仓库时非常有用：`helm repo add [NAME] [URL]`。 使用 `helm search repo` 命令，你可以从你所添加的仓库中查找chart的名字。 ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm 搜索使用模糊字符串匹配算法，所以你可以只输入名字的一部分： ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` 搜索是用来发现可用包的一个好办法。一旦你找到你想安装的 helm 包，你便可以通过使用 `helm install` 命令来安装它。 ## 'helm install'：安装一个 helm 包 使用 `helm install` 命令来安装一个新的 helm 包。最简单的使用方法只需要传入两个参数：你命名的release名字和你想安装的chart的名称。 ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` 现在`wordpress` chart 已经安装。注意安装chart时创建了一个新的 _release_ 对象。上述发布被命名为 `happy-panda`。 （如果想让Helm生成一个名称，删除发布名称并使用`--generate-name`。） 在安装过程中，`helm` 客户端会打印一些有用的信息，其中包括：哪些资源已经被创建，release当前的状态，以及你是否还需要执行额外的配置步骤。 Helm按照以下顺序安装资源： - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm 客户端不会等到所有资源都运行才退出。许多 charts 需要大小超过 600M 的 Docker 镜像，可能需要很长时间才能安装到集群中。 你可以使用 `helm status` 来追踪 release 的状态，或是重新读取配置信息： ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` 上述信息展示了 release 的当前状态。 ### 安装前自定义 chart 上述安装方式只会使用 chart 的默认配置选项。很多时候，我们需要自定义 chart 来指定我们想要的配置。 使用 `helm show values` 可以查看 chart 中的可配置选项： ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` 然后，你可以使用 YAML 格式的文件覆盖上述任意配置项，并在安装过程中使用该文件。 ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` 上述命令将为 MariaDB 创建一个名称为 `user0` 的默认用户，并且授予该用户访问新建的 `user0db` 数据库的权限。chart 中的其他默认配置保持不变。 安装过程中有两种方式传递配置数据： - `--values` (或 `-f`)：使用 YAML 文件覆盖配置。可以指定多次，优先使用最右边的文件。 - `--set`：通过命令行的方式对指定项进行覆盖。 如果同时使用两种方式，则 `--set` 中的值会被合并到 `--values` 中，但是 `--set` 中的值优先级更高。在`--set` 中覆盖的内容会被保存在 Secret 中。可以通过 `helm get values ` 来查看指定 release 中 `--set` 设置的值。也可以通过运行 `helm upgrade` 并指定 `--reset-values` 字段来清除 `--set` 中设置的值。 #### `--set` 的格式和限制 `--set` 选项使用0或多个 name/value 对。最简单的用法类似于：`--set name=value`，等价于如下 YAML 格式： ```yaml name: value ``` 多个值使用逗号分割，因此 `--set a=b,c=d` 的 YAML 表示是： ```yaml a: b c: d ``` 支持更复杂的表达式。例如，`--set outer.inner=value` 被转换成了： ```yaml outer: inner: value ``` 列表使用花括号（`{}`）来表示。例如，`--set name={a, b, c}` 被转换成了： ```yaml name: - a - b - c ``` 某些name/key可以设置为`null`或者空数组，例如 `--set name=[],a=null` 由 ```yaml name: - a - b - c a: b ``` 变成了 ```yaml name: [] a: null ``` 从 2.5.0 版本开始，可以使用数组下标的语法来访问列表中的元素。例如 `--set servers[0].port=80` 就变成了： ```yaml servers: - port: 80 ``` 多个值也可以通过这种方式来设置。`--set servers[0].port=80,servers[0].host=example` 变成了： ```yaml servers: - port: 80 host: example ``` 如果需要在 `--set` 中使用特殊字符，你可以使用反斜线来进行转义；`--set name=value1\,value2` 就变成了： ```yaml name: "value1,value2" ``` 类似的，你也可以转义点序列（英文句号）。这可能会在 chart 使用 `toYaml` 函数来解析 annotations，labels，和 node selectors 时派上用场。`--set nodeSelector."kubernetes\.io/role"=master` 语法就变成了： ```yaml nodeSelector: kubernetes.io/role: master ``` 深层嵌套的数据结构可能会很难用 `--set` 表达。我们希望 Chart 的设计者们在设计 `values.yaml` 文件的格式时，考虑到 `--set` 的使用。（更多内容请查看 [Values 文件](/chart_template_guide/values_files.md)） ### 更多安装方法 `helm install` 命令可以从多个来源进行安装： - chart 的仓库（如上所述） - 本地 chart 压缩包（`helm install foo foo-0.1.1.tgz`） - 解压后的 chart 目录（`helm install foo path/to/foo`） - 完整的 URL（`helm install foo https://example.com/charts/foo-1.2.3.tgz`） ## 'helm upgrade' 和 'helm rollback'：升级 release 和失败时恢复 当你想升级到 chart 的新版本，或是修改 release 的配置，你可以使用 `helm upgrade` 命令。 一次升级操作会使用已有的 release 并根据你提供的信息对其进行升级。由于 Kubernetes 的 chart 可能会很大而且很复杂，Helm 会尝试执行最小侵入式升级。即它只会更新自上次发布以来发生了更改的内容。 ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` 在上面的例子中，`happy-panda` 这个 release 使用相同的 chart 进行升级，但是使用了一个新的 YAML 文件： ```yaml mariadb.auth.username: user1 ``` 我们可以使用 `helm get values` 命令来看看配置值是否真的生效了： ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` `helm get` 是一个查看集群中 release 的有用工具。正如我们上面所看到的，`panda.yaml` 中的新值已经被部署到集群中了。 现在，假如在一次发布过程中，发生了不符合预期的事情，也很容易通过 `helm rollback [RELEASE] [REVISION]` 命令回滚到之前的发布版本。 ```console $ helm rollback happy-panda 1 ``` 上面这条命令将我们的 `happy-panda` 回滚到了它最初的版本。release 版本其实是一个增量修订（revision）。 每当发生了一次安装、升级或回滚操作，revision 的值就会加1。第一次 revision 的值永远是1。我们可以使用 `helm history [RELEASE]` 命令来查看一个特定 release 的修订版本号。 ## 安装、升级、回滚时的有用选项 你还可以指定一些其他有用的选项来自定义 Helm 在安装、升级、回滚期间的行为。请注意这并不是 cli 参数的完整列表。 要查看所有参数的说明，请执行 `helm --help` 命令。 - `--timeout`：一个 [Go duration](https://golang.org/pkg/time/#ParseDuration) 类型的值， 用来表示等待 Kubernetes 命令完成的超时时间，默认值为 `5m0s`。 - `--wait`：表示必须要等到所有的 Pods 都处于 ready 状态，PVC 都被绑定，Deployments 都至少拥有最小 ready 状态 Pods 个数（`Desired`减去 `maxUnavailable`），并且 Services 都具有 IP 地址（如果是`LoadBalancer`， 则为 Ingress），才会标记该 release 为成功。最长等待时间由 `--timeout` 值指定。如果达到超时时间，release 将被标记为 `FAILED`。注意：当 Deployment 的 `replicas` 被设置为1，但其滚动升级策略中的 `maxUnavailable` 没有被设置为0时，`--wait` 将返回就绪，因为已经满足了最小 ready Pod 数。 - `--no-hooks`：不运行当前命令的钩子。 - `--recreate-pods`（仅适用于 `upgrade` 和 `rollback`）：这个参数会导致重建所有的 Pod（deployment中的Pod 除外）。（在 Helm 3 中已被废弃） ## 'helm uninstall'：卸载 release 使用 `helm uninstall` 命令从集群中卸载一个 release： ```console $ helm uninstall happy-panda ``` 该命令将从集群中移除指定 release。你可以通过 `helm list` 命令看到当前部署的所有 release： ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` 从上面的输出中，我们可以看到，`happy-panda` 这个 release 已经被卸载。 在上一个 Helm 版本中，当一个 release 被删除，会保留一条删除记录。而在 Helm 3 中，删除也会移除 release 的记录。 如果你想保留删除记录，使用 `helm uninstall --keep-history`。使用 `helm list --uninstalled` 只会展示使用了 `--keep-history` 删除的 release。 `helm list --all` 会展示 Helm 保留的所有 release 记录，包括失败或删除的条目（指定了 `--keep-history`）： ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` 注意，因为现在默认会删除 release，所以你不再能够回滚一个已经被卸载的资源了。 ## 'helm repo'：使用仓库 Helm 3 不再附带一个默认的 chart 仓库。`helm repo` 提供了一组命令用于添加、列出和移除仓库。 使用 `helm repo list` 来查看配置的仓库： ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` 使用 `helm repo add` 来添加新的仓库： ```console $ helm repo add dev https://example.com/dev-charts ``` 因为 chart 仓库经常在变化，在任何时候你都可以通过执行 `helm repo update` 命令来确保你的 Helm 客户端是最新的。 使用 `helm repo remove` 命令来移除仓库。 ## 创建你自己的 charts [chart 开发指南](/topics/charts.md)介绍了如何开发你自己的 chart。但是你也可以通过使用 `helm create` 命令来快速开始： ```console $ helm create deis-workflow Creating deis-workflow ``` 现在，`./deis-workflow` 目录下已经有一个 chart 了。你可以编辑它并创建你自己的模版。 在编辑 chart 时，可以通过 `helm lint` 验证格式是否正确。 当准备将 chart 打包分发时，你可以运行 `helm package` 命令： ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` 然后这个 chart 就可以很轻松的通过 `helm install` 命令安装： ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` 打包好的 chart 可以上传到 chart 仓库中。查看 [Helm chart 仓库](/topics/chart_repository.md)获取更多信息。 ## 总结 这一章介绍了 `helm` 客户端的基本使用方式，包括搜索，安装，升级，和卸载。也涵盖了一些有用的工具类命令，如`helm status`， `helm get`，和 `helm repo`。 有关这些命令的更多信息，请查看 Helm 的内置帮助命令：`helm help`。 在[下一章](/howto/charts_tips_and_tricks.md)中，我们来看一下如何开发 charts。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_install.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunOption = "none" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) chart, err := loader.Load(chartPath) if err != nil { return err } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil { if err := action.CheckDependencies(chart, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := installClient.RunWithContext(ctx, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created:\n%+v", *release) return nil } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_list.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_main.mdx ================================================ ```go package main import ( "bufio" "context" "fmt" "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver, logger.Printf); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, err } return registryClient, nil } func newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) { if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSverify { registryClient, err := registry.NewRegistryClientWithTLS( logger.Writer(), certFile, keyFile, caFile, insecureSkipTLSverify, settings.RegistryConfig, settings.Debug) if err != nil { return nil, err } return registryClient, nil } registryClient, err := newRegistryClient(settings, plainHTTP) if err != nil { return nil, err } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_pull.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } registryClient, err := newRegistryClient(settings, false) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient pullClient := action.NewPullWithOpts( action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_uninstall.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", *result.Release) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/_upgrade.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunOption = "none" upgradeClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts chart, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } if req := chart.Metadata.Dependencies; req != nil { if err := action.CheckDependencies(chart, req); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/examples.mdx ================================================ --- title: 示例 description: 演示 Helm SDK 的各项功能 sidebar_position: 2 --- import Install from './_install.mdx' import List from './_list.mdx' import Main from './_main.mdx' import Pull from './_pull.mdx' import Uninstall from './_uninstall.mdx' import Upgrade from './_upgrade.mdx' 本文档通过一系列示例来演示 Helm SDK 的使用方法，旨在展示各种 SDK 功能。 最后一个示例展示了 `main.go` 驱动程序（详见[驱动示例](#driver)），该程序会执行下述操作，并包含所需的辅助函数。 所有示例代码均位于 [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) 目录下，并且可以完整运行。 ## 操作 {#actions} ### 安装操作 {#install-action} 此示例演示如何安装指定的 chart/release，支持指定版本和自定义 values： ### 升级操作 {#upgrade-action} 此示例演示如何使用指定的 chart、版本和 values 升级已有的 release： ### 卸载操作 {#uninstall-action} 此示例演示如何卸载指定的 release： ### 列表操作 {#list-action} 此示例会列出当前配置命名空间下的所有已发布 chart： ### 拉取操作 {#pull-action} 此示例演示如何从 OCI 仓库拉取一个 chart： ## 驱动程序 {#driver} 此处的驱动示例展示了 Helm SDK 各项操作所需的辅助函数，并演示了如何实际使用上述示例，从 OCI 仓库拉取、安装、升级和卸载 `podinfo` chart。
================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/gosdk.md ================================================ --- title: 介绍 description: 介绍 Helm Go SDK sidebar_position: 1 --- Helm 的 Go SDK 使自定义软件能够利用 Helm chart 和 Helm 的功能来管理 Kubernetes 软件部署（事实上，Helm CLI 本质上就是这样一个工具！）。 目前，SDK 已在功能上与 Helm CLI 分离。SDK 可以（并且正在）被独立工具使用。Helm 项目已承诺为 SDK 提供 API 稳定性。值得注意的是，SDK 在将 CLI 和 SDK 分离的初始工作中仍有一些未完善之处，Helm 项目旨在随着时间的推移逐步改进。 完整的 API 文档可以在 [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3) 找到。 下面简要概述一些主要的包，并提供一个简单示例。更多示例和更完整的示例程序，请参阅[示例](/sdk/examples.mdx)部分。 ## 主要包概览 - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action)：包含执行 Helm 操作的主要"客户端"。这与 CLI 在底层使用的包相同。如果只需要从其他 Go 程序执行基本的 Helm 命令，可以使用这个包。 - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart)、[pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil)：用于加载和操作 chart 的方法和辅助函数。 - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) 及其子包：包含标准 Helm 环境变量的所有处理程序，其子包包含输出和 values 文件处理。 - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release)：定义 `Release` 对象和状态。 除了这些之外还有很多包，请查看文档以获取更多信息！ ### 简单示例 这是使用 Go SDK 执行 `helm list` 的简单示例。更完整的示例请参阅[示例](/sdk/examples.mdx)部分。 ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // 可以传递空字符串代替 settings.Namespace() 来列出所有命名空间 if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // 仅列出已部署的 client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## 兼容性 Helm SDK 明确遵循 Helm 向后兼容性保证： 也就是说，破坏性更改只会在主要版本中进行。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/advanced.md ================================================ --- title: Helm 高级技术 description: 为 Helm 高级用户说明各种高级特性 sidebar_position: 9 --- 本节介绍使用 Helm 的各种高级特性和技术。这些内容主要面向希望对 chart 和 release 进行高度自定义和操作的 Helm 高级用户。每个高级特性都有各自的权衡利弊，因此使用时需要具备深厚的 Helm 知识并谨慎操作。换言之，请谨记 [Peter Parker 原则](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)。 ## 后置渲染 {#post-rendering} 后置渲染允许 chart 安装者在 Helm 安装渲染后的 manifest 之前，手动操作、配置或验证这些 manifest。这使得有高级配置需求的用户可以使用 [`kustomize`](https://kustomize.io) 等工具来应用配置更改，而无需 fork 公共 chart 或要求 chart 维护者为软件指定所有配置选项。此外，还有一些场景用于在企业环境中注入常用工具和 sidecar，或在部署前对 manifest 进行分析。 ### 前提条件 - Helm 3.1+ ### 使用 后置渲染器可以是任意可执行文件，只要能在 STDIN 接收渲染后的 Kubernetes manifest 并在 STDOUT 返回有效的 Kubernetes manifest 即可。遇到失败时应返回非零退出码。这是两个组件之间唯一的"API"，为后置渲染过程提供了极大的灵活性。 后置渲染器可以与 `install`、`upgrade` 和 `template` 命令一起使用。使用后置渲染器时，通过 `--post-renderer` 参数指定渲染器可执行文件的路径： ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` 如果路径中不包含任何分隔符，会在 $PATH 中搜索；否则会将相对路径解析为完整路径。 如果需要使用多个后置渲染器，可以在脚本中调用它们，或者在构建的二进制工具中组合调用。在 bash 中，只需像 `renderer1 | renderer2 | renderer3` 这样简单地串联即可。 可以在[这里](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)查看使用 `kustomize` 作为后置渲染器的示例。 ### 注意事项 使用后置渲染器时，有几点需要注意。最重要的是，当使用后置渲染器时，所有修改该 release 的人**必须**使用相同的渲染器，以确保构建的可重复性。此功能允许用户切换或停止使用渲染器，但应谨慎操作，以避免意外修改或数据丢失。 另一个重要注意事项是安全性。如果你使用后置渲染器，应确保它来自可信来源（任何可执行文件都应如此）。不建议使用不受信任或未经验证的渲染器，因为它们可以完全访问渲染后的模板，而这些模板通常包含敏感数据。 ### 自定义后置渲染器 在 Go SDK 中使用时，后置渲染器可以提供更大的灵活性。任何后置渲染器只需实现以下 Go 接口： ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` 有关 Go SDK 的更多信息，请参阅 [Go SDK 部分](#go-sdk)。 ## Go SDK Helm 3 引入了全新重构的 Go SDK，为构建基于 Helm 的软件和工具提供更好的体验。完整文档可在 [Go SDK 部分](/zh/docs/sdk/gosdk/)查看。 ## 后端存储 {#storage-backends} Helm 3 将默认的 release 信息存储方式更改为存储在 release 所在命名空间中的 Secret。Helm 2 默认将 release 信息作为 ConfigMap 存储在 Tiller 实例所在的命名空间中。以下小节介绍如何配置不同的存储后端。配置基于 `HELM_DRIVER` 环境变量，可设置为以下值之一：`[configmap, secret, sql]`。 ### ConfigMap 后端存储 要启用 ConfigMap 后端，需要将环境变量 `HELM_DRIVER` 设置为 `configmap`。 可以在 shell 中如下设置： ```shell export HELM_DRIVER=configmap ``` 如果要从默认后端切换到 ConfigMap 后端，需要自行进行迁移。可以使用以下命令获取 release 信息： ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **生产环境说明**：release 信息包含 chart 和 values 文件的内容，因此可能包含需要防止未授权访问的敏感数据（如密码、私钥和其他凭证）。在管理 Kubernetes 授权时（例如使用 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)），可能会授予 ConfigMap 资源较宽泛的访问权限，同时限制对 Secret 资源的访问。例如，默认的[面向用户的角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)"view"授予大多数资源的访问权限，但不包括 Secret。此外，Secret 数据可以配置为[加密存储](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)。如果决定切换到 ConfigMap 后端，请注意这一点，因为它可能会暴露应用程序的敏感数据。 ### SQL 后端存储 这是一个 ***beta*** 版本的 SQL 存储后端，将 release 信息存储在 SQL 数据库中。 如果 release 信息超过 1MB，这种存储后端会特别有用（此时由于 Kubernetes 底层 etcd 键值存储的内部限制，无法存储在 ConfigMap/Secret 中）。 要启用 SQL 后端，需要部署 SQL 数据库并将环境变量 `HELM_DRIVER` 设置为 `sql`。数据库详细信息通过环境变量 `HELM_DRIVER_SQL_CONNECTION_STRING` 设置。 可以在 shell 中如下设置： ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > 注意：目前仅支持 PostgreSQL。 **生产环境说明**：建议： - 确保数据库可用于生产环境。对于 PostgreSQL，请参阅 [Server Administration](https://www.postgresql.org/docs/12/admin.html) 文档了解更多详情 - 启用[权限管理](/zh/docs/topics/permissions_sql_storage_backend/)，以镜像 Kubernetes RBAC 来控制 release 信息的访问权限 如果要从默认后端切换到 SQL 后端，需要自行进行迁移。可以使用以下命令获取 release 信息： ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/architecture.md ================================================ --- title: Helm 架构 description: 从较高层面描述 Helm 架构。 sidebar_position: 8 --- # Helm 架构 本文从较高层面描述 Helm 的架构。 ## Helm 的用途 Helm 是一个管理 Kubernetes 包的工具，这种包称为 _chart_。Helm 可以完成以下任务： - 从头创建新的 chart - 将 chart 打包成归档文件（tgz） - 与存储 chart 的仓库进行交互 - 在现有的 Kubernetes 集群中安装和卸载 chart - 管理使用 Helm 安装的 chart 的 release 周期 Helm 有三个重要概念： 1. _chart_ 是创建 Kubernetes 应用实例所需的一组信息。 2. _config_ 包含配置信息，可以合并到已打包的 chart 中，用于创建可发布的对象。 3. _release_ 是 _chart_ 与特定 _config_ 结合后的运行实例。 ## 组件 Helm 是一个可执行程序，由两个不同的部分组成： **Helm 客户端** 是面向终端用户的命令行客户端，负责以下工作： - 本地 chart 开发 - 管理仓库 - 管理 release - 与 Helm 库交互 - 发送要安装的 chart - 发送升级或卸载现有 release 的请求 **Helm 库** 提供执行所有 Helm 操作的逻辑。它与 Kubernetes API 服务器交互，并提供以下功能： - 将 chart 和配置结合以构建 release - 将 chart 安装到 Kubernetes 中，并提供相应的 release 对象 - 通过与 Kubernetes 交互来升级和卸载 chart 独立的 Helm 库封装了 Helm 逻辑，以便不同的客户端可以使用它。 ## 实现 Helm 客户端和库使用 Go 编程语言编写。 该库使用 Kubernetes 客户端库与 Kubernetes 通信。目前，该库使用 REST+JSON。它将信息存储在 Kubernetes 的 Secret 中，不需要自己的数据库。 配置文件尽可能使用 YAML 编写。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/chart_repository.md ================================================ --- title: Chart 仓库指南 description: 如何创建和使用 Helm chart 仓库。 sidebar_position: 6 --- 本节介绍如何创建和使用 Helm chart 仓库。从较高层面来说，chart 仓库是用来存储和共享打包好的 chart 的位置。 社区的 Helm chart 仓库位于 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)，欢迎参与贡献。不过 Helm 也支持创建和运行你自己的 chart 仓库。本指南将介绍如何操作。如果你正在考虑创建 chart 仓库，也可以考虑使用 [OCI 注册中心](/zh/docs/topics/registries/)作为替代方案。 ## 先决条件 * 阅读[快速开始](/zh/docs/intro/quickstart/)指南 * 阅读 [Charts](/zh/docs/topics/charts/) 文档 ## 创建 chart 仓库 _chart 仓库_ 是一个配置了 `index.yaml` 文件和一些已打包 chart 的 HTTP 服务器。当你准备好分享 chart 时，最好的方式是将 chart 上传到 chart 仓库。 从 Helm 2.2.0 开始，客户端支持对仓库进行 SSL 身份认证。其他身份验证协议可以通过插件提供。 由于 chart 仓库可以是任何能够提供 YAML 和 tar 文件并响应 GET 请求的 HTTP 服务器，托管你自己的 chart 仓库时有很多选择。比如可以使用 Google Cloud Storage (GCS) bucket、Amazon S3 bucket、GitHub Pages，甚至创建你自己的 web 服务器。 ### chart 仓库结构 chart 仓库由 chart 包和一个名为 `index.yaml` 的特殊文件组成，该文件包含了仓库中所有 chart 的索引。通常 `index.yaml` 所描述的 chart 也托管在同一服务器上，[来源文件](/zh/docs/topics/provenance/)也是如此。 例如，仓库 `https://example.com/charts` 的布局可能是这样的： ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` 在这个例子中，index 文件包含了 Alpine 这一个 chart 的信息，并提供了下载地址 `https://example.com/charts/alpine-0.1.2.tgz`。 chart 包不一定要与 `index.yaml` 文件放在同一服务器上，但这样做通常是最简单的。 ### index 文件 index 文件是一个名为 `index.yaml` 的 YAML 文件。它包含了 chart 包的一些元信息，包括 chart 的 `Chart.yaml` 文件内容。一个有效的 chart 仓库必须有 index 文件。index 文件包含了 chart 仓库中每个 chart 的信息。`helm repo index` 命令会基于给定的包含 chart 包的本地目录生成 index 文件。 以下是一个 index 文件示例： ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## 托管 chart 仓库 本部分介绍几种提供 chart 仓库服务的方法。 ### Google Cloud Storage 第一步是**创建你的 GCS bucket**。我们将其命名为 `fantastic-charts`。 ![Create a GCS Bucket](/img/helm2/create-a-bucket.png) 然后通过**编辑 bucket 权限**将其设为公开。 ![Edit Permissions](/img/helm2/edit-permissions.png) 插入以下条目**将 bucket 设为公开**： ![Make Bucket Public](/img/helm2/make-bucket-public.png) 恭喜，现在你有了一个可以提供 chart 服务的空 GCS bucket！ 你可以使用 Google Cloud Storage 命令行工具或 GCS web 界面上传 chart 仓库。公开的 GCS bucket 可以通过简单的 HTTPS 地址访问：`https://bucket-name.storage.googleapis.com/`。 ### Cloudsmith 你也可以使用 Cloudsmith 设置 chart 仓库。在[这里](https://help.cloudsmith.io/docs/helm-chart-repository)了解更多关于 Cloudsmith 配置 chart 仓库的信息。 ### JFrog Artifactory 同样，你也可以使用 JFrog Artifactory 设置 chart 仓库。在[这里](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories)了解更多关于 JFrog Artifactory 配置 chart 仓库的信息。 ### GitHub Pages 示例 你可以用类似的方式使用 GitHub Pages 创建 chart 仓库。 GitHub 允许你通过两种方式提供静态网页： - 配置项目以提供 `docs/` 目录的内容 - 配置项目以提供特定分支的内容 我们将采用第二种方式，不过第一种方式也很简单。 第一步是**创建 gh-pages 分支**。你可以在本地创建： ```console $ git checkout -b gh-pages ``` 或者在 GitHub 仓库中通过 web 界面使用 **Branch** 按钮： ![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png) 然后，确保将 **gh-pages branch** 设置为 GitHub Pages。点击仓库的 **Settings**，向下滚动到 **GitHub pages** 部分，按如下设置： ![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png) 默认情况下，**Source** 通常设置为 **gh-pages branch**。如果没有默认设置，请手动选择。 如果需要，你可以在这里使用**自定义域名**。 然后确保勾选了 **Enforce HTTPS**，这样提供 chart 时会使用 **HTTPS**。 在这种配置下，你可以使用默认分支存储 chart 代码，并使用 **gh-pages branch** 作为 chart 仓库，例如：`https://USERNAME.github.io/REPONAME`。演示仓库 [TS Charts](https://github.com/technosophos/tscharts) 可以通过 `https://technosophos.github.io/tscharts/` 访问。 如果你想使用 GitHub Pages 托管 chart 仓库，请查看 [Chart Releaser Action](/zh/docs/howto/chart_releaser_action/)。Chart Releaser Action 是一个 GitHub Action 工作流，可以使用 [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI 工具将 GitHub 项目转换为自托管的 Helm chart 仓库。 ### 普通 web 服务器 配置普通 web 服务器来提供 Helm chart，你只需要执行以下操作： - 将 index 文件和 chart 放在服务器可以提供服务的目录中 - 确保 `index.yaml` 文件可以无需认证即可访问 - 确保 `yaml` 文件以正确的内容类型提供（`text/yaml` 或 `text/x-yaml`） 例如，如果你想在 `$WEBROOT/charts` 提供 chart，确保 web 根目录下有一个 `charts/` 目录，并将 index 文件和 chart 放在该目录中。 ### ChartMuseum 仓库服务器 ChartMuseum 是一个用 Go (Golang) 编写的开源 Helm chart 仓库服务器，支持多种云存储后端，包括 [Google Cloud Storage](https://cloud.google.com/storage/)、[Amazon S3](https://aws.amazon.com/s3/)、[Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)、[Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss)、[Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/)、[Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage)、[Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html)、[Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos)、[DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/)、[Minio](https://min.io/) 以及 [etcd](https://etcd.io/)。 你也可以使用 [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) 服务器从本地文件系统托管 chart 仓库。 ### GitLab Package Registry 使用 GitLab 可以在项目的 Package Registry 中发布 Helm chart。在[这里](https://docs.gitlab.com/ee/user/packages/helm_repository/)了解更多关于使用 GitLab 设置 Helm 包仓库的信息。 ## 管理 chart 仓库 现在你有了 chart 仓库，本指南的最后一部分将介绍如何在仓库中维护 chart。 ### 在 chart 仓库中存储 chart 现在你有了 chart 仓库，让我们上传 chart 和 index 文件到仓库。chart 仓库中的 chart 必须打包（`helm package chart-name/`）且遵循正确的版本号规范（参照 [SemVer 2](https://semver.org/) 指南）。 以下步骤构成一个示例工作流，但你可以使用任何你喜欢的工作流来存储和更新 chart 仓库中的 chart。 准备好打包的 chart 后，创建一个新目录，然后将打包的 chart 移动到该目录中。 ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` 最后一条命令获取刚创建的本地目录路径和远程 chart 仓库的 URL，并在给定的目录路径中生成 `index.yaml` 文件。 现在你可以使用同步工具或手动方式将 chart 和 index 文件上传到 chart 仓库。如果使用 Google Cloud Storage，可以使用 gsutil 客户端查看[示例工作流](/zh/docs/howto/chart_repository_sync_example/)。对于 GitHub，你可以简单地将 chart 放在合适的目标分支中。 ### 向现有仓库添加新 chart 每次你想向仓库添加新 chart 时，必须重新生成 index。`helm repo index` 命令会从头完全重建 `index.yaml` 文件，只包含它在本地找到的 chart。 不过，你可以使用 `--merge` 参数增量添加新 chart 到现有的 `index.yaml` 文件中（在使用类似 GCS 的远程仓库时很有用）。运行 `helm repo index --help` 了解更多信息。 确保修订后的 `index.yaml` 文件和 chart 都已上传。如果生成了来源文件，也要一并上传。 ### 与他人分享你的 chart 当你准备好分享 chart 时，只需告诉别人你的仓库 URL 即可。 用户可以通过 `helm repo add [NAME] [URL]` 命令将仓库添加到他们的 Helm 客户端，并使用任何他们想要的名称来引用该仓库。 ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` 如果 chart 使用 HTTP 基本认证，你也可以在这里提供用户名和密码： ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **注意：** 如果仓库不包含有效的 `index.yaml`，则无法添加。 **注意：** 如果你的 Helm 仓库使用了自签名证书，你可以使用 `helm repo add --insecure-skip-tls-verify ...` 来跳过 CA 验证。 之后，你的用户就可以搜索你的 chart 了。更新仓库后，他们可以使用 `helm repo update` 命令获取最新的 chart 信息。 *在底层，`helm repo add` 和 `helm repo update` 命令会获取 index.yaml 文件并将其存储在 `$XDG_CACHE_HOME/helm/repository/cache/` 目录中。这是 `helm search` 功能查找 chart 信息的位置。* ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/chart_tests.md ================================================ --- title: Chart Tests description: 描述如何运行和测试你的 chart。 sidebar_position: 3 --- chart 包含了多个协同工作的 Kubernetes 资源和组件。作为 chart 作者，你可能想编写一些测试来验证 chart 在安装时是否按预期工作。这些测试也可以帮助 chart 用户了解你的 chart 预期的功能。 Helm chart 中的**测试**位于 `templates/` 目录下，是一个 Job 定义，指定了一个要运行给定命令的容器。容器应该成功退出（exit 0）才算测试通过。Job 定义必须包含 Helm 测试钩子注解：`helm.sh/hook: test`。 注意在 Helm v3 之前，Job 定义需要包含以下 Helm 测试钩子注解之一：`helm.sh/hook: test-success` 或 `helm.sh/hook: test-failure`。`helm.sh/hook: test-success` 仍然作为 `helm.sh/hook: test` 的向后兼容替代方案被接受。 测试示例： - 验证 values.yaml 文件中的配置是否被正确注入。 - 确保用户名和密码正确工作 - 确保错误的用户名和密码无法工作 - 验证服务已启动且负载均衡正常 - 等等。 你可以使用 `helm test ` 命令对一个 release 运行 Helm 中预定义的测试。对于 chart 用户来说，这是检验他们的 chart release（或应用程序）是否按预期工作的好方法。 ## 测试示例 [helm create](/zh/docs/helm/helm_create/) 命令会自动创建一些目录和文件。要尝试 Helm 测试功能，首先创建一个示例 Helm chart。 ```console $ helm create demo ``` 你现在可以在 demo Helm chart 中看到以下结构。 ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` 在 `demo/templates/tests/test-connection.yaml` 中，你会看到一个可以尝试的测试。可以在这里查看 Helm 测试 Pod 定义： ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## 对 Release 运行测试套件 首先，将 chart 安装到集群中以创建一个 release。你可能需要等待所有 Pod 变为 active 状态；如果在安装后立即测试，可能会出现暂时性失败，届时你需要重新测试。 ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## 注意事项 - 可以在单个 yaml 文件中定义多个测试，也可以将测试分布在 `templates/` 目录下的多个 yaml 文件中。 - 可以将测试套件嵌套放在 `tests/` 目录中（如 `/templates/tests/`）以获得更好的隔离。 - 测试是一种 [Helm 钩子](/zh/docs/topics/charts_hooks/)，因此 `helm.sh/hook-weight` 和 `helm.sh/hook-delete-policy` 等注解也可以用于测试资源。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/charts.md ================================================ --- title: Chart description: 阐述chart格式，并提供使用Helm构建chart的基本指导。 sidebar_position: 1 --- Helm使用的包格式称为 _chart_。 chart就是一个描述Kubernetes相关资源的文件集合。单个chart可以用来部署一些简单的， 类似于memcache pod，或者某些复杂的HTTP服务器以及web全栈应用、数据库、缓存等等。 Chart是作为特定目录布局的文件被创建的。它们可以打包到要部署的版本存档中。 如果你想下载和查看一个发布的chart，但不安装它，你可以用这个命令： `helm pull chartrepo/chartname`。 该文档解释说明了chart格式，并提供了用Helm构建chart的基本指导。 ## Chart 文件结构 chart是一个组织在文件目录中的集合。目录名称就是chart名称（没有版本信息）。因而描述WordPress的chart可以存储在`wordpress/`目录中。 在这个目录中，Helm 期望可以匹配以下结构： ```text wordpress/ Chart.yaml # 包含了chart信息的YAML文件 LICENSE # 可选: 包含chart许可证的纯文本文件 README.md # 可选: 可读的README文件 values.yaml # chart 默认的配置值 values.schema.json # 可选: 一个使用JSON结构的values.yaml文件 charts/ # 包含chart依赖的其他chart crds/ # 自定义资源的定义 templates/ # 模板目录， 当和values 结合时，可生成有效的Kubernetes manifest文件 templates/NOTES.txt # 可选: 包含简要使用说明的纯文本文件 ``` Helm保留使用 `charts/`，`crds/`， `templates/`目录，以及列举出的文件名。其他文件保持原样。 ## Chart.yaml 文件 `Chart.yaml`文件是chart必需的。包含了以下字段： ```yaml apiVersion: chart API 版本 （必需） name: chart名称 （必需） version: 语义化2 版本（必需） kubeVersion: 兼容Kubernetes版本的语义化版本（可选） description: 一句话对这个项目的描述（可选） type: chart类型 （可选） keywords: - 关于项目的一组关键字（可选） home: 项目home页面的URL （可选） sources: - 项目源码的URL列表（可选） dependencies: # chart 必要条件列表 （可选） - name: chart名称 (nginx) version: chart版本 ("1.2.3") repository: （可选）仓库URL ("https://example.com/charts") 或别名 ("@repo-name") condition: （可选） 解析为布尔值的yaml路径，用于启用/禁用chart (e.g. subchart1.enabled ) tags: # （可选） - 用于一次启用/禁用 一组chart的tag import-values: # （可选） - ImportValue 保存源值到导入父键的映射。每项可以是字符串或者一对子/父列表项 alias: （可选） chart中使用的别名。当你要多次添加相同的chart时会很有用 maintainers: # （可选） - name: 维护者名字 （每个维护者都需要） email: 维护者邮箱 （每个维护者可选） url: 维护者URL （每个维护者可选） icon: 用做icon的SVG或PNG图片URL （可选） appVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号 deprecated: 不被推荐的chart （可选，布尔值） annotations: example: 按名称输入的批注列表 （可选）. ``` 从[v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2)，不再允许额外的字段。推荐的方法是在 `annotations` 中添加自定义元数据。 ### Chart和版本控制 每个chart都必须有个版本号。版本必须遵循 [语义化版本 2](https://semver.org/spec/v2.0.0.html) 标准。 不像经典Helm， Helm v2以及后续版本会使用版本号作为发布标记。仓库中的包通过名称加版本号标识。 比如 `nginx` chart的版本字段`version: 1.2.3`按照名称被设置为： ```text nginx-1.2.3.tgz ``` 更多复杂的语义化版本 2 名称也是支持的，比如 `version: 1.2.3-alpha.1+ef365`。但系统明确禁止非语义化版本名称。例外情况是格式为 `x` 或 `x.y` 的版本。例如，如果版本号带有前导 v 或者没有完整的三部分（如 v1.2），系统会尝试将其转换为有效的语义化版本（如 v1.2.0）。 **注意：** 鉴于经典Helm和部署管理器在使用chart时都非常倾向于GitHub，Helm v2 和后续版本不再依赖或需要GitHub甚至是Git。 因此，它完全不使用Git SHA进行版本控制。 `Chart.yaml`文件中的`version`字段被很多Helm工具使用，包括CLI。当生成一个包时， `helm package`命令可以用`Chart.yaml`文件中找到的版本号作为包名中的token。 系统假设chart包名中的版本号可以与`Chart.yaml`文件中的版本号匹配。如果不满足这一假设会导致错误。 ### `apiVersion` 字段 对于至少需要Helm 3的chart，`apiVersion` 字段应该是 `v2`。Chart支持之前`apiVersion` 设置为 `v1` 的Helm 版本， 并且在Helm 3中仍然可安装。 `v1` 到 `v2`的改变： - `dependencies`字段定义了chart的依赖，针对于`v1` 版本的chart被放置在分隔开的`requirements.yaml` 文件中 （查看 [Chart 依赖](#chart-dependency)). - `type`字段, 用于识别应用和库类型的chart（查看 [Chart 类型](#chart-types)). ### `appVersion` 字段 注意这个`appVersion`字段与`version`字段并不相关。这是指定应用版本的一种方式。比如，这个`drupal` chart可能有一个 `appVersion: "8.2.1"`，表示包含在chart（默认）的Drupal的版本是`8.2.1`。此字段仅供参考，对chart版本计算没有影响。 强烈建议使用引号将版本括起来。它强制YAML解析器将版本号视为字符串。不加引号在某些场景会出现解析问题。 比如，YAML将`1.0`解释为浮点值，且git提交的SHA类似`1234e10`是科学计数法。 从Helm v3.5.0开始，`helm create`会将默认的`appVersion`用引号括起来。 ### `kubeVersion` 字段 可选的 `kubeVersion` 字段可以在支持的Kubernetes版本上定义语义化版本约束，Helm 在安装chart时会验证这个版本约束， 并在集群运行不支持的Kubernetes版本时显示失败。 版本约束可以包括空格分隔和比较运算符，比如： ```yaml >= 1.13.0 < 1.15.0 ``` 或者它们可以用或操作符 `||` 连接，比如： ```yaml >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` 这个例子中排除了 `1.14.0` 版本，如果确定某些版本中的错误导致chart无法正常运行，这一点就很有意义。 除了版本约束外，使用运算符 `=` `!=` `>` `<` `>=` `<=` 支持一下速记符号： - 闭合间隔的连字符范围， `1.1 - 2.3.4` 等价于 `>= 1.1 <= 2.3.4` - 通配符 `x`， `X` 和 `*`， `1.2.x` 等价于 `>= 1.2.0 < 1.3.0` - 波浪符号~范围 （允许改变补丁版本）， `~1.2.3` 等价于 `>= 1.2.3 < 1.3.0` - 插入符号^范围 （允许改变次版本）， `^1.2.3` 等价于 `>= 1.2.3 < 2.0.0` 支持的语义化版本约束的细节说明请查看 [Masterminds/semver](https://github.com/Masterminds/semver) ### 已弃用的Chart 在Chart仓库管理chart时，有时需要废弃一个chart。 `Chart.yaml` 中可选的`deprecated`字段可以用来标记已弃用的chart。 如果**latest**版本被标记为已弃用，则所有的chart都会被认为是已弃用的。以后可以通过发布未标记为已弃用的新版本来重新使用chart名称。 弃用chart的工作流是： 1. 升级chart的 `Chart.yaml` 文件，将这个chart标记为已弃用， 并更改版本 2. 在chart仓库中发布新版的chart 3. 从源仓库中移除这个chart （比如用 git） ### Chart Types `type`字段定义了chart的类型。有两种类型： `application` 和 `library`。 应用是默认类型，是可以完全操作的标准chart。 [库类型 chart](http://helm.sh/zh/docs/topics/library_charts) 提供针对chart构建的实用程序和功能。 库类型chart与应用类型chart不同，因为它不能安装，通常不包含任何资源对象。 **注意：** 应用类型chart 可以作为库类型chart使用。可以通过将类型设置为 `library`来实现。 然后这个库就被渲染成了一个库类型chart，所有的实用程序和功能都可以使用。所有的资源对象不会被渲染。 ## Chart 许可证，自述和注释 Chart也可以包含描述安装，配置和使用文件，以及chart许可证。 许可证（LICENSE）是一个包含了chart [license](https://en.wikipedia.org/wiki/Software_license)的纯文本文件。 chart可以包含一个许可证，因为在模板里不只是配置，还可能有编码逻辑。如果需要，还可以为chart安装的应用程序提供单独的许可证。 chart的自述文件README文件应该使用Markdown格式(README.md)，一般应包含： - chart提供的应用或服务的描述 - 运行chart的先决条件或要求 - `values.yaml`的可选项和默认值的描述 - 与chart的安装或配置相关的其他任何信息 `README.md` 文件会包含hub和用户接口显示的chart的详细信息。 chart也会包含一个简短的纯文本 `templates/NOTES.txt` 文件，这会在安装后及查看版本状态时打印出来。 这个文件会作为一个 [模板](#templates-and-values)来评估，并用来显示使用说明，后续步骤，或者其他chart版本的相关信息。 比如，可以提供连接数据库的说明，web UI的访问。由于此文件是在运行`helm install`或`helm status`时打印到STDOUT的， 因此建议保持内容简短，并指向自述文件以获取更多详细信息。 ## Chart dependency Helm 中，chart可能会依赖其他任意个chart。 这些依赖可以使用`Chart.yaml`文件中的`dependencies` 字段动态链接，或者被带入到`charts/` 目录并手动配置。 ### 使用 `dependencies` 字段管理依赖 当前chart依赖的其他chart会在`dependencies`字段定义为一个列表。 ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - `name`字段是你需要的chart的名称 - `version`字段是你需要的chart的版本 - `repository`字段是chart仓库的完整URL。注意你必须使用`helm repo add`在本地添加仓库 - 你可以使用仓库的名称代替URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` 一旦你定义好了依赖，运行 `helm dependency update` 就会使用你的依赖文件下载所有你指定的chart到你的`charts/`目录。 ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` 当 `helm dependency update` 拉取chart时，会在`charts/`目录中形成一个chart包。因此对于上面的示例，会在chart目录中期望看到以下文件： ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### 依赖的别名字段 除了上面的其他字段之外，每个需求项可以包含一个可选的字段 `alias`。 为依赖chart添加一个别名，会使用别名作为新依赖chart的名称。 需要使用其他名称访问chart时可以使用`alias`。 ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` 上述例子中，我们会获得`parentchart`所有的3个依赖项： ```text subchart new-subchart-1 new-subchart-2 ``` 手动完成的方式是将同一个chart用不同的名称复制/粘贴多次到`charts/`目录中。 #### 依赖中的tag和条件字段 除了上面的其他字段外，每个需求项可以包含可选字段 `tags` 和 `condition`。 所有的chart会默认加载。如果存在 `tags` 或者 `condition` 字段，它们将被评估并用于控制它们应用的chart的加载。 Condition - 条件字段field 包含一个或多个YAML路径（用逗号分隔）。 如果这个路径在上层values中已存在并解析为布尔值，chart会基于布尔值启用或禁用chart。 只会使用列表中找到的第一个有效路径，如果路径为未找到则条件无效。 Tags - tag字段是与chart关联的YAML格式的标签列表。在顶层value中，通过指定tag和布尔值，可以启用或禁用所有的带tag的chart。 ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` 在上面的例子中，所有带 `front-end`tag的chart都会被禁用，但只要上层的value中 `subchart1.enabled` 路径被设置为 'true'，该条件会覆盖 `front-end`标签且 `subchart1` 会被启用。 一旦 `subchart2`使用了`back-end`标签并被设置为了 `true`，`subchart2`就会被启用。 也要注意尽管`subchart2` 指定了一个条件字段， 但是上层value没有相应的路径和value，因此这个条件不会生效。 ##### 使用带有标签和条件的CLI `--set` 参数一如既往可以用来设置标签和条件值。 ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### 标签和条件的解析 - **条件 （当设置在value中时）总是会覆盖标签** 第一个chart条件路径存在时会忽略后面的路径。 - 标签被定义为 '如果任意的chart标签是true，chart就可以启用'。 - 标签和条件值必须被设置在顶层value中。 - value中的`tags:`键必须是顶层键。 全局和嵌套的`tags:`表现在不支持了。 #### 通过依赖导入子Value 在某些情况下，允许子chart的值作为公共默认传递到父chart中是值得的。使用 `exports`格式的额外好处是它可是将来的工具可以自检用户可设置的值。 被导入的包含值的key可以在父chart的 `dependencies` 中的 `import-values` 字段以YAML列表形式指定。 列表中的每一项是从子chart中`exports`字段导入的key。 导入`exports` key中未包含的值，使用[子-父](#using-the-child-parent-format)格式。两种格式的示例如下所述。 ##### 使用导出格式 如果子chart的`values.yaml`文件中在根节点包含了`exports`字段，它的内容可以通过指定的可以被直接导入到父chart的value中， 如下所示： ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` 只要我们再导入列表中指定了键`data`，Helm就会在子chart的`exports`字段查找`data`键并导入它的内容。 最终的父级value会包含我们的导出字段： ```yaml # parent's values myint: 99 ``` 注意父级键 `data` 没有包含在父级最终的value中，如果想指定这个父级键，要使用'子-父' 格式。 ##### 使用子-父格式 {#using-the-child-parent-format} 要访问子 chart 中未包含的 `exports` 键的值，你需要指定要导入的值的源键（`child`）和父 chart 中值的目标路径（`parent`）。 下面示例中的`import-values` 指示Helm去拿到能在`child:`路径中找到的任何值，并拷贝到`parent:`的指定路径。 ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` 上面的例子中，在subchart1里面找到的`default.data`的值会被导入到父chart的`myimports`键中，细节如下： ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` 父chart的结果值将会是这样： ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` 父chart中的最终值包含了从 subchart1中导入的`myint`和`mybool`字段。 ### 通过`charts/`目录手动管理依赖 如果对依赖进行更多控制，通过将有依赖关系的chart复制到`charts/`目录中来显式表达这些依赖关系。 依赖应该是一个解压的chart目录。但是名字不能以`_`或`.`开头，否则会被chart加载器忽略。 比如，如果WordPress chart依赖于Apache chart，那么（正确版本的）Apache chart需要放在WordPress chart 的`charts/`目录中： ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` 上面的例子展示了WordPress chart 如何通过将这些chart包含在 `charts/` 目录中来表达它对Apache 和 MySQL的依赖。 **提示：** _要将依赖放入`charts/`目录，使用 `helm pull` 命令_ ### 使用依赖的操作部分 上面的部分说明如何指定chart的依赖，但是对使用 `helm install` 和 `helm upgrade` 安装chart有什么影响？ 假设有个chart "A" 创建了下面的Kubernetes对象： - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" 另外，A是依赖于chart B创建的对象： - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" 安装/升级chart A后，会创建/修改一个单独的Helm版本。这个版本会按顺序创建/升级以下所有的Kubernetes对象： - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet 这是因为当Helm安装/升级chart时，chart中所有的Kubernetes对象以及依赖会 - 聚合成一个单一的集合；然后 - 按照类型和名称排序；然后 - 按这个顺序创建/升级。 至此会为chart及其依赖创建一个包含所有对象的release版本。 Kubernetes类型的安装顺序会按照kind_sorter.go(查看 [Helm源文件](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go))中给出的枚举顺序进行。 ## Templates and Values Helm Chart 模板是按照[Go模板语言](https://golang.org/pkg/text/template/)书写， 增加了50个左右的附加模板函数[来自 Sprig库](https://github.com/Masterminds/sprig) 和一些其他[指定的函数](https://helm.sh/zh/docs/howto/charts_tips_and_tricks)。 所有模板文件存储在chart的 `templates/` 文件夹。 当Helm渲染chart时，它会通过模板引擎遍历目录中的每个文件。 模板的Value通过两种方式提供： - Chart开发者可以在chart中提供一个命名为 `values.yaml` 的文件。这个文件包含了默认值。 - Chart用户可以提供一个包含了value的YAML文件。可以在命令行使用 `helm install`命令时提供。 当用户提供自定义value时，这些value会覆盖chart的`values.yaml`文件中value。 ### 模板文件 模板文件遵守书写Go模板的标准惯例（查看[文本/模板 Go 包文档](https://golang.org/pkg/text/template/)了解更多）。 模板文件的例子看起来像这样： ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` 上面的例子，松散地基于[https://github.com/deis/charts](https://github.com/deis/charts)， 是一个Kubernetes副本控制器的模板。可以使用下面四种模板值（一般被定义在`values.yaml`文件）： - `imageRegistry`: Docker镜像的源注册表 - `dockerTag`: Docker镜像的tag - `pullPolicy`: Kubernetes的拉取策略 - `storage`: 后台存储，默认设置为`"minio"` 所有的值都是模板作者定义的。Helm不需要或指定参数。 要了解更多chart的工作，请查阅CNCF的 [Artifact Hub](https://artifacthub.io/packages/search?kind=0)。 ### 预定义的Values Values通过模板中`.Values`对象可访问的`values.yaml`文件（或者通过 `--set` 参数)提供， 但可以模板中访问其他预定义的数据片段。 以下值是预定义的，对每个模板都有效，并且无法被覆盖。和所有值一样，名称 _区分大小写_。 - `Release.Name`: 版本名称(非chart的) - `Release.Namespace`: 发布的chart版本的命名空间 - `Release.Service`: 组织版本的服务 - `Release.IsUpgrade`: 如果当前操作是升级或回滚，设置为true - `Release.IsInstall`: 如果当前操作是安装，设置为true - `Chart`: `Chart.yaml`的内容。因此，chart的版本可以从 `Chart.Version` 获得， 并且维护者在`Chart.Maintainers`里。 - `Files`: chart中的包含了非特殊文件的类图对象。这将不允许你访问模板， 但是可以访问现有的其他文件（除非被`.helmignore`排除在外）。 使用`{{ index .Files "file.name" }}`可以访问文件或者使用`{{.Files.Get name }}`功能。 你也可以使用`{{ .Files.GetBytes }}`作为`[]byte`访问文件内容。 - `Capabilities`: 包含了Kubernetes版本信息的类图对象。(`{{ .Capabilities.KubeVersion }}`) 和支持的Kubernetes API 版本(`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **注意：** 任何未知的`Chart.yaml`字段会被抛弃。在`Chart`对象中无法访问。因此， `Chart.yaml`不能用于将任意结构的数据传递到模板中。不过values文件可用于此。 ### Values文件 考虑到前面部分的模板，`values.yaml`文件提供的必要值如下： ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` values文件被定义为YAML格式。chart会包含一个默认的`values.yaml`文件。 Helm安装命令允许用户使用附加的YAML values覆盖这个values： ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` 以这种方式传递值时，它们会合并到默认的values文件中。比如，`myvals.yaml`文件如下： ```yaml storage: "gcs" ``` 当在chart中这个值被合并到`values.yaml`文件中时，生成的内容是这样： ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` 注意只有最后一个字段会覆盖。 **注意：** chart包含的默认values文件 _必须_ 被命名为`values.yaml`。不过在命令行指定的文件可以是其他名称。 **注意：** 如果`helm install`或`helm upgrade`使用了`--set`参数，这些值在客户端会被简单地转换为YAML。 **注意：** 如果values 文件存在任何必需的条目，它们会在chart模板中使用['required' 函数](https://helm.sh/zh/docs/howto/charts_tips_and_tricks) 声明为必需的。 然后使用模板中的`.Values`对象就可以任意访问这些值了： ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### 范围，依赖和值 Values文件可以声明顶级chart的值，以及`charts/`目录中包含的其他任意chart。 或者换个说法，values文件可以为chart及其任何依赖项提供值。比如，上面示范的WordPress chart同时有 `mysql` 和 `apache` 作为依赖。values文件可以为以下所有这些组件提供依赖： ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` 更高阶的chart可以访问下面定义的所有变量。因此WordPress chart可以用`.Values.mysql.password`访问MySQL密码。 但是低阶的chart不能访问父级chart，所以MySQL无法访问`title`属性。同样也无法访问`apache.port`。 Values 被限制在命名空间中，但是命名空间被删减了。因此对于WordPress chart， 它可以用`.Values.mysql.password`访问MySQL的密码字段。但是对于MySQL chart，值的范围被缩减了且命名空间前缀被移除了， 因此它把密码字段简单地看作`.Values.password`。 #### 全局Values 从2.0.0-Alpha.2开始，Helm 支持特殊的"global"值。设想一下前面的示例中的修改版本： ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` 上面添加了`global`部分和一个值`app: MyWordPress`。这个值以`.Values.global.app`在 _所有_ chart中有效。 比如，`mysql`模板可以以`{{.Values.global.app}}`访问`app`，同样`apache`chart也可以访问。 实际上，上面的values文件会重新生成为这样： ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` 这提供了一种和所有的子chart共享顶级变量的方式，这在类似label设置`metadata`属性时会很有用。 如果子chart声明了一个全局变量，那这个变量会 _向下_ 传递（到子chart的子chart），但不会 _向上_ 传递到父级chart。 子chart无法影响父chart的值。 并且，父chart的全局变量优先于子chart中的全局变量。 ### 架构文件 {#schema-files} 有时候，chart容器可能想基于它们的values值定义一个结构，这可以在`values.schema.json`文件中定义一个架构实现。 架构使用[JSON 架构](https://json-schema.org/)表示。看起来像这样： ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` 这个架构会应用values值并验证它。当执行以下任意命令时会进行验证： - `helm install` - `helm upgrade` - `helm lint` - `helm template` 一个符合此架构要求的`values.yaml`文件示例如下所示： ```yaml name: frontend protocol: https port: 443 ``` 注意这个架构被应用到了最终的 `.Values` 对象，而不仅仅是`values.yaml`文件。 这意味着下面的`yaml`文件是有效的，给定的chart是用下面显示的适当的`--set`选项安装的： ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` 此外，最终的`.Values`对象是根据*所有的*子chart架构检查。 这意味着父chart无法规避子chart的限制。 这也是逆向的——如果子 chart 的 `values.yaml` 文件无法满足需求，父 chart *必须*满足这些限制才能有效。 可以通过以下选项禁用架构验证。这在离线环境中特别有用，尤其是当 chart 的 JSON Schema 文件包含远程引用时。 ```console helm install --skip-schema-validation ``` ### 参考 在编写模板，值和架构文件时，有几个标准的参考可以帮助你。 - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## 用户自定义资源(CRD) Kubernetes提供了一种声明Kubernetes新类型对象的机制。使用CustomResourceDefinition（CRD）， Kubernetes开发者可以声明自定义资源类型。 Helm 3中,CRD被视为一种特殊的对象。它们被安装在chart的其他部分之前，并受到一些限制。 CRD YAML文件应被放置在chart的`crds/`目录中。 多个CRD(用YAML的开始和结束符分隔)可以被放置在同一个文件中。Helm会尝试加载CRD目录中 _所有的_ 文件到Kubernetes。 CRD 文件 _无法模板化_，必须是普通的YAML文档。 当Helm安装新chart时，会上传CRD，暂停安装直到CRD可以被API服务使用，然后启动模板引擎， 渲染chart其他部分，并上传到Kubernetes。因为这个顺序，CRD信息会在Helm模板中的 `.Capabilities`对象中生效，并且Helm模板会创建在CRD中声明的新的实例对象。 比如，如果你的chart在`crds/`目录中有针对于`CronTab`的CRD，你可以在`templates/`目录中创建`CronTab`类型实例： ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` `crontab.yaml`文件必须包含没有模板指令的CRD: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` 然后模板`mycrontab.yaml`可以创建一个新的`CronTab`（照例使用模板）： ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm在安装`templates/`内容之前会保证`CronTab`类型安装成功并对Kubernetes API可用。 ### CRD的限制 不像大部分的Kubernetes对象，CRD是全局安装的。因此Helm管理CRD时会采取非常谨慎的方式。 CRD受到以下限制： - CRD从不重新安装。 如果Helm确定`crds/`目录中的CRD已经存在（忽略版本），Helm不会安装或升级。 - CRD从不会在升级或回滚时安装。Helm只会在安装时创建CRD。 - CRD从不会被删除。自动删除CRD会删除集群中所有命名空间中的所有CRD内容。因此Helm不会删除CRD。 希望升级或删除CRD的操作员应该谨慎地手动执行此操作。 ## 使用Helm管理Chart `helm`工具有一些命令用来处理chart。 它可以为你创建一个新chart： ```console $ helm create mychart Created mychart/ ``` 编辑了chart之后，`helm`能为你把它打包成一个chart存档： ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` 你也可以使用`helm` 帮你找到chart的格式或信息的问题： ```console $ helm lint mychart No issues found ``` ## Chart仓库 _chart仓库_ 是一个HTTP服务器，包含了一个或多个打包的chart。当`helm`用来管理本地chart目录时， 共享chart时，首选的机制就是使用chart仓库。 任何可以服务于YAML文件和tar文件并可以响应GET请求的HTTP服务器都可以用做仓库服务器。 Helm 团队已经测试了一些服务器，包括激活websit模组的Google Cloud 存储，以及使用website的S3。 仓库的主要特征存在一个名为 `index.yaml` 的特殊文件，文件中包含仓库提供的包的完整列表， 以及允许检索和验证这些包的元数据。 在客户端，仓库使用`helm repo`命令管理。然而，Helm不提供上传chart到远程仓库的工具。 这是因为这样做会给执行服务器增加大量的必要条件，也就增加了设置仓库的障碍。 ## Chart Starter 包 `helm create` 命令可以附带一个可选的 `--starter` 选项让你指定一个 "starter chart"。此外，starter 选项还有一个短别名 `-p`。 用法示例： ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Starter 就只是普通 chart，但是被放置在 `$XDG_DATA_HOME/helm/starters`。作为一个 chart 开发者，你可以编写专门设计用作 starter 的 chart。设计此类 chart 应注意以下考虑因素： - `Chart.yaml`会被生成器覆盖。 - 用户将希望修改此类chart的内容，所以文档应该说明用户如果做到这一点。 - 所有出现的 `` 都会被替换为指定的 chart 名称，以便 starter chart 可以作为模板使用，但某些变量文件除外。例如，如果你在 `vars` 目录中使用自定义文件或某些 `README.md` 文件，`` 将不会在其中被替换。此外，chart 描述不会被继承。 当前增加一个 chart 到 `$XDG_DATA_HOME/helm/starters` 的唯一方式就是手动复制到该目录。在你的 chart 文档中，你可能需要解释这个过程。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/charts_hooks.md ================================================ --- title: Chart 钩子 description: 描述如何使用 chart 钩子。 sidebar_position: 2 --- Helm 提供了钩子（hook）机制，允许 chart 开发者在 release 生命周期的特定节点进行干预。例如，你可以使用钩子来： - 在安装过程中，于其他 chart 加载之前先加载一个 ConfigMap 或 Secret。 - 在安装新 chart 之前执行一个 Job 来备份数据库，然后在升级完成后执行另一个 Job 来恢复数据。 - 在删除 release 之前执行一个 Job，以便优雅地将服务从轮转中移除。 钩子的工作方式与普通模板类似，但它们带有特殊的注解，使 Helm 以不同方式处理它们。本节介绍钩子的基本使用模式。 ## 可用的钩子 定义了以下钩子： | 注解值 | 描述 | | ---------------- | ----------------------------------------------------------------------------------------------- | | `pre-install` | 在模板渲染后、Kubernetes 中创建任何资源之前执行 | | `post-install` | 在所有资源加载到 Kubernetes 后执行 | | `pre-delete` | 在删除请求时、从 Kubernetes 删除任何资源之前执行 | | `post-delete` | 在删除请求时、release 的所有资源已删除后执行 | | `pre-upgrade` | 在升级请求时、模板渲染后、任何资源更新之前执行 | | `post-upgrade` | 在升级请求时、所有资源升级完成后执行 | | `pre-rollback` | 在回滚请求时、模板渲染后、任何资源回滚之前执行 | | `post-rollback` | 在回滚请求时、所有资源修改完成后执行 | | `test` | 在调用 Helm test 子命令时执行（[查看 test 文档](/zh/docs/topics/chart_tests/)） | _注意：`crd-install` 钩子已在 Helm 3 中移除，改用 `crds/` 目录。_ ## 钩子和 Release 生命周期 钩子允许 chart 开发者在 release 生命周期的关键节点执行操作。例如，考虑 `helm install` 的生命周期。默认情况下，生命周期如下： 1. 用户运行 `helm install foo` 2. 调用 Helm 库的安装 API 3. 经过一些验证后，库渲染 `foo` 的模板 4. 库将生成的资源加载到 Kubernetes 5. 库将 release 对象（和其他数据）返回给客户端 6. 客户端退出 Helm 为 `install` 生命周期定义了两个钩子：`pre-install` 和 `post-install`。如果 `foo` chart 的开发者实现了这两个钩子，生命周期会变成这样： 1. 用户运行 `helm install foo` 2. 调用 Helm 库的安装 API 3. 安装 `crds/` 目录中的 CRD 4. 经过一些验证后，库渲染 `foo` 的模板 5. 库准备执行 `pre-install` 钩子（将钩子资源加载到 Kubernetes） 6. 库按权重对钩子排序（默认权重为 0），然后按资源类型排序，最后按名称升序排列 7. 库先加载权重最小的钩子（从负到正） 8. 库等待钩子进入 "Ready" 状态（CRD 除外） 9. 库将生成的资源加载到 Kubernetes。注意，如果设置了 `--wait` 参数，库会等待所有资源进入就绪状态，并且在资源就绪之前不会执行 `post-install` 钩子。 10. 库执行 `post-install` 钩子（加载钩子资源） 11. 库等待钩子进入 "Ready" 状态 12. 库将 release 对象（和其他数据）返回给客户端 13. 客户端退出 等待钩子就绪是什么意思？这取决于钩子中声明的资源类型。如果资源是 `Job` 或 `Pod` 类型，Helm 会等待它成功运行完成。如果钩子失败，release 也会失败。这是一个*阻塞操作*，因此 Helm 客户端会在 Job 运行期间暂停。 对于其他类型的资源，一旦 Kubernetes 将资源标记为已加载（已添加或已更新），该资源就被视为 "Ready"。当一个钩子中声明了多个资源时，这些资源会串行执行。如果它们有钩子权重（见下文），则按权重顺序执行。从 Helm 3.2.0 开始，具有相同权重的钩子资源会按照与普通非钩子资源相同的顺序安装。否则，执行顺序不做保证。（在 Helm 2.3.0 及之后版本中，它们按字母顺序排序。但这一行为并非强制绑定，未来可能会改变。）最佳实践是添加钩子权重，如果权重不重要则设为 `0`。 ### 钩子资源不随对应 release 管理 钩子创建的资源目前不作为 release 的一部分进行跟踪或管理。一旦 Helm 确认钩子已达到就绪状态，就不再管理该钩子资源。在未来的 Helm 3 版本中可能会添加删除对应 release 时的钩子资源垃圾回收功能，因此任何不能被删除的钩子资源都应该添加注解 `helm.sh/resource-policy: keep`。 实际上，这意味着如果你在钩子中创建了资源，就不能依赖 `helm uninstall` 来删除这些资源。要销毁这些资源，你需要在钩子模板文件中[添加自定义的 `helm.sh/hook-delete-policy` 注解](#钩子删除策略)，或者[设置 Job 资源的生存时间（TTL）字段](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)。 ## 编写钩子 钩子就是在 `metadata` 部分带有特殊注解的 Kubernetes 清单文件。由于它们是模板文件，你可以使用所有常规的模板功能，包括读取 `.Values`、`.Release` 和 `.Template`。 例如，下面这个存储在 `templates/post-install-job.yaml` 中的模板，声明了一个在 `post-install` 时运行的 Job： ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` 使这个模板成为钩子的是以下注解： ```yaml annotations: "helm.sh/hook": post-install ``` 一个资源可以实现多个钩子： ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` 同样，实现某个钩子的资源数量也没有限制。例如，可以同时将一个 Secret 和一个 ConfigMap 声明为 pre-install 钩子。 当子 chart 声明钩子时，这些钩子也会被执行。顶级 chart 无法禁用子 chart 声明的钩子。 可以为钩子定义权重，以帮助建立确定性的执行顺序。权重使用以下注解定义： ```yaml annotations: "helm.sh/hook-weight": "5" ``` 钩子权重可以是正数或负数，但必须以字符串形式表示。当 Helm 开始执行特定类型的钩子时，会按升序对这些钩子进行排序。 ### 钩子删除策略 可以定义策略来决定何时删除对应的钩子资源。钩子删除策略使用以下注解定义： ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` 你可以选择一个或多个已定义的注解值： | 注解值 | 描述 | | ---------------------- | ----------------------------------------------- | | `before-hook-creation` | 在启动新钩子之前删除之前的资源（默认） | | `hook-succeeded` | 在钩子成功执行后删除资源 | | `hook-failed` | 如果钩子执行失败，删除资源 | 如果未指定钩子删除策略注解，则默认使用 `before-hook-creation` 行为。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/index.mdx ================================================ --- title: 主题 sidebar_position: 3 --- # 主题指引 这里可以找到所有您想知道的Helm的关键部分说明。 import DocCardList from '@theme/DocCardList'; ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/kubernetes_apis.md ================================================ --- title: "弃用的 Kubernetes API" description: "介绍 Helm 中与 Kubernetes API 弃用相关的问题" --- Kubernetes 是一个 API 驱动的系统，API 会随着时间推移而不断演进，以反映对问题理解的深入。这是系统及其 API 的常见做法。API 演进的一个重要组成部分是完善的弃用策略和通知机制，用于告知用户 API 的变更。换句话说，API 使用者需要提前知道在哪个版本中某个 API 会被移除或变更。这可以避免意外的破坏性变更对使用者造成影响。 [Kubernetes 弃用策略](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)文档描述了 Kubernetes 如何处理 API 版本的变化。弃用策略规定了在发布弃用公告后，API 版本将被支持的时间范围。因此，关注弃用公告并了解 API 何时被移除非常重要，有助于将影响降到最低。 以下是一个公告示例：[Kubernetes 1.16 中弃用的 API 版本](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)，在该版本发布的几个月之前就已公布。在此之前，这些 API 版本可能已经被标记为弃用。这说明 Kubernetes 有一套良好的策略来通知使用者 API 版本的支持情况。 Helm 模板在定义 Kubernetes 对象时需要指定一个 [Kubernetes API 组](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)，与 Kubernetes manifest 文件类似。API 版本在模板的 `apiVersion` 字段中指定，用于标识 Kubernetes 对象的 API 版本。这意味着 Helm 用户和 chart 维护者需要关注 Kubernetes API 版本的弃用时间，以及会在哪个 Kubernetes 版本中被移除。 ## Chart 维护者 你应该审核 chart，检查是否使用了已弃用或已移除的 Kubernetes API 版本。如果发现不再支持的 API 版本，应更新为受支持的版本并发布新的 chart 版本。API 版本由 `kind` 和 `apiVersion` 字段定义。例如，以下是 Kubernetes 1.16 中被移除的 `Deployment` 对象 API 版本： ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm 用户 你应该审核所使用的 chart（类似于 [chart 维护者](#chart-维护者)的做法），识别其中使用了已弃用或已移除 API 版本的 chart。对于这些 chart，需要检查是否有使用受支持 API 版本的新版本，或者自行更新。 此外，你还需要审核已部署的 chart（即 Helm release），检查是否存在已弃用或已移除的 API 版本。可以使用 `helm get manifest` 命令获取 release 的详细信息。 将 Helm release 更新为受支持的 API 版本，具体操作取决于你的发现： 1. 如果只发现弃用（但尚未移除）的 API 版本： - 执行 `helm upgrade`，使用包含受支持 Kubernetes API 版本的 chart - 在升级描述中添加说明，提示不要回滚到此版本之前的 Helm release 2. 如果发现在某个 Kubernetes 版本中已被移除的 API 版本： - 如果你运行的 Kubernetes 版本中该 API 版本仍然可用（例如，你当前使用 Kubernetes 1.15，但发现使用的 API 将在 1.16 中被移除）： - 按照步骤 1 的流程操作 - 否则（例如，你当前运行的 Kubernetes 版本中，`helm get manifest` 显示的某些 API 版本已不可用）： - 需要编辑存储在集群中的 release manifest，将 API 版本更新为受支持的版本。详见[更新 release manifest 的 API 版本](#更新-release-manifest-的-api-版本) > 注意：在所有将 Helm release 更新为受支持 API 的场景中，都不应该将 release 回滚到包含受支持 API 版本的 release 之前的版本。 > 建议：最佳实践是在升级到移除这些 API 的 Kubernetes 集群版本之前，先将使用弃用 API 版本的 release 升级为受支持的 API 版本。 如果没有按照上述建议更新 release，在 API 版本已被移除的 Kubernetes 版本中尝试升级 release 时，会出现类似以下的错误： ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm 在这种情况下会失败，因为它尝试在当前已部署的 release（包含在此 Kubernetes 版本中已移除的 API）与你传入的使用更新/受支持 API 版本的 chart 之间创建差异补丁。失败的根本原因是：当 Kubernetes 移除某个 API 版本后，Kubernetes Go 客户端库将无法解析使用弃用 API 的对象，因此 Helm 在调用该库时会失败。不幸的是，Helm 无法从这种情况中恢复，也无法继续管理这样的 release。有关如何从这种情况中恢复的详细信息，请参阅[更新 release manifest 的 API 版本](#更新-release-manifest-的-api-版本)。 ## 更新 release manifest 的 API 版本 manifest 是 Helm release 对象的一个属性，存储在集群中 Secret（默认）或 ConfigMap 的 data 字段中。data 字段包含一个经过 gzip 压缩并使用 base64 编码的对象（如果是 Secret，还会有额外的一层 base64 编码）。在 release 所在的命名空间中，每个 release 版本/修订都对应一个 Secret 或 ConfigMap。 你可以使用 Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) 插件来将 release 更新为受支持的 API。详情请查看该插件的 readme 文档。 或者，你可以按照以下手动步骤更新 release manifest 的 API 版本。根据你的配置，选择 Secret 或 ConfigMap 后端对应的步骤。 - 获取与最新部署的 release 关联的 Secret 或 ConfigMap 名称： - Secret 后端：`kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap 后端：`kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - 获取最新部署 release 的详细信息： - Secret 后端：`kubectl get secret -n -o yaml > release.yaml` - ConfigMap 后端：`kubectl get configmap -n -o yaml > release.yaml` - 备份 release 以便出错时恢复： - `cp release.yaml release.bak` - 紧急情况下恢复：`kubectl apply -f release.bak -n ` - 解码 release 对象： - Secret 后端：`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap 后端：`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - 修改 manifest 中的 API 版本。可以使用任意工具（如编辑器）进行修改。API 版本位于解码后的 release 对象 (`release.data.decoded`) 的 `manifest` 字段中 - 编码 release 对象： - Secret 后端：`cat release.data.decoded | gzip | base64 | base64` - ConfigMap 后端：`cat release.data.decoded | gzip | base64` - 用新编码的 release 对象替换部署文件 (`release.yaml`) 中 `data.release` 属性的值 - 将文件应用到命名空间：`kubectl apply -f release.yaml -n ` - 使用包含受支持 Kubernetes API 版本的 chart 执行 `helm upgrade` - 在升级描述中添加说明，提示不要回滚到此版本之前的版本 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Kubernetes 发行版指南 description: 介绍在特定 Kubernetes 环境中使用 Helm 的相关信息。 sidebar_position: 10 --- Helm 可以在任何[符合标准的 Kubernetes 版本](https://github.com/cncf/k8s-conformance)上运行（无论是否经过[认证](https://www.cncf.io/certification/software-conformance/)）。 本文档介绍在特定 Kubernetes 环境中使用 Helm 的相关信息。如有需要，欢迎补充更多发行版的详细信息（按字母顺序排列）。 ## AKS Helm 可以在 [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm) 上使用。 ## DC/OS Helm 已在 Mesosphere DC/OS 1.11 Kubernetes 平台上测试通过，无需额外配置。 ## EKS Helm 可以在 Amazon Elastic Kubernetes Service (Amazon EKS) 上使用：[在 Amazon EKS 上使用 Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)。 ## GKE Google 的 GKE 托管 Kubernetes 平台可以正常使用 Helm，无需额外配置。 ## `scripts/local-cluster` 和 Hyperkube 通过 `scripts/local-cluster.sh` 配置的 Hyperkube 可以正常使用。对于原始 Hyperkube，可能需要进行一些手动配置。 ## IKS Helm 可以在 [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm) 上使用。 ## KIND (Kubernetes IN Docker) Helm 会定期在 [KIND](https://github.com/kubernetes-sigs/kind) 上进行测试。 ## KubeOne Helm 可以在 KubeOne 配置的集群中正常使用，无需特殊配置。 ## Kubermatic Helm 可以在 Kubermatic 创建的用户集群中正常使用，无需特殊配置。由于种子集群的配置方式可能不同，Helm 的支持情况取决于具体配置。 ## MicroK8s 可以使用以下命令在 [MicroK8s](https://microk8s.io) 中启用 Helm：`microk8s.enable helm3` ## Minikube Helm 已在 [Minikube](https://github.com/kubernetes/minikube) 上测试通过，无需额外配置。 ## Openshift Helm 可以在 OpenShift Online、OpenShift Dedicated、OpenShift Container Platform（版本 >= 3.6）或 OpenShift Origin（版本 >= 3.6）上直接使用。更多信息请参阅[这篇博客文章](https://blog.openshift.com/getting-started-helm-openshift/)。 ## Platform9 Helm 已预装在 [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes) 中。Platform9 通过 App Catalog UI 和原生 Kubernetes CLI 提供对所有官方 Helm chart 的访问。也可以手动添加其他仓库。更多详情请参阅 [Platform9 App Catalog 文档](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes)。 ## 使用 `kubeadm` 的 Ubuntu 通过 `kubeadm` 引导的 Kubernetes 可以在以下 Linux 发行版上正常运行： - Ubuntu 16.04 - Fedora release 25 某些 Helm 版本（v2.0.0-beta2）需要执行 `export KUBECONFIG=/etc/kubernetes/admin.conf` 或创建 `~/.kube/config` 文件。 ## VMware Tanzu Kubernetes Grid Helm 可以在 VMware Tanzu Kubernetes Grid (TKG) 上运行，无需更改配置。Tanzu CLI 可以管理 [helm-controller](https://fluxcd.io/flux/components/helm/) 的安装包，支持以声明式方式管理 Helm chart release。更多详情请参阅 TKG 文档中的 [CLI 管理包](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5)部分。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/library_charts.md ================================================ --- title: 库 chart description: 介绍库 chart 及其使用示例 sidebar_position: 4 --- 库 chart 是一种 [Helm chart](./charts.md)，用于定义可供其他 chart 中的 Helm 模板共享的 chart 原语或定义。这使用户可以共享可复用的代码片段，避免重复，保持 chart [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)。 库 chart 在 Helm 3 中引入，正式承认了自 Helm 2 以来 chart 维护者一直使用的通用或辅助 chart。将其作为一种 chart 类型引入，可以提供： - 明确区分通用 chart 和应用 chart 的方法 - 阻止安装通用 chart 的逻辑 - 通用 chart 中的模板不会被渲染，这些模板可能包含 release 相关的内容 - 允许依赖的 chart 使用导入者的上下文 chart 维护者可以将通用 chart 定义为库，Helm 会以标准、一致的方式处理该 chart。这也意味着可以通过更改 chart 类型来共享应用 chart 中的定义。 ## 创建简单的库 chart 如前所述，库 chart 是一种 [Helm chart](./charts.md) 类型。这意味着你可以从创建脚手架 chart 开始： ```console $ helm create mylibchart Creating mylibchart ``` 首先删除 `templates` 目录中的所有文件，因为我们将在本示例中创建自己的模板定义。 ```console $ rm -rf mylibchart/templates/* ``` values 文件也不需要。 ```console $ rm -f mylibchart/values.yaml ``` 在创建通用代码之前，先快速回顾一些相关的 Helm 概念。[命名模板](../chart_template_guide/named_templates.md)（有时称为局部模板或子模板）是定义在文件中并赋予名称的简单模板。在 `templates/` 目录中，任何以下划线（_）开头的文件都不会输出 Kubernetes 清单文件。因此按照惯例，辅助模板和局部模板放在 `_*.tpl` 或 `_*.yaml` 文件中。 在本示例中，我们将编写一个通用的 ConfigMap，用于创建空的 ConfigMap 资源。在 `mylibchart/templates/_configmap.yaml` 文件中定义如下： ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` ConfigMap 结构定义在名为 `mylibchart.configmap.tpl` 的命名模板中。这是一个简单的 ConfigMap，`data` 为空资源。该文件中还有另一个命名模板 `mylibchart.configmap`，它包含另一个命名模板 `mylibchart.util.merge`，该模板接受 2 个命名模板作为参数：调用 `mylibchart.configmap` 的模板和 `mylibchart.configmap.tpl`。 辅助函数 `mylibchart.util.merge` 是 `mylibchart/templates/_util.yaml` 文件中的一个命名模板。这是来自[通用 Helm 辅助 chart](#通用-helm-辅助-chart) 的实用工具，因为它可以合并两个模板并覆盖两者的公共部分： ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` 当 chart 需要使用通用代码并通过配置进行自定义时，这一点非常重要。 最后，将 chart 类型更改为 `library`。需要按如下方式编辑 `mylibchart/Chart.yaml`： ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` 库 chart 现在可以共享了，其 ConfigMap 定义可以被复用。 在继续之前，值得检查一下 Helm 是否将该 chart 识别为库 chart： ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## 使用简单的库 chart 现在可以使用库 chart 了。这意味着需要再次创建一个脚手架 chart： ```console $ helm create mychart Creating mychart ``` 因为我们只想创建一个 ConfigMap，所以再次清空模板文件： ```console $ rm -rf mychart/templates/* ``` 在 Helm 模板中创建简单的 ConfigMap 时，看起来类似这样： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` 然而，我们将复用已在 `mylibchart` 中创建的通用代码。可以在 `mychart/templates/configmap.yaml` 文件中创建 ConfigMap，如下所示： ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` 可以看到，通过继承为 ConfigMap 添加标准属性的通用定义，简化了我们的工作。在模板中添加了配置，本例中是数据键 `myvalue` 及其值。该配置会覆盖通用 ConfigMap 的空资源。这得益于我们在上一节中提到的辅助函数 `mylibchart.util.merge`。 为了能使用通用代码，需要添加 `mylibchart` 作为依赖。在 `mychart/Chart.yaml` 文件末尾添加以下内容： ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` 这将库 chart 作为动态依赖包含进来，它位于文件系统中与应用 chart 相同的父路径下。由于将库 chart 作为动态依赖包含，需要运行 `helm dependency update`。它会将库 chart 复制到你的 `charts/` 目录。 ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` 现在可以部署 chart 了。安装之前，值得先检查渲染后的模板。 ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` 这看起来正是我们需要的 ConfigMap，数据已被覆盖为 `myvalue: Hello World`。现在安装它： ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` 我们可以检索该 release 并查看实际加载的模板。 ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## 库 chart 的优势 由于库 chart 无法作为独立 chart 使用，它们可以利用以下功能： - `.Files` 对象引用父 chart 的文件路径，而不是库 chart 的本地路径 - `.Values` 对象与父 chart 相同，与应用[子 chart](../chart_template_guide/subcharts_and_globals.md) 不同（子 chart 接收在父 chart 中其标题下配置的值部分） ## 通用 Helm 辅助 chart ```markdown 注意：GitHub 上的通用 Helm 辅助 chart 仓库已不再积极维护，该仓库已被弃用并归档。 ``` 这个 [chart](https://github.com/helm/charts/tree/master/incubator/common) 是通用 chart 的原始模式。它提供了反映 Kubernetes chart 开发最佳实践的实用工具。最棒的是，在开发 chart 时可以直接使用这些便捷的共享代码。 以下是快速使用它的方法。更多详细信息，请查看 [README](https://github.com/helm/charts/blob/master/incubator/common/README.md)。 再次创建一个脚手架 chart： ```console $ helm create demo Creating demo ``` 使用辅助 chart 中的通用代码。首先，按如下方式编辑 Deployment 文件 `demo/templates/deployment.yaml`： ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` 然后是 Service 文件 `demo/templates/service.yaml`，如下所示： ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` 这些模板展示了如何通过从辅助 chart 继承通用代码，将你的代码简化为仅包含资源的配置或自定义部分。 为了能使用通用代码，需要添加 `common` 作为依赖。在 `demo/Chart.yaml` 文件末尾添加以下内容： ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` 注意：需要将 `incubator` 仓库添加到 Helm 仓库列表中（`helm repo add`）。 由于将该 chart 作为动态依赖包含，需要运行 `helm dependency update`。这会将辅助 chart 复制到你的 `charts/` 目录。 由于辅助 chart 使用了一些 Helm 2 的结构，需要在 `demo/values.yaml` 中添加以下内容，以便在 Helm 3 脚手架 chart 更新后能够加载 `nginx` 镜像： ```yaml image: tag: 1.16.0 ``` 在部署之前，可以使用 `helm lint` 和 `helm template` 命令测试 chart 模板是否正确。 如果一切正常，使用 `helm install` 进行部署！ ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: "SQL 存储后端的权限管理" description: "了解如何在使用 SQL 存储后端时设置权限" --- 本文档旨在指导用户在使用 SQL 存储后端时如何设置和管理权限。 ## 介绍 Helm 利用 Kubernetes 的 RBAC 特性来处理权限。但在使用 SQL 存储后端时，无法使用 Kubernetes 的角色来判断用户是否可以访问特定资源。本文档将展示如何创建和管理这些权限。 ## 初始化 Helm CLI 首次连接数据库时，客户端会检查数据库是否已完成初始化。如果尚未初始化，客户端会自动完成必要的设置。初始化过程需要 public 模式（schema）的管理员权限，或者至少能够： * 创建表 * 在 public 模式上授予权限 数据库完成迁移后，其他角色就可以使用客户端了。 ## 在 PostgreSQL 中向非管理员用户授权 SQL 后端驱动使用 PostgreSQL 的 [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)（行级安全）特性来管理权限。RLS 允许所有用户对同一张表进行读写操作，但在未获得明确授权的情况下，无法操作相同的行。默认情况下，未被明确授予相应权限的角色在运行 `helm list` 时会返回空列表，也无法检索或修改集群中的任何资源。 下面介绍如何为指定角色授予访问特定命名空间的权限： ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` 此命令会将满足 `namespace = 'default'` 条件的所有资源的读写权限授予角色 `role`。创建该策略后，以角色 `role` 身份连接数据库的用户在运行 `helm list` 时就能看到 `default` 命名空间中的所有 release，并可以对其进行修改和删除。 RLS 支持细粒度的权限管理。你可以根据表的不同列来限制访问权限： * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/plugins.md ================================================ --- title: Helm 插件指南 description: 介绍如何使用和创建插件来扩展 Helm 功能。 sidebar_position: 12 --- Helm 插件是一个可以通过 `helm` CLI 访问的工具，但不是 Helm 的内置代码。 已有插件可以在 [相关项目](/community/related#helm-plugins) 部分找到，也可以搜索 [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories)。 本指南介绍如何使用和创建插件。 ## 概述 Helm 插件是与 Helm 无缝集成的附加工具。插件提供一种扩展 Helm 核心特性集的方法，但不需要每个新的特性都用 Go 编写并加入核心工具中。 Helm 插件有以下特性： - 可以在不影响 Helm 核心工具的情况下添加和移除。 - 可以用任意编程语言编写。 - 与 Helm 集成，并展示在 `helm help` 和其他地方。 Helm 插件位于 `$HELM_PLUGINS`。你可以使用 `helm env` 命令找到该变量的当前值，包括未在环境中设置时的默认值。 Helm 插件模型部分基于 Git 的插件模型。为此，你有时可能听到 `helm` 被称为 _porcelain_ 层，而插件是 _plumbing_ 层。这是一种简写方式，表示 Helm 提供用户体验和顶层处理逻辑，而插件执行所需操作的"细节工作"。 ## 安装插件 使用 `helm plugin install ` 命令安装插件。你可以传入本地文件系统上的插件路径或远程 VCS 仓库的 URL。`helm plugin install` 命令会将给定路径/URL 的插件克隆或复制到 `$HELM_PLUGINS`。如果从 VCS 安装，可以使用 `--version` 参数指定版本。 ```console $ helm plugin install https://github.com/adamreese/helm-env ``` 如果是插件 tar 包，只需将插件解压到 `$HELM_PLUGINS` 目录。也可以直接从 URL 安装 tar 包插件：`helm plugin install https://domain/path/to/plugin.tar.gz` ## 插件文件结构 在很多方面，插件类似于 chart。每个插件都有一个包含 `plugin.yaml` 文件的顶级目录。可能存在其他文件，但只有 `plugin.yaml` 文件是必需的。 ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## plugin.yaml 文件 plugin.yaml 文件是插件的必需文件。它包含以下字段： ```yaml name: 插件名称（必需） version: SemVer 2 版本号（必需） usage: 在帮助中显示的单行使用说明 description: 在 helm help 等位置显示的详细描述 ignoreFlags: 忽略从 Helm 传入的参数 platformCommand: # 根据平台配置要执行的命令 - os: 操作系统匹配，可以为空或省略以匹配所有操作系统 arch: 架构匹配，可以为空或省略以匹配所有架构 command: 要执行的插件命令 args: 插件命令参数 command: （已弃用）插件命令，请改用 platformCommand platformHooks: # 根据平台配置插件生命周期钩子 install: # 安装生命周期命令 - os: 操作系统匹配，可以为空或省略以匹配所有操作系统 arch: 架构匹配，可以为空或省略以匹配所有架构 command: 要执行的插件安装命令 args: 插件安装命令参数 update: # 更新生命周期命令 - os: 操作系统匹配，可以为空或省略以匹配所有操作系统 arch: 架构匹配，可以为空或省略以匹配所有架构 command: 要执行的插件更新命令 args: 插件更新命令参数 delete: # 删除生命周期命令 - os: 操作系统匹配，可以为空或省略以匹配所有操作系统 arch: 架构匹配，可以为空或省略以匹配所有架构 command: 要执行的插件删除命令 args: 插件删除命令参数 hooks: # （已弃用）插件生命周期钩子，请改用 platformHooks install: 安装插件的命令 update: 更新插件的命令 delete: 删除插件的命令 downloaders: # 配置下载器能力 - command: 要调用的命令 protocols: - 支持的协议方案 ``` ### `name` 字段 `name` 是插件的名称。当 Helm 执行此插件时使用此名称（例如，`helm NAME` 会调用此插件）。 _`name` 应该匹配目录名称。_ 在上面的例子中，这意味着 `name: last` 的插件应该包含在名为 `last` 的目录中。 `name` 的限制： - `name` 不能与现有的 `helm` 顶级命令重复。 - `name` 的字符必须限制为 ASCII a-z、A-Z、0-9、`_` 和 `-`。 ### `version` 字段 `version` 是插件的 SemVer 2 版本。`usage` 和 `description` 都用于生成命令的帮助文本。 ### `ignoreFlags` 字段 `ignoreFlags` 开关告诉 Helm _不要_ 将参数传递给插件。因此，如果插件使用 `helm myplugin --foo` 调用且 `ignoreFlags: true`，那么 `--foo` 会被静默丢弃。 ### `platformCommand` 字段 `platformCommand` 配置插件被调用时将执行的命令。你不能同时设置 `platformCommand` 和 `command`，否则会导致错误。以下规则用于决定使用哪个命令： - 如果 `platformCommand` 存在，它将被使用。 - 如果 `os` 和 `arch` 都匹配当前平台，搜索将停止并使用该命令。 - 如果 `os` 匹配且 `arch` 为空，将使用该命令。 - 如果 `os` 和 `arch` 都为空，将使用该命令。 - 如果没有匹配，Helm 会报错退出。 - 如果 `platformCommand` 不存在但已弃用的 `command` 存在，将使用 `command`。 - 如果命令为空，Helm 会报错退出。 ### `platformHooks` 字段 `platformHooks` 配置插件针对生命周期事件将执行的命令。你不能同时设置 `platformHooks` 和 `hooks`，否则会导致错误。以下规则用于决定使用哪个钩子命令： - 如果 `platformHooks` 存在，它将被使用，并处理生命周期事件的命令。 - 如果 `os` 和 `arch` 都匹配当前平台，搜索将停止并使用该命令。 - 如果 `os` 匹配且 `arch` 为空，将使用该命令。 - 如果 `os` 和 `arch` 都为空，将使用该命令。 - 如果没有匹配，Helm 将跳过该事件。 - 如果 `platformHooks` 不存在但已弃用的 `hooks` 存在，将使用生命周期事件的命令。 - 如果命令为空，Helm 将跳过该事件。 ## 构建插件 下面是一个简单插件的 YAML，用于获取最后一个 release 名称： ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` 插件可能需要额外的脚本和可执行文件。脚本可以包含在插件目录中，可执行文件可以通过钩子下载。以下是一个示例插件： ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` 环境变量会在插件执行前被插值。上述模式说明了表示插件程序所在位置的首选方法。 ### 插件命令 以下是使用插件命令的一些策略： - 如果插件包含可执行文件，`platformCommand:` 的可执行文件应该打包在插件目录中或通过钩子安装。 - `platformCommand:` 或 `command:` 行会在执行前展开所有环境变量。`$HELM_PLUGIN_DIR` 会指向插件目录。 - 命令本身不是在 shell 中执行的。所以你不能写成一行 shell 脚本。 - Helm 在环境变量中注入了大量配置。查看环境变量以了解可用信息。 - Helm 对插件的语言不做任何假设。你可以用任何你喜欢的语言编写。 - 命令负责实现 `-h` 和 `--help` 的特定帮助文本。Helm 会在 `helm help` 和 `helm help myplugin` 中使用 `usage` 和 `description`，但不会处理 `helm myplugin --help`。 ### 测试本地插件 首先你需要找到你的 `HELM_PLUGINS` 路径，运行以下命令： ``` bash helm env ``` 切换到 `HELM_PLUGINS` 设置的目录。 现在你可以添加一个指向插件构建输出的符号链接，在这个例子中我们为 `mapkubeapis` 创建链接。 ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## 下载器插件 默认情况下，Helm 可以使用 HTTP/S 拉取 Chart。从 Helm 2.4.0 开始，插件有一种特殊能力可以从任意来源下载 Chart。 插件应该在 `plugin.yaml` 文件（顶层）中声明这个特殊能力： ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` 如果安装了这样的插件，Helm 可以通过调用 `command` 使用指定的协议方案与仓库进行交互。特殊仓库的添加与常规仓库类似：`helm repo add favorite myprotocol://example.com/`。特殊仓库的规则与常规仓库相同：Helm 必须能够下载 `index.yaml` 文件以发现和缓存可用 Chart 的列表。 已定义的命令将使用以下格式调用：`command certFile keyFile caFile full-URL`。SSL 证书来自仓库定义，存储在 `$HELM_REPOSITORY_CONFIG`（即 `$HELM_CONFIG_HOME/repositories.yaml`）。下载器插件应将原始内容输出到 stdout，并在 stderr 报告错误。 下载器命令也支持子命令或参数，允许你在 `plugin.yaml` 中指定，例如 `bin/mydownloader subcommand -d`。如果你想为主插件命令和下载器命令使用相同的可执行文件，但每个使用不同的子命令，这将非常有用。 ## 环境变量 当 Helm 执行插件时，会将外部环境传递给插件，并且会注入一些额外的环境变量。 像 `KUBECONFIG` 这样的变量，如果在外部环境中设置了，则会为插件设置。 以下变量保证会被设置： - `HELM_PLUGINS`：插件目录的路径。 - `HELM_PLUGIN_NAME`：由 `helm` 调用的插件名称。所以 `helm myplug` 的短名称是 `myplug`。 - `HELM_PLUGIN_DIR`：包含插件的目录。 - `HELM_BIN`：`helm` 命令的路径（如用户执行的那样）。 - `HELM_DEBUG`：表示 helm 是否设置了 debug 标志。 - `HELM_REGISTRY_CONFIG`：注册表配置的位置（如果使用）。注意，Helm 与注册表的使用是实验性功能。 - `HELM_REPOSITORY_CACHE`：仓库缓存文件的路径。 - `HELM_REPOSITORY_CONFIG`：仓库配置文件的路径。 - `HELM_NAMESPACE`：给 `helm` 命令的命名空间（通常使用 `-n` 标志）。 - `HELM_KUBECONTEXT`：给 `helm` 命令的 Kubernetes 配置上下文名称。 另外，如果明确指定了 Kubernetes 配置文件，它将被设置为 `KUBECONFIG` 变量。 ## 参数解析说明 当执行插件时，Helm 会解析全局标志供自己使用。这些标志都不会传递给插件。 - `--burst-limit`：转换为 `$HELM_BURST_LIMIT` - `--debug`：如果指定，`$HELM_DEBUG` 设置为 `1` - `--kube-apiserver`：转换为 `$HELM_KUBEAPISERVER` - `--kube-as-group`：转换为 `$HELM_KUBEASGROUPS` - `--kube-as-user`：转换为 `$HELM_KUBEASUSER` - `--kube-ca-file`：转换为 `$HELM_KUBECAFILE` - `--kube-context`：转换为 `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`：转换为 `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`：转换为 `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`：转换为 `$HELM_KUBETOKEN` - `--kubeconfig`：转换为 `$KUBECONFIG` - `--namespace` 和 `-n`：转换为 `$HELM_NAMESPACE` - `--qps`：转换为 `$HELM_QPS` - `--registry-config`：转换为 `$HELM_REGISTRY_CONFIG` - `--repository-cache`：转换为 `$HELM_REPOSITORY_CACHE` - `--repository-config`：转换为 `$HELM_REPOSITORY_CONFIG` 插件 _应该_ 对 `-h` 和 `--help` 显示帮助文本然后退出。在所有其他情况下，插件可以根据需要使用参数。 ## 提供 shell 自动补全 从 Helm 3.2 开始，作为 Helm 现有自动补全机制的一部分，插件可以选择性地提供 shell 自动补全支持。 ### 静态自动补全 如果插件提供了自己的标志和/或子命令，可以通过在插件根目录中放置 `completion.yaml` 文件来通知 Helm。`completion.yaml` 文件格式如下： ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: <以此类推，递归> ``` 注意： 1. 所有部分都是可选的，但应在适用时提供。 2. 标志不应包含 `-` 或 `--` 前缀。 3. 可以且应该指定短标志和长标志。短标志不需要与其对应的长格式关联，但两种形式都应列出。 4. 标志不需要以任何方式排序，但需要列在文件子命令层次结构的正确位置。 5. Helm 现有的全局标志已由 Helm 的自动补全机制处理，因此插件不需要指定以下标志：`--debug`、`--namespace` 或 `-n`、`--kube-context` 和 `--kubeconfig`，或任何其他全局标志。 6. `validArgs` 列表提供了子命令后第一个参数的可能补全的静态列表。并非总是能事先提供这样的列表（参见下面的[动态补全](#动态补全)部分），在这种情况下可以省略 `validArgs` 部分。 `completion.yaml` 文件是完全可选的。如果没有提供，Helm 将不会为插件提供 shell 自动补全功能（除非插件支持[动态补全](#动态补全)）。另外，添加 `completion.yaml` 文件是向后兼容的，不会影响在旧版 helm 中使用插件的行为。 例如，对于 [`fullstatus 插件`](https://github.com/marckhouzam/helm-fullstatus)，它没有子命令但接受与 `helm status` 命令相同的标志，`completion.yaml` 文件是： ```yaml name: fullstatus flags: - o - output - revision ``` 一个更复杂的例子是 [`2to3 插件`](https://github.com/helm/helm-2to3)，它的 `completion.yaml` 文件是： ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### 动态补全 同样从 Helm 3.2 开始，插件可以提供自己的动态 shell 自动补全。动态 shell 自动补全是对无法事先定义的参数值或标志值的补全。例如，补全集群中当前可用的 helm release 名称。 对于支持动态自动补全的插件，必须在其根目录中提供一个名为 `plugin.complete` 的**可执行**文件。当 Helm 补全脚本需要插件的动态补全时，它将执行 `plugin.complete` 文件，传递需要补全的命令行。`plugin.complete` 可执行文件需要有逻辑来确定正确的补全选项，并将它们输出到标准输出以供 Helm 补全脚本使用。 `plugin.complete` 文件是完全可选的。如果没有提供，Helm 将不会为插件提供动态自动补全。另外，添加 `plugin.complete` 文件是向后兼容的，不会影响在旧版 helm 中使用插件的行为。 `plugin.complete` 脚本的输出应该是以换行分隔的列表，例如： ```console rel1 rel2 rel3 ``` 当调用 `plugin.complete` 时，插件环境的设置与调用插件主脚本时相同。因此，变量 `$HELM_NAMESPACE`、`$HELM_KUBECONTEXT` 和所有其他插件变量都已设置，并且它们对应的全局标志会被移除。 `plugin.complete` 文件可以是任何可执行形式；它可以是 shell 脚本、Go 程序或任何其他 Helm 可以执行的程序。`plugin.complete` 文件 ***必须*** 对用户具有可执行权限。`plugin.complete` 文件 ***必须*** 以成功代码（值 0）退出。 在某些情况下，动态补全需要从 Kubernetes 集群获取信息。例如，`helm fullstatus` 插件需要 release 名称作为输入。在 `fullstatus` 插件中，它的 `plugin.complete` 脚本要提供当前 release 名称的补全，只需运行 `helm list -q` 并输出结果即可。 如果希望插件执行和插件补全使用相同的可执行文件，可以让 `plugin.complete` 脚本使用某些特殊参数或标志调用主插件可执行文件；当主插件可执行文件检测到特殊参数或标志时，它就知道要运行补全。在我们的例子中，`plugin.complete` 可以这样实现： ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` `fullstatus` 插件的实际脚本（`status.sh`）必须查找 `--complete` 标志，如果找到，则打印出正确的补全。 ### 提示和技巧 1. Shell 会自动过滤掉与用户输入不匹配的补全选项。因此，插件可以返回所有相关的补全，而不需要移除与用户输入不匹配的选项。例如，如果命令行是 `helm fullstatus ngin`，`plugin.complete` 脚本可以打印 *所有*（`default` 命名空间的）release 名称，而不仅仅是以 `ngin` 开头的；shell 只会保留以 `ngin` 开头的。 2. 为了简化动态补全支持，特别是如果你有一个复杂的插件，你可以让 `plugin.complete` 脚本调用你的主插件脚本并请求补全选项。参见上面的[动态补全](#动态补全)部分的例子。 3. 要调试动态补全和 `plugin.complete` 文件，可以运行以下命令查看补全结果： - `helm __complete `。例如： - `helm __complete fullstatus --output js`， - `helm __complete fullstatus -o json ""` ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/provenance.md ================================================ --- title: Helm 来源和完整性 description: 描述如何验证 chart 的完整性和来源。 sidebar_position: 5 --- Helm 提供了来源验证工具，帮助 chart 用户验证包的完整性和来源。使用基于 PKI、GnuPG 及流行包管理器的行业标准工具，Helm 可以生成和验证签名文件。 ## 概述 完整性是通过比较 chart 的来源记录来建立的。来源记录存储在 _来源文件_ 中，和打包好的 chart 放在一起。例如，如果有个名为 `myapp-1.2.3.tgz` 的 chart，则它的来源文件是 `myapp-1.2.3.tgz.prov`。 来源文件会在打包时生成（`helm package --sign ...`），并可以通过多个命令进行检查，尤其是 `helm install --verify`。 ## 工作流 本节描述如何有效使用来源数据的工作流。 前置条件： - 有效的二进制格式（非 ASCII-armored）的 PGP 密钥对 - `helm` 命令行工具 - GnuPG 命令行工具（可选） - Keybase 命令行工具（可选） **注意：** 如果你的 PGP 私钥有密码，系统会提示你为所有支持 `--sign` 选项的命令输入密码。 创建新的 chart 与之前一样： ```console $ helm create mychart Creating mychart ``` 准备好打包后，在 `helm package` 命令中添加 `--sign` 参数，并指定签名密钥的名称和包含相应私钥的密钥环： ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **注意：** `--key` 参数的值必须是对应密钥 `uid`（在 `gpg --list-keys` 输出中）的子字符串，例如名字或邮箱。**指纹码 _不能_ 使用。** **提示：** 对于 GnuPG 用户，你的私钥密钥环位于 `~/.gnupg/secring.gpg`。可以使用 `gpg --list-secret-keys` 列出你拥有的密钥。 **警告：** GnuPG v2 在默认位置 `~/.gnupg/pubring.kbx` 使用新格式 `kbx` 存储密钥环。请使用以下命令将密钥环转换为传统的 gpg 格式： ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` 此时，你应该同时看到 `mychart-0.1.0.tgz` 和 `mychart-0.1.0.tgz.prov` 两个文件。这两个文件最终都会被上传到对应的 chart 仓库。 可以使用 `helm verify` 验证 chart： ```console $ helm verify mychart-0.1.0.tgz ``` 验证失败的输出如下： ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` 在安装时同时验证，使用 `--verify` 参数： ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` 如果包含签名 chart 对应公钥的密钥环不在默认位置，需要使用 `--keyring PATH` 指定密钥环路径，与 `helm package` 示例类似。 如果验证失败，chart 的安装会在渲染前中止。 ### 使用 Keybase.io 凭据 [Keybase.io](https://keybase.io) 服务使得建立加密身份的信任链变得很容易。Keybase 凭据可以用于签名 chart。 前置条件： - 已配置的 Keybase.io 账户 - 本地已安装 GnuPG - 本地已安装 `keybase` CLI #### 对包签名 第一步是将 Keybase 密钥导入本地的 GnuPG 密钥环： ```console $ keybase pgp export -s | gpg --import ``` 这会将你的 Keybase 密钥转换成 OpenPGP 格式，然后导入到本地的 `~/.gnupg/secring.gpg` 文件。 可以运行 `gpg --list-secret-keys` 进行确认： ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` 注意你的密钥会有一个标识字符串： ``` technosophos (keybase.io/technosophos) ``` 这是密钥的完整名称。 然后，可以使用 `helm package` 打包和签名 chart。确保在 `--key` 参数中使用名称的一部分： ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` `package` 命令会同时生成 `.tgz` 文件和 `.tgz.prov` 文件。 #### 验证包 你也可以使用类似的方法验证由其他 Keybase 密钥签名的 chart。例如，你要验证由 `keybase.io/technosophos` 签名的包，可以使用 `keybase` 工具： ```console $ keybase follow technosophos $ keybase pgp pull ``` 第一个命令会关注用户 `technosophos`。然后 `keybase pgp pull` 会下载你关注的所有账户的 OpenPGP 密钥，并将它们放入 GnuPG 密钥环（`~/.gnupg/pubring.gpg`）。 此时，就可以使用 `helm verify` 或其他带 `--verify` 参数的命令： ```console $ helm verify somechart-1.2.3.tgz ``` ### chart 无法验证的原因 验证失败通常有以下原因： - `.prov` 文件缺失或损坏。这说明配置有误，或者原始维护者没有创建来源文件。 - 签名文件所用的密钥不在你的密钥环中。这说明签名 chart 的实体不是你已标记为信任的人。 - `.prov` 文件验证失败。这说明 chart 或来源数据本身有问题。 - 来源文件中的文件哈希与归档文件的哈希不匹配。这表明 chart 包已被篡改。 如果验证失败，就有理由不信任该包。 ## 来源文件 来源文件包含 chart 的 YAML 文件以及一些验证信息。来源文件会自动生成。 会添加以下来源数据： * chart 文件（`Chart.yaml`）包含在内，让人和工具都可以方便地查看 chart 的内容。 * chart 包（`.tgz` 文件）的签名（SHA256，类似 Docker）包含在内，可用于验证 chart 包的完整性。 * 整个文件体使用 OpenPGP 算法签名（参见 [Keybase.io](https://keybase.io)，一种使加密签名和验证更简单的新方式）。 这些内容的组合为用户提供以下保证： * 包本身没有被篡改（通过 `.tgz` 包的校验和）。 * 发布该包的实体是可知的（通过 GnuPG/PGP 签名）。 文件格式类似这样： ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` 注意 YAML 部分包含两个文档（用 `...\n` 分隔）。第一个文档是 `Chart.yaml` 的内容。第二个是校验和，即打包时文件名到该文件内容 SHA-256 摘要的映射。 签名块是标准的 PGP 签名，提供[防篡改](https://www.rossde.com/PGP/pgp_signatures.html)功能。 ## Chart 仓库 Chart 仓库是 Helm chart 的集中存储。 Chart 仓库必须能够通过 HTTP 请求提供来源文件，且来源文件必须与 chart 位于相同的 URI 路径下。 例如，如果包的基础 URL 是 `https://example.com/charts/mychart-1.2.3.tgz`，那么来源文件（如果存在）必须可以通过 `https://example.com/charts/mychart-1.2.3.tgz.prov` 访问。 从终端用户的角度来看，`helm install --verify myrepo/mychart-1.2.3` 应该同时下载 chart 和来源文件，无需额外的用户配置或操作。 ### 基于 OCI 的注册中心中的签名 将 chart 发布到[基于 OCI 的注册中心](/topics/registries.md)时，可以使用 [`helm-sigstore` 插件](https://github.com/sigstore/helm-sigstore/)将来源信息发布到 [sigstore](https://sigstore.dev/)。[如文档所述](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)，创建来源文件和使用 GPG 密钥签名的过程是相同的，但可以使用 `helm sigstore upload` 命令将来源信息发布到不可变的透明日志中。 ## 建立权威和真实性 在处理信任链系统时，建立签名者的权威性非常重要。简单来说，上述系统建立在你信任签名 chart 的人这一事实之上。这意味着你需要信任签名者的公钥。 Helm 的一个设计决策是 Helm 项目不会作为信任链中的必要一方。我们不想成为所有 chart 签名者的"证书颁发机构"，而是更倾向于去中心化模型，这也是我们选择 OpenPGP 作为基础技术的原因之一。因此，在建立权威性方面，我们在 Helm 2 中基本没有定义这一步骤（这一决定在 Helm 3 中延续）。 不过，对于有兴趣使用来源系统的人，我们有一些提示和建议： - [Keybase](https://keybase.io) 平台提供了一个公共的集中式信任信息仓库。 - 你可以使用 Keybase 存储你的密钥或获取其他人的公钥。 - Keybase 还有非常出色的文档。 - 虽然我们还没有测试过，但 Keybase 的"安全站点"功能可以用来托管 Helm chart。 - 基本思路是：官方"chart 审核人"使用他（她）的密钥签名 chart，然后将来源文件上传到 chart 仓库。 - 有人提出过一个想法：在仓库的 `index.yaml` 文件中包含有效签名密钥的列表。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/rbac.md ================================================ --- title: 基于角色的访问控制 description: 解释 Helm 如何与 Kubernetes 基于角色的访问控制交互。 sidebar_position: 11 --- 在 Kubernetes 中，向用户或应用程序特定的服务账户授予角色是确保应用程序在指定范围内运行的最佳实践。 有关服务账户权限的更多信息，请查看[官方 Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)。 从 Kubernetes 1.6 开始，基于角色的访问控制默认是启用的。RBAC 允许你根据组织中的用户及其角色来指定允许的操作类型。 有了 RBAC，你可以： - 授权特殊操作（创建集群范围内的资源，比如新角色）给管理员 - 限制用户在指定命名空间创建资源的能力（Pod、持久卷、Deployment），或者在集群范围内创建资源的能力（资源配额、角色、自定义资源定义） - 限制用户在特定命名空间或集群范围内查看资源的能力 本指南适用于希望限制用户与 Kubernetes API 交互范围的管理员。 ## 管理用户账户 所有 Kubernetes 集群有两类用户：Kubernetes 管理的服务账户和普通用户。 普通用户被认为是由外部独立服务管理的，例如管理员分发私钥、Keystone 或 Google 账户等用户存储、甚至是包含用户名和密码列表的文件。 在这方面，Kubernetes 没有表示普通用户账户的对象。普通用户无法通过 API 调用添加到集群中。 相反，服务账户是由 Kubernetes API 管理的用户。它们被绑定到指定的命名空间，并由 API 服务器自动创建或通过 API 调用手动创建。 服务账户绑定到一组作为 Secret 存储的凭据。这些凭据被挂载到 Pod 中，允许集群内进程与 Kubernetes API 交互。 API 请求要么绑定到普通用户或服务账户，要么被视为匿名请求。这意味着集群内或外部的每个进程——从人类用户在工作站上使用 `kubectl`， 到节点上的 kubelet，再到控制平面的成员——向 API 服务器发送请求时都必须进行身份验证，否则被视为匿名用户。 ## Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 在 Kubernetes 中，用户账户和服务账户只能查看和编辑被授权访问的资源。访问权限通过 Role 和 RoleBinding 授予。 Role 和 RoleBinding 绑定到特定的命名空间，授予用户查看和/或编辑该命名空间中 Role 允许访问的资源的能力。 在集群范围内，它们被称为 ClusterRole 和 ClusterRoleBinding。授予用户 ClusterRole 后，用户可以查看和/或编辑整个集群的资源。 查看和/或编辑集群范围的资源（命名空间、资源配额、节点）也需要 ClusterRole。 ClusterRole 可以通过在 RoleBinding 中引用来绑定到特定的命名空间。`admin`、`edit` 和 `view` 这些默认 ClusterRole 通常以这种方式使用。 Kubernetes 默认提供了一些 ClusterRole，它们旨在成为面向用户的角色。包括超级用户角色（`cluster-admin`）以及具有更细粒度访问权限的角色（`admin`、`edit`、`view`）。 | 默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` group | 允许超级用户访问任意资源并执行任意操作。在 ClusterRoleBinding 中使用时，它提供对集群和所有命名空间中每个资源的完全控制。在 RoleBinding 中使用时，提供对该 RoleBinding 所在命名空间中每个资源的完全控制，包括命名空间本身。 | `admin` | 无 | 允许管理员访问，旨在使用 RoleBinding 在命名空间中授权。如果在 RoleBinding 中使用，允许对命名空间中的大部分资源进行读写，包括在命名空间中创建 Role 和 RoleBinding。不允许对资源配额或命名空间本身进行写操作。 | `edit` | 无 | 允许对命名空间中大部分对象进行读写。不允许查看或修改 Role 或 RoleBinding。 | `view` | 无 | 允许对命名空间中大部分对象进行只读访问。不允许查看 Role 或 RoleBinding。由于存在权限升级风险，也不允许查看 Secret。 ## 使用 RBAC 限制用户账户的访问 现在我们了解了基于角色的访问控制的基础知识，让我们讨论一下管理员如何限制用户的访问范围。 ### 示例：授予用户特定命名空间的读写权限 要限制用户访问特定的命名空间，可以使用 `edit` 或 `admin` 角色。如果你的 chart 创建或使用 Role 和 RoleBinding，应该使用 `admin` ClusterRole。 另外，也可以使用 `cluster-admin` 访问权限创建 RoleBinding。在命名空间范围内授予用户 `cluster-admin` 访问权限，可以提供对该命名空间内每个资源的完全控制，包括命名空间本身。 在这个示例中，我们将使用 `edit` Role 创建一个用户。首先，创建一个命名空间： ```console $ kubectl create namespace foo ``` 现在在该命名空间中创建一个 RoleBinding，授予用户 `edit` 角色。 ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### 示例：授予用户集群范围内的读写权限 如果用户希望安装一个包含集群范围资源（命名空间、角色、自定义资源定义等）的 chart，则需要集群范围的写权限。 这需要授予用户 `admin` 或 `cluster-admin` 访问权限。 授予用户 `cluster-admin` 访问权限意味着他们可以访问 Kubernetes 中所有可用的资源，包括使用 `kubectl drain` 访问节点以及执行其他管理任务。 强烈建议考虑使用 `admin` 权限代替，或者创建一个针对其需求量身定制的自定义 ClusterRole。 ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### 示例：授予用户特定命名空间的只读权限 你可能已经注意到没有用于查看 Secret 的 ClusterRole。出于权限升级的考虑，`view` ClusterRole 不允许用户读取 Secret。Helm 默认将 release 元数据存储为 Secret。 为了让用户可以运行 `helm list`，他们需要能够读取这些 Secret。为此，我们需要创建一个特殊的 `secret-reader` ClusterRole。 创建 `cluster-role-secret-reader.yaml` 文件并写入以下内容： ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` 然后使用以下命令创建该 ClusterRole： ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` 完成后，我们可以授予用户对大多数资源的读权限，然后再授予他们读取 Secret 的权限： ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### 示例：授予用户集群范围的只读权限 在某些情况下，授予用户集群范围的访问权限是有益的。例如，如果用户想运行 `helm list --all-namespaces`， API 需要用户具有集群范围的读权限。 可以按照上述方式授予用户 `view` 和 `secret-reader` 访问权限，但使用 ClusterRoleBinding。 ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## 其他说明 上述示例使用了 Kubernetes 提供的默认 ClusterRole。如需对用户授予更细粒度的资源访问控制，请查看 [Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)了解如何创建自定义的 Role 和 ClusterRole。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/registries.md ================================================ --- title: 使用基于 OCI 的注册中心 description: 描述如何使用 OCI 进行 chart 的分发。 sidebar_position: 7 --- 从 Helm 3 开始，可以使用具有 [OCI](https://www.opencontainers.org/)支持的容器注册中心来存储和共享 chart 包。从 Helm v3.8.0 开始，默认启用 OCI 支持。 ## v3.8.0 版本之前对 OCI 的支持 OCI 支持在 Helm v3.8.0 版本从试验阶段过渡成为普遍可用。在之前版本中，OCI 支持会有不同的地方。如果你在 v3.8.0 之前的版本使用 OCI，需要着重了解不同Helm 版本之间 OCI 的变化。 ### 在 v3.8.0 之前的版本启用 OCI 支持 Helm v3.8.0 版本之前，OCI 支持是*试验性*的且必须显式启用。 为了在之前版本中启用 OCI 试验性支持，需要在环境变量中设置 `HELM_EXPERIMENTAL_OCI`，例如： ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### OCI 在 v3.8.0 中的弃用和行为变化 [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0) 版本中，以下行为和特性与之前版本不同： - 在依赖中将 chart 设置为 OCI 时，版本号可以像其他依赖一样设置成范围。 - 包含构建信息的SemVer tag 可以被推送和使用。OCI 注册中心的 tag 字符不支持 `+`。如果有，Helm 会将 `+` 转成 `_`。 - `helm registry login` 命令现在采用与 Docker CLI 相同的结构存储凭证。Helm 和 Docker CLI 的注册表配置使用一样的路径。 ### OCI 在 v3.7.0 中的弃用和行为变化 [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) 版本包含了针对支持 OCI 的 [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) 实现方案。因此以下行为和特性与之前版本不同： - 移除了 `helm chart` 子命令。 - 移除了 chart 缓存（没有了 `helm chart list` 等等）。 - OCI 注册引用现在需要以 `oci://` 开头。 - 注册引用的基础名称*必须*和 chart 名称匹配。 - 注册引用的tag*必须*和 chart 的语义版本匹配（比如没有 `latest` 这种 tag）。 - chart 层的媒体类型从 `application/tar+gzip`转换成了 `application/vnd.cncf.helm.chart.content.v1.tar+gzip`。 ## 使用基于 OCI 的注册中心 ### 基于 OCI 注册中心的 Helm 仓库 [Helm 仓库](./chart_repository.md)是一种制作和分发打包好的 Helm chart 的方式。基于 OCI 的注册中心包含零个或多个 Helm 仓库，且每个都会有零个或多个 Helm chart。 ### 使用托管的注册中心 以下是几种 chart 可以使用的托管容器注册中心，都支持 OCI，例如： - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) 参照托管平台提供的文档来创建和配置支持 OCI 的注册中心。 **注意：** 你可以在开发电脑上运行基于 OCI 的注册中心 [Docker Registry](https://docs.docker.com/registry/deploying/) 或者 [`zot`](https://github.com/project-zot/zot)。在开发电脑上运行只能用于测试目的。 ### 使用 sigstore 签名基于 OCI 的 chart [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) 插件支持使用 [Sigstore](https://sigstore.dev/) 签名 Helm chart，与签名容器镜像使用相同的工具。这为经典 [chart 仓库](./chart_repository.md)支持的[基于 GPG 的来源验证](./provenance.md)提供了替代方案。 有关 `helm sigstore` 插件的详细用法，请参阅[该项目的文档](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md)。 ## 用于处理注册中心的命令 ### `registry` 子命令 #### `login` 登录到注册中心 (手动输入密码) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` 从注册中心注销 ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### `push` 子命令 上传 chart 到基于 OCI 的注册中心： ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` `push` 子命令只能用于 `helm package` 提前创建的 `.tgz` 文件。 使用 `helm push` 上传 chart 到 OCI 注册表时，引用必须以 `oci://` 开头，且不能包含基础名称或 tag。 注册表引用的基础名称由 chart 名称推断而来，tag 由 chart 语义版本推断而来。这是强制要求。 某些注册表（如果指定）要求事先创建仓库或者命名空间，或者两者都需要创建。否则，`helm push` 会出现错误。 如果你已经创建了[来源文件](./provenance.md)（`.prov`），且与 `.tgz` 文件位于同一目录下，该文件会在 `push` 时自动上传到注册表，并在 [Helm chart manifest](#helm-chart-manifest) 中生成一个额外的层。 [helm-push plugin](https://github.com/chartmuseum/helm-push) 用户（用于上传 chart 到 [ChartMuseum](./chart_repository.md#chartmuseum-repository-server)）可能会遇到问题，因为该插件与内置的新 `push` 命令有冲突。从 v0.10.0 版本开始，该插件已更名为 `cm-push`。 ### 其他命令 对 `oci://` 协议的支持同样适用于很多其他子命令。以下是完整列表： - `helm pull` - `helm push` - `helm show` - `helm template` - `helm install` - `helm upgrade` 注册表的基础名称（chart name）*包含*了涉及 chart 下载的任意类型的操作（相对于 `helm push` 被省略的位置）。 下面是一些基于 OCI 的 chart 使用上述子命令的示例： ```console $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## 使用摘要安装 chart 使用摘要安装 chart 比使用 tag 更安全，因为摘要是不可变的。摘要在 chart URI 中指定： ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## 指定依赖项 chart 的依赖项可以从注册中心拉取，使用 `dependency update` 命令。 `Chart.yaml` 中给定的 `repository` 被指定为不含基础名称的注册表引用： ```yaml dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` 执行 `dependency update` 时会获取 `oci://localhost:5000/myrepo/mychart:2.7.0`。 ## Helm chart manifest 以下是在注册表中表示的 Helm chart manifest 示例（注意 `mediaType` 字段）： ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` 下面的示例包含一个[来源文件](./provenance.md)（注意额外层）： ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## 从 chart 仓库迁移 从经典 [chart 仓库](./chart_repository.md)（基于 index.yaml）的迁移非常简单，只需使用 `helm pull` 拉取 chart，然后使用 `helm push` 上传生成的 `.tgz` 文件到注册表即可。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/v2_v3_migration.md ================================================ --- title: 从 Helm v2 迁移到 v3 description: 了解如何将 Helm v2 迁移到 v3。 sidebar_position: 13 --- 本指南介绍如何将 Helm v2 迁移到 v3。在开始前，需要先安装 Helm v2 并在一个或多个集群中管理 release。 ## Helm 3 变更概述 Helm 2 到 Helm 3 的完整变更列表请参阅 [FAQ 部分](/faq/changes_since_helm2.md)。以下是用户在迁移之前和迁移期间应该注意的一些变更概述： 1. 移除了 Tiller： - 用 client/library 架构（仅 `helm` 二进制文件）替换了 client/server 架构 - 安全性现在基于单个用户（委托给 Kubernetes 用户集群安全机制） - release 现在作为集群内的 Secret 存储，且 release 对象的元数据格式也已更改 - release 现在按 release 命名空间持久化，不再存储在 Tiller 命名空间中 2. 更新了 Chart 仓库： - `helm search` 现在支持本地仓库搜索和对 Artifact Hub 的搜索查询 3. Chart apiVersion 升级到 "v2"，以支持以下规范变更： - 动态链接的 chart 依赖移至 `Chart.yaml`（移除了 `requirements.yaml`，requirements --> dependencies） - Library chart（辅助/通用 chart）现在可以作为动态链接的 chart 依赖添加 - Chart 有一个 `type` 元数据字段，用于定义 chart 类型是 `application` 还是 `library`。默认是 application，即可渲染和安装 - Helm 2 chart（apiVersion=v1）仍然可以安装 4. 添加了 XDG 目录规范： - Helm home 目录被移除，改用 XDG 目录规范来存储配置文件 - 不再需要初始化 Helm - 移除了 `helm init` 和 `helm home` 5. 其他变更： - Helm 安装/设置简化： - 仅需 Helm 客户端（helm 二进制文件）（无需 Tiller） - 开箱即用 - 不再默认设置 `local` 或 `stable` 仓库 - 移除了 `crd-install` hook，改用 chart 中的 `crds` 目录，其中定义的所有 CRD 将在渲染 chart 之前安装 - 移除了 `test-failure` hook 注解值，且 `test-success` 已弃用。请使用 `test` 代替 - 命令的删除/替换/新增： - delete --> uninstall：默认删除所有发布历史（之前需要 `--purge`） - fetch --> pull - home（已删除） - init（已删除） - install：需要 release 名称或 `--generate-name` 参数 - inspect --> show - reset（已删除） - serve（已删除） - template：`-x`/`--execute` 参数重命名为 `-s`/`--show-only` - upgrade：添加了 `--history-max` 参数，用于限制每个 release 保存的最大修订版本数（0 表示不限制） - Helm 3 Go 库经历了大量变更，与 Helm 2 库不兼容 - release 二进制文件现在托管在 `get.helm.sh` ## 迁移用例 迁移用例如下： 1. Helm v2 和 v3 管理同一集群： - 仅当你打算逐步淘汰 Helm v2 且不需要 v3 管理任何 v2 部署的 release 时，才建议使用此方案。所有新 release 都应通过 v3 部署，现有 v2 部署的 release 仅通过 v2 更新/删除 - Helm v2 和 v3 可以很好地管理同一集群。两个 Helm 版本可以安装在同一系统上，也可以安装在不同系统上 - 如果在同一系统上安装 Helm v3，需要执行额外步骤以确保两个客户端版本可以共存，直到准备好删除 Helm v2 客户端。重命名或将 Helm v3 二进制文件放在不同的文件夹中以避免冲突 - 除此之外，由于以下区别，两个版本之间不会产生冲突： - v2 和 v3 的 release（历史）存储是相互独立的。变更包括用于存储的 Kubernetes 资源和资源中包含的 release 对象元数据。release 将按用户命名空间存储，而不是 Tiller 命名空间（例如，v2 默认的 Tiller 命名空间是 kube-system）。v2 在 Tiller 命名空间中使用 "ConfigMaps" 或 "Secrets"，所有权为 `TILLER`。v3 在用户命名空间中使用 "Secrets"，所有权为 `helm`。release 在 v2 和 v3 中都是增量的 - 唯一可能出现的问题是，如果 chart 中定义了 Kubernetes 集群范围的资源（例如 `clusterroles.rbac`）。即使资源在命名空间中是唯一的，v3 部署也会因为资源冲突而失败 - v3 配置不再使用 `$HELM_HOME`，改用 XDG 目录规范。它还会按需动态创建。因此它独立于 v2 配置。这仅适用于两个版本安装在同一系统上的情况 2. 将 Helm v2 迁移到 Helm v3： - 此用例适用于你希望用 Helm v3 管理现有 Helm v2 release 的情况 - 需要注意的是 Helm v2 客户端： - 可以管理 1 个或多个 Kubernetes 集群 - 可以为一个集群连接 1 个或多个 Tiller 实例 - 这意味着在迁移时必须注意这一点，因为 release 是通过 Tiller 及其命名空间部署到集群中的。因此，你必须注意迁移 Helm v2 客户端实例所管理的每个集群和每个 Tiller 实例 - 推荐的数据迁移路径如下： 1. 备份 v2 数据 2. 迁移 Helm v2 配置 3. 迁移 Helm v2 release 4. 当确信 Helm v3 按预期管理所有 Helm v2 数据（针对 Helm v2 客户端实例的所有集群和 Tiller 实例）后，清理 Helm v2 数据 - 迁移过程可通过 Helm v3 的 [2to3](https://github.com/helm/helm-2to3) 插件自动完成 ## 参考 - Helm v3 [2to3](https://github.com/helm/helm-2to3) 插件 - [博客文章](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)：通过示例说明 `2to3` 插件的用法 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3/topics/version_skew.md ================================================ --- title: "Helm版本支持策略" description: "描述Helm的补丁发布策略，以及Helm和Kubernetes之间支持的最大版本偏差" --- 该文档描述了在Helm和Kubernetes之间支持的最大版本偏差。 ## 支持的版本 Helm的版本用 `x.y.z` 描述，`x`是主版本，`y`是次版本，`z`是补丁版本，遵循 [语义化版本](https://semver.org/spec/v2.0.0.html) 术语。 Helm项目维护了一个针对最近次要版本的发布分支。适当的修复（包括安全修复）会根据严重程度和可行性被cherry-pick到发布分支。更多细节请查看 [Helm 发布策略](/community/release_policy)。 ## 可支持的版本偏差 当一个Helm的新版本发布时，它是针对Kubernetes的一个特定的次版本编译的。比如，Helm 3.0.0 与Kubernetes的1.16.2的客户端版本交互，因此可以兼容Kubernetes 1.16。 从Helm 3开始，Helm编译时假定与`n-3`版本的Kubernetes兼容。由于Kubernetes各次版本之间存在变更，Helm 2的支持策略稍严格一些，假定与`n-1`版本的Kubernetes兼容。 例如，如果您在使用一个针对Kubernetes 1.17客户端API版本编译的Helm 3版本，那么它应该可以安全地使用Kubernetes 1.17， 1.16，1.15，以及1.14。如果您在使用一个针对Kubernetes 1.16客户端API版本编译的Helm 2版本，那么它应该可以安全地使用 Kubernetes 1.16 和 1.15。 不推荐将Helm用于比编译它所依赖的版本更高的Kubernetes版本，因为Helm并没有做出任何向前兼容的保证。 如果您选择将Helm用于不支持的Kubernetes版本，需自负风险。 请参考下表来确定哪个版本的Helm与您的集群兼容。 | Helm 版本 | 支持的 Kubernetes 版本 | |--------------|-------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs/version-3.json ================================================ { "version.label": { "message": "3.19.0", "description": "The label for version 3" }, "sidebar.tutorialSidebar.category.Introduction": { "message": "介绍", "description": "The label for category Introduction in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.How-to": { "message": "操作指南", "description": "The label for category How-to in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Topics": { "message": "主题", "description": "The label for category Topics in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Best Practices": { "message": "最佳实践", "description": "The label for category Best Practices in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Chart Template Guide": { "message": "Chart 模板指南", "description": "The label for category Chart Template Guide in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Helm Commands": { "message": "Helm 命令", "description": "The label for category Helm Commands in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Go SDK": { "message": "Go SDK", "description": "The label for category Go SDK in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Community": { "message": "社区", "description": "The label for category Community in sidebar tutorialSidebar" }, "sidebar.tutorialSidebar.category.Frequently Asked Questions": { "message": "常见问题", "description": "The label for category Frequently Asked Questions in sidebar tutorialSidebar" } } ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/developers.md ================================================ --- title: 开发者指南 description: 开发Helm的环境设置说明。 sidebar_position: 1 --- 该指南说明如何为开发Helm配置环境。 ## 先决条件 - Go最新版本 - Kubernetes集群及kubectl（可选） - Git ## 构建 Helm 我们使用Make构建程序。最简单的开始方式是： ```console $ make ``` 有必要的话要先安装依赖，并验证配置。然后会编译 `helm` 并将其放到 `bin/helm`。 在本地执行Helm，可以执行 `bin/helm`。 - Helm运行在 macOS 和大多数发行版上，包括 Alpine。 ## 执行测试 要运行所有测试，执行 `make test`。作为先决条件，需要安装 [golangci-lint](https://golangci-lint.run)。 ## 贡献指南 我们欢迎你的贡献。 该项目已经设置了一些指南，为了保证 (a) 代码的高质量，(b) 保持项目一致， (c) 贡献遵循开源法律要求。我们的目的不是为贡献者增加负担，但是要构建优雅和高质量的开源代码， 这样我们的用户才能从中受益。 确保你已经阅读并理解主要贡献指南： ### 代码结构 Helm项目的代码组织如下： - 独立的程序位于 `cmd/`。`cmd/` 中的代码不是为库复用设计的。 - 共享的库放在 `pkg/`。 - `scripts/` 目录包含很多实用程序脚本。大多数用于CI/CD流水线。 Go依赖管理在不断变化，而且在Helm生命周期中很可能发生变化。我们建议开发者 _不要_ 手动管理依赖。 而是建议依靠项目的 `Makefile` 来处理。使用Helm 3时，建议使用Go 1.13及更新版本。 ### 编写文档 从Helm 3开始，文档已经移动到了它自己的仓库中。当编制新特性时，请编写随附文档并提交到 [helm-www](https://github.com/helm/helm-www) 仓库。 有个例外：[Helm CLI 输出 (英文)](/docs/helm) 是 `helm` 程序自己生成的。 查看 [更新Helm CLI参考文档](https://github.com/helm/helm-www#updating-the-helm-cli-reference-docs) 来了解如何生成该输出。翻译后，不会生成CLI输出，但可以在 `/content//docs/helm` 中找到。 ### Git 约定 我们使用Git作为版本控制系统。 `main` 分支是当前开发候选分支。发布版本会打tag。 我们通过GitHub的Pull Requests(PRs)接受更改。操作工作流如下： 1. Fork `github.com/helm/helm` 仓库到自己的GitHub账户 2. `git clone` 这个仓库到你想要的目录。 3. 创建一个新分支(`git checkout -b feat/my-feature`) 并在新分支上开发。 4. 当你准备好待审查代码时，将分支推送到GitHub，并开一个新的pull request 给我们。 对于Git提交信息，我们遵循 [语义化提交信息](https://karma-runner.github.io/0.13/dev/git-commit-msg.html)： ```shell fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` 常见提交类型： - fix: 修复bug或错误 - feat: 添加新特性 - docs: 更新文档 - test: 完善测试 - ref: 重构现有代码 通用范围： - helm: Helm CLI - pkg/lint: lint包。对任意包都遵循类似的约定 - `*`: 两个或更多范围 了解更多： - 灵感来源于 [Deis指南](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md)。 - Karma Runner [定义](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) 了语义提交信息的观点。 ### Go 约定 我们非常严格地遵守Go编码风格标准。典型方式是，执行 `go fmt` 可以让代码更加整洁。 我们通常也通过`go lint` 和`gometalinter`遵循推荐的约定。执行 `make test-style` 来测试风格一致性。 了解更多： - 有效的Go[引入格式](https://golang.org/doc/effective_go.html#formatting)。 - Go Wiki有关于[formatting](https://github.com/golang/go/wiki/CodeReviewComments)很棒的文章。 如果运行`make test`，不仅单元测试会执行，格式测试也会自执行。如果 `make test`失败，即使是因为格式方面的原因， 你的PR也不会被合并。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/history.mdx ================================================ --- title: 项目历史 description: 提供项目历史的高级概述。 sidebar_position: 4 --- import Helm4 from "/docs/_v4-in-progress.mdx" Helm 是[CNCF](https://www.cncf.io/projects/)的[毕业项目](https://helm.sh/blog/celebrating-helms-cncf-graduation/)。 Helm 开始时被称为[Helm Classic](https://github.com/helm/helm-classic)，始于2015年的Deis项目并在KubeCon会议中被提出。 2016年1月，该项目与名为Kubernetes部署管理器的GCS工具合并，并移动到了[Kubernetes](https://kubernetes.io)中。 由于代码的合并，Helm 2.0于当年晚些时候发布。在Helm 2中保留的部署管理的关键特性是服务端组件， Helm 2.0最终的发布版本中DM重命名为了Tiller。 Helm于2018年6月从Kubernetes子项目晋升为CNCF的成熟项目。Helm组建了一个顶级的管理机构并在Helm项目中包含了几个子项目， 包括Monocular，Helm Chart仓库，Chart博物馆，以及后来的Helm Hub。 当Helm 3开发周期开始时，移除了Tiller，使其更接近于作为客户工具最初愿景。但Helm 3继续跟踪Kubernetes集群内部的版本， 使团队可以共同完成一个公共的Helm发布版本。Helm 3于2019年11月发布。 Helm [于2020年4月成为CNCF的毕业项目](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)。 CNCF的[Artifact Hub](https://artifacthub.io)在2020年10月份替换了[Helm Hub](https://hub.helm.sh)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/localization.md ================================================ --- title: 本地化Helm文档 description: 本地化Helm文档的说明。 sidebar_position: 5 --- 本指南介绍如何本地化Helm文档。 ## 入门 翻译工作使用与文档稿件相同的过程。翻译通过[pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) 提供给 [helm-www](https://github.com/helm/helm-www) 仓库并由管理站点的团队审查。 ### 双字母语言代码 语言代码文档由[ISO 639-1标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)组织。 比如，韩国的双字母代码是 `ko`。 在内容和配置中可以找到使用的语音码。三个例子如下： - `content` 目录中的子目录以语言码命名且本地化内容在对应的目录中。 主要在每个语言码目录的 `docs`子目录中。 - `i18n`目录包含一个网站使用的每种语言的配置文件。文件按照 `[LANG].toml` 形式命名，`[LANG]` 是双字母语言码。 - 顶层`config.toml`文件中，有按语言码组织的导航和其他详细信息的配置。 英文使用语言码 `en`，是翻译的默认语言和资源。 ### Fork, Branch, Change, Pull Request 贡献翻译从[helm-www仓库](https://github.com/helm/helm-www) [创建fork](https://help.github.com/en/github/getting-started-with-github/fork-a-repo)开始。在你的fork中提交更改。 默认情况下，fork将在名为master的默认分支上工作。请使用分支提交更改并创建pull requests。如果你不熟悉分支，可以 [阅读GitHub文档](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-branches)。 一旦有了分支，就可以添加翻译，将内容本地化为一种语言。 注意，Helm使用一个[Developers Certificate of Origin](https://developercertificate.org/)。 所有的提交需要signoff。提交时可以使用 `-s` 或 `--signoff` 参数使用你Git配置的用户和邮箱签署这个提交。 更多细节请查看 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md#sign-your-work) 文件。 准备好之后，创建一个 [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) 将翻译提交到helm-www仓库。 一旦创建了pull request，维护者会进行审查。过程细节查看 [CONTRIBUTING.md](https://github.com/helm/helm-www/blob/main/CONTRIBUTING.md)。 ## 翻译内容 本地化所有的Helm内容是一项巨大的任务。开始很小的改动是可以的。翻译会随着时间扩展。 ### 开始一个新语言 开始新语言时有些最低要求，包括： - 添加`content/[LANG]/docs`目录，包含`_index.md` 文件。这是顶层的文档落地页。 - `[LANG].toml` 文件在`i18n`目录中。可以复制`en.toml`文件作为起点。 - 在 `config.toml`文件中添加一部分用于展示新语言。可以用已有语言作为起点。 ### 翻译 已翻译内容需要保留在 `content/[LANG]/docs` 目录中。应该有相同的URL作为英文源。 比如，将intro翻译为韩文时拷贝英文是有用的： ```sh mkdir -p content/ko/docs/intro cp content/en/docs/intro/install.md content/ko/docs/intro/install.md ``` 这个新文件中的内容可以翻译成其他语言。 不要在`content/[LANG]/`中添加未翻译的英文文件拷贝。语言存在之后，任何未翻译的页面 都会自动重定向到英文。翻译需要时间，应该翻译最新版本的文档，而不是过时的fork。 确保从头部删除`aliases`行。像 `aliases: ["/docs/using_helm/"]` 不属于翻译。 这些是旧链接的重定向，新页面不存在这些链接。 注意翻译工具可以帮助完成这个过程。包括机器翻译内容。机器翻译内容在发布之前应该由说母语的人编辑或者审查语法和语义。 ## 在语言之间切换 ![Screen Shot 2020-05-11 at 11 24 22 AM](https://user-images.githubusercontent.com/686194/81597103-035de600-937a-11ea-9834-cd9dcef4e914.png) 站点全局 [config.toml](https://github.com/helm/helm-www/blob/main/config.toml#L83L89) 文件可以配置语言导航。 添加新语言，可以使用上面定义的双字母语言码添加一组参数。比如： ```toml # Korean [languages.ko] title = "Helm" description = "Helm - The Kubernetes Package Manager." contentDir = "content/ko" languageName = "한국어 Korean" weight = 1 ``` ## 解析内部链接 翻译的内容有时会包含跳转到其他页面的链接，但只存在于其他语言中。就会出现 [build errors](https://app.netlify.com/sites/helm-merge/deploys)。比如： ```shell 12:45:31 PM: htmltest started at 12:45:30 on app 12:45:31 PM: ======================================================================== 12:45:31 PM: ko/docs/chart_template_guide/accessing_files/index.html 12:45:31 PM: hash does not exist --- ko/docs/chart_template_guide/accessing_files/index.html --> #basic-example 12:45:31 PM: ✘✘✘ failed in 197.566561ms 12:45:31 PM: 1 error in 212 documents ``` 为了解决这个问题，你需要检查翻译中的内部链接。 - 锚点链接需要反映翻译的 `id` 值 - 内部页面链接需要修复 对于不存在的内部页， _(或者还未被翻译的)_，站点不会构建，直到修复错误。应急的话可以指向 另一个已经存在的语言： `< relref path="/docs/topics/library_charts.md" lang="en" >` 查看 [语言之间的交叉引用](https://gohugo.io/content-management/cross-references/#link-to-another-language-version) 获取更多信息。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/related.md ================================================ --- title: 相关项目及文档 description: 社区提供的第三方工具，插件以及文档！ sidebar_position: 3 --- Helm社区已经创建了很多针对Helm的额外工具，插件和文档。我们乐于听到这些项目声音。 如果你有什么需要补充到这里的话，请创建一个 [issue](https://github.com/helm/helm-www/issues) 或者 [pull request](https://github.com/helm/helm-www/pulls)。 ## Helm 插件 {#helm-plugins} - [helm-adopt](https://github.com/HamzaZo/helm-adopt) - 将现有k8s资源转换成新生成的helm chart的helm v3插件。 - [Helm Diff](https://github.com/databus23/helm-diff) - `helm upgrade`的彩色diff预览 - [Helm Dashboard](https://github.com/komodorio/helm-dashboard) - Helm的GUI界面，可视化release、repository及manifest的差异 - [helm-gcs](https://github.com/hayorov/helm-gcs) - 管理Google Cloud Storage中仓库的插件 - [helm-git](https://github.com/aslafy-z/helm-git) - 从Git仓库中安装chart并检索values文件。 - [helm-k8comp](https://github.com/cststack/k8comp) - 使用k8comp从hiera创建Helm Charts的插件 - [helm-mapkubeapis](https://github.com/helm/helm-mapkubeapis) - 更新helm发布版本元数据用于替换过期或已移除的k8s API - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - 基于 Prometheus/ElasticSearch的用于监控版本发布和回滚的插件 - [helm-release-plugin](https://github.com/JovianX/helm-release-plugin) - 该插件用于管理已部署的release，更新release值，拉取（重建）helm chart，以及设置helm release TTL。 - [helm-s3](https://github.com/hypnoglow/helm-s3) - 允许使用AWS S3作为[私有]chart仓库的插件 - [helm-secrets](https://github.com/jkroepke/helm-secrets) - 安全存储密钥的插件 （基于[sops](https://github.com/mozilla/sops)） - [helm-sigstore](https://github.com/sigstore/helm-sigstore) - Helm集成[sigstore](https://sigstore.dev/)生态的插件。 用于搜索、上传及验证已签名的Helm chart。 - [helm-tanka](https://github.com/Duologic/helm-tanka) - 在Helm chart中渲染Tanka/Jsonnet的插件 - [hc-unit](https://github.com/xchapter7x/hcunit) - 使用OPA (Open Policy Agent) 和 Rego本地进行chart单元测试的插件 - [helm-unittest](https://github.com/helm-unittest/helm-unittest) - 使用YAML本地进行chart单元测试的插件 - [helm-val](https://github.com/HamzaZo/helm-val) - 从之前的版本中获取值的插件 - [helm-external-val](https://github.com/kuuji/helm-external-val) - 从外部资源（configMaps， Secrets等）获取Helm values的插件 我们同样鼓励使用GitHub的各位使用[helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) 给插件仓库打tag。 ## 额外工具 Helm的顶层工具。 - [Armada](https://airshipit.readthedocs.io/projects/armada/en/latest/) - 管理各种Kubernetes命名空间中的前缀版本，并删除复杂部署的已完成作业 - [avionix](https://github.com/zbrookle/avionix) - 生成Helm chart和Kubernetes yaml的Python接口，允许继承及更少的代码重复 - [Botkube](https://botkube.io) - 直接从Slack,Discord, Microsoft Teams, 和Mattermost运行Helm命令。 - [Captain](https://github.com/alauda/captain) - 使用HelmRequest和Release CRD的Helm 3控制器 - [Chartify](https://github.com/appscode/chartify) - 从已经存在的Kubernetes资源中生成Helm chart。 - [ChartMuseum](https://github.com/helm/chartmuseum) - 支持 Amazon S3 和Google云存储的Helm Chart仓库 - [chart-registry](https://github.com/hangyan/chart-registry) - 在OCI注册表上的Helm chart主机 - [Codefresh](https://codefresh.io) - 带有UI界面的管理Helm chart和版本的Kubernetes原生CI/CD及管理平台 - [Flux](https://fluxcd.io/docs/components/helm/) - 从Git到Kubernetes的连续和渐进交付 - [Helmfile](https://github.com/helmfile/helmfile) - Helmfile是用于部署helm chart的声明性规范 - [Helmsman](https://github.com/Praqma/helmsman) - Helmsman是helm-charts-as-code工具， 可以从版本控制所需的状态文件（以简单的TOML格式描述）安装、升级、保护、移动及删除发布版本。 - [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - 为HashiCorp Terraform提供Helm， 以声明性的结构作为代码的语法实现Helm Chart的生命周期管理。Helm提供者通常与其他Terraform提供者配对， 类似于Kubernetes提供者，创建一个横跨所有基础服务的通用工作流。 - [K8Studio](https://k8studio.io) - 用于管理 Kubernetes 集群的桌面 UI，集成 Helm 管理器。 - [Konveyor Move2Kube](https://konveyor.io/move2kube/) -为现有项目生成Helm chart。 - [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper获取一组具有值（所需状态）的Helm hart引用，并在Kubernetes集群中实现。" - [Monocular](https://github.com/helm/monocular) - Helm仓库的WEB UI界面。 - [Monokle](https://monokle.io) - 桌面工具，用于创建、调试和部署Kubernetes资源和Helm Chart。 - [Orkestra](https://azure.github.io/orkestra/) - 针对一组相关的Helm版本及子chart的云原生编排和生命周期管理平台（LCM）。 - [Tanka](https://tanka.dev/helm) - Grafana Tanka通过具有使用Helm Chart能力的Jsonnet配置Kubernetes资源 - [Terraform Helm Provider](https://github.com/hashicorp/terraform-provider-helm) - HashiCorp Terraform的Helm provider，支持使用声明性代码语法对Helm Chart进行生命周期管理。 该Helm provider通常与其他Terraform provider配对，比如Kubernetes provider，用于创建跨越所有基础服务的通用工作流。 - [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - Kubernetes和Helm的VIM插件 ## Helm 已含的 Helm支持的平台，发行版本和服务。 - [Kubernetic](https://kubernetic.com/) - Kubernetes桌面客户端 - [Jenkins X](https://jenkins-x.io/) - 使用Helm的Kubernetes开源自动化CI/CD [promoting](https://jenkins-x.io/docs/getting-started/promotion/) 通过GitOps实现的环境应用程序 ## Misc 为Chart作者和Helm用户准备的一些有用的东西。 - [Await](https://github.com/saltside/await) - Docker镜像“等待”不同的条件——对初始化容器尤其有用。 [更多信息](https://blog.slashdeploy.com/2017/02/16/introducing-await/)。 ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/release_checklist.md ================================================ --- title: 版本 Checklist description: 维护人员在发布下一个Helm版本时的checklist。 sidebar_position: 2 --- # 维护人员发布Helm指南 是时候发布新的Helm了！作为Helm维护者发布版本，如果你的经验与这里的文档不同，那你就是 更新版本checklist 的最佳人选。 所有版本都将采用vX.Y.Z的形式，X是主版本号，Y是次版本号，Z是补丁发布号。该项目严格遵守 [语义化版本](https://semver.org/)， 因此遵循这一点非常重要。 Helm会提前宣布下个次版本发布的日期。应尽一切努力遵守宣布的日期。此外，在开始发布过程时，应该选择下一个发布的日期在发布过程中使用。 这些说明将涵盖三种不同版本的遵守发布过程的初始配置： - 主版本 - 发布频率较低 - 有重大更新时 - 次版本 - 每3到4个月发布 - 无重大更新 - 补丁版本 - 每月发布 - 不需要指南中的所有步骤 [初始化配置](#initial-configuration) 1. [创建发布分支](#1-create-the-release-branch) 2. [主/次版本：在Git中更改版本号](#2-majorminor-releases-change-the-version-number-in-git) 3. [主/次版本：提交并推送发布分支](#3-majorminor-releases-commit-and-push-the-release-branch) 4. [主/次版本：创建一个候选发布](#4-majorminor-releases-create-a-release-candidate) 5. [主/次版本：迭代连续的候选版本](#5-majorminor-releases-iterate-on-successive-release-candidates) 6. [完成发布](#6-finalize-the-release) 7. [编写发布日志](#7-write-the-release-notes) 8. [PGP签名下载](#8-pgp-sign-the-downloads) 9. [发布版本](#9-publish-release) 10. [更新文档](#10-update-docs) 11. [告知社区](#11-tell-the-community) ## Initial Configuration ### 设置远程Git 需要注意的是该文档假设你的远程upstream仓库关联到了。 如果不是（比如，如果你选择了“origin”或其他类似的替代），请确保根据本地环境调整列出的代码段。 如果你不确定使用了什么远程的upstream，使用`git remote -v`命令查看。 如果你没有[上游远程](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)， 可以类似这样添加： ```shell git remote add upstream git@github.com:helm/helm.git ``` ### 设置环境变量 在该文档中，我们还会引用一些环境变量，更便于设置。针对主、次版本，使用以下选项： ```shell export RELEASE_NAME=vX.Y.0 export RELEASE_BRANCH_NAME="release-X.Y" export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.1" ``` 如果你在创建一个补丁版本，改用以下命令： ```shell export PREVIOUS_PATCH_RELEASE=vX.Y.Z export RELEASE_NAME=vX.Y.Z+1 export RELEASE_BRANCH_NAME="release-X.Y" ``` ### 设置签名Key 我们还会通过对二进制文件和提供的签名文件进行哈希计算增加发布过程的安全性和认证。 使用[GitHub 和 GPG](https://help.github.com/en/articles/about-commit-signature-verification)来执行。 如果还没设置GPG可以按照以下步骤操作： 1. [安装 GPG](https://gnupg.org/index.html) 2. [生成 GPG key](https://help.github.com/en/articles/generating-a-new-gpg-key) 3. [将key添加到GitHub账户中](https://help.github.com/en/articles/adding-a-new-gpg-key-to-your-github-account) 4. [在Git中设置签名密钥](https://help.github.com/en/articles/telling-git-about-your-signing-key) 一旦你有了签名密钥，需要将其添加到仓库根目录中的KEYS文件中。文件中有添加密钥到KEY文件的说明。如果还没有，需要将公钥添加到keyserver。 如果使用了GnuPG，可以参照[Debian提供的说明](https://debian-administration.org/article/451/Submitting_your_GPG_key_to_a_keyserver)。 ## 1. Create the Release Branch ### 主、次版本 主版本是为新特性及操作且*不具有向后兼容性*。次版本是为了不破坏向后兼容性的新特性。创建一个主版本或次版本，从主干分支创建`release-X.Y`分支。 ```shell git fetch upstream git checkout upstream/main git checkout -b $RELEASE_BRANCH_NAME ``` 这个新分支是发布版本的基础分支，会在后面不断迭代。 为GitHub上已存在的版本验证[helm/helm里程碑](https://github.com/helm/helm/milestones)。 确保针对这个版本的PR和issue都在这个里程碑中。 针对主版本和次版本，跳转到 2: [主/次版本：在Git中更改版本号](#2-majorminor-releases-change-the-version-number-in-git)。 ### 补丁版本 补丁版本是一些已有版本中严格的cherry-picked修复。以创建`release-X.Y`分支开始： ```shell git fetch upstream git checkout -b $RELEASE_BRANCH_NAME upstream/$RELEASE_BRANCH_NAME ``` 在这里可以cherry-pick出需要带到补丁版本中的提交： ```shell # get the commits ids we want to cherry-pick git log --oneline # cherry-pick the commits starting from the oldest one, without including merge commits git cherry-pick -x ``` 挑出提交之后这个版本分支需要被推送。 ```shell git push upstream $RELEASE_BRANCH_NAME ``` 推送分支会触发测试。创建tag之前确保测试是通过的。 这个新tag将成为补丁版本的基础。 针对补丁版本，创建[helm/helm里程碑](https://github.com/helm/helm/milestones)是可选的。 继续之前确保[helm 在 GitHub Actions](https://github.com/helm/helm/actions)通过CI。补丁版本可以跳过2-5步， 直接执行6 [完成发布](#6-finalize-the-release)。 ## 2. Major/Minor releases: Change the Version Number in Git 当有主版本或次版本发布时，确保用新版本更新`internal/version/version.go`。 ```shell $ git diff internal/version/version.go diff --git a/internal/version/version.go b/internal/version/version.go index 712aae64..c1ed191e 100644 --- a/internal/version/version.go +++ b/internal/version/version.go @@ -30,7 +30,7 @@ var ( // Increment major number for new feature additions and behavioral changes. // Increment minor number for bug fixes and performance enhancements. // Increment patch number for critical fixes to existing releases. - version = "v3.3" + version = "v3.4" // metadata is extra build time data metadata = "" ``` 除了在`version.go`文件中更行版本，还需要更新使用了新版本的相关测试。 - `cmd/helm/testdata/output/version.txt` - `cmd/helm/testdata/output/version-client.txt` - `cmd/helm/testdata/output/version-client-shorthand.txt` - `cmd/helm/testdata/output/version-short.txt` - `cmd/helm/testdata/output/version-template.txt` - `pkg/chartutil/capabilities_test.go` ```shell git add . git commit -m "bump version to $RELEASE_NAME" ``` 这只会对$RELEASE_BRANCH_NAME更新。也许要在下个版本更新时推送到主干分支，就像 [3.2 更新到 3.3](https://github.com/helm/helm/pull/8411/files)，并将其添加到下一个版本的里程碑中。 ```shell # get the last commit id i.e. commit to bump the version git log --format="%H" -n 1 # create new branch off main git checkout main git checkout -b bump-version- # cherry pick the commit using id from first command git cherry-pick -x # commit the change git push origin bump-version- ``` ## 3. Major/Minor releases: Commit and Push the Release Branch 为了让他人开始测试，我们可以推送发布分支到upstream并开始测试过程。 ```shell git push upstream $RELEASE_BRANCH_NAME ``` 继续之前确保 [helm 在GitHub Actions](https://github.com/helm/helm/actions)版本通过CI。 如果有人可用，让其他人在确保所有更改都已正确处理且所有该版本的提交都已存在，并提前对分支进行同行评审。 ## 4. Major/Minor releases: Create a Release Candidate 现在，发布分支已经准备好了，可以开始创建和迭代候选版本了。 ```shell git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` GitHub Actions 会自动创建一个打tag的发布镜像，同时测试客户端库。 对测试人员来说，在GitHub Actions完成测试构建过程之后开始测试，包括以下步骤来获取客户端： linux/amd64, 使用 /bin/bash: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-linux-amd64.tar.gz ``` darwin/amd64, 使用 Terminal.app: ```shell wget https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-darwin-amd64.tar.gz ``` windows/amd64, 使用 PowerShell: ```shell PS C:\> Invoke-WebRequest -Uri "https://get.helm.sh/helm-$RELEASE_CANDIDATE_NAME-windows-amd64.tar.gz" -OutFile "helm-$ReleaseCandidateName-windows-amd64.tar.gz" ``` 然后，将二进制包解压并移动到$PATH目录中，或者移动到某个位置并添加$PATH（比如linux/macOS的/usr/local/bin/helm，windows的 C:\Program Files\helm\helm.exe for Windows）。 ## 5. Major/Minor releases: Iterate on Successive Release Candidates 花了几天时间和资源去尝试用各种方式破坏helm，将所有的相关发现都记录到发布中。这段时间应该花在测试和寻找发行版可能导致各种特性或升级环境出现问题的方法上， 不要编码。这段时间发布版本应该冻结代码，且任何要添加的代码更新都推到下个发布版本中。 这个阶段，$RELEASE_BRANCH_NAME 会随着你新产生的候选发布不断发展。新候选的频率取决于发布管理员：依据报告问题的严重性、 测试人员效率和发布期限做出最佳判断。一般来说，即使跨过最后期限也不能发布坏版本。 在每次创建新的候选发布时，需要以添加从主干分支检出的commit开始： ```shell git cherry-pick -x ``` 你也需要推送这个分支到GitHub并保证通过CI。 然后打tag并通知用户有新的候选版本了： ```shell export RELEASE_CANDIDATE_NAME="$RELEASE_NAME-rc.2" git tag --sign --annotate "${RELEASE_CANDIDATE_NAME}" --message "Helm release ${RELEASE_CANDIDATE_NAME}" git push upstream $RELEASE_CANDIDATE_NAME ``` 一旦推送到了GitHub，检查分支确保tag在CI中构建。 从这里重复这个过程，持续测试直到你对候选发布满意为止。对于发布候选，我们不写完整的记录，但可以写一下 [发布日志](#7-write-the-release-notes)。 ## 6. Finalize the Release 当你最终对自己的候选发布的质量感到满意时，可以继续并创建一个真正的发布。 最后再检查一次确保一切正常，最后推送这个发布的tag。 ```shell git checkout $RELEASE_BRANCH_NAME git tag --sign --annotate "${RELEASE_NAME}" --message "Helm release ${RELEASE_NAME}" git push upstream $RELEASE_NAME ``` 在[GitHub Actions](https://github.com/helm/helm/actions)中验证发布是否成功。如果不行，需要修复这个版本并重新推送。 由于CI作业需要运行一段时间，你可以在等待其完成时去写发布日志。 ## 7. Write the Release Notes 我们会根据发布周期提交的记录自动生成一个更新日志，但是，如果发布说明是由人或市场团队手写的，通常对最终用户会更有利。 如果你在发布一个主或次版本，一般列出值得注意的面向用户的特性就足够了。对于补丁版本同样，但要标记出问题和会受影响的人。 发布日志应该包含版本号和下一个版本的计划发布日期。 针对次要版本的发布日志示例如下： ```markdown ## vX.Y.Z Helm vX.Y.Z is a feature release. This release, we focused on . Users are encouraged to upgrade for the best experience. The community keeps growing, and we'd love to see you there! - Join the discussion in [Kubernetes Slack](https://kubernetes.slack.com): - `#helm-users` for questions and just to hang out - `#helm-dev` for discussing PRs, code, and bugs - Hang out at the Public Developer Call: Thursday, 9:30 Pacific via [Zoom](https://zoom.us/j/696660622) - Test, debug, and contribute charts: [Artifact Hub helm charts](https://artifacthub.io/packages/search?kind=0) ## Notable Changes - Kubernetes 1.16 is now supported including new manifest apiVersions - Sprig was upgraded to 2.22 ## Installation and Upgrading Download Helm X.Y. The common platform binaries are here: - [MacOS amd64](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-darwin-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux amd64](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-amd64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux arm](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm.tar.gz.sha256) / CHECKSUM_VAL) - [Linux arm64](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-arm64.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux i386](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-386.tar.gz.sha256) / CHECKSUM_VAL) - [Linux ppc64le](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-ppc64le.tar.gz.sha256sum) / CHECKSUM_VAL) - [Linux s390x](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz) ([checksum](https://get.helm.sh/helm-vX.Y.Z-linux-s390x.tar.gz.sha256sum) / CHECKSUM_VAL) - [Windows amd64](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip) ([checksum](https://get.helm.sh/helm-vX.Y.Z-windows-amd64.zip.sha256sum) / CHECKSUM_VAL) The [Quickstart Guide](/intro/quickstart.md) will get you going from there. For **upgrade instructions** or detailed installation notes, check the [install guide](/intro/install.md). You can also use a [script to install](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3) on any system with `bash`. ## What's Next - vX.Y.Z+1 will contain only bug fixes and is planned for . - vX.Y+1.0 is the next feature release and is planned for . This release will focus on ... ## Changelog - chore(*): bump version to v2.7.0 08c1144f5eb3e3b636d9775617287cc26e53dba4 (Adam Reese) - fix circle not building tags f4f932fabd197f7e6d608c8672b33a483b4b76fa (Matthew Fisher) ``` 通过运行以下命令可以创建一组包括更新日志的部分完成的发行说明： ```shell export VERSION="$RELEASE_NAME" export PREVIOUS_RELEASE=vX.Y.Z make clean make fetch-dist make release-notes ``` 这回生成一个发行日志的良好基线，你仅仅需要填写 **Notable Changes** 和 **What's next** 部分。 可以在发布日志中随意添加你想说的，对用户来说会很好而不至于感觉我们是机器人。 你也需要再次检查自动生成的日志中的URL和校验和。 完成之后，去GitHub的 [helm/helm releases](https://github.com/helm/helm/releases) 中为已打tag的版本编辑发布说明。对于目标分支，设置$RELEASE_BRANCH_NAME。 现在需要让其他人在发行版本发布之前看看发行说明。发一个request到 [#helm-dev](https://kubernetes.slack.com/messages/C51E88VDG)用于评审。发行日志很容易漏掉一些东西，因此评审总是有用的。 ## 8. PGP Sign the downloads 哈希生成一个表明下载内容就是其生成内容的签名，签名包提供了包来自何处的可追溯性。 为此，要执行以下 `make` 命令： ```shell export VERSION="$RELEASE_NAME" make clean # if not already run make fetch-dist # if not already run make sign ``` 这会生成通过CI推送的每个文件的ascii封装的签名文件。 所有的签名文件(`*.asc`)需要上传到GitHub中的发布版本（附件二级制文件）中。 ## 9. Publish Release 是时候正式发布了！ 发布说明保存在GitHub之后，CI构建已经完成，并且已经添加了发布版本的签名文件，你可以在发布版本上点击 "Publish" 了。 发布的版本，标记为"latest"，并在[helm/helm](https://github.com/helm/helm)仓库的首页显示这个发布版本。 ## 10. Update Docs [Helm站点文档部分](/docs)列出了Helm版本的文档。主、次及补丁版本需要更行到这个站点。 下一个次要版本的发布日期也要发布出来且必须更新。这要创建一个pull request 到 [helm-www仓库](https://github.com/helm/helm-www)。在 `config.toml` 文件中找到合适的 `params.versions`部分并更新Helm版本，例如 [更新当前版本](https://github.com/helm/helm-www/pull/676/files)。 在同一个`config.toml`文件中，更新`params.nextversion`部分。 如果需要，关闭这个版本的[helm/helm 里程碑](https://github.com/helm/helm/milestones)。 为主版本和次版本更新[version skew](https://github.com/helm/helm-www/blob/main/content/en/docs/topics/version_skew.md)。 在[这里](https://helm.sh/calendar/release)更新版本日历： - 为下一个次要版本创建一个条目并在GMT下午5点设置提醒 - 在计划发布的前一周的周一为下一个次要版本的RC1创建一个条目，设置GMT下午5点的提醒 ## 11. Tell the Community 恭喜，你已经完成了。去喝一杯吧。这是你应得的。 然后继续前进并在Slack和Twitter上宣布这个新分支，并链接到[GitHub发布版本](https://github.com/helm/helm/releases)。 或者，写一篇新版本的blog并在上面展示一些新特性！ ================================================ FILE: i18n/zh/docusaurus-plugin-content-docs-community/current/release_policy.md ================================================ --- title: "发布计划策略" description: "描述 Helm 的发布计划策略。" --- 为了用户的利益，Helm 提前定义和宣布发布日期。本文档描述了 Helm 发布计划的策略。 ## 发布日历 {#release-calendar} 可以在[这里](https://helm.sh/calendar/release)找到一份公开日历，显示即将发布的 Helm 版本。 ## 语义化版本 {#semantic-versioning} Helm 的版本格式为 `x.y.z`，其中 `x` 是主版本号，`y` 是次版本号，`z` 是补丁版本号，遵循[语义化版本](https://semver.org/spec/v2.0.0.html)规范。 ## 补丁发布 {#patch-releases} 补丁版本为用户提供 bug 修复和安全修复，不包含新特性。 与最新次要/主要版本相关的新补丁版本通常在每月的第二个星期三发布。 如有需要修复高优先级回归问题或安全问题，可以随时发布补丁版本。 以下情况会取消补丁发布： - 自上一个版本以来没有新内容 - 补丁发布日期在即将发布的次版本第一个候选版本（RC1）之前的一周内 - 补丁发布日期在次版本发布后的四周内 - 主版本或次版本发布安排在同一个月 ## 次版本发布 {#minor-releases} 次版本包含安全和 bug 修复以及新特性。它们在 API 和 CLI 使用方面向后兼容。 为了与 Kubernetes 版本保持一致，Helm 次版本每四个月发布一次（一年三个版本）。 如有需要，可以发布额外的次版本，但不会影响已宣布的未来版本的发布时间，除非距离该版本发布不到 7 天。 版本发布的同时，会在 Helm 主页上宣布下一个次版本的发布日期。 ## 主版本发布 {#major-releases} 主版本包含破坏性变更。这类发布很少见，但有时为了让 Helm 能够在重要的新方向上持续演进，这是必要的。 主版本很难计划。因此，只有当第一个 beta 版本可用时，才会选择并宣布最终发布日期。 ================================================ FILE: i18n/zh/docusaurus-theme-classic/footer.json ================================================ { "link.title.Helm Project": { "message": "Helm 项目", "description": "The title of the footer links column with title=Helm Project in the footer" }, "link.title.Charts": { "message": "Charts", "description": "The title of the footer links column with title=Charts in the footer" }, "link.title.Development": { "message": "开发", "description": "The title of the footer links column with title=Development in the footer" }, "link.title.Community": { "message": "社区", "description": "The title of the footer links column with title=Community in the footer" }, "link.item.label.Source code": { "message": "源代码", "description": "The label of footer link with label=Source code linking to https://github.com/helm/helm" }, "link.item.label.Blog": { "message": "博客", "description": "The label of footer link with label=Blog linking to blog" }, "link.item.label.Events": { "message": "活动", "description": "The label of footer link with label=Events linking to https://www.cncf.io/community/kubecon-cloudnativecon-events/" }, "link.item.label.Code of Conduct": { "message": "行为准则", "description": "The label of footer link with label=Code of Conduct linking to https://github.com/cncf/foundation/blob/master/code-of-conduct.md" }, "link.item.label.Introduction": { "message": "简介", "description": "The label of footer link with label=Introduction linking to docs/intro" }, "link.item.label.Chart tips & tricks": { "message": "Chart 提示与技巧", "description": "The label of footer link with label=Chart tips & tricks linking to #" }, "link.item.label.Developing Charts": { "message": "开发 Charts", "description": "The label of footer link with label=Developing Charts linking to #" }, "link.item.label.Search 800+ Charts": { "message": "搜索 800+ Charts", "description": "The label of footer link with label=Search 800+ Charts linking to https://artifacthub.io/" }, "link.item.label.Slack (#helm-dev)": { "message": "Slack (#helm-dev)", "description": "The label of footer link with label=Slack (#helm-dev) linking to https://kubernetes.slack.com/messages/C51E88VDG" }, "link.item.label.Contribution Guide": { "message": "贡献指南", "description": "The label of footer link with label=Contribution Guide linking to https://github.com/helm/helm/blob/main/CONTRIBUTING.md" }, "link.item.label.Maintainers": { "message": "维护者", "description": "The label of footer link with label=Maintainers linking to https://github.com/helm/helm/blob/main/OWNERS" }, "link.item.label.Weekly Meetings": { "message": "每周会议", "description": "The label of footer link with label=Weekly Meetings linking to https://github.com/helm/community/blob/main/communication.md#meetings" }, "link.item.label.GitHub Community": { "message": "GitHub 社区", "description": "The label of footer link with label=GitHub Community linking to https://github.com/helm/community" }, "link.item.label.Slack (#helm-users)": { "message": "Slack (#helm-users)", "description": "The label of footer link with label=Slack (#helm-users) linking to https://kubernetes.slack.com/" }, "link.item.label.Stack Overflow": { "message": "Stack Overflow", "description": "The label of footer link with label=Stack Overflow linking to https://stackoverflow.com/questions/tagged/kubernetes-helm" }, "link.item.label.X": { "message": "X", "description": "The label of footer link with label=X linking to https://x.com/helmpack" }, "copyright": { "message": "我们是云原生计算基金会的毕业项目。
© Helm 作者 2025。文档在 CC-BY-4.0 下发布。
© 2025 The Linux Foundation。保留所有权利。The Linux Foundation 拥有注册商标并使用商标。有关 The Linux Foundation 的商标列表，请参阅我们的商标使用页面。", "description": "The footer copyright" }, "logo.alt": { "message": "CNCF 标志", "description": "The alt text of footer logo" } } ================================================ FILE: i18n/zh/docusaurus-theme-classic/navbar.json ================================================ { "title": { "message": "Helm", "description": "The title in the navbar" }, "logo.alt": { "message": "Helm 标志", "description": "The alt text of navbar logo" }, "item.label.Docs": { "message": "文档", "description": "Navbar item with label Docs" }, "item.label.Charts": { "message": "Charts", "description": "Navbar item with label Charts" }, "item.label.Blog": { "message": "博客", "description": "Navbar item with label Blog" }, "item.label.Community": { "message": "社区", "description": "Navbar item with label Community" } } ================================================ FILE: netlify-plugins/README.md ================================================ # Netlify Build Plugins Caches Docusaurus build directories to reduce ~11 minute builds to 2-4 minutes. ## Quick Reference **Current plugin:** `cache-docusaurus-dirs-file` (stable) **Build command:** `make netlify-build` (preserves cache) ## Configuration ```toml # netlify.toml [[plugins]] package = "./netlify-plugins/cache-docusaurus-dirs-file" [plugins.inputs] dirs = [".docusaurus", "node_modules", "build"] ``` All caching behavior controlled by environment variables: - `CACHE_VERSION` - Manual cache busting per environment - `CACHE_PER_BRANCH` - Set to `"false"` for PR previews to share cache ## Switching Plugins To test beta Cache API (potentially 10x faster): ```toml package = "./netlify-plugins/cache-docusaurus-dirs-api" ``` ================================================ FILE: netlify-plugins/cache-docusaurus-dirs-api/index.js ================================================ // Netlify Core Build Plugin to cache directories using utils.cache. // - Docusaurus-friendly: cache ".docusaurus", "node_modules", and "build" // - node_modules auto-invalidation via yarn.lock hash // - On-demand busting via CACHE_VERSION env var per environment // - Per-branch cache isolation by default const path = require("path"); const fs = require("fs"); const crypto = require("crypto"); function dirExists(dirPath) { try { const stat = fs.statSync(dirPath); return stat.isDirectory(); } catch { return false; } } function fileSha256(filePath) { try { const data = fs.readFileSync(filePath); return crypto.createHash("sha256").update(data).digest("hex"); } catch { return null; } } function makeKey({ dir, repoRoot }) { const cacheVersion = process.env.CACHE_VERSION || ""; const perBranch = process.env.CACHE_PER_BRANCH !== "false"; // default true const branch = process.env.NETLIFY_BRANCH || process.env.BRANCH || "unknown"; let key = dir; // Auto-invalidate node_modules with yarn.lock changes if (dir === "node_modules") { const yarnLockPath = path.join(repoRoot, "yarn.lock"); const hash = fileSha256(yarnLockPath); if (hash) { key = `${key}@yarn-${hash.slice(0, 16)}`; } } // On-demand busting if (cacheVersion) { key = `${key}@cv-${cacheVersion}`; } // Per-branch isolation if (perBranch) { key = `${key}@${branch}`; } return key; } async function restoreDir(utils, absPath, key) { try { const restored = await utils.cache.restore(absPath, { key }); utils.status.show({ title: restored ? `Cache restored: ${key}` : `No cache: ${key}`, summary: `${restored ? "Restored" : "No prior cache"} into ${absPath}`, }); return restored; } catch (err) { utils.status.show({ title: `Cache restore failed: ${key}`, summary: err.message, }); return false; } } async function saveDir(utils, absPath, key) { try { const saved = await utils.cache.save(absPath, { key }); utils.status.show({ title: saved ? `Cache saved: ${key}` : `Cache skipped: ${key}`, summary: `${saved ? "Saved" : "Skipped"} from ${absPath}`, }); return saved; } catch (err) { utils.status.show({ title: `Cache save failed: ${key}`, summary: err.message, }); return false; } } module.exports = { async onPreBuild({ inputs, utils }) { const repoRoot = process.cwd(); const dirs = inputs.dirs; for (const dir of dirs) { const key = makeKey({ dir, repoRoot }); const abs = path.resolve(repoRoot, dir); await restoreDir(utils, abs, key); // Guidance for node_modules: ensure yarn.lock exists to keep cache fresh if (dir === "node_modules") { const yarnLockPath = path.join(repoRoot, "yarn.lock"); if (!fs.existsSync(yarnLockPath)) { utils.status.show({ title: "node_modules cache warning", summary: "yarn.lock not found. Caching node_modules without yarn.lock can lead to stale dependencies. Ensure yarn.lock is committed.", }); } } } }, async onPostBuild({ inputs, utils }) { const repoRoot = process.cwd(); const dirs = inputs.dirs; for (const dir of dirs) { const key = makeKey({ dir, repoRoot }); const abs = path.resolve(repoRoot, dir); if (!dirExists(abs)) { utils.status.show({ title: `Cache not saved (missing directory)`, summary: `${abs} does not exist.`, }); continue; } const hasFiles = fs.readdirSync(abs).length > 0; if (!hasFiles) { utils.status.show({ title: `Cache not saved (empty directory)`, summary: `${abs} is empty.`, }); continue; } await saveDir(utils, abs, key); } }, }; ================================================ FILE: netlify-plugins/cache-docusaurus-dirs-api/manifest.yml ================================================ name: cache-docusaurus-dirs-api inputs: - name: dirs description: Array of directories to cache (relative to repo root) required: true ================================================ FILE: netlify-plugins/cache-docusaurus-dirs-file/index.js ================================================ // Netlify Build Plugin to cache directories using file-based caching (stable) // - Docusaurus-friendly: cache ".docusaurus", "node_modules", and "build" // - node_modules auto-invalidation via yarn.lock hash // - On-demand busting via CACHE_VERSION env var per environment // - Per-branch cache isolation by default const path = require("path"); const fs = require("fs"); const crypto = require("crypto"); function dirExists(dirPath) { try { const stat = fs.statSync(dirPath); return stat.isDirectory(); } catch { return false; } } function fileSha256(filePath) { try { const data = fs.readFileSync(filePath); return crypto.createHash("sha256").update(data).digest("hex"); } catch { return null; } } function makeKey({ dir, repoRoot }) { const cacheVersion = process.env.CACHE_VERSION || ""; const perBranch = process.env.CACHE_PER_BRANCH !== "false"; // default true const branch = process.env.NETLIFY_BRANCH || process.env.BRANCH || "unknown"; let key = dir; // Auto-invalidate node_modules with yarn.lock changes if (dir === "node_modules") { const yarnLockPath = path.join(repoRoot, "yarn.lock"); const hash = fileSha256(yarnLockPath); if (hash) { key = `${key}@yarn-${hash.slice(0, 16)}`; } } // On-demand busting if (cacheVersion) { key = `${key}@cv-${cacheVersion}`; } // Per-branch isolation if (perBranch) { key = `${key}@${branch}`; } return key; } async function restoreDir(utils, absPath, key) { try { // File-based caching: check if cache exists, then restore const cacheExists = await utils.cache.has(key); if (!cacheExists) { utils.status.show({ title: `No cache: ${key}`, summary: `No prior cache for ${absPath}`, }); return false; } const restored = await utils.cache.restore(key); if (restored) { // File-based caching often requires manual copy from cache location // The exact implementation may vary based on Netlify's file-based API utils.status.show({ title: `Cache restored: ${key}`, summary: `Restored into ${absPath}`, }); } else { utils.status.show({ title: `Cache restore failed: ${key}`, summary: `Failed to restore cache for ${absPath}`, }); } return restored; } catch (err) { utils.status.show({ title: `Cache restore failed: ${key}`, summary: err.message, }); return false; } } async function saveDir(utils, absPath, key) { try { // File-based caching: save directory to cache const saved = await utils.cache.save(key, absPath); utils.status.show({ title: saved ? `Cache saved: ${key}` : `Cache skipped: ${key}`, summary: `${saved ? "Saved" : "Skipped"} from ${absPath}`, }); return saved; } catch (err) { utils.status.show({ title: `Cache save failed: ${key}`, summary: err.message, }); return false; } } module.exports = { async onPreBuild({ inputs, utils }) { const repoRoot = process.cwd(); const dirs = inputs.dirs; for (const dir of dirs) { const key = makeKey({ dir, repoRoot }); const abs = path.resolve(repoRoot, dir); await restoreDir(utils, abs, key); // Guidance for node_modules: ensure yarn.lock exists to keep cache fresh if (dir === "node_modules") { const yarnLockPath = path.join(repoRoot, "yarn.lock"); if (!fs.existsSync(yarnLockPath)) { utils.status.show({ title: "node_modules cache warning", summary: "yarn.lock not found. Caching node_modules without yarn.lock can lead to stale dependencies. Ensure yarn.lock is committed.", }); } } } }, async onPostBuild({ inputs, utils }) { const repoRoot = process.cwd(); const dirs = inputs.dirs; for (const dir of dirs) { const key = makeKey({ dir, repoRoot }); const abs = path.resolve(repoRoot, dir); if (!dirExists(abs)) { utils.status.show({ title: `Cache not saved (missing directory)`, summary: `${abs} does not exist.`, }); continue; } const hasFiles = fs.readdirSync(abs).length > 0; if (!hasFiles) { utils.status.show({ title: `Cache not saved (empty directory)`, summary: `${abs} is empty.`, }); continue; } await saveDir(utils, abs, key); } }, }; ================================================ FILE: netlify-plugins/cache-docusaurus-dirs-file/manifest.yml ================================================ name: cache-docusaurus-dirs-file inputs: - name: dirs description: Array of directories to cache (relative to repo root) required: true ================================================ FILE: netlify.toml ================================================ # Build configs [build] command = "make netlify-build" publish = "build" # Cache Docusaurus internal cache (.docusaurus) with optional CACHE_VERSION per environment [[plugins]] package = "./netlify-plugins/cache-docusaurus-dirs-file" [plugins.inputs] dirs = [".docusaurus", "node_modules", "build"] [context.production.environment] SITE_URL = "https://helm.sh" CACHE_VERSION = "prod-v1" [context.deploy-preview.environment] CACHE_VERSION = "preview-v1" CACHE_PER_BRANCH = "false" [context.branch-deploy.environment] CACHE_VERSION = "branch-v1" # Go module import support handled by static HTML files in /static/ # These paths serve HTML with go-import meta tags + client-side redirects # redirect Go package lookups [[redirects]] from = "/helm/v3/*" to = "/helm/v3" status = 200 [[redirects]] from = "/helm/v2/*" to = "/helm/v2" status = 200 # custom external redirects [[redirects]] from = "/calendar/release" to = "https://calendar.google.com/calendar/u/0/embed?src=8tji8e0obp5skr2pval9g55ftk@group.calendar.google.com" status = 302 [[redirects]] from = "/v4-launch-party-sponsorship" to = "https://docs.google.com/document/d/10cyzggPiLeLz169cDF1UaUMmM4uZx6rO3Bw9rRQRjJA/edit?usp=sharing" status = 302 # RSS feed alias [[redirects]] from = "/blog/index.xml" to = "/blog/rss.xml" status = 200 # docs.helm.sh to current domain [[redirects]] from = "https://docs.helm.sh/*" to = "https://helm.sh/docs/:splat" # v3 redirects [[redirects]] from = "/docs/topics/v2_v3_migration" to = "/docs/v3/topics/v2_v3_migration" [[redirects]] from = "/docs/faq/changes_since_helm2" to = "/docs/v3/faq/changes_since_helm2" [[redirects]] from = "/docs/faq/troubleshooting" to = "/docs/v3/faq/troubleshooting" # v2.helm.sh redirects # TODO: Change status codes below from 302 to 301 after Docusaurus cutover verification # v2.helm.sh to current domain [[redirects]] from = "https://v2.helm.sh/docs/*" to = "https://helm.sh/docs/v2/:splat" status = 302 # v2.helm.sh categories not present in v3 docs # Category-level redirects only (no wildcard) because v2.helm.sh did not have # sub-pages, only anchors to one combined category page # Note URL fragments are not supported by Netlify redirects [[redirects]] from = "/docs/using_helm/" to = "/docs/v2/using_helm/" status = 302 [[redirects]] from = "/docs/developing_charts/" to = "/docs/v2/developing_charts/" status = 302 # v2.helm.sh categories with new corresponding v3 paths [[redirects]] from = "/docs/related/" to = "/community/related/" status = 302 [[redirects]] from = "/docs/architecture/" to = "/docs/topics/architecture/" status = 302 [[redirects]] from = "/docs/developers/" to = "/community/developers/" status = 302 [[redirects]] from = "/docs/history/" to = "/community/history/" status = 302 # START - Hugo frontmatter aliases redirects, removed during Docusaurus migration [[redirects]] from = "/docs/advanced_helm_techniques" to = "/docs/topics/advanced/" status = 302 [[redirects]] from = "/docs/chart_repository/" to = "/docs/topics/chart_repository/" status = 302 [[redirects]] from = "/docs/chart_repository_sync_example/" to = "/docs/howto/chart_repository_sync_example/" status = 302 [[redirects]] from = "/docs/chart_tests/" to = "/docs/topics/chart_tests/" status = 302 [[redirects]] from = "/docs/charts_hooks/" to = "/docs/topics/charts_hooks/" status = 302 [[redirects]] from = "/docs/charts_tips_and_tricks/" to = "/docs/howto/charts_tips_and_tricks/" status = 302 [[redirects]] from = "/docs/gosdk" to = "/docs/sdk/gosdk/" status = 302 [[redirects]] from = "/docs/install/" to = "/docs/intro/install/" status = 302 [[redirects]] from = "/docs/kubernetes_distros/" to = "/docs/topics/kubernetes_distros/" status = 302 [[redirects]] from = "/docs/localization/" to = "/community/localization/" status = 302 [[redirects]] from = "/docs/permissions_sql_storage_backend/" to = "/docs/topics/permissions_sql_storage_backend/" status = 302 [[redirects]] from = "/docs/plugins/" to = "/docs/topics/plugins/" status = 302 [[redirects]] from = "/docs/provenance/" to = "/docs/topics/provenance/" status = 302 [[redirects]] from = "/docs/quickstart/" to = "/docs/intro/quickstart/" status = 302 [[redirects]] from = "/docs/rbac/" to = "/docs/topics/rbac/" status = 302 [[redirects]] from = "/docs/registries/" to = "/docs/topics/registries/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/" to = "/docs/chart_best_practices/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/conventions/" to = "/docs/chart_best_practices/conventions/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/custom_resource_definitions/" to = "/docs/chart_best_practices/custom_resource_definitions/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/dependencies/" to = "/docs/chart_best_practices/dependencies/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/labels/" to = "/docs/chart_best_practices/labels/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/pods/" to = "/docs/chart_best_practices/pods/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/rbac/" to = "/docs/chart_best_practices/rbac/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/templates/" to = "/docs/chart_best_practices/templates/" status = 302 [[redirects]] from = "/docs/topics/chart_best_practices/values/" to = "/docs/chart_best_practices/values/" status = 302 [[redirects]] from = "/docs/topics/faq/" to = "/docs/faq/" status = 302 [[redirects]] from = "/intro/getting_started/" to = "/docs/chart_template_guide/getting_started/" status = 302 [[redirects]] from = "/topics/chart_template_guide/" to = "/docs/chart_template_guide/" status = 302 [[redirects]] from = "/docs/k8s_apis/" to = "/docs/topics/kubernetes_apis/" status = 302 [[redirects]] from = "/docs/library_charts/" to = "/docs/topics/library_charts/" status = 302 # Additional redirects for Hugo frontmatter aliases removed during v3 migration [[redirects]] from = "/docs/developers/" to = "/community/developers/" status = 302 [[redirects]] from = "/docs/history/" to = "/community/history/" status = 302 [[redirects]] from = "/docs/related/" to = "/community/related/" status = 302 [[redirects]] from = "/docs/faq/" to = "/docs/faq/" status = 302 [[redirects]] from = "/docs/using_helm/" to = "/docs/intro/" status = 302 [[redirects]] from = "/docs/architecture/" to = "/docs/topics/architecture/" status = 302 [[redirects]] from = "/docs/developing_charts/" to = "/docs/topics/charts/" status = 302 [[redirects]] from = "/developing_charts/" to = "/docs/topics/charts/" status = 302 # END - Hugo frontmatter aliases redirects # Moved to community section [[redirects]] from = "/docs/community/*" to = "/community/:splat" status = 302 # Community release policy [[redirects]] from = '/docs/topics/release_policy' to = '/community/release_policy' status = 302 [[redirects]] from = '/docs/v3/topics/release_policy' to = '/community/release_policy' status = 302 # Community release policy (i18n/ko) [[redirects]] from = '/ko/docs/v3/topics/release_policy' to = '/ko/community/release_policy' status = 302 # Community release policy (i18n/uk) [[redirects]] from = '/uk/docs/topics/release_policy' to = '/uk/community/release_policy' status = 302 [[redirects]] from = '/uk/docs/v3/topics/release_policy' to = '/uk/community/release_policy' status = 302 # Community release policy (i18n/zh) [[redirects]] from = '/zh/docs/v3/topics/release_policy' to = '/zh/community/release_policy' status = 302 ================================================ FILE: package.json ================================================ { "name": "helm-www", "version": "0.0.0", "private": true, "scripts": { "docusaurus": "docusaurus", "start": "docusaurus start", "build": "docusaurus build", "swizzle": "docusaurus swizzle", "deploy": "docusaurus deploy", "clear": "docusaurus clear", "serve": "docusaurus serve", "write-translations": "docusaurus write-translations", "write-heading-ids": "docusaurus write-heading-ids", "migrate:v2": "node scripts/migrate-v2-docs.js", "migrate:v3": "node scripts/migrate-v3-docs.js", "download-remote-community": "docusaurus download-remote-community", "clear-remote-community": "docusaurus clear-remote-community" }, "dependencies": { "@docusaurus/core": "3.9.2", "@docusaurus/preset-classic": "3.9.2", "@mdx-js/react": "^3.0.0", "@octokit/rest": "^22.0.1", "clsx": "^2.0.0", "docusaurus-plugin-remote-content": "^4.0.0", "js-yaml": "^4.1.1", "ora": "^9.0.0", "prism-react-renderer": "^2.3.0", "raw-loader": "^4.0.2", "react": "^19.0.0", "react-dom": "^19.0.0", "react-icons": "^5.5.0", "simple-git": "^3.32.3" }, "devDependencies": { "@docusaurus/module-type-aliases": "3.9.2", "@docusaurus/types": "3.9.2", "baseline-browser-mapping": "^2.10.21", "jsdom": "^27.0.1" }, "browserslist": { "production": [ ">0.5%", "not dead", "not op_mini all" ], "development": [ "last 3 chrome version", "last 3 firefox version", "last 5 safari version" ] }, "engines": { "node": ">=20.0" }, "resolutions": { "gray-matter/js-yaml": "3.14.2", "serialize-javascript": ">=7.0.5", "path-to-regexp": "0.1.13", "minimatch": ">=3.1.3", "browserslist": "^4.28.1" } } ================================================ FILE: postcss.config.js ================================================ module.exports = { plugins: { autoprefixer: {} }, } ================================================ FILE: remote-content_community.js ================================================ /** * Configuration for the "community" instance of docusaurus-plugin-remote-content * Imports documentation from the helm/community GitHub repository */ module.exports = { // Source repository information sourceRepo: "https://github.com/helm/community", sourceBaseUrl: "https://raw.githubusercontent.com/helm/community/refs/heads/main/", // Files to import with their transformations files: { // Simple files with no modifications "blog-topics.md": {}, "code-of-conduct.md": {}, "communication.md": {}, "incubator.md": {}, "stable-repo-charts-new-locations.md": {}, "user-profiles.md": {}, // Files with modifications "README.md": { meta: { sidebar_position: 1, }, links: { "https://github.com/helm/community/tree/main/art": "/community/art", }, }, "MAINTAINERS.md": {}, "SECURITY.md": { meta: { sidebar_label: "Helm Security", }, links: { "README.md": "/community", }, }, "governance/README.md": { meta: { sidebar_label: "Governance", title: "Governance Introduction", id: "helm-governance", sidebar_position: 9, }, links: { "governance.md": "/community/governance/governance", "../MAINTAINERS.md": "/community/MAINTAINERS", }, }, "governance/governance.md": { meta: { sidebar_label: "Rules", title: "Governance Rules", slug: "governance", }, }, // Art files "art/readme.md": { meta: { title: "Styleguide", }, }, // Meeting notes - automatically converted from .txt to .md "meeting-notes/2017.txt": {}, "meeting-notes/2018.txt": {}, "meeting-notes/2019.txt": {}, "meeting-notes/2020.txt": {}, "meeting-notes/2021.txt": {}, // HIPs "hips/README.md": {}, "hips/hip-0001.md": {}, "hips/hip-0002.md": {}, "hips/hip-0003.md": {}, "hips/hip-0004.md": {}, "hips/hip-0005.md": { links: { "https://github.com/helm/community/blob/master/governance/governance.md": "/community/governance/governance", }, }, "hips/hip-0006.md": {}, "hips/hip-0007.md": { links: { "https://github.com/helm/community/blob/master/governance/governance.md": "/community/governance/governance", "../maintainer-groups.yaml": "https://github.com/helm/community/blob/main/maintainer-groups.yaml", }, }, "hips/hip-0008.md": {}, "hips/hip-0009.md": { links: { "../security.md": "../SECURITY.md", }, }, "hips/hip-0010.md": {}, "hips/hip-0011.md": {}, "hips/hip-0012.md": { links: { "https://github.com/helm/community/blob/main/user-profiles.md": "/community/user-profiles", }, }, "hips/hip-0014.md": { links: { "https://github.com/helm/community/tree/main/governance": "/community/governance/governance", "https://github.com/helm/community/blob/main/Teams.md": "https://github.com/helm/community/blob/main/maintainer-groups.yaml", }, }, "hips/hip-0015.md": {}, "hips/hip-0016.md": {}, "hips/hip-0017.md": {}, "hips/hip-0018.md": {}, "hips/hip-0019.md": {}, "hips/hip-0020.md": {}, "hips/hip-0021.md": {}, "hips/hip-0022.md": {}, "hips/hip-0023.md": {}, "hips/hip-0024.md": {}, "hips/hip-0025.md": { links: { "https://github.com/helm/community/blob/main/user-profiles.md": "/community/user-profiles", }, }, "hips/hip-0026.md": { links: { "https://github.com/helm/community/blob/main/hips/hip-0012.md": "/community/hips/hip-0012", "https://github.com/helm/community/blob/main/hips/archives/helm/distributed-search.md": "/community/hips/archives/helm/distributed-search", }, }, // HIP Archives "hips/archives/README.md": {}, "hips/archives/monocular/1.0-improvements.md": { links: { "https://github.com/helm/community/blob/master/proposals/distributed-search.md": "/community/hips/archives/helm/distributed-search", }, }, "hips/archives/helm/distributed-search.md": {}, "hips/archives/helm/helm-v3/000-helm-v3.md": { links: { "../../../user-profiles.md": "../../../../user-profiles.md", }, }, "hips/archives/helm/helm-v3/001-charts.md": {}, "hips/archives/helm/helm-v3/002-events.md": {}, "hips/archives/helm/helm-v3/003-state.md": {}, "hips/archives/helm/helm-v3/004-hooks.md": {}, "hips/archives/helm/helm-v3/005-plugins.md": {}, "hips/archives/helm/helm-v3/006-repositories.md": {}, "hips/archives/helm/helm-v3/007-security.md": {}, "hips/archives/helm/helm-v3/008-controller.md": {}, "hips/archives/helm/helm-v3/009-package_manager.md": {}, "hips/archives/helm/helm-v3/010-removed.md": {}, "hips/archives/helm/helm-v3/011-user_stories.md": { links: { "../user-profiles.md": "../../../../user-profiles.md", }, }, "hips/archives/helm/helm-v3/012-chart-dev-stories.md": {}, "hips/archives/helm/helm-v3/research/package-manager-ux.md": {}, }, }; ================================================ FILE: scripts/migrate-v2-docs.js ================================================ #!/usr/bin/env node const { startFresh, restoreSourceContent, skaffoldMajorVersion } = require("./util/util-migration.js"); const { copyV2DocsToDocusaurus } = require("./v2/copy-files.js"); const path = require('path'); /** * Master orchestrator for v2 docs migration * Simple migration that fetches v2 menu structure and copies files */ async function migrateV2Docs(majorVersion = 2) { console.log("🚀 Starting v2 docs migration..."); try { // Step 1: Start with clean slate and restore source content console.log("\n📋 Step 1: Starting fresh..."); startFresh(majorVersion); restoreSourceContent(majorVersion); // Step 2: Setup Docusaurus version structure (creates versioned_docs/version-2) console.log("\n📋 Step 2: Setting up Docusaurus version structure..."); skaffoldMajorVersion(majorVersion); // Step 3: Generate v2 menu structure console.log("\n📋 Step 3: Generating v2 menu structure..."); const { fetchV2Navigation } = require("./v2/menu-generate.js"); await fetchV2Navigation(); // Step 4: Copy v2 files using the structured menu console.log("\n📋 Step 4: Processing v2 files with Docusaurus structure..."); copyV2DocsToDocusaurus(); // Step 5: Fix v2 href differences (link paths) console.log("\n📋 Step 5: Fixing v2 href differences..."); const path = require('path'); const { processHrefDifferences } = require("./util/href-diffs-process.js"); const differencesFile = path.join(__dirname, 'v2/href-diffs.json'); processHrefDifferences(majorVersion, differencesFile); console.log("\n🎉 v2 docs migration completed successfully!"); } catch (error) { console.error("❌ Migration failed:", error.message); console.error("Stack trace:", error.stack); process.exit(1); } } // Run if called directly if (require.main === module) { const majorVersion = process.argv[2] ? parseInt(process.argv[2]) : 2; migrateV2Docs(majorVersion); } module.exports = { migrateV2Docs }; ================================================ FILE: scripts/migrate-v3-docs.js ================================================ #!/usr/bin/env node const { processHelmFiles } = require('./v3/process-helm-files.js'); const { removeAliasesFromFiles } = require('./v3/remove-aliases.js'); const { migrateSdkSection } = require("./v3/migrate-sdk-section.js"); const { addNetlifyRedirects } = require("./v3/add-netlify-redirects.js"); const { startFresh, restoreSourceContent, skaffoldMajorVersion, moveDocs, deleteDeprecatedFiles, renameIndexFilesToMdx, replaceWeightWithSidebarPosition, addMainIndexMetadata, addDocsIndexLists, renameCommandsToHelm, } = require("./util/util-migration.js"); const { applyAllTextReplacements } = require("./util/util-text-replacements.js"); const { convertRelativeLinksToAbsolute } = require("./util/util-docusaurus-links.js"); const { processHrefDifferences } = require("./util/href-diffs-process.js"); /** * Master orchestrator for v3 docs migration * Replaces migrate-docs.sh with idiomatic Node.js */ async function migrateV3Docs(majorVersion = 3) { console.log("🚀 Starting v3 docs migration..."); try { // Step 1: Start with clean slate (reset directories and restore from git main) console.log("\n📋 Step 1: Starting fresh..."); startFresh(majorVersion); restoreSourceContent(majorVersion); // Step 2: Setup Docusaurus version structure (idempotent) console.log("\n📋 Step 2: Setting up Docusaurus version structure..."); skaffoldMajorVersion(majorVersion); // Step 3: Move docs from Hugo to Docusaurus structure console.log("\n📋 Step 3: Moving docs..."); moveDocs(majorVersion); // Step 4: Delete files with deprecated section console.log("\n📋 Step 4: Deleting deprecated files..."); deleteDeprecatedFiles(majorVersion); // Step 5: Rename index.md → index.mdx files console.log("\n📋 Step 5: Renaming index files..."); renameIndexFilesToMdx(majorVersion); // Step 6: Replace Hugo weight with Docusaurus sidebar_position console.log("\n📋 Step 6: Converting frontmatter..."); replaceWeightWithSidebarPosition(majorVersion); // Step 7: Add metadata to main index file console.log("\n📋 Step 7: Adding main index metadata..."); addMainIndexMetadata(majorVersion); // Step 8: Migrate SDK section (import Go files and apply transformations) console.log("\n📋 Step 8: Migrating SDK section..."); migrateSdkSection(majorVersion); // Step 9: Rename commands directories to helm in i18n console.log("\n📋 Step 9: Renaming commands to helm in i18n directories..."); renameCommandsToHelm(majorVersion); // Step 10: Apply text replacements (Hugo shortcodes and per-file rules) console.log("\n📋 Step 10: Applying text replacements..."); applyAllTextReplacements(majorVersion); // Step 11: Process Helm files (H2 → titles, add slug/id metadata) console.log("\n📋 Step 11: Processing Helm files..."); processHelmFiles(); // Step 12: Remove all aliases from v3 files console.log("\n📋 Step 12: Removing aliases..."); removeAliasesFromFiles(); // Step 13: Add DocCardList components to index pages console.log("\n📋 Step 13: Adding DocCardList components..."); addDocsIndexLists(majorVersion); // Step 14: Add netlify redirects for removed aliases console.log("\n📋 Step 14: Adding netlify redirects..."); addNetlifyRedirects(); // Step 15: Process href differences (fix broken links) console.log("\n📋 Step 15: Processing href differences..."); processHrefDifferences(majorVersion, `./scripts/v${majorVersion}/href-diffs.json`); // Step 16: Convert all relative links to absolute Docusaurus paths console.log("\n📋 Step 16: Converting relative links to absolute paths..."); convertRelativeLinksToAbsolute(majorVersion); console.log("\n🎉 v3 docs migration completed successfully!"); } catch (error) { console.error("❌ Migration failed:", error.message); console.error("Stack trace:", error.stack); process.exit(1); } } // Main execution if (require.main === module) { migrateV3Docs(); } module.exports = { migrateV3Docs }; ================================================ FILE: scripts/regenerate-cli-docs.mjs ================================================ #!/usr/bin/env node import { execSync } from 'child_process'; import fs from 'fs'; import path from 'path'; import { fileURLToPath } from 'url'; import { tmpdir } from 'os'; // ESM compatibility for __dirname const __filename = fileURLToPath(import.meta.url); const __dirname = path.dirname(__filename); const PROJECT_ROOT = path.dirname(__dirname); /** * Extract major version from a version string (e.g., v3.19.0 -> 3, v4.0.0-alpha.1 -> 4) */ function getMajorVersion(version) { const match = version.match(/^v(\d+)/); return match ? match[1] : null; } /** * Get latest Helm version from get.helm.sh script */ async function getHelmLatest() { try { const response = await fetch('https://get.helm.sh'); const text = await response.text(); const match = text.match(/v\d+\.\d+\.\d+/); if (match) { return match[0]; } throw new Error('No version found in get.helm.sh script'); } catch (error) { console.error('Error fetching latest Helm version:', error.message); process.exit(1); } } /** * Regenerate Helm CLI documentation */ function regenerateDocs(helmVersion, versionDir) { console.log('📦 Regenerating Helm CLI documentation...'); const tempDir = fs.mkdtempSync(path.join(tmpdir(), 'helm-')); try { // Download and install Helm console.log(` 📥 Downloading Helm ${helmVersion}...`); process.env.DESIRED_VERSION = helmVersion; process.env.HELM_INSTALL_DIR = tempDir; // Download helm binary directly const arch = process.arch === 'x64' ? 'amd64' : process.arch === 'arm64' ? 'arm64' : 'amd64'; const platform = process.platform === 'darwin' ? 'darwin' : 'linux'; const helmUrl = `https://get.helm.sh/helm-${helmVersion}-${platform}-${arch}.tar.gz`; execSync(` cd "${tempDir}" && \ curl -fsSL -o helm.tar.gz "${helmUrl}" && \ tar -xzf helm.tar.gz && \ mv ${platform}-${arch}/helm ./helm && \ chmod +x ./helm `, { stdio: 'inherit' }); // Set environment variables to match Linux defaults process.env.HOME = '~'; process.env.HELM_CACHE_HOME = '~/.cache/helm'; process.env.HELM_CONFIG_HOME = '~/.config/helm'; process.env.HELM_DATA_HOME = '~/.local/share/helm'; // Create helm directory and generate docs const helmDocsDir = path.join(PROJECT_ROOT, versionDir, 'helm'); fs.mkdirSync(helmDocsDir, { recursive: true }); console.log(` 📝 Generating documentation in ${versionDir}/helm/...`); execSync(`"${tempDir}/helm" docs --type markdown --generate-headers`, { cwd: helmDocsDir, stdio: 'inherit' }); console.log(' ✅ Documentation generated successfully'); } finally { // Clean up temp directory fs.rmSync(tempDir, { recursive: true, force: true }); } } /** * Delete deprecated files with 'section: deprecated' frontmatter */ function deleteDeprecatedFiles(helmDir) { console.log('🗑️ Removing deprecated files...'); const files = fs.readdirSync(helmDir).filter(file => file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx' ); let deletedCount = 0; files.forEach(fileName => { const filePath = path.join(helmDir, fileName); try { const content = fs.readFileSync(filePath, 'utf8'); // Check for deprecated section in frontmatter const frontmatterMatch = content.match(/^---\n([\s\S]*?)\n---/); if (frontmatterMatch) { const frontmatter = frontmatterMatch[1]; if (frontmatter.includes('section: deprecated')) { fs.unlinkSync(filePath); console.log(` 🗑️ Deleted: ${fileName}`); deletedCount++; } } } catch (error) { console.warn(` ⚠️ Error checking ${fileName}: ${error.message}`); } }); if (deletedCount > 0) { console.log(` ✅ Removed ${deletedCount} deprecated files`); } } /** * Rename index files to .mdx format */ function renameIndexFilesToMdx(helmDir) { console.log('🔄 Renaming index files to .mdx...'); let renamedCount = 0; // Check for _index.md or index.md ['_index.md', 'index.md'].forEach(fileName => { const oldPath = path.join(helmDir, fileName); if (fs.existsSync(oldPath)) { const newPath = path.join(helmDir, 'index.mdx'); fs.renameSync(oldPath, newPath); console.log(` 🔄 Renamed: ${fileName} → index.mdx`); renamedCount++; } }); if (renamedCount > 0) { console.log(` ✅ Renamed ${renamedCount} index files`); } } /** * Create or update main index file */ function createOrUpdateIndexFile(helmDir) { console.log('📝 Creating/updating index.mdx file...'); const indexPath = path.join(helmDir, 'index.mdx'); // Create the index.mdx content const indexContent = `--- title: Helm Commands description: Documentation for the full list of helm CLI commands. sidebar_position: 6 id: helm-category --- # Helm Commands Here you'll find the list of CLI commands for Helm, with help info on their usage. import DocCardList from '@theme/DocCardList'; `; fs.writeFileSync(indexPath, indexContent); console.log(' ✅ Index file created/updated'); } /** * Process Helm command files - extract H2 title and set as frontmatter title */ function processHelmFiles(helmDir) { console.log('🔧 Processing Helm command files...'); const files = fs.readdirSync(helmDir).filter(file => file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx' ); let processedCount = 0; files.forEach(fileName => { const filePath = path.join(helmDir, fileName); try { let content = fs.readFileSync(filePath, 'utf8'); // Find first H2 heading const h2Match = content.match(/^## (.+)$/m); if (h2Match) { const title = h2Match[1]; // Remove the H2 line and any following blank line content = content.replace(/^## .+\n(\n)?/m, ''); // Parse existing frontmatter if it exists let frontmatter = {}; let restContent = content; if (content.startsWith('---')) { const frontmatterMatch = content.match(/^---\n([\s\S]*?)\n---\n([\s\S]*)$/); if (frontmatterMatch) { // Parse existing frontmatter const frontmatterText = frontmatterMatch[1]; frontmatterText.split('\n').forEach(line => { const match = line.match(/^(\w+):\s*(.*)$/); if (match && match[1] !== 'title') { // Keep all existing frontmatter except title frontmatter[match[1]] = match[2].replace(/^["']|["']$/g, ''); } }); restContent = frontmatterMatch[2]; } } // Set the title (lowercase, no quotes) frontmatter.title = title; // Special handling for helm.md - add slug if (fileName === 'helm.md') { frontmatter.slug = 'helm'; } // Build new content with updated frontmatter const frontmatterLines = Object.entries(frontmatter) .map(([key, value]) => `${key}: ${value}`) .join('\n'); content = `--- ${frontmatterLines} --- ${restContent}`; fs.writeFileSync(filePath, content); console.log(` ✅ Processed: ${fileName}`); processedCount++; } } catch (error) { console.error(` ❌ Error processing ${fileName}: ${error.message}`); } }); console.log(` ✅ Processed ${processedCount} files`); // Create _category_.json with link to category doc const categoryPath = path.join(helmDir, '_category_.json'); const categoryContent = { link: { type: "doc", id: "helm-category" } }; fs.writeFileSync(categoryPath, JSON.stringify(categoryContent, null, 2) + '\n'); console.log(' ✅ Created _category_.json'); } /** * Process href differences for helm files only */ function processHelmHrefDifferences(helmDir) { console.log('🔗 Fixing glossary references in helm files...'); const rules = [ { fileName: 'helm_install.md', before: 'docs/glossary/_index.md#chart-archive', after: '../glossary/index.mdx#chart-archive' }, { fileName: 'helm_install.md', before: 'docs/glossary/_index.md#linhagem-arquivo-de-linhagem', after: '../glossary/index.mdx#linhagem-arquivo-de-linhagem' } ]; let fixedCount = 0; rules.forEach(rule => { const filePath = path.join(helmDir, rule.fileName); if (fs.existsSync(filePath)) { try { let content = fs.readFileSync(filePath, 'utf8'); // Look for the exact text to replace if (content.includes(rule.before)) { content = content.replace(new RegExp(rule.before.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'g'), rule.after); fs.writeFileSync(filePath, content); console.log(` 🔗 Fixed: ${rule.fileName}`); fixedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${rule.fileName}: ${error.message}`); } } }); if (fixedCount > 0) { console.log(` ✅ Fixed ${fixedCount} glossary references`); } } /** * Convert SEE ALSO links to absolute paths */ function convertSeeAlsoLinksToAbsolute(helmDir) { console.log('🔗 Converting SEE ALSO links to absolute paths...'); const files = fs.readdirSync(helmDir).filter(file => file.endsWith('.md') || file.endsWith('.mdx') ); let totalFilesConverted = 0; files.forEach(fileName => { const filePath = path.join(helmDir, fileName); try { let content = fs.readFileSync(filePath, 'utf8'); let hasChanges = false; // Pattern for markdown links to helm commands (relative links without path) // Matches: [text](helm.md) or [text](helm_command.md) const helmLinkPattern = /\[([^\]]+)\]\((helm[^/)]*\.md)\)/g; content = content.replace(helmLinkPattern, (match, text, link) => { hasChanges = true; // Convert to absolute /helm/ links return `[${text}](/helm/${link})`; }); if (hasChanges) { fs.writeFileSync(filePath, content); console.log(` 🔗 Converted links in ${fileName}`); totalFilesConverted++; } } catch (error) { console.warn(` ⚠️ Error processing ${fileName}: ${error.message}`); } }); if (totalFilesConverted > 0) { console.log(` ✅ Converted links in ${totalFilesConverted} files`); } } /** * Main function */ async function main() { // Check for help flag if (process.argv[2] === '--help' || process.argv[2] === '-h') { console.log(`Usage: node scripts/regenerate-cli-docs.mjs Regenerate Helm CLI documentation and apply post-processing. Arguments: helm-version Required. Helm version to use (e.g., v3.19.0, v4.0.0-rc.1) target-directory Required. Directory to generate docs in (e.g., docs, versioned_docs/version-3) Examples: node scripts/regenerate-cli-docs.mjs v3.16.4 versioned_docs/version-3 node scripts/regenerate-cli-docs.mjs v4.0.0-rc.1 docs node scripts/regenerate-cli-docs.mjs v4.0.0 versioned_docs/version-4 The script will: 1. Download and install the specified Helm version 2. Generate CLI documentation using 'helm docs' in /helm/ 3. Delete deprecated files 4. Convert index files to .mdx format 5. Extract H2 titles as frontmatter 6. Fix specific href references 7. Convert relative links to absolute paths`); process.exit(0); } // Validate required arguments if (!process.argv[2] || !process.argv[3]) { console.error('Error: Both helm version and target directory are required'); console.error('Usage: node scripts/regenerate-cli-docs.mjs '); console.error('Run with --help for more information'); process.exit(1); } // Get arguments const helmVersion = process.argv[2]; const versionDir = process.argv[3]; const majorVersion = getMajorVersion(helmVersion); console.log('==============================================='); console.log('Helm CLI Documentation Generator'); console.log(`Helm version: ${helmVersion}`); console.log(`Major version: ${majorVersion}`); console.log(`Documentation directory: ${versionDir}`); console.log('===============================================\n'); // Step 1: Regenerate docs regenerateDocs(helmVersion, versionDir); const helmDir = path.join(PROJECT_ROOT, versionDir, 'helm'); // Step 2: Delete deprecated files deleteDeprecatedFiles(helmDir); // Step 3: Rename index files to .mdx renameIndexFilesToMdx(helmDir); // Step 4: Create/update main index file createOrUpdateIndexFile(helmDir); // Step 5: Process Helm files (extract H2 titles) processHelmFiles(helmDir); // Step 6: Process helm-specific href differences processHelmHrefDifferences(helmDir); // Step 7: Convert SEE ALSO links to absolute paths convertSeeAlsoLinksToAbsolute(helmDir); console.log('\n✅ Documentation regeneration complete!'); } // Run the script main().catch(error => { console.error('Fatal error:', error); process.exit(1); }); ================================================ FILE: scripts/util/href-diffs-process.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { findFiles } = require('./util-file-operations.js'); /** * Process href differences and apply link fixes to documentation files * Uses the specified href-diffs.json file to determine what href transformations to apply * @param {number} majorVersion - Version number (e.g., 2, 3) * @param {string} differencesFile - Path to the href-diffs.json file */ function processHrefDifferences(majorVersion, differencesFile) { console.log(`🔗 Processing v${majorVersion} href differences and applying link fixes...`); let totalFilesProcessed = 0; let totalFixesApplied = 0; // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; if (!fs.existsSync(differencesFile)) { console.warn('⚠️ Href differences file not found:', differencesFile); console.log('Create the differences file first or check the path'); return; } // Load href differences const hrefDifferences = JSON.parse(fs.readFileSync(differencesFile, 'utf8')); console.log(`📋 Loaded ${hrefDifferences.length} v${majorVersion} href differences`); if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = processHrefDifferencesInDirectory(versionDir, hrefDifferences, majorVersion); totalFilesProcessed += result.filesProcessed; totalFixesApplied += result.fixesApplied; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = processHrefDifferencesInDirectory(translationVersionDir, hrefDifferences, majorVersion); totalFilesProcessed += result.filesProcessed; totalFixesApplied += result.fixesApplied; } }); } } console.log(`✅ Applied ${totalFixesApplied} href fixes across ${totalFilesProcessed} files`); } /** * Process href differences in a specific directory * @param {string} dirPath - Directory to process * @param {Array} hrefDifferences - Array of href difference objects * @param {number} majorVersion - Major version number * @returns {Object} - Results with filesProcessed and fixesApplied */ function processHrefDifferencesInDirectory(dirPath, hrefDifferences, majorVersion) { const files = findFiles(dirPath, ['.md', '.mdx']); // Group transformations by target file const fileTransforms = {}; hrefDifferences.forEach(diff => { // Only process actual path hrefs (skip components and regex patterns) if (!diff.after.includes('<') && !diff.after.includes('{{') && !diff.after.includes('\\(') && diff.after !== diff.before) { // Group by fileName if (!fileTransforms[diff.fileName]) { fileTransforms[diff.fileName] = {}; } fileTransforms[diff.fileName][diff.before] = diff.after; console.log(` ${diff.fileName}: ${diff.before} → ${diff.after}`); } }); const totalTransforms = Object.values(fileTransforms).reduce((sum, transforms) => sum + Object.keys(transforms).length, 0); console.log(`📋 Found ${totalTransforms} path transformations for ${Object.keys(fileTransforms).length} files`); let updatedCount = 0; let totalFixes = 0; files.forEach(filePath => { try { const relativePath = path.relative(dirPath, filePath); // Only apply transformations specific to this file if (!fileTransforms[relativePath]) { return; // No transformations for this file } let content = fs.readFileSync(filePath, 'utf8'); let hasChanges = false; // Apply transformations specific to this file Object.entries(fileTransforms[relativePath]).forEach(([fromPath, toPath]) => { // For v2: simple string replacement (no markdown link pattern matching needed) // For v3: look for markdown links containing the old path if (majorVersion === 2) { // V2 uses simple path replacements const beforeRegex = new RegExp(fromPath.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'g'); if (content.includes(fromPath)) { content = content.replace(beforeRegex, toPath); hasChanges = true; totalFixes++; } } else { // V3 uses markdown link pattern matching, but also handles raw text for special cases if (fromPath.includes('<') && fromPath.includes('>') || toPath === '') { // Special cases: // 1. Raw text replacement for angle bracket URLs (MDX compilation fixes) // 2. Text deletion (when toPath is empty string) const beforeRegex = new RegExp(fromPath.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'g'); if (content.includes(fromPath)) { content = content.replace(beforeRegex, toPath); hasChanges = true; totalFixes++; } } else { // Standard V3 markdown link pattern matching const escapedFrom = fromPath.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'); const linkPattern = new RegExp(`(\\[[^\\]]+\\])\\(${escapedFrom}\\)`, 'g'); if (content.includes(`](${fromPath})`)) { content = content.replace(linkPattern, `$1(${toPath})`); hasChanges = true; totalFixes++; } } } }); if (hasChanges) { fs.writeFileSync(filePath, content); console.log(` 🔗 Fixed hrefs: ${relativePath}`); updatedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); } }); return { filesProcessed: updatedCount, fixesApplied: totalFixes }; } module.exports = { processHrefDifferences }; ================================================ FILE: scripts/util/util-docusaurus-links.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); // Known categories in Helm docs (directories that should link to index.mdx) const HELM_CATEGORIES = [ 'intro', 'chart_best_practices', 'chart_template_guide', 'sdk', 'faq', 'howto', 'community', 'helm', 'topics', 'glossary' ]; /** * Check if a path refers to a category (should link to index.mdx) * @param {string} pathSegment - Path segment to check * @returns {boolean} - True if this is a category */ function isCategory(pathSegment) { // Remove trailing slash and leading ./ let cleanPath = pathSegment.replace(/\/$/, '').replace(/^\.\//, ''); // Check if it's a known category return HELM_CATEGORIES.includes(cleanPath); } /** * Convert category path to index.mdx path * @param {string} categoryPath - Category path * @param {number} currentDepth - Current file's depth * @param {string} relativePath - Current file's relative path * @returns {string} - Absolute path to category index */ function convertCategoryPath(categoryPath, currentDepth, relativePath) { // Handle anchors: category#anchor -> /category/index.mdx#anchor let cleanPath = categoryPath; let anchor = ''; if (cleanPath.includes('#')) { const parts = cleanPath.split('#'); cleanPath = parts[0]; anchor = '#' + parts.slice(1).join('#'); } // Remove trailing slash and leading ./ cleanPath = cleanPath.replace(/\/$/, '').replace(/^\.\//, ''); // Convert to absolute category index path const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath); return `${absolutePath}/index.mdx${anchor}`; } /** * Convert relative links to absolute Docusaurus paths * This addresses the Docusaurus bug: https://github.com/facebook/docusaurus/issues/10907 * @param {number} majorVersion - Version number (e.g., 3) */ function convertRelativeLinksToAbsolute(majorVersion) { console.log('🔗 Converting relative links to absolute Docusaurus paths...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let totalFilesProcessed = 0; let totalLinksConverted = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = processDirectoryLinks(versionDir); totalFilesProcessed += result.filesProcessed; totalLinksConverted += result.linksConverted; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = processDirectoryLinks(translationVersionDir); totalFilesProcessed += result.filesProcessed; totalLinksConverted += result.linksConverted; } }); } } console.log(`\n📊 Link conversion summary:`); console.log(` Files processed: ${totalFilesProcessed}`); console.log(` Links converted: ${totalLinksConverted}`); console.log('✅ Relative links converted to absolute paths'); } /** * Process links in a specific directory * @param {string} dirPath - Directory path to process * @returns {Object} - Results with filesProcessed and linksConverted */ function processDirectoryLinks(dirPath) { let filesProcessed = 0; let linksConverted = 0; /** * Recursively process directory for .md and .mdx files * @param {string} currentDir - Current directory to process */ function processDirectory(currentDir) { const entries = fs.readdirSync(currentDir, { withFileTypes: true }); entries.forEach(entry => { const fullPath = path.join(currentDir, entry.name); if (entry.isDirectory()) { // Recursively process subdirectories processDirectory(fullPath); } else if (entry.isFile() && (entry.name.endsWith('.md') || entry.name.endsWith('.mdx'))) { // Process markdown files const result = processMarkdownFile(fullPath, dirPath); if (result.modified) { filesProcessed++; linksConverted += result.linksConverted; } } }); } processDirectory(dirPath); return { filesProcessed, linksConverted }; } /** * Process a single markdown file for link conversion * @param {string} filePath - Full path to the file * @param {string} basePath - Base directory path for calculating relative positions * @returns {Object} - Results with modified flag and linksConverted count */ function processMarkdownFile(filePath, basePath) { try { const content = fs.readFileSync(filePath, 'utf8'); let modifiedContent = content; let linksConverted = 0; // Get the current file's directory relative to the base path const relativePath = path.relative(basePath, path.dirname(filePath)); const currentDepth = relativePath === '' ? 0 : relativePath.split(path.sep).length; // Regex patterns for different link types const patterns = [ // Standard markdown/mdx links: [text](file.md) or [text](../category/file.mdx) // But skip URLs with schemes (http://, https://, etc.) { regex: /\[([^\]]*)\]\(([^)]+\.mdx?(?:#[^)]*)?)\)/g, handler: (match, text, linkPath) => { // Skip URLs with schemes if (/^https?:\/\//.test(linkPath) || /^\w+:\/\//.test(linkPath)) { return match; // Return unchanged } return convertMarkdownLink(text, linkPath, currentDepth, relativePath); } }, // Hugo shortcode refs that weren't converted: {{< ref "file.md" >}} { regex: /\{\{<\s*ref\s+"([^"]+)"\s*>\}\}/g, handler: (match, linkPath) => { // Skip URLs with schemes if (/^https?:\/\//.test(linkPath) || /^\w+:\/\//.test(linkPath)) { return match; // Return unchanged } return `[${path.basename(linkPath, '.md')}](${convertToAbsolutePath(linkPath, currentDepth, relativePath)})`; } }, // Doc links without .md extension: [text](/docs/path) -> should become [text](/path.md) or [text](/path/index.mdx] // Handle anchors, trailing slashes, and categories properly { regex: /\[([^\]]*)\]\(\/docs\/([^)]+)\)/g, handler: (match, text, docPath) => { // Skip URLs with schemes if (/^https?:\/\//.test(docPath) || /^\w+:\/\//.test(docPath)) { return match; // Return unchanged } // Handle anchors: path#anchor -> path.md#anchor let cleanPath = docPath; let anchor = ''; if (cleanPath.includes('#')) { const parts = cleanPath.split('#'); cleanPath = parts[0]; anchor = '#' + parts.slice(1).join('#'); } // Remove trailing slash cleanPath = cleanPath.replace(/\/$/, ''); // Check if this is a category if (isCategory(cleanPath)) { return `[${text}](/${cleanPath}/index.mdx${anchor})`; } // Don't add .md if it already ends with .md or .mdx if (cleanPath.endsWith('.md') || cleanPath.endsWith('.mdx')) { return `[${text}](/${cleanPath}${anchor})`; } return `[${text}](/${cleanPath}.md${anchor})`; } }, // Blog links: [text](../blog/post) -> [text](/blog/post) { regex: /\[([^\]]*)\]\((\.\.\/)*blog\/([^)]+)\)/g, handler: (match, text, dots, blogPath) => `[${text}](/blog/${blogPath})` }, // Links that don't end in .md but should: [text](../category/file) -> [text](/category/file.md) // [text](file) -> [text](/current-category/file.md) // But skip URLs with schemes and anchors only { regex: /\[([^\]]*)\]\(([^)]+)\)/g, handler: (match, text, linkPath) => { // Skip URLs with schemes if (/^https?:\/\//.test(linkPath) || /^\w+:\/\//.test(linkPath)) { return match; // Return unchanged } // Skip links that are just anchors (#something) if (linkPath.startsWith('#')) { return match; // Return unchanged } // Skip if already ends with .md or .mdx (already handled by first pattern) if (linkPath.endsWith('.md') || linkPath.includes('.md#') || linkPath.endsWith('.mdx') || linkPath.includes('.mdx#')) { return match; // Return unchanged } // Skip blog links (handled by previous pattern) if (linkPath.includes('/blog/') || linkPath.match(/(\.\.\/)*blog\//)) { return match; // Return unchanged } // Skip if starts with /docs/ (handled by previous pattern) if (linkPath.startsWith('/docs/')) { return match; // Return unchanged } // Handle anchors: path#anchor -> path.md#anchor or category#anchor -> /category/index.mdx#anchor let cleanPath = linkPath; let anchor = ''; if (cleanPath.includes('#')) { const parts = cleanPath.split('#'); cleanPath = parts[0]; anchor = '#' + parts.slice(1).join('#'); } // Remove trailing slash and ./ cleanPath = cleanPath.replace(/\/$/, '').replace(/^\.\//, ''); // Check if this is a category (simple path without slashes) if (!cleanPath.includes('/') && isCategory(cleanPath)) { return `[${text}](${convertCategoryPath(linkPath, currentDepth, relativePath)})`; } // For relative category paths like ../category or ./category const pathParts = cleanPath.split('/'); const lastSegment = pathParts[pathParts.length - 1]; if (isCategory(lastSegment)) { return `[${text}](${convertCategoryPath(linkPath, currentDepth, relativePath)})`; } // Add .md extension for non-category files cleanPath = cleanPath + '.md'; const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath); return `[${text}](${absolutePath}${anchor})`; } } ]; // Apply each pattern patterns.forEach(({ regex, handler }) => { modifiedContent = modifiedContent.replace(regex, (...args) => { const originalMatch = args[0]; const convertedLink = handler(...args); if (convertedLink !== originalMatch) { linksConverted++; } return convertedLink; }); }); // Write file if modified if (modifiedContent !== content) { fs.writeFileSync(filePath, modifiedContent); const relativePath = path.relative(basePath, filePath); console.log(` 🔗 Updated links: ${relativePath} (${linksConverted} links)`); return { modified: true, linksConverted }; } return { modified: false, linksConverted: 0 }; } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); return { modified: false, linksConverted: 0 }; } } /** * Convert markdown link to absolute path * @param {string} text - Link text * @param {string} linkPath - Original link path * @param {number} currentDepth - Current file's depth in directory structure * @param {string} relativePath - Current file's relative path * @returns {string} - Converted markdown link */ function convertMarkdownLink(text, linkPath, currentDepth, relativePath) { // Handle anchors: file.md#anchor -> /path/file.md#anchor let cleanPath = linkPath; let anchor = ''; if (cleanPath.includes('#')) { const parts = cleanPath.split('#'); cleanPath = parts[0]; anchor = '#' + parts.slice(1).join('#'); } const absolutePath = convertToAbsolutePath(cleanPath, currentDepth, relativePath); return `[${text}](${absolutePath}${anchor})`; } /** * Convert relative path to absolute Docusaurus path * @param {string} linkPath - Original link path (relative) * @param {number} currentDepth - Current file's depth in directory structure * @param {string} relativePath - Current file's relative path * @returns {string} - Absolute path for Docusaurus */ function convertToAbsolutePath(linkPath, currentDepth, relativePath) { // Handle different link patterns if (linkPath.startsWith('/')) { // Already absolute return linkPath; } if (linkPath.startsWith('../')) { // Parent directory references: ../category/file.md or ../file.md const pathParts = linkPath.split('/'); const upLevels = pathParts.filter(part => part === '..').length; const remainingPath = pathParts.slice(upLevels).join('/'); if (upLevels >= currentDepth) { // Goes to root or beyond return `/${remainingPath}`; } else { // Stays within subdirectories const currentParts = relativePath.split(path.sep); const targetParts = currentParts.slice(0, currentParts.length - upLevels); return `/${targetParts.join('/')}${targetParts.length > 0 ? '/' : ''}${remainingPath}`; } } else { // Same directory or subdirectory: file.md, ./file.md, or subdir/file.md let cleanPath = linkPath; // Normalize ./filename.md to filename.md if (cleanPath.startsWith('./')) { cleanPath = cleanPath.substring(2); } if (relativePath === '') { // Root level return `/${cleanPath}`; } else { // In subdirectory return `/${relativePath}/${cleanPath}`; } } } module.exports = { convertRelativeLinksToAbsolute }; ================================================ FILE: scripts/util/util-file-operations.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); /** * Recursively find all files matching extensions in a directory * @param {string} dir - Directory to search * @param {string[]} extensions - File extensions to match (e.g., ['.md', '.mdx']) * @returns {string[]} - Array of file paths */ function findFiles(dir, extensions = ['.md', '.mdx']) { const files = []; function traverse(currentDir) { const entries = fs.readdirSync(currentDir, { withFileTypes: true }); entries.forEach(entry => { const fullPath = path.join(currentDir, entry.name); if (entry.isDirectory()) { traverse(fullPath); } else if (entry.isFile()) { const ext = path.extname(entry.name); if (extensions.includes(ext)) { files.push(fullPath); } } }); } if (fs.existsSync(dir)) { traverse(dir); } return files; } /** * Move directory contents from source to destination * @param {string} sourceDir - Source directory * @param {string} destDir - Destination directory */ function moveDirectoryContents(sourceDir, destDir) { if (!fs.existsSync(sourceDir)) { console.warn(`⚠️ Source directory not found: ${sourceDir}`); return; } // Ensure destination directory exists fs.mkdirSync(destDir, { recursive: true }); const entries = fs.readdirSync(sourceDir); let movedCount = 0; entries.forEach(entry => { const sourcePath = path.join(sourceDir, entry); const destPath = path.join(destDir, entry); fs.renameSync(sourcePath, destPath); movedCount++; }); console.log(`📁 Moved ${movedCount} items from ${sourceDir} to ${destDir}`); } /** * Remove directory and all its contents * @param {string} dir - Directory to remove */ function removeDirectory(dir) { if (fs.existsSync(dir)) { fs.rmSync(dir, { recursive: true, force: true }); console.log(`🗑️ Removed directory: ${dir}`); } } /** * Create directory (and parent directories if needed) * @param {string} dir - Directory to create */ function createDirectory(dir) { fs.mkdirSync(dir, { recursive: true }); console.log(`📁 Created directory: ${dir}`); } /** * Copy file from source to destination * @param {string} sourceFile - Source file path * @param {string} destFile - Destination file path */ function copyFile(sourceFile, destFile) { // Ensure destination directory exists const destDir = path.dirname(destFile); fs.mkdirSync(destDir, { recursive: true }); fs.copyFileSync(sourceFile, destFile); console.log(`📋 Copied: ${sourceFile} → ${destFile}`); } /** * Rename/move a file * @param {string} oldPath - Current file path * @param {string} newPath - New file path */ function renameFile(oldPath, newPath) { if (fs.existsSync(oldPath)) { // Ensure destination directory exists const destDir = path.dirname(newPath); fs.mkdirSync(destDir, { recursive: true }); fs.renameSync(oldPath, newPath); console.log(`🔄 Renamed: ${oldPath} → ${newPath}`); } else { console.warn(`⚠️ File not found for rename: ${oldPath}`); } } module.exports = { findFiles, moveDirectoryContents, removeDirectory, createDirectory, copyFile, renameFile }; ================================================ FILE: scripts/util/util-frontmatter.js ================================================ #!/usr/bin/env node const yaml = require('js-yaml'); /** * Parse frontmatter from content, returning both the YAML data and the rest of the content * @param {string} content - File content * @returns {Object} - { frontmatter: Object, restContent: string, hasFrontmatter: boolean } */ function frontMatterFromYaml(content) { const lines = content.split('\n'); // Find frontmatter boundaries let frontmatterStart = -1; let frontmatterEnd = -1; let dashCount = 0; for (let i = 0; i < lines.length; i++) { if (lines[i].trim() === '---') { dashCount++; if (dashCount === 1) { frontmatterStart = i; } else if (dashCount === 2) { frontmatterEnd = i; break; } } } if (frontmatterStart === -1 || frontmatterEnd === -1) { // No frontmatter found return { frontmatter: {}, restContent: content, hasFrontmatter: false }; } const frontmatterText = lines.slice(frontmatterStart + 1, frontmatterEnd).join('\n'); const restContent = lines.slice(frontmatterEnd + 1).join('\n'); try { const frontmatter = yaml.load(frontmatterText) || {}; return { frontmatter, restContent, hasFrontmatter: true }; } catch (error) { console.error(' ❌ Error parsing YAML frontmatter:', error.message); return { frontmatter: {}, restContent: content, hasFrontmatter: false }; } } /** * Convert YAML data back to frontmatter content * @param {Object} frontmatter - YAML data object * @param {string} restContent - The rest of the content after frontmatter * @returns {string} - Complete content with frontmatter */ function frontMatterToYaml(frontmatter, restContent) { if (!frontmatter || Object.keys(frontmatter).length === 0) { // No frontmatter to add, return just the content return restContent; } const frontmatterYaml = yaml.dump(frontmatter, { indent: 2, lineWidth: 120, quotingType: '"', forceQuotes: false }).trim(); return `---\n${frontmatterYaml}\n---\n${restContent}`; } module.exports = { frontMatterFromYaml, frontMatterToYaml }; ================================================ FILE: scripts/util/util-migration.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { execSync } = require('child_process'); const { findFiles, moveDirectoryContents, removeDirectory, createDirectory } = require('./util-file-operations.js'); const { frontMatterFromYaml, frontMatterToYaml } = require('./util-frontmatter.js'); /** * Clean up version directory for fresh migration * @param {number} majorVersion - Version number (e.g., 2, 3) */ function startFresh(majorVersion) { console.log('🔄 Starting fresh migration...'); const versionDir = `versioned_docs/version-${majorVersion}`; // Remove version directory and recreate removeDirectory(versionDir); createDirectory(versionDir); console.log('✅ Fresh migration setup completed'); } /** * Restore source content for specified version to orig/ directory * @param {number} majorVersion - Version number (2 or 3) */ function restoreSourceContent(majorVersion) { console.log(`📥 Restoring v${majorVersion} source content...`); // Clean and create orig directory structure removeDirectory('orig'); execSync('mkdir -p orig', { stdio: 'inherit' }); if (majorVersion === 2) { // Clone helm2 repository console.log('📥 Cloning Helm v2 repository...'); try { execSync('git clone --single-branch --branch release-2.17 https://github.com/helm/helm.git helm2', { stdio: 'inherit' }); execSync('mv helm2/docs orig/docs-v2', { stdio: 'inherit' }); removeDirectory('helm2'); console.log('✅ v2 source content restored to orig/docs-v2'); } catch (error) { console.error('❌ Failed to clone Helm v2 repository:', error.message); process.exit(1); } } else if (majorVersion === 3) { // Restore content from git main console.log('📥 Restoring v3 content from git main...'); execSync('git restore --source main -- content/en/docs', { stdio: 'inherit' }); execSync('mv content/en/docs orig/docs-v3', { stdio: 'inherit' }); removeDirectory('content/en'); console.log('✅ v3 source content restored to orig/docs-v3'); } else { console.error(`❌ Unsupported major version: ${majorVersion}`); process.exit(1); } } /** * Setup Docusaurus versioned structure (idempotent) * Creates version in versions.json, versioned_docs, and versioned_sidebars * @param {number} majorVersion - Version number (e.g., 3) */ function skaffoldMajorVersion(majorVersion = 3) { console.log('📁 Setting up Docusaurus version structure...'); const versionDir = `versioned_docs/version-${majorVersion}`; if (!fs.existsSync(versionDir)) { // Create Docusaurus version structure execSync(`yarn docusaurus docs:version ${majorVersion}`, { stdio: 'inherit' }); // Empty the directory but keep the structure const files = fs.readdirSync(versionDir); files.forEach(file => { const filePath = path.join(versionDir, file); fs.rmSync(filePath, { recursive: true, force: true }); }); console.log('✅ Docusaurus version structure created'); } else { console.log('⏭️ Docusaurus version structure already exists'); } } /** * Move content from Hugo structure to Docusaurus structure * @param {number} majorVersion - Version number (e.g., 3) */ function moveDocs(majorVersion = 3) { console.log('📦 Moving docs from Hugo to Docusaurus structure...'); const sourceDir = `orig/docs-v${majorVersion}`; const versionDir = `versioned_docs/version-${majorVersion}`; if (fs.existsSync(sourceDir)) { moveDirectoryContents(sourceDir, versionDir); console.log('✅ Docs moved successfully'); } else { console.warn('⚠️ Source docs directory not found'); } } /** * Delete files with 'section: deprecated' frontmatter * Hugo hid these files, Docusaurus doesn't have this feature * @param {number} majorVersion - Version number (e.g., 3) */ function deleteDeprecatedFiles(majorVersion = 3) { console.log('🗑️ Removing deprecated files...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let deletedCount = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = deleteDeprecatedFilesInDirectory(versionDir); deletedCount += result.deletedCount; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = deleteDeprecatedFilesInDirectory(translationVersionDir); deletedCount += result.deletedCount; } }); } } console.log(`✅ Removed ${deletedCount} deprecated files`); } /** * Delete deprecated files in a specific directory * @param {string} dirPath - Directory path to process * @returns {Object} - Results with deletedCount */ function deleteDeprecatedFilesInDirectory(dirPath) { const files = findFiles(dirPath, ['.md', '.mdx']); let deletedCount = 0; files.forEach(filePath => { try { const content = fs.readFileSync(filePath, 'utf8'); const { frontmatter, hasFrontmatter } = frontMatterFromYaml(content); if (hasFrontmatter && frontmatter.section === 'deprecated') { fs.unlinkSync(filePath); console.log(` 🗑️ Deleted: ${path.relative(dirPath, filePath)}`); deletedCount++; } } catch (error) { console.warn(` ⚠️ Error checking ${filePath}: ${error.message}`); } }); return { deletedCount }; } /** * Replace Hugo 'weight:' frontmatter with Docusaurus 'sidebar_position:' * @param {number} majorVersion - Version number (e.g., 3) */ function replaceWeightWithSidebarPosition(majorVersion = 3) { console.log('🔄 Converting weight → sidebar_position in frontmatter...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let updatedCount = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = replaceWeightInDirectory(versionDir); updatedCount += result.updatedCount; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = replaceWeightInDirectory(translationVersionDir); updatedCount += result.updatedCount; } }); } } console.log(`✅ Updated ${updatedCount} files with sidebar_position`); } /** * Replace weight with sidebar_position in a specific directory * @param {string} dirPath - Directory path to process * @returns {Object} - Results with updatedCount */ function replaceWeightInDirectory(dirPath) { const files = findFiles(dirPath, ['.md', '.mdx']); let updatedCount = 0; files.forEach(filePath => { try { const content = fs.readFileSync(filePath, 'utf8'); const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content); if (hasFrontmatter && frontmatter.hasOwnProperty('weight')) { // Replace weight with sidebar_position frontmatter.sidebar_position = frontmatter.weight; delete frontmatter.weight; const updatedContent = frontMatterToYaml(frontmatter, restContent); fs.writeFileSync(filePath, updatedContent); console.log(` 🔄 Updated: ${path.relative(dirPath, filePath)}`); updatedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); } }); return { updatedCount }; } /** * Add metadata to main index file (_index.md → index.mdx) * @param {number} majorVersion - Version number (e.g., 3) */ function addMainIndexMetadata(majorVersion = 3) { console.log('📝 Adding metadata to main index file...'); const versionDir = `versioned_docs/version-${majorVersion}`; const indexPath = path.join(versionDir, 'index.mdx'); if (fs.existsSync(indexPath)) { const content = fs.readFileSync(indexPath, 'utf8'); const { frontmatter, restContent } = frontMatterFromYaml(content); // Add required metadata (frontmatter only) frontmatter.sidebar_position = 1; if (!frontmatter.title) { frontmatter.title = 'Documentation'; } const updatedContent = frontMatterToYaml(frontmatter, restContent); fs.writeFileSync(indexPath, updatedContent); console.log('✅ Main index file metadata updated'); } else { console.warn('⚠️ Main index file (index.mdx) not found'); } } /** * Add components to category index pages * Reproduces Hugo's automatic page listing functionality * @param {number} majorVersion - Version number (e.g., 3) */ function addDocsIndexLists(majorVersion = 3) { console.log('📋 Adding DocCardList components to index pages...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let updatedCount = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = addDocCardListInDirectory(versionDir); updatedCount += result.updatedCount; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = addDocCardListInDirectory(translationVersionDir); updatedCount += result.updatedCount; } }); } } console.log(`✅ Added DocCardList to ${updatedCount} index pages`); } /** * Add DocCardList components in a specific directory * @param {string} dirPath - Directory path to process * @returns {Object} - Results with updatedCount */ function addDocCardListInDirectory(dirPath) { // Find all index.mdx files (category pages) const indexFiles = []; function findIndexFiles(dir) { const entries = fs.readdirSync(dir, { withFileTypes: true }); entries.forEach(entry => { if (entry.isDirectory()) { const indexPath = path.join(dir, entry.name, 'index.mdx'); if (fs.existsSync(indexPath)) { indexFiles.push(indexPath); } findIndexFiles(path.join(dir, entry.name)); } }); } findIndexFiles(dirPath); // Also add the root index.mdx file if it exists const rootIndexPath = path.join(dirPath, 'index.mdx'); if (fs.existsSync(rootIndexPath)) { indexFiles.push(rootIndexPath); } let updatedCount = 0; indexFiles.forEach(filePath => { try { const content = fs.readFileSync(filePath, 'utf8'); // Check if DocCardList is already present if (!content.includes('DocCardList')) { // Simply append import and component to the end const updatedContent = content + '\n\nimport DocCardList from \'@theme/DocCardList\';\n\n\n'; fs.writeFileSync(filePath, updatedContent); console.log(` 📋 Added DocCardList: ${path.relative(dirPath, filePath)}`); updatedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); } }); return { updatedCount }; } /** * Import SDK examples from .go files to .mdx files with code blocks * Also renames examples.md to examples.mdx and adds imports * @param {number} majorVersion - Version number (e.g., 3) */ function importSDK(majorVersion = 3) { console.log('💻 Importing SDK examples...'); const versionDir = `versioned_docs/version-${majorVersion}`; const sdkDir = path.join(versionDir, 'sdk'); const examplesFile = path.join(sdkDir, 'examples.md'); const examplesFileNew = path.join(sdkDir, 'examples.mdx'); const sdkExamplesDir = 'sdkexamples'; if (!fs.existsSync(sdkExamplesDir)) { console.warn('⚠️ SDK examples source directory not found'); return; } if (!fs.existsSync(sdkDir)) { console.warn('⚠️ SDK docs directory not found'); return; } // Find all .go files in sdkexamples/ const goFiles = fs.readdirSync(sdkExamplesDir) .filter(file => file.endsWith('.go')) .filter(file => file !== 'main.go'); // Skip main.go let importLines = []; let processedCount = 0; // Process each .go file goFiles.forEach(goFile => { try { const name = path.basename(goFile, '.go'); const sourcePath = path.join(sdkExamplesDir, goFile); const destPath = path.join(sdkDir, `_${name}.mdx`); // Read the .go file content const goContent = fs.readFileSync(sourcePath, 'utf8'); // Wrap in code block const mdxContent = '```go\n' + goContent + '\n```\n'; // Write to destination fs.writeFileSync(destPath, mdxContent); // Create import line with capitalized name const capName = name.charAt(0).toUpperCase() + name.slice(1); importLines.push(`import ${capName} from './_${name}.mdx'`); console.log(` 💻 Processed: ${goFile} → _${name}.mdx`); processedCount++; } catch (error) { console.warn(` ⚠️ Error processing ${goFile}: ${error.message}`); } }); // Rename examples.md to examples.mdx and add imports if (fs.existsSync(examplesFile)) { try { const content = fs.readFileSync(examplesFile, 'utf8'); const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content); if (hasFrontmatter) { // Add imports after frontmatter const importsSection = importLines.join('\n') + '\n\n'; // Remove any existing import lines from restContent const cleanedContent = restContent.replace(/^import .* from '\.\/_.*.mdx';?\n?/gm, ''); const newRestContent = importsSection + cleanedContent.trim(); const updatedContent = frontMatterToYaml(frontmatter, newRestContent); fs.writeFileSync(examplesFileNew, updatedContent); fs.unlinkSync(examplesFile); // Remove old file console.log(' 📝 Updated examples.mdx with imports'); } } catch (error) { console.warn(` ⚠️ Error updating examples file: ${error.message}`); } } console.log(`✅ Imported ${processedCount} SDK examples`); } /** * Rename Hugo _index.md files to Docusaurus index.mdx in preparation for DocCardList * @param {number} majorVersion - Version number (e.g., 3) */ function renameIndexFilesToMdx(majorVersion = 3) { console.log('🔄 Renaming Hugo _index.md → Docusaurus index.mdx files...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let renamedCount = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = renameIndexFilesInDirectory(versionDir); renamedCount += result.renamedCount; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = renameIndexFilesInDirectory(translationVersionDir); renamedCount += result.renamedCount; } }); } } console.log(`✅ Renamed ${renamedCount} Hugo index files to Docusaurus .mdx`); } /** * Rename index files in a specific directory * @param {string} dirPath - Directory path to process * @returns {Object} - Results with renamedCount */ function renameIndexFilesInDirectory(dirPath) { // Find all _index.md and index.md files that should become index.mdx const indexFiles = []; function findIndexFiles(dir) { const entries = fs.readdirSync(dir, { withFileTypes: true }); entries.forEach(entry => { if (entry.isDirectory()) { findIndexFiles(path.join(dir, entry.name)); } else if (entry.name === '_index.md' || entry.name === 'index.md') { indexFiles.push(path.join(dir, entry.name)); } }); } findIndexFiles(dirPath); let renamedCount = 0; indexFiles.forEach(filePath => { const newPath = filePath.replace(/(_index\.md|index\.md)$/, 'index.mdx'); fs.renameSync(filePath, newPath); const originalName = path.basename(filePath); console.log(` 🔄 Renamed: ${path.relative(dirPath, filePath)} → index.mdx`); renamedCount++; }); return { renamedCount }; } /** * Rename commands directories to helm in i18n translations * This fixes structural inconsistencies in i18n directories where some languages * have a top-level "commands" directory instead of "helm" * @param {number} majorVersion - Major version number (e.g., 3) */ function renameCommandsToHelm(majorVersion) { console.log('🔧 Renaming commands directories to helm in i18n directories...'); const i18nDir = 'i18n'; if (!fs.existsSync(i18nDir)) { console.log(' ⏭️ No i18n directory found, skipping'); return; } const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); let renamedCount = 0; languages.forEach(lang => { const commandsDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}/commands`; const helmDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}/helm`; if (fs.existsSync(commandsDir)) { console.log(` 🔄 Renaming ${lang}: commands → helm`); if (fs.existsSync(helmDir)) { console.log(` ⚠️ Warning: ${lang} has both commands and helm directories, merging...`); // Move all files from commands to helm const files = fs.readdirSync(commandsDir); files.forEach(file => { const oldPath = path.join(commandsDir, file); const newPath = path.join(helmDir, file); if (!fs.existsSync(newPath)) { fs.renameSync(oldPath, newPath); } else { console.log(` ⚠️ Skipping ${file} (already exists in helm directory)`); } }); } else { // Simply rename commands to helm fs.renameSync(commandsDir, helmDir); } // Remove empty commands directory if it still exists if (fs.existsSync(commandsDir)) { try { fs.rmdirSync(commandsDir); } catch (error) { // Directory might not be empty, that's okay } } renamedCount++; } }); if (renamedCount > 0) { console.log(`✅ Renamed commands to helm in ${renamedCount} language(s)`); } else { console.log(' ✅ No commands directories found to rename'); } } module.exports = { startFresh, restoreSourceContent, skaffoldMajorVersion, moveDocs, deleteDeprecatedFiles, replaceWeightWithSidebarPosition, addMainIndexMetadata, addDocsIndexLists, renameIndexFilesToMdx, renameCommandsToHelm }; ================================================ FILE: scripts/util/util-text-replacements.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { findFiles } = require('./util-file-operations.js'); /** * Category A: Replace Hugo shortcodes with their content * Reliably converts: {{< ref "path" >}} → path * Also converts: {{< highlightexamplego file="path" >}} → path * Handles multi-line shortcodes and escape characters * @param {number} majorVersion - Version number (e.g., 3) */ function replaceHugoShortcodes(majorVersion = 3) { console.log('🔗 Converting Hugo shortcodes...'); // Process main version docs const versionDir = `versioned_docs/version-${majorVersion}`; let updatedCount = 0; let totalReplacements = 0; if (fs.existsSync(versionDir)) { console.log(` 📁 Processing main docs: ${versionDir}`); const result = processHugoShortcodesInDirectory(versionDir); updatedCount += result.updatedCount; totalReplacements += result.totalReplacements; } // Process translation docs (only for v3 and above) if (majorVersion >= 3) { const i18nDir = 'i18n'; if (fs.existsSync(i18nDir)) { const languages = fs.readdirSync(i18nDir, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const translationVersionDir = `${i18nDir}/${lang}/docusaurus-plugin-content-docs/version-${majorVersion}`; if (fs.existsSync(translationVersionDir)) { console.log(` 🌐 Processing ${lang} translations: ${translationVersionDir}`); const result = processHugoShortcodesInDirectory(translationVersionDir); updatedCount += result.updatedCount; totalReplacements += result.totalReplacements; } }); } } console.log(`✅ Converted ${totalReplacements} Hugo shortcodes in ${updatedCount} files`); } /** * Process Hugo shortcodes in a specific directory * @param {string} dirPath - Directory to process * @returns {Object} - Results with updatedCount and totalReplacements */ function processHugoShortcodesInDirectory(dirPath) { const files = findFiles(dirPath, ['.md', '.mdx']); let updatedCount = 0; let totalReplacements = 0; files.forEach(filePath => { try { let content = fs.readFileSync(filePath, 'utf8'); let hasChanges = false; const originalContent = content; // Find multiline Hugo shortcodes: {{< ref\n"path" >}} and regular ones let searchIndex = 0; while (true) { const startIndex = content.indexOf('{{<', searchIndex); if (startIndex === -1) break; // Find the matching closing >}} const endIndex = content.indexOf('>}}', startIndex); if (endIndex === -1) { console.warn(` ⚠️ Unclosed Hugo shortcode at position ${startIndex}`); searchIndex = startIndex + 3; continue; } // Extract the full shortcode const shortcode = content.substring(startIndex, endIndex + 3); let replacement = null; // Handle ref shortcodes: {{< ref "path" >}} or {{< relref path="path" lang="en">}} → path if (shortcode.includes('ref')) { // Handle both ref and relref shortcodes let pathMatch; // Try relref pattern first: {{< relref path="/docs/path.md" lang="en">}} if (shortcode.includes('relref') && shortcode.includes('path=')) { pathMatch = shortcode.match(/path="([^"]+)"/); } else { // Standard ref pattern: {{< ref "path" >}} pathMatch = shortcode.match(/"([^"]+)"/); } if (pathMatch) { replacement = pathMatch[1].replace(/[\\()]/g, ''); // Strip escape characters } } // Handle highlightexamplego shortcodes: {{< highlightexamplego file="path" >}} → path else if (shortcode.includes('highlightexamplego')) { const fileMatch = shortcode.match(/file="([^"]+)"/); if (fileMatch) { replacement = fileMatch[1].replace(/[\\()]/g, ''); // Strip escape characters } } if (replacement !== null) { // Replace the entire shortcode with the extracted path content = content.substring(0, startIndex) + replacement + content.substring(endIndex + 3); hasChanges = true; totalReplacements++; console.log(` 🔗 ${shortcode.replace(/\n/g, '\\n').substring(0, 50)}... → ${replacement}`); // Adjust search index since content length changed searchIndex = startIndex + replacement.length; } else { // No replacement made, continue searching searchIndex = endIndex + 3; } } if (hasChanges) { fs.writeFileSync(filePath, content); console.log(` 🔗 Updated: ${path.relative(dirPath, filePath)}`); updatedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); } }); return { updatedCount, totalReplacements }; } /** * Category C: Fix markdown link hrefs based on href differences * Uses the shared href processor to apply link fixes * @param {number} majorVersion - Version number (e.g., 3) */ function fixMarkdownLinkHrefs(majorVersion = 3) { const path = require('path'); const { processHrefDifferences } = require('./href-diffs-process.js'); const differencesFile = path.join(__dirname, `../v${majorVersion}/href-diffs.json`); processHrefDifferences(majorVersion, differencesFile); } /** * Master function to handle all text replacements * @param {number} majorVersion - Version number (e.g., 3) */ function applyAllTextReplacements(majorVersion = 3) { console.log('📖 Applying all text replacements...'); // Step 1: Fix markdown link hrefs BEFORE Hugo shortcode conversion // This allows href-diffs to catch /docs/ paths inside shortcodes fixMarkdownLinkHrefs(majorVersion); // Step 2: Convert Hugo shortcodes to standard content replaceHugoShortcodes(majorVersion); console.log('✅ All text replacements completed'); } module.exports = { replaceHugoShortcodes, fixMarkdownLinkHrefs, applyAllTextReplacements }; ================================================ FILE: scripts/v2/copy-files.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); /** * Copy script that uses menu.json with header extraction to find and copy files * Matches headers to local markdown files and creates proper Docusaurus structure */ function copyV2DocsToDocusaurus() { console.log('📋 Starting v2 docs copy to Docusaurus...'); // Read the menu.json structure const structureFile = path.join(__dirname, 'menu.json'); if (!fs.existsSync(structureFile)) { console.error('❌ menu.json not found. Run menu-generate.js first.'); process.exit(1); } const menuData = JSON.parse(fs.readFileSync(structureFile, 'utf8')); const navigationStructure = menuData.navigationStructure; const helm2DocsPath = path.join(__dirname, '..', '..', 'orig', 'docs-v2'); const outputPath = path.join(__dirname, '..', '..', 'versioned_docs', 'version-2'); if (!fs.existsSync(helm2DocsPath)) { console.error('❌ orig/docs-v2 directory not found'); process.exit(1); } // Clean and create output directory if (fs.existsSync(outputPath)) { fs.rmSync(outputPath, { recursive: true, force: true }); console.log('🗑️ Cleaned existing version-2 directory'); } fs.mkdirSync(outputPath, { recursive: true }); // Create index.mdx file createIndexFile(outputPath); console.log('📄 Created index.mdx file'); // Build file header mapping from orig/docs-v2 console.log('🔍 Building header-to-file mapping from local markdown files...'); const headerToFileMap = buildHeaderFileMap(helm2DocsPath); console.log(`📊 Found ${Object.keys(headerToFileMap).size} headers in ${headerToFileMap._totalFiles} files`); let topLevelPosition = 2; // Start at 2 since index.mdx takes position 1 let copiedFiles = 0; navigationStructure.forEach(item => { if (item.children && item.children.length > 0) { // This is a category with children const categoryName = extractCategoryFromUrlPath(item.link); if (categoryName) { copiedFiles += processCategoryWithChildren(item, categoryName, outputPath, helm2DocsPath, headerToFileMap, topLevelPosition); topLevelPosition++; } } else { // This is a top-level file without children copiedFiles += processTopLevelFile(item, outputPath, helm2DocsPath, headerToFileMap, topLevelPosition); topLevelPosition++; } }); console.log(`✅ Successfully copied ${copiedFiles} files to ${outputPath}`); console.log('🚀 Ready for Docusaurus!'); } /** * Build a mapping of headers to file paths by scanning all markdown files */ function buildHeaderFileMap(docsPath) { const headerMap = {}; let totalFiles = 0; function scanDirectory(dir, relativePath = '') { const items = fs.readdirSync(dir); items.forEach(item => { const fullPath = path.join(dir, item); const stat = fs.statSync(fullPath); if (stat.isDirectory()) { scanDirectory(fullPath, path.join(relativePath, item)); } else if (item.endsWith('.md')) { totalFiles++; const relativeFilePath = path.join(relativePath, item); try { const content = fs.readFileSync(fullPath, 'utf8'); const header = extractHeaderFromContent(content); if (!header) { console.error(`❌ No H1 or H2 header found in ${relativeFilePath} - script halted`); process.exit(1); } if (headerMap[header]) { console.warn(`⚠️ Duplicate header found: "${header}" in both ${headerMap[header]} and ${relativeFilePath}`); } else { headerMap[header] = relativeFilePath; } } catch (error) { console.warn(`⚠️ Error reading ${relativeFilePath}: ${error.message}`); } } }); } scanDirectory(docsPath); headerMap._totalFiles = totalFiles; return headerMap; } /** * Extract the primary header from markdown content: first H1, or first H2 if no H1 exists */ function extractHeaderFromContent(content) { const lines = content.split('\n'); // First pass: look for H1 for (const line of lines) { const h1Match = line.match(/^#\s+(.+)$/); if (h1Match) { return h1Match[1].trim(); } } // Second pass: look for H2 if no H1 found for (const line of lines) { const h2Match = line.match(/^##\s+(.+)$/); if (h2Match) { return h2Match[1].trim(); } } // No H1 or H2 found return null; } /** * Extract category name from URL path like /docs/using_helm/ → using_helm */ function extractCategoryFromUrlPath(urlPath) { if (!urlPath) return null; const match = urlPath.match(/\/docs\/([^\/]+)\//); return match ? match[1] : null; } /** * Process a category (parent with children) */ function processCategoryWithChildren(categoryItem, categoryName, outputPath, helm2DocsPath, headerToFileMap, categoryPosition) { console.log(`📁 Processing category: ${categoryItem.label} (${categoryName})`); const categoryDir = path.join(outputPath, categoryName); fs.mkdirSync(categoryDir, { recursive: true }); let copiedCount = 0; let childPosition = 1; // First child becomes the index file for the category const indexChild = categoryItem.children[0]; categoryItem.children.forEach((child, index) => { const isIndex = index === 0; const headerToMatch = child.header || child.label; // Find the source file using header matching const sourceFile = findSourceFileByHeader(headerToMatch, headerToFileMap); if (!sourceFile) { console.log(` ⚠️ No source file found for header: "${headerToMatch}"`); return; } const sourcePath = path.join(helm2DocsPath, sourceFile); if (!fs.existsSync(sourcePath)) { console.log(` ⚠️ Source file not found: ${sourceFile}`); return; } let targetFileName; let sidebarPosition; if (isIndex) { // This is the index file - rename it to category/category.md targetFileName = `${categoryName}.md`; sidebarPosition = categoryPosition; // Use parent's position console.log(` 📄 Index: ${child.label} → ${categoryName}/${targetFileName} (${sourceFile})`); } else { // Regular child file const baseFileName = path.basename(sourceFile, '.md'); targetFileName = `${baseFileName}.md`; sidebarPosition = childPosition++; console.log(` 📄 Child: ${child.label} → ${categoryName}/${targetFileName} (${sourceFile})`); } const targetPath = path.join(categoryDir, targetFileName); if (copyFileWithFrontmatter(sourcePath, targetPath, { position: sidebarPosition, label: isIndex ? categoryItem.label : child.label, // Use parent label for index slug: isIndex ? undefined : undefined // Index files should have no slug }, isIndex)) { copiedCount++; } }); return copiedCount; } /** * Process a top-level file (no children) */ function processTopLevelFile(item, outputPath, helm2DocsPath, headerToFileMap, position) { console.log(`📄 Processing top-level: ${item.label}`); // Special handling for "Docs Home" - already created if (item.label === "Docs Home") { console.log(` ✅ Docs Home already created as index.mdx`); return 0; } const headerToMatch = item.header || item.label; const sourceFile = findSourceFileByHeader(headerToMatch, headerToFileMap); if (!sourceFile) { console.log(` ⚠️ No source file found for header: "${headerToMatch}"`); return 0; } const sourcePath = path.join(helm2DocsPath, sourceFile); if (!fs.existsSync(sourcePath)) { console.log(` ⚠️ Source file not found: ${sourceFile}`); return 0; } const targetFileName = path.basename(sourceFile); const targetPath = path.join(outputPath, targetFileName); console.log(` 📄 ${item.label} → ${targetFileName} (${sourceFile})`); if (copyFileWithFrontmatter(sourcePath, targetPath, { position: position, label: item.label }, false)) { return 1; } return 0; } /** * Normalize smart quotes to regular quotes */ function normalizeQuotes(text) { return text .replace(/[""]/g, '"') // Smart double quotes (U+201C, U+201D) → regular double quotes .replace(/['']/g, "'") // Smart single quotes (U+2018, U+2019) → regular single quotes .replace(/\u2019/g, "'") // Right single quotation mark (U+2019) → regular single quote .replace(/\u2018/g, "'") // Left single quotation mark (U+2018) → regular single quote .replace(/\u201C/g, '"') // Left double quotation mark (U+201C) → regular double quote .replace(/\u201D/g, '"'); // Right double quotation mark (U+201D) → regular double quote } /** * Find source file by matching header text */ function findSourceFileByHeader(headerText, headerToFileMap) { // Normalize smart quotes in the search text const normalizedHeaderText = normalizeQuotes(headerText); // Direct match first (try both original and normalized) if (headerToFileMap[headerText]) { return headerToFileMap[headerText]; } if (headerToFileMap[normalizedHeaderText]) { return headerToFileMap[normalizedHeaderText]; } // Try case-insensitive match (with both original and normalized) const lowerHeaderText = headerText.toLowerCase(); const lowerNormalizedHeaderText = normalizedHeaderText.toLowerCase(); for (const [header, file] of Object.entries(headerToFileMap)) { if (header !== '_totalFiles') { const lowerHeader = header.toLowerCase(); if (lowerHeader === lowerHeaderText || lowerHeader === lowerNormalizedHeaderText) { return file; } } } // Try partial match for helm commands (remove "helm" prefix) if (headerText.startsWith('helm ')) { const commandOnly = headerText.substring(5); // Remove "helm " for (const [header, file] of Object.entries(headerToFileMap)) { if (header !== '_totalFiles' && header.toLowerCase().includes(commandOnly.toLowerCase())) { return file; } } } return null; } /** * Copy file with proper Docusaurus frontmatter */ function copyFileWithFrontmatter(sourcePath, targetPath, frontmatterData, isIndex = false) { try { let content = fs.readFileSync(sourcePath, 'utf8'); // Remove UTF-8 BOM if present if (content.charCodeAt(0) === 0xFEFF || content.startsWith('\\uFEFF')) { content = content.slice(1); } if (content.startsWith('\\xEF\\xBB\\xBF')) { content = content.slice(3); } // Replace image paths from (images/ to (/img/helm2/ content = content.replace(/\(images\//g, '(/img/helm2/'); // Special processing for helm/*.md files - extract H2 title and remove heading let h2Title = null; if (sourcePath.includes('/helm/helm') && sourcePath.endsWith('.md')) { h2Title = extractFirstH2Heading(content); content = removeFirstH2Heading(content); } // Create frontmatter (include H2 title for helm commands) const frontmatter = createFrontmatter({ ...frontmatterData, title: h2Title // Add H2 title if extracted }, isIndex); const fullContent = frontmatter + content; fs.writeFileSync(targetPath, fullContent); const indexNote = isIndex ? ' [INDEX]' : ''; console.log(` ✅ Copied (pos: ${frontmatterData.position})${indexNote}`); return true; } catch (error) { console.log(` ❌ Error copying: ${error.message}`); return false; } } /** * Create the index.mdx file for the version-2 docs */ function createIndexFile(outputPath) { const indexContent = `--- title: "Docs Home" sidebar_position: 1 --- Complete documentation for Helm v2, the Kubernetes package manager. Learn how to install, configure, and use Helm to deploy applications to your Kubernetes cluster. import DocCardList from "@theme/DocCardList"; `; const indexPath = path.join(outputPath, 'index.mdx'); fs.writeFileSync(indexPath, indexContent); } /** * Extract the first H2 heading text from content */ function extractFirstH2Heading(content) { const lines = content.split('\n'); for (let i = 0; i < lines.length; i++) { if (lines[i].startsWith('## helm')) { // Extract just the text after "## " return lines[i].substring(3).trim(); } } return null; } /** * Remove the first H2 heading from helm command files */ function removeFirstH2Heading(content) { // Look for the first H2 heading (## helm...) and remove it along with any following empty lines const lines = content.split('\n'); let firstH2Index = -1; for (let i = 0; i < lines.length; i++) { if (lines[i].startsWith('## helm')) { firstH2Index = i; break; } } if (firstH2Index !== -1) { // Remove the H2 line lines.splice(firstH2Index, 1); // Remove any immediately following empty lines while (firstH2Index < lines.length && lines[firstH2Index].trim() === '') { lines.splice(firstH2Index, 1); } } return lines.join('\n'); } /** * Create Docusaurus frontmatter */ function createFrontmatter(data, isIndex = false) { const frontmatterLines = ['---']; // Add title if specified (for helm commands) if (data.title) { frontmatterLines.push(`title: "${data.title}"`); } // Add position frontmatterLines.push(`sidebar_position: ${data.position}`); // Add label frontmatterLines.push(`sidebar_label: "${data.label}"`); // Add slug if specified if (data.slug) { frontmatterLines.push(`slug: ${data.slug}`); } // Add index-specific metadata if (isIndex) { frontmatterLines.push('# This is the index/landing page for this section'); } frontmatterLines.push('---'); frontmatterLines.push(''); return frontmatterLines.join('\n'); } // Main execution if (require.main === module) { copyV2DocsToDocusaurus(); } module.exports = { copyV2DocsToDocusaurus }; ================================================ FILE: scripts/v2/href-diffs.json ================================================ [ { "fileName": "chart_template_guide/getting_started.md", "before": "../charts.md", "after": "../developing_charts/developing_charts.md" }, { "fileName": "chart_template_guide/subcharts_and_globals.md", "before": "../charts.md", "after": "../developing_charts/developing_charts.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../charts.md", "after": "../developing_charts/developing_charts.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../charts_hooks.md", "after": "../developing_charts/charts_hooks.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../charts_tips_and_tricks.md", "after": "../developing_charts/charts_tips_and_tricks.md" }, { "fileName": "developing_charts/chart_repository.md", "before": "quickstart.md", "after": "../using_helm/using_helm.md" }, { "fileName": "developing_charts/chart_repository.md", "before": "charts.md", "after": "developing_charts.md" }, { "fileName": "using_helm/securing_installation.md", "before": "provenance.md", "after": "../developing_charts/provenance.md" }, { "fileName": "using_helm/kubernetes_apis.md", "before": "developers#grpc-and-protobuf", "after": "../developers.md#grpc-and-protobuf" }, { "fileName": "using_helm/install.md", "before": "#kubernetes-distribution-guide", "after": "kubernetes_distros.md" }, { "fileName": "using_helm/using_helm.md", "before": "#Install-Helm", "after": "install.md" } ] ================================================ FILE: scripts/v2/menu-generate.js ================================================ #!/usr/bin/env node const fs = require('fs'); const https = require('https'); const { JSDOM } = require('jsdom'); const V2_DOCS_URL = 'https://v2.helm.sh/docs/'; // DOM extraction function from user const linksTree = (rootSel = 'nav.sidebar-nav ul.current.sidebar-main', document) => { const ul = typeof rootSel === 'string' ? document.querySelector(rootSel) : rootSel; if (!ul || ul.tagName !== 'UL') throw new Error('Target UL .current.sidebar-main not found under nav.sidebar-nav'); const parse = u => Array.from(u.children).flatMap(li => li.tagName === 'LI' ? [{ link: li.querySelector(':scope > a')?.href ?? null, label: li.querySelector(':scope > a')?.textContent.trim() ?? null, children: (() => { const cu = li.querySelector(':scope > ul'); return cu ? parse(cu) : []; })() }] : []); return parse(ul); }; // Convert v2.helm.sh navigation structure to simplified format for copy script const convertToSimplifiedFormat = async (navTree) => { const results = []; for (const item of navTree) { // Skip external links (not on v2.helm.sh/docs domain) if (item.link && !item.link.startsWith('/docs')) { console.log(`🚫 Skipping external link: ${item.label} (${item.link})`); continue; } const result = { label: item.label, link: item.link // Store full URL path for categories }; // Extract header text for the main page (except for "Docs Home") if (item.link && item.label !== "Docs Home") { try { const headerText = await extractHeaderText(`https://v2.helm.sh${item.link}`); if (headerText) { result.header = headerText; } } catch (error) { console.warn(`Failed to extract header for ${item.link}: ${error.message}`); } } else if (item.label === "Docs Home") { console.log(`📄 Skipping header extraction for Docs Home (handled by copy script)`); } // Only add children key if there are actual children if (item.children.length > 0) { result.children = []; for (const child of item.children) { const childResult = { label: child.label, anchor: extractAnchor(child.link) // Store just the anchor fragment }; // Extract header text for child anchor if (child.link && item.link) { try { const fullChildUrl = `https://v2.helm.sh${item.link}${child.link.startsWith('#') ? child.link : '#' + extractAnchor(child.link)}`; const childHeaderText = await extractHeaderTextFromAnchor(`https://v2.helm.sh${item.link}`, extractAnchor(child.link)); if (childHeaderText) { childResult.header = childHeaderText; } } catch (error) { console.warn(`Failed to extract header for ${child.link}: ${error.message}`); } } result.children.push(childResult); } } results.push(result); } return results; }; // Extract anchor fragment from relative URL const extractAnchor = (link) => { if (!link) return null; const anchorIndex = link.indexOf('#'); return anchorIndex !== -1 ? link.substring(anchorIndex + 1) : null; }; // Extract header text from a page following the pattern: div.content-wrap + empty h3 + next H1/H2 const extractHeaderText = (url) => { return new Promise((resolve, reject) => { console.log(` 🔍 Extracting header from: ${url}`); https.get(url, (response) => { let data = ''; response.on('data', (chunk) => { data += chunk; }); response.on('end', () => { try { const dom = new JSDOM(data); const document = dom.window.document; // Find div.content-wrap const contentWrap = document.querySelector('div.content-wrap'); if (!contentWrap) { console.log(` ❌ No div.content-wrap found`); resolve(null); return; } // Look for empty h3 inside content-wrap const emptyH3 = contentWrap.querySelector('h3'); if (!emptyH3 || emptyH3.textContent.trim() !== '') { console.log(` ❌ No empty h3 found inside content-wrap`); resolve(null); return; } // Find the next H1 or H2 after the empty h3 let nextElement = emptyH3.nextElementSibling; while (nextElement && !['H1', 'H2'].includes(nextElement.tagName)) { nextElement = nextElement.nextElementSibling; } if (nextElement) { const headerText = nextElement.textContent.trim(); console.log(` ✅ Found header: "${headerText}"`); resolve(headerText); } else { console.log(` ❌ No H1/H2 found after empty h3`); resolve(null); } } catch (error) { reject(error); } }); }).on('error', reject); }); }; // Extract header text from anchor on a page const extractHeaderTextFromAnchor = (baseUrl, anchor) => { return new Promise((resolve, reject) => { if (!anchor) { resolve(null); return; } console.log(` 🔍 Extracting anchor header from: ${baseUrl}#${anchor}`); https.get(baseUrl, (response) => { let data = ''; response.on('data', (chunk) => { data += chunk; }); response.on('end', () => { try { const dom = new JSDOM(data); const document = dom.window.document; // Find element with matching id const targetElement = document.querySelector(`#${anchor}`); if (targetElement) { const headerText = targetElement.textContent.trim(); console.log(` ✅ Found anchor header: "${headerText}"`); resolve(headerText); } else { // Try to find by matching text in headings const headings = document.querySelectorAll('h1, h2, h3, h4, h5, h6'); for (const heading of headings) { const headingId = heading.id || ''; if (headingId === anchor || heading.textContent.toLowerCase().includes(anchor.replace(/-/g, ' '))) { const headerText = heading.textContent.trim(); console.log(` ✅ Found matching header: "${headerText}"`); resolve(headerText); return; } } resolve(null); } } catch (error) { reject(error); } }); }).on('error', reject); }); }; // Fetch and parse the v2.helm.sh docs page const fetchV2Navigation = () => { return new Promise((resolve, reject) => { console.log(`Fetching navigation from ${V2_DOCS_URL}...`); https.get(V2_DOCS_URL, (response) => { let data = ''; response.on('data', (chunk) => { data += chunk; }); response.on('end', () => { try { console.log('Parsing HTML and extracting navigation...'); const dom = new JSDOM(data); const document = dom.window.document; // Extract navigation using the provided function const navTree = linksTree('nav.sidebar-nav ul.current.sidebar-main', document); console.log(`Extracted ${navTree.length} top-level navigation items`); resolve(navTree); } catch (error) { reject(new Error(`Failed to parse navigation: ${error.message}`)); } }); }).on('error', (error) => { reject(new Error(`Failed to fetch ${V2_DOCS_URL}: ${error.message}`)); }); }); }; // Count total items recursively const countTotalItems = (items) => { return items.reduce((count, item) => { return count + 1 + countTotalItems(item.children || []); }, 0); }; // Add missing files that exist in orig/docs-v2 but aren't in the menu const addMissingFilesToMenu = (navigationStructure) => { console.log('🔍 Adding missing files to navigation menu...'); // Find the "Helm Commands" category const helmCommandsCategory = navigationStructure.find(item => item.label === "Helm Commands" || (item.children && item.children.some(child => child.label && child.label.startsWith("Helm ") )) ); if (helmCommandsCategory && helmCommandsCategory.children) { // Add "helm get notes" before "helm get values" const getValuesIndex = helmCommandsCategory.children.findIndex(child => child.label === "Helm Get Values" ); if (getValuesIndex > 0) { helmCommandsCategory.children.splice(getValuesIndex, 0, { label: "Helm Get Notes", header: "helm get notes", link: "/docs/helm/helm_get_notes/" }); console.log(' ✅ Added "Helm Get Notes" before "Helm Get Values"'); } // Add "helm inspect readme" before "helm inspect values" const inspectValuesIndex = helmCommandsCategory.children.findIndex(child => child.label === "Helm Inspect Values" ); if (inspectValuesIndex > 0) { helmCommandsCategory.children.splice(inspectValuesIndex, 0, { label: "Helm Inspect Readme", header: "helm inspect readme", link: "/docs/helm/helm_inspect_readme/" }); console.log(' ✅ Added "Helm Inspect Readme" before "Helm Inspect Values"'); } } }; // Main execution const main = async () => { try { const rawNavTree = await fetchV2Navigation(); console.log('\n🔍 Extracting header texts from live site...'); const navigationStructure = await convertToSimplifiedFormat(rawNavTree); // Add missing files that exist in orig/docs-v2 but aren't in the menu addMissingFilesToMenu(navigationStructure); // Write the simplified menu structure const outputPath = './scripts/v2/menu.json'; const output = { navigationStructure, metadata: { sourceUrl: V2_DOCS_URL, method: 'DOM extraction with header text extraction from live site', totalItems: countTotalItems(navigationStructure) } }; fs.writeFileSync(outputPath, JSON.stringify(output, null, 2)); console.log(`\n✅ Successfully generated ${outputPath}`); console.log(`📊 Extracted ${output.metadata.totalItems} total navigation items with header texts`); console.log(`🔗 Source: ${V2_DOCS_URL}`); } catch (error) { console.error(`❌ Error: ${error.message}`); process.exit(1); } }; if (require.main === module) { main(); } module.exports = { fetchV2Navigation, convertToSimplifiedFormat, linksTree }; ================================================ FILE: scripts/v2/menu.json ================================================ { "navigationStructure": [ { "label": "Docs Home", "link": "/docs" }, { "label": "Using Helm", "link": "/docs/using_helm/", "header": "Quickstart Guide", "children": [ { "label": "Quickstart", "anchor": "quickstart-guide", "header": "Quickstart Guide" }, { "label": "Installing Helm", "anchor": "installing-helm", "header": "Installing Helm" }, { "label": "Deprecated Kubernetes APIs", "anchor": "deprecated-kubernetes-apis", "header": "Deprecated Kubernetes APIs" }, { "label": "Kubernetes Distro Notes", "anchor": "kubernetes-distribution-guide", "header": "Kubernetes Distribution Guide" }, { "label": "Install FAQ", "anchor": "installation-frequently-asked-questions", "header": "Installation: Frequently Asked Questions" }, { "label": "Using Helm", "anchor": "using-helm", "header": "Using Helm" }, { "label": "Plugins", "anchor": "the-helm-plugins-guide", "header": "The Helm Plugins Guide" }, { "label": "Role-Based Access Control", "anchor": "role-based-access-control", "header": "Role-based Access Control" }, { "label": "TLS/SSL for Helm and Tiller", "anchor": "using-ssl-between-helm-and-tiller", "header": "Using SSL Between Helm and Tiller" }, { "label": "Securing Helm", "anchor": "securing-your-helm-installation", "header": "Securing your Helm Installation" } ] }, { "label": "Helm Commands", "link": "/docs/helm/", "header": "helm", "children": [ { "label": "Helm", "anchor": "helm", "header": "helm" }, { "label": "Helm Completion", "anchor": "helm-completion", "header": "helm completion" }, { "label": "Helm Create", "anchor": "helm-create", "header": "helm create" }, { "label": "Helm Delete", "anchor": "helm-delete", "header": "helm delete" }, { "label": "Helm Dependency", "anchor": "helm-dependency", "header": "helm dependency" }, { "label": "Helm Dependency Build", "anchor": "helm-dependency-build", "header": "helm dependency build" }, { "label": "Helm Dependency List", "anchor": "helm-dependency-list", "header": "helm dependency list" }, { "label": "Helm Dependency Update", "anchor": "helm-dependency-update", "header": "helm dependency update" }, { "label": "Helm Fetch", "anchor": "helm-fetch", "header": "helm fetch" }, { "label": "Helm Get", "anchor": "helm-get", "header": "helm get" }, { "label": "Helm Get Hooks", "anchor": "helm-get-hooks", "header": "helm get hooks" }, { "label": "Helm Get Manifest", "anchor": "helm-get-manifest", "header": "helm get manifest" }, { "label": "Helm Get Notes", "header": "helm get notes", "link": "/docs/helm/helm_get_notes/" }, { "label": "Helm Get Values", "anchor": "helm-get-values", "header": "helm get values" }, { "label": "Helm History", "anchor": "helm-history", "header": "helm history" }, { "label": "Helm Home", "anchor": "helm-home", "header": "helm home" }, { "label": "Helm Init", "anchor": "helm-init", "header": "helm init" }, { "label": "Helm Inspect", "anchor": "helm-inspect", "header": "helm inspect" }, { "label": "Helm Inspect Chart", "anchor": "helm-inspect-chart", "header": "helm inspect chart" }, { "label": "Helm Inspect Readme", "header": "helm inspect readme", "link": "/docs/helm/helm_inspect_readme/" }, { "label": "Helm Inspect Values", "anchor": "helm-inspect-values", "header": "helm inspect values" }, { "label": "Helm Install", "anchor": "helm-install", "header": "helm install" }, { "label": "Helm Lint", "anchor": "helm-lint", "header": "helm lint" }, { "label": "Helm List", "anchor": "helm-list", "header": "helm list" }, { "label": "Helm Package", "anchor": "helm-package", "header": "helm package" }, { "label": "Helm Plugin", "anchor": "helm-plugin", "header": "helm plugin" }, { "label": "Helm Plugin Install", "anchor": "helm-plugin-install", "header": "helm plugin install" }, { "label": "Helm Plugin List", "anchor": "helm-plugin-list", "header": "helm plugin list" }, { "label": "Helm Plugin Remove", "anchor": "helm-plugin-remove", "header": "helm plugin remove" }, { "label": "Helm Plugin Update", "anchor": "helm-plugin-update", "header": "helm plugin update" }, { "label": "Helm Repo", "anchor": "helm-repo", "header": "helm repo" }, { "label": "Helm Repo Add", "anchor": "helm-repo-add", "header": "helm repo add" }, { "label": "Helm Repo Index", "anchor": "helm-repo-index", "header": "helm repo index" }, { "label": "Helm Repo List", "anchor": "helm-rep-list" }, { "label": "Helm Repo Remove", "anchor": "helm-repo-remove", "header": "helm repo remove" }, { "label": "Helm Repo Update", "anchor": "helm-repo-update", "header": "helm repo update" }, { "label": "Helm Reset", "anchor": "helm-reset", "header": "helm reset" }, { "label": "Helm Rollback", "anchor": "helm-rollback", "header": "helm rollback" }, { "label": "Helm Search", "anchor": "helm-search", "header": "helm search" }, { "label": "Helm Serve", "anchor": "helm-serve", "header": "helm serve" }, { "label": "Helm Status", "anchor": "helm-status", "header": "helm status" }, { "label": "Helm Template", "anchor": "helm-template", "header": "helm template" }, { "label": "Helm Test", "anchor": "helm-test", "header": "helm test" }, { "label": "Helm Upgrade", "anchor": "helm-upgrade", "header": "helm upgrade" }, { "label": "Helm Verify", "anchor": "helm-verify", "header": "helm verify" }, { "label": "Helm Version", "anchor": "helm-version", "header": "helm version" } ] }, { "label": "Charts", "link": "/docs/developing_charts/", "header": "Charts", "children": [ { "label": "Intro to Charts", "anchor": "charts", "header": "Charts" }, { "label": "Chart Lifecycle Hooks", "anchor": "hooks", "header": "Hooks" }, { "label": "Charts Tips and Tricks", "anchor": "chart-development-tips-and-tricks", "header": "Chart Development Tips and Tricks" }, { "label": "Charts Repository Guide", "anchor": "the-chart-repository-guide", "header": "The Chart Repository Guide" }, { "label": "Syncing Your Chart Repo", "anchor": "syncing-your-chart-repository", "header": "Syncing Your Chart Repository" }, { "label": "Signing Charts", "anchor": "helm-provenance-and-integrity", "header": "Helm Provenance and Integrity" }, { "label": "Chart Tests", "anchor": "chart-tests", "header": "Chart Tests" }, { "label": "Chart Repository FAQ", "anchor": "chart-repositories-frequently-asked-questions", "header": "Chart Repositories: Frequently Asked Questions" } ] }, { "label": "Developing Templates", "link": "/docs/chart_template_guide/", "header": "The Chart Template Developer’s Guide", "children": [ { "label": "Intro", "anchor": "the-chart-template-developer-s-guide", "header": "The Chart Template Developer’s Guide" }, { "label": "Getting Started", "anchor": "getting-started-with-a-chart-template", "header": "Getting Started with a Chart Template" }, { "label": "Built-In Objects", "anchor": "built-in-objects", "header": "Built-in Objects" }, { "label": "Values Files", "anchor": "values-files", "header": "Values Files" }, { "label": "Template Functions and Pipelines", "anchor": "template-functions-and-pipelines", "header": "Template Functions and Pipelines" }, { "label": "Flow Control", "anchor": "flow-control", "header": "Flow Control" }, { "label": "Variables", "anchor": "variables", "header": "Variables" }, { "label": "Named Templates", "anchor": "named-templates", "header": "Named Templates" }, { "label": "Accessing Files Inside Templates", "anchor": "accessing-files-inside-templates", "header": "Accessing Files Inside Templates" }, { "label": "Creating a NOTES.txt File", "anchor": "creating-a-notes-txt-file", "header": "Creating a NOTES.txt File" }, { "label": "Subcharts and Global Values", "anchor": "subcharts-and-global-values", "header": "Subcharts and Global Values" }, { "label": "The .helmignore File", "anchor": "the-helmignore-file", "header": "The .helmignore file" }, { "label": "Debugging Templates", "anchor": "debugging-templates", "header": "Debugging Templates" }, { "label": "Next Steps", "anchor": "wrapping-up", "header": "Wrapping Up" }, { "label": "Appendix: YAML Techniques", "anchor": "yaml-techniques", "header": "YAML Techniques" }, { "label": "Appendix: Go Data Types and Templates", "anchor": "appendix-go-data-types-and-templates", "header": "Appendix: Go Data Types and Templates" } ] }, { "label": "Best Practices", "link": "/docs/chart_best_practices/", "header": "The Chart Best Practices Guide", "children": [ { "label": "Intro", "anchor": "the-chart-best-practices-guide", "header": "The Chart Best Practices Guide" }, { "label": "General Conventions", "anchor": "general-conventions", "header": "General Conventions" }, { "label": "Values", "anchor": "values", "header": "Values" }, { "label": "Templates", "anchor": "templates", "header": "Templates" }, { "label": "Requirements", "anchor": "requirements-files", "header": "Requirements Files" }, { "label": "Labels & Annotations", "anchor": "labels-and-annotations", "header": "Labels and Annotations" }, { "label": "Pods & PodTemplates", "anchor": "pods-and-podtemplates", "header": "Pods and PodTemplates" }, { "label": "Custom Resource Definitions", "anchor": "custom-resource-definitions", "header": "Custom Resource Definitions" }, { "label": "RBAC", "anchor": "role-based-access-control", "header": "Role-Based Access Control" } ] }, { "label": "Related Projects", "link": "/docs/related/", "header": "Related Projects and Documentation" }, { "label": "Architecture", "link": "/docs/architecture/", "header": "The Kubernetes Helm Architecture" }, { "label": "Developer Guide", "link": "/docs/developers/", "header": "Developers Guide" }, { "label": "History", "link": "/docs/history/", "header": "The History of the Project" }, { "label": "Glossary", "link": "/docs/glossary/", "header": "Helm Glossary" } ], "metadata": { "generatedAt": "2025-10-22T06:20:58.478Z", "sourceUrl": "https://v2.helm.sh/docs/", "method": "DOM extraction with header text extraction from live site", "totalItems": 100 } } ================================================ FILE: scripts/v3/add-netlify-redirects.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); /** * Adds missing redirects to netlify.toml for Hugo frontmatter aliases that were removed */ function addNetlifyRedirects() { const netlifyTomlPath = path.join(__dirname, '..', '..', 'netlify.toml'); const removedAliasesPath = path.join(__dirname, 'removed-aliases.json'); console.log('📝 Adding missing redirects to netlify.toml...'); // Load removed aliases if (!fs.existsSync(removedAliasesPath)) { console.error('❌ removed-aliases.json not found. Run remove-aliases.js first.'); process.exit(1); } const removedAliases = JSON.parse(fs.readFileSync(removedAliasesPath, 'utf-8')); // Read netlify.toml if (!fs.existsSync(netlifyTomlPath)) { console.error('❌ netlify.toml not found'); process.exit(1); } let netlifyContent = fs.readFileSync(netlifyTomlPath, 'utf-8'); // Define the redirects we need to add const redirectsToAdd = [ { from: "/docs/developers/", to: "/community/developers/", status: 302, comment: 'Additional redirects for Hugo frontmatter aliases removed during v3 migration' }, { from: "/docs/history/", to: "/community/history/", status: 302, }, { from: "/docs/related/", to: "/community/related/", status: 302, }, { from: '/docs/faq/', to: '/docs/faq/', status: 302 }, { from: '/docs/using_helm/', to: '/docs/intro/', status: 302 }, { from: '/docs/architecture/', to: '/docs/topics/architecture/', status: 302 }, { from: '/docs/developing_charts/', to: '/docs/topics/charts/', status: 302 }, { from: '/developing_charts/', to: '/docs/topics/charts/', status: 302 } ]; // Check if our section already exists const startMarker = "# START - Hugo frontmatter aliases redirects, removed during docusaurus migration"; const endMarker = "# END - Hugo frontmatter aliases redirects"; const startIndex = netlifyContent.indexOf(startMarker); const endIndex = netlifyContent.indexOf(endMarker); if (startIndex !== -1 && endIndex !== -1) { console.log(' ⏭️ Redirects section already exists, replacing...'); // Remove existing section netlifyContent = netlifyContent.substring(0, startIndex) + netlifyContent.substring(endIndex + endMarker.length); } else if (startIndex !== -1) { console.log(' ⚠️ Found start marker but no end marker. Cleaning up...'); netlifyContent = netlifyContent.substring(0, startIndex); } // Build new redirects section let redirectsSection = `\n${startMarker}\n`; redirectsToAdd.forEach(redirect => { redirectsSection += `[[redirects]]\n`; redirectsSection += ` from = "${redirect.from}"\n`; redirectsSection += ` to = "${redirect.to}"\n`; redirectsSection += ` status = ${redirect.status}\n`; redirectsSection += `\n`; }); redirectsSection += `${endMarker}\n`; // Append the new section netlifyContent = netlifyContent.trim() + redirectsSection; // Write back to file fs.writeFileSync(netlifyTomlPath, netlifyContent); console.log(`✅ Added ${redirectsToAdd.length} redirects to netlify.toml`); console.log(' 📋 Redirects added:'); redirectsToAdd.forEach(redirect => { console.log(` ${redirect.from} → ${redirect.to}`); }); } // Run if called directly if (require.main === module) { addNetlifyRedirects(); } module.exports = { addNetlifyRedirects }; ================================================ FILE: scripts/v3/href-diffs.json ================================================ [ { "fileName": "index.mdx", "before": "topics", "after": "topics/index.mdx" }, { "fileName": "index.mdx", "before": "/docs/howto/charts_tips_and_tricks/_index.md", "after": "../howto/charts_tips_and_tricks.md" }, { "fileName": "index.mdx", "before": "community", "after": "community/index.mdx" }, { "fileName": "index.mdx", "before": "howto", "after": "howto/index.mdx" }, { "fileName": "index.mdx", "before": "../", "after": "https://helm.sh/" }, { "fileName": "index.mdx", "before": "- [开发案例](example) 如果您期望使用SDK做集成开发，这里有一些帮助案例。", "after": "" }, { "fileName": "chart_best_practices/dependencies.md", "before": "../topics/plugins#downloader-plugins", "after": "../topics/plugins.md#downloader-plugins" }, { "fileName": "chart_template_guide/accessing_files.md", "before": "/docs/chart_template_guide/subcharts_and_globals.md", "after": "subcharts_and_globals.md" }, { "fileName": "chart_template_guide/builtin_objects.md", "before": "/docs/topics/charts.md#the-chartyaml-file", "after": "../topics/charts.md#the-chartyaml-file" }, { "fileName": "chart_template_guide/builtin_objects.md", "before": "/docs/chart_template_guide/accessing_files.md", "after": "accessing_files.md" }, { "fileName": "chart_template_guide/getting_started.md", "before": "../../topics/charts", "after": "../topics/charts" }, { "fileName": "chart_template_guide/getting_started.md", "before": "_index.md", "after": "index.mdx" }, { "fileName": "chart_template_guide/getting_started.md", "before": "./", "after": "index.mdx" }, { "fileName": "chart_template_guide/subcharts_and_globals.md", "before": "/docs/topics/library_charts.md", "after": "../topics/library_charts.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../../topics/charts/", "after": "../topics/charts.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../../topics/charts_hooks/", "after": "../topics/charts_hooks.md" }, { "fileName": "chart_template_guide/wrapping_up.md", "before": "../../howto/charts_tips_and_tricks/", "after": "../howto/charts_tips_and_tricks.md" }, { "fileName": "chart_template_guide/function_list.md", "before": "functions_and_pipelines.md/#using-the-lookup-function", "after": "functions_and_pipelines.md#using-the-lookup-function" }, { "fileName": "howto/chart_repository_sync_example.md", "before": "/docs/topics/chart_repository.md", "after": "../topics/chart_repository.md" }, { "fileName": "howto/chart_repository_sync_example.md", "before": "/docs/topics/chart_repository.md", "after": "../topics/chart_repository.md" }, { "fileName": "howto/index.mdx", "before": "../topics", "after": "../topics/index.mdx" }, { "fileName": "intro/using_helm.md", "before": "/docs/howto/charts_tips_and_tricks/_index.md", "after": "../howto/charts_tips_and_tricks.md" }, { "fileName": "intro/using_helm.md", "before": "/docs/topics/chart_repository.md", "after": "../topics/chart_repository.md" }, { "fileName": "intro/using_helm.md", "before": "/docs/chart_template_guide/values_files/_index.md", "after": "../chart_template_guide/values_files.md" }, { "fileName": "topics/advanced.md", "before": "/docs/permissions_sql_storage_backend/", "after": "permissions_sql_storage_backend.md" }, { "fileName": "topics/chart_repository.md", "before": "/docs/topics/registries.md", "after": "registries.md" }, { "fileName": "topics/chart_repository.md", "before": "quickstart.md", "after": "../intro/quickstart.md" }, { "fileName": "topics/chart_repository.md", "before": "/docs/topics/charts.md", "after": "charts.md" }, { "fileName": "topics/chart_repository.md", "before": "/docs/howto/chart_releaser_action.md", "after": "../howto/chart_releaser_action.md" }, { "fileName": "topics/chart_repository.md", "before": "/docs/howto/chart_repository_sync_example.md", "after": "../howto/chart_repository_sync_example.md" }, { "fileName": "topics/chart_tests.md", "before": "/commands/helm_create.md", "after": "../helm/helm_create.md" }, { "fileName": "topics/chart_tests.md", "before": "/docs/helm/helm_create", "after": "../helm/helm_create.md" }, { "fileName": "topics/chart_tests.md", "before": "/docs/charts_hooks/", "after": "charts_hooks.md" }, { "fileName": "topics/charts.md", "before": "/docs/topics/library_charts.md", "after": "library_charts.md" }, { "fileName": "topics/charts.md", "before": "/docs/howto/charts_tips_and_tricks.md", "after": "../howto/charts_tips_and_tricks.md" }, { "fileName": "topics/charts.md", "before": "/docs/howto/charts_tips_and_tricks.md", "after": "../howto/charts_tips_and_tricks.md" }, { "fileName": "topics/charts_hooks.md", "before": "/docs/chart_tests/", "after": "chart_tests.md" }, { "fileName": "topics/library_charts.md", "before": "/docs/topics/charts.md", "after": "charts.md" }, { "fileName": "topics/library_charts.md", "before": "/docs/topics/charts.md", "after": "charts.md" }, { "fileName": "topics/library_charts.md", "before": "/docs/chart_template_guide/named_templates.md", "after": "../chart_template_guide/named_templates.md" }, { "fileName": "topics/library_charts.md", "before": "/docs/chart_template_guide/subcharts_and_globals.md", "after": "../chart_template_guide/subcharts_and_globals.md" }, { "fileName": "topics/plugins.md", "before": "related.md#helm-plugins", "after": "../community/related.md#helm-plugins" }, { "fileName": "community/localization.md", "before": "./localization/#two-letter-language-code", "after": "#two-letter-language-code" }, { "fileName": "community/release_checklist.md", "before": "https://docs.helm.sh/using_helm/#quickstart-guide", "after": "../intro/quickstart.md" }, { "fileName": "community/release_checklist.md", "before": "https://docs.helm.sh/using_helm/#installing-helm", "after": "../intro/install.md" }, { "fileName": "community/release_checklist.md", "before": "/docs", "after": "../index.mdx" }, { "fileName": "faq/changes_since_helm2.md", "before": "/docs/topics/advanced/#storage-backends", "after": "../topics/advanced.md#storage-backends" }, { "fileName": "faq/troubleshooting.md", "before": "https://helm.sh/docs/topics/v2_v3_migration/#helm", "after": "../topics/v2_v3_migration.md" }, { "fileName": "intro/install.md", "before": "https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository", "after": "quickstart.md#initialize-a-helm-chart-repository" }, { "fileName": "topics/v2_v3_migration.md", "before": "https://v3.helm.sh/docs/faq/#changes-since-helm-2", "after": "../faq/changes_since_helm2.md" }, { "fileName": "community/developers.md", "before": "https://helm.sh/docs/helm/", "after": "/helm/index.mdx" }, { "fileName": "community/developers.md", "before": "/commands/index.mdx", "after": "../helm/index.mdx" }, { "fileName": "helm/helm_install.md", "before": "docs/glossary/_index.md#chart-archive", "after": "../glossary/index.mdx#chart-archive" }, { "fileName": "helm/helm_install.md", "before": "docs/glossary/_index.md#linhagem-arquivo-de-linhagem", "after": "../glossary/index.mdx#linhagem-arquivo-de-linhagem" }, { "fileName": "faq/index.mdx", "before": "", "after": "[https://storage.googleapis.com/kubernetes-helm/](https://storage.googleapis.com/kubernetes-helm/)" } ] ================================================ FILE: scripts/v3/migrate-sdk-section.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { findFiles } = require('../util/util-file-operations.js'); const { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js'); /** * Import SDK examples from .go files to .mdx files with code blocks * Also renames examples.md to examples.mdx and adds imports * @param {number} majorVersion - Version number (e.g., 3) */ function importSdkExamplesFromGoFiles(majorVersion = 3) { console.log('💻 Importing SDK examples from Go files...'); const versionDir = `versioned_docs/version-${majorVersion}`; const sdkDir = path.join(versionDir, 'sdk'); const examplesFile = path.join(sdkDir, 'examples.md'); const examplesFileMdx = path.join(sdkDir, 'examples.mdx'); const examplesFileNew = path.join(sdkDir, 'examples.mdx'); const sdkExamplesDir = 'sdkexamples'; if (!fs.existsSync(sdkExamplesDir)) { console.warn('⚠️ SDK examples source directory not found'); return; } if (!fs.existsSync(sdkDir)) { console.warn('⚠️ SDK docs directory not found'); return; } // Find all .go files in sdkexamples/ const goFiles = fs.readdirSync(sdkExamplesDir) .filter(file => file.endsWith('.go')); let importLines = []; let processedCount = 0; // Process each .go file goFiles.forEach(goFile => { try { const name = path.basename(goFile, '.go'); const sourcePath = path.join(sdkExamplesDir, goFile); const destPath = path.join(sdkDir, `_${name}.mdx`); // Read the .go file content const goContent = fs.readFileSync(sourcePath, 'utf8'); // Wrap in code block const mdxContent = '```go\n' + goContent + '\n```\n'; // Write to destination fs.writeFileSync(destPath, mdxContent); // Create import line with capitalized name const capName = name.charAt(0).toUpperCase() + name.slice(1); importLines.push(`import ${capName} from './_${name}.mdx'`); console.log(` 💻 Processed: ${goFile} → _${name}.mdx`); processedCount++; } catch (error) { console.warn(` ⚠️ Error processing ${goFile}: ${error.message}`); } }); // Process examples file (either .md or .mdx) and add imports const examplesSourceFile = fs.existsSync(examplesFile) ? examplesFile : fs.existsSync(examplesFileMdx) ? examplesFileMdx : null; if (examplesSourceFile) { try { const content = fs.readFileSync(examplesSourceFile, 'utf8'); const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content); if (hasFrontmatter) { // Add imports after frontmatter const importsSection = importLines.join('\n') + '\n\n'; // Remove any existing import lines from restContent const cleanedContent = restContent.replace(/^import .* from '\.\/_.*.mdx';?\n?/gm, ''); const newRestContent = importsSection + cleanedContent.trim(); const updatedContent = frontMatterToYaml(frontmatter, newRestContent); fs.writeFileSync(examplesFileNew, updatedContent); if (examplesSourceFile !== examplesFileNew) { fs.unlinkSync(examplesSourceFile); // Remove old file if different } console.log(' 📝 Updated examples.mdx with imports'); } } catch (error) { console.warn(` ⚠️ Error updating examples file: ${error.message}`); } } console.log(`✅ Imported ${processedCount} SDK examples`); } /** * Apply SDK href transformations from JSON differences file * Uses the sdk-href-diffs.json file to apply SDK-specific text changes * @param {number} majorVersion - Version number (e.g., 3) */ function applySdkHrefTransformations(majorVersion = 3) { console.log('🔗 Applying SDK href transformations...'); const versionDir = `versioned_docs/version-${majorVersion}`; const sdkDiffsFile = 'scripts/v3/sdk-href-diffs.json'; if (!fs.existsSync(sdkDiffsFile)) { console.warn('⚠️ SDK differences file not found:', sdkDiffsFile); console.log('Run href-diffs-generate.js first to create the differences file'); return; } // Load SDK transformations const sdkTransformations = JSON.parse(fs.readFileSync(sdkDiffsFile, 'utf8')); console.log(`📋 Loaded ${sdkTransformations.length} SDK transformations`); const files = findFiles(versionDir, ['.md', '.mdx']); let updatedCount = 0; let totalFixes = 0; files.forEach(filePath => { try { let content = fs.readFileSync(filePath, 'utf8'); let hasChanges = false; // Apply each SDK transformation sdkTransformations.forEach(transform => { const { fileName, before, after } = transform; // Only apply transformations to the specific file const relativePath = path.relative(versionDir, filePath); if (relativePath === fileName) { // Apply the transformation if (content.includes(before)) { content = content.replace(new RegExp(before.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'g'), after); hasChanges = true; totalFixes++; console.log(` 🔗 Applied SDK transformation: ${before} → ${after}`); } } }); if (hasChanges) { fs.writeFileSync(filePath, content); console.log(` ✅ Updated SDK file: ${path.relative(versionDir, filePath)}`); updatedCount++; } } catch (error) { console.warn(` ⚠️ Error processing ${filePath}: ${error.message}`); } }); console.log(`✅ Applied ${totalFixes} SDK transformations across ${updatedCount} files`); } /** * Complete SDK section migration * Orchestrates both importing Go files and applying href transformations * @param {number} majorVersion - Version number (e.g., 3) */ function migrateSdkSection(majorVersion = 3) { console.log('💻 Migrating SDK section...'); // Step 1: Import SDK examples from Go files to .mdx files importSdkExamplesFromGoFiles(majorVersion); // Step 2: Apply SDK href transformations applySdkHrefTransformations(majorVersion); console.log('✅ SDK section migration completed'); } // Run if called directly if (require.main === module) { const majorVersion = process.argv[2] ? parseInt(process.argv[2]) : 3; migrateSdkSection(majorVersion); } module.exports = { importSdkExamplesFromGoFiles, applySdkHrefTransformations, migrateSdkSection }; ================================================ FILE: scripts/v3/migrate-sdk-section.json ================================================ [ { "line": 26, "fileName": "sdk/examples.mdx", "before": "sdkexamples/install.go", "after": "" }, { "line": 27, "fileName": "sdk/examples.mdx", "before": "sdkexamples/upgrade.go", "after": "" }, { "line": 28, "fileName": "sdk/examples.mdx", "before": "sdkexamples/uninstall.go", "after": "" }, { "line": 29, "fileName": "sdk/examples.mdx", "before": "sdkexamples/list.go", "after": "" }, { "line": 30, "fileName": "sdk/examples.mdx", "before": "sdkexamples/pull.go", "after": "" }, { "line": 31, "fileName": "sdk/examples.mdx", "before": "sdkexamples/main.go", "after": "
" }, { "line": 32, "fileName": "sdk/gosdk.md", "before": "./examples.md", "after": "examples.mdx" } ] ================================================ FILE: scripts/v3/process-helm-files.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js'); /** * Process Helm command files in version-3/helm/ and i18n directories * - Extract first H2 heading text and set as frontmatter title * - Remove the original H2 heading line * - Add special configurations for helm category */ function processHelmFiles() { console.log('🔧 Processing Helm v3 command files...'); // Process main docs const mainHelmDir = path.join(__dirname, '..', '..', 'versioned_docs', 'version-3', 'helm'); if (fs.existsSync(mainHelmDir)) { console.log(' 📁 Processing main docs: versioned_docs/version-3/helm'); processHelmDirectory(mainHelmDir); } // Process i18n directories const i18nDir = path.join(__dirname, '..', '..'); if (fs.existsSync(i18nDir)) { const i18nPath = path.join(i18nDir, 'i18n'); if (fs.existsSync(i18nPath)) { const languages = fs.readdirSync(i18nPath, { withFileTypes: true }) .filter(dirent => dirent.isDirectory()) .map(dirent => dirent.name); languages.forEach(lang => { const langHelmDir = path.join(i18nPath, lang, 'docusaurus-plugin-content-docs', 'version-3', 'helm'); if (fs.existsSync(langHelmDir)) { console.log(` 🌐 Processing ${lang} translations: i18n/${lang}/docusaurus-plugin-content-docs/version-3/helm`); processHelmDirectory(langHelmDir); } }); } } console.log('🎉 Helm files processing completed'); } /** * Process Helm files in a specific directory * @param {string} helmDir - Path to helm directory */ function processHelmDirectory(helmDir) { const files = fs.readdirSync(helmDir).filter(file => file.endsWith('.md') && file !== 'index.md' && file !== 'index.mdx' ); console.log(` 📄 Found ${files.length} Helm command files to process`); let processedCount = 0; // Process regular command files files.forEach(fileName => { const filePath = path.join(helmDir, fileName); try { const content = fs.readFileSync(filePath, 'utf8'); let processedContent = processHelmFile(content, fileName); // Special handling for helm.md - add slug metadata if (fileName === 'helm.md') { const { frontmatter, restContent } = frontMatterFromYaml(processedContent); // Add slug if it doesn't exist if (!frontmatter.hasOwnProperty('slug')) { frontmatter.slug = 'helm'; processedContent = frontMatterToYaml(frontmatter, restContent); console.log(` 🔧 Added slug metadata to helm.md`); } } if (processedContent !== content) { fs.writeFileSync(filePath, processedContent); console.log(` ✅ Processed: ${fileName}`); processedCount++; } else { console.log(` ⏭️ Skipped: ${fileName} (no H2 found or already processed)`); } } catch (error) { console.error(` ❌ Error processing ${fileName}:`, error.message); } }); // Update index.mdx with id updateIndexMdx(helmDir); // Create _category_.json createCategoryJson(helmDir); console.log(` 🎉 Successfully processed ${processedCount} files`); } /** * Process a single Helm command file * @param {string} content - File content * @param {string} fileName - File name for logging * @returns {string} - Processed content */ function processHelmFile(content, fileName) { const lines = content.split('\n'); // Find the frontmatter boundaries let frontmatterStart = -1; let frontmatterEnd = -1; let dashCount = 0; for (let i = 0; i < lines.length; i++) { if (lines[i].trim() === '---') { dashCount++; if (dashCount === 1) { frontmatterStart = i; } else if (dashCount === 2) { frontmatterEnd = i; break; } } } if (frontmatterStart === -1 || frontmatterEnd === -1) { console.warn(` ⚠️ No frontmatter found in ${fileName}`); return content; } // Find the first H2 heading after frontmatter let h2LineIndex = -1; let h2Text = null; for (let i = frontmatterEnd + 1; i < lines.length; i++) { const line = lines[i].trim(); if (line.startsWith('## ')) { h2Text = line.substring(3).trim(); // Remove "## " h2LineIndex = i; break; } } if (!h2Text || h2LineIndex === -1) { // No H2 found, skip processing return content; } // Remove the H2 line and any empty lines after it const beforeFrontmatter = lines.slice(0, frontmatterStart); const frontmatterLines = lines.slice(frontmatterStart, frontmatterEnd + 1); const afterH2 = lines.slice(h2LineIndex + 1); // Remove any empty lines immediately after the removed H2 while (afterH2.length > 0 && afterH2[0].trim() === '') { afterH2.shift(); } // Rebuild content without the H2 line const contentWithoutH2 = [ ...beforeFrontmatter, ...frontmatterLines, ...afterH2 ].join('\n'); // Add the title using general utilities const { frontmatter, restContent } = frontMatterFromYaml(contentWithoutH2); frontmatter.title = h2Text; return frontMatterToYaml(frontmatter, restContent); } /** * Update index.mdx to add id: helm-category * @param {string} helmDir - Helm directory path */ function updateIndexMdx(helmDir) { const indexPath = path.join(helmDir, 'index.mdx'); if (!fs.existsSync(indexPath)) { console.warn(` ⚠️ index.mdx not found`); return; } try { const content = fs.readFileSync(indexPath, 'utf8'); const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content); if (!hasFrontmatter) { console.warn(` ⚠️ No frontmatter found in index.mdx`); return; } let needsUpdate = false; // Add id field if missing if (!frontmatter.hasOwnProperty('id')) { frontmatter.id = 'helm-category'; needsUpdate = true; } // Remove slug field if present (Docusaurus handles helm/ directory slug automatically) if (frontmatter.hasOwnProperty('slug')) { delete frontmatter.slug; needsUpdate = true; } if (needsUpdate) { const updatedContent = frontMatterToYaml(frontmatter, restContent); fs.writeFileSync(indexPath, updatedContent); console.log(` 🔧 Updated index.mdx metadata`); } else { console.log(` ⏭️ index.mdx already up to date`); } } catch (error) { console.error(` ❌ Error updating index.mdx:`, error.message); } } /** * Create _category_.json file * @param {string} helmDir - Helm directory path */ function createCategoryJson(helmDir) { const categoryPath = path.join(helmDir, '_category_.json'); const categoryContent = `{ "link": { "type": "doc", "id": "helm-category" } } `; try { fs.writeFileSync(categoryPath, categoryContent); console.log(` 📁 Created _category_.json`); } catch (error) { console.error(` ❌ Error creating _category_.json:`, error.message); } } // Main execution if (require.main === module) { processHelmFiles(); } module.exports = { processHelmFiles }; ================================================ FILE: scripts/v3/remove-aliases.js ================================================ #!/usr/bin/env node const fs = require('fs'); const path = require('path'); const { frontMatterFromYaml, frontMatterToYaml } = require('../util/util-frontmatter.js'); /** * Find and remove all aliases from v3 .md and .mdx files */ function removeAliasesFromFiles() { console.log('🔍 Finding and removing aliases from version-3 files...'); const v3DocsDir = path.join(__dirname, '..', '..', 'versioned_docs', 'version-3'); const i18nDir = path.join(__dirname, '..', '..', 'i18n'); if (!fs.existsSync(v3DocsDir)) { console.error('❌ Version-3 docs directory not found:', v3DocsDir); process.exit(1); } const aliasesFound = []; let filesWithAliases = 0; let aliasesRemoved = 0; /** * Recursively process directory for .md and .mdx files * @param {string} dirPath - Directory to process * @param {string} relativePath - Relative path for display */ function processDirectory(dirPath, relativePath = '') { const entries = fs.readdirSync(dirPath, { withFileTypes: true }); entries.forEach(entry => { const fullPath = path.join(dirPath, entry.name); const relativeFilePath = path.join(relativePath, entry.name); if (entry.isDirectory()) { // Recursively process subdirectories processDirectory(fullPath, relativeFilePath); } else if (entry.isFile() && (entry.name.endsWith('.md') || entry.name.endsWith('.mdx'))) { // Process markdown files processMarkdownFile(fullPath, relativeFilePath); } }); } /** * Process a single markdown file * @param {string} filePath - Full path to the file * @param {string} relativeFilePath - Relative path for display */ function processMarkdownFile(filePath, relativeFilePath) { try { const content = fs.readFileSync(filePath, 'utf8'); const { frontmatter, restContent, hasFrontmatter } = frontMatterFromYaml(content); if (!hasFrontmatter) { return; // Skip files without frontmatter } // Check if aliases exist if (frontmatter.hasOwnProperty('aliases') && Array.isArray(frontmatter.aliases)) { const aliases = [...frontmatter.aliases]; // Copy the array // Only record aliases from main docs, not i18n docs const isI18nFile = relativeFilePath.startsWith('i18n/'); if (!isI18nFile) { aliasesFound.push({ file: relativeFilePath, aliases: aliases }); } filesWithAliases++; aliasesRemoved += aliases.length; // Remove aliases from frontmatter delete frontmatter.aliases; // Write back the updated content const updatedContent = frontMatterToYaml(frontmatter, restContent); fs.writeFileSync(filePath, updatedContent); console.log(` ✅ Processed: ${relativeFilePath} (removed ${aliases.length} aliases)`); } } catch (error) { console.error(` ❌ Error processing ${relativeFilePath}:`, error.message); } } // Start processing from v3 docs directory processDirectory(v3DocsDir); // Process i18n translation directories for v3 const languages = ['de', 'es', 'fr', 'ja', 'ko', 'zh']; languages.forEach(lang => { const i18nVersionDir = path.join(i18nDir, lang, 'docusaurus-plugin-content-docs', 'version-3'); if (fs.existsSync(i18nVersionDir)) { console.log(`\n🌍 Processing translation directory: ${lang}`); processDirectory(i18nVersionDir, `i18n/${lang}/version-3`); } }); // Display results console.log('\n📊 Summary:'); console.log(` Files with aliases: ${filesWithAliases}`); console.log(` Total aliases removed: ${aliasesRemoved}`); if (aliasesFound.length > 0) { console.log('\n📋 Aliases found and removed:'); console.log('====================================='); aliasesFound.forEach(({ file, aliases }) => { console.log(`\n📄 ${file}:`); aliases.forEach((alias, index) => { console.log(` ${index + 1}. ${alias}`); }); }); // Also write to a file for reference const aliasesReport = { summary: { filesWithAliases, aliasesRemoved }, aliases: aliasesFound }; const reportPath = path.join(__dirname, 'removed-aliases.json'); fs.writeFileSync(reportPath, JSON.stringify(aliasesReport, null, 2)); console.log(`\n💾 Detailed report saved to: ${reportPath}`); } else { console.log('\n✨ No aliases found in any files.'); } console.log('\n🎉 Aliases removal completed!'); } // Main execution if (require.main === module) { removeAliasesFromFiles(); } module.exports = { removeAliasesFromFiles }; ================================================ FILE: scripts/v3/removed-aliases.json ================================================ { "summary": { "filesWithAliases": 42, "aliasesRemoved": 44 }, "aliases": [ { "file": "chart_best_practices/conventions.md", "aliases": [ "/docs/topics/chart_best_practices/conventions/" ] }, { "file": "chart_best_practices/custom_resource_definitions.md", "aliases": [ "/docs/topics/chart_best_practices/custom_resource_definitions/" ] }, { "file": "chart_best_practices/dependencies.md", "aliases": [ "/docs/topics/chart_best_practices/dependencies/" ] }, { "file": "chart_best_practices/index.mdx", "aliases": [ "/docs/topics/chart_best_practices/" ] }, { "file": "chart_best_practices/labels.md", "aliases": [ "/docs/topics/chart_best_practices/labels/" ] }, { "file": "chart_best_practices/pods.md", "aliases": [ "/docs/topics/chart_best_practices/pods/" ] }, { "file": "chart_best_practices/rbac.md", "aliases": [ "/docs/topics/chart_best_practices/rbac/" ] }, { "file": "chart_best_practices/templates.md", "aliases": [ "/docs/topics/chart_best_practices/templates/" ] }, { "file": "chart_best_practices/values.md", "aliases": [ "/docs/topics/chart_best_practices/values/" ] }, { "file": "chart_template_guide/getting_started.md", "aliases": [ "/intro/getting_started/" ] }, { "file": "chart_template_guide/index.mdx", "aliases": [ "/topics/chart_template_guide/" ] }, { "file": "community/developers.md", "aliases": [ "/docs/developers/" ] }, { "file": "community/history.md", "aliases": [ "/docs/history/" ] }, { "file": "community/localization.md", "aliases": [ "/docs/localization/" ] }, { "file": "community/related.md", "aliases": [ "/docs/related/" ] }, { "file": "faq/index.mdx", "aliases": [ "/docs/topics/faq/", "/docs/faq/" ] }, { "file": "howto/chart_repository_sync_example.md", "aliases": [ "/docs/chart_repository_sync_example/" ] }, { "file": "howto/charts_tips_and_tricks.md", "aliases": [ "/docs/charts_tips_and_tricks/" ] }, { "file": "intro/index.mdx", "aliases": [ "/docs/using_helm/" ] }, { "file": "intro/install.md", "aliases": [ "/docs/install/" ] }, { "file": "intro/quickstart.md", "aliases": [ "/docs/quickstart/" ] }, { "file": "sdk/gosdk.md", "aliases": [ "/docs/gosdk" ] }, { "file": "topics/advanced.md", "aliases": [ "/docs/advanced_helm_techniques" ] }, { "file": "topics/architecture.md", "aliases": [ "/docs/architecture/" ] }, { "file": "topics/chart_repository.md", "aliases": [ "/docs/chart_repository/" ] }, { "file": "topics/chart_tests.md", "aliases": [ "/docs/chart_tests/" ] }, { "file": "topics/charts.md", "aliases": [ "docs/developing_charts/", "developing_charts" ] }, { "file": "topics/charts_hooks.md", "aliases": [ "/docs/charts_hooks/" ] }, { "file": "topics/kubernetes_apis.md", "aliases": [ "docs/k8s_apis/" ] }, { "file": "topics/kubernetes_distros.md", "aliases": [ "/docs/kubernetes_distros/" ] }, { "file": "topics/library_charts.md", "aliases": [ "docs/library_charts/" ] }, { "file": "topics/permissions_sql_storage_backend.md", "aliases": [ "/docs/permissions_sql_storage_backend/" ] }, { "file": "topics/plugins.md", "aliases": [ "/docs/plugins/" ] }, { "file": "topics/provenance.md", "aliases": [ "/docs/provenance/" ] }, { "file": "topics/rbac.md", "aliases": [ "/docs/rbac/" ] }, { "file": "topics/registries.md", "aliases": [ "/docs/registries/" ] } ] } ================================================ FILE: scripts/v3/sdk-href-diffs.json ================================================ [ { "line": 26, "fileName": "sdk/examples.mdx", "before": "sdkexamples/install.go", "after": "" }, { "line": 27, "fileName": "sdk/examples.mdx", "before": "sdkexamples/upgrade.go", "after": "" }, { "line": 28, "fileName": "sdk/examples.mdx", "before": "sdkexamples/uninstall.go", "after": "" }, { "line": 29, "fileName": "sdk/examples.mdx", "before": "sdkexamples/list.go", "after": "" }, { "line": 30, "fileName": "sdk/examples.mdx", "before": "sdkexamples/pull.go", "after": "" }, { "line": 31, "fileName": "sdk/examples.mdx", "before": "sdkexamples/main.go", "after": "
" }, { "line": 32, "fileName": "sdk/gosdk.md", "before": "./examples.md", "after": "examples.mdx" } ] ================================================ FILE: scripts/v4/changelog.mjs ================================================ #!/usr/bin/env node import { execSync } from "child_process"; import fs from "fs"; import path from "path"; import { fileURLToPath } from "url"; import { Octokit } from "@octokit/rest"; import simpleGit from "simple-git"; import pLimit from "p-limit"; import ora from "ora"; // ESM compatibility for __dirname const __filename = fileURLToPath(import.meta.url); const __dirname = path.dirname(__filename); // Configuration const PARALLEL_LIMIT = 10; // Process 10 commits at a time const RATE_LIMIT_THRESHOLD = 500; const PROJECT_ROOT = path.resolve(__dirname, "../.."); const HELM_REPO_DIR = path.join(PROJECT_ROOT, "orig/helm"); // Breaking changes and backported PRs (manually identified) const BREAKING_CHANGES = new Set([ 13617, 30586, 30589, 31081, 31165, 31216, 31225, 30812, 31030, 31142, 31194, 31145, 31146, 31172, 31174, 31176, 31196, 31217, 31218, 31219, 31220, 13629, 30982, 30749, 13573, 13611, 30567, 30580, 13494, 31023, 13458, 30686, ]); // Parse command line arguments const args = process.argv.slice(2); // Validate required arguments if (args.length < 2) { console.error("Error: Missing required arguments"); console.error(""); console.error( "Usage: node scripts/v4/changelog.mjs [output-file]" ); console.error(""); console.error("Examples:"); console.error(" node scripts/v4/changelog.mjs v3.19.0 v4.0.0-rc.1"); console.error(" node scripts/v4/changelog.mjs v4.0.0-beta.1 v4.0.0-beta.2"); console.error( " node scripts/v4/changelog.mjs v3.19.0 main docs/changelog.md" ); console.error(""); console.error("Arguments:"); console.error( " base-ref The starting ref (tag, branch, or commit) to compare from" ); console.error( " head-ref The ending ref (tag, branch, or commit) to compare to" ); console.error( " output-file Optional output file path (default: docs/changelog.md)" ); process.exit(1); } const BASE_REF = args[0]; const HEAD_REF = args[1]; const OUTPUT_FILE = args[2] || "docs/changelog.md"; // Get GitHub token let githubToken = process.env.GITHUB_TOKEN; if (!githubToken) { try { githubToken = execSync("gh auth token", { encoding: "utf8" }).trim(); } catch (e) { console.error("Error: GitHub authentication required"); console.error(""); console.error("Please authenticate using one of these methods:"); console.error(" 1. Run: gh auth login"); console.error( " 2. Set environment variable: export GITHUB_TOKEN=" ); console.error(""); console.error( "You can create a token at: https://github.com/settings/tokens" ); process.exit(1); } } // Initialize Octokit with auth token const octokit = new Octokit({ auth: githubToken, throttle: { onRateLimit: (retryAfter, options) => { console.log(`Rate limit hit, waiting ${retryAfter} seconds...`); return true; }, onSecondaryRateLimit: (retryAfter, options) => { console.log(`Secondary rate limit hit, waiting ${retryAfter} seconds...`); return true; }, }, }); async function setupHelmRepo() { const spinner = ora("Setting up helm repository...").start(); // Create orig directory if it doesn't exist if (!fs.existsSync(path.join(PROJECT_ROOT, "orig"))) { fs.mkdirSync(path.join(PROJECT_ROOT, "orig"), { recursive: true }); } const git = simpleGit(); if (!fs.existsSync(HELM_REPO_DIR)) { spinner.text = "Cloning helm/helm repository..."; await git.clone("https://github.com/helm/helm.git", HELM_REPO_DIR); } else { spinner.text = "Helm repository already exists, updating..."; } // Fetch latest tags const helmGit = simpleGit(HELM_REPO_DIR); spinner.text = "Fetching latest tags..."; await helmGit.fetch(["--all", "--tags"]); // Verify tags exist const tags = await helmGit.tags(); if (!tags.all.includes(BASE_REF)) { spinner.fail(`Error: Tag ${BASE_REF} not found in helm repository`); process.exit(1); } if (!tags.all.includes(HEAD_REF)) { spinner.fail(`Error: Tag ${HEAD_REF} not found in helm repository`); process.exit(1); } spinner.succeed("Helm repository ready"); return helmGit; } async function getCommits(git) { const spinner = ora("Getting commits from git...").start(); // Get all commits between refs const revListOutput = await git.raw(["rev-list", `${BASE_REF}..${HEAD_REF}`]); const allCommits = revListOutput.trim().split("\n").filter(Boolean); spinner.text = `Found ${allCommits.length} commits, filtering merge commits...`; // Filter out merge commits const nonMergeCommits = []; const limit = pLimit(20); // Check 20 commits in parallel await Promise.all( allCommits.map((sha) => limit(async () => { const parentCount = ( await git.raw(["show", "--no-patch", "--format=%P", sha]) ) .trim() .split(" ").length; if (parentCount < 2) { nonMergeCommits.push(sha); } }) ) ); spinner.succeed( `Found ${nonMergeCommits.length} non-merge commits (filtered ${ allCommits.length - nonMergeCommits.length } merge commits)` ); return nonMergeCommits; } async function checkRateLimit() { try { const { data } = await octokit.rateLimit.get(); return data.rate.remaining; } catch { return 5000; // Default if can't check } } async function fetchPRForCommit(sha, git) { try { // Get PRs associated with this commit const { data: prs } = await octokit.request( "GET /repos/{owner}/{repo}/commits/{commit_sha}/pulls", { owner: "helm", repo: "helm", commit_sha: sha, } ); if (prs.length === 0) { // Get commit info for commits without PRs const commitInfo = await git.show(["-s", "--format=%h %ai %an: %s", sha]); return { sha, commitInfo: commitInfo.trim(), prs: [] }; } // Filter out dependabot and return PR details const validPRs = prs.filter( (pr) => pr.user.login !== "dependabot" && pr.user.login !== "dependabot[bot]" ); return { sha, prs: validPRs }; } catch (error) { console.error(`Error fetching PR for commit ${sha}:`, error.message); return { sha, prs: [], error: true }; } } async function fetchAllPRs(commits, git) { const spinner = ora("Fetching PR associations...").start(); const prCache = new Map(); const commitsWithoutPRs = []; let processed = 0; let dependabotSkipped = 0; // Create a limited concurrent processor const limit = pLimit(PARALLEL_LIMIT); // Check initial rate limit const remaining = await checkRateLimit(); if (remaining < RATE_LIMIT_THRESHOLD) { console.warn(`⚠️ Low API rate limit: ${remaining} remaining`); } // Process all commits with concurrency limit const results = await Promise.all( commits.map((sha) => limit(async () => { const result = await fetchPRForCommit(sha, git); processed++; // Update progress const percentage = Math.round((processed / commits.length) * 100); spinner.text = `Fetching PR associations... ${processed}/${commits.length} (${percentage}%) - Found ${prCache.size} unique PRs`; // Process results if (result.commitInfo) { commitsWithoutPRs.push(result); } else { for (const pr of result.prs) { if (!prCache.has(pr.number)) { // Check for dependabot if ( pr.user.login === "dependabot" || pr.user.login === "dependabot[bot]" ) { dependabotSkipped++; } else { prCache.set(pr.number, { number: pr.number, title: pr.title, mergedAt: pr.merged_at, author: { login: pr.user.login }, labels: { nodes: pr.labels.map((l) => ({ name: l.name })) }, }); } } } } return result; }) ) ); spinner.succeed( `Fetched ${prCache.size} unique PRs (${dependabotSkipped} dependabot PRs skipped)` ); // Report commits without PRs if (commitsWithoutPRs.length > 0) { console.log( `\nFound ${commitsWithoutPRs.length} commits without associated PRs:` ); commitsWithoutPRs.forEach((commit, i) => { console.log(` ${i + 1}. ${commit.commitInfo}`); console.log(` SHA: ${commit.sha}`); }); } return Array.from(prCache.values()); } function categorizePRs(prs) { const categories = { features: [], bugs: [], refactor: [], other: [], backported_features: [], backported_bugs: [], backported_refactor: [], backported_other: [], }; for (const pr of prs) { const labels = pr.labels.nodes.map((n) => n.name); // Check if backported either by manual list or by "v3 port complete" label const isBackported = labels.includes("v3 port complete"); const category = isBackported ? "backported_" : ""; // Add breaking change flag if (BREAKING_CHANGES.has(pr.number)) { pr.isBreaking = true; } if (labels.includes("feature")) { categories[`${category}features`].push(pr); } else if (labels.includes("bug")) { categories[`${category}bugs`].push(pr); } else if (labels.includes("refactor")) { categories[`${category}refactor`].push(pr); } else { categories[`${category}other`].push(pr); } } return categories; } function formatPRRow(pr) { const date = pr.mergedAt ? pr.mergedAt.split("T")[0] : "unknown"; const author = pr.author.login || "unknown"; let title = pr.title; if (pr.isBreaking) { title = `BREAKING CHANGE: ${title}`; } return `| #${pr.number} | ${date} | ${author} | ${title} |`; } function sortByDate(prs) { return prs.sort((a, b) => new Date(b.mergedAt) - new Date(a.mergedAt)); } function generateMarkdown(categories, totalPRs) { const backportedCount = categories.backported_features.length + categories.backported_bugs.length + categories.backported_refactor.length + categories.backported_other.length; const v4OnlyCount = totalPRs - backportedCount; let output = `--- sidebar_position: 2 sidebar_label: Full Changelog --- # Helm 4 Full Changelog **Scope**: ${totalPRs} PRs from (\`${HEAD_REF}\`) compared to \`${BASE_REF}\` **v4-only**: ${v4OnlyCount} PRs (${backportedCount} backported to v3 excluded) See the [Overview](/overview.md) for an actionable summary of these changes. `; // New Features if (categories.features.length > 0) { output += `## New Features New features in Helm 4 that were not backported to v3 | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.features).map(formatPRRow).join("\n")} `; } // Bug Fixes if (categories.bugs.length > 0) { output += `## Bug Fixes Fixes in Helm 4 that were not backported to v3 | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.bugs).map(formatPRRow).join("\n")} `; } // Refactor/Cleanup if (categories.refactor.length > 0) { output += `## Refactor/Cleanup Code quality improvements and modernization | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.refactor).map(formatPRRow).join("\n")} `; } // Other if (categories.other.length > 0) { output += `## Other Infrastructure and project management improvements | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.other).map(formatPRRow).join("\n")} `; } // Backported section output += `## v4 Changes Also Backported to v3 These PRs were included in v4 but were also backported to v3 releases `; if (categories.backported_features.length > 0) { output += `### New Features (Backported) | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.backported_features).map(formatPRRow).join("\n")} `; } if (categories.backported_bugs.length > 0) { output += `### Bug Fixes (Backported) | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.backported_bugs).map(formatPRRow).join("\n")} `; } if (categories.backported_refactor.length > 0) { output += `### Refactor/Cleanup (Backported) | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.backported_refactor).map(formatPRRow).join("\n")} `; } if (categories.backported_other.length > 0) { output += `### Other (Backported) | PR | Date | Author | Title | |---|---|---|---| ${sortByDate(categories.backported_other).map(formatPRRow).join("\n")} `; } return output; } async function main() { console.log("==============================================="); console.log("Generating changelog with Node.js (ESM)"); console.log(`Base: ${BASE_REF}`); console.log(`Head: ${HEAD_REF}`); console.log("===============================================\n"); const startTime = Date.now(); try { // Step 1: Setup helm repository const git = await setupHelmRepo(); // Step 2: Get commits const commits = await getCommits(git); // Step 3: Fetch all PRs in parallel const prs = await fetchAllPRs(commits, git); // Step 4: Categorize PRs const spinner = ora("Categorizing PRs...").start(); const categories = categorizePRs(prs); spinner.succeed("PRs categorized"); // Step 5: Generate markdown spinner.text = "Generating markdown..."; const markdown = generateMarkdown(categories, prs.length); // Step 6: Write to file fs.writeFileSync(OUTPUT_FILE, markdown); spinner.succeed(`Changelog written to ${OUTPUT_FILE}`); // Summary const elapsed = ((Date.now() - startTime) / 1000).toFixed(1); console.log("\n✅ Complete!"); console.log(`Total time: ${elapsed} seconds`); console.log(`Total PRs: ${prs.length}`); const backportedCount = categories.backported_features.length + categories.backported_bugs.length + categories.backported_refactor.length + categories.backported_other.length; console.log(`v4-only PRs: ${prs.length - backportedCount}`); console.log(`Backported PRs: ${backportedCount}`); } catch (error) { console.error("Error:", error); process.exit(1); } } // Run the script main(); ================================================ FILE: sdkexamples/.gitignore ================================================ podinfo-6.4.1.tgz ================================================ FILE: sdkexamples/Makefile ================================================ .PHONY: build build: $(BINDIR)/$(BINNAME) go build ./... ================================================ FILE: sdkexamples/README.md ================================================ # Helm Go SDK examples This directory implements various Go SDK examples and a "driver". These examples are fully working, and can be run by: ``` # cd helm-www/sdkexamples $ go run ./... ``` ================================================ FILE: sdkexamples/go.mod ================================================ module github.com/helm/helm-www/sdkexamples go 1.24.0 require helm.sh/helm/v4 v4.0.0 require ( dario.cat/mergo v1.0.1 // indirect github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c // indirect github.com/BurntSushi/toml v1.5.0 // indirect github.com/MakeNowJust/heredoc v1.0.0 // indirect github.com/Masterminds/goutils v1.1.1 // indirect github.com/Masterminds/semver/v3 v3.4.0 // indirect github.com/Masterminds/sprig/v3 v3.3.0 // indirect github.com/Masterminds/squirrel v1.5.4 // indirect github.com/ProtonMail/go-crypto v1.3.0 // indirect github.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 // indirect github.com/blang/semver/v4 v4.0.0 // indirect github.com/chai2010/gettext-go v1.0.2 // indirect github.com/cloudflare/circl v1.6.3 // indirect github.com/cyphar/filepath-securejoin v0.6.0 // indirect github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect github.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a // indirect github.com/emicklei/go-restful/v3 v3.12.2 // indirect github.com/evanphx/json-patch/v5 v5.9.11 // indirect github.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f // indirect github.com/extism/go-sdk v1.7.1 // indirect github.com/fatih/color v1.18.0 // indirect github.com/fluxcd/cli-utils v0.36.0-flux.14 // indirect github.com/fxamacker/cbor/v2 v2.9.0 // indirect github.com/go-errors/errors v1.5.1 // indirect github.com/go-gorp/gorp/v3 v3.1.0 // indirect github.com/go-logr/logr v1.4.3 // indirect github.com/go-openapi/jsonpointer v0.21.1 // indirect github.com/go-openapi/jsonreference v0.21.0 // indirect github.com/go-openapi/swag v0.23.1 // indirect github.com/gobwas/glob v0.2.3 // indirect github.com/gogo/protobuf v1.3.2 // indirect github.com/google/btree v1.1.3 // indirect github.com/google/gnostic-models v0.7.0 // indirect github.com/google/go-cmp v0.7.0 // indirect github.com/google/uuid v1.6.0 // indirect github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674 // indirect github.com/gosuri/uitable v0.0.4 // indirect github.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79 // indirect github.com/huandu/xstrings v1.5.0 // indirect github.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca // indirect github.com/inconshreveable/mousetrap v1.1.0 // indirect github.com/jmoiron/sqlx v1.4.0 // indirect github.com/josharian/intern v1.0.0 // indirect github.com/json-iterator/go v1.1.12 // indirect github.com/lann/builder v0.0.0-20180802200727-47ae307949d0 // indirect github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 // indirect github.com/lib/pq v1.10.9 // indirect github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect github.com/mailru/easyjson v0.9.0 // indirect github.com/mattn/go-colorable v0.1.13 // indirect github.com/mattn/go-isatty v0.0.20 // indirect github.com/mattn/go-runewidth v0.0.9 // indirect github.com/mitchellh/copystructure v1.2.0 // indirect github.com/mitchellh/go-wordwrap v1.0.1 // indirect github.com/mitchellh/reflectwalk v1.0.2 // indirect github.com/moby/spdystream v0.5.1 // indirect github.com/moby/term v0.5.2 // indirect github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee // indirect github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 // indirect github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f // indirect github.com/opencontainers/go-digest v1.0.0 // indirect github.com/opencontainers/image-spec v1.1.1 // indirect github.com/peterbourgon/diskv v2.0.1+incompatible // indirect github.com/pkg/errors v0.9.1 // indirect github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect github.com/rubenv/sql-migrate v1.8.0 // indirect github.com/russross/blackfriday/v2 v2.1.0 // indirect github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 // indirect github.com/shopspring/decimal v1.4.0 // indirect github.com/spf13/cast v1.7.0 // indirect github.com/spf13/cobra v1.10.1 // indirect github.com/spf13/pflag v1.0.10 // indirect github.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834 // indirect github.com/tetratelabs/wazero v1.9.0 // indirect github.com/x448/float16 v0.8.4 // indirect github.com/xlab/treeprint v1.2.0 // indirect go.opentelemetry.io/proto/otlp v1.5.0 // indirect go.yaml.in/yaml/v2 v2.4.2 // indirect go.yaml.in/yaml/v3 v3.0.4 // indirect golang.org/x/crypto v0.45.0 // indirect golang.org/x/net v0.47.0 // indirect golang.org/x/oauth2 v0.30.0 // indirect golang.org/x/sync v0.18.0 // indirect golang.org/x/sys v0.38.0 // indirect golang.org/x/term v0.37.0 // indirect golang.org/x/text v0.31.0 // indirect golang.org/x/time v0.12.0 // indirect google.golang.org/protobuf v1.36.6 // indirect gopkg.in/evanphx/json-patch.v4 v4.12.0 // indirect gopkg.in/inf.v0 v0.9.1 // indirect gopkg.in/yaml.v3 v3.0.1 // indirect k8s.io/api v0.34.1 // indirect k8s.io/apiextensions-apiserver v0.34.1 // indirect k8s.io/apimachinery v0.34.1 // indirect k8s.io/apiserver v0.34.1 // indirect k8s.io/cli-runtime v0.34.1 // indirect k8s.io/client-go v0.34.1 // indirect k8s.io/component-base v0.34.1 // indirect k8s.io/klog/v2 v2.130.1 // indirect k8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b // indirect k8s.io/kubectl v0.34.1 // indirect k8s.io/utils v0.0.0-20250604170112-4c0f3b243397 // indirect oras.land/oras-go/v2 v2.6.0 // indirect sigs.k8s.io/controller-runtime v0.22.3 // indirect sigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8 // indirect sigs.k8s.io/kustomize/api v0.20.1 // indirect sigs.k8s.io/kustomize/kyaml v0.20.1 // indirect sigs.k8s.io/randfill v1.0.0 // indirect sigs.k8s.io/structured-merge-diff/v6 v6.3.0 // indirect sigs.k8s.io/yaml v1.6.0 // indirect ) ================================================ FILE: sdkexamples/go.sum ================================================ dario.cat/mergo v1.0.1 h1:Ra4+bf83h2ztPIQYNP99R6m+Y7KfnARDfID+a+vLl4s= dario.cat/mergo v1.0.1/go.mod h1:uNxQE+84aUszobStD9th8a29P2fMDhsBdgRYvZOxGmk= filippo.io/edwards25519 v1.1.0 h1:FNf4tywRC1HmFuKW5xopWpigGjJKiJSV0Cqo0cJWDaA= filippo.io/edwards25519 v1.1.0/go.mod h1:BxyFTGdWcka3PhytdK4V28tE5sGfRvvvRV7EaN4VDT4= github.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24 h1:bvDV9vkmnHYOMsOr4WLk+Vo07yKIzd94sVoIqshQ4bU= github.com/AdaLogics/go-fuzz-headers v0.0.0-20230811130428-ced1acdcaa24/go.mod h1:8o94RPi1/7XTJvwPpRSzSUedZrtlirdB3r9Z20bi2f8= github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c h1:udKWzYgxTojEKWjV8V+WSxDXJ4NFATAsZjh8iIbsQIg= github.com/Azure/go-ansiterm v0.0.0-20250102033503-faa5f7b0171c/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E= github.com/BurntSushi/toml v1.5.0 h1:W5quZX/G/csjUnuI8SUYlsHs9M38FC7znL0lIO+DvMg= github.com/BurntSushi/toml v1.5.0/go.mod h1:ukJfTF/6rtPPRCnwkur4qwRxa8vTRFBF0uk2lLoLwho= github.com/DATA-DOG/go-sqlmock v1.5.2 h1:OcvFkGmslmlZibjAjaHm3L//6LiuBgolP7OputlJIzU= github.com/DATA-DOG/go-sqlmock v1.5.2/go.mod h1:88MAG/4G7SMwSE3CeA0ZKzrT5CiOU3OJ+JlNzwDqpNU= github.com/MakeNowJust/heredoc v1.0.0 h1:cXCdzVdstXyiTqTvfqk9SDHpKNjxuom+DOlyEeQ4pzQ= github.com/MakeNowJust/heredoc v1.0.0/go.mod h1:mG5amYoWBHf8vpLOuehzbGGw0EHxpZZ6lCpQ4fNJ8LE= github.com/Masterminds/goutils v1.1.1 h1:5nUrii3FMTL5diU80unEVvNevw1nH4+ZV4DSLVJLSYI= github.com/Masterminds/goutils v1.1.1/go.mod h1:8cTjp+g8YejhMuvIA5y2vz3BpJxksy863GQaJW2MFNU= github.com/Masterminds/semver/v3 v3.4.0 h1:Zog+i5UMtVoCU8oKka5P7i9q9HgrJeGzI9SA1Xbatp0= github.com/Masterminds/semver/v3 v3.4.0/go.mod h1:4V+yj/TJE1HU9XfppCwVMZq3I84lprf4nC11bSS5beM= github.com/Masterminds/sprig/v3 v3.3.0 h1:mQh0Yrg1XPo6vjYXgtf5OtijNAKJRNcTdOOGZe3tPhs= github.com/Masterminds/sprig/v3 v3.3.0/go.mod h1:Zy1iXRYNqNLUolqCpL4uhk6SHUMAOSCzdgBfDb35Lz0= github.com/Masterminds/squirrel v1.5.4 h1:uUcX/aBc8O7Fg9kaISIUsHXdKuqehiXAMQTYX8afzqM= github.com/Masterminds/squirrel v1.5.4/go.mod h1:NNaOrjSoIDfDA40n7sr2tPNZRfjzjA400rg+riTZj10= github.com/ProtonMail/go-crypto v1.3.0 h1:ILq8+Sf5If5DCpHQp4PbZdS1J7HDFRXz/+xKBiRGFrw= github.com/ProtonMail/go-crypto v1.3.0/go.mod h1:9whxjD8Rbs29b4XWbB8irEcE8KHMqaR2e7GWU1R+/PE= github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5 h1:0CwZNZbxp69SHPdPJAN/hZIm0C4OItdklCFmMRWYpio= github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5/go.mod h1:wHh0iHkYZB8zMSxRWpUBQtwG5a7fFgvEO+odwuTv2gs= github.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 h1:DklsrG3dyBCFEj5IhUbnKptjxatkF07cF2ak3yi77so= github.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2/go.mod h1:WaHUgvxTVq04UNunO+XhnAqY/wQc+bxr74GqbsZ/Jqw= github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM= github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw= github.com/blang/semver/v4 v4.0.0 h1:1PFHFE6yCCTv8C1TeyNNarDzntLi7wMI5i/pzqYIsAM= github.com/blang/semver/v4 v4.0.0/go.mod h1:IbckMUScFkM3pff0VJDNKRiT6TG/YpiHIM2yvyW5YoQ= github.com/bshuster-repo/logrus-logstash-hook v1.0.0 h1:e+C0SB5R1pu//O4MQ3f9cFuPGoOVeF2fE4Og9otCc70= github.com/bshuster-repo/logrus-logstash-hook v1.0.0/go.mod h1:zsTqEiSzDgAa/8GZR7E1qaXrhYNDKBYy5/dWPTIflbk= github.com/cenkalti/backoff/v4 v4.3.0 h1:MyRJ/UdXutAwSAT+s3wNd7MfTIcy71VQueUuFK343L8= github.com/cenkalti/backoff/v4 v4.3.0/go.mod h1:Y3VNntkOUPxTVeUxJ/G5vcM//AlwfmyYozVcomhLiZE= github.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs= github.com/cespare/xxhash/v2 v2.3.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs= github.com/chai2010/gettext-go v1.0.2 h1:1Lwwip6Q2QGsAdl/ZKPCwTe9fe0CjlUbqj5bFNSjIRk= github.com/chai2010/gettext-go v1.0.2/go.mod h1:y+wnP2cHYaVj19NZhYKAwEMH2CI1gNHeQQ+5AjwawxA= github.com/cloudflare/circl v1.6.3 h1:9GPOhQGF9MCYUeXyMYlqTR6a5gTrgR/fBLXvUgtVcg8= github.com/cloudflare/circl v1.6.3/go.mod h1:2eXP6Qfat4O/Yhh8BznvKnJ+uzEoTQ6jVKJRn81BiS4= github.com/coreos/go-systemd/v22 v22.5.0 h1:RrqgGjYQKalulkV8NGVIfkXQf6YYmOyiJKk8iXXhfZs= github.com/coreos/go-systemd/v22 v22.5.0/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc= github.com/cpuguy83/go-md2man/v2 v2.0.6/go.mod h1:oOW0eioCTA6cOiMLiUPZOpcVxMig6NIQQ7OS05n1F4g= github.com/creack/pty v1.1.18 h1:n56/Zwd5o6whRC5PMGretI4IdRLlmBXYNjScPaBgsbY= github.com/creack/pty v1.1.18/go.mod h1:MOBLtS5ELjhRRrroQr9kyvTxUAFNvYEK993ew/Vr4O4= github.com/cyphar/filepath-securejoin v0.6.0 h1:BtGB77njd6SVO6VztOHfPxKitJvd/VPT+OFBFMOi1Is= github.com/cyphar/filepath-securejoin v0.6.0/go.mod h1:A8hd4EnAeyujCJRrICiOWqjS1AX0a9kM5XL+NwKoYSc= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f h1:lO4WD4F/rVNCu3HqELle0jiPLLBs70cWOduZpkS1E78= github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f/go.mod h1:cuUVRXasLTGF7a8hSLbxyZXjz+1KgoB3wDUb6vlszIc= github.com/distribution/distribution/v3 v3.0.0 h1:q4R8wemdRQDClzoNNStftB2ZAfqOiN6UX90KJc4HjyM= github.com/distribution/distribution/v3 v3.0.0/go.mod h1:tRNuFoZsUdyRVegq8xGNeds4KLjwLCRin/tTo6i1DhU= github.com/distribution/reference v0.6.0 h1:0IXCQ5g4/QMHHkarYzh5l+u8T3t73zM5QvfrDyIgxBk= github.com/distribution/reference v0.6.0/go.mod h1:BbU0aIcezP1/5jX/8MP0YiH4SdvB5Y4f/wlDRiLyi3E= github.com/dlclark/regexp2 v1.11.0 h1:G/nrcoOa7ZXlpoa/91N3X7mM3r8eIlMBBJZvsz/mxKI= github.com/dlclark/regexp2 v1.11.0/go.mod h1:DHkYz0B9wPfa6wondMfaivmHpzrQ3v9q8cnmRbL6yW8= github.com/docker/docker-credential-helpers v0.8.2 h1:bX3YxiGzFP5sOXWc3bTPEXdEaZSeVMrFgOr3T+zrFAo= github.com/docker/docker-credential-helpers v0.8.2/go.mod h1:P3ci7E3lwkZg6XiHdRKft1KckHiO9a2rNtyFbZ/ry9M= github.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c h1:+pKlWGMw7gf6bQ+oDZB4KHQFypsfjYlq/C4rfL7D3g8= github.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c/go.mod h1:Uw6UezgYA44ePAFQYUehOuCzmy5zmg/+nl2ZfMWGkpA= github.com/docker/go-metrics v0.0.1 h1:AgB/0SvBxihN0X8OR4SjsblXkbMvalQ8cjmtKQ2rQV8= github.com/docker/go-metrics v0.0.1/go.mod h1:cG1hvH2utMXtqgqqYE9plW6lDxS3/5ayHzueweSI3Vw= github.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a h1:UwSIFv5g5lIvbGgtf3tVwC7Ky9rmMFBp0RMs+6f6YqE= github.com/dylibso/observe-sdk/go v0.0.0-20240819160327-2d926c5d788a/go.mod h1:C8DzXehI4zAbrdlbtOByKX6pfivJTBiV9Jjqv56Yd9Q= github.com/emicklei/go-restful/v3 v3.12.2 h1:DhwDP0vY3k8ZzE0RunuJy8GhNpPL6zqLkDf9B/a0/xU= github.com/emicklei/go-restful/v3 v3.12.2/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc= github.com/evanphx/json-patch/v5 v5.9.11 h1:/8HVnzMq13/3x9TPvjG08wUGqBTmZBsCWzjTM0wiaDU= github.com/evanphx/json-patch/v5 v5.9.11/go.mod h1:3j+LviiESTElxA4p3EMKAB9HXj3/XEtnUf6OZxqIQTM= github.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f h1:Wl78ApPPB2Wvf/TIe2xdyJxTlb6obmF18d8QdkxNDu4= github.com/exponent-io/jsonpath v0.0.0-20210407135951-1de76d718b3f/go.mod h1:OSYXu++VVOHnXeitef/D8n/6y4QV8uLHSFXX4NeXMGc= github.com/extism/go-sdk v1.7.1 h1:lWJos6uY+tRFdlIHR+SJjwFDApY7OypS/2nMhiVQ9Sw= github.com/extism/go-sdk v1.7.1/go.mod h1:IT+Xdg5AZM9hVtpFUA+uZCJMge/hbvshl8bwzLtFyKA= github.com/fatih/color v1.18.0 h1:S8gINlzdQ840/4pfAwic/ZE0djQEH3wM94VfqLTZcOM= github.com/fatih/color v1.18.0/go.mod h1:4FelSpRwEGDpQ12mAdzqdOukCy4u8WUtOY6lkT/6HfU= github.com/felixge/httpsnoop v1.0.4 h1:NFTV2Zj1bL4mc9sqWACXbQFVBBg2W3GPvqp8/ESS2Wg= github.com/felixge/httpsnoop v1.0.4/go.mod h1:m8KPJKqk1gH5J9DgRY2ASl2lWCfGKXixSwevea8zH2U= github.com/fluxcd/cli-utils v0.36.0-flux.14 h1:I//AMVUXTc+M04UtIXArMXQZCazGMwfemodV1j/yG8c= github.com/fluxcd/cli-utils v0.36.0-flux.14/go.mod h1:uDo7BYOfbdmk/asnHuI0IQPl6u0FCgcN54AHDu3Y5As= github.com/foxcpp/go-mockdns v1.1.0 h1:jI0rD8M0wuYAxL7r/ynTrCQQq0BVqfB99Vgk7DlmewI= github.com/foxcpp/go-mockdns v1.1.0/go.mod h1:IhLeSFGed3mJIAXPH2aiRQB+kqz7oqu8ld2qVbOu7Wk= github.com/frankban/quicktest v1.14.6 h1:7Xjx+VpznH+oBnejlPUj8oUpdxnVs4f8XU8WnHkI4W8= github.com/frankban/quicktest v1.14.6/go.mod h1:4ptaffx2x8+WTWXmUCuVU6aPUX1/Mz7zb5vbUoiM6w0= github.com/fxamacker/cbor/v2 v2.9.0 h1:NpKPmjDBgUfBms6tr6JZkTHtfFGcMKsw3eGcmD/sapM= github.com/fxamacker/cbor/v2 v2.9.0/go.mod h1:vM4b+DJCtHn+zz7h3FFp/hDAI9WNWCsZj23V5ytsSxQ= github.com/go-errors/errors v1.5.1 h1:ZwEMSLRCapFLflTpT7NKaAc7ukJ8ZPEjzlxt8rPN8bk= github.com/go-errors/errors v1.5.1/go.mod h1:sIVyrIiJhuEF+Pj9Ebtd6P/rEYROXFi3BopGUQ5a5Og= github.com/go-gorp/gorp/v3 v3.1.0 h1:ItKF/Vbuj31dmV4jxA1qblpSwkl9g1typ24xoe70IGs= github.com/go-gorp/gorp/v3 v3.1.0/go.mod h1:dLEjIyyRNiXvNZ8PSmzpt1GsWAUK8kjVhEpjH8TixEw= github.com/go-logr/logr v1.4.3 h1:CjnDlHq8ikf6E492q6eKboGOC0T8CDaOvkHCIg8idEI= github.com/go-logr/logr v1.4.3/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY= github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag= github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE= github.com/go-logr/zapr v1.3.0 h1:XGdV8XW8zdwFiwOA2Dryh1gj2KRQyOOoNmBy4EplIcQ= github.com/go-logr/zapr v1.3.0/go.mod h1:YKepepNBd1u/oyhd/yQmtjVXmm9uML4IXUgMOwR8/Gg= github.com/go-openapi/jsonpointer v0.21.1 h1:whnzv/pNXtK2FbX/W9yJfRmE2gsmkfahjMKB0fZvcic= github.com/go-openapi/jsonpointer v0.21.1/go.mod h1:50I1STOfbY1ycR8jGz8DaMeLCdXiI6aDteEdRNNzpdk= github.com/go-openapi/jsonreference v0.21.0 h1:Rs+Y7hSXT83Jacb7kFyjn4ijOuVGSvOdF2+tg1TRrwQ= github.com/go-openapi/jsonreference v0.21.0/go.mod h1:LmZmgsrTkVg9LG4EaHeY8cBDslNPMo06cago5JNLkm4= github.com/go-openapi/swag v0.23.1 h1:lpsStH0n2ittzTnbaSloVZLuB5+fvSY/+hnagBjSNZU= github.com/go-openapi/swag v0.23.1/go.mod h1:STZs8TbRvEQQKUA+JZNAm3EWlgaOBGpyFDqQnDHMef0= github.com/go-sql-driver/mysql v1.8.1 h1:LedoTUt/eveggdHS9qUFC1EFSa8bU2+1pZjSRpvNJ1Y= github.com/go-sql-driver/mysql v1.8.1/go.mod h1:wEBSXgmK//2ZFJyE+qWnIsVGmvmEKlqwuVSjsCm7DZg= github.com/go-task/slim-sprig/v3 v3.0.0 h1:sUs3vkvUymDpBKi3qH1YSqBQk9+9D/8M2mN1vB6EwHI= github.com/go-task/slim-sprig/v3 v3.0.0/go.mod h1:W848ghGpv3Qj3dhTPRyJypKRiqCdHZiAzKg9hl15HA8= github.com/gobwas/glob v0.2.3 h1:A4xDbljILXROh+kObIiy5kIaPYD8e96x1tgBhUI5J+Y= github.com/gobwas/glob v0.2.3/go.mod h1:d3Ez4x06l9bZtSvzIay5+Yzi0fmZzPgnTbPcKjJAkT8= github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q= github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q= github.com/google/btree v1.1.3 h1:CVpQJjYgC4VbzxeGVHfvZrv1ctoYCAI8vbl07Fcxlyg= github.com/google/btree v1.1.3/go.mod h1:qOPhT0dTNdNzV6Z/lhRX0YXUafgPLFUh+gZMl761Gm4= github.com/google/gnostic-models v0.7.0 h1:qwTtogB15McXDaNqTZdzPJRHvaVJlAl+HVQnLmJEJxo= github.com/google/gnostic-models v0.7.0/go.mod h1:whL5G0m6dmc5cPxKc5bdKdEN3UjI7OUGxBlw57miDrQ= github.com/google/go-cmp v0.7.0 h1:wk8382ETsv4JYUZwIsn6YpYiWiBsYLSJiTsyBybVuN8= github.com/google/go-cmp v0.7.0/go.mod h1:pXiqmnSA92OHEEa9HXL2W4E7lf9JzCmGVUdgjX3N/iU= github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= github.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5 h1:xhMrHhTJ6zxu3gA4enFM9MLn9AY7613teCdFnlUVbSQ= github.com/google/pprof v0.0.0-20250630185457-6e76a2b096b5/go.mod h1:5hDyRhoBCxViHszMt12TnOpEI4VVi+U8Gm9iphldiMA= github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0= github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= github.com/gorilla/handlers v1.5.2 h1:cLTUSsNkgcwhgRqvCNmdbRWG0A3N4F+M2nWKdScwyEE= github.com/gorilla/handlers v1.5.2/go.mod h1:dX+xVpaxdSw+q0Qek8SSsl3dfMk3jNddUkMzo0GtH0w= github.com/gorilla/mux v1.8.1 h1:TuBL49tXwgrFYWhqrNgrUNEY92u81SPhu7sTdzQEiWY= github.com/gorilla/mux v1.8.1/go.mod h1:AKf9I4AEqPTmMytcMc0KkNouC66V3BtZ4qD5fmWSiMQ= github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674 h1:JeSE6pjso5THxAzdVpqr6/geYxZytqFMBCOtn/ujyeo= github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674/go.mod h1:r4w70xmWCQKmi1ONH4KIaBptdivuRPyosB9RmPlGEwA= github.com/gosuri/uitable v0.0.4 h1:IG2xLKRvErL3uhY6e1BylFzG+aJiwQviDDTfOKeKTpY= github.com/gosuri/uitable v0.0.4/go.mod h1:tKR86bXuXPZazfOTG1FIzvjIdXzd0mo4Vtn16vt0PJo= github.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79 h1:+ngKgrYPPJrOjhax5N+uePQ0Fh1Z7PheYoUI/0nzkPA= github.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3 h1:5ZPtiqj0JL5oKWmcsq4VMaAW5ukBEgSGXEN89zeH1Jo= github.com/grpc-ecosystem/grpc-gateway/v2 v2.26.3/go.mod h1:ndYquD05frm2vACXE1nsccT4oJzjhw2arTS2cpUD1PI= github.com/hashicorp/golang-lru/arc/v2 v2.0.5 h1:l2zaLDubNhW4XO3LnliVj0GXO3+/CGNJAg1dcN2Fpfw= github.com/hashicorp/golang-lru/arc/v2 v2.0.5/go.mod h1:ny6zBSQZi2JxIeYcv7kt2sH2PXJtirBN7RDhRpxPkxU= github.com/hashicorp/golang-lru/v2 v2.0.5 h1:wW7h1TG88eUIJ2i69gaE3uNVtEPIagzhGvHgwfx2Vm4= github.com/hashicorp/golang-lru/v2 v2.0.5/go.mod h1:QeFd9opnmA6QUJc5vARoKUSoFhyfM2/ZepoAG6RGpeM= github.com/huandu/xstrings v1.5.0 h1:2ag3IFq9ZDANvthTwTiqSSZLjDc+BedvHPAp5tJy2TI= github.com/huandu/xstrings v1.5.0/go.mod h1:y5/lhBue+AyNmUVz9RLU9xbLR0o4KIIExikq4ovT0aE= github.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca h1:T54Ema1DU8ngI+aef9ZhAhNGQhcRTrWxVeG07F+c/Rw= github.com/ianlancetaylor/demangle v0.0.0-20240805132620-81f5be970eca/go.mod h1:gx7rwoVhcfuVKG5uya9Hs3Sxj7EIvldVofAWIUtGouw= github.com/inconshreveable/mousetrap v1.1.0 h1:wN+x4NVGpMsO7ErUn/mUI3vEoE6Jt13X2s0bqwp9tc8= github.com/inconshreveable/mousetrap v1.1.0/go.mod h1:vpF70FUmC8bwa3OWnCshd2FqLfsEA9PFc4w1p2J65bw= github.com/jmoiron/sqlx v1.4.0 h1:1PLqN7S1UYp5t4SrVVnt4nUVNemrDAtxlulVe+Qgm3o= github.com/jmoiron/sqlx v1.4.0/go.mod h1:ZrZ7UsYB/weZdl2Bxg6jCRO9c3YHl8r3ahlKmRT4JLY= github.com/josharian/intern v1.0.0 h1:vlS4z54oSdjm0bgjRigI+G1HpF+tI+9rE5LLzOg8HmY= github.com/josharian/intern v1.0.0/go.mod h1:5DoeVV0s6jJacbCEi61lwdGj/aVlrQvzHFFd8Hwg//Y= github.com/json-iterator/go v1.1.12 h1:PV8peI4a0ysnczrg+LtxykD8LfKY9ML6u2jnxaEnrnM= github.com/json-iterator/go v1.1.12/go.mod h1:e30LSqwooZae/UwlEbR2852Gd8hjQvJoHmT4TnhNGBo= github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8= github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck= github.com/klauspost/compress v1.18.0 h1:c/Cqfb0r+Yi+JtIEq73FWXVkRonBlf0CRNYc8Zttxdo= github.com/klauspost/compress v1.18.0/go.mod h1:2Pp+KzxcywXVXMr50+X0Q/Lsb43OQHYWRCY2AiWywWQ= github.com/kr/pretty v0.3.1 h1:flRD4NNwYAUpkphVc1HcthR4KEIFJ65n8Mw5qdRn3LE= github.com/kr/pretty v0.3.1/go.mod h1:hoEshYVHaxMs3cyo3Yncou5ZscifuDolrwPKZanG3xk= github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY= github.com/kr/text v0.2.0/go.mod h1:eLer722TekiGuMkidMxC/pM04lWEeraHUUmBw8l2grE= github.com/lann/builder v0.0.0-20180802200727-47ae307949d0 h1:SOEGU9fKiNWd/HOJuq6+3iTQz8KNCLtVX6idSoTLdUw= github.com/lann/builder v0.0.0-20180802200727-47ae307949d0/go.mod h1:dXGbAdH5GtBTC4WfIxhKZfyBF/HBFgRZSWwZ9g/He9o= github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 h1:P6pPBnrTSX3DEVR4fDembhRWSsG5rVo6hYhAB/ADZrk= github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0/go.mod h1:vmVJ0l/dxyfGW6FmdpVm2joNMFikkuWg0EoCKLGUMNw= github.com/lib/pq v1.10.9 h1:YXG7RB+JIjhP29X+OtkiDnYaXQwpS4JEWq7dtCCRUEw= github.com/lib/pq v1.10.9/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o= github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de h1:9TO3cAIGXtEhnIaL+V+BEER86oLrvS+kWobKpbJuye0= github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de/go.mod h1:zAbeS9B/r2mtpb6U+EI2rYA5OAXxsYw6wTamcNW+zcE= github.com/mailru/easyjson v0.9.0 h1:PrnmzHw7262yW8sTBwxi1PdJA3Iw/EKBa8psRf7d9a4= github.com/mailru/easyjson v0.9.0/go.mod h1:1+xMtQp2MRNVL/V1bOzuP3aP8VNwRW55fQUto+XFtTU= github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA= github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg= github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM= github.com/mattn/go-isatty v0.0.20 h1:xfD0iDuEKnDkl03q4limB+vH+GxLEtL/jb4xVJSWWEY= github.com/mattn/go-isatty v0.0.20/go.mod h1:W+V8PltTTMOvKvAeJH7IuucS94S2C6jfK/D7dTCTo3Y= github.com/mattn/go-runewidth v0.0.9 h1:Lm995f3rfxdpd6TSmuVCHVb/QhupuXlYr8sCI/QdE+0= github.com/mattn/go-runewidth v0.0.9/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI= github.com/mattn/go-sqlite3 v1.14.22 h1:2gZY6PC6kBnID23Tichd1K+Z0oS6nE/XwU+Vz/5o4kU= github.com/mattn/go-sqlite3 v1.14.22/go.mod h1:Uh1q+B4BYcTPb+yiD3kU8Ct7aC0hY9fxUwlHK0RXw+Y= github.com/miekg/dns v1.1.57 h1:Jzi7ApEIzwEPLHWRcafCN9LZSBbqQpxjt/wpgvg7wcM= github.com/miekg/dns v1.1.57/go.mod h1:uqRjCRUuEAA6qsOiJvDd+CFo/vW+y5WR6SNmHE55hZk= github.com/mitchellh/copystructure v1.2.0 h1:vpKXTN4ewci03Vljg/q9QvCGUDttBOGBIa15WveJJGw= github.com/mitchellh/copystructure v1.2.0/go.mod h1:qLl+cE2AmVv+CoeAwDPye/v+N2HKCj9FbZEVFJRxO9s= github.com/mitchellh/go-wordwrap v1.0.1 h1:TLuKupo69TCn6TQSyGxwI1EblZZEsQ0vMlAFQflz0v0= github.com/mitchellh/go-wordwrap v1.0.1/go.mod h1:R62XHJLzvMFRBbcrT7m7WgmE1eOyTSsCt+hzestvNj0= github.com/mitchellh/reflectwalk v1.0.2 h1:G2LzWKi524PWgd3mLHV8Y5k7s6XUvT0Gef6zxSIeXaQ= github.com/mitchellh/reflectwalk v1.0.2/go.mod h1:mSTlrgnPZtwu0c4WaC2kGObEpuNDbx0jmZXqmk4esnw= github.com/moby/spdystream v0.5.1 h1:9sNYeYZUcci9R6/w7KDaFWEWeV4LStVG78Mpyq/Zm/Y= github.com/moby/spdystream v0.5.1/go.mod h1:xBAYlnt/ay+11ShkdFKNAG7LsyK/tmNBVvVOwrfMgdI= github.com/moby/term v0.5.2 h1:6qk3FJAFDs6i/q3W/pQ97SX192qKfZgGjCQqfCJkgzQ= github.com/moby/term v0.5.2/go.mod h1:d3djjFCrjnB+fl8NJux+EJzu0msscUP+f8it8hPkFLc= github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg= github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= github.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk= github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee h1:W5t00kpgFdJifH4BDsTlE89Zl93FEloxaWZfGcifgq8= github.com/modern-go/reflect2 v1.0.3-0.20250322232337-35a7c28c31ee/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk= github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 h1:n6/2gBQ3RWajuToeY6ZtZTIKv2v7ThUy5KKusIT0yc0= github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00/go.mod h1:Pm3mSP3c5uWn86xMLZ5Sa7JB9GsEZySvHYXCTK4E9q4= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f h1:y5//uYreIhSUg3J1GEMiLbxo1LJaP8RfCpH6pymGZus= github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f/go.mod h1:ZdcZmHo+o7JKHSa8/e818NopupXU1YMK5fe1lsApnBw= github.com/onsi/ginkgo/v2 v2.23.4 h1:ktYTpKJAVZnDT4VjxSbiBenUjmlL/5QkBEocaWXiQus= github.com/onsi/ginkgo/v2 v2.23.4/go.mod h1:Bt66ApGPBFzHyR+JO10Zbt0Gsp4uWxu5mIOTusL46e8= github.com/onsi/gomega v1.37.0 h1:CdEG8g0S133B4OswTDC/5XPSzE1OeP29QOioj2PID2Y= github.com/onsi/gomega v1.37.0/go.mod h1:8D9+Txp43QWKhM24yyOBEdpkzN8FvJyAwecBgsU4KU0= github.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U= github.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM= github.com/opencontainers/image-spec v1.1.1 h1:y0fUlFfIZhPF1W537XOLg0/fcx6zcHCJwooC2xJA040= github.com/opencontainers/image-spec v1.1.1/go.mod h1:qpqAh3Dmcf36wStyyWU+kCeDgrGnAve2nCC8+7h8Q0M= github.com/peterbourgon/diskv v2.0.1+incompatible h1:UBdAOUP5p4RWqPBg048CAvpKN+vxiaj6gdUUzhl4XmI= github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU= github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4= github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRIccs7FGNTlIRMkT8wgtp5eCXdBlqhYGL6U= github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/poy/onpar v1.1.2 h1:QaNrNiZx0+Nar5dLgTVp5mXkyoVFIbepjyEoGSnhbAY= github.com/poy/onpar v1.1.2/go.mod h1:6X8FLNoxyr9kkmnlqpK6LSoiOtrO6MICtWwEuWkLjzg= github.com/prometheus/client_golang v1.22.0 h1:rb93p9lokFEsctTys46VnV1kLCDpVZ0a/Y92Vm0Zc6Q= github.com/prometheus/client_golang v1.22.0/go.mod h1:R7ljNsLXhuQXYZYtw6GAE9AZg8Y7vEW5scdCXrWRXC0= github.com/prometheus/client_model v0.6.2 h1:oBsgwpGs7iVziMvrGhE53c/GrLUsZdHnqNwqPLxwZyk= github.com/prometheus/client_model v0.6.2/go.mod h1:y3m2F6Gdpfy6Ut/GBsUqTWZqCUvMVzSfMLjcu6wAwpE= github.com/prometheus/common v0.65.0 h1:QDwzd+G1twt//Kwj/Ww6E9FQq1iVMmODnILtW1t2VzE= github.com/prometheus/common v0.65.0/go.mod h1:0gZns+BLRQ3V6NdaerOhMbwwRbNh9hkGINtQAsP5GS8= github.com/prometheus/procfs v0.17.0 h1:FuLQ+05u4ZI+SS/w9+BWEM2TXiHKsUQ9TADiRH7DuK0= github.com/prometheus/procfs v0.17.0/go.mod h1:oPQLaDAMRbA+u8H5Pbfq+dl3VDAvHxMUOVhe0wYB2zw= github.com/redis/go-redis/extra/rediscmd/v9 v9.0.5 h1:EaDatTxkdHG+U3Bk4EUr+DZ7fOGwTfezUiUJMaIcaho= github.com/redis/go-redis/extra/rediscmd/v9 v9.0.5/go.mod h1:fyalQWdtzDBECAQFBJuQe5bzQ02jGd5Qcbgb97Flm7U= github.com/redis/go-redis/extra/redisotel/v9 v9.0.5 h1:EfpWLLCyXw8PSM2/XNJLjI3Pb27yVE+gIAfeqp8LUCc= github.com/redis/go-redis/extra/redisotel/v9 v9.0.5/go.mod h1:WZjPDy7VNzn77AAfnAfVjZNvfJTYfPetfZk5yoSTLaQ= github.com/redis/go-redis/v9 v9.7.3 h1:YpPyAayJV+XErNsatSElgRZZVCwXX9QzkKYNvO7x0wM= github.com/redis/go-redis/v9 v9.7.3/go.mod h1:bGUrSggJ9X9GUmZpZNEOQKaANxSGgOEBRltRTZHSvrA= github.com/rogpeppe/go-internal v1.13.1 h1:KvO1DLK/DRN07sQ1LQKScxyZJuNnedQ5/wKSR38lUII= github.com/rogpeppe/go-internal v1.13.1/go.mod h1:uMEvuHeurkdAXX61udpOXGD/AzZDWNMNyH2VO9fmH0o= github.com/rubenv/sql-migrate v1.8.0 h1:dXnYiJk9k3wetp7GfQbKJcPHjVJL6YK19tKj8t2Ns0o= github.com/rubenv/sql-migrate v1.8.0/go.mod h1:F2bGFBwCU+pnmbtNYDeKvSuvL6lBVtXDXUUv5t+u1qw= github.com/russross/blackfriday/v2 v2.1.0 h1:JIOH55/0cWyOuilr9/qlrm0BSXldqnqwMsf35Ld67mk= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2 h1:KRzFb2m7YtdldCEkzs6KqmJw4nqEVZGK7IN2kJkjTuQ= github.com/santhosh-tekuri/jsonschema/v6 v6.0.2/go.mod h1:JXeL+ps8p7/KNMjDQk3TCwPpBy0wYklyWTfbkIzdIFU= github.com/sergi/go-diff v1.2.0 h1:XU+rvMAioB0UC3q1MFrIQy4Vo5/4VsRDQQXHsEya6xQ= github.com/sergi/go-diff v1.2.0/go.mod h1:STckp+ISIX8hZLjrqAeVduY0gWCT9IjLuqbuNXdaHfM= github.com/shopspring/decimal v1.4.0 h1:bxl37RwXBklmTi0C79JfXCEBD1cqqHt0bbgBAGFp81k= github.com/shopspring/decimal v1.4.0/go.mod h1:gawqmDU56v4yIKSwfBSFip1HdCCXN8/+DMd9qYNcwME= github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ= github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ= github.com/spf13/cast v1.7.0 h1:ntdiHjuueXFgm5nzDRdOS4yfT43P5Fnud6DH50rz/7w= github.com/spf13/cast v1.7.0/go.mod h1:ancEpBxwJDODSW/UG4rDrAqiKolqNNh2DX3mk86cAdo= github.com/spf13/cobra v1.10.1 h1:lJeBwCfmrnXthfAupyUTzJ/J4Nc1RsHC/mSRU2dll/s= github.com/spf13/cobra v1.10.1/go.mod h1:7SmJGaTHFVBY0jW4NXGluQoLvhqFQM+6XSKD+P4XaB0= github.com/spf13/pflag v1.0.9/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= github.com/spf13/pflag v1.0.10 h1:4EBh2KAYBwaONj6b2Ye1GiHfwjqyROoF4RwYO+vPwFk= github.com/spf13/pflag v1.0.10/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/objx v0.5.2 h1:xuMeJ0Sdp5ZMRXx/aWO6RZxdr3beISkG5/G/aIRr3pY= github.com/stretchr/objx v0.5.2/go.mod h1:FRsXN1f5AsAjCGJKqEizvkpNtU+EGNCLh3NxZ/8L+MA= github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI= github.com/stretchr/testify v1.6.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg= github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg= github.com/stretchr/testify v1.11.1 h1:7s2iGBzp5EwR7/aIZr8ao5+dra3wiQyKjjFuvgVKu7U= github.com/stretchr/testify v1.11.1/go.mod h1:wZwfW3scLgRK+23gO65QZefKpKQRnfz6sD981Nm4B6U= github.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834 h1:ZF+QBjOI+tILZjBaFj3HgFonKXUcwgJ4djLb6i42S3Q= github.com/tetratelabs/wabin v0.0.0-20230304001439-f6f874872834/go.mod h1:m9ymHTgNSEjuxvw8E7WWe4Pl4hZQHXONY8wE6dMLaRk= github.com/tetratelabs/wazero v1.9.0 h1:IcZ56OuxrtaEz8UYNRHBrUa9bYeX9oVY93KspZZBf/I= github.com/tetratelabs/wazero v1.9.0/go.mod h1:TSbcXCfFP0L2FGkRPxHphadXPjo1T6W+CseNNY7EkjM= github.com/x448/float16 v0.8.4 h1:qLwI1I70+NjRFUR3zs1JPUCgaCXSh3SW62uAKT1mSBM= github.com/x448/float16 v0.8.4/go.mod h1:14CWIYCyZA/cWjXOioeEpHeN/83MdbZDRQHoFcYsOfg= github.com/xlab/treeprint v1.2.0 h1:HzHnuAF1plUN2zGlAFHbSQP2qJ0ZAD3XF5XD7OesXRQ= github.com/xlab/treeprint v1.2.0/go.mod h1:gj5Gd3gPdKtR1ikdDK6fnFLdmIS0X30kTTuNd/WEJu0= github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= go.opentelemetry.io/auto/sdk v1.1.0 h1:cH53jehLUN6UFLY71z+NDOiNJqDdPRaXzTel0sJySYA= go.opentelemetry.io/auto/sdk v1.1.0/go.mod h1:3wSPjt5PWp2RhlCcmmOial7AvC4DQqZb7a7wCow3W8A= go.opentelemetry.io/contrib/bridges/prometheus v0.57.0 h1:UW0+QyeyBVhn+COBec3nGhfnFe5lwB0ic1JBVjzhk0w= go.opentelemetry.io/contrib/bridges/prometheus v0.57.0/go.mod h1:ppciCHRLsyCio54qbzQv0E4Jyth/fLWDTJYfvWpcSVk= go.opentelemetry.io/contrib/exporters/autoexport v0.57.0 h1:jmTVJ86dP60C01K3slFQa2NQ/Aoi7zA+wy7vMOKD9H4= go.opentelemetry.io/contrib/exporters/autoexport v0.57.0/go.mod h1:EJBheUMttD/lABFyLXhce47Wr6DPWYReCzaZiXadH7g= go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.58.0 h1:yd02MEjBdJkG3uabWP9apV+OuWRIXGDuJEUJbOHmCFU= go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.58.0/go.mod h1:umTcuxiv1n/s/S6/c2AT/g2CQ7u5C59sHDNmfSwgz7Q= go.opentelemetry.io/otel v1.37.0 h1:9zhNfelUvx0KBfu/gb+ZgeAfAgtWrfHJZcAqFC228wQ= go.opentelemetry.io/otel v1.37.0/go.mod h1:ehE/umFRLnuLa/vSccNq9oS1ErUlkkK71gMcN34UG8I= go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.8.0 h1:WzNab7hOOLzdDF/EoWCt4glhrbMPVMOO5JYTmpz36Ls= go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.8.0/go.mod h1:hKvJwTzJdp90Vh7p6q/9PAOd55dI6WA6sWj62a/JvSs= go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp v0.8.0 h1:S+LdBGiQXtJdowoJoQPEtI52syEP/JYBUpjO49EQhV8= go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp v0.8.0/go.mod h1:5KXybFvPGds3QinJWQT7pmXf+TN5YIa7CNYObWRkj50= go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.32.0 h1:j7ZSD+5yn+lo3sGV69nW04rRR0jhYnBwjuX3r0HvnK0= go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc v1.32.0/go.mod h1:WXbYJTUaZXAbYd8lbgGuvih0yuCfOFC5RJoYnoLcGz8= go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.32.0 h1:t/Qur3vKSkUCcDVaSumWF2PKHt85pc7fRvFuoVT8qFU= go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp v1.32.0/go.mod h1:Rl61tySSdcOJWoEgYZVtmnKdA0GeKrSqkHC1t+91CH8= go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.34.0 h1:OeNbIYk/2C15ckl7glBlOBp5+WlYsOElzTNmiPW/x60= go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.34.0/go.mod h1:7Bept48yIeqxP2OZ9/AqIpYS94h2or0aB4FypJTc8ZM= go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.34.0 h1:tgJ0uaNS4c98WRNUEx5U3aDlrDOI5Rs+1Vifcw4DJ8U= go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.34.0/go.mod h1:U7HYyW0zt/a9x5J1Kjs+r1f/d4ZHnYFclhYY2+YbeoE= go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.32.0 h1:cMyu9O88joYEaI47CnQkxO1XZdpoTF9fEnW2duIddhw= go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp v1.32.0/go.mod h1:6Am3rn7P9TVVeXYG+wtcGE7IE1tsQ+bP3AuWcKt/gOI= go.opentelemetry.io/otel/exporters/prometheus v0.54.0 h1:rFwzp68QMgtzu9PgP3jm9XaMICI6TsofWWPcBDKwlsU= go.opentelemetry.io/otel/exporters/prometheus v0.54.0/go.mod h1:QyjcV9qDP6VeK5qPyKETvNjmaaEc7+gqjh4SS0ZYzDU= go.opentelemetry.io/otel/exporters/stdout/stdoutlog v0.8.0 h1:CHXNXwfKWfzS65yrlB2PVds1IBZcdsX8Vepy9of0iRU= go.opentelemetry.io/otel/exporters/stdout/stdoutlog v0.8.0/go.mod h1:zKU4zUgKiaRxrdovSS2amdM5gOc59slmo/zJwGX+YBg= go.opentelemetry.io/otel/exporters/stdout/stdoutmetric v1.32.0 h1:SZmDnHcgp3zwlPBS2JX2urGYe/jBKEIT6ZedHRUyCz8= go.opentelemetry.io/otel/exporters/stdout/stdoutmetric v1.32.0/go.mod h1:fdWW0HtZJ7+jNpTKUR0GpMEDP69nR8YBJQxNiVCE3jk= go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.32.0 h1:cC2yDI3IQd0Udsux7Qmq8ToKAx1XCilTQECZ0KDZyTw= go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.32.0/go.mod h1:2PD5Ex6z8CFzDbTdOlwyNIUywRr1DN0ospafJM1wJ+s= go.opentelemetry.io/otel/log v0.8.0 h1:egZ8vV5atrUWUbnSsHn6vB8R21G2wrKqNiDt3iWertk= go.opentelemetry.io/otel/log v0.8.0/go.mod h1:M9qvDdUTRCopJcGRKg57+JSQ9LgLBrwwfC32epk5NX8= go.opentelemetry.io/otel/metric v1.37.0 h1:mvwbQS5m0tbmqML4NqK+e3aDiO02vsf/WgbsdpcPoZE= go.opentelemetry.io/otel/metric v1.37.0/go.mod h1:04wGrZurHYKOc+RKeye86GwKiTb9FKm1WHtO+4EVr2E= go.opentelemetry.io/otel/sdk v1.34.0 h1:95zS4k/2GOy069d321O8jWgYsW3MzVV+KuSPKp7Wr1A= go.opentelemetry.io/otel/sdk v1.34.0/go.mod h1:0e/pNiaMAqaykJGKbi+tSjWfNNHMTxoC9qANsCzbyxU= go.opentelemetry.io/otel/sdk/log v0.8.0 h1:zg7GUYXqxk1jnGF/dTdLPrK06xJdrXgqgFLnI4Crxvs= go.opentelemetry.io/otel/sdk/log v0.8.0/go.mod h1:50iXr0UVwQrYS45KbruFrEt4LvAdCaWWgIrsN3ZQggo= go.opentelemetry.io/otel/sdk/metric v1.34.0 h1:5CeK9ujjbFVL5c1PhLuStg1wxA7vQv7ce1EK0Gyvahk= go.opentelemetry.io/otel/sdk/metric v1.34.0/go.mod h1:jQ/r8Ze28zRKoNRdkjCZxfs6YvBTG1+YIqyFVFYec5w= go.opentelemetry.io/otel/trace v1.37.0 h1:HLdcFNbRQBE2imdSEgm/kwqmQj1Or1l/7bW6mxVK7z4= go.opentelemetry.io/otel/trace v1.37.0/go.mod h1:TlgrlQ+PtQO5XFerSPUYG0JSgGyryXewPGyayAWSBS0= go.opentelemetry.io/proto/otlp v1.5.0 h1:xJvq7gMzB31/d406fB8U5CBdyQGw4P399D1aQWU/3i4= go.opentelemetry.io/proto/otlp v1.5.0/go.mod h1:keN8WnHxOy8PG0rQZjJJ5A2ebUoafqWp0eVQ4yIXvJ4= go.uber.org/automaxprocs v1.6.0 h1:O3y2/QNTOdbF+e/dpXNNW7Rx2hZ4sTIPyybbxyNqTUs= go.uber.org/automaxprocs v1.6.0/go.mod h1:ifeIMSnPZuznNm6jmdzmU3/bfk01Fe2fotchwEFJ8r8= go.uber.org/goleak v1.3.0 h1:2K3zAYmnTNqV73imy9J1T3WC+gmCePx2hEGkimedGto= go.uber.org/goleak v1.3.0/go.mod h1:CoHD4mav9JJNrW/WLlf7HGZPjdw8EucARQHekz1X6bE= go.uber.org/multierr v1.11.0 h1:blXXJkSxSSfBVBlC76pxqeO+LN3aDfLQo+309xJstO0= go.uber.org/multierr v1.11.0/go.mod h1:20+QtiLqy0Nd6FdQB9TLXag12DsQkrbs3htMFfDN80Y= go.uber.org/zap v1.27.0 h1:aJMhYGrd5QSmlpLMr2MftRKl7t8J8PTZPA732ud/XR8= go.uber.org/zap v1.27.0/go.mod h1:GB2qFLM7cTU87MWRP2mPIjqfIDnGu+VIO4V/SdhGo2E= go.yaml.in/yaml/v2 v2.4.2 h1:DzmwEr2rDGHl7lsFgAHxmNz/1NlQ7xLIrlN2h5d1eGI= go.yaml.in/yaml/v2 v2.4.2/go.mod h1:081UH+NErpNdqlCXm3TtEran0rJZGxAYx9hb/ELlsPU= go.yaml.in/yaml/v3 v3.0.4 h1:tfq32ie2Jv2UxXFdLJdh3jXuOzWiL1fo0bu/FbuKpbc= go.yaml.in/yaml/v3 v3.0.4/go.mod h1:DhzuOOF2ATzADvBadXxruRBLzYTpT36CKvDb3+aBEFg= golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto= golang.org/x/crypto v0.45.0 h1:jMBrvKuj23MTlT0bQEOBcAE0mjg8mK9RXFhRH6nyF3Q= golang.org/x/crypto v0.45.0/go.mod h1:XTGrrkGJve7CYK7J8PEww4aY7gM3qMCElcJQ8n8JdX4= golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= golang.org/x/mod v0.29.0 h1:HV8lRxZC4l2cr3Zq1LvtOsi/ThTgWnUk/y64QSs8GwA= golang.org/x/mod v0.29.0/go.mod h1:NyhrlYXJ2H4eJiRy/WDBO6HMqZQ6q9nk4JzS3NuCK+w= golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU= golang.org/x/net v0.47.0 h1:Mx+4dIFzqraBXUugkia1OOvlD6LemFo1ALMHjrXDOhY= golang.org/x/net v0.47.0/go.mod h1:/jNxtkgq5yWUGYkaZGqo27cfGZ1c5Nen03aYrrKpVRU= golang.org/x/oauth2 v0.30.0 h1:dnDm7JmhM45NNpd8FDDeLhK6FwqbOf4MLCM9zb1BOHI= golang.org/x/oauth2 v0.30.0/go.mod h1:B++QgG3ZKulg6sRPGD/mqlHQs5rB3Ml9erfeDY7xKlU= golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.18.0 h1:kr88TuHDroi+UVf+0hZnirlk8o8T+4MrK6mr60WkH/I= golang.org/x/sync v0.18.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI= golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= golang.org/x/sys v0.0.0-20210616094352-59db8d763f22/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc= golang.org/x/sys v0.38.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks= golang.org/x/term v0.37.0 h1:8EGAD0qCmHYZg6J17DvsMy9/wJ7/D/4pV/wfnld5lTU= golang.org/x/term v0.37.0/go.mod h1:5pB4lxRNYYVZuTLmy8oR2BH8dflOR+IbTYFD8fi3254= golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ= golang.org/x/text v0.31.0 h1:aC8ghyu4JhP8VojJ2lEHBnochRno1sgL6nEi9WGFGMM= golang.org/x/text v0.31.0/go.mod h1:tKRAlv61yKIjGGHX/4tP1LTbc13YSec1pxVEWXzfoeM= golang.org/x/time v0.12.0 h1:ScB/8o8olJvc+CQPWrK3fPZNfh7qgwCrY0zJmoEQLSE= golang.org/x/time v0.12.0/go.mod h1:CDIdPxbZBQxdj6cxyCIdrNogrJKMJ7pr37NYpMcMDSg= golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= golang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA= golang.org/x/tools v0.38.0 h1:Hx2Xv8hISq8Lm16jvBZ2VQf+RLmbd7wVUsALibYI/IQ= golang.org/x/tools v0.38.0/go.mod h1:yEsQ/d/YK8cjh0L6rZlY8tgtlKiBNTL14pGDJPJpYQs= golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= google.golang.org/genproto/googleapis/api v0.0.0-20250303144028-a0af3efb3deb h1:p31xT4yrYrSM/G4Sn2+TNUkVhFCbG9y8itM2S6Th950= google.golang.org/genproto/googleapis/api v0.0.0-20250303144028-a0af3efb3deb/go.mod h1:jbe3Bkdp+Dh2IrslsFCklNhweNTBgSYanP1UXhJDhKg= google.golang.org/genproto/googleapis/rpc v0.0.0-20250303144028-a0af3efb3deb h1:TLPQVbx1GJ8VKZxz52VAxl1EBgKXXbTiU9Fc5fZeLn4= google.golang.org/genproto/googleapis/rpc v0.0.0-20250303144028-a0af3efb3deb/go.mod h1:LuRYeWDFV6WOn90g357N17oMCaxpgCnbi/44qJvDn2I= google.golang.org/grpc v1.72.1 h1:HR03wO6eyZ7lknl75XlxABNVLLFc2PAb6mHlYh756mA= google.golang.org/grpc v1.72.1/go.mod h1:wH5Aktxcg25y1I3w7H69nHfXdOG3UiadoBtjh3izSDM= google.golang.org/protobuf v1.36.6 h1:z1NpPI8ku2WgiWnf+t9wTPsn6eP1L7ksHUlkfLvd9xY= google.golang.org/protobuf v1.36.6/go.mod h1:jduwjTPXsFjZGTmRluh+L6NjiWu7pchiJ2/5YcXBHnY= gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c h1:Hei/4ADfdWqJk1ZMxUNpqntNwaWcugrBjAiHlqqRiVk= gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c/go.mod h1:JHkPIbrfpd72SG/EVd6muEfDQjcINNoR0C8j2r3qZ4Q= gopkg.in/evanphx/json-patch.v4 v4.12.0 h1:n6jtcsulIzXPJaxegRbvFNNrZDjbij7ny3gmSPG+6V4= gopkg.in/evanphx/json-patch.v4 v4.12.0/go.mod h1:p8EYWUEYMpynmqDbY58zCKCFZw8pRWMG4EsWvDvM72M= gopkg.in/inf.v0 v0.9.1 h1:73M5CoZyi3ZLMOyDlQh031Cx6N9NDJ2Vvfl76EDAgDc= gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw= gopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY= gopkg.in/yaml.v2 v2.4.0/go.mod h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ= gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA= gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= helm.sh/helm/v4 v4.0.0 h1:Ppai7cygdmyxSR+JR9djUoVrRmyMI/yY5P5TBd25oHs= helm.sh/helm/v4 v4.0.0/go.mod h1:G1Y5AE+lJPQSAjh7nbXnhZrtGtxo+I6POSu9DruYiGI= k8s.io/api v0.34.1 h1:jC+153630BMdlFukegoEL8E/yT7aLyQkIVuwhmwDgJM= k8s.io/api v0.34.1/go.mod h1:SB80FxFtXn5/gwzCoN6QCtPD7Vbu5w2n1S0J5gFfTYk= k8s.io/apiextensions-apiserver v0.34.1 h1:NNPBva8FNAPt1iSVwIE0FsdrVriRXMsaWFMqJbII2CI= k8s.io/apiextensions-apiserver v0.34.1/go.mod h1:hP9Rld3zF5Ay2Of3BeEpLAToP+l4s5UlxiHfqRaRcMc= k8s.io/apimachinery v0.34.1 h1:dTlxFls/eikpJxmAC7MVE8oOeP1zryV7iRyIjB0gky4= k8s.io/apimachinery v0.34.1/go.mod h1:/GwIlEcWuTX9zKIg2mbw0LRFIsXwrfoVxn+ef0X13lw= k8s.io/apiserver v0.34.1 h1:U3JBGdgANK3dfFcyknWde1G6X1F4bg7PXuvlqt8lITA= k8s.io/apiserver v0.34.1/go.mod h1:eOOc9nrVqlBI1AFCvVzsob0OxtPZUCPiUJL45JOTBG0= k8s.io/cli-runtime v0.34.1 h1:btlgAgTrYd4sk8vJTRG6zVtqBKt9ZMDeQZo2PIzbL7M= k8s.io/cli-runtime v0.34.1/go.mod h1:aVA65c+f0MZiMUPbseU/M9l1Wo2byeaGwUuQEQVVveE= k8s.io/client-go v0.34.1 h1:ZUPJKgXsnKwVwmKKdPfw4tB58+7/Ik3CrjOEhsiZ7mY= k8s.io/client-go v0.34.1/go.mod h1:kA8v0FP+tk6sZA0yKLRG67LWjqufAoSHA2xVGKw9Of8= k8s.io/component-base v0.34.1 h1:v7xFgG+ONhytZNFpIz5/kecwD+sUhVE6HU7qQUiRM4A= k8s.io/component-base v0.34.1/go.mod h1:mknCpLlTSKHzAQJJnnHVKqjxR7gBeHRv0rPXA7gdtQ0= k8s.io/klog/v2 v2.130.1 h1:n9Xl7H1Xvksem4KFG4PYbdQCQxqc/tTUyrgXaOhHSzk= k8s.io/klog/v2 v2.130.1/go.mod h1:3Jpz1GvMt720eyJH1ckRHK1EDfpxISzJ7I9OYgaDtPE= k8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b h1:MloQ9/bdJyIu9lb1PzujOPolHyvO06MXG5TUIj2mNAA= k8s.io/kube-openapi v0.0.0-20250710124328-f3f2b991d03b/go.mod h1:UZ2yyWbFTpuhSbFhv24aGNOdoRdJZgsIObGBUaYVsts= k8s.io/kubectl v0.34.1 h1:1qP1oqT5Xc93K+H8J7ecpBjaz511gan89KO9Vbsh/OI= k8s.io/kubectl v0.34.1/go.mod h1:JRYlhJpGPyk3dEmJ+BuBiOB9/dAvnrALJEiY/C5qa6A= k8s.io/utils v0.0.0-20250604170112-4c0f3b243397 h1:hwvWFiBzdWw1FhfY1FooPn3kzWuJ8tmbZBHi4zVsl1Y= k8s.io/utils v0.0.0-20250604170112-4c0f3b243397/go.mod h1:OLgZIPagt7ERELqWJFomSt595RzquPNLL48iOWgYOg0= oras.land/oras-go/v2 v2.6.0 h1:X4ELRsiGkrbeox69+9tzTu492FMUu7zJQW6eJU+I2oc= oras.land/oras-go/v2 v2.6.0/go.mod h1:magiQDfG6H1O9APp+rOsvCPcW1GD2MM7vgnKY0Y+u1o= sigs.k8s.io/controller-runtime v0.22.3 h1:I7mfqz/a/WdmDCEnXmSPm8/b/yRTy6JsKKENTijTq8Y= sigs.k8s.io/controller-runtime v0.22.3/go.mod h1:+QX1XUpTXN4mLoblf4tqr5CQcyHPAki2HLXqQMY6vh8= sigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8 h1:gBQPwqORJ8d8/YNZWEjoZs7npUVDpVXUUOFfW6CgAqE= sigs.k8s.io/json v0.0.0-20241014173422-cfa47c3a1cc8/go.mod h1:mdzfpAEoE6DHQEN0uh9ZbOCuHbLK5wOm7dK4ctXE9Tg= sigs.k8s.io/kustomize/api v0.20.1 h1:iWP1Ydh3/lmldBnH/S5RXgT98vWYMaTUL1ADcr+Sv7I= sigs.k8s.io/kustomize/api v0.20.1/go.mod h1:t6hUFxO+Ph0VxIk1sKp1WS0dOjbPCtLJ4p8aADLwqjM= sigs.k8s.io/kustomize/kyaml v0.20.1 h1:PCMnA2mrVbRP3NIB6v9kYCAc38uvFLVs8j/CD567A78= sigs.k8s.io/kustomize/kyaml v0.20.1/go.mod h1:0EmkQHRUsJxY8Ug9Niig1pUMSCGHxQ5RklbpV/Ri6po= sigs.k8s.io/randfill v1.0.0 h1:JfjMILfT8A6RbawdsK2JXGBR5AQVfd+9TbzrlneTyrU= sigs.k8s.io/randfill v1.0.0/go.mod h1:XeLlZ/jmk4i1HRopwe7/aU3H5n1zNUcX6TM94b3QxOY= sigs.k8s.io/structured-merge-diff/v6 v6.3.0 h1:jTijUJbW353oVOd9oTlifJqOGEkUw2jB/fXCbTiQEco= sigs.k8s.io/structured-merge-diff/v6 v6.3.0/go.mod h1:M3W8sfWvn2HhQDIbGWj3S099YozAsymCo/wrT5ohRUE= sigs.k8s.io/yaml v1.6.0 h1:G8fkbMSAFqgEFgh4b1wmtzDnioxFCUgTZhlbj5P9QYs= sigs.k8s.io/yaml v1.6.0/go.mod h1:796bPqUfzR/0jLAl6XjHl3Ck7MiyVv8dbTdyT3/pMf4= ================================================ FILE: sdkexamples/install.go ================================================ package main import ( "context" "fmt" "log" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/chart" "helm.sh/helm/v4/pkg/chart/loader" "helm.sh/helm/v4/pkg/cli" "helm.sh/helm/v4/pkg/downloader" "helm.sh/helm/v4/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunStrategy = "none" installClient.WaitStrategy = "watcher" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClient( settings, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) charter, err := loader.Load(chartPath) if err != nil { return err } chartAccessor, err := chart.NewDefaultAccessor(charter) if err != nil { return fmt.Errorf("error creating chart accessor: %w", err) } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chartAccessor.MetaDependencies(); chartDependencies != nil { if err := action.CheckDependencies(charter, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if charter, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } _, err = installClient.RunWithContext(ctx, charter, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created") return nil } ================================================ FILE: sdkexamples/list.go ================================================ package main import ( "fmt" "log" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ================================================ FILE: sdkexamples/main.go ================================================ package main import ( "bufio" "context" "fmt" "log" "net/http" "os" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" "helm.sh/helm/v4/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, certFile, keyFile, caFile string, insecureSkipTLSVerify, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSVerify { tlsConf, err := NewTLSConfig( WithInsecureSkipVerify(insecureSkipTLSVerify), WithCertKeyPairFiles(certFile, keyFile), WithCAFile(caFile), ) if err != nil { return nil, fmt.Errorf("failed to load client TLS certs: %w", err) } opts = append(opts, registry.ClientOptHTTPClient(&http.Client{ Transport: &http.Transport{ TLSClientConfig: tlsConf, Proxy: http.ProxyFromEnvironment, }, })) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, fmt.Errorf("failed to initialize registry client: %w", err) } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ================================================ FILE: sdkexamples/pull.go ================================================ package main import ( "fmt" "log" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } pullClient := action.NewPull(action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion registryClient, err := newRegistryClient( settings, pullClient.CertFile, pullClient.KeyFile, pullClient.CaFile, pullClient.InsecureSkipTLSverify, pullClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ================================================ FILE: sdkexamples/tlsutil.go ================================================ /* Copyright The Helm Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package main import ( "crypto/tls" "crypto/x509" "fmt" "os" "errors" ) type TLSConfigOptions struct { insecureSkipTLSverify bool certPEMBlock, keyPEMBlock []byte caPEMBlock []byte } type TLSConfigOption func(options *TLSConfigOptions) error func WithInsecureSkipVerify(insecureSkipTLSverify bool) TLSConfigOption { return func(options *TLSConfigOptions) error { options.insecureSkipTLSverify = insecureSkipTLSverify return nil } } func WithCertKeyPairFiles(certFile, keyFile string) TLSConfigOption { return func(options *TLSConfigOptions) error { if certFile == "" && keyFile == "" { return nil } certPEMBlock, err := os.ReadFile(certFile) if err != nil { return fmt.Errorf("unable to read cert file: %q: %w", certFile, err) } keyPEMBlock, err := os.ReadFile(keyFile) if err != nil { return fmt.Errorf("unable to read key file: %q: %w", keyFile, err) } options.certPEMBlock = certPEMBlock options.keyPEMBlock = keyPEMBlock return nil } } func WithCAFile(caFile string) TLSConfigOption { return func(options *TLSConfigOptions) error { if caFile == "" { return nil } caPEMBlock, err := os.ReadFile(caFile) if err != nil { return fmt.Errorf("can't read CA file: %q: %w", caFile, err) } options.caPEMBlock = caPEMBlock return nil } } func NewTLSConfig(options ...TLSConfigOption) (*tls.Config, error) { to := TLSConfigOptions{} errs := []error{} for _, option := range options { err := option(&to) if err != nil { errs = append(errs, err) } } if len(errs) > 0 { return nil, errors.Join(errs...) } config := tls.Config{ InsecureSkipVerify: to.insecureSkipTLSverify, } if len(to.certPEMBlock) > 0 && len(to.keyPEMBlock) > 0 { cert, err := tls.X509KeyPair(to.certPEMBlock, to.keyPEMBlock) if err != nil { return nil, fmt.Errorf("unable to load cert from key pair: %w", err) } config.Certificates = []tls.Certificate{cert} } if len(to.caPEMBlock) > 0 { cp := x509.NewCertPool() if !cp.AppendCertsFromPEM(to.caPEMBlock) { return nil, fmt.Errorf("failed to append certificates from pem block") } config.RootCAs = cp } return &config, nil } ================================================ FILE: sdkexamples/uninstall.go ================================================ package main import ( "fmt" "log" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" uninstallClient.WaitStrategy = "watcher" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", result.Info) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ================================================ FILE: sdkexamples/upgrade.go ================================================ package main import ( "context" "fmt" "log" "helm.sh/helm/v4/pkg/action" "helm.sh/helm/v4/pkg/chart" "helm.sh/helm/v4/pkg/chart/loader" "helm.sh/helm/v4/pkg/cli" "helm.sh/helm/v4/pkg/downloader" "helm.sh/helm/v4/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunStrategy = "none" upgradeClient.Version = chartVersion upgradeClient.WaitStrategy = "watcher" registryClient, err := newRegistryClient( settings, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts charter, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } chartAccessor, err := chart.NewDefaultAccessor(charter) if err != nil { return fmt.Errorf("error creating chart accessor: %w", err) } if chartDependencies := chartAccessor.MetaDependencies(); chartDependencies != nil { if err := action.CheckDependencies(charter, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if charter, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, charter, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ================================================ FILE: sidebars.js ================================================ // @ts-check // This runs in Node.js - Don't use client-side code here (browser APIs, JSX...) /** * Creating a sidebar enables you to: - create an ordered group of docs - render a sidebar for each doc of that group - provide next/previous navigation The sidebars can be generated from the filesystem, or explicitly defined here. Create as many sidebars as you want. @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ const sidebars = { // By default, Docusaurus generates a sidebar from the docs folder structure tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], // But you can create a sidebar manually /* tutorialSidebar: [ 'intro', 'hello', { type: 'category', label: 'Tutorial', items: ['tutorial-basics/create-a-document'], }, ], */ }; export default sidebars; ================================================ FILE: sidebars_community.js ================================================ module.exports = { communitySidebar: [ { type: 'autogenerated', dirName: '.', }, ], }; ================================================ FILE: src/client-modules/heroHeightCalculator.js ================================================ // Hero height calculator client module function initializeHeroHeightCalculation() { // Only run in browser environment if (typeof window === 'undefined' || typeof document === 'undefined') { return; } // Move hero to outer scope so it's accessible by all functions let hero = null; function calculateHeroHeight() { hero = document.querySelector(".hero"); if (!hero) { // Retry after React components have rendered setTimeout(calculateHeroHeight, 100); return; } function updateHeroHeight() { // Safety check - hero might have been removed from DOM if (!hero) { return; } const vh = window.innerHeight; const navbar = document.querySelector(".navbar"); const navbarHeight = navbar ? navbar.offsetHeight : 0; // Check for announcement bar const announcementBar = document.querySelector( "div.theme-announcement-bar" ); let announcementBarHeight = 0; if (announcementBar && announcementBar.offsetHeight > 0) { // Only count it if it's visible and has height announcementBarHeight = announcementBar.offsetHeight; } const heroHeight = vh - navbarHeight - announcementBarHeight; // Apply the calculated height (with safety check) if (hero && hero.style) { hero.style.height = `${heroHeight}px`; hero.style.minHeight = `${heroHeight}px`; hero.style.maxHeight = `${heroHeight}px`; } } // Throttled scroll and resize handler let ticking = false; function requestTick() { if (!ticking) { requestAnimationFrame(updateHeroHeight); ticking = true; setTimeout(() => (ticking = false), 16); } } function handleResize() { updateHeroHeight(); } // Event listeners window.addEventListener("resize", handleResize); window.addEventListener("orientationchange", () => { setTimeout(handleResize, 100); }); // iOS Safari specific events window.addEventListener("pageshow", handleResize); // Watch for announcement bar close button clicks function observeAnnouncementBar() { const announcementBar = document.querySelector("div.theme-announcement-bar"); if (announcementBar) { const closeButton = announcementBar.querySelector("button"); if (closeButton) { closeButton.addEventListener("click", () => { // Delay recalculation to allow DOM to update after close animation setTimeout(handleResize, 300); }); } } } // Set up announcement bar observer observeAnnouncementBar(); // Initial setup with multiple attempts for better compatibility updateHeroHeight(); observeAnnouncementBar(); // Delayed recalculation for dynamic content setTimeout(() => { updateHeroHeight(); observeAnnouncementBar(); }, 100); setTimeout(() => { updateHeroHeight(); observeAnnouncementBar(); }, 500); } // Track if we've successfully applied styles let stylesApplied = false; function ensureHeroStylesApplied() { if (!stylesApplied && hero && hero.style.height) { stylesApplied = true; return true; } return false; } // Initialize with multiple strategies to catch hydration function initializeHero() { calculateHeroHeight(); // Keep trying until styles are actually applied let attempts = 0; const checkInterval = setInterval(() => { attempts++; if (ensureHeroStylesApplied() || attempts > 20) { clearInterval(checkInterval); } else { calculateHeroHeight(); } }, 100); } // Initialize on page load if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', initializeHero); } else { initializeHero(); } // Also listen for React hydration completion if (typeof window !== 'undefined') { // React 18+ hydration const reactRoot = document.getElementById('__docusaurus'); if (reactRoot) { // Use MutationObserver to detect when React modifies the DOM const observer = new MutationObserver((mutations) => { if (window.location.pathname === '/' && !stylesApplied) { calculateHeroHeight(); if (ensureHeroStylesApplied()) { observer.disconnect(); } } }); observer.observe(reactRoot, { childList: true, subtree: true, attributes: true, attributeFilter: ['class', 'style'] }); // Disconnect after 5 seconds to prevent memory leaks setTimeout(() => observer.disconnect(), 5000); } } // Force scroll to top AFTER browser's scroll restoration if (window.location.pathname === '/') { // Disable scroll restoration for this page if ('scrollRestoration' in history) { history.scrollRestoration = 'manual'; } // Multiple attempts to ensure we stay at top window.scrollTo(0, 0); setTimeout(() => window.scrollTo(0, 0), 0); setTimeout(() => window.scrollTo(0, 0), 100); setTimeout(() => window.scrollTo(0, 0), 300); } // Handle Docusaurus route changes window.addEventListener('docusaurus:route-did-update', () => { if (window.location.pathname === '/') { stylesApplied = false; // Reset for new navigation setTimeout(initializeHero, 100); } }); // Handle client-side navigation (Docusaurus SPA routing) const originalPushState = history.pushState; const originalReplaceState = history.replaceState; history.pushState = function() { originalPushState.apply(history, arguments); setTimeout(() => { calculateHeroHeight(); }, 100); }; history.replaceState = function() { originalReplaceState.apply(history, arguments); setTimeout(() => { calculateHeroHeight(); }, 100); }; window.addEventListener("popstate", () => { setTimeout(() => { calculateHeroHeight(); }, 100); }); // Handle hot module replacement during development if (module.hot) { module.hot.addStatusHandler((status) => { if (status === 'idle') { setTimeout(calculateHeroHeight, 200); } }); } // Alternative: Listen for React's development mode updates if (typeof window !== 'undefined' && window.__REACT_DEVTOOLS_GLOBAL_HOOK__) { const hook = window.__REACT_DEVTOOLS_GLOBAL_HOOK__; if (hook.onCommitFiberRoot) { const originalOnCommitFiberRoot = hook.onCommitFiberRoot; hook.onCommitFiberRoot = function() { originalOnCommitFiberRoot.apply(this, arguments); setTimeout(calculateHeroHeight, 100); }; } } } // Execute immediately when module is imported initializeHeroHeightCalculation(); ================================================ FILE: src/components/Boat/boat.css ================================================ /** * Helm boat animation styles. */ @keyframes boat-bob { 0% { bottom: max(1.5rem, 2vw); transform: rotate(4deg); } 50% { bottom: max(2.1rem, 3.5vw); transform: rotate(-6deg); } 100% { bottom: max(1.5rem, 2vw); transform: rotate(4deg); } } @keyframes boat-badge-bob { 0% { top: 0.425vw; transform: rotate(-4deg); } 50% { top: 0.75vw; transform: rotate(2deg); } 100% { top: 0.425vw; transform: rotate(-4deg); } } @keyframes move-forever { 0% { transform: translate3d(-90px, 0, 0); } 100% { transform: translate3d(85px, 0, 0); } } /* override search bar to give more z-index room between the navbar and boat layers */ /* Navbar is --ifm-z-index-fixed, and search was --ifm-z-index-fixed + 1 */ body .DocSearch-Container { z-index: calc(var(--ifm-z-index-fixed) + 10); } .boat { width: auto; position: absolute; top: auto; bottom: 0; left: 0; right: 0; min-height: 10vw; z-index: calc(var(--ifm-z-index-fixed) + 5); transition: all 0.5s ease-in-out; /* Ensure boat is positioned relative to its parent and contained within borders */ } .boat .boat-ship { position: absolute; margin-top: max(0.25rem, 0.5vw); left: max(1.5rem, 3.25vw); bottom: max(6rem, 2vw); max-width: max(8rem, 15vw); /* Minimum 8rem boat, scales with viewport */ z-index: calc(var(--ifm-z-index-fixed) + 4); animation: boat-bob 7s ease-in-out infinite; transition: all 0.5s ease-in-out; } .boat:after { content: "ahoy!"; font-family: var(--ifm-heading-font-family); font-size: 0.75rem; padding: 0.75em; color: var(--navy); background: var(--salmon); position: absolute; bottom: 8vw; left: 13.5vw; line-height: 1; z-index: calc(var(--ifm-z-index-fixed) + 1); opacity: 0; transition: all 0.3s ease-in-out; border-radius: 4px; } .boat:hover:after { opacity: 1; bottom: 11vw; } .boat .wave-wrapper { position: absolute; margin: 0; left: 0; right: 0; bottom: 0; height: max(3rem, 6vw); /* Just tall enough for waves */ overflow: visible; z-index: calc(var(--ifm-z-index-fixed) + 2); background-color: transparent; transition: all 0.5s ease-in-out; } .boat .wave-wrapper:before { position: absolute; bottom: 0; left: 0; right: 0; content: " "; height: max(1.8rem, 3.5vw); /* Scale down more to match boat */ width: 100%; background: var(--blue-light); transition: all 0.3s ease-in-out; } .boat .wave-wrapper .waves { position: relative; width: 100%; height: max(1.2rem, 3vw); /* Scale down more to match boat */ transition: all 0.3s ease-in-out; } .boat .parallax > use { animation: move-forever 25s ease-in-out infinite; } .boat .parallax > use:nth-child(1) { animation-delay: -2s; animation-duration: 7s; } .boat .parallax > use:nth-child(2) { animation-delay: -3s; animation-duration: 10s; } .boat .parallax > use:nth-child(3) { animation-delay: -4s; animation-duration: 13s; } .boat .parallax > use:nth-child(4) { animation-delay: -5s; animation-duration: 20s; } /* Boat fixed nav 'badge' mode */ .boat.boat-badge { position: fixed; top: calc(var(--ifm-navbar-height) + 0.25rem); left: 1rem; width: 7.5vw; height: 7.5vw; z-index: calc( var(--ifm-z-index-fixed) - 1 ); /* Lower z-index to stay below navbar */ max-width: 80px; max-height: 80px; } .boat.boat-badge .boat-ship { left: 0.636vw; top: 0.2vw; z-index: calc(var(--ifm-z-index-fixed) + 3); max-width: 7vw; animation: boat-badge-bob 7s ease-in-out infinite; bottom: auto; right: auto; } .boat.boat-badge .wave-wrapper { width: 7.5vw; height: 7.5vw; border-radius: 50%; border: 3px solid rgba(255, 255, 255, 0.05); background-blend-mode: screen; background: rgba(219, 225, 243, 0.5); bottom: auto; right: auto; overflow: hidden; } .boat.boat-badge .wave-wrapper .waves { margin-top: 3.75vw; margin-bottom: -7px; min-height: 0.25vw; max-height: 1.5vw; } .boat.boat-badge .wave-wrapper:before { width: 100%; height: 3vw; top: 5.25vw; bottom: auto; right: auto; } .boat.boat-badge:after { display: none; /* Hide the tooltip in badge mode */ } .boat.boat-badge:hover:after { display: none; } /* Responsive adjustments for boat badge */ @media screen and (max-width: 768px) { /* Keep boat positioning absolute to stay at bottom of hero section */ .boat { position: absolute; /* Keep absolute positioning */ bottom: 0; /* Stay at bottom */ width: 100vw; } .boat .boat-ship { max-width: 15vw; min-width: 100px; /* Add minimum size for mobile */ } .boat.boat-badge { width: 60px; height: 60px; max-width: 60px; max-height: 60px; } .boat.boat-badge .boat-ship { left: 0.3rem; top: 0.1rem; max-width: 60px; min-width: 60px; } .boat.boat-badge .wave-wrapper { width: 60px; height: 60px; } .boat.boat-badge .wave-wrapper .waves { margin-top: 30px; } .boat.boat-badge .wave-wrapper:before { height: 25px; top: 35px; } } ================================================ FILE: src/components/Boat/index.js ================================================ import { useState, useEffect } from "react"; import "./boat.css"; export default function BoatComponent() { const [isBadgeMode, setIsBadgeMode] = useState(false); useEffect(() => { const handleScroll = () => { // Switch to badge mode when scrolled down more than the viewport height const scrollPosition = window.scrollY; const triggerPoint = window.innerHeight * 0.7; // Trigger at 70% of viewport height setIsBadgeMode(scrollPosition > triggerPoint); }; window.addEventListener("scroll", handleScroll); return () => window.removeEventListener("scroll", handleScroll); }, []); return (
boat
); } ================================================ FILE: src/components/GetVersion.js ================================================ import { useVersions } from "@docusaurus/plugin-content-docs/client"; import Link from "@docusaurus/Link"; /** * Component to find and return the label for a specific major version as a raw string. * @param {object} props * @param {string} props.majorVersion The major version number to find (e.g., "4") * @param {boolean} props.label Whether or not to return the configured Docusaurus label for this major version or just the SemVer string * @param {boolean} props.link Whether or not to wrap the version-or-label in the link to the GitHub release for this version */ export default function GetVersion({ majorVersion, label, link }) { const versions = useVersions(); // Official SemVer 2.0.0 ECMA-compatible RegEx // ref: https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string // Example: a label like "4.0.0-rc.1 🚧" has a SemVer match array like: // 0: "4.0.0-rc.1" // 1: "4" // 2: "0" // 3: "0" // 4: "rc.1" const semverRegex = /(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?/; let SemVerMatch = null; let ReturnValue = null; const targetVersion = versions.find((version) => { const match = version.label.match(semverRegex); if (match) { const extractedMajor = match[1]; if (extractedMajor === majorVersion) { SemVerMatch = match[0]; return true; } } return false; }); if (!targetVersion) { return `${majorVersion}.x (not found)`; } if (label) { // Return the string value of the label ReturnValue = targetVersion.label; } else { // Return only the SemVer ReturnValue = `v${SemVerMatch}`; } if (link) { return ( {ReturnValue} ); } else { return ReturnValue; } } ================================================ FILE: src/components/HomeAbout/index.js ================================================ import Heading from '@theme/Heading'; import clsx from 'clsx'; import styles from './styles.module.css'; import homeSections from '@site/src/css/home-sections.module.css'; import Translate from '@docusaurus/Translate'; const Pyramid = require("@site/static/img/helm-pyramid-solid.svg").default; function About() { return (

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste.

CNCF ), helmCommunityLink: ( Helm community ), }}> {'Helm is a graduated project in the {cncfLink} and is maintained by the {helmCommunityLink}.'}

Learn more:

); } export default function HomeAbout() { return (
What is Helm?
); } ================================================ FILE: src/components/HomeAbout/styles.module.css ================================================ .pyramid { display: block; margin: 0 auto 2rem; height: 6rem; width: auto; } ================================================ FILE: src/components/HomeCommunity/index.js ================================================ import React from "react"; import clsx from "clsx"; import Heading from "@theme/Heading"; import styles from "./styles.module.css"; import homeSections from "@site/src/css/home-sections.module.css"; import homeCards from "@site/src/css/home-cards.module.css"; import Translate from "@docusaurus/Translate"; import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; import { MdVideoCall, MdForum, MdSchedule, MdCalendarToday, MdRocketLaunch, MdGroup, MdVideoLibrary, MdLogin, MdCalendarMonth, } from "react-icons/md"; function CustomDate({dateString, formatType, endDateString}) { const {i18n} = useDocusaurusContext(); const date = new Date(dateString); const formats = { day: { day: 'numeric', month: 'short', year: 'numeric' }, month: { month: 'long', year: 'numeric' }, }; if (formatType === 'dayRange') { const startDate = new Date(dateString); const endDate = endDateString ? new Date(endDateString) : new Date(startDate.getTime() + 4 * 24 * 60 * 60 * 1000); // 4 days later if no endDate const formatter = new Intl.DateTimeFormat(i18n.currentLocale, { day: 'numeric', month: 'short', }); const yearFormatter = new Intl.DateTimeFormat(i18n.currentLocale, { year: 'numeric' }); const startFormatted = formatter.format(startDate); const endFormatted = formatter.format(endDate); const year = yearFormatter.format(startDate); return ( {startFormatted} - {endFormatted}, {year} ); } else { const options = formats[formatType] || formats['day']; const formatter = new Intl.DateTimeFormat(i18n.currentLocale, options); return {formatter.format(date)}; } } const BlockList = [ { title: ( Next Feature Release ), description: ( <>
v4.2.0
Release Calendar
), }, { title: ( Events ), description: ( <>
Upcoming Events
-{" "} KubeCon Europe 2026
Past Events
-{" "} KubeCon North America 2025
-{" "} KubeCon Europe 2025
-{" "} KubeCon North America 2024
), }, { title: ( SIG Apps ), description: ( <>

meet each week ), youtubeLink: ( shared to YouTube ), }} > { "They {meetLink} to demo and discuss tools and projects. Community meetings are recorded and {youtubeLink}." }

), }, { title: ( Developer Standups ), description: ( <>

Thursdays 9:30-10am (PT)

community repo ), }} > { "These meetings are open to all. Check the {communityRepoLink} for notes and details." }

), }, { title: "Slack", description: ( <>

Request access here ), }} > {"{slackLink} to join the Kubernetes Slack team."}

Helm Users
Discussion around using Helm, working with charts and solving common errors.
Helm Development
Topics regarding Helm development, ongoing PRs, releases, etc.
Charts
Discussion for users and contributors to Helm Charts.
), }, { title: ( Contributing ), description: ( <>

Helm always welcomes new contributions to the project!

Where to begin?

Helm is a big project with a lot of users and contributors. It can be a lot to take in!

good first issues ), }} > { "We have a list of {goodFirstIssuesLink} if you want to help but don't know where to start." }

What do I do?

Contribution Guide ), }} > { "Before you contribute some code, please read our {contributionGuideLink}. It goes over the processes around creating and reviewing pull requests." }

sign your commits ), dcoLink: DCO, cncfLink: CNCF, }} > { "After you write some code, please {signYourCommitsLink} to ensure Helm adheres to the {dcoLink} agreement used by the {cncfLink}." }

), }, ]; function Block({ title, description }) { return (
{title}
{description}
); } export default function HomeCommunity() { return (
Join the Community

More information about the Helm project, and how to contribute.

{BlockList.map((props, idx) => ( ))}
); } ================================================ FILE: src/components/HomeCommunity/styles.module.css ================================================ /* Component has no specific styles - uses shared home module styles */ /* Material Design Icon styling */ .icon { vertical-align: middle; margin-right: 0.5rem; font-size: 1.2em; /* Make React Icons larger to match other icon libraries */ } ================================================ FILE: src/components/HomeFeatures/index.js ================================================ import clsx from 'clsx'; import Heading from '@theme/Heading'; import styles from './styles.module.css'; import homeSections from "@site/src/css/home-sections.module.css"; import homeCards from "@site/src/css/home-cards.module.css"; import Translate from '@docusaurus/Translate'; const FeatureList = [ { title: Manage Complexity, description: ( <> Charts describe even the most complex apps, provide repeatable application installation, and serve as a single point of authority. ), }, { title: Easy Updates, description: ( <> Take the pain out of updates with in-place upgrades and custom hooks. ), }, { title: Simple Sharing, description: ( <> Charts are easy to version, share, and host on public or private servers. ), }, { title: Rollbacks, description: ( <> helm rollback ), }}> {'Use {helmRollback} to roll back to an older version of a release with ease.'} ), }, ]; function Feature({ title, description }) { return (
{title}

{description}

); } export default function HomeFeatures() { return (
Features
{FeatureList.map((props, idx) => ( ))}
); } ================================================ FILE: src/components/HomeFeatures/styles.module.css ================================================ /* Component has no specific styles - uses shared home module styles */ ================================================ FILE: src/components/HomeGettingStarted/index.js ================================================ import Heading from "@theme/Heading"; import clsx from "clsx"; import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem"; import CodeBlock from "@theme/CodeBlock"; import styles from "./styles.module.css"; import homeSections from "@site/src/css/home-sections.module.css"; import homeCards from "@site/src/css/home-cards.module.css"; import Translate from '@docusaurus/Translate'; export default function HomeGettingStarted() { return (
Getting Started
Get Helm

download a binary ), }}> {'Install Helm with a package manager, or {downloadLink}.'}

brew install helm choco install kubernetes-helm scoop install helm sudo snap install helm --classic

docs ), installationLink: ( installation ), usageLink: ( usage instructions ), }}> {'Once installed, unpack the helm binary and add it to your PATH and you are good to go! Check the {docsLink} for further {installationLink} and {usageLink}.'}

Get Charts

Artifact Hub ), helmChartsLink: ( Helm charts ), }}> {'Visit {artifactHubLink} to explore {helmChartsLink} from numerous public repositories.'}

Artifact Hub
); } ================================================ FILE: src/components/HomeGettingStarted/styles.module.css ================================================ .gettingStarted :global(.card) { height: 100%; } .gettingStarted :global(.col) { margin-bottom: 1rem; } /* Install Helm tabs */ .gettingStarted :global(.tabs) { /* Needed to wrap tabs. Wrap instead of horizontal overflow scrolling or scaling smaller */ flex-wrap: wrap; } /* Use standard Helm link color for tabs */ .gettingStarted :global(.tabs__item) { color: var(--ifm-color-white); /* Needed to wrap tabs. Wrap instead of horizontal overflow scrolling or scaling smaller */ white-space: normal; } .gettingStarted :global(.tabs__item--active) { color: var(--shade-green-bright); border-bottom-color: var(--shade-green-bright); } .gettingStarted :global(.tabs__item):hover { color: var(--shade-green-bright); } /* Ensure copy buttons are visible on mobile */ @media (max-width: 996px) { .gettingStarted :global(button.clean-btn) { opacity: 1 !important; } } ================================================ FILE: src/components/HomeHeader/index.js ================================================ // import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; import Heading from "@theme/Heading"; import clsx from "clsx"; import styles from "./styles.module.css"; import Boat from "@site/src/components/Boat"; import Translate from '@docusaurus/Translate'; export default function HomeHeader() { // const { siteConfig } = useDocusaurusContext(); return (
The package manager for Kubernetes

Helm is the best way to find, share, and use software built for {" "} Kubernetes.

); } ================================================ FILE: src/components/HomeHeader/styles.module.css ================================================ .hero { padding: 4rem 0; text-align: center; position: relative; overflow: hidden; --ifm-hero-background-color: none; --ifm-hero-text-color: var(--navy); /* Prevent layout shift on page load/refresh by setting a reasonable default height */ /* Use 90vh to account for potential announcement bar and avoid exact match with JS calculation */ min-height: 90vh; } .container { position: absolute; top: 0; left: 0; right: 0; bottom: max(3rem, 6vw); /* Above wave-wrapper, matches wrapper height */ display: flex; flex-direction: column; align-items: center; justify-content: center; padding: 2rem; box-sizing: border-box; } @media screen and (max-width: 996px) { .hero { padding: 2rem; } } .hero h1 { font-size: clamp(1.8rem, 5vw, 2.5rem); margin: 0; line-height: 1.2; } .hero h2 { font-size: clamp(1rem, 3vw, 1.5rem); padding: clamp(1rem, 3vh, 2rem) clamp(0.75rem, 2vw, 1rem); border: 5px solid var(--shade-light); background: rgba(255, 255, 255, 0.67); font-family: var(--ifm-font-family-base); font-weight: unset; display: inline-block; margin: clamp(1.5rem, 4vh, 3rem) 0 0 0; text-align: center; line-height: 1.3; max-width: 90%; } /* Side-by-side layout for very constrained heights */ @media screen and (max-height: 380px) { .container { flex-direction: row; align-items: center; justify-content: center; gap: clamp(0.5rem, 2vw, 2rem); padding: 1rem; } .hero h1 { font-size: clamp(1.6rem, 3.5vw, 2rem); margin: 0; flex: 1 1 50%; /* Equal 50/50 width, can shrink */ min-width: 0; /* Allow text to wrap/shrink */ } .hero h2 { font-size: clamp(1.1rem, 2vw, 1.2rem); padding: clamp(0.75rem, 1.5vh, 1rem) clamp(0.5rem, 1vw, 0.75rem); margin: 0; flex: 1 1 50%; /* Equal 50/50 width, can shrink */ min-width: 0; /* Allow text to wrap/shrink */ max-width: none; word-wrap: break-word; hyphens: auto; } } /* Extra constrained heights - further scaling */ @media screen and (max-height: 400px) { .container { gap: clamp(0.25rem, 1vw, 1rem); padding: 0.5rem; } .hero h1 { font-size: clamp(1.3rem, 3vw, 1.5rem); } .hero h2 { font-size: clamp(0.9rem, 1.8vw, 1rem); padding: clamp(0.5rem, 1vh, 0.75rem) clamp(0.4rem, 0.8vw, 0.5rem); } } ================================================ FILE: src/components/HomeSupport/index.js ================================================ import clsx from "clsx"; import Heading from "@theme/Heading"; import styles from "./styles.module.css"; import homeSections from "@site/src/css/home-sections.module.css"; import Translate from "@docusaurus/Translate"; const CompanyList = [ { name: "Bitnami", src: "/img/logowall/bitnami.png", url: "https://bitnami.com/", }, { name: "codecentric AG", src: "/img/logowall/codecentric.png", url: "https://www.codecentric.de/", }, { name: "Codefresh", src: "/img/logowall/codefresh.png", url: "https://codefresh.io/", }, { name: "Google", src: "/img/logowall/google.png", url: "https://cloud.google.com/", }, { name: "IBM", src: "/img/logowall/ibm.png", url: "https://www.ibm.com/", }, { name: "JetBrains", src: "/img/logowall/jetbrains.png", url: "https://www.jetbrains.com/", }, { name: "Microsoft", src: "/img/logowall/microsoft.png", url: "https://www.microsoft.com/", }, { name: "Montreal", src: "/img/logowall/montreal.png", url: "#", }, { name: "Red Hat", src: "/img/logowall/redhat.png", url: "https://www.redhat.com/", }, { name: "Replicated", src: "/img/logowall/replicated.png", url: "https://www.replicated.com/", }, { name: "Samsung SDS", src: "/img/logowall/samsungsds.png", url: "https://www.samsungsds.com/", }, { name: "SUSE", src: "/img/logowall/suse.png", url: "https://www.suse.com/", }, { name: "Ticketmaster", src: "/img/logowall/tm.png", url: "https://www.ticketmaster.com/", }, ]; function CompanyLogo({ name, src, url }) { const logoElement = (
{`${name}
); if (url === "#") { return logoElement; } return ( {logoElement} ); } export default function HomeSupport() { return (
Supporters

Helm is supported by and built with a community of over 400 developers.

{CompanyList.map((props, idx) => ( ))}

many other wonderful helm core maintainers ), }} > {"...and {maintainersLink}."}

); } ================================================ FILE: src/components/HomeSupport/styles.module.css ================================================ /* Component has no specific styles - uses shared home module styles */ /* Maintainers text styling */ .maintainersText { font-size: 1.25rem; } /* Logo wall styling using flexbox with viewport-based sizing */ .logoGrid { display: flex; flex-wrap: wrap; justify-content: center; align-items: center; gap: max(1vw, 0.75rem); margin: 2rem 0; } .logoItem { display: flex; align-items: center; justify-content: center; height: max(12vw, 120px); width: max(18vw, 200px); min-width: 200px; flex: 0 0 max(18vw, 200px); transition: transform 0.2s ease; } .logoItem:hover { transform: scale(1.15); z-index: 1; } .logoImage { max-height: max(12vw, 120px); max-width: max(18vw, 200px); width: auto; height: auto; object-fit: contain; } /* Large desktop optimization */ @media (min-width: 1400px) { .logoGrid { max-width: 1400px; margin: 2rem auto; } .logoItem { height: 160px; width: 280px; flex: 0 0 280px; } .logoImage { max-height: 160px; max-width: 280px; } } /* Mobile optimization */ @media (max-width: 768px) { .logoGrid { gap: max(2vw, 0.5rem); } .logoItem { height: max(15vw, 100px); width: max(40vw, 150px); min-width: 150px; flex: 0 0 max(40vw, 150px); } .logoItem:hover { transform: scale(1.1); } .logoImage { max-height: max(15vw, 100px); max-width: max(40vw, 150px); } } ================================================ FILE: src/css/announcement-bar.css ================================================ :root { /* set custom var for announcement bar height because --docusaurus-announcement-bar-height var is not properly overridden from here during yarn build/serve, eve with !important. use this custom var in announcement-bar.css until a better solution is found. */ --helm-announcement-bar-height: 5rem; } /* Position the announcement bar fixed below the navbar and keep it within the body border */ .theme-announcement-bar { position: fixed; top: var(--ifm-navbar-height); left: 0; right: 0; /* z-index 1 beneath boat badge */ z-index: calc(var(--ifm-z-index-fixed) - 2); box-sizing: border-box; /* Honor the site's body border visually */ margin-inline: var(--helm-body-border); /* we must override the default announcement bar height here for yarn build/serve */ height: var(--helm-announcement-bar-height); } [class*="announcementBarContent"] { font-size: inherit; } /* Ensure the close button stays on the right and retains its padding */ .theme-announcement-bar .close { /* center the icon vertically within the button */ align-items: center; opacity: 0.5; padding: 1rem; transition: opacity var(--ifm-transition-fast) var(--ifm-transition-timing-default); /* keep light, assuming announcement bar config will be a medium to dark color. eg, --navy: "#0f1689" */ color: var(--ifm-color-white); } .theme-announcement-bar .close:hover { opacity: 1; } /* bump content down when announcement is present */ .theme-announcement-bar + .navbar + .main-wrapper { margin-top: var(--helm-announcement-bar-height); } /* offset the sidebar viewport when announcement is present */ @media (min-width: 997px) { #__docusaurus:has(.theme-announcement-bar) .theme-doc-sidebar-container { margin-top: calc(-1 * calc(var(--ifm-navbar-height) + var(--helm-announcement-bar-height))); } /* target sidebar menu on both docs and blog with announcement bar */ #__docusaurus:has(.theme-announcement-bar) [class*="sidebarViewport"] .thin-scrollbar { padding-top: var(--ifm-navbar-height); } /* bottom of docs scrollbar when docusaurus adds this class with js */ #__docusaurus:has(.theme-announcement-bar) [class*="menuWithAnnouncementBar"] { margin-bottom: 0px; } } /* bump TOC on desktop down when announcement is present */ #__docusaurus:has(.theme-announcement-bar) .theme-doc-toc-desktop, #__docusaurus:has(.theme-announcement-bar) [class*="tableOfContents"] { top: calc(var(--ifm-navbar-height) + 1rem + var(--helm-announcement-bar-height)); } #__docusaurus:has(.theme-announcement-bar) [class*="tableOfContents"] { max-height: calc(100vh - (var(--ifm-navbar-height) + 2rem + var(--helm-announcement-bar-height))); } /* fix headers visually cut off by announcement bar */ #__docusaurus:has(.theme-announcement-bar) .anchor { scroll-margin-top: calc(var(--ifm-navbar-height) + 2rem + var(--helm-announcement-bar-height)); } ================================================ FILE: src/css/content.css ================================================ /* Float right with sensible sizing and margins; text wraps around */ .float-right { float: right; margin: 0 0 1rem 1rem; max-width: 420px; width: 50%; } /* Float left variant */ .float-left { float: left; margin: 0 1rem 1rem 0; max-width: 420px; width: 50%; } /* Mobile: disable float and make the image full-width for readability */ @media (max-width: 768px) { .float-right, .float-left { float: none; display: block; width: 100%; max-width: 100%; margin: 0 0 1rem 0; } } /* Optional: ensure images don’t overflow their container */ .float-right img, .float-left img { max-width: 100%; height: auto; } /* Optional clear utility: add where you want to stop wrapping below */ .clear-wrap { clear: both; } .breaking { color: red; font-weight: bold; } .breaking::before { content: "⚠️"; margin-right: 0.25rem; } /* Target the "Date" column to fit content */ .docs-doc-id-changelog table th:nth-child(2), .docs-doc-id-changelog table td:nth-child(2) { white-space: nowrap; /* Prevent wrapping */ width: auto; /* Adjust width to fit content */ } /* Target the "Title" column to wrap content */ .docs-doc-id-changelog table th:nth-child(4), .docs-doc-id-changelog table td:nth-child(4) { word-wrap: break-word; /* Allow long words to break */ white-space: normal; /* Allow normal wrapping */ width: 100%; /* Take up remaining available width */ } ================================================ FILE: src/css/custom.css ================================================ /* Import component-specific stylesheets */ @import './fonts.css'; @import './main.css'; @import './announcement-bar.css'; @import './navbar.css'; @import './content.css'; @import './footer.css'; /* You can override the default Infima variables here. */ :root { /* Helm style guide colors https://github.com/helm/community/tree/main/art */ /* Primary */ --navy: #0f1689; /* Secondary */ --blue-dark: #090e6f; --blue-light: #1b53c2; /* Shades */ --shade-dark: #050843; --shade-mid: #b7c2e9; --shade-light: #dbe1f3; /* Accents */ --accent-blue: #3b82bf; --accent-green: #2f84a7; --accent-red: #95297c; --accent-yellow: #d1aa9b; /* Additional colors not in style guide */ --light: #e5e5e5; --grey: #4e4e4e; --salmon: #f8dcdf; --shade-green-bright: #2ba0d3; --ifm-color-primary: var(--navy); --ifm-color-primary-dark: var(--navy); --ifm-color-primary-darker: var(--blue-dark); --ifm-color-primary-darkest: var(--blue-dark); --ifm-color-primary-light: var(--blue-light); --ifm-color-primary-lighter: var(--blue-light); --ifm-color-primary-lightest: var(--blue-light); /* font */ --ifm-code-font-size: 95%; --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); --ifm-font-family-base: "Public Sans", Helvetica, Arial, sans-serif; --ifm-heading-font-family: "Space Mono", "Courier New", monaco, monospace; --ifm-heading-font-weight: 700; /* links */ --ifm-link-color: var(--shade-green-bright); --ifm-link-hover-color: var(--shade-green-bright); /* headers */ --ifm-heading-color: var(--navy); /* global navbar style (needed elsewhere) */ --ifm-navbar-height: 5.5rem; /* custom site vars */ --helm-body-border: 8px; } ================================================ FILE: src/css/fonts.css ================================================ /* Local font declarations for Helm website */ /* Space Mono - Regular */ @font-face { font-family: 'Space Mono'; src: url('/fonts/spacemono-regular-webfont.woff2') format('woff2'), url('/fonts/spacemono-regular-webfont.woff') format('woff'); font-weight: 400; font-style: normal; font-display: swap; } /* Space Mono - Bold */ @font-face { font-family: 'Space Mono'; src: url('/fonts/spacemono-bold-webfont.woff2') format('woff2'), url('/fonts/spacemono-bold-webfont.woff') format('woff'); font-weight: 700; font-style: normal; font-display: swap; } /* Public Sans - Regular */ @font-face { font-family: 'Public Sans'; src: url('/fonts/publicsans-regular-webfont.woff2') format('woff2'), url('/fonts/publicsans-regular-webfont.woff') format('woff'); font-weight: 400; font-style: normal; font-display: swap; } /* Public Sans - Medium */ @font-face { font-family: 'Public Sans'; src: url('/fonts/publicsans-medium-webfont.woff2') format('woff2'), url('/fonts/publicsans-medium-webfont.woff') format('woff'); font-weight: 500; font-style: normal; font-display: swap; } ================================================ FILE: src/css/footer.css ================================================ .footer--dark { --ifm-footer-color: var(--shade-mid); --ifm-footer-background-color: var(--navy); --ifm-footer-link-color: var(--shade-green-bright); --ifm-footer-link-hover-color: var(--shade-green-bright); } /* Enhanced background with blend mode for supported browsers */ @supports (background-blend-mode: color-burn) { @media screen and (min-width: 769px) { .footer--dark { background: url("/img/topography.png"), var(--navy); background-blend-mode: color-burn; background-attachment: fixed; } } } .footer__links, .footer__title, .footer__bottom { font-family: var(--ifm-heading-font-family); } .footer__bottom { padding: 2rem 0; } ================================================ FILE: src/css/home-cards.module.css ================================================ /* Card styles shared by multiple home module components */ /* Card column styling */ .col { margin-bottom: var(--ifm-card-vertical-spacing); } /* Card base styling */ .card { height: 100%; } /* Card header styling */ .card__header { text-align: center; } .card__header h3 { font-size: 1.5rem; } /* Card images */ .card img { max-width: 100%; height: auto; border-radius: var(--ifm-global-radius); } ================================================ FILE: src/css/home-sections.module.css ================================================ /* Section styles shared by multiple home module components */ /* Base section styling */ .section { padding: 2rem 0; width: 100%; display: flex; align-items: center; } /* Section headers */ .section h2 { font-size: 2.25rem; text-align: center; } .section h2 + div, .section h2 + p + div { margin-top: 3rem; } .section h2 + p { text-align: center; font-size: 1.25rem; margin-bottom: 1rem; } /* Light sections (pattern background, navy text) */ .sectionLight { color: var(--navy); } .sectionLight h2, .sectionLight h3, .sectionLight h4 { color: var(--navy); } /* Dark sections (blue pattern background, white text) */ .sectionDark { background: var(--navy); color: white; } /* Enhanced background with blend mode for supported browsers */ @supports (background-blend-mode: color-burn) { @media screen and (min-width: 769px) { .sectionDark { background: url("/img/topography.png"), var(--navy); background-blend-mode: color-burn; background-attachment: fixed; } } } .sectionDark h2, .sectionDark h3, .sectionDark h4 { color: var(--ifm-color-white); } .sectionDark :global(code) { background-color: inherit; } /* Card styles for light sections */ .sectionLight :global(.card) { --ifm-card-background-color: var(--ifm-background-surface-color); box-shadow: 0 5px 12px var(--ifm-color-secondary-dark); } /* Card styles for dark sections */ .sectionDark :global(.card) { --ifm-card-background-color: var(--shade-dark); box-shadow: 0 2px 8px rgba(0, 0, 0, 0.2); } ================================================ FILE: src/css/main.css ================================================ /** * Any CSS included here will be global. The classic template * bundles Infima by default. Infima is a CSS framework designed to * work well for content-centric websites. */ @import url("https://fonts.googleapis.com/css2?family=Space+Mono:ital,wght@0,400;0,700;1,400;1,700&display=swap"); @import url("https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"); body { /* needed for border to fit content instead of initial viewport */ height: fit-content !important; border: var(--helm-body-border) solid var(--navy); } /* background image */ body::before { content: ""; position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-image: url("/img/topography.png"); background-repeat: repeat; z-index: -1; pointer-events: none; } main:not(.home) { background: white; } /* fix headers visually cut off by navbar */ .anchor { scroll-margin-top: calc(var(--ifm-navbar-height) + 2rem); } ================================================ FILE: src/css/navbar.css ================================================ .navbar--fixed-top { /* Restore background image so content flows "beneath" it */ background-image: url("/img/topography.png"); background-repeat: repeat; /* To get -8px we have to use calc, because -var(--name) doesn't work */ background-position: calc(-1 * var(--helm-body-border)) calc(-1 * var(--helm-body-border)); margin-top: calc(-1 * var(--helm-body-border)); border-top: var(--helm-body-border) solid var(--navy); } /* logo */ .navbar__logo { height: 3.5rem; } .navbar__logo img { transition: transform var(--ifm-transition-slow) ease-in-out; } .navbar__logo:hover img { transform: rotateZ(180deg); } /* logo fix on iphone. otherwise stuck upside down on click */ @media (hover: none) { .navbar__logo:hover img { /* stays upright */ transform: rotateZ(0deg); /* avoid accidental sticky states */ transition: none; } } /* hide title */ /* TODO is there a better way to hide this? */ .navbar__title { display: none; } /* links */ .navbar__link { --ifm-navbar-link-color: var(--navy); font-family: var(--ifm-heading-font-family); font-weight: var(--ifm-heading-font-weight); } ================================================ FILE: src/pages/helm-4-release-party.js ================================================ import Layout from "@theme/Layout"; import clsx from "clsx"; import ReplicatedLogo from "../../static/img/helm-4-release-party/replicated_logo_red.svg"; import CNCFLogo from "../../static/img/helm-4-release-party/cncf-color.svg"; import styles from "./party.module.css"; import Link from "@docusaurus/Link"; import { MdLink, MdCalendarMonth } from "react-icons/md"; import Admonition from "@theme/Admonition"; export default function Party() { return (

Present:

Hazel 1 Hazel 2
Hazel 3 Hazel 4

The Official Helm 4 Release Party!

Wed, Nov 12 from 6-9 PM

Max Lager’s Wood-fired Grill & Brewery

320 Peachtree Rd NE, Atlanta, GA 30308

(~1 mile from the conference)

Menu

Low-country Boil w/ Lobster, Shrimp, Beef Sausage, Corn on Cob, Potatoes

Pasta D’Avellino (vegetarian)

Premium Open Bar

RSVP Required

Hazel 3

See the full list of Helm events @ KubeCon + CloudNativeCon NA '25

); } ================================================ FILE: src/pages/index.js ================================================ import Link from "@docusaurus/Link"; import useDocusaurusContext from "@docusaurus/useDocusaurusContext"; import Layout from "@theme/Layout"; import HomeHeader from "@site/src/components/HomeHeader"; import HomeAbout from "@site/src/components/HomeAbout"; import HomeFeatures from "@site/src/components/HomeFeatures"; import HomeGettingStarted from "@site/src/components/HomeGettingStarted"; import HomeCommunity from "@site/src/components/HomeCommunity"; import HomeSupport from "@site/src/components/HomeSupport"; export default function Home() { const { siteConfig } = useDocusaurusContext(); return (
); } ================================================ FILE: src/pages/index.module.css ================================================ /** * CSS files with the .module.css suffix will be treated as CSS modules * and scoped locally. */ ================================================ FILE: src/pages/markdown-page.md ================================================ --- title: Markdown page example --- # Markdown page example You don't need React to write simple standalone pages. ================================================ FILE: src/pages/party.module.css ================================================ /** * CSS files with the .module.css suffix will be treated as CSS modules * and scoped locally. */ main.party { padding: 2rem; } main.party h1 { font-size: 3rem; } main.party h2, .col p { font-size: 2rem; } main.party h3 { font-size: 1.5rem; } .svgauto { width: 100%; height: auto; } .col { text-align: center; padding: 2rem; } .logocol { padding-bottom: 0; } .hazelcol { padding-top: 0; padding-bottom: 0; } .hazel { width: 50%; height: auto; } .menucol { border: 2px solid var(--ifm-link-color); border-radius: var(--ifm-card-border-radius); } .bottomrow { margin-top: 1rem; } .bottomrow .col { --ifm-col-width: 100%; } .calendarcol { padding-top: 0; } .calendarlink { margin-bottom: 0; } @media (min-width: 576px) { .bottomrow .col { --ifm-col-width: calc(6 / 12 * 100%); } .calendarcol { padding-top: 2rem; } .calendarlink { margin-top: 1rem; } } /* See HomeCommunity component styles */ .icon { vertical-align: middle; margin-right: 0.5rem; font-size: 1.2em; } ================================================ FILE: src/theme/Blog/Pages/BlogAuthorsListPage/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import { PageMetadata, HtmlClassNameProvider, ThemeClassNames, } from '@docusaurus/theme-common'; import {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal'; import BlogLayout from '@theme/BlogLayout'; import SearchMetadata from '@theme/SearchMetadata'; import Heading from '@theme/Heading'; import Author from '@theme/Blog/Components/Author'; import BlogAuthorsListBreadcrumbs from '@theme/BlogAuthorsListBreadcrumbs'; import styles from './styles.module.css'; function AuthorListItem({author}) { return (
    • ); } function AuthorsList({authors}) { return (
      {authors.map((author) => ( ))}
    ); } export default function BlogAuthorsListPage({authors, sidebar}) { const title = translateBlogAuthorsListPageTitle(); return ( {title} ); } ================================================ FILE: src/theme/Blog/Pages/BlogAuthorsListPage/styles.module.css ================================================ .authorListItem { list-style-type: none; margin-bottom: 2rem; } ================================================ FILE: src/theme/Blog/Pages/BlogAuthorsPostsPage/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import { PageMetadata, HtmlClassNameProvider, ThemeClassNames, } from '@docusaurus/theme-common'; import { useBlogAuthorPageTitle, BlogAuthorsListViewAllLabel, BlogAuthorNoPostsLabel, } from '@docusaurus/theme-common/internal'; import Link from '@docusaurus/Link'; import {useBlogMetadata} from '@docusaurus/plugin-content-blog/client'; import BlogLayout from '@theme/BlogLayout'; import BlogListPaginator from '@theme/BlogListPaginator'; import SearchMetadata from '@theme/SearchMetadata'; import BlogPostItems from '@theme/BlogPostItems'; import Author from '@theme/Blog/Components/Author'; import BlogAuthorsPostsBreadcrumbs from '@theme/BlogAuthorsPostsBreadcrumbs'; function Metadata({author}) { const title = useBlogAuthorPageTitle(author); return ( <> ); } function ViewAllAuthorsLink() { const {authorsListPath} = useBlogMetadata(); return ( ); } function Content({author, items, sidebar, listMetadata}) { return (
    {author.description &&

    {author.description}

    }
    {items.length === 0 ? (

    ) : ( <>
    )}     ); } export default function BlogAuthorsPostsPage(props) { return ( ); } ================================================ FILE: src/theme/BlogAuthorsListBreadcrumbs/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl'; import {translate} from '@docusaurus/Translate'; import {ThemeClassNames} from '@docusaurus/theme-common'; import {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal'; import {useBlogMetadata} from '@docusaurus/plugin-content-blog/client'; import IconHome from '@theme/Icon/Home'; import styles from './styles.module.css'; export default function BlogAuthorsListBreadcrumbs() { const homeHref = useBaseUrl('/'); const {blogBasePath} = useBlogMetadata(); return ( ); } ================================================ FILE: src/theme/BlogAuthorsListBreadcrumbs/styles.module.css ================================================ .breadcrumbsContainer { --ifm-breadcrumb-size-multiplier: 0.8; margin-bottom: 0.8rem; } .breadcrumbHomeIcon { position: relative; top: 1px; vertical-align: top; height: 1.1rem; width: 1.1rem; } ================================================ FILE: src/theme/BlogAuthorsPostsBreadcrumbs/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl'; import {translate} from '@docusaurus/Translate'; import {ThemeClassNames} from '@docusaurus/theme-common'; import {translateBlogAuthorsListPageTitle} from '@docusaurus/theme-common/internal'; import {useBlogMetadata} from '@docusaurus/plugin-content-blog/client'; import IconHome from '@theme/Icon/Home'; import styles from './styles.module.css'; export default function BlogAuthorsPostsBreadcrumbs({author}) { const homeHref = useBaseUrl('/'); const {blogBasePath, authorsListPath} = useBlogMetadata(); return ( ); } ================================================ FILE: src/theme/BlogAuthorsPostsBreadcrumbs/styles.module.css ================================================ .breadcrumbsContainer { --ifm-breadcrumb-size-multiplier: 0.8; margin-bottom: 0.8rem; } .breadcrumbHomeIcon { position: relative; top: 1px; vertical-align: top; height: 1.1rem; width: 1.1rem; } ================================================ FILE: src/theme/BlogBreadcrumbs/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl'; import {translate} from '@docusaurus/Translate'; import {useBlogPost} from '@docusaurus/plugin-content-blog/client'; import {ThemeClassNames} from '@docusaurus/theme-common'; import IconHome from '@theme/Icon/Home'; import styles from './styles.module.css'; export default function BlogBreadcrumbs() { const {metadata} = useBlogPost(); const {title, permalink} = metadata; const homeHref = useBaseUrl('/'); return ( ); } ================================================ FILE: src/theme/BlogBreadcrumbs/styles.module.css ================================================ .breadcrumbsContainer { --ifm-breadcrumb-size-multiplier: 0.8; margin-bottom: 0.8rem; } .breadcrumbHomeIcon { position: relative; top: 1px; vertical-align: top; height: 1.1rem; width: 1.1rem; } ================================================ FILE: src/theme/BlogLayout/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Layout from '@theme/Layout'; import BlogSidebar from '@theme/BlogSidebar'; import {ThemeClassNames, useWindowSize} from '@docusaurus/theme-common'; import BackToTopButton from '@theme/BackToTopButton'; import TOC from '@theme/TOC'; import TOCCollapsible from '@theme/TOCCollapsible'; import styles from './styles.module.css'; // Create mobile and desktop TOC like docs do function useBlogTOC(toc, frontMatter = {}) { const windowSize = useWindowSize(); const hidden = frontMatter.hide_table_of_contents; const canRender = !hidden && toc && toc.length > 0; const mobile = canRender ? ( ) : undefined; const desktop = canRender && (windowSize === 'desktop' || windowSize === 'ssr') ? ( ) : undefined; return { hidden, mobile, desktop }; } export default function BlogLayout(props) { const {sidebar, toc, children, frontMatter, ...layoutProps} = props; const hasSidebar = sidebar && sidebar.items.length > 0; const blogTOC = useBlogTOC(toc, frontMatter); return (
    {hasSidebar && ( )}
    {blogTOC.mobile} {children}
    {blogTOC.desktop && (
    {blogTOC.desktop}
    )}
    ); } ================================================ FILE: src/theme/BlogLayout/styles.module.css ================================================ /* Blog layout styles based on docs layout structure */ :root { --doc-sidebar-width: 300px; --doc-sidebar-hidden-width: 30px; } .docRoot { display: flex; width: 100%; } .docsWrapper { display: flex; flex: 1 0 auto; } .docSidebarContainer { display: none; } @media (min-width: 997px) { .docSidebarContainer { display: block; width: var(--doc-sidebar-width); margin-top: calc(-1 * var(--ifm-navbar-height)); border-right: 1px solid var(--ifm-toc-border-color); will-change: width; transition: width var(--ifm-transition-fast) ease; clip-path: inset(0); } .sidebarViewport { top: 0; position: sticky; height: 100%; max-height: 100vh; overflow-y: auto; padding: var(--ifm-spacing-vertical) var(--ifm-spacing-horizontal); } } .docMainContainer { display: flex; width: 100%; } @media (min-width: 997px) { .docMainContainer { flex-grow: 1; max-width: calc(100% - var(--doc-sidebar-width)); } .docMainContainerEnhanced { max-width: calc(100% - var(--doc-sidebar-hidden-width)); } .docItemWrapperEnhanced { max-width: calc( var(--ifm-container-width) + var(--doc-sidebar-width) ) !important; } } .docItemWrapper { /* Additional spacing for blog content */ } .docItemRow { /* Row containing main content + TOC */ } .docItemCol { /* Main content column - always constrained to 75% like docs */ } @media (min-width: 997px) { .docItemCol { max-width: 75% !important; } } .tocWrapper { /* TOC column styling */ } .tocMobile { /* Mobile TOC styling - hidden on desktop */ } @media (min-width: 997px) { .tocMobile { display: none; } } .docItemContainer header + *, .docItemContainer article > *:first-child { margin-top: 0; } ================================================ FILE: src/theme/BlogListBreadcrumbs/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl'; import {translate} from '@docusaurus/Translate'; import {ThemeClassNames} from '@docusaurus/theme-common'; import IconHome from '@theme/Icon/Home'; import styles from './styles.module.css'; export default function BlogListBreadcrumbs() { const homeHref = useBaseUrl('/'); return ( ); } ================================================ FILE: src/theme/BlogListBreadcrumbs/styles.module.css ================================================ .breadcrumbsContainer { --ifm-breadcrumb-size-multiplier: 0.8; margin-bottom: 0.8rem; } .breadcrumbHomeIcon { position: relative; top: 1px; vertical-align: top; height: 1.1rem; width: 1.1rem; } ================================================ FILE: src/theme/BlogListPage/StructuredData/index.js ================================================ import React from 'react'; import Head from '@docusaurus/Head'; import {useBlogListPageStructuredData} from '@docusaurus/plugin-content-blog/client'; export default function BlogListPageStructuredData(props) { const structuredData = useBlogListPageStructuredData(props); return ( ); } ================================================ FILE: src/theme/BlogListPage/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; import { PageMetadata, HtmlClassNameProvider, ThemeClassNames, } from '@docusaurus/theme-common'; import BlogLayout from '@theme/BlogLayout'; import BlogListPaginator from '@theme/BlogListPaginator'; import SearchMetadata from '@theme/SearchMetadata'; import BlogPostItems from '@theme/BlogPostItems'; import BlogListPageStructuredData from '@theme/BlogListPage/StructuredData'; import BlogListBreadcrumbs from '@theme/BlogListBreadcrumbs'; function BlogListPageMetadata(props) { const {metadata} = props; const { siteConfig: {title: siteTitle}, } = useDocusaurusContext(); const {blogDescription, blogTitle, permalink} = metadata; const isBlogOnlyMode = permalink === '/'; const title = isBlogOnlyMode ? siteTitle : blogTitle; return ( <> ); } function BlogListPageContent(props) { const {metadata, items, sidebar} = props; return ( ); } export default function BlogListPage(props) { return ( ); } ================================================ FILE: src/theme/BlogPostItem/index.tsx ================================================ import React, {type ReactNode} from 'react'; import clsx from 'clsx'; import {useBlogPost} from '@docusaurus/plugin-content-blog/client'; import BlogPostItemContainer from '@theme/BlogPostItem/Container'; import BlogPostItemHeader from '@theme/BlogPostItem/Header'; import BlogPostItemContent from '@theme/BlogPostItem/Content'; import BlogPostItemFooter from '@theme/BlogPostItem/Footer'; import BlogBreadcrumbs from '@theme/BlogBreadcrumbs'; import type {Props} from '@theme/BlogPostItem'; // apply a bottom margin in list view function useContainerClassName() { const {isBlogPostPage} = useBlogPost(); return !isBlogPostPage ? 'margin-bottom--xl' : undefined; } export default function BlogPostItem({children, className}: Props): ReactNode { const {isBlogPostPage} = useBlogPost(); const containerClassName = useContainerClassName(); return ( {isBlogPostPage && } {children} ); } ================================================ FILE: src/theme/BlogPostPage/Metadata/index.js ================================================ import React from 'react'; import {PageMetadata} from '@docusaurus/theme-common'; import {useBlogPost} from '@docusaurus/plugin-content-blog/client'; export default function BlogPostPageMetadata() { const {assets, metadata} = useBlogPost(); const {title, description, date, tags, authors, frontMatter} = metadata; const {keywords} = frontMatter; const image = assets.image ?? frontMatter.image; return ( {/* TODO double check those article meta array syntaxes, see https://ogp.me/#array */} {authors.some((author) => author.url) && ( author.url) .filter(Boolean) .join(',')} /> )} {tags.length > 0 && ( tag.label).join(',')} /> )} ); } ================================================ FILE: src/theme/BlogPostPage/StructuredData/index.js ================================================ import React from 'react'; import Head from '@docusaurus/Head'; import {useBlogPostStructuredData} from '@docusaurus/plugin-content-blog/client'; export default function BlogPostStructuredData() { const structuredData = useBlogPostStructuredData(); return ( ); } ================================================ FILE: src/theme/BlogPostPage/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import {HtmlClassNameProvider, ThemeClassNames} from '@docusaurus/theme-common'; import { BlogPostProvider, useBlogPost, } from '@docusaurus/plugin-content-blog/client'; import BlogLayout from '@theme/BlogLayout'; import BlogPostItem from '@theme/BlogPostItem'; import BlogPostPaginator from '@theme/BlogPostPaginator'; import BlogPostPageMetadata from '@theme/BlogPostPage/Metadata'; import BlogPostPageStructuredData from '@theme/BlogPostPage/StructuredData'; import TOC from '@theme/TOC'; import ContentVisibility from '@theme/ContentVisibility'; function BlogPostPageContent({sidebar, children}) { const {metadata, toc} = useBlogPost(); const {nextItem, prevItem, frontMatter} = metadata; const { hide_table_of_contents: hideTableOfContents, toc_min_heading_level: tocMinHeadingLevel, toc_max_heading_level: tocMaxHeadingLevel, } = frontMatter; return ( {children} {(nextItem || prevItem) && ( )} ); } export default function BlogPostPage(props) { const BlogPostContent = props.content; return ( ); } ================================================ FILE: src/theme/BlogSidebar/Desktop/index.js ================================================ import React, {memo} from 'react'; import clsx from 'clsx'; import {translate} from '@docusaurus/Translate'; import {ThemeClassNames} from '@docusaurus/theme-common'; import { useVisibleBlogSidebarItems, BlogSidebarItemList, } from '@docusaurus/plugin-content-blog/client'; import BlogSidebarContent from '@theme/BlogSidebar/Content'; import styles from './styles.module.css'; const ListComponent = ({items}) => { return ( ); }; function BlogSidebarDesktop({sidebar}) { const items = useVisibleBlogSidebarItems(sidebar.items); return ( ); } export default memo(BlogSidebarDesktop); ================================================ FILE: src/theme/BlogSidebar/Desktop/styles.module.css ================================================ .sidebar { max-height: calc(100vh - (var(--ifm-navbar-height) + 2rem)); overflow-y: auto; position: sticky; top: calc(var(--ifm-navbar-height) + 2rem); padding: 0 var(--ifm-spacing-horizontal); } .sidebarItemTitle { font-size: var(--ifm-h3-font-size); font-weight: var(--ifm-font-weight-bold); } .sidebarItemList { font-size: 0.9rem; } .sidebarItem { margin-top: 0.7rem; } .sidebarItemLink { color: var(--ifm-font-color-base); display: block; } .sidebarItemLink:hover { text-decoration: none; } .sidebarItemLinkActive { color: var(--ifm-color-primary) !important; } @media (max-width: 996px) { .sidebar { display: none; } } .yearGroupHeading { margin-top: 1.6rem; margin-bottom: 0.4rem; } ================================================ FILE: src/theme/DocBreadcrumbs/Items/Home/index.js ================================================ import React from 'react'; import Link from '@docusaurus/Link'; import useBaseUrl from '@docusaurus/useBaseUrl'; import {translate} from '@docusaurus/Translate'; import IconHome from '@theme/Icon/Home'; import styles from './styles.module.css'; export default function HomeBreadcrumbItem() { const homeHref = useBaseUrl('/'); return (
    • ); } ================================================ FILE: src/theme/DocBreadcrumbs/Items/Home/styles.module.css ================================================ .breadcrumbHomeIcon { position: relative; top: 1px; vertical-align: top; height: 1.1rem; width: 1.1rem; } ================================================ FILE: src/theme/DocBreadcrumbs/StructuredData/index.js ================================================ import React from 'react'; import Head from '@docusaurus/Head'; import {useBreadcrumbsStructuredData} from '@docusaurus/plugin-content-docs/client'; export default function DocBreadcrumbsStructuredData(props) { const structuredData = useBreadcrumbsStructuredData({ breadcrumbs: props.breadcrumbs, }); return ( ); } ================================================ FILE: src/theme/DocBreadcrumbs/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import {ThemeClassNames} from '@docusaurus/theme-common'; import {useSidebarBreadcrumbs, useDocsVersion, useVersions} from '@docusaurus/plugin-content-docs/client'; import {useHomePageRoute} from '@docusaurus/theme-common/internal'; import Link from '@docusaurus/Link'; import {translate} from '@docusaurus/Translate'; import HomeBreadcrumbItem from '@theme/DocBreadcrumbs/Items/Home'; import DocBreadcrumbsStructuredData from '@theme/DocBreadcrumbs/StructuredData'; import styles from './styles.module.css'; // TODO move to design system folder function BreadcrumbsItemLink({children, href, isLast}) { const className = 'breadcrumbs__link'; if (isLast) { return {children}; } return href ? ( {children} ) : ( {children} ); } // TODO move to design system folder function BreadcrumbsItem({children, active}) { return (
  • {children}
    • ); } export default function DocBreadcrumbs() { const breadcrumbs = useSidebarBreadcrumbs(); const homePageRoute = useHomePageRoute(); const docsVersion = useDocsVersion(); const versions = useVersions(docsVersion.pluginId); // Find the current version in the full versions list to get the main doc path const currentVersion = versions.find(v => v.name === docsVersion.version); const versionMainDoc = currentVersion?.docs.find((doc) => doc.id === currentVersion.mainDocId); const docsPath = versionMainDoc?.path || '/docs'; // Determine if we're in the community section and set the label/path accordingly const isCommunitySection = docsVersion.pluginId === 'community'; const sectionLabel = isCommunitySection ? 'Community' : 'Docs'; const sectionPath = isCommunitySection ? '/community' : docsPath; if (!breadcrumbs) { return null; } return ( <> ); } ================================================ FILE: src/theme/DocBreadcrumbs/styles.module.css ================================================ .breadcrumbsContainer { --ifm-breadcrumb-size-multiplier: 0.8; margin-bottom: 0.8rem; } ================================================ FILE: src/theme/TOCCollapsible/CollapseButton/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import Translate from '@docusaurus/Translate'; import styles from './styles.module.css'; export default function TOCCollapsibleCollapseButton({collapsed, ...props}) { return ( ); } ================================================ FILE: src/theme/TOCCollapsible/CollapseButton/styles.module.css ================================================ .tocCollapsibleButton { font-size: inherit; display: flex; justify-content: space-between; align-items: center; padding: 0.4rem 0.8rem; width: 100%; } .tocCollapsibleButton::after { content: ''; background: var(--ifm-menu-link-sublist-icon) 50% 50% / 2rem 2rem no-repeat; filter: var(--ifm-menu-link-sublist-icon-filter); height: 1.25rem; width: 1.25rem; transform: rotate(180deg); transition: transform var(--ifm-transition-fast); } .tocCollapsibleButtonExpanded::after { transform: none; } ================================================ FILE: src/theme/TOCCollapsible/index.js ================================================ import React from 'react'; import clsx from 'clsx'; import {useCollapsible, Collapsible} from '@docusaurus/theme-common'; import TOCItems from '@theme/TOCItems'; import CollapseButton from '@theme/TOCCollapsible/CollapseButton'; import styles from './styles.module.css'; export default function TOCCollapsible({ toc, className, minHeadingLevel, maxHeadingLevel, }) { const {collapsed, toggleCollapsed} = useCollapsible({ initialState: true, }); return (
    ); } ================================================ FILE: src/theme/TOCCollapsible/styles.module.css ================================================ .tocCollapsible { background-color: var(--ifm-menu-color-background-active); border-radius: var(--ifm-global-radius); margin: 1rem 0; } .tocCollapsibleContent > ul { border-left: none; border-top: 1px solid var(--ifm-color-emphasis-300); padding: 0.2rem 0; font-size: 15px; } .tocCollapsibleContent ul li { margin: 0.4rem 0.8rem; } .tocCollapsibleContent a { display: block; } .tocCollapsibleExpanded { transform: none; } ================================================ FILE: src/utils/communityDocsHelpers.js ================================================ /** * Helper functions for processing community documentation configuration */ /** * @typedef {Object} ProcessedConfig * @property {string} sourceBaseUrl - Base URL for fetching remote content * @property {string[]} documents - Array of document paths to fetch * @property {Object.} metaByPath - Metadata indexed by file path * @property {Object.} slugByPath - Slug mappings indexed by file path * @property {Object.>} linkExceptions - Link transformations indexed by file path */ /** * Converts the simplified community config to the format needed by docusaurus-plugin-remote-content * @param {Object} config - The community docs configuration * @param {string} config.sourceBaseUrl - Base URL for remote content * @param {string} config.sourceRepo - GitHub repository URL * @param {Object.} config.files - File configurations * @returns {ProcessedConfig} Configuration for docusaurus-plugin-remote-content */ function processConfig(config) { const { sourceBaseUrl, files } = config; // Extract file paths const remoteDocPaths = Object.keys(files); // Build metadata and link mappings const metaByPath = {}; const linkExceptions = {}; for (const [filename, fileConfig] of Object.entries(files)) { if (fileConfig.meta) { metaByPath[filename] = fileConfig.meta; } if (fileConfig.links) { linkExceptions[filename] = fileConfig.links; } } // Build slug mapping (for files with slug in meta) const slugByPath = {}; for (const [path, meta] of Object.entries(metaByPath)) { if (meta.slug) { slugByPath[path] = meta.slug; } } return { sourceBaseUrl, documents: remoteDocPaths, metaByPath, slugByPath, linkExceptions, }; } /** * Creates the edit URL function for community docs * @param {string} sourceRepo - The GitHub repository URL * @returns {Function} Edit URL function for Docusaurus */ function createEditUrlFunction(sourceRepo) { return function editUrl({ docPath }) { // Convert .md back to .txt for meeting notes const origPath = docPath.replace(/^meeting-notes\/(\d+)\.md$/, 'meeting-notes/$1.txt'); return `${sourceRepo}/edit/main/${origPath}`; }; } module.exports = { processConfig, createEditUrlFunction, }; ================================================ FILE: src/utils/communityDocsTransforms.js ================================================ const path = require("path"); const yaml = require("js-yaml"); // Parse existing frontmatter and content function parseFrontMatterAndContent(rawContent) { const frontMatterRegex = /^---\n([\s\S]*?)\n---\n([\s\S]*)$/; const match = rawContent.match(frontMatterRegex); if (match) { const frontMatterStr = match[1]; const content = match[2]; try { // Use js-yaml to parse frontmatter properly const frontMatter = yaml.load(frontMatterStr) || {}; return { frontMatter, content }; } catch (e) { console.warn(`Failed to parse frontmatter YAML: ${e.message}`); return { frontMatter: {}, content: rawContent }; } } return { frontMatter: {}, content: rawContent }; } // Extract H1 title from content function extractH1Title(content) { const h1Match = content.match(/^\s*#\s+([^\n]+)\n/); return h1Match ? h1Match[1].trim() : null; } // Remove H1 from content (including the newline) function stripH1(content) { // This removes the H1 and its trailing newline, but preserves any blank lines after it return content.replace(/^\s*#\s+[^\n]+\n/, ""); } // Build front matter from merged meta function buildFrontMatter(meta) { if (!meta || Object.keys(meta).length === 0) return ""; // Filter out null/empty values const cleanMeta = {}; for (const [key, value] of Object.entries(meta)) { if (value != null && value !== "") { cleanMeta[key] = value; } } if (Object.keys(cleanMeta).length === 0) return ""; // Use js-yaml to properly dump the frontmatter // This handles special characters, arrays, etc. correctly const yamlStr = yaml.dump(cleanMeta, { lineWidth: -1, // Don't wrap long lines quotingType: '"', // Use double quotes when needed forceQuotes: false, // Only quote when necessary }); return `---\n${yamlStr}---\n\n`; } // Resolve relative link target against current file function resolveCanonicalTargetPath(currentFilePath, hrefPath) { const currentDir = path.posix.dirname(currentFilePath); return path.posix.normalize(path.posix.join(currentDir, hrefPath)); } // Helper to process a link href (used by both inline and reference links) function processLinkHref(filename, href, linkExceptions, slugByPath) { // Don't process anchors or mailto if (href.startsWith("#") || href.startsWith("mailto:")) { return href; } const m = href.match(/^([^?#]+)(\?[^#]*)?(#.*)?$/); if (!m) return href; const [, pathPart, queryPart = "", hashPart = ""] = m; // Check file-specific exceptions (works for both absolute and relative URLs) const fileExceptions = linkExceptions[filename]; if ( fileExceptions && Object.prototype.hasOwnProperty.call(fileExceptions, pathPart) ) { const forced = fileExceptions[pathPart]; return `${forced}${queryPart}${hashPart}`; } // Otherwise, return the link as-is (don't strip .md or transform paths) // Since we're keeping the same file structure, internal links should just work return href; } // Rewrite relative markdown links using exceptions/slug when available, otherwise strip .md/.mdx function rewriteMarkdownLinks(filename, content, linkExceptions, slugByPath) { // First, handle inline links: [text](url) const inlineLinkRe = /!?\[([^\]]+)\]\(([^)\s]+(?:\s+"[^"]*")?)\)/g; content = content.replace(inlineLinkRe, (full, text, hrefRaw) => { if (full.startsWith("!")) return full; // image const mTitle = hrefRaw.match(/^([^\s]+)(?:\s+"[^"]*")?$/); const href = mTitle ? mTitle[1] : hrefRaw; const processedHref = processLinkHref(filename, href, linkExceptions, slugByPath); // Reconstruct with title if present if (mTitle && mTitle[0] !== mTitle[1]) { const title = mTitle[0].substring(mTitle[1].length); return `[${text}](${processedHref}${title})`; } return `[${text}](${processedHref})`; }); // Handle angle-bracket links: const angleBracketLinkRe = /<(https?:\/\/[^>]+)>/g; content = content.replace(angleBracketLinkRe, (full, url) => { const processedUrl = processLinkHref(filename, url, linkExceptions, slugByPath); // If the URL was transformed, convert to markdown link format if (processedUrl !== url && !processedUrl.startsWith('http')) { return `[${processedUrl}](${processedUrl})`; } return `<${processedUrl}>`; }); // Then, handle reference link definitions: [ref]: url const refLinkDefRe = /^\[([^\]]+)\]:\s*(.+)$/gm; content = content.replace(refLinkDefRe, (full, ref, url) => { // Process the URL part (handle angle brackets in reference definitions too) let cleanUrl = url.trim(); let isAngleBracket = false; if (cleanUrl.startsWith('<') && cleanUrl.endsWith('>')) { cleanUrl = cleanUrl.slice(1, -1); isAngleBracket = true; } const processedUrl = processLinkHref(filename, cleanUrl, linkExceptions, slugByPath); // Preserve angle brackets if they were there and URL wasn't transformed to internal link if (isAngleBracket && processedUrl.startsWith('http')) { return `[${ref}]: <${processedUrl}>`; } return `[${ref}]: ${processedUrl}`; }); return content; } // Add import notice header function addImportNotice(filename) { const sourceUrl = `https://github.com/helm/community/blob/main/${filename}`; return ` `; // Removed extra newline here } // Format HIP sidebar_label with number prefix function formatHipSidebarLabel(meta, originalFrontmatter, filename) { // Check if this is a HIP file (has hip field in original frontmatter) const isHip = filename.startsWith('hips/') && originalFrontmatter && originalFrontmatter.hip; if (isHip && originalFrontmatter.hip && meta.title) { // Format hip number with leading zeros (4 digits) const hipNum = String(originalFrontmatter.hip).padStart(4, '0'); // Add sidebar_label with HIP number prefix meta.sidebar_label = `${hipNum}: ${meta.title}`; } return meta; } // Create markdown table from HIP frontmatter function createHipFrontmatterTable(originalFrontmatter, filename) { // Only create table for HIP files if (!filename.startsWith('hips/') || !originalFrontmatter.hip) { return ''; } // Define which fields to show and their display names // Order matches HIP-0001 specification const hipFields = [ { key: 'hip', label: 'HIP' }, { key: 'title', label: 'Title' }, { key: 'authors', label: 'Author(s)' }, { key: 'created', label: 'Created' }, { key: 'type', label: 'Type' }, { key: 'status', label: 'Status' }, { key: 'helm-version', label: 'Helm Version' }, // optional { key: 'requires', label: 'Requires' }, // optional { key: 'replaces', label: 'Replaces' }, // optional { key: 'superseded-by', label: 'Superseded by' }, // optional ]; // Collect fields that have values const fieldsWithValues = []; const values = []; for (const field of hipFields) { const value = originalFrontmatter[field.key]; if (value !== undefined && value !== null && value !== '') { fieldsWithValues.push(field); let displayValue; // Handle arrays (like authors) if (Array.isArray(value)) { displayValue = value.join(', '); } else { displayValue = String(value); } // Escape pipe characters in values displayValue = displayValue.replace(/\|/g, '\\|'); values.push(displayValue); } } if (fieldsWithValues.length === 0) { return ''; } // Build header row with field names const headerRow = '| ' + fieldsWithValues.map(f => `**${f.label}**`).join(' | ') + ' |'; // Build separator row with correct number of columns const separatorRow = '|' + fieldsWithValues.map(() => '---').join('|') + '|'; // Build data row with values const dataRow = '| ' + values.join(' | ') + ' |'; return '\n' + headerRow + '\n' + separatorRow + '\n' + dataRow + '\n\n'; } // Extract title from .txt file (handles both Markdown and underline-style headers) function extractTxtTitle(content) { // First try markdown-style H1 const h1Match = content.match(/^\s*#\s+([^\n]+)\n/); if (h1Match) return { title: h1Match[1].trim(), contentWithoutTitle: content.replace(/^\s*#\s+[^\n]+\n/, "") }; // Then try underline-style header (text followed by ===) const underlineMatch = content.match(/^\s*([^\n]+)\n=+\n/); if (underlineMatch) { return { title: underlineMatch[1].trim(), contentWithoutTitle: content.replace(/^\s*[^\n]+\n=+\n/, "") }; } return { title: null, contentWithoutTitle: content }; } // Compose transforms per file function transformImportedContent(filename, rawContent, metaByPath, slugByPath, linkExceptions) { // Check if this is a .txt file const isTxtFile = filename.endsWith('.txt'); // For .txt files, handle them specially if (isTxtFile) { // Extract title from the content const { title, contentWithoutTitle } = extractTxtTitle(rawContent); // Build metadata const meta = { ...(metaByPath[filename] || {}), ...(title ? { title } : {}) }; // Build frontmatter const fm = buildFrontMatter(meta); // Add import notice const importNotice = addImportNotice(filename); // Wrap the content in a code block const wrappedContent = `\`\`\`txt\n${contentWithoutTitle.trim()}\n\`\`\`\n`; // Return transformed content with new filename return { content: `${fm}${importNotice}\n${wrappedContent}`, filename: filename.replace(/\.txt$/, '.md') }; } // Original logic for non-.txt files // 1) Parse existing frontmatter and content const { frontMatter: existingFrontMatter, content: bodyWithH1 } = parseFrontMatterAndContent(rawContent); // Keep original frontmatter for HIP table const originalFrontmatter = { ...existingFrontMatter }; // 2) Extract H1 title and remove it from content const h1Title = extractH1Title(bodyWithH1); const bodyWithoutH1 = stripH1(bodyWithH1); // 3) For HIPs, remove HIP-specific fields from merged frontmatter (they'll go in the table) const hipSpecificFields = [ 'hip', 'authors', 'created', 'type', 'status', 'helm-version', 'requires', 'replaces', 'superseded-by' ]; const isHip = filename.startsWith('hips/') && existingFrontMatter.hip; let mergedMeta; if (isHip) { // For HIPs, filter out HIP-specific fields from frontmatter const filteredExisting = {}; for (const [key, value] of Object.entries(existingFrontMatter)) { if (!hipSpecificFields.includes(key)) { filteredExisting[key] = value; } } mergedMeta = { ...filteredExisting, ...metaByPath[filename] || {} }; } else { // For non-HIPs, keep everything mergedMeta = { ...existingFrontMatter, ...metaByPath[filename] || {} }; } // Add extracted H1 as title if no title is specified if (h1Title && !mergedMeta.title) { mergedMeta.title = h1Title; } // 4) Apply HIP-specific sidebar_label formatting formatHipSidebarLabel(mergedMeta, originalFrontmatter, filename); // 5) Build frontmatter (will always exist since we extract H1 or have config) const fm = buildFrontMatter(mergedMeta); // 6) Add import notice after frontmatter const importNotice = addImportNotice(filename); // 7) Create HIP frontmatter table if applicable const hipTable = createHipFrontmatterTable(originalFrontmatter, filename); // 8) Compose final content: frontmatter + import notice + HIP table + body let content = `${fm}${importNotice}${hipTable}${bodyWithoutH1}`; // 9) Rewrite links content = rewriteMarkdownLinks(filename, content, linkExceptions, slugByPath); // Return as object for consistency (even for non-.txt files) return { content }; } module.exports = { parseFrontMatterAndContent, extractH1Title, stripH1, buildFrontMatter, resolveCanonicalTargetPath, rewriteMarkdownLinks, transformImportedContent, }; ================================================ FILE: static/.nojekyll ================================================ ================================================ FILE: static/chartmuseum/index.html ================================================ Nothing to see here; move along. ================================================ FILE: static/helm/index.html ================================================ Nothing to see here; move along. ================================================ FILE: static/helm/v2/index.html ================================================ Nothing to see here; move along. ================================================ FILE: static/helm/v3/index.html ================================================ Nothing to see here; move along. ================================================ FILE: static/helm/v4/index.html ================================================ Nothing to see here; move along. ================================================ FILE: style-guide.md ================================================ # Documentation Style Guide This page lists writing style guidelines for the Helm documentation. These are guidelines, not rules. Use your best judgement, and depart from these guidelines when doing so improves our content. By default, the Helm docs use the Google Developer Docs Style Guide: https://developers.google.com/style/ This document provides several key guidelines, plus some house rules that aren't captured or differ from what's in the Google Developer Docs Style Guide. Refer to the Google Developer Docs Style Guide for additional guidelines that are not covered here. ## Helm Terminology For a list of common Helm terms, see the [Glossary](https://helm.sh/docs/glossary/) ## Markdown Features in Docusaurus Our static site generator, Docusaurus, has various built-in Markdown features that you can use when authoring content, such as: - Admonitions (notes, warnings, etc) - Code blocks - Tabs For more information about how to format these and other elements, see [Markdown Features](https://docusaurus.io/docs/markdown-features) in the Docusaurus documentation. ## Using Markdown and MDX This site uses Docusaurus with `markdown.format: "detect"`. Files with the `.md` extension are parsed as CommonMark, but `.mdx` files are parsed as MDX and require escaping characters like `{` and `<` (e.g., `\{`, `\<`). See the Docusaurus guide on [Markdown and JSX interoperability](https://docusaurus.io/docs/markdown-features/react#markdown-and-jsx-interoperability) for details. ## Word Choice, Tone, and Voice - Use active voice - Use the second person "you" to address the reader. Never use "let's" or "we" to refer to an action that the user is doing - Use present tense (for example, use "returns" and not "will return") - Write in a friendly tone without using slang, jargon, or frivolous words - Avoid marketing language that is overly promotional - Avoid terms like "simple" or "easy" - Use common words. For example, don't use words like "utilize" or "leverage" when you mean "use". Using common words makes the docs more suitable for a global audience - Avoid time-bound terminology like "currently", "new", "at this time", and "now". Instead, write timeless documentation that makes no assumptions about a reader's prior knowledge. - Avoid using the word "should". Instead, strive for more prescriptive documentation. For example, if an action is required, use words and phrase like "must" or "ensure that". If an action is optional/recommended, use words and phrases like "you can", "might", or "we recommend". ## Readability - Break up walls of text to make content easier to scan - Try to use fewer than 26 words per sentence - Define acronyms and abbreviations on first usage - Procedural/how-to content must use numbered steps. For one-step procedures, use a bullet point. See https://developers.google.com/style/procedures#single-step-procedures for examples. - Use semantic line breaks when authoring content. In general, this means adding a line break after each sentence. For longer sentences, you can also add a semantic line break in between clauses. Using semantic line breaks makes content easier to edit and review, without altering the final rendered version seen by users. ## Text Formatting - Use bold and italic text sparingly. - Bold text is primarily used to identify UI elements. For example, "Click **Save**." - Do not use bold text to emphasize important content. Instead, if discoverability is a concern, consider how the content could be reorganized or how you could use clearer headings. - It's okay to use bold text for introducing an example (`**Example:**`) or for run-in headings in unordered lists (`* **Item 1:** Description`) - Use notes and asides sparingly. In general, the user should be able to succeed even if they skip the information in the note. ## Titles and Headings - Use title case for titles and headings - Use a bare infinitive verb form for titles and headings for how-to content. As in, use "Create a Release" instead of "Creating a Release" - Don't skip levels in the heading hierarchy. For example, an h3 element must only appear after an h2 ## Cross References - Use descriptive link text. This is important to help improve both accessibility and readability. In general, effective link text is formatted like this: `For more information about X, see [Page or Section Title]`, where "X" is a description of the subject matter. For example, `For more information about accessing values from within templates, see [Subcharts and Global Values](/chart_template_guide/subcharts_and_globals).` - Avoid vague link text like `"click [here](link) for more information"` or `"see this [blog post](link)"` ================================================ FILE: versioned_docs/version-2/architecture.md ================================================ --- sidebar_position: 9 sidebar_label: "Architecture" --- # The Kubernetes Helm Architecture This document describes the Helm architecture at a high level. ## The Purpose of Helm Helm is a tool for managing Kubernetes packages called _charts_. Helm can do the following: - Create new charts from scratch - Package charts into chart archive (tgz) files - Interact with chart repositories where charts are stored - Install and uninstall charts into an existing Kubernetes cluster - Manage the release cycle of charts that have been installed with Helm For Helm, there are three important concepts: 1. The _chart_ is a bundle of information necessary to create an instance of a Kubernetes application. 2. The _config_ contains configuration information that can be merged into a packaged chart to create a releasable object. 3. A _release_ is a running instance of a _chart_, combined with a specific _config_. ## Components Helm has two major components: **The Helm Client** is a command-line client for end users. The client is responsible for the following domains: - Local chart development - Managing repositories - Interacting with the Tiller server - Sending charts to be installed - Asking for information about releases - Requesting upgrading or uninstalling of existing releases **The Tiller Server** is an in-cluster server that interacts with the Helm client, and interfaces with the Kubernetes API server. The server is responsible for the following: - Listening for incoming requests from the Helm client - Combining a chart and configuration to build a release - Installing charts into Kubernetes, and then tracking the subsequent release - Upgrading and uninstalling charts by interacting with Kubernetes In a nutshell, the client is responsible for managing charts, and the server is responsible for managing releases. ## Implementation The Helm client is written in the Go programming language, and uses the gRPC protocol suite to interact with the Tiller server. The Tiller server is also written in Go. It provides a gRPC server to connect with the client, and it uses the Kubernetes client library to communicate with Kubernetes. Currently, that library uses REST+JSON. The Tiller server stores information in ConfigMaps located inside of Kubernetes. It does not need its own database. Configuration files are, when possible, written in YAML. ================================================ FILE: versioned_docs/version-2/chart_best_practices/chart_best_practices.md ================================================ --- sidebar_position: 7 sidebar_label: "Best Practices" # This is the index/landing page for this section --- # The Chart Best Practices Guide This guide covers the Helm Team's considered best practices for creating charts. It focuses on how charts should be structured. We focus primarily on best practices for charts that may be publicly deployed. We know that many charts are for internal-use only, and authors of such charts may find that their internal interests override our suggestions here. ## Table of Contents - [General Conventions](conventions.md): Learn about general chart conventions. - [Values Files](values.md): See the best practices for structuring `values.yaml`. - [Templates](templates.md): Learn some of the best techniques for writing templates. - [Requirements](requirements.md): Follow best practices for `requirements.yaml` files. - [Labels and Annotations](labels.md): Helm has a _heritage_ of labeling and annotating. - Kubernetes Resources: - [Pods and Pod Specs](pods.md): See the best practices for working with pod specifications. - [Role-Based Access Control](rbac.md): Guidance on creating and using service accounts, roles, and role bindings. - [Custom Resource Definitions](custom_resource_definitions.md): Custom Resource Definitions (CRDs) have their own associated best practices. ================================================ FILE: versioned_docs/version-2/chart_best_practices/conventions.md ================================================ --- sidebar_position: 1 sidebar_label: "General Conventions" --- # General Conventions This part of the Best Practices Guide explains general conventions. ## Chart Names Chart names should use lower case letters and numbers, and start with a letter. Hyphens (-) are allowed, but are known to be a little trickier to work with in Helm templates (see [issue #2192](https://github.com/helm/helm/issues/2192) for more information). Here are a few examples of good chart names from the [Helm Community Charts](https://github.com/helm/charts): ``` drupal cert-manager oauth2-proxy ``` Neither uppercase letters nor underscores should be used in chart names. Dots should not be used in chart names. The directory that contains a chart MUST have the same name as the chart. Thus, the chart `cert-manager` MUST be created in a directory called `cert-manager/`. This is not merely a stylistic detail, but a requirement of the Helm Chart format. ## Version Numbers Wherever possible, Helm uses [SemVer 2](https://semver.org) to represent version numbers. (Note that Docker image tags do not necessarily follow SemVer, and are thus considered an unfortunate exception to the rule.) When SemVer versions are stored in Kubernetes labels, we conventionally alter the `+` character to an `_` character, as labels do not allow the `+` sign as a value. ## Formatting YAML YAML files should be indented using _two spaces_ (and never tabs). ## Usage of the Words Helm, Tiller, and Chart There are a few small conventions followed for using the words Helm, helm, Tiller, and tiller. - Helm refers to the project, and is often used as an umbrella term - `helm` refers to the client-side command - Tiller is the proper name of the backend - `tiller` is the name of the binary run on the backend - The term 'chart' does not need to be capitalized, as it is not a proper noun. When in doubt, use _Helm_ (with an uppercase 'H'). ## Restricting Tiller by Version A `Chart.yaml` file can specify a `tillerVersion` SemVer constraint: ```yaml name: mychart version: 0.2.0 tillerVersion: ">=2.4.0" ``` This constraint should be set when templates use a new feature that was not supported in older versions of Helm. While this parameter will accept sophisticated SemVer rules, the best practice is to default to the form `>=2.4.0`, where `2.4.0` is the version that introduced the new feature used in the chart. This feature was introduced in Helm 2.4.0, so any version of Tiller older than 2.4.0 will simply ignore this field. ================================================ FILE: versioned_docs/version-2/chart_best_practices/custom_resource_definitions.md ================================================ --- sidebar_position: 7 sidebar_label: "Custom Resource Definitions" --- # Custom Resource Definitions This section of the Best Practices Guide deals with creating and using Custom Resource Definition objects. When working with Custom Resource Definitions (CRDs), it is important to distinguish two different pieces: - There is a declaration of a CRD. This is the YAML file that has the kind `CustomResourceDefinition` - Then there are resources that _use_ the CRD. Say a CRD defines `foo.example.com/v1`. Any resource that has `apiVersion: example.com/v1` and kind `Foo` is a resource that uses the CRD. ## Install a CRD Declaration Before Using the Resource Helm is optimized to load as many resources into Kubernetes as fast as possible. By design, Kubernetes can take an entire set of manifests and bring them all online (this is called the reconciliation loop). But there's a difference with CRDs. For a CRD, the declaration must be registered before any resources of that CRDs kind(s) can be used. And the registration process sometimes takes a few seconds. ### Method 1: Separate Charts One way to do this is to put the CRD definition in one chart, and then put any resources that use that CRD in _another_ chart. In this method, each chart must be installed separately. ### Method 2: Crd-install Hooks To package the two together, add a `crd-install` hook to the CRD definition so that it is fully installed before the rest of the chart is executed. Note that if you create the CRD with a `crd-install` hook, that CRD definition will not be deleted when `helm delete` is run. ================================================ FILE: versioned_docs/version-2/chart_best_practices/labels.md ================================================ --- sidebar_position: 5 sidebar_label: "Labels & Annotations" --- # Labels and Annotations This part of the Best Practices Guide discusses the best practices for using labels and annotations in your chart. ## Is it a Label or an Annotation? An item of metadata should be a label under the following conditions: - It is used by Kubernetes to identify this resource - It is useful to expose to operators for the purpose of querying the system. For example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that operators can conveniently find all of the instances of a particular chart to use. If an item of metadata is not used for querying, it should be set as an annotation instead. Helm hooks are always annotations. ## Standard Labels The following table defines common labels that Helm charts use. Helm itself never requires that a particular label be present. Labels that are marked REC are recommended, and _should_ be placed onto a chart for global consistency. Those marked OPT are optional. These are idiomatic or commonly in use, but are not relied upon frequently for operational purposes. Name|Status|Description -----|------|---------- `app.kubernetes.io/name` | REC | This should be the app name, reflecting the entire app. Usually `{{ template "name" . }}` is used for this. This is used by many Kubernetes manifests, and is not Helm-specific. `helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Tiller. `app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application. `app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | This is a common label for marking the different roles that pieces may play in an application. For example, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | When multiple charts or pieces of software are used together to make one application. For example, application software and a database to produce a website. This can be set to the top level application being supported. You can find more information on the Kubernetes labels, prefixed with `app.kubernetes.io`, in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: versioned_docs/version-2/chart_best_practices/pods.md ================================================ --- sidebar_position: 6 sidebar_label: "Pods & PodTemplates" --- # Pods and PodTemplates This part of the Best Practices Guide discusses formatting the Pod and PodTemplate portions in chart manifests. The following (non-exhaustive) list of resources use PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images A container image should use a fixed tag or the SHA of the image. It should not use the tags `latest`, `head`, `canary`, or other tags that are designed to be "floating". Images _may_ be defined in the `values.yaml` file to make it easy to swap out images. ``` image: {{ .Values.redisImage | quote }} ``` An image and a tag _may_ be defined in `values.yaml` as two separate fields: ``` image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing the following in your `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` And `values.yaml`: ```yaml pullPolicy: IfNotPresent ``` Similarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is not defined at all. If you want a value other than `IfNotPresent`, simply update the value in `values.yaml` to your desired value. ## PodTemplates Should Declare Selectors All PodTemplate sections should specify a selector. For example: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` This is a good practice because it makes the relationship between the set and the pod. But this is even more important for sets like Deployment. Without this, the _entire_ set of labels is used to select matching pods, and this will break if you use labels that change, like version or release date. ================================================ FILE: versioned_docs/version-2/chart_best_practices/rbac.md ================================================ --- sidebar_position: 8 sidebar_label: "RBAC" --- # Role-Based Access Control This part of the Best Practices Guide discusses the creation and formatting of RBAC resources in chart manifests. RBAC resources are: - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## YAML Configuration RBAC and ServiceAccount configuration should happen under separate keys. They are separate things. Splitting these two concepts out in the YAML disambiguates them and make this clearer. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` This structure can be extended for more complex charts that require multiple ServiceAccounts. ```yaml serviceAccounts: client: create: true name: server: create: true name: ``` ## RBAC Resources Should be Created by Default `rbac.create` should be a boolean value controlling whether RBAC resources are created. The default should be `true`. Users who wish to manage RBAC access controls themselves can set this value to `false` (in which case see below). ## Using RBAC Resources `serviceAccount.name` should set to the name of the ServiceAccount to be used by access-controlled resources created by the chart. If `serviceAccount.create` is true, then a ServiceAccount with this name should be created. If the name is not set, then a name is generated using the `fullname` template, If `serviceAccount.create` is false, then it should not be created, but it should still be associated with the same resources so that manually-created RBAC resources created later that reference it will function correctly. If `serviceAccount.create` is false and the name is not specified, then the default ServiceAccount is used. The following helper template should be used for the ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: versioned_docs/version-2/chart_best_practices/requirements.md ================================================ --- sidebar_position: 4 sidebar_label: "Requirements" --- # Requirements Files This section of the guide covers best practices for `requirements.yaml` files. ## Versions Where possible, use version ranges instead of pinning to an exact version. The suggested default is to use a patch-level version match: ```yaml version: ~1.2.3 ``` This will match version `1.2.3` and any patches to that release. In other words, `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0` For the complete version matching syntax, please see the [semver documentation](https://github.com/Masterminds/semver#checking-version-constraints) ### Repository URLs Where possible, use `https://` repository URLs, followed by `http://` URLs. If the repository has been added to the repository index file, the repository name can be used as an alias of URL. Use `alias:` or `@` followed by repository names. File URLs (`file://...`) are considered a "special case" for charts that are assembled by a fixed deployment pipeline. Charts that use `file://` in a `requirements.yaml` file are not allowed in the official Helm repository. ## Conditions and Tags Conditions or tags should be added to any dependencies that _are optional_. The preferred form of a condition is: ```yaml condition: somechart.enabled ``` Where `somechart` is the chart name of the dependency. When multiple subcharts (dependencies) together provide an optional or swappable feature, those charts should share the same tags. For example, if both `nginx` and `memcached` together provided performance optimizations for the main app in the chart, and were required to both be present when that feature is enabled, then they might both have a tags section like this: ``` tags: - webaccelerator ``` This allows a user to turn that feature on and off with one tag. ================================================ FILE: versioned_docs/version-2/chart_best_practices/templates.md ================================================ --- sidebar_position: 3 sidebar_label: "Templates" --- # Templates This part of the Best Practices Guide focuses on templates. ## Structure of templates/ The templates directory should be structured as follows: - Template files should have the extension `.yaml` if they produce YAML output. The extension `.tpl` may be used for template files that produce no formatted content. - Template file names should use dashed notation (`my-example-configmap.yaml`), not camelcase. - Each resource definition should be in its own template file. - Template file names should reflect the resource kind in the name. e.g. `foo-pod.yaml`, `bar-svc.yaml` ## Names of Defined Templates Defined templates (templates created inside a `{{ define }} ` directive) are globally accessible. That means that a chart and all of its subcharts will have access to all of the templates created with `{{ define }}`. For that reason, _all defined template names should be namespaced._ Correct: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorrect: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` It is highly recommended that new charts are created via `helm create` command as the template names are automatically defined as per this best practice. ## Formatting Templates Templates should be indented using _two spaces_ (never tabs). Template directives should have whitespace after the opening braces and before the closing braces: Correct: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorrect: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Templates should chomp whitespace where possible: ``` foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Blocks (such as control structures) may be indented to indicate flow of the template code. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` However, since YAML is a whitespace-oriented language, it is often not possible for code indentation to follow that convention. ## Whitespace in Generated Templates It is preferable to keep the amount of whitespace in generated templates to a minimum. In particular, numerous blank lines should not appear adjacent to each other. But occasional empty lines (particularly between logical sections) is fine. This is best: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` This is okay: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` But this should be avoided: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Resource Naming in Templates Hard-coding the `name:` into a resource is usually considered to be bad practice. Names should be unique to a release. So we might want to generate a name field by inserting the release name - for example: ```yaml apiVersion: v1 kind: Service metadata: name: {{ .Release.Name }}-myservice ``` Or if there is only one resource of this kind then we could use .Release.Name or the template fullname function defined in \_helpers.tpl (which uses release name): ```yaml apiVersion: v1 kind: Service metadata: name: {{ template "fullname" . }} ``` However, there may be cases where it is known that there won't be naming conflicts from a fixed name. In these cases a fixed name might make it easier for an application to find a resource such as a Service. If the option for fixed names is needed then one way to manage this might be to make the setting of the name explicit by using a service.name value from the values.yaml if provided: ```yaml apiVersion: v1 kind: Service metadata: {{- if .Values.service.name }} name: {{ .Values.service.name }} {{- else }} name: {{ template "fullname" . }} {{- end }} ``` ## Comments (YAML Comments vs. Template Comments) Both YAML and Helm Templates have comment markers. YAML comments: ```yaml # This is a comment type: sprocket ``` Template Comments: ```yaml {{- /* This is a comment. */ -}} type: frobnitz ``` Template comments should be used when documenting features of a template, such as explaining a defined template: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */ -}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Inside of templates, YAML comments may be used when it is useful for Helm users to (possibly) see the comments during debugging. ``` # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` The comment above is visible when the user runs `helm install --debug`, while comments specified in `{{- /* */ -}}` sections are not. ## Use of JSON in Templates and Template Output YAML is a superset of JSON. In some cases, using a JSON syntax can be more readable than other YAML representations. For example, this YAML is closer to the normal YAML method of expressing lists: ```yaml arguments: - "--dirname" - "/foo" ``` But it is easier to read when collapsed into a JSON list style: ```yaml arguments: ["--dirname", "/foo"] ``` Using JSON for increased legibility is good. However, JSON syntax should not be used for representing more complex constructs. When dealing with pure JSON embedded inside of YAML (such as init container configuration), it is of course appropriate to use the JSON format. ================================================ FILE: versioned_docs/version-2/chart_best_practices/values.md ================================================ --- sidebar_position: 2 sidebar_label: "Values" --- # Values This part of the best practices guide covers using values. In this part of the guide, we provide recommendations on how you should structure and use your values, with focus on designing a chart's `values.yaml` file. ## Naming Conventions Variables names should begin with a lowercase letter, and words should be separated with camelcase: Correct: ```yaml chicken: true chickenNoodleSoup: true ``` Incorrect: ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` Note that all of Helm's built-in variables begin with an uppercase letter to easily distinguish them from user-defined values: `.Release.Name`, `.Capabilities.KubeVersion`. ## Flat or Nested Values YAML is a flexible format, and values may be nested deeply or flattened. Nested: ```yaml server: name: nginx port: 80 ``` Flat: ```yaml serverName: nginx serverPort: 80 ``` In most cases, flat should be favored over nested. The reason for this is that it is simpler for template developers and users. For optimal safety, a nested value must be checked at every level: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` For every layer of nesting, an existence check must be done. But for flat configuration, such checks can be skipped, making the template easier to read and use. ``` {{ default "none" .Values.serverName }} ``` When there are a large number of related variables, and at least one of them is non-optional, nested values may be used to improve readability. ## Make Types Clear YAML's type coercion rules are sometimes counterintuitive. For example, `foo: false` is not the same as `foo: "false"`. Large integers like `foo: 12345678` will get converted to scientific notation in some cases. The easiest way to avoid type conversion errors is to be explicit about strings, and implicit about everything else. Or, in short, _quote all strings_. Often, to avoid the integer casting issues, it is advantageous to store your integers as strings as well, and use `{{ int $value }}` in the template to convert from a string back to an integer. In most cases, explicit type tags are respected, so `foo: !!string 1234` should treat `1234` as a string. _However_, the YAML parser consumes tags, so the type data is lost after one parse. ## Consider How Users Will Use Your Values There are four potential sources of values: - A chart's `values.yaml` file - A values file supplied by `helm install -f` or `helm upgrade -f` - The values passed to a `--set` or `--set-string` flag on `helm install` or `helm upgrade` - The content of a file passed to `--set-file` flag on `helm install` or `helm upgrade` When designing the structure of your values, keep in mind that users of your chart may want to override them via either the `-f` flag or with the `--set` option. Since `--set` is more limited in expressiveness, the first guidelines for writing your `values.yaml` file is _make it easy to override from `--set`_. For this reason, it's often better to structure your values file using maps. Difficult to use with `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` The above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5, the accessing the port on foo is `--set servers[0].port=80`. Not only is it harder for the user to figure out, but it is prone to errors if at some later time the order of the `servers` is changed. Easy to use: ```yaml servers: foo: port: 80 bar: port: 81 ``` Accessing foo's port is much more obvious: `--set servers.foo.port=80`. ## Document 'values.yaml' Every defined property in 'values.yaml' should be documented. The documentation string should begin with the name of the property that it describes, and then give at least a one-sentence description. Incorrect: ``` # the host name for the webserver serverHost = example serverPort = 9191 ``` Correct: ``` # serverHost is the host name for the webserver serverHost = example # serverPort is the HTTP listener port for the webserver serverPort = 9191 ``` Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation, and will enable documentation tools to reliably correlate doc strings with the parameters they describe. ================================================ FILE: versioned_docs/version-2/chart_template_guide/accessing_files.md ================================================ --- sidebar_position: 8 sidebar_label: "Accessing Files Inside Templates" --- # Accessing Files Inside Templates In the previous section we looked at several ways to create and access named templates. This makes it easy to import one template from within another template. But sometimes it is desirable to import a _file that is not a template_ and inject its contents without sending the contents through the template renderer. Helm provides access to files through the `.Files` object. Before we get going with the template examples, though, there are a few things to note about how this works: - It is okay to add extra files to your Helm chart. These files will be bundled and sent to Tiller. Be careful, though. Charts must be smaller than 1M because of the storage limitations of Kubernetes objects. - Some files cannot be accessed through the `.Files` object, usually for security reasons. - Files in `templates/` cannot be accessed. - Files excluded using `.helmignore` cannot be accessed. - Charts do not preserve UNIX mode information, so file-level permissions will have no impact on the availability of a file when it comes to the `.Files` object. - [Basic example](#basic-example) - [Path helpers](#path-helpers) - [Glob patterns](#glob-patterns) - [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions) - [Encoding](#encoding) - [Lines](#lines) ## Basic example With those caveats behind, let's write a template that reads three files into our ConfigMap. To get started, we will add three files to the chart, putting all three directly inside of the `mychart/` directory. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Each of these is a simple TOML file (think old-school Windows INI files). We know the names of these files, so we can use a `range` function to loop through them and inject their contents into our ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range list "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` This config map uses several of the techniques discussed in previous sections. For example, we create a `$files` variable to hold a reference to the `.Files` object. We also use the `list` function to create a list of files that we loop through. Then we print each file name (`{{.}}: |-`) followed by the contents of the file `{{ $files.Get . }}`. Running this template will produce a single ConfigMap with the contents of all three files: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Path helpers When working with files, it can be very useful to perform some standard operations on the file paths themselves. To help with this, Helm imports many of the functions from Go's [path](https://golang.org/pkg/path/) package for your use. They are all accessible with the same names as in the Go package, but with a lowercase first letter. For example, `Base` becomes `base`, etc. The imported functions are: - Base - Dir - Ext - IsAbs - Clean ## Glob patterns As your chart grows, you may find you have a greater need to organize your files more, and so we provide a `Files.Glob(pattern string)` method to assist in extracting certain files with all the flexibility of [glob patterns](https://godoc.org/github.com/gobwas/glob). `.Glob` returns a `Files` type, so you may call any of the `Files` methods on the returned object. For example, imagine the directory structure: ```txt foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` You have multiple options with Globs: ```yaml {{ $root := . }} {{ range $path, $bytes := .Files.Glob "**.yaml" }} {{ $path }}: |- {{ $root.Files.Get $path }} {{ end }} ``` Or ```yaml {{ $root := . }} {{ range $path, $bytes := .Files.Glob "foo/*" }} {{ base $path }}: '{{ $root.Files.Get $path | b64enc }}' {{ end }} ``` ## ConfigMap and Secrets utility functions (Not present in version 2.0.2 or prior) It is very common to want to place file content into both configmaps and secrets, for mounting into your pods at run time. To help with this, we provide a couple utility methods on the `Files` type. For further organization, it is especially useful to use these methods in conjunction with the `Glob` method. Given the directory structure from the [Glob](#glob-patterns) example above: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{- (.Files.Glob "foo/*").AsConfig | nindent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{- (.Files.Glob "bar/*").AsSecrets | nindent 2 }} ``` ## Encoding You can import a file and have the template base-64 encode it to ensure successful transmission: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` The above will take the same `config1.toml` file we used before and encode it: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9IEhlbGxvIGZyb20gY29uZmlnIDEK ``` ## Lines Sometimes it is desirable to access each line of a file in your template. We provide a convenient `Lines` method for this. ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` Currently, there is no way to pass files external to the chart during `helm install`. So if you are asking users to supply data, it must be loaded using `helm install -f` or `helm install --set`. This discussion wraps up our dive into the tools and techniques for writing Helm templates. In the next section we will see how you can use one special file, `templates/NOTES.txt`, to send post-installation instructions to the users of your chart. ================================================ FILE: versioned_docs/version-2/chart_template_guide/builtin_objects.md ================================================ --- sidebar_position: 2 sidebar_label: "Built-In Objects" --- # Built-in Objects Objects are passed into a template from the template engine. And your code can pass objects around (we'll see examples when we look at the `with` and `range` statements). There are even a few ways to create new objects within your templates, like with the `list` function we'll see later. Objects can be simple, and have just one value. Or they can contain other objects or functions. For example. the `Release` object contains several objects (like `Release.Name`) and the `Files` object has a few functions. In the previous section, we use `{{.Release.Name}}` to insert the name of a release into a template. `Release` is one of the top-level objects that you can access in your templates. - `Release`: This object describes the release itself. It has several objects inside of it: - `Release.Name`: The release name - `Release.Time`: The time of the release - `Release.Namespace`: The namespace to be released into (if the manifest doesn't override) - `Release.Service`: The name of the releasing service (always `Tiller`). - `Release.Revision`: The revision number of this release. It begins at 1 and is incremented for each `helm upgrade`. - `Release.IsUpgrade`: This is set to `true` if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to `true` if the current operation is an install. - `Values`: Values passed into the template from the `values.yaml` file and from user-supplied files. By default, `Values` is empty. - `Chart`: The contents of the `Chart.yaml` file. Any data in `Chart.yaml` will be accessible here. For example `{{.Chart.Name}}-{{.Chart.Version}}` will print out the `mychart-0.1.0`. - The available fields are listed in the [Charts Guide](https://github.com/helm/helm/blob/master/docs/charts.md#the-chartyaml-file) - `Files`: This provides access to all non-special files in a chart. While you cannot use it to access templates, you can use it to access other files in the chart. See the section _Accessing Files_ for more. - `Files.Get` is a function for getting a file by name (`.Files.Get config.ini`) - `Files.GetBytes` is a function for getting the contents of a file as an array of bytes instead of as a string. This is useful for things like images. - `Capabilities`: This provides information about what capabilities the Kubernetes cluster supports. - `Capabilities.APIVersions` is a set of versions. - `Capabilities.APIVersions.Has $version` indicates whether a version (e.g., `batch/v1`) or resource (e.g., `apps/v1/Deployment`) is available on the cluster. Note, resources were not available before Helm v2.15. - `Capabilities.KubeVersion` provides a way to look up the Kubernetes version. It has the following values: `Major`, `Minor`, `GitVersion`, `GitCommit`, `GitTreeState`, `BuildDate`, `GoVersion`, `Compiler`, and `Platform`. - `Capabilities.TillerVersion` provides a way to look up the Tiller version. It has the following values: `SemVer`, `GitCommit`, and `GitTreeState`. - `Template`: Contains information about the current template that is being executed - `Name`: A namespaced filepath to the current template (e.g. `mychart/templates/mytemplate.yaml`) - `BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`). The values are available to any top-level template. As we will see later, this does not necessarily mean that they will be available _everywhere_. The built-in values always begin with a capital letter. This is in keeping with Go's naming convention. When you create your own names, you are free to use a convention that suits your team. Some teams, like the [Helm Charts](https://github.com/helm/charts) team, choose to use only initial lower case letters in order to distinguish local names from those built-in. In this guide, we follow that convention. ================================================ FILE: versioned_docs/version-2/chart_template_guide/chart_template_guide.md ================================================ --- sidebar_position: 6 sidebar_label: "Developing Templates" # This is the index/landing page for this section --- # The Chart Template Developer's Guide This guide provides an introduction to Helm's chart templates, with emphasis on the template language. Templates generate manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. We'll look at how templates are structured, how they can be used, how to write Go templates, and how to debug your work. This guide focuses on the following concepts: - The Helm template language - Using values - Techniques for working with templates This guide is oriented toward learning the ins and outs of the Helm template language. Other guides provide introductory material, examples, and best practices. ================================================ FILE: versioned_docs/version-2/chart_template_guide/control_structures.md ================================================ --- sidebar_position: 5 sidebar_label: "Flow Control" --- # Flow Control Control structures (called "actions" in template parlance) provide you, the template author, with the ability to control the flow of a template's generation. Helm's template language provides the following control structures: - `if`/`else` for creating conditional blocks - `with` to specify a scope - `range`, which provides a "for each"-style loop In addition to these, it provides a few actions for declaring and using named template segments: - `define` declares a new named template inside of your template - `template` imports a named template - `block` declares a special kind of fillable template area In this section, we'll talk about `if`, `with`, and `range`. The others are covered in the "Named Templates" section later in this guide. ## If/Else The first control structure we'll look at is for conditionally including blocks of text in a template. This is the `if`/`else` block. The basic structure for a conditional looks like this: ```yaml {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Notice that we're now talking about _pipelines_ instead of values. The reason for this is to make it clear that control structures can execute an entire pipeline, not just evaluate a value. A pipeline is evaluated as _false_ if the value is: - a boolean false - a numeric zero - an empty string - a `nil` (empty or null) - an empty collection (`map`, `slice`, `tuple`, `dict`, `array`) In any other case, the condition is evaluated to _true_ and the pipeline is executed. Let's add a simple conditional to our ConfigMap. We'll add another setting if the drink is set to coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if and .Values.favorite.drink (eq .Values.favorite.drink "coffee") }}mug: true{{ end }} ``` Note that `.Values.favorite.drink` must be defined or else it will throw an error when comparing it to "coffee". Since we commented out `drink: coffee` in our last example, the output should not include a `mug: true` flag. But if we add that line back into our `values.yaml` file, the output should look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true ``` ## Controlling Whitespace While we're looking at conditionals, we should take a quick look at the way whitespace is controlled in templates. Let's take the previous example and format it to be a little easier to read: ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{if eq .Values.favorite.drink "coffee"}} mug: true {{end}} ``` Initially, this looks good. But if we run it through the template engine, we'll get an unfortunate result: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` What happened? We generated incorrect YAML because of the whitespacing above. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true ``` `mug` is incorrectly indented. Let's simply out-dent that one line, and re-run: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{if eq .Values.favorite.drink "coffee"}} mug: true {{end}} ``` When we sent that, we'll get YAML that is valid, but still looks a little funny: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true ``` Notice that we received a few empty lines in our YAML. Why? When the template engine runs, it _removes_ the contents inside of `{{` and `}}`, but it leaves the remaining whitespace exactly as is. YAML ascribes meaning to whitespace, so managing the whitespace becomes pretty important. Fortunately, Helm templates have a few tools to help. First, the curly brace syntax of template declarations can be modified with special characters to tell the template engine to chomp whitespace. `{{- ` (with the dash and space added) indicates that whitespace should be chomped left, while ` -}}` means whitespace to the right should be consumed. _Be careful! Newlines are whitespace!_ > Make sure there is a space between the `-` and the rest of your directive. `{{- 3 }}` means "trim left whitespace and print 3" while `{{-3}}` means "print -3". Using this syntax, we can modify our template to get rid of those new lines: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee"}} mug: true {{- end}} ``` Just for the sake of making this point clear, let's adjust the above, and substitute an `*` for each whitespace that will be deleted following this rule. an `*` at the end of the line indicates a newline character that would be removed ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee"}} mug: true* **{{- end}} ``` Keeping that in mind, we can run our template through Helm and see the result: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: true ``` Be careful with the chomping modifiers. It is easy to accidentally do things like this: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: true {{- end -}} ``` That will produce `food: "PIZZA"mug:true` because it consumed newlines on both sides. > For the details on whitespace control in templates, see the [Official Go template documentation](https://godoc.org/text/template) Finally, sometimes it's easier to tell the template system how to indent for you instead of trying to master the spacing of template directives. For that reason, you may sometimes find it useful to use the `indent` function (`{{indent 2 "mug:true"}}`). ## Modifying scope using `with` The next control structure to look at is the `with` action. This controls variable scoping. Recall that `.` is a reference to _the current scope_. So `.Values` tells the template to find the `Values` object in the current scope. The syntax for `with` is similar to a simple `if` statement: ```yaml {{ with PIPELINE }} # restricted scope {{ end }} ``` Scopes can be changed. `with` can allow you to set the current scope (`.`) to a particular object. For example, we've been working with `.Values.favorites`. Let's rewrite our ConfigMap to alter the `.` scope to point to `.Values.favorites`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` (Note that we removed the `if` conditional from the previous exercise) Notice that now we can reference `.drink` and `.food` without qualifying them. That is because the `with` statement sets `.` to point to `.Values.favorite`. The `.` is reset to its previous scope after `{{ end }}`. But here's a note of caution! Inside of the restricted scope, you will not be able to access the other objects from the parent scope. This, for example, will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` It will produce an error because `Release.Name` is not inside of the restricted scope for `.`. However, if we swap the last two lines, all will work as expected because the scope is reset after `{{end}}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` After looking at `range`, we will take a look at template variables, which offers one solution to the scoping issue above. ## Looping with the `range` action Many programming languages have support for looping using `for` loops, `foreach` loops, or similar functional mechanisms. In Helm's template language, the way to iterate through a collection is to use the `range` operator. To start, let's add a list of pizza toppings to our `values.yaml` file: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions ``` Now we have a list (called a `slice` in templates) of `pizzaToppings`. We can modify our template to print this list into our ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` Let's take a closer look at the `toppings:` list. The `range` function will "range over" (iterate through) the `pizzaToppings` list. But now something interesting happens. Just like `with` sets the scope of `.`, so does a `range` operator. Each time through the loop, `.` is set to the current pizza topping. That is, the first time, `.` is set to `mushrooms`. The second iteration it is set to `cheese`, and so on. We can send the value of `.` directly down a pipeline, so when we do `{{ . | title | quote }}`, it sends `.` to `title` (title case function) and then to `quote`. If we run this template, the output will be: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" ``` Now, in this example we've done something tricky. The `toppings: |-` line is declaring a multi-line string. So our list of toppings is actually not a YAML list. It's a big string. Why would we do this? Because the data in ConfigMaps `data` is composed of key/value pairs, where both the key and the value are simple strings. To understand why this is the case, take a look at the [Kubernetes ConfigMap docs](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/). For us, though, this detail doesn't matter much. > The `|-` marker in YAML takes a multi-line string. This can be a useful technique for embedding big blocks of data inside of your manifests, as exemplified here. Sometimes it's useful to be able to quickly make a list inside of your template, and then iterate over that list. Helm templates have a function that's called just that: `list`. ```yaml sizes: |- {{- range list "small" "medium" "large" }} - {{ . }} {{- end }} ``` The above will produce this: ```yaml sizes: |- - small - medium - large ``` In addition to lists, `range` can be used to iterate over collections that have a key and a value (like a `map` or `dict`). We'll see how to do that in the next section when we introduce template variables. ================================================ FILE: versioned_docs/version-2/chart_template_guide/data_types.md ================================================ --- sidebar_position: 15 sidebar_label: "Appendix: Go Data Types and Templates" --- # Appendix: Go Data Types and Templates The Helm template language is implemented in the strongly typed Go programming language. For that reason, variables in templates are _typed_. For the most part, variables will be exposed as one of the following types: - string: A string of text - bool: a `true` or `false` - int: An integer value (there are also 8, 16, 32, and 64 bit signed and unsigned variants of this) - float64: a 64-bit floating point value (there are also 8, 16, and 32 bit varieties of this) - a byte slice (`[]byte`), often used to hold (potentially) binary data - struct: an object with properties and methods - a slice (indexed list) of one of the previous types - a string-keyed map (`map[string]interface{}`) where the value is one of the previous types There are many other types in Go, and sometimes you will have to convert between them in your templates. The easiest way to debug an object's type is to pass it through `printf "%t"` in a template, which will print the type. Also see the `typeOf` and `kindOf` functions. ================================================ FILE: versioned_docs/version-2/chart_template_guide/debugging.md ================================================ --- sidebar_position: 12 sidebar_label: "Debugging Templates" --- # Debugging Templates Debugging templates can be tricky simply because the templates are rendered on the Tiller server, not the Helm client. And then the rendered templates are sent to the Kubernetes API server, which may reject the YAML files for reasons other than formatting. There are a few commands that can help you debug. - `helm lint` is your go-to tool for verifying that your chart follows best practices - `helm install --dry-run --debug`: We've seen this trick already. It's a great way to have the server render your templates, then return the resulting manifest file. - `helm get manifest`: This is a good way to see what templates are installed on the server. When your YAML is failing to parse, but you want to see what is generated, one easy way to retrieve the YAML is to comment out the problem section in the template, and then re-run `helm install --dry-run --debug`: ```yaml apiVersion: v1 # some: problem section # {{ .Values.foo | quote }} ``` The above will be rendered and returned with the comments intact: ```yaml apiVersion: v1 # some: problem section # "bar" ``` This provides a quick way of viewing the generated content without YAML parse errors blocking. ================================================ FILE: versioned_docs/version-2/chart_template_guide/functions_and_pipelines.md ================================================ --- sidebar_position: 4 sidebar_label: "Template Functions and Pipelines" --- # Template Functions and Pipelines So far, we've seen how to place information into a template. But that information is placed into the template unmodified. Sometimes we want to transform the supplied data in a way that makes it more usable to us. Let's start with a best practice: When injecting strings from the `.Values` object into the template, we ought to quote these strings. We can do that by calling the `quote` function in the template directive: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Template functions follow the syntax `functionName arg1 arg2...`. In the snippet above, `quote .Values.favorite.drink` calls the `quote` function and passes it a single argument. Helm has over 60 available functions. Some of them are defined by the [Go template language](https://godoc.org/text/template) itself. Most of the others are part of the [Sprig template library](https://godoc.org/github.com/Masterminds/sprig). We'll see many of them as we progress through the examples. > While we talk about the "Helm template language" as if it is Helm-specific, it is actually a combination of the Go template language, some extra functions, and a variety of wrappers to expose certain objects to the templates. Many resources on Go templates may be helpful as you learn about templating. ## Pipelines One of the powerful features of the template language is its concept of _pipelines_. Drawing on a concept from UNIX, pipelines are a tool for chaining together a series of template commands to compactly express a series of transformations. In other words, pipelines are an efficient way of getting several things done in sequence. Let's rewrite the above example using a pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` In this example, instead of calling `quote ARGUMENT`, we inverted the order. We "sent" the argument to the function using a pipeline (`|`): `.Values.favorite.drink | quote`. Using pipelines, we can chain several functions together: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Inverting the order is a common practice in templates. You will see `.val | quote` more often than `quote .val`. Either practice is fine. When evaluated, that template will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Note that our original `pizza` has now been transformed to `"PIZZA"`. When pipelining arguments like this, the result of the first evaluation (`.Values.favorite.drink`) is sent as the _last argument to the function_. We can modify the drink example above to illustrate with a function that takes two arguments: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` The `repeat` function will echo the given string the given number of times, so we will get this for output: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Using the `default` function One function frequently used in templates is the `default` function: `default DEFAULT_VALUE GIVEN_VALUE`. This function allows you to specify a default value inside of the template, in case the value is omitted. Let's use it to modify the drink example above: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` If we run this as normal, we'll get our `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Now, we will remove the favorite drink setting from `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Now re-running `helm install --dry-run --debug ./mychart` will produce this YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` In an actual chart, all static default values should live in the values.yaml, and should not be repeated using the `default` command (otherwise they would be redundant). However, the `default` command is perfect for computed values, which can not be declared inside values.yaml. For example: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` In some places, an `if` conditional guard may be better suited than `default`. We'll see those in the next section. Template functions and pipelines are a powerful way to transform information and then insert it into your YAML. But sometimes it's necessary to add some template logic that is a little more sophisticated than just inserting a string. In the next section we will look at the control structures provided by the template language. ## Operators are functions Operators are implemented as functions that return a boolean value. To use `eq`, `ne`, `lt`, `gt`, `and`, `or`, `not` etcetera place the operator at the front of the statement followed by its parameters just as you would a function. To chain multiple operations together, separate individual functions by surrounding them with parentheses. ```yaml {{/* include the body of this if statement when the variable .Values.fooString exists and is set to "foo" */}} {{ if and .Values.fooString (eq .Values.fooString "foo") }} {{ ... }} {{ end }} {{/* include the body of this if statement when the variable .Values.anUnsetVariable is set or .values.aSetVariable is not set */}} {{ if or .Values.anUnsetVariable (not .Values.aSetVariable) }} {{ ... }} {{ end }} ``` Now we can turn from functions and pipelines to flow control with conditions, loops, and scope modifiers. ================================================ FILE: versioned_docs/version-2/chart_template_guide/getting_started.md ================================================ --- sidebar_position: 1 sidebar_label: "Getting Started" --- # Getting Started with a Chart Template In this section of the guide, we'll create a chart and then add a first template. The chart we created here will be used throughout the rest of the guide. To get going, let's take a brief look at a Helm chart. ## Charts As described in the [Charts Guide](../developing_charts/developing_charts.md), Helm charts are structured like this: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` The `templates/` directory is for template files. When Tiller evaluates a chart, it will send all of the files in the `templates/` directory through the template rendering engine. Tiller then collects the results of those templates and sends them on to Kubernetes. The `values.yaml` file is also important to templates. This file contains the _default values_ for a chart. These values may be overridden by users during `helm install` or `helm upgrade`. The `Chart.yaml` file contains a description of the chart. You can access it from within a template. The `charts/` directory _may_ contain other charts (which we call _subcharts_). Later in this guide we will see how those work when it comes to template rendering. ## A Starter Chart For this guide, we'll create a simple chart called `mychart`, and then we'll create some templates inside of the chart. ```console $ helm create mychart Creating mychart ``` From here on, we'll be working in the `mychart` directory. ### A Quick Glimpse of `mychart/templates/` If you take a look at the `mychart/templates/` directory, you'll notice a few files already there. - `NOTES.txt`: The "help text" for your chart. This will be displayed to your users when they run `helm install`. - `deployment.yaml`: A basic manifest for creating a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - `service.yaml`: A basic manifest for creating a [service endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment - `_helpers.tpl`: A place to put template helpers that you can re-use throughout the chart And what we're going to do is... _remove them all!_ That way we can work through our tutorial from scratch. We'll actually create our own `NOTES.txt` and `_helpers.tpl` as we go. ```console $ rm -rf mychart/templates/*.* ``` When you're writing production grade charts, having basic versions of these charts can be really useful. So in your day-to-day chart authoring, you probably won't want to remove them. ## A First Template The first template we are going to create will be a `ConfigMap`. In Kubernetes, a ConfigMap is simply a container for storing configuration data. Other things, like pods, can access the data in a ConfigMap. Because ConfigMaps are basic resources, they make a great starting point for us. Let's begin by creating a file called `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** Template names do not follow a rigid naming pattern. However, we recommend using the suffix `.yaml` for YAML files and `.tpl` for helpers. The YAML file above is a bare-bones ConfigMap, having the minimal necessary fields. In virtue of the fact that this file is in the `templates/` directory, it will be sent through the template engine. It is just fine to put a plain YAML file like this in the `templates/` directory. When Tiller reads this template, it will simply send it to Kubernetes as-is. With this simple template, we now have an installable chart. And we can install it like this: ```console $ helm install ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/ConfigMap NAME DATA AGE mychart-configmap 1 1m ``` In the output above, we can see that our ConfigMap was created. Using Helm, we can retrieve the release and see the actual template that was loaded. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` The `helm get manifest` command takes a release name (`full-coral`) and prints out all of the Kubernetes resources that were uploaded to the server. Each file begins with `---` to indicate the start of a YAML document, and then is followed by an automatically generated comment line that tells us what template file generated this YAML document. From there on, we can see that the YAML data is exactly what we put in our `configmap.yaml` file. Now we can delete our release: `helm delete full-coral`. ### Adding a Simple Template Call Hard-coding the `name:` into a resource is usually considered to be bad practice. Names should be unique to a release. So we might want to generate a name field by inserting the release name. **TIP:** The `name:` field is limited to 63 characters because of limitations to the DNS system. For that reason, release names are limited to 53 characters. Kubernetes 1.3 and earlier limited to only 24 characters (thus 14 character names). Let's alter `configmap.yaml` accordingly. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` The big change comes in the value of the `name:` field, which is now `{{ .Release.Name }}-configmap`. > A template directive is enclosed in `{{` and `}}` blocks. The template directive `{{ .Release.Name }}` injects the release name into the template. The values that are passed into a template can be thought of as _namespaced objects_, where a dot (`.`) separates each namespaced element. The leading dot before `Release` indicates that we start with the top-most namespace for this scope (we'll talk about scope in a bit). So we could read `.Release.Name` as "start at the top namespace, find the `Release` object, then look inside of it for an object called `Name`". The `Release` object is one of the built-in objects for Helm, and we'll cover it in more depth later. But for now, it is sufficient to say that this will display the release name that Tiller assigns to our release. Now when we install our resource, we'll immediately see the result of using this template directive: ```console $ helm install ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/ConfigMap NAME DATA AGE clunky-serval-configmap 1 1m ``` Note that in the `RESOURCES` section, the name we see there is `clunky-serval-configmap` instead of `mychart-configmap`. You can run `helm get manifest clunky-serval` to see the entire generated YAML. At this point, we've seen templates at their most basic: YAML files that have template directives embedded in `{{` and `}}`. In the next part, we'll take a deeper look into templates. But before moving on, there's one quick trick that can make building templates faster: When you want to test the template rendering, but not actually install anything, you can use `helm install ./mychart --debug --dry-run`. This will send the chart to the Tiller server, which will render the templates. But instead of installing the chart, it will return the rendered template to you so you can see the output: ```console $ helm install ./mychart --debug --dry-run SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart NAME: goodly-guppy TARGET NAMESPACE: default CHART: mychart 0.1.0 MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Using `--dry-run` will make it easier to test your code, but it won't ensure that Kubernetes itself will accept the templates you generate. It's best not to assume that your chart will install just because `--dry-run` works. In the next few sections, we'll take the basic chart we defined here and explore the Helm template language in detail. And we'll get started with built-in objects. ================================================ FILE: versioned_docs/version-2/chart_template_guide/helm_ignore_file.md ================================================ --- sidebar_position: 11 sidebar_label: "The .helmignore File" --- # The .helmignore file The `.helmignore` file is used to specify files you don't want to include in your helm chart. If this file exists, the `helm package` command will ignore all the files that match the pattern specified in the `.helmignore` file while packaging your application. This can help in avoiding unnecessary or sensitive files or directories from being added in your helm chart. The `.helmignore` file supports Unix shell glob matching, relative path matching, and negation (prefixed with !). Only one pattern per line is considered. Here is an example `.helmignore` file: ``` # comment .git */temp* */*/temp* temp? ``` **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm/issues) or send us a pull request. ================================================ FILE: versioned_docs/version-2/chart_template_guide/named_templates.md ================================================ --- sidebar_position: 7 sidebar_label: "Named Templates" --- # Named Templates It is time to move beyond one template, and begin to create others. In this section, we will see how to define _named templates_ in one file, and then use them elsewhere. A _named template_ (sometimes called a _partial_ or a _subtemplate_) is simply a template defined inside of a file, and given a name. We'll see two ways to create them, and a few different ways to use them. In the "Flow Control" section we introduced three actions for declaring and managing templates: `define`, `template`, and `block`. In this section, we'll cover those three actions, and also introduce a special-purpose `include` function that works similarly to the `template` action. An important detail to keep in mind when naming templates: **template names are global**. If you declare two templates with the same name, whichever one is loaded last will be the one used. Because templates in subcharts are compiled together with top-level templates, you should be careful to name your templates with _chart-specific names_. One popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. By using the specific chart name as a prefix we can avoid any conflicts that may arise due to two different charts that implement templates of the same name. ## Partials and `_` files So far, we've used one file, and that one file has contained a single template. But Helm's template language allows you to create named embedded templates, that can be accessed by name elsewhere. Before we get to the nuts-and-bolts of writing those templates, there is file naming convention that deserves mention: - Most files in `templates/` are treated as if they contain Kubernetes manifests - The `NOTES.txt` is one exception - But files whose name begins with an underscore (`_`) are assumed to _not_ have a manifest inside. These files are not rendered to Kubernetes object definitions, but are available everywhere within other chart templates for use. These files are used to store partials and helpers. In fact, when we first created `mychart`, we saw a file called `_helpers.tpl`. That file is the default location for template partials. ## Declaring and using templates with `define` and `template` The `define` action allows us to create a named template inside of a template file. Its syntax goes like this: ```yaml {{ define "MY.NAME" }} # body of template here {{ end }} ``` For example, we can define a template to encapsulate a Kubernetes block of labels: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Now we can embed this template inside of our existing ConfigMap, and then include it with the `template` action: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` When the template engine reads this file, it will store away the reference to `mychart.labels` until `template "mychart.labels"` is called. Then it will render that template inline. So the result will look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Conventionally, Helm charts put these templates inside of a partials file, usually `_helpers.tpl`. Let's move this function there: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` By convention, `define` functions should have a simple documentation block (`{{/* ... */}}`) describing what they do. Even though this definition is in `_helpers.tpl`, it can still be accessed in `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` As mentioned above, **template names are global**. As a result of this, if two templates are declared with the same name the last occurrence will be the one that is used. Since templates in subcharts are compiled together with top-level templates, it is best to name your templates with _chart specific names_. A popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. ## Setting the scope of a template In the template we defined above, we did not use any objects. We just used functions. Let's modify our defined template to include the chart name and chart version: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` If we render this, the result will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2016-11-02 chart: version: ``` What happened to the name and version? They weren't in the scope for our defined template. When a named template (created with `define`) is rendered, it will receive the scope passed in by the `template` call. In our example, we included the template like this: ```gotpl {{- template "mychart.labels" }} ``` No scope was passed in, so within the template we cannot access anything in `.`. This is easy enough to fix, though. We simply pass a scope to the template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Note that we pass `.` at the end of the `template` call. We could just as easily pass `.Values` or `.Values.favorite` or whatever scope we want. But what we want is the top-level scope. Now when we execute this template with `helm install --dry-run --debug ./mychart`, we get this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2016-11-02 chart: mychart version: 0.1.0 ``` Now `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}` resolves to `0.1.0`. ## The `include` function Say we've defined a simple template that looks like this: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}+{{ .Release.Time.Seconds }}" {{- end -}} ``` Now say I want to insert this both into the `labels:` section of my template, and also the `data:` section: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" .}} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` The output will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0+1478129847" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0+1478129847" ``` Note that the indentation on `app_version` is wrong in both places. Why? Because the template that is substituted in has the text aligned to the right. Because `template` is an action, and not a function, there is no way to pass the output of a `template` call to other functions; the data is simply inserted inline. To work around this case, Helm provides an alternative to `template` that will import the contents of a template into the present pipeline where it can be passed along to other functions in the pipeline. Here's the example above, corrected to use `nindent` to indent the `mychart_app` template correctly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{- include "mychart.app" . | nindent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{- include "mychart.app" . | nindent 2 }} ``` Now the produced YAML is correctly indented for each section: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0+1478129987" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0+1478129987" ``` > It is considered preferable to use `include` over `template` in Helm templates simply so that the output formatting can be handled better for YAML documents. Sometimes we want to import content, but not as templates. That is, we want to import files verbatim. We can achieve this by accessing files through the `.Files` object described in the next section. ================================================ FILE: versioned_docs/version-2/chart_template_guide/notes_files.md ================================================ --- sidebar_position: 9 sidebar_label: "Creating a NOTES.txt File" --- # Creating a NOTES.txt File In this section we are going to look at Helm's tool for providing instructions to your chart users. At the end of a `helm install` or `helm upgrade`, Helm can print out a block of helpful information for users. This information is highly customizable using templates. To add installation notes to your chart, simply create a `templates/NOTES.txt` file. This file is plain text, but it is processed like as a template, and has all the normal template functions and objects available. Let's create a simple `NOTES.txt` file: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get {{ .Release.Name }} ``` Now if we run `helm install ./mychart` we will see this message at the bottom: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get rude-cardinal ``` Using `NOTES.txt` this way is a great way to give your users detailed information about how to use their newly installed chart. Creating a `NOTES.txt` file is strongly recommended, though it is not required. ================================================ FILE: versioned_docs/version-2/chart_template_guide/subcharts_and_globals.md ================================================ --- sidebar_position: 10 sidebar_label: "Subcharts and Global Values" --- # Subcharts and Global Values To this point we have been working only with one chart. But charts can have dependencies, called _subcharts_, that also have their own values and templates. In this section we will create a subchart and see the different ways we can access values from within templates. Before we dive into the code, there are a few important details to learn about subcharts. 1. A subchart is considered "stand-alone", which means a subchart can never explicitly depend on its parent chart. 2. For that reason, a subchart cannot access the values of its parent. 3. A parent chart can override values for subcharts. 4. Helm has a concept of _global values_ that can be accessed by all charts. As we walk through the examples in this section, many of these concepts will become clearer. ## Creating a Subchart For these exercises, we'll start with the `mychart/` chart we created at the beginning of this guide, and we'll add a new chart inside of it. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/*.* ``` Notice that just as before, we deleted all of the base templates so that we can start from scratch. In this guide, we are focused on how templates work, not on managing dependencies. But the [Charts Guide](../developing_charts/developing_charts.md) has more information on how subcharts work. ## Adding Values and a Template to the Subchart Next, let's create a simple template and values file for our `mysubchart` chart. There should already be a `values.yaml` in `mychart/charts/mysubchart`. We'll set it up like this: ```yaml dessert: cake ``` Next, we'll create a new ConfigMap template in `mychart/charts/mysubchart/templates/configmap.yaml`: ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Because every subchart is a _stand-alone chart_, we can test `mysubchart` on its own: ```console $ helm install --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Overriding Values of a Child Chart Our original chart, `mychart` is now the _parent_ chart of `mysubchart`. This relationship is based entirely on the fact that `mysubchart` is within `mychart/charts`. Because `mychart` is a parent, we can specify configuration in `mychart` and have that configuration pushed into `mysubchart`. For example, we can modify `mychart/values.yaml` like this: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Note the last two lines. Any directives inside of the `mysubchart` section will be sent to the `mysubchart` chart. So if we run `helm install --dry-run --debug mychart`, one of the things we will see is the `mysubchart` ConfigMap: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` The value at the top level has now overridden the value of the subchart. There's an important detail to notice here. We didn't change the template of `mychart/charts/mysubchart/templates/configmap.yaml` to point to `.Values.mysubchart.dessert`. From that template's perspective, the value is still located at `.Values.dessert`. As the template engine passes values along, it sets the scope. So for the `mysubchart` templates, only values specifically for `mysubchart` will be available in `.Values`. Sometimes, though, you do want certain values to be available to all of the templates. This is accomplished using global chart values. ## Global Chart Values Global values are values that can be accessed from any chart or subchart by exactly the same name. Globals require explicit declaration. You can't use an existing non-global as if it were a global. The Values data type has a reserved section called `Values.global` where global values can be set. Let's set one in our `mychart/values.yaml` file. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Because of the way globals work, both `mychart/templates/configmap.yaml` and `mychart/charts/mysubchart/templates/configmap.yaml` should be able to access that value as `{{ .Values.global.salad}}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Now if we run a dry run install, we'll see the same value in both outputs: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Globals are useful for passing information like this, though it does take some planning to make sure the right templates are configured to use globals. ## Sharing Templates with Subcharts Parent charts and subcharts can share templates. Any defined block in any chart is available to other charts. For example, we can define a simple template like this: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Recall how the labels on templates are _globally shared_. Thus, the `labels` chart can be included from any other chart. While chart developers have a choice between `include` and `template`, one advantage of using `include` is that `include` can dynamically reference templates: ```yaml {{ include $mytemplate }} ``` The above will dereference `$mytemplate`. The `template` function, in contrast, will only accept a string literal. ## Avoid Using Blocks The Go template language provides a `block` keyword that allows developers to provide a default implementation which is overridden later. In Helm charts, blocks are not the best tool for overriding because if multiple implementations of the same block are provided, the one selected is unpredictable. The suggestion is to instead use `include`. ================================================ FILE: versioned_docs/version-2/chart_template_guide/values_files.md ================================================ --- sidebar_position: 3 sidebar_label: "Values Files" --- # Values Files In the previous section we looked at the built-in objects that Helm templates offer. One of these built-in objects is `Values`. This object provides access to values passed into the chart. Its contents come from four sources: - The `values.yaml` file in the chart - If this is a subchart, the `values.yaml` file of a parent chart - A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`) - Individual parameters passed with `--set` (such as `helm install --set foo=bar ./mychart`) The list above is in order of specificity: `values.yaml` is the default, which can be overridden by a parent chart's `values.yaml`, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by `--set` parameters. Values files are plain YAML files. Let's edit `mychart/values.yaml` and then edit our ConfigMap template. Removing the defaults in `values.yaml`, we'll set just one parameter: ```yaml favoriteDrink: coffee ``` Now we can use this inside of a template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Notice on the last line we access `favoriteDrink` as an attribute of `Values`: `{{ .Values.favoriteDrink }}`. Let's see how this renders. ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart NAME: geared-marsupi TARGET NAMESPACE: default CHART: mychart 0.1.0 MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Because `favoriteDrink` is set in the default `values.yaml` file to `coffee`, that's the value displayed in the template. We can easily override that by adding a `--set` flag in our call to `helm install`: ```console helm install --dry-run --debug --set favoriteDrink=slurm ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart NAME: solid-vulture TARGET NAMESPACE: default CHART: mychart 0.1.0 MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Since `--set` has a higher precedence than the default `values.yaml` file, our template generates `drink: slurm`. Values files can contain more structured content, too. For example, we could create a `favorite` section in our `values.yaml` file, and then add several keys there: ```yaml favorite: drink: coffee food: pizza ``` Now we would have to modify the template slightly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` While structuring data this way is possible, the recommendation is that you keep your values trees shallow, favoring flatness. When we look at assigning values to subcharts, we'll see how values are named using a tree structure. ## Deleting a default key If you need to delete a key from the default values, you may override the value of the key to be `null`, in which case Helm will remove the key from the overridden values merge. For example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` If you try to override the livenessProbe handler to `exec` instead of `httpGet` using `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will coalesce the default and overridden keys together, resulting in the following YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` However, Kubernetes would then fail because you can not declare more than one livenessProbe handler. To overcome this, you may instruct Helm to delete the `livenessProbe.httpGet` by setting it to null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` At this point, we've seen several built-in objects, and used them to inject information into a template. Now we will take a look at another aspect of the template engine: functions and pipelines. ================================================ FILE: versioned_docs/version-2/chart_template_guide/variables.md ================================================ --- sidebar_position: 6 sidebar_label: "Variables" --- # Variables With functions, pipelines, objects, and control structures under our belts, we can turn to one of the more basic ideas in many programming languages: variables. In templates, they are less frequently used. But we will see how to use them to simplify code, and to make better use of `with` and `range`. In an earlier example, we saw that this code will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` is not inside of the scope that's restricted in the `with` block. One way to work around scoping issues is to assign objects to variables that can be accessed without respect to the present scope. In Helm templates, a variable is a named reference to another object. It follows the form `$name`. Variables are assigned with a special assignment operator: `:=`. We can rewrite the above to use a variable for `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Notice that before we start the `with` block, we assign `$relname := .Release.Name`. Now inside of the `with` block, the `$relname` variable still points to the release name. Running that will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Variables are particularly useful in `range` loops. They can be used on list-like objects to capture both the index and the value: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Note that `range` comes first, then the variables, then the assignment operator, then the list. This will assign the integer index (starting from zero) to `$index` and the value to `$topping`. Running it will produce: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` For data structures that have both a key and a value, we can use `range` to get both. For example, we can loop through `.Values.favorite` like this: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end}} ``` Now on the first iteration, `$key` will be `drink` and `$val` will be `coffee`, and on the second, `$key` will be `food` and `$val` will be `pizza`. Running the above will generate this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Variables are normally not "global". They are scoped to the block in which they are declared. Earlier, we assigned `$relname` in the top level of the template. That variable will be in scope for the entire template. But in our last example, `$key` and `$val` will only be in scope inside of the `{{range...}}{{end}}` block. However, there is one variable that is always global - `$` - this variable will always point to the root context. This can be very useful when you are looping in a range and need to know the chart's release name. An example illustrating this: ```yaml {{- range .Values.tlsSecrets }} apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} --- {{- end }} ``` So far we have looked at just one template declared in just one file. But one of the powerful features of the Helm template language is its ability to declare multiple templates and use them together. We'll turn to that in the next section. ================================================ FILE: versioned_docs/version-2/chart_template_guide/wrapping_up.md ================================================ --- sidebar_position: 13 sidebar_label: "Next Steps" --- # Wrapping Up This guide is intended to give you, the chart developer, a strong understanding of how to use Helm's template language. The guide focuses on the technical aspects of template development. But there are many things this guide has not covered when it comes to the practical day-to-day development of charts. Here are some useful pointers to other documentation that will help you as you create new charts: - The [Helm Charts project](https://github.com/helm/charts) is an indispensable source of charts. That project is also sets the standard for best practices in chart development. - The Kubernetes [Documentation](https://kubernetes.io/docs/home/) provides detailed examples of the various resource kinds that you can use, from ConfigMaps and Secrets to DaemonSets and Deployments. - The Helm [Charts Guide](../developing_charts/developing_charts.md) explains the workflow of using charts. - The Helm [Chart Hooks Guide](../developing_charts/charts_hooks.md) explains how to create lifecycle hooks. - The Helm [Charts Tips and Tricks](../developing_charts/charts_tips_and_tricks.md) article provides some useful tips for writing charts. - The [Sprig documentation](https://github.com/Masterminds/sprig) documents more than sixty of the template functions. - The [Go template docs](https://godoc.org/text/template) explain the template syntax in detail. - The [Schelm tool](https://github.com/databus23/schelm) is a nice helper utility for debugging charts. Sometimes it's easier to ask a few questions and get answers from experienced developers. The best place to do this is in the [Kubernetes Slack](https://kubernetes.slack.com) Helm channels: - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Finally, if you find errors or omissions in this document, want to suggest some new content, or would like to contribute, visit [The Helm Project](https://github.com/helm/helm). ================================================ FILE: versioned_docs/version-2/chart_template_guide/yaml_techniques.md ================================================ --- sidebar_position: 14 sidebar_label: "Appendix: YAML Techniques" --- # YAML Techniques Most of this guide has been focused on writing the template language. Here, we'll look at the YAML format. YAML has some useful features that we, as template authors, can use to make our templates less error prone and easier to read. ## Scalars and Collections According to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two types of collections, and many scalar types. The two types of collections are maps and sequences: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Scalar values are individual values (as opposed to collections) ### Scalar Types in YAML In Helm's dialect of YAML, the scalar data type of a value is determined by a complex set of rules, including the Kubernetes schema for resource definitions. But when inferring types, the following rules tend to hold true. If an integer or float is an unquoted bare word, it is typically treated as a numeric type: ```yaml count: 1 size: 2.34 ``` But if they are quoted, they are treated as strings: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` The same is true of booleans: ```yaml isGood: true # bool answer: "true" # string ``` The word for an empty value is `null` (not `nil`). Note that `port: "80"` is valid YAML, and will pass through both the template engine and the YAML parser, but will fail if Kubernetes expects `port` to be an integer. In some cases, you can force a particular type inference using YAML node tags: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` In the above, `!!str` tells the parser that `age` is a string, even if it looks like an int. And `port` is treated as an int, even though it is quoted. ## Strings in YAML Much of the data that we place in YAML documents are strings. YAML has more than one way to represent a string. This section explains the ways and demonstrates how to use some of them. There are three "inline" ways of declaring a string: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` All inline styles must be on one line. - Bare words are unquoted, and are not escaped. For this reason, you have to be careful what characters you use. - Double-quoted strings can have specific characters escaped with `\`. For example `"\"Hello\", she said"`. You can escape line breaks with `\n`. - Single-quoted strings are "literal" strings, and do not use the `\` to escape characters. The only escape sequence is `''`, which is decoded as a single `'`. In addition to the one-line strings, you can declare multi-line strings: ```yaml coffee: | Latte Cappuccino Espresso ``` The above will treat the value of `coffee` as a single string equivalent to `Latte\nCappuccino\nEspresso\n`. Note that the first line after the `|` must be correctly indented. So we could break the example above by doing this: ```yaml coffee: | Latte Cappuccino Espresso ``` Because `Latte` is incorrectly indented, we'd get an error like this: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` In templates, it is sometimes safer to put a fake "first line" of content in a multi-line document just for protection from the above error: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Note that whatever that first line is, it will be preserved in the output of the string. So if you are, for example, using this technique to inject a file's contents into a ConfigMap, the comment should be of the type expected by whatever is reading that entry. ### Controlling Spaces in Multi-line Strings In the example above, we used `|` to indicate a multi-line string. But notice that the content of our string was followed with a trailing `\n`. If we want the YAML processor to strip off the trailing newline, we can add a `-` after the `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Now the `coffee` value will be: `Latte\nCappuccino\nEspresso` (with no trailing `\n`). Other times, we might want all trailing whitespace to be preserved. We can do this with the `|+` notation: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Now the value of `coffee` will be `Latte\nCappuccino\nEspresso\n\n\n`. Indentation inside of a text block is preserved, and results in the preservation of line breaks, too: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` In the above case, `coffee` will be `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indenting and Templates When writing templates, you may find yourself wanting to inject the contents of a file into the template. As we saw in previous chapters, there are two ways of doing this: - Use `{{ .Files.Get "FILENAME" }}` to get the contents of a file in the chart. - Use `{{ include "TEMPLATE" . }}` to render a template and then place its contents into the chart. When inserting files into YAML, it's good to understand the multi-line rules above. Often times, the easiest way to insert a static file is to do something like this: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Note how we do the indentation above: `indent 2` tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that template line. That's because if we did, the file content of the first line would be indented twice. ### Folded Multi-line Strings Sometimes you want to represent a string in your YAML with multiple lines, but want it to be treated as one long line when it is interpreted. This is called "folding". To declare a folded block, use `>` instead of `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` The value of `coffee` above will be `Latte Cappuccino Espresso\n`. Note that all but the last line feed will be converted to spaces. You can combine the whitespace controls with the folded text marker, so `>-` will replace or trim all newlines. Note that in the folded syntax, indenting text will cause lines to be preserved. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` The above will produce `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Note that both the spacing and the newlines are still there. ## Embedding Multiple Documents in One File It is possible to place more than one YAML documents into a single file. This is done by prefixing a new document with `---` and ending the document with `...` ```yaml --- document:1 ... --- document: 2 ... ``` In many cases, either the `---` or the `...` may be omitted. Some files in Helm cannot contain more than one doc. If, for example, more than one document is provided inside of a `values.yaml` file, only the first will be used. Template files, however, may have more than one document. When this happens, the file (and all of its documents) is treated as one object during template rendering. But then the resulting YAML is split into multiple documents before it is fed to Kubernetes. We recommend only using multiple documents per file when it is absolutely necessary. Having multiple documents in a file can be difficult to debug. ## YAML is a Superset of JSON Because YAML is a superset of JSON, any valid JSON document _should_ be valid YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` The above is another way of representing this: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` And the two can be mixed (with care): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` All three of these should parse into the same internal representation. While this means that files such as `values.yaml` may contain JSON data, Helm does not treat the file extension `.json` as a valid suffix. ## YAML Anchors The YAML spec provides a way to store a reference to a value, and later refer to that value by reference. YAML refers to this as "anchoring": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappucino" coffees: - Latte - *favoriteCoffee - Espresso ``` In the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that reference is used as `*favoriteCoffee`. So `coffees` becomes `Latte, Cappuccino, Espresso`. While there are a few cases where anchors are useful, there is one aspect of them that can cause subtle bugs: The first time the YAML is consumed, the reference is expanded and then discarded. So if we were to decode and then re-encode the example above, the resulting YAML would be: ```yaml coffee: yes, please favorite: Cappucino coffees: - Latte - Cappucino - Espresso ``` Because Helm and Kubernetes often read, modify, and then rewrite YAML files, the anchors will be lost. ================================================ FILE: versioned_docs/version-2/developers.md ================================================ --- sidebar_position: 10 sidebar_label: "Developer Guide" --- # Developers Guide This guide explains how to set up your environment for developing on Helm and Tiller. ## Prerequisites - The latest version of Go - The latest version of Glide - A Kubernetes cluster w/ kubectl (optional) - The gRPC toolchain - Git ## Building Helm/Tiller We use Make to build our programs. The simplest way to get started is: ```console $ make bootstrap build ``` NOTE: This will fail if not running from the path `$GOPATH/src/k8s.io/helm`. The directory `k8s.io` should not be a symlink or `build` will not find the relevant packages. This will build both Helm and Tiller. `make bootstrap` will attempt to install certain tools if they are missing. To run all the tests (without running the tests for `vendor/`), run `make test`. To run all tests in a containerized environment, run `make docker-test`. To run Helm and Tiller locally, you can run `bin/helm` or `bin/tiller`. - Helm and Tiller are known to run on macOS and most Linux distributions, including Alpine. - Tiller must have access to a Kubernetes cluster. It learns about the cluster by examining the Kube config files that `kubectl` uses. ### Man pages Man pages and Markdown documentation are already pre-built in `docs/`. You may regenerate documentation using `make docs`. To expose the Helm man pages to your `man` client, you can put the files in your `$MANPATH`: ``` $ export MANPATH=$GOPATH/src/k8s.io/helm/docs/man:$MANPATH $ man helm ``` ## gRPC and Protobuf Helm and Tiller communicate using gRPC. To get started with gRPC, you will need to... - Install `protoc` for compiling protobuf files. Releases are [here](https://github.com/google/protobuf/releases) - Run Helm's `make bootstrap` to generate the `protoc-gen-go` plugin and place it in `bin/`. Note that you need to be on protobuf 3.2.0 (`protoc --version`). The version of `protoc-gen-go` is tied to the version of gRPC used in Kubernetes. So the plugin is maintained locally. While the gRPC and ProtoBuf specs remain silent on indentation, we require that the indentation style matches the Go format specification. Namely, protocol buffers should use tab-based indentation and rpc declarations should follow the style of Go function declarations. ### The Helm API (HAPI) We use gRPC as an API layer. See `pkg/proto/hapi` for the generated Go code, and `_proto` for the protocol buffer definitions. To regenerate the Go files from the protobuf source, `make protoc`. ## Docker Images To build Docker images, use `make docker-build`. Pre-build images are already available in the official Kubernetes Helm GCR registry. ## Running a Local Cluster For development, we highly recommend using the [Kubernetes Minikube](https://github.com/kubernetes/minikube) developer-oriented distribution. Once this is installed, you can use `helm init` to install into the cluster. Note that version of tiller you're using for development may not be available in Google Cloud Container Registry. If you're getting image pull errors, you can override the version of Tiller. Example: ```console helm init --tiller-image=ghcr.io/helm/tiller:2.17.0 ``` Or use the latest version: ```console helm init --canary-image ``` For developing on Tiller, it is sometimes more expedient to run Tiller locally instead of packaging it into an image and running it in-cluster. You can do this by telling the Helm client to use a local instance. ```console $ make build $ bin/tiller ``` And to configure the Helm client, use the `--host` flag or export the `HELM_HOST` environment variable: ```console $ export HELM_HOST=localhost:44134 $ helm install foo ``` (Note that you do not need to use `helm init` when you are running Tiller directly) Tiller should run on any >= 1.3 Kubernetes cluster. ## Contribution Guidelines We welcome contributions. This project has set up some guidelines in order to ensure that (a) code quality remains high, (b) the project remains consistent, and (c) contributions follow the open source legal requirements. Our intent is not to burden contributors, but to build elegant and high-quality open source code so that our users will benefit. Make sure you have read and understood the main CONTRIBUTING guide: https://github.com/helm/helm/blob/master/CONTRIBUTING.md ### Structure of the Code The code for the Helm project is organized as follows: - The individual programs are located in `cmd/`. Code inside of `cmd/` is not designed for library re-use. - Shared libraries are stored in `pkg/`. - The raw ProtoBuf files are stored in `_proto/hapi` (where `hapi` stands for the Helm Application Programming Interface). - The Go files generated from the `proto` definitions are stored in `pkg/proto`. - The `scripts/` directory contains a number of utility scripts. Most of these are used by the CI/CD pipeline. - The `rootfs/` folder is used for Docker-specific files. - The `docs/` folder is used for documentation and examples. Go dependencies are managed with [Glide](https://github.com/Masterminds/glide) and stored in the `vendor/` directory. ### Git Conventions We use Git for our version control system. The `master` branch is the home of the current development candidate. Releases are tagged. We accept changes to the code via GitHub Pull Requests (PRs). One workflow for doing this is as follows: 1. Go to your `$GOPATH/src/k8s.io` directory and `git clone` the `github.com/helm/helm` repository. 2. Fork that repository into your GitHub account 3. Add your repository as a remote for `$GOPATH/src/k8s.io/helm` 4. Create a new working branch (`git checkout -b feat/my-feature`) and do your work on that branch. 5. When you are ready for us to review, sign your commit, push your branch to GitHub, and then open a new pull request with us. For Git commit messages, we follow the [Semantic Commit Messages](https://karma-runner.github.io/0.13/dev/git-commit-msg.html): ``` fix(helm): add --foo flag to 'helm install' When 'helm install --foo bar' is run, this will print "foo" in the output regardless of the outcome of the installation. Closes #1234 ``` Common commit types: - fix: Fix a bug or error - feat: Add a new feature - docs: Change documentation - test: Improve testing - ref: refactor existing code Common scopes: - helm: The Helm CLI - tiller: The Tiller server - proto: Protobuf definitions - pkg/lint: The lint package. Follow a similar convention for any package - `*`: two or more scopes Read more: - The [Deis Guidelines](https://github.com/deis/workflow/blob/master/src/contributing/submitting-a-pull-request.md) were the inspiration for this section. - Karma Runner [defines](https://karma-runner.github.io/0.13/dev/git-commit-msg.html) the semantic commit message idea. ### Go Conventions We follow the Go coding style standards very closely. Typically, running `go fmt` will make your code beautiful for you. We also typically follow the conventions recommended by `go lint` and `gometalinter`. Run `make test-style` to test the style conformance. If you do not want to install all the linters from `gometalinter` into your global Go environment, you can run `make docker-test-style` which will run the same tests, but isolated within a docker container. Read more: - Effective Go [introduces formatting](https://golang.org/doc/effective_go.html#formatting). - The Go Wiki has a great article on [formatting](https://github.com/golang/go/wiki/CodeReviewComments). ### Protobuf Conventions Because this project is largely Go code, we format our Protobuf files as closely to Go as possible. There are currently no real formatting rules or guidelines for Protobuf, but as they emerge, we may opt to follow those instead. Standards: - Tabs for indentation, not spaces. - Spacing rules follow Go conventions (curly braces at line end, spaces around operators). Conventions: - Files should specify their package with `option go_package = "...";` - Comments should translate into good Go code comments (since `protoc` copies comments into the destination source code file). - RPC functions are defined in the same file as their request/response messages. - Deprecated RPCs, messages, and fields are marked deprecated in the comments (`// UpdateFoo DEPRECATED updates a foo.`). ================================================ FILE: versioned_docs/version-2/developing_charts/chart_repository.md ================================================ --- sidebar_position: 3 sidebar_label: "Charts Repository Guide" --- # The Chart Repository Guide This section explains how to create and work with Helm chart repositories. At a high level, a chart repository is a location where packaged charts can be stored and shared. The official chart repository is maintained by the [Helm Charts](https://github.com/helm/charts), and we welcome participation. But Helm also makes it easy to create and run your own chart repository. This guide explains how to do so. ## Prerequisites * Go through the [Quickstart](../using_helm/using_helm.md) Guide * Read through the [Charts](developing_charts.md) document ## Create a chart repository A _chart repository_ is an HTTP server that houses an `index.yaml` file and optionally some packaged charts. When you're ready to share your charts, the preferred way to do so is by uploading them to a chart repository. **Note:** For Helm 2.0.0, chart repositories do not have any intrinsic authentication. There is an [issue tracking progress](https://github.com/helm/helm/issues/1038) in GitHub. Because a chart repository can be any HTTP server that can serve YAML and tar files and can answer GET requests, you have a plethora of options when it comes down to hosting your own chart repository. For example, you can use a Google Cloud Storage (GCS) bucket, Amazon S3 bucket, Github Pages, or even create your own web server. ### The chart repository structure A chart repository consists of packaged charts and a special file called `index.yaml` which contains an index of all of the charts in the repository. Frequently, the charts that `index.yaml` describes are also hosted on the same server, as are the [provenance files](provenance.md). For example, the layout of the repository `https://example.com/charts` might look like this: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` In this case, the index file would contain information about one chart, the Alpine chart, and provide the download URL `https://example.com/charts/alpine-0.1.2.tgz` for that chart. It is not required that a chart package be located on the same server as the `index.yaml` file. However, doing so is often the easiest. ### The index file The index file is a yaml file called `index.yaml`. It contains some metadata about the package, including the contents of a chart's `Chart.yaml` file. A valid chart repository must have an index file. The index file contains information about each chart in the chart repository. The `helm repo index` command will generate an index file based on a given local directory that contains packaged charts. This is an example of an index file: ``` apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://k8s.io/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://k8s.io/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://k8s.io/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` A generated index and packages can be served from a basic webserver. You can test things out locally with the `helm serve` command, which starts a local server. ```console $ helm serve --repo-path ./charts Regenerating index. This may take a moment. Now serving you on 127.0.0.1:8879 ``` The above starts a local webserver, serving the charts it finds in `./charts`. The serve command will automatically generate an `index.yaml` file for you during startup. ## Hosting Chart Repositories This part shows several ways to serve a chart repository. ### ChartMuseum The Helm project provides an open-source Helm repository server called [ChartMuseum](https://chartmuseum.com) that you can host yourself. ChartMuseum supports multiple cloud storage backends. Configure it to point to the directory or bucket containing your chart packages, and the index.yaml file will be generated dynamically. It can be deployed easily as a [Helm chart](https://github.com/helm/charts/tree/master/stable/chartmuseum): ``` helm install stable/chartmuseum ``` and also as a [Docker image](https://hub.docker.com/r/chartmuseum/chartmuseum/tags): ``` docker run --rm -it \ -p 8080:8080 \ -v $(pwd)/charts:/charts \ -e DEBUG=true \ -e STORAGE=local \ -e STORAGE_LOCAL_ROOTDIR=/charts \ chartmuseum/chartmuseum ``` You can then add the repo to your local repository list: ``` helm repo add chartmuseum http://localhost:8080 ``` ChartMuseum provides other features, such as an API for chart uploads. Please see the [README](https://github.com/helm/chartmuseum) for more info. ### Google Cloud Storage The first step is to **create your GCS bucket**. We'll call ours `fantastic-charts`. ![Create a GCS Bucket](/img/helm2/create-a-bucket.png) Next, make your bucket public by **editing the bucket permissions**. ![Edit Permissions](/img/helm2/edit-permissions.png) Insert this line item to **make your bucket public**: ![Make Bucket Public](/img/helm2/make-bucket-public.png) Congratulations, now you have an empty GCS bucket ready to serve charts! You may upload your chart repository using the Google Cloud Storage command line tool, or using the GCS web UI. This is the technique the official Kubernetes Charts repository hosts its charts, so you may want to take a [peek at that project](https://github.com/helm/charts) if you get stuck. **Note:** A public GCS bucket can be accessed via simple HTTPS at this address `https://bucket-name.storage.googleapis.com/`. ### JFrog Artifactory You can also set up chart repositories using JFrog Artifactory. Read more about chart repositories with JFrog Artifactory [here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### ProGet Helm chart repositories are supported by ProGet. For more information, visit the [Helm repository documentation](https://inedo.com/support/documentation/proget/feeds/helm) on the Inedo website. ### Sonatype Nexus Repository Manager OSS Edition Helm repositories are available in Nexus Repository Manager OSS Edition. See [Helm Repositories](https://help.sonatype.com/repomanager3/formats/helm-repositories) for details! ### Github Pages example In a similar way you can create charts repository using GitHub Pages. GitHub allows you to serve static web pages in two different ways: - By configuring a project to serve the contents of its `docs/` directory - By configuring a project to serve a particular branch We'll take the second approach, though the first is just as easy. The first step will be to **create your gh-pages branch**. You can do that locally as. ```console $ git checkout -b gh-pages ``` Or via web browser using **Branch** button on your Github repository: ![Create Github Pages branch](/img/helm2/create-a-gh-page-button.png) Next, you'll want to make sure your **gh-pages branch** is set as Github Pages, click on your repo **Settings** and scroll down to **Github pages** section and set as per below: ![Create Github Pages branch](/img/helm2/set-a-gh-page.png) By default **Source** usually gets set to **gh-pages branch**. If this is not set by default, then select it. You can use a **custom domain** there if you wish so. And check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when charts are served. In such setup you can use **master branch** to store your charts code, and **gh-pages branch** as charts repository, e.g.: `https://USERNAME.github.io/REPONAME`. The demonstration [TS Charts](https://github.com/technosophos/tscharts) repository is accessible at `https://technosophos.github.io/tscharts/`. ### Ordinary web servers To configure an ordinary web server to serve Helm charts, you merely need to do the following: - Put your index and charts in a directory that the server can serve - Make sure the `index.yaml` file can be accessed with no authentication requirement - Make sure `yaml` files are served with the correct content type (`text/yaml` or `text/x-yaml`) For example, if you want to serve your charts out of `$WEBROOT/charts`, make sure there is a `charts/` directory in your web root, and put the index file and charts inside of that folder. ## Managing Chart Repositories Now that you have a chart repository, the last part of this guide explains how to maintain charts in that repository. ### Store charts in your chart repository Now that you have a chart repository, let's upload a chart and an index file to the repository. Charts in a chart repository must be packaged (`helm package chart-name/`) and versioned correctly (following [SemVer 2](https://semver.org/) guidelines). These next steps compose an example workflow, but you are welcome to use whatever workflow you fancy for storing and updating charts in your chart repository. Once you have a packaged chart ready, create a new directory, and move your packaged chart to that directory. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` The last command takes the path of the local directory that you just created and the URL of your remote chart repository and composes an `index.yaml` file inside the given directory path. Now you can upload the chart and the index file to your chart repository using a sync tool or manually. If you're using Google Cloud Storage, check out this [example workflow](chart_repository_sync_example.md) using the gsutil client. For GitHub, you can simply put the charts in the appropriate destination branch. ### Add new charts to an existing repository Each time you want to add a new chart to your repository, you must regenerate the index. The `helm repo index` command will completely rebuild the `index.yaml` file from scratch, including only the charts that it finds locally. However, you can use the `--merge` flag to incrementally add new charts to an existing `index.yaml` file (a great option when working with a remote repository like GCS). Run `helm repo index --help` to learn more, Make sure that you upload both the revised `index.yaml` file and the chart. And if you generated a provenance file, upload that too. ### Share your charts with others When you're ready to share your charts, simply let someone know what the URL of your repository is. From there, they will add the repository to their helm client via the `helm repo add [NAME] [URL]` command with any name they would like to use to reference the repository. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` If the charts are backed by HTTP basic authentication, you can also supply the username and password here: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Note:** A repository will not be added if it does not contain a valid `index.yaml`. After that, your users will be able to search through your charts. After you've updated the repository, they can use the `helm repo update` command to get the latest chart information. *Under the hood, the `helm repo add` and `helm repo update` commands are fetching the index.yaml file and storing them in the `$HELM_HOME/repository/cache/` directory. This is where the `helm search` function finds information about charts.* ================================================ FILE: versioned_docs/version-2/developing_charts/chart_repository_faq.md ================================================ --- sidebar_position: 7 sidebar_label: "Chart Repository FAQ" --- # Chart Repositories: Frequently Asked Questions This section tracks some of the more frequently encountered issues with using chart repositories. **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm/issues) or send us a pull request. ## Fetching **Q: Why do I get a `unsupported protocol scheme ""` error when trying to fetch a chart from my custom repo?** A: (Helm < 2.5.0) This is likely caused by you creating your chart repo index without specifying the `--url` flag. Try recreating your `index.yaml` file with a command like `helm repo index --url http://my-repo/charts .`, and then re-uploading it to your custom charts repo. This behavior was changed in Helm 2.5.0. ================================================ FILE: versioned_docs/version-2/developing_charts/chart_repository_sync_example.md ================================================ --- sidebar_position: 4 sidebar_label: "Syncing Your Chart Repo" --- # Syncing Your Chart Repository *Note: This example is specifically for a Google Cloud Storage (GCS) bucket which serves a chart repository.* ## Prerequisites * Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We rely heavily on the gsutil rsync functionality* * Be sure to have access to the Helm binary * _Optional: We recommend you set [object versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) on your GCS bucket in case you accidentally delete something._ ## Set up a local chart repository directory Create a local directory like we did in [the chart repository guide](chart_repository.md), and place your packaged charts in that directory. For example: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Generate an updated index.yaml Use Helm to generate an updated index.yaml file by passing in the directory path and the url of the remote repository to the `helm repo index` command like this: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` This will generate an updated index.yaml file and place in the `fantastic-charts/` directory. ## Sync your local and remote chart repositories Upload the contents of the directory to your GCS bucket by running `scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket name. For example: ```console $ pwd /Users/funuser/go/src/github.com/helm/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Updating your chart repository You'll want to keep a local copy of the contents of your chart repository or use `gsutil rsync` to copy the contents of your remote chart repository to a local directory. For example: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Helpful Links: * Documentation on [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [The Chart Repository Guide](chart_repository.md) * Documentation on [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage ================================================ FILE: versioned_docs/version-2/developing_charts/chart_tests.md ================================================ --- sidebar_position: 6 sidebar_label: "Chart Tests" --- # Chart Tests A chart contains a number of Kubernetes resources and components that work together. As a chart author, you may want to write some tests that validate that your chart works as expected when it is installed. These tests also help the chart consumer understand what your chart is supposed to do. A **test** in a helm chart lives under the `templates/` directory and is a pod definition that specifies a container with a given command to run. The container should exit successfully (exit 0) for a test to be considered a success. The pod definition must contain one of the helm test hook annotations: `helm.sh/hook: test-success` or `helm.sh/hook: test-failure`. Example tests: - Validate that your configuration from the values.yaml file was properly injected. - Make sure your username and password work correctly - Make sure an incorrect username and password does not work - Assert that your services are up and correctly loadbalanced. - etc. You can run the pre-defined tests in Helm on a release using the command `helm test `. For a chart consumer, this is a great way to sanity check that their release of a chart (or application) works as expected. ## A Breakdown of the Helm Test Hooks In Helm, there are two test hooks: `test-success` and `test-failure` `test-success` indicates that test pod should complete successfully. In other words, the containers in the pod should exit 0. `test-failure` is a way to assert that a test pod should not complete successfully. If the containers in the pod do not exit 0, that indicates success. ## Example Test Here is an example of a helm test pod definition in an example wordpress chart. The test verifies the access and login to the mariadb database: ``` wordpress/ Chart.yaml README.md values.yaml charts/ templates/ templates/tests/test-mariadb-connection.yaml ``` In `wordpress/templates/tests/test-mariadb-connection.yaml`: ``` apiVersion: v1 kind: Pod metadata: name: "{{ .Release.Name }}-credentials-test" annotations: "helm.sh/hook": test-success spec: containers: - name: {{ .Release.Name }}-credentials-test image: {{ .Values.image }} env: - name: MARIADB_HOST value: {{ template "mariadb.fullname" . }} - name: MARIADB_PORT value: "3306" - name: WORDPRESS_DATABASE_NAME value: {{ default "" .Values.mariadb.mariadbDatabase | quote }} - name: WORDPRESS_DATABASE_USER value: {{ default "" .Values.mariadb.mariadbUser | quote }} - name: WORDPRESS_DATABASE_PASSWORD valueFrom: secretKeyRef: name: {{ template "mariadb.fullname" . }} key: mariadb-password command: ["sh", "-c", "mysql --host=$MARIADB_HOST --port=$MARIADB_PORT --user=$WORDPRESS_DATABASE_USER --password=$WORDPRESS_DATABASE_PASSWORD"] restartPolicy: Never ``` ## Steps to Run a Test Suite on a Release 1. `$ helm install stable/wordpress` ``` NAME: quirky-walrus LAST DEPLOYED: Mon Feb 13 13:50:43 2017 NAMESPACE: default STATUS: DEPLOYED ``` 2. `$ helm test quirky-walrus` ``` RUNNING: quirky-walrus-credentials-test SUCCESS: quirky-walrus-credentials-test ``` ## Notes - You can define as many tests as you would like in a single yaml file or spread across several yaml files in the `templates/` directory - You are welcome to nest your test suite under a `tests/` directory like `/templates/tests/` for more isolation ================================================ FILE: versioned_docs/version-2/developing_charts/charts_hooks.md ================================================ --- sidebar_position: 1 sidebar_label: "Chart Lifecycle Hooks" --- # Hooks Helm provides a _hook_ mechanism to allow chart developers to intervene at certain points in a release's life cycle. For example, you can use hooks to: - Load a ConfigMap or Secret during install before any other charts are loaded. - Execute a Job to back up a database before installing a new chart, and then execute a second job after the upgrade in order to restore data. - Run a Job before deleting a release to gracefully take a service out of rotation before removing it. Hooks work like regular templates, but they have special annotations that cause Helm to utilize them differently. In this section, we cover the basic usage pattern for hooks. Hooks are declared as an annotation in the metadata section of a manifest: ```yaml apiVersion: ... kind: .... metadata: annotations: "helm.sh/hook": "pre-install" # ... ``` ## The Available Hooks The following hooks are defined: - pre-install: Executes after templates are rendered, but before any resources are created in Kubernetes. - post-install: Executes after all resources are loaded into Kubernetes - pre-delete: Executes on a deletion request before any resources are deleted from Kubernetes. - post-delete: Executes on a deletion request after all of the release's resources have been deleted. - pre-upgrade: Executes on an upgrade request after templates are rendered, but before any resources are loaded into Kubernetes (e.g. before a Kubernetes apply operation). - post-upgrade: Executes on an upgrade after all resources have been upgraded. - pre-rollback: Executes on a rollback request after templates are rendered, but before any resources have been rolled back. - post-rollback: Executes on a rollback request after all resources have been modified. - crd-install: Adds CRD resources before any other checks are run. This is used only on CRD definitions that are used by other manifests in the chart. - test-success: Executes when running `helm test` and expects the pod to return successfully (return code == 0). - test-failure: Executes when running `helm test` and expects the pod to fail (return code != 0). ## Hooks and the Release Lifecycle Hooks allow you, the chart developer, an opportunity to perform operations at strategic points in a release lifecycle. For example, consider the lifecycle for a `helm install`. By default, the lifecycle looks like this: 1. User runs `helm install foo` 2. Chart is loaded into Tiller 3. After some verification, Tiller renders the `foo` templates 4. Tiller loads the resulting resources into Kubernetes 5. Tiller returns the release name (and other data) to the client 6. The client exits Helm defines two hooks for the `install` lifecycle: `pre-install` and `post-install`. If the developer of the `foo` chart implements both hooks, the lifecycle is altered like this: 1. User runs `helm install foo` 2. Chart is loaded into Tiller 3. After some verification, Tiller renders the `foo` templates 4. Tiller prepares to execute the `pre-install` hooks (loading hook resources into Kubernetes) 5. Tiller sorts hooks by weight (assigning a weight of 0 by default) and by name for those hooks with the same weight in ascending order. 6. Tiller then loads the hook with the lowest weight first (negative to positive) 7. Tiller waits until the hook is "Ready" (except for CRDs) 8. Tiller loads the resulting resources into Kubernetes. Note that if the `--wait` flag is set, Tiller will wait until all resources are in a ready state and will not run the `post-install` hook until they are ready. 9. Tiller executes the `post-install` hook (loading hook resources) 10. Tiller waits until the hook is "Ready" 11. Tiller returns the release name (and other data) to the client 12. The client exits What does it mean to wait until a hook is ready? This depends on the resource declared in the hook. If the resources is a `Job` kind, Tiller will wait until the job successfully runs to completion. And if the job fails, the release will fail. This is a _blocking operation_, so the Helm client will pause while the Job is run. For all other kinds, as soon as Kubernetes marks the resource as loaded (added or updated), the resource is considered "Ready". When many resources are declared in a hook, the resources are executed serially. If they have hook weights (see below), they are executed in weighted order. Otherwise, ordering is not guaranteed. (In Helm 2.3.0 and after, they are sorted alphabetically. That behavior, though, is not considered binding and could change in the future.) It is considered good practice to add a hook weight, and set it to `0` if weight is not important. ### Hook resources are not managed with corresponding releases The resources that a hook creates are not tracked or managed as part of the release. Once Tiller verifies that the hook has reached its ready state, it will leave the hook resource alone. Practically speaking, this means that if you create resources in a hook, you cannot rely upon `helm delete` to remove the resources. To destroy such resources, you need to either write code to perform this operation in a `pre-delete` or `post-delete` hook or add `"helm.sh/hook-delete-policy"` annotation to the hook template file. ## Writing a Hook Hooks are just Kubernetes manifest files with special annotations in the `metadata` section. Because they are template files, you can use all of the normal template features, including reading `.Values`, `.Release`, and `.Template`. For example, this template, stored in `templates/post-install-job.yaml`, declares a job to be run on `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{.Release.Name}}" labels: app.kubernetes.io/managed-by: {{.Release.Service | quote }} app.kubernetes.io/instance: {{.Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{.Release.Name}}" labels: app.kubernetes.io/managed-by: {{.Release.Service | quote }} app.kubernetes.io/instance: {{.Release.Name | quote }} helm.sh/chart: "{{.Chart.Name}}-{{.Chart.Version}}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{default "10" .Values.sleepyTime}}"] ``` What makes this template a hook is the annotation: ``` annotations: "helm.sh/hook": post-install ``` One resource can implement multiple hooks: ``` annotations: "helm.sh/hook": post-install,post-upgrade ``` Similarly, there is no limit to the number of different resources that may implement a given hook. For example, one could declare both a secret and a config map as a pre-install hook. When subcharts declare hooks, those are also evaluated. There is no way for a top-level chart to disable the hooks declared by subcharts. It is possible to define a weight for a hook which will help build a deterministic executing order. Weights are defined using the following annotation: ``` annotations: "helm.sh/hook-weight": "5" ``` Hook weights can be positive or negative numbers but must be represented as strings. When Tiller starts the execution cycle of hooks of a particular kind (ex. the `pre-install` hooks or `post-install` hooks, etc.) it will sort those hooks in ascending order. It is also possible to define policies that determine when to delete corresponding hook resources. Hook deletion policies are defined using the following annotation: ``` annotations: "helm.sh/hook-delete-policy": hook-succeeded ``` You can choose one or more defined annotation values: * `"hook-succeeded"` specifies Tiller should delete the hook after the hook is successfully executed. * `"hook-failed"` specifies Tiller should delete the hook if the hook failed during execution. * `"before-hook-creation"` specifies Tiller should delete the previous hook before the new hook is launched. By default Tiller will wait for 60 seconds for a deleted hook to no longer exist in the API server before timing out. This behavior can be changed using the `helm.sh/hook-delete-timeout` annotation. The value is the number of seconds Tiller should wait for the hook to be fully deleted. A value of 0 means Tiller does not wait at all. ### Defining a CRD with the `crd-install` Hook Custom Resource Definitions (CRDs) are a special kind in Kubernetes. They provide a way to define other kinds. On occasion, a chart needs to both define a kind and then use it. This is done with the `crd-install` hook. The `crd-install` hook is executed very early during an installation, before the rest of the manifests are verified. CRDs can be annotated with this hook so that they are installed before any instances of that CRD are referenced. In this way, when verification happens later, the CRDs will be available. Here is an example of defining a CRD with a hook, and an instance of the CRD: ```yaml apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com annotations: "helm.sh/hook": crd-install spec: group: stable.example.com version: v1 scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab shortNames: - ct ``` And: ```yaml apiVersion: stable.example.com/v1 kind: CronTab metadata: name: {{ .Release.Name }}-inst ``` Both of these can now be in the same chart, provided that the CRD is correctly annotated. ### Automatically delete hook from previous release When a helm release, that uses a hook, is being updated, it is possible that the hook resource might already exist in the cluster. In such circumstances, by default, helm will fail trying to install the hook resource with an `"... already exists"` error. A common reason why the hook resource might already exist is that it was not deleted following use on a previous install/upgrade. There are, in fact, good reasons why one might want to keep the hook: for example, to aid manual debugging in case something went wrong. In this case, the recommended way of ensuring subsequent attempts to create the hook do not fail is to define a `"hook-delete-policy"` that can handle this: `"helm.sh/hook-delete-policy": "before-hook-creation"`. This hook annotation causes any existing hook to be removed, before the new hook is installed. If it is preferred to actually delete the hook after each use (rather than have to handle it on a subsequent use, as shown above), then this can be achieved using a delete policy of `"helm.sh/hook-delete-policy": "hook-succeeded,hook-failed"`. ================================================ FILE: versioned_docs/version-2/developing_charts/charts_tips_and_tricks.md ================================================ --- sidebar_position: 2 sidebar_label: "Charts Tips and Tricks" --- # Chart Development Tips and Tricks This guide covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. ## Know Your Template Functions Helm uses [Go templates](https://godoc.org/text/template) for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added almost all of the functions in the [Sprig library](https://godoc.org/github.com/Masterminds/sprig). We removed two for security reasons: `env` and `expandenv` (which would have given chart authors access to Tiller's environment). We also added two special template functions: `include` and `required`. The `include` function allows you to bring in another template, and then pass the results to other template functions. For example, this template snippet includes a template called `mytpl`, then lowercases the result, then wraps that in double quotes. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` The `required` function allows you to declare a particular values entry as required for template rendering. If the value is empty, the template rendering will fail with a user submitted error message. The following example of the `required` function declares an entry for .Values.who is required, and will print an error message when that entry is missing: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` When using the `include` function, you can pass it a custom object tree built from the current context by using the `dict` function: ```yaml {{- include "mytpl" (dict "key1" .Values.originalKey1 "key2" .Values.originalKey2) }} ``` ## Quote Strings, Don't Quote Integers When you are working with string data, you are always safer quoting the strings than leaving them as bare words: ```yaml name: {{ .Values.MyName | quote }} ``` But when working with integers _do not quote the values._ That can, in many cases, cause parsing errors inside of Kubernetes. ```yaml port: {{ .Values.Port }} ``` This remark does not apply to env variables values which are expected to be string, even if they represent integers: ```yaml env: -name: HOST value: "http://host" -name: PORT value: "1234" ``` ## Using the 'include' Function Go provides a way of including one template in another using a built-in `template` directive. However, the built-in function cannot be used in Go template pipelines. To make it possible to include a template, and then perform an operation on that template's output, Helm has a special `include` function: ```gotpl {{- include "toYaml" $value | nindent 2 }} ``` The above includes a template called `toYaml`, passes it `$value`, and then passes the output of that template to the `nindent` function. Using the `{{- ... | nindent _n_ }}` pattern makes it easier to read the `include` in context, because it chomps the whitespace to the left (including the previous newline), then the `nindent` re-adds the newline and indents the included content by the requested amount. Because YAML ascribes significance to indentation levels and whitespace, this is one great way to include snippets of code, but handle indentation in a relevant context. ## Using the 'required' function Go provides a way for setting template options to control behavior when a map is indexed with a key that's not present in the map. This is typically set with template.Options("missingkey=option"), where option can be default, zero, or error. While setting this option to error will stop execution with an error, this would apply to every missing key in the map. There may be situations where a chart developer wants to enforce this behavior for select values in the values.yml file. The `required` function gives developers the ability to declare a value entry as required for template rendering. If the entry is empty in values.yml, the template will not render and will return an error message supplied by the developer. For example: ```gotpl {{ required "A valid foo is required!" .Values.foo }} ``` The above will render the template when .Values.foo is defined, but will fail to render and exit when .Values.foo is undefined. ## Using the 'tpl' Function The `tpl` function allows developers to evaluate strings as templates inside a template. This is useful to pass a template string as a value to a chart or render external configuration files. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}` Examples: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Rendering a external configuration file: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Creating Image Pull Secrets Image pull secrets are essentially a combination of _registry_, _username_, and _password_. You may need them in an application you are deploying, but to create them requires running _base64_ a couple of times. We can write a helper template to compose the Docker configuration file for use as the Secret's payload. Here is an example: First, assume that the credentials are defined in the `values.yaml` file like so: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness ``` We then define our helper template as follows: ```gotpl {{- define "imagePullSecret" }} {{- printf "{\"auths\": {\"%s\": {\"auth\": \"%s\"}}}" .Values.imageCredentials.registry (printf "%s:%s" .Values.imageCredentials.username .Values.imageCredentials.password | b64enc) | b64enc }} {{- end }} ``` Finally, we use the helper template in a larger template to create the Secret manifest: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Automatically Roll Deployments When ConfigMaps or Secrets change Often times configmaps or secrets are injected as configuration files in containers. Depending on the application a restart may be required should those be updated with a subsequent `helm upgrade`, but if the deployment spec itself didn't change the application keeps running with the old configuration resulting in an inconsistent deployment. The `sha256sum` function can be used to ensure a deployment's annotation section is updated if another file changes: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` See also the `helm upgrade --recreate-pods` flag for a slightly different way of addressing this issue. ## Tell Tiller Not To Delete a Resource Sometimes there are resources that should not be deleted when Helm runs a `helm delete`. Chart developers can add an annotation to a resource to prevent it from being deleted. ```yaml kind: Secret metadata: annotations: "helm.sh/resource-policy": keep [...] ``` (Quotation marks are required) The annotation `"helm.sh/resource-policy": keep` instructs Tiller to skip this resource during a `helm delete` operation. _However_, this resource becomes orphaned. Helm will no longer manage it in any way. This can lead to problems if using `helm install --replace` on a release that has already been deleted, but has kept resources. To explicitly opt in to resource deletion, for example when overriding a chart's default annotations, set the resource policy annotation value to `delete`. ## Using "Partials" and Template Includes Sometimes you want to create some reusable parts in your chart, whether they're blocks or template partials. And often, it's cleaner to keep these in their own files. In the `templates/` directory, any file that begins with an underscore(`_`) is not expected to output a Kubernetes manifest file. So by convention, helper templates and partials are placed in a `_helpers.tpl` file. ## Complex Charts with Many Dependencies Many of the charts in the [official charts repository](https://github.com/helm/charts) are "building blocks" for creating more advanced applications. But charts may be used to create instances of large-scale applications. In such cases, a single umbrella chart may have multiple subcharts, each of which functions as a piece of the whole. The current best practice for composing a complex application from discrete parts is to create a top-level umbrella chart that exposes the global configurations, and then use the `charts/` subdirectory to embed each of the components. Two strong design patterns are illustrated by these projects: **SAP's [Converged charts](https://github.com/sapcc/helm-charts):** These charts install SAP Converged Cloud a full OpenStack IaaS on Kubernetes. All of the charts are collected together in one GitHub repository, except for a few submodules. **Deis's [Workflow](https://github.com/deis/workflow/tree/master/charts/workflow):** This chart exposes the entire Deis PaaS system with one chart. But it's different from the SAP chart in that this umbrella chart is built from each component, and each component is tracked in a different Git repository. Check out the `requirements.yaml` file to see how this chart is composed by their CI/CD pipeline. Both of these charts illustrate proven techniques for standing up complex environments using Helm. ## YAML is a Superset of JSON According to the YAML specification, YAML is a superset of JSON. That means that any valid JSON structure ought to be valid in YAML. This has an advantage: Sometimes template developers may find it easier to express a data structure with a JSON-like syntax rather than deal with YAML's whitespace sensitivity. As a best practice, templates should follow a YAML-like syntax _unless_ the JSON syntax substantially reduces the risk of a formatting issue. ## Be Careful with Generating Random Values There are functions in Helm that allow you to generate random data, cryptographic keys, and so on. These are fine to use. But be aware that during upgrades, templates are re-executed. When a template run generates data that differs from the last run, that will trigger an update of that resource. ## Upgrade a release idempotently In order to use the same command when installing and upgrading a release, use the following command: ```shell helm upgrade --install --values ``` ================================================ FILE: versioned_docs/version-2/developing_charts/developing_charts.md ================================================ --- sidebar_position: 5 sidebar_label: "Charts" # This is the index/landing page for this section --- # Charts Helm uses a packaging format called _charts_. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on. Charts are created as files laid out in a particular directory tree, then they can be packaged into versioned archives to be deployed. This document explains the chart format, and provides basic guidance for building charts with Helm. ## The Chart File Structure A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing WordPress would be stored in the `wordpress/` directory. Inside of this directory, Helm will expect a structure that matches this: ``` wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file requirements.yaml # OPTIONAL: A YAML file listing dependencies for the chart values.yaml # The default configuration values for this chart charts/ # A directory containing any charts upon which this chart depends. templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Helm reserves use of the `charts/` and `templates/` directories, and of the listed file names. Other files will be left as they are. ## The Chart.yaml File The `Chart.yaml` file is required for a chart. It contains the following fields: ```yaml apiVersion: The chart API version, always "v1" (required) name: The name of the chart (required) version: A SemVer 2 version (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) keywords: - A list of keywords about this project (optional) home: The URL of this project's home page (optional) sources: - A list of URLs to source code for this project (optional) maintainers: # (optional) - name: The maintainer's name (required for each maintainer) email: The maintainer's email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) engine: gotpl # The name of the template engine (optional, defaults to gotpl) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). This needn't be SemVer. deprecated: Whether this chart is deprecated (optional, boolean) tillerVersion: The version of Tiller that this chart requires. This should be expressed as a SemVer range: ">2.0.0" (optional) ``` If you are familiar with the `Chart.yaml` file format for Helm Classic, you will notice that fields specifying dependencies have been removed. That is because the new Chart format expresses dependencies using the `charts/` directory. Other fields will be silently ignored. ### Charts and Versioning Every chart must have a version number. A version must follow the [SemVer 2](https://semver.org/) standard. Unlike Helm Classic, Kubernetes Helm uses version numbers as release markers. Packages in repositories are identified by name plus version. For example, an `nginx` chart whose version field is set to `version: 1.2.3` will be named: ``` nginx-1.2.3.tgz ``` More complex SemVer 2 names are also supported, such as `version: 1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly disallowed by the system. **NOTE:** Whereas Helm Classic and Deployment Manager were both very GitHub oriented when it came to charts, Kubernetes Helm does not rely upon or require GitHub or even Git. Consequently, it does not use Git SHAs for versioning at all. The `version` field inside of the `Chart.yaml` is used by many of the Helm tools, including the CLI and the Tiller server. When generating a package, the `helm package` command will use the version that it finds in the `Chart.yaml` as a token in the package name. The system assumes that the version number in the chart package name matches the version number in the `Chart.yaml`. Failure to meet this assumption will cause an error. ### The appVersion field Note that the `appVersion` field is not related to the `version` field. It is a way of specifying the version of the application. For example, the `drupal` chart may have an `appVersion: 8.2.1`, indicating that the version of Drupal included in the chart (by default) is `8.2.1`. This field is informational, and has no impact on chart version calculations. ### Deprecating Charts When managing charts in a Chart Repository, it is sometimes necessary to deprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used to mark a chart as deprecated. If the **latest** version of a chart in the repository is marked as deprecated, then the chart as a whole is considered to be deprecated. The chart name can later be reused by publishing a newer version that is not marked as deprecated. The workflow for deprecating charts, as followed by the [helm/charts](https://github.com/helm/charts) project is: - Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the version - Release the new chart version in the Chart Repository - Remove the chart from the source repository (e.g. git) ## Chart LICENSE, README and NOTES Charts can also contain files that describe the installation, configuration, usage and license of a chart. A LICENSE is a plain text file containing the [license](https://en.wikipedia.org/wiki/Software_license) for the chart. The chart can contain a license as it may have programming logic in the templates and would therefore not be configuration only. There can also be separate license(s) for the application installed by the chart, if required. A README for a chart should be formatted in Markdown (README.md), and should generally contain: - A description of the application or service the chart provides - Any prerequisites or requirements to run the chart - Descriptions of options in `values.yaml` and default values - Any other information that may be relevant to the installation or configuration of the chart The chart can also contain a short plain text `templates/NOTES.txt` file that will be printed out after installation, and when viewing the status of a release. This file is evaluated as a [template](#templates-and-values), and can be used to display usage notes, next steps, or any other information relevant to a release of the chart. For example, instructions could be provided for connecting to a database, or accessing a web UI. Since this file is printed to STDOUT when running `helm install` or `helm status`, it is recommended to keep the content brief and point to the README for greater detail. ## Chart Dependencies In Helm, one chart may depend on any number of other charts. These dependencies can be dynamically linked through the `requirements.yaml` file or brought in to the `charts/` directory and managed manually. Although manually managing your dependencies has a few advantages some teams need, the preferred method of declaring dependencies is by using a `requirements.yaml` file inside of your chart. **Note:** The `dependencies:` section of the `Chart.yaml` from Helm Classic has been completely removed. ### Managing Dependencies with `requirements.yaml` A `requirements.yaml` file is a simple file for listing your dependencies. ```yaml dependencies: - name: apache version: 1.2.3 repository: http://example.com/charts - name: mysql version: 3.2.1 repository: http://another.example.com/charts ``` - The `name` field is the name of the chart you want. - The `version` field is the version of the chart you want. - The `repository` field is the full URL to the chart repository. Note that you must also use `helm repo add` to add that repo locally. Once you have a dependencies file, you can run `helm dependency update` and it will use your dependency file to download all the specified charts into your `charts/` directory for you. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Saving 2 charts Downloading apache from repo http://example.com/charts Downloading mysql from repo http://another.example.com/charts ``` When `helm dependency update` retrieves charts, it will store them as chart archives in the `charts/` directory. So for the example above, one would expect to see the following files in the charts directory: ``` charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` Managing charts with `requirements.yaml` is a good way to easily keep charts updated, and also share requirements information throughout a team. #### Alias field in requirements.yaml In addition to the other fields above, each requirements entry may contain the optional field `alias`. Adding an alias for a dependency chart would put a chart in dependencies using alias as name of new dependency. One can use `alias` in cases where they need to access a chart with other name(s). ```yaml # parentchart/requirements.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` In the above example we will get 3 dependencies in all for `parentchart` ``` subchart new-subchart-1 new-subchart-2 ``` The manual way of achieving this is by copy/pasting the same chart in the `charts/` directory multiple times with different names. #### Tags and Condition fields in requirements.yaml In addition to the other fields above, each requirements entry may contain the optional fields `tags` and `condition`. All charts are loaded by default. If `tags` or `condition` fields are present, they will be evaluated and used to control loading for the chart(s) they are applied to. Condition - The condition field holds one or more YAML paths (delimited by commas). If this path exists in the parent's values and resolves to a boolean value, the chart will be enabled or disabled based on that boolean value. Only the first valid path found in the list is evaluated and if no paths exist then the condition has no effect. For multiple level dependencies the condition is prependend by the path to the parent chart. Tags - The tags field is a YAML list of labels to associate with this chart. In the top parent's values, all charts with tags can be enabled or disabled by specifying the tag and a boolean value. ```yaml # parentchart/requirements.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # subchart2/requirements.yaml dependencies: - name: subsubchart repository: http://localhost:10191 version: 0.1.0 condition: subsubchart.enabled ``` ```yaml # parentchart/values.yaml subchart1: enabled: true subchart2: subsubchart: enabled: false tags: front-end: false back-end: true ``` In the above example all charts with the tag `front-end` would be disabled but since the `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the `front-end` tag and `subchart1` will be enabled. Since `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be enabled. Also note that although `subchart2` has a condition specified in `requirements.yaml`, there is no corresponding path and value in the parent's values so that condition has no effect. `subsubchart` is disabled by default but can be enabled by setting `subchart2.subsubchart.enabled=true`. Hint: disabling `subchart2` via tag will also disable all sub-charts (even if overriding the value `subchart2.subsubchart.enabled=true`). ##### Using the CLI with Tags and Conditions The `--set` parameter can be used as usual to alter tag and condition values. ```` helm install --set tags.front-end=true --set subchart2.enabled=false ```` ##### Tags and Condition Resolution - **Conditions (when set in values) always override tags.** - The first condition path that exists wins and subsequent ones for that chart are ignored. - Tags are evaluated as 'if any of the chart's tags are true then enable the chart'. - Tags and conditions values must be set in the top parent's values. - The `tags:` key in values must be a top level key. Globals and nested `tags:` tables are not currently supported. #### Importing Child Values via requirements.yaml In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be shared as common defaults. An additional benefit of using the `exports` format is that it will enable future tooling to introspect user-settable values. The keys containing the values to be imported can be specified in the parent chart's `requirements.yaml` file using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field. To import values not contained in the `exports` key, use the [child-parent](#using-the-child-parent-format) format. Examples of both formats are described below. ##### Using the exports format If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported directly into the parent's values by specifying the keys to import as in the example below: ```yaml # parent's requirements.yaml file ... import-values: - data ``` ```yaml # child's values.yaml file ... exports: data: myint: 99 ``` Since we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child chart for `data` key and imports its contents. The final parent values would contain our exported field: ```yaml # parent's values file ... myint: 99 ``` Please note the parent key `data` is not contained in the parent's final values. If you need to specify the parent key, use the 'child-parent' format. ##### Using the child-parent format To access values that are not contained in the `exports` key of the child chart's values, you will need to specify the source key of the values to be imported (`child`) and the destination path in the parent chart's values (`parent`). The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them to the parent's values at the path specified in `parent:` ```yaml # parent's requirements.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` In the above example, values found at `default.data` in the subchart1's values will be imported to the `myimports` key in the parent chart's values as detailed below: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` The parent chart's resulting values would be: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` The parent's final values now contains the `myint` and `mybool` fields imported from subchart1. ### Managing Dependencies manually via the `charts/` directory If more control over dependencies is desired, these dependencies can be expressed explicitly by copying the dependency charts into the `charts/` directory. A dependency can be either a chart archive (`foo-1.2.3.tgz`) or an unpacked chart directory. But its name cannot start with `_` or `.`. Such files are ignored by the chart loader. For example, if the WordPress chart depends on the Apache chart, the Apache chart (of the correct version) is supplied in the WordPress chart's `charts/` directory: ``` wordpress: Chart.yaml requirements.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` The example above shows how the WordPress chart expresses its dependency on Apache and MySQL by including those charts inside of its `charts/` directory. **TIP:** _To drop a dependency into your `charts/` directory, use the `helm fetch` command_ ### Operational aspects of using dependencies The above sections explain how to specify chart dependencies, but how does this affect chart installation using `helm install` and `helm upgrade`? Suppose that a chart named "A" creates the following Kubernetes objects - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Furthermore, A is dependent on chart B that creates objects - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" After installation/upgrade of chart A, a single Helm release is created/modified. The release will create/update all of the above Kubernetes objects in the following order: - A-Namespace - B-Namespace - A-StatefulSet - B-ReplicaSet - A-Service - B-Service This is because when Helm installs/upgrades charts, the Kubernetes objects from the charts and all its dependencies are - aggregated into a single set; then - sorted by type followed by name; and then - created/updated in that order. Hence a single release is created with all the objects for the chart and its dependencies. The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go (see [the Helm source file](https://github.com/helm/helm/blob/master/pkg/tiller/kind_sorter.go#L26)). ## Templates and Values Helm Chart templates are written in the [Go template language](https://golang.org/pkg/text/template/), with the addition of 50 or so add-on template functions [from the Sprig library](https://github.com/Masterminds/sprig) and a few other [specialized functions](charts_tips_and_tricks.md). All template files are stored in a chart's `templates/` folder. When Helm renders the charts, it will pass every file in that directory through the template engine. Values for the templates are supplied two ways: - Chart developers may supply a file called `values.yaml` inside of a chart. This file can contain default values. - Chart users may supply a YAML file that contains values. This can be provided on the command line with `helm install`. When a user supplies custom values, these values will override the values in the chart's `values.yaml` file. ### Template Files Template files follow the standard conventions for writing Go templates (see [the text/template Go package documentation](https://golang.org/pkg/text/template/) for details). An example template file might look something like this: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}} imagePullPolicy: {{.Values.pullPolicy}} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{default "minio" .Values.storage}} ``` The above example, based loosely on [https://github.com/deis/charts](https://github.com/deis/charts), is a template for a Kubernetes replication controller. It can use the following four template values (usually defined in a `values.yaml` file): - `imageRegistry`: The source registry for the Docker image. - `dockerTag`: The tag for the docker image. - `pullPolicy`: The Kubernetes pull policy. - `storage`: The storage backend, whose default is set to `"minio"` All of these values are defined by the template author. Helm does not require or dictate parameters. To see many working charts, check out the [Helm Charts project](https://github.com/helm/charts) ### Predefined Values Values that are supplied via a `values.yaml` file (or via the `--set` flag) are accessible from the `.Values` object in a template. But there are other pre-defined pieces of data you can access in your templates. The following values are pre-defined, are available to every template, and cannot be overridden. As with all values, the names are _case sensitive_. - `Release.Name`: The name of the release (not the chart) - `Release.Time`: The time the chart release was last updated. This will match the `Last Released` time on a Release object. - `Release.Namespace`: The namespace the chart was released to. - `Release.Service`: The service that conducted the release. Usually this is `Tiller`. - `Release.IsUpgrade`: This is set to true if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to true if the current operation is an install. - `Release.Revision`: The revision number. It begins at 1, and increments with each `helm upgrade`. - `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is obtainable as `Chart.Version` and the maintainers are in `Chart.Maintainers`. - `Files`: A map-like object containing all non-special files in the chart. This will not give you access to templates, but will give you access to additional files that are present (unless they are excluded using `.helmignore`). Files can be accessed using `{{index .Files "file.name"}}` or using the `{{.Files.Get name}}` or `{{.Files.GetString name}}` functions. You can also access the contents of the file as `[]byte` using `{{.Files.GetBytes}}` - `Capabilities`: A map-like object that contains information about the versions of Kubernetes (`{{.Capabilities.KubeVersion}}`, Tiller (`{{.Capabilities.TillerVersion}}`, and the supported Kubernetes API versions (`{{.Capabilities.APIVersions.Has "batch/v1"`) **NOTE:** Any unknown Chart.yaml fields will be dropped. They will not be accessible inside of the `Chart` object. Thus, Chart.yaml cannot be used to pass arbitrarily structured data into the template. The values file can be used for that, though. ### Values files Considering the template in the previous section, a `values.yaml` file that supplies the necessary values would look like this: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` A values file is formatted in YAML. A chart may include a default `values.yaml` file. The Helm install command allows a user to override values by supplying additional YAML values: ```console $ helm install --values=myvals.yaml wordpress ``` When values are passed in this way, they will be merged into the default values file. For example, consider a `myvals.yaml` file that looks like this: ```yaml storage: "gcs" ``` When this is merged with the `values.yaml` in the chart, the resulting generated content will be: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Note that only the last field was overridden. **NOTE:** The default values file included inside of a chart _must_ be named `values.yaml`. But files specified on the command line can be named anything. **NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those values are simply converted to YAML on the client side. **NOTE:** If any required entries in the values file exist, they can be declared as required in the chart template by using the ['required' function](charts_tips_and_tricks.md) Any of these values are then accessible inside of templates using the `.Values` object: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}} imagePullPolicy: {{.Values.pullPolicy}} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{default "minio" .Values.storage}} ``` ### Scope, Dependencies, and Values Values files can declare values for the top-level chart, as well as for any of the charts that are included in that chart's `charts/` directory. Or, to phrase it differently, a values file can supply values to the chart as well as to any of its dependencies. For example, the demonstration WordPress chart above has both `mysql` and `apache` as dependencies. The values file could supply values to all of these components: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Charts at a higher level have access to all of the variables defined beneath. So the WordPress chart can access the MySQL password as `.Values.mysql.password`. But lower level charts cannot access things in parent charts, so MySQL will not be able to access the `title` property. Nor, for that matter, can it access `apache.port`. Values are namespaced, but namespaces are pruned. So for the WordPress chart, it can access the MySQL password field as `.Values.mysql.password`. But for the MySQL chart, the scope of the values has been reduced and the namespace prefix removed, so it will see the password field simply as `.Values.password`. #### Global Values As of 2.0.0-Alpha.2, Helm supports special "global" value. Consider this modified version of the previous example: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` The above adds a `global` section with the value `app: MyWordPress`. This value is available to _all_ charts as `.Values.global.app`. For example, the `mysql` templates may access `app` as `{{.Values.global.app}}`, and so can the `apache` chart. Effectively, the values file above is regenerated like this: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` This provides a way of sharing one top-level variable with all subcharts, which is useful for things like setting `metadata` properties like labels. If a subchart declares a global variable, that global will be passed _downward_ (to the subchart's subcharts), but not _upward_ to the parent chart. There is no way for a subchart to influence the values of the parent chart. Also, global variables of parent charts take precedence over the global variables from subcharts. ### References When it comes to writing templates and values files, there are several standard references that will help you out. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) ## Using Helm to Manage Charts The `helm` tool has several commands for working with charts. It can create a new chart for you: ```console $ helm create mychart Created mychart/ ``` Once you have edited a chart, `helm` can package it into a chart archive for you: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` You can also use `helm` to help you find issues with your chart's formatting or information: ```console $ helm lint mychart No issues found ``` ## Chart Repositories A _chart repository_ is an HTTP server that houses one or more packaged charts. While `helm` can be used to manage local chart directories, when it comes to sharing charts, the preferred mechanism is a chart repository. Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server. Helm comes with built-in package server for developer testing (`helm serve`). The Helm team has tested other servers, including Google Cloud Storage with website mode enabled, and S3 with website mode enabled. A repository is characterized primarily by the presence of a special file called `index.yaml` that has a list of all of the packages supplied by the repository, together with metadata that allows retrieving and verifying those packages. On the client side, repositories are managed with the `helm repo` commands. However, Helm does not provide tools for uploading charts to remote repository servers. This is because doing so would add substantial requirements to an implementing server, and thus raise the barrier for setting up a repository. ## Chart Starter Packs The `helm create` command takes an optional `--starter` option that lets you specify a "starter chart". Starters are just regular charts, but are located in `$HELM_HOME/starters`. As a chart developer, you may author charts that are specifically designed to be used as starters. Such charts should be designed with the following considerations in mind: - The `Chart.yaml` will be overwritten by the generator. - Users will expect to modify such a chart's contents, so documentation should indicate how users can do so. - All occurrences of `` in files within the `templates` directory will be replaced with the specified chart name so that starter charts can be used as templates. Additionally, occurrences of `` in `values.yaml` will also be replaced. Currently the only way to add a chart to `$HELM_HOME/starters` is to manually copy it there. In your chart's documentation, you may want to explain that process. ================================================ FILE: versioned_docs/version-2/developing_charts/provenance.md ================================================ --- sidebar_position: 5 sidebar_label: "Signing Charts" --- # Helm Provenance and Integrity Helm has provenance tools which help chart users verify the integrity and origin of a package. Using industry-standard tools based on PKI, GnuPG, and well-respected package managers, Helm can generate and verify signature files. ## Overview Integrity is established by comparing a chart to a provenance record. Provenance records are stored in _provenance files_, which are stored alongside a packaged chart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file will be `myapp-1.2.3.tgz.prov`. Provenance files are generated at packaging time (`helm package --sign ...`), and can be checked by multiple commands, notable `helm install --verify`. ## The Workflow This section describes a potential workflow for using provenance data effectively. Prerequisites: - A valid PGP keypair in a binary (not ASCII-armored) format - The `helm` command line tool - GnuPG >=2.1 command line tools (optional) - Keybase command line tools (optional) **NOTE:** If your PGP private key has a passphrase, you will be prompted to enter that passphrase for any commands that support the `--sign` option. You can set the HELM_KEY_PASSPHRASE environment variable to that passphrase in case you don't want to be prompted to enter the passphrase. **NOTE:** The keyfile format for GnuPG changed in version 2.1. Prior to that release it was unnecessary to export keys out of GnuPG, and you could instead point Helm at your `*.gpg` files. With 2.1, the new `.kbx` format was introduced, and this format is not supported by Helm. Creating a new chart is the same as before: ``` $ helm create mychart Creating mychart ``` Once ready to package, add the `--sign` flag to `helm package`. Also, specify the name under which the signing key is known and the keyring containing the corresponding private key: ``` $ helm package --sign --key 'helm signing key' --keyring path/to/keyring.secret mychart ``` **TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.kbx`. You can use `gpg --list-secret-keys` to list the keys you have. **Warning:** the GnuPG v2.1 store your secret keyring using a new format 'kbx' on the default location '~/.gnupg/pubring.kbx'. Please use the following command to convert your keyring to the legacy gpg format: ``` $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` At this point, you should see both `mychart-0.1.0.tgz` and `mychart-0.1.0.tgz.prov`. Both files should eventually be uploaded to your desired chart repository. You can verify a chart using `helm verify`: ``` $ helm verify mychart-0.1.0.tgz ``` A failed verification looks like this: ``` $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` To verify during an install, use the `--verify` flag. ``` $ helm install --verify mychart-0.1.0.tgz ``` If the keyring (containing the public key associated with the signed chart) is not in the default location, you may need to point to the keyring with `--keyring PATH` as in the `helm package` example. If verification fails, the install will be aborted before the chart is even pushed up to Tiller. ### Using Keybase.io credentials The [Keybase.io](https://keybase.io) service makes it easy to establish a chain of trust for a cryptographic identity. Keybase credentials can be used to sign charts. Prerequisites: - A configured Keybase.io account - GnuPG installed locally - The `keybase` CLI installed locally #### Signing packages The first step is to import your keybase keys into your local GnuPG keyring: ``` $ keybase pgp export -s > secring.gpg ``` This will convert your Keybase key into the OpenPGP format, and then place it locally into your `secring.gpg` file. > Tip: If you need to add a Keybase key to an existing keyring, you will need to > do `keybase pgp export -s | gpg --import && gpg --export-secret-keys --outfile secring.gpg` Your secret key will have an identifier string: ``` technosophos (keybase.io/technosophos) ``` That is the full name of your key. Next, you can package and sign a chart with `helm package`. Make sure you use at least part of that name string in `--key`. ``` $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` As a result, the `package` command should produce both a `.tgz` file and a `.tgz.prov` file. #### Verifying packages You can also use a similar technique to verify a chart signed by someone else's Keybase key. Say you want to verify a package signed by `keybase.io/technosophos`. To do this, use the `keybase` tool: ``` $ keybase follow technosophos $ keybase pgp pull ``` The first command above tracks the user `technosophos`. Next `keybase pgp pull` downloads the OpenPGP keys of all of the accounts you follow, placing them in your GnuPG keyring (`~/.gnupg/pubring.gpg`). At this point, you can now use `helm verify` or any of the commands with a `--verify` flag: ``` $ helm verify somechart-1.2.3.tgz ``` ### Reasons a chart may not verify These are common reasons for failure. - The prov file is missing or corrupt. This indicates that something is misconfigured or that the original maintainer did not create a provenance file. - The key used to sign the file is not in your keyring. This indicate that the entity who signed the chart is not someone you've already signaled that you trust. - The verification of the prov file failed. This indicates that something is wrong with either the chart or the provenance data. - The file hashes in the provenance file do not match the hash of the archive file. This indicates that the archive has been tampered with. If a verification fails, there is reason to distrust the package. ## The Provenance File The provenance file contains a chart’s YAML file plus several pieces of verification information. Provenance files are designed to be automatically generated. The following pieces of provenance data are added: * The chart file (Chart.yaml) is included to give both humans and tools an easy view into the contents of the chart. * The signature (SHA256, just like Docker) of the chart package (the .tgz file) is included, and may be used to verify the integrity of the chart package. * The entire body is signed using the algorithm used by PGP (see [https://keybase.io] for an emerging way of making crypto signing and verification easy). The combination of this gives users the following assurances: * The package itself has not been tampered with (checksum package tgz). * The entity who released this package is known (via the GnuPG/PGP signature). The format of the file looks something like this: ``` -----BEGIN PGP SIGNED MESSAGE----- name: nginx description: The nginx web server as a replication controller and service pair. version: 0.5.1 keywords: - https - http - web server - proxy source: - https://github.com/foo/bar home: https://nginx.com ... files: nginx-0.5.1.tgz: “sha256:9f5270f50fc842cfcb717f817e95178f” -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjilUEACgQkB01zfu119ZnHuQCdGCcg2YxF3XFscJLS4lzHlvte WkQAmQGHuuoLEJuKhRNo+Wy7mhE7u1YG =eifq -----END PGP SIGNATURE----- ``` Note that the YAML section contains two documents (separated by `...\n`). The first is the Chart.yaml. The second is the checksums, a map of filenames to SHA-256 digests (value shown is fake/truncated) The signature block is a standard PGP signature, which provides [tamper resistance](https://www.rossde.com/PGP/pgp_signatures.html). ## Chart Repositories Chart repositories serve as a centralized collection of Helm charts. Chart repositories must make it possible to serve provenance files over HTTP via a specific request, and must make them available at the same URI path as the chart. For example, if the base URL for a package is `https://example.com/charts/mychart-1.2.3.tgz`, the provenance file, if it exists, MUST be accessible at `https://example.com/charts/mychart-1.2.3.tgz.prov`. From the end user's perspective, `helm install --verify myrepo/mychart-1.2.3` should result in the download of both the chart and the provenance file with no additional user configuration or action. ## Establishing Authority and Authenticity When dealing with chain-of-trust systems, it is important to be able to establish the authority of a signer. Or, to put this plainly, the system above hinges on the fact that you trust the person who signed the chart. That, in turn, means you need to trust the public key of the signer. One of the design decisions with Kubernetes Helm has been that the Helm project would not insert itself into the chain of trust as a necessary party. We don't want to be "the certificate authority" for all chart signers. Instead, we strongly favor a decentralized model, which is part of the reason we chose OpenPGP as our foundational technology. So when it comes to establishing authority, we have left this step more-or-less undefined in Helm 2.0.0. However, we have some pointers and recommendations for those interested in using the provenance system: - The [Keybase](https://keybase.io) platform provides a public centralized repository for trust information. - You can use Keybase to store your keys or to get the public keys of others. - Keybase also has fabulous documentation available - While we haven't tested it, Keybase's "secure website" feature could be used to serve Helm charts. - The [official Helm Charts project](https://github.com/helm/charts) is trying to solve this problem for the official chart repository. - There is a long issue there [detailing the current thoughts](https://github.com/helm/charts/issues/23). - The basic idea is that an official "chart reviewer" signs charts with her or his key, and the resulting provenance file is then uploaded to the chart repository. - There has been some work on the idea that a list of valid signing keys may be included in the `index.yaml` file of a repository. Finally, chain-of-trust is an evolving feature of Helm, and some community members have proposed adapting part of the OSI model for signatures. This is an open line of inquiry in the Helm team. If you're interested, jump on in. ================================================ FILE: versioned_docs/version-2/glossary.md ================================================ --- sidebar_position: 12 sidebar_label: "Glossary" --- # Helm Glossary Helm uses a few special terms to describe components of the architecture. ## Chart A Helm package that contains information sufficient for installing a set of Kubernetes resources into a Kubernetes cluster. Charts contain a `Chart.yaml` file as well as templates, default values (`values.yaml`), and dependencies. Charts are developed in a well-defined directory structure, and then packaged into an archive format called a _chart archive_. ## Chart Archive A _chart archive_ is a tarred and gzipped (and optionally signed) chart. ## Chart Dependency (Subcharts) Charts may depend upon other charts. There are two ways a dependency may occur: - Soft dependency: A chart may simply not function without another chart being installed in a cluster. Helm does not provide tooling for this case. In this case, dependencies may be managed separately. - Hard dependency: A chart may contain (inside of its `charts/` directory) another chart upon which it depends. In this case, installing the chart will install all of its dependencies. In this case, a chart and its dependencies are managed as a collection. When a chart is packaged (via `helm package`) all of its hard dependencies are bundled with it. ## Chart Version Charts are versioned according to the [SemVer 2 spec](https://semver.org). A version number is required on every chart. ## Chart.yaml Information about a chart is stored in a special file called `Chart.yaml`. Every chart must have this file. ## Helm (and helm) Helm is the package manager for Kubernetes. As an operating system package manager makes it easy to install tools on an OS, Helm makes it easy to install applications and resources into Kubernetes clusters. While _Helm_ is the name of the project, the command line client is also named `helm`. By convention, when speaking of the project, _Helm_ is capitalized. When speaking of the client, _helm_ is in lowercase. ## Helm Home (HELM_HOME) The Helm client stores information in a local directory referred to as _helm home_. By default, this is in the `$HOME/.helm` directory. This directory contains configuration and cache data, and is created by `helm init`. ## Kube Config (KUBECONFIG) The Helm client learns about Kubernetes clusters by using files in the _Kube config_ file format. By default, Helm attempts to find this file in the place where `kubectl` creates it (`$HOME/.kube/config`). ## Lint (Linting) To _lint_ a chart is to validate that it follows the conventions and requirements of the Helm chart standard. Helm provides tools to do this, notably the `helm lint` command. ## Provenance (Provenance file) Helm charts may be accompanied by a _provenance file_ which provides information about where the chart came from and what it contains. Provenance files are one part of the Helm security story. A provenance contains a cryptographic hash of the chart archive file, the Chart.yaml data, and a signature block (an OpenPGP "clearsign" block). When coupled with a keychain, this provides chart users with the ability to: - Validate that a chart was signed by a trusted party - Validate that the chart file has not been tampered with - Validate the contents of a chart metadata (`Chart.yaml`) - Quickly match a chart to its provenance data Provenance files have the `.prov` extension, and can be served from a chart repository server or any other HTTP server. ## Release When a chart is installed, Tiller (the Helm server) creates a _release_ to track that installation. A single chart may be installed many times into the same cluster, and create many different releases. For example, one can install three PostgreSQL databases by running `helm install` three times with a different release name. (Prior to 2.0.0-Alpha.1, releases were called _deployments_. But this caused confusion with the Kubernetes _Deployment_ kind.) ## Release Number (Release Version) A single release can be updated multiple times. A sequential counter is used to track releases as they change. After a first `helm install`, a release will have _release number_ 1. Each time a release is upgraded or rolled back, the release number will be incremented. ## Rollback A release can be upgraded to a newer chart or configuration. But since release history is stored, a release can also be _rolled back_ to a previous release number. This is done with the `helm rollback` command. Importantly, a rolled back release will receive a new release number. Operation | Release Number ----------|--------------- install | release 1 upgrade | release 2 upgrade | release 3 rollback 1| release 4 (but running the same config as release 1) The above table illustrates how release numbers increment across install, upgrade, and rollback. ## Tiller Tiller is the in-cluster component of Helm. It interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It also stores the objects that represent releases. ## Repository (Repo, Chart Repository) Helm charts may be stored on dedicated HTTP servers called _chart repositories_ (_repositories_, or just _repos_). A chart repository server is a simple HTTP server that can serve an `index.yaml` file that describes a batch of charts, and provides information on where each chart can be downloaded from. (Many chart repositories serve the charts as well as the `index.yaml` file.) A Helm client can point to zero or more chart repositories. By default, Helm clients point to the `stable` official Kubernetes chart repository. ## Values (Values Files, values.yaml) Values provide a way to override template defaults with your own information. Helm Charts are "parameterized", which means the chart developer may expose configuration that can be overridden at installation time. For example, a chart may expose a `username` field that allows setting a user name for a service. These exposed variables are called _values_ in Helm parlance. Values can be set during `helm install` and `helm upgrade` operations, either by passing them in directly, or by uploading a `values.yaml` file. ================================================ FILE: versioned_docs/version-2/helm/helm.md ================================================ --- title: "helm" sidebar_position: 4 sidebar_label: "Helm Commands" # This is the index/landing page for this section --- The Helm package manager for Kubernetes. ### Synopsis The Kubernetes package manager To begin working with Helm, run the 'helm init' command: $ helm init This will install Tiller to your running Kubernetes cluster. It will also set up any necessary local configuration. Common actions from this point include: - helm search: Search for charts - helm fetch: Download a chart to your local directory to view - helm install: Upload the chart to Kubernetes - helm list: List releases of charts Environment: - $HELM_HOME: Set an alternative location for Helm files. By default, these are stored in ~/.helm - $HELM_HOST: Set an alternative Tiller host. The format is host:port - $HELM_NO_PLUGINS: Disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins. - $TILLER_NAMESPACE: Set an alternative Tiller namespace (default "kube-system") - $KUBECONFIG: Set an alternative Kubernetes configuration file (default "~/.kube/config") - $HELM_TLS_CA_CERT: Path to TLS CA certificate used to verify the Helm client and Tiller server certificates (default "$HELM_HOME/ca.pem") - $HELM_TLS_CERT: Path to TLS client certificate file for authenticating to Tiller (default "$HELM_HOME/cert.pem") - $HELM_TLS_KEY: Path to TLS client key file for authenticating to Tiller (default "$HELM_HOME/key.pem") - $HELM_TLS_ENABLE: Enable TLS connection between Helm and Tiller (default "false") - $HELM_TLS_VERIFY: Enable TLS connection between Helm and Tiller and verify Tiller server certificate (default "false") - $HELM_TLS_HOSTNAME: The hostname or IP address used to verify the Tiller server certificate (default "127.0.0.1") - $HELM_KEY_PASSPHRASE: Set HELM_KEY_PASSPHRASE to the passphrase of your PGP private key. If set, you will not be prompted for the passphrase while signing helm charts ### Options ``` --debug Enable verbose output -h, --help help for helm --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm completion](helm_completion.md) - Generate autocompletions script for the specified shell (bash or zsh) * [helm create](helm_create.md) - Create a new chart with the given name * [helm delete](helm_delete.md) - Given a release name, delete the release from Kubernetes * [helm dependency](helm_dependency.md) - Manage a chart's dependencies * [helm fetch](helm_fetch.md) - Download a chart from a repository and (optionally) unpack it in local directory * [helm get](helm_get.md) - Download a named release * [helm history](helm_history.md) - Fetch release history * [helm home](helm_home.md) - Displays the location of HELM_HOME * [helm init](helm_init.md) - Initialize Helm on both client and server * [helm inspect](helm_inspect.md) - Inspect a chart * [helm install](helm_install.md) - Install a chart archive * [helm lint](helm_lint.md) - Examines a chart for possible issues * [helm list](helm_list.md) - List releases * [helm package](helm_package.md) - Package a chart directory into a chart archive * [helm plugin](helm_plugin.md) - Add, list, or remove Helm plugins * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories * [helm reset](helm_reset.md) - Uninstalls Tiller from a cluster * [helm rollback](helm_rollback.md) - Rollback a release to a previous revision * [helm search](helm_search.md) - Search for a keyword in charts * [helm serve](helm_serve.md) - Start a local http web server * [helm status](helm_status.md) - Displays the status of the named release * [helm template](helm_template.md) - Locally render templates * [helm test](helm_test.md) - Test a release * [helm upgrade](helm_upgrade.md) - Upgrade a release * [helm verify](helm_verify.md) - Verify that a chart at the given path has been signed and is valid * [helm version](helm_version.md) - Print the client/server version information ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_completion.md ================================================ --- title: "helm completion" sidebar_position: 1 sidebar_label: "Helm Completion" --- Generate autocompletions script for the specified shell (bash or zsh) ### Synopsis Generate autocompletions script for Helm for the specified shell (bash or zsh). This command can generate shell autocompletions. e.g. $ helm completion bash Can be sourced as such $ source <(helm completion bash) ``` helm completion SHELL [flags] ``` ### Options ``` -h, --help help for completion ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_create.md ================================================ --- title: "helm create" sidebar_position: 2 sidebar_label: "Helm Create" --- Create a new chart with the given name ### Synopsis This command creates a chart directory along with the common files and directories used in a chart. It provides a basic example and is not meant to cover all Kubernetes resources. For example, 'helm create foo' will create a directory structure that looks something like this: foo/ | |- .helmignore # Contains patterns to ignore when packaging Helm charts. | |- Chart.yaml # Information about your chart | |- values.yaml # The default values for your templates | |- charts/ # Charts that this chart depends on | |- templates/ # The template files | |- templates/tests/ # The test files 'helm create' takes a path for an argument. If directories in the given path do not exist, Helm will attempt to create them as it goes. If the given destination exists and there are files in that directory, conflicting files will be overwritten, but other files will be left alone. The chart that is created by invoking this command contains a Deployment, Ingress and a Service. To use other Kubernetes resources with your chart, refer to [The Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide). ``` helm create NAME [flags] ``` ### Options ``` -h, --help help for create -p, --starter string The name or absolute path to Helm starter scaffold ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 7-Jul-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_delete.md ================================================ --- title: "helm delete" sidebar_position: 3 sidebar_label: "Helm Delete" --- Given a release name, delete the release from Kubernetes ### Synopsis This command takes a release name, and then deletes the release from Kubernetes. It removes all of the resources associated with the last release of the chart. Use the '--dry-run' flag to see which releases will be deleted without actually deleting them. ``` helm delete [flags] RELEASE_NAME [...] ``` ### Options ``` --description string Specify a description for the release --dry-run Simulate a delete -h, --help help for delete --no-hooks Prevent hooks from running during deletion --purge Remove the release from the store and make its name free for later use --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300) --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_dependency.md ================================================ --- title: "helm dependency" sidebar_position: 4 sidebar_label: "Helm Dependency" --- Manage a chart's dependencies ### Synopsis Manage the dependencies of a chart. Helm charts store their dependencies in 'charts/'. For chart developers, it is often easier to manage a single dependency file ('requirements.yaml') which declares all dependencies. The dependency commands operate on that file, making it easy to synchronize between the desired dependencies and the actual dependencies stored in the 'charts/' directory. A 'requirements.yaml' file is a YAML file in which developers can declare chart dependencies, along with the location of the chart and the desired version. For example, this requirements file declares two dependencies: # requirements.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" The 'name' should be the name of a chart, where that name must match the name in that chart's 'Chart.yaml' file. The 'version' field should contain a semantic version or version range. The 'repository' URL should point to a Chart Repository. Helm expects that by appending '/index.yaml' to the URL, it should be able to retrieve the chart repository's index. Note: 'repository' can be an alias. The alias must start with 'alias:' or '@'. Starting from 2.2.0, repository can be defined as the path to the directory of the dependency charts stored locally. The path should start with a prefix of "file://". For example, # requirements.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" If the dependency chart is retrieved locally, it is not required to have the repository added to helm by "helm repo add". Version matching is also supported for this case. ### Options ``` -h, --help help for dependency ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. * [helm dependency build](helm_dependency_build.md) - Rebuild the charts/ directory based on the requirements.lock file * [helm dependency list](helm_dependency_list.md) - List the dependencies for the given chart * [helm dependency update](helm_dependency_update.md) - Update charts/ based on the contents of requirements.yaml ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_dependency_build.md ================================================ --- title: "helm dependency build" sidebar_position: 5 sidebar_label: "Helm Dependency Build" --- Rebuild the charts/ directory based on the requirements.lock file ### Synopsis Build out the charts/ directory from the requirements.lock file. Build is used to reconstruct a chart's dependencies to the state specified in the lock file. If no lock file is found, 'helm dependency build' will mirror the behavior of the 'helm dependency update' command. This means it will update the on-disk dependencies to mirror the requirements.yaml file and generate a lock file. ``` helm dependency build [flags] CHART ``` ### Options ``` -h, --help help for build --keyring string Keyring containing public keys (default "~/.gnupg/pubring.gpg") --verify Verify the packages against signatures ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm dependency](helm_dependency.md) - Manage a chart's dependencies ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_dependency_list.md ================================================ --- title: "helm dependency list" sidebar_position: 6 sidebar_label: "Helm Dependency List" --- List the dependencies for the given chart ### Synopsis List all of the dependencies declared in a chart. This can take chart archives and chart directories as input. It will not alter the contents of a chart. This will produce an error if the chart cannot be loaded. It will emit a warning if it cannot find a requirements.yaml. ``` helm dependency list [flags] CHART ``` ### Options ``` -h, --help help for list ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm dependency](helm_dependency.md) - Manage a chart's dependencies ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_dependency_update.md ================================================ --- title: "helm dependency update" sidebar_position: 7 sidebar_label: "Helm Dependency Update" --- Update charts/ based on the contents of requirements.yaml ### Synopsis Update the on-disk dependencies to mirror the requirements.yaml file. This command verifies that the required charts, as expressed in 'requirements.yaml', are present in 'charts/' and are at an acceptable version. It will pull down the latest charts that satisfy the dependencies, and clean up old dependencies. On successful update, this will generate a lock file that can be used to rebuild the requirements to an exact version. Dependencies are not required to be represented in 'requirements.yaml'. For that reason, an update command will not remove charts unless they are (a) present in the requirements.yaml file, but (b) at the wrong version. ``` helm dependency update [flags] CHART ``` ### Options ``` -h, --help help for update --keyring string Keyring containing public keys (default "~/.gnupg/pubring.gpg") --skip-refresh Do not refresh the local repository cache --verify Verify the packages against signatures ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm dependency](helm_dependency.md) - Manage a chart's dependencies ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_fetch.md ================================================ --- title: "helm fetch" sidebar_position: 8 sidebar_label: "Helm Fetch" --- Download a chart from a repository and (optionally) unpack it in local directory ### Synopsis Retrieve a package from a package repository, and download it locally. This is useful for fetching packages to inspect, modify, or repackage. It can also be used to perform cryptographic verification of a chart without installing the chart. There are options for unpacking the chart after download. This will create a directory for the chart and uncompress into that directory. If the --verify flag is specified, the requested chart MUST have a provenance file, and MUST pass the verification process. Failure in any part of this will result in an error, and the chart will not be saved locally. ``` helm fetch [flags] [chart URL | repo/chartname] [...] ``` ### Options ``` --ca-file string Verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string Identify HTTPS client using this SSL certificate file -d, --destination string Location to write the chart. If this and tardir are specified, tardir is appended to this (default ".") --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for fetch --key-file string Identify HTTPS client using this SSL key file --keyring string Keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string Chart repository password --prov Fetch the provenance file, but don't perform verification --repo string Chart repository url where to locate the requested chart --untar If set to true, will untar the chart after downloading it --untardir string If untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string Chart repository username --verify Verify the package against its signature --version string Specific version of a chart. Without this, the latest version is fetched ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_get.md ================================================ --- title: "helm get" sidebar_position: 9 sidebar_label: "Helm Get" --- Download a named release ### Synopsis This command shows the details of a named release. It can be used to get extended information about the release, including: - The values used to generate the release - The chart used to generate the release - The generated manifest file By default, this prints a human readable collection of information about the chart, the supplied values, and the generated manifest file. ``` helm get [flags] RELEASE_NAME ``` ### Options ``` -h, --help help for get --revision int32 Get the named release with revision --template string Go template for formatting the output, eg: {{.Release.Name}} --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. * [helm get hooks](helm_get_hooks.md) - Download all hooks for a named release * [helm get manifest](helm_get_manifest.md) - Download the manifest for a named release * [helm get notes](helm_get_notes.md) - Displays the notes of the named release * [helm get values](helm_get_values.md) - Download the values file for a named release ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_get_hooks.md ================================================ --- title: "helm get hooks" sidebar_position: 10 sidebar_label: "Helm Get Hooks" --- Download all hooks for a named release ### Synopsis This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. ``` helm get hooks [flags] RELEASE_NAME ``` ### Options ``` -h, --help help for hooks --revision int32 Get the named release with revision --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm get](helm_get.md) - Download a named release ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_get_manifest.md ================================================ --- title: "helm get manifest" sidebar_position: 11 sidebar_label: "Helm Get Manifest" --- Download the manifest for a named release ### Synopsis This command fetches the generated manifest for a given release. A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. ``` helm get manifest [flags] RELEASE_NAME ``` ### Options ``` -h, --help help for manifest --revision int32 Get the named release with revision --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm get](helm_get.md) - Download a named release ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_get_notes.md ================================================ --- title: "helm get notes" sidebar_position: 12 sidebar_label: "Helm Get Notes" --- Displays the notes of the named release ### Synopsis This command shows notes provided by the chart of a named release. ``` helm get notes [flags] RELEASE_NAME ``` ### Options ``` -h, --help help for notes --revision int32 Get the notes of the named release with revision --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm get](helm_get.md) - Download a named release ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_get_values.md ================================================ --- title: "helm get values" sidebar_position: 13 sidebar_label: "Helm Get Values" --- Download the values file for a named release ### Synopsis This command downloads a values file for a given release. ``` helm get values [flags] RELEASE_NAME ``` ### Options ``` -a, --all Dump all (computed) values -h, --help help for values --output string Output the specified format (json or yaml) (default "yaml") --revision int32 Get the named release with revision --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm get](helm_get.md) - Download a named release ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_history.md ================================================ --- title: "helm history" sidebar_position: 14 sidebar_label: "Helm History" --- Fetch release history ### Synopsis History prints historical revisions for a given release. A default maximum of 256 revisions will be returned. Setting '--max' configures the maximum length of the revision list returned. The historical release set is printed as a formatted table, e.g: $ helm history angry-bird --max=4 REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 SUPERSEDED alpine-0.1.0 1.1 Initial install 2 Mon Oct 3 10:15:13 2016 SUPERSEDED alpine-0.1.0 1.2 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 SUPERSEDED alpine-0.1.0 1.1 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 DEPLOYED alpine-0.1.0 1.3 Upgraded successfully ``` helm history [flags] RELEASE_NAME ``` ### Options ``` --col-width uint Specifies the max column width of output (default 60) -h, --help help for history --max int32 Maximum number of revisions to include in history (default 256) -o, --output string Prints the output in the specified format (json|table|yaml) (default "table") --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_home.md ================================================ --- title: "helm home" sidebar_position: 15 sidebar_label: "Helm Home" --- Displays the location of HELM_HOME ### Synopsis This command displays the location of HELM_HOME. This is where any helm configuration files live. ``` helm home [flags] ``` ### Options ``` -h, --help help for home ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_init.md ================================================ --- title: "helm init" sidebar_position: 16 sidebar_label: "Helm Init" --- Initialize Helm on both client and server ### Synopsis This command installs Tiller (the Helm server-side component) onto your Kubernetes Cluster and sets up local configuration in $HELM_HOME (default ~/.helm/). As with the rest of the Helm commands, 'helm init' discovers Kubernetes clusters by reading $KUBECONFIG (default '~/.kube/config') and using the default context. To set up just a local environment, use '--client-only'. That will configure $HELM_HOME, but not attempt to connect to a Kubernetes cluster and install the Tiller deployment. When installing Tiller, 'helm init' will attempt to install the latest released version. You can specify an alternative image with '--tiller-image'. For those frequently working on the latest code, the flag '--canary-image' will install the latest pre-release version of Tiller (e.g. the HEAD commit in the GitHub repository on the master branch). To dump a manifest containing the Tiller deployment YAML, combine the '--dry-run' and '--debug' flags. ``` helm init [flags] ``` ### Options ``` --automount-service-account-token Auto-mount the given service account to tiller (default true) --canary-image Use the canary Tiller image -c, --client-only If set does not install Tiller --dry-run Do not install local or remote --force-upgrade Force upgrade of Tiller to the current helm version -h, --help help for init --history-max int Limit the maximum number of revisions saved per release. Use 0 for no limit. --local-repo-url string URL for local repository (default "http://127.0.0.1:8879/charts") --net-host Install Tiller with net=host --node-selectors string Labels to specify the node on which Tiller is installed (app=tiller,helm=rocks) -o, --output OutputFormat Skip installation and output Tiller's manifest in specified format (json or yaml) --override stringArray Override values for the Tiller Deployment manifest (can specify multiple or separate values with commas: key1=val1,key2=val2) --replicas int Amount of tiller instances to run on the cluster (default 1) --service-account string Name of service account --skip-refresh Do not refresh (download) the local repository cache --skip-repos Skip adding the stable and local repositories --stable-repo-url string URL for stable repository (default "https://charts.helm.sh/stable") -i, --tiller-image string Override Tiller image --tiller-tls Install Tiller with TLS enabled --tiller-tls-cert string Path to TLS certificate file to install with Tiller --tiller-tls-hostname string The server name used to verify the hostname on the returned certificates from Tiller --tiller-tls-key string Path to TLS key file to install with Tiller --tiller-tls-verify Install Tiller with TLS enabled and to verify remote certificates --tls-ca-cert string Path to CA root certificate --upgrade Upgrade if Tiller is already installed --use-deprecated-stable-repository Use the old (googleapis) repository URL even though that URL is being shutdown. --wait Block until Tiller is running and ready to receive requests ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 15-Oct-2020 ================================================ FILE: versioned_docs/version-2/helm/helm_inspect.md ================================================ --- title: "helm inspect" sidebar_position: 17 sidebar_label: "Helm Inspect" --- Inspect a chart ### Synopsis This command inspects a chart and displays information. It takes a chart reference ('stable/drupal'), a full path to a directory or packaged chart, or a URL. Inspect prints the contents of the Chart.yaml file and the values.yaml file. ``` helm inspect [CHART] [flags] ``` ### Options ``` --ca-file string Chart repository url where to locate the requested chart --cert-file string Verify certificates of HTTPS-enabled servers using this CA bundle --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for inspect --key-file string Identify HTTPS client using this SSL key file --keyring string Path to the keyring containing public verification keys (default "~/.gnupg/pubring.gpg") --password string Chart repository password where to locate the requested chart --repo string Chart repository url where to locate the requested chart --username string Chart repository username where to locate the requested chart --verify Verify the provenance data for this chart --version string Version of the chart. By default, the newest chart is shown ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. * [helm inspect chart](helm_inspect_chart.md) - shows inspect chart * [helm inspect readme](helm_inspect_readme.md) - shows inspect readme * [helm inspect values](helm_inspect_values.md) - shows inspect values ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_inspect_chart.md ================================================ --- title: "helm inspect chart" sidebar_position: 18 sidebar_label: "Helm Inspect Chart" --- shows inspect chart ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the Charts.yaml file ``` helm inspect chart [CHART] [flags] ``` ### Options ``` --ca-file string Chart repository url where to locate the requested chart --cert-file string Verify certificates of HTTPS-enabled servers using this CA bundle --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for chart --key-file string Identify HTTPS client using this SSL key file --keyring string Path to the keyring containing public verification keys (default "~/.gnupg/pubring.gpg") --password string Chart repository password where to locate the requested chart --repo string Chart repository url where to locate the requested chart --username string Chart repository username where to locate the requested chart --verify Verify the provenance data for this chart --version string Version of the chart. By default, the newest chart is shown ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm inspect](helm_inspect.md) - Inspect a chart ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_inspect_readme.md ================================================ --- title: "helm inspect readme" sidebar_position: 19 sidebar_label: "Helm Inspect Readme" --- shows inspect readme ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the README file ``` helm inspect readme [CHART] [flags] ``` ### Options ``` --ca-file string Chart repository url where to locate the requested chart --cert-file string Verify certificates of HTTPS-enabled servers using this CA bundle --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for readme --key-file string Identify HTTPS client using this SSL key file --keyring string Path to the keyring containing public verification keys (default "~/.gnupg/pubring.gpg") --repo string Chart repository url where to locate the requested chart --verify Verify the provenance data for this chart --version string Version of the chart. By default, the newest chart is shown ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm inspect](helm_inspect.md) - Inspect a chart ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_inspect_values.md ================================================ --- title: "helm inspect values" sidebar_position: 20 sidebar_label: "Helm Inspect Values" --- shows inspect values ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the values.yaml file ``` helm inspect values [CHART] [flags] ``` ### Options ``` --ca-file string Chart repository url where to locate the requested chart --cert-file string Verify certificates of HTTPS-enabled servers using this CA bundle --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for values --key-file string Identify HTTPS client using this SSL key file --keyring string Path to the keyring containing public verification keys (default "~/.gnupg/pubring.gpg") --password string Chart repository password where to locate the requested chart --repo string Chart repository url where to locate the requested chart --username string Chart repository username where to locate the requested chart --verify Verify the provenance data for this chart --version string Version of the chart. By default, the newest chart is shown ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm inspect](helm_inspect.md) - Inspect a chart ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_install.md ================================================ --- title: "helm install" sidebar_position: 21 sidebar_label: "Helm Install" --- Install a chart archive ### Synopsis This command installs a chart archive. The install argument must be a chart reference, a path to a packaged chart, a path to an unpacked chart directory or a URL. To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line. To force string values in '--set', use '--set-string' instead. In case a value is large and therefore you want not to use neither '--values' nor '--set', use '--set-file' to read the single large value from file. $ helm install -f myvalues.yaml ./redis or $ helm install --set name=prod ./redis or $ helm install --set-string long_int=1234567890 ./redis or $ helm install --set-file multiline_text=path/to/textfile You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm install -f myvalues.yaml -f override.yaml ./redis You can specify the '--set' flag multiple times. The priority will be given to the last (right-most) set specified. For example, if both 'bar' and 'newbar' values are set for a key called 'foo', the 'newbar' value would take precedence: $ helm install --set foo=bar --set foo=newbar ./redis To check the generated manifests of a release without installing the chart, the '--debug' and '--dry-run' flags can be combined. This will still require a round-trip to the Tiller server. If --verify is set, the chart MUST have a provenance file, and the provenance file MUST pass all verification steps. There are five different ways you can express the chart you want to install: 1. By chart reference: helm install stable/mariadb 2. By path to a packaged chart: helm install ./nginx-1.2.3.tgz 3. By path to an unpacked chart directory: helm install ./nginx 4. By absolute URL: helm install https://example.com/charts/nginx-1.2.3.tgz 5. By chart reference and repo url: helm install --repo https://example.com/charts/ nginx CHART REFERENCES A chart reference is a convenient way of reference a chart in a chart repository. When you use a chart reference with a repo prefix ('stable/mariadb'), Helm will look in the local configuration for a chart repository named 'stable', and will then look for a chart in that repository whose name is 'mariadb'. It will install the latest version of that chart unless you also supply a version number with the '--version' flag. To see the list of chart repositories, use 'helm repo list'. To search for charts in a repository, use 'helm search'. ``` helm install [CHART] [flags] ``` ### Options ``` --atomic If set, installation process purges chart on fail, also sets --wait flag --ca-file string Verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string Identify HTTPS client using this SSL certificate file --dep-up Run helm dependency update before installing the chart --description string Specify a description for the release --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. --dry-run Simulate an install -h, --help help for install --key-file string Identify HTTPS client using this SSL key file --keyring string Location of public keys used for verification (default "~/.gnupg/pubring.gpg") -n, --name string The release name. If unspecified, it will autogenerate one for you --name-template string Specify template used to name the release --namespace string Namespace to install the release into. Defaults to the current kube config namespace. --no-crd-hook Prevent CRD hooks from running, but run other hooks --no-hooks Prevent hooks from running during install -o, --output string Prints the output in the specified format. Allowed values: table, json, yaml (default "table") --password string Chart repository password where to locate the requested chart --render-subchart-notes Render subchart notes along with the parent --replace Re-use the given name, even if that name is already used. This is unsafe in production --repo string Chart repository url where to locate the requested chart --set stringArray Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray Set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-string stringArray Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300) --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote --username string Chart repository username where to locate the requested chart -f, --values valueFiles Specify values in a YAML file or a URL(can specify multiple) (default []) --verify Verify the package before installing it --version string Specify the exact chart version to install. If this is not specified, the latest version is installed --wait If set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 24-Sep-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_lint.md ================================================ --- title: "helm lint" sidebar_position: 22 sidebar_label: "Helm Lint" --- Examines a chart for possible issues ### Synopsis This command takes a path to a chart and runs a series of tests to verify that the chart is well-formed. If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages. ``` helm lint [flags] PATH ``` ### Options ``` -h, --help help for lint --namespace string Namespace to put the release into (default "default") --set stringArray Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray Set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-string stringArray Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --strict Fail on lint warnings -f, --values valueFiles Specify values in a YAML file (can specify multiple) (default []) ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_list.md ================================================ --- title: "helm list" sidebar_position: 23 sidebar_label: "Helm List" --- List releases ### Synopsis This command lists all of the releases. By default, it lists only releases that are deployed or failed. Flags like '--deleted' and '--all' will alter this behavior. Such flags can be combined: '--deleted --failed'. By default, items are sorted alphabetically. Use the '-d' flag to sort by release date. If an argument is provided, it will be treated as a filter. Filters are regular expressions (Perl compatible) that are applied to the list of releases. Only items that match the filter will be returned. $ helm list 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid Mon May 9 16:07:08 2016 alpine-0.1.0 If no results are found, 'helm list' will exit 0, but with no output (or in the case of no '-q' flag, only headers). By default, up to 256 items may be returned. To limit this, use the '--max' flag. Setting '--max' to 0 will not return all results. Rather, it will return the server's default, which may be much higher than 256. Pairing the '--max' flag with the '--offset' flag allows you to page through results. ``` helm list [flags] [FILTER] ``` ### Options ``` -a, --all Show all releases, not just the ones marked DEPLOYED -c, --chart-name Sort by chart name --col-width uint Specifies the max column width of output (default 60) -d, --date Sort by release date --deleted Show deleted releases --deleting Show releases that are currently being deleted --deployed Show deployed releases. If no other is specified, this will be automatically enabled --failed Show failed releases -h, --help help for list -m, --max int Maximum number of releases to fetch (default 256) --namespace string Show releases within a specific namespace -o, --offset string Next release name in the list, used to offset from start value --output string Output the specified format (json or yaml) --pending Show pending releases -r, --reverse Reverse the sort order -q, --short Output short (quiet) listing format --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_package.md ================================================ --- title: "helm package" sidebar_position: 24 sidebar_label: "Helm Package" --- Package a chart directory into a chart archive ### Synopsis This command packages a chart into a versioned chart archive file. If a path is given, this will look at that path for a chart (which must contain a Chart.yaml file) and then package that directory. If no path is given, this will look in the present working directory for a Chart.yaml file, and (if found) build the current directory into a chart. Versioned chart archives are used by Helm package repositories. ``` helm package [flags] [CHART_PATH] [...] ``` ### Options ``` --app-version string Set the appVersion on the chart to this version -u, --dependency-update Update dependencies from "requirements.yaml" to dir "charts/" before packaging -d, --destination string Location to write the chart. (default ".") -h, --help help for package --key string Name of the key to use when signing. Used if --sign is true --keyring string Location of a public keyring (default "~/.gnupg/pubring.gpg") --save Save packaged chart to local chart repository (default true) --sign Use a PGP private key to sign this package --version string Set the version on the chart to this semver version ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_plugin.md ================================================ --- title: "helm plugin" sidebar_position: 25 sidebar_label: "Helm Plugin" --- Add, list, or remove Helm plugins ### Synopsis Manage client-side Helm plugins. ### Options ``` -h, --help help for plugin ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. * [helm plugin install](helm_plugin_install.md) - Install one or more Helm plugins * [helm plugin list](helm_plugin_list.md) - List installed Helm plugins * [helm plugin remove](helm_plugin_remove.md) - Remove one or more Helm plugins * [helm plugin update](helm_plugin_update.md) - Update one or more Helm plugins ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_plugin_install.md ================================================ --- title: "helm plugin install" sidebar_position: 26 sidebar_label: "Helm Plugin Install" --- Install one or more Helm plugins ### Synopsis This command allows you to install a plugin from a url to a VCS repo or a local path. Example usage: $ helm plugin install https://github.com/technosophos/helm-template ``` helm plugin install [options] ... [flags] ``` ### Options ``` -h, --help help for install --version string Specify a version constraint. If this is not specified, the latest version is installed ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm plugin](helm_plugin.md) - Add, list, or remove Helm plugins ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_plugin_list.md ================================================ --- title: "helm plugin list" sidebar_position: 27 sidebar_label: "Helm Plugin List" --- List installed Helm plugins ### Synopsis List installed Helm plugins ``` helm plugin list [flags] ``` ### Options ``` -h, --help help for list ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm plugin](helm_plugin.md) - Add, list, or remove Helm plugins ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_plugin_remove.md ================================================ --- title: "helm plugin remove" sidebar_position: 28 sidebar_label: "Helm Plugin Remove" --- Remove one or more Helm plugins ### Synopsis Remove one or more Helm plugins ``` helm plugin remove ... [flags] ``` ### Options ``` -h, --help help for remove ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm plugin](helm_plugin.md) - Add, list, or remove Helm plugins ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_plugin_update.md ================================================ --- title: "helm plugin update" sidebar_position: 29 sidebar_label: "Helm Plugin Update" --- Update one or more Helm plugins ### Synopsis Update one or more Helm plugins ``` helm plugin update ... [flags] ``` ### Options ``` -h, --help help for update ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm plugin](helm_plugin.md) - Add, list, or remove Helm plugins ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo.md ================================================ --- title: "helm repo" sidebar_position: 30 sidebar_label: "Helm Repo" --- Add, list, remove, update, and index chart repositories ### Synopsis This command consists of multiple subcommands to interact with chart repositories. It can be used to add, remove, list, and index chart repositories. Example usage: $ helm repo add [NAME] [REPO_URL] ### Options ``` -h, --help help for repo ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. * [helm repo add](helm_repo_add.md) - Add a chart repository * [helm repo index](helm_repo_index.md) - Generate an index file given a directory containing packaged charts * [helm repo list](helm_repo_list.md) - List chart repositories * [helm repo remove](helm_repo_remove.md) - Remove a chart repository * [helm repo update](helm_repo_update.md) - Update information of available charts locally from chart repositories ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo_add.md ================================================ --- title: "helm repo add" sidebar_position: 31 sidebar_label: "Helm Repo Add" --- Add a chart repository ### Synopsis Add a chart repository ``` helm repo add [flags] [NAME] [URL] ``` ### Options ``` --ca-file string Verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string Identify HTTPS client using this SSL certificate file -h, --help help for add --key-file string Identify HTTPS client using this SSL key file --no-update Raise error if repo is already registered --password string Chart repository password --username string Chart repository username ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo_index.md ================================================ --- title: "helm repo index" sidebar_position: 32 sidebar_label: "Helm Repo Index" --- Generate an index file given a directory containing packaged charts ### Synopsis Read the current directory and generate an index file based on the charts found. This tool is used for creating an 'index.yaml' file for a chart repository. To set an absolute URL to the charts, use '--url' flag. To merge the generated index with an existing index file, use the '--merge' flag. In this case, the charts found in the current directory will be merged into the existing index, with local charts taking priority over existing charts. ``` helm repo index [flags] [DIR] ``` ### Options ``` -h, --help help for index --merge string Merge the generated index into the given index --url string URL of the chart repository ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo_list.md ================================================ --- title: "helm repo list" sidebar_position: 33 sidebar_label: "Helm Repo List" --- List chart repositories ### Synopsis List chart repositories ``` helm repo list [flags] ``` ### Options ``` -h, --help help for list -o, --output string Prints the output in the specified format. Allowed values: table, json, yaml (default "table") ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 24-Sep-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo_remove.md ================================================ --- title: "helm repo remove" sidebar_position: 34 sidebar_label: "Helm Repo Remove" --- Remove a chart repository ### Synopsis Remove a chart repository ``` helm repo remove [flags] [NAME] ``` ### Options ``` -h, --help help for remove ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_repo_update.md ================================================ --- title: "helm repo update" sidebar_position: 35 sidebar_label: "Helm Repo Update" --- Update information of available charts locally from chart repositories ### Synopsis Update gets the latest information about charts from the respective chart repositories. Information is cached locally, where it is used by commands like 'helm search'. 'helm update' is the deprecated form of 'helm repo update'. It will be removed in future releases. You can specify the name of a repository you want to update. $ helm repo update To update all the repositories, use 'helm repo update'. ``` helm repo update [REPO_NAME] [flags] ``` ### Options ``` -h, --help help for update --strict Fail on update warnings ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm repo](helm_repo.md) - Add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 7-Jun-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_reset.md ================================================ --- title: "helm reset" sidebar_position: 36 sidebar_label: "Helm Reset" --- Uninstalls Tiller from a cluster ### Synopsis This command uninstalls Tiller (the Helm server-side component) from your Kubernetes Cluster and optionally deletes local configuration in $HELM_HOME (default ~/.helm/) ``` helm reset [flags] ``` ### Options ``` -f, --force Forces Tiller uninstall even if there are releases installed, or if Tiller is not in ready state. Releases are not deleted.) -h, --help help for reset --remove-helm-home If set, deletes $HELM_HOME --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_rollback.md ================================================ --- title: "helm rollback" sidebar_position: 37 sidebar_label: "Helm Rollback" --- Rollback a release to a previous revision ### Synopsis This command rolls back a release to a previous revision. The first argument of the rollback command is the name of a release, and the second is a revision (version) number. To see revision numbers, run 'helm history RELEASE'. If you'd like to rollback to the previous release use 'helm rollback [RELEASE] 0'. ``` helm rollback [flags] [RELEASE] [REVISION] ``` ### Options ``` --cleanup-on-fail Allow deletion of new resources created in this rollback when rollback failed --description string Specify a description for the release --dry-run Simulate a rollback --force Force resource update through delete/recreate if needed -h, --help help for rollback --no-hooks Prevent hooks from running during rollback --recreate-pods Performs pods restart for the resource if applicable --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300) --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote --wait If set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_search.md ================================================ --- title: "helm search" sidebar_position: 38 sidebar_label: "Helm Search" --- Search for a keyword in charts ### Synopsis Search reads through all of the repositories configured on the system, and looks for matches. It will display the latest stable versions of the charts found. If you specify the --devel flag, the output will include pre-release versions. If you want to search using a version constraint, use --version. Examples: # Search for stable release versions matching the keyword "nginx" helm search nginx # Search for release versions matching the keyword "nginx", including pre-release versions helm search nginx --devel # Search for the latest stable release for nginx-ingress with a major version of 1 helm search nginx-ingress --version ^1.0.0 Repositories are managed with 'helm repo' commands. To look for charts with a particular name (such as stable/mysql), try searching using vertical tabs (\v). Vertical tabs are used as the delimiter between search fields. For example: helm search --regexp '\vstable/mysql\v' To search for charts using common keywords (such as "database" or "key-value store"), use helm search database or helm search key-value store ``` helm search [keyword] [flags] ``` ### Options ``` --col-width uint Specifies the max column width of output (default 60) --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for search -o, --output string Prints the output in the specified format. Allowed values: table, json, yaml (default "table") -r, --regexp Use regular expressions for searching -v, --version string Search using semantic versioning constraints -l, --versions Show the long listing, with each version of each chart on its own line ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 30-Oct-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_serve.md ================================================ --- title: "helm serve" sidebar_position: 39 sidebar_label: "Helm Serve" --- Start a local http web server ### Synopsis This command starts a local chart repository server that serves charts from a local directory. The new server will provide HTTP access to a repository. By default, it will scan all of the charts in '$HELM_HOME/repository/local' and serve those over the local IPv4 TCP port (default '127.0.0.1:8879'). This command is intended to be used for educational and testing purposes only. It is best to rely on a dedicated web server or a cloud-hosted solution like Google Cloud Storage for production use. See https://github.com/helm/helm/blob/master/docs/chart_repository.md#hosting-chart-repositories for more information on hosting chart repositories in a production setting. ``` helm serve [flags] ``` ### Options ``` --address string Address to listen on (default "127.0.0.1:8879") -h, --help help for serve --repo-path string Local directory path from which to serve charts --url string External URL of chart repository ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_status.md ================================================ --- title: "helm status" sidebar_position: 40 sidebar_label: "Helm Status" --- Displays the status of the named release ### Synopsis This command shows the status of a named release. The status consists of: - last deployment time - k8s namespace in which the release lives - state of the release (can be: UNKNOWN, DEPLOYED, DELETED, SUPERSEDED, FAILED or DELETING) - list of resources that this release consists of, sorted by kind - details on last test suite run, if applicable - additional notes provided by the chart ``` helm status [flags] RELEASE_NAME ``` ### Options ``` -h, --help help for status -o, --output string Prints the output in the specified format. Allowed values: table, json, yaml (default "table") --revision int32 If set, display the status of the named release with revision --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 6-Sep-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_template.md ================================================ --- title: "helm template" sidebar_position: 41 sidebar_label: "Helm Template" --- Locally render templates ### Synopsis Render chart templates locally and display the output. This does not require Tiller. However, any values that would normally be looked up or retrieved in-cluster will be faked locally. Additionally, none of the server-side testing of chart validity (e.g. whether an API is supported) is done. To render just one template in a chart, use '-x': $ helm template mychart -x templates/deployment.yaml ``` helm template [flags] CHART ``` ### Options ``` -a, --api-versions stringArray Kubernetes api versions used for Capabilities.APIVersions -x, --execute stringArray Only execute the given templates -h, --help help for template --is-upgrade Set .Release.IsUpgrade instead of .Release.IsInstall --kube-version string Kubernetes version used as Capabilities.KubeVersion.Major/Minor (default "1.14") -n, --name string Release name (default "release-name") --name-template string Specify template used to name the release --namespace string Namespace to install the release into --notes Show the computed NOTES.txt file as well --output-dir string Writes the executed templates to files in output-dir instead of stdout --set stringArray Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray Set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-string stringArray Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -f, --values valueFiles Specify values in a YAML file (can specify multiple) (default []) ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 3-Oct-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_test.md ================================================ --- title: "helm test" sidebar_position: 42 sidebar_label: "Helm Test" --- Test a release ### Synopsis The test command runs the tests for a release. The argument this command takes is the name of a deployed release. The tests to be run are defined in the chart that was installed. ``` helm test [RELEASE] [flags] ``` ### Options ``` --cleanup Delete test pods upon completion -h, --help help for test --logs Dump the logs from test pods (this runs after all tests are complete, but before any cleanup --max uint32 Maximum number of test pods to run in parallel (default 20) --parallel Run test pods in parallel --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300) --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 8-Oct-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_upgrade.md ================================================ --- title: "helm upgrade" sidebar_position: 43 sidebar_label: "Helm Upgrade" --- Upgrade a release ### Synopsis This command upgrades a release to a specified version of a chart and/or updates chart values. Required arguments are release and chart. The chart argument can be one of: - a chart reference('stable/mariadb'); use '--version' and '--devel' flags for versions other than latest, - a path to a chart directory, - a packaged chart, - a fully qualified URL. To customize the chart values, use any of - '--values'/'-f' to pass in a yaml file holding settings, - '--set' to provide one or more key=val pairs directly, - '--set-string' to provide key=val forcing val to be stored as a string, - '--set-file' to provide key=path to read a single large value from a file at path. To edit or append to the existing customized values, add the '--reuse-values' flag, otherwise any existing customized values are ignored. If no chart value arguments are provided on the command line, any existing customized values are carried forward. If you want to revert to just the values provided in the chart, use the '--reset-values' flag. You can specify any of the chart value flags multiple times. The priority will be given to the last (right-most) value specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis Note that the key name provided to the '--set', '--set-string' and '--set-file' flags can reference structure elements. Examples: - mybool=TRUE - livenessProbe.timeoutSeconds=10 - metrics.annotations[0]=hey,metrics.annotations[1]=ho which sets the top level key mybool to true, the nested timeoutSeconds to 10, and two array values, respectively. Note that the value side of the key=val provided to '--set' and '--set-string' flags will pass through shell evaluation followed by yaml type parsing to produce the final value. This may alter inputs with special characters in unexpected ways, for example $ helm upgrade --set pwd=3jk$o2,z=f\30.e redis ./redis results in "pwd: 3jk" and "z: f30.e". Use single quotes to avoid shell evaluation and argument delimiters, and use backslash to escape yaml special characters: $ helm upgrade --set pwd='3jk$o2z=f\\30.e' redis ./redis which results in the expected "pwd: 3jk$o2z=f\30.e". If a single quote occurs in your value then follow your shell convention for escaping it; for example in bash: $ helm upgrade --set pwd='3jk$o2z=f\\30with'\''quote' which results in "pwd: 3jk$o2z=f\30with'quote". ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Options ``` --atomic If set, upgrade process rolls back changes made in case of failed upgrade, also sets --wait flag --ca-file string Verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string Identify HTTPS client using this SSL certificate file --cleanup-on-fail Allow deletion of new resources created in this upgrade when upgrade failed --description string Specify the description to use for the upgrade, rather than the default --devel Use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. --dry-run Simulate an upgrade --force Force resource update through delete/recreate if needed -h, --help help for upgrade -i, --install If a release by this name doesn't already exist, run an install --key-file string Identify HTTPS client using this SSL key file --keyring string Path to the keyring that contains public signing keys (default "~/.gnupg/pubring.gpg") --namespace string Namespace to install the release into (only used if --install is set). Defaults to the current kube config namespace --no-hooks Disable pre/post upgrade hooks -o, --output string Prints the output in the specified format. Allowed values: table, json, yaml (default "table") --password string Chart repository password where to locate the requested chart --recreate-pods Performs pods restart for the resource if applicable --render-subchart-notes Render subchart notes along with parent --repo string Chart repository url where to locate the requested chart --reset-values When upgrading, reset the values to the ones built into the chart --reuse-values When upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored. --set stringArray Set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray Set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-string stringArray Set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --timeout int Time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300) --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote --username string Chart repository username where to locate the requested chart -f, --values valueFiles Specify values in a YAML file or a URL(can specify multiple) (default []) --verify Verify the provenance of the chart before upgrading --version string Specify the exact chart version to use. If this is not specified, the latest version is used --wait If set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 24-Sep-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_verify.md ================================================ --- title: "helm verify" sidebar_position: 44 sidebar_label: "Helm Verify" --- Verify that a chart at the given path has been signed and is valid ### Synopsis Verify that the given chart has a valid provenance file. Provenance files provide cryptographic verification that a chart has not been tampered with, and was packaged by a trusted provider. This command can be used to verify a local chart. Several other commands provide '--verify' flags that run the same validation. To generate a signed package, use the 'helm package --sign' command. ``` helm verify [flags] PATH ``` ### Options ``` -h, --help help for verify --keyring string Keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/helm/helm_version.md ================================================ --- title: "helm version" sidebar_position: 45 sidebar_label: "Helm Version" --- Print the client/server version information ### Synopsis Show the client and server versions for Helm and tiller. This will print a representation of the client and server versions of Helm and Tiller. The output will look something like this: Client: &version.Version{SemVer:"v2.0.0", GitCommit:"ff52399e51bb880526e9cd0ed8386f6433b74da1", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.0.0", GitCommit:"b0c113dfb9f612a9add796549da66c0d294508a3", GitTreeState:"clean"} - SemVer is the semantic version of the release. - GitCommit is the SHA for the commit that this version was built from. - GitTreeState is "clean" if there are no local code changes when this binary was built, and "dirty" if the binary was built from locally modified code. To print just the client version, use '--client'. To print just the server version, use '--server'. ``` helm version [flags] ``` ### Options ``` -c, --client Client version only -h, --help help for version -s, --server Server version only --short Print the version number --template string Template for version string format --tls Enable TLS for request --tls-ca-cert string Path to TLS CA certificate file (default "$HELM_HOME/ca.pem") --tls-cert string Path to TLS certificate file (default "$HELM_HOME/cert.pem") --tls-hostname string The server name used to verify the hostname on the returned certificates from the server --tls-key string Path to TLS key file (default "$HELM_HOME/key.pem") --tls-verify Enable TLS for request and verify remote ``` ### Options inherited from parent commands ``` --debug Enable verbose output --home string Location of your Helm config. Overrides $HELM_HOME (default "~/.helm") --host string Address of Tiller. Overrides $HELM_HOST --kube-context string Name of the kubeconfig context to use --kubeconfig string Absolute path of the kubeconfig file to be used --tiller-connection-timeout int The duration (in seconds) Helm will wait to establish a connection to Tiller (default 300) --tiller-namespace string Namespace of Tiller (default "kube-system") ``` ### SEE ALSO * [helm](helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 16-May-2019 ================================================ FILE: versioned_docs/version-2/history.md ================================================ --- sidebar_position: 11 sidebar_label: "History" --- ## The History of the Project Kubernetes Helm is the merged result of [Helm Classic](https://github.com/helm/helm) and the Kubernetes port of GCS Deployment Manager. The project was jointly started by Google and Deis, though it is now part of the CNCF. Many companies now contribute regularly to Helm. Differences from Helm Classic: - Helm now has both a client (`helm`) and a server (`tiller`). The server runs inside of Kubernetes, and manages your resources. - Helm's chart format has changed for the better: - Dependencies are immutable and stored inside of a chart's `charts/` directory. - Charts are strongly versioned using [SemVer 2](https://semver.org/spec/v2.0.0.html) - Charts can be loaded from directories or from chart archive files - Helm supports Go templates without requiring you to run `generate` or `template` commands. - Helm makes it easy to configure your releases -- and share the configuration with the rest of your team. - Helm chart repositories now use plain HTTP(S) instead of Git/GitHub. There is no longer any GitHub dependency. - A chart server is a simple HTTP server - Charts are referenced by version - The `helm serve` command will run a local chart server, though you can easily use object storage (S3, GCS) or a regular web server. - And you can still load charts from a local directory. - The Helm workspace is gone. You can now work anywhere on your filesystem that you want to work. ================================================ FILE: versioned_docs/version-2/index.mdx ================================================ --- title: "Docs Home" sidebar_position: 1 --- Complete documentation for Helm v2, the Kubernetes package manager. Learn how to install, configure, and use Helm to deploy applications to your Kubernetes cluster. import DocCardList from "@theme/DocCardList"; ================================================ FILE: versioned_docs/version-2/related.md ================================================ --- sidebar_position: 8 sidebar_label: "Related Projects" --- # Related Projects and Documentation The Helm community has produced many extra tools, plugins, and documentation about Helm. We love to hear about these projects. If you have anything you'd like to add to this list, please open an [issue](https://github.com/helm/helm/issues) or [pull request](https://github.com/helm/helm/pulls). ## Article, Blogs, How-Tos, and Extra Documentation - [Awesome Helm](https://github.com/cdwv/awesome-helm) - List of awesome Helm resources - [CI/CD with Kubernetes, Helm & Wercker ](https://www.slideshare.net/Diacode/cicd-with-kubernetes-helm-wercker-madscalability) - [Creating a Helm Plugin in 3 Steps](http://technosophos.com/2017/03/21/creating-a-helm-plugin.html) - [Deploying Kubernetes Applications with Helm](https://cloudacademy.com/blog/deploying-kubernetes-applications-with-helm/) - [GitLab, Consumer Driven Contracts, Helm and Kubernetes](https://medium.com/@enxebre/gitlab-consumer-driven-contracts-helm-and-kubernetes-b7235a60a1cb#.xwp1y4tgi) - [Honestbee's Helm Chart Conventions](https://gist.github.com/so0k/f927a4b60003cedd101a0911757c605a) - [Releasing backward-incompatible changes: Kubernetes, Jenkins, Prometheus Operator, Helm and Traefik](https://medium.com/@enxebre/releasing-backward-incompatible-changes-kubernetes-jenkins-plugin-prometheus-operator-helm-self-6263ca61a1b1#.e0c7elxhq) - [The Missing CI/CD Kubernetes Component: Helm package manager](https://medium.com/@gajus/the-missing-ci-cd-kubernetes-component-helm-package-manager-1fe002aac680) - [Using Helm to Deploy to Kubernetes](https://daemonza.github.io/2017/02/20/using-helm-to-deploy-to-kubernetes/) - [Writing a Helm Chart](https://www.influxdata.com/packaged-kubernetes-deployments-writing-helm-chart/) - [A basic walk through Kubernetes Helm](https://github.com/muffin87/helm-tutorial) - [Tillerless Helm v2](https://rimusz.net/tillerless-helm/) - [Generating Certificate Authorities and Certificates using Terraform](https://github.com/jbussdieker/tiller-ssl-terraform) ## Video, Audio, and Podcast - [CI/CD with Jenkins, Kubernetes, and Helm](https://www.youtube.com/watch?v=NVoln4HdZOY): AKA "The Infamous Croc Hunter Video". - [Helm with Michelle Noorali and Matthew Butcher](https://gcppodcast.com/post/episode-50-helm-with-michelle-noorali-and-matthew-butcher/): The official Google CloudPlatform Podcast interviews Michelle and Matt about Helm. - [KubeCon2016: Delivering Kubernetes-Native Applications by Michelle Noorali](https://www.youtube.com/watch?v=zBc1goRfk3k&index=49&list=PLj6h78yzYM2PqgIGU1Qmi8nY7dqn9PCr4) ## Helm Plugins - [App Registry](https://github.com/app-registry/helm-plugin) - Plugin to manage charts via the [App Registry specification](https://github.com/app-registry/spec) - [helm-backup](https://github.com/maorfr/helm-backup) - Plugin which performs backup/restore of releases in a namespace to/from a file - [Helm Diff](https://github.com/databus23/helm-diff) - Preview `helm upgrade` as a coloured diff - [Helm Value Store](https://github.com/skuid/helm-value-store) - Plugin for working with Helm deployment values - [Technosophos's Helm Plugins](https://github.com/technosophos/helm-plugins) - Plugins for GitHub, Keybase, and GPG - [helm-convert](https://github.com/ContainerSolutions/helm-convert) - Plugin to convert charts into Kustomize compatible packages - [helm-cos](https://github.com/imroc/helm-cos) - Plugin to manage repositories on Tencent Cloud Object Storage - [helm-edit](https://github.com/mstrzele/helm-edit) - Plugin for editing release's values - [helm-env](https://github.com/adamreese/helm-env) - Plugin to show current environment - [helm-gcs](https://github.com/hayorov/helm-gcs) - Plugin to manage repositories on Google Cloud Storage - [helm-github](https://github.com/sagansystems/helm-github) - Plugin to install Helm Charts from Github repositories - [helm-hashtag](https://github.com/balboah/helm-hashtag) - Plugin for tracking docker tag hash digests as values - [helm-inject](https://github.com/maorfr/helm-inject) - Plugin for injecting additional configurations during release upgrade - [helm-k8comp](https://github.com/cststack/k8comp) - Plugin to create Helm Charts from hiera using k8comp - [helm-last](https://github.com/adamreese/helm-last) - Plugin to show the latest release - [helm-local](https://github.com/adamreese/helm-local) - Plugin to run Tiller as a local daemon - [helm-logs](https://github.com/maorfr/helm-logs) - Plugin to view changed releases over time - [helm-monitor](https://github.com/ContainerSolutions/helm-monitor) - Plugin to monitor a release and rollback based on Prometheus/ElasticSearch query - [helm-nexus](https://github.com/yisiqi/helm-nexus) - Plugin to use Sonatype Nexus OSS as your own charts repository. - [helm-nuke](https://github.com/adamreese/helm-nuke) - Plugin to destroy all releases - [helm-plugin-utils](https://github.com/maorfr/helm-plugin-utils) - Utility functions to be used within Helm plugins - [helm-restore](https://github.com/maorfr/helm-restore) - Plugin to restore a deployed release to its original state - [helm-secrets](https://github.com/futuresimple/helm-secrets) - Plugin to manage and store secrets safely - [helm-ssm](https://github.com/codacy/helm-ssm) - Plugin to inject values coming from AWS SSM parameters on the `values.yaml` file - [helm-stop](https://github.com/IBM/helm-stop) - Plugin for stopping a release pods - [helm-template](https://github.com/technosophos/helm-template) - Debug/render templates client-side - [helm-tiller](https://github.com/adamreese/helm-tiller) - Additional commands to work with Tiller - [helm-tiller-info](https://github.com/maorfr/helm-tiller-info) - Plugin which prints information about Tiller - [helm-unittest](https://github.com/lrills/helm-unittest) - Plugin for unit testing chart locally with YAML - [Tillerless Helm v2](https://github.com/rimusz/helm-tiller) - Helm plugin for using Tiller locally and in CI/CD pipelines We also encourage GitHub authors to use the [helm-plugin](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories) tag on their plugin repositories. ## Additional Tools Tools layered on top of Helm or Tiller. - [AppsCode Swift](https://github.com/appscode/swift) - Ajax friendly Helm Tiller Proxy using [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) - [Armada](https://github.com/att-comdev/armada) - Manage prefixed releases throughout various Kubernetes namespaces, and removes completed jobs for complex deployments. Used by the [Openstack-Helm](https://github.com/openstack/openstack-helm) team. - [ChartMuseum](https://github.com/chartmuseum/chartmuseum) - Helm Chart Repository with support for Amazon S3 and Google Cloud Storage - [Chartify](https://github.com/appscode/chartify) - Generate Helm charts from existing Kubernetes resources. - [Cloudsmith](https://cloudsmith.io/l/helm-repository/) - Fully managed SaaS offering private Helm Chart Repositories - [Codefresh](https://codefresh.io) - Kubernetes native CI/CD and management platform with UI dashboards for managing Helm charts and releases - [Cog](https://github.com/ohaiwalt/cog-helm) - Helm chart to deploy Cog on Kubernetes - [Drone.io Helm Plugin](http://plugins.drone.io/ipedrazas/drone-helm/) - Run Helm inside of the Drone CI/CD system - [Helm Chart Publisher](https://github.com/luizbafilho/helm-chart-publisher) - HTTP API for publishing Helm Charts in an easy way - [Helm.NET](https://github.com/qmfrederik/helm) - A .NET client for Tiller's API - [Helmfile](https://github.com/roboll/helmfile) - Helmfile is a declarative spec for deploying helm charts - [Helmsman](https://github.com/Praqma/helmsman) - Helmsman is a helm-charts-as-code tool which enables installing/upgrading/protecting/moving/deleting releases from version controlled desired state files (described in a simple TOML format). - [Landscaper](https://github.com/Eneco/landscaper/) - "Landscaper takes a set of Helm Chart references with values (a desired state), and realizes this in a Kubernetes cluster." - [Monocular](https://github.com/helm/monocular) - Web UI for Helm Chart repositories - [Orca](https://github.com/nuvo/orca) - Advanced CI\CD tool for Kubernetes and Helm made simple. - [Quay App Registry](https://coreos.com/blog/quay-application-registry-for-kubernetes.html) - Open Kubernetes application registry, including a Helm access client - [Reckoner](https://github.com/reactiveops/reckoner) - Reckoner (formerly Autohelm) is a tool for declarative management of helm releases. Written in python and supports git urls as a source for helm charts. - [Rudder](https://github.com/AcalephStorage/rudder) - RESTful (JSON) proxy for Tiller's API - [Schelm](https://github.com/databus23/schelm) - Render a Helm manifest to a directory - [Shipper](https://github.com/bookingcom/shipper) - Multi-cluster canary or blue-green rollouts using Helm - [VIM-Kubernetes](https://github.com/andrewstuart/vim-kubernetes) - VIM plugin for Kubernetes and Helm ## Helm Included Platforms, distributions, and services that include Helm support. - [Codefresh](https://codefresh.io/) - A CI/CD solution designed specifically for Docker/Kubernetes/Helm. Includes a private Helm repository and graphical dashboards for Helm charts, Helm releases and Helm environments. - [Fabric8](https://fabric8.io) - Integrated development platform for Kubernetes - [Jenkins X](https://jenkins-x.io/) - open source automated CI/CD for Kubernetes which uses Helm for [promoting](https://jenkins-x.io/about/features/#promotion) applications through [environments via GitOps](https://jenkins-x.io/about/features/#environments) - [Kubernetic](https://kubernetic.com/) - Kubernetes Desktop Client - [Qstack](https://qstack.com) ## Misc Grab bag of useful things for Chart authors and Helm users - [Await](https://github.com/saltside/await) - Docker image to "await" different conditions--especially useful for init containers. [More Info](http://blog.slashdeploy.com/2017/02/16/introducing-await/) ================================================ FILE: versioned_docs/version-2/using_helm/install.md ================================================ --- sidebar_position: 1 sidebar_label: "Installing Helm" --- # Installing Helm There are two parts to Helm: The Helm client (`helm`) and the Helm server (Tiller). This guide shows how to install the client, and then proceeds to show two ways to install the server. **IMPORTANT**: If you are responsible for ensuring your cluster is a controlled environment, especially when resources are shared, it is strongly recommended installing Tiller using a secured configuration. For guidance, see [Securing your Helm Installation](securing_installation.md). ## Installing the Helm Client The Helm client can be installed either from source, or from pre-built binary releases. ### From The Helm Project The Helm project provides two ways to fetch and install Helm. These are the official methods to get Helm releases. In addition to that, the Helm community provides methods to install Helm through different package managers. Installation through those methods can be found below the official methods. #### From the Binary Releases Every [release](https://github.com/helm/helm/releases) of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed. 1. Download your [desired version](https://github.com/helm/helm/releases) 2. Unpack it (`tar -zxvf helm-v2.0.0-linux-amd64.tgz`) 3. Find the `helm` binary in the unpacked directory, and move it to its desired destination (`mv linux-amd64/helm /usr/local/bin/helm`) From there, you should be able to run the client: `helm help`. #### From Script Helm now has an installer script that will automatically grab the latest version of the Helm client and [install it locally](https://git.io/get_helm.sh). You can fetch that script, and then execute it locally. It's well documented so that you can read through it and understand what it is doing before you run it. ``` $ curl -LO https://git.io/get_helm.sh $ chmod 700 get_helm.sh $ ./get_helm.sh ``` Yes, you can `curl -L https://git.io/get_helm.sh | bash` that if you want to live on the edge. ### Through Package Managers The Helm community provides the ability to install Helm through operating system package managers. These are not supported by the Helm project and are not considered trusted 3rd parties. #### From Snap (Linux) The Snap package for Helm is maintained by [Snapcrafters](https://github.com/snapcrafters/helm). ``` sudo snap install helm --classic ``` #### From Homebrew (macOS) Members of the Helm community have contributed a Helm formula build to Homebrew. This formula is generally up to date. ``` brew install kubernetes-helm ``` (Note: There is also a formula for emacs-helm, which is a different project.) ### #From Chocolatey or scoop (Windows) Members of the Helm community have contributed a [Helm package](https://chocolatey.org/packages/kubernetes-helm) build to [Chocolatey](https://chocolatey.org/). This package is generally up to date. ``` choco install kubernetes-helm ``` The binary can also be installed via [`scoop`](https://scoop.sh) command-line installer. ``` scoop install helm ``` #### From Apt (Debian/Ubuntu) Members of the Helm community have contributed a [Helm package](https://helm.baltorepo.com/stable/debian/) for Apt. This package is generally up to date. ``` curl https://baltocdn.com/helm/signing.asc | sudo apt-key add - sudo apt-get install apt-transport-https --yes echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm2 ``` ### Development Builds In addition to releases you can download or install development snapshots of Helm. #### From Canary Builds "Canary" builds are versions of the Helm software that are built from the latest master branch. They are not official releases, and may not be stable. However, they offer the opportunity to test the cutting edge features. Canary Helm binaries are stored at [get.helm.sh](https://get.helm.sh). Here are links to the common builds: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) #### From Source (Linux, macOS) Building Helm from source is slightly more work, but is the best way to go if you want to test the latest (pre-release) Helm version. You must have a working Go environment with [glide](https://github.com/Masterminds/glide) installed. ```console $ cd $GOPATH $ mkdir -p src/k8s.io $ cd src/k8s.io $ git clone https://github.com/helm/helm.git $ cd helm $ make bootstrap build ``` The `bootstrap` target will attempt to install dependencies, rebuild the `vendor/` tree, and validate configuration. The `build` target will compile `helm` and place it in `bin/helm`. Tiller is also compiled, and is placed in `bin/tiller`. ## Installing Tiller Tiller, the server portion of Helm, typically runs inside of your Kubernetes cluster. But for development, it can also be run locally, and configured to talk to a remote Kubernetes cluster. ### Special Note for RBAC Users Most cloud providers enable a feature called Role-Based Access Control - RBAC for short. If your cloud provider enables this feature, you will need to create a service account for Tiller with the right roles and permissions to access resources. Check the [Kubernetes Distribution Guide](kubernetes_distros.md) to see if there's any further points of interest on using Helm with your cloud provider. Also check out the guide on [Tiller and Role-Based Access Control](rbac.md) for more information on how to run Tiller in an RBAC-enabled Kubernetes cluster. ### Easy In-Cluster Installation The easiest way to install `tiller` into the cluster is simply to run `helm init`. This will validate that `helm`'s local environment is set up correctly (and set it up if necessary). Then it will connect to whatever cluster `kubectl` connects to by default (`kubectl config view`). Once it connects, it will install `tiller` into the `kube-system` namespace. After `helm init`, you should be able to run `kubectl get pods --namespace kube-system` and see Tiller running. You can explicitly tell `helm init` to... - Install the canary build with the `--canary-image` flag - Install a particular image (version) with `--tiller-image` - Install to a particular cluster with `--kube-context` - Install into a particular namespace with `--tiller-namespace` - Install Tiller with a Service Account with `--service-account` (for [RBAC enabled clusters](securing_installation.md#rbac)) - Install Tiller without mounting a service account with `--automount-service-account false` Once Tiller is installed, running `helm version` should show you both the client and server version. (If it shows only the client version, `helm` cannot yet connect to the server. Use `kubectl` to see if any `tiller` pods are running.) Helm will look for Tiller in the `kube-system` namespace unless `--tiller-namespace` or `TILLER_NAMESPACE` is set. ### Installing Tiller Canary Builds Canary images are built from the `master` branch. They may not be stable, but they offer you the chance to test out the latest features. The easiest way to install a canary image is to use `helm init` with the `--canary-image` flag: ```console $ helm init --canary-image ``` This will use the most recently built container image. You can always uninstall Tiller by deleting the Tiller deployment from the `kube-system` namespace using `kubectl`. ### Running Tiller Locally For development, it is sometimes easier to work on Tiller locally, and configure it to connect to a remote Kubernetes cluster. The process of building Tiller is explained above. Once `tiller` has been built, simply start it: ```console $ bin/tiller Tiller running on :44134 ``` When Tiller is running locally, it will attempt to connect to the Kubernetes cluster that is configured by `kubectl`. (Run `kubectl config view` to see which cluster that is.) You must tell `helm` to connect to this new local Tiller host instead of connecting to the one in-cluster. There are two ways to do this. The first is to specify the `--host` option on the command line. The second is to set the `$HELM_HOST` environment variable. ```console $ export HELM_HOST=localhost:44134 $ helm version # Should connect to localhost. Client: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"db...", GitTreeState:"dirty"} Server: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"a5...", GitTreeState:"dirty"} ``` Importantly, even when running locally, Tiller will store release configuration in ConfigMaps inside of Kubernetes. ## Upgrading Tiller As of Helm 2.2.0, Tiller can be upgraded using `helm init --upgrade`. For older versions of Helm, or for manual upgrades, you can use `kubectl` to modify the Tiller image: ```console $ export TILLER_TAG=v2.0.0-beta.1 # Or whatever version you want $ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=ghcr.io/helm/tiller:$TILLER_TAG deployment "tiller-deploy" image updated ``` Setting `TILLER_TAG=canary` will get the latest snapshot of master. ## Deleting or Reinstalling Tiller Because Tiller stores its data in Kubernetes ConfigMaps, you can safely delete and re-install Tiller without worrying about losing any data. The recommended way of deleting Tiller is with `kubectl delete deployment tiller-deploy --namespace kube-system`, or more concisely `helm reset`. Tiller can then be re-installed from the client with: ```console $ helm init ``` ## Advanced Usage `helm init` provides additional flags for modifying Tiller's deployment manifest before it is installed. ### Using `--node-selectors` The `--node-selectors` flag allows us to specify the node labels required for scheduling the Tiller pod. The example below will create the specified label under the nodeSelector property. ``` helm init --node-selectors "beta.kubernetes.io/os"="linux" ``` The installed deployment manifest will contain our node selector label. ``` ... spec: template: spec: nodeSelector: beta.kubernetes.io/os: linux ... ``` ### Using `--override` `--override` allows you to specify properties of Tiller's deployment manifest. Unlike the `--set` command used elsewhere in Helm, `helm init --override` manipulates the specified properties of the final manifest (there is no "values" file). Therefore you may specify any valid value for any valid property in the deployment manifest. #### Override annotation In the example below we use `--override` to add the revision property and set its value to 1. ``` helm init --override metadata.annotations."deployment\.kubernetes\.io/revision"="1" ``` Output: ``` apiVersion: apps/v1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" ... ``` #### Override affinity In the example below we set properties for node affinity. Multiple `--override` commands may be combined to modify different properties of the same list item. ``` helm init --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].weight"="1" --override "spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution[0].preference.matchExpressions[0].key"="e2e-az-name" ``` The specified properties are combined into the "preferredDuringSchedulingIgnoredDuringExecution" property's first list item. ``` ... spec: strategy: {} template: ... spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - preference: matchExpressions: - key: e2e-az-name operator: "" weight: 1 ... ``` ### Using `--output` The `--output` flag allows us skip the installation of Tiller's deployment manifest and simply output the deployment manifest to stdout in either JSON or YAML format. The output may then be modified with tools like `jq` and installed manually with `kubectl`. In the example below we execute `helm init` with the `--output json` flag. ``` helm init --output json ``` The Tiller installation is skipped and the manifest is output to stdout in JSON format. ``` "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "creationTimestamp": null, "labels": { "app": "helm", "name": "tiller" }, "name": "tiller-deploy", "namespace": "kube-system" }, ... ``` ### Storage backends By default, `tiller` stores release information in `ConfigMaps` in the namespace where it is running. #### Secret storage backend As of Helm 2.7.0, there is now a beta storage backend that uses `Secrets` for storing release information. This was added for additional security in protecting charts in conjunction with the release of `Secret` encryption in Kubernetes. To enable the secrets backend, you'll need to init Tiller with the following options: ```shell helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' ``` Currently, if you want to switch from the default backend to the secrets backend, you'll have to do the migration for this on your own. When this backend graduates from beta, there will be a more official path of migration #### SQL storage backend As of Helm 2.14.0 there is now a beta SQL storage backend that stores release information in an SQL database (only postgres has been tested so far). Using such a storage backend is particularly useful if your release information weighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets because of internal limits in Kubernetes' underlying etcd key-value store). To enable the SQL backend, you'll need to deploy a SQL database and init Tiller with the following options: ```shell helm init \ --override \ 'spec.template.spec.containers[0].args'='{--storage=sql,--sql-dialect=postgres,--sql-connection-string=postgresql://tiller-postgres:5432/helm?user=helm&password=changeme}' ``` **PRODUCTION NOTES**: it's recommended to change the username and password of the SQL database in production deployments. Enabling SSL is also a good idea. Last, but not least, perform regular backups/snapshots of your SQL database. Currently, if you want to switch from the default backend to the SQL backend, you'll have to do the migration for this on your own. When this backend graduates from beta, there will be a more official migration path. ## Conclusion In most cases, installation is as simple as getting a pre-built `helm` binary and running `helm init`. This document covers additional cases for those who want to do more sophisticated things with Helm. Once you have the Helm Client and Tiller successfully installed, you can move on to using Helm to manage charts. ================================================ FILE: versioned_docs/version-2/using_helm/install_faq.md ================================================ --- sidebar_position: 4 sidebar_label: "Install FAQ" --- # Installation: Frequently Asked Questions This section tracks some of the more frequently encountered issues with installing or getting started with Helm. **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm/issues) or send us a pull request. ## Downloading I want to know more about my downloading options. **Q: I can't get to GitHub releases of the newest Helm. Where are they?** Binaries are stored at [get.helm.sh](https://get.helm.sh). **Q: Why aren't there native packages of Helm for Fedora and other Linux distros?** We'd love to provide these or point you toward a trusted provider. If you're interested in helping, we'd love it. This is how the Homebrew formula was started. **Q: Why do you provide a `curl ...|bash` script?** A: There is a script in our repository (`scripts/get`) that can be executed as a `curl ..|bash` script. The transfers are all protected by HTTPS, and the script does some auditing of the packages it fetches. However, the script has all the usual dangers of any shell script. We provide it because it is useful, but we suggest that users carefully read the script first. What we'd really like, though, are better packaged releases of Helm. ## Installing I'm trying to install Helm/Tiller, but something is not right. **Q: How do I put the Helm client files somewhere other than ~/.helm?** Set the `$HELM_HOME` environment variable, and then run `helm init`: ```console export HELM_HOME=/some/path helm init --client-only ``` Note that if you have existing repositories, you will need to re-add them with `helm repo add...`. **Q: How do I configure Helm, but not install Tiller?** A: By default, `helm init` will ensure that the local `$HELM_HOME` is configured, and then install Tiller on your cluster. To locally configure, but not install Tiller, use `helm init --client-only`. **Q: How do I manually install Tiller on the cluster?** A: Tiller is installed as a Kubernetes `deployment`. You can get the manifest by running `helm init --dry-run --debug`, and then manually install it with `kubectl`. It is suggested that you do not remove or change the labels on that deployment, as they are sometimes used by supporting scripts and tools. **Q: Why do I get `Error response from daemon: target is unknown` during Tiller install?** A: Users have reported being unable to install Tiller on Kubernetes instances that are using Docker 1.13.0. The root cause of this was a bug in Docker that made that one version incompatible with images pushed to the Docker registry by earlier versions of Docker. This [issue](https://github.com/docker/docker/issues/30083) was fixed shortly after the release, and is available in Docker 1.13.1-RC1 and later. ## Getting Started I successfully installed Helm/Tiller but I can't use it. **Q: Trying to use Helm, I get the error "client transport was broken"** ``` E1014 02:26:32.885226 16143 portforward.go:329] an error occurred forwarding 37008 -> 44134: error forwarding port 44134 to pod tiller-deploy-2117266891-e4lev_kube-system, uid : unable to do port forwarding: socat not found. 2016/10/14 02:26:32 transport: http2Client.notifyError got notified that the client transport was broken EOF. Error: transport is closing ``` A: This is usually a good indication that Kubernetes is not set up to allow port forwarding. Typically, the missing piece is `socat`. If you are running CoreOS, we have been told that it may have been misconfigured on installation. The CoreOS team recommends reading this: - https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html Here are a few resolved issues that may help you get started: - https://github.com/helm/helm/issues/1371 - https://github.com/helm/helm/issues/966 **Q: Trying to use Helm, I get the error "lookup XXXXX on 8.8.8.8:53: no such host"** ``` Error: Error forwarding ports: error upgrading connection: dial tcp: lookup kube-4gb-lon1-02 on 8.8.8.8:53: no such host ``` A: We have seen this issue with Ubuntu and Kubeadm in multi-node clusters. The issue is that the nodes expect certain DNS records to be obtainable via global DNS. Until this is resolved upstream, you can work around the issue as follows. On each of the control plane nodes: 1) Add entries to `/etc/hosts`, mapping your hostnames to their public IPs 2) Install `dnsmasq` (e.g. `apt install -y dnsmasq`) 3) Remove the k8s api server container (kubelet will recreate it) 4) Then `systemctl restart docker` (or reboot the node) for it to pick up the /etc/resolv.conf changes See this issue for more information: https://github.com/helm/helm/issues/1455 **Q: On GKE (Google Container Engine) I get "No SSH tunnels currently open"** ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Another variation of the error message is: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` A: The issue is that your local Kubernetes config file must have the correct credentials. When you create a cluster on GKE, it will give you credentials, including SSL certificates and certificate authorities. These need to be stored in a Kubernetes config file (Default: `~/.kube/config` so that `kubectl` and `helm` can access them. **Q: When I run a Helm command, I get an error about the tunnel or proxy** A: Helm uses the Kubernetes proxy service to connect to the Tiller server. If the command `kubectl proxy` does not work for you, neither will Helm. Typically, the error is related to a missing `socat` service. **Q: Tiller crashes with a panic** When I run a command on Helm, Tiller crashes with an error like this: ``` Tiller is listening on :44134 Probes server is listening on :44135 Storage driver is ConfigMap Cannot initialize Kubernetes connection: the server has asked for the client to provide credentials 2016-12-20 15:18:40.545739 I | storage.go:37: Getting release "bailing-chinchilla" (v1) from storage panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8053d5] goroutine 77 [running]: panic(0x1abbfc0, 0xc42000a040) /usr/local/go/src/runtime/panic.go:500 +0x1a1 k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned.(*ConfigMaps).Get(0xc4200c6200, 0xc420536100, 0x15, 0x1ca7431, 0x6, 0xc42016b6a0) /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned/configmap.go:58 +0x75 k8s.io/helm/pkg/storage/driver.(*ConfigMaps).Get(0xc4201d6190, 0xc420536100, 0x15, 0xc420536100, 0x15, 0xc4205360c0) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/driver/cfgmaps.go:69 +0x62 k8s.io/helm/pkg/storage.(*Storage).Get(0xc4201d61a0, 0xc4205360c0, 0x12, 0xc400000001, 0x12, 0x0, 0xc420200070) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/storage.go:38 +0x160 k8s.io/helm/pkg/tiller.(*ReleaseServer).uniqName(0xc42002a000, 0x0, 0x0, 0xc42016b800, 0xd66a13, 0xc42055a040, 0xc420558050, 0xc420122001) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:577 +0xd7 k8s.io/helm/pkg/tiller.(*ReleaseServer).prepareRelease(0xc42002a000, 0xc42027c1e0, 0xc42002a001, 0xc42016bad0, 0xc42016ba08) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:630 +0x71 k8s.io/helm/pkg/tiller.(*ReleaseServer).InstallRelease(0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c1e0, 0x0, 0x31a9, 0x31a9) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:604 +0x78 k8s.io/helm/pkg/proto/hapi/services._ReleaseService_InstallRelease_Handler(0x1c51f80, 0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c190, 0x0, 0x0, 0x0, 0x0, 0x0) /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/proto/hapi/services/tiller.pb.go:747 +0x27d k8s.io/helm/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420166150, 0x288cbe8, 0xc420250bd0, 0x0, 0x0) /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:608 +0xc50 k8s.io/helm/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420250bd0) /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:766 +0x6b0 k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc420124710, 0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690) /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:419 +0xab created by k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1 /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:420 +0xa3 ``` A: Check your security settings for Kubernetes. A panic in Tiller is almost always the result of a failure to negotiate with the Kubernetes API server (at which point Tiller can no longer do anything useful, so it panics and exits). Often, this is a result of authentication failing because the Pod in which Tiller is running does not have the right token. To fix this, you will need to change your Kubernetes configuration. Make sure that `--service-account-private-key-file` from `controller-manager` and `--service-account-key-file` from apiserver point to the _same_ x509 RSA key. ## Upgrading My Helm used to work, then I upgrade. Now it is broken. **Q: After upgrade, I get the error "Client version is incompatible". What's wrong?** Tiller and Helm have to negotiate a common version to make sure that they can safely communicate without breaking API assumptions. That error means that the version difference is too great to safely continue. Typically, you need to upgrade Tiller manually for this. The [Installation Guide](install.md) has definitive information about safely upgrading Helm and Tiller. The rules for version numbers are as follows: - Pre-release versions are incompatible with everything else. `Alpha.1` is incompatible with `Alpha.2`. - Patch revisions _are compatible_: 1.2.3 is compatible with 1.2.4 - Minor revisions _are not compatible_: 1.2.0 is not compatible with 1.3.0, though we may relax this constraint in the future. - Major revisions _are not compatible_: 1.0.0 is not compatible with 2.0.0. ## Uninstalling I am trying to remove stuff. **Q: When I delete the Tiller deployment, how come all the releases are still there?** Releases are stored in ConfigMaps inside of the `kube-system` namespace. You will have to manually delete them to get rid of the record, or use ```helm delete --purge```. **Q: I want to delete my local Helm. Where are all its files?** Along with the `helm` binary, Helm stores some files in `$HELM_HOME`, which is located by default in `~/.helm`. ================================================ FILE: versioned_docs/version-2/using_helm/kubernetes_apis.md ================================================ --- sidebar_position: 2 sidebar_label: "Deprecated Kubernetes APIs" --- # Deprecated Kubernetes APIs Kubernetes is an API-driven system and the API evolves over time to reflect the evolving understanding of the problem space. This is common practice across systems and their APIs. An important part of evolving APIs is a good deprecation policy and process to inform users of how changes to APIs are implemented. In other words, consumers of your API need to know in advance and in what release an API will be removed or changed. This removes the element of surprise and breaking changes to consumers. The [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documents how Kubernetes handles the changes to its API versions. The policy for deprecation states the timeframe that API versions will be supported following a deprecation announcement. It is therefore important to be aware of deprecation announcements and know when API versions will be removed, to help minimize the effect. This is an example of an announcement [for the removal of deprecated API versions in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) and was advertised a few months prior to the release. These API versions would have been announced for deprecation prior to this again. This shows that there is a good policy in place which informs consumers of API version support. Helm templates specify a [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) when defining a Kubernetes object, similar to a Kubernetes manifest file. It is specified in the `apiVersion` field of the template and it identifies the API version of the Kubernetes object. This means that Helm users and chart maintainers need to be aware when Kubernetes API versions have been deprecated and in what Kubernetes version they will be removed. ## Chart Maintainers You should audit your charts checking for Kubernetes API versions that are deprecated or are removed in a Kubernetes version. The API versions found as due to be or that are now out of support, should be updated to the supported version and a new version of the chart released. The API version is defined by the `kind` and `apiVersion` fields. For example, here is a removed `Deployment` object API version in Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm Users You should audit the charts that you use (similar to [chart maintainers](#chart-maintainers)) and identify any charts where API versions are deprecated or removed in a Kubernetes version. For the charts identified, you need to check for the latest version of the chart (which has supported API versions) or update the chart yourself. Additionally, you also need to audit any charts deployed (i.e. Helm releases) checking again for any deprecated or removed API versions. This can be done by getting details of a release using the `helm get manifest` command. The means for updating a Helm release to supported APIs depends on your findings as follows: 1. If you find deprecated API versions only then: - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version 2. If you find any API version(s) that is/are removed in a Kubernetes version then: - If you are running a Kubernetes version where the API version(s) are still available (for example, you are on Kubernetes 1.15 and found you use APIs that will be removed in Kubernetes 1.16): - Follow the step 1 procedure - Otherwise (for example, you are already running a Kubernetes version where some API versions reported by `helm get manifest` are no longer available): - You need to edit the release manifest that is stored in the cluster to update the API versions to supported APIs. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details > Note: In all cases of updating a Helm release with supported APIs, you should never rollback the release to a version prior to the release version with the supported APIs. > Recommendation: The best practice is to upgrade releases using deprecated API versions to supported API versions, prior to upgrading to a kubernetes cluster that removes those API versions. If you don't update a release as suggested previously, you will have an error similar to the following when trying to upgrade a release in a Kubernetes version where its API version(s) is/are removed: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm fails in this scenario because it attempts to create a diff patch between the current deployed release (which contains the Kubernetes APIs that are removed in this Kubernetes version) against the chart you are passing with the updated/supported API versions. The underlying reason for failure is that when Kubernetes removes an API version, the Kubernetes Go client library can no longer parse the deprecated objects and Helm therefore fails when calling the library. Helm unfortunately is unable to recover from this situation and is no longer able to manage such a release. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details on how to recover from this scenario. ## Updating API Versions of a Release Manifest The manifest is a property of the Helm release object which is stored in the data field of a ConfigMap (default) or Secret in the cluster. The data field contains a gzipped [protobuf object](../developers.md#grpc-and-protobuf) which is base 64 encoded (there is an additional base 64 encoding for a Secret). There is a Secret/ConfigMap per release version/revision in the namespace of the release. You can use the Helm [mapkubeapis](https://github.com/hickeyma/helm-mapkubeapis) plugin to perform the update of a release to supported APIs. Check out the readme for more details. Alternatively, you can follow these manual steps to perform an update of the API versions of a release manifest. Depending on your configuration you will follow the steps for the ConfigMap or Secret backend. - Prerequisites: - HELM_PROTOBUF_SCHEMA: [Helm protobuf schema](https://github.com/helm/helm/tree/dev-v2/_proto) - PROTOBUF_SCHEMA: [Protobuf base schema](https://github.com/protocolbuffers/protobuf/tree/master/src) - Get the name of the ConfigMap or Secret associated with the latest deployed release: - ConfigMap backend: `kubectl get configmap -l OWNER=TILLER,STATUS=DEPLOYED,NAME= --namespace | awk '{print $1}' | grep -v NAME` - Secrets backend: `kubectl get secret -l OWNER=TILLER,STATUS=DEPLOYED,NAME= --namespace | awk '{print $1}' | grep -v NAME` - Get latest deployed release details: - ConfigMap backend: `kubectl get configmap -n -o yaml > release.yaml` - Secrets backend: `kubectl get secret -n -o yaml > release.yaml` - Backup the release in case you need to restore if something goes wrong: - `cp release.yaml release.bak` - In case of emergency, restore: `kubectl apply -f release.bak -n ` - Decode the release object: - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d | protoc --proto_path ${HELM_PROTOBUF_SCHEMA} --proto_path ${PROTOBUF_SCHEMA} --decode hapi.release.Release ${HELM_PROTOBUF_SCHEMA}/hapi/**/* > release.data.decoded` - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d | protoc --proto_path ${HELM_PROTOBUF_SCHEMA} --proto_path ${PROTOBUF_SCHEMA} --decode hapi.release.Release ${HELM_PROTOBUF_SCHEMA}/hapi/**/* > release.data.decoded` - Change API versions of the manifests. Can use any tool (e.g. editor) to make the changes. This is in the `manifest` field of your decoded release object (`release.data.decoded`) - Encode the release object: - ConfigMap backend: `cat release.data.decoded | protoc --proto_path ${HELM_PROTOBUF_SCHEMA} --proto_path ${PROTOBUF_SCHEMA} --encode hapi.release.Release ${HELM_PROTOBUF_SCHEMA}/hapi/**/* | gzip | base64 --wrap 0` - Secrets backend: `cat release.data.decoded | protoc --proto_path ${HELM_PROTOBUF_SCHEMA} --proto_path ${PROTOBUF_SCHEMA} --encode hapi.release.Release ${HELM_PROTOBUF_SCHEMA}/hapi/**/* | gzip | base64 | base64 --wrap 0` - Replace `data.release` property value in the deployed release file (`release.yaml`) with the new encoded release object - Apply file to namespace: `kubectl apply -f release.yaml -n ` - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version > Note: Ensure to use the `protobuf schema` for the deployed Tiller version, otherwise the decoding might fail ================================================ FILE: versioned_docs/version-2/using_helm/kubernetes_distros.md ================================================ --- sidebar_position: 3 sidebar_label: "Kubernetes Distro Notes" --- # Kubernetes Distribution Guide This document captures information about using Helm in specific Kubernetes environments. We are trying to add more details to this document. Please contribute via Pull Requests if you can. ## MicroK8s Helm can be enabled in [MicroK8s](https://microk8s.io) using the command: `microk8s.enable helm` ## MiniKube Helm is tested and known to work with [minikube](https://github.com/kubernetes/minikube). It requires no additional configuration. ## `scripts/local-cluster` and Hyperkube Hyperkube configured via `scripts/local-cluster.sh` is known to work. For raw Hyperkube you may need to do some manual configuration. ## GKE Google's GKE hosted Kubernetes platform enables RBAC by default. You will need to create a service account for tiller, and use the --service-account flag when initializing the helm server. See [Tiller and role-based access control](https://docs.helm.sh/using_helm/#role-based-access-control) for more information. ## AKS Helm works with [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). If using an RBAC-enabled AKS cluster, you need [a service account and role binding for the Tiller service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm#create-a-service-account). ## IKS Helm works with [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started). IKS cluster enables RBAC by default and this means you will need [a service account and role binding for the Tiller service](https://cloud.ibm.com/docs/containers?topic=containers-helm#public_helm_install). ## Ubuntu with 'kubeadm' Kubernetes bootstrapped with `kubeadm` is known to work on the following Linux distributions: - Arch Linux - Ubuntu 16.04 - Fedora release 25 Some versions of Helm (v2.0.0-beta2) require you to `export KUBECONFIG=/etc/kubernetes/admin.conf` or create a `~/.kube/config`. ## Container Linux by CoreOS Helm requires that kubelet have access to a copy of the `socat` program to proxy connections to the Tiller API. On Container Linux the Kubelet runs inside of a [hyperkube](https://github.com/kubernetes/kubernetes/tree/master/cluster/images/hyperkube) container image that has socat. So, even though Container Linux doesn't ship `socat` the container filesystem running kubelet does have socat. To learn more read the [Kubelet Wrapper](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html) docs. ## Openshift Helm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To learn more read [this blog](https://blog.openshift.com/getting-started-helm-openshift/) post. ## Platform9 Helm Client and Helm Server (Tiller) are pre-installed with [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 provides access to all official Helm charts through the App Catalog UI and native Kubernetes CLI. Additional repositories can be manually added. Further details are available in this [Platform9 App Catalog article](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## DC/OS Helm (both client and server) has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes platform, and requires no additional configuration. ## Kubermatic Helm works in user clusters that are created by Kubermatic without caveats. Since seed cluster can be setup up in different ways Helm support depends on them. ## KubeOne Helm works in clusters that are set up by KubeOne without caveats. ================================================ FILE: versioned_docs/version-2/using_helm/plugins.md ================================================ --- sidebar_position: 5 sidebar_label: "Plugins" --- # The Helm Plugins Guide Helm 2.1.0 introduced the concept of a client-side Helm _plugin_. A plugin is a tool that can be accessed through the `helm` CLI, but which is not part of the built-in Helm codebase. Existing plugins can be found on [related](related.md#helm-plugins) section or by searching [Github](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). This guide explains how to use and create plugins. ## An Overview Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool. Helm plugins have the following features: - They can be added and removed from a Helm installation without impacting the core Helm tool. - They can be written in any programming language. - They integrate with Helm, and will show up in `helm help` and other places. Helm plugins live in `$(helm home)/plugins`. The Helm plugin model is partially modeled on Git's plugin model. To that end, you may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins being the _plumbing_. This is a shorthand way of suggesting that Helm provides the user experience and top level processing logic, while the plugins do the "detail work" of performing a desired action. ## Installing a Plugin Plugins are installed using the `$ helm plugin install ` command. You can pass in a path to a plugin on your local file system or a url of a remote VCS repo. The `helm plugin install` command clones or copies the plugin at the path/url given into `$ (helm home)/plugins` ```console $ helm plugin install https://github.com/technosophos/helm-template ``` If you have a plugin tar distribution, simply untar the plugin into the `$(helm home)/plugins` directory. You can also install tarball plugins directly from url by issuing `helm plugin install http://domain/path/to/plugin.tar.gz` ## Building Plugins In many ways, a plugin is similar to a chart. Each plugin has a top-level directory, and then a `plugin.yaml` file. ``` $(helm home)/plugins/ |- keybase/ | |- plugin.yaml |- keybase.sh ``` In the example above, the `keybase` plugin is contained inside of a directory named `keybase`. It has two files: `plugin.yaml` (required) and an executable script, `keybase.sh` (optional). The core of a plugin is a simple YAML file named `plugin.yaml`. Here is a plugin YAML for a plugin that adds support for Keybase operations: ``` name: "keybase" version: "0.1.0" usage: "Integrate Keybase.io tools with Helm" description: |- This plugin provides Keybase services to Helm. ignoreFlags: false useTunnel: false command: "$HELM_PLUGIN_DIR/keybase.sh" ``` The `name` is the name of the plugin. When Helm executes it plugin, this is the name it will use (e.g. `helm NAME` will invoke this plugin). _`name` should match the directory name._ In our example above, that means the plugin with `name: keybase` should be contained in a directory named `keybase`. Restrictions on `name`: - `name` cannot duplicate one of the existing `helm` top-level commands. - `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`. `version` is the SemVer 2 version of the plugin. `usage` and `description` are both used to generate the help text of a command. The `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a plugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then `--foo` is silently discarded. The `useTunnel` switch indicates that the plugin needs a tunnel to Tiller. This should be set to `true` _anytime a plugin talks to Tiller_. It will cause Helm to open a tunnel, and then set `$TILLER_HOST` to the right local address for that tunnel. But don't worry: if Helm detects that a tunnel is not necessary because Tiller is running locally, it will not create the tunnel. Finally, and most importantly, `command` is the command that this plugin will execute when it is called. Environment variables are interpolated before the plugin is executed. The pattern above illustrates the preferred way to indicate where the plugin program lives. There are some strategies for working with plugin commands: - If a plugin includes an executable, the executable for a `command:` should be packaged in the plugin directory. - The `command:` line will have any environment variables expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin directory. - The command itself is not executed in a shell. So you can't oneline a shell script. - Helm injects lots of configuration into environment variables. Take a look at the environment to see what information is available. - Helm makes no assumptions about the language of the plugin. You can write it in whatever you prefer. - Commands are responsible for implementing specific help text for `-h` and `--help`. Helm will use `usage` and `description` for `helm help` and `helm help myplugin`, but will not handle `helm myplugin --help`. ## Downloader Plugins By default, Helm is able to fetch Charts using HTTP/S. As of Helm 2.4.0, plugins can have a special capability to download Charts from arbitrary sources. Plugins shall declare this special capability in the `plugin.yaml` file (top level): ``` downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` If such plugin is installed, Helm can interact with the repository using the specified protocol scheme by invoking the `command`. The special repository shall be added similarly to the regular ones: `helm repo add favorite myprotocol://example.com/` The rules for the special repos are the same to the regular ones: Helm must be able to download the `index.yaml` file in order to discover and cache the list of available Charts. The defined command will be invoked with the following scheme: `command certFile keyFile caFile full-URL`. The SSL credentials are coming from the repo definition, stored in `$HELM_HOME/repository/repositories.yaml`. Downloader plugin is expected to dump the raw content to stdout and report errors on stderr. The downloader command also supports sub-commands or arguments, allowing you to specify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This is useful if you want to use the same executable for the main plugin command and the downloader command, but with a different sub-command for each. ## Environment Variables When Helm executes a plugin, it passes the outer environment to the plugin, and also injects some additional environment variables. Variables like `KUBECONFIG` are set for the plugin if they are set in the outer environment. The following variables are guaranteed to be set: - `HELM_PLUGIN`: The path to the plugins directory - `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm myplug` will have the short name `myplug`. - `HELM_PLUGIN_DIR`: The directory that contains the plugin. - `HELM_BIN`: The path to the `helm` command (as executed by the user). - `HELM_HOME`: The path to the Helm home. - `HELM_PATH_*`: Paths to important Helm files and directories are stored in environment variables prefixed by `HELM_PATH`. - `TILLER_HOST`: The `domain:port` to Tiller. If a tunnel is created, this will point to the local endpoint for the tunnel. Otherwise, it will point to `$HELM_HOST`, `--host`, or the default host (according to Helm's rules of precedence). While `HELM_HOST` _may_ be set, there is no guarantee that it will point to the correct Tiller instance. This is done to allow plugin developer to access `HELM_HOST` in its raw state when the plugin itself needs to manually configure a connection. ## A Note on `useTunnel` If a plugin specifies `useTunnel: true`, Helm will do the following (in order): 1. Parse global flags and the environment 2. Create the tunnel 3. Set `TILLER_HOST` 4. Execute the plugin 5. Close the tunnel The tunnel is removed as soon as the `command` returns. So, for example, a command cannot background a process and assume that process will be able to use the tunnel. ## A Note on Flag Parsing When executing a plugin, Helm will parse global flags for its own use. Some of these flags are _not_ passed on to the plugin. - `--debug`: If this is specified, `$HELM_DEBUG` is set to `1` - `--home`: This is converted to `$HELM_HOME` - `--host`: This is converted to `$HELM_HOST` - `--kube-context`: This is simply dropped. If your plugin uses `useTunnel`, this is used to set up the tunnel for you. Plugins _should_ display help text and then exit for `-h` and `--help`. In all other cases, plugins may use flags as appropriate. ================================================ FILE: versioned_docs/version-2/using_helm/rbac.md ================================================ --- sidebar_position: 6 sidebar_label: "Role-Based Access Control" --- # Role-based Access Control In Kubernetes, granting a role to an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified. Read more about service account permissions [in the official Kubernetes docs](https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions). Bitnami also has a fantastic guide for [configuring RBAC in your cluster](https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/) that takes you through RBAC basics. This guide is for users who want to restrict Tiller's capabilities to install resources to certain namespaces, or to grant a Helm client running access to a Tiller instance. ## Tiller and Role-based Access Control You can add a service account to Tiller using the `--service-account ` flag while you're configuring Helm. As a prerequisite, you'll have to create a role binding which specifies a [role](https://kubernetes.io/docs/admin/authorization/rbac/#role-and-clusterrole) and a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) name that have been set up in advance. Once you have satisfied the pre-requisite and have a service account with the correct permissions, you'll run a command like this: `helm init --service-account ` ### Example: Service account with cluster-admin role In `rbac-config.yaml`: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system ``` _Note: The cluster-admin role is created by default in a Kubernetes cluster, so you don't have to define it explicitly._ ```console $ kubectl create -f rbac-config.yaml serviceaccount "tiller" created clusterrolebinding "tiller" created $ helm init --service-account tiller --history-max 200 ``` ### Example: Deploy Tiller in a namespace, restricted to deploying resources only in that namespace In the example above, we gave Tiller admin access to the entire cluster. You are not at all required to give Tiller cluster-admin access for it to work. Instead of specifying a ClusterRole or a ClusterRoleBinding, you can specify a Role and RoleBinding to limit Tiller's scope to a particular namespace. ```console $ kubectl create namespace tiller-world namespace "tiller-world" created $ kubectl create serviceaccount tiller --namespace tiller-world serviceaccount "tiller" created ``` Define a Role that allows Tiller to manage all resources in `tiller-world` like in `role-tiller.yaml`: ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-manager namespace: tiller-world rules: - apiGroups: ["", "batch", "extensions", "apps"] resources: ["*"] verbs: ["*"] ``` ```console $ kubectl create -f role-tiller.yaml role "tiller-manager" created ``` In `rolebinding-tiller.yaml`, ```yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-binding namespace: tiller-world subjects: - kind: ServiceAccount name: tiller namespace: tiller-world roleRef: kind: Role name: tiller-manager apiGroup: rbac.authorization.k8s.io ``` ```console $ kubectl create -f rolebinding-tiller.yaml rolebinding "tiller-binding" created ``` Afterwards you can run `helm init` to install Tiller in the `tiller-world` namespace. ```console $ helm init --service-account tiller --tiller-namespace tiller-world $HELM_HOME has been configured at /Users/awesome-user/.helm. Tiller (the Helm server side component) has been installed into your Kubernetes Cluster. $ helm install stable/lamp --tiller-namespace tiller-world --namespace tiller-world NAME: wayfaring-yak LAST DEPLOYED: Mon Aug 7 16:00:16 2017 NAMESPACE: tiller-world STATUS: DEPLOYED RESOURCES: ==> v1/Pod NAME READY STATUS RESTARTS AGE wayfaring-yak-alpine 0/1 ContainerCreating 0 0s ``` ### Example: Deploy Tiller in a namespace, restricted to deploying resources in another namespace In the example above, we gave Tiller admin access to the namespace it was deployed inside. Now, let's limit Tiller's scope to deploy resources in a different namespace! For example, let's install Tiller in the namespace `myorg-system` and allow Tiller to deploy resources in the namespace `myorg-users`. ```console $ kubectl create namespace myorg-system namespace "myorg-system" created $ kubectl create serviceaccount tiller --namespace myorg-system serviceaccount "tiller" created ``` Define a Role that allows Tiller to manage all resources in `myorg-users` like in `role-tiller.yaml`: ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-manager namespace: myorg-users rules: - apiGroups: ["", "batch", "extensions", "apps"] resources: ["*"] verbs: ["*"] ``` ```console $ kubectl create -f role-tiller.yaml role "tiller-manager" created ``` Bind the service account to that role. In `rolebinding-tiller.yaml`, ```yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-binding namespace: myorg-users subjects: - kind: ServiceAccount name: tiller namespace: myorg-system roleRef: kind: Role name: tiller-manager apiGroup: rbac.authorization.k8s.io ``` ```console $ kubectl create -f rolebinding-tiller.yaml rolebinding "tiller-binding" created ``` We'll also need to grant Tiller access to read configmaps in myorg-system so it can store release information. In `role-tiller-myorg-system.yaml`: ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: myorg-system name: tiller-manager rules: - apiGroups: ["", "extensions", "apps"] resources: ["configmaps"] verbs: ["*"] ``` ```console $ kubectl create -f role-tiller-myorg-system.yaml role "tiller-manager" created ``` And the respective role binding. In `rolebinding-tiller-myorg-system.yaml`: ```yaml kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-binding namespace: myorg-system subjects: - kind: ServiceAccount name: tiller namespace: myorg-system roleRef: kind: Role name: tiller-manager apiGroup: rbac.authorization.k8s.io ``` ```console $ kubectl create -f rolebinding-tiller-myorg-system.yaml rolebinding "tiller-binding" created ``` ## Helm and Role-based Access Control When running a Helm client in a pod, in order for the Helm client to talk to a Tiller instance, it will need certain privileges to be granted. Specifically, the Helm client will need to be able to create pods, forward ports and be able to list pods in the namespace where Tiller is running (so it can find Tiller). ### Example: Deploy Helm in a namespace, talking to Tiller in another namespace In this example, we will assume Tiller is running in a namespace called `tiller-world` and that the Helm client is running in a namespace called `helm-world`. By default, Tiller is running in the `kube-system` namespace. In `helm-user.yaml`: ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: helm namespace: helm-world --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: tiller-user namespace: tiller-world rules: - apiGroups: - "" resources: - pods/portforward verbs: - create - apiGroups: - "" resources: - pods verbs: - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: tiller-user-binding namespace: tiller-world roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: tiller-user subjects: - kind: ServiceAccount name: helm namespace: helm-world ``` ```console $ kubectl create -f helm-user.yaml serviceaccount "helm" created role "tiller-user" created rolebinding "tiller-user-binding" created ``` ================================================ FILE: versioned_docs/version-2/using_helm/securing_installation.md ================================================ --- sidebar_position: 8 sidebar_label: "Securing Helm" --- # Securing your Helm Installation Helm is a powerful and flexible package-management and operations tool for Kubernetes. Installing it using the default installation command -- `helm init` -- quickly and easily installs **Tiller**, the server-side component with which Helm corresponds. This default installation applies **_no security configurations_**, however. It's completely appropriate to use this type of installation when you are working against a cluster with no or very few security concerns, such as local development with Minikube or with a cluster that is well-secured in a private network with no data-sharing or no other users or teams. If this is the case, then the default installation is fine, but remember: With great power comes great responsibility. Always use due diligence when deciding to use the default installation. ## Who Needs Security Configurations? For the following types of clusters we strongly recommend that you apply the proper security configurations to Helm and Tiller to ensure the safety of the cluster, the data in it, and the network to which it is connected. - Clusters that are exposed to uncontrolled network environments: either untrusted network actors can access the cluster, or untrusted applications that can access the network environment. - Clusters that are for many people to use -- _multitenant_ clusters -- as a shared environment - Clusters that have access to or use high-value data or networks of any type Often, environments like these are referred to as _production grade_ or _production quality_ because the damage done to any company by misuse of the cluster can be profound for either customers, the company itself, or both. Once the risk of damage becomes high enough, you need to ensure the integrity of your cluster no matter what the actual risk. To configure your installation properly for your environment, you must: - Understand the security context of your cluster - Choose the Best Practices you should apply to your helm installation The following assumes you have a Kubernetes configuration file (a _kubeconfig_ file) or one was given to you to access a cluster. ## Understanding the Security Context of your Cluster `helm init` installs Tiller into the cluster in the `kube-system` namespace and without any RBAC rules applied. This is appropriate for local development and other private scenarios because it enables you to be productive immediately. It also enables you to continue running Helm with existing Kubernetes clusters that do not have role-based access control (RBAC) support until you can move your workloads to a more recent Kubernetes version. There are four main areas to consider when securing a tiller installation: 1. Role-based access control, or RBAC 2. Tiller's gRPC endpoint and its usage by Helm 3. Tiller release information 4. Helm charts ### RBAC Recent versions of Kubernetes employ a [role-based access control (or RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control) system (as do modern operating systems) to help mitigate the damage that can be done if credentials are misused or bugs exist. Even where an identity is hijacked, the identity has only so many permissions to a controlled space. This effectively adds a layer of security to limit the scope of any attack with that identity. Helm and Tiller are designed to install, remove, and modify logical applications that can contain many services interacting together. As a result, often its usefulness involves cluster-wide operations, which in a multitenant cluster means that great care must be taken with access to a cluster-wide Tiller installation to prevent improper activity. Specific users and teams -- developers, operators, system and network administrators -- will need their own portion of the cluster in which they can use Helm and Tiller without risking other portions of the cluster. This means using a Kubernetes cluster with RBAC enabled and Tiller configured to enforce them. For more information about using RBAC in Kubernetes, see [Using RBAC Authorization](rbac.md). #### Tiller and User Permissions Tiller in its current form does not provide a way to map user credentials to specific permissions within Kubernetes. When Tiller is running inside of the cluster, it operates with the permissions of its service account. If no service account name is supplied to Tiller, it runs with the default service account for that namespace. This means that all Tiller operations on that server are executed using the Tiller pod's credentials and permissions. To properly limit what Tiller itself can do, the standard Kubernetes RBAC mechanisms must be attached to Tiller, including Roles and RoleBindings that place explicit limits on what things a Tiller instance can install, and where. This situation may change in the future. While the community has several methods that might address this, at the moment performing actions using the rights of the client, instead of the rights of Tiller, is contingent upon the outcome of the Pod Identity Working Group, which has taken on the task of solving the problem in a general way. ### The Tiller gRPC Endpoint In the default installation the gRPC endpoint that Tiller offers is available inside the cluster (not external to the cluster) without authentication configuration applied. Without applying authentication, any process in the cluster can use the gRPC endpoint to perform operations inside the cluster. In a local or secured private cluster, this enables rapid usage and is normal. (When running outside the cluster, Helm authenticates through the Kubernetes API server to reach Tiller, leveraging existing Kubernetes authentication support.) The following two sub-sections describe options of how to setup Tiller so there isn't an unauthenticated endpoint (i.e. gRPC) in your cluster. #### Enabling TLS (Note that out of the two options, this is the recommended one for Helm 2.) Shared and production clusters -- for the most part -- should use Helm 2.7.2 at a minimum and configure TLS for each Tiller gRPC endpoint to ensure that within the cluster usage of gRPC endpoints is only for the properly authenticated identity for that endpoint (i.e. configure each endpoint to use a separate TLS certificate). Doing so enables any number of Tiller instances to be deployed in any number of namespaces and yet no unauthenticated usage of any gRPC endpoint is possible. Finally, use Helm `init` with the `--tiller-tls-verify` option to install Tiller with TLS enabled and to verify remote certificates, and all other Helm commands should use the `--tls` option. For more information about the proper steps to configure Tiller and use Helm properly with TLS configured, see the [Best Practices](#best-practices-for-securing-helm-and-tiller) section below, and [Using SSL between Helm and Tiller](tiller_ssl.md). When Helm clients are connecting from outside of the cluster, the security between the Helm client and the API server is managed by Kubernetes itself. You may want to ensure that this link is secure. Note that if you are using the TLS configuration recommended above, not even the Kubernetes API server has access to the encrypted messages between the client and Tiller. #### Running Tiller Locally Contrary to the previous [Enabling TLS](#enabling-tls) section, this section does not involve running a tiller server pod in your cluster (for what it's worth, that lines up with the current [helm v3 proposal](https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md)), thus there is no gRPC endpoint (and thus there's no need to create & manage TLS certificates to secure each gRPC endpoint). Steps: - Fetch the latest helm release tarball from the [GitHub release page](https://github.com/helm/helm/releases), and extract and move `helm` and `tiller` somewhere on your `$PATH`. - "Server": Run `tiller --storage=secret`. (Note that `tiller` has a default value of ":44134" for the `--listen` argument.) - Client: In another terminal (and on the same host that the aforementioned `tiller` command was run for the previous bullet): Run `export HELM_HOST=:44134`, and then run `helm` commands as usual. ### Tiller's Release Information For historical reasons, Tiller stores its release information in ConfigMaps. We suggest changing the default to Secrets. Secrets are the Kubernetes accepted mechanism for saving configuration data that is considered sensitive. While secrets don't themselves offer many protections, Kubernetes cluster management software often treats them differently than other objects. Thus, we suggest using secrets to store releases. Enabling this feature currently requires setting the `--storage=secret` flag in the tiller-deploy deployment. This entails directly modifying the deployment or using `helm init --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}'`, as no helm init flag is currently available to do this for you. ### Thinking about Charts Because of the relative longevity of Helm, the Helm chart ecosystem evolved without the immediate concern for cluster-wide control, and especially in the developer space this makes complete sense. However, charts are a kind of package that not only installs containers you may or may not have validated yourself, but it may also install into more than one namespace. As with all shared software, in a controlled or shared environment you must validate all software you install yourself _before_ you install it. If you have secured Tiller with TLS and have installed it with permissions to only one or a subset of namespaces, some charts may fail to install -- but in these environments, that is exactly what you want. If you need to use the chart, you may have to work with the creator or modify it yourself in order to use it securely in a multitenant cluster with proper RBAC rules applied. The `helm template` command renders the chart locally and displays the output. Once vetted, you can use Helm's provenance tools to [ensure the provenance and integrity of charts](../developing_charts/provenance.md) that you use. ### gRPC Tools and Secured Tiller Configurations Many very useful tools use the gRPC interface directly, and having been built against the default installation -- which provides cluster-wide access -- may fail once security configurations have been applied. RBAC policies are controlled by you or by the cluster operator, and either can be adjusted for the tool, or the tool can be configured to work properly within the constraints of specific RBAC policies applied to Tiller. The same may need to be done if the gRPC endpoint is secured: the tools need their own secure TLS configuration in order to use a specific Tiller instance. The combination of RBAC policies and a secured gRPC endpoint configured in conjunction with gRPC tools enables you to control your cluster environment as you should. ## Best Practices for Securing Helm and Tiller The following guidelines reiterate the Best Practices for securing Helm and Tiller and using them correctly. 1. Create a cluster with RBAC enabled 2. Configure each Tiller gRPC endpoint to use a separate TLS certificate 3. Release information should be a Kubernetes Secret 4. Install one Tiller per user, team, or other organizational entity with the `--service-account` flag, Roles, and RoleBindings 5. Use the `--tiller-tls-verify` option with `helm init` and the `--tls` flag with other Helm commands to enforce verification If these steps are followed, an example `helm init` command might look something like this: ```bash $ helm init \ --override 'spec.template.spec.containers[0].command'='{/tiller,--storage=secret}' \ --tiller-tls \ --tiller-tls-verify \ --tiller-tls-cert=cert.pem \ --tiller-tls-key=key.pem \ --tls-ca-cert=ca.pem \ --service-account=accountname ``` This command will start Tiller with strong authentication over gRPC, release information stored in a Kubernetes Secret, and a service account to which RBAC policies have been applied. ================================================ FILE: versioned_docs/version-2/using_helm/tiller_ssl.md ================================================ --- sidebar_position: 7 sidebar_label: "TLS/SSL for Helm and Tiller" --- # Using SSL Between Helm and Tiller This document explains how to create strong SSL/TLS connections between Helm and Tiller. The emphasis here is on creating an internal CA, and using both the cryptographic and identity functions of SSL. > Support for TLS-based auth was introduced in Helm 2.3.0 Configuring SSL is considered an advanced topic, and knowledge of Helm and Tiller is assumed. ## Overview The Tiller authentication model uses client-side SSL certificates. Tiller itself verifies these certificates using a certificate authority. Likewise, the client also verifies Tiller's identity by certificate authority. There are numerous possible configurations for setting up certificates and authorities, but the method we cover here will work for most situations. > As of Helm 2.7.2, Tiller _requires_ that the client certificate be validated > by its CA. In prior versions, Tiller used a weaker validation strategy that > allowed self-signed certificates. In this guide, we will show how to: - Create a private CA that is used to issue certificates for Tiller clients and servers. - Create a certificate for Tiller - Create a certificate for the Helm client - Create a Tiller instance that uses the certificate - Configure the Helm client to use the CA and client-side certificate By the end of this guide, you should have a Tiller instance running that will only accept connections from clients who can be authenticated by SSL certificate. ## Generating Certificate Authorities and Certificates One way to generate SSL CAs is via the `openssl` command line tool. There are many guides and best practices documents available online. This explanation is focused on getting ready within a small amount of time. For production configurations, we urge readers to read [the official documentation](https://www.openssl.org) and consult other resources. There are other alternative ways to generating SSL CAs in addition to `openssl`, for example Terraform. They are not documented here but you can find links to these alternative means in [Related Projects and Documentation](https://helm.sh/docs/related/). ### Generate a Certificate Authority The simplest way to generate a certificate authority is to run two commands: ```console $ openssl genrsa -out ./ca.key.pem 4096 $ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca Enter pass phrase for ca.key.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CO Locality Name (eg, city) []:Boulder Organization Name (eg, company) [Internet Widgits Pty Ltd]:tiller Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:tiller Email Address []:tiller@example.com ``` Note that the data input above is _sample data_. You should customize to your own specifications. The above will generate both a secret key and a CA. Note that these two files are very important. The key in particular should be handled with particular care. Often, you will want to generate an intermediate signing key. For the sake of brevity, we will be signing keys with our root CA. ### Generating Certificates We will be generating two certificates, each representing a type of certificate: - One certificate is for Tiller. You will want one of these _per tiller host_ that you run. - One certificate is for the user. You will want one of these _per helm user_. Since the commands to generate these are the same, we'll be creating both at the same time. The names will indicate their target. First, the Tiller key: ```console $ openssl genrsa -out ./tiller.key.pem 4096 Generating RSA private key, 4096 bit long modulus ..........................................................................................................................................................................................................................................................................................................................++ ............................................................................++ e is 65537 (0x10001) Enter pass phrase for ./tiller.key.pem: Verifying - Enter pass phrase for ./tiller.key.pem: ``` Next, generate the Helm client's key: ```console $ openssl genrsa -out ./helm.key.pem 4096 Generating RSA private key, 4096 bit long modulus .....++ ......................................................................................................................................................................................++ e is 65537 (0x10001) Enter pass phrase for ./helm.key.pem: Verifying - Enter pass phrase for ./helm.key.pem: ``` Again, for production use you will generate one client certificate for each user. Next we need to create certificates from these keys. For each certificate, this is a two-step process of creating a CSR, and then creating the certificate. ```console $ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem Enter pass phrase for tiller.key.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CO Locality Name (eg, city) []:Boulder Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tiller Server Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:tiller-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: ``` And we repeat this step for the Helm client certificate: ```console $ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem # Answer the questions with your client user's info ``` (In rare cases, we've had to add the `-nodes` flag when generating the request.) Now we sign each of these CSRs with the CA certificate we created (adjust the days parameter to suit your requirements): ```console $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 Signature ok subject=/C=US/ST=CO/L=Boulder/O=Tiller Server/CN=tiller-server Getting CA Private Key Enter pass phrase for ca.key.pem: ``` And again for the client certificate: ```console $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem -days 365 ``` At this point, the important files for us are these: ``` # The CA. Make sure the key is kept secret. ca.cert.pem ca.key.pem # The Helm client files helm.cert.pem helm.key.pem # The Tiller server files. tiller.cert.pem tiller.key.pem ``` Now we're ready to move on to the next steps. ## Creating a Custom Tiller Installation Helm includes full support for creating a deployment configured for SSL. By specifying a few flags, the `helm init` command can create a new Tiller installation complete with all of our SSL configuration. To take a look at what this will generate, run this command: ```console $ helm init --dry-run --debug --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem ``` The output will show you a Deployment, a Secret, and a Service. Your SSL information will be preloaded into the Secret, which the Deployment will mount to pods as they start up. If you want to customize the manifest, you can save that output to a file and then use `kubectl create` to load it into your cluster. > We strongly recommend enabling RBAC on your cluster and adding [service accounts](rbac.md) > with RBAC. Otherwise, you can remove the `--dry-run` and `--debug` flags. We also recommend putting Tiller in a non-system namespace (`--tiller-namespace=something`) and enable a service account (`--service-account=somename`). But for this example we will stay with the basics: ```console $ helm init --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem ``` In a minute or two it should be ready. We can check Tiller like this: ```console $ kubectl -n kube-system get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE ... other stuff tiller-deploy 1 1 1 1 2m ``` If there is a problem, you may want to use `kubectl get pods -n kube-system` to find out what went wrong. With the SSL/TLS support, the most common problems all have to do with improperly generated TLS certificates or accidentally swapping the cert and the key. At this point, you should get a _failure_ when you run basic Helm commands: ```console $ helm ls Error: transport is closing ``` This is because your Helm client does not have the correct certificate to authenticate to Tiller. ## Configuring the Helm Client The Tiller server is now running with TLS protection. It's time to configure the Helm client to also perform TLS operations. For a quick test, we can specify our configuration manually. We'll run a normal Helm command (`helm ls`), but with SSL/TLS enabled. ```console helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem ``` This configuration sends our client-side certificate to establish identity, uses the client key for encryption, and uses the CA certificate to validate the remote Tiller's identity. Typing a line that is cumbersome, though. The shortcut is to move the key, cert, and CA into `$HELM_HOME`: ```console $ cp ca.cert.pem $(helm home)/ca.pem $ cp helm.cert.pem $(helm home)/cert.pem $ cp helm.key.pem $(helm home)/key.pem ``` With this, you can simply run `helm ls --tls` to enable TLS. ### Troubleshooting *Running a command, I get `Error: transport is closing`* This is almost always due to a configuration error in which the client is missing a certificate (`--tls-cert`) or the certificate is bad. *I'm using a certificate, but get `Error: remote error: tls: bad certificate`* This means that Tiller's CA cannot verify your certificate. In the examples above, we used a single CA to generate both the client and server certificates. In these examples, the CA has _signed_ the client's certificate. We then load that CA up to Tiller. So when the client certificate is sent to the server, Tiller checks the client certificate against the CA. *If I use `--tls-verify` on the client, I get `Error: x509: certificate is valid for tiller-server, not localhost`* If you plan to use `--tls-verify` on the client, you will need to make sure that the host name that Helm connects to matches the host name on the certificate. In some cases this is awkward, since Helm will connect over localhost, or the FQDN is not available for public resolution. *If I use `--tls-verify` on the client, I get `Error: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs`* By default, the Helm client connects to Tiller via tunnel (i.e. kube proxy) at 127.0.0.1. During the TLS handshake, a target, usually provided as a hostname (e.g. example.com), is checked against the subject and subject alternative names of the certificate (i.e. hostname verification). However, because of the tunnel, the target is an IP address. Therefore, to validate the certificate, the IP address 127.0.0.1 must be listed as an IP subject alternative name (IP SAN) in the Tiller certificate. For example, to list 127.0.0.1 as an IP SAN when generating the Tiller certificate: ```console $ echo subjectAltName=IP:127.0.0.1 > extfile.cnf $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 -extfile extfile.cnf ``` Alternatively, you can override the expected hostname of the tiller certificate using the `--tls-hostname` flag. *If I use `--tls-verify` on the client, I get `Error: x509: certificate has expired or is not yet valid`* Your helm certificate has expired, you need to sign a new certificate using your private key and the CA (and consider increasing the number of days) If your tiller certificate has expired, you'll need to sign a new certificate, base64 encode it and update the Tiller Secret: `kubectl edit secret tiller-secret` ## References - https://github.com/denji/golang-tls - https://www.openssl.org/docs/ - https://jamielinux.com/docs/openssl-certificate-authority/sign-server-and-client-certificates.html ================================================ FILE: versioned_docs/version-2/using_helm/using_helm.md ================================================ --- sidebar_position: 3 sidebar_label: "Using Helm" # This is the index/landing page for this section --- # Quickstart Guide This guide covers how you can quickly get started using Helm. ## Prerequisites The following prerequisites are required for a successful and properly secured use of Helm. 1. A Kubernetes cluster 2. Deciding what security configurations to apply to your installation, if any 3. Installing and configuring Helm and Tiller, the cluster-side service. ### Install Kubernetes or have access to a cluster - You must have Kubernetes installed. For the latest release of Helm, we recommend the latest stable release of Kubernetes, which in most cases is the second-latest minor release. - You should also have a local configured copy of `kubectl`. NOTE: Kubernetes versions prior to 1.6 have limited or no support for role-based access controls (RBAC). Helm will figure out where to install Tiller by reading your Kubernetes configuration file (usually `$HOME/.kube/config`). This is the same file that `kubectl` uses. To find out which cluster Tiller would install to, you can run `kubectl config current-context` or `kubectl cluster-info`. ```console $ kubectl config current-context my-cluster ``` ### Understand your Security Context As with all powerful tools, ensure you are installing it correctly for your scenario. If you're using Helm on a cluster that you completely control, like minikube or a cluster on a private network in which sharing is not a concern, the default installation -- which applies no security configuration -- is fine, and it's definitely the easiest. To install Helm without additional security steps, [install Helm](install.md) and then [initialize Helm](#initialize-helm-and-install-tiller). However, if your cluster is exposed to a larger network or if you share your cluster with others -- production clusters fall into this category -- you must take extra steps to secure your installation to prevent careless or malicious actors from damaging the cluster or its data. To apply configurations that secure Helm for use in production environments and other multi-tenant scenarios, see [Securing a Helm installation](securing_installation.md) If your cluster has Role-Based Access Control (RBAC) enabled, you may want to [configure a service account and rules](rbac.md) before proceeding. ## Install Helm Download a binary release of the Helm client. You can use tools like `homebrew`, or look at [the official releases page](https://github.com/helm/helm/releases). For more details, or for other options, see [the installation guide](install.md). ## Initialize Helm and Install Tiller Once you have Helm ready, you can initialize the local CLI and also install Tiller into your Kubernetes cluster in one step: ```console $ helm init --history-max 200 ``` **TIP:** Setting `--history-max` on helm init is recommended as configmaps and other objects in helm history can grow large in number if not purged by max limit. Without a max history set the history is kept indefinitely, leaving a large number of records for helm and tiller to maintain. This will install Tiller into the Kubernetes cluster you saw with `kubectl config current-context`. **TIP:** Want to install into a different cluster? Use the `--kube-context` flag. **TIP:** When you want to upgrade Tiller, just run `helm init --upgrade`. By default, when Tiller is installed, it does not have authentication enabled. To learn more about configuring strong TLS authentication for Tiller, consult [the Tiller TLS guide](tiller_ssl.md). ## Install an Example Chart To install a chart, you can run the `helm install` command. Helm has several ways to find and install a chart, but the easiest is to use one of the official `stable` charts. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install stable/mysql NAME: wintering-rodent LAST DEPLOYED: Thu Oct 18 14:21:18 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME AGE wintering-rodent-mysql 0s ==> v1/ConfigMap wintering-rodent-mysql-test 0s ==> v1/PersistentVolumeClaim wintering-rodent-mysql 0s ==> v1/Service wintering-rodent-mysql 0s ==> v1beta1/Deployment wintering-rodent-mysql 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE wintering-rodent-mysql-6986fd6fb-988x7 0/1 Pending 0 0s NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: wintering-rodent-mysql.default.svc.cluster.local To get your root password run: MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo) To connect to your database: 1. Run an Ubuntu pod that you can use as a client: kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il 2. Install the mysql client: $ apt-get update && apt-get install mysql-client -y 3. Connect using the mysql cli, then provide your password: $ mysql -h wintering-rodent-mysql -p To connect to your database directly from outside the K8s cluster: MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 # Execute the following command to route the connection: kubectl port-forward svc/wintering-rodent-mysql 3306 mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD} ``` In the example above, the `stable/mysql` chart was released, and the name of our new release is `wintering-rodent`. You get a simple idea of the features of this MySQL chart by running `helm inspect stable/mysql`. Whenever you install a chart, a new release is created. So one chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded. The `helm install` command is a very powerful command with many capabilities. To learn more about it, check out the [Using Helm Guide](using_helm.md) ## Learn About Releases It's easy to see what has been released using Helm: ```console $ helm ls NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE wintering-rodent 1 Thu Oct 18 15:06:58 2018 DEPLOYED mysql-0.10.1 5.7.14 default ``` The `helm list` function will show you a list of all deployed releases. ## Uninstall a Release To uninstall a release, use the `helm delete` command: ```console $ helm delete wintering-rodent release "wintering-rodent" deleted ``` This will uninstall `wintering-rodent` from Kubernetes, but you will still be able to request information about that release: ```console $ helm status wintering-rodent LAST DEPLOYED: Thu Oct 18 14:21:18 2018 NAMESPACE: default STATUS: DELETED NOTES: MySQL can be accessed via port 3306 on the following DNS name from within your cluster: wintering-rodent-mysql.default.svc.cluster.local To get your root password run: MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default wintering-rodent-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo) To connect to your database: 1. Run an Ubuntu pod that you can use as a client: kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il 2. Install the mysql client: $ apt-get update && apt-get install mysql-client -y 3. Connect using the mysql cli, then provide your password: $ mysql -h wintering-rodent-mysql -p To connect to your database directly from outside the K8s cluster: MYSQL_HOST=127.0.0.1 MYSQL_PORT=3306 # Execute the following command to route the connection: kubectl port-forward svc/wintering-rodent-mysql 3306 mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD} ``` Because Helm tracks your releases even after you've deleted them, you can audit a cluster's history, and even undelete a release (with `helm rollback`). ## Reading the Help Text To learn more about the available Helm commands, use `helm help` or type a command followed by the `-h` flag: ```console $ helm get -h ``` ================================================ FILE: versioned_docs/version-3/chart_best_practices/conventions.md ================================================ --- title: General Conventions description: General conventions for charts. sidebar_position: 1 --- This part of the Best Practices Guide explains general conventions. ## Chart Names Chart names must be lower case letters and numbers. Words _may_ be separated with dashes (-): Examples: ``` drupal nginx-lego aws-cluster-autoscaler ``` Neither uppercase letters nor underscores can be used in chart names. Dots should not be used in chart names. ## Version Numbers Wherever possible, Helm uses [SemVer 2](https://semver.org) to represent version numbers. (Note that Docker image tags do not necessarily follow SemVer, and are thus considered an unfortunate exception to the rule.) When SemVer versions are stored in Kubernetes labels, we conventionally alter the `+` character to an `_` character, as labels do not allow the `+` sign as a value. ## Formatting YAML YAML files should be indented using _two spaces_ (and never tabs). ## Usage of the Words Helm and Chart There are a few conventions for using the words _Helm_ and _helm_. - _Helm_ refers to the project as a whole - `helm` refers to the client-side command - The term `chart` does not need to be capitalized, as it is not a proper noun - However, `Chart.yaml` does need to be capitalized because the file name is case sensitive When in doubt, use _Helm_ (with an uppercase 'H'). ## Chart templates and namespaces Avoid defining the `namespace` property in the `metadata` section of your chart templates. The namespace to apply rendered templates to should be specified in the call to a Kubernetes client via the flag like `--namespace`. Helm is rendering your templates as-is and sending them off to the Kubernetes client, whether it be Helm itself or another program (kubectl, flux, spinnaker, etc). ================================================ FILE: versioned_docs/version-3/chart_best_practices/custom_resource_definitions.md ================================================ --- title: Custom Resource Definitions description: How to handle creating and using CRDs. sidebar_position: 7 --- This section of the Best Practices Guide deals with creating and using Custom Resource Definition objects. When working with Custom Resource Definitions (CRDs), it is important to distinguish two different pieces: - There is a declaration of a CRD. This is the YAML file that has the kind `CustomResourceDefinition` - Then there are resources that _use_ the CRD. Say a CRD defines `foo.example.com/v1`. Any resource that has `apiVersion: example.com/v1` and kind `Foo` is a resource that uses the CRD. ## Install a CRD Declaration Before Using the Resource Helm is optimized to load as many resources into Kubernetes as fast as possible. By design, Kubernetes can take an entire set of manifests and bring them all online (this is called the reconciliation loop). But there's a difference with CRDs. For a CRD, the declaration must be registered before any resources of that CRDs kind(s) can be used. And the registration process sometimes takes a few seconds. ### Method 1: Let `helm` Do It For You With the arrival of Helm 3, we removed the old `crd-install` hooks for a more simple methodology. There is now a special directory called `crds` that you can create in your chart to hold your CRDs. These CRDs are not templated, but will be installed by default when running a `helm install` for the chart. If the CRD already exists, it will be skipped with a warning. If you wish to skip the CRD installation step, you can pass the `--skip-crds` flag. #### Some caveats (and explanations) There is no support at this time for upgrading or deleting CRDs using Helm. This was an explicit decision after much community discussion due to the danger for unintentional data loss. Furthermore, there is currently no community consensus around how to handle CRDs and their lifecycle. As this evolves, Helm will add support for those use cases. The `--dry-run` flag of `helm install` and `helm upgrade` is not currently supported for CRDs. The purpose of "Dry Run" is to validate that the output of the chart will actually work if sent to the server. But CRDs are a modification of the server's behavior. Helm cannot install the CRD on a dry run, so the discovery client will not know about that Custom Resource (CR), and validation will fail. You can alternatively move the CRDs to their own chart or use `helm template` instead. Another important point to consider in the discussion around CRD support is how the rendering of templates is handled. One of the distinct disadvantages of the `crd-install` method used in Helm 2 was the inability to properly validate charts due to changing API availability (a CRD is actually adding another available API to your Kubernetes cluster). If a chart installed a CRD, `helm` no longer had a valid set of API versions to work against. This is also the reason behind removing templating support from CRDs. With the new `crds` method of CRD installation, we now ensure that `helm` has completely valid information about the current state of the cluster. ### Method 2: Separate Charts Another way to do this is to put the CRD definition in one chart, and then put any resources that use that CRD in _another_ chart. In this method, each chart must be installed separately. However, this workflow may be more useful for cluster operators who have admin access to a cluster ================================================ FILE: versioned_docs/version-3/chart_best_practices/dependencies.md ================================================ --- title: Dependencies description: Covers best practices for Chart dependencies. sidebar_position: 4 --- This section of the guide covers best practices for `dependencies` declared in `Chart.yaml`. ## Versions Where possible, use version ranges instead of pinning to an exact version. The suggested default is to use a patch-level version match: ```yaml version: ~1.2.3 ``` This will match version `1.2.3` and any patches to that release. In other words, `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0` For the complete version matching syntax, please see the [semver documentation](https://github.com/Masterminds/semver#checking-version-constraints). ### Prerelease versions The above versioning constraints will not match on pre-release versions. For example `version: ~1.2.3` will match `version: ~1.2.4` but not `version: ~1.2.3-1`. The following provides a pre-release as well as patch-level matching: ```yaml version: ~1.2.3-0 ``` ### Repository URLs Where possible, use `https://` repository URLs, followed by `http://` URLs. If the repository has been added to the repository index file, the repository name can be used as an alias of URL. Use `alias:` or `@` followed by repository names. File URLs (`file://...`) are considered a "special case" for charts that are assembled by a fixed deployment pipeline. When using [downloader plugins](/topics/plugins.md#downloader-plugins) the URL scheme will be specific to the plugin. Note, a user of the chart will need to have a plugin supporting the scheme installed to update or build the dependency. Helm cannot perform dependency management operations on the dependency when the `repository` field is left blank. In that case Helm will assume the dependency is in a sub-directory of the `charts` folder with the name being the same as the `name` property for the dependency. ## Conditions and Tags Conditions or tags should be added to any dependencies that _are optional_. Note that by default a `condition` is `true`. The preferred form of a condition is: ```yaml condition: somechart.enabled ``` Where `somechart` is the chart name of the dependency. When multiple subcharts (dependencies) together provide an optional or swappable feature, those charts should share the same tags. For example, if both `nginx` and `memcached` together provide performance optimizations for the main app in the chart, and are required to both be present when that feature is enabled, then they should both have a tags section like this: ```yaml tags: - webaccelerator ``` This allows a user to turn that feature on and off with one tag. ================================================ FILE: versioned_docs/version-3/chart_best_practices/index.mdx ================================================ --- title: Best Practices sidebar: true sidebar_position: 4 --- # The Chart Best Practices Guide This guide covers the Helm Team's considered best practices for creating charts. It focuses on how charts should be structured. We focus primarily on best practices for charts that may be publicly deployed. We know that many charts are for internal-use only, and authors of such charts may find that their internal interests override our suggestions here. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/chart_best_practices/labels.md ================================================ --- title: Labels and Annotations description: Covers best practices for using labels and annotations in your Chart. sidebar_position: 5 --- This part of the Best Practices Guide discusses the best practices for using labels and annotations in your chart. ## Is it a Label or an Annotation? An item of metadata should be a label under the following conditions: - It is used by Kubernetes to identify this resource - It is useful to expose to operators for the purpose of querying the system. For example, we suggest using `helm.sh/chart: NAME-VERSION` as a label so that operators can conveniently find all of the instances of a particular chart to use. If an item of metadata is not used for querying, it should be set as an annotation instead. Helm hooks are always annotations. ## Standard Labels The following table defines common labels that Helm charts use. Helm itself never requires that a particular label be present. Labels that are marked REC are recommended, and _should_ be placed onto a chart for global consistency. Those marked OPT are optional. These are idiomatic or commonly in use, but are not relied upon frequently for operational purposes. Name|Status|Description -----|------|---------- `app.kubernetes.io/name` | REC | This should be the app name, reflecting the entire app. Usually `{{ template "name" . }}` is used for this. This is used by many Kubernetes manifests, and is not Helm-specific. `helm.sh/chart` | REC | This should be the chart name and version: `{{ .Chart.Name }}-{{ .Chart.Version \| replace "+" "_" }}`. `app.kubernetes.io/managed-by` | REC | This should always be set to `{{ .Release.Service }}`. It is for finding all things managed by Helm. `app.kubernetes.io/instance` | REC | This should be the `{{ .Release.Name }}`. It aids in differentiating between different instances of the same application. `app.kubernetes.io/version` | OPT | The version of the app and can be set to `{{ .Chart.AppVersion }}`. `app.kubernetes.io/component` | OPT | This is a common label for marking the different roles that pieces may play in an application. For example, `app.kubernetes.io/component: frontend`. `app.kubernetes.io/part-of` | OPT | When multiple charts or pieces of software are used together to make one application. For example, application software and a database to produce a website. This can be set to the top level application being supported. You can find more information on the Kubernetes labels, prefixed with `app.kubernetes.io`, in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). ================================================ FILE: versioned_docs/version-3/chart_best_practices/pods.md ================================================ --- title: Pods and PodTemplates description: Discusses formatting the Pod and PodTemplate portions in Chart manifests. sidebar_position: 6 --- This part of the Best Practices Guide discusses formatting the Pod and PodTemplate portions in chart manifests. The following (non-exhaustive) list of resources use PodTemplates: - Deployment - ReplicationController - ReplicaSet - DaemonSet - StatefulSet ## Images A container image should use a fixed tag or the SHA of the image. It should not use the tags `latest`, `head`, `canary`, or other tags that are designed to be "floating". Images _may_ be defined in the `values.yaml` file to make it easy to swap out images. ```yaml image: {{ .Values.redisImage | quote }} ``` An image and a tag _may_ be defined in `values.yaml` as two separate fields: ```yaml image: "{{ .Values.redisImage }}:{{ .Values.redisTag }}" ``` ## ImagePullPolicy `helm create` sets the `imagePullPolicy` to `IfNotPresent` by default by doing the following in your `deployment.yaml`: ```yaml imagePullPolicy: {{ .Values.image.pullPolicy }} ``` And `values.yaml`: ```yaml image: pullPolicy: IfNotPresent ``` Similarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is not defined at all. If you want a value other than `IfNotPresent`, simply update the value in `values.yaml` to your desired value. ## PodTemplates Should Declare Selectors All PodTemplate sections should specify a selector. For example: ```yaml selector: matchLabels: app.kubernetes.io/name: MyName template: metadata: labels: app.kubernetes.io/name: MyName ``` This is a good practice because it makes the relationship between the set and the pod. But this is even more important for sets like Deployment. Without this, the _entire_ set of labels is used to select matching pods, and this will break if you use labels that change, like version or release date. ================================================ FILE: versioned_docs/version-3/chart_best_practices/rbac.md ================================================ --- title: Role-Based Access Control description: Discusses the creation and formatting of RBAC resources in Chart manifests. sidebar_position: 8 --- This part of the Best Practices Guide discusses the creation and formatting of RBAC resources in chart manifests. RBAC resources are: - ServiceAccount (namespaced) - Role (namespaced) - ClusterRole - RoleBinding (namespaced) - ClusterRoleBinding ## YAML Configuration RBAC and ServiceAccount configuration should happen under separate keys. They are separate things. Splitting these two concepts out in the YAML disambiguates them and makes this clearer. ```yaml rbac: # Specifies whether RBAC resources should be created create: true serviceAccount: # Specifies whether a ServiceAccount should be created create: true # The name of the ServiceAccount to use. # If not set and create is true, a name is generated using the fullname template name: ``` This structure can be extended for more complex charts that require multiple ServiceAccounts. ```yaml someComponent: serviceAccount: create: true name: anotherComponent: serviceAccount: create: true name: ``` ## RBAC Resources Should be Created by Default `rbac.create` should be a boolean value controlling whether RBAC resources are created. The default should be `true`. Users who wish to manage RBAC access controls themselves can set this value to `false` (in which case see below). ## Using RBAC Resources `serviceAccount.name` should be set to the name of the ServiceAccount to be used by access-controlled resources created by the chart. If `serviceAccount.create` is true, then a ServiceAccount with this name should be created. If the name is not set, then a name is generated using the `fullname` template, If `serviceAccount.create` is false, then it should not be created, but it should still be associated with the same resources so that manually-created RBAC resources created later that reference it will function correctly. If `serviceAccount.create` is false and the name is not specified, then the default ServiceAccount is used. The following helper template should be used for the ServiceAccount. ```yaml {{/* Create the name of the service account to use */}} {{- define "mychart.serviceAccountName" -}} {{- if .Values.serviceAccount.create -}} {{ default (include "mychart.fullname" .) .Values.serviceAccount.name }} {{- else -}} {{ default "default" .Values.serviceAccount.name }} {{- end -}} {{- end -}} ``` ================================================ FILE: versioned_docs/version-3/chart_best_practices/templates.md ================================================ --- title: Templates description: A closer look at best practices surrounding templates. sidebar_position: 3 --- This part of the Best Practices Guide focuses on templates. ## Structure of `templates/` The `templates/` directory should be structured as follows: - Template files should have the extension `.yaml` if they produce YAML output. The extension `.tpl` may be used for template files that produce no formatted content. - Template file names should use dashed notation (`my-example-configmap.yaml`), not camelcase. - Each resource definition should be in its own template file. - Template file names should reflect the resource kind in the name. e.g. `foo-pod.yaml`, `bar-svc.yaml` ## Names of Defined Templates Defined templates (templates created inside a `{{ define }} ` directive) are globally accessible. That means that a chart and all of its subcharts will have access to all of the templates created with `{{ define }}`. For that reason, _all defined template names should be namespaced._ Correct: ```yaml {{- define "nginx.fullname" }} {{/* ... */}} {{ end -}} ``` Incorrect: ```yaml {{- define "fullname" -}} {{/* ... */}} {{ end -}} ``` It is highly recommended that new charts are created via `helm create` command as the template names are automatically defined as per this best practice. ## Formatting Templates Templates should be indented using _two spaces_ (never tabs). Template directives should have whitespace after the opening braces and before the closing braces: Correct: ``` {{ .foo }} {{ print "foo" }} {{- print "bar" -}} ``` Incorrect: ``` {{.foo}} {{print "foo"}} {{-print "bar"-}} ``` Templates should chomp whitespace where possible: ```yaml foo: {{- range .Values.items }} {{ . }} {{ end -}} ``` Blocks (such as control structures) may be indented to indicate flow of the template code. ``` {{ if $foo -}} {{- with .Bar }}Hello{{ end -}} {{- end -}} ``` However, since YAML is a whitespace-oriented language, it is often not possible for code indentation to follow that convention. ## Whitespace in Generated Templates It is preferable to keep the amount of whitespace in generated templates to a minimum. In particular, numerous blank lines should not appear adjacent to each other. But occasional empty lines (particularly between logical sections) is fine. This is best: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` This is okay: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` But this should be avoided: ```yaml apiVersion: batch/v1 kind: Job metadata: name: example labels: first: first second: second ``` ## Comments (YAML Comments vs. Template Comments) Both YAML and Helm Templates have comment markers. YAML comments: ```yaml # This is a comment type: sprocket ``` Template Comments: ```yaml {{- /* This is a comment. */}} type: frobnitz ``` Template comments should be used when documenting features of a template, such as explaining a defined template: ```yaml {{- /* mychart.shortname provides a 6 char truncated version of the release name. */}} {{ define "mychart.shortname" -}} {{ .Release.Name | trunc 6 }} {{- end -}} ``` Inside of templates, YAML comments may be used when it is useful for Helm users to (possibly) see the comments during debugging. ```yaml # This may cause problems if the value is more than 100Gi memory: {{ .Values.maxMem | quote }} ``` The comment above is visible when the user runs `helm install --debug`, while comments specified in `{{- /* */}}` sections are not. Beware of adding `#` YAML comments on template sections containing Helm values that may be required by certain template functions. For example, if `required` function is introduced to the above example, and `maxMem` is unset, then a `#` YAML comment will introduce a rendering error. Correct: `helm template` does not render this block ```yaml {{- /* # This may cause problems if the value is more than 100Gi memory: {{ required "maxMem must be set" .Values.maxMem | quote }} */ -}} ``` Incorrect: `helm template` returns `Error: execution error at (templates/test.yaml:2:13): maxMem must be set` ```yaml # This may cause problems if the value is more than 100Gi # memory: {{ required .Values.maxMem "maxMem must be set" | quote }} ``` Review [Debugging Templates](/chart_template_guide/debugging.md) for another example of this behavior of how YAML comments are left intact. ## Use of JSON in Templates and Template Output YAML is a superset of JSON. In some cases, using a JSON syntax can be more readable than other YAML representations. For example, this YAML is closer to the normal YAML method of expressing lists: ```yaml arguments: - "--dirname" - "/foo" ``` But it is easier to read when collapsed into a JSON list style: ```yaml arguments: ["--dirname", "/foo"] ``` Using JSON for increased legibility is good. However, JSON syntax should not be used for representing more complex constructs. When dealing with pure JSON embedded inside of YAML (such as init container configuration), it is of course appropriate to use the JSON format. ================================================ FILE: versioned_docs/version-3/chart_best_practices/values.md ================================================ --- title: Values description: Focuses on how you should structure and use your values. sidebar_position: 2 --- This part of the best practices guide covers using values. In this part of the guide, we provide recommendations on how you should structure and use your values, with focus on designing a chart's `values.yaml` file. ## Naming Conventions Variable names should begin with a lowercase letter, and words should be separated with camelcase: Correct: ```yaml chicken: true chickenNoodleSoup: true ``` Incorrect: ```yaml Chicken: true # initial caps may conflict with built-ins chicken-noodle-soup: true # do not use hyphens in the name ``` Note that all of Helm's built-in variables begin with an uppercase letter to easily distinguish them from user-defined values: `.Release.Name`, `.Capabilities.KubeVersion`. ## Flat or Nested Values YAML is a flexible format, and values may be nested deeply or flattened. Nested: ```yaml server: name: nginx port: 80 ``` Flat: ```yaml serverName: nginx serverPort: 80 ``` In most cases, flat should be favored over nested. The reason for this is that it is simpler for template developers and users. For optimal safety, a nested value must be checked at every level: ``` {{ if .Values.server }} {{ default "none" .Values.server.name }} {{ end }} ``` For every layer of nesting, an existence check must be done. But for flat configuration, such checks can be skipped, making the template easier to read and use. ``` {{ default "none" .Values.serverName }} ``` When there are a large number of related variables, and at least one of them is non-optional, nested values may be used to improve readability. ## Make Types Clear YAML's type coercion rules are sometimes counterintuitive. For example, `foo: false` is not the same as `foo: "false"`. Large integers like `foo: 12345678` will get converted to scientific notation in some cases. The easiest way to avoid type conversion errors is to be explicit about strings, and implicit about everything else. Or, in short, _quote all strings_. Often, to avoid the integer casting issues, it is advantageous to store your integers as strings as well, and use `{{ int $value }}` in the template to convert from a string back to an integer. In most cases, explicit type tags are respected, so `foo: !!string 1234` should treat `1234` as a string. _However_, the YAML parser consumes tags, so the type data is lost after one parse. ## Consider How Users Will Use Your Values There are three potential sources of values: - A chart's `values.yaml` file - A values file supplied by `helm install -f` or `helm upgrade -f` - The values passed to a `--set` or `--set-string` flag on `helm install` or `helm upgrade` When designing the structure of your values, keep in mind that users of your chart may want to override them via either the `-f` flag or with the `--set` option. Since `--set` is more limited in expressiveness, the first guidelines for writing your `values.yaml` file is _make it easy to override from `--set`_. For this reason, it's often better to structure your values file using maps. Difficult to use with `--set`: ```yaml servers: - name: foo port: 80 - name: bar port: 81 ``` The above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5, accessing the port on foo is `--set servers[0].port=80`. Not only is it harder for the user to figure out, but it is prone to errors if at some later time the order of the `servers` is changed. Easy to use: ```yaml servers: foo: port: 80 bar: port: 81 ``` Accessing foo's port is much more obvious: `--set servers.foo.port=80`. ## Document `values.yaml` Every defined property in `values.yaml` should be documented. The documentation string should begin with the name of the property that it describes, and then give at least a one-sentence description. Incorrect: ```yaml # the host name for the webserver serverHost: example serverPort: 9191 ``` Correct: ```yaml # serverHost is the host name for the webserver serverHost: example # serverPort is the HTTP listener port for the webserver serverPort: 9191 ``` Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation, and will enable documentation tools to reliably correlate doc strings with the parameters they describe. ================================================ FILE: versioned_docs/version-3/chart_template_guide/accessing_files.md ================================================ --- title: Accessing Files Inside Templates description: How to access files from within a template. sidebar_position: 10 --- In the previous section we looked at several ways to create and access named templates. This makes it easy to import one template from within another template. But sometimes it is desirable to import a _file that is not a template_ and inject its contents without sending the contents through the template renderer. Helm provides access to files through the `.Files` object. Before we get going with the template examples, though, there are a few things to note about how this works: - It is okay to add extra files to your Helm chart. These files will be bundled. Be careful, though. Charts must be smaller than 1M because of the storage limitations of Kubernetes objects. - Some files cannot be accessed through the `.Files` object, usually for security reasons. - Files in `templates/` cannot be accessed. - Files excluded using `.helmignore` cannot be accessed. - Files outside of a Helm application [subchart](/chart_template_guide/subcharts_and_globals.md), including those of the parent, cannot be accessed - Charts do not preserve UNIX mode information, so file-level permissions will have no impact on the availability of a file when it comes to the `.Files` object. - [Basic example](#basic-example) - [Path helpers](#path-helpers) - [Glob patterns](#glob-patterns) - [ConfigMap and Secrets utility functions](#configmap-and-secrets-utility-functions) - [Encoding](#encoding) - [Lines](#lines) ## Basic example With those caveats behind, let's write a template that reads three files into our ConfigMap. To get started, we will add three files to the chart, putting all three directly inside of the `mychart/` directory. `config1.toml`: ```toml message = "Hello from config 1" ``` `config2.toml`: ```toml message = "This is config 2" ``` `config3.toml`: ```toml message = "Goodbye from config 3" ``` Each of these is a simple TOML file (think old-school Windows INI files). We know the names of these files, so we can use a `range` function to loop through them and inject their contents into our ConfigMap. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: {{- $files := .Files }} {{- range tuple "config1.toml" "config2.toml" "config3.toml" }} {{ . }}: |- {{ $files.Get . }} {{- end }} ``` This ConfigMap uses several of the techniques discussed in previous sections. For example, we create a `$files` variable to hold a reference to the `.Files` object. We also use the `tuple` function to create a list of files that we loop through. Then we print each file name (`{{ . }}: |-`) followed by the contents of the file `{{ $files.Get . }}`. Running this template will produce a single ConfigMap with the contents of all three files: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: quieting-giraf-configmap data: config1.toml: |- message = "Hello from config 1" config2.toml: |- message = "This is config 2" config3.toml: |- message = "Goodbye from config 3" ``` ## Path helpers When working with files, it can be very useful to perform some standard operations on the file paths themselves. To help with this, Helm imports many of the functions from Go's [path](https://golang.org/pkg/path/) package for your use. They are all accessible with the same names as in the Go package, but with a lowercase first letter. For example, `Base` becomes `base`, etc. The imported functions are: - Base - Dir - Ext - IsAbs - Clean ## Glob patterns As your chart grows, you may find you have a greater need to organize your files more, and so we provide a `Files.Glob(pattern string)` method to assist in extracting certain files with all the flexibility of [glob patterns](https://godoc.org/github.com/gobwas/glob). `.Glob` returns a `Files` type, so you may call any of the `Files` methods on the returned object. For example, imagine the directory structure: ``` foo/: foo.txt foo.yaml bar/: bar.go bar.conf baz.yaml ``` You have multiple options with Globs: ```yaml {{ $currentScope := .}} {{ range $path, $_ := .Files.Glob "**.yaml" }} {{- with $currentScope}} {{ .Files.Get $path }} {{- end }} {{ end }} ``` Or ```yaml {{ range $path, $_ := .Files.Glob "**.yaml" }} {{ $.Files.Get $path }} {{ end }} ``` ## ConfigMap and Secrets utility functions (Available Helm 2.0.2 and after) It is very common to want to place file content into both ConfigMaps and Secrets, for mounting into your pods at run time. To help with this, we provide a couple utility methods on the `Files` type. For further organization, it is especially useful to use these methods in conjunction with the `Glob` method. Given the directory structure from the [Glob](#glob-patterns) example above: ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: conf data: {{ (.Files.Glob "foo/*").AsConfig | indent 2 }} --- apiVersion: v1 kind: Secret metadata: name: very-secret type: Opaque data: {{ (.Files.Glob "bar/*").AsSecrets | indent 2 }} ``` ## Encoding You can import a file and have the template base-64 encode it to ensure successful transmission: ```yaml apiVersion: v1 kind: Secret metadata: name: {{ .Release.Name }}-secret type: Opaque data: token: |- {{ .Files.Get "config1.toml" | b64enc }} ``` The above will take the same `config1.toml` file we used before and encode it: ```yaml # Source: mychart/templates/secret.yaml apiVersion: v1 kind: Secret metadata: name: lucky-turkey-secret type: Opaque data: token: |- bWVzc2FnZSA9ICJIZWxsbyBmcm9tIGNvbmZpZyAxIgo= ``` ## Lines Sometimes it is desirable to access each line of a file in your template. We provide a convenient `Lines` method for this. You can loop through `Lines` using a `range` function: ```yaml data: some-file.txt: {{ range .Files.Lines "foo/bar.txt" }} {{ . }}{{ end }} ``` There is no way to pass files external to the chart during `helm install`. So if you are asking users to supply data, it must be loaded using `helm install -f` or `helm install --set`. This discussion wraps up our dive into the tools and techniques for writing Helm templates. In the next section we will see how you can use one special file, `templates/NOTES.txt`, to send post-installation instructions to the users of your chart. ================================================ FILE: versioned_docs/version-3/chart_template_guide/builtin_objects.md ================================================ --- title: Built-in Objects description: Built-in objects available to templates. sidebar_position: 3 --- Objects are passed into a template from the template engine. And your code can pass objects around (we'll see examples when we look at the `with` and `range` statements). There are even a few ways to create new objects within your templates, like with the `tuple` function we'll see later. Objects can be simple, and have just one value. Or they can contain other objects or functions. For example, the `Release` object contains several objects (like `Release.Name`) and the `Files` object has a few functions. In the previous section, we use `{{ .Release.Name }}` to insert the name of a release into a template. `Release` is one of the top-level objects that you can access in your templates. - `Release`: This object describes the release itself. It has several objects inside of it: - `Release.Name`: The release name - `Release.Namespace`: The namespace to be released into (if the manifest doesn’t override) - `Release.IsUpgrade`: This is set to `true` if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to `true` if the current operation is an install. - `Release.Revision`: The revision number for this release. On install, this is 1, and it is incremented with each upgrade and rollback. - `Release.Service`: The service that is rendering the present template. On Helm, this is always `Helm`. - `Values`: Values passed into the template from the `values.yaml` file and from user-supplied files. By default, `Values` is empty. - `Chart`: The contents of the `Chart.yaml` file. Any data in `Chart.yaml` will be accessible here. For example `{{ .Chart.Name }}-{{ .Chart.Version }}` will print out the `mychart-0.1.0`. - The available fields are listed in the [Charts Guide](/topics/charts.md#the-chartyaml-file) - `Subcharts`: This provides access to the scope (.Values, .Charts, .Releases etc.) of subcharts to the parent. For example `.Subcharts.mySubChart.myValue` to access the `myValue` in the `mySubChart` chart. - `Files`: This provides access to all non-special files in a chart. While you cannot use it to access templates, you can use it to access other files in the chart. See the section [Accessing Files](/chart_template_guide/accessing_files.md) for more. - `Files.Get` is a function for getting a file by name (`.Files.Get config.ini`) - `Files.GetBytes` is a function for getting the contents of a file as an array of bytes instead of as a string. This is useful for things like images. - `Files.Glob` is a function that returns a list of files whose names match the given shell glob pattern. - `Files.Lines` is a function that reads a file line-by-line. This is useful for iterating over each line in a file. - `Files.AsSecrets` is a function that returns the file bodies as Base 64 encoded strings. - `Files.AsConfig` is a function that returns file bodies as a YAML map. - `Capabilities`: This provides information about what capabilities the Kubernetes cluster supports. - `Capabilities.APIVersions` is a set of versions. - `Capabilities.APIVersions.Has $version` indicates whether a version (e.g., `batch/v1`) or resource (e.g., `apps/v1/Deployment`) is available on the cluster. - `Capabilities.KubeVersion` and `Capabilities.KubeVersion.Version` is the Kubernetes version. - `Capabilities.KubeVersion.Major` is the Kubernetes major version. - `Capabilities.KubeVersion.Minor` is the Kubernetes minor version. - `Capabilities.HelmVersion` is the object containing the Helm Version details, it is the same output of `helm version`. - `Capabilities.HelmVersion.Version` is the current Helm version in semver format. - `Capabilities.HelmVersion.GitCommit` is the Helm git sha1. - `Capabilities.HelmVersion.GitTreeState` is the state of the Helm git tree. - `Capabilities.HelmVersion.GoVersion` is the version of the Go compiler used. - `Template`: Contains information about the current template that is being executed - `Template.Name`: A namespaced file path to the current template (e.g. `mychart/templates/mytemplate.yaml`) - `Template.BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`). The built-in values always begin with a capital letter. This is in keeping with Go's naming convention. When you create your own names, you are free to use a convention that suits your team. Some teams, like many whose charts you may see on [Artifact Hub](https://artifacthub.io/packages/search?kind=0), choose to use only initial lower case letters in order to distinguish local names from those built-in. In this guide, we follow that convention. ================================================ FILE: versioned_docs/version-3/chart_template_guide/control_structures.md ================================================ --- title: Flow Control description: A quick overview on the flow structure within templates. sidebar_position: 7 --- Control structures (called "actions" in template parlance) provide you, the template author, with the ability to control the flow of a template's generation. Helm's template language provides the following control structures: - `if`/`else` for creating conditional blocks - `with` to specify a scope - `range`, which provides a "for each"-style loop In addition to these, it provides a few actions for declaring and using named template segments: - `define` declares a new named template inside of your template - `template` imports a named template - `block` declares a special kind of fillable template area In this section, we'll talk about `if`, `with`, and `range`. The others are covered in the "Named Templates" section later in this guide. ## If/Else The first control structure we'll look at is for conditionally including blocks of text in a template. This is the `if`/`else` block. The basic structure for a conditional looks like this: ``` {{ if PIPELINE }} # Do something {{ else if OTHER PIPELINE }} # Do something else {{ else }} # Default case {{ end }} ``` Notice that we're now talking about _pipelines_ instead of values. The reason for this is to make it clear that control structures can execute an entire pipeline, not just evaluate a value. A pipeline is evaluated as _false_ if the value is: - a boolean false - a numeric zero - an empty string - a `nil` (empty or null) - an empty collection (`map`, `slice`, `tuple`, `dict`, `array`) Under all other conditions, the condition is true. Let's add a simple conditional to our ConfigMap. We'll add another setting if the drink is set to coffee: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` Since we commented out `drink: coffee` in our last example, the output should not include a `mug: "true"` flag. But if we add that line back into our `values.yaml` file, the output should look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` ## Controlling Whitespace While we're looking at conditionals, we should take a quick look at the way whitespace is controlled in templates. Let's take the previous example and format it to be a little easier to read: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` Initially, this looks good. But if we run it through the template engine, we'll get an unfortunate result: ```console $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart Error: YAML parse error on mychart/templates/configmap.yaml: error converting YAML to JSON: yaml: line 9: did not find expected key ``` What happened? We generated incorrect YAML because of the whitespacing above. ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eyewitness-elk-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` `mug` is incorrectly indented. Let's simply out-dent that one line, and re-run: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{ if eq .Values.favorite.drink "coffee" }} mug: "true" {{ end }} ``` When we sent that, we'll get YAML that is valid, but still looks a little funny: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: telling-chimp-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Notice that we received a few empty lines in our YAML. Why? When the template engine runs, it _removes_ the contents inside of `{{` and `}}`, but it leaves the remaining whitespace exactly as is. YAML ascribes meaning to whitespace, so managing the whitespace becomes pretty important. Fortunately, Helm templates have a few tools to help. First, the curly brace syntax of template declarations can be modified with special characters to tell the template engine to chomp whitespace. `{{- ` (with the dash and space added) indicates that whitespace should be chomped left, while ` -}}` means whitespace to the right should be consumed. _Be careful! Newlines are whitespace!_ > Make sure there is a space between the `-` and the rest of your directive. > `{{- 3 }}` means "trim left whitespace and print 3" while `{{-3 }}` means > "print -3". Using this syntax, we can modify our template to get rid of those new lines: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" }} mug: "true" {{- end }} ``` Just for the sake of making this point clear, let's adjust the above, and substitute an `*` for each whitespace that will be deleted following this rule. An `*` at the end of the line indicates a newline character that would be removed ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | default "tea" | quote }} food: {{ .Values.favorite.food | upper | quote }}* **{{- if eq .Values.favorite.drink "coffee" }} mug: "true"* **{{- end }} ``` Keeping that in mind, we can run our template through Helm and see the result: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: clunky-cat-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" mug: "true" ``` Be careful with the chomping modifiers. It is easy to accidentally do things like this: ```yaml food: {{ .Values.favorite.food | upper | quote }} {{- if eq .Values.favorite.drink "coffee" -}} mug: "true" {{- end -}} ``` That will produce `food: "PIZZA"mug: "true"` because it consumed newlines on both sides. > For the details on whitespace control in templates, see the [Official Go > template documentation](https://godoc.org/text/template) Finally, sometimes it's easier to tell the template system how to indent for you instead of trying to master the spacing of template directives. For that reason, you may sometimes find it useful to use the `indent` function (`{{ indent 2 "mug:true" }}`). ## Modifying scope using `with` The next control structure to look at is the `with` action. This controls variable scoping. Recall that `.` is a reference to _the current scope_. So `.Values` tells the template to find the `Values` object in the current scope. The syntax for `with` is similar to a simple `if` statement: ``` {{ with PIPELINE }} # restricted scope {{ end }} ``` Scopes can be changed. `with` can allow you to set the current scope (`.`) to a particular object. For example, we've been working with `.Values.favorite`. Let's rewrite our ConfigMap to alter the `.` scope to point to `.Values.favorite`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` Note that we removed the `if` conditional from the previous exercise because it is now unnecessary - the block after `with` only executes if the value of `PIPELINE` is not empty. Notice that now we can reference `.drink` and `.food` without qualifying them. That is because the `with` statement sets `.` to point to `.Values.favorite`. The `.` is reset to its previous scope after `{{ end }}`. But here's a note of caution! Inside of the restricted scope, you will not be able to access the other objects from the parent scope using `.`. This, for example, will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` It will produce an error because `Release.Name` is not inside of the restricted scope for `.`. However, if we swap the last two lines, all will work as expected because the scope is reset after `{{ end }}`. ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} release: {{ .Release.Name }} ``` Or, we can use `$` for accessing the object `Release.Name` from the parent scope. `$` is mapped to the root scope when template execution begins and it does not change during template execution. The following would work as well: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $.Release.Name }} {{- end }} ``` After looking at `range`, we will take a look at template variables, which offer one solution to the scoping issue above. ## Looping with the `range` action Many programming languages have support for looping using `for` loops, `foreach` loops, or similar functional mechanisms. In Helm's template language, the way to iterate through a collection is to use the `range` operator. To start, let's add a list of pizza toppings to our `values.yaml` file: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` Now we have a list (called a `slice` in templates) of `pizzaToppings`. We can modify our template to print this list into our ConfigMap: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` We can use `$` for accessing the list `Values.pizzaToppings` from the parent scope. `$` is mapped to the root scope when template execution begins and it does not change during template execution. The following would work as well: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} toppings: |- {{- range $.Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} {{- end }} ``` Let's take a closer look at the `toppings:` list. The `range` function will "range over" (iterate through) the `pizzaToppings` list. But now something interesting happens. Just like `with` sets the scope of `.`, so does a `range` operator. Each time through the loop, `.` is set to the current pizza topping. That is, the first time, `.` is set to `mushrooms`. The second iteration it is set to `cheese`, and so on. We can send the value of `.` directly down a pipeline, so when we do `{{ . | title | quote }}`, it sends `.` to `title` (title case function) and then to `quote`. If we run this template, the output will be: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-dragonfly-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" toppings: |- - "Mushrooms" - "Cheese" - "Peppers" - "Onions" - "Pineapple" ``` Now, in this example we've done something tricky. The `toppings: |-` line is declaring a multi-line string. So our list of toppings is actually not a YAML list. It's a big string. Why would we do this? Because the data in ConfigMaps `data` is composed of key/value pairs, where both the key and the value are simple strings. To understand why this is the case, take a look at the [Kubernetes ConfigMap docs](https://kubernetes.io/docs/concepts/configuration/configmap/). For us, though, this detail doesn't matter much. > The `|-` marker in YAML takes a multi-line string. This can be a useful > technique for embedding big blocks of data inside of your manifests, as > exemplified here. Sometimes it's useful to be able to quickly make a list inside of your template, and then iterate over that list. Helm templates have a function to make this easy: `tuple`. In computer science, a tuple is a list-like collection of fixed size, but with arbitrary data types. This roughly conveys the way a `tuple` is used. ```yaml sizes: |- {{- range tuple "small" "medium" "large" }} - {{ . }} {{- end }} ``` The above will produce this: ```yaml sizes: |- - small - medium - large ``` In addition to lists and tuples, `range` can be used to iterate over collections that have a key and a value (like a `map` or `dict`). We'll see how to do that in the next section when we introduce template variables. ================================================ FILE: versioned_docs/version-3/chart_template_guide/data_types.md ================================================ --- title: "Appendix: Go Data Types and Templates" description: A quick overview on variables in templates. sidebar_position: 16 --- The Helm template language is implemented in the strongly typed Go programming language. For that reason, variables in templates are _typed_. For the most part, variables will be exposed as one of the following types: - string: A string of text - bool: a `true` or `false` - int: An integer value (there are also 8, 16, 32, and 64 bit signed and unsigned variants of this) - float64: a 64-bit floating point value (there are also 8, 16, and 32 bit varieties of this) - a byte slice (`[]byte`), often used to hold (potentially) binary data - struct: an object with properties and methods - a slice (indexed list) of one of the previous types - a string-keyed map (`map[string]interface{}`) where the value is one of the previous types There are many other types in Go, and sometimes you will have to convert between them in your templates. The easiest way to debug an object's type is to pass it through `printf "%T"` in a template, which will print the type. Also see the `typeOf` and `kindOf` functions. ================================================ FILE: versioned_docs/version-3/chart_template_guide/debugging.md ================================================ --- title: Debugging Templates description: Troubleshooting charts that are failing to deploy. sidebar_position: 13 --- Debugging templates can be tricky because the rendered templates are sent to the Kubernetes API server, which may reject the YAML files for reasons other than formatting. There are a few commands that can help you debug. - `helm lint` is your go-to tool for verifying that your chart follows best practices - `helm template --debug` will test rendering chart templates locally. - `helm install --dry-run --debug` will also render your chart locally without installing it, but will also check if conflicting resources are already running on the cluster. Setting `--dry-run=server` will additionally execute any `lookup` in your chart towards the server. - `helm get manifest`: This is a good way to see what templates are installed on the server. When your YAML is failing to parse, but you want to see what is generated, one easy way to retrieve the YAML is to comment out the problem section in the template, and then re-run `helm install --dry-run --debug`: ```yaml apiVersion: v2 # some: problem section # {{ .Values.foo | quote }} ``` The above will be rendered and returned with the comments intact: ```yaml apiVersion: v2 # some: problem section # "bar" ``` This provides a quick way of viewing the generated content without YAML parse errors blocking. ================================================ FILE: versioned_docs/version-3/chart_template_guide/function_list.md ================================================ --- title: Template Function List description: A list of template functions available in Helm sidebar_position: 6 --- Helm includes many template functions you can take advantage of in templates. They are listed here and broken down by the following categories: * [Cryptographic and Security](#cryptographic-and-security-functions) * [Date](#date-functions) * [Dictionaries](#dictionaries-and-dict-functions) * [Encoding](#encoding-functions) * [File Path](#file-path-functions) * [Kubernetes and Chart](#kubernetes-and-chart-functions) * [Logic and Flow Control](#logic-and-flow-control-functions) * [Lists](#lists-and-list-functions) * [Math](#math-functions) * [Float Math](#float-math-functions) * [Network](#network-functions) * [Reflection](#reflection-functions) * [Regular Expressions](#regular-expressions) * [Semantic Versions](#semantic-version-functions) * [String](#string-functions) * [Type Conversion](#type-conversion-functions) * [URL](#url-functions) * [UUID](#uuid-functions) ## Logic and Flow Control Functions Helm includes numerous logic and control flow functions including [and](#and), [coalesce](#coalesce), [default](#default), [empty](#empty), [eq](#eq), [fail](#fail), [ge](#ge), [gt](#gt), [le](#le), [lt](#lt), [ne](#ne), [not](#not), [or](#or), and [required](#required). ### and Returns the boolean AND of two or more arguments (the first empty argument, or the last argument). ``` and .Arg1 .Arg2 ``` ### or Returns the boolean OR of two or more arguments (the first non-empty argument, or the last argument). ``` or .Arg1 .Arg2 ``` ### not Returns the boolean negation of its argument. ``` not .Arg ``` ### eq Returns the boolean equality of the arguments (e.g., Arg1 == Arg2). ``` eq .Arg1 .Arg2 ``` ### ne Returns the boolean inequality of the arguments (e.g., Arg1 != Arg2) ``` ne .Arg1 .Arg2 ``` ### lt Returns a boolean true if the first argument is less than the second. False is returned otherwise (e.g., Arg1 < Arg2). ``` lt .Arg1 .Arg2 ``` ### le Returns a boolean true if the first argument is less than or equal to the second. False is returned otherwise (e.g., Arg1 <= Arg2). ``` le .Arg1 .Arg2 ``` ### gt Returns a boolean true if the first argument is greater than the second. False is returned otherwise (e.g., Arg1 > Arg2). ``` gt .Arg1 .Arg2 ``` ### ge Returns a boolean true if the first argument is greater than or equal to the second. False is returned otherwise (e.g., Arg1 >= Arg2). ``` ge .Arg1 .Arg2 ``` ### default To set a simple default value, use `default`: ``` default "foo" .Bar ``` In the above, if `.Bar` evaluates to a non-empty value, it will be used. But if it is empty, `foo` will be returned instead. The definition of "empty" depends on type: - Numeric: 0 - String: "" - Lists: `[]` - Dicts: `{}` - Boolean: `false` - And always `nil` (aka null) For structs, there is no definition of empty, so a struct will never return the default. ### required Specify values that must be set with `required`: ``` required "A valid foo is required!" .Bar ``` If `.Bar` is empty or not defined (see [default](#default) on how this is evaluated), the template will not render and will return the error message supplied instead. ### empty The `empty` function returns `true` if the given value is considered empty, and `false` otherwise. The empty values are listed in the `default` section. ``` empty .Foo ``` Note that in Go template conditionals, emptiness is calculated for you. Thus, you rarely need `if not empty .Foo`. Instead, just use `if .Foo`. ### fail Unconditionally returns an empty `string` and an `error` with the specified text. This is useful in scenarios where other conditionals have determined that template rendering should fail. ``` fail "Please accept the end user license agreement" ``` ### coalesce The `coalesce` function takes a list of values and returns the first non-empty one. ``` coalesce 0 1 2 ``` The above returns `1`. This function is useful for scanning through multiple variables or values: ``` coalesce .name .parent.name "Matt" ``` The above will first check to see if `.name` is empty. If it is not, it will return that value. If it _is_ empty, `coalesce` will evaluate `.parent.name` for emptiness. Finally, if both `.name` and `.parent.name` are empty, it will return `Matt`. ### ternary The `ternary` function takes two values, and a test value. If the test value is true, the first value will be returned. If the test value is empty, the second value will be returned. This is similar to the ternary operator in C and other programming languages. #### true test value ``` ternary "foo" "bar" true ``` or ``` true | ternary "foo" "bar" ``` The above returns `"foo"`. #### false test value ``` ternary "foo" "bar" false ``` or ``` false | ternary "foo" "bar" ``` The above returns `"bar"`. ## String Functions Helm includes the following string functions: [abbrev](#abbrev), [abbrevboth](#abbrevboth), [camelcase](#camelcase), [cat](#cat), [contains](#contains), [hasPrefix](#hasprefix-and-hassuffix), [hasSuffix](#hasprefix-and-hassuffix), [indent](#indent), [initials](#initials), [kebabcase](#kebabcase), [lower](#lower), [nindent](#nindent), [nospace](#nospace), [plural](#plural), [print](#print), [printf](#printf), [println](#println), [quote](#quote-and-squote), [randAlpha](#randalphanum-randalpha-randnumeric-and-randascii), [randAlphaNum](#randalphanum-randalpha-randnumeric-and-randascii), [randAscii](#randalphanum-randalpha-randnumeric-and-randascii), [randNumeric](#randalphanum-randalpha-randnumeric-and-randascii), [repeat](#repeat), [replace](#replace), [shuffle](#shuffle), [snakecase](#snakecase), [squote](#quote-and-squote), [substr](#substr), [swapcase](#swapcase), [title](#title), [trim](#trim), [trimAll](#trimall), [trimPrefix](#trimprefix), [trimSuffix](#trimsuffix), [trunc](#trunc), [untitle](#untitle), [upper](#upper), [wrap](#wrap), and [wrapWith](#wrapwith). ### print Returns a string from the combination of its parts. ``` print "Matt has " .Dogs " dogs" ``` Types that are not strings are converted to strings where possible. Note, when two arguments next to each other are not strings a space is added between them. ### println Works the same way as [print](#print) but adds a new line at the end. ### printf Returns a string based on a formatting string and the arguments to pass to it in order. ``` printf "%s has %d dogs." .Name .NumberDogs ``` The placeholder to use depends on the type for the argument being passed in. This includes: General purpose: * `%v` the value in a default format * when printing dicts, the plus flag (%+v) adds field names * `%%` a literal percent sign; consumes no value Boolean: * `%t` the word true or false Integer: * `%b` base 2 * `%c` the character represented by the corresponding Unicode code point * `%d` base 10 * `%o` base 8 * `%O` base 8 with 0o prefix * `%q` a single-quoted character literal safely escaped * `%x` base 16, with lower-case letters for a-f * `%X` base 16, with upper-case letters for A-F * `%U` Unicode format: U+1234; same as "U+%04X" Floating-point and complex constituents: * `%b` decimal less scientific notation with exponent a power of two, e.g. -123456p-78 * `%e` scientific notation, e.g. -1.234456e+78 * `%E` scientific notation, e.g. -1.234456E+78 * `%f` decimal point but no exponent, e.g. 123.456 * `%F` synonym for %f * `%g` %e for large exponents, %f otherwise. * `%G` %E for large exponents, %F otherwise * `%x` hexadecimal notation (with decimal power of two exponent), e.g. -0x1.23abcp+20 * `%X` upper-case hexadecimal notation, e.g. -0X1.23ABCP+20 String and slice of bytes (treated equivalently with these verbs): * `%s` the uninterpreted bytes of the string or slice * `%q` a double-quoted string safely escaped * `%x` base 16, lower-case, two characters per byte * `%X` base 16, upper-case, two characters per byte Slice: * `%p` address of 0th element in base 16 notation, with leading 0x ### trim The `trim` function removes white space from both sides of a string: ``` trim " hello " ``` The above produces `hello` ### trimAll Removes the given characters from the front and back of a string: ``` trimAll "$" "$5.00" ``` The above returns `5.00` (as a string). ### trimPrefix Trim just the prefix from a string: ``` trimPrefix "-" "-hello" ``` The above returns `hello` ### trimSuffix Trim just the suffix from a string: ``` trimSuffix "-" "hello-" ``` The above returns `hello` ### lower Convert the entire string to lowercase: ``` lower "HELLO" ``` The above returns `hello` ### upper Convert the entire string to uppercase: ``` upper "hello" ``` The above returns `HELLO` ### title Convert to title case: ``` title "hello world" ``` The above returns `Hello World` ### untitle Remove title casing. `untitle "Hello World"` produces `hello world`. ### repeat Repeat a string multiple times: ``` repeat 3 "hello" ``` The above returns `hellohellohello` ### substr Get a substring from a string. It takes three parameters: - start (int) - end (int) - string (string) ``` substr 0 5 "hello world" ``` The above returns `hello` ### nospace Remove all whitespace from a string. ``` nospace "hello w o r l d" ``` The above returns `helloworld` ### trunc Truncate a string ``` trunc 5 "hello world" ``` The above produces `hello`. ``` trunc -5 "hello world" ``` The above produces `world`. ### abbrev Truncate a string with ellipses (`...`) Parameters: - max length - the string ``` abbrev 5 "hello world" ``` The above returns `he...`, since it counts the width of the ellipses against the maximum length. ### abbrevboth Abbreviate both sides: ``` abbrevboth 5 10 "1234 5678 9123" ``` the above produces `...5678...` It takes: - left offset - max length - the string ### initials Given multiple words, take the first letter of each word and combine. ``` initials "First Try" ``` The above returns `FT` ### randAlphaNum, randAlpha, randNumeric, and randAscii These four functions generate cryptographically secure (uses ```crypto/rand```) random strings, but with different base character sets: - `randAlphaNum` uses `0-9a-zA-Z` - `randAlpha` uses `a-zA-Z` - `randNumeric` uses `0-9` - `randAscii` uses all printable ASCII characters Each of them takes one parameter: the integer length of the string. ``` randNumeric 3 ``` The above will produce a random string with three digits. ### wrap Wrap text at a given column count: ``` wrap 80 $someText ``` The above will wrap the string in `$someText` at 80 columns. ### wrapWith `wrapWith` works as `wrap`, but lets you specify the string to wrap with. (`wrap` uses `\n`) ``` wrapWith 5 "\t" "Hello World" ``` The above produces `Hello World` (where the whitespace is an ASCII tab character) ### contains Test to see if one string is contained inside of another: ``` contains "cat" "catch" ``` The above returns `true` because `catch` contains `cat`. ### hasPrefix and hasSuffix The `hasPrefix` and `hasSuffix` functions test whether a string has a given prefix or suffix: ``` hasPrefix "cat" "catch" ``` The above returns `true` because `catch` has the prefix `cat`. ### quote and squote These functions wrap a string in double quotes (`quote`) or single quotes (`squote`). ### cat The `cat` function concatenates multiple strings together into one, separating them with spaces: ``` cat "hello" "beautiful" "world" ``` The above produces `hello beautiful world` ### indent The `indent` function indents every line in a given string to the specified indent width. This is useful when aligning multi-line strings: ``` indent 4 $lots_of_text ``` The above will indent every line of text by 4 space characters. ### nindent The `nindent` function is the same as the indent function, but prepends a new line to the beginning of the string. ``` nindent 4 $lots_of_text ``` The above will indent every line of text by 4 space characters and add a new line to the beginning. ### replace Perform simple string replacement. It takes three arguments: - string to replace - string to replace with - source string ``` "I Am Henry VIII" | replace " " "-" ``` The above will produce `I-Am-Henry-VIII` ### plural Pluralize a string. ``` len $fish | plural "one anchovy" "many anchovies" ``` In the above, if the length of the string is 1, the first argument will be printed (`one anchovy`). Otherwise, the second argument will be printed (`many anchovies`). The arguments are: - singular string - plural string - length integer NOTE: Helm does not currently support languages with more complex pluralization rules. And `0` is considered a plural because the English language treats it as such (`zero anchovies`). ### snakecase Convert string from camelCase to snake_case. ``` snakecase "FirstName" ``` This above will produce `first_name`. ### camelcase Convert string from snake_case to CamelCase ``` camelcase "http_server" ``` This above will produce `HttpServer`. ### kebabcase Convert string from camelCase to kebab-case. ``` kebabcase "FirstName" ``` This above will produce `first-name`. ### swapcase Swap the case of a string using a word based algorithm. Conversion algorithm: - Upper case character converts to Lower case - Title case character converts to Lower case - Lower case character after Whitespace or at start converts to Title case - Other Lower case character converts to Upper case - Whitespace is defined by unicode.IsSpace(char) ``` swapcase "This Is A.Test" ``` This above will produce `tHIS iS a.tEST`. ### shuffle Shuffle a string. ``` shuffle "hello" ``` The above will randomize the letters in `hello`, perhaps producing `oelhl`. ## Type Conversion Functions The following type conversion functions are provided by Helm: - `atoi`: Convert a string to an integer. - `float64`: Convert to a `float64`. - `int`: Convert to an `int` at the system's width. - `int64`: Convert to an `int64`. - `toDecimal`: Convert a unix octal to a `int64`. - `toString`: Convert to a string. - `toStrings`: Convert a list, slice, or array to a list of strings. - `toJson` (`mustToJson`): Convert list, slice, array, dict, or object to JSON. - `toPrettyJson` (`mustToPrettyJson`): Convert list, slice, array, dict, or object to indented JSON. - `toRawJson` (`mustToRawJson`): Convert list, slice, array, dict, or object to JSON with HTML characters unescaped. - `fromYaml`: Convert a YAML string to an object. - `fromJson`: Convert a JSON string to an object. - `fromJsonArray`: Convert a JSON array to a list. - `toYaml`: Convert list, slice, array, dict, or object to indented yaml, can be used to copy chunks of yaml from any source. This function is equivalent to GoLang yaml.Marshal function, see docs here: https://pkg.go.dev/gopkg.in/yaml.v2#Marshal - `toYamlPretty`: Convert list, slice, array, dict, or object to indented yaml. Equivalent to `toYaml` but will additionally indent lists by 2 spaces. - `toToml`: Convert list, slice, array, dict, or object to toml, can be used to copy chunks of toml from any source. - `fromYamlArray`: Convert a YAML array to a list. Only `atoi` requires that the input be a specific type. The others will attempt to convert from any type to the destination type. For example, `int64` can convert floats to ints, and it can also convert strings to ints. ### toStrings Given a list-like collection, produce a slice of strings. ``` list 1 2 3 | toStrings ``` The above converts `1` to `"1"`, `2` to `"2"`, and so on, and then returns them as a list. ### toDecimal Given a unix octal permission, produce a decimal. ``` "0777" | toDecimal ``` The above converts `0777` to `511` and returns the value as an int64. ### toJson, mustToJson The `toJson` function encodes an item into a JSON string. If the item cannot be converted to JSON the function will return an empty string. `mustToJson` will return an error in case the item cannot be encoded in JSON. ``` toJson .Item ``` The above returns JSON string representation of `.Item`. ### toPrettyJson, mustToPrettyJson The `toPrettyJson` function encodes an item into a pretty (indented) JSON string. ``` toPrettyJson .Item ``` The above returns indented JSON string representation of `.Item`. ### toRawJson, mustToRawJson The `toRawJson` function encodes an item into JSON string with HTML characters unescaped. ``` toRawJson .Item ``` The above returns unescaped JSON string representation of `.Item`. ### fromYaml The `fromYaml` function takes a YAML string and returns an object that can be used in templates. `File at: yamls/person.yaml` ```yaml name: Bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml {{- $person := .Files.Get "yamls/person.yaml" | fromYaml }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJson The `fromJson` function takes a JSON string and returns an object that can be used in templates. `File at: jsons/person.json` ```json { "name": "Bob", "age": 25, "hobbies": [ "hiking", "fishing", "cooking" ] } ``` ```yaml {{- $person := .Files.Get "jsons/person.json" | fromJson }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. My hobbies are {{ range $person.hobbies }}{{ . }} {{ end }}. ``` ### fromJsonArray The `fromJsonArray` function takes a JSON Array and returns a list that can be used in templates. `File at: jsons/people.json` ```json [ { "name": "Bob","age": 25 }, { "name": "Ram","age": 16 } ] ``` ```yaml {{- $people := .Files.Get "jsons/people.json" | fromJsonArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ### toYaml, toYamlPretty The `toYaml` and `toYamlPretty` functions encode an object (list, slice, array, dict, or object) into an indented YAML string. > Note that `toYamlPretty` is functionally equivalent but will output YAML with additional indents for list elements ```yaml # toYaml - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ```yaml # toYamlPretty - name: bob age: 25 hobbies: - hiking - fishing - cooking ``` ### fromYamlArray The `fromYamlArray` function takes a YAML Array and returns a list that can be used in templates. `File at: yamls/people.yml` ```yaml - name: Bob age: 25 - name: Ram age: 16 ``` ```yaml {{- $people := .Files.Get "yamls/people.yml" | fromYamlArray }} {{- range $person := $people }} greeting: | Hi, my name is {{ $person.name }} and I am {{ $person.age }} years old. {{ end }} ``` ## Regular Expressions Helm includes the following regular expression functions: [regexFind (mustRegexFind)](#regexfindall-mustregexfindall), [regexFindAll (mustRegexFindAll)](#regexfind-mustregexfind), [regexMatch (mustRegexMatch)](#regexmatch-mustregexmatch), [regexReplaceAll (mustRegexReplaceAll)](#regexreplaceall-mustregexreplaceall), [regexReplaceAllLiteral (mustRegexReplaceAllLiteral)](#regexreplaceallliteral-mustregexreplaceallliteral), [regexSplit (mustRegexSplit)](#regexsplit-mustregexsplit). ### regexMatch, mustRegexMatch Returns true if the input string contains any match of the regular expression. ``` regexMatch "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" "test@acme.com" ``` The above produces `true` `regexMatch` panics if there is a problem and `mustRegexMatch` returns an error to the template engine if there is a problem. ### regexFindAll, mustRegexFindAll Returns a slice of all matches of the regular expression in the input string. The last parameter n determines the number of substrings to return, where -1 means return all matches ``` regexFindAll "[2,4,6,8]" "123456789" -1 ``` The above produces `[2 4 6 8]` `regexFindAll` panics if there is a problem and `mustRegexFindAll` returns an error to the template engine if there is a problem. ### regexFind, mustRegexFind Return the first (left most) match of the regular expression in the input string ``` regexFind "[a-zA-Z][1-9]" "abcd1234" ``` The above produces `d1` `regexFind` panics if there is a problem and `mustRegexFind` returns an error to the template engine if there is a problem. ### regexReplaceAll, mustRegexReplaceAll Returns a copy of the input string, replacing matches of the Regexp with the replacement string replacement. Inside string replacement, $ signs are interpreted as in Expand, so for instance $1 represents the text of the first submatch. The first argument is ``, second is ``, and third is ``. ``` regexReplaceAll "a(x*)b" "-ab-axxb-" "${1}W" ``` The above produces `-W-xxW-` `regexReplaceAll` panics if there is a problem and `mustRegexReplaceAll` returns an error to the template engine if there is a problem. ### regexReplaceAllLiteral, mustRegexReplaceAllLiteral Returns a copy of the input string, replacing matches of the Regexp with the replacement string replacement. The replacement string is substituted directly, without using Expand. The first argument is ``, second is ``, and third is ``. ``` regexReplaceAllLiteral "a(x*)b" "-ab-axxb-" "${1}" ``` The above produces `-${1}-${1}-` `regexReplaceAllLiteral` panics if there is a problem and `mustRegexReplaceAllLiteral` returns an error to the template engine if there is a problem. ### regexSplit, mustRegexSplit Slices the input string into substrings separated by the expression and returns a slice of the substrings between those expression matches. The last parameter `n` determines the number of substrings to return, where `-1` means return all matches ``` regexSplit "z+" "pizza" -1 ``` The above produces `[pi a]` `regexSplit` panics if there is a problem and `mustRegexSplit` returns an error to the template engine if there is a problem. ## Cryptographic and Security Functions Helm provides some advanced cryptographic functions. They include [adler32sum](#adler32sum), [buildCustomCert](#buildcustomcert), [decryptAES](#decryptaes), [derivePassword](#derivepassword), [encryptAES](#encryptaes), [genCA](#genca), [genPrivateKey](#genprivatekey), [genSelfSignedCert](#genselfsignedcert), [genSignedCert](#gensignedcert), [htpasswd](#htpasswd), [randBytes](#randbytes), [sha1sum](#sha1sum), and [sha256sum](#sha256sum). ### sha1sum The `sha1sum` function receives a string, and computes it's SHA1 digest. ``` sha1sum "Hello world!" ``` ### sha256sum The `sha256sum` function receives a string, and computes it's SHA256 digest. ``` sha256sum "Hello world!" ``` The above will compute the SHA 256 sum in an "ASCII armored" format that is safe to print. ### adler32sum The `adler32sum` function receives a string, and computes its Adler-32 checksum. ``` adler32sum "Hello world!" ``` ### htpasswd The `htpasswd` function takes a `username` and `password` and generates a `bcrypt` hash of the password. The result can be used for basic authentication on an [Apache HTTP Server](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#basic). ``` htpasswd "myUser" "myPassword" ``` Note that it is insecure to store the password directly in the template. ### randBytes The randBytes function accepts a count N and generates a cryptographically secure (uses crypto/rand) random sequence of N bytes. The sequence is returned as a base64 encoded string. ``` randBytes 24 ``` ### derivePassword The `derivePassword` function can be used to derive a specific password based on some shared "master password" constraints. The algorithm for this is [well specified](https://web.archive.org/web/20211019121301/https://masterpassword.app/masterpassword-algorithm.pdf). ``` derivePassword 1 "long" "password" "user" "example.com" ``` Note that it is considered insecure to store the parts directly in the template. ### genPrivateKey The `genPrivateKey` function generates a new private key encoded into a PEM block. It takes one of the values for its first param: - `ecdsa`: Generate an elliptic curve DSA key (P256) - `dsa`: Generate a DSA key (L2048N256) - `rsa`: Generate an RSA 4096 key ### buildCustomCert The `buildCustomCert` function allows customizing the certificate. It takes the following string parameters: - A base64 encoded PEM format certificate - A base64 encoded PEM format private key It returns a certificate object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $ca := buildCustomCert "base64-encoded-ca-crt" "base64-encoded-ca-key" ``` Note that the returned object can be passed to the `genSignedCert` function to sign a certificate using this CA. ### genCA The `genCA` function generates a new, self-signed x509 certificate authority. It takes the following parameters: - Subject's common name (cn) - Cert validity duration in days It returns an object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $ca := genCA "foo-ca" 365 ``` Note that the returned object can be passed to the `genSignedCert` function to sign a certificate using this CA. ### genSelfSignedCert The `genSelfSignedCert` function generates a new, self-signed x509 certificate. It takes the following parameters: - Subject's common name (cn) - Optional list of IPs; may be nil - Optional list of alternate DNS names; may be nil - Cert validity duration in days It returns an object with the following attributes: - `Cert`: A PEM-encoded certificate - `Key`: A PEM-encoded private key Example: ``` $cert := genSelfSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 ``` ### genSignedCert The `genSignedCert` function generates a new, x509 certificate signed by the specified CA. It takes the following parameters: - Subject's common name (cn) - Optional list of IPs; may be nil - Optional list of alternate DNS names; may be nil - Cert validity duration in days - CA (see `genCA`) Example: ``` $ca := genCA "foo-ca" 365 $cert := genSignedCert "foo.com" (list "10.0.0.1" "10.0.0.2") (list "bar.com" "bat.com") 365 $ca ``` ### encryptAES The `encryptAES` function encrypts text with AES-256 CBC and returns a base64 encoded string. ``` encryptAES "secretkey" "plaintext" ``` ### decryptAES The `decryptAES` function receives a base64 string encoded by the AES-256 CBC algorithm and returns the decoded text. ``` "30tEfhuJSVRhpG97XCuWgz2okj7L8vQ1s6V9zVUPeDQ=" | decryptAES "secretkey" ``` ## Date Functions Helm includes the following date functions you can use in templates: [ago](#ago), [date](#date), [dateInZone](#dateinzone), [dateModify (mustDateModify)](#datemodify-mustdatemodify), [duration](#duration), [durationRound](#durationround), [htmlDate](#htmldate), [htmlDateInZone](#htmldateinzone), [now](#now), [toDate (mustToDate)](#todate-musttodate), and [unixEpoch](#unixepoch). ### now The current date/time. Use this in conjunction with other date functions. ### ago The `ago` function returns duration from time. Now in seconds resolution. ``` ago .CreatedAt ``` returns in `time.Duration` String() format ``` 2h34m7s ``` ### date The `date` function formats a date. Format the date to YEAR-MONTH-DAY: ``` now | date "2006-01-02" ``` Date formatting in Go is a [little bit different](https://pauladamsmith.com/blog/2011/05/go_time.html). In short, take this as the base date: ``` Mon Jan 2 15:04:05 MST 2006 ``` Write it in the format you want. Above, `2006-01-02` is the same date, but in the format we want. ### dateInZone Same as `date`, but with a timezone. ``` dateInZone "2006-01-02" (now) "UTC" ``` ### duration Formats a given amount of seconds as a `time.Duration`. This returns 1m35s ``` duration "95" ``` ### durationRound Rounds a given duration to the most significant unit. Strings and `time.Duration` gets parsed as a duration, while a `time.Time` is calculated as the duration since. This return 2h ``` durationRound "2h10m5s" ``` This returns 3mo ``` durationRound "2400h10m5s" ``` ### unixEpoch Returns the seconds since the unix epoch for a `time.Time`. ``` now | unixEpoch ``` ### dateModify, mustDateModify The `dateModify` takes a modification and a date and returns the timestamp. Subtract an hour and thirty minutes from the current time: ``` now | dateModify "-1.5h" ``` If the modification format is wrong `dateModify` will return the date unmodified. `mustDateModify` will return an error otherwise. ### htmlDate The `htmlDate` function formats a date for inserting into an HTML date picker input field. ``` now | htmlDate ``` ### htmlDateInZone Same as htmlDate, but with a timezone. ``` htmlDateInZone (now) "UTC" ``` ### toDate, mustToDate `toDate` converts a string to a date. The first argument is the date layout and the second the date string. If the string can't be convert it returns the zero value. `mustToDate` will return an error in case the string cannot be converted. This is useful when you want to convert a string date to another format (using pipe). The example below converts "2017-12-31" to "31/12/2017". ``` toDate "2006-01-02" "2017-12-31" | date "02/01/2006" ``` ## Dictionaries and Dict Functions Helm provides a key/value storage type called a `dict` (short for "dictionary", as in Python). A `dict` is an _unordered_ type. The key to a dictionary **must be a string**. However, the value can be any type, even another `dict` or `list`. Unlike `list`s, `dict`s are not immutable. The `set` and `unset` functions will modify the contents of a dictionary. Helm provides the following functions to support working with dicts: [deepCopy (mustDeepCopy)](#deepcopy-mustdeepcopy), [dict](#dict), [dig](#dig), [get](#get), [hasKey](#haskey), [keys](#keys), [merge (mustMerge)](#merge-mustmerge), [mergeOverwrite (mustMergeOverwrite)](#mergeoverwrite-mustmergeoverwrite), [omit](#omit), [pick](#pick), [pluck](#pluck), [set](#set), [unset](#unset), and [values](#values). ### dict Creating dictionaries is done by calling the `dict` function and passing it a list of pairs. The following creates a dictionary with three items: ``` $myDict := dict "name1" "value1" "name2" "value2" "name3" "value 3" ``` ### get Given a map and a key, get the value from the map. ``` get $myDict "name1" ``` The above returns `"value1"` Note that if the key is not found, this operation will simply return `""`. No error will be generated. ### set Use `set` to add a new key/value pair to a dictionary. ``` $_ := set $myDict "name4" "value4" ``` Note that `set` _returns the dictionary_ (a requirement of Go template functions), so you may need to trap the value as done above with the `$_` assignment. ### unset Given a map and a key, delete the key from the map. ``` $_ := unset $myDict "name4" ``` As with `set`, this returns the dictionary. Note that if the key is not found, this operation will simply return. No error will be generated. ### hasKey The `hasKey` function returns `true` if the given dict contains the given key. ``` hasKey $myDict "name1" ``` If the key is not found, this returns `false`. ### pluck The `pluck` function makes it possible to give one key and multiple maps, and get a list of all of the matches: ``` pluck "name1" $myDict $myOtherDict ``` The above will return a `list` containing every found value (`[value1 otherValue1]`). If the given key is _not found_ in a map, that map will not have an item in the list (and the length of the returned list will be less than the number of dicts in the call to `pluck`). If the key is _found_ but the value is an empty value, that value will be inserted. A common idiom in Helm templates is to use `pluck... | first` to get the first matching key out of a collection of dictionaries. ### dig The `dig` function traverses a nested set of dicts, selecting keys from a list of values. It returns a default value if any of the keys are not found at the associated dict. ``` dig "user" "role" "humanName" "guest" $dict ``` Given a dict structured like ``` { user: { role: { humanName: "curator" } } } ``` the above would return `"curator"`. If the dict lacked even a `user` field, the result would be `"guest"`. Dig can be very useful in cases where you'd like to avoid guard clauses, especially since Go's template package's `and` doesn't shortcut. For instance `and a.maybeNil a.maybeNil.iNeedThis` will always evaluate `a.maybeNil.iNeedThis`, and panic if `a` lacks a `maybeNil` field.) `dig` accepts its dict argument last in order to support pipelining. For instance: ``` merge a b c | dig "one" "two" "three" "" ``` ### merge, mustMerge Merge two or more dictionaries into one, giving precedence to the dest dictionary: Given: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` will result in: ``` newdict: default: default overwrite: me key: true ``` ``` $newdict := merge $dest $source1 $source2 ``` This is a deep merge operation but not a deep copy operation. Nested objects that are merged are the same instance on both dicts. If you want a deep copy along with the merge, then use the `deepCopy` function along with merging. For example, ``` deepCopy $source | merge $dest ``` `mustMerge` will return an error in case of unsuccessful merge. ### mergeOverwrite, mustMergeOverwrite Merge two or more dictionaries into one, giving precedence from **right to left**, effectively overwriting values in the dest dictionary: Given: ``` dest: default: default overwrite: me key: true src: overwrite: overwritten key: false ``` will result in: ``` newdict: default: default overwrite: overwritten key: false ``` ``` $newdict := mergeOverwrite $dest $source1 $source2 ``` This is a deep merge operation but not a deep copy operation. Nested objects that are merged are the same instance on both dicts. If you want a deep copy along with the merge then use the `deepCopy` function along with merging. For example, ``` deepCopy $source | mergeOverwrite $dest ``` `mustMergeOverwrite` will return an error in case of unsuccessful merge. ### keys The `keys` function will return a `list` of all of the keys in one or more `dict` types. Since a dictionary is _unordered_, the keys will not be in a predictable order. They can be sorted with `sortAlpha`. ``` keys $myDict | sortAlpha ``` When supplying multiple dictionaries, the keys will be concatenated. Use the `uniq` function along with `sortAlpha` to get a unique, sorted list of keys. ``` keys $myDict $myOtherDict | uniq | sortAlpha ``` ### pick The `pick` function selects just the given keys out of a dictionary, creating a new `dict`. ``` $new := pick $myDict "name1" "name2" ``` The above returns `{name1: value1, name2: value2}` ### omit The `omit` function is similar to `pick`, except it returns a new `dict` with all the keys that _do not_ match the given keys. ``` $new := omit $myDict "name1" "name3" ``` The above returns `{name2: value2}` ### values The `values` function is similar to `keys`, except it returns a new `list` with all the values of the source `dict` (only one dictionary is supported). ``` $vals := values $myDict ``` The above returns `list["value1", "value2", "value 3"]`. Note that the `values` function gives no guarantees about the result ordering; if you care about this, then use `sortAlpha`. ### deepCopy, mustDeepCopy The `deepCopy` and `mustDeepCopy` functions take a value and make a deep copy of the value. This includes dicts and other structures. `deepCopy` panics when there is a problem, while `mustDeepCopy` returns an error to the template system when there is an error. ``` dict "a" 1 "b" 2 | deepCopy ``` ### A Note on Dict Internals A `dict` is implemented in Go as a `map[string]interface{}`. Go developers can pass `map[string]interface{}` values into the context to make them available to templates as `dict`s. ## Encoding Functions Helm has the following encoding and decoding functions: - `b64enc`/`b64dec`: Encode or decode with Base64 - `b32enc`/`b32dec`: Encode or decode with Base32 ## Lists and List Functions Helm provides a simple `list` type that can contain arbitrary sequential lists of data. This is similar to arrays or slices, but lists are designed to be used as immutable data types. Create a list of integers: ``` $myList := list 1 2 3 4 5 ``` The above creates a list of `[1 2 3 4 5]`. Helm provides the following list functions: [append (mustAppend)](#append-mustappend), [chunk](#chunk), [compact (mustCompact)](#compact-mustcompact), [concat](#concat), [first (mustFirst)](#first-mustfirst), [has (mustHas)](#has-musthas), [initial (mustInitial)](#initial-mustinitial), [last (mustLast)](#last-mustlast), [prepend (mustPrepend)](#prepend-mustprepend), [rest (mustRest)](#rest-mustrest), [reverse (mustReverse)](#reverse-mustreverse), [seq](#seq), [index](#index), [slice (mustSlice)](#slice-mustslice), [uniq (mustUniq)](#uniq-mustuniq), [until](#until), [untilStep](#untilstep), and [without (mustWithout)](#without-mustwithout). ### first, mustFirst To get the head item on a list, use `first`. `first $myList` returns `1` `first` panics if there is a problem, while `mustFirst` returns an error to the template engine if there is a problem. ### rest, mustRest To get the tail of the list (everything but the first item), use `rest`. `rest $myList` returns `[2 3 4 5]` `rest` panics if there is a problem, while `mustRest` returns an error to the template engine if there is a problem. ### last, mustLast To get the last item on a list, use `last`: `last $myList` returns `5`. This is roughly analogous to reversing a list and then calling `first`. ### initial, mustInitial This compliments `last` by returning all _but_ the last element. `initial $myList` returns `[1 2 3 4]`. `initial` panics if there is a problem, while `mustInitial` returns an error to the template engine if there is a problem. ### append, mustAppend Append a new item to an existing list, creating a new list. ``` $new = append $myList 6 ``` The above would set `$new` to `[1 2 3 4 5 6]`. `$myList` would remain unaltered. `append` panics if there is a problem, while `mustAppend` returns an error to the template engine if there is a problem. ### prepend, mustPrepend Push an element onto the front of a list, creating a new list. ``` prepend $myList 0 ``` The above would produce `[0 1 2 3 4 5]`. `$myList` would remain unaltered. `prepend` panics if there is a problem, while `mustPrepend` returns an error to the template engine if there is a problem. ### concat Concatenate arbitrary number of lists into one. ``` concat $myList ( list 6 7 ) ( list 8 ) ``` The above would produce `[1 2 3 4 5 6 7 8]`. `$myList` would remain unaltered. ### reverse, mustReverse Produce a new list with the reversed elements of the given list. ``` reverse $myList ``` The above would generate the list `[5 4 3 2 1]`. `reverse` panics if there is a problem, while `mustReverse` returns an error to the template engine if there is a problem. ### uniq, mustUniq Generate a list with all of the duplicates removed. ``` list 1 1 1 2 | uniq ``` The above would produce `[1 2]` `uniq` panics if there is a problem, while `mustUniq` returns an error to the template engine if there is a problem. ### without, mustWithout The `without` function filters items out of a list. ``` without $myList 3 ``` The above would produce `[1 2 4 5]` `without` can take more than one filter: ``` without $myList 1 3 5 ``` That would produce `[2 4]` `without` panics if there is a problem, while `mustWithout` returns an error to the template engine if there is a problem. ### has, mustHas Test to see if a list has a particular element. ``` has 4 $myList ``` The above would return `true`, while `has "hello" $myList` would return false. `has` panics if there is a problem, while `mustHas` returns an error to the template engine if there is a problem. ### compact, mustCompact Accepts a list and removes entries with empty values. ``` $list := list 1 "a" "foo" "" $copy := compact $list ``` `compact` will return a new list with the empty (i.e., "") item removed. `compact` panics if there is a problem and `mustCompact` returns an error to the template engine if there is a problem. ### index To get the nth element of a list, use `index list [n]`. To index into multi-dimensional lists, use `index list [n] [m] ...` - `index $myList 0` returns `1`. It is the same as `myList[0]` - `index $myList 0 1` would be the same as `myList[0][1]` ### slice, mustSlice To get partial elements of a list, use `slice list [n] [m]`. It is equivalent of `list[n:m]`. - `slice $myList` returns `[1 2 3 4 5]`. It is same as `myList[:]`. - `slice $myList 3` returns `[4 5]`. It is same as `myList[3:]`. - `slice $myList 1 3` returns `[2 3]`. It is same as `myList[1:3]`. - `slice $myList 0 3` returns `[1 2 3]`. It is same as `myList[:3]`. `slice` panics if there is a problem, while `mustSlice` returns an error to the template engine if there is a problem. ### until The `until` function builds a range of integers. ``` until 5 ``` The above generates the list `[0, 1, 2, 3, 4]`. This is useful for looping with `range $i, $e := until 5`. ### untilStep Like `until`, `untilStep` generates a list of counting integers. But it allows you to define a start, stop, and step: ``` untilStep 3 6 2 ``` The above will produce `[3 5]` by starting with 3, and adding 2 until it is equal or greater than 6. This is similar to Python's `range` function. ### seq Works like the bash `seq` command. * 1 parameter (end) - will generate all counting integers between 1 and `end` inclusive. * 2 parameters (start, end) - will generate all counting integers between `start` and `end` inclusive incrementing or decrementing by 1. * 3 parameters (start, step, end) - will generate all counting integers between `start` and `end` inclusive incrementing or decrementing by `step`. ``` seq 5 => 1 2 3 4 5 seq -3 => 1 0 -1 -2 -3 seq 0 2 => 0 1 2 seq 2 -2 => 2 1 0 -1 -2 seq 0 2 10 => 0 2 4 6 8 10 seq 0 -2 -5 => 0 -2 -4 ``` ### chunk To split a list into chunks of given size, use `chunk size list`. This is useful for pagination. ``` chunk 3 (list 1 2 3 4 5 6 7 8) ``` This produces list of lists `[ [ 1 2 3 ] [ 4 5 6 ] [ 7 8 ] ]`. ## Math Functions All math functions operate on `int64` values unless specified otherwise. The following math functions are available: [add](#add), [add1](#add1), [ceil](#ceil), [div](#div), [floor](#floor), [len](#len), [max](#max), [min](#min), [mod](#mod), [mul](#mul), [round](#round), and [sub](#sub). ### add Sum numbers with `add`. Accepts two or more inputs. ``` add 1 2 3 ``` ### add1 To increment by 1, use `add1`. ### sub To subtract, use `sub`. ### div Perform integer division with `div`. ### mod Modulo with `mod`. ### mul Multiply with `mul`. Accepts two or more inputs. ``` mul 1 2 3 ``` ### max Return the largest of a series of integers. This will return `3`: ``` max 1 2 3 ``` ### min Return the smallest of a series of integers. `min 1 2 3` will return `1`. ### len Returns the length of the argument as an integer. ``` len .Arg ``` ## Float Math Functions All math functions operate on `float64` values. ### addf Sum numbers with `addf` This will return `5.5`: ``` addf 1.5 2 2 ``` ### add1f To increment by 1, use `add1f` ### subf To subtract, use `subf` This is equivalent to `7.5 - 2 - 3` and will return `2.5`: ``` subf 7.5 2 3 ``` ### divf Perform integer division with `divf` This is equivalent to `10 / 2 / 4` and will return `1.25`: ``` divf 10 2 4 ``` ### mulf Multiply with `mulf` This will return `6`: ``` mulf 1.5 2 2 ``` ### maxf Return the largest of a series of floats: This will return `3`: ``` maxf 1 2.5 3 ``` ### minf Return the smallest of a series of floats. This will return `1.5`: ``` minf 1.5 2 3 ``` ### floor Returns the greatest float value less than or equal to input value. `floor 123.9999` will return `123.0`. ### ceil Returns the greatest float value greater than or equal to input value. `ceil 123.001` will return `124.0`. ### round Returns a float value with the remainder rounded to the given number to digits after the decimal point. `round 123.555555 3` will return `123.556`. ## Network Functions Helm has a single network function, `getHostByName`. The `getHostByName` receives a domain name and returns the ip address. `getHostByName "www.google.com"` would return the corresponding ip address of `www.google.com`. This function requires the `--enable-dns` option to be passed on the helm command line. ## File Path Functions While Helm template functions do not grant access to the filesystem, they do provide functions for working with strings that follow file path conventions. Those include [base](#base), [clean](#clean), [dir](#dir), [ext](#ext), and [isAbs](#isabs). ### base Return the last element of a path. ``` base "foo/bar/baz" ``` The above prints "baz". ### dir Return the directory, stripping the last part of the path. So `dir "foo/bar/baz"` returns `foo/bar`. ### clean Clean up a path. ``` clean "foo/bar/../baz" ``` The above resolves the `..` and returns `foo/baz`. ### ext Return the file extension. ``` ext "foo.bar" ``` The above returns `.bar`. ### isAbs To check whether a file path is absolute, use `isAbs`. ## Reflection Functions Helm provides rudimentary reflection tools. These help advanced template developers understand the underlying Go type information for a particular value. Helm is written in Go and is strongly typed. The type system applies within templates. Go has several primitive _kinds_, like `string`, `slice`, `int64`, and `bool`. Go has an open _type_ system that allows developers to create their own types. Helm provides a set of functions for each via [kind functions](#kind-functions) and [type functions](#type-functions). A [deepEqual](#deepequal) function is also provided to compare to values. ### Kind Functions There are two Kind functions: `kindOf` returns the kind of an object. ``` kindOf "hello" ``` The above would return `string`. For simple tests (like in `if` blocks), the `kindIs` function will let you verify that a value is a particular kind: ``` kindIs "int" 123 ``` The above will return `true`. ### Type Functions Types are slightly harder to work with, so there are three different functions: - `typeOf` returns the underlying type of a value: `typeOf $foo` - `typeIs` is like `kindIs`, but for types: `typeIs "*io.Buffer" $myVal` - `typeIsLike` works as `typeIs`, except that it also dereferences pointers **Note:** None of these can test whether or not something implements a given interface, since doing so would require compiling the interface in ahead of time. ### deepEqual `deepEqual` returns true if two values are ["deeply equal"](https://golang.org/pkg/reflect/#DeepEqual) Works for non-primitive types as well (compared to the built-in `eq`). ``` deepEqual (list 1 2 3) (list 1 2 3) ``` The above will return `true`. ## Semantic Version Functions Some version schemes are easily parseable and comparable. Helm provides functions for working with [SemVer 2](http://semver.org) versions. These include [semver](#semver) and [semverCompare](#semvercompare). Below you will also find details on using ranges for comparisons. ### semver The `semver` function parses a string into a Semantic Version: ``` $version := semver "1.2.3-alpha.1+123" ``` _If the parser fails, it will cause template execution to halt with an error._ At this point, `$version` is a pointer to a `Version` object with the following properties: - `$version.Major`: The major number (`1` above) - `$version.Minor`: The minor number (`2` above) - `$version.Patch`: The patch number (`3` above) - `$version.Prerelease`: The prerelease (`alpha.1` above) - `$version.Metadata`: The build metadata (`123` above) - `$version.Original`: The original version as a string Additionally, you can compare a `Version` to another `version` using the `Compare` function: ``` semver "1.4.3" | (semver "1.2.3").Compare ``` The above will return `-1`. The return values are: - `-1` if the given semver is greater than the semver whose `Compare` method was called - `1` if the version who's `Compare` function was called is greater. - `0` if they are the same version (Note that in SemVer, the `Metadata` field is not compared during version comparison operations.) ### semverCompare A more robust comparison function is provided as `semverCompare`. This version supports version ranges: - `semverCompare "1.2.3" "1.2.3"` checks for an exact match - `semverCompare "~1.2.0" "1.2.3"` checks that the major and minor versions match, and that the patch number of the second version is _greater than or equal to_ the first parameter. The SemVer functions use the [Masterminds semver library](https://github.com/Masterminds/semver), from the creators of Sprig. ### Basic Comparisons There are two elements to the comparisons. First, a comparison string is a list of space or comma separated AND comparisons. These are then separated by || (OR) comparisons. For example, `">= 1.2 < 3.0.0 || >= 4.2.3"` is looking for a comparison that's greater than or equal to 1.2 and less than 3.0.0 or is greater than or equal to 4.2.3. The basic comparisons are: - `=`: equal (aliased to no operator) - `!=`: not equal - `>`: greater than - `<`: less than - `>=`: greater than or equal to - `<=`: less than or equal to ### Working With Prerelease Versions Pre-releases, for those not familiar with them, are used for software releases prior to stable or generally available releases. Examples of prereleases include development, alpha, beta, and release candidate releases. A prerelease may be a version such as `1.2.3-beta.1`, while the stable release would be `1.2.3`. In the order of precedence, prereleases come before their associated releases. In this example `1.2.3-beta.1 < 1.2.3`. According to the Semantic Version specification prereleases may not be API compliant with their release counterpart. It says, > A pre-release version indicates that the version is unstable and might not > satisfy the intended compatibility requirements as denoted by its associated > normal version. SemVer comparisons using constraints without a prerelease comparator will skip prerelease versions. For example, `>=1.2.3` will skip prereleases when looking at a list of releases, while `>=1.2.3-0` will evaluate and find prereleases. The reason for the `0` as a pre-release version in the example comparison is because pre-releases can only contain ASCII alphanumerics and hyphens (along with `.` separators), per the spec. Sorting happens in ASCII sort order, again per the spec. The lowest character is a `0` in ASCII sort order (see an [ASCII Table](http://www.asciitable.com/)) Understanding ASCII sort ordering is important because A-Z comes before a-z. That means `>=1.2.3-BETA` will return `1.2.3-alpha`. What you might expect from case sensitivity doesn't apply here. This is due to ASCII sort ordering which is what the spec specifies. ### Hyphen Range Comparisons There are multiple methods to handle ranges and the first is hyphens ranges. These look like: - `1.2 - 1.4.5` which is equivalent to `>= 1.2 <= 1.4.5` - `2.3.4 - 4.5` which is equivalent to `>= 2.3.4 <= 4.5` ### Wildcards In Comparisons The `x`, `X`, and `*` characters can be used as a wildcard character. This works for all comparison operators. When used on the `=` operator it falls back to the patch level comparison (see tilde below). For example, - `1.2.x` is equivalent to `>= 1.2.0, < 1.3.0` - `>= 1.2.x` is equivalent to `>= 1.2.0` - `<= 2.x` is equivalent to `< 3` - `*` is equivalent to `>= 0.0.0` ### Tilde Range Comparisons (Patch) The tilde (`~`) comparison operator is for patch level ranges when a minor version is specified and major level changes when the minor number is missing. For example, - `~1.2.3` is equivalent to `>= 1.2.3, < 1.3.0` - `~1` is equivalent to `>= 1, < 2` - `~2.3` is equivalent to `>= 2.3, < 2.4` - `~1.2.x` is equivalent to `>= 1.2.0, < 1.3.0` - `~1.x` is equivalent to `>= 1, < 2` ### Caret Range Comparisons (Major) The caret (`^`) comparison operator is for major level changes once a stable (1.0.0) release has occurred. Prior to a 1.0.0 release the minor versions acts as the API stability level. This is useful when comparisons of API versions as a major change is API breaking. For example, - `^1.2.3` is equivalent to `>= 1.2.3, < 2.0.0` - `^1.2.x` is equivalent to `>= 1.2.0, < 2.0.0` - `^2.3` is equivalent to `>= 2.3, < 3` - `^2.x` is equivalent to `>= 2.0.0, < 3` - `^0.2.3` is equivalent to `>=0.2.3 <0.3.0` - `^0.2` is equivalent to `>=0.2.0 <0.3.0` - `^0.0.3` is equivalent to `>=0.0.3 <0.0.4` - `^0.0` is equivalent to `>=0.0.0 <0.1.0` - `^0` is equivalent to `>=0.0.0 <1.0.0` ## URL Functions Helm includes the [urlParse](#urlparse), [urlJoin](#urljoin), and [urlquery](#urlquery) functions enabling you to work with URL parts. ### urlParse Parses string for URL and produces dict with URL parts ``` urlParse "http://admin:secret@server.com:8080/api?list=false#anchor" ``` The above returns a dict, containing URL object: ```yaml scheme: 'http' host: 'server.com:8080' path: '/api' query: 'list=false' opaque: nil fragment: 'anchor' userinfo: 'admin:secret' ``` This is implemented used the URL packages from the Go standard library. For more info, check https://golang.org/pkg/net/url/#URL ### urlJoin Joins map (produced by `urlParse`) to produce URL string ``` urlJoin (dict "fragment" "fragment" "host" "host:80" "path" "/path" "query" "query" "scheme" "http") ``` The above returns the following string: ``` http://host:80/path?query#fragment ``` ### urlquery Returns the escaped version of the value passed in as an argument so that it is suitable for embedding in the query portion of a URL. ``` $var := urlquery "string for query" ``` ## UUID Functions Helm can generate UUID v4 universally unique IDs. ``` uuidv4 ``` The above returns a new UUID of the v4 (randomly generated) type. ## Kubernetes and Chart Functions Helm includes functions for working with Kubernetes including [.Capabilities.APIVersions.Has](#capabilitiesapiversionshas), [Files](#file-functions), and [lookup](#lookup). ### lookup `lookup` is used to look up resource in a running cluster. When used with the `helm template` command it always returns an empty response. You can find more detail in the [documentation on the lookup function](/chart_template_guide/functions_and_pipelines.md#using-the-lookup-function). ### .Capabilities.APIVersions.Has Returns if an API version or resource is available in a cluster. ``` .Capabilities.APIVersions.Has "apps/v1" .Capabilities.APIVersions.Has "apps/v1/Deployment" ``` More information is available on the [built-in object documentation](/chart_template_guide/builtin_objects.md). ### File Functions There are several functions that enable you to get to non-special files within a chart. For example, to access application configuration files. These are documented in [Accessing Files Inside Templates](/chart_template_guide/accessing_files.md). _Note, the documentation for many of these functions come from [Sprig](https://github.com/Masterminds/sprig). Sprig is a template function library available to Go applications._ ================================================ FILE: versioned_docs/version-3/chart_template_guide/functions_and_pipelines.md ================================================ --- title: Template Functions and Pipelines description: Using functions in templates. sidebar_position: 5 --- So far, we've seen how to place information into a template. But that information is placed into the template unmodified. Sometimes we want to transform the supplied data in a way that makes it more useable to us. Let's start with a best practice: When injecting strings from the `.Values` object into the template, we ought to quote these strings. We can do that by calling the `quote` function in the template directive: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ quote .Values.favorite.drink }} food: {{ quote .Values.favorite.food }} ``` Template functions follow the syntax `functionName arg1 arg2...`. In the snippet above, `quote .Values.favorite.drink` calls the `quote` function and passes it a single argument. Helm has over 60 available functions. Some of them are defined by the [Go template language](https://godoc.org/text/template) itself. Most of the others are part of the [Sprig template library](https://masterminds.github.io/sprig/). We'll see many of them as we progress through the examples. > While we talk about the "Helm template language" as if it is Helm-specific, it > is actually a combination of the Go template language, some extra functions, > and a variety of wrappers to expose certain objects to the templates. Many > resources on Go templates may be helpful as you learn about templating. ## Pipelines One of the powerful features of the template language is its concept of _pipelines_. Drawing on a concept from UNIX, pipelines are a tool for chaining together a series of template commands to compactly express a series of transformations. In other words, pipelines are an efficient way of getting several things done in sequence. Let's rewrite the above example using a pipeline. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | quote }} ``` In this example, instead of calling `quote ARGUMENT`, we inverted the order. We "sent" the argument to the function using a pipeline (`|`): `.Values.favorite.drink | quote`. Using pipelines, we can chain several functions together: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` > Inverting the order is a common practice in templates. You will see `.val | > quote` more often than `quote .val`. Either practice is fine. When evaluated, that template will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: trendsetting-p-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Note that our original `pizza` has now been transformed to `"PIZZA"`. When pipelining arguments like this, the result of the first evaluation (`.Values.favorite.drink`) is sent as the _last argument to the function_. We can modify the drink example above to illustrate with a function that takes two arguments: `repeat COUNT STRING`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink | repeat 5 | quote }} food: {{ .Values.favorite.food | upper | quote }} ``` The `repeat` function will echo the given string the given number of times, so we will get this for output: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: melting-porcup-configmap data: myvalue: "Hello World" drink: "coffeecoffeecoffeecoffeecoffee" food: "PIZZA" ``` ## Using the `default` function One function frequently used in templates is the `default` function: `default DEFAULT_VALUE GIVEN_VALUE`. This function allows you to specify a default value inside of the template, in case the value is omitted. Let's use it to modify the drink example above: ```yaml drink: {{ .Values.favorite.drink | default "tea" | quote }} ``` If we run this as normal, we'll get our `coffee`: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: virtuous-mink-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" ``` Now, we will remove the favorite drink setting from `values.yaml`: ```yaml favorite: #drink: coffee food: pizza ``` Now re-running `helm install --dry-run --debug fair-worm ./mychart` will produce this YAML: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: fair-worm-configmap data: myvalue: "Hello World" drink: "tea" food: "PIZZA" ``` In an actual chart, all static default values should live in the `values.yaml`, and should not be repeated using the `default` command (otherwise they would be redundant). However, the `default` command is perfect for computed values, which cannot be declared inside `values.yaml`. For example: ```yaml drink: {{ .Values.favorite.drink | default (printf "%s-tea" (include "fullname" .)) }} ``` In some places, an `if` conditional guard may be better suited than `default`. We'll see those in the next section. Template functions and pipelines are a powerful way to transform information and then insert it into your YAML. But sometimes it's necessary to add some template logic that is a little more sophisticated than just inserting a string. In the next section we will look at the control structures provided by the template language. ## Using the `lookup` function The `lookup` function can be used to _look up_ resources in a running cluster. The synopsis of the lookup function is `lookup apiVersion, kind, namespace, name -> resource or resource list`. | parameter | type | |------------|--------| | apiVersion | string | | kind | string | | namespace | string | | name | string | Both `name` and `namespace` are optional and can be passed as an empty string (`""`). However, if you're working with a namespace-scoped resource, both `name` and `namespace` must be specified. The following combination of parameters are possible: | Behavior | Lookup function | |----------------------------------------|--------------------------------------------| | `kubectl get pod mypod -n mynamespace` | `lookup "v1" "Pod" "mynamespace" "mypod"` | | `kubectl get pods -n mynamespace` | `lookup "v1" "Pod" "mynamespace" ""` | | `kubectl get pods --all-namespaces` | `lookup "v1" "Pod" "" ""` | | `kubectl get namespace mynamespace` | `lookup "v1" "Namespace" "" "mynamespace"` | | `kubectl get namespaces` | `lookup "v1" "Namespace" "" ""` | When `lookup` returns an object, it will return a dictionary. This dictionary can be further navigated to extract specific values. The following example will return the annotations present for the `mynamespace` object: ```go (lookup "v1" "Namespace" "" "mynamespace").metadata.annotations ``` When `lookup` returns a list of objects, it is possible to access the object list via the `items` field: ```go {{ range $index, $service := (lookup "v1" "Service" "mynamespace" "").items }} {{/* do something with each service */}} {{ end }} ``` When no object is found, an empty value is returned. This can be used to check for the existence of an object. The `lookup` function uses Helm's existing Kubernetes connection configuration to query Kubernetes. If any error is returned when interacting with calling the API server (for example due to lack of permission to access a resource), Helm's template processing will fail. Keep in mind that Helm is not supposed to contact the Kubernetes API Server during a `helm template|install|upgrade|delete|rollback --dry-run` operation. To test `lookup` against a running cluster, `helm template|install|upgrade|delete|rollback --dry-run=server` should be used instead to allow cluster connection. ## Operators are functions For templates, the operators (`eq`, `ne`, `lt`, `gt`, `and`, `or` and so on) are all implemented as functions. In pipelines, operations can be grouped with parentheses (`(`, and `)`). Now we can turn from functions and pipelines to flow control with conditions, loops, and scope modifiers. ================================================ FILE: versioned_docs/version-3/chart_template_guide/getting_started.md ================================================ --- title: Getting Started description: A quick guide on Chart templates. sidebar_position: 2 --- In this section of the guide, we'll create a chart and then add a first template. The chart we created here will be used throughout the rest of the guide. To get going, let's take a brief look at a Helm chart. ## Charts As described in the [Charts Guide](/topics/charts.md), Helm charts are structured like this: ``` mychart/ Chart.yaml values.yaml charts/ templates/ ... ``` The `templates/` directory is for template files. When Helm evaluates a chart, it will send all of the files in the `templates/` directory through the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes. The `values.yaml` file is also important to templates. This file contains the _default values_ for a chart. These values may be overridden by users during `helm install` or `helm upgrade`. The `Chart.yaml` file contains a description of the chart. You can access it from within a template. The `charts/` directory _may_ contain other charts (which we call _subcharts_). Later in this guide we will see how those work when it comes to template rendering. ## A Starter Chart For this guide, we'll create a simple chart called `mychart`, and then we'll create some templates inside of the chart. ```console $ helm create mychart Creating mychart ``` ### A Quick Glimpse of `mychart/templates/` If you take a look at the `mychart/templates/` directory, you'll notice a few files already there. - `NOTES.txt`: The "help text" for your chart. This will be displayed to your users when they run `helm install`. - `deployment.yaml`: A basic manifest for creating a Kubernetes [deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) - `service.yaml`: A basic manifest for creating a [service endpoint](https://kubernetes.io/docs/concepts/services-networking/service/) for your deployment - `_helpers.tpl`: A place to put template helpers that you can re-use throughout the chart And what we're going to do is... _remove them all!_ That way we can work through our tutorial from scratch. We'll actually create our own `NOTES.txt` and `_helpers.tpl` as we go. ```console $ rm -rf mychart/templates/* ``` When you're writing production grade charts, having basic versions of these charts can be really useful. So in your day-to-day chart authoring, you probably won't want to remove them. ## A First Template The first template we are going to create will be a `ConfigMap`. In Kubernetes, a ConfigMap is simply an object for storing configuration data. Other things, like pods, can access the data in a ConfigMap. Because ConfigMaps are basic resources, they make a great starting point for us. Let's begin by creating a file called `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` **TIP:** Template names do not follow a rigid naming pattern. However, we recommend using the extension `.yaml` for YAML files and `.tpl` for helpers. The YAML file above is a bare-bones ConfigMap, having the minimal necessary fields. By virtue of the fact that this file is in the `mychart/templates/` directory, it will be sent through the template engine. It is just fine to put a plain YAML file like this in the `mychart/templates/` directory. When Helm reads this template, it will simply send it to Kubernetes as-is. With this simple template, we now have an installable chart. And we can install it like this: ```console $ helm install full-coral ./mychart NAME: full-coral LAST DEPLOYED: Tue Nov 1 17:36:01 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` Using Helm, we can retrieve the release and see the actual template that was loaded. ```console $ helm get manifest full-coral --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mychart-configmap data: myvalue: "Hello World" ``` The `helm get manifest` command takes a release name (`full-coral`) and prints out all of the Kubernetes resources that were uploaded to the server. Each file begins with `---` to indicate the start of a YAML document, and then is followed by an automatically generated comment line that tells us what template file generated this YAML document. From there on, we can see that the YAML data is exactly what we put in our `configmap.yaml` file. Now we can uninstall our release: `helm uninstall full-coral`. ### Adding a Simple Template Call Hard-coding the `name:` into a resource is usually considered to be bad practice. Names should be unique to a release. So we might want to generate a name field by inserting the release name. **TIP:** The `name:` field is limited to 63 characters because of limitations to the DNS system. For that reason, release names are limited to 53 characters. Kubernetes 1.3 and earlier limited to only 24 characters (thus 14 character names). Let's alter `configmap.yaml` accordingly. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" ``` The big change comes in the value of the `name:` field, which is now `{{ .Release.Name }}-configmap`. > A template directive is enclosed in `{{` and `}}` blocks. The template directive `{{ .Release.Name }}` injects the release name into the template. The values that are passed into a template can be thought of as _namespaced objects_, where a dot (`.`) separates each namespaced element. The leading dot before `Release` indicates that we start with the top-most namespace for this scope (we'll talk about scope in a bit). So we could read `.Release.Name` as "start at the top namespace, find the `Release` object, then look inside of it for an object called `Name`". The `Release` object is one of the built-in objects for Helm, and we'll cover it in more depth later. But for now, it is sufficient to say that this will display the release name that the library assigns to our release. Now when we install our resource, we'll immediately see the result of using this template directive: ```console $ helm install clunky-serval ./mychart NAME: clunky-serval LAST DEPLOYED: Tue Nov 1 17:45:37 2016 NAMESPACE: default STATUS: DEPLOYED REVISION: 1 TEST SUITE: None ``` You can run `helm get manifest clunky-serval` to see the entire generated YAML. Note that the ConfigMap inside Kubernetes name is `clunky-serval-configmap` instead of `mychart-configmap` previously. At this point, we've seen templates at their most basic: YAML files that have template directives embedded in `{{` and `}}`. In the next part, we'll take a deeper look into templates. But before moving on, there's one quick trick that can make building templates faster: When you want to test the template rendering, but not actually install anything, you can use `helm install --debug --dry-run goodly-guppy ./mychart`. This will render the templates. But instead of installing the chart, it will return the rendered template to you so you can see the output: ```console $ helm install --debug --dry-run goodly-guppy ./mychart install.go:149: [debug] Original chart version: "" install.go:166: [debug] CHART PATH: /Users/ninja/mychart NAME: goodly-guppy LAST DEPLOYED: Thu Dec 26 17:24:13 2019 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: goodly-guppy-configmap data: myvalue: "Hello World" ``` Using `--dry-run` will make it easier to test your code, but it won't ensure that Kubernetes itself will accept the templates you generate. It's best not to assume that your chart will install just because `--dry-run` works. In the [Chart Template Guide](/chart_template_guide/index.mdx), we take the basic chart we defined here and explore the Helm template language in detail. And we'll get started with built-in objects. ================================================ FILE: versioned_docs/version-3/chart_template_guide/helm_ignore_file.md ================================================ --- title: The .helmignore file description: The `.helmignore` file is used to specify files you don't want to include in your helm chart. sidebar_position: 12 --- The `.helmignore` file is used to specify files you don't want to include in your helm chart. If this file exists, the `helm package` command will ignore all the files that match the pattern specified in the `.helmignore` file while packaging your application. This can help in avoiding unnecessary or sensitive files or directories from being added in your helm chart. The `.helmignore` file supports Unix shell glob matching, relative path matching, and negation (prefixed with !). Only one pattern per line is considered. Here is an example `.helmignore` file: ``` # comment # Match any file or path named .helmignore .helmignore # Match any file or path named .git .git # Match any text file *.txt # Match only directories named mydir mydir/ # Match only text files in the top-level directory /*.txt # Match only the file foo.txt in the top-level directory /foo.txt # Match any file named ab.txt, ac.txt, or ad.txt a[b-d].txt # Match any file under subdir matching temp* */temp* */*/temp* temp? ``` Some notable differences from .gitignore: - The '**' syntax is not supported. - The globbing library is Go's 'filepath.Match', not fnmatch(3) - Trailing spaces are always ignored (there is no supported escape sequence) - There is no support for '\!' as a special leading sequence. - It does not exclude itself by default, you have to add an explicit entry for `.helmignore` **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm-www/issues) or send us a pull request. ================================================ FILE: versioned_docs/version-3/chart_template_guide/index.mdx ================================================ --- title: Chart Template Guide sidebar_position: 5 --- # The Chart Template Developer's Guide This guide provides an introduction to Helm's chart templates, with emphasis on the template language. Templates generate manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. We'll look at how templates are structured, how they can be used, how to write Go templates, and how to debug your work. This guide focuses on the following concepts: - The Helm template language - Using values - Techniques for working with templates This guide is oriented toward learning the ins and outs of the Helm template language. Other guides provide introductory material, examples, and best practices. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/chart_template_guide/named_templates.md ================================================ --- title: Named Templates description: How to define named templates. sidebar_position: 9 --- It is time to move beyond one template, and begin to create others. In this section, we will see how to define _named templates_ in one file, and then use them elsewhere. A _named template_ (sometimes called a _partial_ or a _subtemplate_) is simply a template defined inside of a file, and given a name. We'll see two ways to create them, and a few different ways to use them. In the [Flow Control](/chart_template_guide/control_structures.md) section we introduced three actions for declaring and managing templates: `define`, `template`, and `block`. In this section, we'll cover those three actions, and also introduce a special-purpose `include` function that works similarly to the `template` action. An important detail to keep in mind when naming templates: **template names are global**. If you declare two templates with the same name, whichever one is loaded last will be the one used. Because templates in subcharts are compiled together with top-level templates, you should be careful to name your templates with _chart-specific names_. One popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. By using the specific chart name as a prefix we can avoid any conflicts that may arise due to two different charts that implement templates of the same name. This behavior also applies to different versions of a chart. If you have `mychart` version `1.0.0` that defines a template one way, and a `mychart` version `2.0.0` that modifies the existing named template, it will use the one that was loaded last. You can work around this issue by also adding a version in the name of the chart: `{{ define "mychart.v1.labels" }}` and `{{ define "mychart.v2.labels" }}`. ## Partials and `_` files So far, we've used one file, and that one file has contained a single template. But Helm's template language allows you to create named embedded templates, that can be accessed by name elsewhere. Before we get to the nuts-and-bolts of writing those templates, there is file naming convention that deserves mention: * Most files in `templates/` are treated as if they contain Kubernetes manifests * The `NOTES.txt` is one exception * But files whose name begins with an underscore (`_`) are assumed to _not_ have a manifest inside. These files are not rendered to Kubernetes object definitions, but are available everywhere within other chart templates for use. These files are used to store partials and helpers. In fact, when we first created `mychart`, we saw a file called `_helpers.tpl`. That file is the default location for template partials. ## Declaring and using templates with `define` and `template` The `define` action allows us to create a named template inside of a template file. Its syntax goes like this: ```yaml {{- define "MY.NAME" }} # body of template here {{- end }} ``` For example, we can define a template to encapsulate a Kubernetes block of labels: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` Now we can embed this template inside of our existing ConfigMap, and then include it with the `template` action: ```yaml {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` When the template engine reads this file, it will store away the reference to `mychart.labels` until `template "mychart.labels"` is called. Then it will render that template inline. So the result will look like this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: running-panda-configmap labels: generator: helm date: 2016-11-02 data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Note: a `define` does not produce output unless it is called with a template, as in this example. Conventionally, Helm charts put these templates inside of a partials file, usually `_helpers.tpl`. Let's move this function there: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} {{- end }} ``` By convention, `define` functions should have a simple documentation block (`{{/* ... */}}`) describing what they do. Even though this definition is in `_helpers.tpl`, it can still be accessed in `configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` As mentioned above, **template names are global**. As a result of this, if two templates are declared with the same name the last occurrence will be the one that is used. Since templates in subcharts are compiled together with top-level templates, it is best to name your templates with _chart specific names_. A popular naming convention is to prefix each defined template with the name of the chart: `{{ define "mychart.labels" }}`. ## Setting the scope of a template In the template we defined above, we did not use any objects. We just used functions. Let's modify our defined template to include the chart name and chart version: ```yaml {{/* Generate basic labels */}} {{- define "mychart.labels" }} labels: generator: helm date: {{ now | htmlDate }} chart: {{ .Chart.Name }} version: {{ .Chart.Version }} {{- end }} ``` If we render this, we will get an error like this: ```console $ helm install --dry-run moldy-jaguar ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [unknown object type "nil" in ConfigMap.metadata.labels.chart, unknown object type "nil" in ConfigMap.metadata.labels.version] ``` To see what rendered, re-run with `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation moldy-jaguar ./mychart`. The result will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: moldy-jaguar-configmap labels: generator: helm date: 2021-03-06 chart: version: ``` What happened to the name and version? They weren't in the scope for our defined template. When a named template (created with `define`) is rendered, it will receive the scope passed in by the `template` call. In our example, we included the template like this: ```yaml {{- template "mychart.labels" }} ``` No scope was passed in, so within the template we cannot access anything in `.`. This is easy enough to fix, though. We simply pass a scope to the template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap {{- template "mychart.labels" . }} ``` Note that we pass `.` at the end of the `template` call. We could just as easily pass `.Values` or `.Values.favorite` or whatever scope we want. But what we want is the top-level scope. In the context of the named template, `$` will refer to the scope you passed in and not some global scope. Now when we execute this template with `helm install --dry-run --debug plinking-anaco ./mychart`, we get this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: plinking-anaco-configmap labels: generator: helm date: 2021-03-06 chart: mychart version: 0.1.0 ``` Now `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}` resolves to `0.1.0`. ## The `include` function Say we've defined a simple template that looks like this: ```yaml {{- define "mychart.app" -}} app_name: {{ .Chart.Name }} app_version: "{{ .Chart.Version }}" {{- end -}} ``` Now say I want to insert this both into the `labels:` section of my template, and also the `data:` section: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ template "mychart.app" . }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ template "mychart.app" . }} ``` If we render this, we will get an error like this: ```console $ helm install --dry-run measly-whippet ./mychart Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(ConfigMap): unknown field "app_name" in io.k8s.api.core.v1.ConfigMap, ValidationError(ConfigMap): unknown field "app_version" in io.k8s.api.core.v1.ConfigMap] ``` To see what rendered, re-run with `--disable-openapi-validation`: `helm install --dry-run --disable-openapi-validation measly-whippet ./mychart`. The output will not be what we expect: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: measly-whippet-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` Note that the indentation on `app_version` is wrong in both places. Why? Because the template that is substituted in has the text aligned to the left. Because `template` is an action, and not a function, there is no way to pass the output of a `template` call to other functions; the data is simply inserted inline. To work around this case, Helm provides an alternative to `template` that will import the contents of a template into the present pipeline where it can be passed along to other functions in the pipeline. Here's the example above, corrected to use `indent` to indent the `mychart.app` template correctly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap labels: {{ include "mychart.app" . | indent 4 }} data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} {{ include "mychart.app" . | indent 2 }} ``` Now the produced YAML is correctly indented for each section: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: edgy-mole-configmap labels: app_name: mychart app_version: "0.1.0" data: myvalue: "Hello World" drink: "coffee" food: "pizza" app_name: mychart app_version: "0.1.0" ``` > It is considered preferable to use `include` over `template` in Helm templates > simply so that the output formatting can be handled better for YAML documents. Sometimes we want to import content, but not as templates. That is, we want to import files verbatim. We can achieve this by accessing files through the `.Files` object described in the next section. ================================================ FILE: versioned_docs/version-3/chart_template_guide/notes_files.md ================================================ --- title: Creating a NOTES.txt File description: How to provide instructions to your Chart users. sidebar_position: 10 --- In this section we are going to look at Helm's tool for providing instructions to your chart users. At the end of a `helm install` or `helm upgrade`, Helm can print out a block of helpful information for users. This information is highly customizable using templates. To add installation notes to your chart, simply create a `templates/NOTES.txt` file. This file is plain text, but it is processed like a template, and has all the normal template functions and objects available. Let's create a simple `NOTES.txt` file: ``` Thank you for installing {{ .Chart.Name }}. Your release is named {{ .Release.Name }}. To learn more about the release, try: $ helm status {{ .Release.Name }} $ helm get all {{ .Release.Name }} ``` Now if we run `helm install rude-cardinal ./mychart` we will see this message at the bottom: ``` RESOURCES: ==> v1/Secret NAME TYPE DATA AGE rude-cardinal-secret Opaque 1 0s ==> v1/ConfigMap NAME DATA AGE rude-cardinal-configmap 3 0s NOTES: Thank you for installing mychart. Your release is named rude-cardinal. To learn more about the release, try: $ helm status rude-cardinal $ helm get all rude-cardinal ``` Using `NOTES.txt` this way is a great way to give your users detailed information about how to use their newly installed chart. Creating a `NOTES.txt` file is strongly recommended, though it is not required. ================================================ FILE: versioned_docs/version-3/chart_template_guide/subcharts_and_globals.md ================================================ --- title: Subcharts and Global Values description: Interacting with a subchart's and global values. sidebar_position: 11 --- To this point we have been working only with one chart. But charts can have dependencies, called _subcharts_, that also have their own values and templates. In this section we will create a subchart and see the different ways we can access values from within templates. Before we dive into the code, there are a few important details to learn about application subcharts. 1. A subchart is considered "stand-alone", which means a subchart can never explicitly depend on its parent chart. 2. For that reason, a subchart cannot access the values of its parent. 3. A parent chart can override values for subcharts. 4. Helm has a concept of _global values_ that can be accessed by all charts. > These limitations do not all necessarily apply to [library charts](/topics/library_charts.md), which are designed to provide standardized helper functionality. As we walk through the examples in this section, many of these concepts will become clearer. ## Creating a Subchart For these exercises, we'll start with the `mychart/` chart we created at the beginning of this guide, and we'll add a new chart inside of it. ```console $ cd mychart/charts $ helm create mysubchart Creating mysubchart $ rm -rf mysubchart/templates/* ``` Notice that just as before, we deleted all of the base templates so that we can start from scratch. In this guide, we are focused on how templates work, not on managing dependencies. But the [Charts Guide](/topics/charts.md) has more information on how subcharts work. ## Adding Values and a Template to the Subchart Next, let's create a simple template and values file for our `mysubchart` chart. There should already be a `values.yaml` in `mychart/charts/mysubchart`. We'll set it up like this: ```yaml dessert: cake ``` Next, we'll create a new ConfigMap template in `mychart/charts/mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} ``` Because every subchart is a _stand-alone chart_, we can test `mysubchart` on its own: ```console $ helm install --generate-name --dry-run --debug mychart/charts/mysubchart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/helm.sh/helm/_scratch/mychart/charts/mysubchart NAME: newbie-elk TARGET NAMESPACE: default CHART: mysubchart 0.1.0 MANIFEST: --- # Source: mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: newbie-elk-cfgmap2 data: dessert: cake ``` ## Overriding Values from a Parent Chart Our original chart, `mychart` is now the _parent_ chart of `mysubchart`. This relationship is based entirely on the fact that `mysubchart` is within `mychart/charts`. Because `mychart` is a parent, we can specify configuration in `mychart` and have that configuration pushed into `mysubchart`. For example, we can modify `mychart/values.yaml` like this: ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream ``` Note the last two lines. Any directives inside of the `mysubchart` section will be sent to the `mysubchart` chart. So if we run `helm install --generate-name --dry-run --debug mychart`, one of the things we will see is the `mysubchart` ConfigMap: ```yaml # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: unhinged-bee-cfgmap2 data: dessert: ice cream ``` The value at the top level has now overridden the value of the subchart. There's an important detail to notice here. We didn't change the template of `mychart/charts/mysubchart/templates/configmap.yaml` to point to `.Values.mysubchart.dessert`. From that template's perspective, the value is still located at `.Values.dessert`. As the template engine passes values along, it sets the scope. So for the `mysubchart` templates, only values specifically for `mysubchart` will be available in `.Values`. Sometimes, though, you do want certain values to be available to all of the templates. This is accomplished using global chart values. ## Global Chart Values Global values are values that can be accessed from any chart or subchart by exactly the same name. Globals require explicit declaration. You can't use an existing non-global as if it were a global. The Values data type has a reserved section called `Values.global` where global values can be set. Let's set one in our `mychart/values.yaml` file. ```yaml favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions mysubchart: dessert: ice cream global: salad: caesar ``` Because of the way globals work, both `mychart/templates/configmap.yaml` and `mysubchart/templates/configmap.yaml` should be able to access that value as `{{ .Values.global.salad }}`. `mychart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: salad: {{ .Values.global.salad }} ``` `mysubchart/templates/configmap.yaml`: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-cfgmap2 data: dessert: {{ .Values.dessert }} salad: {{ .Values.global.salad }} ``` Now if we run a dry run install, we'll see the same value in both outputs: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-configmap data: salad: caesar --- # Source: mychart/charts/mysubchart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: silly-snake-cfgmap2 data: dessert: ice cream salad: caesar ``` Globals are useful for passing information like this, though it does take some planning to make sure the right templates are configured to use globals. ## Sharing Templates with Subcharts Parent charts and subcharts can share templates. Any defined block in any chart is available to other charts. For example, we can define a simple template like this: ```yaml {{- define "labels" }}from: mychart{{ end }} ``` Recall how the labels on templates are _globally shared_. Thus, the `labels` chart can be included from any other chart. While chart developers have a choice between `include` and `template`, one advantage of using `include` is that `include` can dynamically reference templates: ```yaml {{ include $mytemplate }} ``` The above will dereference `$mytemplate`. The `template` function, in contrast, will only accept a string literal. ## Avoid Using Blocks The Go template language provides a `block` keyword that allows developers to provide a default implementation which is overridden later. In Helm charts, blocks are not the best tool for overriding because if multiple implementations of the same block are provided, the one selected is unpredictable. The suggestion is to instead use `include`. ================================================ FILE: versioned_docs/version-3/chart_template_guide/values_files.md ================================================ --- title: Values Files description: Instructions on how to use the --values flag. sidebar_position: 4 --- In the previous section we looked at the built-in objects that Helm templates offer. One of the built-in objects is `Values`. This object provides access to values passed into the chart. Its contents come from multiple sources: - The `values.yaml` file in the chart - If this is a subchart, the `values.yaml` file of a parent chart - A values file is passed into `helm install` or `helm upgrade` with the `-f` flag (`helm install -f myvals.yaml ./mychart`) - Individual parameters are passed with `--set` (such as `helm install --set foo=bar ./mychart`) The list above is in order of specificity: `values.yaml` is the default, which can be overridden by a parent chart's `values.yaml`, which can in turn be overridden by a user-supplied values file, which can in turn be overridden by `--set` parameters. Values files are plain YAML files. Let's edit `mychart/values.yaml` and then edit our ConfigMap template. Removing the defaults in `values.yaml`, we'll set just one parameter: ```yaml favoriteDrink: coffee ``` Now we can use this inside of a template: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favoriteDrink }} ``` Notice on the last line we access `favoriteDrink` as an attribute of `Values`: `{{ .Values.favoriteDrink }}`. Let's see how this renders. ```console $ helm install geared-marsupi ./mychart --dry-run --debug install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: geared-marsupi LAST DEPLOYED: Wed Feb 19 23:21:13 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: favoriteDrink: coffee HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: geared-marsupi-configmap data: myvalue: "Hello World" drink: coffee ``` Because `favoriteDrink` is set in the default `values.yaml` file to `coffee`, that's the value displayed in the template. We can easily override that by adding a `--set` flag in our call to `helm install`: ```console $ helm install solid-vulture ./mychart --dry-run --debug --set favoriteDrink=slurm install.go:158: [debug] Original chart version: "" install.go:175: [debug] CHART PATH: /home/bagratte/src/playground/mychart NAME: solid-vulture LAST DEPLOYED: Wed Feb 19 23:25:54 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: favoriteDrink: slurm COMPUTED VALUES: favoriteDrink: slurm HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: solid-vulture-configmap data: myvalue: "Hello World" drink: slurm ``` Since `--set` has a higher precedence than the default `values.yaml` file, our template generates `drink: slurm`. Values files can contain more structured content, too. For example, we could create a `favorite` section in our `values.yaml` file, and then add several keys there: ```yaml favorite: drink: coffee food: pizza ``` Now we would have to modify the template slightly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" drink: {{ .Values.favorite.drink }} food: {{ .Values.favorite.food }} ``` While structuring data this way is possible, the recommendation is that you keep your values trees shallow, favoring flatness. When we look at assigning values to subcharts, we'll see how values are named using a tree structure. ## Deleting a default key If you need to delete a key from the default values, you may override the value of the key to be `null`, in which case Helm will remove the key from the overridden values merge. For example, the stable Drupal chart allows configuring the liveness probe, in case you configure a custom image. Here are the default values: ```yaml livenessProbe: httpGet: path: /user/login port: http initialDelaySeconds: 120 ``` If you try to override the livenessProbe handler to `exec` instead of `httpGet` using `--set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt]`, Helm will coalesce the default and overridden keys together, resulting in the following YAML: ```yaml livenessProbe: httpGet: path: /user/login port: http exec: command: - cat - docroot/CHANGELOG.txt initialDelaySeconds: 120 ``` However, Kubernetes would then fail because you can not declare more than one livenessProbe handler. To overcome this, you may instruct Helm to delete the `livenessProbe.httpGet` by setting it to null: ```sh helm install stable/drupal --set image=my-registry/drupal:0.1.0 --set livenessProbe.exec.command=[cat,docroot/CHANGELOG.txt] --set livenessProbe.httpGet=null ``` At this point, we've seen several built-in objects, and used them to inject information into a template. Now we will take a look at another aspect of the template engine: functions and pipelines. ================================================ FILE: versioned_docs/version-3/chart_template_guide/variables.md ================================================ --- title: Variables description: Using variables in templates. sidebar_position: 8 --- With functions, pipelines, objects, and control structures under our belts, we can turn to one of the more basic ideas in many programming languages: variables. In templates, they are less frequently used. But we will see how to use them to simplify code, and to make better use of `with` and `range`. In an earlier example, we saw that this code will fail: ```yaml {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ .Release.Name }} {{- end }} ``` `Release.Name` is not inside of the scope that's restricted in the `with` block. One way to work around scoping issues is to assign objects to variables that can be accessed without respect to the present scope. In Helm templates, a variable is a named reference to another object. It follows the form `$name`. Variables are assigned with a special assignment operator: `:=`. We can rewrite the above to use a variable for `Release.Name`. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- $relname := .Release.Name -}} {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} release: {{ $relname }} {{- end }} ``` Notice that before we start the `with` block, we assign `$relname := .Release.Name`. Now inside of the `with` block, the `$relname` variable still points to the release name. Running that will produce this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: viable-badger-configmap data: myvalue: "Hello World" drink: "coffee" food: "PIZZA" release: viable-badger ``` Variables are particularly useful in `range` loops. They can be used on list-like objects to capture both the index and the value: ```yaml toppings: |- {{- range $index, $topping := .Values.pizzaToppings }} {{ $index }}: {{ $topping }} {{- end }} ``` Note that `range` comes first, then the variables, then the assignment operator, then the list. This will assign the integer index (starting from zero) to `$index` and the value to `$topping`. Running it will produce: ```yaml toppings: |- 0: mushrooms 1: cheese 2: peppers 3: onions ``` For data structures that have both a key and a value, we can use `range` to get both. For example, we can loop through `.Values.favorite` like this: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- range $key, $val := .Values.favorite }} {{ $key }}: {{ $val | quote }} {{- end }} ``` Now on the first iteration, `$key` will be `drink` and `$val` will be `coffee`, and on the second, `$key` will be `food` and `$val` will be `pizza`. Running the above will generate this: ```yaml # Source: mychart/templates/configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: eager-rabbit-configmap data: myvalue: "Hello World" drink: "coffee" food: "pizza" ``` Variables are normally not "global". They are scoped to the block in which they are declared. Earlier, we assigned `$relname` in the top level of the template. That variable will be in scope for the entire template. But in our last example, `$key` and `$val` will only be in scope inside of the `{{ range... }}{{ end }}` block. However, there is one variable that will always point to the root context: - `$` -. This can be very useful when you are looping in a range and you need to know the chart's release name. An example illustrating this: ```yaml {{- range .Values.tlsSecrets }} --- apiVersion: v1 kind: Secret metadata: name: {{ .name }} labels: # Many helm templates would use `.` below, but that will not work, # however `$` will work here app.kubernetes.io/name: {{ template "fullname" $ }} # I cannot reference .Chart.Name, but I can do $.Chart.Name helm.sh/chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}" app.kubernetes.io/instance: "{{ $.Release.Name }}" # Value from appVersion in Chart.yaml app.kubernetes.io/version: "{{ $.Chart.AppVersion }}" app.kubernetes.io/managed-by: "{{ $.Release.Service }}" type: kubernetes.io/tls data: tls.crt: {{ .certificate }} tls.key: {{ .key }} {{- end }} ``` So far we have looked at just one template declared in just one file. But one of the powerful features of the Helm template language is its ability to declare multiple templates and use them together. We'll turn to that in the next section. ================================================ FILE: versioned_docs/version-3/chart_template_guide/wrapping_up.md ================================================ --- title: Next Steps description: Wrapping up - some useful pointers to other documentation that will help you. sidebar_position: 14 --- This guide is intended to give you, the chart developer, a strong understanding of how to use Helm's template language. The guide focuses on the technical aspects of template development. But there are many things this guide has not covered when it comes to the practical day-to-day development of charts. Here are some useful pointers to other documentation that will help you as you create new charts: - The CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) is an indispensable source of charts. - The Kubernetes [Documentation](https://kubernetes.io/docs/home/) provides detailed examples of the various resource kinds that you can use, from ConfigMaps and Secrets to DaemonSets and Deployments. - The Helm [Charts Guide](/topics/charts.md) explains the workflow of using charts. - The Helm [Chart Hooks Guide](/topics/charts_hooks.md) explains how to create lifecycle hooks. - The Helm [Charts Tips and Tricks](/howto/charts_tips_and_tricks.md) article provides some useful tips for writing charts. - The [Sprig documentation](https://github.com/Masterminds/sprig) documents more than sixty of the template functions. - The [Go template docs](https://godoc.org/text/template) explain the template syntax in detail. - The [Schelm tool](https://github.com/databus23/schelm) is a nice helper utility for debugging charts. Sometimes it's easier to ask a few questions and get answers from experienced developers. The best place to do this is in the [Kubernetes Slack](https://kubernetes.slack.com) Helm channels: - [#helm-users](https://kubernetes.slack.com/messages/helm-users) - [#helm-dev](https://kubernetes.slack.com/messages/helm-dev) - [#charts](https://kubernetes.slack.com/messages/charts) Finally, if you find errors or omissions in this document, want to suggest some new content, or would like to contribute, visit [The Helm Project](https://github.com/helm/helm-www). ================================================ FILE: versioned_docs/version-3/chart_template_guide/yaml_techniques.md ================================================ --- title: "Appendix: YAML Techniques" description: A closer look at the YAML specification and how it applies to Helm. sidebar_position: 15 --- Most of this guide has been focused on writing the template language. Here, we'll look at the YAML format. YAML has some useful features that we, as template authors, can use to make our templates less error prone and easier to read. ## Scalars and Collections According to the [YAML spec](https://yaml.org/spec/1.2/spec.html), there are two types of collections, and many scalar types. The two types of collections are maps and sequences: ```yaml map: one: 1 two: 2 three: 3 sequence: - one - two - three ``` Scalar values are individual values (as opposed to collections) ### Scalar Types in YAML In Helm's dialect of YAML, the scalar data type of a value is determined by a complex set of rules, including the Kubernetes schema for resource definitions. But when inferring types, the following rules tend to hold true. If an integer or float is an unquoted bare word, it is typically treated as a numeric type: ```yaml count: 1 size: 2.34 ``` But if they are quoted, they are treated as strings: ```yaml count: "1" # <-- string, not int size: '2.34' # <-- string, not float ``` The same is true of booleans: ```yaml isGood: true # bool answer: "true" # string ``` The word for an empty value is `null` (not `nil`). Note that `port: "80"` is valid YAML, and will pass through both the template engine and the YAML parser, but will fail if Kubernetes expects `port` to be an integer. In some cases, you can force a particular type inference using YAML node tags: ```yaml coffee: "yes, please" age: !!str 21 port: !!int "80" ``` In the above, `!!str` tells the parser that `age` is a string, even if it looks like an int. And `port` is treated as an int, even though it is quoted. ## Strings in YAML Much of the data that we place in YAML documents are strings. YAML has more than one way to represent a string. This section explains the ways and demonstrates how to use some of them. There are three "inline" ways of declaring a string: ```yaml way1: bare words way2: "double-quoted strings" way3: 'single-quoted strings' ``` All inline styles must be on one line. - Bare words are unquoted, and are not escaped. For this reason, you have to be careful what characters you use. - Double-quoted strings can have specific characters escaped with `\`. For example `"\"Hello\", she said"`. You can escape line breaks with `\n`. - Single-quoted strings are "literal" strings, and do not use the `\` to escape characters. The only escape sequence is `''`, which is decoded as a single `'`. In addition to the one-line strings, you can declare multi-line strings: ```yaml coffee: | Latte Cappuccino Espresso ``` The above will treat the value of `coffee` as a single string equivalent to `Latte\nCappuccino\nEspresso\n`. Note that the first line after the `|` must be correctly indented. So we could break the example above by doing this: ```yaml coffee: | Latte Cappuccino Espresso ``` Because `Latte` is incorrectly indented, we'd get an error like this: ``` Error parsing file: error converting YAML to JSON: yaml: line 7: did not find expected key ``` In templates, it is sometimes safer to put a fake "first line" of content in a multi-line document just for protection from the above error: ```yaml coffee: | # Commented first line Latte Cappuccino Espresso ``` Note that whatever that first line is, it will be preserved in the output of the string. So if you are, for example, using this technique to inject a file's contents into a ConfigMap, the comment should be of the type expected by whatever is reading that entry. ### Controlling Spaces in Multi-line Strings In the example above, we used `|` to indicate a multi-line string. But notice that the content of our string was followed with a trailing `\n`. If we want the YAML processor to strip off the trailing newline, we can add a `-` after the `|`: ```yaml coffee: |- Latte Cappuccino Espresso ``` Now the `coffee` value will be: `Latte\nCappuccino\nEspresso` (with no trailing `\n`). Other times, we might want all trailing whitespace to be preserved. We can do this with the `|+` notation: ```yaml coffee: |+ Latte Cappuccino Espresso another: value ``` Now the value of `coffee` will be `Latte\nCappuccino\nEspresso\n\n\n`. Indentation inside of a text block is preserved, and results in the preservation of line breaks, too: ```yaml coffee: |- Latte 12 oz 16 oz Cappuccino Espresso ``` In the above case, `coffee` will be `Latte\n 12 oz\n 16 oz\nCappuccino\nEspresso`. ### Indenting and Templates When writing templates, you may find yourself wanting to inject the contents of a file into the template. As we saw in previous chapters, there are two ways of doing this: - Use `{{ .Files.Get "FILENAME" }}` to get the contents of a file in the chart. - Use `{{ include "TEMPLATE" . }}` to render a template and then place its contents into the chart. When inserting files into YAML, it's good to understand the multi-line rules above. Often times, the easiest way to insert a static file is to do something like this: ```yaml myfile: | {{ .Files.Get "myfile.txt" | indent 2 }} ``` Note how we do the indentation above: `indent 2` tells the template engine to indent every line in "myfile.txt" with two spaces. Note that we do not indent that template line. That's because if we did, the file content of the first line would be indented twice. ### Folded Multi-line Strings Sometimes you want to represent a string in your YAML with multiple lines, but want it to be treated as one long line when it is interpreted. This is called "folding". To declare a folded block, use `>` instead of `|`: ```yaml coffee: > Latte Cappuccino Espresso ``` The value of `coffee` above will be `Latte Cappuccino Espresso\n`. Note that all but the last line feed will be converted to spaces. You can combine the whitespace controls with the folded text marker, so `>-` will replace or trim all newlines. Note that in the folded syntax, indenting text will cause lines to be preserved. ```yaml coffee: >- Latte 12 oz 16 oz Cappuccino Espresso ``` The above will produce `Latte\n 12 oz\n 16 oz\nCappuccino Espresso`. Note that both the spacing and the newlines are still there. ## Embedding Multiple Documents in One File It is possible to place more than one YAML document into a single file. This is done by prefixing a new document with `---` and ending the document with `...` ```yaml --- document: 1 ... --- document: 2 ... ``` In many cases, either the `---` or the `...` may be omitted. Some files in Helm cannot contain more than one doc. If, for example, more than one document is provided inside of a `values.yaml` file, only the first will be used. Template files, however, may have more than one document. When this happens, the file (and all of its documents) is treated as one object during template rendering. But then the resulting YAML is split into multiple documents before it is fed to Kubernetes. We recommend only using multiple documents per file when it is absolutely necessary. Having multiple documents in a file can be difficult to debug. ## YAML is a Superset of JSON Because YAML is a superset of JSON, any valid JSON document _should_ be valid YAML. ```json { "coffee": "yes, please", "coffees": [ "Latte", "Cappuccino", "Espresso" ] } ``` The above is another way of representing this: ```yaml coffee: yes, please coffees: - Latte - Cappuccino - Espresso ``` And the two can be mixed (with care): ```yaml coffee: "yes, please" coffees: [ "Latte", "Cappuccino", "Espresso"] ``` All three of these should parse into the same internal representation. While this means that files such as `values.yaml` may contain JSON data, Helm does not treat the file extension `.json` as a valid suffix. ## YAML Anchors The YAML spec provides a way to store a reference to a value, and later refer to that value by reference. YAML refers to this as "anchoring": ```yaml coffee: "yes, please" favorite: &favoriteCoffee "Cappuccino" coffees: - Latte - *favoriteCoffee - Espresso ``` In the above, `&favoriteCoffee` sets a reference to `Cappuccino`. Later, that reference is used as `*favoriteCoffee`. So `coffees` becomes `Latte, Cappuccino, Espresso`. While there are a few cases where anchors are useful, there is one aspect of them that can cause subtle bugs: The first time the YAML is consumed, the reference is expanded and then discarded. So if we were to decode and then re-encode the example above, the resulting YAML would be: ```yaml coffee: yes, please favorite: Cappuccino coffees: - Latte - Cappuccino - Espresso ``` Because Helm and Kubernetes often read, modify, and then rewrite YAML files, the anchors will be lost. ================================================ FILE: versioned_docs/version-3/faq/changes_since_helm2.md ================================================ --- title: Changes Since Helm 2 sidebar_position: 1 --- ## Changes since Helm 2 Here's an exhaustive list of all the major changes introduced in Helm 3. ### Removal of Tiller During the Helm 2 development cycle, we introduced Tiller. Tiller played an important role for teams working on a shared cluster - it made it possible for multiple different operators to interact with the same set of releases. With role-based access controls (RBAC) enabled by default in Kubernetes 1.6, locking down Tiller for use in a production scenario became more difficult to manage. Due to the vast number of possible security policies, our stance was to provide a permissive default configuration. This allowed first-time users to start experimenting with Helm and Kubernetes without having to dive headfirst into the security controls. Unfortunately, this permissive configuration could grant a user a broad range of permissions they weren’t intended to have. DevOps and SREs had to learn additional operational steps when installing Tiller into a multi-tenant cluster. After hearing how community members were using Helm in certain scenarios, we found that Tiller’s release management system did not need to rely upon an in-cluster operator to maintain state or act as a central hub for Helm release information. Instead, we could simply fetch information from the Kubernetes API server, render the Charts client-side, and store a record of the installation in Kubernetes. Tiller’s primary goal could be accomplished without Tiller, so one of the first decisions we made regarding Helm 3 was to completely remove Tiller. With Tiller gone, the security model for Helm is radically simplified. Helm 3 now supports all the modern security, identity, and authorization features of modern Kubernetes. Helm’s permissions are evaluated using your [kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Cluster administrators can restrict user permissions at whatever granularity they see fit. Releases are still recorded in-cluster, and the rest of Helm’s functionality remains. ### Improved Upgrade Strategy: 3-way Strategic Merge Patches Helm 2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart's manifest against the proposed chart's manifest (the one supplied during `helm upgrade`). It compared the differences between these two charts to determine what changes needed to be applied to the resources in Kubernetes. If changes were applied to the cluster out-of-band (such as during a `kubectl edit`), those changes were not considered. This resulted in resources being unable to roll back to its previous state: because Helm only considered the last applied chart's manifest as its current state, if there were no changes in the chart's state, the live state was left unchanged. In Helm 3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, and the new manifest when generating a patch. #### Examples Let's go through a few common examples what this change impacts. ##### Rolling back where live state has changed Your team just deployed their application to production on Kubernetes using Helm. The chart contains a Deployment object where the number of replicas is set to three: ```console $ helm install myapp ./myapp ``` A new developer joins the team. On their first day while observing the production cluster, a horrible coffee-spilling-on-the-keyboard accident happens and they `kubectl scale` the production deployment from three replicas down to zero. ```console $ kubectl scale --replicas=0 deployment/myapp ``` Another developer on your team notices that the production site is down and decides to rollback the release to its previous state: ```console $ helm rollback myapp ``` What happens? In Helm 2, it would generate a patch, comparing the old manifest against the new manifest. Because this is a rollback, it's the same manifest. Helm would determine that there is nothing to change because there is no difference between the old manifest and the new manifest. The replica count continues to stay at zero. Panic ensues. In Helm 3, the patch is generated using the old manifest, the live state, and the new manifest. Helm recognizes that the old state was at three, the live state is at zero and the new manifest wishes to change it back to three, so it generates a patch to change the state back to three. ##### Upgrades where live state has changed Many service meshes and other controller-based applications inject data into Kubernetes objects. This can be something like a sidecar, labels, or other information. Previously if you had the given manifest rendered from a Chart: ```yaml containers: - name: server image: nginx:2.0.0 ``` And the live state was modified by another application to ```yaml containers: - name: server image: nginx:2.0.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` Now, you want to upgrade the `nginx` image tag to `2.1.0`. So, you upgrade to a chart with the given manifest: ```yaml containers: - name: server image: nginx:2.1.0 ``` What happens? In Helm 2, Helm generates a patch of the `containers` object between the old manifest and the new manifest. The cluster's live state is not considered during the patch generation. The cluster's live state is modified to look like the following: ```yaml containers: - name: server image: nginx:2.1.0 ``` The sidecar pod is removed from live state. More panic ensues. In Helm 3, Helm generates a patch of the `containers` object between the old manifest, the live state, and the new manifest. It notices that the new manifest changes the image tag to `2.1.0`, but live state contains a sidecar container. The cluster's live state is modified to look like the following: ```yaml containers: - name: server image: nginx:2.1.0 - name: my-injected-sidecar image: my-cool-mesh:1.0.0 ``` ### Release Names are now scoped to the Namespace With the removal of Tiller, the information about each release had to go somewhere. In Helm 2, this was stored in the same namespace as Tiller. In practice, this meant that once a name was used by a release, no other release could use that same name, even if it was deployed in a different namespace. In Helm 3, information about a particular release is now stored in the same namespace as the release itself. This means that users can now `helm install wordpress stable/wordpress` in two separate namespaces, and each can be referred with `helm list` by changing the current namespace context (e.g. `helm list --namespace foo`). With this greater alignment to native cluster namespaces, the `helm list` command no longer lists all releases by default. Instead, it will list only the releases in the namespace of your current kubernetes context (i.e. the namespace shown when you run `kubectl config view --minify`). It also means you must supply the `--all-namespaces` flag to `helm list` to get behaviour similar to Helm 2. ### Secrets as the default storage driver In Helm 3, Secrets are now used as the [default storage driver](/topics/advanced.md#storage-backends). Helm 2 used ConfigMaps by default to store release information. In Helm 2.7.0, a new storage backend that uses Secrets for storing release information was implemented, and it is now the default starting in Helm 3. Changing to Secrets as the Helm 3 default allows for additional security in protecting charts in conjunction with the release of Secret encryption in Kubernetes. [Encrypting secrets at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) became available as an alpha feature in Kubernetes 1.7 and became stable as of Kubernetes 1.13. This allows users to encrypt Helm release metadata at rest, and so it is a good starting point that can be expanded later into using something like Vault. ### Go import path changes In Helm 3, Helm switched the Go import path over from `k8s.io/helm` to `helm.sh/helm/v3`. If you intend to upgrade to the Helm 3 Go client libraries, make sure to change your import paths. ### Capabilities The `.Capabilities` built-in object available during the rendering stage has been simplified. [Built-in Objects](/chart_template_guide/builtin_objects.md) ### Validating Chart Values with JSONSchema A JSON Schema can now be imposed upon chart values. This ensures that values provided by the user follow the schema laid out by the chart maintainer, providing better error reporting when the user provides an incorrect set of values for a chart. Validation occurs when any of the following commands are invoked: * `helm install` * `helm upgrade` * `helm template` * `helm lint` See the documentation on [Schema files](/topics/charts.md#schema-files) for more information. ### Consolidation of `requirements.yaml` into `Chart.yaml` The Chart dependency management system moved from requirements.yaml and requirements.lock to Chart.yaml and Chart.lock. We recommend that new charts meant for Helm 3 use the new format. However, Helm 3 still understands Chart API version 1 (`v1`) and will load existing `requirements.yaml` files In Helm 2, this is how a `requirements.yaml` looked: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` In Helm 3, the dependency is expressed the same way, but now from your `Chart.yaml`: ```yaml dependencies: - name: mariadb version: 5.x.x repository: https://charts.helm.sh/stable condition: mariadb.enabled tags: - database ``` Charts are still downloaded and placed in the `charts/` directory, so subcharts vendored into the `charts/` directory will continue to work without modification. ### Name (or --generate-name) is now required on install In Helm 2, if no name was provided, an auto-generated name would be given. In production, this proved to be more of a nuisance than a helpful feature. In Helm 3, Helm will throw an error if no name is provided with `helm install`. For those who still wish to have a name auto-generated for you, you can use the `--generate-name` flag to create one for you. ### Pushing Charts to OCI Registries This is an experimental feature introduced in Helm 3. To use, set the environment variable `HELM_EXPERIMENTAL_OCI=1`. At a high level, a Chart Repository is a location where Charts can be stored and shared. The Helm client packs and ships Helm Charts to a Chart Repository. Simply put, a Chart Repository is a basic HTTP server that houses an index.yaml file and some packaged charts. While there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show: - Chart Repositories have a very hard time abstracting most of the security implementations required in a production environment. Having a standard API for authentication and authorization is very important in production scenarios. - Helm’s Chart provenance tools used for signing and verifying the integrity and origin of a chart are an optional piece of the Chart publishing process. - In multi-tenant scenarios, the same Chart can be uploaded by another tenant, costing twice the storage cost to store the same content. Smarter chart repositories have been designed to handle this, but it’s not a part of the formal specification. - Using a single index file for search, metadata information, and fetching Charts has made it difficult or clunky to design around in secure multi-tenant implementations. Docker’s Distribution project (also known as Docker Registry v2) is the successor to the Docker Registry project. Many major cloud vendors have a product offering of the Distribution project, and with so many vendors offering the same product, the Distribution project has benefited from many years of hardening, security best practices, and battle-testing. Please have a look at `helm help chart` and `helm help registry` for more information on how to package a chart and push it to a Docker registry. For more info, please see [this page](/topics/registries.md). ### Removal of `helm serve` `helm serve` ran a local Chart Repository on your machine for development purposes. However, it didn't receive much uptake as a development tool and had numerous issues with its design. In the end, we decided to remove it and split it out as a plugin. For a similar experience to `helm serve`, have a look at the local filesystem storage option in [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) and the [servecm plugin](https://github.com/jdolitsky/helm-servecm). ### Library chart support Helm 3 supports a class of chart called a “library chart”. This is a chart that is shared by other charts, but does not create any release artifacts of its own. A library chart’s templates can only declare `define` elements. Globally scoped non-`define` content is simply ignored. This allows users to re-use and share snippets of code that can be re-used across many charts, avoiding redundancy and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Library charts are declared in the dependencies directive in Chart.yaml, and are installed and managed like any other chart. ```yaml dependencies: - name: mylib version: 1.x.x repository: quay.io ``` We’re very excited to see the use cases this feature opens up for chart developers, as well as any best practices that arise from consuming library charts. ### Chart.yaml apiVersion bump With the introduction of library chart support and the consolidation of requirements.yaml into Chart.yaml, clients that understood Helm 2's package format won't understand these new features. So, we bumped the apiVersion in Chart.yaml from `v1` to `v2`. `helm create` now creates charts using this new format, so the default apiVersion was bumped there as well. Clients wishing to support both versions of Helm charts should inspect the `apiVersion` field in Chart.yaml to understand how to parse the package format. ### XDG Base Directory Support [The XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) is a portable standard defining where configuration, data, and cached files should be stored on the filesystem. In Helm 2, Helm stored all this information in `~/.helm` (affectionately known as `helm home`), which could be changed by setting the `$HELM_HOME` environment variable, or by using the global flag `--home`. In Helm 3, Helm now respects the following environment variables as per the XDG Base Directory Specification: - `$XDG_CACHE_HOME` - `$XDG_CONFIG_HOME` - `$XDG_DATA_HOME` Helm plugins are still passed `$HELM_HOME` as an alias to `$XDG_DATA_HOME` for backwards compatibility with plugins looking to use `$HELM_HOME` as a scratchpad environment. Several new environment variables are also passed in to the plugin's environment to accommodate this change: - `$HELM_PATH_CACHE` for the cache path - `$HELM_PATH_CONFIG` for the config path - `$HELM_PATH_DATA` for the data path Helm plugins looking to support Helm 3 should consider using these new environment variables instead. ### CLI Command Renames In order to better align the verbiage from other package managers, `helm delete` was re-named to `helm uninstall`. `helm delete` is still retained as an alias to `helm uninstall`, so either form can be used. In Helm 2, in order to purge the release ledger, the `--purge` flag had to be provided. This functionality is now enabled by default. To retain the previous behavior, use `helm uninstall --keep-history`. Additionally, several other commands were re-named to accommodate the same conventions: - `helm inspect` -> `helm show` - `helm fetch` -> `helm pull` These commands have also retained their older verbs as aliases, so you can continue to use them in either form. ### Automatically creating namespaces When creating a release in a namespace that does not exist, Helm 2 created the namespace. Helm 3 follows the behavior of other Kubernetes tooling and returns an error if the namespace does not exist. Helm 3 will create the namespace if you explicitly specify `--create-namespace` flag. ### What happened to .Chart.ApiVersion? Helm follows the typical convention for CamelCasing which is to capitalize an acronym. We have done this elsewhere in the code, such as with `.Capabilities.APIVersions.Has`. In Helm v3, we corrected `.Chart.ApiVersion` to follow this pattern, renaming it to `.Chart.APIVersion`. ================================================ FILE: versioned_docs/version-3/faq/index.mdx ================================================ --- title: Frequently Asked Questions sidebar_position: 9 --- # Frequently Asked Questions > This section provides help with the most common questions. **We'd love your help** making this document better. To add, correct, or remove information, [file an issue](https://github.com/helm/helm-www/issues) or send us a pull request. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/faq/installing.md ================================================ --- title: Installing sidebar_position: 2 --- ## Installing ### Why aren't there native packages of Helm for Fedora and other Linux distros? The Helm project does not maintain packages for operating systems and environments. The Helm community may provide native packages and if the Helm project is made aware of them they will be listed. This is how the Homebrew formula was started and listed. If you're interested in maintaining a package, we'd love it. ### Why do you provide a `curl ...|bash` script? There is a script in our repository (`scripts/get-helm-3`) that can be executed as a `curl ..|bash` script. The transfers are all protected by HTTPS, and the script does some auditing of the packages it fetches. However, the script has all the usual dangers of any shell script. We provide it because it is useful, but we suggest that users carefully read the script first. What we'd really like, though, are better packaged releases of Helm. ### How do I put the Helm client files somewhere other than their defaults? Helm uses the XDG structure for storing files. There are environment variables you can use to override these locations: - `$XDG_CACHE_HOME`: set an alternative location for storing cached files. - `$XDG_CONFIG_HOME`: set an alternative location for storing Helm configuration. - `$XDG_DATA_HOME`: set an alternative location for storing Helm data. Note that if you have existing repositories, you will need to re-add them with `helm repo add...`. ================================================ FILE: versioned_docs/version-3/faq/troubleshooting.md ================================================ --- title: Troubleshooting sidebar_position: 4 --- ## Troubleshooting ### I am getting a warning about "Unable to get an update from the "stable" chart repository" Run `helm repo list`. If it shows your `stable` repository pointing to a `storage.googleapis.com` URL, you will need to update that repository. On November 13, 2020, the Helm Charts repo [became unsupported](https://github.com/helm/charts#deprecation-timeline) after a year-long deprecation. An archive has been made available at `https://charts.helm.sh/stable` but will no longer receive updates. You can run the following command to fix your repository: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` The same goes for the `incubator` repository, which has an archive available at https://charts.helm.sh/incubator. You can run the following command to repair it: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### I am getting the warning 'WARNING: "kubernetes-charts.storage.googleapis.com" is deprecated for "stable" and will be deleted Nov. 13, 2020.' The old Google helm chart repository has been replaced by a new Helm chart repository. Run the following command to permanently fix this: ```console $ helm repo add stable https://charts.helm.sh/stable --force-update ``` If you get a similar error for `incubator`, run this command: ```console $ helm repo add incubator https://charts.helm.sh/incubator --force-update ``` ### When I add a Helm repo, I get the error 'Error: Repo "https://kubernetes-charts.storage.googleapis.com" is no longer available' The Helm Chart repositories are no longer supported after [a year-long deprecation period](https://github.com/helm/charts#deprecation-timeline). Archives for these repositories are available at `https://charts.helm.sh/stable` and `https://charts.helm.sh/incubator`, however they will no longer receive updates. The command `helm repo add` will not let you add the old URLs unless you specify `--use-deprecated-repos`. ### On GKE (Google Container Engine) I get "No SSH tunnels currently open" ``` Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"? ``` Another variation of the error message is: ``` Unable to connect to the server: x509: certificate signed by unknown authority ``` The issue is that your local Kubernetes config file must have the correct credentials. When you create a cluster on GKE, it will give you credentials, including SSL certificates and certificate authorities. These need to be stored in a Kubernetes config file (Default: `~/.kube/config`) so that `kubectl` and `helm` can access them. ### After migration from Helm 2, `helm list` shows only some (or none) of my releases It is likely that you have missed the fact that Helm 3 now uses cluster namespaces throughout to scope releases. This means that for all commands referencing a release you must either: * rely on the current namespace in the active kubernetes context (as described by the `kubectl config view --minify` command), * specify the correct namespace using the `--namespace`/`-n` flag, or * for the `helm list` command, specify the `--all-namespaces`/`-A` flag This applies to `helm ls`, `helm uninstall`, and all other `helm` commands referencing a release. ### On macOS, the file `/etc/.mdns_debug` is accessed. Why? We are aware of a case on macOS where Helm will try to access a file named `/etc/.mdns_debug`. If the file exists, Helm holds the file handle open while it executes. This is caused by macOS's MDNS library. It attempts to load that file to read debugging settings (if enabled). The file handle probably should not be held open, and this issue has been reported to Apple. However, it is macOS, not Helm, that causes this behavior. If you do not want Helm to load this file, you may be able to compile Helm to as a static library that does not use the host network stack. Doing so will inflate the binary size of Helm, but will prevent the file from being open. This issue was originally flagged as a potential security problem. But it has since been determined that there is no flaw or vulnerability caused by this behavior. ### helm repo add fails when it used to work In helm 3.3.1 and before, the command `helm repo add ` will give no output if you attempt to add a repo which already exists. The flag `--no-update` would raise an error if the repo was already registered. In helm 3.3.2 and beyond, an attempt to add an existing repo will error: `Error: repository name (reponame) already exists, please specify a different name` The default behavior is now reversed. `--no-update` is now ignored, while if you want to replace (overwrite) an existing repo, you can use `--force-update`. This is due to a breaking change for a security fix as explained in the [Helm 3.3.2 release notes](https://github.com/helm/helm/releases/tag/v3.3.2). ### Enabling Kubernetes client logging Printing log messages for debugging the Kubernetes client can be enabled using the [klog](https://pkg.go.dev/k8s.io/klog) flags. Using the `-v` flag to set verbosity level will be enough for most cases. For example: ``` helm list -v 6 ``` ### Tiller installations stopped working and access is denied Helm releases used to be available from . As explained in ["Announcing get.helm.sh"](https://helm.sh/blog/get-helm-sh/), the official location changed in June 2019. [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) makes all the old Tiller images available. If you are trying to download older versions of Helm from the storage bucket you used in the past, you may find that they are missing: ``` AccessDenied Access denied.
    Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.
     ``` The [legacy Tiller image location](https://gcr.io/kubernetes-helm/tiller) began the removal of images in August 2021. We have made these images available at the [GitHub Container Registry](https://github.com/orgs/helm/packages/container/package/tiller) location. For example, to download version v2.17.0, replace: `https://storage.googleapis.com/kubernetes-helm/helm-v2.17.0-linux-amd64.tar.gz` with: `https://get.helm.sh/helm-v2.17.0-linux-amd64.tar.gz` To initialize with Helm v2.17.0: `helm init —upgrade` Or if a different version is needed, use the --tiller-image flag to override the default location and install a specific Helm v2 version: `helm init --tiller-image ghcr.io/helm/tiller:v2.16.9` **Note:** The Helm maintainers recommend migration to a currently-supported version of Helm. Helm v2.17.0 was the final release of Helm v2; Helm v2 is unsupported since November 2020, as detailed in [Helm 2 and the Charts Project Are Now Unsupported](https://helm.sh/blog/helm-2-becomes-unsupported/). Many CVEs have been flagged against Helm since then, and those exploits are patched in Helm v3 but will never be patched in Helm v2. See the [current list of published Helm advisories](https://github.com/helm/helm/security/advisories?state=published) and make a plan to [migrate to Helm v3](/topics/v2_v3_migration.md) today. ================================================ FILE: versioned_docs/version-3/faq/uninstalling.md ================================================ --- title: Uninstalling sidebar_position: 3 --- ## Uninstalling ### I want to delete my local Helm. Where are all its files? Along with the `helm` binary, Helm stores some files in the following locations: - $XDG_CACHE_HOME - $XDG_CONFIG_HOME - $XDG_DATA_HOME The following table gives the default folder for each of these, by OS: | Operating System | Cache Path | Configuration Path | Data Path | |------------------|-----------------------------|----------------------------------|---------------------------| | Linux | `$HOME/.cache/helm ` | `$HOME/.config/helm ` | `$HOME/.local/share/helm` | | macOS | `$HOME/Library/Caches/helm` | `$HOME/Library/Preferences/helm` | `$HOME/Library/helm ` | | Windows | `%TEMP%\helm ` | `%APPDATA%\helm ` | `%APPDATA%\helm` | ================================================ FILE: versioned_docs/version-3/glossary/index.mdx ================================================ --- title: Glossary description: Terms used to describe components of Helm's architecture. sidebar_position: 10 --- # Glossary ## Chart A Helm package that contains information sufficient for installing a set of Kubernetes resources into a Kubernetes cluster. Charts contain a `Chart.yaml` file as well as templates, default values (`values.yaml`), and dependencies. Charts are developed in a well-defined directory structure, and then packaged into an archive format called a _chart archive_. ## Chart Archive A _chart archive_ is a tarred and gzipped (and optionally signed) chart. ## Chart Dependency (Subcharts) Charts may depend upon other charts. There are two ways a dependency may occur: - Soft dependency: A chart may simply not function without another chart being installed in a cluster. Helm does not provide tooling for this case. In this case, dependencies may be managed separately. - Hard dependency: A chart may contain (inside of its `charts/` directory) another chart upon which it depends. In this case, installing the chart will install all of its dependencies. In this case, a chart and its dependencies are managed as a collection. When a chart is packaged (via `helm package`) all of its hard dependencies are bundled with it. ## Chart Version Charts are versioned according to the [SemVer 2 spec](https://semver.org). A version number is required on every chart. ## Chart.yaml Information about a chart is stored in a special file called `Chart.yaml`. Every chart must have this file. ## Helm (and helm) Helm is the package manager for Kubernetes. As an operating system package manager makes it easy to install tools on an OS, Helm makes it easy to install applications and resources into Kubernetes clusters. While _Helm_ is the name of the project, the command line client is also named `helm`. By convention, when speaking of the project, _Helm_ is capitalized. When speaking of the client, _helm_ is in lowercase. ## Helm Configuration Files (XDG) Helm stores its configuration files in XDG directories. These directories are created the first time `helm` is run. ## Kube Config (KUBECONFIG) The Helm client learns about Kubernetes clusters by using files in the _Kube config_ file format. By default, Helm attempts to find this file in the place where `kubectl` creates it (`$HOME/.kube/config`). ## Lint (Linting) To _lint_ a chart is to validate that it follows the conventions and requirements of the Helm chart standard. Helm provides tools to do this, notably the `helm lint` command. ## Provenance (Provenance file) Helm charts may be accompanied by a _provenance file_ which provides information about where the chart came from and what it contains. Provenance files are one part of the Helm security story. A provenance contains a cryptographic hash of the chart archive file, the Chart.yaml data, and a signature block (an OpenPGP "clearsign" block). When coupled with a keychain, this provides chart users with the ability to: - Validate that a chart was signed by a trusted party - Validate that the chart file has not been tampered with - Validate the contents of a chart metadata (`Chart.yaml`) - Quickly match a chart to its provenance data Provenance files have the `.prov` extension, and can be served from a chart repository server or any other HTTP server. ## Release When a chart is installed, the Helm library creates a _release_ to track that installation. A single chart may be installed many times into the same cluster, and create many different releases. For example, one can install three PostgreSQL databases by running `helm install` three times with a different release name. ## Release Number (Release Version) A single release can be updated multiple times. A sequential counter is used to track releases as they change. After a first `helm install`, a release will have _release number_ 1. Each time a release is upgraded or rolled back, the release number will be incremented. ## Rollback A release can be upgraded to a newer chart or configuration. But since release history is stored, a release can also be _rolled back_ to a previous release number. This is done with the `helm rollback` command. Importantly, a rolled back release will receive a new release number. | Operation | Release Number | |------------|------------------------------------------------------| | install | release 1 | | upgrade | release 2 | | upgrade | release 3 | | rollback 1 | release 4 (but running the same config as release 1) | The above table illustrates how release numbers increment across install, upgrade, and rollback. ## Helm Library (or SDK) The Helm Library (or SDK) refers to the Go code that interacts directly with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources. It can be imported into a project to use Helm as a client library instead of a CLI. ## Repository (Repo, Chart Repository) Helm charts may be stored on dedicated HTTP servers called _chart repositories_ (_repositories_, or just _repos_). A chart repository server is a simple HTTP server that can serve an `index.yaml` file that describes a batch of charts, and provides information on where each chart can be downloaded from. (Many chart repositories serve the charts as well as the `index.yaml` file.) A Helm client can point to zero or more chart repositories. By default, Helm clients are not configured with any chart repositories. Chart repositories can be added at any time using the `helm repo add` command. ## Chart Registry (OCI-based Registry) A Helm Chart Registry is an [OCI-based](https://opencontainers.org/about/overview/) storage and distribution system that is used to host and share Helm chart packages. For more information, see the [Helm documentation on registries](https://helm.sh/docs/topics/registries/). ## Values (Values Files, values.yaml) Values provide a way to override template defaults with your own information. Helm Charts are "parameterized", which means the chart developer may expose configuration that can be overridden at installation time. For example, a chart may expose a `username` field that allows setting a user name for a service. These exposed variables are called _values_ in Helm parlance. Values can be set during `helm install` and `helm upgrade` operations, either by passing them in directly, or by using a `values.yaml` file. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/helm/_category_.json ================================================ { "link": { "type": "doc", "id": "helm-category" } } ================================================ FILE: versioned_docs/version-3/helm/helm.md ================================================ --- title: helm slug: helm --- The Helm package manager for Kubernetes. ### Synopsis The Kubernetes package manager Common actions for Helm: - helm search: search for charts - helm pull: download a chart to your local directory to view - helm install: upload the chart to Kubernetes - helm list: list releases of charts Environment variables: | Name | Description | |------------------------------------|------------------------------------------------------------------------------------------------------------| | $HELM_CACHE_HOME | set an alternative location for storing cached files. | | $HELM_CONFIG_HOME | set an alternative location for storing Helm configuration. | | $HELM_DATA_HOME | set an alternative location for storing Helm data. | | $HELM_DEBUG | indicate whether or not Helm is running in Debug mode | | $HELM_DRIVER | set the backend storage driver. Values are: configmap, secret, memory, sql. | | $HELM_DRIVER_SQL_CONNECTION_STRING | set the connection string the SQL storage driver should use. | | $HELM_MAX_HISTORY | set the maximum number of helm release history. | | $HELM_NAMESPACE | set the namespace used for the helm operations. | | $HELM_NO_PLUGINS | disable plugins. Set HELM_NO_PLUGINS=1 to disable plugins. | | $HELM_PLUGINS | set the path to the plugins directory | | $HELM_REGISTRY_CONFIG | set the path to the registry config file. | | $HELM_REPOSITORY_CACHE | set the path to the repository cache directory | | $HELM_REPOSITORY_CONFIG | set the path to the repositories file. | | $KUBECONFIG | set an alternative Kubernetes configuration file (default "~/.kube/config") | | $HELM_KUBEAPISERVER | set the Kubernetes API Server Endpoint for authentication | | $HELM_KUBECAFILE | set the Kubernetes certificate authority file. | | $HELM_KUBEASGROUPS | set the Groups to use for impersonation using a comma-separated list. | | $HELM_KUBEASUSER | set the Username to impersonate for the operation. | | $HELM_KUBECONTEXT | set the name of the kubeconfig context. | | $HELM_KUBETOKEN | set the Bearer KubeToken used for authentication. | | $HELM_KUBEINSECURE_SKIP_TLS_VERIFY | indicate if the Kubernetes API server's certificate validation should be skipped (insecure) | | $HELM_KUBETLS_SERVER_NAME | set the server name used to validate the Kubernetes API server certificate | | $HELM_BURST_LIMIT | set the default burst limit in the case the server contains many CRDs (default 100, -1 to disable) | | $HELM_QPS | set the Queries Per Second in cases where a high number of calls exceed the option for higher burst values | Helm stores cache, configuration, and data based on the following configuration order: - If a HELM_*_HOME environment variable is set, it will be used - Otherwise, on systems supporting the XDG base directory specification, the XDG variables will be used - When no other location is set a default location will be used based on the operating system By default, the default directories depend on the Operating System. The defaults are listed below: | Operating System | Cache Path | Configuration Path | Data Path | |------------------|---------------------------|--------------------------------|-------------------------| | Linux | $HOME/.cache/helm | $HOME/.config/helm | $HOME/.local/share/helm | | macOS | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm | | Windows | %TEMP%\helm | %APPDATA%\helm | %APPDATA%\helm | ### Options ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell * [helm create](/helm/helm_create.md) - create a new chart with the given name * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies * [helm env](/helm/helm_env.md) - helm client environment information * [helm get](/helm/helm_get.md) - download extended information of a named release * [helm history](/helm/helm_history.md) - fetch release history * [helm install](/helm/helm_install.md) - install a chart * [helm lint](/helm/helm_lint.md) - examine a chart for possible issues * [helm list](/helm/helm_list.md) - list releases * [helm package](/helm/helm_package.md) - package a chart directory into a chart archive * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins * [helm pull](/helm/helm_pull.md) - download a chart from a repository and (optionally) unpack it in local directory * [helm push](/helm/helm_push.md) - push a chart to remote * [helm registry](/helm/helm_registry.md) - login to or logout from a registry * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories * [helm rollback](/helm/helm_rollback.md) - roll back a release to a previous revision * [helm search](/helm/helm_search.md) - search for a keyword in charts * [helm show](/helm/helm_show.md) - show information of a chart * [helm status](/helm/helm_status.md) - display the status of the named release * [helm template](/helm/helm_template.md) - locally render templates * [helm test](/helm/helm_test.md) - run tests for a release * [helm uninstall](/helm/helm_uninstall.md) - uninstall a release * [helm upgrade](/helm/helm_upgrade.md) - upgrade a release * [helm verify](/helm/helm_verify.md) - verify that a chart at the given path has been signed and is valid * [helm version](/helm/helm_version.md) - print the client version information ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_completion.md ================================================ --- title: helm completion --- generate autocompletion scripts for the specified shell ### Synopsis Generate autocompletion scripts for Helm for the specified shell. ### Options ``` -h, --help help for completion ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm completion bash](/helm/helm_completion_bash.md) - generate autocompletion script for bash * [helm completion fish](/helm/helm_completion_fish.md) - generate autocompletion script for fish * [helm completion powershell](/helm/helm_completion_powershell.md) - generate autocompletion script for powershell * [helm completion zsh](/helm/helm_completion_zsh.md) - generate autocompletion script for zsh ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_completion_bash.md ================================================ --- title: helm completion bash --- generate autocompletion script for bash ### Synopsis Generate the autocompletion script for Helm for the bash shell. To load completions in your current shell session: source <(helm completion bash) To load completions for every new session, execute once: - Linux: helm completion bash > /etc/bash_completion.d/helm - MacOS: helm completion bash > /usr/local/etc/bash_completion.d/helm ``` helm completion bash [flags] ``` ### Options ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_completion_fish.md ================================================ --- title: helm completion fish --- generate autocompletion script for fish ### Synopsis Generate the autocompletion script for Helm for the fish shell. To load completions in your current shell session: helm completion fish | source To load completions for every new session, execute once: helm completion fish > ~/.config/fish/completions/helm.fish You will need to start a new shell for this setup to take effect. ``` helm completion fish [flags] ``` ### Options ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_completion_powershell.md ================================================ --- title: helm completion powershell --- generate autocompletion script for powershell ### Synopsis Generate the autocompletion script for powershell. To load completions in your current shell session: PS C:\> helm completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` helm completion powershell [flags] ``` ### Options ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_completion_zsh.md ================================================ --- title: helm completion zsh --- generate autocompletion script for zsh ### Synopsis Generate the autocompletion script for Helm for the zsh shell. To load completions in your current shell session: source <(helm completion zsh) To load completions for every new session, execute once: helm completion zsh > "${fpath[1]}/_helm" ``` helm completion zsh [flags] ``` ### Options ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm completion](/helm/helm_completion.md) - generate autocompletion scripts for the specified shell ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_create.md ================================================ --- title: helm create --- create a new chart with the given name ### Synopsis This command creates a chart directory along with the common files and directories used in a chart. For example, 'helm create foo' will create a directory structure that looks something like this: foo/ ├── .helmignore # Contains patterns to ignore when packaging Helm charts. ├── Chart.yaml # Information about your chart ├── values.yaml # The default values for your templates ├── charts/ # Charts that this chart depends on └── templates/ # The template files └── tests/ # The test files 'helm create' takes a path for an argument. If directories in the given path do not exist, Helm will attempt to create them as it goes. If the given destination exists and there are files in that directory, conflicting files will be overwritten, but other files will be left alone. ``` helm create NAME [flags] ``` ### Options ``` -h, --help help for create -p, --starter string the name or absolute path to Helm starter scaffold ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_dependency.md ================================================ --- title: helm dependency --- manage a chart's dependencies ### Synopsis Manage the dependencies of a chart. Helm charts store their dependencies in 'charts/'. For chart developers, it is often easier to manage dependencies in 'Chart.yaml' which declares all dependencies. The dependency commands operate on that file, making it easy to synchronize between the desired dependencies and the actual dependencies stored in the 'charts/' directory. For example, this Chart.yaml declares two dependencies: # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "https://example.com/charts" - name: memcached version: "3.2.1" repository: "https://another.example.com/charts" The 'name' should be the name of a chart, where that name must match the name in that chart's 'Chart.yaml' file. The 'version' field should contain a semantic version or version range. The 'repository' URL should point to a Chart Repository. Helm expects that by appending '/index.yaml' to the URL, it should be able to retrieve the chart repository's index. Note: 'repository' can be an alias. The alias must start with 'alias:' or '@'. Starting from 2.2.0, repository can be defined as the path to the directory of the dependency charts stored locally. The path should start with a prefix of "file://". For example, # Chart.yaml dependencies: - name: nginx version: "1.2.3" repository: "file://../dependency_chart/nginx" If the dependency chart is retrieved locally, it is not required to have the repository added to helm by "helm add repo". Version matching is also supported for this case. ### Options ``` -h, --help help for dependency ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm dependency build](/helm/helm_dependency_build.md) - rebuild the charts/ directory based on the Chart.lock file * [helm dependency list](/helm/helm_dependency_list.md) - list the dependencies for the given chart * [helm dependency update](/helm/helm_dependency_update.md) - update charts/ based on the contents of Chart.yaml ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_dependency_build.md ================================================ --- title: helm dependency build --- rebuild the charts/ directory based on the Chart.lock file ### Synopsis Build out the charts/ directory from the Chart.lock file. Build is used to reconstruct a chart's dependencies to the state specified in the lock file. This will not re-negotiate dependencies, as 'helm dependency update' does. If no lock file is found, 'helm dependency build' will mirror the behavior of 'helm dependency update'. ``` helm dependency build CHART [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for build --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_dependency_list.md ================================================ --- title: helm dependency list --- list the dependencies for the given chart ### Synopsis List all of the dependencies declared in a chart. This can take chart archives and chart directories as input. It will not alter the contents of a chart. This will produce an error if the chart cannot be loaded. ``` helm dependency list CHART [flags] ``` ### Options ``` -h, --help help for list --max-col-width uint maximum column width for output table (default 80) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_dependency_update.md ================================================ --- title: helm dependency update --- update charts/ based on the contents of Chart.yaml ### Synopsis Update the on-disk dependencies to mirror Chart.yaml. This command verifies that the required charts, as expressed in 'Chart.yaml', are present in 'charts/' and are at an acceptable version. It will pull down the latest charts that satisfy the dependencies, and clean up old dependencies. On successful update, this will generate a lock file that can be used to rebuild the dependencies to an exact version. Dependencies are not required to be represented in 'Chart.yaml'. For that reason, an update command will not remove charts unless they are (a) present in the Chart.yaml file, but (b) at the wrong version. ``` helm dependency update CHART [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -h, --help help for update --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --skip-refresh do not refresh the local repository cache --username string chart repository username where to locate the requested chart --verify verify the packages against signatures ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm dependency](/helm/helm_dependency.md) - manage a chart's dependencies ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_env.md ================================================ --- title: helm env --- helm client environment information ### Synopsis Env prints out all the environment information in use by Helm. ``` helm env [flags] ``` ### Options ``` -h, --help help for env ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get.md ================================================ --- title: helm get --- download extended information of a named release ### Synopsis This command consists of multiple subcommands which can be used to get extended information about the release, including: - The values used to generate the release - The generated manifest file - The notes provided by the chart of the release - The hooks associated with the release - The metadata of the release ### Options ``` -h, --help help for get ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm get all](/helm/helm_get_all.md) - download all information for a named release * [helm get hooks](/helm/helm_get_hooks.md) - download all hooks for a named release * [helm get manifest](/helm/helm_get_manifest.md) - download the manifest for a named release * [helm get metadata](/helm/helm_get_metadata.md) - This command fetches metadata for a given release * [helm get notes](/helm/helm_get_notes.md) - download the notes for a named release * [helm get values](/helm/helm_get_values.md) - download the values file for a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_all.md ================================================ --- title: helm get all --- download all information for a named release ### Synopsis This command prints a human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. ``` helm get all RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for all --revision int get the named release with revision --template string go template for formatting the output, eg: {{.Release.Name}} ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_hooks.md ================================================ --- title: helm get hooks --- download all hooks for a named release ### Synopsis This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. ``` helm get hooks RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for hooks --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_manifest.md ================================================ --- title: helm get manifest --- download the manifest for a named release ### Synopsis This command fetches the generated manifest for a given release. A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. ``` helm get manifest RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for manifest --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_metadata.md ================================================ --- title: helm get metadata --- This command fetches metadata for a given release ``` helm get metadata RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for metadata -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int specify release revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_notes.md ================================================ --- title: helm get notes --- download the notes for a named release ### Synopsis This command shows notes provided by the chart of a named release. ``` helm get notes RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for notes --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_get_values.md ================================================ --- title: helm get values --- download the values file for a named release ### Synopsis This command downloads a values file for a given release. ``` helm get values RELEASE_NAME [flags] ``` ### Options ``` -a, --all dump all (computed) values -h, --help help for values -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int get the named release with revision ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm get](/helm/helm_get.md) - download extended information of a named release ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_history.md ================================================ --- title: helm history --- fetch release history ### Synopsis History prints historical revisions for a given release. A default maximum of 256 revisions will be returned. Setting '--max' configures the maximum length of the revision list returned. The historical release set is printed as a formatted table, e.g: $ helm history angry-bird REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Initial install 2 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Upgraded successfully 3 Mon Oct 3 10:15:13 2016 superseded alpine-0.1.0 1.0 Rolled back to 2 4 Mon Oct 3 10:15:13 2016 deployed alpine-0.1.0 1.0 Upgraded successfully ``` helm history RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for history --max int maximum number of revision to include in history (default 256) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_install.md ================================================ --- title: helm install --- install a chart ### Synopsis This command installs a chart archive. The install argument must be a chart reference, a path to a packaged chart, a path to an unpacked chart directory or a URL. To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line, to force a string value use '--set-string'. You can use '--set-file' to set individual values from a file when the value itself is too long for the command line or is dynamically generated. You can also use '--set-json' to set json values (scalars/objects/arrays) from the command line. $ helm install -f myvalues.yaml myredis ./redis or $ helm install --set name=prod myredis ./redis or $ helm install --set-string long_int=1234567890 myredis ./redis or $ helm install --set-file my_script=dothings.sh myredis ./redis or $ helm install --set-json 'master.sidecars=[{"name":"sidecar","image":"myImage","imagePullPolicy":"Always","ports":[{"name":"portname","containerPort":1234}]}]' myredis ./redis You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm install -f myvalues.yaml -f override.yaml myredis ./redis You can specify the '--set' flag multiple times. The priority will be given to the last (right-most) set specified. For example, if both 'bar' and 'newbar' values are set for a key called 'foo', the 'newbar' value would take precedence: $ helm install --set foo=bar --set foo=newbar myredis ./redis Similarly, in the following example 'foo' is set to '["four"]': $ helm install --set-json='foo=["one", "two", "three"]' --set-json='foo=["four"]' myredis ./redis And in the following example, 'foo' is set to '{"key1":"value1","key2":"bar"}': $ helm install --set-json='foo={"key1":"value1","key2":"value2"}' --set-json='foo.key2="bar"' myredis ./redis To check the generated manifests of a release without installing the chart, the --debug and --dry-run flags can be combined. The --dry-run flag will output all generated chart manifests, including Secrets which can contain sensitive values. To hide Kubernetes Secrets use the --hide-secret flag. Please carefully consider how and when these flags are used. If --verify is set, the chart MUST have a provenance file, and the provenance file MUST pass all verification steps. There are six different ways you can express the chart you want to install: 1. By chart reference: helm install mymaria example/mariadb 2. By path to a packaged chart: helm install mynginx ./nginx-1.2.3.tgz 3. By path to an unpacked chart directory: helm install mynginx ./nginx 4. By absolute URL: helm install mynginx https://example.com/charts/nginx-1.2.3.tgz 5. By chart reference and repo url: helm install --repo https://example.com/charts/ mynginx nginx 6. By OCI registries: helm install mynginx --version 1.2.3 oci://example.com/charts/nginx CHART REFERENCES A chart reference is a convenient way of referencing a chart in a chart repository. When you use a chart reference with a repo prefix ('example/mariadb'), Helm will look in the local configuration for a chart repository named 'example', and will then look for a chart in that repository whose name is 'mariadb'. It will install the latest stable version of that chart until you specify '--devel' flag to also include development version (alpha, beta, and release candidate releases), or supply a version number with the '--version' flag. To see the list of chart repositories, use 'helm repo list'. To search for charts in a repository, use 'helm search'. ``` helm install [NAME] [CHART] [flags] ``` ### Options ``` --rollback-on-failure if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --rollback-on-failure is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for install --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_lint.md ================================================ --- title: helm lint --- examine a chart for possible issues ### Synopsis This command takes a path to a chart and runs a series of tests to verify that the chart is well-formed. If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages. ``` helm lint PATH [flags] ``` ### Options ``` -h, --help help for lint --kube-version string Kubernetes version used for capabilities and deprecation checks --quiet print only warnings and errors --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-schema-validation if set, disables JSON schema validation --strict fail on lint warnings -f, --values strings specify values in a YAML file or a URL (can specify multiple) --with-subcharts lint dependent charts ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_list.md ================================================ --- title: helm list --- list releases ### Synopsis This command lists all of the releases for a specified namespace (uses current namespace context if namespace not specified). By default, it lists only releases that are deployed or failed. Flags like '--uninstalled' and '--all' will alter this behavior. Such flags can be combined: '--uninstalled --failed'. By default, items are sorted alphabetically. Use the '-d' flag to sort by release date. If the --filter flag is provided, it will be treated as a filter. Filters are regular expressions (Perl compatible) that are applied to the list of releases. Only items that match the filter will be returned. $ helm list --filter 'ara[a-z]+' NAME UPDATED CHART maudlin-arachnid 2020-06-18 14:17:46.125134977 +0000 UTC alpine-0.1.0 If no results are found, 'helm list' will exit 0, but with no output (or in the case of no '-q' flag, only headers). By default, up to 256 items may be returned. To limit this, use the '--max' flag. Setting '--max' to 0 will not return all results. Rather, it will return the server's default, which may be much higher than 256. Pairing the '--max' flag with the '--offset' flag allows you to page through results. ``` helm list [flags] ``` ### Options ``` -a, --all show all releases without any filter applied -A, --all-namespaces list releases across all namespaces -d, --date sort by release date --deployed show deployed releases. If no other is specified, this will be automatically enabled --failed show failed releases -f, --filter string a regular expression (Perl compatible). Any releases that match the expression will be included in the results -h, --help help for list -m, --max int maximum number of releases to fetch (default 256) --no-headers don't print headers when using the default output format --offset int next release index in the list, used to offset from start value -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pending show pending releases -r, --reverse reverse the sort order -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2). Works only for secret(default) and configmap storage backends. -q, --short output short (quiet) listing format --superseded show superseded releases --time-format string format time using golang time formatter. Example: --time-format "2006-01-02 15:04:05Z0700" --uninstalled show uninstalled releases (if 'helm uninstall --keep-history' was used) --uninstalling show releases that are currently being uninstalled ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_package.md ================================================ --- title: helm package --- package a chart directory into a chart archive ### Synopsis This command packages a chart into a versioned chart archive file. If a path is given, this will look at that path for a chart (which must contain a Chart.yaml file) and then package that directory. Versioned chart archives are used by Helm package repositories. To sign a chart, use the '--sign' flag. In most cases, you should also provide '--keyring path/to/secret/keys' and '--key keyname'. $ helm package --sign ./mychart --key mykey --keyring ~/.gnupg/secring.gpg If '--keyring' is not specified, Helm usually defaults to the public keyring unless your environment is otherwise configured. ``` helm package [CHART_PATH] [...] [flags] ``` ### Options ``` --app-version string set the appVersion on the chart to this version --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -u, --dependency-update update dependencies from "Chart.yaml" to dir "charts/" before packaging -d, --destination string location to write the chart. (default ".") -h, --help help for package --insecure-skip-tls-verify skip tls certificate checks for the chart download --key string name of the key to use when signing. Used if --sign is true --key-file string identify HTTPS client using this SSL key file --keyring string location of a public keyring (default "~/.gnupg/pubring.gpg") --passphrase-file string location of a file which contains the passphrase for the signing key. Use "-" in order to read from stdin. --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --sign use a PGP private key to sign this package --username string chart repository username where to locate the requested chart --version string set the version on the chart to this semver version ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_plugin.md ================================================ --- title: helm plugin --- install, list, or uninstall Helm plugins ### Synopsis Manage client-side Helm plugins. ### Options ``` -h, --help help for plugin ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm plugin install](/helm/helm_plugin_install.md) - install a Helm plugin * [helm plugin list](/helm/helm_plugin_list.md) - list installed Helm plugins * [helm plugin uninstall](/helm/helm_plugin_uninstall.md) - uninstall one or more Helm plugins * [helm plugin update](/helm/helm_plugin_update.md) - update one or more Helm plugins ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_plugin_install.md ================================================ --- title: helm plugin install --- install a Helm plugin ### Synopsis This command allows you to install a plugin from a url to a VCS repo or a local path. ``` helm plugin install [options] [flags] ``` ### Options ``` -h, --help help for install --version string specify a version constraint. If this is not specified, the latest version is installed ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_plugin_list.md ================================================ --- title: helm plugin list --- list installed Helm plugins ``` helm plugin list [flags] ``` ### Options ``` -h, --help help for list ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_plugin_uninstall.md ================================================ --- title: helm plugin uninstall --- uninstall one or more Helm plugins ``` helm plugin uninstall ... [flags] ``` ### Options ``` -h, --help help for uninstall ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_plugin_update.md ================================================ --- title: helm plugin update --- update one or more Helm plugins ``` helm plugin update ... [flags] ``` ### Options ``` -h, --help help for update ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm plugin](/helm/helm_plugin.md) - install, list, or uninstall Helm plugins ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_pull.md ================================================ --- title: helm pull --- download a chart from a repository and (optionally) unpack it in local directory ### Synopsis Retrieve a package from a package repository, and download it locally. This is useful for fetching packages to inspect, modify, or repackage. It can also be used to perform cryptographic verification of a chart without installing the chart. There are options for unpacking the chart after download. This will create a directory for the chart and uncompress into that directory. If the --verify flag is specified, the requested chart MUST have a provenance file, and MUST pass the verification process. Failure in any part of this will result in an error, and the chart will not be saved locally. ``` helm pull [chart URL | repo/chartname] [...] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file -d, --destination string location to write the chart. If this and untardir are specified, untardir is appended to this (default ".") --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored. -h, --help help for pull --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --prov fetch the provenance file, but don't perform verification --repo string chart repository url where to locate the requested chart --untar if set to true, will untar the chart after downloading it --untardir string if untar is specified, this flag specifies the name of the directory into which the chart is expanded (default ".") --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_push.md ================================================ --- title: helm push --- push a chart to remote ### Synopsis Upload a chart to a registry. If the chart has an associated provenance file, it will also be uploaded. ``` helm push [chart] [remote] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for push --insecure-skip-tls-verify skip tls certificate checks for the chart upload --key-file string identify registry client using this SSL key file --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart upload --username string chart repository username where to locate the requested chart ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_registry.md ================================================ --- title: helm registry --- login to or logout from a registry ### Synopsis This command consists of multiple subcommands to interact with registries. ### Options ``` -h, --help help for registry ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm registry login](/helm/helm_registry_login.md) - login to a registry * [helm registry logout](/helm/helm_registry_logout.md) - logout from a registry ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_registry_login.md ================================================ --- title: helm registry login --- login to a registry ### Synopsis Authenticate to a remote registry. ``` helm registry login [host] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify registry client using this SSL certificate file -h, --help help for login --insecure allow connections to TLS registry without certs --key-file string identify registry client using this SSL key file -p, --password string registry password or identity token --password-stdin read password or identity token from stdin --plain-http use insecure HTTP connections for the chart upload -u, --username string registry username ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm registry](/helm/helm_registry.md) - login to or logout from a registry ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_registry_logout.md ================================================ --- title: helm registry logout --- logout from a registry ### Synopsis Remove credentials stored for a remote registry. ``` helm registry logout [host] [flags] ``` ### Options ``` -h, --help help for logout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm registry](/helm/helm_registry.md) - login to or logout from a registry ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo.md ================================================ --- title: helm repo --- add, list, remove, update, and index chart repositories ### Synopsis This command consists of multiple subcommands to interact with chart repositories. It can be used to add, remove, list, and index chart repositories. ### Options ``` -h, --help help for repo ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm repo add](/helm/helm_repo_add.md) - add a chart repository * [helm repo index](/helm/helm_repo_index.md) - generate an index file given a directory containing packaged charts * [helm repo list](/helm/helm_repo_list.md) - list chart repositories * [helm repo remove](/helm/helm_repo_remove.md) - remove one or more chart repositories * [helm repo update](/helm/helm_repo_update.md) - update information of available charts locally from chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo_add.md ================================================ --- title: helm repo add --- add a chart repository ``` helm repo add [NAME] [URL] [flags] ``` ### Options ``` --allow-deprecated-repos by default, this command will not allow adding official repos that have been permanently deleted. This disables that behavior --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --force-update replace (overwrite) the repo if it already exists -h, --help help for add --insecure-skip-tls-verify skip tls certificate checks for the repository --key-file string identify HTTPS client using this SSL key file --no-update Ignored. Formerly, it would disabled forced updates. It is deprecated by force-update. --pass-credentials pass credentials to all domains --password string chart repository password --password-stdin read chart repository password from stdin --timeout duration time to wait for the index file download to complete (default 2m0s) --username string chart repository username ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo_index.md ================================================ --- title: helm repo index --- generate an index file given a directory containing packaged charts ### Synopsis Read the current directory, generate an index file based on the charts found and write the result to 'index.yaml' in the current directory. This tool is used for creating an 'index.yaml' file for a chart repository. To set an absolute URL to the charts, use '--url' flag. To merge the generated index with an existing index file, use the '--merge' flag. In this case, the charts found in the current directory will be merged into the index passed in with --merge, with local charts taking priority over existing charts. ``` helm repo index [DIR] [flags] ``` ### Options ``` -h, --help help for index --json output in JSON format --merge string merge the generated index into the given index --url string url of chart repository ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo_list.md ================================================ --- title: helm repo list --- list chart repositories ``` helm repo list [flags] ``` ### Options ``` -h, --help help for list -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo_remove.md ================================================ --- title: helm repo remove --- remove one or more chart repositories ``` helm repo remove [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` -h, --help help for remove ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_repo_update.md ================================================ --- title: helm repo update --- update information of available charts locally from chart repositories ### Synopsis Update gets the latest information about charts from the respective chart repositories. Information is cached locally, where it is used by commands like 'helm search'. You can optionally specify a list of repositories you want to update. $ helm repo update ... To update all the repositories, use 'helm repo update'. ``` helm repo update [REPO1 [REPO2 ...]] [flags] ``` ### Options ``` --fail-on-repo-update-fail update fails if any of the repository updates fail -h, --help help for update --timeout duration time to wait for the index file download to complete (default 2m0s) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm repo](/helm/helm_repo.md) - add, list, remove, update, and index chart repositories ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_rollback.md ================================================ --- title: helm rollback --- roll back a release to a previous revision ### Synopsis This command rolls back a release to a previous revision. The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release. To see revision numbers, run 'helm history RELEASE'. ``` helm rollback [REVISION] [flags] ``` ### Options ``` --cleanup-on-fail allow deletion of new resources created in this rollback when rollback fails --dry-run simulate a rollback --force force resource update through delete/recreate if needed -h, --help help for rollback --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --no-hooks prevent hooks from running during rollback --recreate-pods performs pods restart for the resource if applicable --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_search.md ================================================ --- title: helm search --- search for a keyword in charts ### Synopsis Search provides the ability to search for Helm charts in the various places they can be stored including the Artifact Hub and repositories you have added. Use search subcommands to search different locations for charts. ### Options ``` -h, --help help for search ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm search hub](/helm/helm_search_hub.md) - search for charts in the Artifact Hub or your own hub instance * [helm search repo](/helm/helm_search_repo.md) - search repositories for a keyword in charts ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_search_hub.md ================================================ --- title: helm search hub --- search for charts in the Artifact Hub or your own hub instance ### Synopsis Search for Helm charts in the Artifact Hub or your own hub instance. Artifact Hub is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects, including publicly available distributed charts Helm charts. It is a Cloud Native Computing Foundation sandbox project. You can browse the hub at https://artifacthub.io/ The [KEYWORD] argument accepts either a keyword string, or quoted string of rich query options. For rich query options documentation, see https://artifacthub.github.io/hub/api/?urls.primaryName=Monocular%20compatible%20search%20API#/Monocular/get_api_chartsvc_v1_charts_search Previous versions of Helm used an instance of Monocular as the default 'endpoint', so for backwards compatibility Artifact Hub is compatible with the Monocular search API. Similarly, when setting the 'endpoint' flag, the specified endpoint must also be implement a Monocular compatible search API endpoint. Note that when specifying a Monocular instance as the 'endpoint', rich queries are not supported. For API details, see https://github.com/helm/monocular ``` helm search hub [KEYWORD] [flags] ``` ### Options ``` --endpoint string Hub instance to query for charts (default "https://hub.helm.sh") --fail-on-no-result search fails if no results are found -h, --help help for hub --list-repo-url print charts repository URL --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm search](/helm/helm_search.md) - search for a keyword in charts ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_search_repo.md ================================================ --- title: helm search repo --- search repositories for a keyword in charts ### Synopsis Search reads through all of the repositories configured on the system, and looks for matches. Search of these repositories uses the metadata stored on the system. It will display the latest stable versions of the charts found. If you specify the --devel flag, the output will include pre-release versions. If you want to search using a version constraint, use --version. Examples: # Search for stable release versions matching the keyword "nginx" $ helm search repo nginx # Search for release versions matching the keyword "nginx", including pre-release versions $ helm search repo nginx --devel # Search for the latest stable release for nginx-ingress with a major version of 1 $ helm search repo nginx-ingress --version ^1.0.0 Repositories are managed with 'helm repo' commands. ``` helm search repo [keyword] [flags] ``` ### Options ``` --devel use development versions (alpha, beta, and release candidate releases), too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --fail-on-no-result search fails if no results are found -h, --help help for repo --max-col-width uint maximum column width for output table (default 50) -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) -r, --regexp use regular expressions for searching repositories you have added --version string search using semantic versioning constraints on repositories you have added -l, --versions show the long listing, with each version of each chart on its own line, for repositories you have added ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm search](/helm/helm_search.md) - search for a keyword in charts ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show.md ================================================ --- title: helm show --- show information of a chart ### Synopsis This command consists of multiple subcommands to display information about a chart ### Options ``` -h, --help help for show ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. * [helm show all](/helm/helm_show_all.md) - show all information of the chart * [helm show chart](/helm/helm_show_chart.md) - show the chart's definition * [helm show crds](/helm/helm_show_crds.md) - show the chart's CRDs * [helm show readme](/helm/helm_show_readme.md) - show the chart's README * [helm show values](/helm/helm_show_values.md) - show the chart's values ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show_all.md ================================================ --- title: helm show all --- show all information of the chart ### Synopsis This command inspects a chart (directory, file, or URL) and displays all its content (values.yaml, Chart.yaml, README) ``` helm show all [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for all --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show_chart.md ================================================ --- title: helm show chart --- show the chart's definition ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the Chart.yaml file ``` helm show chart [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for chart --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show_crds.md ================================================ --- title: helm show crds --- show the chart's CRDs ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the CustomResourceDefinition files ``` helm show crds [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for crds --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show_readme.md ================================================ --- title: helm show readme --- show the chart's README ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the README file ``` helm show readme [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for readme --insecure-skip-tls-verify skip tls certificate checks for the chart download --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_show_values.md ================================================ --- title: helm show values --- show the chart's values ### Synopsis This command inspects a chart (directory, file, or URL) and displays the contents of the values.yaml file ``` helm show values [CHART] [flags] ``` ### Options ``` --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored -h, --help help for values --insecure-skip-tls-verify skip tls certificate checks for the chart download --jsonpath string supply a JSONPath expression to filter the output --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --repo string chart repository url where to locate the requested chart --username string chart repository username where to locate the requested chart --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm show](/helm/helm_show.md) - show information of a chart ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_status.md ================================================ --- title: helm status --- display the status of the named release ### Synopsis This command shows the status of a named release. The status consists of: - last deployment time - k8s namespace in which the release lives - state of the release (can be: unknown, deployed, uninstalled, superseded, failed, uninstalling, pending-install, pending-upgrade or pending-rollback) - revision of the release - description of the release (can be completion message or error message, need to enable --show-desc) - list of resources that this release consists of (need to enable --show-resources) - details on last test suite run, if applicable - additional notes provided by the chart ``` helm status RELEASE_NAME [flags] ``` ### Options ``` -h, --help help for status -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --revision int if set, display the status of the named release with revision --show-desc if set, display the description message of the named release --show-resources if set, display the resources of the named release ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_template.md ================================================ --- title: helm template --- locally render templates ### Synopsis Render chart templates locally and display the output. Any values that would normally be looked up or retrieved in-cluster will be faked locally. Additionally, none of the server-side testing of chart validity (e.g. whether an API is supported) is done. ``` helm template [NAME] [CHART] [flags] ``` ### Options ``` -a, --api-versions strings Kubernetes api versions used for Capabilities.APIVersions --rollback-on-failure if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --rollback-on-failure is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --create-namespace create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -g, --generate-name generate the name (and omit the NAME parameter) -h, --help help for template --hide-notes if set, do not show notes in install output. Does not affect presence in chart metadata --include-crds include CRDs in the templated output --insecure-skip-tls-verify skip tls certificate checks for the chart download --is-upgrade set .Release.IsUpgrade instead of .Release.IsInstall --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") --kube-version string Kubernetes version used for Capabilities.KubeVersion -l, --labels stringToString Labels that would be added to release metadata. Should be divided by comma. (default []) --name-template string specify template used to name the release --no-hooks prevent hooks from running during install --output-dir string writes the executed templates to files in output-dir instead of stdout --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --release-name use release name in the output-dir path. --render-subchart-notes if set, render subchart notes along with the parent --replace re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production --repo string chart repository url where to locate the requested chart --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) -s, --show-only stringArray only show manifests rendered from the given templates --skip-crds if set, no CRDs will be installed. By default, CRDs are installed if not already present --skip-schema-validation if set, disables JSON schema validation --skip-tests skip tests from templated output --take-ownership if set, install will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart --validate validate your manifests against the Kubernetes cluster you are currently pointing at. This is the same validation performed on an install -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_test.md ================================================ --- title: helm test --- run tests for a release ### Synopsis The test command runs the tests for a release. The argument this command takes is the name of a deployed release. The tests to be run are defined in the chart that was installed. ``` helm test [RELEASE] [flags] ``` ### Options ``` --filter strings specify tests by attribute (currently "name") using attribute=value syntax or '!attribute=value' to exclude a test (can specify multiple or separate values with commas: name=test1,name=test2) -h, --help help for test --hide-notes if set, do not show notes in test output. Does not affect presence in chart metadata --logs dump the logs from test pods (this runs after all tests are complete, but before any cleanup) --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_uninstall.md ================================================ --- title: helm uninstall --- uninstall a release ### Synopsis This command takes a release name and uninstalls the release. It removes all of the resources associated with the last release of the chart as well as the release history, freeing it up for future use. Use the '--dry-run' flag to see which releases will be uninstalled without actually uninstalling them. ``` helm uninstall RELEASE_NAME [...] [flags] ``` ### Options ``` --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run simulate a uninstall -h, --help help for uninstall --ignore-not-found Treat "release not found" as a successful uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --no-hooks prevent hooks from running during uninstallation --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_upgrade.md ================================================ --- title: helm upgrade --- upgrade a release ### Synopsis This command upgrades a release to a new version of a chart. The upgrade arguments must be a release and chart. The chart argument can be either: a chart reference('example/mariadb'), a path to a chart directory, a packaged chart, or a fully qualified URL. For chart references, the latest version will be specified unless the '--version' flag is set. To override values in a chart, use either the '--values' flag and pass in a file or use the '--set' flag and pass configuration from the command line, to force string values, use '--set-string'. You can use '--set-file' to set individual values from a file when the value itself is too long for the command line or is dynamically generated. You can also use '--set-json' to set json values (scalars/objects/arrays) from the command line. You can specify the '--values'/'-f' flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence: $ helm upgrade -f myvalues.yaml -f override.yaml redis ./redis You can specify the '--set' flag multiple times. The priority will be given to the last (right-most) set specified. For example, if both 'bar' and 'newbar' values are set for a key called 'foo', the 'newbar' value would take precedence: $ helm upgrade --set foo=bar --set foo=newbar redis ./redis You can update the values for an existing release with this command as well via the '--reuse-values' flag. The 'RELEASE' and 'CHART' arguments should be set to the original parameters, and existing values will be merged with any values set via '--values'/'-f' or '--set' flags. Priority is given to new values. $ helm upgrade --reuse-values --set foo=bar --set foo=newbar redis ./redis The --dry-run flag will output all generated chart manifests, including Secrets which can contain sensitive values. To hide Kubernetes Secrets use the --hide-secret flag. Please carefully consider how and when these flags are used. ``` helm upgrade [RELEASE] [CHART] [flags] ``` ### Options ``` --rollback-on-failure if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --rollback-on-failure is used --ca-file string verify certificates of HTTPS-enabled servers using this CA bundle --cert-file string identify HTTPS client using this SSL certificate file --cleanup-on-fail allow deletion of new resources created in this upgrade when upgrade fails --create-namespace if --install is set, create the release namespace if not present --dependency-update update dependencies if they are missing before installing the chart --description string add a custom description --devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored --disable-openapi-validation if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema --dry-run string[="client"] simulate an install. If --dry-run is set with no option being specified or as '--dry-run=client', it will not attempt cluster connections. Setting '--dry-run=server' allows attempting cluster connections. --enable-dns enable DNS lookups when rendering templates --force force resource updates through a replacement strategy -h, --help help for upgrade --hide-notes if set, do not show notes in upgrade output. Does not affect presence in chart metadata --hide-secret hide Kubernetes Secrets when also using the --dry-run flag --history-max int limit the maximum number of revisions saved per release. Use 0 for no limit (default 10) --insecure-skip-tls-verify skip tls certificate checks for the chart download -i, --install if a release by this name doesn't already exist, run an install --key-file string identify HTTPS client using this SSL key file --keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg") -l, --labels stringToString Labels that would be added to release metadata. Should be separated by comma. Original release labels will be merged with upgrade labels. You can unset label using null. (default []) --no-hooks disable pre/post upgrade hooks -o, --output format prints the output in the specified format. Allowed values: table, json, yaml (default table) --pass-credentials pass credentials to all domains --password string chart repository password where to locate the requested chart --plain-http use insecure HTTP connections for the chart download --post-renderer postRendererString the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path --post-renderer-args postRendererArgsSlice an argument to the post-renderer (can specify multiple) (default []) --render-subchart-notes if set, render subchart notes along with the parent --repo string chart repository url where to locate the requested chart --reset-then-reuse-values when upgrading, reset the values to the ones built into the chart, apply the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' or '--reuse-values' is specified, this is ignored --reset-values when upgrading, reset the values to the ones built into the chart --reuse-values when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored --set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2) --set-json stringArray set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2) --set-literal stringArray set a literal STRING value on the command line --set-string stringArray set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --skip-crds if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled --skip-schema-validation if set, disables JSON schema validation --take-ownership if set, upgrade will ignore the check for helm annotations and take ownership of the existing resources --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --username string chart repository username where to locate the requested chart -f, --values strings specify values in a YAML file or a URL (can specify multiple) --verify verify the package before using it --version string specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used --wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout --wait-for-jobs if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_verify.md ================================================ --- title: helm verify --- verify that a chart at the given path has been signed and is valid ### Synopsis Verify that the given chart has a valid provenance file. Provenance files provide cryptographic verification that a chart has not been tampered with, and was packaged by a trusted provider. This command can be used to verify a local chart. Several other commands provide '--verify' flags that run the same validation. To generate a signed package, use the 'helm package --sign' command. ``` helm verify PATH [flags] ``` ### Options ``` -h, --help help for verify --keyring string keyring containing public keys (default "~/.gnupg/pubring.gpg") ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/helm_version.md ================================================ --- title: helm version --- print the client version information ### Synopsis Show the version for Helm. This will print a representation the version of Helm. The output will look something like this: version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"} - Version is the semantic version of the release. - GitCommit is the SHA for the commit that this version was built from. - GitTreeState is "clean" if there are no local code changes when this binary was built, and "dirty" if the binary was built from locally modified code. - GoVersion is the version of Go that was used to compile Helm. When using the --template flag the following properties are available to use in the template: - .Version contains the semantic version of Helm - .GitCommit is the git commit - .GitTreeState is the state of the git tree when Helm was built - .GoVersion contains the version of Go that Helm was compiled with For example, --template='Version: {{.Version}}' outputs 'Version: v3.2.1'. ``` helm version [flags] ``` ### Options ``` -h, --help help for version --short print the version number --template string template for version string format ``` ### Options inherited from parent commands ``` --burst-limit int client-side default throttling limit (default 100) --debug enable verbose output --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-tls-server-name string server name to use for Kubernetes API server certificate validation. If it is not provided, the hostname used to contact the server is used --kube-token string bearer token used for authentication --kubeconfig string path to the kubeconfig file -n, --namespace string namespace scope for this request --qps float32 queries per second used when communicating with the Kubernetes API, not including bursting --registry-config string path to the registry config file (default "~/.config/helm/registry/config.json") --repository-cache string path to the directory containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") ``` ### SEE ALSO * [helm](/helm/helm.md) - The Helm package manager for Kubernetes. ###### Auto generated by spf13/cobra on 14-Jan-2026 ================================================ FILE: versioned_docs/version-3/helm/index.mdx ================================================ --- title: Helm Commands description: Documentation for the full list of helm CLI commands. sidebar_position: 6 id: helm-category --- # Helm Commands Here you'll find the list of CLI commands for Helm, with help info on their usage. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/howto/chart_releaser_action.md ================================================ --- title: Chart Releaser Action to Automate GitHub Page Charts description: Describe how to use Chart Releaser Action to automate releasing charts through GitHub pages. sidebar_position: 3 --- This guide describes how to use [Chart Releaser Action](https://github.com/marketplace/actions/helm-chart-releaser) to automate releasing charts through GitHub pages. Chart Releaser Action is a GitHub Action workflow to turn a GitHub project into a self-hosted Helm chart repo, using [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool. ## Repository Changes Create a Git repository under your GitHub organization. You could give the name of the repository as `helm-charts`, though other names are also acceptable. The sources of all the charts can be placed under the `main` branch. The charts should be placed under `/charts` directory at the top-level of the directory tree. There should be another branch named `gh-pages` to publish the charts. The changes to that branch will be automatically created by the Chart Releaser Action described here. However, you can create that `gh-branch` and add `README.md` file, which is going to be visible to the users visiting the page. You can add instruction in the `README.md` for charts installation like this (replace ``, ``, and ``): ``` ## Usage [Helm](https://helm.sh) must be installed to use the charts. Please refer to Helm's [documentation](https://helm.sh/docs) to get started. Once Helm has been set up correctly, add the repo as follows: helm repo add https://.github.io/helm-charts If you had already added this repo earlier, run `helm repo update` to retrieve the latest versions of the packages. You can then run `helm search repo ` to see the charts. To install the chart: helm install my- / To uninstall the chart: helm uninstall my- ``` The charts will be published to a website with URL like this: https://.github.io/helm-charts ## GitHub Actions Workflow Create GitHub Actions workflow file in the `main` branch at `.github/workflows/release.yml` ``` name: Release Charts on: push: branches: - main jobs: release: permissions: contents: write runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Run chart-releaser uses: helm/chart-releaser-action@v1.6.0 env: CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}" ``` The above configuration uses [@helm/chart-releaser-action](https://github.com/helm/chart-releaser-action) to turn your GitHub project into a self-hosted Helm chart repo. It does this - during every push to main - by checking each chart in your project, and whenever there's a new chart version, creates a corresponding GitHub release named for the chart version, adds Helm chart artifacts to the release, and creates or updates an `index.yaml` file with metadata about those releases, which is then hosted on GitHub pages. The Chart Releaser Action version number used in the above example is `v1.6.0`. You can change it to the [latest available version](https://github.com/helm/chart-releaser-action/releases). Note: The Chart Releaser Action is almost always used in tandem with the [Helm Testing Action](https://github.com/marketplace/actions/helm-chart-testing) and [Kind Action](https://github.com/marketplace/actions/kind-cluster). ================================================ FILE: versioned_docs/version-3/howto/chart_repository_sync_example.md ================================================ --- title: Syncing Your Chart Repository description: Describes how to synchronize your local and remote chart repositories. sidebar_position: 2 --- *Note: This example is specifically for a Google Cloud Storage (GCS) bucket which serves a chart repository.* ## Prerequisites * Install the [gsutil](https://cloud.google.com/storage/docs/gsutil) tool. *We rely heavily on the gsutil rsync functionality* * Be sure to have access to the Helm binary * _Optional: We recommend you set [object versioning](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#top_of_page) on your GCS bucket in case you accidentally delete something._ ## Set up a local chart repository directory Create a local directory like we did in [the chart repository guide](/topics/chart_repository.md), and place your packaged charts in that directory. For example: ```console $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ ``` ## Generate an updated index.yaml Use Helm to generate an updated index.yaml file by passing in the directory path and the url of the remote repository to the `helm repo index` command like this: ```console $ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com ``` This will generate an updated index.yaml file and place it in the `fantastic-charts/` directory. ## Sync your local and remote chart repositories Upload the contents of the directory to your GCS bucket by running `scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket name. For example: ```console $ pwd /Users/me/code/go/src/helm.sh/helm $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts Getting ready to sync your local directory (fantastic-charts/) to a remote repository at gs://fantastic-charts Verifying Prerequisites.... Thumbs up! Looks like you have gsutil. Let's continue. Building synchronization state... Starting synchronization Would copy file://fantastic-charts/alpine-0.1.0.tgz to gs://fantastic-charts/alpine-0.1.0.tgz Would copy file://fantastic-charts/index.yaml to gs://fantastic-charts/index.yaml Are you sure you would like to continue with these changes?? [y/N]} y Building synchronization state... Starting synchronization Copying file://fantastic-charts/alpine-0.1.0.tgz [Content-Type=application/x-tar]... Uploading gs://fantastic-charts/alpine-0.1.0.tgz: 740 B/740 B Copying file://fantastic-charts/index.yaml [Content-Type=application/octet-stream]... Uploading gs://fantastic-charts/index.yaml: 347 B/347 B Congratulations your remote chart repository now matches the contents of fantastic-charts/ ``` ## Updating your chart repository You'll want to keep a local copy of the contents of your chart repository or use `gsutil rsync` to copy the contents of your remote chart repository to a local directory. For example: ```console $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization Would copy gs://bucket-name/alpine-0.1.0.tgz to file://local-dir/alpine-0.1.0.tgz Would copy gs://bucket-name/index.yaml to file://local-dir/index.yaml $ gsutil rsync -d gs://bucket-name local-dir/ # performs the copy actions Building synchronization state... Starting synchronization Copying gs://bucket-name/alpine-0.1.0.tgz... Downloading file://local-dir/alpine-0.1.0.tgz: 740 B/740 B Copying gs://bucket-name/index.yaml... Downloading file://local-dir/index.yaml: 346 B/346 B ``` Helpful Links: * Documentation on [gsutil rsync](https://cloud.google.com/storage/docs/gsutil/commands/rsync#description) * [The Chart Repository Guide](/topics/chart_repository.md) * Documentation on [object versioning and concurrency control](https://cloud.google.com/storage/docs/gsutil/addlhelp/ObjectVersioningandConcurrencyControl#overview) in Google Cloud Storage ================================================ FILE: versioned_docs/version-3/howto/charts_tips_and_tricks.md ================================================ --- title: Chart Development Tips and Tricks description: Covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. sidebar_position: 1 --- This guide covers some of the tips and tricks Helm chart developers have learned while building production-quality charts. ## Know Your Template Functions Helm uses [Go templates](https://godoc.org/text/template) for templating your resource files. While Go ships several built-in functions, we have added many others. First, we added all of the functions in the [Sprig library](https://masterminds.github.io/sprig/), except `env` and `expandenv`, for security reasons. We also added two special template functions: `include` and `required`. The `include` function allows you to bring in another template, and then pass the results to other template functions. For example, this template snippet includes a template called `mytpl`, then lowercases the result, then wraps that in double quotes. ```yaml value: {{ include "mytpl" . | lower | quote }} ``` The `required` function allows you to declare a particular values entry as required for template rendering. If the value is empty, the template rendering will fail with a user submitted error message. The following example of the `required` function declares an entry for `.Values.who` is required, and will print an error message when that entry is missing: ```yaml value: {{ required "A valid .Values.who entry required!" .Values.who }} ``` ## Quote Strings, Don't Quote Integers When you are working with string data, you are always safer quoting the strings than leaving them as bare words: ```yaml name: {{ .Values.MyName | quote }} ``` But when working with integers _do not quote the values._ That can, in many cases, cause parsing errors inside of Kubernetes. ```yaml port: {{ .Values.Port }} ``` This remark does not apply to env variables values which are expected to be string, even if they represent integers: ```yaml env: - name: HOST value: "http://host" - name: PORT value: "1234" ``` ## Using the 'include' Function Go provides a way of including one template in another using a built-in `template` directive. However, the built-in function cannot be used in Go template pipelines. To make it possible to include a template, and then perform an operation on that template's output, Helm has a special `include` function: ``` {{ include "toYaml" $value | indent 2 }} ``` The above includes a template called `toYaml`, passes it `$value`, and then passes the output of that template to the `indent` function. Because YAML ascribes significance to indentation levels and whitespace, this is one great way to include snippets of code, but handle indentation in a relevant context. ## Using the 'required' function Go provides a way for setting template options to control behavior when a map is indexed with a key that's not present in the map. This is typically set with `template.Options("missingkey=option")`, where `option` can be `default`, `zero`, or `error`. While setting this option to error will stop execution with an error, this would apply to every missing key in the map. There may be situations where a chart developer wants to enforce this behavior for select values in the `values.yaml` file. The `required` function gives developers the ability to declare a value entry as required for template rendering. If the entry is empty in `values.yaml`, the template will not render and will return an error message supplied by the developer. For example: ``` {{ required "A valid foo is required!" .Values.foo }} ``` The above will render the template when `.Values.foo` is defined, but will fail to render and exit when `.Values.foo` is undefined. ## Using the 'tpl' Function The `tpl` function allows developers to evaluate strings as templates inside a template. This is useful to pass a template string as a value to a chart or render external configuration files. Syntax: `{{ tpl TEMPLATE_STRING VALUES }}` Examples: ```yaml # values template: "{{ .Values.name }}" name: "Tom" # template {{ tpl .Values.template . }} # output Tom ``` Rendering an external configuration file: ```yaml # external configuration file conf/app.conf firstName={{ .Values.firstName }} lastName={{ .Values.lastName }} # values firstName: Peter lastName: Parker # template {{ tpl (.Files.Get "conf/app.conf") . }} # output firstName=Peter lastName=Parker ``` ## Creating Image Pull Secrets Image pull secrets are essentially a combination of _registry_, _username_, and _password_. You may need them in an application you are deploying, but to create them requires running `base64` a couple of times. We can write a helper template to compose the Docker configuration file for use as the Secret's payload. Here is an example: First, assume that the credentials are defined in the `values.yaml` file like so: ```yaml imageCredentials: registry: quay.io username: someone password: sillyness email: someone@host.com ``` We then define our helper template as follows: ``` {{- define "imagePullSecret" }} {{- with .Values.imageCredentials }} {{- printf "{\"auths\":{\"%s\":{\"username\":\"%s\",\"password\":%s,\"email\":\"%s\",\"auth\":\"%s\"}}}" .registry .username (.password | quote) .email (printf "%s:%s" .username .password | b64enc) | b64enc }} {{- end }} {{- end }} ``` Finally, we use the helper template in a larger template to create the Secret manifest: ```yaml apiVersion: v1 kind: Secret metadata: name: myregistrykey type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: {{ template "imagePullSecret" . }} ``` ## Automatically Roll Deployments Often times ConfigMaps or Secrets are injected as configuration files in containers or there are other external dependency changes that require rolling pods. Depending on the application a restart may be required should those be updated with a subsequent `helm upgrade`, but if the deployment spec itself didn't change the application keeps running with the old configuration resulting in an inconsistent deployment. The `sha256sum` function can be used to ensure a deployment's annotation section is updated if another file changes: ```yaml kind: Deployment spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} [...] ``` NOTE: If you're adding this to a library chart you won't be able to access your file in `$.Template.BasePath`. Instead you can reference your definition with `{{ include ("mylibchart.configmap") . | sha256sum }}`. In the event you always want to roll your deployment, you can use a similar annotation step as above, instead replacing with a random string so it always changes and causes the deployment to roll: ```yaml kind: Deployment spec: template: metadata: annotations: rollme: {{ randAlphaNum 5 | quote }} [...] ``` Each invocation of the template function will generate a unique random string. This means that if it's necessary to sync the random strings used by multiple resources, all relevant resources will need to be in the same template file. Both of these methods allow your Deployment to leverage the built in update strategy logic to avoid taking downtime. NOTE: In the past we recommended using the `--recreate-pods` flag as another option. This flag has been marked as deprecated in Helm 3 in favor of the more declarative method above. ## Tell Helm Not To Uninstall a Resource Sometimes there are resources that should not be uninstalled when Helm runs a `helm uninstall`. Chart developers can add an annotation to a resource to prevent it from being uninstalled. ```yaml kind: Secret metadata: annotations: helm.sh/resource-policy: keep [...] ``` The annotation `helm.sh/resource-policy: keep` instructs Helm to skip deleting this resource when a helm operation (such as `helm uninstall`, `helm upgrade` or `helm rollback`) would result in its deletion. _However_, this resource becomes orphaned. Helm will no longer manage it in any way. This can lead to problems if using `helm install --replace` on a release that has already been uninstalled, but has kept resources. ## Using "Partials" and Template Includes Sometimes you want to create some reusable parts in your chart, whether they're blocks or template partials. And often, it's cleaner to keep these in their own files. In the `templates/` directory, any file that begins with an underscore(`_`) is not expected to output a Kubernetes manifest file. So by convention, helper templates and partials are placed in a `_helpers.tpl` file. ## Complex Charts with Many Dependencies Many of the charts in the CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0) are "building blocks" for creating more advanced applications. But charts may be used to create instances of large-scale applications. In such cases, a single umbrella chart may have multiple subcharts, each of which functions as a piece of the whole. The current best practice for composing a complex application from discrete parts is to create a top-level umbrella chart that exposes the global configurations, and then use the `charts/` subdirectory to embed each of the components. ## YAML is a Superset of JSON According to the YAML specification, YAML is a superset of JSON. That means that any valid JSON structure ought to be valid in YAML. This has an advantage: Sometimes template developers may find it easier to express a datastructure with a JSON-like syntax rather than deal with YAML's whitespace sensitivity. As a best practice, templates should follow a YAML-like syntax _unless_ the JSON syntax substantially reduces the risk of a formatting issue. ## Be Careful with Generating Random Values There are functions in Helm that allow you to generate random data, cryptographic keys, and so on. These are fine to use. But be aware that during upgrades, templates are re-executed. When a template run generates data that differs from the last run, that will trigger an update of that resource. ## Install or Upgrade a Release with One Command Helm provides a way to perform an install-or-upgrade as a single command. Use `helm upgrade` with the `--install` command. This will cause Helm to see if the release is already installed. If not, it will run an install. If it is, then the existing release will be upgraded. ```console $ helm upgrade --install --values ``` ================================================ FILE: versioned_docs/version-3/howto/index.mdx ================================================ --- title: How-to sidebar_position: 2 --- # How-to Guides Here you’ll find short answers to “How do I….?” types of questions. These how-to guides don’t cover topics in depth – you’ll find that material in the [Topic Guides](/topics/index.mdx). However, these guides will help you quickly accomplish common tasks. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/index.mdx ================================================ --- title: Docs Home description: Everything you need to know about how the documentation is organized. sidebar_position: 1 --- # Welcome Welcome to the [Helm](https://helm.sh/) documentation. Helm is the package manager for Kubernetes, and you can read detailed background information in the [CNCF Helm Project Journey report](https://www.cncf.io/cncf-helm-project-journey/). # How the documentation is organized Helm has a lot of documentation. A high-level overview of how it’s organized will help you know where to look for certain things: - [Tutorials](/chart_template_guide/getting_started.md) take you by the hand through a series of steps to create your first Helm chart. Start here if you’re new to Helm. - [Topic guides](/topics/index.mdx) discuss key topics and concepts at a fairly high level and provide useful background information and explanation. - [Community Guides](/community) discuss topics centered around Helm’s community. Start here if you want to learn more about the development process of Helm itself and how you can contribute. - [How-to guides](/howto/index.mdx) are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how Helm works. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/intro/CheatSheet.md ================================================ --- title: Cheat Sheet description: Helm cheatsheet sidebar_position: 4 --- Helm cheatsheet featuring all the necessary commands required to manage an application through Helm. ----------------------------------------------------------------------------------------------------------------------------------------------- ### Basic interpretations/context Chart: - It is the name of your chart in case it has been pulled and untarred. - It is / in case the repository has been added but chart not pulled. - It is the URL/Absolute path to the chart. Name: - It is the name you want to give to your current helm chart installation. Release: - Is the name you assigned to an installation instance. Revision: - Is the value from the Helm history command Repo-name: - The name of a repository. DIR: - Directory name/path ------------------------------------------------------------------------------------------------------------------------------------------------ ### Chart Management ```bash helm create # Creates a chart directory along with the common files and directories used in a chart. helm package # Packages a chart into a versioned chart archive file. helm lint # Run tests to examine a chart and identify possible issues: helm show all # Inspect a chart and list its contents: helm show values # Displays the contents of the values.yaml file helm pull # Download/pull chart helm pull --untar=true # If set to true, will untar the chart after downloading it helm pull --verify # Verify the package before using it helm pull --version # Default-latest is used, specify a version constraint for the chart version to use helm dependency list # Display a list of a chart’s dependencies: ``` -------------------------------------------------------------------------------------------------------------------------------------------------- ### Install and Uninstall Apps ```bash helm install # Install the chart with a name helm install --namespace # Install the chart in a specific namespace helm install --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas) helm install --values # Install the chart with your specified values helm install --dry-run --debug # Run a test installation to validate chart (p) helm install --verify # Verify the package before using it helm install --dependency-update # update dependencies if they are missing before installing the chart helm uninstall # Uninstalls a release from the current (default) namespace helm uninstall --namespace # Uninstalls a release from the specified namespace ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### Perform App Upgrade and Rollback ```bash helm upgrade # Upgrade a release helm upgrade --rollback-on-failure # If set, upgrade process rolls back changes made in case of failed upgrade. helm upgrade --dependency-update # update dependencies if they are missing before installing the chart helm upgrade --version # specify a version constraint for the chart version to use helm upgrade --values # specify values in a YAML file or a URL (can specify multiple) helm upgrade --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate valuese) helm upgrade --force # Force resource updates through a replacement strategy helm rollback # Roll back a release to a specific revision helm rollback --cleanup-on-fail # Allow deletion of new resources created in this rollback when rollback fails ``` ------------------------------------------------------------------------------------------------------------------------------------------------ ### List, Add, Remove, and Update Repositories ```bash helm repo add # Add a repository from the internet: helm repo list # List added chart repositories helm repo update # Update information of available charts locally from chart repositories helm repo remove # Remove one or more chart repositories helm repo index # Read the current directory and generate an index file based on the charts found. helm repo index --merge # Merge the generated index with an existing index file helm search repo # Search repositories for a keyword in charts helm search hub # Search for charts in the Artifact Hub or your own hub instance ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Helm Release monitoring ```bash helm list # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified helm list --all # Show all releases without any filter applied, can use -a helm list --all-namespaces # List releases across all namespaces, we can use -A helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!=' helm list --date # Sort by release date helm list --deployed # Show deployed releases. If no other is specified, this will be automatically enabled helm list --pending # Show pending releases helm list --failed # Show failed releases helm list --uninstalled # Show uninstalled releases (if 'helm uninstall --keep-history' was used) helm list --superseded # Show superseded releases helm list -o yaml # Prints the output in the specified format. Allowed values: table, json, yaml (default table) helm status # This command shows the status of a named release. helm status --revision # if set, display the status of the named release with revision helm history # Historical revisions for a given release. helm env # Env prints out all the environment information in use by Helm. ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Download Release Information ```bash helm get all # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release. helm get hooks # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator. helm get manifest # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest. helm get notes # Shows notes provided by the chart of a named release. helm get values # Downloads a values file for a given release. use -o to format output ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ### Plugin Management ```bash helm plugin install # Install plugins helm plugin list # View a list of all installed plugins helm plugin update # Update plugins helm plugin uninstall # Uninstall a plugin ``` ------------------------------------------------------------------------------------------------------------------------------------------------- ================================================ FILE: versioned_docs/version-3/intro/index.mdx ================================================ --- title: Introduction sidebar_position: 1 --- # Introduction to Helm Are you new to Helm? This is the place to start! import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/intro/install.md ================================================ --- title: Installing Helm description: Learn how to install and get running with Helm. sidebar_position: 2 --- This guide shows how to install the Helm CLI. Helm can be installed either from source, or from pre-built binary releases. ## From The Helm Project The Helm project provides two ways to fetch and install Helm. These are the official methods to get Helm releases. In addition to that, the Helm community provides methods to install Helm through different package managers. Installation through those methods can be found below the official methods. ### From the Binary Releases Every [release](https://github.com/helm/helm/releases) of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed. 1. Download your [desired version](https://github.com/helm/helm/releases) 2. Unpack it (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`) 3. Find the `helm` binary in the unpacked directory, and move it to its desired destination (`mv linux-amd64/helm /usr/local/bin/helm`) From there, you should be able to run the client and [add the stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository): `helm help`. **Note:** Helm automated tests are performed for Linux AMD64 only during GitHub Actions builds and releases. Testing of other OSes are the responsibility of the community requesting Helm for the OS in question. ### From Script Helm now has an installer script that will automatically grab the latest version of Helm and [install it locally](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3). You can fetch that script, and then execute it locally. It's well documented so that you can read through it and understand what it is doing before you run it. ```console curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh ``` Yes, you can `curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` if you want to live on the edge. ## Through Package Managers The Helm community provides the ability to install Helm through operating system package managers. These are not supported by the Helm project and are not considered trusted 3rd parties. ### From Homebrew (macOS) Members of the Helm community have contributed a Helm formula build to Homebrew. This formula is generally up to date. ```console brew install helm ``` (Note: There is also a formula for emacs-helm, which is a different project.) ### From Chocolatey (Windows) Members of the Helm community have contributed a [Helm package](https://chocolatey.org/packages/kubernetes-helm) build to [Chocolatey](https://chocolatey.org/). This package is generally up to date. ```console choco install kubernetes-helm ``` ### From Scoop (Windows) Members of the Helm community have contributed a [Helm package](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) build to [Scoop](https://scoop.sh). This package is generally up to date. ```console scoop install helm ``` ### From Winget (Windows) Members of the Helm community have contributed a [Helm package](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) build to [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). This package is generally up to date. ```console winget install Helm.Helm ``` ### From Apt (Debian/Ubuntu) Members of the Helm community have contributed an Apt package for Debian/Ubuntu. This package is generally up to date. Thanks to [Buildkite](https://buildkite.com/organizations/helm-linux/packages/registries/helm-debian) for hosting the repo. ```console sudo apt-get install curl gpg apt-transport-https --yes curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` ### From dnf/yum (fedora) Since Fedora 35, Helm is available on the official repository. You can install Helm by invoking: ```console sudo dnf install helm ``` ### From Snap The [Snapcrafters](https://github.com/snapcrafters) community maintains the Snap version of the [Helm package](https://snapcraft.io/helm): ```console sudo snap install helm --classic ``` ### From pkg (FreeBSD) Members of the FreeBSD community have contributed a [Helm package](https://www.freshports.org/sysutils/helm) build to the [FreeBSD Ports Collection](https://man.freebsd.org/ports). This package is generally up to date. ```console pkg install helm ``` ### Development Builds In addition to releases you can download or install development snapshots of Helm. ### From Canary Builds "Canary" builds are versions of the Helm software that are built from the latest `main` branch. They are not official releases, and may not be stable. However, they offer the opportunity to test the cutting edge features. Canary Helm binaries are stored at `get.helm.sh`. Here are links to the common builds: - [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz) - [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz) - [Experimental Windows AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip) ### From Source (Linux, macOS) Building Helm from source is slightly more work, but is the best way to go if you want to test the latest (pre-release) Helm version. You must have a working Go environment. ```console $ git clone https://github.com/helm/helm.git $ cd helm $ make ``` If required, it will fetch the dependencies and cache them, and validate configuration. It will then compile `helm` and place it in `bin/helm`. ## Conclusion In most cases, installation is as simple as getting a pre-built `helm` binary. This document covers additional cases for those who want to do more sophisticated things with Helm. Once you have the Helm Client successfully installed, you can move on to using Helm to manage charts and [add the stable chart repository](/intro/quickstart.md#initialize-a-helm-chart-repository). ================================================ FILE: versioned_docs/version-3/intro/quickstart.md ================================================ --- title: Quickstart Guide description: How to install and get started with Helm including instructions for distros, FAQs, and plugins. sidebar_position: 1 --- This guide covers how you can quickly get started using Helm. ## Prerequisites The following prerequisites are required for a successful and properly secured use of Helm: 1. A Kubernetes cluster 2. Deciding what security configurations to apply to your installation, if any 3. Installing and configuring Helm. ### Install Kubernetes or have access to a cluster - You must have Kubernetes installed. For the latest release of Helm, we recommend the latest stable release of Kubernetes, which in most cases is the second-latest minor release. - You should also have a local configured copy of `kubectl`. See the [Helm Version Support Policy](https://helm.sh/docs/topics/version_skew/) for the maximum version skew supported between Helm and Kubernetes. ## Install Helm Download a binary release of the Helm client. You can use tools like `homebrew`, or look at [the official releases page](https://github.com/helm/helm/releases). For more details, or for other options, see [the installation guide](/intro/install.md). ## Initialize a Helm Chart Repository Once you have Helm ready, you can add a chart repository. Check [Artifact Hub](https://artifacthub.io/packages/search?kind=0) for available Helm chart repositories. ```console $ helm repo add bitnami https://charts.bitnami.com/bitnami ``` Once this is installed, you will be able to list the charts you can install: ```console $ helm search repo bitnami NAME CHART VERSION APP VERSION DESCRIPTION bitnami/bitnami-common 0.0.9 0.0.9 DEPRECATED Chart with custom templates used in ... bitnami/airflow 8.0.2 2.0.0 Apache Airflow is a platform to programmaticall... bitnami/apache 8.2.3 2.4.46 Chart for Apache HTTP Server bitnami/aspnet-core 1.2.3 3.1.9 ASP.NET Core is an open-source framework create... # ... and many more ``` ## Install an Example Chart To install a chart, you can run the `helm install` command. Helm has several ways to find and install a chart, but the easiest is to use the `bitnami` charts. ```console $ helm repo update # Make sure we get the latest list of charts $ helm install bitnami/mysql --generate-name NAME: mysql-1612624192 LAST DEPLOYED: Sat Feb 6 16:09:56 2021 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ... ``` In the example above, the `bitnami/mysql` chart was released, and the name of our new release is `mysql-1612624192`. You get a simple idea of the features of this MySQL chart by running `helm show chart bitnami/mysql`. Or you could run `helm show all bitnami/mysql` to get all information about the chart. Whenever you install a chart, a new release is created. So one chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded. The `helm install` command is a very powerful command with many capabilities. To learn more about it, check out the [Using Helm Guide](/intro/using_helm.md). ## Learn About Releases It's easy to see what has been released using Helm: ```console $ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION mysql-1612624192 default 1 2021-02-06 16:09:56.283059 +0100 CET deployed mysql-8.3.0 8.0.23 ``` The `helm list` (or `helm ls`) function will show you a list of all deployed releases. ## Uninstall a Release To uninstall a release, use the `helm uninstall` command: ```console $ helm uninstall mysql-1612624192 release "mysql-1612624192" uninstalled ``` This will uninstall `mysql-1612624192` from Kubernetes, which will remove all resources associated with the release as well as the release history. If the flag `--keep-history` is provided, release history will be kept. You will be able to request information about that release: ```console $ helm status mysql-1612624192 Status: UNINSTALLED ... ``` Because Helm tracks your releases even after you've uninstalled them, you can audit a cluster's history, and even undelete a release (with `helm rollback`). ## Reading the Help Text To learn more about the available Helm commands, use `helm help` or type a command followed by the `-h` flag: ```console $ helm get -h ``` ================================================ FILE: versioned_docs/version-3/intro/using_helm.md ================================================ --- title: Using Helm description: Explains the basics of Helm. sidebar_position: 3 --- This guide explains the basics of using Helm to manage packages on your Kubernetes cluster. It assumes that you have already [installed](/intro/install.md) the Helm client. If you are simply interested in running a few quick commands, you may wish to begin with the [Quickstart Guide](/intro/quickstart.md). This chapter covers the particulars of Helm commands, and explains how to use Helm. ## Three Big Concepts A *Chart* is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file. A *Repository* is the place where charts can be collected and shared. It's like Perl's [CPAN archive](https://www.cpan.org) or the [Fedora Package Database](https://src.fedoraproject.org/), but for Kubernetes packages. A *Release* is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new _release_ is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own _release_, which will in turn have its own _release name_. With these concepts in mind, we can now explain Helm like this: Helm installs _charts_ into Kubernetes, creating a new _release_ for each installation. And to find new charts, you can search Helm chart _repositories_. ## 'helm search': Finding Charts Helm comes with a powerful search command. It can be used to search two different types of source: - `helm search hub` searches [the Artifact Hub](https://artifacthub.io), which lists helm charts from dozens of different repositories. - `helm search repo` searches the repositories that you have added to your local helm client (with `helm repo add`). This search is done over local data, and no public network connection is needed. You can find publicly available charts by running `helm search hub`: ```console $ helm search hub wordpress URL CHART VERSION APP VERSION DESCRIPTION https://hub.helm.sh/charts/bitnami/wordpress 7.6.7 5.2.4 Web publishing platform for building blogs and ... https://hub.helm.sh/charts/presslabs/wordpress-... v0.6.3 v0.6.3 Presslabs WordPress Operator Helm Chart https://hub.helm.sh/charts/presslabs/wordpress-... v0.7.1 v0.7.1 A Helm chart for deploying a WordPress site on ... ``` The above searches for all `wordpress` charts on Artifact Hub. With no filter, `helm search hub` shows you all of the available charts. `helm search hub` exposes the URL to the location on [artifacthub.io](https://artifacthub.io/) but not the actual Helm repo. `helm search hub --list-repo-url` exposes the actual Helm repo URL which comes in handy when you are looking to add a new repo: `helm repo add [NAME] [URL]`. Using `helm search repo`, you can find the names of the charts in repositories you have already added: ```console $ helm repo add brigade https://brigadecore.github.io/charts "brigade" has been added to your repositories $ helm search repo brigade NAME CHART VERSION APP VERSION DESCRIPTION brigade/brigade 1.3.2 v1.2.1 Brigade provides event-driven scripting of Kube... brigade/brigade-github-app 0.4.1 v0.2.1 The Brigade GitHub App, an advanced gateway for... brigade/brigade-github-oauth 0.2.0 v0.20.0 The legacy OAuth GitHub Gateway for Brigade brigade/brigade-k8s-gateway 0.1.0 A Helm chart for Kubernetes brigade/brigade-project 1.0.0 v1.0.0 Create a Brigade project brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Helm search uses a fuzzy string matching algorithm, so you can type parts of words or phrases: ```console $ helm search repo kash NAME CHART VERSION APP VERSION DESCRIPTION brigade/kashti 0.4.0 v0.4.0 A Helm chart for Kubernetes ``` Search is a good way to find available packages. Once you have found a package you want to install, you can use `helm install` to install it. ## 'helm install': Installing a Package To install a new package, use the `helm install` command. At its simplest, it takes two arguments: A release name that you pick, and the name of the chart you want to install. ```console $ helm install happy-panda bitnami/wordpress NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` Now the `wordpress` chart is installed. Note that installing a chart creates a new _release_ object. The release above is named `happy-panda`. (If you want Helm to generate a name for you, leave off the release name and use `--generate-name`.) During installation, the `helm` client will print useful information about which resources were created, what the state of the release is, and also whether there are additional configuration steps you can or should take. Helm installs resources in the following order: - Namespace - NetworkPolicy - ResourceQuota - LimitRange - PodSecurityPolicy - PodDisruptionBudget - ServiceAccount - Secret - SecretList - ConfigMap - StorageClass - PersistentVolume - PersistentVolumeClaim - CustomResourceDefinition - ClusterRole - ClusterRoleList - ClusterRoleBinding - ClusterRoleBindingList - Role - RoleList - RoleBinding - RoleBindingList - Service - DaemonSet - Pod - ReplicationController - ReplicaSet - Deployment - HorizontalPodAutoscaler - StatefulSet - Job - CronJob - Ingress - APIService - MutatingWebhookConfiguration - ValidatingWebhookConfiguration Helm does not wait until all of the resources are running before it exits. Many charts require Docker images that are over 600MB in size, and may take a long time to install into the cluster. To keep track of a release's state, or to re-read configuration information, you can use `helm status`: ```console $ helm status happy-panda NAME: happy-panda LAST DEPLOYED: Tue Jan 26 10:27:17 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ** Please be patient while the chart is being deployed ** Your WordPress site can be accessed through the following DNS name from within your cluster: happy-panda-wordpress.default.svc.cluster.local (port 80) To access your WordPress site from outside the cluster follow the steps below: 1. Get the WordPress URL by running these commands: NOTE: It may take a few minutes for the LoadBalancer IP to be available. Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress' export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}") echo "WordPress URL: http://$SERVICE_IP/" echo "WordPress Admin URL: http://$SERVICE_IP/admin" 2. Open a browser and access WordPress using the obtained URL. 3. Login with the following credentials below to see your blog: echo Username: user echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) ``` The above shows the current state of your release. ### Customizing the Chart Before Installing Installing the way we have here will only use the default configuration options for this chart. Many times, you will want to customize the chart to use your preferred configuration. To see what options are configurable on a chart, use `helm show values`: ```console $ helm show values bitnami/wordpress ## Global Docker image parameters ## Please, note that this will override the image parameters, including dependencies, configured to use the global value ## Current available global Docker image parameters: imageRegistry and imagePullSecrets ## # global: # imageRegistry: myRegistryName # imagePullSecrets: # - myRegistryKeySecretName # storageClass: myStorageClass ## Bitnami WordPress image version ## ref: https://hub.docker.com/r/bitnami/wordpress/tags/ ## image: registry: docker.io repository: bitnami/wordpress tag: 5.6.0-debian-10-r35 [..] ``` You can then override any of these settings in a YAML formatted file, and then pass that file during installation. ```console $ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml $ helm install -f values.yaml bitnami/wordpress --generate-name ``` The above will create a default MariaDB user with the name `user0`, and grant this user access to a newly created `user0db` database, but will accept all the rest of the defaults for that chart. There are two ways to pass configuration data during install: - `--values` (or `-f`): Specify a YAML file with overrides. This can be specified multiple times and the rightmost file will take precedence - `--set`: Specify overrides on the command line. If both are used, `--set` values are merged into `--values` with higher precedence. Overrides specified with `--set` are persisted in a Secret. Values that have been `--set` can be viewed for a given release with `helm get values `. Values that have been `--set` can be cleared by running `helm upgrade` with `--reset-values` specified. #### The Format and Limitations of `--set` The `--set` option takes zero or more name/value pairs. At its simplest, it is used like this: `--set name=value`. The YAML equivalent of that is: ```yaml name: value ``` Multiple values are separated by `,` characters. So `--set a=b,c=d` becomes: ```yaml a: b c: d ``` More complex expressions are supported. For example, `--set outer.inner=value` is translated into this: ```yaml outer: inner: value ``` Lists can be expressed by enclosing values in `{` and `}`. For example, `--set name={a, b, c}` translates to: ```yaml name: - a - b - c ``` Certain name/key can be set to be `null` or to be an empty array `[]`. For example, `--set name=[],a=null` translates ```yaml name: - a - b - c a: b ``` to ```yaml name: [] a: null ``` As of Helm 2.5.0, it is possible to access list items using an array index syntax. For example, `--set servers[0].port=80` becomes: ```yaml servers: - port: 80 ``` Multiple values can be set this way. The line `--set servers[0].port=80,servers[0].host=example` becomes: ```yaml servers: - port: 80 host: example ``` Sometimes you need to use special characters in your `--set` lines. You can use a backslash to escape the characters; `--set name=value1\,value2` will become: ```yaml name: "value1,value2" ``` Similarly, you can escape dot sequences as well, which may come in handy when charts use the `toYaml` function to parse annotations, labels and node selectors. The syntax for `--set nodeSelector."kubernetes\.io/role"=master` becomes: ```yaml nodeSelector: kubernetes.io/role: master ``` Deeply nested data structures can be difficult to express using `--set`. Chart designers are encouraged to consider the `--set` usage when designing the format of a `values.yaml` file (read more about [Values Files](/chart_template_guide/values_files.md)). ### More Installation Methods The `helm install` command can install from several sources: - A chart repository (as we've seen above) - A local chart archive (`helm install foo foo-0.1.1.tgz`) - An unpacked chart directory (`helm install foo path/to/foo`) - A full URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`) ## 'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure When a new version of a chart is released, or when you want to change the configuration of your release, you can use the `helm upgrade` command. An upgrade takes an existing release and upgrades it according to the information you provide. Because Kubernetes charts can be large and complex, Helm tries to perform the least invasive upgrade. It will only update things that have changed since the last release. ```console $ helm upgrade -f panda.yaml happy-panda bitnami/wordpress ``` In the above case, the `happy-panda` release is upgraded with the same chart, but with a new YAML file: ```yaml mariadb.auth.username: user1 ``` We can use `helm get values` to see whether that new setting took effect. ```console $ helm get values happy-panda mariadb: auth: username: user1 ``` The `helm get` command is a useful tool for looking at a release in the cluster. And as we can see above, it shows that our new values from `panda.yaml` were deployed to the cluster. Now, if something does not go as planned during a release, it is easy to roll back to a previous release using `helm rollback [RELEASE] [REVISION]`. ```console $ helm rollback happy-panda 1 ``` The above rolls back our happy-panda to its very first release version. A release version is an incremental revision. Every time an install, upgrade, or rollback happens, the revision number is incremented by 1. The first revision number is always 1. And we can use `helm history [RELEASE]` to see revision numbers for a certain release. ## Helpful Options for Install/Upgrade/Rollback There are several other helpful options you can specify for customizing the behavior of Helm during an install/upgrade/rollback. Please note that this is not a full list of cli flags. To see a description of all flags, just run `helm --help`. - `--timeout`: A [Go duration](https://golang.org/pkg/time/#ParseDuration) value to wait for Kubernetes commands to complete. This defaults to `5m0s`. - `--wait`: Waits until all Pods are in a ready state, PVCs are bound, Deployments have minimum (`Desired` minus `maxUnavailable`) Pods in ready state and Services have an IP address (and Ingress if a `LoadBalancer`) before marking the release as successful. It will wait for as long as the `--timeout` value. If timeout is reached, the release will be marked as `FAILED`. Note: In scenarios where Deployment has `replicas` set to 1 and `maxUnavailable` is not set to 0 as part of rolling update strategy, `--wait` will return as ready as it has satisfied the minimum Pod in ready condition. - `--no-hooks`: This skips running hooks for the command - `--recreate-pods` (only available for `upgrade` and `rollback`): This flag will cause all pods to be recreated (with the exception of pods belonging to deployments). (DEPRECATED in Helm 3) ## 'helm uninstall': Uninstalling a Release When it is time to uninstall a release from the cluster, use the `helm uninstall` command: ```console $ helm uninstall happy-panda ``` This will remove the release from the cluster. You can see all of your currently deployed releases with the `helm list` command: ```console $ helm list NAME VERSION UPDATED STATUS CHART inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 ``` From the output above, we can see that the `happy-panda` release was uninstalled. In previous versions of Helm, when a release was deleted, a record of its deletion would remain. In Helm 3, deletion removes the release record as well. If you wish to keep a deletion release record, use `helm uninstall --keep-history`. Using `helm list --uninstalled` will only show releases that were uninstalled with the `--keep-history` flag. The `helm list --all` flag will show you all release records that Helm has retained, including records for failed or deleted items (if `--keep-history` was specified): ```console $ helm list --all NAME VERSION UPDATED STATUS CHART happy-panda 2 Wed Sep 28 12:47:54 2016 UNINSTALLED wordpress-10.4.5.6.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 kindred-angelf 2 Tue Sep 27 16:16:10 2016 UNINSTALLED alpine-0.1.0 ``` Note that because releases are now deleted by default, it is no longer possible to rollback an uninstalled resource. ## 'helm repo': Working with Repositories Helm 3 no longer ships with a default chart repository. The `helm repo` command group provides commands to add, list, and remove repositories. You can see which repositories are configured using `helm repo list`: ```console $ helm repo list NAME URL stable https://charts.helm.sh/stable mumoshu https://mumoshu.github.io/charts ``` And new repositories can be added with `helm repo add [NAME] [URL]`: ```console $ helm repo add dev https://example.com/dev-charts ``` Because chart repositories change frequently, at any point you can make sure your Helm client is up to date by running `helm repo update`. Repositories can be removed with `helm repo remove`. ## Creating Your Own Charts The [Chart Development Guide](/topics/charts.md) explains how to develop your own charts. But you can get started quickly by using the `helm create` command: ```console $ helm create deis-workflow Creating deis-workflow ``` Now there is a chart in `./deis-workflow`. You can edit it and create your own templates. As you edit your chart, you can validate that it is well-formed by running `helm lint`. When it's time to package the chart up for distribution, you can run the `helm package` command: ```console $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` And that chart can now easily be installed by `helm install`: ```console $ helm install deis-workflow ./deis-workflow-0.1.0.tgz ... ``` Charts that are packaged can be loaded into chart repositories. See the documentation for [Helm chart repositories](/topics/chart_repository.md) for more details. ## Conclusion This chapter has covered the basic usage patterns of the `helm` client, including searching, installation, upgrading, and uninstalling. It has also covered useful utility commands like `helm status`, `helm get`, and `helm repo`. For more information on these commands, take a look at Helm's built-in help: `helm help`. In the [next chapter](/howto/charts_tips_and_tricks.md), we look at the process of developing charts. ================================================ FILE: versioned_docs/version-3/sdk/_install.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runInstall(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } installClient := action.NewInstall(actionConfig) installClient.DryRunOption = "none" installClient.ReleaseName = releaseName installClient.Namespace = settings.Namespace() installClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, installClient.CertFile, installClient.KeyFile, installClient.CaFile, installClient.InsecureSkipTLSverify, installClient.PlainHTTP) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } installClient.SetRegistryClient(registryClient) chartPath, err := installClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) chart, err := loader.Load(chartPath) if err != nil { return err } // Check chart dependencies to make sure all are present in /charts if chartDependencies := chart.Metadata.Dependencies; chartDependencies != nil { if err := action.CheckDependencies(chart, chartDependencies); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !installClient.DependencyUpdate { return err } manager := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: installClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, RegistryClient: installClient.GetRegistryClient(), } if err := manager.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := installClient.RunWithContext(ctx, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run install: %w", err) } logger.Printf("release created:\n%+v", *release) return nil } ``` ================================================ FILE: versioned_docs/version-3/sdk/_list.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runList(logger *log.Logger, settings *cli.EnvSettings) error { actionConfig, err := initActionConfigList(settings, logger, false) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } listClient := action.NewList(actionConfig) // Only list deployed //listClient.Deployed = true listClient.All = true listClient.SetStateMask() results, err := listClient.Run() if err != nil { return fmt.Errorf("failed to run list action: %w", err) } for _, rel := range results { logger.Printf("list result: %+v", rel) } return nil } ``` ================================================ FILE: versioned_docs/version-3/sdk/_main.mdx ================================================ ```go package main import ( "bufio" "context" "fmt" "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/registry" ) var helmDriver string = os.Getenv("HELM_DRIVER") func initActionConfig(settings *cli.EnvSettings, logger *log.Logger) (*action.Configuration, error) { return initActionConfigList(settings, logger, false) } func initActionConfigList(settings *cli.EnvSettings, logger *log.Logger, allNamespaces bool) (*action.Configuration, error) { actionConfig := new(action.Configuration) namespace := func() string { // For list action, you can pass an empty string instead of settings.Namespace() to list // all namespaces if allNamespaces { return "" } return settings.Namespace() }() if err := actionConfig.Init( settings.RESTClientGetter(), namespace, helmDriver, logger.Printf); err != nil { return nil, err } return actionConfig, nil } func newRegistryClient(settings *cli.EnvSettings, plainHTTP bool) (*registry.Client, error) { opts := []registry.ClientOption{ registry.ClientOptDebug(settings.Debug), registry.ClientOptEnableCache(true), registry.ClientOptWriter(os.Stderr), registry.ClientOptCredentialsFile(settings.RegistryConfig), } if plainHTTP { opts = append(opts, registry.ClientOptPlainHTTP()) } // Create a new registry client registryClient, err := registry.NewClient(opts...) if err != nil { return nil, err } return registryClient, nil } func newRegistryClientTLS(settings *cli.EnvSettings, logger *log.Logger, certFile, keyFile, caFile string, insecureSkipTLSverify, plainHTTP bool) (*registry.Client, error) { if certFile != "" && keyFile != "" || caFile != "" || insecureSkipTLSverify { registryClient, err := registry.NewRegistryClientWithTLS( logger.Writer(), certFile, keyFile, caFile, insecureSkipTLSverify, settings.RegistryConfig, settings.Debug) if err != nil { return nil, err } return registryClient, nil } registryClient, err := newRegistryClient(settings, plainHTTP) if err != nil { return nil, err } return registryClient, nil } func main() { logger := log.Default() // For convenience, initialize SDK setting via CLI mechanism settings := cli.New() // Release name, chart and values releaseName := "helm-sdk-example" chartRef := "oci://ghcr.io/stefanprodan/charts/podinfo" releaseValues := map[string]interface{}{ "replicaCount": "2", } // Pull the chart to the local filesystem if err := runPull(logger, settings, chartRef, "6.4.1"); err != nil { fmt.Printf("failed to run pull: %+v", err) os.Exit(1) } // Install the chart (from the pulled chart local archive) if err := runInstall(context.TODO(), logger, settings, releaseName, "./podinfo-6.4.1.tgz", "", releaseValues); err != nil { fmt.Printf("failed to run install: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart installed. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Upgrade to version 6.5.4, updating the replicaCount to three releaseValues["replicaCount"] = "3" if err := runUpgrade(context.TODO(), logger, settings, releaseName, chartRef, "6.5.4", releaseValues); err != nil { fmt.Printf("failed to run upgrade: %+v", err) os.Exit(1) } // List installed charts if err := runList(logger, settings); err != nil { fmt.Printf("failed to run list: %+v", err) os.Exit(1) } // fmt.Print("Chart upgraded. Press 'Return' to continue...") bufio.NewReader(os.Stdin).ReadBytes('\n') // Uninstall the chart if err := runUninstall(logger, settings, releaseName); err != nil { fmt.Printf("failed to run uninstall: %+v", err) os.Exit(1) } } ``` ================================================ FILE: versioned_docs/version-3/sdk/_pull.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runPull(logger *log.Logger, settings *cli.EnvSettings, chartRef, chartVersion string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } registryClient, err := newRegistryClient(settings, false) if err != nil { return fmt.Errorf("failed to created registry client: %w", err) } actionConfig.RegistryClient = registryClient pullClient := action.NewPullWithOpts( action.WithConfig(actionConfig)) // client.RepoURL = "" pullClient.DestDir = "./" pullClient.Settings = settings pullClient.Version = chartVersion result, err := pullClient.Run(chartRef) if err != nil { return fmt.Errorf("failed to pull chart: %w", err) } logger.Printf("%+v", result) return nil } ``` ================================================ FILE: versioned_docs/version-3/sdk/_uninstall.mdx ================================================ ```go package main import ( "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func runUninstall(logger *log.Logger, settings *cli.EnvSettings, releaseName string) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } uninstallClient := action.NewUninstall(actionConfig) uninstallClient.DeletionPropagation = "foreground" // "background" or "orphan" result, err := uninstallClient.Run(releaseName) if err != nil { return fmt.Errorf("failed to run uninstall action: %w", err) } if result != nil { logger.Printf("result: %+v\n", *result.Release) } logger.Printf("release \"%s\" uninstalled\n", releaseName) return nil } ``` ================================================ FILE: versioned_docs/version-3/sdk/_upgrade.mdx ================================================ ```go package main import ( "context" "fmt" "log" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/chart/loader" "helm.sh/helm/v3/pkg/cli" "helm.sh/helm/v3/pkg/downloader" "helm.sh/helm/v3/pkg/getter" ) func runUpgrade(ctx context.Context, logger *log.Logger, settings *cli.EnvSettings, releaseName string, chartRef string, chartVersion string, releaseValues map[string]interface{}) error { actionConfig, err := initActionConfig(settings, logger) if err != nil { return fmt.Errorf("failed to init action config: %w", err) } upgradeClient := action.NewUpgrade(actionConfig) upgradeClient.Namespace = settings.Namespace() upgradeClient.DryRunOption = "none" upgradeClient.Version = chartVersion registryClient, err := newRegistryClientTLS( settings, logger, upgradeClient.CertFile, upgradeClient.KeyFile, upgradeClient.CaFile, upgradeClient.InsecureSkipTLSverify, upgradeClient.PlainHTTP) if err != nil { return fmt.Errorf("missing registry client: %w", err) } upgradeClient.SetRegistryClient(registryClient) chartPath, err := upgradeClient.ChartPathOptions.LocateChart(chartRef, settings) if err != nil { return err } providers := getter.All(settings) // Check chart dependencies to make sure all are present in /charts chart, err := loader.Load(chartPath) if err != nil { return fmt.Errorf("failed to load chart: %w", err) } if req := chart.Metadata.Dependencies; req != nil { if err := action.CheckDependencies(chart, req); err != nil { err = fmt.Errorf("failed to check chart dependencies: %w", err) if !upgradeClient.DependencyUpdate { return err } man := &downloader.Manager{ Out: logger.Writer(), ChartPath: chartPath, Keyring: upgradeClient.ChartPathOptions.Keyring, SkipUpdate: false, Getters: providers, RepositoryConfig: settings.RepositoryConfig, RepositoryCache: settings.RepositoryCache, Debug: settings.Debug, } if err := man.Update(); err != nil { return err } // Reload the chart with the updated Chart.lock file. if chart, err = loader.Load(chartPath); err != nil { return fmt.Errorf("failed to reload chart after repo update: %w", err) } } } release, err := upgradeClient.RunWithContext(ctx, releaseName, chart, releaseValues) if err != nil { return fmt.Errorf("failed to run upgrade action: %w", err) } logger.Printf("release: %+v", release) return nil } ``` ================================================ FILE: versioned_docs/version-3/sdk/examples.mdx ================================================ --- title: Examples description: Examples various features if the Helm SDK sidebar_position: 2 --- import Install from './_install.mdx' import List from './_list.mdx' import Main from './_main.mdx' import Pull from './_pull.mdx' import Uninstall from './_uninstall.mdx' import Upgrade from './_upgrade.mdx' This document runs though a series of examples of using the Helm SDK. Intended to document various SDK functionalities. The final example shows `main.go` driver ([link](#driver)). That runs the below actions and includes necessary helper functions. The code for the examples lives in the [helm/helm-www/sdkexamples/](https://github.com/helm/helm-www/tree/main/sdkexamples) directory. And is intended to be fully functional. ## Actions ### Install Action This example installs the given chart/release, for the given version and values: ### Upgrade Action This example upgrades the given release, with the given chart, version and values: ### Uninstall Action This example uninstalls the given release ### List Action This example lists all released charts (in the currently configured namespace) ### Pull Action This example pulls a chart from an OCI repository ## Driver The driver here shows the necessary auxiliary functions needed for the Helm SDK actions to function. And shows the above examples in action, to pull, install, update, and uninstall the 'podinfo' chart from an OCI repository.
    ================================================ FILE: versioned_docs/version-3/sdk/gosdk.md ================================================ --- title: Introduction description: Introduces the Helm Go SDK sidebar_position: 1 --- Helm's Go SDK enables custom software to leverage Helm charts and Helm's functionality for managing Kubernetes software deployment (In fact, the Helm CLI is effectively just one such tool!) Currently, the SDK has been functionally separated from the Helm CLI. And the SDK can (and is) used by standalone tooling. The Helm project has committed to API stability for the SDK. As a warning, the SDK has some rough edges remaining from the initial work to separate the CLI and the SDK. Which the Helm project aims to improve and over time. Full API documentation can be found at [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3). A brief overview of some of the main types of packages and a simple example follows below. See the [Examples](/sdk/examples.mdx) section for more examples and a more full featured 'driver'. ## Main package overview - [pkg/action](https://pkg.go.dev/helm.sh/helm/v3/pkg/action): Contains the main “client” for performing Helm actions. This is the same package that the CLI is using underneath the hood. If you just need to perform basic Helm commands from another Go program, this package is for you - [pkg/chart](https://pkg.go.dev/helm.sh/helm/v3/pkg/chart), [pkg/chartutil](https://pkg.go.dev/helm.sh/helm/v3/pkg/chartutil): Methods and helpers used for loading and manipulating charts - [pkg/cli](https://pkg.go.dev/helm.sh/helm/v3/pkg/cli) and its subpackages: Contains all the handlers for the standard Helm environment variables and its subpackages contain output and values file handling - [pkg/release](https://pkg.go.dev/helm.sh/helm/v3/pkg/release): Defines the `Release` object and statuses There are many more packages besides these, so go check out the documentation for more information! ### Simple example This is a simple example of doing a `helm list` using the Go SDK. See the [Examples](/sdk/examples.mdx) section for more full featured examples. ```go package main import ( "log" "os" "helm.sh/helm/v3/pkg/action" "helm.sh/helm/v3/pkg/cli" ) func main() { settings := cli.New() actionConfig := new(action.Configuration) // You can pass an empty string instead of settings.Namespace() to list // all namespaces if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil { log.Printf("%+v", err) os.Exit(1) } client := action.NewList(actionConfig) // Only list deployed client.Deployed = true results, err := client.Run() if err != nil { log.Printf("%+v", err) os.Exit(1) } for _, rel := range results { log.Printf("%+v", rel) } } ``` ## Compatibility The Helm SDK explicitly follows the Helm backwards compatibility guarantees: That is, break changes will only be made over major versions. ================================================ FILE: versioned_docs/version-3/sdk/index.mdx ================================================ --- title: Go SDK sidebar_position: 7 --- import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/topics/advanced.md ================================================ --- title: Advanced Helm Techniques description: Explains various advanced features for Helm power users sidebar_position: 9 --- This section explains various advanced features and techniques for using Helm. The information in this section is intended for "power users" of Helm that wish to do advanced customization and manipulation of their charts and releases. Each of these advanced features comes with their own tradeoffs and caveats, so each one must be used carefully and with deep knowledge of Helm. Or in other words, remember the [Peter Parker principle](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility) ## Post Rendering Post rendering gives chart installers the ability to manually manipulate, configure, and/or validate rendered manifests before they are installed by Helm. This allows users with advanced configuration needs to be able to use tools like [`kustomize`](https://kustomize.io) to apply configuration changes without the need to fork a public chart or requiring chart maintainers to specify every last configuration option for a piece of software. There are also use cases for injecting common tools and side cars in enterprise environments or analysis of the manifests before deployment. ### Prerequisites - Helm 3.1+ ### Usage A post-renderer can be any executable that accepts rendered Kubernetes manifests on STDIN and returns valid Kubernetes manifests on STDOUT. It should return an non-0 exit code in the event of a failure. This is the only "API" between the two components. It allows for great flexibility in what you can do with your post-render process. A post renderer can be used with `install`, `upgrade`, and `template`. To use a post-renderer, use the `--post-renderer` flag with a path to the renderer executable you wish to use: ```shell $ helm install mychart stable/wordpress --post-renderer ./path/to/executable ``` If the path does not contain any separators, it will search in $PATH, otherwise it will resolve any relative paths to a fully qualified path If you wish to use multiple post-renderers, call all of them in a script or together in whatever binary tool you have built. In bash, this would be as simple as `renderer1 | renderer2 | renderer3`. You can see an example of using `kustomize` as a post renderer [here](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render). ### Caveats When using post renderers, there are several important things to keep in mind. The most important of these is that when using a post-renderer, all people modifying that release **MUST** use the same renderer in order to have repeatable builds. This feature is purposefully built to allow any user to switch out which renderer they are using or to stop using a renderer, but this should be done deliberately to avoid accidental modification or data loss. One other important note is around security. If you are using a post-renderer, you should ensure it is coming from a reliable source (as is the case for any other arbitrary executable). Using non-trusted or non-verified renderers is NOT recommended as they have full access to rendered templates, which often contain secret data. ### Custom Post Renderers The post render step offers even more flexibility when used in the Go SDK. Any post renderer only needs to implement the following Go interface: ```go type PostRenderer interface { // Run expects a single buffer filled with Helm rendered manifests. It // expects the modified results to be returned on a separate buffer or an // error if there was an issue or failure while running the post render step Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error) } ``` For more information on using the Go SDK, See the [Go SDK section](#go-sdk) ## Go SDK Helm 3 debuted a completely restructured Go SDK for a better experience when building software and tools that leverage Helm. Full documentation can be found in the [Go SDK Section](/sdk/gosdk.md). ## Storage backends Helm 3 changed the default release information storage to Secrets in the namespace of the release. Helm 2 by default stores release information as ConfigMaps in the namespace of the Tiller instance. The subsections which follow show how to configure different backends. This configuration is based on the `HELM_DRIVER` environment variable. It can be set to one of the values: `[configmap, secret, sql]`. ### ConfigMap storage backend To enable the ConfigMap backend, you'll need to set the environmental variable `HELM_DRIVER` to `configmap`. You can set it in a shell as follows: ```shell export HELM_DRIVER=configmap ``` If you want to switch from the default backend to the ConfigMap backend, you'll have to do the migration for this on your own. You can retrieve release information with the following command: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` **PRODUCTION NOTES**: The release information includes the contents of charts and values files, and therefore might contain sensitive data (like passwords, private keys, and other credentials) that needs to be protected from unauthorized access. When managing Kubernetes authorization, for instance with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), it is possible to grant broader access to ConfigMap resources, while restricting access to Secret resources. For instance, the default [user-facing role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) "view" grants access to most resources, but not to Secrets. Furthermore, secrets data can be configured for [encrypted storage](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/). Please keep that in mind if you decide to switch to the ConfigMap backend, as it could expose your application's sensitive data. ### SQL storage backend There is a ***beta*** SQL storage backend that stores release information in an SQL database. Using such a storage backend is particularly useful if your release information weighs more than 1MB (in which case, it can't be stored in ConfigMaps/Secrets because of internal limits in Kubernetes' underlying etcd key-value store). To enable the SQL backend, you'll need to deploy a SQL database and set the environmental variable `HELM_DRIVER` to `sql`. The DB details are set with the environmental variable `HELM_DRIVER_SQL_CONNECTION_STRING`. You can set it in a shell as follows: ```shell export HELM_DRIVER=sql export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme ``` > Note: Only PostgreSQL is supported at this moment. **PRODUCTION NOTES**: It is recommended to: - Make your database production ready. For PostgreSQL, refer to the [Server Administration](https://www.postgresql.org/docs/12/admin.html) docs for more details - Enable [permission management](/topics/permissions_sql_storage_backend.md) to mirror Kubernetes RBAC for release information If you want to switch from the default backend to the SQL backend, you'll have to do the migration for this on your own. You can retrieve release information with the following command: ```shell kubectl get secret --all-namespaces -l "owner=helm" ``` ================================================ FILE: versioned_docs/version-3/topics/architecture.md ================================================ --- title: Helm Architecture description: Describes the Helm architecture at a high level. sidebar_position: 8 --- # Helm Architecture This document describes the Helm architecture at a high level. ## The Purpose of Helm Helm is a tool for managing Kubernetes packages called _charts_. Helm can do the following: - Create new charts from scratch - Package charts into chart archive (tgz) files - Interact with chart repositories where charts are stored - Install and uninstall charts into an existing Kubernetes cluster - Manage the release cycle of charts that have been installed with Helm For Helm, there are three important concepts: 1. The _chart_ is a bundle of information necessary to create an instance of a Kubernetes application. 2. The _config_ contains configuration information that can be merged into a packaged chart to create a releasable object. 3. A _release_ is a running instance of a _chart_, combined with a specific _config_. ## Components Helm is an executable which is implemented into two distinct parts: **The Helm Client** is a command-line client for end users. The client is responsible for the following: - Local chart development - Managing repositories - Managing releases - Interfacing with the Helm library - Sending charts to be installed - Requesting upgrading or uninstalling of existing releases **The Helm Library** provides the logic for executing all Helm operations. It interfaces with the Kubernetes API server and provides the following capability: - Combining a chart and configuration to build a release - Installing charts into Kubernetes, and providing the subsequent release object - Upgrading and uninstalling charts by interacting with Kubernetes The standalone Helm library encapsulates the Helm logic so that it can be leveraged by different clients. ## Implementation The Helm client and library is written in the Go programming language. The library uses the Kubernetes client library to communicate with Kubernetes. Currently, that library uses REST+JSON. It stores information in Secrets located inside of Kubernetes. It does not need its own database. Configuration files are, when possible, written in YAML. ================================================ FILE: versioned_docs/version-3/topics/chart_repository.md ================================================ --- title: The Chart Repository Guide description: How to create and work with Helm chart repositories. sidebar_position: 6 --- This section explains how to create and work with Helm chart repositories. At a high level, a chart repository is a location where packaged charts can be stored and shared. The distributed community Helm chart repository is located at [Artifact Hub](https://artifacthub.io/packages/search?kind=0) and welcomes participation. But Helm also makes it possible to create and run your own chart repository. This guide explains how to do so. If you are considering creating a chart repository, you may want to consider using an [OCI registry](/topics/registries.md) instead. ## Prerequisites * Go through the [Quickstart](/intro/quickstart.md) Guide * Read through the [Charts](/topics/charts.md) document ## Create a chart repository A _chart repository_ is an HTTP server that houses an `index.yaml` file and optionally some packaged charts. When you're ready to share your charts, the preferred way to do so is by uploading them to a chart repository. As of Helm 2.2.0, client-side SSL auth to a repository is supported. Other authentication protocols may be available as plugins. Because a chart repository can be any HTTP server that can serve YAML and tar files and can answer GET requests, you have a plethora of options when it comes down to hosting your own chart repository. For example, you can use a Google Cloud Storage (GCS) bucket, Amazon S3 bucket, GitHub Pages, or even create your own web server. ### The chart repository structure A chart repository consists of packaged charts and a special file called `index.yaml` which contains an index of all of the charts in the repository. Frequently, the charts that `index.yaml` describes are also hosted on the same server, as are the [provenance files](/topics/provenance.md). For example, the layout of the repository `https://example.com/charts` might look like this: ``` charts/ | |- index.yaml | |- alpine-0.1.2.tgz | |- alpine-0.1.2.tgz.prov ``` In this case, the index file would contain information about one chart, the Alpine chart, and provide the download URL `https://example.com/charts/alpine-0.1.2.tgz` for that chart. It is not required that a chart package be located on the same server as the `index.yaml` file. However, doing so is often the easiest. ### The index file The index file is a yaml file called `index.yaml`. It contains some metadata about the package, including the contents of a chart's `Chart.yaml` file. A valid chart repository must have an index file. The index file contains information about each chart in the chart repository. The `helm repo index` command will generate an index file based on a given local directory that contains packaged charts. This is an example of an index file: ```yaml apiVersion: v1 entries: alpine: - created: 2016-10-06T16:23:20.499814565-06:00 description: Deploy a basic Alpine Linux pod digest: 99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.2.0.tgz version: 0.2.0 - created: 2016-10-06T16:23:20.499543808-06:00 description: Deploy a basic Alpine Linux pod digest: 515c58e5f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cd78727 home: https://helm.sh/helm name: alpine sources: - https://github.com/helm/helm urls: - https://technosophos.github.io/tscharts/alpine-0.1.0.tgz version: 0.1.0 nginx: - created: 2016-10-06T16:23:20.499543808-06:00 description: Create a basic nginx HTTP server digest: aaff4545f79d8b2913a10cb400ebb6fa9c77fe813287afbacf1a0b897cdffffff home: https://helm.sh/helm name: nginx sources: - https://github.com/helm/charts urls: - https://technosophos.github.io/tscharts/nginx-1.1.0.tgz version: 1.1.0 generated: 2016-10-06T16:23:20.499029981-06:00 ``` ## Hosting Chart Repositories This part shows several ways to serve a chart repository. ### Google Cloud Storage The first step is to **create your GCS bucket**. We'll call ours `fantastic-charts`. ![Create a GCS Bucket](/img/helm2/create-a-bucket.png) Next, make your bucket public by **editing the bucket permissions**. ![Edit Permissions](/img/helm2/edit-permissions.png) Insert this line item to **make your bucket public**: ![Make Bucket Public](/img/helm2/make-bucket-public.png) Congratulations, now you have an empty GCS bucket ready to serve charts! You may upload your chart repository using the Google Cloud Storage command line tool, or using the GCS web UI. A public GCS bucket can be accessed via simple HTTPS at this address: `https://bucket-name.storage.googleapis.com/`. ### Cloudsmith You can also set up chart repositories using Cloudsmith. Read more about chart repositories with Cloudsmith [here](https://help.cloudsmith.io/docs/helm-chart-repository) ### JFrog Artifactory Similarly, you can also set up chart repositories using JFrog Artifactory. Read more about chart repositories with JFrog Artifactory [here](https://www.jfrog.com/confluence/display/RTF/Helm+Chart+Repositories) ### GitHub Pages example In a similar way you can create charts repository using GitHub Pages. GitHub allows you to serve static web pages in two different ways: - By configuring a project to serve the contents of its `docs/` directory - By configuring a project to serve a particular branch We'll take the second approach, though the first is just as easy. The first step will be to **create your gh-pages branch**. You can do that locally as. ```console $ git checkout -b gh-pages ``` Or via web browser using **Branch** button on your GitHub repository: ![Create GitHub Pages branch](/img/helm2/create-a-gh-page-button.png) Next, you'll want to make sure your **gh-pages branch** is set as GitHub Pages, click on your repo **Settings** and scroll down to **GitHub pages** section and set as per below: ![Create GitHub Pages branch](/img/helm2/set-a-gh-page.png) By default **Source** usually gets set to **gh-pages branch**. If this is not set by default, then select it. You can use a **custom domain** there if you wish so. And check that **Enforce HTTPS** is ticked, so the **HTTPS** will be used when charts are served. In such setup you can use your default branch to store your charts code, and **gh-pages branch** as charts repository, e.g.: `https://USERNAME.github.io/REPONAME`. The demonstration [TS Charts](https://github.com/technosophos/tscharts) repository is accessible at `https://technosophos.github.io/tscharts/`. If you have decided to use GitHub pages to host the chart repository, check out [Chart Releaser Action](/howto/chart_releaser_action.md). Chart Releaser Action is a GitHub Action workflow to turn a GitHub project into a self-hosted Helm chart repo, using [helm/chart-releaser](https://github.com/helm/chart-releaser) CLI tool. ### Ordinary web servers To configure an ordinary web server to serve Helm charts, you merely need to do the following: - Put your index and charts in a directory that the server can serve - Make sure the `index.yaml` file can be accessed with no authentication requirement - Make sure `yaml` files are served with the correct content type (`text/yaml` or `text/x-yaml`) For example, if you want to serve your charts out of `$WEBROOT/charts`, make sure there is a `charts/` directory in your web root, and put the index file and charts inside of that folder. ### ChartMuseum Repository Server ChartMuseum is an open-source Helm Chart Repository server written in Go (Golang), with support for cloud storage backends, including [Google Cloud Storage](https://cloud.google.com/storage/), [Amazon S3](https://aws.amazon.com/s3/), [Microsoft Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Alibaba Cloud OSS Storage](https://www.alibabacloud.com/product/oss), [Openstack Object Storage](https://developer.openstack.org/api-ref/object-store/), [Oracle Cloud Infrastructure Object Storage](https://cloud.oracle.com/storage), [Baidu Cloud BOS Storage](https://cloud.baidu.com/product/bos.html), [Tencent Cloud Object Storage](https://intl.cloud.tencent.com/product/cos), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces/), [Minio](https://min.io/), and [etcd](https://etcd.io/). You can also use the [ChartMuseum](https://chartmuseum.com/docs/#using-with-local-filesystem-storage) server to host a chart repository from a local file system. ### GitLab Package Registry With GitLab you can publish Helm charts in your project’s Package Registry. Read more about setting up a helm package repository with GitLab [here](https://docs.gitlab.com/ee/user/packages/helm_repository/). ## Managing Chart Repositories Now that you have a chart repository, the last part of this guide explains how to maintain charts in that repository. ### Store charts in your chart repository Now that you have a chart repository, let's upload a chart and an index file to the repository. Charts in a chart repository must be packaged (`helm package chart-name/`) and versioned correctly (following [SemVer 2](https://semver.org/) guidelines). These next steps compose an example workflow, but you are welcome to use whatever workflow you fancy for storing and updating charts in your chart repository. Once you have a packaged chart ready, create a new directory, and move your packaged chart to that directory. ```console $ helm package docs/examples/alpine/ $ mkdir fantastic-charts $ mv alpine-0.1.0.tgz fantastic-charts/ $ helm repo index fantastic-charts --url https://fantastic-charts.storage.googleapis.com ``` The last command takes the path of the local directory that you just created and the URL of your remote chart repository and composes an `index.yaml` file inside the given directory path. Now you can upload the chart and the index file to your chart repository using a sync tool or manually. If you're using Google Cloud Storage, check out this [example workflow](/howto/chart_repository_sync_example.md) using the gsutil client. For GitHub, you can simply put the charts in the appropriate destination branch. ### Add new charts to an existing repository Each time you want to add a new chart to your repository, you must regenerate the index. The `helm repo index` command will completely rebuild the `index.yaml` file from scratch, including only the charts that it finds locally. However, you can use the `--merge` flag to incrementally add new charts to an existing `index.yaml` file (a great option when working with a remote repository like GCS). Run `helm repo index --help` to learn more, Make sure that you upload both the revised `index.yaml` file and the chart. And if you generated a provenance file, upload that too. ### Share your charts with others When you're ready to share your charts, simply let someone know what the URL of your repository is. From there, they will add the repository to their helm client via the `helm repo add [NAME] [URL]` command with any name they would like to use to reference the repository. ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` If the charts are backed by HTTP basic authentication, you can also supply the username and password here: ```console $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo list fantastic-charts https://fantastic-charts.storage.googleapis.com ``` **Note:** A repository will not be added if it does not contain a valid `index.yaml`. **Note:** If your helm repository is e.g. using a self signed certificate, you can use `helm repo add --insecure-skip-tls-verify ...` in order to skip the CA verification. After that, your users will be able to search through your charts. After you've updated the repository, they can use the `helm repo update` command to get the latest chart information. *Under the hood, the `helm repo add` and `helm repo update` commands are fetching the index.yaml file and storing them in the `$XDG_CACHE_HOME/helm/repository/cache/` directory. This is where the `helm search` function finds information about charts.* ================================================ FILE: versioned_docs/version-3/topics/chart_tests.md ================================================ --- title: Chart Tests description: Describes how to run and test your charts. sidebar_position: 3 --- A chart contains a number of Kubernetes resources and components that work together. As a chart author, you may want to write some tests that validate that your chart works as expected when it is installed. These tests also help the chart consumer understand what your chart is supposed to do. A **test** in a helm chart lives under the `templates/` directory and is a job definition that specifies a container with a given command to run. The container should exit successfully (exit 0) for a test to be considered a success. The job definition must contain the helm test hook annotation: `helm.sh/hook: test`. Note that until Helm v3, the job definition needed to contain one of these helm test hook annotations: `helm.sh/hook: test-success` or `helm.sh/hook: test-failure`. `helm.sh/hook: test-success` is still accepted as a backwards-compatible alternative to `helm.sh/hook: test`. Example tests: - Validate that your configuration from the values.yaml file was properly injected. - Make sure your username and password work correctly - Make sure an incorrect username and password does not work - Assert that your services are up and correctly load balancing - etc. You can run the pre-defined tests in Helm on a release using the command `helm test `. For a chart consumer, this is a great way to check that their release of a chart (or application) works as expected. ## Example Test The [helm create](/helm/helm_create.md) command will automatically create a number of folders and files. To try the helm test functionality, first create a demo helm chart. ```console $ helm create demo ``` You will now be able to see the following structure in your demo helm chart. ``` demo/ Chart.yaml values.yaml charts/ templates/ templates/tests/test-connection.yaml ``` In `demo/templates/tests/test-connection.yaml` you'll see a test you can try. You can see the helm test pod definition here: ```yaml apiVersion: v1 kind: Pod metadata: name: "{{ include "demo.fullname" . }}-test-connection" labels: {{- include "demo.labels" . | nindent 4 }} annotations: "helm.sh/hook": test spec: containers: - name: wget image: busybox command: ['wget'] args: ['{{ include "demo.fullname" . }}:{{ .Values.service.port }}'] restartPolicy: Never ``` ## Steps to Run a Test Suite on a Release First, install the chart on your cluster to create a release. You may have to wait for all pods to become active; if you test immediately after this install, it is likely to show a transitive failure, and you will want to re-test. ```console $ helm install demo demo --namespace default $ helm test demo NAME: demo LAST DEPLOYED: Mon Feb 14 20:03:16 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: demo-test-connection Last Started: Mon Feb 14 20:35:19 2022 Last Completed: Mon Feb 14 20:35:23 2022 Phase: Succeeded [...] ``` ## Notes - You can define as many tests as you would like in a single yaml file or spread across several yaml files in the `templates/` directory. - You are welcome to nest your test suite under a `tests/` directory like `/templates/tests/` for more isolation. - A test is a [Helm hook](/topics/charts_hooks.md), so annotations like `helm.sh/hook-weight` and `helm.sh/hook-delete-policy` may be used with test resources. ================================================ FILE: versioned_docs/version-3/topics/charts.md ================================================ --- title: Charts description: Explains the chart format, and provides basic guidance for building charts with Helm. sidebar_position: 1 --- Helm uses a packaging format called _charts_. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on. Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed. If you want to download and look at the files for a published chart, without installing it, you can do so with `helm pull chartrepo/chartname`. This document explains the chart format, and provides basic guidance for building charts with Helm. ## The Chart File Structure A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing WordPress would be stored in a `wordpress/` directory. Inside of this directory, Helm will expect a structure that matches this: ```text wordpress/ Chart.yaml # A YAML file containing information about the chart LICENSE # OPTIONAL: A plain text file containing the license for the chart README.md # OPTIONAL: A human-readable README file values.yaml # The default configuration values for this chart values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file charts/ # A directory containing any charts upon which this chart depends. crds/ # Custom Resource Definitions templates/ # A directory of templates that, when combined with values, # will generate valid Kubernetes manifest files. templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes ``` Helm reserves use of the `charts/`, `crds/`, and `templates/` directories, and of the listed file names. Other files will be left as they are. ## The Chart.yaml File The `Chart.yaml` file is required for a chart. It contains the following fields: ```yaml apiVersion: The chart API version (required) name: The name of the chart (required) version: The version of the chart (required) kubeVersion: A SemVer range of compatible Kubernetes versions (optional) description: A single-sentence description of this project (optional) type: The type of the chart (optional) keywords: - A list of keywords about this project (optional) home: The URL of this projects home page (optional) sources: - A list of URLs to source code for this project (optional) dependencies: # A list of the chart requirements (optional) - name: The name of the chart (nginx) version: The version of the chart ("1.2.3") repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name") condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled ) tags: # (optional) - Tags can be used to group charts for enabling/disabling together import-values: # (optional) - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items. alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times maintainers: # (optional) - name: The maintainers name (required for each maintainer) email: The maintainers email (optional for each maintainer) url: A URL for the maintainer (optional for each maintainer) icon: A URL to an SVG or PNG image to be used as an icon (optional). appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended. deprecated: Whether this chart is deprecated (optional, boolean) annotations: example: A list of annotations keyed by name (optional). ``` As of [v3.3.2](https://github.com/helm/helm/releases/tag/v3.3.2), additional fields are not allowed. The recommended approach is to add custom metadata in `annotations`. ### Charts and Versioning Every chart must have a version number. A version should follow the [SemVer 2](https://semver.org/spec/v2.0.0.html) standard but it is not strictly enforced. Unlike Helm Classic, Helm v2 and later uses version numbers as release markers. Packages in repositories are identified by name plus version. For example, an `nginx` chart whose version field is set to `version: 1.2.3` will be named: ```text nginx-1.2.3.tgz ``` More complex SemVer 2 names are also supported, such as `version: 1.2.3-alpha.1+ef365`. But non-SemVer names are explicitly disallowed by the system. Subject to exception are versions in format `x` or `x.y`. For example, if there is a leading v or a version listed without all 3 parts (e.g. v1.2) it will attempt to coerce it into a valid semantic version (e.g., v1.2.0). **NOTE:** Whereas Helm Classic and Deployment Manager were both very GitHub oriented when it came to charts, Helm v2 and later does not rely upon or require GitHub or even Git. Consequently, it does not use Git SHAs for versioning at all. The `version` field inside of the `Chart.yaml` is used by many of the Helm tools, including the CLI. When generating a package, the `helm package` command will use the version that it finds in the `Chart.yaml` as a token in the package name. The system assumes that the version number in the chart package name matches the version number in the `Chart.yaml`. Failure to meet this assumption will cause an error. ### The `apiVersion` Field The `apiVersion` field should be `v2` for Helm charts that require at least Helm 3. Charts supporting previous Helm versions have an `apiVersion` set to `v1` and are still installable by Helm 3. Changes from `v1` to `v2`: - A `dependencies` field defining chart dependencies, which were located in a separate `requirements.yaml` file for `v1` charts (see [Chart Dependencies](#chart-dependencies)). - The `type` field, discriminating application and library charts (see [Chart Types](#chart-types)). ### The `appVersion` Field Note that the `appVersion` field is not related to the `version` field. It is a way of specifying the version of the application. For example, the `drupal` chart may have an `appVersion: "8.2.1"`, indicating that the version of Drupal included in the chart (by default) is `8.2.1`. This field is informational, and has no impact on chart version calculations. Wrapping the version in quotes is highly recommended. It forces the YAML parser to treat the version number as a string. Leaving it unquoted can lead to parsing issues in some cases. For example, YAML interprets `1.0` as a floating point value, and a git commit SHA like `1234e10` as scientific notation. As of Helm v3.5.0, `helm create` wraps the default `appVersion` field in quotes. ### The `kubeVersion` Field The optional `kubeVersion` field can define semver constraints on supported Kubernetes versions. Helm will validate the version constraints when installing the chart and fail if the cluster runs an unsupported Kubernetes version. Version constraints may comprise space separated AND comparisons such as ``` >= 1.13.0 < 1.15.0 ``` which themselves can be combined with the OR `||` operator like in the following example ``` >= 1.13.0 < 1.14.0 || >= 1.14.1 < 1.15.0 ``` In this example the version `1.14.0` is excluded, which can make sense if a bug in certain versions is known to prevent the chart from running properly. Apart from version constrains employing operators `=` `!=` `>` `<` `>=` `<=` the following shorthand notations are supported * hyphen ranges for closed intervals, where `1.1 - 2.3.4` is equivalent to `>= 1.1 <= 2.3.4`. * wildcards `x`, `X` and `*`, where `1.2.x` is equivalent to `>= 1.2.0 < 1.3.0`. * tilde ranges (patch version changes allowed), where `~1.2.3` is equivalent to `>= 1.2.3 < 1.3.0`. * caret ranges (minor version changes allowed), where `^1.2.3` is equivalent to `>= 1.2.3 < 2.0.0`. For a detailed explanation of supported semver constraints see [Masterminds/semver](https://github.com/Masterminds/semver). ### Deprecating Charts When managing charts in a Chart Repository, it is sometimes necessary to deprecate a chart. The optional `deprecated` field in `Chart.yaml` can be used to mark a chart as deprecated. If the **latest** version of a chart in the repository is marked as deprecated, then the chart as a whole is considered to be deprecated. The chart name can be later reused by publishing a newer version that is not marked as deprecated. The workflow for deprecating charts is: 1. Update chart's `Chart.yaml` to mark the chart as deprecated, bumping the version 2. Release the new chart version in the Chart Repository 3. Remove the chart from the source repository (e.g. git) ### Chart Types The `type` field defines the type of chart. There are two types: `application` and `library`. Application is the default type and it is the standard chart which can be operated on fully. The [library chart](/topics/library_charts.md) provides utilities or functions for the chart builder. A library chart differs from an application chart because it is not installable and usually doesn't contain any resource objects. **Note:** An application chart can be used as a library chart. This is enabled by setting the type to `library`. The chart will then be rendered as a library chart where all utilities and functions can be leveraged. All resource objects of the chart will not be rendered. ## Chart LICENSE, README and NOTES Charts can also contain files that describe the installation, configuration, usage and license of a chart. A LICENSE is a plain text file containing the [license](https://en.wikipedia.org/wiki/Software_license) for the chart. The chart can contain a license as it may have programming logic in the templates and would therefore not be configuration only. There can also be separate license(s) for the application installed by the chart, if required. A README for a chart should be formatted in Markdown (README.md), and should generally contain: - A description of the application or service the chart provides - Any prerequisites or requirements to run the chart - Descriptions of options in `values.yaml` and default values - Any other information that may be relevant to the installation or configuration of the chart When hubs and other user interfaces display details about a chart that detail is pulled from the content in the `README.md` file. The chart can also contain a short plain text `templates/NOTES.txt` file that will be printed out after installation, and when viewing the status of a release. This file is evaluated as a [template](#templates-and-values), and can be used to display usage notes, next steps, or any other information relevant to a release of the chart. For example, instructions could be provided for connecting to a database, or accessing a web UI. Since this file is printed to STDOUT when running `helm install` or `helm status`, it is recommended to keep the content brief and point to the README for greater detail. ## Chart Dependencies In Helm, one chart may depend on any number of other charts. These dependencies can be dynamically linked using the `dependencies` field in `Chart.yaml` or brought in to the `charts/` directory and managed manually. ### Managing Dependencies with the `dependencies` field The charts required by the current chart are defined as a list in the `dependencies` field. ```yaml dependencies: - name: apache version: 1.2.3 repository: https://example.com/charts - name: mysql version: 3.2.1 repository: https://another.example.com/charts ``` - The `name` field is the name of the chart you want. - The `version` field is the version of the chart you want. - The `repository` field is the full URL to the chart repository. Note that you must also use `helm repo add` to add that repo locally. - You might use the name of the repo instead of URL ```console $ helm repo add fantastic-charts https://charts.helm.sh/incubator ``` ```yaml dependencies: - name: awesomeness version: 1.0.0 repository: "@fantastic-charts" ``` Once you have defined dependencies, you can run `helm dependency update` and it will use your dependency file to download all the specified charts into your `charts/` directory for you. ```console $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "local" chart repository ...Successfully got an update from the "stable" chart repository ...Successfully got an update from the "example" chart repository ...Successfully got an update from the "another" chart repository Update Complete. Happy Helming! Saving 2 charts Downloading apache from repo https://example.com/charts Downloading mysql from repo https://another.example.com/charts ``` When `helm dependency update` retrieves charts, it will store them as chart archives in the `charts/` directory. So for the example above, one would expect to see the following files in the charts directory: ```text charts/ apache-1.2.3.tgz mysql-3.2.1.tgz ``` #### Alias field in dependencies In addition to the other fields above, each requirements entry may contain the optional field `alias`. Adding an alias for a dependency chart would put a chart in dependencies using alias as name of new dependency. One can use `alias` in cases where they need to access a chart with other name(s). ```yaml # parentchart/Chart.yaml dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-1 - name: subchart repository: http://localhost:10191 version: 0.1.0 alias: new-subchart-2 - name: subchart repository: http://localhost:10191 version: 0.1.0 ``` In the above example we will get 3 dependencies in all for `parentchart`: ```text subchart new-subchart-1 new-subchart-2 ``` The manual way of achieving this is by copy/pasting the same chart in the `charts/` directory multiple times with different names. #### Tags and Condition fields in dependencies In addition to the other fields above, each requirements entry may contain the optional fields `tags` and `condition`. All charts are loaded by default. If `tags` or `condition` fields are present, they will be evaluated and used to control loading for the chart(s) they are applied to. Condition - The condition field holds one or more YAML paths (delimited by commas). If this path exists in the top parent's values and resolves to a boolean value, the chart will be enabled or disabled based on that boolean value. Only the first valid path found in the list is evaluated and if no paths exist then the condition has no effect. Tags - The tags field is a YAML list of labels to associate with this chart. In the top parent's values, all charts with tags can be enabled or disabled by specifying the tag and a boolean value. ```yaml # parentchart/Chart.yaml dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 condition: subchart1.enabled,global.subchart1.enabled tags: - front-end - subchart1 - name: subchart2 repository: http://localhost:10191 version: 0.1.0 condition: subchart2.enabled,global.subchart2.enabled tags: - back-end - subchart2 ``` ```yaml # parentchart/values.yaml subchart1: enabled: true tags: front-end: false back-end: true ``` In the above example all charts with the tag `front-end` would be disabled but since the `subchart1.enabled` path evaluates to 'true' in the parent's values, the condition will override the `front-end` tag and `subchart1` will be enabled. Since `subchart2` is tagged with `back-end` and that tag evaluates to `true`, `subchart2` will be enabled. Also note that although `subchart2` has a condition specified, there is no corresponding path and value in the parent's values so that condition has no effect. ##### Using the CLI with Tags and Conditions The `--set` parameter can be used as usual to alter tag and condition values. ```console helm install --set tags.front-end=true --set subchart2.enabled=false ``` ##### Tags and Condition Resolution - **Conditions (when set in values) always override tags.** The first condition path that exists wins and subsequent ones for that chart are ignored. - Tags are evaluated as 'if any of the chart's tags are true then enable the chart'. - Tags and conditions values must be set in the top parent's values. - The `tags:` key in values must be a top level key. Globals and nested `tags:` tables are not currently supported. #### Importing Child Values via dependencies In some cases it is desirable to allow a child chart's values to propagate to the parent chart and be shared as common defaults. An additional benefit of using the `exports` format is that it will enable future tooling to introspect user-settable values. The keys containing the values to be imported can be specified in the parent chart's `dependencies` in the field `import-values` using a YAML list. Each item in the list is a key which is imported from the child chart's `exports` field. To import values not contained in the `exports` key, use the [child-parent](#using-the-child-parent-format) format. Examples of both formats are described below. ##### Using the exports format If a child chart's `values.yaml` file contains an `exports` field at the root, its contents may be imported directly into the parent's values by specifying the keys to import as in the example below: ```yaml # parent's Chart.yaml file dependencies: - name: subchart repository: http://localhost:10191 version: 0.1.0 import-values: - data ``` ```yaml # child's values.yaml file exports: data: myint: 99 ``` Since we are specifying the key `data` in our import list, Helm looks in the `exports` field of the child chart for `data` key and imports its contents. The final parent values would contain our exported field: ```yaml # parent's values myint: 99 ``` Please note the parent key `data` is not contained in the parent's final values. If you need to specify the parent key, use the 'child-parent' format. ##### Using the child-parent format To access values that are not contained in the `exports` key of the child chart's values, you will need to specify the source key of the values to be imported (`child`) and the destination path in the parent chart's values (`parent`). The `import-values` in the example below instructs Helm to take any values found at `child:` path and copy them to the parent's values at the path specified in `parent:` ```yaml # parent's Chart.yaml file dependencies: - name: subchart1 repository: http://localhost:10191 version: 0.1.0 ... import-values: - child: default.data parent: myimports ``` In the above example, values found at `default.data` in the subchart1's values will be imported to the `myimports` key in the parent chart's values as detailed below: ```yaml # parent's values.yaml file myimports: myint: 0 mybool: false mystring: "helm rocks!" ``` ```yaml # subchart1's values.yaml file default: data: myint: 999 mybool: true ``` The parent chart's resulting values would be: ```yaml # parent's final values myimports: myint: 999 mybool: true mystring: "helm rocks!" ``` The parent's final values now contains the `myint` and `mybool` fields imported from subchart1. ### Managing Dependencies manually via the `charts/` directory If more control over dependencies is desired, these dependencies can be expressed explicitly by copying the dependency charts into the `charts/` directory. A dependency should be an unpacked chart directory but its name cannot start with `_` or `.`. Such files are ignored by the chart loader. For example, if the WordPress chart depends on the Apache chart, the Apache chart (of the correct version) is supplied in the WordPress chart's `charts/` directory: ```yaml wordpress: Chart.yaml # ... charts/ apache/ Chart.yaml # ... mysql/ Chart.yaml # ... ``` The example above shows how the WordPress chart expresses its dependency on Apache and MySQL by including those charts inside of its `charts/` directory. **TIP:** _To drop a dependency into your `charts/` directory, use the `helm pull` command_ ### Operational aspects of using dependencies The above sections explain how to specify chart dependencies, but how does this affect chart installation using `helm install` and `helm upgrade`? Suppose that a chart named "A" creates the following Kubernetes objects - namespace "A-Namespace" - statefulset "A-StatefulSet" - service "A-Service" Furthermore, A is dependent on chart B that creates objects - namespace "B-Namespace" - replicaset "B-ReplicaSet" - service "B-Service" After installation/upgrade of chart A a single Helm release is created/modified. The release will create/update all of the above Kubernetes objects in the following order: - A-Namespace - B-Namespace - A-Service - B-Service - B-ReplicaSet - A-StatefulSet This is because when Helm installs/upgrades charts, the Kubernetes objects from the charts and all its dependencies are - aggregated into a single set; then - sorted by type followed by name; and then - created/updated in that order. Hence a single release is created with all the objects for the chart and its dependencies. The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go (see [the Helm source file](https://github.com/helm/helm/blob/484d43913f97292648c867b56768775a55e4bba6/pkg/releaseutil/kind_sorter.go)). ## Templates and Values Helm Chart templates are written in the [Go template language](https://golang.org/pkg/text/template/), with the addition of 50 or so add-on template functions [from the Sprig library](https://github.com/Masterminds/sprig) and a few other [specialized functions](/howto/charts_tips_and_tricks.md). All template files are stored in a chart's `templates/` folder. When Helm renders the charts, it will pass every file in that directory through the template engine. Values for the templates are supplied two ways: - Chart developers may supply a file called `values.yaml` inside of a chart. This file can contain default values. - Chart users may supply a YAML file that contains values. This can be provided on the command line with `helm install`. When a user supplies custom values, these values will override the values in the chart's `values.yaml` file. ### Template Files Template files follow the standard conventions for writing Go templates (see [the text/template Go package documentation](https://golang.org/pkg/text/template/) for details). An example template file might look something like this: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` The above example, based loosely on [https://github.com/deis/charts](https://github.com/deis/charts), is a template for a Kubernetes replication controller. It can use the following four template values (usually defined in a `values.yaml` file): - `imageRegistry`: The source registry for the Docker image. - `dockerTag`: The tag for the docker image. - `pullPolicy`: The Kubernetes pull policy. - `storage`: The storage backend, whose default is set to `"minio"` All of these values are defined by the template author. Helm does not require or dictate parameters. To see many working charts, check out the CNCF [Artifact Hub](https://artifacthub.io/packages/search?kind=0). ### Predefined Values Values that are supplied via a `values.yaml` file (or via the `--set` flag) are accessible from the `.Values` object in a template. But there are other pre-defined pieces of data you can access in your templates. The following values are pre-defined, are available to every template, and cannot be overridden. As with all values, the names are _case sensitive_. - `Release.Name`: The name of the release (not the chart) - `Release.Namespace`: The namespace the chart was released to. - `Release.Service`: The service that conducted the release. - `Release.IsUpgrade`: This is set to true if the current operation is an upgrade or rollback. - `Release.IsInstall`: This is set to true if the current operation is an install. - `Chart`: The contents of the `Chart.yaml`. Thus, the chart version is obtainable as `Chart.Version` and the maintainers are in `Chart.Maintainers`. - `Files`: A map-like object containing all non-special files in the chart. This will not give you access to templates, but will give you access to additional files that are present (unless they are excluded using `.helmignore`). Files can be accessed using `{{ index .Files "file.name" }}` or using the `{{.Files.Get name }}` function. You can also access the contents of the file as `[]byte` using `{{ .Files.GetBytes }}` - `Capabilities`: A map-like object that contains information about the versions of Kubernetes (`{{ .Capabilities.KubeVersion }}`) and the supported Kubernetes API versions (`{{ .Capabilities.APIVersions.Has "batch/v1" }}`) **NOTE:** Any unknown `Chart.yaml` fields will be dropped. They will not be accessible inside of the `Chart` object. Thus, `Chart.yaml` cannot be used to pass arbitrarily structured data into the template. The values file can be used for that, though. ### Values files Considering the template in the previous section, a `values.yaml` file that supplies the necessary values would look like this: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "s3" ``` A values file is formatted in YAML. A chart may include a default `values.yaml` file. The Helm install command allows a user to override values by supplying additional YAML values: ```console $ helm install --generate-name --values=myvals.yaml wordpress ``` When values are passed in this way, they will be merged into the default values file. For example, consider a `myvals.yaml` file that looks like this: ```yaml storage: "gcs" ``` When this is merged with the `values.yaml` in the chart, the resulting generated content will be: ```yaml imageRegistry: "quay.io/deis" dockerTag: "latest" pullPolicy: "Always" storage: "gcs" ``` Note that only the last field was overridden. **NOTE:** The default values file included inside of a chart _must_ be named `values.yaml`. But files specified on the command line can be named anything. **NOTE:** If the `--set` flag is used on `helm install` or `helm upgrade`, those values are simply converted to YAML on the client side. **NOTE:** If any required entries in the values file exist, they can be declared as required in the chart template by using the ['required' function](/howto/charts_tips_and_tricks.md) Any of these values are then accessible inside of templates using the `.Values` object: ```yaml apiVersion: v1 kind: ReplicationController metadata: name: deis-database namespace: deis labels: app.kubernetes.io/managed-by: deis spec: replicas: 1 selector: app.kubernetes.io/name: deis-database template: metadata: labels: app.kubernetes.io/name: deis-database spec: serviceAccount: deis-database containers: - name: deis-database image: {{ .Values.imageRegistry }}/postgres:{{ .Values.dockerTag }} imagePullPolicy: {{ .Values.pullPolicy }} ports: - containerPort: 5432 env: - name: DATABASE_STORAGE value: {{ default "minio" .Values.storage }} ``` ### Scope, Dependencies, and Values Values files can declare values for the top-level chart, as well as for any of the charts that are included in that chart's `charts/` directory. Or, to phrase it differently, a values file can supply values to the chart as well as to any of its dependencies. For example, the demonstration WordPress chart above has both `mysql` and `apache` as dependencies. The values file could supply values to all of these components: ```yaml title: "My WordPress Site" # Sent to the WordPress template mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` Charts at a higher level have access to all of the variables defined beneath. So the WordPress chart can access the MySQL password as `.Values.mysql.password`. But lower level charts cannot access things in parent charts, so MySQL will not be able to access the `title` property. Nor, for that matter, can it access `apache.port`. Values are namespaced, but namespaces are pruned. So for the WordPress chart, it can access the MySQL password field as `.Values.mysql.password`. But for the MySQL chart, the scope of the values has been reduced and the namespace prefix removed, so it will see the password field simply as `.Values.password`. #### Global Values As of 2.0.0-Alpha.2, Helm supports special "global" value. Consider this modified version of the previous example: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: max_connections: 100 # Sent to MySQL password: "secret" apache: port: 8080 # Passed to Apache ``` The above adds a `global` section with the value `app: MyWordPress`. This value is available to _all_ charts as `.Values.global.app`. For example, the `mysql` templates may access `app` as `{{ .Values.global.app}}`, and so can the `apache` chart. Effectively, the values file above is regenerated like this: ```yaml title: "My WordPress Site" # Sent to the WordPress template global: app: MyWordPress mysql: global: app: MyWordPress max_connections: 100 # Sent to MySQL password: "secret" apache: global: app: MyWordPress port: 8080 # Passed to Apache ``` This provides a way of sharing one top-level variable with all subcharts, which is useful for things like setting `metadata` properties like labels. If a subchart declares a global variable, that global will be passed _downward_ (to the subchart's subcharts), but not _upward_ to the parent chart. There is no way for a subchart to influence the values of the parent chart. Also, global variables of parent charts take precedence over the global variables from subcharts. ### Schema Files Sometimes, a chart maintainer might want to define a structure on their values. This can be done by defining a schema in the `values.schema.json` file. A schema is represented as a [JSON Schema](https://json-schema.org/). It might look something like this: ```json { "$schema": "https://json-schema.org/draft-07/schema#", "properties": { "image": { "description": "Container Image", "properties": { "repo": { "type": "string" }, "tag": { "type": "string" } }, "type": "object" }, "name": { "description": "Service name", "type": "string" }, "port": { "description": "Port", "minimum": 0, "type": "integer" }, "protocol": { "type": "string" } }, "required": [ "protocol", "port" ], "title": "Values", "type": "object" } ``` This schema will be applied to the values to validate it. Validation occurs when any of the following commands are invoked: - `helm install` - `helm upgrade` - `helm lint` - `helm template` An example of a `values.yaml` file that meets the requirements of this schema might look something like this: ```yaml name: frontend protocol: https port: 443 ``` Note that the schema is applied to the final `.Values` object, and not just to the `values.yaml` file. This means that the following `yaml` file is valid, given that the chart is installed with the appropriate `--set` option shown below. ```yaml name: frontend protocol: https ``` ```console helm install --set port=443 ``` Furthermore, the final `.Values` object is checked against *all* subchart schemas. This means that restrictions on a subchart can't be circumvented by a parent chart. This also works backwards - if a subchart has a requirement that is not met in the subchart's `values.yaml` file, the parent chart *must* satisfy those restrictions in order to be valid. Schema validation can be disabled by setting the option shown below. This is particularly useful in air-gapped environments when a chart's JSON Schema file contains remote references. ```console helm install --skip-schema-validation ``` ### References When it comes to writing templates, values, and schema files, there are several standard references that will help you out. - [Go templates](https://godoc.org/text/template) - [Extra template functions](https://godoc.org/github.com/Masterminds/sprig) - [The YAML format](https://yaml.org/spec/) - [JSON Schema](https://json-schema.org/) ## Custom Resource Definitions (CRDs) Kubernetes provides a mechanism for declaring new types of Kubernetes objects. Using CustomResourceDefinitions (CRDs), Kubernetes developers can declare custom resource types. In Helm 3, CRDs are treated as a special kind of object. They are installed before the rest of the chart, and are subject to some limitations. CRD YAML files should be placed in the `crds/` directory inside of a chart. Multiple CRDs (separated by YAML start and end markers) may be placed in the same file. Helm will attempt to load _all_ of the files in the CRD directory into Kubernetes. CRD files _cannot be templated_. They must be plain YAML documents. When Helm installs a new chart, it will upload the CRDs, pause until the CRDs are made available by the API server, and then start the template engine, render the rest of the chart, and upload it to Kubernetes. Because of this ordering, CRD information is available in the `.Capabilities` object in Helm templates, and Helm templates may create new instances of objects that were declared in CRDs. For example, if your chart had a CRD for `CronTab` in the `crds/` directory, you may create instances of the `CronTab` kind in the `templates/` directory: ```text crontabs/ Chart.yaml crds/ crontab.yaml templates/ mycrontab.yaml ``` The `crontab.yaml` file must contain the CRD with no template directives: ```yaml kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: crontabs singular: crontab kind: CronTab ``` Then the template `mycrontab.yaml` may create a new `CronTab` (using templates as usual): ```yaml apiVersion: stable.example.com kind: CronTab metadata: name: {{ .Values.name }} spec: # ... ``` Helm will make sure that the `CronTab` kind has been installed and is available from the Kubernetes API server before it proceeds installing the things in `templates/`. ### Limitations on CRDs Unlike most objects in Kubernetes, CRDs are installed globally. For that reason, Helm takes a very cautious approach in managing CRDs. CRDs are subject to the following limitations: - CRDs are never reinstalled. If Helm determines that the CRDs in the `crds/` directory are already present (regardless of version), Helm will not attempt to install or upgrade. - CRDs are never installed on upgrade or rollback. Helm will only create CRDs on installation operations. - CRDs are never deleted. Deleting a CRD automatically deletes all of the CRD's contents across all namespaces in the cluster. Consequently, Helm will not delete CRDs. Operators who want to upgrade or delete CRDs are encouraged to do this manually and with great care. ## Using Helm to Manage Charts The `helm` tool has several commands for working with charts. It can create a new chart for you: ```console $ helm create mychart Created mychart/ ``` Once you have edited a chart, `helm` can package it into a chart archive for you: ```console $ helm package mychart Archived mychart-0.1.-.tgz ``` You can also use `helm` to help you find issues with your chart's formatting or information: ```console $ helm lint mychart No issues found ``` ## Chart Repositories A _chart repository_ is an HTTP server that houses one or more packaged charts. While `helm` can be used to manage local chart directories, when it comes to sharing charts, the preferred mechanism is a chart repository. Any HTTP server that can serve YAML files and tar files and can answer GET requests can be used as a repository server. The Helm team has tested some servers, including Google Cloud Storage with website mode enabled, and S3 with website mode enabled. A repository is characterized primarily by the presence of a special file called `index.yaml` that has a list of all of the packages supplied by the repository, together with metadata that allows retrieving and verifying those packages. On the client side, repositories are managed with the `helm repo` commands. However, Helm does not provide tools for uploading charts to remote repository servers. This is because doing so would add substantial requirements to an implementing server, and thus raise the barrier for setting up a repository. ## Chart Starter Packs The `helm create` command takes an optional `--starter` option that lets you specify a "starter chart". Also, the starter option has a short alias `-p`. Examples of usage: ```console helm create my-chart --starter starter-name helm create my-chart -p starter-name helm create my-chart -p /absolute/path/to/starter-name ``` Starters are just regular charts, but are located in `$XDG_DATA_HOME/helm/starters`. As a chart developer, you may author charts that are specifically designed to be used as starters. Such charts should be designed with the following considerations in mind: - The `Chart.yaml` will be overwritten by the generator. - Users will expect to modify such a chart's contents, so documentation should indicate how users can do so. - All occurrences of `` will be replaced with the specified chart name so that starter charts can be used as templates, except for some variable files. For example, if you use custom files in the `vars` directory or certain `README.md` files, `` will NOT override inside them. Additionally, the chart description is not inherited. Currently the only way to add a chart to `$XDG_DATA_HOME/helm/starters` is to manually copy it there. In your chart's documentation, you may want to explain that process. ================================================ FILE: versioned_docs/version-3/topics/charts_hooks.md ================================================ --- title: Chart Hooks description: Describes how to work with chart hooks. sidebar_position: 2 --- Helm provides a _hook_ mechanism to allow chart developers to intervene at certain points in a release's life cycle. For example, you can use hooks to: - Load a ConfigMap or Secret during install before any other charts are loaded. - Execute a Job to back up a database before installing a new chart, and then execute a second job after the upgrade in order to restore data. - Run a Job before deleting a release to gracefully take a service out of rotation before removing it. Hooks work like regular templates, but they have special annotations that cause Helm to utilize them differently. In this section, we cover the basic usage pattern for hooks. ## The Available Hooks The following hooks are defined: | Annotation Value | Description | | ---------------- | ----------------------------------------------------------------------------------------------------- | | `pre-install` | Executes after templates are rendered, but before any resources are created in Kubernetes | | `post-install` | Executes after all resources are loaded into Kubernetes | | `pre-delete` | Executes on a deletion request before any resources are deleted from Kubernetes | | `post-delete` | Executes on a deletion request after all of the release's resources have been deleted | | `pre-upgrade` | Executes on an upgrade request after templates are rendered, but before any resources are updated | | `post-upgrade` | Executes on an upgrade request after all resources have been upgraded | | `pre-rollback` | Executes on a rollback request after templates are rendered, but before any resources are rolled back | | `post-rollback` | Executes on a rollback request after all resources have been modified | | `test` | Executes when the Helm test subcommand is invoked ([view test docs](/topics/chart_tests.md)) | _Note that the `crd-install` hook has been removed in favor of the `crds/` directory in Helm 3._ ## Hooks and the Release Lifecycle Hooks allow you, the chart developer, an opportunity to perform operations at strategic points in a release lifecycle. For example, consider the lifecycle for a `helm install`. By default, the lifecycle looks like this: 1. User runs `helm install foo` 2. The Helm library install API is called 3. After some verification, the library renders the `foo` templates 4. The library loads the resulting resources into Kubernetes 5. The library returns the release object (and other data) to the client 6. The client exits Helm defines two hooks for the `install` lifecycle: `pre-install` and `post-install`. If the developer of the `foo` chart implements both hooks, the lifecycle is altered like this: 1. User runs `helm install foo` 2. The Helm library install API is called 3. CRDs in the `crds/` directory are installed 4. After some verification, the library renders the `foo` templates 5. The library prepares to execute the `pre-install` hooks (loading hook resources into Kubernetes) 6. The library sorts hooks by weight (assigning a weight of 0 by default), by resource kind and finally by name in ascending order. 7. The library then loads the hook with the lowest weight first (negative to positive) 8. The library waits until the hook is "Ready" (except for CRDs) 9. The library loads the resulting resources into Kubernetes. Note that if the `--wait` flag is set, the library will wait until all resources are in a ready state and will not run the `post-install` hook until they are ready. 10. The library executes the `post-install` hook (loading hook resources) 11. The library waits until the hook is "Ready" 12. The library returns the release object (and other data) to the client 13. The client exits What does it mean to wait until a hook is ready? This depends on the resource declared in the hook. If the resource is a `Job` or `Pod` kind, Helm will wait until it successfully runs to completion. And if the hook fails, the release will fail. This is a _blocking operation_, so the Helm client will pause while the Job is run. For all other kinds, as soon as Kubernetes marks the resource as loaded (added or updated), the resource is considered "Ready". When many resources are declared in a hook, the resources are executed serially. If they have hook weights (see below), they are executed in weighted order. Starting from Helm 3.2.0 hook resources with same weight are installed in the same order as normal non-hook resources. Otherwise, ordering is not guaranteed. (In Helm 2.3.0 and after, they are sorted alphabetically. That behavior, though, is not considered binding and could change in the future.) It is considered good practice to add a hook weight, and set it to `0` if weight is not important. ### Hook resources are not managed with corresponding releases The resources that a hook creates are currently not tracked or managed as part of the release. Once Helm verifies that the hook has reached its ready state, it will leave the hook resource alone. Garbage collection of hook resources when the corresponding release is deleted may be added to Helm 3 in the future, so any hook resources that must never be deleted should be annotated with `helm.sh/resource-policy: keep`. Practically speaking, this means that if you create resources in a hook, you cannot rely upon `helm uninstall` to remove the resources. To destroy such resources, you need to either [add a custom `helm.sh/hook-delete-policy` annotation](#hook-deletion-policies) to the hook template file, or [set the time to live (TTL) field of a Job resource](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/). ## Writing a Hook Hooks are just Kubernetes manifest files with special annotations in the `metadata` section. Because they are template files, you can use all of the normal template features, including reading `.Values`, `.Release`, and `.Template`. For example, this template, stored in `templates/post-install-job.yaml`, declares a job to be run on `post-install`: ```yaml apiVersion: batch/v1 kind: Job metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} app.kubernetes.io/version: {{ .Chart.AppVersion }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" annotations: # This is what defines this resource as a hook. Without this line, the # job is considered part of the release. "helm.sh/hook": post-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": hook-succeeded spec: template: metadata: name: "{{ .Release.Name }}" labels: app.kubernetes.io/managed-by: {{ .Release.Service | quote }} app.kubernetes.io/instance: {{ .Release.Name | quote }} helm.sh/chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" spec: restartPolicy: Never containers: - name: post-install-job image: "alpine:3.3" command: ["/bin/sleep","{{ default "10" .Values.sleepyTime }}"] ``` What makes this template a hook is the annotation: ```yaml annotations: "helm.sh/hook": post-install ``` One resource can implement multiple hooks: ```yaml annotations: "helm.sh/hook": post-install,post-upgrade ``` Similarly, there is no limit to the number of different resources that may implement a given hook. For example, one could declare both a secret and a config map as a pre-install hook. When subcharts declare hooks, those are also evaluated. There is no way for a top-level chart to disable the hooks declared by subcharts. It is possible to define a weight for a hook which will help build a deterministic executing order. Weights are defined using the following annotation: ```yaml annotations: "helm.sh/hook-weight": "5" ``` Hook weights can be positive or negative numbers but must be represented as strings. When Helm starts the execution cycle of hooks of a particular Kind it will sort those hooks in ascending order. ### Hook deletion policies It is possible to define policies that determine when to delete corresponding hook resources. Hook deletion policies are defined using the following annotation: ```yaml annotations: "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded ``` You can choose one or more defined annotation values: | Annotation Value | Description | | ---------------------- | -------------------------------------------------------------------- | | `before-hook-creation` | Delete the previous resource before a new hook is launched (default) | | `hook-succeeded` | Delete the resource after the hook is successfully executed | | `hook-failed` | Delete the resource if the hook failed during execution | If no hook deletion policy annotation is specified, the `before-hook-creation` behavior applies by default. ================================================ FILE: versioned_docs/version-3/topics/index.mdx ================================================ --- title: Topics sidebar_position: 3 --- # Topic Guides Here you’ll find introductions to all the key parts of Helm you’ll need or want to know. import DocCardList from '@theme/DocCardList'; ================================================ FILE: versioned_docs/version-3/topics/kubernetes_apis.md ================================================ --- title: Deprecated Kubernetes APIs description: Explains deprecated Kubernetes APIs in Helm --- Kubernetes is an API-driven system and the API evolves over time to reflect the evolving understanding of the problem space. This is common practice across systems and their APIs. An important part of evolving APIs is a good deprecation policy and process to inform users of how changes to APIs are implemented. In other words, consumers of your API need to know in advance and in what release an API will be removed or changed. This removes the element of surprise and breaking changes to consumers. The [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) documents how Kubernetes handles the changes to its API versions. The policy for deprecation states the timeframe that API versions will be supported following a deprecation announcement. It is therefore important to be aware of deprecation announcements and know when API versions will be removed, to help minimize the effect. This is an example of an announcement [for the removal of deprecated API versions in Kubernetes 1.16](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) and was advertised a few months prior to the release. These API versions would have been announced for deprecation prior to this again. This shows that there is a good policy in place which informs consumers of API version support. Helm templates specify a [Kubernetes API group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups) when defining a Kubernetes object, similar to a Kubernetes manifest file. It is specified in the `apiVersion` field of the template and it identifies the API version of the Kubernetes object. This means that Helm users and chart maintainers need to be aware when Kubernetes API versions have been deprecated and in what Kubernetes version they will be removed. ## Chart Maintainers You should audit your charts checking for Kubernetes API versions that are deprecated or are removed in a Kubernetes version. The API versions found as due to be or that are now out of support, should be updated to the supported version and a new version of the chart released. The API version is defined by the `kind` and `apiVersion` fields. For example, here is a removed `Deployment` object API version in Kubernetes 1.16: ```yaml apiVersion: apps/v1beta1 kind: Deployment ``` ## Helm Users You should audit the charts that you use (similar to [chart maintainers](#chart-maintainers)) and identify any charts where API versions are deprecated or removed in a Kubernetes version. For the charts identified, you need to check for the latest version of the chart (which has supported API versions) or update the chart yourself. Additionally, you also need to audit any charts deployed (i.e. Helm releases) checking again for any deprecated or removed API versions. This can be done by getting details of a release using the `helm get manifest` command. The means for updating a Helm release to supported APIs depends on your findings as follows: 1. If you find deprecated API versions only then: - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version 2. If you find any API version(s) that is/are removed in a Kubernetes version then: - If you are running a Kubernetes version where the API version(s) are still available (for example, you are on Kubernetes 1.15 and found you use APIs that will be removed in Kubernetes 1.16): - Follow the step 1 procedure - Otherwise (for example, you are already running a Kubernetes version where some API versions reported by `helm get manifest` are no longer available): - You need to edit the release manifest that is stored in the cluster to update the API versions to supported APIs. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details > Note: In all cases of updating a Helm release with supported APIs, you should never rollback the release to a version prior to the release version with the supported APIs. > Recommendation: The best practice is to upgrade releases using deprecated API versions to supported API versions, prior to upgrading to a kubernetes cluster that removes those API versions. If you don't update a release as suggested previously, you will have an error similar to the following when trying to upgrade a release in a Kubernetes version where its API version(s) is/are removed: ``` Error: UPGRADE FAILED: current release manifest contains removed kubernetes api(s) for this kubernetes version and it is therefore unable to build the kubernetes objects for performing the diff. error from kubernetes: unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta1" ``` Helm fails in this scenario because it attempts to create a diff patch between the current deployed release (which contains the Kubernetes APIs that are removed in this Kubernetes version) against the chart you are passing with the updated/supported API versions. The underlying reason for failure is that when Kubernetes removes an API version, the Kubernetes Go client library can no longer parse the deprecated objects and Helm therefore fails when calling the library. Helm unfortunately is unable to recover from this situation and is no longer able to manage such a release. See [Updating API Versions of a Release Manifest](#updating-api-versions-of-a-release-manifest) for more details on how to recover from this scenario. ## Updating API Versions of a Release Manifest The manifest is a property of the Helm release object which is stored in the data field of a Secret (default) or ConfigMap in the cluster. The data field contains a gzipped object which is base 64 encoded (there is an additional base 64 encoding for a Secret). There is a Secret/ConfigMap per release version/revision in the namespace of the release. You can use the Helm [mapkubeapis](https://github.com/helm/helm-mapkubeapis) plugin to perform the update of a release to supported APIs. Check out the readme for more details. Alternatively, you can follow these manual steps to perform an update of the API versions of a release manifest. Depending on your configuration you will follow the steps for the Secret or ConfigMap backend. - Get the name of the Secret or Configmap associated with the latest deployed release: - Secrets backend: `kubectl get secret -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - ConfigMap backend: `kubectl get configmap -l owner=helm,status=deployed,name= --namespace | awk '{print $1}' | grep -v NAME` - Get latest deployed release details: - Secrets backend: `kubectl get secret -n -o yaml > release.yaml` - ConfigMap backend: `kubectl get configmap -n -o yaml > release.yaml` - Backup the release in case you need to restore if something goes wrong: - `cp release.yaml release.bak` - In case of emergency, restore: `kubectl apply -f release.bak -n ` - Decode the release object: - Secrets backend:`cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | base64 -d | gzip -d > release.data.decoded` - ConfigMap backend: `cat release.yaml | grep -oP '(?<=release: ).*' | base64 -d | gzip -d > release.data.decoded` - Change API versions of the manifests. Can use any tool (e.g. editor) to make the changes. This is in the `manifest` field of your decoded release object (`release.data.decoded`) - Encode the release object: - Secrets backend: `cat release.data.decoded | gzip | base64 | base64` - ConfigMap backend: `cat release.data.decoded | gzip | base64` - Replace `data.release` property value in the deployed release file (`release.yaml`) with the new encoded release object - Apply file to namespace: `kubectl apply -f release.yaml -n ` - Perform a `helm upgrade` with a version of the chart with supported Kubernetes API versions - Add a description in the upgrade, something along the lines to not perform a rollback to a Helm version prior to this current version ================================================ FILE: versioned_docs/version-3/topics/kubernetes_distros.md ================================================ --- title: Kubernetes Distribution Guide description: Captures information about using Helm in specific Kubernetes environments. sidebar_position: 10 --- Helm should work with any [conformant version of Kubernetes](https://github.com/cncf/k8s-conformance) (whether [certified](https://www.cncf.io/certification/software-conformance/) or not). This document captures information about using Helm in specific Kubernetes environments. Please contribute more details about any distros (sorted alphabetically) if desired. ## AKS Helm works with [Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm). ## DC/OS Helm has been tested and is working on Mesospheres DC/OS 1.11 Kubernetes platform, and requires no additional configuration. ## EKS Helm works with Amazon Elastic Kubernetes Service (Amazon EKS): [Using Helm with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html). ## GKE Google's GKE hosted Kubernetes platform is known to work with Helm, and requires no additional configuration. ## `scripts/local-cluster` and Hyperkube Hyperkube configured via `scripts/local-cluster.sh` is known to work. For raw Hyperkube you may need to do some manual configuration. ## IKS Helm works with [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-helm). ## KIND (Kubernetes IN Docker) Helm is regularly tested on [KIND](https://github.com/kubernetes-sigs/kind). ## KubeOne Helm works in clusters that are set up by KubeOne without caveats. ## Kubermatic Helm works in user clusters that are created by Kubermatic without caveats. Since seed cluster can be set up in different ways Helm support depends on their configuration. ## MicroK8s Helm can be enabled in [MicroK8s](https://microk8s.io) using the command: `microk8s.enable helm3` ## Minikube Helm is tested and known to work with [Minikube](https://github.com/kubernetes/minikube). It requires no additional configuration. ## Openshift Helm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To learn more read [this blog](https://blog.openshift.com/getting-started-helm-openshift/) post. ## Platform9 Helm is pre-installed with [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/?utm_source=helm_distro_notes). Platform9 provides access to all official Helm charts through the App Catalog UI and native Kubernetes CLI. Additional repositories can be manually added. Further details are available in this [Platform9 App Catalog article](https://platform9.com/support/deploying-kubernetes-apps-platform9-managed-kubernetes/?utm_source=helm_distro_notes). ## Ubuntu with `kubeadm` Kubernetes bootstrapped with `kubeadm` is known to work on the following Linux distributions: - Ubuntu 16.04 - Fedora release 25 Some versions of Helm (v2.0.0-beta2) require you to `export KUBECONFIG=/etc/kubernetes/admin.conf` or create a `~/.kube/config`. ## VMware Tanzu Kubernetes Grid Helm runs on VMware Tanzu Kubernetes Grid, TKG, without needing configuration changes. The Tanzu CLI can manage installing packages for [helm-controller](https://fluxcd.io/flux/components/helm/) allowing for declaratively managing Helm chart releases. Further details available in the TKG documentation for [CLI-Managed Packages](https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.6/vmware-tanzu-kubernetes-grid-16/GUID-packages-user-managed-index.html#package-locations-and-dependencies-5). ================================================ FILE: versioned_docs/version-3/topics/library_charts.md ================================================ --- title: Library Charts description: Explains library charts and examples of usage sidebar_position: 4 --- A library chart is a type of [Helm chart](/topics/charts.md) that defines chart primitives or definitions which can be shared by Helm templates in other charts. This allows users to share snippets of code that can be re-used across charts, avoiding repetition and keeping charts [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). The library chart was introduced in Helm 3 to formally recognize common or helper charts that have been used by chart maintainers since Helm 2. By including it as a chart type, it provides: - A means to explicitly distinguish between common and application charts - Logic to prevent installation of a common chart - No rendering of templates in a common chart which may contain release artifacts - Allow for dependent charts to use the importer's context A chart maintainer can define a common chart as a library chart and now be confident that Helm will handle the chart in a standard consistent fashion. It also means that definitions in an application chart can be shared by changing the chart type. ## Create a Simple Library Chart As mentioned previously, a library chart is a type of [Helm chart](/topics/charts.md). This means that you can start off by creating a scaffold chart: ```console $ helm create mylibchart Creating mylibchart ``` You will first remove all the files in `templates` directory as we will create our own templates definitions in this example. ```console $ rm -rf mylibchart/templates/* ``` The values file will not be required either. ```console $ rm -f mylibchart/values.yaml ``` Before we jump into creating common code, lets do a quick review of some relevant Helm concepts. A [named template](/chart_template_guide/named_templates.md) (sometimes called a partial or a subtemplate) is simply a template defined inside of a file, and given a name. In the `templates/` directory, any file that begins with an underscore(_) is not expected to output a Kubernetes manifest file. So by convention, helper templates and partials are placed in a `_*.tpl` or `_*.yaml` files. In this example, we will code a common ConfigMap which creates an empty ConfigMap resource. We will define the common ConfigMap in file `mylibchart/templates/_configmap.yaml` as follows: ```yaml {{- define "mylibchart.configmap.tpl" -}} apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: {} {{- end -}} {{- define "mylibchart.configmap" -}} {{- include "mylibchart.util.merge" (append . "mylibchart.configmap.tpl") -}} {{- end -}} ``` The ConfigMap construct is defined in named template `mylibchart.configmap.tpl`. It is a simple ConfigMap with an empty resource, `data`. Within this file there is another named template called `mylibchart.configmap`. This named template includes another named template `mylibchart.util.merge` which will take 2 named templates as arguments, the template calling `mylibchart.configmap` and `mylibchart.configmap.tpl`. The helper function `mylibchart.util.merge` is a named template in `mylibchart/templates/_util.yaml`. It is a handy util from [The Common Helm Helper Chart](#the-common-helm-helper-chart) because it merges the 2 templates and overrides any common parts in both: ```yaml {{- /* mylibchart.util.merge will merge two YAML templates and output the result. This takes an array of three values: - the top context - the template name of the overrides (destination) - the template name of the base (source) */}} {{- define "mylibchart.util.merge" -}} {{- $top := first . -}} {{- $overrides := fromYaml (include (index . 1) $top) | default (dict ) -}} {{- $tpl := fromYaml (include (index . 2) $top) | default (dict ) -}} {{- toYaml (merge $overrides $tpl) -}} {{- end -}} ``` This is important when a chart wants to use common code that it needs to customize with its configuration. Finally, lets change the chart type to `library`. This requires editing `mylibchart/Chart.yaml` as follows: ```yaml apiVersion: v2 name: mylibchart description: A Helm chart for Kubernetes # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. # type: application type: library # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application and it is recommended to use it with quotes. appVersion: "1.16.0" ``` The library chart is now ready to be shared and its ConfigMap definition to be re-used. Before moving on, it is worth checking if Helm recognizes the chart as a library chart: ```console $ helm install mylibchart mylibchart/ Error: library charts are not installable ``` ## Use the Simple Library Chart It is time to use the library chart. This means creating a scaffold chart again: ```console $ helm create mychart Creating mychart ``` Lets clean out the template files again as we want to create a ConfigMap only: ```console $ rm -rf mychart/templates/* ``` When we want to create a simple ConfigMap in a Helm template, it could look similar to the following: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name | printf "%s-%s" .Chart.Name }} data: myvalue: "Hello World" ``` We are however going to re-use the common code already created in `mylibchart`. The ConfigMap can be created in the file `mychart/templates/configmap.yaml` as follows: ```yaml {{- include "mylibchart.configmap" (list . "mychart.configmap") -}} {{- define "mychart.configmap" -}} data: myvalue: "Hello World" {{- end -}} ``` You can see that it simplifies the work we have to do by inheriting the common ConfigMap definition which adds standard properties for ConfigMap. In our template we add the configuration, in this case the data key `myvalue` and its value. The configuration override the empty resource of the common ConfigMap. This is feasible because of the helper function `mylibchart.util.merge` we mentioned in the previous section. To be able to use the common code, we need to add `mylibchart` as a dependency. Add the following to the end of the file `mychart/Chart.yaml`: ```yaml # My common code in my library chart dependencies: - name: mylibchart version: 0.1.0 repository: file://../mylibchart ``` This includes the library chart as a dynamic dependency from the filesystem which is at the same parent path as our application chart. As we are including the library chart as a dynamic dependency, we need to run `helm dependency update`. It will copy the library chart into your `charts/` directory. ```console $ helm dependency update mychart/ Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "stable" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Deleting outdated charts ``` We are now ready to deploy our chart. Before installing, it is worth checking the rendered template first. ```console $ helm install mydemo mychart/ --debug --dry-run install.go:159: [debug] Original chart version: "" install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:48:47 2020 NAMESPACE: default STATUS: pending-install REVISION: 1 TEST SUITE: None USER-SUPPLIED VALUES: {} COMPUTED VALUES: affinity: {} fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx imagePullSecrets: [] ingress: annotations: {} enabled: false hosts: - host: chart-example.local paths: [] tls: [] mylibchart: global: {} nameOverride: "" nodeSelector: {} podSecurityContext: {} replicaCount: 1 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: null tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` This looks like the ConfigMap we want with data override of `myvalue: Hello World`. Lets install it: ```console $ helm install mydemo mychart/ NAME: mydemo LAST DEPLOYED: Tue Mar 3 17:52:40 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ``` We can retrieve the release and see that the actual template was loaded. ```console $ helm get manifest mydemo --- # Source: mychart/templates/configmap.yaml apiVersion: v1 data: myvalue: Hello World kind: ConfigMap metadata: labels: app: mychart chart: mychart-0.1.0 release: mydemo name: mychart-mydemo ``` ## Library Chart Benefits Because of their inability to act as standalone charts, library charts can leverage the following functionality: - The `.Files` object references the file paths on the parent chart, rather than the path local to the library chart - The `.Values` object is the same as the parent chart, in contrast to application [subcharts](/chart_template_guide/subcharts_and_globals.md) which receive the section of values configured under their header in the parent. ## The Common Helm Helper Chart ```markdown Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived. ``` This [chart](https://github.com/helm/charts/tree/master/incubator/common) was the original pattern for common charts. It provides utilities that reflect best practices of Kubernetes chart development. Best of all it can be used off the bat by you when developing your charts to give you handy shared code. Here is a quick way to use it. For more details, have a look at the [README](https://github.com/helm/charts/blob/master/incubator/common/README.md). Create a scaffold chart again: ```console $ helm create demo Creating demo ``` Lets use the common code from the helper chart. First, edit deployment `demo/templates/deployment.yaml` as follows: ```yaml {{- template "common.deployment" (list . "demo.deployment") -}} {{- define "demo.deployment" -}} ## Define overrides for your Deployment resource here, e.g. apiVersion: apps/v1 spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include "demo.selectorLabels" . | nindent 6 }} template: metadata: labels: {{- include "demo.selectorLabels" . | nindent 8 }} {{- end -}} ``` And now the service file, `demo/templates/service.yaml` as follows: ```yaml {{- template "common.service" (list . "demo.service") -}} {{- define "demo.service" -}} ## Define overrides for your Service resource here, e.g. # metadata: # labels: # custom: label # spec: # ports: # - port: 8080 {{- end -}} ``` These templates show how inheriting the common code from the helper chart simplifies your coding down to your configuration or customization of the resources. To be able to use the common code, we need to add `common` as a dependency. Add the following to the end of the file `demo/Chart.yaml`: ```yaml dependencies: - name: common version: "^0.0.5" repository: "https://charts.helm.sh/incubator/" ``` Note: You will need to add the `incubator` repo to the Helm repository list (`helm repo add`). As we are including the chart as a dynamic dependency, we need to run `helm dependency update`. It will copy the helper chart into your `charts/` directory. As helper chart is using some Helm 2 constructs, you will need to add the following to `demo/values.yaml` to enable the `nginx` image to be loaded as this was updated in Helm 3 scaffold chart: ```yaml image: tag: 1.16.0 ``` You can test that the chart templates are correct prior to deploying using the `helm lint` and `helm template` commands. If it's good to go, deploy away using `helm install`! ================================================ FILE: versioned_docs/version-3/topics/permissions_sql_storage_backend.md ================================================ --- title: Permissions management for SQL storage backend description: Get to know how to setup permissions when using SQL storage backend. --- This document aims to provide guidance to users for setting up and managing permissions when using the SQL storage backend. ## Introduction To handle permissions, Helm leverages the RBAC feature of Kubernetes. When using the SQL storage backend, Kubernetes' roles can't be used to determine whether or not an user can access a given resource. This document shows how to create and manage these permissions. ## Initialization The first time the Helm CLI will make connect to your database, the client will make sure that it was previously initialized. If it is not, it will take care of the necessary setup automatically. This initialization requires admin privileges on the public schema, or at least to be able to: * create a table * grant privileges on the public schema After the migration was run against your database, all the other roles can use the client. ## Grant privileges to a non admin user in PostgreSQL To manage permissions, the SQL backend driver leverages the [RLS](https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html)(Row Security Level) feature of PostgreSQL. RLS allows all users to be able to read/write from/to the same table, without being able to manipulate the same rows if they are not explicitly allowed to. By default, any role that has not been explicitly granted with the right privileges will always return an empty list when running `helm list` and will not be able to retrieve or modify any resource in the cluster. Let's see how to grant a given role access to specific namespaces: ```sql CREATE POLICY ON releases_v1 FOR ALL TO USING (namespace = 'default'); ``` This command will grant the permissions to read and write all resources that meet the `namespace = 'default'` condition to the role `role`. After creating this policy, the user being connected to the database on the behalf of the role `role` will therefore be able to see all the releases living in the `default` namespace when running `helm list`, and to modify and delete them. Privileges can be managed granularly with RLS, and one might be interested in restraining access given the different columns of the table: * key * type * body * name * namespace * version * status * owner * createdAt * modifiedAt ================================================ FILE: versioned_docs/version-3/topics/plugins.md ================================================ --- title: The Helm Plugins Guide description: Introduces how to use and create plugins to extend Helm's functionality. sidebar_position: 12 --- A Helm plugin is a tool that can be accessed through the `helm` CLI, but which is not part of the built-in Helm codebase. Existing plugins can be found on [related](/community/related#helm-plugins) section or by searching [GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories). This guide explains how to use and create plugins. ## An Overview Helm plugins are add-on tools that integrate seamlessly with Helm. They provide a way to extend the core feature set of Helm, but without requiring every new feature to be written in Go and added to the core tool. Helm plugins have the following features: - They can be added and removed from a Helm installation without impacting the core Helm tool. - They can be written in any programming language. - They integrate with Helm, and will show up in `helm help` and other places. Helm plugins live in `$HELM_PLUGINS`. You can find the current value of this, including the default value when not set in the environment, using the `helm env` command. The Helm plugin model is partially based on Git's plugin model. To that end, you may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins being the _plumbing_. This is a shorthand way of suggesting that Helm provides the user experience and top level processing logic, while the plugins do the "detail work" of performing a desired action. ## Installing a Plugin Plugins are installed using the `$ helm plugin install ` command. You can pass in a path to a plugin on your local file system or a url of a remote VCS repo. The `helm plugin install` command clones or copies the plugin at the path/url given into `$HELM_PLUGINS`. If you are installing from a VCS you can specify the version with the `--version` argument. ```console $ helm plugin install https://github.com/adamreese/helm-env ``` If you have a plugin tar distribution, simply untar the plugin into the `$HELM_PLUGINS` directory. You can also install tarball plugins directly from url by issuing `helm plugin install https://domain/path/to/plugin.tar.gz` ## The Plugin File Structure In many ways, a plugin is similar to a chart. Each plugin has a top-level directory containing a `plugin.yaml` file. Additional files may be present but only the `plugin.yaml` file is required. ```console $HELM_PLUGINS/ |- last/ |- plugin.yaml ``` ## The plugin.yaml File The plugin.yaml file is required for a plugin. It contains the following fields: ```yaml name: The name of the plugin (REQUIRED) version: A SemVer 2 version (REQUIRED) usage: Single line usage text shown in help description: Long description shown in places like helm help ignoreFlags: Ignore flags passed in from Helm platformCommand: # Configure command to run based on the platform - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin command to execute args: Plugin command arguments command: (DEPRECATED) Plugin command, use platformCommand instead platformHooks: # Configure plugin lifecycle hooks based on the platform install: # Install lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin install command to execute args: Plugin install command arguments update: # Update lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin update command to execute args: Plugin update command arguments delete: # Delete lifecycle commands - os: OS match, can be empty or omitted to match all OS' arch: Architecture match, can be empty or omitted to match all architectures command: Plugin delete command to execute args: Plugin delete command arguments hooks: # (Deprecated) Plugin lifecycle hooks, use platformHooks instead install: Command to install plugin update: Command to update plugin delete: Command to delete plugin downloaders: # Configure downloaders capability - command: Command to invoke protocols: - Protocol schema supported ``` ### The `name` Field The `name` is the name of the plugin. When Helm executes this plugin, this is the name it will use (e.g. `helm NAME` will invoke this plugin). _`name` should match the directory name._ In our example above, that means the plugin with `name: last` should be contained in a directory named `last`. Restrictions on `name`: - `name` cannot duplicate one of the existing `helm` top-level commands. - `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`. ### The `version` Field The `version` is the SemVer 2 version of the plugin. `usage` and `description` are both used to generate the help text of a command. ### The `ignoreFlags` Field The `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a plugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then `--foo` is silently discarded. ### The `platformCommand` Field The `platformCommand` configures the command that the plugin will execute when it is called. You can't set both `platformCommand` & `command` as this will result in an error. The following rules will apply in deciding which command to use: - If `platformCommand` is present, it will be used. - If both `os` and `arch` match the current platform, search will stop and the command will be used. - If `os` matches and `arch` is empty, the command will be used. - If `os` and `arch` are both empty, the command will be used. - If there is no match, Helm will exit with an error. - If `platformCommand` is not present and the deprecated `command` is present it will be used. - If the command is empty, Helm will exit with an error. ### The `platformHooks` Field The `platformHooks` configures the commands that the plugin will execute for lifecycle events. You can't set both `platformHooks` & `hooks` as this will resultin an error. The following rules will apply in deciding which hook command to use: - If `platformHooks` is present, it will be used and the commands for the lifecycle event will be processed. - If both `os` and `arch` match the current platform, search will stop and the command will be used. - If `os` matches and `arch` is empty, the command will be used. - If `os` and `arch` are both empty, the command will be used. - If there is no match, Helm will skip the event. - If `platformHooks` is not present and the deprecated `hooks` is present the command for the lifecycle event will be used. - If the command is empty, Helm will skip the event. ## Building a Plugin Here is the plugin YAML for a simple plugin that helps get the last release name: ```yaml name: last version: 0.1.0 usage: get the last release name description: get the last release name ignoreFlags: false platformCommand: - command: ${HELM_BIN} args: - list - --short - --max=1 - --date - -r ``` Plugins may require additional scripts and executables. Scripts can be included in the plugin directory and executables can be downloaded via a hook. The following is an example plugin: ```console $HELM_PLUGINS/ |- myplugin/ |- scripts/ |- install.ps1 |- install.sh |- plugin.yaml ``` ```yaml name: myplugin version: 0.1.0 usage: example plugin description: example plugin ignoreFlags: false platformCommand: - command: ${HELM_PLUGIN_DIR}/bin/myplugin - os: windows command: ${HELM_PLUGIN_DIR}\bin\myplugin.exe platformHooks: install: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 update: - command: ${HELM_PLUGIN_DIR}/scripts/install.sh args: - -u - os: windows command: pwsh args: - -c - ${HELM_PLUGIN_DIR}\scripts\install.ps1 - -Update ``` Environment variables are interpolated before the plugin is executed. The pattern above illustrates the preferred way to indicate where the plugin program lives. ### Plugin Commands There are some strategies for working with plugin commands: - If a plugin includes an executable, the executable for a `platformCommand:` or should be packaged in the plugin directory or installed via a hook. - The `platformCommand:` or `command:` line will have any environment variables expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin directory. - The command itself is not executed in a shell. So you can't oneline a shell script. - Helm injects lots of configuration into environment variables. Take a look at the environment to see what information is available. - Helm makes no assumptions about the language of the plugin. You can write it in whatever you prefer. - Commands are responsible for implementing specific help text for `-h` and `--help`. Helm will use `usage` and `description` for `helm help` and `helm help myplugin`, but will not handle `helm myplugin --help`. ### Testing a Local Plugin First you need to find your `HELM_PLUGINS` path to do it run the following command: ``` bash helm env ``` Change your current directory to the director that `HELM_PLUGINS` is set to. Now you can add a symbolic link to your build output of your plugin in this example we did it for `mapkubeapis`. ``` bash ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis ``` ## Downloader Plugins By default, Helm is able to pull Charts using HTTP/S. As of Helm 2.4.0, plugins can have a special capability to download Charts from arbitrary sources. Plugins shall declare this special capability in the `plugin.yaml` file (top level): ```yaml downloaders: - command: "bin/mydownloader" protocols: - "myprotocol" - "myprotocols" ``` If such plugin is installed, Helm can interact with the repository using the specified protocol scheme by invoking the `command`. The special repository shall be added similarly to the regular ones: `helm repo add favorite myprotocol://example.com/` The rules for the special repos are the same to the regular ones: Helm must be able to download the `index.yaml` file in order to discover and cache the list of available Charts. The defined command will be invoked with the following scheme: `command certFile keyFile caFile full-URL`. The SSL credentials are coming from the repo definition, stored in `$HELM_REPOSITORY_CONFIG` (i.e., `$HELM_CONFIG_HOME/repositories.yaml`). A Downloader plugin is expected to dump the raw content to stdout and report errors on stderr. The downloader command also supports sub-commands or arguments, allowing you to specify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This is useful if you want to use the same executable for the main plugin command and the downloader command, but with a different sub-command for each. ## Environment Variables When Helm executes a plugin, it passes the outer environment to the plugin, and also injects some additional environment variables. Variables like `KUBECONFIG` are set for the plugin if they are set in the outer environment. The following variables are guaranteed to be set: - `HELM_PLUGINS`: The path to the plugins directory. - `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm myplug` will have the short name `myplug`. - `HELM_PLUGIN_DIR`: The directory that contains the plugin. - `HELM_BIN`: The path to the `helm` command (as executed by the user). - `HELM_DEBUG`: Indicates if the debug flag was set by helm. - `HELM_REGISTRY_CONFIG`: The location for the registry configuration (if using). Note that the use of Helm with registries is an experimental feature. - `HELM_REPOSITORY_CACHE`: The path to the repository cache files. - `HELM_REPOSITORY_CONFIG`: The path to the repository configuration file. - `HELM_NAMESPACE`: The namespace given to the `helm` command (generally using the `-n` flag). - `HELM_KUBECONTEXT`: The name of the Kubernetes config context given to the `helm` command. Additionally, if a Kubernetes configuration file was explicitly specified, it will be set as the `KUBECONFIG` variable ## A Note on Flag Parsing When executing a plugin, Helm will parse global flags for its own use. None of these flags are passed on to the plugin. - `--burst-limit`: This is converted to `$HELM_BURST_LIMIT` - `--debug`: If this is specified, `$HELM_DEBUG` is set to `1` - `--kube-apiserver`: This is converted to `$HELM_KUBEAPISERVER` - `--kube-as-group`: These are converted to `$HELM_KUBEASGROUPS` - `--kube-as-user`: This is converted to `$HELM_KUBEASUSER` - `--kube-ca-file`: This is converted to `$HELM_KUBECAFILE` - `--kube-context`: This is converted to `$HELM_KUBECONTEXT` - `--kube-insecure-skip-tls-verify`: This is converted to `$HELM_KUBEINSECURE_SKIP_TLS_VERIFY` - `--kube-tls-server-name`: This is converted to `$HELM_KUBETLS_SERVER_NAME` - `--kube-token`: This is converted to `$HELM_KUBETOKEN` - `--kubeconfig`: This is converted to `$KUBECONFIG` - `--namespace` and `-n`: This is converted to `$HELM_NAMESPACE` - `--qps`: This is converted to `$HELM_QPS` - `--registry-config`: This is converted to `$HELM_REGISTRY_CONFIG` - `--repository-cache`: This is converted to `$HELM_REPOSITORY_CACHE` - `--repository-config`: This is converted to `$HELM_REPOSITORY_CONFIG` Plugins _should_ display help text and then exit for `-h` and `--help`. In all other cases, plugins may use flags as appropriate. ## Providing shell auto-completion As of Helm 3.2, a plugin can optionally provide support for shell auto-completion as part of Helm's existing auto-completion mechanism. ### Static auto-completion If a plugin provides its own flags and/or sub-commands, it can inform Helm of them by having a `completion.yaml` file located in the plugin's root directory. The `completion.yaml` file has the form: ```yaml name: flags: - - validArgs: - - commands: name: flags: - - validArgs: - - commands: ``` Notes: 1. All sections are optional but should be provided if applicable. 1. Flags should not include the `-` or `--` prefix. 1. Both short and long flags can and should be specified. A short flag need not be associated with its corresponding long form, but both forms should be listed. 1. Flags need not be ordered in any way, but need to be listed at the correct point in the sub-command hierarchy of the file. 1. Helm's existing global flags are already handled by Helm's auto-completion mechanism, therefore plugins need not specify the following flags `--debug`, `--namespace` or `-n`, `--kube-context`, and `--kubeconfig`, or any other global flag. 1. The `validArgs` list provides a static list of possible completions for the first parameter following a sub-command. It is not always possible to provide such a list in advance (see the [Dynamic Completion](#dynamic-completion) section below), in which case the `validArgs` section can be omitted. The `completion.yaml` file is entirely optional. If it is not provided, Helm will simply not provide shell auto-completion for the plugin (unless [Dynamic Completion](#dynamic-completion) is supported by the plugin). Also, adding a `completion.yaml` file is backwards-compatible and will not impact the behavior of the plugin when using older helm versions. As an example, for the [`fullstatus plugin`](https://github.com/marckhouzam/helm-fullstatus) which has no sub-commands but accepts the same flags as the `helm status` command, the `completion.yaml` file is: ```yaml name: fullstatus flags: - o - output - revision ``` A more intricate example for the [`2to3 plugin`](https://github.com/helm/helm-2to3), has a `completion.yaml` file of: ```yaml name: 2to3 commands: - name: cleanup flags: - config-cleanup - dry-run - l - label - release-cleanup - s - release-storage - tiller-cleanup - t - tiller-ns - tiller-out-cluster - name: convert flags: - delete-v2-releases - dry-run - l - label - s - release-storage - release-versions-max - t - tiller-ns - tiller-out-cluster - name: move commands: - name: config flags: - dry-run ``` ### Dynamic completion Also starting with Helm 3.2, plugins can provide their own dynamic shell auto-completion. Dynamic shell auto-completion is the completion of parameter values or flag values that cannot be defined in advance. For example, completion of the names of helm releases currently available on the cluster. For the plugin to support dynamic auto-completion, it must provide an **executable** file called `plugin.complete` in its root directory. When the Helm completion script requires dynamic completions for the plugin, it will execute the `plugin.complete` file, passing it the command-line that needs to be completed. The `plugin.complete` executable will need to have the logic to determine what the proper completion choices are and output them to standard output to be consumed by the Helm completion script. The `plugin.complete` file is entirely optional. If it is not provided, Helm will simply not provide dynamic auto-completion for the plugin. Also, adding a `plugin.complete` file is backwards-compatible and will not impact the behavior of the plugin when using older helm versions. The output of the `plugin.complete` script should be a new-line separated list such as: ```console rel1 rel2 rel3 ``` When `plugin.complete` is called, the plugin environment is set just like when the plugin's main script is called. Therefore, the variables `$HELM_NAMESPACE`, `$HELM_KUBECONTEXT`, and all other plugin variables will already be set, and their corresponding global flags will be removed. The `plugin.complete` file can be in any executable form; it can be a shell script, a Go program, or any other type of program that Helm can execute. The `plugin.complete` file ***must*** have executable permissions for the user. The `plugin.complete` file ***must*** exit with a success code (value 0). In some cases, dynamic completion will require to obtain information from the Kubernetes cluster. For example, the `helm fullstatus` plugin requires a release name as input. In the `fullstatus` plugin, for its `plugin.complete` script to provide completion for current release names, it can simply run `helm list -q` and output the result. If it is desired to use the same executable for plugin execution and for plugin completion, the `plugin.complete` script can be made to call the main plugin executable with some special parameter or flag; when the main plugin executable detects the special parameter or flag, it will know to run the completion. In our example, `plugin.complete` could be implemented like this: ```sh #!/usr/bin/env sh # "$@" is the entire command-line that requires completion. # It is important to double-quote the "$@" variable to preserve a possibly empty last parameter. $HELM_PLUGIN_DIR/status.sh --complete "$@" ``` The `fullstatus` plugin's real script (`status.sh`) must then look for the `--complete` flag and if found, printout the proper completions. ### Tips and tricks 1. The shell will automatically filter out completion choices that don't match user input. A plugin can therefore return all relevant completions without removing the ones that don't match the user input. For example, if the command-line is `helm fullstatus ngin`, the `plugin.complete` script can print *all* release names (of the `default` namespace), not just the ones starting with `ngin`; the shell will only retain the ones starting with `ngin`. 1. To simplify dynamic completion support, especially if you have a complex plugin, you can have your `plugin.complete` script call your main plugin script and request completion choices. See the [Dynamic Completion](#dynamic-completion) section above for an example. 1. To debug dynamic completion and the `plugin.complete` file, one can run the following to see the completion results : - `helm __complete `. For example: - `helm __complete fullstatus --output js`, - `helm __complete fullstatus -o json ""` ================================================ FILE: versioned_docs/version-3/topics/provenance.md ================================================ --- title: Helm Provenance and Integrity description: Describes how to verify the integrity and origin of a Chart. sidebar_position: 5 --- Helm has provenance tools which help chart users verify the integrity and origin of a package. Using industry-standard tools based on PKI, GnuPG, and well-respected package managers, Helm can generate and verify signature files. ## Overview Integrity is established by comparing a chart to a provenance record. Provenance records are stored in _provenance files_, which are stored alongside a packaged chart. For example, if a chart is named `myapp-1.2.3.tgz`, its provenance file will be `myapp-1.2.3.tgz.prov`. Provenance files are generated at packaging time (`helm package --sign ...`), and can be checked by multiple commands, notably `helm install --verify`. ## The Workflow This section describes a potential workflow for using provenance data effectively. Prerequisites: - A valid PGP keypair in a binary (not ASCII-armored) format - The `helm` command line tool - GnuPG command line tools (optional) - Keybase command line tools (optional) **NOTE:** If your PGP private key has a passphrase, you will be prompted to enter that passphrase for any commands that support the `--sign` option. Creating a new chart is the same as before: ```console $ helm create mychart Creating mychart ``` Once ready to package, add the `--sign` flag to `helm package`. Also, specify the name under which the signing key is known and the keyring containing the corresponding private key: ```console $ helm package --sign --key 'John Smith' --keyring path/to/keyring.secret mychart ``` **Note:** The value of the `--key` argument must be a substring of the desired key's `uid` (in the output of `gpg --list-keys`), for example the name or email. **The fingerprint _cannot_ be used.** **TIP:** for GnuPG users, your secret keyring is in `~/.gnupg/secring.gpg`. You can use `gpg --list-secret-keys` to list the keys you have. **Warning:** the GnuPG v2 store your secret keyring using a new format `kbx` on the default location `~/.gnupg/pubring.kbx`. Please use the following command to convert your keyring to the legacy gpg format: ```console $ gpg --export >~/.gnupg/pubring.gpg $ gpg --export-secret-keys >~/.gnupg/secring.gpg ``` At this point, you should see both `mychart-0.1.0.tgz` and `mychart-0.1.0.tgz.prov`. Both files should eventually be uploaded to your desired chart repository. You can verify a chart using `helm verify`: ```console $ helm verify mychart-0.1.0.tgz ``` A failed verification looks like this: ```console $ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a" ``` To verify during an install, use the `--verify` flag. ```console $ helm install --generate-name --verify mychart-0.1.0.tgz ``` If the keyring containing the public key associated with the signed chart is not in the default location, you may need to point to the keyring with `--keyring PATH` as in the `helm package` example. If verification fails, the install will be aborted before the chart is even rendered. ### Using Keybase.io credentials The [Keybase.io](https://keybase.io) service makes it easy to establish a chain of trust for a cryptographic identity. Keybase credentials can be used to sign charts. Prerequisites: - A configured Keybase.io account - GnuPG installed locally - The `keybase` CLI installed locally #### Signing packages The first step is to import your keybase keys into your local GnuPG keyring: ```console $ keybase pgp export -s | gpg --import ``` This will convert your Keybase key into the OpenPGP format, and then import it locally into your `~/.gnupg/secring.gpg` file. You can double check by running `gpg --list-secret-keys`. ```console $ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg ------------------------------------- sec 2048R/1FC18762 2016-07-25 uid technosophos (keybase.io/technosophos) ssb 2048R/D125E546 2016-07-25 ``` Note that your secret key will have an identifier string: ``` technosophos (keybase.io/technosophos) ``` That is the full name of your key. Next, you can package and sign a chart with `helm package`. Make sure you use at least part of that name string in `--key`. ```console $ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart ``` As a result, the `package` command should produce both a `.tgz` file and a `.tgz.prov` file. #### Verifying packages You can also use a similar technique to verify a chart signed by someone else's Keybase key. Say you want to verify a package signed by `keybase.io/technosophos`. To do this, use the `keybase` tool: ```console $ keybase follow technosophos $ keybase pgp pull ``` The first command above tracks the user `technosophos`. Next `keybase pgp pull` downloads the OpenPGP keys of all of the accounts you follow, placing them in your GnuPG keyring (`~/.gnupg/pubring.gpg`). At this point, you can now use `helm verify` or any of the commands with a `--verify` flag: ```console $ helm verify somechart-1.2.3.tgz ``` ### Reasons a chart may not verify These are common reasons for failure. - The `.prov` file is missing or corrupt. This indicates that something is misconfigured or that the original maintainer did not create a provenance file. - The key used to sign the file is not in your keyring. This indicate that the entity who signed the chart is not someone you've already signaled that you trust. - The verification of the `.prov` file failed. This indicates that something is wrong with either the chart or the provenance data. - The file hashes in the provenance file do not match the hash of the archive file. This indicates that the archive has been tampered with. If a verification fails, there is reason to distrust the package. ## The Provenance File The provenance file contains a chart’s YAML file plus several pieces of verification information. Provenance files are designed to be automatically generated. The following pieces of provenance data are added: * The chart file (`Chart.yaml`) is included to give both humans and tools an easy view into the contents of the chart. * The signature (SHA256, just like Docker) of the chart package (the `.tgz` file) is included, and may be used to verify the integrity of the chart package. * The entire body is signed using the algorithm used by OpenPGP (see [Keybase.io](https://keybase.io) for an emerging way of making crypto signing and verification easy). The combination of this gives users the following assurances: * The package itself has not been tampered with (checksum package `.tgz`). * The entity who released this package is known (via the GnuPG/PGP signature). The format of the file looks something like this: ``` Hash: SHA512 apiVersion: v2 appVersion: "1.16.0" description: Sample chart name: mychart type: application version: 0.1.0 ... files: mychart-0.1.0.tgz: sha256:d31d2f08b885ec696c37c7f7ef106709aaf5e8575b6d3dc5d52112ed29a9cb92 -----BEGIN PGP SIGNATURE----- wsBcBAEBCgAQBQJdy0ReCRCEO7+YH8GHYgAAfhUIADx3pHHLLINv0MFkiEYpX/Kd nvHFBNps7hXqSocsg0a9Fi1LRAc3OpVh3knjPfHNGOy8+xOdhbqpdnB+5ty8YopI mYMWp6cP/Mwpkt7/gP1ecWFMevicbaFH5AmJCBihBaKJE4R1IX49/wTIaLKiWkv2 cR64bmZruQPSW83UTNULtdD7kuTZXeAdTMjAK0NECsCz9/eK5AFggP4CDf7r2zNi hZsNrzloIlBZlGGns6mUOTO42J/+JojnOLIhI3Psd0HBD2bTlsm/rSfty4yZUs7D qtgooNdohoyGSzR5oapd7fEvauRQswJxOA0m0V+u9/eyLR0+JcYB8Udi1prnWf8= =aHfz -----END PGP SIGNATURE----- ``` Note that the YAML section contains two documents (separated by `...\n`). The first file is the content of `Chart.yaml`. The second is the checksums, a map of filenames to SHA-256 digests of that file's content at packaging time. The signature block is a standard PGP signature, which provides [tamper resistance](https://www.rossde.com/PGP/pgp_signatures.html). ## Chart Repositories Chart repositories serve as a centralized collection of Helm charts. Chart repositories must make it possible to serve provenance files over HTTP via a specific request, and must make them available at the same URI path as the chart. For example, if the base URL for a package is `https://example.com/charts/mychart-1.2.3.tgz`, the provenance file, if it exists, MUST be accessible at `https://example.com/charts/mychart-1.2.3.tgz.prov`. From the end user's perspective, `helm install --verify myrepo/mychart-1.2.3` should result in the download of both the chart and the provenance file with no additional user configuration or action. ### Signatures in OCI-based registries When publishing charts to an [OCI-based registry](/topics/registries.md), the [`helm-sigstore` plugin](https://github.com/sigstore/helm-sigstore/) can be used to publish provenance to [sigstore](https://sigstore.dev/). [As described in the documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md), the process of creating provenance and signing with a GPG key are common, but the `helm sigstore upload` command can be used to publish the provenance to an immutable transparency log. ## Establishing Authority and Authenticity When dealing with chain-of-trust systems, it is important to be able to establish the authority of a signer. Or, to put this plainly, the system above hinges on the fact that you trust the person who signed the chart. That, in turn, means you need to trust the public key of the signer. One of the design decisions with Helm has been that the Helm project would not insert itself into the chain of trust as a necessary party. We don't want to be "the certificate authority" for all chart signers. Instead, we strongly favor a decentralized model, which is part of the reason we chose OpenPGP as our foundational technology. So when it comes to establishing authority, we have left this step more-or-less undefined in Helm 2 (a decision carried forward in Helm 3). However, we have some pointers and recommendations for those interested in using the provenance system: - The [Keybase](https://keybase.io) platform provides a public centralized repository for trust information. - You can use Keybase to store your keys or to get the public keys of others. - Keybase also has fabulous documentation available - While we haven't tested it, Keybase's "secure website" feature could be used to serve Helm charts. - The basic idea is that an official "chart reviewer" signs charts with her or his key, and the resulting provenance file is then uploaded to the chart repository. - There has been some work on the idea that a list of valid signing keys may be included in the `index.yaml` file of a repository. ================================================ FILE: versioned_docs/version-3/topics/rbac.md ================================================ --- title: Role-based Access Control description: Explains how Helm interacts with Kubernetes' Role-Based Access Control. sidebar_position: 11 --- In Kubernetes, granting roles to a user or an application-specific service account is a best practice to ensure that your application is operating in the scope that you have specified. Read more about service account permissions [in the official Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions). From Kubernetes 1.6 onwards, Role-based Access Control is enabled by default. RBAC allows you to specify which types of actions are permitted depending on the user and their role in your organization. With RBAC, you can - grant privileged operations (creating cluster-wide resources, like new roles) to administrators - limit a user's ability to create resources (pods, persistent volumes, deployments) to specific namespaces, or in cluster-wide scopes (resource quotas, roles, custom resource definitions) - limit a user's ability to view resources either in specific namespaces or at a cluster-wide scope. This guide is for administrators who want to restrict the scope of a user's interaction with the Kubernetes API. ## Managing user accounts All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. Normal users are assumed to be managed by an outside, independent service. An administrator distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords. In this regard, Kubernetes does not have objects which represent normal user accounts. Normal users cannot be added to a cluster through an API call. In contrast, service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as Secrets, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API. API requests are tied to either a normal user or a service account, or are treated as anonymous requests. This means every process inside or outside the cluster, from a human user typing `kubectl` on a workstation, to kubelets on nodes, to members of the control plane, must authenticate when making requests to the API server, or be treated as an anonymous user. ## Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings In Kubernetes, user accounts and service accounts can only view and edit resources they have been granted access to. This access is granted through the use of Roles and RoleBindings. Roles and RoleBindings are bound to a particular namespace, which grant users the ability to view and/or edit resources within that namespace the Role provides them access to. At a cluster scope, these are called ClusterRoles and ClusterRoleBindings. Granting a user a ClusterRole grants them access to view and/or edit resources across the entire cluster. It is also required to view and/or edit resources at the cluster scope (namespaces, resource quotas, nodes). ClusterRoles can be bound to a particular namespace through reference in a RoleBinding. The `admin`, `edit` and `view` default ClusterRoles are commonly used in this manner. These are a few ClusterRoles available by default in Kubernetes. They are intended to be user-facing roles. They include super-user roles (`cluster-admin`), and roles with more granular access (`admin`, `edit`, `view`). | Default ClusterRole | Default ClusterRoleBinding | Description |---------------------|----------------------------|------------- | `cluster-admin` | `system:masters` group | Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself. | `admin` | None | Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and rolebindings within the namespace. It does not allow write access to resource quota or to the namespace itself. | `edit` | None | Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings. | `view` | None | Allows read-only access to see most objects in a namespace. It does not allow viewing roles or rolebindings. It does not allow viewing secrets, since those are escalating. ## Restricting a user account's access using RBAC Now that we understand the basics of Role-based Access Control, let's discuss how an administrator can restrict a user's scope of access. ### Example: Grant a user read/write access to a particular namespace To restrict a user's access to a particular namespace, we can use either the `edit` or the `admin` role. If your charts create or interact with Roles and Rolebindings, you'll want to use the `admin` ClusterRole. Additionally, you may also create a RoleBinding with `cluster-admin` access. Granting a user `cluster-admin` access at the namespace scope provides full control over every resource in the namespace, including the namespace itself. For this example, we will create a user with the `edit` Role. First, create the namespace: ```console $ kubectl create namespace foo ``` Now, create a RoleBinding in that namespace, granting the user the `edit` role. ```console $ kubectl create rolebinding sam-edit --clusterrole edit \​ --user sam \​ --namespace foo ``` ### Example: Grant a user read/write access at the cluster scope If a user wishes to install a chart that installs cluster-scope resources (namespaces, roles, custom resource definitions, etc.), they will require cluster-scope write access. To do that, grant the user either `admin` or `cluster-admin` access. Granting a user `cluster-admin` access grants them access to absolutely every resource available in Kubernetes, including node access with `kubectl drain` and other administrative tasks. It is highly recommended to consider providing the user `admin` access instead, or to create a custom ClusterRole tailored to their needs. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ### Example: Grant a user read-only access to a particular namespace You might've noticed that there is no ClusterRole available for viewing secrets. The `view` ClusterRole does not grant a user read access to Secrets due to escalation concerns. Helm stores release metadata as Secrets by default. In order for a user to run `helm list`, they need to be able to read these secrets. For that, we will create a special `secret-reader` ClusterRole. Create the file `cluster-role-secret-reader.yaml` and write the following content into the file: ```yaml apiVersion: rbac.authorization.k8s.io/v1​ kind: ClusterRole​ metadata:​ name: secret-reader​ rules:​ - apiGroups: [""]​ resources: ["secrets"]​ verbs: ["get", "watch", "list"] ``` Then, create the ClusterRole using ```console $ kubectl create -f clusterrole-secret-reader.yaml​ ``` Once that's done, we can grant a user read access to most resources, and then grant them read access to secrets: ```console $ kubectl create namespace foo $ kubectl create rolebinding sam-view --clusterrole view \​ --user sam \​ --namespace foo $ kubectl create rolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam \​ --namespace foo ``` ### Example: Grant a user read-only access at the cluster scope In certain scenarios, it may be beneficial to grant a user cluster-scope access. For example, if a user wants to run the command `helm list --all-namespaces`, the API requires the user has cluster-scope read access. To do that, grant the user both `view` and `secret-reader` access as described above, but with a ClusterRoleBinding. ```console $ kubectl create clusterrolebinding sam-view --clusterrole view \​ --user sam $ kubectl create clusterrolebinding sam-secret-reader --clusterrole secret-reader \​ --user sam ``` ## Additional Thoughts The examples shown above utilize the default ClusterRoles provided with Kubernetes. For more fine-grained control over what resources users are granted access to, have a look at [the Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) on creating your own custom Roles and ClusterRoles. ================================================ FILE: versioned_docs/version-3/topics/registries.md ================================================ --- title: Use OCI-based registries description: Describes how to use OCI for Chart distribution. sidebar_position: 7 --- Beginning in Helm 3, you can use container registries with [OCI](https://www.opencontainers.org/) support to store and share chart packages. Beginning in Helm v3.8.0, OCI support is enabled by default. ## OCI support prior to v3.8.0 OCI support graduated from experimental to general availability with Helm v3.8.0. In prior versions of Helm, OCI support behaved differently. If you were using OCI support prior to Helm v3.8.0, its important to understand what has changed with different versions of Helm. ### Enabling OCI support prior to v3.8.0 Prior to Helm v3.8.0, OCI support is *experimental* and must be enabled. To enable OCI experimental support for Helm versions prior to v3.8.0, set `HELM_EXPERIMENTAL_OCI` in your environment. For example: ```console export HELM_EXPERIMENTAL_OCI=1 ``` ### OCI feature deprecation and behavior changes with v3.8.0 The release of [Helm v3.8.0](https://github.com/helm/helm/releases/tag/v3.8.0), the following features and behaviors are different from previous versions of Helm: - When setting a chart in the dependencies as OCI, the version can be set to a range like other dependencies. - SemVer tags that include build information can be pushed and used. OCI registries don't support `+` as a tag character. Helm translates the `+` to `_` when stored as a tag. - The `helm registry login` command now follows the same structure as the Docker CLI for storing credentials. The same location for registry configuration can be passed to both Helm and the Docker CLI. ### OCI feature deprecation and behavior changes with v3.7.0 The release of [Helm v3.7.0](https://github.com/helm/helm/releases/tag/v3.7.0) included the implementation of [HIP 6](https://github.com/helm/community/blob/main/hips/hip-0006.md) for OCI support. As a result, the following features and behaviors are different from previous versions of Helm: - The `helm chart` subcommand has been removed. - The chart cache has been removed (no `helm chart list` etc.). - OCI registry references are now always prefixed with `oci://`. - The basename of the registry reference must *always* match the chart's name. - The tag of the registry reference must *always* match the chart's semantic version (i.e. no `latest` tags). - The chart layer media type was switched from `application/tar+gzip` to `application/vnd.cncf.helm.chart.content.v1.tar+gzip`. ## Using an OCI-based registry ### Helm repositories in OCI-based registries A [Helm repository](/topics/chart_repository.md) is a way to house and distribute packaged Helm charts. An OCI-based registry can contain zero or more Helm repositories and each of those repositories can contain zero or more packaged Helm charts. ### Use hosted registries There are several hosted container registries with OCI support that you can use for your Helm charts. For example: - [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html) - [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/container-registry-helm-repos#push-chart-to-registry-as-oci-artifact) - [Cloudsmith](https://help.cloudsmith.io/docs/oci-repository) - [Docker Hub](https://docs.docker.com/docker-hub/oci-artifacts/) - [Google Artifact Registry](https://cloud.google.com/artifact-registry/docs/helm/manage-charts) - [Harbor](https://goharbor.io/docs/main/administration/user-defined-oci-artifact/) - [IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_helm_charts) - [JFrog Artifactory](https://jfrog.com/help/r/jfrog-artifactory-documentation/helm-oci-repositories) - [RepoFlow](https://docs.repoflow.io/PackageTypes/helm#oci-helm-support) Follow the hosted container registry provider's documentation to create and configure a registry with OCI support. **Note:** You can run [Docker Registry](https://docs.docker.com/registry/deploying/) or [`zot`](https://github.com/project-zot/zot), which are OCI-based registries, on your development computer. Running an OCI-based registry on your development computer should only be used for testing purposes. ### Using sigstore to sign OCI-based charts The [`helm-sigstore`](https://github.com/sigstore/helm-sigstore) plugin allows using [Sigstore](https://sigstore.dev/) to sign Helm charts with the same tools used to sign container images. This provides an alternative to the [GPG-based provenance](/topics/provenance.md) supported by classic [chart repositories](/topics/chart_repository.md). For more details on using the `helm sigstore` plugin, see [that project's documentation](https://github.com/sigstore/helm-sigstore/blob/main/USAGE.md). ## Commands for working with registries ### The `registry` subcommand #### `login` login to a registry (with manual password entry) ```console $ helm registry login -u myuser localhost:5000 Password: Login succeeded ``` #### `logout` logout from a registry ```console $ helm registry logout localhost:5000 Logout succeeded ``` ### The `push` subcommand Upload a chart to an OCI-based registry: ```console $ helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts Pushed: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:ec5f08ee7be8b557cd1fc5ae1a0ac985e8538da7c93f51a51eff4b277509a723 ``` The `push` subcommand can only be used against `.tgz` files created ahead of time using `helm package`. When using `helm push` to upload a chart an OCI registry, the reference must be prefixed with `oci://` and must not contain the basename or tag. The registry reference basename is inferred from the chart's name, and the tag is inferred from the chart's semantic version. This is currently a strict requirement. Certain registries require the repository and/or namespace (if specified) to be created beforehand. Otherwise, an error will be produced during the `helm push` operation. If you have created a [provenance file](/topics/provenance.md) (`.prov`), and it is present next to the chart `.tgz` file, it will automatically be uploaded to the registry upon `push`. This results in an extra layer on [the Helm chart manifest](#helm-chart-manifest). Users of the [helm-push plugin](https://github.com/chartmuseum/helm-push) (for uploading charts to [ChartMuseum](/topics/chart_repository.md#chartmuseum-repository-server)) may experience issues, since the plugin conflicts with the new, built-in `push`. As of version v0.10.0, the plugin has been renamed to `cm-push`. ### Other subcommands Support for the `oci://` protocol is also available in various other subcommands. Here is a complete list: - `helm pull` - `helm push` - `helm show ` - `helm template` - `helm install` - `helm upgrade` The basename (chart name) of the registry reference *is* included for any type of action involving chart download (vs. `helm push` where it is omitted). Here are a few examples of using the subcommands listed above against OCI-based charts: ``` $ helm pull oci://localhost:5000/helm-charts/mychart --version 0.1.0 Pulled: localhost:5000/helm-charts/mychart:0.1.0 Digest: sha256:0be7ec9fb7b962b46d81e4bb74fdcdb7089d965d3baca9f85d64948b05b402ff $ helm show all oci://localhost:5000/helm-charts/mychart --version 0.1.0 apiVersion: v2 appVersion: 1.16.0 description: A Helm chart for Kubernetes name: mychart ... $ helm template myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 --- # Source: mychart/templates/serviceaccount.yaml apiVersion: v1 kind: ServiceAccount ... $ helm install myrelease oci://localhost:5000/helm-charts/mychart --version 0.1.0 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... $ helm upgrade myrelease oci://localhost:5000/helm-charts/mychart --version 0.2.0 Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:12:05 2021 NAMESPACE: default STATUS: deployed REVISION: 2 NOTES: ... ``` ## Installing charts with digest Installing a chart with a digest is more secure than a tag because digests are immutable. The digest is specified in the chart URI: ``` $ helm install myrelease oci://localhost:5000/helm-charts/mychart@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79 NAME: myrelease LAST DEPLOYED: Wed Oct 27 15:11:40 2021 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: ... ``` ## Specifying dependencies Dependencies of a chart can be pulled from a registry using the `dependency update` subcommand. The `repository` for a given entry in `Chart.yaml` is specified as the registry reference without the basename: ``` dependencies: - name: mychart version: "2.7.0" repository: "oci://localhost:5000/myrepo" ``` This will fetch `oci://localhost:5000/myrepo/mychart:2.7.0` when `dependency update` is executed. ## Helm chart manifest Example Helm chart manifest as represented in a registry (note the `mediaType` fields): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 } ] } ``` The following example contains a [provenance file](/topics/provenance.md) (note the extra layer): ```json { "schemaVersion": 2, "config": { "mediaType": "application/vnd.cncf.helm.config.v1+json", "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111", "size": 117 }, "layers": [ { "mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip", "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617", "size": 2487 }, { "mediaType": "application/vnd.cncf.helm.chart.provenance.v1.prov", "digest": "sha256:3e207b409db364b595ba862cdc12be96dcdad8e36c59a03b7b3b61c946a5741a", "size": 643 } ] } ``` ## Migrating from chart repos Migrating from classic [chart repositories](/topics/chart_repository.md) (index.yaml-based repos) is as simple using `helm pull`, then using `helm push` to upload the resulting `.tgz` files to a registry. ================================================ FILE: versioned_docs/version-3/topics/v2_v3_migration.md ================================================ --- title: Migrating Helm v2 to v3 description: Learn how to migrate Helm v2 to v3. sidebar_position: 13 --- This guide shows how to migrate Helm v2 to v3. Helm v2 needs to be installed and managing releases in one or more clusters. ## Overview of Helm 3 Changes The full list of changes from Helm 2 to 3 are documented in the [FAQ section](/faq/changes_since_helm2.md). The following is a summary of some of those changes that a user should be aware of before and during migration: 1. Removal of Tiller: - Replaces client/server with client/library architecture (`helm` binary only) - Security is now on per user basis (delegated to Kubernetes user cluster security) - Releases are now stored as in-cluster secrets and the release object metadata has changed - Releases are persisted on a release namespace basis and not in the Tiller namespace anymore 2. Chart repository updated: - `helm search` now supports both local repository searches and making search queries against Artifact Hub 3. Chart apiVersion bumped to "v2" for following specification changes: - Dynamically linked chart dependencies moved to `Chart.yaml` (`requirements.yaml` removed and requirements --> dependencies) - Library charts (helper/common charts) can now be added as dynamically linked chart dependencies - Charts have a `type` metadata field to define the chart to be of an `application` or `library` chart. It is application by default which means it is renderable and installable - Helm 2 charts (apiVersion=v1) are still installable 4. XDG directory specification added: - Helm home removed and replaced with XDG directory specification for storing configuration files - No longer need to initialize Helm - `helm init` and `helm home` removed 5. Additional changes: - Helm install/set-up is simplified: - Helm client (helm binary) only (no Tiller) - Run-as-is paradigm - `local` or `stable` repositories are not set-up by default - `crd-install` hook removed and replaced with `crds` directory in chart where all CRDs defined in it will be installed before any rendering of the chart - `test-failure` hook annotation value removed, and `test-success` deprecated. Use `test` instead - Commands removed/replaced/added: - delete --> uninstall : removes all release history by default (previously needed `--purge`) - fetch --> pull - home (removed) - init (removed) - install: requires release name or `--generate-name` argument - inspect --> show - reset (removed) - serve (removed) - template: `-x`/`--execute` argument renamed to `-s`/`--show-only` - upgrade: Added argument `--history-max` which limits the maximum number of revisions saved per release (0 for no limit) - Helm 3 Go library has undergone a lot of changes and is incompatible with the Helm 2 library - Release binaries are now hosted on `get.helm.sh` ## Migration Use Cases The migration use cases are as follows: 1. Helm v2 and v3 managing the same cluster: - This use case is only recommended if you intend to phase out Helm v2 gradually and do not require v3 to manage any releases deployed by v2. All new releases being deployed should be performed by v3 and existing v2 deployed releases are updated/removed by v2 only - Helm v2 and v3 can quite happily manage the same cluster. The Helm versions can be installed on the same or separate systems - If installing Helm v3 on the same system, you need to perform an additional step to ensure that both client versions can co-exist until ready to remove Helm v2 client. Rename or put the Helm v3 binary in a different folder to avoid conflict - Otherwise there are no conflicts between both versions because of the following distinctions: - v2 and v3 release (history) storage are independent of each other. The changes include the Kubernetes resource for storage and the release object metadata contained in the resource. Releases will also be on a per user namespace instead of using the Tiller namespace (for example, v2 default Tiller namespace kube-system). v2 uses "ConfigMaps" or "Secrets" under the Tiller namespace and `TILLER`ownership. v3 uses "Secrets" in the user namespace and `helm` ownership. Releases are incremental in both v2 and v3 - The only issue could be if Kubernetes cluster scoped resources (e.g. `clusterroles.rbac`) are defined in a chart. The v3 deployment would then fail even if unique in the namespace as the resources would clash - v3 configuration no longer uses `$HELM_HOME` and uses XDG directory specification instead. It is also created on the fly as need be. It is therefore independent of v2 configuration. This is applicable only when both versions are installed on the same system 2. Migrating Helm v2 to Helm v3: - This use case applies when you want Helm v3 to manage existing Helm v2 releases - It should be noted that a Helm v2 client: - can manage 1 to many Kubernetes clusters - can connect to 1 to many Tiller instances for a cluster - This means that you have to be aware of this when migrating as releases are deployed into clusters by Tiller and its namespace. You have to therefore be aware of migrating for each cluster and each Tiller instance that is managed by the Helm v2 client instance - The recommended data migration path is as follows: 1. Backup v2 data 2. Migrate Helm v2 configuration 3. Migrate Helm v2 releases 4. When confident that Helm v3 is managing all Helm v2 data (for all clusters and Tiller instances of the Helm v2 client instance) as expected, then clean up Helm v2 data - The migration process is automated by the Helm v3 [2to3](https://github.com/helm/helm-2to3) plugin ## Reference - Helm v3 [2to3](https://github.com/helm/helm-2to3) plugin - Blog [post](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) explaining `2to3` plugin usage with examples ================================================ FILE: versioned_docs/version-3/topics/version_skew.md ================================================ --- title: "Helm Version Support Policy" description: "Describes Helm's patch release policy as well as the maximum version skew supported between Helm and Kubernetes." --- This document describes the maximum version skew supported between Helm and Kubernetes. ## Supported Versions Helm versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, following [Semantic Versioning](https://semver.org/spec/v2.0.0.html) terminology. The Helm project maintains a release branch for the most recent minor release. Applicable fixes, including security fixes, are cherry-picked into the release branch, depending on severity and feasibility. More details can be found in [Helm's release policy](/community/release_policy). ## Supported Version Skew When a new version of Helm is released, it is compiled against a particular minor version of Kubernetes. For example, Helm 3.0.0 interacts with Kubernetes using the Kubernetes 1.16.2 client, so it is compatible with Kubernetes 1.16. As of Helm 3, Helm is assumed to be compatible with `n-3` versions of Kubernetes it was compiled against. Due to Kubernetes' changes between minor versions, Helm 2's support policy is slightly stricter, assuming to be compatible with `n-1` versions of Kubernetes. For example, if you are using a version of Helm 3 that was compiled against the Kubernetes 1.17 client APIs, then it should be safe to use with Kubernetes 1.17, 1.16, 1.15, and 1.14. If you are using a version of Helm 2 that was compiled against the Kubernetes 1.16 client APIs, then it should be safe to use with Kubernetes 1.16 and 1.15. It is not recommended to use Helm with a version of Kubernetes that is newer than the version it was compiled against, as Helm does not make any forward compatibility guarantees. If you choose to use Helm with a version of Kubernetes that it does not support, you are using it at your own risk. Please refer to the table below to determine what version of Helm is compatible with your cluster. | Helm Version | Supported Kubernetes Versions | |--------------|-------------------------------| | 3.20.x | 1.35.x - 1.32.x | | 3.19.x | 1.34.x - 1.31.x | | 3.18.x | 1.33.x - 1.30.x | | 3.17.x | 1.32.x - 1.29.x | | 3.16.x | 1.31.x - 1.28.x | | 3.15.x | 1.30.x - 1.27.x | | 3.14.x | 1.29.x - 1.26.x | | 3.13.x | 1.28.x - 1.25.x | | 3.12.x | 1.27.x - 1.24.x | | 3.11.x | 1.26.x - 1.23.x | | 3.10.x | 1.25.x - 1.22.x | | 3.9.x | 1.24.x - 1.21.x | | 3.8.x | 1.23.x - 1.20.x | | 3.7.x | 1.22.x - 1.19.x | | 3.6.x | 1.21.x - 1.18.x | | 3.5.x | 1.20.x - 1.17.x | | 3.4.x | 1.19.x - 1.16.x | | 3.3.x | 1.18.x - 1.15.x | | 3.2.x | 1.18.x - 1.15.x | | 3.1.x | 1.17.x - 1.14.x | | 3.0.x | 1.16.x - 1.13.x | | 2.16.x | 1.16.x - 1.15.x | | 2.15.x | 1.15.x - 1.14.x | | 2.14.x | 1.14.x - 1.13.x | | 2.13.x | 1.13.x - 1.12.x | | 2.12.x | 1.12.x - 1.11.x | | 2.11.x | 1.11.x - 1.10.x | | 2.10.x | 1.10.x - 1.9.x | | 2.9.x | 1.10.x - 1.9.x | | 2.8.x | 1.9.x - 1.8.x | | 2.7.x | 1.8.x - 1.7.x | | 2.6.x | 1.7.x - 1.6.x | | 2.5.x | 1.6.x - 1.5.x | | 2.4.x | 1.6.x - 1.5.x | | 2.3.x | 1.5.x - 1.4.x | | 2.2.x | 1.5.x - 1.4.x | | 2.1.x | 1.5.x - 1.4.x | | 2.0.x | 1.4.x - 1.3.x | ================================================ FILE: versioned_sidebars/version-2-sidebars.json ================================================ { "tutorialSidebar": [ { "type": "autogenerated", "dirName": "." } ] } ================================================ FILE: versioned_sidebars/version-3-sidebars.json ================================================ { "tutorialSidebar": [ { "type": "autogenerated", "dirName": "." } ] } ================================================ FILE: versions.json ================================================ ["3", "2"]